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

[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

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