[Dune] Kleine ?nderungen an der Schnittstelle

[Christian Engwer]

Hallo,

Es liegt mal wieder alles im AUge des Betrachters :-)

> ABER: Sofern ich nichts ?bersehen habe, ist es deutlich aufwendiger,
> Variante A nach B umzurechnen als umgekehrt.  Denn: angenommen
> man hat einen B-Index.  Dann kann man einen A-Index ausrechnen
> indem man ein gro?es Array anlegt, und dort die A-Indizes reinschreibt.
> Die Umrechnung erfolgt dann mit
>     A-Index = umrechnungsarray[B-index];

Dein Rechenaufwand ist O(1), aber Dein Speicheraufwand ist O(N) [wenn
N die Größe deines Gitters ist].

> Umgekehrt braucht man aber ein Array f?r jeden vorhandenen
> GeometryType.  Und bei jeder Umrechnung mu? man erst in einer
> map nachschauen, welches Array jetzt verwendet werden soll:
> 
>     std::map<GeometryType,std::vector<int> > umrechnungsmap;
>     const std::vector<int>& umrechnungsarray = 
>     umrechnungsmap.find(entity->type()).second;
>     B-Index = umrechnungsarray[A-Index];

Dein Rechenaufwand ist O(1) und Dein Speicheraufwand ist
O(1). Natürlich hast Du hier einen Zusatzaufwand, jedoch ist der
unabhängig von Deiner Gittergröße.
 
> Ich bef?rchte, da? man dadurch merkliche Geschwindigkeitseinbu?en
> bekommt, wenn man z.B. Elementdaten auf gemischten Gittern hat.

Man kann zusätzlich noch die Abfrage beschleunigen, indem man zwei
verschachtelte Vektoren verwendet:

   std::vector< std::vector<int> > codimGeomOffset;
   offset = codimGeomOffset[Entity::codim]
                           [static_cast<BasicGeometryType>(entity->type())];
   B-Index = A-Index + offset;

Man kommt also auch ohne Map aus. Das ganze geht natürlich nur mit
einem epsilon an internem Wissen (der BasicType), welches aber, wie
ich finde, an dieser Stelle zulässig ist, da es sich nicht um ein
Gitterdetail sondern um ein Schnittstellendetail handelt.

> Deshalb schlage ich vor, doch auf Variante B umzusteigen.  Der
> Implementierungsaufwand w?re recht gering, da ja bisher nur
> UGGrid ?berhaupt gemischte Gitter anbietet.

Ich bin dagegen hier komplett umzustellen, da der zusätzliche
Speicheraufwand nicht vernachlässigt werden sollte. Man könnte
natürlich diskutieren, ob man ein wieteres IndexSet einführen möchte,
welches dann den 'B-Index' liefert, aber derzeit würde ich solche
Diskussionen gerne aufschieben, bis wir 1.0 fertig haben.

Tschüß Christian