[Dune] Dune Agenda 2011

[Andreas Dedner]

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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20100928/ea190dad/attachment.htm>