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

Wed Mar 19 13:42:05 CET 2014

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

On 19.03.2014 13:07, Andreas Dedner wrote:
> 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

That would not matter, as the idea was not to store the GridPtr, but to
transfer the information provided by the GridPtr (i.e. the boundaryIds
on the macro-level) into a vector indexed by boundarySegmentIndex().

> achieved with a singleton
> BoundaryDescriptor class which in a similar way to the Parameter class
> can be filled

Still a singleton-per-HGrid is probably a better approach. Also, that
boundarySegmentIndex() is attached to the macro-grid of the underlying
hierarchical grid, so the GridPart is indeed the wrong structure to
attach that data to.

> 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

So maybe something like this

Dune::GridPtr<HGridType> gridPtr(gridfile);
Dune::Fem::BoundaryDataSingleton<HGridType>::setup(gridPtr);

Anyhow, when trying to go with the boundarySegmentIndex() the data
(boundary-ids, maybe boundaryParameters) has to be transferred (copied)
from the GridPtr to some lookup-tables from where the data is available
after the GridPtr has gone. As this functionality (access to boundary
ids) is rather common this stuff should be easy to use for "standard"
applications.

Of course, one could also shift the functionality to the problem
definitions at "model" level or something like this. But those are
rather constructed from grid-parts or even discrete function spaces.

I also suppose that someone trying to start to use dune-fem would
probably not start by configuring dune-grid with the experimental grid
extensions (which now is indeed a requirement). So some solution should
be found at some time. But I do not want to put too much stress on this
issue. Just started to think about this after I understood that access
to the boundary extra-data is still possible at all.

> 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

Auch so,

Claus

> 
> On 19/03/14 11:43, Claus-Justus Heine wrote:
> 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
>>
>> _______________________________________________
>> 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/

iQIcBAEBAgAGBQJTKZCdAAoJEAbZWiFWzP01f+oP/3E2LKKH2KK3wmEjr709DpTF
b/N4YFuUxHIRG6aXZA2XvWBGXWBJOt3c9Bi6J4DU4/yv6ofwHkOHx0BEuHkWMrpH
VJF9VINshU0ysjbsSiYNW/C3S3/wU3ZfsAoAl4OSxmkWx3KqxBK0k523rj4juxnq
h1oVEY5KVDizYBwWQAq757uSU9FMRM4Bgx2oxlL3kzjMjLOhu73SzwiWbYMlwW8U
eXWzXrPu9eUKrPkn60DQJVNtaZJdPGJSUZ/6ChuoeoPyr42NpLJNTlBXeLfWK23C
Z3oNyX8M6kpsDboLaKnMXRxgSMWYC1VLJ3NsvRAYW2eGUHiJpdTD7ecSP+AEjdtI
ZcX6ONMrcf1hZLKQbXLusub12OWmn/Wfte7ns0iuYZ982hZdHSZthCW5rNyVu5J1
naFKr/1f3eNBGR07hZDHHTEipbHiZ/+7W6MshgX1vzUoFMk4mjYp9v48MFgI4Stk
mlqVojLeFnrjKvbFeZZXa0HHUAe035coA15WFv7bC7BuiXFinLIWE28PcG/z28fK
VKMGyqSJvgtfjWDbrEUyDVIpTbAv+ov0182ahFcC2SbcfM9QLtwFvgSV7Rx/Thm/
f9ElZj2hENHTDsVOZlGeTS4F/J7xBVIQM7+KaorzidxZVMgAvPR52aD/Fpb90xCf
VBfn+H1XAVVlf6qhDP8t
=Wqxx
-----END PGP SIGNATURE-----