[dune-functions] TypeTree now works with dune-functions again

[Carsten Gräser]

Hi Steffen,

Am 15.09.2015 um 17:54 schrieb Steffen Müthing:
> Hi everyone,
> 
> I finally cleaned up the HybridTreePath stuff in dune-typetree (that escalated into something
> a little larger than expected…).
thanks a lot for cleaning this up and bringing dune-functions in line
with typetree again. I simply couldn't find this functionality, but
now everything seems to natural.

> There is now a HybridTreePath in TypeTree, which is a wrapper around std::tuple (I didn’t just
> alias or inherit for a number of reasons). I replaced all occurrences of Carsten’s interim implementation
> that I could find. When trying to compile everything, I noticed a surprising amount of breakage in our
> tests… is it just me, or do we have to start fighting the bitrot? ;-)
Regarding the failing test:

discretescalarglobalbasisfunctiontest:
This does not compile because it uses PQ2NodalBasis which was not
adapted since our meeting. Should we keep this or drop it in favour
of PQk... ?

functionfromcallabletest:
This and derivativecheck.hh have not been adapted since we dropped
the virtual interface. I'll have a look.

gridviewfunctionspacebasistest:
This does not compile because PQ2NodalBasis, LagrangeDGBasis, and
BSplineBasis have not been adapted. If these are commented, the test
compiles and fails because it calls testFE which fails for PrismP1,
as it would do in dune-localfunctions, if the test was not disabled.
There's also a bug-report for this.

taylorhoodbasistest:
This does not compile since your push. Same for the stokes-taylorhood
example. Could you have a look?

Best,
Carsten

> I also really liked Carsten’s idea of having an index_constant that’s a template alias for an
> integral_constant<std::size_t,…>, so I put that into TypeTree and started to use it extensively. There’s
> also a standard-compliant reimplementation of the integer_range and index_range functionality in
> Dune::TypeTree::Std (BTW, it’s *really* bad that we have something not quite correct in Dune::Std).
> 
> The pre-made index objects now live in Dune::TypeTree::Indices (I thought the „Static“ was a little redundant).
> I really like the idea of those constants and would like to see them in dune-common after the release of 2.4.
> 
> There is now a new API for accessing children in TypeTree: to get a child, just write
> 
> Dune::TypeTree::child(node,indices...);
> 
> Indices can be either a combination of std::size_t and index_constant, a TreePath (fully static) or a HybridTreePath.
> For convenience (to avoid having to qualify child() all the time), there are also new member functions, so you
> can also write
> 
> node.child(indices…);
> 
> Beware: Doing so is problematic in generic code that expects to call node.child(treePath) with an empty TreePath
> on a leaf node. That only works with the freestanding function - the member function cannot specify the correct
> return type in that case. So generic code (like the stuff in defaultnodetorangemap.hh) will have to use the freestanding
> functions.
> 
> The type of a child can be extracted using one of two template aliases:
> 
> using ChildType = Dune::TypeTree::Child<Node,0,3,_2>; // this accepts both integer literals and the predefined index_constants
> using ChildType = Dune::TypeTree::ChildForTreePath<Node,TreePath>; // the path can be either TreePath or HybridTreePath
> 
> I quite like the way it works now, but if you have any suggestions for improvements, shoot!
> 
> Steffen

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