Re: [Libmesh-devel] Element neighbors and element deletion

[John P. <pet...@cf...>]

Roy Stogner writes:
 > On Fri, 2 Nov 2007, Benjamin Kirk wrote:
 > 
 > > The Elem::nullify_neighbors() method is used to remove an element from its
 > > neighbor's list of neighbors.  Currently, this method is protected and is
 > > called only from MeshRefinement when deleting an element.
 > >
 > > I think it needs to be called *at least* from
 > > ParallelMesh::delete_nonlocal_elements(), and probably any time an element
 > > gets deleted.  Currently, the elements left behind after calling
 > > delete_nonlocal_elements() may contain pointers to invalid elements, which
 > > seems like a segfault waiting to happen.
 > 
 > True... but honestly, I'd rather have a segfault than an incorrect
 > result, and it seems to me that having non-boundary elements with NULL
 > neighbor pointers (which we use to signify a boundary) would be
 > inviting the latter sort of failure.  On the other hand, in general
 > user code should only be iterating over local elements, which will
 > never have non-semilocal neighbors.
 > 
 > > So I am thinking this should go into the Elem destructor.  Is there any
 > > subactive element weirdness I should be aware of here?
 > 
 > No subactive-specific weirdness, I don't think.  Really, the greatest
 > common thread is that both "subactive" and "non-semilocal" demonstrate
 > my ineptitude at inventing new technical vocabulary terms.
 > 
 > There is element-hierarchy weirdness, though.  It looks like
 > nullify_neighbors() only NULLs out the deletee's neighbor's pointer,
 > but if our goal is to get rid of invalid pointers then that neighbor
 > may have any number of descendants whose pointers also ought to be
 > NULLed.
 > 
 > > Note that in the ParallelMesh this will change the semantics of what
 > > elem->neighbor(s) == NULL means.  It will only indicate that the element is
 > > on a physical boundary for *local* elements.
 > 
 > I've actually thought that we need to be able to separate the two
 > concepts: instead of using pointer-to-NULL for both, we'd use a
 > pointer-to-static-const-Elem for one.  Presumably we'd use it for the
 > "has a non-semilocal neighbor" case, since application code already
 > has the "NULL means boundary" assumption hard-coded into it.
 > 
 > We could make a new subclass of Elem for this, which gives an error()
 > for all of its methods - that way we'd actually detect attempts to use
 > non-semilocal elements rather than playing Russian Roulette between
 > segfaults and invalid data use.  What do you think?

I like it.  Also I like the fact that we can derive additional "ErrorElem" types
for future "NULL-but-not-really" classes of Elems which arise, each of which could
implement its own special error message when you try to access it.

-J