[Dune] Suggested changes/additions to the Dune grid interface

[Atgeirr Flø Rasmussen]

Dear Dune,

I accidentally posted my reply to Andreas just to him and not to the list, here it is (a little delayed). [Andreas, you have already got this...]

Andreas Dedner skreiv:

> > Hi,
>   
>> >> First priority, item 1 on the wiki: a reduced geometry interface.
>> >> Not all useful grids have cells and/or intersections that may be mapped 
>> >> to a finite set of reference elements. Examples include voronoi grids 
>> >> (the dual of a Delaunay simplex grid), the corner-point grids used in 
>> >> reservoir simulation or general polyhedral grids. These kinds of grids 
>> >> are hard to implement in Dune, since the Dune interface requires that 
>> >> every entity and intersection has a type().
>> >> We propose to allow geometries without reference elements, that is, that 
>> >> they only implement corners(), corner(), volume() and position()[new 
>> >> method].
>> >> Our proposal is similar to the NONE reference element type and BasicType 
>> >> geometry of "FS#449 - arbitrary reference elements", but with some 
>> >> differences. With the NONE reference element type, grids must still 
>> >> provide a (dummy) implementation for methods that are not used (such as 
>> >> local() and global()), whereas we propose using a Capability for this in 
>> >> order to support compile-time branching.
>> >> The only new method we suggest, is a method called position() or 
>> >> centroid() for the geometries, which should be easy to implement for 
>> >> existing grids.
>>     
> > Just for my better understanding:
> > If you look at the first comment in FS#449 where I suggested a
> > modification of the original idea: an entity with NONE/SUBDIVIDED
> > as type return a BasicGeometry instead of a Geometry, i.e., a reduced
> > interface. Is this - together with a Capability that no entity has a
> > reference element - something that would work for you?
> >
>   
I think this would work for us, but I am not quite sure if I understand 
how your suggestion would work. First of all, the return type of 
geometry() must of course be the same for all 0-entities. It is not 
possible to return a basic geometry class for some and a full geometry 
class for others. Therefore, returning a basic geometry (or not) is 
something that applies to the grid as a whole, and must be decided at 
compile time. This is why we suggest using Capabilities for this. But 
then there is no need to return a NONE type at all. The NONE type will 
not enable you to write code like this:

if (geom.type().isNone()) {
    // use geom.position(), geom.volume() etc.
} else {
    // also use geom.global(), geom.jacobianTransposed() etc.
}

Since this requires the presence of the global() etc. methods to 
compile, it will only work for grids will full geometries. [Actually, 
the above could be made to work by moving the contents of the braces to 
separate template functions, but I do not think that changes my main 
point, that we cannot really do run-time branching on the NONE type.]

>> >> Second priority, item 6 on the wiki: random access to entities.
>> >> For some grids, this may not be possible, but for others it is quite 
>> >> doable. We propose to add a new interface to the mapper classes (or to a 
>> >> new mapper class), a method entity() that maps indices (or ids) to 
>> >> entities. This would build on such a method being available from the 
>> >> grid's index/id sets. The presence of this method can again be indicated 
>> >> by the use of capabilities, and it would not require changing any 
>> >> existing grids (unless they want to support this feature).
>> >>
>>     
> > I am not very happy with this idea. Having more and more Capabilities
> > and methods in the interface which are only meaningful if some
> > capability is set makes it difficult to write generic code and difficult
> > to maintain dune. Could you give me an example of an application?
>   
I can see that. I think Capabilities are appropriate if they expand the 
scope of Dune, that is, they enable code to be written with Dune that 
otherwise could not be (or at least not easily). Our example is a 
so-called "multiscale pressure solver", which basically needs to deal 
with a partitioning of the grid into coarse blocks. One can view this as 
a coarse grid, in which each coarse block is a 0-entity consisting of a 
connected set of 0-entities (cells) from the underlying grid. We need to 
iterate over all cells in various pairs of coarse blocks, without having 
to iterate over all cells in the entire grid. Currently, this requires 
creating and storing a mapping of index-to-entity (as EntityPointers in 
a vector for example) ourselves.

Atgeirr and Bård