On May 16, 2012, at 2:18 PM, Roy Stogner wrote: > True. We never really expect anyone to call reinit() except after > changing the mesh, though, do we? I suppose maybe if your mesh is > staying fixed but your stencil is changing you might be calling it to > reinitialize ImplicitSystem matrices?
This is essentially what we are doing… but it's an "implicit" stencil that happens between "contact" surfaces (I say "contact" because it might not actually be contact… just two disparate surfaces that need to communicate). So when we are calling reinit() our mesh numbering is changing out from under us… flubbing up everything we've done for "contact". Now that I've thought about this for a few days (and based on your reply) here's what I'm thinking: Why don't we _only_ renumber nodes and elements that are "beyond" the initial mesh. What I mean by that is this: a: Read mesh containing elements 4,3,1,2 (out of order on purpose) b: Refine some to create 5,6,7… leave 4,3,1,2 alone so we have this "ordering": 4,3,1,2,5,6,7 c: Coarsen later to remove 6 so now we have 4,3,1,2,5,_,7 d: Contract ONLY elements beyond the initial mesh so we would get 4,3,1,2,5,6 (where 7 has now become 6) This should be pretty trivial to do by keeping track of the max elem # and max node # for the mesh we've read in… and only reordering / contracting elements/nodes from those numbers on. That way, our original mesh continues to have the same ordering. This works perfectly because we can't coarsen beyond our initial mesh in libMesh… so we won't ever get holes there…. > Even if we did come up with a way to track vanishing and reappearing > nodes, nodes are an artifact of the discretization - caring about a > coefficient at node N is like caring about the float at memory address > 0xC0DE. Track the value by Point location rather than by Node index > and you get a sane result even if the node gets coarsened away, even > if you switch from a Lagrange to a non-nodal basis set, etc. Yes, yes. That will fly in my ivory tower and yours… but there are realities involved here as well. MOOSE does currently allow users to track values at nodes given by node id. It's something our users wanted and needed… and in some cases it makes sense. For instance, how do you track by x,y,z position when you have a MOVING mesh? But ultimately, it's just a convenience thing. Note that when users are tracking by node id it has to be a node _in the initial mesh_…. so my scheme outlined above would be sufficient. As you correctly guessed I was giving the "track value at new node" case as a hypothetical ;-) We could try to band-aid reinit()… but I really think for our users they REALLY want the input numbering to _not_ change for the initial mesh… no matter what (even when using Adaptivity). What do you think about my proposal? Derek ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
