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

[Carsten Gräser]

Hi Oliver,
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).

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

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