[Dune] CurvilinearGridAPI: Implementation of EntityTags and BoundaryIterators

[Aleksejs Fomins]

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.

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

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
> 

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