dumux merge requests
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests
2023-07-27T13:04:26Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3624
Draft: [doxygen][highleveldocs] update overview
2023-07-27T13:04:26Z
Ned Coltman
Draft: [doxygen][highleveldocs] update overview
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
**Notes for the reviewer**
I would like to go through the "overview" page and change a few things, ...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
**Notes for the reviewer**
I would like to go through the "overview" page and change a few things, but we should definitely discuss a bit first.
These were just a few quick changes that we can talk about tomorrow.
Ned Coltman
Ned Coltman
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3616
Draft: Feature/energy balance porous media
2024-03-28T10:34:39Z
Timo Koch
timokoch@math.uio.no
Draft: Feature/energy balance porous media
Fix #1256
Fix #1256
3.9
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3588
Feature/hld solver
2023-07-27T13:03:39Z
Kai Wendel
Feature/hld solver
Ned Coltman
Ned Coltman
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3587
Feature/hld iofields
2023-07-27T12:40:46Z
Kai Wendel
Feature/hld iofields
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
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)
-->
Kai Wendel
Kai Wendel
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3573
Draft: Cvfe ff-pm coupling
2023-08-23T13:45:05Z
Martin Schneider
Draft: Cvfe ff-pm coupling
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
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)
-->
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3570
Draft: Feature/gridvar based assembly
2023-07-26T13:18:25Z
Dennis Gläser
Draft: Feature/gridvar based assembly
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
An attempt to add the minimum changes necessary to support grid-vars-based assembly with the new grid variables interface (i.e. not carrying `prevGridVars`, but representing one state of the solution)...
Adds a helper class to detect if the given grid vars have the "new interface" (detecting `gridVars.volVars()`), which is used in several places to alter the behaviour of certain classes. For instance, the `LocalAssembler` is changed to operate as such:
```cpp
LocalAssembler localAssembler{..., gridVariables};
localAssembler.assembleJacobian(matrix);
```
instead of the current
```cpp
LocalAssembler localAssembler{..., curSol};
localAssembler.assemble(matrix, gridVars); // gridVars must actually fit to curSol :/
```
This implementation actually does not make use of the `localView` concept of grid variables, in order not to have to touch all the interfaces. As mentioned, the idea was to do the minimum necessary to enable gridvars-based-assembly.
Supersedes !3570, which should be closed in case we prefer this.
<!--
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)
-->
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3564
WIP: [tpfa] Add possiblity for custom boundary function
2024-02-23T22:09:13Z
Timo Koch
timokoch@math.uio.no
WIP: [tpfa] Add possiblity for custom boundary function
I needed to mark certain intersections as boundaries although they are not boundaries in the grid (i.e. have a neighbor). This can be for example a touching point/edge for networks that should be marked as a boundary. One possibility is ...
I needed to mark certain intersections as boundaries although they are not boundaries in the grid (i.e. have a neighbor). This can be for example a touching point/edge for networks that should be marked as a boundary. One possibility is to modify the grid to double the vertex/edge. Another possibility is implemented in this MR and is providing a function that determined which intersections are boundaries.
Rough implementation, can be improved. For example, I don't think the function actually has to be stored. It's enough to pass it to update I think.
* [ ] Remove debug output
* [ ] pass function to update
3.9
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3561
Draft: [sincos][navierstokesnc] sincos with two components in old staggered
2023-10-25T16:05:19Z
Kai Wendel
Draft: [sincos][navierstokesnc] sincos with two components in old staggered
don't merge this!
We tried to implement the sincos test with navierstokesnc in the old staggered.
don't merge this!
We tried to implement the sincos test with navierstokesnc in the old staggered.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3560
Draft: feature/gridvars-based-assembly
2023-07-20T08:31:30Z
Dennis Gläser
Draft: feature/gridvars-based-assembly
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
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 changes the assembly mechanism to operate on grid variables rather than solution vectors. This solves two issues:
- the grid vars stored in the assembler, so far, were expected to be in sync with the solution vector passed into the `assemble` function. However, this was not really obvious.
- the grid vars in the assembler were "magically" updated in the background in calls to `newtonSolver.solve(x)`. This is now not magical anymore because one writes `newtonSolver.solve(gridVars)`
The old assembly behaviour looked something like this:
```cpp
LocalAssembler la{assembler, element, curSol};
la.assemble(jacobian, gridVars...); // so these grid vars should match with curSol, right?
```
I changed this to something like:
```cpp
LocalAssembler la{assembler, element, gridVars};
la.assemble(jacobian);
```
The grid variables now expose a local view that internally contains local views on the grid volume variables and the flux vars cache. The new `GridVariables` contain information on the time level on which they are defined and this time level can be retrieved from the `elemVariables`, and thus, this provides the means to forward time information into problem interfaces as e.g. `neumann`.
`GridVariables` are now tied to one specific time level, the interface `prevGridVolVars()` has been removed. Instead, in this proposition one carries `prevGridVariables` in the main file (instead of `xOld`) and passes that to the assembler.
A general point of discussion:
- In case we want this change, how should we proceed? Currently, this introduces breaking changes. I guess we have a few options:
- 1. We could add this as separate classes/functions, (possibly) deprecating the old ones. Then, we could make more and more tests use the new interfaces bit by bit.
- 2. We may make it nice, adapt all tests to the new style directly and merge -> this way we directly check how it plays out over all of dumux and test it thorougly. Independent on how it plays out in the context of the time bug, it may be viewed as an improvement for the time being. However, this would mean we make dumux master targetting `4.0`..
- 3. Basically do `2` but on a dedicated `4.0` branch that we leave open until we have fixed the time bug in follow-up-branches. However, we'll eventually have to rebase, keep things in sync, etc.
- 4. We leave this on a branch in some intermediate state and keep working on the time bug in follow-up branches, and only finish all branches once we see that the steps actually do take us to fixing the bug for some selection of tests. The issue here is again that we'll have to do heavy rebasing etc (probably).
I personally think `2` would be the "easiest", although most cumbersome for users who want to keep their code working with master. But if we go for `2.`, I guess we'd have to make an announcement via the mailing list that we are entering a refactoring phase and that people should stay on a release branch for some time.
If we keep going with this, some more things to discuss:
- [ ] `neumann` now has access to time info via the `elemVars`, but `boundaryTypes` and `dirichlet` don't. There, we should/could maybe directly pass in an instance of `TimeLevel`? We could make it `auto boundaryTypes(const Element&, const Scv&, const std::optional<TimeLevel>& = {})` to make it explicit that this may be optional (i.e. in stationary settings it shouldn't be passed).
- [ ] so far I only modified whatever was necessary for TPFA to work. Other schemes should also be modified.
- [ ] in many places, this just forwards `elemVars.elemVolVars()` and `elemVars.elemFluxVarsCache()` to the old interfaces that expected them separately. Maybe there could be some harmonization done.
- [ ] The `element` argument has been removed in some interfaces, because it is implicitly carried in `fvElementGeometry`. In the flux functions it was left in, because it could be some element of the stencil, not necessarily the bound one. On the other hand, via the `scvf` one could retrieve the inside element, if necessary. We could check if we could remove the argument from those interfaces as well and/or double-check if we shouldn't have removed them from some in the first place...
- [ ] The assembler now receives a non-const reference to `GridVariables` to assemble the jacobian. That is not so nice, but was required because in the case of caching we deflect the grid vars directly. So far, the `Assembler` received a const ref to a solution, however, it carried a non-const reference to grid vars internally. So the current master has the same "issue", this change just makes it more explicit/obvious. Without a performance penalty (e.g. making a copy, which would introduce memory overhead) I don't see how to circumvent this, though.
<!--
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)
-->
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3421
Draft: Feature/bspline function
2023-09-27T16:13:00Z
Dennis Gläser
Draft: Feature/bspline 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**:
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)
-->
3.9
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3414
Draft: [densitydrivenflow] tried to use the simple preconditioner, but type d...
2023-03-06T16:00:34Z
Kai Wendel
Draft: [densitydrivenflow] tried to use the simple preconditioner, but type deduction fails
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.
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 Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3406
Draft:Feature/high level documentation
2023-10-13T13:43:37Z
Leon Keim
Draft:Feature/high level documentation
**What this MR does / why does DuMux need it**:
Adds the highlevel concepts documentation
**What this MR does / why does DuMux need it**:
Adds the highlevel concepts documentation
3.9
Leon Keim
Leon Keim
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3400
Draft: Parallel diamond
2024-03-26T15:28:16Z
Timo Koch
timokoch@math.uio.no
Draft: Parallel diamond
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3392
Draft: Block-AMG in parallel
2023-12-21T12:09:03Z
Timo Koch
timokoch@math.uio.no
Draft: Block-AMG in parallel
Supersedes !1950
Make the `BlockDiagAMGBiCGSTABSolver` work in parallel.
On the user side, this requires passing argument and template tuples. For the currently working test in `multidomain/poroelastic/el1p`, this amounts to
```cpp
...
Supersedes !1950
Make the `BlockDiagAMGBiCGSTABSolver` work in parallel.
On the user side, this requires passing argument and template tuples. For the currently working test in `multidomain/poroelastic/el1p`, this amounts to
```cpp
using GridGeometries = std::tuple<OnePFVGridGeometry, PoroMechFVGridGeometry>;
using LinearSolver = BlockDiagAMGBiCGSTABSolver<GridGeometries>;
auto views = std::make_tuple(std::cref(leafGridView), std::cref(leafGridView));
auto mappers = std::make_tuple(onePFvGridGeometry->dofMapper(), poroMechFvGridGeometry->dofMapper());
auto groups = std::make_tuple(std::string("OneP"), std::string("PoroElastic"));
auto linearSolver = std::make_shared<LinearSolver>(views, mappers, groups);
```
1. [x] Make it work for [dumux-sediment](https://git.iws.uni-stuttgart.de/dumux-appl/dumux-sediment).
2. [x] Make it work for `YaspGrid`, `UGGrid` and `ALUGrid`.
3. [x] Decide where to put what.
3.9
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3383
Draft: Feature/pq2 discretization
2024-02-01T08:05:48Z
Martin Schneider
Draft: Feature/pq2 discretization
TODOs:
- [x] Jacobian Pattern can be generalized by using localCoefficients (-> master)
- [x] ElementSolutions can also be generalized by using localCoefficients
- [ ] Think about non-overlapping partition for 2d case (not possible in 3...
TODOs:
- [x] Jacobian Pattern can be generalized by using localCoefficients (-> master)
- [x] ElementSolutions can also be generalized by using localCoefficients
- [ ] Think about non-overlapping partition for 2d case (not possible in 3D)
- [x] Can we generalize the subdomain NS assemblers (-> master)
- [ ] IstlSolverFactoryBackend for pq2 scheme
Martin Schneider
Martin Schneider
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3256
Draft: [pq1bubble] Add Navier-Stokes model parallel
2023-09-27T16:15:35Z
Timo Koch
timokoch@math.uio.no
Draft: [pq1bubble] Add Navier-Stokes model parallel
3.9
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3240
WIP: Parallel diamond
2023-09-27T16:13:04Z
Timo Koch
timokoch@math.uio.no
WIP: Parallel diamond
3.9
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3187
Draft: Stokes permeability upscaling in parallel
2023-09-27T16:16:21Z
Timo Koch
timokoch@math.uio.no
Draft: Stokes permeability upscaling in parallel
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3186
Draft: Feature/fluxvariables flux
2023-10-23T13:54:12Z
Timo Koch
timokoch@math.uio.no
Draft: Feature/fluxvariables flux
<!--
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**
Fixes #1156
* [ ] Make interface in energylr changes backwards-comptatible
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3173
WIP: encapsulate operations in the volvars update method
2023-09-27T16:15:46Z
Ned Coltman
WIP: 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.9