[Dune] How children which are copies of their father handled in DUNE?
Martin Nolte
nolte at mathematik.uni-freiburg.de
Tue Apr 8 22:07:09 CEST 2014
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 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 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
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>
--
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>
Universität Freiburg phone: +49-761-203-5630
Abteilung für angewandte Mathematik fax: +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany
More information about the Dune
mailing list