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

Claus-Justus Heine Claus-Justus.Heine at IANS.Uni-Stuttgart.DE
Wed Mar 19 16:42:22 CET 2014 

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

Hi Martin,

Am 19.03.14 14:11, schrieb Martin Nolte:
> 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).

Yes.

> (b) The grid implementations (read: ALUGrid) must support this
> concept in parallel.

well, I suspect that things will get complicated. OTOH: one will need
something like this anyway. Or declare --experimental-grid-extensions
as being the solution ;)

> 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.

Well, you also mentioned some related FlySpray tasks in some other
email (FS#671, FS#684, FS#772) as well as some LBDataHandle and the
suggestion to distribute the boundarySegmemntIndexed data of whatever
kind through a map.

> <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>

I do not have any objections against indexing with the
boundarySegmentIndex(). As mentioned above, the load-balancing problem
- -- or maybe better: task -- is an issue with all data attached to the
boundary facets of the macro triangulation.

Best,

Claus



> 
> Best,
> 
> Martin
> 
> On 03/19/2014 01:42 PM, Claus-Justus Heine wrote: 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
> 
>> 
>> _______________________________________________ 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 v1.4.15 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTKbreAAoJEAbZWiFWzP01eCoQAOsXGa1K5RCMJRQmQ4oFy4X9
AN+yVNNXBvYwXQ8rViZeVu8YaX3TgD8ojD7HfQNQtEYRrhWk1yzBVx1PGfvwrKeP
XlQ0YKhbE5PMqAfuDCkwGorY7rCLrVvBjKHHwrMciC1kdL8Wi4vL0nOa4aF3ptCj
e/ZlB+EHJgeF+mOGENBn1SY/EJOL6g25aQkmtrBc8wYg0AA8V4m7oMc4iv/T+W6x
AD5QxhRNszxMyNbCriW5q3Bu0X5Ct8qBY/9kiNv+zkr6EaJD6MIoJV3kt12VNgZ6
0olJw6oSCLbq3d8eWP7w4kcRyJh8fuTxkusW38aAl2SV1U3MtL/0+3akm++zl7aU
zZkVPa5fgOSt9adYHAGgErrdIONjRLkowpHaTPHh/ksHTP1mnOF+eraE2wxMZNYl
tFUbcG1pRSb+/fB6ka04MVijCJxY0uvOPZLtYQ/xuPhQzBjNuSX923l/5LS6+kv1
3qTtP/FpFgSYFR6Sqcf08c6RPqgJj3ZwtF4s38I/K+8ByZ2p2zLEGvL/tjM2OxQD
GjgOViOadQyFBXoRhIovD7Re9hPJnOS9xzQqU7RcVGTLSQeV66kmh+KK5utQN4P0
+ahg0WsO2yN6NGPvhOtPP7a5BGf1QgA3b8ColGPr/hxRiZbrtTI5zp8DS3CzwhoE
oV/m+V+F/jISmH4+Qj1p
=iMNY
-----END PGP SIGNATURE-----

More information about the dune-fem mailing list