[Dune] Re: Frage Grid Interface.

[Robert Kloefkorn]

Peter Bastian wrote:
> Hallo Robert,
> 
> Du hast vollkommen Recht. Genau dieses ist mir beim implementieren von
> sgrid auch klar geworden. Man kann die Schnittstelle nicht
> anhand einer Pilotimplementierung dokumentieren, da dort
> Schnittstelle (was ist ein Grid) und Implementierung (spezielle
> Methoden und Klassen, die ich für SGrid brauche) miteineander
> verwoben sind. 
> 
> Es muss doch etwas wie eine Basisklasse im Barton Nackman geben.
> Man wird diese zwar nicht in den generischen Algorithmen verwenden,
> aber um sicherzustellen, dass alle Methoden im mit den richtigen
> Typen implementiert sind ist das praktisch.
> 
> Ich habe auch schon eine Idee wie das implementiert werden kann.
> Ich habe nämlich gefunden, dass man templates als template-Parameter
> übergeben kann (stroustrup C.13.3). Hier ein Beispiel wie Grid aussehen
> könnte:
> 
> template<int dim, int dimworld, template<int,int> class GridEngine>
> class Grid {
> public:
> 	int maxlevel() { return gref.maxlevel; }
> 	... hier würde man alle Methoden von Grid aufführen ...
> 	GridIF (GridEngine<dim,dimworld>& g) : gref(g) {}
> private:
> 	GridEngine<dim,dimworld>& gref;
> };
> 
> Der dritte Parameter von Grid ist ein Klassentemplate mit
> zwei int Parametern (das wäre zB SGrid). Die Methoden von
> Grid sind nun mittels member function forwarding auf
> die Engine implementiert.
> 
> verwenden würde man das dann so:
> 
> template<class T>
> void test (T& t)
> {
> 	cout << t.maxlevel(); << endl;
> }
> 
> SGrid<2,2> sgrid( Tupel<int,2>(1,1) , Tupel<double,2>(1.0,1.0) , 2 );
> Grid<2,2,SGrid> grid = sgrid;
> test(grid);
> 
> Man kann natürlich Grid als Basisklasse für SGrid verwenden und
> dann wie im Barton-Nackman verfahren.
> 
> Mein nächstes Ziel wäre nun ein grid.hh, das genau die Schnittstelle
> auf diese Weise beschreibt und dokumentiert. in dune/grid/common
> könnte man dann noch Testfunktionen unterbriengen. Denn es muss
> jede Methode einer Template-Klasse auch einmal aufgerufen werden damit
> auch der Code wirklich übersetzt wird.
> 
> Wie findest Du das?

Hört sich super an. Ich denke mit dieser Methode fahren wir am besten.
Einerseits stellen wir Konsistenz sicher, müssen uns aber beim 
Implementieren nicht total einen abbrechen, sonderen verwenden gleich 
die konkreten Implementierungen und haben damit auch keinen unnötigen 
overhead.

Eine andere Sache ist noch folgende:

Einige Sachen der Schnittstelle sind mit dem Albertgitter nur limitiert 
umsetzbar, z.B.

- Nachbarschaftselemente sind nur auf dem tiefsten Level der Hierarchie 
zu erreichen

- über Kanten/Flächen kann nur auf dem tiefsten Level iteriert werden, 
im Moment

- Elementnummerierung bei Kanten, Flächen ist nicht so ganz einfach, 
muss mir hier noch was überlegen.

Desweiteren habe ich soweit die Funktionalität implementiert, auch wenn 
ich im Moment noch keine Performance Analyse gemacht habe, was ich noch 
tun werde, um die Sache so verlustfrei wie möglich bereitzustellen.

Ein anderer Punkt, der mir noch aufgefallen ist, ist der folgende:

Sollte es bei einem Gitterelement auch möglich sein zu den Element der 
höheren Codimension zu gelangen, also von einem Element (Dreieck) zu 
seinen Kanten und von dort zu den Knoten, oder soll diese Funktionalität 
anders bereitgestellt werden. Ich denke, dass dies irgendwie vorhanden 
sein sollte, auch wenn das nicht die schnellst Art ist, um z.B. an die 
Knoten eines Elements heranzukommen.


Als letztes wollte ich noch fragen, ob ihr schon eine Albert lib 
besitzt, oder ob ich mal eine für euch organisieren soll, damit ihr das 
Ganze dann auch verwenden könnt.

Ansonsten ist übrigens Mario nächste Woch mal wieder in Freiburg, dann 
werde ich ihm die ganze Sache mal vorstellen. Hat sich ja doch ganz 
schön viel getan in den letzten zwei Wochen.

Tschö

Robert


-- 

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

   Mathematisches Institut              Tel: +49 (0) 761 203 5642
   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