1. 03 Dec, 2019 5 commits
  2. 30 Nov, 2019 3 commits
  3. 29 Nov, 2019 1 commit
  4. 27 Sep, 2019 1 commit
    • Simon Praetorius's avatar
      [!212] add template parameter for range type to lagrange basis · 885eeec7
      Simon Praetorius authored
      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
      885eeec7
  5. 07 Sep, 2019 1 commit
  6. 02 Sep, 2019 2 commits
    • Oliver Sander's avatar
      [!215] Use dependency tracking provided by UseLatexMk.cmake · 2e74addd
      Oliver Sander authored
      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
      2e74addd
    • Oliver Sander's avatar
      Use dependency tracking provided by UseLatexMk.cmake · 5511fb26
      Oliver Sander authored
      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.
      5511fb26
  7. 31 May, 2019 2 commits
    • Carsten Gräser's avatar
      [!213] Use this pointer for subPreBasis(i) in lambdas [bugfix] · 40f32a47
      Carsten Gräser authored
      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
      40f32a47
    • Steffen Müthing's avatar
      [!208] Allow wrapping of non-differentiable functions in GridFunction · 84de71c8
      Steffen Müthing authored
      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
      84de71c8
  8. 28 May, 2019 1 commit
  9. 27 May, 2019 4 commits
    • Simon Praetorius's avatar
    • Carsten Gräser's avatar
      [!209] Feature/expose subprebases · f6683b4f
      Carsten Gräser authored
      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
      f6683b4f
    • Carsten Gräser's avatar
      Explicitly use 'this->' when calling member in lambda · 1a092643
      Carsten Gräser authored
      This is needed to calm down gcc 5 and gcc 6.
      1a092643
    • Oliver Sander's avatar
      [!211] add inline keyword to lagrange(int) function [bugfix] · f9293226
      Oliver Sander authored
      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
      f9293226
  10. 22 May, 2019 1 commit
  11. 21 May, 2019 7 commits
  12. 16 May, 2019 2 commits
  13. 14 May, 2019 4 commits
    • Carsten Gräser's avatar
      [!207] Improve poisson-pq2 example · 6d280aab
      Carsten Gräser authored
      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
      6d280aab
    • Carsten Gräser's avatar
      Improve poisson-pq2 example · bae7ec27
      Carsten Gräser authored
      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).
      bae7ec27
    • Carsten Gräser's avatar
      [!206] [cmake] Modernize examples/CMakeLists.txt · 5b648c11
      Carsten Gräser authored
      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
      5b648c11
    • Carsten Gräser's avatar
      [cmake] Modernize examples/CMakeLists.txt · 47d2e67e
      Carsten Gräser authored
      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"
      47d2e67e
  14. 28 Mar, 2019 5 commits
  15. 26 Mar, 2019 1 commit
    • Carsten Gräser's avatar
      [!205] Add compatibility check to istlVectorBackend() · 72dd909f
      Carsten Gräser authored
      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
      72dd909f