[Dune] Dune Agenda 2011

[Martin Drohmann]

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