[Dune] [Dune-Commit] dune-grid r7996 - trunk/dune/grid/common

[Carsten Gräser]

Hi,
Am 21.04.2012 21:26, schrieb Oliver Sander:
>> while the BoundaryPatch is a nice tool to do boundary related
>> stuff one you have constructed it, the descibed way of doing the
>> latter does not really solve the problem for two reasons:
>>
>> * In many cases you would like to define the patch as a set
>>    of boundary faces/intersections. One can imagine two
>>    ways to do this unsing vertices:
>>    (a) Put all faces that share one marked vertex in the patch.
>>    (b) Put all faces that have all vertices marked in the patch.
>>    Unfortunately none of these approaches covers all possible
>>    patches. Even worse there are patches that can't be constructed
>>    by both of them: Conside a cube with 4 vertices where the patch
>>    should contain face 1,2,6 (using a dice-like face numbering).
>>
> 
> Yes, I am aware of that.  Please note that I do _not_ believe that
> my approach is alleinseligmachend.  I do _not_ propose that every-
> body should do it that way.
I know. I just wanted to point this out for the others.

>> * Similar to the boundary segments, the interface does not guarantee
>>    that the vertex insertion index is the same as the level-0 index.
>>    Hence you still need to do the same renumbering you would need
>>    for boundary segmentes using GridFactory::insertionIndex().
>>
> True, but I think that grids should simply guarantee that the numbering
> stays the same, anyway.  We could then just do away with the whole
> insertionIndex business.
I'd support this. The index translation is really a mess - especially
since every mesh reader has to export the factory, and every user
has to do the same index translation.

Carsten


> 
> best,
> Oliver
> 
> 
>> Best,
>> Carsten
>>
>> BTW:
>> You could also setup a BoundaryPatch using a set of boundary segemnt
>> indices or the grid factory and a set of insertion indices.
>>
>> Am 20.04.2012 20:37, schrieb Oliver Sander:
>>> Hi,
>>> for each type of boundary condition that is not homogeneous Neumann
>>> I set up a file with a '1' for each vertex that is part of the
>>> corresponding boundary part.  dune-fufem has a class BoundaryPatch,
>>> which encapsulates parts of the boundary, and which you can set
>>> up with a per-vertex bitfield (which you read from the file).
>>> The BoundaryPatch provides an iterator over all boundary segments
>>> that are part of the patch, and we have a special type of assemblers
>>> that uses this iterator to assemble boundary conditions.
>>>
>>> While having individual files for the different types of boundary
>>> conditions may not be the most elegant way, our approach has
>>> its advantages.  First of all, it doesn't rely on anything special
>>> in the grid interface.  More importantly, my boundary conditions
>>> need not be resolved by the macro grid boundary.  Sometimes that
>>> is very useful.
>>>
>>> best,
>>> Oliver
>>>
>>> Am 20.04.2012 20:02, schrieb Patrick Leidenberger:
>>>> Hi Oliver,
>>>>
>>>> in your comment about the boundaryId you wrote that you have a good
>>>> solution how to handle different boundary condition:
>>>>
>>>> On 04/18/2012 06:45 PM, Oliver Sander wrote:
>>>>> I am a bit surprised
>>>>> that so many people use boundaryId given that I have personally
>>>>> never had to use one of these methods, even though some of my problems
>>>>> have quite complicated boundary conditions.
>>>>
>>>> Can you please enlight me, how you handle them? I use the boundaryId in
>>>> my code, but I am always open for new ideas.
>>>>
>>>> Best regards
>>>>
>>>> Patrick

-- 
----------------------------------------------------------------------
Dr. Carsten Gräser       | phone: +49-30 / 838-75349
Freie Universität Berlin | fax  : +49-30 / 838-54977
Institut für Mathematik  | email: graeser at math.fu-berlin.de
Arnimallee 6             |
14195 Berlin, Germany    | URL  : http://page.mi.fu-berlin.de/graeser
----------------------------------------------------------------------