[Dune] same ID for several interfaces!

[Carsten Gräser]

Hi Benjamin,

Am 08.06.2011 13:53, schrieb Oliver Sander:
> Hi Benjamin!
> Thanks for reporting this.  So you claim that you have come across a
> UGGrid configuration with non-unique edge indices?  That would indeed
> be a bug.
> 
> However, you know that the line
> 
> grid.globalIdSet().subId(*is.inside(), is.indexInOutside(), 1);
> 
> is not what you want: you would want is is.indexInInside().  That may
> already explain your problem with the double id: if you are on 38 then
> indexInOutside is one of 0,1,2,3,4.  However element 38 has only
> four edges.  Hence if indexInOutside happens to be 4 you run into
> undefined behaviour.
this is not true. In your case both have four faces.

If the situation is exactly as you depicted this is an error. Since
7,8,36,38 all have four faces but 36 and 38 do not share a common
face this should not happen.

If the situation is only similar to your drawing, the behaviour
might be OK:

* If 7 or 6 have more faces then 38 or 36, respectively, (triangles and quads)
  you have undefined behaviour. That's the case Oliver had in mind.
* If you exchange 38 and 39 this behaviour might be correct,
  since 36 and 38 would share a face.

> Here's my suggestion:
> Try the same with Dune 2.1 and see if the problem persists.
> If it does persist create a test case that triggers the problem
> while using the grid API correctly.  If you have such a test
> case please report back to me and I will try to fix it.
In addition please check if one of the two points above apply.

Thanks,
Carsten

> 
> Thanks in advance,
> Oliver
> 
> 
> Am 08.06.2011 13:08, schrieb Benjamin Faigle:
>> Hello Dune,
>>
>> I maybe stumbled over some strange behaviour in dune (stable 2.0), and I
>> was told to send it to the list:
>>
>> After some work on refinement, I had the situation where I got the same
>> ID for completely different interfaces when simulating in 2D with UGgrid
>> (numbers are CellIndice). I encountered a situation like this:
>>
>> +-------+
>> | |
>> | 7 |
>> | |
>> +---+---+
>> | 39| 38|
>> +---+---+
>> | 36| 37|
>> +---+---+
>> | |
>> | 6 |
>> | |
>> +-------+
>>
>> If I regard the Interface (IF) between 38 and 7 from Element 38, I
>> should get an unique ID with
>> grid.globalIdSet().subId(*is.inside(), is.indexInOutside(), 1);
>> Works most often.
>>
>> With the right geometries, after many refinement steps, I had now the
>> situation where this method gave the ID 798 - the same ID as for the IF
>> between 36 and 6 (as seen from 36)!
>>
>> Of course I could fix this by using (inside, indexInInside,1), but I
>> nevertheless thought that IDs should be unique.
>>
>> In case you are interested, tell me what information you need,
>> best regards,
>>
>> Benjamin
>>
>>
>> On 05/16/2011 12:04 PM, Jö Fahlke wrote:
>>> Am Mon, 16. May 2011, 11:27:09 +0200 schrieb Benjamin Faigle:
>>>> if i understood it right, the method
>>>> grid.localIdSet().id(const EntityType&e)
>>>> should return a unique ID for every sort of entities, be it
>>>> elements, vertices or intersections. It works out pretty well with
>>>> elements, as shown for example in the Dune Grid Howto
>>>> IdType idf = idset.id (* ep );
>>>>
>>>> However, if I try the same with an *intersection, I get the error
>>>> message:
>>>> ...dune-grid/dune/grid/common/indexidset.hh:394:43: error:
>>>> ‘codimension’ is not a member of ‘Dune::IntersectionIterator<const
>>>> Dune::UGGrid<2>, Dune::UGGridLeafIntersectionIterator,
>>>> Dune::UGGridLeafIntersection>’
>>>>
>>>> I am using dune 2.0.
>>>> I am sorry if it is just an incredibly silly question, and many
>>>> thanks for your help,
>>>
>>> Only entities have ids. Intersections are not entities!
>>>
>>> All grids have entities of codimension dim (vertices) and codimension 0
>>> (elements), and all have intersections. Some grids have entities of other
>>> codimensions as well. Even if a grid has entities of codimension 1,
>>> these are
>>> not the same as entities. Most obvious differences:
>>>
>>> * Intersections know the neighbouring cells, codim 1 entities don't.
>>>
>>> * Intersections have an orientation, codim 1 entities don't.
>>>
>>> * Codim 1 entities have indices and ids and can be used to obtain array
>>> indices from a mapper (even if the grid does not support codim 1 entity
>>> objects!) For intersections, indices, id's and maps are not provided by
>>> core Dune, though it is possibly to build such things yourself.
>>>
>>> * In non-conforming grids you may have the following situation:
>>>
>>> +-------+---+---+
>>> | | b | d |
>>> | a +---+---+
>>> | | c | e |
>>> +-------+---+---+
>>>
>>> Elements b, c, d and e all have four codim 1 subentities and four
>>> corresponding intersections. Element a also has four codim 1 subentities,
>>> but it has five intersections. The codim 1 entity to the right of b is
>>> the
>>> same as the codim 1 entity to the left of d. You have three codim 1
>>> entities to the right of a however: on covering the whole of a's right
>>> border, and two smaller one each covering the upper and the lower half of
>>> a's border, respectively.
>>>
>>> If you know you have a conforming grid, you have a correspondance between
>>> intersections and codim 1 entities (ignoring the orientation of the
>>> intersections). In that case you can usually get away by using the id
>>> of the
>>> corresponding codim 1 entity as the id of the intersection (even if
>>> the grid
>>> does not support codim 1 entities as independent objects. Use
>>>
>>> grid.globalIdSet().subId(e, i.indexInInside(), 1);
>>>
>>> where i is the intersection and e is the codim 0 entity i was obtained
>>> from.
>>> If you don't have e readily available, you can use
>>>
>>> grid.globalIdSet().subId(*i.inside(), i.indexInInside(), 1);
>>>
>>> instead.
>>>
>>> Bye,
>>> Jö.