[dune-fem] [bewilderment resolved] Re: Design of boundary classification, e.g. fem-poisson in school code
Martin Nolte
nolte at mathematik.uni-freiburg.de
Wed Mar 19 14:11:26 CET 2014
Hi Claus,
while the idea sounds intriguingly simple, the true problems lie in the
parallel part, as Robert already hinted. You have to ensure that the
boundaryIds are transferred correctly during load balancing. In my opinion,
the problem will to twofold:
(a) Your singleton must automatically be included in the load balancing
process (and do the "right" thing, of course).
(b) The grid implementations (read: ALUGrid) must support this concept in
parallel.
In my opinion, (a) is relatively straight forward (if you properly test it).
However, (b) seems less trivial to me (unless Robert already implemented this
stuff). To my knowledge, the problem is that ALUGrid will start extracting
data before all elements have been created. So, the number of (local) boundary
segments might not be known at this point. In other words, the boundary ids
would need to be stored in a map, using the id of the corresponding codim-1
entity as a key.
<SIDE ISSUE>
Similiar problems arise for (non-global) boundary projections in parallel (I
think they were called node-projections in Alberta). Of course, this problem
can also by solved by attaching the boundary projections to the boundaryId
(though I would prefer the segmennt index) and using a callback mechanism
during adaptation (which would be my solution to this issue).
</SIDE ISSUE>
Best,
Martin
On 03/19/2014 01:42 PM, Claus-Justus Heine wrote:
> -----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-----
>
> _______________________________________________
> dune-fem mailing list
> dune-fem at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-fem
>
--
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>
Universität Freiburg phone: +49-761-203-5630
Abteilung für angewandte Mathematik fax: +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany
More information about the dune-fem
mailing list