[Dune] CurvilinearGridAPI: Implementation of EntityTags and BoundaryIterators

[Christian Engwer]

Am 18. Dezember 2014 16:04:50 MEZ, schrieb Aleksejs Fomins <aleksejs.fomins at lspr.ch>:
>Dear Oliver,
>
>Yes, in principle it would be nicer to associate a vector of tags with
>an element, as it is done in DGF.
>
>But my argument is a little different. I can store another file for my
>derived code which associates 1 integer tag for every element with a
>hundred and one physical property, as many as I want. Then I would be
>able to recover these properties in the derived code.

You can do exactly the same already. You have an indexset and store your Id in a vector in user code. The memory overhead is exactly the same, but it's only required, if you need the Id. And you don't blow up the interface and the entities.

>At the moment I do not see a nice way for me to input an element into
>the grid, and then find which element that is after the grid is
>assembled. An integer tag would fill this hole

Have a look at the gmsh reader. You can pass a vector to the reader to store the Id from the file for each coarse grid entity.

Christian

>
>Best,
>Aleksejs
>
>On 12/18/2014 03:51 PM, Oliver Sander wrote:
>> Am 18.12.2014 um 15:45 schrieb Aleksejs Fomins:
>>> Dear All,
>>>
>>> Thank you for your replies. I will read through the
>PersistentContainer
>>> and get back to you.
>>>
>>> Oliver, You only ever need to attach 1 integer to each element to
>>> represent physical property. Since there are finite number of
>elements
>>> in the mesh, they have finite number of material properties which
>will
>>> be stored whichever way the user chooses in the derived code.
>> 
>> So what if you have more than one property per element, say in a
>multi-physics
>> application?  Will you multiplex all properties into the single
>integer,
>> or request that more integers be added to the grid interface?
>> --
>> Oliver
>> 
>>>
>>> Rob, I already know how to implement this iterator, there is no
>problem
>>> with that. I was only asking on what would people find more
>convenient
>>> to use. And I disagree that in general looping over elements and
>>> boundaries is not much different, there is N^{2/3} less of the
>latter
>>> than the former, for very large tasks this can become significant.
>>>
>>> Cheers,
>>> Aleksejs
>>>
>>>
>>> On 12/18/2014 03:33 PM, Oliver Sander wrote:
>>>> Am 18.12.2014 um 15:24 schrieb Christoph Grüninger:
>>>>> Hi!
>>>>>
>>>>>> I agree with both feature request but I can tell you right away
>that at
>>>>>> least with respect to the material property you will not find
>much
>>>>>> support. We had a method like that for a boundary id but that was
>now
>>>>>> removed.
>>>>>
>>>>> We have this use case, too. We want to read grids with attached
>>>>> permeabilities to its cells. In principle we would like to have
>such a
>>>>> feature.
>>>>
>>>> So what type would you like to attach to each element?  A double? 
>Or rather
>>>> a full 3x3 matrix, because permeabilities are tensors after all? 
>Or an
>>>> enum?  What would the values of that enum be?
>>>>
>>>>>
>>>>> The boundary ID issues was more complex, if I remember correctly.
>It was
>>>>> removed as some questioned that the feature was properly
>>>>> documented/defined/described.
>>>>
>>>> This was an additional objection.
>>>>
>>>>>
>>>>> Oliver answered Aleksejs should "expect quite a bit of opposition
>to
>>>>> it." I am wondering, who is this opposition?
>>>>
>>>> Me, to say the least.
>>>>
>>>> :-)
>>>> Oliver
>>>>
>>>>  Maybe we should make a
>>>>> non-decisive move to get a insight in the general opinion?
>>>>>
>>>>> Best
>>>>> Christoph
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dune mailing list
>>>> Dune at dune-project.org
>>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Dune mailing list
>>> Dune at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>> 
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Dune mailing list
>Dune at dune-project.org
>http://lists.dune-project.org/mailman/listinfo/dune