[Dune] meeting in berlin

[Andreas Dedner]

Hi,
here some results from the discussion in the Freiburg
group:
- Implementor grid how-to:
  it is very time consuming and confusing for 
  somebody to add a new implementation of the dune
  interface. The main reasons is that many classes have to 
  be written in one go without a clear
  guideline what the correct order is - this makes 
  debugging very difficult. Also the grid checks are not
  clearly constructed with an ascending order of
complexity.
  It would be nice to have a series of
  checks where the first one requires only a small part of
  the dune interface and then complexity increases in the
  following checks.
- Generic geometry implementations:
  This point was already mentioned in Christians mail and 
  I just want to repeat it here because it is closely
  related to the the previous issue. If an implementor does
  not have to implemented all geometries but can use 
  generic implementations than the complexity
  of a new grid implementation would be severely reduced.
  A second issue with generic geometry implementations is 
  that real subentities can also be implemented genericly -
  as long as ids are available for all subendities of the
  grid.
- subentities:
  the issue if subentities should be a required part of
  a dune grid should be discussed. The communication method
  (also on yasp) takes subentities which are not available
  in yasp.
- Generic reference elements:
  This is again closely connected to the generic geometries
  since generic geometries require reference elements.
  The existing ref. elements - especially in 3d - are not 
  defined in a very obvious and consistent way, e.g., the
  base cube of the pyramid does not correspond to the 2d 
  cube. This also makes the numbering of
  subenteties, e.g., vertices of edges difficult to figure 
  out. In higher space dimension no ref. elements exists
  (only cube). Simplex and prism grids are an interesting
  possibility also in 4d or higher.
  We have a concept with recursively constructed reference
  elements - using ref. elements of dimension d to
construct 
  ref. elements of dimension d+1 by either building a 
  ''pyramid'' or a ''prism''.
  This leads to a generic numbering of subentities and has
  been impl. using TMP. This approach also allows the impl.
  of generic lagrange finite-element base function.
  Of course we can not construct a generic heptagon in this
  manner...

- ''Twists'':
  we have not yet found a generic way for constructing 
  higher order (order>2) finite-element spaces using the 
  grid interface. One can use some
  index comparisons and some tricks to identify dofs on 
  subentities but for general reference elements we did not
  find this trivial - and we do not have a good solution
  yet...

- save/restore for grids:
  this already works for alu/alberta/yasp/sgrid and it 
  would be nice to have these methods in the interface even
  if not all grids can implement these methods
- Revisit of the GridPart interface.
- isConforming method on intersectionIterator for speedup.

see you in Berlin
Andreas