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

Tue Apr 8 21:50:31 CEST 2014

Hi,

Perfect, now only point 5) remains a bit unclear :D If you could look up 5) I would be very thankful because this is the really important point for my composite grid, i.e. it determines with what algorithm I can assign composite indices.

Hopefully we can incorporate the essential conclusions of this thread into the DUNE docu, I will at least make a proposal.

Cheers,
Raffael

________________________________________
From: Carsten Gräser [graeser at mi.fu-berlin.de]
Sent: Tuesday, April 08, 2014 9:39 PM
To: Casagrande  Raffael; dune at dune-project.org
Subject: Re: [Dune] How children which are copies of their father handled in DUNE?

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