Re: [Libmesh-devel] Boundary element abusing parent notion

[Kirk, B. (JSC-EG) <Ben...@na...>]

>> However, for efficiency it would be nice for these 2d surface
>> elements to know the 3d element that created them.  To make that
>> happen, I have been considering abusing the notion of parent -
>> basically using the -parent pointer to store the (dim+1)-dimensional
>> parent, and then making the parent() member return NULL if (a) the
>> ptr is NULL as is done now, or (b) the parent and child are of
>> different dimensions.
>> 
>> All that is needed is some other method to get access to the
>> not-so-conventional parent. Elem::super_dimensional_parent()?
> 
> Elem::interior_parent()?
> 
> But I'm not sure this is the right design, for a few reasons:
> 
> Reusing the parent pointer scares me.
> 
> In the future we'll likely want to create meshes of the manifold
> between two subdomains, where each element will have two higher
> dimensional "parents"; reusing a single parent pointer doesn't work so
> well for that.

Not sure about that...  Since the orientation of the elements on the
manifold introduce the notion of 'inside' and 'outside' I think the notion
is still valid - the parent is the higher-dimensional element the surface
normal points away from.  If you need to get access to the element you are
pointing in to then you can query the parent's neighbor.

> Ideally a refined N-dimensional mesh should produce a similarly
> refined (N-1)-dimensional boundary mesh; the child cells of this mesh
> would then have both coarser (N-1)-dimensional parents as well as
> interior N-dimensional "parents", and we can't use the same pointer
> for both.

True, except for the level-0 (N-1)-dimensional elements.  I still think it
might be useful to have these know the level-0 N-dimensional element from
which it came.  If the refined (N-1)-d elements need to know the N-d element
they are adjacent to they can grab the family tree from the N-d level-0
element and at least have a small amount of elements to check.

> We already have a class that I think was designed to associate
> arbitrary user information with elements and/or nodes, MeshData.
> It's a real shame that this class isn't really supported by any of the
> active developers.  Perhaps this is the right opportunity to actually
> become familiar with how that class is supposed to work, get it
> working properly with newer libMesh features, and write some code that
> we can use for regression testing it.

Agreed.  Unfortunately, I think this is one area we cannot hide the user
from parallel communication.  I can imagine a user-defined class derived
from some abstract DofObjectAdditionalData base class or something, but the
user will have to provide pack/unpack functions for redistribution to work.

-Ben