[Dune] How children which are copies of their father handled in DUNE?

Carsten Gräser graeser at mi.fu-berlin.de
Tue Apr 8 22:36:54 CEST 2014 

Hi Martin,

Am 08.04.2014 22:07, schrieb Martin Nolte:
> Hi Carsten,
> 
> as far as I understand it, the leaf grid view consists of equivalence
> classes of entities. From the point of the grid view, all possible
> representatives of this equivalence class are the same (e.g., the have
> the same index) and cannot be distinguished by methods on the grid view.
> 
> When iterating over the grid view, you actually iterate over these
> equivalence classes. For simplicity, however, you will not get the
> entire equivalence class as an entity, but only one representative. For
I've never seen it that way but from the perspective of the grid view
you're of course right.

> me, this implies that the iterator will not stop twice on entities of
> the same equivalence class. To my knowledge, all grid managers implement
> these iterators in this way.
> 
> I would like to amend that this confusion is partly caused by the method
> level being on the entity. On the leaf view, an entity does not have a
> level. The method level returns the "number" of the/a level grid view
However it is relatively new that the level() method is the only
possible difference. Before we decided on the globally fixed
orientation of faces on the last meeting you could have the case that
the face corresponding to a conforming leaf intersection behaves
differently when viewed from a coarse or fine level leaf element.

Best,
Carsten


BTW:
If one wants to split hairs one could argue that they would also
be distinguishable without the level method because of
gridView().grid().levelGridView(i).contains(vertex)    ;-)


> containing this entity. In this sense, the method actually belongs onto
> the container of the level grid views, i.e., on the grid. But let's keep
> that can of worms closed for now. Hopefully, improving the documentation
> of the method level a bit will already help the readers.
> 
> Best,
> 
> Martin
> 
> On 04/08/2014 09:39 PM, Carsten Gräser wrote:
>> Hi,
>>
>> Am 08.04.2014 21:27, schrieb Casagrande Raffael:
>>> Hi,
>>>
>>> Thanks a lot for the explanation! I think this answered all my
>>> questions :) But just to make sure that I got everything right I've
>>> rephrased it a bit:
>>>
>>> 1) Generally every entity OBJECT represents an entity and not the
>>> equivalence class of an entity. (E.g. node (I) and (J) are not the
>>> same objects even though they belong to the same equivalence class
>> yes.
>>
>>> w.r.t. the copy relation) However some grid managers may choose to use
>>> the same object for node (I) and (J) and in this case the level()
>>> method of the entity object returns max(level(I), level(J)) (or is
>>> this arbitrary?)
>> No this is not allowed.
>>
>>> 2) If I take a conforming, interior leaf intersection, i, then it is
>>> possible that: i.inside().subEntity<1>(i.indexInInside()) !=
>>> i.outside().subEntity<1>(i.indexInOutside()) . (In the example above
>>> this would be the case for the leaf intersection associated with
>> Yes.
>>
>>> (IJ)). On the other hand if we additionally take a leaf index set,
>>> lis, into consideration, then the following is always true:
>>> lis.subIndex(i.inside(),i.indexInInside(),1) ==
>>> lis.subIndex(i.outside(), i.indexInOutside(),1).
>> Yes, if the intersection is conforming.
>>
>>> 3) The size methods of the leafView return the total number of
>>> equivalence classes for entities of a given codim/Geometry type
>>> (Markus Blatt). E.g. if I ask the leaf view in your example for the
>>> number of nodes it will return 5.
>> Yes, or equivalently its the maximal index+1.
>>
>>> 4) The contains method of the leaf view will return true for nodes (I)
>>> and (J) but not for node (h).
>> Yes.
>>
>>> 5) If I loop over all codim=1 entities of the leaf view directly then
>>> I get (your example): (C),(G),(N),(J),(L) ? (I've chosen Node (G)
>>> instead of (F) because (G) has a lower refinement level, do you know
>>> if this always holds?). So in a way I iterate over the equivalence
>>> classes of the nodes and the grid manager gives me for every
>>> equivalence class ONE representant.
>> I'd say it iterates also over (F), (M), and (L). However Oliver
>> confused by stating this differently in this thread. I'll look
>> this up.
>>
>> Best,
>> Carsten
>>
>>>
>>> Is this correct?
>>>
>>> Btw. I need to know these details so accurate because I'm working on a
>>> "composite grid" which fulfils the DUNE interface and which consists
>>> internally of other grids fulfilling the DUNE interface.
>>>
>>> Cheers and thanks again,
>>> Raffael
>>>> -----Original Message-----
>>>> From: Carsten Gräser [mailto:graeser at mi.fu-berlin.de]
>>>> Sent: Dienstag, 8. April 2014 20:03
>>>> To: Casagrande Raffael; dune at dune-project.org
>>>> Subject: Re: [Dune] How children which are copies of their father
>>>> handled in
>>>> DUNE?
>>>>
>>>> Hi,
>>>> I believe it's worth to add some more corner cases to make things
>>>> more clear.
>>>> To this end let's extend the example a little bit:
>>>>
>>>> (a)---(d)---------(h)---(k)   level 0
>>>> (b)---(e)---------(I)===(L)   level 1
>>>> (C)===(F)---(M)===(J)         level 2
>>>>        (G)===(N)               level 3
>>>>
>>>> Such grid is perfectly OK within the interface.
>>>> E.g. UGGrid uses copies of elements under certain circumstances.
>>>> Leaf vertices
>>>> and elements are marked by capital letters and =, respectively.
>>>>
>>>> In this example (J) is indeed a copy of (I) and both share the same
>>>> leaf index.
>>>> However they are _not_ the same thing, even from the perspective of the
>>>> LeafView. E.g. if you loop over the elements in the LeafView and ask
>>>> each for its
>>>> vertices then (MJ) will give you (M) and (J) whereas (IL) will give
>>>> you (I) and (L)
>>>> and _not_ (J) and (L).
>>>>
>>>> As stated earlier (I) and (J) can easily be distinguished e.g. using
>>>> the level()
>>>> method. However copies can differ in more aspects:
>>>>
>>>> * (h) is also a copy of (I) and (J) but
>>>> * (h) is _not_ a leaf vertex
>>>> * The leafIndex of (h) is undefined and in fact not
>>>>    implemented in some grid managers.
>>>> * (F-M) is a copy of (G=N) but (F-M) is not leaf
>>>>    although all its vertices (F) and (M) as well as
>>>>    its copy (G=N) is leaf.
>>>>
>>>> I hope this helps to clarify things.
>>>>
>>>> Carsten
>>>>
>>>> Am 08.04.2014 16:15, schrieb Oliver Sander:
>>>>> Am 08.04.2014 16:12, schrieb Casagrande Raffael:
>>>>>> Hi Oliver,
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: sander at igpm.rwth-aachen.de [mailto:sander at igpm.rwth-
>>>> aachen.de]
>>>>>>> Sent: Dienstag, 8. April 2014 16:02
>>>>>>> To: dune at dune-project.org; Casagrande Raffael
>>>>>>> Subject: Re: [Dune] How children which are copies of their father
>>>>>>> handled in DUNE?
>>>>>>>
>>>>>>> Hi Raffael,
>>>>>>>
>>>>>>>>
>>>>>>>> Hmm what I meant with std::distance(begin,end) is just the number
>>>>>>>> of times that I have to increment begin until begin == end. So if I
>>>>>>>> take again the example from my original question,
>>>>>>>>
>>>>>>>> (a)-------------(i)------(b)    level 0
>>>>>>>> (c)------(d)----(j)               level 1,
>>>>>>>>
>>>>>>>> Then the leaf view contains nodes (c), (d), (i), (j), (b) so I
>>>>>>>> assume that when I iterate through all nodes of the leaf view I
>>>>>>>> will effectively get 5 nodes? (i.e.
>>>>>>>> std::distance(leafView().begin<1>(),
>>>>>>>> leafView().end<1>()) == 5 but
>>>>>>>> leafView().size(1) == 4)
>>>>>>>>
>>>>>>>
>>>>>>> The vertices in a leaf view are equivalence classes of actual
>>>>>>> vertices.  Therefore in your example (i) and (j) are actually the
>>>>>>> same thing.  Upon iterating over all leaf vertices you will get
>>>>>>> (c), (c), (i/j), (b),
>>>> i.e., four vertices.
>>>>>>>
>>>>>>
>>>>>> Okay that makes sense. I think what confused me is the level()
>>>>>> function of a
>>>> codim>0 entity because it implied for me that one node object can
>>>> only belong
>>>> to exactly one level. Do you know how the level of node (i/j) would
>>>> be defined in
>>>> the described setting?
>>>>>>
>>>>>
>>>>> I suppose that would be the number of the finest grid level the
>>>>> vertex is on.
>>>>> -- 
>>>>> Oliver
>>>>>
>>>>>> Thanks a lot,
>>>>>> Raffael
>>>>>>
>>>>>>> Hope that helps,
>>>>>>> Oliver
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2) But I guess for any levelView this equality will hold because
>>>>>>>>>> there are no
>>>>>>>>> children and fathers (which could be copies of each other) in the
>>>>>>>>> same level view?
>>>>>>>>>>
>>>>>>>>>> If this is so then I would suggest to update the documentation of
>>>>>>>>>> the IndexSet
>>>>>>>>> to something like this:
>>>>>>>>>>
>>>>>>>>>> The index map \f$ m \f$ has the following properties:
>>>>>>>>>>    - Two entities have the same index if one is an exact copy
>>>>>>>>>> of the other,
>>>> i.e.
>>>>>>>>> for any \f$ e, e' \in E_g^c \f$ we have \f$ e \mathcal{C} e'
>>>>>>>>> \rightarrow m(e) = m(e')\f$ (this is only possible in leaf views)
>>>>>>>>>>    - Otherwise they have different indices: For any \f$ e, e' \in
>>>>>>>>>> E_g^c\f$ such
>>>>>>>>> that \f$ e \neq e' \wedge  \neg( e \mathcal{C} e' ) \f$ then \f$
>>>>>>>>> m(e) != m(e') \f$
>>>>>>>>>>    - It is consecutive and zero-based within the subsets \f$
>>>>>>>>>> E_g^c
>>>>>>>>>> / \mathcal{C}
>>>>>>>>> \f$, i.e. we have \f$ 0 \leq m(e) < |E_g^c / \mathcal{C} | \f$ for
>>>>>>>>> any \f$ e \in E_g^c\f$.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please open a bug report about this at
>>>>>>>>> <http://www.dune-project.org/flyspray>. On this list it might
>>>>>>>>> simply get
>>>> lost.
>>>>>>>>
>>>>>>>> Okay, I'll do that in a moment when I'm sure I've understood the
>>>>>>>> problem ;)
>>>>>>>>
>>>>>>>> Thanks a lot in advance,
>>>>>>>> Raffael
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Markus



-- 
Prof. Dr. Carsten Gräser
Freie Universität Berlin
Institut für Mathematik
Arnimallee 6
14195 Berlin, Germany
phone: +49 30 838 75399
fax  : +49 30 838 54977
email: graeser at mi.fu-berlin.de
URL  : http://page.mi.fu-berlin.de/graeser

More information about the Dune mailing list