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

Wed Mar 19 13:07:24 CET 2014

I see a problem with this approach, or I did not understand
what you mean with GridPart::?

You can have many different gridparts generated all over the places in 
the code
while the grid pointer is only available until the grid has been 
generated (that even more
true for the GridFactory). I guess your approach would better be 
achieved with a singleton
BoundaryDescriptor class which in a similar way to the Parameter class 
can be filled
up during grid construction and is then available through the code. Its 
a bit like of
global variable of course and one would have to make it "Singleton per 
grid object" of
course so not quite like the Parameter class but possible and done in 
other places in dune-fem
(e.g. for the DofManager).

Best
Andreas

On 19/03/14 11:43, Claus-Justus Heine wrote:
> -----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-----
>
> _______________________________________________
> dune-fem mailing list
> dune-fem at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-fem