[dune-fem] [bewilderment resolved] Re: Design of boundary classification, e.g. fem-poisson in school code

[Claus-Justus Heine]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

to bring this message-thread to a positive end: I somehow got the
expression that with the removal of intersection.boundaryId() the access
to any boundary classification in the macro triangulation had been
abandoned altogether. That really felt even insane.

Its only tonight that I realize that this is not the case, as currently
the boundaryId and -Parameters are very well still accessible through
the GridFactory, and at least the BoundaryParameters also through the
GridPtr (it appear from reading the source code that it was somehow
forgotten to export the BoundaryId also from the GridPtr. Martin is
alread working on that, AFAIK.)

In so far, removing the method from the interface may very well be
understood as interface-cleanup, though it is somewhat inconvenient. As
boundary-ids are often needed, one would probably want to have a
standard-way to access them, something like the BoundaryIdProvider
mentioned below by Tobias, but probably rather using the
boundarySegmentIndex() instead of enabling experimental-grid-extensions.

Best,

Claus

On 16.01.2014 10:20, Tobias Malkmus wrote:
> Hi all
> 
> You can find a BoundaryIdProvider in dune/fem/misc/boundaryidprovider.hh
> 
>     template< class Grid >
>     struct BoundaryIdProvider;
> 
> But you will need set the "experimental-grid-extensions" flag, since you
> will need to have access to the grid implementation.
> 
> Switching to the boundarySegmentIndex() method of the intersections is
> still an open task.Enigmail
> 
> Best Tobias
> 
> 
> On 01/16/2014 09:12 AM, Andreas Dedner wrote:
>> Hi.
>> I agree that this is not optimal - we should think of an option to
>> extract
>> boundary id information from the macro grid file and store it somehow.
>> Perhaps a Singleton object BoundaryIdProvider or
>> perhaps a method on the GridPart::boundaryId(intersection)
>> would do. I don't think using global coordinates is a viable solution....
>> Best
>> Andreas
>>
>> On 14.01.2014 15:37, Claus-Justus Heine wrote:
>>> Hi,
>>>
>>> now that the boundaryId() method has been removed from the dune-grid
>>> interface (... unless BLAH_EXPERIMENTAL ...) one in principle has only
>>> the geometry itself to decide whether a given boundary facet belongs
>>> to a specific part of the boundary. If I then think of the layout of
>>> the example implementation of fem-poisson in the school-code, for
>>> example, then we have (simplified) the following way to construct the
>>> final algorithm
>>>
>>> problem -> model -> fem-scheme -> algorithm
>>>
>>> If now the model has no other chance than to look at the geometry to
>>> assign suitable boundary conditions, then the model must have some
>>> knowledge about the computational domain. This seems to be somewhat
>>> inconvenient: when changing the macro triangulation (e.g. make it
>>> twice as large or whatever) then one also has to adjust the model. At
>>> least to me this seems to suggest that the definition of the
>>> computational domain should be part of the model. Defining the macro
>>> triangulation in the parameter file does not seem to fit this layout.
>>>
>>> Cheers,
>>>
>>> Claus
>>>
>>>
>>>
>>>
>>>
>>>
>>  > _______________________________________________
>>  > dune-fem mailing list
>>  > dune-fem at dune-project.org
>>  > http://lists.dune-project.org/mailman/listinfo/dune-fem
>>
>>
>>
>>
>> _______________________________________________
>> dune-fem mailing list
>> dune-fem at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-fem
>>
> 
> 


- -- 
Dr. Claus-Justus Heine
Institut für Angewandte Analysis und Simulation
* Numerische Mathematik für Höchstleistungsrechner
Universität Stuttgart

Fon: +49 (0) 711 - 685 65558
Fax: +49 (0) 711 - 685 65507
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTKLOpAAoJEAbZWiFWzP01fR8P/jaN33pon2ZI6VUGZ+C+3uVF
vs+sn6RmUoBjJRk7ZmYHzrf8FGDwZ3OXRlwOf9fDvdiQzEOywC7UA+jFe4ddmk87
g+fMaarWwkz7CfloPtolpcxwBpUf7h7mYNZnyQETpr7laLbC/sw5/4QNCEPVhE6U
Vkn7OT5C8qqnHA8IOrQsU7ZqhkK1b6rthJXSgY5SXzjq/6qGAOtWif9SxdWTGptB
gMEm+fvmEUSXea8m+UJXB5abZoPcgXebXhZ5hXOUAkjPg7dsbpaVCuKGHxAj7A5C
dbB/LaVLYI2AVgg+6Sh/rhC/sGjA51PBpbIfqYWeibUMbWPz4cqYublvRuaOWfGN
4RoOrPx+fdKMYCINTUCES7euwQ9Rpx5C34xX9SQ3rPVYrdLEVIMc5dSgT0txNC0l
g4fRkVhlLtCgSRPFmRjFL3OdnM1TwxEJtzXUAGa6OIqAY84PW8AUkV4z/kXwQiBF
dWMMdS/+XXO7BJ/S4nPib2P6KpBtKULA6mP5wo+GPjBpT0/1i9Cpva2d+21rbaNM
HFf3fGLXutA9P0/dZwJRXs5PbrKDouZ2PuDJu+VqtaPsyd6XYCyBkgXs8K72iEyT
a8cI7xUL+ZpjvloO3qhihaa1SONzRvd+p+Vou83VFqX+LOx7W/aYNXfbF/K5Pkxd
ZuhgLniJbqbpi9EtBQki
=eIRP
-----END PGP SIGNATURE-----