>> 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 ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
