dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-02-27T23:56:34Zhttps://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/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/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/3408[doxygen][staggered] fix missing group titles2023-02-28T18:27:04ZDennis Gläser[doxygen][staggered] fix missing group titlesAddresses a few `doxygen` warnings from missing group titles for staggered schemes.Addresses a few `doxygen` warnings from missing group titles for staggered schemes.3.7Dennis 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/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/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/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/3367[ci] add job for doxygen docu build2023-03-02T12:36:10ZDennis Gläser[ci] add job for doxygen docu build<!--
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 build of the `doxygen` ...<!--
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 build of the `doxygen` documentation to the `build` stage in one of our 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.
-->
Fixes #1187
<!--
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.
<!--
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.7Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3349Feature/cvfe improvements2023-03-02T12:51:05ZTimo Kochtimokoch@math.uio.noFeature/cvfe improvementsUnify several files for all cvfe schemes to reduce code duplication
* Reduce code duplication in Navier-Stokes momentum model and coupling manager
* Deprecated separate coupling managers and separate Navier-Stokes momentum models
* Add ...Unify several files for all cvfe schemes to reduce code duplication
* Reduce code duplication in Navier-Stokes momentum model and coupling manager
* Deprecated separate coupling managers and separate Navier-Stokes momentum models
* Add `elementIndex` for box element geometry like for the other CVFE schemes3.7Martin SchneiderMartin Schneiderhttps://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/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/3419WIP: [doxygen] Use markdown in doxygen and introduce high-level docu.2023-03-03T16:25:45ZIvan BunticWIP: [doxygen] Use markdown in doxygen and introduce high-level docu.Insert beginning of high-level docu into old branch.Insert beginning of high-level docu into old branch.Ivan BunticIvan Buntichttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3414Draft: [densitydrivenflow] tried to use the simple preconditioner, but type d...2023-03-06T16:00:34ZKai WendelDraft: [densitydrivenflow] tried to use the simple preconditioner, but type deduction failsI tried to use the simple preconditioner for a navierstokesnc problem.
The block size has changed in this problem compared to the karman vortex street problem.
It is not clear to me, how we should change the types.I tried to use the simple preconditioner for a navierstokesnc problem.
The block size has changed in this problem compared to the karman vortex street problem.
It is not clear to me, how we should change the types.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3420Use std::format instead of fmt, if availalbe2023-03-07T21:08:35ZChristoph GrüningerUse std::format instead of fmt, if availalbe3.7https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3386New istl linear solvers2023-03-08T07:45:40ZTimo Kochtimokoch@math.uio.noNew istl linear solversMR description (based on !2213):
* [x] Revisit template arguments
* [x] Introduce linear algebra backend or similar to make usage simpler
* [x] Adapt all linear solvers to provide `norm`
* [x] In Newton call `linearSolver->norm(r)` if a...MR description (based on !2213):
* [x] Revisit template arguments
* [x] Introduce linear algebra backend or similar to make usage simpler
* [x] Adapt all linear solvers to provide `norm`
* [x] In Newton call `linearSolver->norm(r)` if available otherwise call `assembler->residualNorm();` (depends on !2311 to be merged)
* [x] Deprecate conversion of multitype matrices in Newton (do in solver instead if necessary)
* [x] Fix parallel helper to work with UG
Depends on !3385 to be merged
The matrix and vector type now have to be known to construct the solver.
This was previously delayed until the solve call but made the structure kind of intransparent because it wasn't really clear which vector type has to come in but only specific types work anyway.
Hard coding the solver hopefully reduces compile times wrt the factory. Also the implementation should be
* more compact than the old backends
* have more runtime option due to parameter tree-based params
* work in parallel as well
* [x] ~~We could deprecated the old solver backends? (not the entire header though)~~ different MR
Updated version as replacement for !2113.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3423Update installexternal.py latest dune, opm and Mmesh2023-03-08T09:21:58ZHamza OukiliUpdate installexternal.py latest dune, opm and Mmesh<!--
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**:
Updates installexternal.py 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**:
Updates installexternal.py to use latest dune, opm and Mmesh
<!--
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/3424Fix CMakeLists for test use Gmsh instead of gmsh2023-03-08T10:47:39ZHamza OukiliFix CMakeLists for test use Gmsh instead of gmsh<!--
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 CMakeLists for tests usi...<!--
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 CMakeLists for tests using Gmsh.
<!--
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/3418Cleanup/resolve istlsolver depracations2023-03-09T08:53:38ZHamza OukiliCleanup/resolve istlsolver depracations<!--
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 deprecation warnings r...<!--
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 deprecation warnings related to the AMGBackend in the tests.
<!--
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.
-->
Related to #1223
**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 Oukili