[Dune] basic concepts

[Peter Bastian]

Oliver Sander schrieb:
> Hallo!
> Ich finde die Idee gut, die Konzepte zu formalisieren.  Das kann man
> auch noch weitertreiben, z.B. bräuchte man ein Konzept 'Gitter'.
> 
Das "Konzept" unseres Gitters wird jetzt erst mal durch die
abstrakten Klassen aus dune/grid/common beschrieben. Ich bemühe mich die
Methoden so konkret wie möglich zu beschreiben, so dass man niemals in 
die konkrete Implementierung gucken muss (macht man ja bei einem 
std::vector<int>::iterator auch nicht). Ist natürlich nicht so einfach 
da die mathematisch vollständige Beschreibung eines Gitters nicht 
trivial ist (habe ich schon mal versucht, müsste aber noch mal 
überarbeitet werden).

> An der angehängten Liste stört mich nur, daß der EntityPointer
> jetzt doch nicht DefaultConstructible und Assignable ist.  
Ich vermute stark - wie Christian ja schon geschrieben hat - dass das
nicht trivial machbar ist und im Detail wieder größere Änderungen nach
sich ziehen wird. Prinzipiell bin ich da dafür, aber post 1.0.

> Und
> eigentlich könnte er auch einen kleiner_als-Operator haben, damit
> man ihn z.B. in std::map verwenden kann.  
Ja, aber bitte post 1.0

> Auf der anderen Seite
> frage ich mich, wofür man Gleichheit von Gittern wohl braucht.
> Was nicht heißen soll, daß ich dagegen bin, sowas zu haben.
> 
Nein, das war kein Vorschlag sowas einzuführen. Um Gottes Willen soll 
das jetzt NICHT rein.


> Da ja anscheinend die Idee im Raum steht, daß die Gitterschnittstelle
> nach 1.0 nicht mehr groß verändert werden kann, möchte ich hier
> mal darauf hinweisen, daß ich seit einer Weile schon noch einen
> größeren Änderungswunsch mit mir herumtrage.  Ich will das
> keinesfalls in 1.0 haben, aber mittelfristig fände ich es schon
> gut.  Es geht um folgendes:
> Im Moment haben Entities der Kodimension 0 ja mehr Methoden als
> die anderen.  Ich würde mir wünschen, daß die Entities aller
> Kodimensionen das gleiche Interface bieten.   Den Implementierungen
> sei freigestellt ob sie die zusätzlichen Methoden wirklich
> bieten.  Der Grund ist, daß Carsten und ich an einem SubGrid
> basteln.  Man nimmt ein beliebiges Gitter, markiert einen Teil
> von dessen Elementen, und bekommt diese Elemente dann als
> selbstständiges Gitter.  Soweit ist das okay, aber ich würde
> gerne auch Mengen von Entities mit Kodim>0 als SubGrid wählen
> können.  Damit könnte man z.B. Randflächen als separate Gitter
> sehen (spannend für mich selbst), oder man könnte z.B. auf
> Teilen des Kantensets rechnen (interessiert eine Gruppe aus
> dem ZIB).  Da das SubGrid die meisten Anfragen einfach weiter-
> leitet müssen sie im zugrundeliegenden Gitter auch angeboten
> werden (können).  Und das ist halt komplett unmöglich, solange
> sich die Schnittstellen für die Entitäten verschiedener
> Kodimensionen unterscheiden.  Tun sie das nicht, so muß man
> immer noch eine Implementierung finden, die auch alles anbietet,
> aber zumindest für UGGrid würde ich mich darum kümmern.
> 
Das finde ich gut, aber das ist wohl was für 2.0 (oder 3.0?).
Jetzt bitte erst mal 1.0 ...

Grüße

-- Peter
------------------------------------------------------------------
Peter Bastian, IWR,Uni Heidelberg, INF 348,R 020, 69120 Heidelberg
email: Peter.Bastian at iwr.uni-heidelberg.de   Tel: +49 6221 54 4984
WWW: http://www.iwr.uni-heidelberg.de/~Peter.Bastian Fax: ... 8860