dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2022-06-02T11:50:20Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3156Merge branch 'feature/facecentered_localidxfix' into 'master'2022-06-02T11:50:20ZYue Wangyue.wang@iws.uni-stuttgart.deMerge branch 'feature/facecentered_localidxfix' into 'master'[facecentered][convexcorner] fix the local Index logic
See merge request dumux-repositories/dumux!3154
(cherry picked from commit 60653203934979eef3d84388abb0619d0355cb43)
b7c21f27 [facecentered][convexcorner] fix the local Index logic[facecentered][convexcorner] fix the local Index logic
See merge request dumux-repositories/dumux!3154
(cherry picked from commit 60653203934979eef3d84388abb0619d0355cb43)
b7c21f27 [facecentered][convexcorner] fix the local Index logic3.5Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3157reorder changelog2022-06-02T11:50:52ZBernd Flemischreorder changelogReorder the changes from 3.4 to 3.5 in the changelog.Reorder the changes from 3.4 to 3.5 in the changelog.3.5Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3158Merge branch 'cleanup/reorder-changelog' into 'master'2022-06-02T11:52:37ZBernd FlemischMerge branch 'cleanup/reorder-changelog' into 'master'reorder changelog
See merge request dumux-repositories/dumux!3157
(cherry picked from commit bcb693e3e5339b2b699fe7b5b2b626fc45d836fa)
5eb589c6 reorder changelogreorder changelog
See merge request dumux-repositories/dumux!3157
(cherry picked from commit bcb693e3e5339b2b699fe7b5b2b626fc45d836fa)
5eb589c6 reorder changelogBernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3159[bin][installdumux] avoid using distutils2022-06-03T09:41:56ZDennis Gläser[bin][installdumux] avoid using distutils<!--
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**:
Removes usage of `distutils` p...<!--
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**:
Removes usage of `distutils` package in the dumux install script, as we now get a warning because the package is deprecated ([see here](https://peps.python.org/pep-0632/#:~:text=In%20Python%203.10%20and%203.11,platforms%20will%20not%20be%20added))
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [x] do the test pipelines pass? (scheduled to merge if succeeds)
- [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] 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.
Fixes #11663.6Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3160Draft: Feature/perm upscaling2024-01-31T10:44:59ZTimo Kochtimokoch@math.uio.noDraft: Feature/perm upscaling<!--
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 a small permeability up...<!--
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 a small permeability upscaling test on a domain with a cutout sphere
* Should also be a test for Stokes domains with convex corners (see #1167)
<!--
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:
- [ ] 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.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3161Draft: Add a pore scale free flow test2024-01-31T10:44:59ZNed ColtmanDraft: Add a pore scale free flow test<!--
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**:
This should hopefully evaluate...<!--
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**:
This should hopefully evaluate pressure driven free flow in more complex geometries. #1167
<!--
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**
Fixes #1167
<!--
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`.
- [ ] 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)
-->Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3162[cleanup][test][porenetwork] removing setPreviousSolution call2022-06-03T09:32:33ZKai Wendel[cleanup][test][porenetwork] removing setPreviousSolution callThere are only three tests that use a function call in the form of assembler->setPreviousSolution(xOld).
If this line is deleted and the tests compiled again, they perform exactly in the same way as before, therefore I would suggest, to ...There are only three tests that use a function call in the form of assembler->setPreviousSolution(xOld).
If this line is deleted and the tests compiled again, they perform exactly in the same way as before, therefore I would suggest, to remove this call as access to the old solution is already given when the constructor of the assembler is called.
This raises the question, whether this setPreviousSolution() method shall be deleted completely, as it is not called anywhere else except those three tests, or if it is maybe left as it could be used under other circumstances3.6Kai WendelKai Wendelhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3163[test][donea][mom][cleanup] Identity mapping is simpler with iota2022-06-04T18:38:01ZTimo Kochtimokoch@math.uio.no[test][donea][mom][cleanup] Identity mapping is simpler with iota3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3164[cleanup][ff][couplingmanager] Remove unused header2022-06-04T18:48:54ZTimo Kochtimokoch@math.uio.no[cleanup][ff][couplingmanager] Remove unused headerTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3165Feature/stamped subgrid2022-09-25T21:44:16ZNed ColtmanFeature/stamped subgrid<!--
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**:
This allows the user to develo...<!--
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**:
This allows the user to develop a domain consisting of multiple stamped images, extending the existing `createGridFromImage_()` functionality.
<!--
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**
Within !3160 the subgrid grid manager is extended to accept 3D "images" using a BinaryMask file. There should be no conflicts, but extending the stamping parts of this MR to the 3D grid should also be possible.
<!--
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.6Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3166Draft: test periodic(SP) subgrids2024-01-31T10:45:00ZNed ColtmanDraft: test periodic(SP) subgrids<!--
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**:
This extends the subgrid manag...<!--
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**:
This extends the subgrid manager to accept subgrid of SP host grids, and to cut them using the `.pbm` create grid from image methods.
<!--
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**
At the moment, periodicity is not forwarded by the subgrid interface, but a branch exists where this is done (feature/SPGrid-Periodicity). Without this branch, the additions made to the test will fail due to lack of periodicity.
In addition, the `createGridFromImage()` has been added to the base class here, as it has previously only been accepted for YASP grid variations. This may need to be changed?
<!--
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)
-->Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3167Draft: [temp] Test precompiled solver factory from dune istl branch2023-12-13T10:52:21ZTimo Kochtimokoch@math.uio.noDraft: [temp] Test precompiled solver factory from dune istl branch<!--
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**:
TODO: insert text here
<!--
I...<!--
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**:
TODO: insert text here
<!--
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:
- [ ] 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))
- [ ] 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)
- [ ] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [ ] is the list of the header includes complete? ("include what you use")
- [ ] 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.
- [ ] (if not applicable remove) are newly introduced or modified physical values/functions backed up with a scientific reference (including doi) in the docs?
- [ ] (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)
-->Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3168[python] Update .pylintrc2022-06-24T09:20:37ZTimo Kochtimokoch@math.uio.no[python] Update .pylintrcThe py2/3 compatibility layer has been removed https://github.com/PyCQA/pylint/pull/4942The py2/3 compatibility layer has been removed https://github.com/PyCQA/pylint/pull/4942Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3169Merge branch 'fix/pylint-after-py3comp-removed-upstream' into 'master'2022-06-24T09:31:00ZTimo Kochtimokoch@math.uio.noMerge branch 'fix/pylint-after-py3comp-removed-upstream' into 'master'[python] Update .pylintrc
See merge request dumux-repositories/dumux!3168
(cherry picked from commit c70af7c770a65803ea3e3b8a513191d4e8548f15)
df85511a [python] Update .pylintrc
00ebef23 [python][pylint] Use path relative to pylintrc ...[python] Update .pylintrc
See merge request dumux-repositories/dumux!3168
(cherry picked from commit c70af7c770a65803ea3e3b8a513191d4e8548f15)
df85511a [python] Update .pylintrc
00ebef23 [python][pylint] Use path relative to pylintrc in init-hook
a8a8d434 [python][pylint] Rename section MASTER -> MAIN after upstream change
0a48c8b2 [python][pylint] Fixup init hookTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3170Cleanup/deprecated2022-07-23T11:31:50ZStefanie KiemleCleanup/deprecated<!--
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**:
This merge request is supposed...<!--
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**:
This merge request is supposed to remove the deprecated lines of code, headers and files trailing after release/3.5.
The corresponding issue is described in #1163.
<!--
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**
Fixes #1163
<!--
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.3.6Stefanie KiemleStefanie Kiemlehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3171Separate extended 1.5phase Richards model into a separate model2022-10-05T12:41:25ZSina AckermannSeparate extended 1.5phase Richards model into a separate 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**:
See Issue #1165
- [x] keep or...<!--
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 Issue #1165
- [x] keep original richards folder with deprecation warnings
- [x] adapt richardsextended folder, inherit from richards1p
- [x] adapt tests: `richards/nonisothermal/evaporation` uses the extended model
<!--
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)?
- [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.6Sina AckermannSina Ackermannhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3172[ci][default] allow setting max_cxx_standard and add C++20 pipeline2022-07-27T11:47:40ZDennis Gläser[ci][default] allow setting max_cxx_standard and add C++20 pipeline<!--
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 a pipeline with C++20 and...<!--
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 a pipeline with C++20 and dune master, and pushes the corresponding pipeline with C++17 from MR to the scheduled pipelines.
<!--
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**
Fixes #1169
Depends on !3227 to be merged first
<!--
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))
- [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.3.6Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3173WIP: encapsulate operations in the volvars update method2023-09-27T16:15:46ZNed ColtmanWIP: encapsulate operations in the volvars update method<!--
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**:
This merge request should remo...<!--
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**:
This merge request should remove duplicated code often seen in the volvars' update functions. This issue is outlined in #814.
<!--
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**
@tufan, @nedc, @hanchuan, @yue
**Question: **
does it make sense to add new headers to the dumux/material/constraintsolvers/ directory, or would another location make more sense?
<!--
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:
- [ ] 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)
- [ ] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [ ] 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.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3174[mpnc] add an initial helper that makes the choice of the constraintsolver de...2022-07-28T08:25:53ZKatharina Heck[mpnc] add an initial helper that makes the choice of the constraintsolver depending on present phasesThis fixes #1109 .
We add a helper that decides on the constraintsolver to use to compute fugacities etc to use as initial conditions for the mpnc model based on if all phases are present or not
Todo
- [x] this does not work with the c...This fixes #1109 .
We add a helper that decides on the constraintsolver to use to compute fugacities etc to use as initial conditions for the mpnc model based on if all phases are present or not
Todo
- [x] this does not work with the chemical non-equilibrium tests. Technically chemical non-equilibrium does not need to use a constraintsolver as not fugacities are the primary variables but mole fractions one can choose as one likes. The kinetic test only uses a constraintsolver as first the equilibrium state is calculated and then a deviation from that state is set as primary variables. Check if it makes sense to leave the chemical non-equilibrium test then as it is.
- [x] check thermalnonequilibrium test. why does this not work with the constraintsolver
- [x] Wrap FluidState in helper and provide setters for necessary stuff (pressures/saturations/moleFractions/temperature)Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3175[1d3d] Copy privars only once and use the correct numeric epsilon for the ext...2022-06-29T14:07:10ZTimo Kochtimokoch@math.uio.no[1d3d] Copy privars only once and use the correct numeric epsilon for the extended source stencil* Copying privars only once for efficiency.
* Using the correct epsilon fixes a bug (bad Jacobian approximation) for zero initial data and/or when the epsilon
is given in the input file* Copying privars only once for efficiency.
* Using the correct epsilon fixes a bug (bad Jacobian approximation) for zero initial data and/or when the epsilon
is given in the input file3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.no