1. 14 Jan, 2019 2 commits
  2. 17 Dec, 2018 2 commits
    • Jö Fahlke's avatar
      [!119] Narrow compiler/options for skipping testcornerstoragerefwrap · 253af83f
      Jö Fahlke authored
      Merge branch 'narrow-testskip-to-bad-config' into 'master'
      
      ref:core/dune-geometry We now only skip if
      
      -   The compiler is gcc 8.2.\*
      -   The compile options include -ftree-loop-vectorize (possibly implicitly due
          to -O3)
      
      We also complain loudly during cmake configure run, as this issue might
      miscompile other code than just the test.
      
      Closes: [#19], [#21]
      
      See merge request [!119]
      
        [#19]: gitlab.dune-project.org/NoneNone/issues/19
        [#21]: gitlab.dune-project.org/NoneNone/issues/21
        [!119]: gitlab.dune-project.org/core/dune-geometry/merge_requests/119
      
      
      Closes #19 and #21
      253af83f
    • Jö Fahlke's avatar
      Consider build-type when checking for bad optimization options · 0d09c4b0
      Jö Fahlke authored
      For single build-type generators such as unix make files check
      CMAKE_CXX_FLAGS_<CONFIG> in addition CMAKE_CXX_FLAGS.  This is equivalent to
      just CMAKE_CXX_FLAGS if not build-type is selected.  For multi-configuration
      generators, check each configuration, and skip the test is any of them is bad.
      
      I'd like to skip it only for the bad configs, but that would require generator
      expression support in dune_add_test(CMAKE_GUARD ...).
      0d09c4b0
  3. 14 Dec, 2018 1 commit
  4. 06 Dec, 2018 7 commits
    • Carsten Gräser's avatar
      [!116] [doc] Mention referenceElement.subEntity() in changelog · 92165eda
      Carsten Gräser authored
      Merge branch 'feature/update-changelog' into 'master'
      
      See merge request [!116]
      
        [!116]: Nonecore/dune-geometry/merge_requests/116
      92165eda
    • Carsten Gräser's avatar
    • Steffen Müthing's avatar
      [!94] Add ReferenceElement::subEntities() method returning a range · d721f3b8
      Steffen Müthing authored
      Merge branch 'feature/re-subentities-range' into 'master'
      
      For a reference element re the call
      
            re.subEntity(i,codim,j,c);
      
      returns the index (wrt re) of the j-th sub-subentity of codim (wrt re) c of
      the subentity (i,codim). This allows e.g. to access all vertices of a face.
      However, there's a big problem with this method:
      
      It is often misinterpreted by users that the passed index j is the index of
      one grid-subentity within another grid-subentity. To be more precise it is
      assumed that the subEntity() methods of the reference element and a grid
      element are consistent with each other. Unfortunately this is in general not
      true because it is impossible to construct such an consistent subentity
      embedding for any grid. As a consequence both may provide a different
      embedding and the index j is essentially useless despite allowing to iterate
      over all such subentities using
      
          // Don't use j directly in such a loop, it's very likely that
          // your assumptions on the meaning of j don't hold true!
          for(std::size_t j=0; j<re.size(i,codim,c); ++j)
            foo(re.subEntity(i,codim,j,c));
      
      While the behaviour is documented, users repeatedly fall into this trap and
      the issue is discussed on the list once in a while.
      
      As a remedy this introduces a new method ReferenceElement::subEntities()
      returning all the subentities as an iterable range. The actual type of this
      range is implementation defined. Using this the above loop turns into:
      
          // No j here!
          for(auto k : re.subEntities(i,codim,c))
            foo(k);
      
      This is not only more readable, but it especially avoids misinterpreting the
      'index' j. You can still run into the trap on purpose by assuming a special
      ordering of the range. But this is very unlikely and you have to take special
      action to construct the index j.
      
      This MR is based on [!93] (contains) because it consistently tests for all
      codim/c combinations. But one could also restrict the allowed cases to
      c>=codim here. In a later stage we may want to deprecate the error prone
      subEntity() method.
      
      Side note: Thanks to the implementer (@martin.nolte?) of the reference
      elements for caching those numbers in a consecutive way. Implementing this
      feature just amounts into wrapping pointers into the cache in a
      Dune::IteratorRange. However, I'd even more like to put them into gsl:span.
      
      See merge request [!94]
      
        [!93]: gitlab.dune-project.org/NoneNone/merge_requests/93
        [!94]: gitlab.dune-project.org/core/dune-geometry/merge_requests/94
      d721f3b8
    • Carsten Gräser's avatar
      Implement exact upper bound for number of subentities · 86542ec1
      Carsten Gräser authored
      While I'm not aware of an explicit formular (feel free to
      provide/prove one), a constexpr function computing the
      max works nicely here.
      86542ec1
    • Steffen Müthing's avatar
      [!115] Centralize CI configuration · 57c3019b
      Steffen Müthing authored
      Merge branch 'ci/centralize-config' into 'master'
      
      See merge request [!115]
      
        [!115]: Nonecore/dune-geometry/merge_requests/115
      57c3019b
    • Carsten Gräser's avatar
      Add contains() and size() method to subentity range · fca01008
      Carsten Gräser authored
      Now the index range returned from referenceElement.subEntities(i,codim,c)
      is not just iterable but also provides the methods size() and contains().
      This is not just for convenience:
      
      It's a common use case of this method (e.g. when determining boundary DOFs),
      to check if a faced contains the subentities associated to DOFs. Until know
      you always had to loop over the range provided by referenceelement.subEntity()
      and compare resulting indices. Now you can use the contains() method
      which just looks up the result in a table.
      
      Design decision:
      The per-codim look-up is implemented using a std::bitset<K> with
      K=3^dim as upper bound for the per-codim subentity count. While
      this is pessipistic, it's much cheaper than any dynamic version
      for dim<=4. Feel free to add a better upper bound for larger dimensions.
      fca01008
    • Steffen Müthing's avatar
      [ci] Centralize CI configuration · a7185229
      Steffen Müthing authored
      a7185229
  5. 23 Nov, 2018 2 commits
  6. 08 Nov, 2018 1 commit
    • Steffen Müthing's avatar
      [!111] Deprecate constructor GeometryType(int) · d642ac94
      Steffen Müthing authored
      Merge branch 'deprecated-geometrytype-dim' into 'master'
      
      ref:core/dune-geometry As decided at the 2018 dev meeting in Stuttgart.
      
      This constructor (and its cousin GeometryType(uint)) are not really needed
      with the new way to construct GeometryType objects.
      
      See merge request [!111]
      
        [!111]: gitlab.dune-project.org/core/dune-geometry/merge_requests/111
      d642ac94
  7. 07 Nov, 2018 2 commits
    • Oliver Sander's avatar
      Deprecate constructor GeometryType(int) · ebfd7568
      Oliver Sander authored
      As decided at the 2018 dev meeting in Stuttgart.
      
      This constructor (and its cousin GeometryType(uint)) are not
      really needed with the new way to construct GeometryType objects.
      ebfd7568
    • Ansgar Burchardt's avatar
      [!110] use `std::vector` instead of `NoCopyVector` · 8d45d597
      Ansgar Burchardt authored
      Merge branch 'cleanup/remove-NoCopyVector' into 'master'
      
      ref:core/dune-geometry NoCopyVector is a very limited vector type for items
      missing a copy constructor. This was required in the past as vector's template
      parameter T "must meet the requirements of CopyAssignable and
      CopyConstructible", however since C++11 this was weakened to "The requirements
      that are imposed on the elements depend on the actual operations performed on
      the container" which should allow use with non-CopyAssignable and
      non-CopyConstructible types.
      
      See merge request [!110]
      
        [!110]: gitlab.dune-project.org/core/dune-geometry/merge_requests/110
      8d45d597
  8. 24 Oct, 2018 1 commit
    • Ansgar Burchardt's avatar
      use `std::vector` instead of `NoCopyVector` · efba241c
      Ansgar Burchardt authored
      `NoCopyVector` is a very limited vector type for items missing a copy
      constructor.  This was required in the past as `vector`'s template
      parameter `T` "must meet the requirements of CopyAssignable and
      CopyConstructible", however since C++11 this was weakened to "The
      requirements that are imposed on the elements depend on the actual
      operations performed on the container" which should allow use with
      non-CopyAssignable and non-CopyConstructible types.
      efba241c
  9. 06 Sep, 2018 1 commit
    • Jö Fahlke's avatar
      [!107] Add missing include. · a0d66736
      Jö Fahlke authored
      Merge branch 'feature/missing-include-in-simplex-cc' into 'master'
      
      See merge request [!107]
      
        [!107]: Nonecore/dune-geometry/merge_requests/107
      a0d66736
  10. 05 Sep, 2018 1 commit
  11. 01 Aug, 2018 1 commit
  12. 27 Jul, 2018 1 commit
  13. 02 Jul, 2018 1 commit
  14. 29 Jun, 2018 2 commits
  15. 24 Apr, 2018 2 commits
  16. 20 Apr, 2018 2 commits
  17. 18 Apr, 2018 2 commits
  18. 29 Mar, 2018 2 commits
  19. 26 Mar, 2018 3 commits
    • Carsten Gräser's avatar
      [test] Add test for new method `ReferenceElement::subEntities()` · a387f1a6
      Carsten Gräser authored
      This essentially tests some special cases and consistency of
      `subEntity()`, `subEntities()`, and `size()`.
      a387f1a6
    • Carsten Gräser's avatar
      Add `ReferenceElement::subEntities()` method returning a range · 4a45da2c
      Carsten Gräser authored
      For a reference element re the call
      
      ```cpp
        re.subEntity(i,codim,j,c);
      ```
      
      returns the index (wrt re) of the j-th sub-subentity
      of codim (wrt re) c of the subentity (i,codim). This allows
      e.g. to access all vertices of a face. However, there's
      a big problem with this method:
      
      It is often misinterpreted by users that the passed index j is
      the index of one grid-subentity within another grid-subentity.
      To be more precise it is assumed that the `subEntity()` methods
      of the reference element and a grid element are consistent with
      each other. Unfortunately this is in general not true because
      it is impossible to construct such an consistent subentity
      embedding for any grid. As a consequence both may provide a
      different embedding and the index j is essentially useless
      despite allowing to iterate over all such subentities using
      
      ```cpp
      // Do use j directly in this loop, it's very likely that
      // your assumptions on the meaning of j don't hold true.
      for(std::size_t j=0; j<re.size(i,codim,c); ++j)
        foo(re.subEntity(i,codim,j,c));
      ```
      
      While the behaviour is documented, users repeatedly fall into
      this trap and the issue is discussed on the list once in a while.
      
      As a remedy this introduces a new method ReferenceElement::subEntities()
      returning all the subentities as an iterable range. Using this the
      above loop turns into:
      
      ```cpp
      // No j here!
      for(auto k : re.subEntity(i,codim,c))
        foo(k);
      ```
      
      This is not only more readable, but it especially avoids misinterpreting
      the 'index' j. You can still fall into the trap be assuming a special
      ordering in the range. But this is very unlikely and you have to take
      special action to construct the index j.
      
      In a later stage we may want to deprecate the error prone `subEntity()` method.
      4a45da2c
    • Carsten Gräser's avatar
      Allow ReferenceElement::size(i,c,cc) for cc<c · edcac37f
      Carsten Gräser authored
      While subEntity(i,c,j,cc) is surely not allowed for
      cc<c because there's no viable j, there's no reason
      to not allow this case for size(i,c,cc). Actually the
      implementation works nicely in this case and returns
      the correct number size zero. Any grid-specific
      ReferenceElement implementation should simply return
      zero in this case.
      
      Allowing this case gives the possibility to seamlessly test
      for(int j=0; j < re.size(i,c,cc); ++j)
      for all 0<=c<=dim and 0<=cc<=dim.
      edcac37f
  20. 19 Mar, 2018 1 commit
  21. 14 Mar, 2018 3 commits