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

[Oliver Sander]

Hi,

> 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.

> * 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.

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
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune