Merge branch 'fix-vector-leaf-index' into 'master'

ref:core/dune-grid It is used to store certain leaf indices, so let's call it
'leafIndex'.

See merge request [!361]

  [!361]: gitlab.dune-project.org/core/dune-grid/merge_requests/361

It is used to store certain leaf indices, so let's call it
'leafIndex'.

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

See merge request [!359]

  [!359]: Nonecore/dune-grid/merge_requests/359

Merge branch 'i386-tolerance' into 'master'

ref:core/dune-grid This fixes a test failure on i386 with recent versions of
GCC where the numbers looked identical, even when printed with increased
precision or in binary (hexfloat) format, for the test-dgf-yasp-offset test:

    InvalidStateException [checkEntityLifetimeForCodim:.../dune-grid-2.6.0/dune/grid/test/checkentitylifetime.hh:77]:
    ERROR! inconsistent corner(0) coordinate for entity 27
      (0 0.30000000000000004 != 0 0.30000000000000004)
      (0x0p+0 0x1.3333333333334p-2 != 0x0p+0 0x1.3333333333334p-2)

But the test still failed as i386's x87 FPU uses a higher precision
internally.

Reference:
[https://buildd.debian.org/status/fetch.php?pkg=dune-grid&arch=i386&ver=2.6.0-4&stamp=1570661057&raw=0]

See merge request [!356]

  [https://buildd.debian.org/status/fetch.php?pkg=dune-grid&arch=i386&ver=2.6.0-4&stamp=1570661057&raw=0]:
    https://buildd.debian.org/status/fetch.php?pkg=dune-grid&arch=i386&ver=2.6.0-4&stamp=1570661057&raw=0
  [!356]: gitlab.dune-project.org/core/dune-grid/merge_requests/356

This fixes a test failure on i386 with recent versions of GCC where
the numbers looked identical, even when printed with increased
precision or in binary (hexfloat) format, for the
`test-dgf-yasp-offset` test:

```
InvalidStateException [checkEntityLifetimeForCodim:.../dune-grid-2.6.0/dune/grid/test/checkentitylifetime.hh:77]:
ERROR! inconsistent corner(0) coordinate for entity 27
  (0 0.30000000000000004 != 0 0.30000000000000004)
  (0x0p+0 0x1.3333333333334p-2 != 0x0p+0 0x1.3333333333334p-2)
```

But the test still failed as i386's x87 FPU uses a higher precision
internally.

Reference: https://buildd.debian.org/status/fetch.php?pkg=dune-grid&arch=i386&ver=2.6.0-4&stamp=1570661057&raw=0

Merge branch 'issue/test_tolerances' into 'master'

ref:core/dune-grid

### Summary

Change the fixed hard coded tolerances in grid tests with something related to
numeric_limits<ctype>::epsilon().

### Details

Many tolerances in the grid tests are hard coded to something like 1.e-8.
Those tests will fail if ctype=float. Thus, all those comparisons are changed
to either sqrt(numeric_limits<ctype>::epsilon()) or
numeric_limits<ctype>::epsilon(), depending on the previous value.

### Discussion

The tolerance values seem quite arbitrary. Sometimes it is compared against
1.e-8, sometimes 1.e-7 or 1.e-6 or 1e3*numeric_limits<ctype>::epsilon(). Maybe
it would be cleaner to use the FloatCmp utilities and clearly define what's
the expected accuracy.

See merge request [!352]

  [!352]: gitlab.dune-project.org/core/dune-grid/merge_requests/352

Merge branch 'gmsh_reader_fix' into 'master'

ref:core/dune-grid

-   otherwise on windows it is opened in text mode
    -   ftell/fseek on windows only work correctly on binary files
    -   see e.g.
        [https://stackoverflow.com/questions/47256223/why-does-fseek-0-seek-cur-fail-on-windows]
    -   this makes no difference on posix systems

also: use ftello/fseeko with type off_t instead of ftell/fseek with type long

-   [https://www.gnu.org/software/libc/manual/html_node/File-Positioning.html]
-   "using ftello is preferable whenever it is available"

See merge request [!353]

  [https://stackoverflow.com/questions/47256223/why-does-fseek-0-seek-cur-fail-on-windows]:
    https://stackoverflow.com/questions/47256223/why-does-fseek-0-seek-cur-fail-on-windows
  [https://www.gnu.org/software/libc/manual/html_node/File-Positioning.html]: https://www.gnu.org/software/libc/manual/html_node/File-Positioning.html
  [!353]: gitlab.dune-project.org/core/dune-grid/merge_requests/353

Merge branch 'use-SOURCES-in-dune-add-library' into 'master'

ref:core/dune-grid dune_add_library implicitly treats all unclaimed trailing
arguments as source file names, but explicitly marking those as SOURCE makes
the code more readable.

See merge request [!354]

  [!354]: gitlab.dune-project.org/core/dune-grid/merge_requests/354

dune_add_library implicitly treats all unclaimed trailing
arguments as source file names, but explicitly marking
those as SOURCE makes the code more readable.

  - otherwise on windows it is opened in text mode
  - ftell/fseek on windows only work correctly on binary files
  - see e.g. https://stackoverflow.com/questions/47256223/why-does-fseek-0-seek-cur-fail-on-windows
  - this makes no difference on posix systems

also use ftello/fseeko with type off_t instead of ftell/fseek with type long
  - https://www.gnu.org/software/libc/manual/html_node/File-Positioning.html
  - "using ftello is preferable whenever it is available"

Merge branch 'bug/do-not-crash-paraview-on-macos' into 'master'

ref:core/dune-grid Paraview (well, probably VTK) on macOS crashes when reading
ASCII files with denormalized float values. This seems to be due to libc++'s
IO stream implementation, which sets the fail bit when reading a denormalized
value. On top of that, Paraview just segfaults when encountering a fail bit
while loading VTK files.

libstdc++ does not set the failt bit, and I don't know what is the correct
behavior, but having Paraview mysteriously crash on DUNE output files is not
good.

So this patch truncates subnormal floating point values to 0 when writing
ASCII. This should not seriously influence any visualization results, but it
might trip up people who use exact floating point comparisons for tests (but
then you shouldn't do that anyway\...).

See merge request [!350]

  [!350]: gitlab.dune-project.org/core/dune-grid/merge_requests/350

Paraview (well, probably VTK) on macOS crashes when reading ASCII files with
denormalized float values. This seems to be due to libc++'s IO stream
implementation, which sets the fail bit when reading a denormalized value.
On top of that, Paraview just segfaults when encountering a fail bit while
loading VTK files.

libstdc++ does not set the failt bit, and I don't know what is the correct
behavior, but having Paraview mysteriously crash on DUNE output files is not
good.

So this patch truncates subnormal floating point values to 0 when writing ASCII.
This should not seriously influence any visualization results, but it might trip
up people who use exact floating point comparisons for tests (but then you
shouldn't do that anyway...).

Merge branch 'bugfix/gridtype-uggrid' into 'master'

ref:core/dune-grid Small fix to make grid type definition in config.h work for
UGGrid.

See merge request [!333]

  [!333]: gitlab.dune-project.org/core/dune-grid/merge_requests/333

Merge branch 'feature/gmsh-reader-boundarysegments-1d-grids' into 'master'

ref:core/dune-grid Boundary segments were not inserted for 1d grids (where
boundary segments are single nodes). However this is needed to e.g. attach
boundary data to a `Dune::FoamGrid<1, 3>` or Dune::OneDGrid.

-   Fixes [#93]
-   Adds a test for 1d gmsh boundary data with OneDGrid

See merge request [!348]

  [#93]: gitlab.dune-project.org/NoneNone/issues/93
  [!348]: gitlab.dune-project.org/core/dune-grid/merge_requests/348


Closes #93

Merge branch 'feature/sumouternormalerror-warning' into 'master'

ref:core/dune-grid The check is only true for affine elements and if the
element is not part of a network where intersections can overlap. The 'error'
will still be propagated as a warning in these cases.

With this change the grid check passes for all tested dune-foamgrid
configurations which previously failed due to this one check.

See merge request [!332]

  [!332]: gitlab.dune-project.org/core/dune-grid/merge_requests/332

Merge branch 'cleanup-1' into 'master'

See merge request [!347]

  [!347]: Nonecore/dune-grid/merge_requests/347

`assert(...)` should not be used in tests as it might not be checked
at all when building with `-DNDEBUG`

This addresses the following compiler warnings from GCC 9:

    dune/grid/utility/test/structuredgridfactorytest.cc:89:16:
    warning: unused variable ‘numVertices2d’ [-Wunused-variable]

    dune/grid/utility/test/structuredgridfactorytest.cc:90:16:
    warning: unused variable ‘numCubes2d’ [-Wunused-variable]

    dune/grid/utility/test/structuredgridfactorytest.cc:164:16:
    warning: unused variable ‘numVertices3d’ [-Wunused-variable]

    dune/grid/utility/test/structuredgridfactorytest.cc:165:16:
    warning: unused variable ‘numCubes3d’ [-Wunused-variable]

Merge branch 'yaspgrid-simplify-torus-communication' into 'master'

See merge request [!334]

  [!334]: Nonecore/dune-grid/merge_requests/334

Merge branch 'cmake-non-matching-endif' into 'master'

ref:core/dune-grid This silences a CMake warning about the argument not
matching the one in the if(...) condition two lines before.

See merge request [!346]

  [!346]: gitlab.dune-project.org/core/dune-grid/merge_requests/346

This silences a CMake warning about the argument not matching the one
in the `if(...)` condition two lines before.

The check is only true for affine elements and if the element is not
part of a network where intersections can overlap.
The 'error' will still be propagated as a warning in these cases.

Merge branch 'update-uggridfactory-documentation' into 'master'

ref:core/dune-grid The return value of createGrid should nowadays be captured
by a std::unique_ptr or std::shared_ptr.

See merge request [!344]

  [!344]: gitlab.dune-project.org/core/dune-grid/merge_requests/344

The return value of createGrid should nowadays be captured
by a std::unique_ptr or std::shared_ptr.

Merge branch 'uggrid-heapSize-Wundefined-var-template' into 'master'

ref:core/dune-grid Closes: [#91]

WIP:

-   [x] Manually verify in job trace the warning is gone (the remaining
    instances of the same error seem Alberta-related)

See merge request [!343]

  [#91]: gitlab.dune-project.org/NoneNone/issues/91
  [!343]: gitlab.dune-project.org/core/dune-grid/merge_requests/343


Closes #91

Closes: #91

Merge branch 'santiago.ospina/dune-grid-feature/change-type-of-volume-method-to-typedef' into 'master'

ref:core/dune-grid This is a rebased version of [!305] \-\-- I seem unable to
rebase that one in situ.

See merge request [!342]

  [!305]: gitlab.dune-project.org/NoneNone/merge_requests/305
  [!342]: gitlab.dune-project.org/core/dune-grid/merge_requests/342

Test User authored 6 years ago and Oliver Sander committed 5 years ago

Previously this was 'ctype', but grids may care about proper
dimensions.  In that case, a volume is not the same as a
coordinate, and a separate type for volumes is necessary.

The interface class does not hard-wire any type but rather exports
the type used by the Geometry implementation class.  That type
is determined by introspection, there is no need to adapt
downstream grid implementations.

Merge branch 'fix/gcc-9-warnings' into 'master'

ref:core/dune-grid Indicated by GCC 9's -Wpessimizing-move

See merge request [!341]

  [!341]: gitlab.dune-project.org/core/dune-grid/merge_requests/341

Indicated by GCC 9's -Wpessimizing-move

Merge branch 'issue/alberta_backuprestore_warning' into 'master'

ref:core/dune-grid

### Summary

Remove the usage of writeGridXdr and readGridXdr in AlbertaGrid since is
produces a deprecated warning.

### Details

The functions writeGridXdr and readGridXdr were simplified to writeGrid and
readGrid some time ago, but used in the backup-restore facilities of the
AlbertaGrid. This emits a deprecated warning all the time. This MR, replaces
the old functions with the new ones.

See merge request [!338]

  [!338]: gitlab.dune-project.org/core/dune-grid/merge_requests/338

Merge branch 'issue/geometrygrid_backuprestore_coordfunction' into 'master'

ref:core/dune-grid

### Summary

Changes GeometryGrid capabilities to be true for hasBackupRestoreFacilities
only if the CoordFunction is default constructible

### Details

Instantiating the BackupRestoreFacilities::restore for
`GeometryGrid<HostGrid, CoordFunction>` with a CoordFunction that is not
default constructible leads to an error. This is in contrast to the capability
hasBackupRestoreFacilities that returns true for this grid.

This MR updates the capabilities to be false if the CoordsFunction is not
default constructible and adds a tag-dispatching with a runtime-error in case
someone instantiates the BackupRestoreFacilities with such a CoordsFunction
nevertheless.

So, the BackupRestoreFacilities can be instantiated without a compile-time
error and one can use the hasBackupRestoreFacilities for a compile-time check
whether this should work or not.

### See Also

Some discussions about how to restore a non-default-constructible
CoordFunction can be found in [!339]

See merge request [!340]

  [!339]: gitlab.dune-project.org/NoneNone/merge_requests/339
  [!340]: gitlab.dune-project.org/core/dune-grid/merge_requests/340