dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-07-18T11:11:20Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3503[doxygen] Update doxygen for 3.72023-07-18T11:11:20ZTimo Kochtimokoch@math.uio.no[doxygen] Update doxygen for 3.7* Remove broken Files tab
* Update installation instruction to 3.7* Remove broken Files tab
* Update installation instruction to 3.73.7https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3506[readme] Update links to doxygen2023-07-18T11:11:19ZTimo Kochtimokoch@math.uio.no[readme] Update links to doxygenFixes links after docs were moved to the doxygen documentationFixes links after docs were moved to the doxygen documentation3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3492[doc] update the parameter list2023-07-18T11:11:19ZYue Wangyue.wang@iws.uni-stuttgart.de[doc] update the parameter list<!--
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**:
fixes #1236
<!--
Is there a co...<!--
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**:
fixes #1236
<!--
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.
-->
<!--
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.7Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3493[bin/getparam] add new mode option 'ignore' to remove the entry in parameter ...2023-07-18T11:11:19ZYue Wangyue.wang@iws.uni-stuttgart.de[bin/getparam] add new mode option 'ignore' to remove the entry in parameter list.<!--
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**:
added the new option `mode:ign...<!--
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**:
added the new option `mode:ignore` in json file to deprecate some parameters in output.
<!--
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.
-->
<!--
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.7Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3380[example] Add simple diffusion eqution including full model2023-07-18T11:11:19ZTimo Kochtimokoch@math.uio.no[example] Add simple diffusion eqution including full model* [x] Turn it into a documented example using the doc generator* [x] Turn it into a documented example using the doc generator3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3482Fix/update versions for release 3 72023-07-18T11:11:19ZHamza OukiliFix/update versions for release 3 7<!--
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**:
Update versions in dune.module...<!--
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**:
Update versions in dune.module and installation files for the 3.7 release.
<!--
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.
-->
- [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/3490[examples] unify formatting of overview2023-07-18T11:11:19ZMartin Schneider[examples] unify formatting of overview3.7Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3484[test] fix missed tests to use new default-co2-table2023-07-18T11:11:19ZMathis Kelm[test] fix missed tests to use new default-co2-table<!--
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**:
Some tests were missed in !345...<!--
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**:
Some tests were missed in !3455, and the MR CI didn't detect them as affected. This MR fixes them.
<!--
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**
TODO: insert text here
<!--
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.7Mathis KelmMathis Kelmhttps://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/3485[python][fix][properties] Recognize the new property macro2023-07-18T11:11:18ZTimo Kochtimokoch@math.uio.no[python][fix][properties] Recognize the new property macroFixes #1237
Fixes a bug introduced by !3479 which adds a new way of defining properties but didn't adjust the Python bindings.Fixes #1237
Fixes a bug introduced by !3479 which adds a new way of defining properties but didn't adjust the Python bindings.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3389[example] cahn hilliard including full model2023-07-18T11:11:18ZTimo Kochtimokoch@math.uio.no[example] cahn hilliard including full modelSimilar intent as example of !3380 implementing a nonlinear model with two equations.
Parallel should work with e.g. `DUMUX_NUM_THREADS=1 mpirun -np 4 ./example_cahn_hilliard` (multi-threaded assembly will not help much because the main ...Similar intent as example of !3380 implementing a nonlinear model with two equations.
Parallel should work with e.g. `DUMUX_NUM_THREADS=1 mpirun -np 4 ./example_cahn_hilliard` (multi-threaded assembly will not help much because the main time is the solver, could try different solver with !3386 or the solver factory).
* [x] Add example description and doc generator3.7Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3455Feature/standard co2 table2023-07-18T11:11:18ZYue Wangyue.wang@iws.uni-stuttgart.deFeature/standard co2 table<!--
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**:
see discussion in #1164.
The f...<!--
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**:
see discussion in #1164.
The file `co2tables.hh` is moved into the `components`.
The template for `make_co2_table.py` includes the namespace and can be flexibly included.
<!--
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.7Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://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/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/3559Merge branch 'cleanup/finalize-changelog-for-3.7' into 'master'2023-04-26T10:20:19ZHamza OukiliMerge branch 'cleanup/finalize-changelog-for-3.7' into 'master'3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3556Merge branch 'update/changelog-3-7release' into 'master'2023-04-26T04:54:08ZTimo Kochtimokoch@math.uio.noMerge branch 'update/changelog-3-7release' into 'master'3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3555Merge branch '1240-installexternal-py-fails-to-download-metis' into 'master'2023-04-25T15:27:33ZHamza OukiliMerge branch '1240-installexternal-py-fails-to-download-metis' into 'master'3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3553Merge branch 'fix/make_example_pnm1pupscling_pass_ctest' into 'master'2023-04-21T09:41:03ZHamza OukiliMerge branch 'fix/make_example_pnm1pupscling_pass_ctest' into 'master'3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3550Merge branch 'fix/changesolver-to-sequential' into 'master'2023-04-20T11:50:15ZMathis KelmMerge branch 'fix/changesolver-to-sequential' into 'master'3.7Hamza OukiliHamza Oukili