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

[Andreas Dedner]

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?

> 
> 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?

Best
Andreas