1. 25 Apr, 2018 1 commit
  2. 24 Apr, 2018 2 commits
  3. 18 Jul, 2017 1 commit
  4. 17 Jul, 2017 1 commit
  5. 14 Jun, 2017 1 commit
  6. 09 Mar, 2017 2 commits
  7. 02 Jan, 2017 1 commit
  8. 18 Dec, 2016 2 commits
  9. 15 Dec, 2016 1 commit
  10. 24 Nov, 2016 1 commit
  11. 23 Nov, 2016 3 commits
  12. 18 Nov, 2016 1 commit
    • Ansgar Burchardt's avatar
      Merge branch 'cherry-pick-76b1d4bf' into 'releases/2.5' · 2ed17720
      Ansgar Burchardt authored
      Merge branch 'feature/remove-generic-geometry' into 'master'
      
      remove generic geometry subdirectory
      
      On the last developer meeting, we agree on the following things:
      - The `genericgeometry` subdirectory should vanish in the next DUNE release.
      - All content of the namespace GenericGeometry is considered an implemenation detail.
      
      This merge implements these decisions. All functionality that is sitll required is migrated into the appropriate headers in `dune/geometry` and put into the namespace `Impl`. 
      
      **Note**: There is *no transition phase* for the content of the `genericgeometry` subdirectory.
      
      See merge request !34
      
      See merge request !38
      2ed17720
  13. 17 Nov, 2016 1 commit
    • Christian Engwer's avatar
      Merge branch 'feature/remove-generic-geometry' into 'master' · 51779cd5
      Christian Engwer authored
      remove generic geometry subdirectory
      
      On the last developer meeting, we agree on the following things:
      - The `genericgeometry` subdirectory should vanish in the next DUNE release.
      - All content of the namespace GenericGeometry is considered an implemenation detail.
      
      This merge implements these decisions. All functionality that is sitll required is migrated into the appropriate headers in `dune/geometry` and put into the namespace `Impl`. 
      
      **Note**: There is *no transition phase* for the content of the `genericgeometry` subdirectory.
      
      See merge request !34
      51779cd5
  14. 27 Oct, 2016 1 commit
  15. 19 Oct, 2016 2 commits
    • Ansgar Burchardt's avatar
    • Carsten Gräser's avatar
      Merge branch 'feature/constrain-geometrytype-constructor' into 'master' · 448af15f
      Carsten Gräser authored
      Contrain GeometryType template constructor
      
      The templated constructor is supposed to be used with
      types modelling a `TopologyType`, i.e., types providing
      `::dimension` and `::id`. This MR constrains the overload
      to such types only.
      
      This fixes the problem that dune-functions cannot be
      build with clang and libstdc++-6. For the same reason
      the `PQkLocalFiniteElementCache` could not be used with
      this combination which is unfortunately not triggered
      by any test.
      
      Since the reason is far from obvious I'll give a short summary:
      
      * Dune-functions uses `PQkLocalFiniteElementCache`.
      * The copy constructor and `get()` function of `PQkLocalFiniteElementCache`
        use `operator[](const GeometryType&)` of `std::map<GeometryType,Foo>`.
      * When called with an l-value, the `operator[]` of an `std::map<T, Foo>`
        checks if `T` can be constructed from a `tuple<...>`. (*)
      * This check fails to compile with the very greedy templated constructor
      
      ```cpp
      template<class TopologyType> GeometryType(TopologyType);
      ```
      
      Notice that I don't understand the purpose of the check in (*)
      which spans over about 20 levels of template instantiation context.
      E.g. it does not happen if `operator[]` is called with an r-value as
      argument.
      
      By constraining the constructor to only be available for appropriate
      types we can avoid this problem.
      
      See merge request !32
      448af15f
  16. 18 Oct, 2016 3 commits
    • Carsten Gräser's avatar
      Contrain GeometryType template constructor · 6da8c7d9
      Carsten Gräser authored
      The templated constructor is supposed to be used with
      types modelling a TopologyType, i.e., types providing
      ::dimension and ::id.
      
      This fixes the problem that dune-functions cannot be
      build with clang and libstdc++-6. For the same reason
      the PQkLocalFiniteElementCache could not be used with
      this combination which is unfortunately not triggered
      by any test.
      
      Since the reason is far from obvious I'll give a short summary:
      
      a)Dune-functions uses PQkLocalFiniteElementCache.
      b)The copy constructor and get() function of PQkLocalFiniteElementCache
        uses operator[](const GeometryType&) of std::map<GeometryType,Foo>
      c)When called with an l-value, the operator[] of an std::map<T, Foo>
        checks if T can be constructed from a tuple<...>.
      d)This check fails to compile with the very greedy templated constructor
        of GeometryType
      
          template<class TopologyType> GeometryType(TopologyType);
      
      Notice that I don't understand the purpose of the check in c)
      which spans over about 20 levels of template instantiation context.
      E.g. it does not happen if operator[] is called with an r-value as
      argument.
      
      By constraining the constructor to only be available for appropriate
      types we can avoid this problem.
      6da8c7d9
    • Oliver Sander's avatar
      Merge branch 'feature/update-test-environments' into 'master' · 388f03de
      Oliver Sander authored
      Update test environments
      
      - No longer test with clang 3.5.
      - Add clang 3.8 from Debian 8 + backports
      - Add gcc 5.4 + clang 3.8 from Ubuntu 16.04 LTS.
      - Use `duneci-standard-test`
      
      See merge request !31
      388f03de
    • Ansgar Burchardt's avatar
      Update test environments · 6c396657
      Ansgar Burchardt authored
      - No longer test with clang 3.5.
      - Add clang 3.8 from Debian 8 + backports
      - Add gcc 5.4 + clang 3.8 from Ubuntu 16.04 LTS.
      - Use `duneci-standard-test`
      6c396657
  17. 06 Oct, 2016 2 commits
  18. 05 Oct, 2016 1 commit
  19. 20 Sep, 2016 1 commit
  20. 16 Sep, 2016 3 commits
  21. 16 Aug, 2016 1 commit
    • Oliver Sander's avatar
      Merge branch 'feature/remove-dimensionworld' into 'master' · 3b8efcfd
      Oliver Sander authored
      Remove exported number 'dimensionworld' from the virtual refinement interface
      
      It has been removed from the Geometry interface, so it makes sense
      to remove it here too:  After all, the virtual refinement mimic
      the Geometry interface.
      
      See merge request !25
      3b8efcfd
  22. 13 Aug, 2016 1 commit
  23. 05 Aug, 2016 2 commits
  24. 19 Jul, 2016 1 commit
  25. 18 Jul, 2016 1 commit
  26. 07 Jul, 2016 2 commits
  27. 14 Jun, 2016 1 commit
    • Jö Fahlke's avatar
      Merge branch 'feature/issue-5-fix-signed-overflow-warning' into 'master' · 9e4f3530
      Jö Fahlke authored
      Fix "warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]"
      
      This was a tricky one.  It was highly non-obvious why the compiler even ran
      into this issue.  My best guess is as follows: The compiler was trying to
      optimize the loop over the vertices in `testStaticRefinementGeometry()`,
      test-refinement.cc:122.  To do this it needed to statically evaluate
      `vEnd(refinement)`, where `refinement` is unsigned, but converted to int due to
      the signature of `vEnd()`.  The constructed iterator stores it as unsigned
      `_level`, and it also stores the current position as unsigned `_index`.  So there
      is a conversion from unsigned to int and back to unsigned.
      
      Changing the parameter and return value of `vEnd()` to unsigned turns out not to
      be enough: `vEnd` calls `nVertices()`, which also takes and returns an int.
      Changing that to unsigned too is still not enough, because `nVertices` evaluates
      the expression `Power<dimension>::eval((1<<level)+1)`.  While `level` is now
      unsigned, the literal `1`'s are not, and the result of `operator<<()` will have
      the type of the (promoted) left operand (the "usual integral conversions" do
      not happen for `<<`).  Thus we need to change the literals to `1u`.
      
      To be clear: the warning happens because of conversion from unsigned to int
      and then back to unsigned, where the compiler is unable to fully track all
      possible values and cannot prove that everything is fine.
      
      This patch fixes this by making the level parameter unsigned, and by making
      sure that any literals are suffixed by u.
      
      Adresses #5.
      
      See merge request !19
      9e4f3530