[Dune] Even more proposals for changes to DUNE

[Christian Engwer]

Hi,

I composed a list of issues in the current interface, we should
discuss in the near future. Not all points need to be discussed in
Berlin, since the time is limited, but still some of the are rather
important.

I already discussed these points with my colleagues in Stuttgart and
with Bernd Flemisch.

The first part of the list are actuall proposals for changes in the
interface (mainly cleanups). The second part are problems where we
don't have a proposed solution yet.

Furthermore I can forward a suggestion/wish of Bernd Flemisch:

  The DGF interface allows to specify boundaryIds for unstructured
  grids. Bernd asked for boundaryId support in the UGGrid
  implementation. It is clear that the boundaryId is not sufficient,
  but up till now it is moreless the only way to get boundary
  information from the mesh generator to the discretization.

  Bernd also asked about the possibilities to specify internal
  boundaries. Te underlying ug supports this, but it seems, that it is
  not supported in the DUNE interface. Can the DGF parser handle
  these?

Find the list of my own questions attached.

Cheers Christian
-------------- next part --------------
=== proposed changes after dune 1.0 ===

1) New Capabilities

"IsCartesian"
   => geometries are not affine; they are given by as
      $T \circ S$
	  where T is a translation and S a scaling operator
   => the axis of a normal vector is given as
      ItersectionIterator it;
      ...
      int axis = it.numberInSelf()/2;

2) Proper Definition of "IsUnstructured"

It is not clear, what the implication of the Capability
"IsUnstructured" are. Especially it is not clear, what we get if
"IsUnstructured" is false.

3) Entity vs. EntityPointer

Some interfaces in Dune require an Entity instead of an
EntityPointer. This limits the flexibility of the underlying
implementation, as an entity can neither be copied nor stored. I
suggest to changes these interfaces and mark the old methods
deprecated.

affected classes:
* Mapper
* IndexSet
* IdSet
* several ones in dune-disc

4) Proper View concept for the grids

The grid follows a view concept. We should emphasize this in the
interfaces. The different size/begin/end/intersection/indexset methods
should be moved to the appropriate view (which corresponds to what are
GridParts right now) and should be removed/deprecated in Grid and in
IndexSet. We should add methods and typedefs to Grid to access these
views.

Suggestions are:
* Grid::Partition<>::LeafView/LevelView
* grid.leafview<cd,ptype>() / grid.levelview<cd,ptype>(level)

5) HierarchicIndexSet / HierarchicGridPart

What are their use? The documentation does not shed any light on this
question. I think that the hierarchic iterator is something completely
different from level and leaf. I suggest to remove these "hierarchic
views".

I think the hierarchic iterator is something similar to the
intersection iterator and not to leaf/leveliterator. Leaf- and
leveliterator iterator over something which is still a
grid. Intersection- and hierarchiciterator are defined by a certain
relation of an element. The intersectioniterator by the intersection
relation, the hierarchiciterator by the father-son relation.

6) Access to reference elements

It would be very convenient if the reference element could be obtained
from the geometry.

7) Generic Geometry classes

The geometry class itself is more or less independent from the grid
implementation. We should offer generic geometry implementations which
can be used be the grid implementations. For certain grids it can
still be desired to write it's own implementation.

8) XxxDefault classes

The benefit of the XxxDefault classes is close to zero, most of them
are empty. I suggest remove these XxxDefault classes. The default
implementations can be moved to different classes and the implementer
of a grid can choose from which implementation to import a certain
feature. This will also allow to offer different default
implementation for the same feature for different grid concepts
(e.g. hierarchic vs. level oriented structures).

9) Make IntersectionIterator a real iterator

Intersections are too slow. We should make the IntersectionIterator a
real iterator, this would also allow some efficiency tweaks, as we
don't have to create the whole intersection, when only
iterating. Making the intersectioniterator a real iterator (with
dereference etc.) would also enhance the readability of the interface.

=== Things to discuss, but not a real proposal yet ===

1) Access to further relations on the grid

There are only very few relations of the grid available via the
interface. It would be desirable to have way to generate other
relations.

2) Only one intersection per neighbor

For certain discretization schemes it is necessary to get information
about the complete intersection with the neighboring element.

In the Dune interface it is said that one can not always describe an
intersection by just one geometry. You might have several geometries
for single intersection. Right now one would get several
intersections.

It would be nice to have only one intersection and then operate on
this one intersection. The problems that arise here is that you can't
describe it any longer using a reference element and a mapping. One
would have define more or less arbitrary reference elements and
mappings which are defined piecewise.

3) Entity->type()

Entity->type() isn't strictly related to a reference element. For some
elements, e.g. a heptagon, you will have problems defining the element
by a reference element and a mapping, but still it would be nice to
allow these kind of elements in the grid interface.

The problems arising here are similar to those of the intersection.

Oh! And before people ask... yes there are applications for the last
two suggestions.