<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
I added a new page to our wiki - I think we decided, that that is a
good place for a discussion <br>
on the agenda for our meetings?<br>
<br>
I started by copying in Robert's suggestions...<br>
<br>
Best<br>
Andreas<br>
<br>
<br>
On 27/09/10 13:11, Robert Kloefkorn wrote:
<blockquote cite="mid:4CA089D6.9040802@mathematik.uni-freiburg.de"
type="cite">Dear Dune Developers,
<br>
<br>
the followings changes to the DUNE-Grid interface I do consider very
<br>
useful and I think these can be achieved during the next year:
<br>
<br>
=============================================
<br>
1) Performance issues of the Grid interface:
<br>
=============================================
<br>
<br>
i) Entity and EntityPointers:
<br>
Entity can be stored (although this might be memory consuming)
<br>
meaning one can write:
<br>
<br>
Entity entity = *it;
<br>
<br>
For efficiency reasons the Entity class can be implemented as a
<br>
reference counted pointer which would allow both, easy use and no
copying.
<br>
<br>
Code of the from
<br>
<br>
const Entity& entity = *it ;
<br>
<br>
will still be valid.
<br>
<br>
The best consequence of this is:
<br>
<br>
ii) removal of EntityPointer
<br>
<br>
The transition should be not to difficult since the typedef for
<br>
EntityPointer will point to Entity and on the Entity class we
introduce
<br>
the method
<br>
<br>
const Entity* operator -> () const { return this; }
<br>
<br>
After this the interface will be much better to understand
<br>
better to use.
<br>
<br>
In fact, all methods returning a reference to an object should be
revised.
<br>
<br>
iii) For "storage" of Entities in array-like structures we introduce
the
<br>
concept EntityKey (appropriate name to be found) which only
<br>
contains the minimal information needed to create the corresponding
<br>
Entity from this. An appropriate method will be available on the
Grid class.
<br>
This makes the implementation of Grids and the maintenance of
current
<br>
grids much easier since the we do not have to implement two
contrary
<br>
concepts in one class.
<br>
<br>
iv) the method jacobianInverseTransposed (and probably the method
<br>
jacobian) return not a FieldMatrix but an object specified by the
<br>
implementation (which can still be a FieldMatrix) which implements
all
<br>
mult methods and casts into a FieldMatrix. With this extension we
can
<br>
implement the jacobianInverseTransposed for Cartesian grids much
more
<br>
efficiently, not the full matvec is needed in this case.
<br>
<br>
v) not only the jacobianInverseTransposed but also the Geometry (on
Entity and
<br>
Intersection) should not be returned as a reference. This would
improve
<br>
the performance of meta grids which is currently not good,
<br>
i.e. about 25% are lost when wrapping a grid to provide
<br>
additional features, e.g. GeometryGrid, PrismGrid, ....
<br>
<br>
<br>
=============================================
<br>
2) Interface design issues:
<br>
=============================================
<br>
<br>
i) The boundarySegmentIndex is put into an index set (like any other
<br>
index) instead of implementing it on an class. This is a
contradiction
<br>
to the existing interface and also something one might only
generate
<br>
when needed.
<br>
<br>
<br>
ii) Boundary projections have to become "user data". The current
<br>
approach is a contradiction to separation of data and grid
structures.
<br>
<br>
<br>
iii) Persistent Index Container: Currently when a DoF mapping is built
<br>
that should be persistent also in an adaptive computation one would
<br>
have to use LocalIdSet in some sense which implies O(log(N)) index
<br>
access instead of O(1). Using AlbertaGrid or ALUGrid together with
<br>
DUNE-Fem there is a concept to overcome this shortcoming. This
should
<br>
also be introduced in the DUNE-Grid interface and replace the
LocalIdSet
<br>
(not the GlobalIdSet which is still needed as it is). We could
<br>
introduce a utility class that uses the current IdSet to
<br>
implement this feature (by default) and which can be specialized
<br>
for each grid if a better implementation is available.
<br>
<br>
<br>
=============================================
<br>
3) Interface extension for special purpose:
<br>
=============================================
<br>
<br>
i) Easier extension of the Grid interface to introduce new features
<br>
much more easily and, for example, to allow change of the interface
in a better way.
<br>
<br>
ii) The method getRealImp() should be replaced by impl() and should be
public which
<br>
would be a good step towards i). Together with this "capabilities"
in a namespace
<br>
Extensions are needed that tell whether special features are
available or not.
<br>
<br>
<br>
Best regards
<br>
<br>
Robert
<br>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Dune mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dune@dune-project.org">Dune@dune-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.dune-project.org/mailman/listinfo/dune">http://lists.dune-project.org/mailman/listinfo/dune</a>
</pre>
</blockquote>
<br>
</body>
</html>