[Dune] ISI
Andreas Dedner
dedner at mathematik.uni-freiburg.de
Wed May 31 16:28:29 CEST 2006
>
> Peter Bastian wrote:
>
>>Klar, finde ich auch gut. Zwei Fragen:
>>
>>(1) Das übliche: Vor 1.0? Und was ist eigentlich mit 1.0? Gibts da noch
>>einen Plan?
>
ich denke von unserer Seite ist die Umstellung nicht so
schlimm, dass das nicht bis 1.0 ginge.
Die Tests muessen natuerlich auch umgebaut werden. Da ist allerdings
noch an einigen Stellen implizite Annahmen ueber die Konformitaet
des Gitters (level Gitters) enthalten, die bei konformer Bisektion
schief gehen. Wir sollten also meiner Meinug nach moeglichst schnell
das geaenderte Interface festlegen.
>>(2) Was ist mit boundary intersections? Liefert dann jeder Iterator
>>einfach auch die intersections mit dem Rand wie bisher? Die Sache mit
>>dem Rand ist folgende: In manchen Fällen (zB P1 Elemente) braucht man
>>NUR die Randintersections. Dann wäre es effizienter nur über die
>>Randintersections laufen zu können. Alternativ wäre folgendes möglich
>>(hab ich, glaub ich schon mal vorgeschlagen): Man kann effizient an der
>>codim 0 entity abfragen ob es überhabt Randintersections gibt und nur
>>dann den Iterator anwerfen.
bauen wir das auch ins Interface an - z.B. mit DefaultImplementierung
Interface: bool hasBoundaryIntersection() const
Gruss Andreas
>>Viele Grüße
>>
>>Peter
>>
>>Oliver Sander schrieb:
>>
>>
>>>Da stimme ich voll zu.
>>>
>>>Grüße,
>>>Oliver
>>>
>>>************************************************************************
>>>* Oliver Sander ** email: sander at mi.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 6 ** -------------------------------------*
>>>* 14195 Berlin, Germany ** Member of MATHEON (www.matheon.de) *
>>>************************************************************************
>>>
>>>On Wed, 31 May 2006, Andreas Dedner wrote:
>>>
>>>
>>>>Hallo,
>>>>wir haben uns heute mal in Freiburg abgesprochen und folgenden
>>>>Vorschlag fuer den InterSectionIterator erarbeitet:
>>>>
>>>>0) Der jetzige faule Kompromiss ist unschoen. Vor allen Dingen heisst
>>>> das im Moment, dass bei allen Gittern der Isi ineffizient ist,
>>>> wenn es schwierig ist entweder die leaf oder die level Nachbarn
>>>> zu berechnen.
>>>>1) Wir sollten doch einfach zwei Iteratoren (Leaf/Level) machen,
>>>> dass ist konsistent mit dem sonstigen Interface
>>>>2) Es gibt dann ein ileafbegin/end und ein ilevelbegin/end
>>>> auf der Entity, ibegin/end wird depricated
>>>>3) Es gibt dann wieder nur eine neighbor Methode.
>>>>
>>>>Gruss aus Freiburg
>>>>
>>>>_______________________________________________
>>>>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
>>
>>
>
More information about the Dune
mailing list