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

Casagrande Raffael raffael.casagrande at sam.math.ethz.ch
Tue Apr 8 21:27:10 CEST 2014


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 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?)
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 (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).
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.
4) The contains method of the leaf view will return true for nodes (I) and (J) but not for node (h).
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.

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





More information about the Dune mailing list