[Fwd: Re: [Dune] Roadmap...]

[Andreas Dedner]

> Mein Vorschlag: vertagen.

Stimme ich nicht zu:
Dune sollte einem ja auch eine einfache Moeglichkeit geben, neue
Verfahren zu test und Peters Laplace Ergebnisse haben ja schon
schoen demonstriert, wie unterschiedliche Gittervarianten
die Loesung beeinflussen. Es ist also haeufig nicht so, dass ich bereits
weiss, ob ich Gitter A oder B verwenden moechte - etwa ob Bisektion,
Viertelung oder RotGruen die beste Wahl fuer mein Verfahren ist.
So was kann ich gut auf einfachen Gebieten mit einfachen Gittern testen!
Dafuer ist unser Gitterformat gemacht. Komplexe Anwendungen sind da
sicherlich was anderes, obwohl man auch hier mit einem einfachen
Gitterformat relativ weit kommt. Es spricht ja dann auch nix gegen
spezielle Konstrutoren fuer spezielle Gitter, wenn - nachdem Testen -
ich ein Anwendungsproblem mit Gitter A rechnen moechte und alle
Features nutzen will, kann ich ja dann auch die speziellen Konstruktoren
verwenden.
Gruss Andreas

Oliver Sander wrote:
> 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
>>
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Dune mailing list
> Dune at hal.iwr.uni-heidelberg.de
> http://hal.iwr.uni-heidelberg.de/cgi-bin/mailman/listinfo/dune