[Dune] refelem

[Peter Bastian]

Moin, moin,

da geht es ja schon wieder heiss her. Ich kann einerseits schon Roberts
Argument mit Schnittstelle vs. Gemeinsamkeit verstehen. Andererseits
meine ich auch, dass wir bei einem unserer Treffen uns einig waren diese
Flexibilität nicht zu erlauben (Tja, da bräuchten wir jetzt gute
Protokolle).

Ich meine der Grund ist der folgende (wir haben da auch in Avignon
drüber gesprochen, Robert): Diese Flexibilität macht nur Sinn, wenn ich
dann ein FE-Verfahren wirklich komplett unabhängig von der Definition
des Referenzelementes programmieren kann. Das bedeutet aber auch, dass
Quadraturformeln und Shapefunctions auf beliebigen Referenzelementen
arbeiten müssen. Das kann man zwar machen aber es macht die Sache
langsamer und das wo man nicht mal einen vernünftigen Grund für diese
Flexibilität angeben kann.

Ich wäre für folgendes: Robert zeigt uns wie man nicht nur
Referenzeelemente sondern ALLES wirklich flexibel machen kann und das
auch noch effizient. Dann wäre ich auch dafür.

Die Möglichkeit mit dem GeometryType bleibt einem immer. Es spricht
nichts dagegen zwei verschiedene Vierecke (z.B. mit unterschiedlichen
Nummerierungen) zu definieren. Wenn man dann noch die Referenzelemente,
Quadraturen und Shapefunctions dazu definiert würde das jetzt schon
funktionieren.

Grüße aus HD

-- Peter

Robert Kloefkorn schrieb:
> Oliver Sander wrote:
> 
>>Hallo!
>>Ich halte das für inkonsistent.  Schließlich weisen sich Elemente
>>über ihren GeometryType aus.  Wenn Du jetzt unter Flexibilität
>>verstehst, daß verschiedene Gitterimplementierungen unterschiedliche
>>(== z.B. unterschiedliche Numerierungen) Referenzhexaeder verwenden,
>>so kannst man das natürlich machen. 
> 
> Ja über den Sinn kann man sich hier streiten. Ich wüsste keinen guten
> Grund das zu verbieten. Schliesslich weiss man ja jetzt noch nicht
> genau, was es später für Gitterimplementierungen geben wird.
> 
> 
>>Wir haben allerdings mal
>>beschlossen, IMHO aus gutem Grund, das nicht so zu machen.
> 
> Ich habe da nichts beschlossen und bin immer noch dagegen.
> 
> 
>>Wenn Du mit Flexibilität allerdings meinst, daß eine Gitterimplemen-
>>tierung völlig neue Element-Typen benutzen kann, dann müssen die
>>ja doch wieder als GeometryType auftauchen, und dann kann man
>>auch gleich eine zentrale Referenztopologiensammlung erweitern.
> 
> Meine Ansicht der Dinge ist folgende: Die Schnittstellen sollten
> ermöglichen, dass verschiedene Implementierungen in einem Kontext
> genutzt werden können, falls das prizipiell möglich ist. Allerdings bin
> ich nicht der Meinung, dass das Interface auch gleich noch vorschreiben
> sollte, dass entsprechender Code nicht mehr anders verwendet werden
> darf. Genau das ist halt das Problem bei der jetztigen
> Implementationsstrategie der Refelemente. Diese ist keine Interface,
> sonderen Gemeinsamkeit wird einfach dadurch erreicht, das man alle
> anderen RefElement Implementierungen verbietet. Das ich da nicht
> mitmache, versteht sich ja wohl von selbst. Das ist mir einfach zu
> restriktiv. Aber das können wir ja auf dem nächsten Treffen nochmal
> durchdiskutieren.
> 
> 
>>Ich vermute mal das ich Dich damit nicht habe überzeugen können ;-)
> 
> Right you are ;)
> 
> GRüssle
> 
> R
> 

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