[Dune] Re: Frage zu Methoden local und global.

Robert Kloefkorn robertk at mathematik.uni-freiburg.de
Wed Mar 26 11:11:23 CET 2003


Peter Bastian wrote:
> Robert Kloefkorn schrieb:
> 
>>Hi Peter,
>>
>>sollen die Methoden local und global eigentlich von baryzentrischen
>>Koordinaten in Raumkoordinaten umrechnen oder geben sie wirkliche
>>Koordinaten in den Elementen zurück. Wenn letzteres der Fall ist, dan
>>bräuchten wir noch ensprechende Methoden.
>>
> 
> 
> Hallo Robert,
> 
> global rechnet von localen Koordinaten auf dem Referenzelement auf
> globale
> Koordinaten (im transformierten Element) um. 
> 
> local macht genau die inverse Abbildung.
> 
> Meines Erachtens ist es notwendig für Dune die Referenzelemente
> festzulegen, d.h. in der Schnittstelle werden implizit gewisse
> Referenzelemente vorausgesetzt. Das müssen wir uns jetzt überlegen.
> Für Vierecke nehmen wir immer [0,1]^d, das habe ich in SGrid
> auch so eingebaut. Baryzentrische Koordinaten eignen sich halt
> nur für SImplizes. Wir verwenden dort immer 0 <= \sum x_i <= 1.
> Hat den Vorteil, dass man seine FE-Diskretiserung elementunabhängig
> programmieren kann (wenn man Basisfunktionen, Quadraturformeln etc
> geeignet
> bereitstellt). Aber das müssen wir jetzt ausdiskutieren.
> 
> Übrigens: Das mit den Basisklassen wird ultracool ... Bin gerade
> dabei das einzubauen.

Klingt immer besser. Ich bin gerade dabei Basisfunktionen, 
Gitterfunktionen, Funktionenräume zu entwerfen. Deswegen bin ich 
überhaupt darauf gekommen, weil ich bei der Auswertung einer 
Gitterfunktion an einen Punkt im Gitter zuerst das Element, welches den 
Punkt enthält suche, was hervorragend funktioniert mit einem 
LevelIterator über Level 0 iterieren und in dem Element, in welchem der 
Punkt liegt, dann den Baum bis zu den Blättern laufen. Dafür musste ich 
die Methoden local und global implementieren. Das Problem ist, dass für 
die baryzentrischen Koordinaten die Funktion local etwa so aussieht

   Vec<dim+1> local (Vec<dimworld> global);

während es eben für SGrids so aussieht

   Vec<dim> local (Vec<dimworld> global);

Aber wir werden sicher ein Lösung finden. Ein Ausweg wäre, das man eben 
eine Methode local hat, die die wirklichen Koordinaten ausrechnet und 
eine Methode localBary, die dann die baryzentrischen Koordinaten 
liefert. Vielleicht lässt sich das aber auch noch geschickter lösen.

Desweiteren wollte ich fragen, ob wir eigentlich ganz auf STL verzichten 
wollten, oder nur eben nicht den namespace verwenden?

Grüsse

Robert


-- 

   Robert Klöfkorn           <robertk at mathematik.uni-freiburg.de>

   Mathematisches Institut              Tel: +49 (0) 761 203 5642
   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





More information about the Dune mailing list