Merge branch 'patch-1' into 'master'

ref:core/dune-geometry needs to be backported to releases/2.7

See merge request [!133]

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

Merge branch 'feature/bump-to-2.8' into 'master'

See merge request [!132]

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

Merge branch 'feature/add-geometrytype-id' into 'master'

ref:core/dune-geometry After thinking about what I proposed in [#17], I
realized that an index is probably not the right idea of thinking about this.
Instead, we can just do a 1-to-1 mapping of GeometryType to a canonical id, as
GeometryType itself is just a 8 byte struct that stores three integral values.

I've nested the id within GeometryType as GeometryType::Id here and added
implicit conversions between the two. The id type is a scoped enum to avoid
any future nastiness with implicit conversions to other integral types.

With this merge request, you can have a template with a GeometryType parameter
with just a tiny bit of overhead on the implementor's side:

    // note the additional "::Id"
    template<GeometryType::Id gt_>
    class Foo
    {
      // reconstruct the GeometryType
      static constexpr GeometryType gt = gt_;
    };

For the user, it looks like they can just plug in a GeometryType:

    Foo<GeometryTypes::triangle> foo;

This solves a major 2.6 headache in PDELab (see [#17],
[pdelab/dune-pdelab#102]), so I'd really like this to go into 2.6.

Closes [#17].

See merge request [!87]

  [#17]: gitlab.dune-project.org/NoneNone/issues/17
  [pdelab/dune-pdelab#102]: gitlab.dune-project.org/pdelab/dune-pdelab/issues/102
  [!87]: gitlab.dune-project.org/core/dune-geometry/merge_requests/87


Closes #17

Steffen Müthing authored 7 years ago and Christoph Grüninger committed 5 years ago

While GeometryType is constexpr and can thus be used in a lot of compile time contexts, C++ does not
allow us to declare a template parameter of type GeometryType, as the standard only allows data
types that directly map to a built-in integral type for this purpose.

On the other hand, GeometryType itself is just a simple 64 bit struct that stores a few integral
values, so we can easily map it to an integral type.

This patch does just that by adding an opaque nested type GeometryType::Id that is implemented as a
scoped enum as well as implicit conversions between GeometryType and GeometryType::Id. By using a
scoped enum, we clearly tag the type as something which is not a normal number, because C++ requires
explicit conversion between scoped enums and other integral types.

The storage layout of the id is chosen identical to that of GeometryType, making conversion between
the two almost free.

When writing a template with a GeometryType parameter, just use the id instead and convert it back
into a GeometryType inside the template:

template<GeometryType::Id gt_>
class Foo
{
  static constexpr GeometryType gt = gt_;
};

Merge branch 'bugfix/multilin-geom' into 'master'

ref:core/dune-geometry This MR is simply setup to trigger the problem pointed
out in issue [#23].

See merge request [!125]

  [#23]: gitlab.dune-project.org/NoneNone/issues/23
  [!125]: gitlab.dune-project.org/core/dune-geometry/merge_requests/125

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

quads when point is outside of geometry, e.g. by dealing with the singular matrices.

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