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

[Simon Praetorius]

Hi,

I'm currently looking for any reference (manual, comment, paper, 
documentation) about the requirements on the argument to bind(element) 
function in the basistree nodes. The argument type gives us no 
information, It is simply a codim<0> entity. The comments above the 
method just say "Bind to element.", not what the element is supposed to 
be. The dune-functions manual speaks about grid elements not 
LeafGridView elements. Maybe I have missed it.

I would love to see any more information about what is undefined 
behavior or what are the requirements on arguments to functions, either 
in the documentation of the functions, or as assert or something that is 
human readable and easy to find. This does not necessarily introduce a 
run-time overhead. One could, for example, adopt the c++20 contracts and 
put them in the comment section, something like

//! Bind to element.
// [[ expects: gridView().contains(e) ]]
// [[ ensures: bound() ]]
void bind(const Element& e);

//! Return whether the node is bound by \ref bind() to an element or not.
bool bound() const;

//! Return the LocalFiniteElement for the element we are bound to
// [[ expects: bound() ]]
const FiniteElement& finiteElement() const;

So that violations of the contracts are UB.

But, there is no base-class for BasisNodes that defines the interface. 
Maybe one could follow the style of other dune-modules and provide a 
documentation-only interface class.

Best,
Simon

Am 20.11.18 um 05:25 schrieb Carsten Gräser:
> Hi Simon,
>
> Am 20.11.18 um 07:27 schrieb Simon Praetorius:
> [...]
>> if you want to access the finiteElement() of a leaf basis node, you have
>> to bind it to an element, since, e.g. LagrangeNode uses a
>> FiniteElementCache that gives you a different FiniteElement depending on
>> the element type. Binding a TypeTree to an element could be done using
>> the free function `bindTree(tree, element)` from
>> dune/functions/functionspacebases/nodes.hh. But therefore you need a
>> mutable tree object. The LocalView gives you only a const& to the
>> TypeTree. An option would be to simply create a copy of the tree and
>> bind this copy to the element, i.e.
> please don't do this! Notice that bindTree() is not part of the
> user interface and the tree should not be copyable by the user.
>
>> The tree traversal does not require a bound tree, so you could also bind
>> the leaf node directly to an element, i.e.
> As described in my reply to Felix Müller this leads to undefined
> behavior. While the current implementation does give you some
> finite element, there's no guarantee on its type and it may
> as well terminate with an error or kill your kitten.
>
> Best,
> Carsten
>