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

[Atgeirr Flø Rasmussen]

Hello Dune!

For some time, we (the simulation group at Sintef ICT in Oslo) have been 
writing code using the Dune interfaces. We are in general quite happy 
with this, and believe this is a good way to open our grids and solvers 
to a larger user base, while simultaneously gaining the ability to use 
other people's code for our purposes. Our code is structured as a dune 
module, called dune-cornerpoint, and is available (public svn). For 
information, see the module's wiki page:

https://public.ict.sintef.no/openrs/wiki/The_dune-cornerpoint_module_for_Dune

There are some limitations and restrictions in the Dune interface 
though, that we would like to address. We have a page on our wiki with 
change proposals:

https://public.ict.sintef.no/openrs/wiki/Dune_interface_change_proposal

I will here give a summary of the changes that are most important for us.

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.

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).

That's all for now! Any comments are welcome.

Atgeirr Flø Rasmussen and Bård Skaflestad

PS. We would appreciate to have any discussions on this on the list, as 
we do not have access to the private wiki.