[Dune] Referenztopologien

[Robert Kloefkorn]

Oliver Sander wrote:
> Hallo Leute!
> Ich habe mal ein bischen über die Implementierung der Referenz-
> topologien nachgedacht.  Dabei ist mir erstmal aufgefallen, daß
> es eine Klasse ReferenceTopology schon gibt.  (in grid.hh)
> Diese Klasse wirkt etwas unfertig, und gibt auch nur geometrische
> Informationen -- wie etwa den Elementmittelpunkt -- zurück.
> Darum schlage ich vor, daß wir entweder die Klasse in
> ReferenceGeometry umbenennen, oder sie mit meiner neuen 'richtigen'
> Topologieimplementierung verschmelzen.
> 
> Für diese Implementierungen sind mir spontan drei unterschiedliche
> Ansätze eingefallen, die alle ihre Vor- und Nachteile haben.
> 
> - Die schönste Variante wäre es, wenn es für jeden Elementtyp eine
> Singletonklasse gäbe.  Unter Angabe des Elementtyps bekäme man
> die Klasse und diese hätte dann die Topologie als statische
> Tabellen gespeichert.  Nachteil:  man braucht virtuelle Funktionen.
> 
> - Oder man nimmt eine einzige statische Methode, die den Elementtyp
> als Parameter bekommt.  Intern würde man eine switch auf den Typ
> machen, um die korrekten Werte zurückzugeben.  Das ist nicht so
> hübsch, und statt der virtuellen Funktion hat man jetzt den switch,
> aber man kann den Aufruf inlinen.
> 
> - Oder man führt zwischen den einzelnen Tabellen in der Klasse
> soviel Padding ein, daß die Topologie für jedes Element gleich groß
> wird.  Dann kann man auf den switch verzichten und mit
> (int)ElementType * Tabellengröße zu den richtigen Daten kommen.
> Das ist nicht schön, und schlecht zu warten, aber es ist die
> schnellste Variante und verschwindet hinter der Schnittstelle.

:)

Oder wir machen es wie bisher. Man kann die ReferenceGeometry genau wie 
bisher das ReferenceElement auf der entsprechenden ElementKlasse 
abfragen. Dafür muss eine Schnittstelle festgelegt sein, die ähnlich wie 
beim coount und entity der Entityklasse immer Zugriff und maximale 
Zugriffsadresse angibt oder man könnte dies auch über Iteratoren 
realisieren.
Für Gitter mit unterschiedlichen Element Typen in eimem Gitter müsste 
man natürlich immer noch ein switch-case machen, bei Gittern mit nur 
einem Element Typ jedoch nicht.
Virtuelle Methode wären hier nicht notwendig. Die bedeutet, das jedes 
Gitter eine Implementierung der Referencetopologie zur Verfügung stellt, 
die aber als typedef die Standard Dune Implementierung sein kann.
Der Vorteil wäre bei diesem Vorschlag, dass man sowohl Schnittstelle als 
auch Effizienz vereinen kann und die nötige Allgemeinheit behält.

Ich hoffe mal es ist ungefähr klar geworden was ich meine.

Grüssle

R

-- 

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

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