dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2022-08-13T18:33:47Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3249Draft: Implementation of navier-stokes cvfe model2022-08-13T18:33:47ZMartin SchneiderDraft: Implementation of navier-stokes cvfe modelImplements a cvfe discretization for Navier-StokesImplements a cvfe discretization for Navier-StokesMartin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3247Draft: Control-volume finite-element discretization2022-08-12T22:54:52ZMartin SchneiderDraft: Control-volume finite-element discretization**What this MR does / why does DuMux need it**:
* Implements a new discretization scheme (box + cell unknown)
* Implements a 1p porous medium test
* Tests the discretization
** ToDo
- [ ] Cleanup geometryhelper, maybe use tuple
- [ ] I...**What this MR does / why does DuMux need it**:
* Implements a new discretization scheme (box + cell unknown)
* Implements a 1p porous medium test
* Tests the discretization
** ToDo
- [ ] Cleanup geometryhelper, maybe use tuple
- [ ] Implement MultithreadedAssembly
- [ ] Implement ParallelizationMartin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3212Draft: staggered par2023-12-13T10:52:22ZTimo Kochtimokoch@math.uio.noDraft: staggered parsee if there is anything from here that can be reused on mastersee if there is anything from here that can be reused on masterTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3210Draft: python dune master bugfix test DO NOT MERGE2022-07-20T16:42:01ZTimo Kochtimokoch@math.uio.noDraft: python dune master bugfix test DO NOT MERGE<!--
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/3207Draft: Feature/bin find non tested headers2023-12-13T10:52:21ZDennis GläserDraft: Feature/bin find non tested headers<!--
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 script to determine hea...<!--
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 script to determine headers of a dumux project that are not included by its test suite. This could be included into the test suite to ensure that any new header is covered in the test suite.
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? (TODO: introduce a fake change to check that selection still works)
- [ ] 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)Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3206Draft: [pm/1p] add initialfluidstate to encapsule completefluidstate function.2023-12-13T10:51:33ZYue Wangyue.wang@iws.uni-stuttgart.deDraft: [pm/1p] add initialfluidstate to encapsule completefluidstate function.<!--
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**:
An `InitialFluidState` is intr...<!--
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**:
An `InitialFluidState` is introduced to improve the `completeFluidState`.
See also #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**
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)
-->Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3203Draft: [box] Add cache to hide implementation interface from the grid geometr...2022-09-05T17:37:26ZTimo Kochtimokoch@math.uio.noDraft: [box] Add cache to hide implementation interface from the grid geometry public interfaceTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3182Draft: Feature/new experimental assembly2023-12-13T10:52:22ZDennis GläserDraft: Feature/new experimental assembly<!--
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)
-->
potential steps/milestones:
- [ ] use some external lib for solution of the linear system (e.g. Eigen) -> makes sure the layout is flexible enough to make use of non-dune-solvers
- [ ] set up a toy example with time dependency to properly integrate `TimeStepper` into the new assembly layout.
- [ ] set up a toy multidomain example to ensure that support for multitypeblockvectors/matrices can be realized
- [ ] implement actual assembler and realize poisson problem
- [ ] make stationary 1p test work
- [ ] make instationary test work
- [ ] make a 2p2c test work (privarswitch should be tried to be put into `GridVariables::update()` such that newton is agnostic of that
- [ ] check that multidomain test with privar switch works with the new assembly layoutDennis GläserDennis Gläserhttps://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/3139Feature/incompressible stokes solver2023-02-24T22:42:35ZTimo Kochtimokoch@math.uio.noFeature/incompressible stokes solver3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3130[fix] use referece instead of copy in loop2022-05-25T18:23:22ZYue Wangyue.wang@iws.uni-stuttgart.de[fix] use referece instead of copy in loop3.5Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3123Draft: fix test freeflow-pornetwork2022-05-25T13:27:55ZMaziar VeyskaramiDraft: fix test freeflow-pornetworkhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3118Draft: [test][richards] Add test case on the square to see influence (-> diff...2023-12-13T10:52:21ZTimo Kochtimokoch@math.uio.noDraft: [test][richards] Add test case on the square to see influence (-> difference...https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3108Merge branch 'fix/fmt-for-use-with-opm' into 'master'2022-05-11T07:18:18ZYue Wangyue.wang@iws.uni-stuttgart.deMerge branch 'fix/fmt-for-use-with-opm' into 'master'Move fmt to Dumux namespace
Closes #1150
See merge request dumux-repositories/dumux!3099
(cherry picked from commit ffa6d36ff84da95458da34c02ea2a4c796448f15)
dc5d7d03 [fmt] move implementation to namespace Dumux
27942de6 [test] Use F...Move fmt to Dumux namespace
Closes #1150
See merge request dumux-repositories/dumux!3099
(cherry picked from commit ffa6d36ff84da95458da34c02ea2a4c796448f15)
dc5d7d03 [fmt] move implementation to namespace Dumux
27942de6 [test] Use Fmt in cornerpoint test3.5Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3065[cmake]update cmakelists2022-04-26T12:03:29ZYue Wangyue.wang@iws.uni-stuttgart.de[cmake]update cmakelists3.5Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3053Feature/use inialize in tests2022-04-22T17:08:39ZTimo Kochtimokoch@math.uio.noFeature/use inialize in tests3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3051Draft: Feature/grid geometry observer2023-12-13T10:52:21ZDennis GläserDraft: Feature/grid geometry observerAllows observing grid geometries such that the observers can be notified in case the grid changesAllows observing grid geometries such that the observers can be notified in case the grid changesTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3047Draft: Feature/improve poroelastic doc2022-04-26T10:11:54ZDennis GläserDraft: Feature/improve poroelastic docDepends on !3046Depends on !30463.5Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3045Draft: feature/improve-geomechanics-documentation2022-04-13T14:29:36ZDennis GläserDraft: feature/improve-geomechanics-documentationYue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3036Improve documentation for 2p flow tests2022-03-30T15:07:49ZStefanie KiemleImprove documentation for 2p flow tests