[Dune] meeting in berlin

[Oliver Sander]

Your proposals are now on the web page.

--
Oliver

Andreas Dedner schrieb:
> 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
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>   


-- 
************************************************************************
* Oliver Sander                ** email: sander at mi.fu-berlin.de        *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75217           *
* Institut für Mathematik II   ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 6                 ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************