dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-03-02T19:51:13Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3417[disc][projection] add missing dune functions include2023-03-02T19:51:13ZDennis Gläser[disc][projection] add missing dune functions includean include was missing for `makeGridViewFunction`.an include was missing for `makeGridViewFunction`.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3416Doxygen/remove shell script2023-03-02T14:29:47ZTimo Kochtimokoch@math.uio.noDoxygen/remove shell scriptWait for !3367 to be merged.Wait for !3367 to be merged.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3415[ci] temporary fix for conflicts with opm cmake setup2023-03-01T16:46:04ZDennis Gläser[ci] temporary fix for conflicts with opm cmake setupAdds a (temporary) fix for the python tests in the CI when opm is installed (OPM is not used in the python tests anywhere). A proper solution probably needs upstream changes, but until then, this seems to make the CI pass...
TODO:
- [x...Adds a (temporary) fix for the python tests in the CI when opm is installed (OPM is not used in the python tests anywhere). A proper solution probably needs upstream changes, but until then, this seems to make the CI pass...
TODO:
- [x] commits should be squashed upon merge3.7Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3413Fix/istl solvers can communicate2023-02-28T18:58:54ZTimo Kochtimokoch@math.uio.noFix/istl solvers can communicateFixes #1229Fixes #12293.7Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3412[ci] Test against dumux-lecture 3.52023-02-28T13:32:16ZTimo Kochtimokoch@math.uio.no[ci] Test against dumux-lecture 3.5Note: tests against dune-maste have already been removed.Note: tests against dune-maste have already been removed.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3411[ci] Don't test release 3.6 against dune master2023-02-28T15:57:08ZTimo Kochtimokoch@math.uio.no[ci] Don't test release 3.6 against dune masterDennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3410Cleanup/doxygen freeflow and embedded2023-02-28T18:28:46ZDennis GläserCleanup/doxygen freeflow and embeddedAdds a few `doxygen` fixes in the freeflow module and the embedded coupling managerAdds a few `doxygen` fixes in the freeflow module and the embedded coupling manager3.7Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3409[material][platonicbody] use single ingroup2023-02-28T13:14:49ZDennis Gläser[material][platonicbody] use single ingroupthe `doxygen` build in the CI raised warnings from this header, because apparently aliases cannot be defined in multiple groups? The log says, for instance
```sh
warning: Member TwoPLocalRulesPlatonicBodyDefault found in multiple @ingro...the `doxygen` build in the CI raised warnings from this header, because apparently aliases cannot be defined in multiple groups? The log says, for instance
```sh
warning: Member TwoPLocalRulesPlatonicBodyDefault found in multiple @ingroup groups! The member will be put in group PoreNetworkModels, and not in group Fluidmatrixinteractions
```
So apparently doxygen takes the last appearing group. I changed this to use the `fluidmatrixinteractions` group, as in principle, one could use these classes independent of a pore network model (for whatever reason)?
This is what the [doxygen docs](https://www.star.bnl.gov/public/comp/sofi/doxygen/grouping.html) say about grouping:
"Note that compound entities (like classes, files and namespaces) can be put into multiple groups, but members (like variable, functions, typedefs and enums) can only be a member of one group (this restriction is to avoid ambiguous linking targets)."3.7Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3407Fix missing include and missing CMake test guard2023-02-27T23:07:13ZChristoph GrüningerFix missing include and missing CMake test guard<!--
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**:
Add missing CMake guard for UM...<!--
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**:
Add missing CMake guard for UMFPack to tracer tests
Add header that is no longer automatically included with upcoming GCC and Clang versions.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3405Resolve "[frictionlaws] Roughnessheight calculation in friction laws"2023-03-09T14:27:10ZLeopold StadlerResolve "[frictionlaws] Roughnessheight calculation in friction laws"<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**Make adding artificial water depth in friction laws optional**:
TODO:
- [x]...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**Make adding artificial water depth in friction laws optional**:
TODO:
- [x] adapt limitRoughH in frictionlaw.hh for zero roughnessHeight
- [x] make roughnessHeight optional parameter (default = 0.0) for Manning
- [x] make roughnessHeight optional parameter (default = 0.0) for Nikuradse
- [x] Improve documentation in friction laws
Add some tests
- [x] Add test Nikuradse
<!--
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**
I added a new rough channel example with limited Nikuradse friction law to ensure that the changes will work. All previous tests and examples produce the same results since the water depth was always large enough or no friction law was applied.
Should these changes are mentioned somewhere?
<!--
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)
-->
Closes #1216Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3404Feature/seq stokes solver2023-02-27T23:56:34ZTimo Kochtimokoch@math.uio.noFeature/seq stokes solver* Adds a solver specialized for the Stokes problem
* Add a helper to symmetrize Dirichlet, this can be used to make sure a symmetric matrix stays symmetric. Moreover it sometimes seems to help in the solver even for slightly non-symmetri...* Adds a solver specialized for the Stokes problem
* Add a helper to symmetrize Dirichlet, this can be used to make sure a symmetric matrix stays symmetric. Moreover it sometimes seems to help in the solver even for slightly non-symmetric problems
* Test solver in the benchmark test3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3403Fix CI python tests with dune 2.92023-03-01T17:44:25ZMathis KelmFix CI python tests with dune 2.9<!--
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**:
With Dune 2.9 python bindings ...<!--
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**:
With Dune 2.9 python bindings are active by default. In the minimal setups we want to test only minimal dependencies and not the python bindings. The `test python` job attempts to run the python tests and gives warning "No tests were found!!!". The job is still treated as passed.
<!--
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.7Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3401Feature/helmholtz operator2023-02-24T08:20:38ZTimo Kochtimokoch@math.uio.noFeature/helmholtz operator* Add a Helmholtz operator assemble useful for solver testing or as a component in a preconditioner
* Add a test using the Helmholtz operator and the multi-threaded AMG smoothers (there is a nice speed-up)
The operator is based on the i...* Add a Helmholtz operator assemble useful for solver testing or as a component in a preconditioner
* Add a test using the Helmholtz operator and the multi-threaded AMG smoothers (there is a nice speed-up)
The operator is based on the initial implementation in !3240 where it was used as a Stokes solver component3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3399[ci] Update the ci to use dune 2.92023-02-23T14:58:01ZHamza Oukili[ci] Update the ci to use dune 2.9<!--
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**:
It updates the CI gitlab to te...<!--
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**:
It updates the CI gitlab to test dumux master with dune 2.9 instead of 2.8 / DuMux 3.7 will not support dune 2.8
<!--
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.
-->
Fixes #12263.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3398[fix][md] Add Residual vector to Multidomain traits and fix multidomain conve...2023-03-14T20:16:13ZAnna Mareike Kostelecky[fix][md] Add Residual vector to Multidomain traits and fix multidomain convergence writer* ResidualVector is added to the multidomain traits
* The `MultiDomainNewtonConvergenceWriter` is adapted such that `SolutionVector` type and the `ResidualVector` type are distinguished, as introduced in !3385.
Fixes #1227
- [x] does...* ResidualVector is added to the multidomain traits
* The `MultiDomainNewtonConvergenceWriter` is adapted such that `SolutionVector` type and the `ResidualVector` type are distinguished, as introduced in !3385.
Fixes #1227
- [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.7Anna Mareike KosteleckyAnna Mareike Kosteleckyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3397[preconditioners] Add three preconditioners2023-02-23T18:23:37ZTimo Kochtimokoch@math.uio.no[preconditioners] Add three preconditioners* Thread-parallel Jacobi smoother/preconditioner
* Thread-parallel SOR/SSOR with coloring
* They can be selected via the factory
* They can be used with AMG as smoother (but not unfortunately not via the factory yet)
The reason being tha...* Thread-parallel Jacobi smoother/preconditioner
* Thread-parallel SOR/SSOR with coloring
* They can be selected via the factory
* They can be used with AMG as smoother (but not unfortunately not via the factory yet)
The reason being that Dune currently hard-coded the selection of available smoothers.
We would have to write our own AMGCreator to include them. Probably better to find an
upstream solution.
The tests added for the richards test only add a few seconds in runtime because the solver factory is used anyways.
Because the grid is quite small in the test multi-threading actually makes them slightly slower. But for larger grids
there is a speedup.
Extracted from !32403.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3394Cleanup/partitioningyaspgrid2023-02-23T17:12:18ZHamza OukiliCleanup/partitioningyaspgrid<!--
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**:
It eliminates gridmanager_yasp...<!--
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**:
It eliminates gridmanager_yasp warning about the use of the new interface
<!--
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.
-->
Fixes #1224
**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/3393[solver] Use thread parallel linear operator2023-02-23T06:57:34ZTimo Kochtimokoch@math.uio.no[solver] Use thread parallel linear operatorAdds multihreading capability to some multitype solver linear operators showing some speedup of the tests.
Header extracted from !3240Adds multihreading capability to some multitype solver linear operators showing some speedup of the tests.
Header extracted from !32403.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3391[test] Use ignore option for test script instead of zero threshold2023-03-14T18:01:35ZHarsha Pallamharsha.pallam@iws.uni-stuttgart.de[test] Use ignore option for test script instead of zero threshold<!--
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**:
Instead of using very large ze...<!--
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**:
Instead of using very large zero thresholds, we tried to replace them by using the (ignore) option
<!--
Is there a corresponding issue? Add "Fixes hashtag 1209" 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.
-->
Fixes #1209
<!--
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.7Harsha Pallamharsha.pallam@iws.uni-stuttgart.deHarsha Pallamharsha.pallam@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3390[disc] Add simple L2 projection implementation and test2023-02-22T15:21:59ZTimo Kochtimokoch@math.uio.no[disc] Add simple L2 projection implementation and testTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.no