[Dune] Grid refinement and persistent geometry objects

[Oliver Sander]

Hi Martin!
As far as coarsening is concerned, you're supposed to save information
from elements that will disappear _before_ the refinement.  This is
what the method Entity<0,...>::mightBeCoarsened() is good for.  It
tells you whether the entity you call it for may disappear in the
next call to adapt(), and you have to project any functions stored
on it to its father.

--
Oliver

************************************************************************
* Oliver Sander                ** email: sander at mi.fu-berlin.de        *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75217           *
* Institut für Mathematik II   ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 6                 ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************

On Mon, 16 Oct 2006, Martin Weiser wrote:

> Dear DUNE developers,
>
> I think that for prolongating FE functions during grid refinement,
> persistent geometry objects are needed. In the following, somewhat
> detailed and lengthy, elaborations I will describe how this requirement
> arises, and subsequently suggest a design that should solve the problem.
> Since this concerns the design of DUNE and in particular the
> implementation of grid interfaces, I'd appreciate any constructive
> comment.
>
> Assume I have FE functions defined in terms of Lagrangian shape functions
> associated to certain nodes in the codimension 0 elements (cells for
> short). Note that the nodes may be distributed in a fairly complex
> fashion, in particular, no one to one correspondence to grid subentities
> of certain codimension need exist.
> The preferred way to interpolate FE functions during refinement is to
> simply evaluate the function at the new nodes, giving the new
> coefficients. Since I use DUNE for good reason,
> (i) I don't know these new nodes before refinement, since I don't know
> wheter bisection or red/green refinement is used. In fact, even if I
> knew, it is a rather difficult and global computation to decide whether
> any cell is refined at all.
> (ii) I cannot access geometry objects for the pre-refinement leaf cells,
> since these cells need not exist after refinement (clear for coarsening,
> but also true for green closures removed before refinement). Remember
> that the Geometry class does not offer any guarantees or specific
> information about the mapping from reference to grid cell. Most often it
> will be affine, but that's in no way guaranteed.
>
> Now the problem is that in order to evaluate a pre-refinement FE function,
> I need the local coordinates of *new* nodes wrt the *old* cell in which
> the node happens to be. But the new node is known only after refinement,
> whereas the old cell geometry is known only before refinement. Am I
> missing somewhat?
>
> A solution to this dilemma may be structured as follows:
> Every Grid exports via its Codim<0> traits a class PersistentGeometry that
> can be constructed from a Codim<0>::Geometry object. This
> PersistentGeometry should be a model of Dune::Geometry<>.
> In that way, PersistentGeometry objects can be stored along with the
> (persistent) id of old leaf cells and be accessible *after* refinement.
> For affine mappings it is quite trivial to store the required information
> without any reference to the grid. In fact, a default implementation can
> be reused by any specific grid by just defining the
> Codim<0>::PersistentGeometry type.
> For, say, isoparametric mappings this is somewhat more involved, but not
> that hard.
>
> A second approach would be to require Geometry<> objects to be copy
> constructible and not be invalidated by grid refinement, but this might
> incur inefficiencies and require more massive code changes.
>
> Yours,
> Martin
>
>
> -- 
> Dr. Martin Weiser                  web:     www.zib.de/weiser
> Zuse Institute Berlin              mail:    weiser at zib.de
> Numerical Analysis and Modelling   pgp key: www.zib.de/weiser/weiser.asc
>
>
>