Merge branch 'feature/require-cmake-3.13' into 'master'

See merge request [!166]

  [!166]: Nonecore/dune-localfunctions/merge_requests/166

Merge branch 'feature/remove-add-doc-install' into 'master'

ref:core/dune-localfunctions\> Since the move to UseLatexMk installation is
completely handled by the dune_add_latex_document call and this function call
is superfluous or might even break installation.

@gruenich I am backporting this to the 2.7 release branch because it breaks my
experiments with the Spack package manager, where I need to heavily rely on
correct installations.

See merge request [!164]

  [!164]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/164

Since the move to UseLatexMk installation is completely handled
by the dune_add_latex_document call and this function call is
superfluous or might even break installation.

Merge branch 'issue/using_std_abs' into 'master'

ref:core/dune-localfunctions\>

### Summary

Replace explicit namespace qualification by using directive for std::abs

See merge request [!161]

  [!161]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/161

Merge branch 'feature/avoid-dune-common-function' into 'master'

ref:core/dune-localfunctions\> This removed all uses of the old interface in
dune-localfunctions. Here's a list of all changes. The one with potential
influence to users are bold:

-   Stop using VirtualFunction in LocalFiniteElementVirtualInterface and
    replace it by std:function. Strictly speaking this is an interface change.
    Implications of this change:
    -   You can still pass a function providing the old interface to
        interpolate(). It will still be wrapped automatically.
    -   The virtual wrapper LocalFiniteElementVirtualImp still works, but
        **from now on the virtual wrapper assumes that the wrapped LFE
        supports passing functions with operator()**.
    -   If you derived from the virtual interface class (instead of using
        `LocalFiniteElementVirtualImp') you have to be careful to switch the function type if you did not extract it from the interface class by using the `FunctionType\`
        typedef.
-   Deprecate LocalFiniteElementFunctionBase and now **exports a dummy base
    class** to keep it working during the deprecation period.
-   Avoid deprecated function base classes in tests
-   Use operator() function interface in internal helper ComponentEvaluator.
-   Remove internal helpers for creating old style function classes

See merge request [!159]

  [!159]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/159

By deprecating the generation of the old-to-new-interface
wrapper we issue a warning whenever an old style function
is used. To avoid warnings in checks of the deprecated
interface the deprecation is disabled by defining the
flag `DUNE_DEPRECATED_INTERPOLATE_CHECK=1` for
`dune/localfunctions/test`.

To still test the deprecated `evaluate()` based interface,
the functions passed to `interpolate()` just mimic the
old behaviour without deriving from the old base classes.

This class was needed to determine the base class to be used
for functions passing to `interpolate()`. Now we can simple
pass a callable object and type erasure in the virtual interface
is done using `std::function`.
Passing functions with the old interface providing an
`evaluate(x,y)` method is still possible using a wrapper.

To keep code using `LocalFiniteElementFunctionBase` working
during its deprecation, it exports a dummy base class which
is a look-a-like of the old `Dune::Function` base class.
This allows to no longer rely on the deprecated `Dune::Function`
class even during the deprecation period of
`LocalFiniteElementFunctionBase`.

This patch replaces `VirtualFunction` by `std:function` in the
virtual interface `LocalFiniteElementVirtualInterface`. Strictly
speaking this is an interface change. Implications of this change:

* You can still pass a function providing the old interface to
  `interpolate()`. It will still be wrapped automatically.
* The virtual wrapper `LocalFiniteElementVirtualImp` still works,
  but from now on it assumes that the wrapped LFE supports
  passing functions with `operator()`.
* If you derived from the virtual interface class (instead of using
  `LocalFiniteElementVirtualImp') you have to be careful
  to switch the function type if you did not extract
  it from the iterface class by using the `FunctionType` typedef.

Merge branch 'feature/update-std-utility' into 'master'

ref:core/dune-localfunctions\> This replaces all Dune::Std:: stuff in
dune/std//utility.hh by its corresponing std:: analogue in utility

See merge request [!158]

  [!158]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/158

This replaces all `Dune::Std::` stuff in `dune/std//utility.hh`
by its corresponing `std::` analogue in `utility`

Merge branch 'feature/use-std-variant' into 'master'

See merge request [!157]

  [!157]: Nonecore/dune-localfunctions/merge_requests/157

Merge branch 'lisa-shape-function-fix' into 'master'

ref:core/dune-localfunctions\> One of the shape functions of the second-order
Lagrange element for pyramids was implemented wrongly, and the derivative
along with it. This went unnoticed for a long time, until it was noticed that
the element was not able to represent constant functions.

See merge request [!155]

  [!155]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/155

One of the shape functions of the second-order Lagrange element for
pyramids was implemented wrongly, and the derivative along with it.
This went unnoticed for a long time, until I saw that the element
was not able to represent constant functions.

Merge branch 'improve-pyramid-testing' into 'master'

ref:core/dune-localfunctions\> This MR adds two new tests for Lagrange finite
elements

-   Testing the derivative even if it is only piecwise differentiable
-   Testing whether all shape functions sum up to 1.

See merge request [!153]

  [!153]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/153

This patch adds a new test that checks whether the functions space
spanned by the shape functions includes the constant functions.
This holds for all finite elements we currently implement.

This test can be disabled by setting DisableRepresentConstants.

The patch does disable the new test for the second order
Lagrange finite elements on the pyramid element, because
that one is apparently buggy.  A fix will come in a separate commit.

There are finite element shape functions that are only piecewise
differentiable.  One example are the Lagrange shape functions
for pyramid elements, which are nondifferentiable on the plane
where x[0]==x[1].  Previously, the derivative tests where skipped
entirely for such elements.

This patch adds the infrastructure to skip individual test points
instead when testing derivatives.  This allows to test the
derivates where they are defined.  The points to skip are
specified by a predicate class that receives a point position
in the reference element, and returns 'true' if that point
is to be skipped.

This patch also uses the new infrastructure to enable the tests
for the derivatives of pyramidal Lagrange functions.

Merge branch 'document-pyramid-lfe' into 'master'

ref:core/dune-localfunctions\> These elements are nontrivial, and need some
documentation.

Fixes [#3]

See merge request [!151]

  [#3]: gitlab.dune-project.org/NoneNone/issues/3
  [!151]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/151


Closes #3

These elements are nontrivial, and need some documentation.

Fixes #3

Merge branch 'add_using_std_sqrt_directives' into 'master'

ref:core/dune-localfunctions\> This MR adds `using std::sqrt` directives. This
is needed because Dune::sqrt is probably found before std::sqrt.

See merge request [!149]

  [!149]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/149

Merge branch 'fix/missing-author' into 'master'

See merge request [!147]

  [!147]: Nonecore/dune-localfunctions/merge_requests/147

Merge branch 'feature/bdfm-spaces' into 'master'

ref:core/dune-localfunctions The coefficients and interpolation are
implemented for arbitrary dimension (\>1) and order (\>0). The actual basis is
only implemented for dim =2 and order=1,2,3.

The basis was calculated with [base.py]

##### Note:

this MR depends on [dune-common!471] for binomial(...)

##### Note to the interpolation:

The unrank(...) algorithm and its inverse rank(...) (not implemeted here)
might be better moved into [dune-common!471].

The split into trace and interior interpolation is the interface that I
actually need for my code.

See merge request [!105]

  [base.py]: /uploads/79e53ef938abe294040b9fb4404d05f3/base.py
  [dune-common!471]: gitlab.dune-project.org/Nonedune-common/merge_requests/471
  [!105]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/105

Merge branch 'feature/bump-to-2.8' into 'master'

See merge request [!146]

  [!146]: Nonecore/dune-localfunctions/merge_requests/146

3.8

Merge branch 'bugfix/returnSizeTinSizeAndOrderMethod2' into 'master'

ref:core/dune-localfunctions Correct the return type of the interface methods
size and order to return size_t instead of `unsigned int`

Also fix two unsigned int warnings

See merge request [!122]

  [!122]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/122

the default return type for `size` and `order` is std::size_t not `unsigned int` which was returned by
the `utility` based RT and Lagrange space