[Dune] Re: Task #114.

[Oliver Sander]

Hi everybody!
Before we do this maybe we should consider the following point:
is there a better way to implement a mark state than a simple
integer?  Using -1, 0, 1 for coarsening, do-nothing, refinement,
respectively, does work, but an enumeration type may be nicer.

That's only style, though.  The more important problem is that
there are grid implementations which offer a wider range of
marks.  UG, for example brings about 15 different ways to
refine 3d elements.  Ideally, our interface (read: the new
mark method) should be able to reflect this.  Currently I
can't really think of a simple way to do this, though.

regards,
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 Mon, 6 Nov 2006, Mario Ohlberger wrote:

> Hi all,
>
>  we also discussed task 114 in our meeting today. As a result, we
> suggest to follow Olivers proposal in the following way:
> there should be an additional method "int getMark(Entity &)" on the
> grid-class that returns the mark that is set on the Entity.
>
> Best regards,
>
> Mario.
>
>
>
> Markus Blatt wrote:
>> Hi,
>>
>> On Mon, Nov 06, 2006 at 10:30:30AM +0100, Oliver Sander wrote:
>>
>>> 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
>>>
>>
>>
>> we just discussed this issue in our group meeting here in
>> Stuttgart. We agree with Oliver that his proposed solution (mark
>> method just marks and user code can query mark state) is  more
>> intuitive and clear to the user. It is not too much additional work to
>> include and if statement in the already exisitent loop over all
>> entities and for people reading the user code it is more clear what
>> happens.
>>
>> Therefore we would prefer this
>> (rather simple) soltion over the solution with priority rules
>>
>> Cheers,
>>
>> Markus (Speaking for Stuttgart)
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://www.dune-project.org/cgi-bin/mailman/listinfo/dune
>
> -- 
> ***********************************************************
>  Dr. Mario Ohlberger		     Tel.: +49-761/203-5635
>  Abteilung f. Angewandte Mathematik Fax.: +49-761/203-5632
>  Universitaet Freiburg
>  Hermann-Herder-Str. 10
>  D-79104 Freiburg
>
>  E-Mail: mario at mathematik.uni-freiburg.de
>  http://www.mathematik.uni-freiburg.de/IAM/homepages/mario/
> ************************************************************
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://www.dune-project.org/cgi-bin/mailman/listinfo/dune
>