[dune-functions] Binding to non-leaf entities in dune-functions 2.6

[Carsten Gräser]

Am 20.11.18 um 22:22 schrieb Simon Praetorius:
> Thanks a lot for the hint. I was aware of the MR but did not yet had the
> time to look at it more closely. Some points you have mentioned in the
> comments and below will make it really hard for me to use it, though, in
> a framework. For example, I need to store the basis creator/factory in
> order create a persistentBasis.
That's one of the reasons why it's not a ready to use solution.
From a user perspective one would like something like

  auto persistentBasis = rebindBasis(basis, persistentGridView);

which 'rebinds' (in the sense of allocators) an existing basis
to a different grid view. This could probably be achieved by
adding a corresponding method to the PreBasis interface. But
I hesitate to extend the interface for a partial solution that
does not cover coarsening.

Best,
Carsten

> 
> But I will think about this. Maybe I can adopt some ideas of the MR to
> build something similar for my purposes.
> 
> Simon
> 
> Am 20.11.18 um 16:07 schrieb Carsten Gräser:
>> For the record: The discussion mostly concerns grid
>> coarsening. If you only refine the problem is different.
>> In this case the elements still exist, but you cannot
>> use the old basis after refinement because the grid
>> view and the index set changed. This problem is mostly
>> solved by the WIP merge request
>>
>>   
>> https://gitlab.dune-project.org/staging/dune-functions/merge_requests/128
>>
>> which allows to get a persistent version of the
>> basis that survives grid refinement. This one
>> can be used to interpolate on the new grid.
>>
>> However there's some open problems/restrictions:
>> a)It only works for grids that do not remove
>>    closures on refinement. This leads to the
>>    coarsening problem again.
>> b)It requires that the basis only uses the index set
>>    of the grid view. This should be true for most
>>    bases.
>> c)It does not work straight ahead if the basis
>>    stores additional information e.g. in the case
>>    of p-refinement. This can be solved by either
>>    manually copying/sharing the information to
>>    the new basis or by introducing an additional
>>    interface/constructor for this purpose.
>>
>> That being said, the branch is successfully used
>> for refinement with hp-adaptive DG elements.
>>
>> Best,
>> Carsten
>>
>> Am 20.11.18 um 17:32 schrieb Carsten Gräser:
>>> Dear Simon,
>>>
>>> Am 20.11.18 um 15:00 schrieb Simon Praetorius:
>>>> Hi Carsten,
>>>>
>>>> In you explanation, you explained why a LocalView is not bindable to an
>>>> element that is not part of the GridView of the basis. That makes
>>>> perfectly sense. Also, there are some Basis implementations, like
>>>> BSplineBasis, that call gridView functions in the bind(Element) method
>>>> of the BasisNode, so in general it can not be bound to a non-GridView
>>>> element, you are right.
>>> that's exactly why using a basis like this leads to
>>> undefined behavior.
>>>
>>>> Creating a LocalFiniteElement, on the other hand, should be independent
>>>> of the GridView, since the dune-localfunctions module does not know
>>>> anything about a GridView at all. This is what you need in grid
>>>> adaption
>>>> and this is the way the discretization modules, like dune-pdelabs,
>>>> implement some adaption routines. You do not need the full LocalView,
>>>> you just need the LocalFiniteElement.
>>> I didn't say that you cannot create the LocalFiniteElement(LFE),
>>> because you're free to create them using dune-localfunctions'
>>> interfaces. However, there's no interface in dune-functions
>>> for the creation of isolated LFEs. You can try to abuse a
>>> local tree to do so, but there's no guarantee that the result
>>> is what you're looking for. That's the case for two reasons:
>>>
>>> * It's not specified in the interface what the result is.
>>> * There's no single natural way to specify the result.
>>>    Instead there's several possibilities of what a user
>>>    may expect:
>>>
>>> a)A LFE that is the exact restriction of the fine LFEs
>>>    to coarse element.
>>> b)A LFE that is the restriction of the fine LFE to the
>>>    coarse element up to the father->son domain deformation.
>>> c)A LFE that looks like the one you would get if you
>>>    define the same global basis on a grid view containing
>>>    this element.
>>> d)The LFE of the target space that you would like interpolate
>>>    to after adaptation.
>>>
>>>> The problem is now: How do I get the LocalFiniteElement associated to a
>>>> GlobalBasis (Leaf-)Node. Since there is no general factory for
>>>> finiteElements, like the PQkLocalFiniteElementCache in Lagrange nodes,
>>>> or the RaviartThomasLocalFiniteElementMap for the ravier thomas nodes,
>>>> and the FiniteElement type alone does not allow the construction, I
>>>> need
>>>> to get it somewhere. Either I write an own factory that gets a global
>>>> basis and walk through the basis nodes and extracts the FiniteElement
>>>> type and then manually associate to each type a factory or I need
>>>> something to get this from the node itself, since there all the
>>>> factories are already encoded but not accessible.
>>>>
>>>> The BSplineBasis is somehow special, since the LocalFiniteElement is
>>>> parametrized with the GridView.
>>>>
>>>> Any idea how to get a local finite-element otherwise?
>>> As outlined above the problem is that it's not clear what
>>> you expect. From your arguments I guess that you're aiming
>>> at c). Unfortunately it's hard to define this for a general
>>> basis. For example this is not defined for BSplineBasis and
>>> bases with dynamic local order p. For PQk one might argue
>>> that there's a natural definition. But in fact this may already
>>> fail for k>2 because the exact variant/permutation of the LFE
>>> is an implementation detail which may (or may not) depend
>>> on global information of the grid view. Also c) is not very
>>> helpful if you want to interpolate into another basis.
>>>
>>> Regarding the other options:
>>> a)It probably not what you want and hard to implement.
>>> b)Would allow to keep all information in a reasonable way
>>>    but is also hard to implement.
>>> d)Is the generalization of c) to the cases where c) fails,
>>>    but it obviously depends on additional user-information.
>>>
>>> In my opinion a true solution would do something along
>>> the line of b). However I'd not represent this as LFE
>>> but as a function. Then you can interpolate into whatever
>>> basis you're interested in after adapting the grid.
>>>
>>> As long as something like this is not specified and implemented
>>> you could also use dune-localfunctions directly for the PQ1/PQ2
>>> case.
>>>
>>> Alternatively you can follow the approach you proposed, because
>>> PQk currently does c). However you should be aware that there's
>>> no guarantees and that this may change and brake your code at
>>> any time.
>>>
>>> Best,
>>> Carsten


-- 
Prof. Dr. Carsten Gräser
Freie Universität Berlin
Institut für Mathematik
Arnimallee 6
14195 Berlin, Germany
phone: +49 30 838 72637
fax  : +49 30 838 472637
email: graeser at mi.fu-berlin.de
URL  : http://page.mi.fu-berlin.de/graeser

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20181120/35b976ab/attachment.sig>