Ok - attached is a patch that fixes this... but it does have a drawback. We kicked around a lot of ideas on how to deal with this situation... but ultimately settled on a straightforward method that keeps track of nodes that are still connected to elements and then during the node renumbering we remove any orphaned nodes (nodes not in the set). This works beautifully... and preserves numbering as much as possible. HOWEVER: This is now a 2nLog(n) algorithm... where n is the number of nodes in your mesh. It will also take up a similar amount of memory to the _nodes vector itself (which is pretty small... it's storing pointers and it will only do so for a short amount of time during the renumbering process).
There were other ideas that were "better" than this in complexity / space... but had larger drawbacks. One of the better ones involves keeping track of "possibly_orphaned" nodes as you remove elements from the mesh... then remove them from being possibly orphaned as you loop over the elements and run into those nodes and then ultimately delete them if they really were orphaned during the node renumbering process. That had the very large drawback of making sure to add nodes to the possibly_orphaned set _everywhere_ we remove an element... which would allow for bugs to creep in. Also, this algorithm would still theoretically have 2nLog(n) complexity in time / space... but only in the case of uniform coarsening (which doesn't happen often). Yet another option was to do what I originally suggested... keeping track of the max node id of the mesh we read in (before any renumbering) and only renumbering above that. That has a problem with "arbitrary deletion" (where a user just deletes an element because they want to) though. To fix that you could use that plus the above algorithm by filling in possibly_orphaned _only_ for nodes below the max original node number... but that adds complexity and still has the same theoretical complexity (although you would only hit that limit in the case that a user deletes every element in the mesh!). At any rate... we settled on the attached patch. It fixes the problem for us... and I am happy with it. Let me know what you guys think. Derek On Thu, May 17, 2012 at 10:34 AM, Derek Gaston <fried...@gmail.com> wrote: > Yep - I think that would do it! > > Derek > > On May 17, 2012, at 9:28 AM, Roy Stogner wrote: > > > > > On Thu, 17 May 2012, Derek Gaston wrote: > > > >> You're right about Elements, Roy… I hadn't notice that. But for > >> nodes that's not the case (and that's where we're seeing problems). > >> > >> The issue happens when the node numbering for an element in a read > >> in mesh doesn't match the libMesh ordering for nodes on that > >> element. Look just below where it's setting the elem ids… > > > > Ha! I saw the behavior for elements and just assumed it would be > > using the same behavior for nodes. > > > > Would it fix things for you (at least as a first pass) if it *was* > > using the same behavior for nodes? Take the node renumbering out of > > the elements loop, add a nodes loop which does the same > > renumbering-without-reordering? > > --- > > Roy > >
0001-preserve-node-ordering-as-much-as-possible.patch
Description: Binary data
------------------------------------------------------------------------------ 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
