dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-03-24T08:33:29Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3481Merge branch 'feature/standard-co2-table' into 'master'2023-03-24T08:33:29ZTimo Kochtimokoch@math.uio.noMerge branch 'feature/standard-co2-table' into 'master'3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3480Merge branch 'fix/deactivate-fcstaggered-multithreaded-assembly' into 'master'2023-03-24T04:32:43ZTimo Kochtimokoch@math.uio.noMerge branch 'fix/deactivate-fcstaggered-multithreaded-assembly' into 'master'3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3479Merge branch 'feature/property-system-aliases' into 'master'2023-03-24T08:35:39ZTimo Kochtimokoch@math.uio.noMerge branch 'feature/property-system-aliases' into 'master'3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3478[multidomain][assembly] deactivate multithreaded assembly for fcstaggered2023-07-18T11:11:17ZMathis Kelm[multidomain][assembly] deactivate multithreaded assembly for fcstaggered<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
There seems to be a race condi...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
There seems to be a race condition in multithreaded assembly for freeflow problems using a couplingmanager. Now it has been observed that also with the fcstaggered discretization simulation results can be inconsistent between runs when using multi-threaded assembly. This MR temporarily disables multithreaded assembly for the free-flow fcstaggered couplingmanager until the race condition has been found and resolved.3.7Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3477Merge branch 'feature/update-handbook-cmake' into 'master'2023-03-23T14:59:06ZTimo Kochtimokoch@math.uio.noMerge branch 'feature/update-handbook-cmake' into 'master'3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3476[handbook] Bump the required CMake version to 3.14.2023-07-18T11:11:17ZIvan Buntic[handbook] Bump the required CMake version to 3.14.<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Bump the required version of C...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Bump the required version of CMake to 3.14 in the handbook
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [x] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
<!--
The following aspects might also come up during review:
* Does the change reduce the performance of the code (more CPU time or more memory) and is this justified by the benefits
* Does the change improve the performance? (if yes, add this aspect to the MR description)
* Is the code is a gross violation of programming best practices such as DRY (don't repeat yourself / code duplication, see https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself, the SOLID principles (https://en.wikipedia.org/wiki/SOLID), or the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)?
* Is the code well-documented, concise, easily readable? (e.g. variables are well-named, the logic is split into small & well-named functions)
-->3.7Ivan BunticIvan Buntichttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3475Feature/property system aliases2023-07-18T11:11:17ZTimo Kochtimokoch@math.uio.noFeature/property system aliasesA new feature for the property system. Properties can now be "specialized" by creating an alias with the same name as a member of the type tag we would usually specialize for. This allows for a more terse notation.
Theoretically, this c...A new feature for the property system. Properties can now be "specialized" by creating an alias with the same name as a member of the type tag we would usually specialize for. This allows for a more terse notation.
Theoretically, this can replace all specializations. The only thing that specialization can do in addition is defining custom members apart from type/value that can be also extracted, but we hardly use that anywhere.
In particular, this is proposed to be useful for high-level test-level property definitions. For default (models, discretization) specialization is preferred as more explicit. In particular one would be tempted to use other alias members of the same type tag to set properties. However, this would break the inheritance (at least in case some inherits from this typetag and overwrite the property that is the dependency). For the inheritance to work one has to use `GetProp` for such and template aliases for such cases. (This works with aliases as well, it's just easier to forget because it looks like you have direct access to the other types) Naturally, this isn't a problem on the user level / leaf of inheritance, so there you can use the tersest syntax.
I added a test demonstrating how it works (based on the existing test). Also !3380 shows how this looks in application code.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3474[python] update readme for new setup2023-07-18T11:11:18ZMathis Kelm[python] update readme for new setup<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
By default we now enable pytho...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
By default we now enable python bindings. This adapts the readme instructions accordingly.3.7Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3473Remove unnecessary define UGGRID 02023-03-23T09:49:36ZHamza OukiliRemove unnecessary define UGGRID 0<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Since dune 2.6 and OPM 2018.04...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Since dune 2.6 and OPM 2018.04 are not compatible and give a compiler error, `#define HAVE_DUNE_UGGRID 0` has been added. But it produces a warning of "HAVE_DUNE_UGGRID" redefined
But now dune 2.9 and OPM 2022.10 seems to be compatible. This MR removes `#define HAVE_DUNE_UGGRID 0`
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
**Notes for the reviewer**
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
Before you request a review from someone, make sure to revise the following points:
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [ ] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
- [x] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.
<!--
The following aspects might also come up during review:
* Does the change reduce the performance of the code (more CPU time or more memory) and is this justified by the benefits
* Does the change improve the performance? (if yes, add this aspect to the MR description)
* Is the code is a gross violation of programming best practices such as DRY (don't repeat yourself / code duplication, see https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself, the SOLID principles (https://en.wikipedia.org/wiki/SOLID), or the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)?
* Is the code well-documented, concise, easily readable? (e.g. variables are well-named, the logic is split into small & well-named functions)
-->3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3472Cleanup/gridmanager only include what we use2023-03-22T23:14:22ZTimo Kochtimokoch@math.uio.noCleanup/gridmanager only include what we use3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3471[cleanup] Remove deprecated type tag for momentum model2023-03-22T14:16:05ZStefanie Kiemle[cleanup] Remove deprecated type tag for momentum model<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
fix #1231 Clean up for release...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
fix #1231 Clean up for release/3.7
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
**Notes for the reviewer**
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
Before you request a review from someone, make sure to revise the following points:
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [x] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
- [x] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.
- [x] (if not applicable remove) are newly introduced or modified physical values/functions backed up with a scientific reference (including doi) in the docs?
- [x] (if not applicable remove) if the examples are modified, is the documentation regenerated (using [`generate_example_docs.py`](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/generate_example_docs.py))
<!--
The following aspects might also come up during review:
* Does the change reduce the performance of the code (more CPU time or more memory) and is this justified by the benefits
* Does the change improve the performance? (if yes, add this aspect to the MR description)
* Is the code is a gross violation of programming best practices such as DRY (don't repeat yourself / code duplication, see https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself, the SOLID principles (https://en.wikipedia.org/wiki/SOLID), or the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)?
* Is the code well-documented, concise, easily readable? (e.g. variables are well-named, the logic is split into small & well-named functions)
-->3.7Stefanie KiemleStefanie Kiemlehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3470[staggered][disc] Deprecate scv/scvf.geometry/corner2023-03-22T10:51:29ZTimo Kochtimokoch@math.uio.no[staggered][disc] Deprecate scv/scvf.geometry/cornerUpdate for the staggered geometry that was forgotten to be updated in !3463Update for the staggered geometry that was forgotten to be updated in !34633.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3469[test][angeli] Use fvGeometry.geometry(scvf)2023-03-22T10:51:22ZTimo Kochtimokoch@math.uio.no[test][angeli] Use fvGeometry.geometry(scvf)3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3468Add missing includes2023-03-21T13:49:05ZHamza OukiliAdd missing includes<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Adds missing headers related to...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Adds missing headers related to [MR](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3462)
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
**Notes for the reviewer**
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
Before you request a review from someone, make sure to revise the following points:
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [x] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
- [x] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.
<!--
The following aspects might also come up during review:
* Does the change reduce the performance of the code (more CPU time or more memory) and is this justified by the benefits
* Does the change improve the performance? (if yes, add this aspect to the MR description)
* Is the code is a gross violation of programming best practices such as DRY (don't repeat yourself / code duplication, see https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself, the SOLID principles (https://en.wikipedia.org/wiki/SOLID), or the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)?
* Is the code well-documented, concise, easily readable? (e.g. variables are well-named, the logic is split into small & well-named functions)
-->3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3467[cmake] Bump version to 3.14 for install(SCRIPT/CODE)2023-03-21T09:27:03ZTimo Kochtimokoch@math.uio.no[cmake] Bump version to 3.14 for install(SCRIPT/CODE)This fixes a deprecation/policy warning with CMakeThis fixes a deprecation/policy warning with CMake3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3466[cmake] Make sure we build shared libs when Python is enabled and enforce C++172023-03-20T19:51:07ZTimo Kochtimokoch@math.uio.no[cmake] Make sure we build shared libs when Python is enabled and enforce C++17!3436 accidentally removed DUMUX_CMAKE_FLAGS which was used in some downstream tests to set BUILD_SHARED_LIBS for Python. The fact that is was removed shows that it wasn't clear what it's good for. We need a better mechanism that actuall...!3436 accidentally removed DUMUX_CMAKE_FLAGS which was used in some downstream tests to set BUILD_SHARED_LIBS for Python. The fact that is was removed shows that it wasn't clear what it's good for. We need a better mechanism that actually enforced our requirement of BUILD_SHARED_LIBS=ON when using Python bindings. This attempts to do this through CMake.
We also enforce C++17 by setting it as a PUBLIC interface of the dumux library.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3465[linear][istlsolvers] Improve parameter handling and allow setting a matrix o...2023-03-20T21:05:52ZTimo Kochtimokoch@math.uio.no[linear][istlsolvers] Improve parameter handling and allow setting a matrix operator for reuse* [parallelhelpers] Introduce possibility to split treatment of vector and matrix
* [linear][istlsolvers] Improve parameter handling and allow setting a matrix operator for reuse
* The solver accepts now either a parameter group or a Dun...* [parallelhelpers] Introduce possibility to split treatment of vector and matrix
* [linear][istlsolvers] Improve parameter handling and allow setting a matrix operator for reuse
* The solver accepts now either a parameter group or a Dune::ParameterTree. In the case of the latter,
the parameter tree is forwarded without modificaiton to the dune-istl solvers.
* Introduce a new function to set the maximum number of itertions
* Introduce two new interfaces "setMatrix(A)" and "solve(x, b)". The first one constructs a solver
based on the matrix A. If the new solve interface without matrix is called, this pre-constructed
solver is used in the solver. solve(A, x, b) still exists and construct a solver based on A and
ignores any stored solver. This allows to contruct a solver and then reuse it for many right hand sides.
This can be practical, for example, in parallel for linear problems
where constructing the solver involves the modificaiton
of the matrix and communication and is therefore an expensive step.
* [projection] Use istl solvers replacing old solver backends
* Use new istl solvers everywhere
* Deprecated the old solvers
* Return solver result that is convertible to bool but contains Dune::InverseOperatorResults
* Simplify parallel code branches
* Make solver copyable by using shared_ptr for parallel helper
Fixes #1220
Fixes #1230
Fixes #12233.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3464Feature/improve cvfe localassembler2023-03-19T22:21:45ZTimo Kochtimokoch@math.uio.noFeature/improve cvfe localassemblerSmall fixes in the subdomain cvfe localassemblerSmall fixes in the subdomain cvfe localassembler3.7https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3463[disc] Deprecate scv/scvf.geometry/corner2023-03-21T22:26:02ZTimo Kochtimokoch@math.uio.no[disc] Deprecate scv/scvf.geometry/cornerAddresses #1173 (makes sure we can finish this task after release 3.7 and all interfaces are properly deprecated for release 3.7).Addresses #1173 (makes sure we can finish this task after release 3.7 and all interfaces are properly deprecated for release 3.7).3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3462[assembly][cvfe] Unify CVFE assembly2023-03-21T13:09:01ZTimo Kochtimokoch@math.uio.no[assembly][cvfe] Unify CVFE assembly* [x] Unify the local and subdomain assemblers for CVFE
* [x] Unify treatment for fcdiamond on the boundary, treat like other CVFE schemes (non-compatible change)
* [x] Add changelog entry for fcdiamond
* [x] Remove obsolete local assemb...* [x] Unify the local and subdomain assemblers for CVFE
* [x] Unify treatment for fcdiamond on the boundary, treat like other CVFE schemes (non-compatible change)
* [x] Add changelog entry for fcdiamond
* [x] Remove obsolete local assemblers
depends on !3460 because it adopts that bugfix to all CVFE schemes.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.no