1. 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
  2. 07 Sep, 2019 1 commit
  3. 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
  4. 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
  5. 28 May, 2019 1 commit
  6. 27 May, 2019 4 commits
  7. 22 May, 2019 1 commit
  8. 21 May, 2019 7 commits
  9. 16 May, 2019 2 commits
  10. 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
  11. 28 Mar, 2019 5 commits
  12. 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 [!205]
      
        [!205]: gitlab.dune-project.org/staging/dune-functions/merge_requests/205
      72dd909f
  13. 25 Mar, 2019 4 commits
    • Carsten Gräser's avatar
      Guard Hybrid::ifElse lambda body using id() · 4e72152b
      Carsten Gräser authored
      * I can understand, why this need's to be done, but I have
        no idea, why it's necessary only after introducing a
        static_asset() in istlVectorBackend(). The error can
        reproducibly be avoided by removing the static_assert
        again.
      * It looks like this is still not correct. If you pass
        a temporary vector to makeDiscreteGlobalBasisFunction()
        it may be double wrapped leading to a pointer to
        (vanished) temporary.
      4e72152b
    • Carsten Gräser's avatar
      Add compatibility check to istlVectorBackend() · 0b423483
      Carsten Gräser authored
      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 fails 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();
      ```
      0b423483
    • Carsten Gräser's avatar
      Guard Hybrid::ifElse lambda bodies using identity function · 9542c9eb
      Carsten Gräser authored
      Without doing this, istVectorBackend() is instanciated for AllTrueBitVector.
      This is problematic, because operator[] can lead to an infinite template recursion
      or related error ("auto ... was used before auto could be deduced").
      This will become a problem if static_asserts are added to istlVectorBackend().
      9542c9eb
    • Carsten Gräser's avatar
      Add HasStaticIndexAccess concept · 29fc7128
      Carsten Gräser authored
      29fc7128
  14. 19 Mar, 2019 5 commits
    • Oliver Sander's avatar
      [!203] Minor cleanup in the examples code · 8535bddb
      Oliver Sander authored
      Merge branch 'minor-examples-cleanup' into 'master'
      
      ref:staging/dune-functions
      
      -   Remove unnecessary 'Dune::' prefixes
      -   Remove unnecessary 'hybridTreePath()' arguments
      -   Use namespace Dune::Indices instead of Dune::TypeTree::Indices
      
      See merge request [!203]
      
        [!203]: gitlab.dune-project.org/staging/dune-functions/merge_requests/203
      8535bddb
    • Oliver Sander's avatar
      Minor cleanup in the examples code · 2f9855d7
      Oliver Sander authored
      * Remove unnecessary 'Dune::' prefixes
      * Remove unnecessary 'hybridTreePath()' arguments
      * Use namespace Dune::Indices instead of Dune::TypeTree::Indices
      2f9855d7
    • Oliver Sander's avatar
      Precompute dofs-per-entity information if order is set at run-time · 08b8b424
      Oliver Sander authored
      The LagrangeBasis implementation needs the number of degrees of freedom
      per GeometryType internally.  These depend only on the order of the
      space.
      
      So where should these values come from?  Without having done
      any measurements, I conjecture that the most efficient solution
      depends on whether the order is given at run-time or at
      compile-time:
      * with a compile-time order, the values should be recomputed every
        time they are used, because the compiler can fold the entire
        expression.  In particular, such a folded expression is faster
        than a memory access.
      * with a run-time order, the expression cannot be folded, and a
        memory access is quicker than recomputing the numbers again
        and again at run-time (I may be wrong here).
      
      This patch implements the corresponding strategy: depending on whether
      the polynomial order is given at run-time or at compile-time, the
      numbers are now precomputed and store, or recomputed every time
      they are needed.
      08b8b424
    • Oliver Sander's avatar
      Unify the different 'dofsPerXYZ' methods · 4a45a38e
      Oliver Sander authored
      Search for 'simplicial polytopic numbers' for a description
      of the simplex formula.
      4a45a38e
    • Oliver Sander's avatar
      Make the run-time order data member const · 6706f6e8
      Oliver Sander authored
      Because it is: after construction it is not and cannot be changed.
      6706f6e8