[Dune-devel] Validity of GridView after grid changes

Simon Praetorius simon.praetorius at tu-dresden.de
Fri Apr 11 13:59:36 CEST 2025


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



More information about the Dune-devel mailing list