dune-common issueshttps://gitlab.dune-project.org/core/dune-common/-/issues2021-01-23T23:24:09Zhttps://gitlab.dune-project.org/core/dune-common/-/issues/2Make FieldVector::size() static2021-01-23T23:24:09ZCarsten Gräsergraeser@math.fau.deMake FieldVector::size() staticIn order to use the `size()` method of `FieldVector` in compile-time context we made it `constexpr` some time ago. Unfortunately this is only partly useful, because one cannot do things like this
template<class V>
auto foo(V ...In order to use the `size()` method of `FieldVector` in compile-time context we made it `constexpr` some time ago. Unfortunately this is only partly useful, because one cannot do things like this
template<class V>
auto foo(V v) -> std::array<int,v.size()>;
The reason is that v itself is not a constexpr. This can be solved by making the method `static constexpr`. Then one could still use it as before, but also in a static context.https://gitlab.dune-project.org/core/dune-common/-/issues/359Deprecate parts of alignedallocator.hh and debugalign.hh that are covered by ...2023-12-21T16:11:21ZChristoph GrüningerDeprecate parts of alignedallocator.hh and debugalign.hh that are covered by C++17From reading the documentation, C++17 should provide replacements for `alignedallocator.hh` and `debugalign.hh`. `std::align` and `std::alligned_alloc` sound like suitable replacements.
We need to clarify, if we need parts of the two he...From reading the documentation, C++17 should provide replacements for `alignedallocator.hh` and `debugalign.hh`. `std::align` and `std::alligned_alloc` sound like suitable replacements.
We need to clarify, if we need parts of the two headers, deprecate the no longer necessary part for Dune 2.10 and remove them after the release.DUNE 2.10.0https://gitlab.dune-project.org/core/dune-common/-/issues/354Compiler warning pollution from dependencies2023-11-06T12:57:49ZAlexander MüllerCompiler warning pollution from dependenciesI tried for my dune module to really go hard on fix warnings from clang.
The output is polluted by giving warnings on all other included modules/header from e.g. `dune-functions,yasp_grid,dune-geometry,...`.
Now I read about the fact th...I tried for my dune module to really go hard on fix warnings from clang.
The output is polluted by giving warnings on all other included modules/header from e.g. `dune-functions,yasp_grid,dune-geometry,...`.
Now I read about the fact that the compilers may not produce warning for system headers.
https://cmake.org/cmake/help/latest/command/target_include_directories.html
>If SYSTEM is specified, the compiler will be told the directories are meant as system include directories on some platforms. This may have effects such as suppressing warnings or skipping the contained headers in dependency calculations (see compiler documentation). Additionally, system include directories are searched after normal include directories regardless of the order specified.
Therefore, in https://gitlab.dune-project.org/core/dune-common/-/blob/1437ba8a2840120ef48d563f798134cbb66db70c/cmake/modules/DuneEnableAllPackages.cmake#L301,
there could be an option to include these as SYSTEM header or even as default?
I'm not sure if this will break.
Maybe there is another mechanism less intrusive I'm unaware of.
Nevertheless, this is a show stopper for me to enable warning, since currently the warning pollution of dependencies is too big.
Any thoughts on this @simon.praetorius @santiago.ospina ? Thanks!https://gitlab.dune-project.org/core/dune-common/-/issues/294reomove pybind11 sources from dune-common2024-02-22T13:33:42ZAndreas Dednerreomove pybind11 sources from dune-commonBackground
----------
At this point in time `pybind11` headers are included in `dune-common`. The reason for that was that `pybind11` was very actively developed and non compatible changes were not uncommon at the beginning. So we wanted...Background
----------
At this point in time `pybind11` headers are included in `dune-common`. The reason for that was that `pybind11` was very actively developed and non compatible changes were not uncommon at the beginning. So we wanted control over the version that is being used. That is not that much of an issue anymore.
Suggestion
----------
Remove the package from dune-common.
Have a cmake find with a required version for pybind11 (equals or >=) and if that is not found in the system, we can install pybind11 into the venv which can be deactivated by the user via some flag (or the user can install a newer version by hand and get dune to install the required version into the venv by setting some flag) For the packages I would suggest to have installation done by dune if the packages is not found.
Related: discussion in !811 and the discussion in dune-istl!386.https://gitlab.dune-project.org/core/dune-common/-/issues/253What is a matrix?2023-10-17T15:32:05ZSimon PraetoriusWhat is a matrix?## What is a matrix?
While we have CRTP base class `DenseMatrix` specifying the interface for matrices, this base is incomplete or wrong documented and even inconsistent. The specification is also not applied to all matrix-like classes n...## What is a matrix?
While we have CRTP base class `DenseMatrix` specifying the interface for matrices, this base is incomplete or wrong documented and even inconsistent. The specification is also not applied to all matrix-like classes neither in dune-common nor in dune-istl. So, I wanted to open a specific discussion on what is a matrix?
### 1. Matrix is a 2d container of values
On Wikipedia, a matrix is defined as "a rectangular array of numbers (or other mathematical objects)". Thus we have the following requirements:
- (a) A matrix stores elements/entries of a specific type. Seeing matrices as collections, this would mean we have a single element-type. For collections this type is typically denoted by `value_type`.
- "The size of a matrix is defined by the number of rows and columns that it contains". Actually, this definition specifies three size informations:
1. (b) There is a type representing the sizes, typically denoted by `size_type`
2. (c) There is number of rows and number of columns. In Dune this is (for historical reasons) denoted by `N()` and `M()` respectively.
3. (d) There us the *total size* of a matrix. Since a matrix shape is denoted by `n x m`, I would suggest to define the size as the product `n*m`. This would allow to see single-row and single-column matrices as row-vector and column-vector, correspondingly. Compare, e.g., `numpy.matrix.size`, `mtl::size(matrix)`, or `Eigen::Matrix::size`.
- (e) The elements of a matrix should be accessible by indices. Since the row and column indices are in the range `[0,rows)` and `[0,cols)`, its index type should also be `size_type`.
- (f) Following the C-array syntax, elements are accessed by `matrix[i][j]`.
### 2. Matrix is an element of a vector space
Matrices over a field build an algebraic set with vector-space properties:
- matrices for an additive abelian group (commutative group)
- matrices are scalable by scalars of the field type
- Multiplication with scalar is distributive with respect to addition.
These mathematical concepts result in the following requirements for the matrix type `M`:
- There is a field type associate to the matrix, i.e. `Dune::FieldType<M>::field_type` exists.
- There are arithmetic operations for matrices `A` and `B`:
* (g) `A + B`, `A - B`
* (h) `A += B`, `A -= B`
* (i) `-A`, `+A` (optional)
- Multiplication with a scalar `s` of field type:
* (j) `A * s`, `s * A`
* (k) `A *= s`
* (l) `A / s`, `A /= s`
- (m) Additionally, we typically require compound operations: `A.axpy(s, B)`
#### 2.1. Normed space and inner-product space
By defining norms over matrices and inner products, the vector spcae could be turned into a normed
vector space or an inner-product space
- Typical norm for matrices include:
* (n) `frobenius_norm()`
* (o) `forbenius_norm2()` (squared frobenius norm)
* (p) `infinity_norm()`
* (q) `infinity_norm_real()` (simplified infinity norm)
- Inner-products:
* (r) frobenius inner-product `A:B = tr(A^H A)` (not implemented by any matrix)
### 3. Matrix is a linear map
A linear transformation or linear map between vector spaces can be represented by a matrix. The operations of a linear map are typically of the form of matrix-vector products:
- (s) `A.mv(x, y)`: `y = A*x`
- (t) `A.umv(x, y)`: `y+= A*x`
- (u) `A.mmv(x, y)`: `y-= A*x`
- (v) `A.usmv(alpha, x, y)`: `y+= alpha * A*x`
If the matrix additionally provide transposed operations:
- (w) `A.mtv(x, y)`: `y = A^T * x`
- (x) `A.umtv(x, y)`: `y+= A^T * x`
- (y) `A.mmtv(x, y)`: `y-= A^T * x`
- (z) `A.usmtv(alpha, x, y)`: `y+= alpha * A^T * x`
If the matrix additionally provide hermitian operations:
- (A) `A.mhv(x, y)`: `y = A^H * x` (currently not implemented by any matrix)
- (B) `A.umhv(x, y)`: `y+= A^H * x`
- (C) `A.mmhv(x, y)`: `y-= A^H * x`
- (D) `A.usmhv(alpha, x, y)`: `y+= alpha * A^H * x`
### 4. Other operations with matrices
- (E) Matrix multiplication: `A in R^nxm` and `B in R^mxk` then `A * B in R^nxk`
* Matrices must be compatible
* square matrices might form a ring under matrix addition and matrix multiplication
this would allow `A *= B`
- (F) The transposed of a matrix: `A in R^nxm` -> `A^T in R^mxn`.
* Either an operation `A.transpose()` or a free function `transpose(A)`?
* The transposed matrix is itself a matrix
- (G) Trace of a matrix `tr(A) = sum_i A_ii`
* Assumption: matrix is square
* Either an operation `A.trace()` or a free function `trace(A)`?
* Recursive definiton: `tr(A) = sum_i tr(A_ii)`
- (H) Determinant of a matrix
* Assumption: matrix is square
* Easy to define for small matrices
* Generalization using, e.g., Laplace expansion
* Special operation: gramian determinant
- (I) Inversion of a matrix or solution of a linear system
* Assumption: matrix is square
* easy to implement for small matrices
* LU decomposition (or other forms of factorization)
### 5. Matrices can be traversed
Visiting all the (stored) elements of a matrix is a useful operation to generalize some algorithms
- Whats is a proper call for choosing the way/order of traversal?
- It exists `begin()` and `end()` functions.
* Are not documented properly but typically mean traversal of rows.
- Additionally reverse traversal is given by `beforeEnd()` and `beforeBegin()`
* Why not using `rbegin()` and `rend()` as for standard containers?
- Missing functions in the interface:
* Traversal over rows first: e.g. `begin_rows()`, `end_rows()`
* Traversal over columns first: e.g. `begin_cols()`, `end_cols()`
### 6. Special matrix types with more properties
- Sparse matrices:
* Check whether elements exist in the store is required: `A.exists(i,j)`
* Number of stored elements (nonzeros): `A.nonzeroes()`
* Iterators only iterate over stored elements/nonzeros.
* Often direct element-access not implemented (neither const nor mutable)
- Banded/Diagonal matrices:
* Special type of sparse matrix
* Additional access to diagonal(s): `A.diagonal()` (current interface does not allow return off-diagonals)
* Direct access to diagonal entries: `A.diagonal(i)`
- Triangular matrices
- Tridiagonal matrices
## Examples in dune-common
### `DenseMatrix`
A `DenseMatrix` is the CRTB base class for some matrix implementation, but it lacks some of the properties from above. Also
its documentation is partially wrong.
- (c) There are multiple functions returning number of rows/columns: `A.N()` and `A.rows()`, `A.M()` and `A.cols()`, where
`rows() -> mat_rows()` and `cols() -> mat_cols()` call the implementation functions.
- (d) is defined differently. For some reason `A.size()` returns the number of rows.
- (g) arithmetic operations not completely available for matrices, `+A` not implemented (not required)
- (j) and (l) not implemented, except for `A /= s`
- (r) There is no inner product for matrices implemented
- (A) Missing lin-map operation `A.mhv(x,y)`
- (E) binary matrix-matrix product not implemented. For square matrices the mult-assign is implemented from left and
right, i.e., `A.leftmultiply(B)` and `A.rightmultiply(B)`. The general matrix-matrix multiplication is commented out.
- (G) Trace is not implemented.
### `FieldMatrix`
Is an implementation of `DenseMatrix` thus inherits its properties. Some additional comments
- (c) Here `rows` and `cols` are enum constants hiding the interface functions `rows()` and `cols()`
- (g) FieldMatrix implements `A + B` and `A - B`
- (j) and (l) are completely implemented
- (E) Multiplication is implemented as `A * B` and `leftmultiply[any]()` and `rightmultiply[any]()`. Additional operations
are implemented in the namespace `Dune::FMatrixHelp`
### `DynamicMatrix`
Is an implementation of `DenseMatrix` thus inherits its properties.
### `DiagonalMatrix`
- (d) is defined differently. For some reason `A.size()` returns the number of rows.
- (f) The element access is only implemented for diagonal entries, i.e. `matrix[i][j]` throws if `i != j`
- (g), (j) Operations `A + B`, `A - B`, and `-A` not implemented.
- (i) compound assignment operators implemented for scalars: `A += s` and `A -= s` meaning elementwise addition and
subtraction of that scalar.
- (m) Operation `axpy` not implemented.
- (r) There is no inner product for matrices implemented
- (A) Missing lin-map operation `A.mhv(x,y)`
- (E) No matrix-matrix products implemented
- (G) Trace is not implemented.
### `TransposedMatrixWrapper`
The wrapper is created by `transpose(matrix)`, but does not produce a matrix in any sense as described above. It
has just one single operation: `A * B^T`. Note, this wrapper only works for transposing a `FieldMatrix`.
## Test of the interface
There is a test in dune-common: `checkmatrixinterface.hh` but it does not test the complete matrix interface, but just the functions
that were already implemented. Thus, this test is probably written after the implementation of the `DenseMatrix` class and
not before.
An alternative test, that is implemented in terms of separating the various aspects of a matrix, is implemented in !953
in terms of c++20 concepts. These tests can run in the ci jobs for toolchains supporting this new c++ standard and can
report interface failures.
## Major problems with the current interface
The existing matrix implementations in dune-common (but also in dune-istl) only partially fulfil the interface definition
from above and are inconsistent. Major problems are:
- Element access is not a defined property of a matrix. It is only guaranteed to succeed in some matrix implementations.
This is mainly for performance reasons. This argument is a bit weak, because there are other ways to ensure performant
data access, e.g. using iterators or specialized access functions.
- Traversal of matrices is not properly specified and cannot easily be extended to column-major traversal. `begin()` and
`end()` have no knowledge about its traversal direction. There should be a better name for row-wise traversal and
column-wise traversal. Proposal: `begin_rows()` and `begin_cols()`. Then, the user has to explicitly use a range-generator
for the iteration, e.g., `rows(matrix).begin()` and `columns(matrix).begin()`
- The iterators itself are not properly specified. Is the dereferenced iterator again a range? What does it traverse?
- Some matrices implement a single index access `matrix[r]` as a row-view onto the matrix, i.e., this operation returns a
vector-like container representing the `r`th row of the matrix. This is not clearly specified. Is this a required property
of a matrix? What are the costs of this operation? Is the row a propery vector or just a proxy providing minimal access
to the row entries?
- Especially in the implementation of geometries, one needs matrix-matrix multiplication. While this is implemented for
`FieldMatrix`, all the other matrix types lack this operation. But, e.g., `YaspGrid` returns for its jacobian a
`DiagonalMatrix`. Other grid implementations maybe something else. We need `A * B`, but also `A^T * B` and `A * B^T`
for various combinations of matrices. This is partially implemented in some "Helper" namespaces in dune-geometry or
for `FieldMatrix` in `FMatrixHelper` namespace. Multiplication seems not properly designed!
- Sparse matrices are a special type of matrices. The interface should mirror this mathematical property. Actually, sparse
matrices are just matrices with a different storage type for its entries. Thus, sparse matrices should only extend the
matrix interface with methods providing fast access to the stored elements. Either by iterators or something else. Currently,
sparse matrices only implement a partial matrix interface and some methods even have different behaviour, e.g. `matrix[i][j]`
is not guaranteed to succeed, not even for const-access, although the matrix value is clearly specified.
- Views over matrices, like transposed-view or hermitian-view are not properly implemented. They do not provide a matrix
interface although this could easily be provided. One could discuss whether views are read-only or provide mutable
access to the matrix elements as well.
- Currently, we can only test that a matrix supports all the different aspects as described above. Not the individual aspect. But, often an algorithm just needs some properties, e.g., in iterative krylov methods, one needs the linear-map properties for a matrix, for lu-decomposition maybe fast element access. In geometry parametrizations we need matrix-matrix multiplication and trace/Gramian determinant computation. It is required to have individual concept/interface checks.
- Single-row and Single-column matrices are not vectors. This often leads to problems, e.g., there is no `two_norm()` implemented and also `dot()` and `axpy` with another vector does not work, even if the shape would allow this. This problem is that vectors are not matrices and also not compatible in its interface to matrices.https://gitlab.dune-project.org/core/dune-common/-/issues/246Use CMake components when installing2023-11-13T12:12:16ZSantiago Ospina De Los Ríossospinar@gmail.comUse CMake components when installing### Description
While modernising my CMake, I realised that dune-common dumps all the installation files into the same bucket. While this is practical because one does not have to think what to install and what not, it is much cleaner t...### Description
While modernising my CMake, I realised that dune-common dumps all the installation files into the same bucket. While this is practical because one does not have to think what to install and what not, it is much cleaner to split installation in different components. This way, the user has much more control over the objects that get installed on its system or package. Doing this is simple: Adding a `COMPONENT` argument to every `install` CMake call.
### Proposal
My proposal would be to have 4 components:
| Component | Description | Example
| ------ | ------ | ------ |
| `Runtime` | Final scripts or binaries product of the module | Executables from application modules |
| `Development` | Header files and build system mandatory to continue downstream development | Header files, cmake macros |
| `Library` | Objects needed for both `Development` and `Runtime` usage in downstream modules | libraries for UGGrid or `libdunecommon` |
| `Documentation` | Documentation files | man pages, Doxygen |
In CMake, objects not assigned to any component are set to `Unspecified` (current behaviour). With the proposed setting, nothing should be in this bucket.
### Usage
Assuming components are set, installation of files in a given component is as simple as:
```bash
# User doesn't want to develop, just to link a final application
cmake --install . --component Library
# User wants to develop a downstream module
cmake --install . --component Library --component Development
# User wants to use final binaries
cmake --install . --component Library --component Runtime
# User wants to use everything (current behaviour)
cmake --install .
```
### Is this backwards compatible?
**Yes!** If no component is given on the command line (current usage), all components are installed. This means that the change is backwards compatible with any installation script out there.
### What next?
Discussion... If there seems to be agreement/interest, I can push a MR.CMake Modernizationhttps://gitlab.dune-project.org/core/dune-common/-/issues/234handling of `config.h` (proposal for dev-meeting 22.1.2021)2023-11-24T09:18:05ZChristian Engwerhandling of `config.h` (proposal for dev-meeting 22.1.2021)As discussed on the last dev-meeting, there are some issues with how we currently work with `config.h` DUNE. Our usage pattern requires all dependent applications to use the DUNE buildsystem, which is not nice.
The aim is now to clean u...As discussed on the last dev-meeting, there are some issues with how we currently work with `config.h` DUNE. Our usage pattern requires all dependent applications to use the DUNE buildsystem, which is not nice.
The aim is now to clean up this part of the buildsystem.
# Long term perspective to remove `config.h`
The `config.h` is an artifact from `autotools` time. As part of the `autotools` workflow it was automatically generated in each module or project building on top of DUNE.
In our effort to support simpler work flows for derived projects (see #199 and #188) we now face the problem, that such projects will not be able to generate the required `config.h`. Thus we need an alterantive way to *"remember"* which features are enabled and which not.
The first indea to install the `config.h` is not practical, as
- there is not the one and only `config.h`, but they are a collection of defines from different modules and their dependencies
- our `config.h` might interfere with a `config.h` generated in the user project
**The goal of this proposal is to eventually remove `config.h` completely.**
## Discussion
The current `config.h` serves a mixture of different purposes:
1. it collects a set of `HAVE_FOO` defines, which correspond to detected features
2. some `HAVE_FOO` flags map to `ENABLE_FOO` to allow enabling/disabling features for individual targets inside a project
3. preprocessor macros, which change their behaviour, depending on the results of configure checks (e.g. `LAPACK_MANGLE`)
This is kind of orthogonal to the handling of dependencies, where we define target (either real `cmake` targets or `pkg-config` files) for each module.
Many of the detected features are not used at all in DUNE, so we don't need to include these.
### Possible solutions
#### `HAVE_FOO` defines
Those defines that are necessary, i.e. they change the behaviour or DUNE headers, should be passed as command line arguments.
#### Optional: rename `HAVE_FOO`
The current preprocessor defines `HAVE_FOO` are very generic and as such the chances of collisions exist.
Thus the more far-reaching proposal is that we replace the defines with DUNE specific one, e.g. `DUNE_WITH_FOO` or `DUNE_ENABLE_FOO`.
As, in the first transition period the `config.h` is present anyway, we can use it to
- warn about the deprecation of `config.h`
- warn about the deprecation of `HAVE_FOO`
- and provide a fallback definition
```
#if DUNE_WITH_FOO
#define HAVE_FOO`
#endif
```
#### `ENABLE_FOO` magic
The `ENABLE_FOO` magic had the goal to have something like target dependent defines.
For example, consider the case that some targets should link against suitesparse and some not. The dune-istl headers will change their behaviour, depending on the presence of suitesparse.
As we now have `cmake` targets we can introduce an auxiliary target `dune-istl-suitesparse`. This target should then define the `ENABLE_SUITESPARSE` or directly `HAVE_SUITESPARSE` (or `DUNE_WITH_SUITESPARSE`) and have `suitesparse` as a dependency itself. The idea behind the naming is that this does not only mean that we use `suitesparse`, but we use the dune interface to `suitesparse`. An application would then add `dune-suitesparse` as a dependency.
We can follow the same approach for pkg-config and introduce explicitly these targets as `pc` files. By this it is possible for an application outside the DUNE buildsystem specify dependencies and get the necessary flags with a call like
```
pkg-config --clags dune-istl dune-istl-suitesparse
```
**Note:** The above example should not imply that we necessarily plan to have suitesparse as a separate target.
### additional macros
We should move these macros into separate headers, which are then included where ever needed.
For `LAPACK_MANGLE` the snippet
```
#ifdef LAPACK_NEEDS_UNDERLINE
#define LAPACK_MANGLE(name,NAME) name##_
#else
#define LAPACK_MANGLE(name,NAME) name
#endif
```
Could simply be moved to a header in dune-common.
For other cases the code is generated. The example we are currently aware are the macros needed for the DUNE_GRID_GRIDTYPE_SELECTOR. Here we can't add this code to a static header, as the code depends on the dune modules found. We argue that this header therefore does not belong into any of the DUNE modules, but it belongs into the leaf module, where the user wants to make use of this features.
We suggest to add a `cmake` macro that can be called to generate a `gridselector.hh` in the `BUILD_DIR` of a project.
**Note:** This does imply that this magic can't be used without the DUNE buildsystem, but that is also the case now.
## Final proposal
Summarizing the above discussion, we suggest the following solution
1. every DUNE module provides its own target (both `cmake` and `pkg-config`... this is planned anyway)
1. any `HAVE_FOO` flags are added to the `CFLAGS` of the corresponding target
1. the `HAVE_FOO` flags get renamed to something DUNE specific
1. `config.h` will be deprecated and only contains some code to ensure backwards compatibility
1. any `ENABLE_FOO` should become a corresponding target or be enabled by default. The corresponding `CFLAGS` will then be added to the module target or to the sub-target
1. any macros in `config.h` will be either moved to separate headers or we introduce `cmake` macros to generate the required header in the `BUILD_DIR` or the application module.CMake Modernizationhttps://gitlab.dune-project.org/core/dune-common/-/issues/227Build wheels for mac/linux2023-02-10T15:06:33ZAndreas DednerBuild wheels for mac/linuxPossibly could be done through CI using https://github.com/joerick/cibuildwheel
An example combined with pybind11: https://github.com/joerick/cibuildwheel
Also build conda packages, e.g., https://github.com/pybind/python_examplePossibly could be done through CI using https://github.com/joerick/cibuildwheel
An example combined with pybind11: https://github.com/joerick/cibuildwheel
Also build conda packages, e.g., https://github.com/pybind/python_examplehttps://gitlab.dune-project.org/core/dune-common/-/issues/221Future direction of dunecontrol2021-06-25T22:01:09ZChristoph GrüningerFuture direction of dunecontrolIn #200 a discussion about the future of dunecontrol started. I want to move the discussion here for better documentation and referencing.
There are two main directions, which I sense:
- Add features to dunecontrol to help users. The ar...In #200 a discussion about the future of dunecontrol started. I want to move the discussion here for better documentation and referencing.
There are two main directions, which I sense:
- Add features to dunecontrol to help users. The are handy to use and easy to teach.
- Try to reduce dunecontrol and make the use more compatible to to the way Compilers, CMake and Make are used in the world outside of Dune. Then users can more easily use the advice they find on Stackoverflow or what they are used from other projects.https://gitlab.dune-project.org/core/dune-common/-/issues/217dune_require_cxx_standard() not working on current macOS with AppleClang2023-03-26T18:20:04ZLukas Riedeldune_require_cxx_standard() not working on current macOS with AppleClang### System Specs
* macOS: 10.15.5 (Catalina)
* AppleClang: 11.0.0
* CMake: 3.18.2
### Problem Description
On recent versions of macOS, `dune_require_cxx_standard()` is not working and a fallback C++ standard *below* the standard speci...### System Specs
* macOS: 10.15.5 (Catalina)
* AppleClang: 11.0.0
* CMake: 3.18.2
### Problem Description
On recent versions of macOS, `dune_require_cxx_standard()` is not working and a fallback C++ standard *below* the standard specified in the command is used.
In our particular problem, we set
```cmake
dune_require_cxx_standard(MODULE "dorie" VERSION 17)
```
However, we end up with *both* a `-std=c++17` *and* a `-std=gnu++11` flag in the list of CXX compiler flags. The compiler then uses the lowest standard in the list and cannot compile our code (which is intended for C++17).
### Workaround
The problem could be remedied by either
1. Setting the `CXX_STANDARD` and `CXX_STANDARD_REQUIRED` property of the targets explicitly:
```cmake
target_set_property(${target} PROPERTIES
# Set standard to C++17
CXX_STANDARD 17
# Avoid "fallback" to lower standards if the compiler does not support the requested one
CXX_STANDARD_REQUIRED TRUE
)
```
OR...
2. Setting the C++ standard as target compile feature *(preferred solution)*:
```cmake
target_compile_features(${target} PUBLIC cxx_std_17)
```
### Possible Cause
CMake is actually *skipping* the compiler check. It might therefore not know the supported standard versions by AppleClang v11 or incorrectly set the flags checked in the code of `dune_require_cxx_standard()`. This might be an issue on CMake side. From the CMake output:
```
-- The CXX compiler identification is AppleClang 11.0.0.11000033
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Checking for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
```
### Conclusion
Workaround 1) demonstrates that `dune_require_cxx_standard()` is somehow failing its purpose on a system with the given specs.https://gitlab.dune-project.org/core/dune-common/-/issues/216[doxygen] Very restrictive timeout2020-09-30T13:46:01ZTimo Koch[doxygen] Very restrictive timeoutIn cmake/scripts/RunDoxygen.cmake a timeout of just 5min is set. For larger modules and on slower machines (or if the process runs slower because of other stuff going on) this can easily be exceeded.
In !835 I set it to one hour. The qu...In cmake/scripts/RunDoxygen.cmake a timeout of just 5min is set. For larger modules and on slower machines (or if the process runs slower because of other stuff going on) this can easily be exceeded.
In !835 I set it to one hour. The question is do we need a timeout at all?
There seems to be no way to overwrite the timeout in a downstream module. I just found out that for building the dumux docs for our website we had been patching dune-common to increase the timeout to not kill doxygen off too early.https://gitlab.dune-project.org/core/dune-common/-/issues/211MPI with C bindings and the MPI_FOUND variable2024-02-22T11:20:02ZSimon PraetoriusMPI with C bindings and the MPI_FOUND variableIn the current dune-common cmake configuration there is a macro `DuneMPI` to find the package MPI and to provide a function to set flags.
There is a comment in the header: "The DUNE way to compile MPI applications is to use the CXX comp...In the current dune-common cmake configuration there is a macro `DuneMPI` to find the package MPI and to provide a function to set flags.
There is a comment in the header: "The DUNE way to compile MPI applications is to use the CXX compiler with MPI flags usually used for C. CXX bindings are deactivated to prevent ABI problems.". Is this necessary any more? What is the actual problem with just linking against the MPI cxx target?
Why not just writing:
```cmake
find_package(MPI)
if (TARGET MPI::MPI_CXX)
target_link_libraries(dune-common PUBLIC MPI::MPI_CXX)
endif ()
```
Maybe there was a change in the meaning of `MPI_CXX` in cmake. The CXX version of MPI does not mean the MPI C++ API (removed in MPI-3), but refers to the MPI C API being usable from C++. So, why do we use `MPI_C` currently in dune-common, then?
This is discussed in https://gitlab.dune-project.org/simon.praetorius/dune-cmake/issues/1 and a related question regarding the cmake and compile flags for MPI is discussed in https://gitlab.dune-project.org/core/dune-common/-/merge_requests/804
### Proposal
- Switch to the `MPI::MPI_CXX` target
- use `MPI_FOUND` as a test that MPI is correctly found and working for all enabled languages in cmake (note, if we just enable CXX, only the MPI_CXX target will be search for) or for all searched components
- Maybe explicitly search only for the CXX component to improve configuration time.New CMake Build-SystemSimon PraetoriusSimon Praetoriushttps://gitlab.dune-project.org/core/dune-common/-/issues/209CMake find_library always called twice with and without NO_DEFAULT_PATH2020-09-21T14:50:33ZSimon PraetoriusCMake find_library always called twice with and without NO_DEFAULT_PATHIn several find modules of dune, the commands `find_library`, `find_path`, and `find_program` are called twice:
1. with option `NO_DEFAULT_PATH` that enabled all NO_* options, i.e., only search in `HINTS` and `PATHS` that are specified i...In several find modules of dune, the commands `find_library`, `find_path`, and `find_program` are called twice:
1. with option `NO_DEFAULT_PATH` that enabled all NO_* options, i.e., only search in `HINTS` and `PATHS` that are specified in the find_xxx commands.
2. without the option `NO_DEFAULT_PATH`
This is a non-standard behaviour and essential means that the paths fixed in the commands are always preferred. Is there any reason for this, that I do not see? Or is it historical, because the behaviour in cmake changed?New CMake Build-Systemhttps://gitlab.dune-project.org/core/dune-common/-/issues/208FindSuiteSparse vs. FundUMFPack2020-05-24T22:38:41ZSimon PraetoriusFindSuiteSparse vs. FundUMFPackWhy are there both, `find_package(SuiteSparse)` and `find_package(UMFPack)`? Probably, we could remove the UMFPack find package, since it is deprecated and is included in the SuiteSparse package find moduleWhy are there both, `find_package(SuiteSparse)` and `find_package(UMFPack)`? Probably, we could remove the UMFPack find package, since it is deprecated and is included in the SuiteSparse package find moduleNew CMake Build-Systemhttps://gitlab.dune-project.org/core/dune-common/-/issues/205Disabling TBB check fails cmake2021-02-04T10:41:38ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deDisabling TBB check fails cmakeThe fact that we are having `add_dune_tbb_flags` within the TBB find module breaks the CMake check disabling mechanism:
If you run cmake with `-DCMAKE_DISABLE_FIND_PACKAGE_TBB=1` the find module is never executed and any later uses of `a...The fact that we are having `add_dune_tbb_flags` within the TBB find module breaks the CMake check disabling mechanism:
If you run cmake with `-DCMAKE_DISABLE_FIND_PACKAGE_TBB=1` the find module is never executed and any later uses of `add_dune_tbb_flags` result in an `Unknown CMake command` error. My proposed solution is to move the add function out of the find module.https://gitlab.dune-project.org/core/dune-common/-/issues/203create_doc_install is superseded by UseLatexMk2020-05-15T07:29:38ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.decreate_doc_install is superseded by UseLatexMkI might be missing something here, but I think that `UseLatexMk` does everything `create_doc_install` does.
So I propose to deprecate `create_doc_install` and remove all its uses from the Core modules.I might be missing something here, but I think that `UseLatexMk` does everything `create_doc_install` does.
So I propose to deprecate `create_doc_install` and remove all its uses from the Core modules.https://gitlab.dune-project.org/core/dune-common/-/issues/186deprecated header warning not very helpful2020-02-15T14:42:52ZChristian Engwerdeprecated header warning not very helpfulCurrently deprecated headers include a `#warning` statement after the inclusion guards. This means that the warning is triggered only during the first inclusion. This might even be in one of the core modules, in case we have to support t...Currently deprecated headers include a `#warning` statement after the inclusion guards. This means that the warning is triggered only during the first inclusion. This might even be in one of the core modules, in case we have to support the deprecated interface (like in the case of function.hh).
I think it would be better to
- trigger this warning upon every inclusion f the header, this helps keeping track of all places which need to be updated
- add an `#ifndef DONT_WARN_DEPRECATED_HEADER` (or similar) to explicitly disable the warning for a particular `#include` statement and use this t avoid warning in those spots of the core modules, where we still have to use the header.
I can prepare an example patch for dune-common...https://gitlab.dune-project.org/core/dune-common/-/issues/178Installation of git-whitespace-hook2019-11-19T23:05:30ZChristoph GrüningerInstallation of git-whitespace-hookCurrently we install git-whitespace-hook to `/usr/bin` which sounds dangerous to me. I see two possibilites:
* switch the name to indicate the affiliation to dune or dune-common
* don't install the hook altogether
What do you think?Currently we install git-whitespace-hook to `/usr/bin` which sounds dangerous to me. I see two possibilites:
* switch the name to indicate the affiliation to dune or dune-common
* don't install the hook altogether
What do you think?DUNE 2.7.0https://gitlab.dune-project.org/core/dune-common/-/issues/169FieldMatrix<T, ...> should be trivially copyable for trivially copyable T2019-09-09T14:44:32ZAnsgar Burchardtansgar.burchardt@tu-dresden.deFieldMatrix<T, ...> should be trivially copyable for trivially copyable TSame as #168: `FieldMatrix<T, ...>` should be trivially copyable if this is the case for `T`.Same as #168: `FieldMatrix<T, ...>` should be trivially copyable if this is the case for `T`.DUNE 2.7.0https://gitlab.dune-project.org/core/dune-common/-/issues/168FieldVector<T, ...> should be trivially copyable for trivially copyable T2019-07-08T12:59:00ZAnsgar Burchardtansgar.burchardt@tu-dresden.deFieldVector<T, ...> should be trivially copyable for trivially copyable TI think `FieldVector<T, ...>` should be a [trivially copyable](https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable) type if `T` is trivially copyable. That allows to copy it with `memcpy` (or MPI communication functions which ...I think `FieldVector<T, ...>` should be a [trivially copyable](https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable) type if `T` is trivially copyable. That allows to copy it with `memcpy` (or MPI communication functions which should have similar requirements).
For trivial `T`, `FieldVector<T, ...>` should also be a [trivial type](https://en.cppreference.com/w/cpp/named_req/TrivialType). This just requires a trivial default constructor in additional to the requirements of a trivially copyable type.
This would also address this warning when building dune-grid:
```
dune-grid/dune/grid/uggrid/uglbgatherscatter.hh:19:15: warning:
'void* memcpy(void*, const void*, size_t)' writing to an object of type
'class Dune::FieldVector<double, 2>' with no trivial copy-assignment; use
copy-assignment or copy-initialization instead [-Wclass-memaccess]
```DUNE 2.7.0