[Dune] Re: Grid refinement and persistent geometry objects.

[Martin Weiser]

Hallo Robert,

vielen Dank für die ausführlichen Hinweise. In der Tat habe ich die 
wasRefined()- und mightBeCoarsened()-Methoden offenbar glatt übersehen.
Da ich mir immer schmeichle, nicht viel blöder als alle anderen zu sein, 
wäre ein Querverweis in der Doxygen-Doku von der Grid-Seite aus auf diese 
Methoden vielleicht eine gute Idee.

Kann ich davon ausgehen, daß der Vater einer 
mightBeCoarsened()==true-Entity nach der Verfeinerung existiert, oder muß 
ich die Restriktionen bis zurück zum Level 0 berechnen?

On Monday 16 October 2006 12:52, Robert Kloefkorn wrote:
> > (i) I don't know these new nodes before refinement, since I don't
> > know wheter bisection or red/green refinement is used. In fact, even
> > if I knew, it is a rather difficult and global computation to decide
> > > whether
> > any cell is refined at all.
>
> Das ist in der Tat Teil der Schnittstelle. Man kann aber vor der
> Adaption abfragen, ob eine Entity vergröbert werden könnte.
> Für diese Entities nimmt man dann eine Restriktion vor.
> Nach der Gitteradaption kann man wiederum abfragen, ob eine Zelle
> verfeinert wurde. Auf diesen nimmt man dann eine Prolongation der Daten
> vor. Zu beiden Zeitpunkten sollte das Gitter eindeutig bestimmt sein.
> Zumindest sieht die Schnittstelle das vor.

Gut, damit kann ich die Verfeinerung (fast) perfekt umsetzen. Nur rot-grün 
verstehe ich noch nicht ganz. Wenn ein  grüner Abschluß weiter verfeinert 
wird, werden die grünen Entities entfernt und deren Vater dann rot 
verfeinert. Die grünen Entities müßten also mightBeCoarsened()==true 
angeben und hinterher deren Vater wasRefined()==true, richtig?
Wenn ich jetzt vor der Adaption auf den Vater restringiere und hinterher 
auf die roten Kinder prolongiere, verliere ich die grüne Information. Ok, 
das ist in vielen Fällen wohl zu verschmerzen.

> Wie man sich ganz allgemein einen Restriktions/Prolongations Operator
> schreibt, ist im Tutorial im file finitevolumeadapt.hh aufgezeigt.
> Allerdings ist der Algorithmus so allgemein, dass er für bestimmte
> Verfahren, bei denen z.B. in jedem Zeitschritt adaptiert wird,
> ineffizient ist. Wenn es Dir um Effizienz geht, dann bist Du besser
> beraten, eine Callback zu verwenden. Dies ist aber im Moment nicht Teil
> der Schnittstelle und nur in AlbertaGrid und  ALUGrid verfügbar.

Hm, hatte DUNE nicht auch den Anspruch der Effizienz? Was ist eigentlich 
so ineffizient an diesem Algorithmus? Der Zugriff über std::map? Oder die 
Berechnung der id's? Oder daß stets über die ganze Hierarchie iteriert 
wird? mightBeCoarsened()/wasRefined() wird ja nicht verwendet.

> >(ii) I cannot access geometry objects for the pre-refinement leaf
> > cells,
> > since these cells need not exist after refinement (clear for
> > coarsening,
> > but also true for green closures removed before refinement).
>
> Verstehe ich nicht. Was meinst Du denn genau mit pre-refinement leaf
> cells? Die Schnittstelle ist doch an dieser Stelle eindeutig. Alle
> Entities die existieren, kann man auch erreichen. Kannst Du mal genauer
> erläutern was da benötigt wird?

Unter pre-refinement leaf cells verstehe ich jene, die vor der Adaption 
Blätter im Gitterbaum waren.  Nachher müssen die ja gar nicht mehr 
existieren. Deshalb kann man hinterher nicht mehr auf deren Geometrie 
zugreifen.

> Vielleicht kannst Du mal den Alogrithmus, den Du zum Prolongieren, bzw.
> Restringieren der Daten verwenden willst, kurz beschreiben, dann kann
> ich Dir wahrscheinlich ein paar Tips geben.

Die Idee war folgende. Pseudocode nach der Adaption:

for (i=indexSet.leafBegin(); i!=indexSet.leafEnd(); ++i)
  for (j=nodes.begin(*i); j!=nodes.end(*i); ++j)
    xglob = i->geometry().global(j->localPosition());
    g = find pre-adapt leaf cell geometry containing xglob 
    // das erfordert etwas auf und ab im Gitterbaum anhand von id's
    newCoefficients[globalIndex(*i,*j)] = evaluate(g,xglob);

War aber offenbar ein DUNE-inkompatibler Ansatz.

Schöne Grüße
Martin

-- 
Dr. Martin Weiser                  web:     www.zib.de/weiser
Zuse Institute Berlin              mail:    weiser at zib.de
Numerical Analysis and Modelling   pgp key: www.zib.de/weiser/weiser.asc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20061016/792ca557/attachment.sig>