On Wed, 16 May 2012, Derek Gaston wrote:
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)
Hmm... this is what already happens for SerialMesh, isn't it? It
ought to be doable for ParallelMesh too.
My first concern there is what happens when we're doing mesh
generation rather than reading a pre-numbered mesh from file. For
ParallelMesh creation of new nodes we start with them being as
*interleaved* as possible, with each processor p responsible for
handling the set ids which (mod n_procs+1) == p (with the n_procs+1
case reserved for unpartitioned nodes and elements). I'd hate to
leave a mesh stuck with an initial numbering that was grossly
interleaved and sparse.
Maybe leave the existing renumbering routine in there, to be called
for those cases, but add a new routine in that doesn't touch the first
Ne0,Nn0 nodes and elements?
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….
But then my second concern: we're capable of deleting (and ought to be
capable of adding) level 0 elements on the fly, it's just that the
library code never does so; it's the sort of thing that a user in a
variable domain problem would do by hand - picture an ablation problem
which combines mesh movement in the outermost cell layer with cell
deletion as the boundary passes that layer. I'd hate to offer a
"guarantee" that some numbers would go unchanged only to have to give
a few pages of fine print explaining under what conditions they'd
change.
I suppose it wouldn't be the first situation requiring care by libMesh
users, though. Add "topologically unchanging initial meshes" to
"Lagrange elements", "unrefined meshes", "non-adaptively-refined
meshes", "serialized meshes", etc. on the list of "stuff that makes it
too easy to write code that will break when your discretization
requirements get more interesting.
and in some cases it makes sense. For instance, how do you track by
x,y,z position when you have a MOVING mesh?
Reference configuration position. But yeah, I can see how that could
be a pain in the neck - throw in mesh tearing and I'd even want an
(fixed-element-id, point-in-master-element-space) identifier pair
myself.
What do you think about my proposal?
I don't have time to implement it myself, but as long as we still end
up doing initial renumbering on meshes which don't get their numbering
from a file, I do like the idea.
---
Roy
------------------------------------------------------------------------------
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
