[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

Maybe one proposal which would live without
- --experimental-grid-extension but would provide boundary-ids and
boundary-parameters. AFAIK, the connection to that is available in a
convenient way only through the GridFactory and the GridPtr. Neither of
these have to be available at all. A quick way -- maybe a little bit
Cish -- would be some methods

GridPart::initBoundaryData()
GridPart::initBoundaryData(GridPtr)
GridPart::initBoundaryData(GridFactory)

which optionally allocate the needed lookup table, i.e. a std::vector
which is filled with 0, or initialized by the data provided by GridPtr
and GridFactory. Later,

GridPart::boundaryId(intersection)

could use that data. One probably could more or less naturally also
supply an additional method

GridPart::setBoundaryId(intersection)

for custom setups. Likewise with the boundary-parameters. Applications
which do not need boundary-ids would simply not use those methods and
the extra lookup-tables would not be allocated. I also suppose that more
would have to be done to support parallel setups.

As of now Dune::Fem + boundary-ids work nicely with
experiemtal-grid-extensions.

Cheers,

Claus

On 18.03.2014 21:59, Claus-Justus Heine wrote:
> 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
>>>
> 
> 
> 
> 
> 
> _______________________________________________
> 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/

iQIcBAEBAgAGBQJTKYLxAAoJEAbZWiFWzP01HSgP/0Lm0/ieDwEnSC7hJxLMKKx9
QvIQkLrWOX5VLLlltQyMByyNy1qpts9rdXO2GzE0LTaNlRa5iN060Trsup3mmCNB
zN3h75jOWXZo3NWEq2Gi0zccuNmSYqp4U6W238KsSveeRoVcyoDu7qaZcgC1b8fr
dGvQRCzwooEPVBFAjIgNueDH6/HFUktii08w0CMUSHYiA+hqHHe01cI2b3AJM1lE
0lzV3KNI6DRUAVvPE1k96p959bEv3vlxa9rFW6sew1CcAz5WbbPJMlK2m7G2p4RO
qCXfcBuRjQrjnEM3Rt6h2C930JL3CxjFaP794jB/h9IrIooggxTpfM0Y0DhZ0LR3
3B1R1hddKHvy8CXSuaaOX9WnlY+m3/QcX62hsKGCp8QGUjErE+coFnsbbKF50l36
PYKQl8AQjpagSjzNB+waX1fdUeppJGd553cNqMghFLodGxBQDGhU3WwmGZ0P1/bO
2gCnlcNdT++GhNv14IZa47qgvfSTzsbdb11JvUyOHuBOZRvNZkLc2wa3IFglzMza
qr7T7nJBmA1eJkAiz7KAaLLtt3T1h8Hx7BlbsUPyyTPcPnpoNrCLDGs0V6PAIa6/
Lfs6G4272OCTZUyKXB0dSYCapMCdWWdKCk3uGZF7ShPkoZv77JgJw0V1/Sg4jTyx
R22yMTdCy5CKwREb2QcP
=eOL+
-----END PGP SIGNATURE-----