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

[Carsten Gräser]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20140408/72895494/attachment.sig>