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

[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: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20181120/7039a8df/attachment.sig>