Merge branch 'check-analytic-derivative' into 'master'

See merge request [!223]

  [!223]: Nonestaging/dune-functions/merge_requests/223

Merge branch 'feature/localview-bound' into 'master'

ref:staging/dune-functions This avoids instantiating a not-bound-to element
(which else needs to have a trivial/default constructor). Furthermore it
provides easy means to find out if we are in bound state.

See merge request [!186]

  [!186]: gitlab.dune-project.org/staging/dune-functions/merge_requests/186

Merge branch 'feature/cleanup-cmake' into 'master'

See merge request [!220]

  [!220]: Nonestaging/dune-functions/merge_requests/220

- require CMake 3.1
- use current code to use dune-common from dune-geometry
- drop cmake/module as it has no module-specific code

Merge branch 'feature/fix-headercheck' into 'master'

See merge request [!219]

  [!219]: Nonestaging/dune-functions/merge_requests/219

Merge branch 'feature/generic_lagrange_basis' into 'master'

ref:staging/dune-functions

### Summary

This MR adds a template parameter to the LagrangePreBasis, for setting the
local-basis range type.

### Details

Following a discussion in issue [#44] , the lagrange basis was fixed to range
type double for the PQkLocalFiniteElement. This is resolved with this MR, by
adding the range template parameter. It is defaulted to double so that no
changes in user code should be necessary, especially when you only use the
generator function lagrange<k>() or lagrange(k).

The range type is added as last template parameter to the pre-basis, node, and
node-indexset.

### Example:

    // compile-time order
    auto basis0 = makeBasis(gridView, lagrange<k>()); // range type = double
    auto basis1 = makeBasis(gridView, lagrange<k, float>());

    // run-time order
    auto basis2 = makeBasis(gridView, lagrange(k)); // range type = double
    auto basis3 = makeBasis(gridView, lagrange<float>(k));

See merge request [!212]

  [#44]: gitlab.dune-project.org/NoneNone/issues/44
  [!212]: gitlab.dune-project.org/staging/dune-functions/merge_requests/212

Merge branch 'use-latexmk-dependency-tracking' into 'master'

ref:staging/dune-functions dune-common switched to UseLatexMk.cmake, which
exploits the dependency tracking of latexmk. Let's use this for the
dune-functions manuals, because it allows to vastly shorten the CMakelists.txt
file.

See merge request [!215]

  [!215]: gitlab.dune-project.org/staging/dune-functions/merge_requests/215

dune-common switched to UseLatexMk.cmake, which exploits
the dependency tracking of latexmk.  Let's use this for
the dune-functions manuals, because it allows to vastly
shorten the CMakelists.txt file.

Merge branch 'issue/subprebasis_this' into 'master'

ref:staging/dune-functions

### Summary

Adds the pointer this-> when calling subPreBasis(i) inside of lambdas.

### Details

The recently introduced function subPreBasis(i) that returns the i'th
subPreBasis is used in lambdas without the this-> pointer. This is fine in
recent compilers, but fails in gcc6.

### Discussion

Maybe one should add a test for older compilers in the ci system, to catch
such bugs.

See merge request [!213]

  [!213]: gitlab.dune-project.org/staging/dune-functions/merge_requests/213

Merge branch 'bug/allow-wrapping-of-nondifferentiable-functions' into 'master'

ref:staging/dune-functions This MR makes it possible to omit the derivatives
from a grid function and its local function and still wrap it in a
GridFunction. This really simplifies life for people who want to do custom
stuff in their local functions, as getting the derivative functions right is
non-trivial (you have to make them return the interface types of the
polymorphic wrapper).

Fixes [#43]

See merge request [!208]

  [#43]: gitlab.dune-project.org/NoneNone/issues/43
  [!208]: gitlab.dune-project.org/staging/dune-functions/merge_requests/208


Closes #43

Merge branch 'feature/expose-subprebases' into 'master'

ref:staging/dune-functions Expose the sub pre-bases stored in a PowerPreBasis
and CompositePreBasis this is needed if you have to access specific
implementation defined properties. Notice that this does not extend the global
basis interface, because the (power/composite-) prebasis is only reachable
using DefaultGLobalBasis::preBasis() which is an interface extension itself.

See merge request [!209]

  [!209]: gitlab.dune-project.org/staging/dune-functions/merge_requests/209

This is needed to calm down gcc 5 and gcc 6.

Merge branch 'issue/lagrange_inline' into 'master'

ref:staging/dune-functions

### Bug

Missing inline keyword for runtime-order lagrange creator function
lagrange(int). Leads to multiple definitions of the symbol.

**NOTE:** This Bug is also resolved by [!212] where the runtime-order lagrange
function is templetaized and thus automatically inline.

See merge request [!211]

  [!212]: gitlab.dune-project.org/NoneNone/merge_requests/212
  [!211]: gitlab.dune-project.org/staging/dune-functions/merge_requests/211

Merge branch 'feature/avoid-warnings' into 'master'

ref:staging/dune-functions Fix some 'unused' and 'maybe uninitialized'
warnings.

See merge request [!210]

  [!210]: gitlab.dune-project.org/staging/dune-functions/merge_requests/210

This also allows to simplify some code.

By exposing this publicly, we can make the subPreBasis_
member private.

Merge branch 'lagrangebasis-with-runtime-order' into 'master'

ref:staging/dune-functions This MR extends the LagrangeBasis class to also
allow to select the polynomial order at run-time. For this, the integer
template parameter 'k' (the order) is made optional, with a default value of
-1. If k is explicitly set to something non-negative, then the basis
implementation behaves as before. If k is indeed -1 then the basis object
needs to be constructed by a new constructor that accepts a run-time order.

The changes to LagrangeBasis are completely backward-compatible. I did not do
any measurements of the performance, but as the switch between run-time and
compile-time order is based on a simple compile-time criterion I expect decent
compilers to optimize away all new code if a compile-time order is selected.

See merge request [!200]

  [!200]: gitlab.dune-project.org/staging/dune-functions/merge_requests/200

This patch changes the LocalFunction and GridFunction wrappers to accept wrapped
objects that are not differentiable, as they were supposed to according to their
documentation.

This patch splits the concepts LocalFunction, GridFunction and GridViewFunction
by removing the differentiability requirement from the existing concepts and
introducing DifferentiableLocalFunction, DifferentialGridFunction and
DifferentialGridViewFunction, which extends the existing concepts and re-add the
differentiability requirement.

The patch also adds corresponding compile-time functions for checking the new
concepts.

Merge branch 'feature/improve-poisson-pq2-example' into 'master'

ref:staging/dune-functions This introduces several improvements to the
poisson-pq2 example:

-   Demonstrate usage of mixed grids if UGGrid is available. While there's no
    reason to use a mixed grid here, we should imho demonstrate that it simply
    works. This is done conditionally using HAVE_UG. However, we strictly
    speaking already depend on dune-uggrid, because it's used unconditionally
    in the tests.
-   Use symmetrized approach to incorporate Dirichlet data. While CG works on
    the non-symmetric approach to (because it stays in an appropriate
    subspace) it's unclear if this is still the case in the presence of a
    preconditioner (see below).
-   Use ILDL instead of ILU preconditioner. Since we use CG, the
    preconditioner should be s.p.d.. In fact it turnes out that ILDL and ILU
    generate exactly the same results once the problem is symmetrized (see
    above). However, we should still use ILDL since the ILU documentation does
    not guarantee this.
-   It turnes out that using ILDL/ILU for the properly symmetrized problem is
    much better that the old method (which was beyond any theory anyway).

See merge request [!207]

  [!207]: gitlab.dune-project.org/staging/dune-functions/merge_requests/207

This introduces several improvements to the poisson-pq2 example:
* Demonstrate usage of mixed grids if `UGGrid` is available.
  While there's no reason to use a mixed grid here, we should
  imho demonstrate that it simply works.
  This is done conditionally using `HAVE_UG`. However, we strictly
  speaking already depend on `dune-uggrid`, because it's used
  unconditionally in the tests.
* Use symmetrized approach to incorporate Dirichlet data. While
  CG works on the non-symmetric approach to (because it stays
  in an appropriate subspace) it's unclear if this is still
  the case in the presence of a preconditioner (see below).
* Use ILDL instead of ILU preconditioner. Since we use CG,
  the preconditioner should be s.p.d.. In fact it turnes out
  that ILDL and ILU generate exactly the same results once
  the problem is symmetrized (see above). However, we should
  still use ILDL since the ILU documentation does not guarantee
  this.
* It turnes out that using ILDL/ILU for the properly symmetrized
  problem is much better that the old method (which was beyond
  any theory anyway).

Merge branch 'feature/modernize-cmake-file' into 'master'

ref:staging/dune-functions Replace target_link_dune_default_libraries(target)
by the modern dune_target_enable_all_packages(target). The problem with the
former is, that it does not append definitions, such that we cannot use UGGrid
because ENABLE_UG is not defined. Surprisingly this is in contrast to
dune_add_test(...) which does add the definitions.

Alternatively we could call dune_enable_all_packages() in our root
CMakeLists.txt, but I'm unsure about the implications.

Notice that this reveals several open questions regarding dune-common:

-   Should target_link_dune_default_libraries() still be used or should it be
    deprecated in favour of dune_target_enable_all_packages()?
-   Should the src/ example created by duneproject still call
    target_link_dune_default_libraries() altough dune_enable_all_packages() is
    called by default?
-   Should the call to add_dune_all_flags() in dune_add_test() be replaced by
    dune_target_enable_all_packages() such that tests are build similarly to
    normal executables?
-   Should a library module (like, e.g. dune-functions) use
    dune_enable_all_packages()? Or is this discouraged, because it has to be
    used in all derived modules?
-   Do we allow building anything without using one of the add-all-flags
    approaches at all? In view of possible binary incompatibility it looks
    like "All tests use it" implies "All libraries have to use it" which
    implies "All applications have to use it"

See merge request [!206]

  [!206]: gitlab.dune-project.org/staging/dune-functions/merge_requests/206

Replace `target_link_dune_default_libraries(target)` by the
modern `dune_target_enable_all_packages(target)`. The problem
with the former is, that it does not append definitions, such
that we cannot use `UGGrid` because `ENABLE_UG` is not defined.
Surprisingly this is in contrast to `dune_add_test(...)` which
does add the definitions.

Alternatively we could call `dune_enable_all_packages()` in
our root `CMakeLists.txt`, but I'm unsure about the implications.

Notice that this reveals several open questions regarding dune-common:

* Should `target_link_dune_default_libraries()` still be used
  or should it be deprecated in favour of `dune_target_enable_all_packages()`?
* Should the `src/` example created by `duneproject` still call
  `target_link_dune_default_libraries()` altough
  `dune_enable_all_packages()` is called by default?
* Should the call to `add_dune_all_flags()` in `dune_add_test()`
  be replaced by `dune_target_enable_all_packages()` such that
  tests are build similarly to normal executables?
* Should a library module (like, e.g. dune-functions) use
  `dune_enable_all_packages()`? Or is this discouraged,
  because it has to be used in all derived modules?
* Do we allow building anything without using one of the
  add-all-flags approaches at all?
  In view of possible binary incompatibility it looks like
  "All tests use it" implies "All libraries have to use it"
  which implies "All applications have to use it"

Merge branch 'test-interpolate-with-vector-of-bool' into 'master'

ref:staging/dune-functions This uncovers a bug, which is also fixed by this
merge request.

See merge request [staging/dune-functions!204]

  [staging/dune-functions!204]: gitlab.dune-project.org/staging/dune-functions/merge_requests/204

Carsten Gräser authored Mar 20, 2019 and Oliver Sander committed Mar 28, 2019

We need to be careful with perfect forwarding and lambdas.
This should work using the new forwardCapture() utility.

Carsten Gräser authored Mar 20, 2019 and Oliver Sander committed Mar 28, 2019

This allows to combine perfect forwarding and lambda captures.

It compiles and runs, but valgrind reports errors.

Merge branch 'feature/check-field-types' into 'master'

ref:staging/dune-functions This now checks if the provided container provides
a unique field type and fails with a nice static_assert message if this is not
the case. Hence you get much better diagnostic messages, if this is not the
case. E.g.

    using VelocityBitVector = std::vector<std::array<bool,dim> >;
    using PressureBitVector = std::vector<bool>;
    using BitVectorType = TupleVector<VelocityBitVector, PressureBitVector>;
    auto v = BitVectorType{};
    auto vBackend = Functions::istlVectorBackend(v);

will now fail with a nice error message because there's two different field
types here: plain bool and the proxy-reference of std::vector<bool>.
Unfortunately you cannot pass more data to the static_assert, not even
constexpr functions are allowed. But you can trick the compiler to see the
list of field types:

    auto fieldTypeList = Dune::Functions::fieldTypes<BitVectorType>();
    Dune::UnpackTypeList_t<std::tuple, decltype(fieldTypeList)>::printError();

See merge request [staging/dune-functions!205]

  [staging/dune-functions!205]: gitlab.dune-project.org/staging/dune-functions/merge_requests/205