[Libmesh-devel] Does renumber_nodes_and_elements always preserve node id order?

 [Libmesh-devel] Does renumber_nodes_and_elements always preserve node id order? From: John Peterson - 2007-09-19 22:09:31 ```Roy Stogner writes: > > It seems like in the special case where: > > Element A is refined, creating a new mid-side node N. > Neighbor B is refined which shares N. Didn't call renumber_nodes_and_elements() here? > Element A is coarsened. We may have assumed that A would either be refined OR coarsened (but not both) before an intervening call to renumber_nodes_and_elements(). -J ```

 [Libmesh-devel] Does renumber_nodes_and_elements always preserve node id order? From: Roy Stogner - 2007-09-19 22:01:51 ```It seems like in the special case where: Element A is refined, creating a new mid-side node N. Neighbor B is refined which shares N. Element A is coarsened. Then the algorithm in renumber_nodes_and_elements, which previously gave N an id as soon as it iterated over A's children, will now wait to give N an id until it iterates over B's children. If we're using an element whose basis orientations are dependent on node id ordering, that could be bad. On the other hand, if I'm just misunderstanding how renumber_ works, let me know; I'd hate to rewrite it unnecessarily. --- Roy ```
 [Libmesh-devel] Does renumber_nodes_and_elements always preserve node id order? From: John Peterson - 2007-09-19 22:09:31 ```Roy Stogner writes: > > It seems like in the special case where: > > Element A is refined, creating a new mid-side node N. > Neighbor B is refined which shares N. Didn't call renumber_nodes_and_elements() here? > Element A is coarsened. We may have assumed that A would either be refined OR coarsened (but not both) before an intervening call to renumber_nodes_and_elements(). -J ```
 Re: [Libmesh-devel] Does renumber_nodes_and_elements always preserve node id order? From: Roy Stogner - 2007-09-19 22:30:10 ```On Wed, 19 Sep 2007, John Peterson wrote: > Roy Stogner writes: > > > > It seems like in the special case where: > > > > Element A is refined, creating a new mid-side node N. > > Neighbor B is refined which shares N. > > Didn't call renumber_nodes_and_elements() here? It should have been called here, yes; in N would get an id based (roughly) on the element id of the first element to encounter it, which would be a child of A. > > Element A is coarsened. Then at this point, N would start getting an id based on one of the children of B, which (assuming there was enough other refinement going on at the same time) might have a much higher element id. I guess this all only really matters if the order of N's id compared to the id of one of its neighboring nodes changed, not if the order changes compared to some node halfway across the mesh. I may end up rewriting renumber_ anyway just so that I better understand how it will work with ParallelMesh. By the way, ParallelMesh::delete_nonlocal_elements now seems to work in those few special cases (i.e. ex13) where it's expected to, but it doesn't yet clear away null Elem* or Node*, and it's still pretty useless since there's as yet no way to restore the nonlocal elements before generating output. --- Roy ```