Right now BoundaryMesh is kind of a second-class citizen. BoundaryInfo::sync only copies over active elements, so the refinement tree is lost, and in the 3D->2D AMR case neighbor information ends up being incorrect. Sync then uses the parent pointers to associate each boundary Elem with its corresponding interior Elem, so any Elem:: functions which rely on parent() may give wrong results - the reason I started looking at this is that on a uniformly refined mesh, Elem::find_point_neighbors was somehow handing us HEX8 volume point neighbors for a QUAD4 surface element.
We're now using a workaround in our app code, but eventually I'd like to fix all that in the library. There's obviously no way to fix it without an API-breaking change (Elem::parent() can't return *both* the real parent element and the interior-"parent"), and I'm still trying to figure out how to make sure this isn't also a functionality-breaking change: where do we make the corresponding interior-"parent" Elem pointers available? Most easily, we could add a new _interior_parent field to Elem. We could get the same effect yet avoid wasting memory on non-boundary elements by making interior_parent() pull out _neighbors[n_neighbors()], and then just make sure that the _neighbors array gets sized a little bigger on boundary elements. We could build up an unordered_map (or equivalent) structure the way we do now with BoundaryInfo. Any thoughts/preferences? --- Roy ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
