[Dune] Re: Task #114.

[Oliver Sander]

Hi Robert!
Thanks for the explanation.  You are right, this is not a difficult
problem to fix in OneDGrid and UGGrid.  However I must say that
I don't particularly like your proposed solution.  Intuitively, I
would expect a method 'mark()' to do just that: mark the element,
and not follow some implicit priority rules while doing so.  These
would have to be documented very well and still people wouldn't
read them and then wonder why mark doesn't always coarsen elements
when it is told to do so.
In order to solve your problem I propose to add a new method which
returns the mark state of an entity.  Then you could implement your
priority rule outside of the class interface.  To me, this would
have several advantages:
- the semantics of mark() are easier to understand
- you could implement other priority rules if that was ever
   necessary
- the implementation of mark() could be faster, which is good,
   because most applications don't use priority rules anyways.
- having access to the mark state may be useful for debugging

What do you think?  What do the others think?

--
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 Fri, 3 Nov 2006, Robert Kloefkorn wrote:

> Hallo Oli,
>
> könntest Du dich bitte mal um Task #114 kümmern. Es fehlen da nur noch
> OneDGrid und UGGrid und es sollte nicht weiter tragisch sein, das zu
> implementieren. Das Problem ist, das beim Aufruf von mark man
> prinzipiell vorher gesetzte marks wieder überschreiben kann.
> Das darf aber nicht sein, weil man von aussen nicht abfragen kann, ob
> bereits markiert  wurde, oder nicht.
> Deshalb muss ein refine flag immer einen none flag und dieser immer
> einen coarsen flag "übertreffen". Dies bedeutet, das Element die einmal
> zum Verfeinern markiert wurden, nicht mehr zum vergröbern markiert
> werden können. Das benötigt man z.B. bei expliziten FV, wenn man ein
> Element markiert, markiert man auch dessen Nachbarn, weil dann
> sichergestellt ist, das das Gitter im nächsten Zeitschritt die richtige
> Feinheit hat. Dabei weiss man ja nicht auf welchen Element man zuerst
> ankommt, man muss nurr wissen, das ein refine flag eben auf jeden Fall
> gesetzt wird und auch bleibt, selbst wenn man später noch mal zum
> vergröbern markieren wollte.
>
> Ich hatte diesen Task 114 schon vor längerer Zeit mal geöffnet und nun
> auch endlich mal die Doku dahingehend verbessert.
> In AlbertaGrid und ALUGrid ist das so implementiert. In UGGrid nicht,
> auf jeden Fall sieht der Code in der mark Methode nicht so aus, also
> könnte er das leisten. Bei OneDGrid weiss ich es nicht.
> Ist das bei den bieden Gittern ein Problem?
>
> 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
>