Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2023-02-10T15:06:33Zhttps://gitlab.dune-project.org/core/dune-common/-/issues/244use dunecontrol in module.py2023-02-10T15:06:33ZAndreas Dedneruse dunecontrol in module.pyUse `dunecontrol --print` to find all available dune modules and add to `Depends` in `dune.module. And then use
`dunecontrol --only=dune-py all`Use `dunecontrol --print` to find all available dune modules and add to `Depends` in `dune.module. And then use
`dunecontrol --only=dune-py all`https://gitlab.dune-project.org/core/dune-common/-/issues/245Using dune internal virtual env2023-02-10T15:06:33ZAndreas DednerUsing dune internal virtual envSteps (for the changes see branch `test/use_interal_duneenv`):
- I changed `DunePythonTestCommand.cmake` to use the virtual env python
- I changed `DunePythonInstallPackage.cmake` to use the virtual env python for `install_python`
- I e...Steps (for the changes see branch `test/use_interal_duneenv`):
- I changed `DunePythonTestCommand.cmake` to use the virtual env python
- I changed `DunePythonInstallPackage.cmake` to use the virtual env python for `install_python`
- I enabled the python env and build my dune modules
```
./dune-common/bin/dunecontrol --opts=config.opts all
```
- I then ran
```
./dune-common/build-cmake/run-in-dune-env \
dune-common/bin/setup-dunepy.py --opts=config.opts install
```
This installs the dune packages (editable with my `config.opts` setting) into the dune internal env (due to the use of the `run-in-dune-env` scripts). The correct cmake flags are used by the `setup-dunepy` script. This last step could be done automatically by `dunecontrol all` after configuring all dune modules.
I can now run
```
make test_python
```
in both the build directories of `dune-common` and `dune-grid` and that works fine.
The embedded tests fail at the moment because I'm not sure how to activate the correct python interpreter:
```
make test_embed1
./test_embed1
terminate called after throwing an instance of 'pybind11::error_already_set'
what(): ModuleNotFoundError: No module named 'dune.common'
Aborted (core dumped)
```
while
```
../../../run-in-dune-env ./test_embed1
```
works as expected.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/247Overhaul of the Python-CMake integration2023-03-01T11:23:16ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deOverhaul of the Python-CMake integrationTL;DR: This issue a summarizes the status quo of our Python/CMake integration and proposes some changes. You might want to have a look at the *High Level Goals* part of the proposal below to get an idea.
With the recent discussion of en...TL;DR: This issue a summarizes the status quo of our Python/CMake integration and proposes some changes. You might want to have a look at the *High Level Goals* part of the proposal below to get an idea.
With the recent discussion of enabling the Python bindings by default, our CMake extension for Python code has become more attention. So far, this extension accommodated the needs of several user groups, but did not do this in a unified, coordinated way. With the prospect of default-enabled Python bindings, additional requirements have arisen that require a bit of reengineering of the extension. This issue summarizes all technical aspects and provides a proposal.
## Prerequisistes: Defining *Installation*
This document will talk a lot about *installation*. It is worth to make some fine distinctions here:
* By *Stack Installation* we refer to a method of installing an entire Dune stack including getting all the core sources. An example of this would be Debian packages or Spack repository. We do not cover this type here, because it is not really affected. In the Python context it is important to note that `pip`-installable Dune packages are also in this category and are therefore not subject of this document, although it seems clearly Python-related.
* By *Global Installation* we refer to the installation method that we know from `make install` in C++: A set of sources and build artifacts is copied into a pre-defined directory structure under a standardized system path prefix.
* By *Local Installation* we refer to the same method as *Global installation* only that the user-given prefix that is not a system path.
* By *Package Installation* we refer to the process that is necessary to execute code in a Python environment without manual adjustments to path variables. Although global/local and Package installation of Python code use the same commands (e.g. `python -m pip install`) this still must be distinguished, as it is also part of the build process.
## Prerequisites: Workflow Stages
It is also worth distinguishing the typical stages in a user/developer workflow.
* *CMake stage*: the project is configured.
* *Build stage*: Compiling C++ sources, potentially also building tests
* *Test Stage*: Running tests on the build produced by the build stage
* *Install stage*: Perform global/local installation
## Status Quo:
Currently, the following Python-related things happen at these stages. You can skip over
this part if it is too technical for you, but I feel like there is a big need for a write-up
of this.
* CMake Stage
* Python is searched on the System. It finds the currently active Python,
which might be the System interpreter or a virtualenv that is activated
at the time CMake runs
* We determine whether the found Python is in a virtualenv
* We search for the Python package `pip`
* If the user enabled `DUNE_PYTHON_VIRTUALENV_SETUP`, a virtualenv is created.
This uses either the `virtualenv` or the `venv` package.
If the build directory tree uses an absolute prefix, this env is located in
`build-prefix/dune-python-env`, otherwise it is placed in the build directory
of `dune-common`. If `dune-common` is globally installed, the Dune module
dependency DAG is traversed to find a build directory - this procedure
potentially breaks if there is a diamond dependency pattern with some modules
of the diamond being globally installed. The created virtualenv is only exposed through
the CMake variable `DUNE_PYTHON_VIRTUALENV_EXECUTABLE`, the Python found by CMake
is still accessible. An `activate` script and `run-in-dune-env.sh` wrapper are
placed in each build directory to give users access to the created environment.
* If the virtualenv was set up, Python packages that are provided by this Dune
module are installed into the virtualenv.
* dune-testtools and modules that depend on it continue to execute Python code
during the CMake run.
* Build Stage
* Python Modules that are added with `dune_add_pybind11_module` are built.
* In dune-codegen, some C++ targets depend on a header that is generated running
Python code in the virtualenv. This is managed by the CMake command `add_custom_command`.
* dune-fufem targets link against the Python libraries to start an embedded
interpreter.
* Test Stage
* As part of `ctest`, Python tests that were added through the `dune_python_add_test`
command are executed.
* If you only want to run the Python tests, you can also do `make test_python`.
* When code using the Python bindings is first executed (likely in the test stage),
it sets up a Dune module called `dune-py` that serves as the playground for code
generation and Just-In-Time compilation. This module is currently not placed in
an isolated per-build location leading to potential compatibility issues between builds.
* Install Stage
* A global/local installation of Python packages is performed via `pip`. In contrast to C++,
the prefix choice depends on the CMake Variable `DUNE_PYTHON_INSTALL_LOCATION=user|system|none`,
where
* `none` disables installation of Python packages
* `system` uses the interpreter found by CMake
* `user` uses `pip install --user`, which installs into `~/.local`
If the variable is not set, it defaults to `system` if the found interpreter
runs in a virtualenv and `none` otherwise. The `user` option is incompatible
with virtual environments.
* A wheel (a standarized binary distribution format for Python packages) is built
for each package and installed into a location under the Dune installation prefix (called a wheelhouse).
This is necessary to allow partially installed Dune stacks: If my module depends
on dune-common - where do I get the Python package `dune.common` from? Answer: from
the Dune wheelhouse under the prefix that was used to install dune-common.
* Dependencies of Python packages are automatically installed by pip using the
Python Package Index: This requires network access. Failing to provide it currently
results in a CMake Error (pip network timeout).
* The Python-specific part of the installation can be run separately by using
the dedicated `make install_python`. This is what is advocated and used for
the Python bindings - although you need to do this before you can run the test
stage.
* All installation rules refer to the Python environment that was active when CMake ran - which
might be different from the Python environment at the time of installation.
If you want to read code for this, it is located in `dune-common/cmake/modules/DunePython*.cmake`.
The main entry point is `DunePythonCommonMacros.cmake`.
## Proposal
I am willing to implement this or a similar solution.
### High Level Goals
* With Dune being and staying a C++ project, the above workflow stages and their order should stay the same.
* *At the build stage, all Python code is package-installed into an isolated per-build environment.* (This was a fundamental outcome of the meeting: In the C++ frame of mind, Python Package Installation is part of building, not installing).
* Building a Dune stack without network access should be successful, though Python parts can be disabled in this build.
* Global/local installation of Python should install all Python packages into the Python environment that was active when CMake ran
* ~~Global/local installation of Python should depend on the Python environment at the time of installation~~ (I really wanted this to work, but thinking about it more I realized that the embedded interpreter case struggles heavily with this)
* Performing a global/local installation of the entire Dune stack (e.g. `dunecontrol make install_python`)
should make the build environment disposable.
* Running Python code should be independent of Dune-specific environment variables. (I added this one after some experiments)
### Technical Details
I think, we already have almost all of the necessary components, they just need to be slightly tweaked.
These are only some core ideas, there is a lot of detail to this that can be discussed
once I provided a sample implementation:
* The virtualenv set up is enabled by default
* The following conditions will lead to all Python aspects being disabled
* Python is not found
* Pip or virtualenv/venv are not found
* Pip operations produce a network timeout (this can still be worked around
by setting up PyPI mirrors, but this should never be part of a standard user workflow)
* After virtualenv set up, the CMake check for Python is performed again, so that
CMake only knows the virtual environment.
* Python Package installations into the virtualenv are formulated as custom targets
that are part of `all` iff the bindings are enabled.
* ~~Package installation is executed in CMake Script Mode (`cmake -P`) to allow searching
and finding the current Python environment in the installation stage.~~
* The embedded interpreter use case should use CMake generator expressions to link
to the system Python after local/global installation.
The only problematic use case that I can think of right now is the dune-testtools
one - but that mostly affects myself. I will find a way to deal with it.https://gitlab.dune-project.org/core/dune-common/-/issues/248packagemetadata.py broken.2023-04-09T13:57:11ZRobert Kpackagemetadata.py broken.@christi: patch df8d14ba6f3d253be85cdc97b2758df18ee70a73 breaks the pip packaging. Python dependencies are not listed correctly anymore. The Python-Requires keyword in dune.module is missing in the valid_entries list, which is easy to fi...@christi: patch df8d14ba6f3d253be85cdc97b2758df18ee70a73 breaks the pip packaging. Python dependencies are not listed correctly anymore. The Python-Requires keyword in dune.module is missing in the valid_entries list, which is easy to fix but also the regex match string needs to account for '-'.
Testing can be done in dune-common by calling dunepackaging.py --onlysdist
The packages listed in Python-Requires in dune.module should then appear in the generated pyproject.tomlhttps://gitlab.dune-project.org/core/dune-common/-/issues/249dune python main file2023-02-10T15:06:34ZAndreas Dednerdune python main fileSuggestion:
-----------
#. Add a `__main__.py` to `python/dune` in `dune-common` which provides an option to produce configuration output. So calling `python -m dune configuration` would generate output that can be added to a bug report...Suggestion:
-----------
#. Add a `__main__.py` to `python/dune` in `dune-common` which provides an option to produce configuration output. So calling `python -m dune configuration` would generate output that can be added to a bug report, containing for example `CMakeCache.txt` from `dune-py`,
`pip list | grep dune` and hash information of the dune modules.
#. Add a `upgrade` command to `__main__` that provides an easy way to patch a dune package without having to go through an extra upload to `pypi` (i.e. for a branch or for testing). Something like this
```
pip install scikit-build
pip install --no-cache-dir --no-deps --upgrade --no-build-isolation -i https://gitlab.dune-project.org/api/v4/projects/???/packages/pypi/simple dune-grid
```
could be executed when calling `python -m dune update -i gitlab grid`https://gitlab.dune-project.org/core/dune-common/-/issues/250AddPTScotchFlags never called2021-04-15T22:20:50ZTimo KochAddPTScotchFlags never calledThere is an `AddPTScotchFlags.cmake` but it's never called/used anywhere. I need to find PTScotch in a downstream module. What's the correct fix?
@simon.praetorius you probably know best?
There is a line in `config.h.cmake`
```
/* De...There is an `AddPTScotchFlags.cmake` but it's never called/used anywhere. I need to find PTScotch in a downstream module. What's the correct fix?
@simon.praetorius you probably know best?
There is a line in `config.h.cmake`
```
/* Define to 1 if PT-Scotch is available */
#cmakedefine HAVE_PTSCOTCH 1
```
But this seems to be never true because `HAVE_PTSCOTCH` is never set.https://gitlab.dune-project.org/core/dune-common/-/issues/251Clean up our type_traits headers (again again)2021-08-18T08:50:21ZSimon PraetoriusClean up our type_traits headers (again again)Some `Dune::Std` type-traits are not needed anymore, since there are std c++17 replacements available in all supported compilers. This should be cleaned up.
Some cleanup already is proposed in MRs:
- !935 (Remove deprecated type-traits ...Some `Dune::Std` type-traits are not needed anymore, since there are std c++17 replacements available in all supported compilers. This should be cleaned up.
Some cleanup already is proposed in MRs:
- !935 (Remove deprecated type-traits that were renamed: remove `has_nan`, `is_indexable` and `is_range` since there are CamelCase alternatives `HasNan`, `IsIndexable` and `IsIterable`)
- !936 (Deprecated `Dune::void_t` in favor of `std::void_t`. It must be tested whether all supported compilers have the same behaviour with the old replacement `Std::void_t` and the standard `std::void_t`. The implementation might be different.
- !933 (Remove cxx feature checks that are already in c++17 standard library: This deprecates the fallback implementations `Dune::Std::apply`, `Dune::Std::bool_constant`, and `Dune::Std::make_array` in favor of std c++ implementations.
In the old issue #83 some other deprecation/removals are proposed:
- `ToUniquePtr` in favor of `std::unique_ptr`, see also !912
- Deprecated `Std::is_callable` and `Std::is_invocable` in favor of `std::is_invocable` (see !969)
- Deprecate `Std::to_true_type` and `Std::to_false_type`. There is no std c++ equivalent. Use `Dune::AlwaysTrue` and `Dune::AlwaysFalse` instead. (see !971)
More deprecated functionality:
- `Std::conjunction`, `Std::disjunction`, ad `Std::negation` should be deprecated in favor of `std::conjunction`, `std::disjunction`, and `std::negation`, respectively, or simply variadic fold expressions like `(exprs &&...)` (see !972)
What is left in `dune/common/std/type_traits.hh` are the is-detected utilities (that are very helpful)
Other proposed cleanup:
- Move `field_t` and `real_t` from `dune/common/typetraits.hh` to `dune/common/ftraits.hh`https://gitlab.dune-project.org/core/dune-common/-/issues/252Meaning and Usage of ENABLE_[PACKAGE] flags2023-11-11T20:23:05ZSimon PraetoriusMeaning and Usage of ENABLE_[PACKAGE] flagsIn several discussions and issues the question came up how to use the `ENABLE_[PACKAGE]=1` compile flags, why are they introduced, what are its implications, and would it be possible to remove these flags completely.
Related issues are:...In several discussions and issues the question came up how to use the `ENABLE_[PACKAGE]=1` compile flags, why are they introduced, what are its implications, and would it be possible to remove these flags completely.
Related issues are:
- #234 (handling of `config.h`)
- #188 (Fix broken pkg-config files)
- #161 (Proper usage of add-all-flags macros)
It turns out that the `ENABLE_FOO` magic gets complicated to handle if different developments are followed: If we decide to remove the `config.h` file in favor of compiler flags, we cannot have both `HAVE_FOO` and `ENABLE_FOO` and the one depending on the other, but just one compile flag. If we always link all packages a separate enable flag would not make sense...
### Questions
- What happens if we add `ENABLE_FOO=0` in an upstream module, but compile a downstream module with `ENABLE_FOO=1`?
- What is the difference between `CMAKE_DISABLE_FIND_PACKAGE_FOO=1` and `ENABLE_FOO=0`
- [...]
### Partial List of Problems
- Changing the `ENABLE`-flag should be possible only for files that are **not** used in any module library. Otherwise we would get incompatible header and library symbols.
- Thus it can be used for tests and executables only.
- It should not be allowed to include any header file that uses a package that can potentially be deactivated.
- Problematic packages are MPI, Vc, and solvers like suitesparse and superlu if a dune interface is provided.
- If a dune header is provided that uses a package that can potentially be deactivated, it can be part of a library in downstream module A but the enable-flags changed in downstream module B and you would get a symbol clash
### Alternatives
- Formulate two groups of external packages:
1. Those that are required by dune code if found and its "enable-flag" should not be changed. Examples: MPI, TBB, Vc
2. Those that are used only in specific applications. Example: Solvers like SuiteSparse, SuperLU
- Always activate packages from group 1 if found.
- Do not activate packages from group 2 by default. The user has to explicitly call something like `add_dune_suitesparse_flags(<target>)`
- Once a package is activated for a dune module library, it is a required dependency. Must be added to the target and be exported. The `HAVE_FOO` flag is not allowed to be changed by the user. If a package should not be used in the first place, it must be deactivated by `CMAKE_DISABLE_FIND_PACKAGE_FOO=1`
- Remove all the `HAVE_FOO` defines from `config.h` related to group 2 and set these flags as compile definition when `add_dune_foo_flags` is called.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/254Generated default CMakeLists.txt2023-12-21T23:51:28ZSimon PraetoriusGenerated default CMakeLists.txt1. In the `CMakeLists.txt` file generated by `duneproject` there are some lines that are hard to understand and not documented:
```cmake
if(NOT (dune-common_DIR OR dune-common_ROOT OR
"${CMAKE_PREFIX_PATH}" MATCHES ".*dune-common.*...1. In the `CMakeLists.txt` file generated by `duneproject` there are some lines that are hard to understand and not documented:
```cmake
if(NOT (dune-common_DIR OR dune-common_ROOT OR
"${CMAKE_PREFIX_PATH}" MATCHES ".*dune-common.*"))
string(REPLACE ${CMAKE_PROJECT_NAME} dune-common dune-common_DIR
${PROJECT_BINARY_DIR})
endif()
```
The meaning is as follows:
- If there is no variable `dune-common_DIR` (or `dune-common_ROOT`) is set, and the `CMAKE_PREFIX_PATH` list does not contain
any directory containing the string `dune-common`
- Then guess the build-dir of dune-common by replacing the module name in the module build-dir by the string "dune-common".
- This constructed build-dir is used as directory to find the dune-common package.
This sounds like a wild construction to me and I always wondered why this is actually necessary.
- If we are using `dunecontrol` then the `dune-common_DIR` is explicitly passed to all built modules.
- If we are not using `dunecontrol` we should pass the directories where to find the modules explicitly instead of wild guessing. (in my opinion)
2. The second strange part of the generate `CMakeLists.txt` file is:
```cmake
list(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake/modules"
${dune-common_MODULE_PATH})
```
Here we add the cmake directory of the current dune module and the corresponding directory of dune-common to the search path `CMAKE_MODULE_PATH` variable.
- The module path of `dune-common` should be added automatically inside the `find_package` to `CMAKE_MODULE_PATH`, because this is what the package exports.
- The module specific cmake directory is currently necessary, since automatically the cmake file `Dune<Module>.cmake` is included recursively by all dune modules. I'm hoping to remove this automatic inclusion in the future in favor of an extended find-package description.DUNE 2.10.0https://gitlab.dune-project.org/core/dune-common/-/issues/255tests fail with ffast-math (using clang-11)2022-02-25T17:24:30ZAndreas Dednertests fail with ffast-math (using clang-11)On my local machine quite a few tests fail when I use -ffast-math with clang-11. An example is `fmatrixtest` which outputs
```
error: norm not NaN: frobenius_norm() on line 760 (type: Dune::FieldVector<double, 2> const)
```
`looptest` is...On my local machine quite a few tests fail when I use -ffast-math with clang-11. An example is `fmatrixtest` which outputs
```
error: norm not NaN: frobenius_norm() on line 760 (type: Dune::FieldVector<double, 2> const)
```
`looptest` is another example (with a lot of output).https://gitlab.dune-project.org/core/dune-common/-/issues/256Installed packages causing cmake trouble for source build.2024-03-02T23:44:47ZRobert KInstalled packages causing cmake trouble for source build.On an Ubuntu 20.04 system when the DUNE core packages are installed (e.g. apt install libdune-grid-dev) then the cmake for a master source tool chain fails with the following error:
CMake Warning at /usr/share/dune/cmake/modules/DunePy...On an Ubuntu 20.04 system when the DUNE core packages are installed (e.g. apt install libdune-grid-dev) then the cmake for a master source tool chain fails with the following error:
CMake Warning at /usr/share/dune/cmake/modules/DunePythonTestCommand.cmake:46 (message):
Unparsed arguments in dune_python_add_test: This often indicates typos!
Call Stack (most recent call first):
dune/python/test/CMakeLists.txt:1 (dune_python_add_test)
CMake Error at /usr/share/dune/cmake/modules/DunePythonTestCommand.cmake:54 (message):
dune_python_add_test: no COMMAND to execute specified!
Call Stack (most recent call first):
dune/python/test/CMakeLists.txt:1 (dune_python_add_test)
This means that the cmake files from the master source tree and the system get mixed up. This seem to only occur when Python bindings are enabled (-DDUNE_ENABLE_PYTHONBINDINGS=ON). However, in general it raises the question whether the mix up always occurred and it was simply not noticed.https://gitlab.dune-project.org/core/dune-grid/-/issues/132Issues with the VTKWriter2023-06-04T09:27:44ZSimon PraetoriusIssues with the VTKWriter## Summary
This issue is a collection of other issues and merge requests related to the VTKWriter. It is suggested in the last developer meeting to include the https://gitlab.dune-project.org/extensions/dune-vtk module into dune-grid, bu...## Summary
This issue is a collection of other issues and merge requests related to the VTKWriter. It is suggested in the last developer meeting to include the https://gitlab.dune-project.org/extensions/dune-vtk module into dune-grid, but this is in the long run. The short perspective would be to fix some issues with the VTKWriter:
### Interplay of VTKWriter with Python
- [ ] #97 (vtk test should use python3)
- [ ] #124 (Memory leak in Python bindings related to VTKWriter.)
### The write method and related issues
- [ ] #95 (Possibility to specifiy output path for .pvd files in VTKSequenceWriter?)
- [ ] #92 (Wrong File references in VTKSequenceWriter)
- [ ] #73 (VtkWriter behaves differently in write() and pwrite() for commSize=1)
- [ ] #168 Tensor data is not supported (but there's no documentation or helpful error message)
### Developement of the new dune-vtk interface
- [ ] #103 (Add support for higher order polynomials to VTKWriter)https://gitlab.dune-project.org/core/dune-grid/-/issues/133Issues with the GmshReader and GmshWriter2022-09-23T09:29:00ZSimon PraetoriusIssues with the GmshReader and GmshWriter## Summary
This issue is a collection of other issues and merge requests related to the GmshReader. In a long run we might want to update the implementation to https://gitlab.mn.tu-dresden.de/iwr/dune-gmsh4. The short perspective would b...## Summary
This issue is a collection of other issues and merge requests related to the GmshReader. In a long run we might want to update the implementation to https://gitlab.mn.tu-dresden.de/iwr/dune-gmsh4. The short perspective would be to fix some issues with the GmshReader and GmshWriter:
### Issues in the tests
- [ ] #117 (Heap-Buffer-Overflow in gmshtest-onedgrid)
### Boundary and Element data
- [x] #107 (New GmshReader Interface does not provide runtime-flexitbility)
- [ ] #80 (No possibility for load-balancing data attached to `boundarySegmentIndex()`)
- [x] !410 (WIP: Feature/gmsh reader dynamic interface)
- [ ] !409 (WIP: [DynamicGmshReader] Runtime-checked Interface to the GmshReader)
- [ ] !405 (WIP: [GmshReader] Interface for allowing run-time data-read decision)
- [ ] !522 ([gmshreader] Replace deprecation warning by note and todo until better solution is found)
### The Gmsh file format
- [ ] #94 (GmshWriter should add "$End" at end of file)
- [ ] #89 (GmshReader fails to ignore $PhysicalNames block)
### Related to the new implementation
- [ ] #85 (Upgrade GMSH reader to GMSH v4)
- [ ] #23 (Common interface for grid-readers)
- [ ] !90 (WIP: Implementation of a grid reader interface)https://gitlab.dune-project.org/core/dune-grid/-/issues/134Conflicting treatment of gridview/indexset in mappers2021-07-18T18:43:56ZTimo KochConflicting treatment of gridview/indexset in mappersThe `MultipleCodimMultipleGeomTypeMapper` internally stores
```
// GridView is needed to keep the IndexSet valid
GV gridView_;
const typename GV::IndexSet& is;
```
a grid view and a reference to an indexset and there is an interesting c...The `MultipleCodimMultipleGeomTypeMapper` internally stores
```
// GridView is needed to keep the IndexSet valid
GV gridView_;
const typename GV::IndexSet& is;
```
a grid view and a reference to an indexset and there is an interesting comment where I don't know if the statement is correct.
In the update method since recently, the gridview is updated, e.g.
```
void update (const GV& gridView)
{
gridView_ = gridView;
update_();
}
```
But the reference to the index set is not updated.
The `SingleCodimSingleGeomTypeMapper` stores a pointer
```
const typename GV::IndexSet* is_;
```
So apparently no gridview is needed here to keep the pointer alive.
Also update just sets the pointer
```
void update (const GV& gridView)
{
is_ = &gridView.indexSet();
}
```
without storing the gridview itself.
What are the correct guarantees offered by the interface? The implementations seem to contradict each other, so at least one of them should be buggy.
I think this should be resolved before release 2.8 since the new mapper.update(gridView) interfaces have just been introduced recently and this might be related.DUNE 2.8.0Carsten Gräsergraeser@math.fau.deCarsten Gräsergraeser@math.fau.dehttps://gitlab.dune-project.org/core/dune-common/-/issues/257Assignement of scalar values in DenseVector2023-03-13T13:33:08ZSantiago Ospina De Los Ríossospinar@gmail.comAssignement of scalar values in DenseVectorThe following doesn't work for me:
```c++
#include <dune/common/fvector>
#include <dune/istl/bvector>
using Vector = Dune::FieldVector<Dune::BlockVector<double>,2>;
Vector v;
v = 0.; // ERROR: assignement is not possible
```
<details...The following doesn't work for me:
```c++
#include <dune/common/fvector>
#include <dune/istl/bvector>
using Vector = Dune::FieldVector<Dune::BlockVector<double>,2>;
Vector v;
v = 0.; // ERROR: assignement is not possible
```
<details><summary>Error message</summary>
- Compiler: `clang-11`
- Branch: `releases/2.8`
```
[100%] Building CXX object dune/istl/test/CMakeFiles/bvectortest.dir/bvectortest.cc.o
dune-istl/dune/istl/test/bvectortest.cc:183:6: error: no viable overloaded '='
fv = 0.;
~~ ^ ~~
dune-common/dune/common/fvector.hh:144:18: note: candidate function not viable: no known conversion from 'double' to 'const Dune::FieldVector<Dune::BlockVector<double, std::allocator<double>>, 2>' for 1st argument
FieldVector& operator= (const FieldVector&) = default;
^
dune-common/dune/common/fvector.hh:147:18: note: candidate template ignored: could not match 'FieldVector<type-parameter-0-0, 2>' against 'double'
FieldVector& operator= (const FieldVector<T, SIZE>& x)
^
dune-common/dune/common/fvector.hh:154:18: note: candidate template ignored: could not match 'FieldVector<type-parameter-0-0, SIZE>' against 'double'
FieldVector& operator=(const FieldVector<T, N>&) = delete;
^
dune-common/dune/common/densevector.hh:267:26: note: candidate function not viable: no known conversion from 'double' to 'const Dune::DenseVector<Dune::FieldVector<Dune::BlockVector<double, std::allocator<double>>, 2>>::value_type' (aka 'const Dune::BlockVector<double, std::allocator<double>>') for 1st argument
inline derived_type& operator= (const value_type& k)
^
dune-common/dune/common/densevector.hh:277:18: note: candidate function not viable: no known conversion from 'double' to 'const Dune::DenseVector<Dune::FieldVector<Dune::BlockVector<double, std::allocator<double>>, 2>>' for 1st argument
DenseVector& operator=(const DenseVector&) = default;
^
dune-common/dune/common/densevector.hh:285:19: note: candidate template ignored: could not match 'DenseVector<type-parameter-0-0>' against 'double'
derived_type& operator= (const DenseVector<W>& other)
^
1 error generated.
```
</details>
I traced the error back to the [`DenseVector` assignment operator for scalars](https://gitlab.dune-project.org/core/dune-common/-/blob/6bb97962478b4252e688e8d1362e4160e9a81a7f/dune/common/densevector.hh#L266). It's set for `value_type` instead of `field_type`. If I change its argument to `field_type`, everything seems to work as expected (including `fvectortest`). But perhaps I am doing something wrong, or this is not possible because of some incompatibility?https://gitlab.dune-project.org/core/dune-common/-/issues/258CMake and dune-py.2022-01-09T21:22:32ZRobert KCMake and dune-py.When cmake is interrupted during dune-py configuration the dune-py is left in an unclean state usually requiring a re-run of setup-dunepy.py which then leads to a compete re-compilation of all python modules.When cmake is interrupted during dune-py configuration the dune-py is left in an unclean state usually requiring a re-run of setup-dunepy.py which then leads to a compete re-compilation of all python modules.Andreas DednerAndreas Dednerhttps://gitlab.dune-project.org/core/dune-common/-/issues/259document imported moduls from new CMake versions and make them usable wiht on...2023-03-13T13:29:39ZMarkus Blattdocument imported moduls from new CMake versions and make them usable wiht only the information from dune-module-config.cmakeApplies to at least FindPkgConfig and FindPython3.
As it is now users might be up for quite some surprises and maintenance for people other than the authors is quite hard.Applies to at least FindPkgConfig and FindPython3.
As it is now users might be up for quite some surprises and maintenance for people other than the authors is quite hard.DUNE 2.9.0https://gitlab.dune-project.org/core/dune-istl/-/issues/100Compiler warnings with gcc 9.32022-09-23T09:38:50ZTimo KochCompiler warnings with gcc 9.3```
dune-istl/dune/istl/paamg/transfer.hh: In instantiation of 'static void Dune::Amg::Transfer<V, V1, Dune::Amg::SequentialInformation>::prolongateVector(const Dune::Amg::AggregatesMap<V>&, Dune::Amg::Transfer<V, V1, Dune::Amg::Sequenti...```
dune-istl/dune/istl/paamg/transfer.hh: In instantiation of 'static void Dune::Amg::Transfer<V, V1, Dune::Amg::SequentialInformation>::prolongateVector(const Dune::Amg::AggregatesMap<V>&, Dune::Amg::Transfer<V, V1, Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer<V, V1, Dune::Amg::SequentialInformation>::Vector&, T, const Dune::Amg::SequentialInformation&) [with T1 = double; V = long unsigned int; V1 = Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >; Dune::Amg::Transfer<V, V1, Dune::Amg::SequentialInformation>::Vector = Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >]':
dune-istl/dune/istl/paamg/amg.hh:1124:27: required from 'void Dune::Amg::AMG<M, X, S, PI, A>::additiveMgc() [with M = Dune::MatrixAdapter<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >; X = Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >; S = Dune::SeqILU<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, 1>; PI = Dune::Amg::SequentialInformation; A = std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >]'
dune-istl/dune/istl/paamg/amg.hh:892:9: required from 'void Dune::Amg::AMG<M, X, S, PI, A>::apply(Dune::Amg::AMG<M, X, S, PI, A>::Domain&, const Range&) [with M = Dune::MatrixAdapter<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >; X = Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >; S = Dune::SeqILU<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, 1>; PI = Dune::Amg::SequentialInformation; A = std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >; Dune::Amg::AMG<M, X, S, PI, A>::Domain = Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >; Dune::Amg::AMG<M, X, S, PI, A>::Range = Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >]'
dune-istl/dune/istl/paamg/amg.hh:886:10: required from here
dune-istl/dune/istl/paamg/transfer.hh:119:10: warning: implicitly-declared 'constexpr Dune::Imp::base_array_unmanaged<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >::RealIterator<Dune::FieldVector<double, 1> >& Dune::Imp::base_array_unmanaged<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >::RealIterator<Dune::FieldVector<double, 1> >::operator=(const Dune::Imp::base_array_unmanaged<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >::RealIterator<Dune::FieldVector<double, 1> >&)' is deprecated [-Wdeprecated-copy]
119 | end=fine.end();
In file included from dune-istl/dune/istl/bvector.hh:26,
from dune-istl/dune/istl/bcrsmatrix.hh:18,
from dune-istl/dune/istl/matrixmarket.hh:29,
from dune-istl/dune/istl/owneroverlapcopy.hh:33,
from dumux/dumux/linear/parallelhelpers.hh:32,
from dumux/dumux/assembly/fvassembler.hh:34,
from dumux/test/freeflow/navierstokes/donea/main_momentum.cc:34:
dune-istl/dune/istl/basearray.hh:112:7: note: because 'Dune::Imp::base_array_unmanaged<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >::RealIterator<Dune::FieldVector<double, 1> >' has user-provided 'Dune::Imp::base_array_unmanaged<B, A>::RealIterator<T>::RealIterator(const Dune::Imp::base_array_unmanaged<B, A>::RealIterator<typename std::remove_const<T>::type>&) [with T = Dune::FieldVector<double, 1>; B = Dune::FieldVector<double, 1>; A = std::allocator<Dune::FieldVector<double, 1> >; typename std::remove_const<T>::type = Dune::FieldVector<double, 1>]'
112 | RealIterator(const RealIterator<ValueType>& it)
| ^~~~~~~~~~~~
```
```
dune-istl/dune/istl/paamg/amg.hh:919:26: warning: implicitly-declared 'Dune::Amg::Hierarchy<Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >::LevelIterator<Dune::Amg::Hierarchy<Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >, Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int> >& Dune::Amg::Hierarchy<Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >::LevelIterator<Dune::Amg::Hierarchy<Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >, Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int> >::operator=(const Dune::Amg::Hierarchy<Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >::LevelIterator<Dune::Amg::Hierarchy<Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >, Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int> >&)' is deprecated [-Wdeprecated-copy]
919 | levelContext.pinfo = matrices_->parallelInformation().finest();
In file included from dune-istl/dune/istl/paamg/matrixhierarchy.hh:13,
from dune-istl/dune/istl/paamg/amg.hh:11,
from dumux/dumux/linear/amgbackend.hh:35,
from dumux/dumux/linear/seqsolverbackend.hh:43,
from dumux/test/freeflow/navierstokes/donea/main_momentum.cc:41:
dumux/dune-istl/dune/istl/paamg/hierarchy.hh:134:9: note: because 'Dune::Amg::Hierarchy<Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >::LevelIterator<Dune::Amg::Hierarchy<Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >, Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int> >' has user-provided 'Dune::Amg::Hierarchy<T, A>::LevelIterator<T1, T2>::LevelIterator(const Dune::Amg::Hierarchy<T, A>::LevelIterator<typename std::remove_const<T>::type, typename std::remove_const<T1>::type>&) [with C = Dune::Amg::Hierarchy<Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >; T1 = Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>; T = Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>; A = std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >; typename std::remove_const<T1>::type = Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>; typename std::remove_const<T>::type = Dune::Amg::Hierarchy<Dune::OwnerOverlapCopyCommunication<Dune::bigunsignedint<96>, int>, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >]'
134 | LevelIterator(const LevelIterator<typename std::remove_const<C>::type,
| ^~~~~~~~~~~~~
```DUNE 2.9.0