On Thu, 17 May 2012, Derek Gaston wrote:
On May 16, 2012, at 4:15 PM, Roy Stogner wrote:
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.
No! This isn't what happens for SerialMesh! The problem we're
having is _with_ serial mesh. Go look at
renumber_nodes_and_elements() around line 405 in
unstructured_mesh.C… it very clearly renumbers _all_ nodes and
elements.
I'm just skimming code here, so if you're seeing different behavior
then I must be wrong, but:
SerialMesh::renumber_nodes_and_elements() "renumbers" all elements,
true, but as long as they start out in proper order
(_elements[i]->id() == i) they should stay the same up until the first
hole is reached, which shouldn't happen until after all the level 0
elements have been passed. Perhaps the trouble is that for file-based
numberings our MeshInput classes *aren't* starting us with
(_elements[i]->id() == i)?
---
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
