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

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

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