On Mon, May 2, 2011 at 1:24 PM, Roy Stogner <[email protected]> wrote:
>
> 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.
Hmm... not crazy about either option really.
Of the two, sticking it on the end of _neighbors seems to be the
worse/more hackish, since the interior parent isn't really a neighbor
in the normal sense.
I also see it leading to some tricky bounds checking code and possible
segfaults, especially since _neighbors is just a bare Elem**.
> We could build up an unordered_map (or equivalent) structure the way
> we do now with BoundaryInfo.
>
> Any thoughts/preferences?
Off the top of my head, what if all elements added to a BoundaryMesh
were BoundaryElem's, where
class BoundaryElem : public Elem
{
Elem* _interior_parent;
Elem* self;
}
All the Elem functionality could be implemented by forwarding to the
underlying "self" pointer, which represents some actual element.
But... that might be way too much work for something that could be
fixed with either of your suggestions above!
--
John
------------------------------------------------------------------------------
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
