[Dune] Dune Agenda 2011

Martin Drohmann mdrohmann at googlemail.com
Wed Sep 29 13:14:57 CEST 2010


In our workgroup, some people criticized the practice to protect the
wiki access by passwords for people with write access to the core
modules only. Isn't it possible to use a global password for the wiki,
that can be published on the mailing list? Because that would probably
protect the wiki from being spammed by a bot, but still allows people
who are interested in the future of Dune to better understand what is
going on.

Best,
Martin D.

On 28 September 2010 16:45, Andreas Dedner
<dedner at mathematik.uni-freiburg.de> wrote:
> Hi,
>
> I added a new page to our wiki - I think we decided, that that is a good
> place for a discussion
> on the agenda for our meetings?
>
> I started by copying in Robert's suggestions...
>
> Best
> Andreas
>
>
> On 27/09/10 13:11, Robert Kloefkorn wrote:
>
> 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
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>
>



-- 
Martin Drohmann
Institut für Numerische und Angewandte Mathematik
Westfälische Wilhelms-Universität Münster
Einsteinstr. 62, D-48149 Münster
Tel. +49 (0) 251 83-35051
Fax. +49 (0) 251 83-32729



More information about the Dune mailing list