On Nov 6, 2013, at 9:26 PM, "Derek Gaston" <fried...@gmail.com> wrote:
> fix_broken_node_and_element_numbering() will destroy any non-contiguous, > non-zero starting numbering - or any numbering where the numbering of nodes > doesn't match the order they are added to the mesh. Note that last one: that > is a serious one as we're getting ready to start using the node and element > "maps" in Exodus that will effectively renumber nodes and elements after they > are added to the mesh. So just writing out an EquationsSystem will destroy > our numbering... Indeed - that method assumes the contiguous and changeable order that's been in the library for a long time. But it doesn't have to - right now it looks through objects and infers their Ids by position, which will indeed break when you make the aforementioned change. That's easy to work around though - the globally_renumber_... can simply save the original ordering and then it can be restored exactly by providing that to fix_broken_... We've not historically treated object ids as sacred, but preserving them when important should not be too difficult. -Ben ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
