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

Peter Bastian Peter.Bastian at iwr.uni-heidelberg.de
Fri Feb 3 22:55:50 CET 2006


Hmmm, kapiere die ganze Diskussion nicht so ganz. Es ist doch alles 
nicht so tragisch. Das Ziel ist doch nur, dass ein File zur 
Grobgitterdefinition in allen Gitterimplementierungen verwendet werden 
kann. Das heisst doch nicht, dass das an jedem Gitter auch von einer 
bestimmtem Methode gemacht wird. Wäre zwar vielleicht ganz nett, ist 
aber total unwichtig für das Ziel. Lasst uns doch einfach kleine 
Brötchen backen und endlich zu potte kommen ...

Grüße

Peter


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

-- 
------------------------------------------------------------------
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





More information about the Dune mailing list