1. 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
  2. 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 [staging/dune-functions!213]
      
        [staging/dune-functions!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 [staging/dune-functions!208]
      
        [#43]: gitlab.dune-project.org/NoneNone/issues/43
        [staging/dune-functions!208]: gitlab.dune-project.org/staging/dune-functions/merge_requests/208
      
      
      Closes #43
      84de71c8
  3. 28 May, 2019 1 commit
  4. 27 May, 2019 3 commits
    • 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 [staging/dune-functions!209]
      
        [staging/dune-functions!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
  5. 22 May, 2019 1 commit
  6. 21 May, 2019 7 commits
  7. 16 May, 2019 2 commits
  8. 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 [staging/dune-functions!207]
      
        [staging/dune-functions!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
  9. 28 Mar, 2019 5 commits
  10. 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
  11. 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
  12. 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
  13. 14 Mar, 2019 2 commits
    • Oliver Sander's avatar
      Remove two redundant local variables · 67afb3be
      Oliver Sander authored
      67afb3be
    • Oliver Sander's avatar
      Implement LagrangeBasis with run-time order · 76ba7a1a
      Oliver Sander authored
      This patch 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.
      76ba7a1a
  14. 12 Mar, 2019 1 commit