[Dune] Dune Agenda 2011

Robert Kloefkorn robertk at mathematik.uni-freiburg.de
Mon Sep 27 14:11:02 CEST 2010


Dear Dune Developers,

the followings changes to the DUNE-Grid interface I do consider very
useful and I think these can be achieved during the next year:

=============================================
1) Performance issues of the Grid interface:
=============================================

  i) Entity and EntityPointers:
     Entity can be stored (although this might be memory consuming)
     meaning one can write:

       Entity entity = *it;

     For efficiency reasons the Entity class can be implemented as a
     reference counted pointer which would allow both, easy use and no 
copying.

     Code of the from

       const Entity& entity = *it ;

     will still be valid.

     The best consequence of this is:

  ii) removal of EntityPointer

     The transition should be not to difficult since the typedef for
     EntityPointer will point to Entity and on the Entity class we 
introduce
     the method

       const Entity* operator -> () const { return this; }

     After this the interface will be much better to understand
     better to use.

     In fact, all methods returning a reference to an object should be 
revised.

   iii) For "storage" of Entities in array-like structures we introduce the
     concept EntityKey (appropriate name to be found) which only
     contains the minimal information needed to create the corresponding
     Entity from this. An appropriate method will be available on the 
Grid class.
     This makes the implementation of Grids and the maintenance of current
     grids much easier since the we do not have to implement two contrary
     concepts in one class.

   iv) the method jacobianInverseTransposed (and probably the method
     jacobian) return not a FieldMatrix but an object specified by the
     implementation (which can still be a FieldMatrix) which implements all
     mult methods and casts into a FieldMatrix. With this extension we can
     implement the jacobianInverseTransposed for Cartesian grids much more
     efficiently, not the full matvec is needed in this case.

   v) not only the jacobianInverseTransposed but also the Geometry (on 
Entity and
     Intersection) should not be returned as a reference. This would 
improve
     the performance of meta grids which is currently not good,
     i.e. about 25% are lost when wrapping a grid to provide
     additional features, e.g. GeometryGrid, PrismGrid, ....


=============================================
2) Interface design issues:
=============================================

   i) The boundarySegmentIndex is put into an index set (like any other
     index) instead of implementing it on an class. This is a contradiction
     to the existing interface and also something one might only generate
     when needed.


  ii) Boundary projections have to become "user data". The current
     approach is a contradiction to separation of data and grid structures.


  iii) Persistent Index Container: Currently when a DoF mapping is built
     that should be persistent also in an adaptive computation one would
     have to use LocalIdSet in some sense which implies O(log(N)) index
     access instead of O(1). Using AlbertaGrid or ALUGrid together with
     DUNE-Fem there is a concept to overcome this shortcoming. This should
     also be introduced in the DUNE-Grid interface and replace the 
LocalIdSet
     (not the GlobalIdSet which is still needed as it is). We could
     introduce a utility class that uses the current IdSet to
     implement this feature (by default) and which can be specialized
     for each grid if a better implementation is available.


=============================================
3) Interface extension for special purpose:
=============================================

   i) Easier extension of the Grid interface to introduce new features
     much more easily and, for example, to allow change of the interface 
in a better way.

  ii) The method getRealImp() should be replaced by impl() and should be 
public which
    would be a good step towards i). Together with this "capabilities" 
in a namespace
    Extensions are needed that tell whether special features are 
available or not.


Best regards

Robert

-- 

   Dr. Robert Klöfkorn         <robertk at mathematik.uni-freiburg.de>

   Mathematisches Institut              Tel: +49 (0) 761 203 5631
   Abt. für Angewandte Mathematik       Fax: +49 (0) 761 203 5632
   Universität Freiburg
   Hermann-Herder-Str. 10
   79104 Freiburg

   http://www.mathematik.uni-freiburg.de/IAM/homepages/robertk
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: agenda_2011.txt
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20100927/50225555/attachment.txt>


More information about the Dune mailing list