Robert K authored 5 years ago and Christoph Grüninger committed 5 years ago

a point that is outside of quad.

Robert K authored 5 years ago and Christoph Grüninger committed 5 years ago

mappings, i.e. break Newton Loop after one iteration.

Merge branch 'fix-negative-dim' into 'master'

ref:core/dune-geometry as the reference elements are used in generic code, the
situation can happen, that one tries to access a reference-element of dim-1
(i.e. faces) for a 0d object. This would result in a reference-element for
dim=-1, which has no topolgies. We fix this explicitly by checking the
dim\>=0.

See merge request [!131]

  [!131]: gitlab.dune-project.org/core/dune-geometry/merge_requests/131

as the reference elements are used in generic code, the situation can
happen, that one tries to access a reference-element of dim-1
(i.e. faces) for a 0d object. This would result in a reference-element
for dim=-1, which has no topolgies. We fix this explicitly by checking
the dim>=0.

Merge branch 'issue/quadrature_rules_ct' into 'master'

ref:core/dune-geometry

### Summary

changed value type to double in vector and matrix in eigenvalue computations
in JacobiNQuadratureRule1D

### Details

When instantiating JacobiNQuadratureRule1D with ct=float, the function
DynamicMatrixHelp::eigenValuesNonSym is not found since float and double are
mixed in the argument types. The reason is that the matrix was filled with ct
and the vector was filled with complex<double>.

The bug is introduced in [!127]

See merge request [!130]

  [!127]: gitlab.dune-project.org/NoneNone/merge_requests/127
  [!130]: gitlab.dune-project.org/core/dune-geometry/merge_requests/130

Simon Praetorius authored 5 years ago and Ansgar Burchardt committed 5 years ago

changed value type to double in vector and matrix in eigenvalue computations in JacobiNQuadratureRule1D

Merge branch 'feature/update-authors' into 'master'

See merge request [!129]

  [!129]: Nonecore/dune-geometry/merge_requests/129

Merge branch 'feature/fix-typos-in-changelog' into 'master'

See merge request [!128]

  [!128]: Nonecore/dune-geometry/merge_requests/128

Merge branch 'master' into 'master'

ref:core/dune-geometry GaussJacobiArbitraryOrder is a quadrature type that
respects the weight function resulting from conical product.

The rules are computed on demand and currently have a "maximal" order of 127.
This upper limit is arbitrary and can be changed.

See merge request [!127]

  [!127]: gitlab.dune-project.org/core/dune-geometry/merge_requests/127

`GaussJacobi_n_0` is a quadrature type that respects the weight function resulting from conical product.
The rules use already existing quadrature rules compatible with various types
and if the desired order or dimension is too high new rules are computed on demand.
This case requires `LAPACK` and a floating point number type.

The rules currently have an arbitrary "maximal" order of 127. This upper limit is imposed by technical issues.

Merge branch 'issue/check_geometry_tolerances' into 'master'

ref:core/dune-geometry

### Summary

Replaces fixed tolerances 1.e-8 with ctype dependent tolerance

### Details

Tests with geometries using float as ctype may fail to reach the desired fixed
tolerance 1.e-8. This is corrected by using the
tolerance=sqrt(numeric_limits<ctype>::epsilon()) value. This value gives
approximately

-   `tolerance<double> = 1.5e-8` and
-   `tolerance<float> = 3.5e-4`

and thus previous test runs with ctype=double should also pass the test with
this change.

See merge request [!126]

  [!126]: gitlab.dune-project.org/core/dune-geometry/merge_requests/126

Merge branch 'remove-unused-variable-v' into 'master'

ref:core/dune-geometry This addresses the following warning from GCC 9:

    dune-geometry/dune/geometry/refinement/simplex.cc:741:21:
    warning: unused variable ‘v’ [-Wunused-variable]

See merge request [!124]

  [!124]: gitlab.dune-project.org/core/dune-geometry/merge_requests/124

This addresses the following warning from GCC 9:

    dune-geometry/dune/geometry/refinement/simplex.cc:741:21:
    warning: unused variable ‘v’ [-Wunused-variable]

Merge branch 'separate-return-type-for-volume' into 'master'

See merge request [!123]

  [!123]: Nonecore/dune-geometry/merge_requests/123

An test the method and type in the unit test.

This was forgotten in the last merge request.

The Volume type is simply hard-wired to ctype.  However, having it
as a separate type allows to change it more easily in the future.

Merge branch 'add-new-type-requirement-of-dune-grid-for-gemoetry' into 'master'

ref:core/dune-geometry This MR is required in order to solve
[dune-grid#79].

See merge request [!106]

  [dune-grid#79]: dune-grid#79
  [!106]: gitlab.dune-project.org/core/dune-geometry/merge_requests/106

Merge branch 'feature/use-latexmk' into 'master'

ref:core/dune-geometry Switch from generating EPS to PNG Requires
[dune-common!642]

See merge request [!120]

  [dune-common!642]: gitlab.dune-project.org/Nonedune-common/merge_requests/642
  [!120]: gitlab.dune-project.org/core/dune-geometry/merge_requests/120

Switch from generating EPS to PNG

Merge branch 'do-not-use-simplextopology' into 'master'

ref:core/dune-geometry The GeometryType::id() method works just as well, is
easier to understand, and less stressful for the compiler.

See merge request [!121]

  [!121]: gitlab.dune-project.org/core/dune-geometry/merge_requests/121

The GeometryType::id() method works just as well, is easier
to understand, and less stressful for the compiler.

Merge branch 'avoid-deprecated-constructor' into 'master'

See merge request [!113]

  [!113]: Nonecore/dune-geometry/merge_requests/113

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

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 ...).

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

Merge branch 'feature/update-changelog' into 'master'

See merge request [!116]

  [!116]: Nonecore/dune-geometry/merge_requests/116

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

While I'm not aware of an explicit formular (feel free to
provide/prove one), a constexpr function computing the
max works nicely here.

Merge branch 'ci/centralize-config' into 'master'

See merge request [!115]

  [!115]: Nonecore/dune-geometry/merge_requests/115

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.

Merge branch 'skip-test-on-buggy-g++' into 'master'

ref:core/dune-geometry Closes: [#19].

See: [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288]

See merge request [!114]

  [#19]: gitlab.dune-project.org/NoneNone/issues/19
  [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288
  [!114]: gitlab.dune-project.org/core/dune-geometry/merge_requests/114


Closes #19

Closes: #19.

See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288