[Dune-devel] Validity of GridView after grid changes

[Christian Engwer]

Dear Simon,

I'd interpret @carstens remark as

 ... there are no guarantees *right now*...

and this is totally true. Still, as the codes are relatively "robust"
in this respect, we could take the freedom to give/require stronger
guarantees in the future.

Ciao Christian

Am Fri, Apr 11, 2025 at 01:59:36PM +0200 schrieb Simon Praetorius:
> Hi,
> 
> yes, probably one can construct a gridview that is invalidated once the grid
> changes.
> 
> But I have not yet found one. Gridviews that stay valid:
> 
> - dune-curvedgrid
> - dune-periodic (flat-periodic)
> - dune-mmesh
> - dune-multidomaingrid
> - dune-subgrid
> - geometrygrid
> - all metagrids from dune-metagrid
> - dune-gridglue
> 
> OK, the first one I have found is dune-spgrid where I think, the gridview is
> invalid after grid change. But this grid has already an update method that
> makes it valid again. And there the indexset is stored in the gridview what
> is not really necessary and could maybe even be changed in the
> implementation.
> 
> Almost all gridview implementations are also (essentially) identical. There
> could even be a common pattern such that there would not be a need to
> implement a new gridview for all grid implementations.
> 
> I am just saying, this invalidity makes a lot of things extra complicated.
> There is also a gap in the grid interface that allows to update the
> gridview. Eliminating the need for such an update would already solve some
> problems.
> 
> Also, we cannot easily test our current implementation (that gridviews are
> correctly reconstructed instead of just left untouched) since we have
> nothing that would fail.
> 
> Best,
> Simon
> 
> Am 11.04.25 um 11:41 schrieb Carsten Gräser:
> > Hi Simon,
> > to me this is simple: The gridview is no longer valid once the grid
> > has been modified. For the standard gridviews it may work, but this
> > is a lucky coincidence. Even if the gridview only stores pointers
> > to the grid's index sets, they may change after grid modification.
> > 
> > For meta grids and custom grid views you're right that they should
> > be light weight and copyable and thus only store pointers to heavy
> > date. However, there's no guarantee that these pointers remain valid
> > once the grid has been modified.
> > 
> > In your downstream class you need to react to a grid change anyway,
> > because you will often have some grid-dependent data. E.g. a mapper
> > needs to recompute its size and offsets. When initiating this update
> > you simply have to pass a fresh grid view.
> > 
> > I agree that this is sometimes inconvenient, but then it's a gap in the
> > interface. It seems that there are two things missing to achieve what
> > you intend to do:
> > 
> > a)A mechanism to register callback that allow to react on grid
> > modification.
> > b)An interface that allows to update a gridview, e.g. an update() method
> >   which does not take an argument. In simple cases this could be empty,
> >   in general it could e.g. update the index sets from the grid. But this
> >   method would have to be optional, since there's no generic update
> >   to custom grid view.
> > 
> > Best
> > Carsten
> > 
> > Am 11.04.25 um 10:13 schrieb Christian Engwer:
> > > Hi Simon,
> > > 
> > > > - If we would assume that the gridviews of the standard grid
> > > > managers are
> > > > safe, and a meta-grid wraps such gridviews and does not manage
> > > > any extra
> > > > data, then also meta-grids could be implemented in a safe way.
> > > 
> > > But this light weight might be that you just store the expensive data
> > > outside the gridview, still it must be ensured somehow that the
> > > hostgridview and the extra data are in sync. Otherwise you could still
> > > work with the gridview, but it would produce oscure results.
> > 
> > _______________________________________________
> > Dune-devel mailing list
> > Dune-devel at lists.dune-project.org
> > https://lists.dune-project.org/mailman/listinfo/dune-devel
> 
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at lists.dune-project.org
> https://lists.dune-project.org/mailman/listinfo/dune-devel

-- 
Prof. Dr. Christian Engwer 
Institut für Numerische und Angewandte Mathematik
Fachbereich Mathematik und Informatik der Universität Münster
Einsteinstrasse 62
48149 Münster

E-Mail  christian.engwer at uni-muenster.de
Telefon +49 251 83-35067
FAX     +49 251 83-32729