[Dune] Roadmap...

[Oliver Sander]

Ich gestehe sofort zu, daß die Variante, jedem Gitter eine Erzeugungs-
schnittstelle aufzuzwingen, auch keine Lösung ist.  Aber:

Erstens mal sehe ich die Notwendigkeit nicht, daß jedes Gitter exakt
gleich erzeugt werden können muß.  Wo genau braucht man das denn?
Wenn jemand eine Applikation gebaut hat, und sie immer mit Gitter A
betrieben hat, dann kann er doch auch die drei Zeilen Gittererzeugung
ändern, wenn er jetzt auf einmal Gitter B haben will.  Obendrein
wird es wahrscheinlich einen Grund haben, warum er auf einmal
Gitter B will.  Z.B. einen Elementtypen, den nur B hat.  Dann ist er
mit der uniformen Gittereinlesemethode auch verloren.
Daß AmiraMesh nie öffentlich gemacht wurde ist wirklich schlecht.
Aber das ist ein anderes Problem.  Ich schreibe sofort noch weitere
Lesemethoden für UGGrid, wenn das gewünscht wird.

Zweitens finde ich die Aussage, Euer Datenformat wäre einfach und
allgemein ziemlich zweifelhaft.  Seid mir bitte nicht böse.  Aber
ich glaube nicht, daß ein einfaches Format die ganze Variabilität
der möglichen Gitterimplementierungen abdecken kann.  Z.B. könnten
wir das Format nicht dazu verwenden, um die Gittertests zu verein-
heitlichen.  Der UGGrid-Test muß auch Prismen und Pyramiden testen
können.  Oder was passiert wenn jemand ein dim=2, dimworld=3 Gitter
implementiert?  Oder OneDGrid?  Oder ein Geologengitter das nur
aus Prismen besteht?

Mein Vorschlag: vertagen.

Viele Grüße,
Oliver

************************************************************************
* Oliver Sander                ** email: sander at math.fu-berlin.de      *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75217           *
* Institut für Mathematik II   ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 2-6               ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************

On Fri, 3 Feb 2006, Robert Kloefkorn wrote:

> Hi alle,
>
>> Wahnsinnig elegant finde ich das alles nicht, aber selbstverständlich
>> kann man sowas in UGGrid einbauen.  Es muß dann halt der neue Konstruktor
>> die UGGrid-Gittererzeugungsschnittstelle ansteuern.
>
>>> Der Ansatz, wie es jetzt ist in UG mit
>>> 1) Default-Konstruktor
>>> 2) nachtraegliches Initialisieren
>>> ist bei den anderen Gittern schwer einzubauen (ginge das so ohne
>>>    weiteres etwa bei Yasp?)
>
> wir sehen im Moment nur zwei Möglichkeiten, entweder, jedes Gitter
> erhält einen DefaultKonstruktor sowie eine Intitializierungs-
> schnittstelle (Olis Variante) oder jedes Gitter erhält eben so einen
> Konstruktor (unser Vorschlag), der einen istream oder besser eine
> Erzeugungsklasse bekommt übergeben bekommt. Ich sehe zwar auch, das die
> Variante mit Erz.Klasse an Konstruktor übergeben etwas einschränkt (aber
> hier eher im Sinne von Schnittstelle festlegen), aber ich denke, das
> macht nichts. Das von uns entwickelte Format für die verschiedenen
> Gittertypen ist so allgemein und einfach, das es ohne weiteres auf alle
> anwendbar ist. D.h. man kann später immer noch bei Bedarf einen
> Konverter AmiraMesh --> Dune Format oder ICEM CFD --> Dune Format
> schreiben. Ausserdem können die Gitter ja beliebig viele Konstruktoren
> haben, nur der eine eben ist bei allen gleich. Der Rest ist frei
> gestaltbar. Deshalb mag die Festlegung auf einen Kontruktor, der für
> alle Gitterklassen gleich ist, unelegant erscheinen, aber die Benutzung
> erleichtern wird es allemal.
>
> Grüßle
>
> 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
>
> _______________________________________________
> Dune mailing list
> Dune at hal.iwr.uni-heidelberg.de
> http://hal.iwr.uni-heidelberg.de/cgi-bin/mailman/listinfo/dune
>