dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-12-21T12:09:03Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3392Draft: Block-AMG in parallel2023-12-21T12:09:03ZTimo Kochtimokoch@math.uio.noDraft: Block-AMG in parallelSupersedes !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.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3383Draft: Feature/pq2 discretization2024-02-01T08:05:48ZMartin SchneiderDraft: Feature/pq2 discretizationTODOs:
- [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 schemeMartin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3240WIP: Parallel diamond2023-09-27T16:13:04ZTimo Kochtimokoch@math.uio.noWIP: Parallel diamond3.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3187Draft: Stokes permeability upscaling in parallel2023-09-27T16:16:21ZTimo Kochtimokoch@math.uio.noDraft: Stokes permeability upscaling in parallelTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3186Draft: Feature/fluxvariables flux2023-10-23T13:54:12ZTimo Kochtimokoch@math.uio.noDraft: 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-comptatibleTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3166Draft: test periodic(SP) subgrids2024-01-31T10:45:00ZNed ColtmanDraft: test periodic(SP) subgrids<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
This extends the subgrid manag...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
This extends the subgrid manager to accept subgrid of SP host grids, and to cut them using the `.pbm` create grid from image methods.
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
**Notes for the reviewer**
At the moment, periodicity is not forwarded by the subgrid interface, but a branch exists where this is done (feature/SPGrid-Periodicity). Without this branch, the additions made to the test will fail due to lack of periodicity.
In addition, the `createGridFromImage()` has been added to the base class here, as it has previously only been accepted for YASP grid variations. This may need to be changed?
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
Before you request a review from someone, make sure to revise the following points:
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [ ] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
- [x] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.
<!--
The following aspects might also come up during review:
* Does the change reduce the performance of the code (more CPU time or more memory) and is this justified by the benefits
* Does the change improve the performance? (if yes, add this aspect to the MR description)
* Is the code is a gross violation of programming best practices such as DRY (don't repeat yourself / code duplication, see https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself, the SOLID principles (https://en.wikipedia.org/wiki/SOLID), or the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)?
* Is the code well-documented, concise, easily readable? (e.g. variables are well-named, the logic is split into small & well-named functions)
-->Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3161Draft: Add a pore scale free flow test2024-01-31T10:44:59ZNed ColtmanDraft: Add a pore scale free flow test<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
This should hopefully evaluate...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
This should hopefully evaluate pressure driven free flow in more complex geometries. #1167
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
**Notes for the reviewer**
Fixes #1167
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
Before you request a review from someone, make sure to revise the following points:
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [ ] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
- [x] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [ ] is the list of the header includes complete? ("include what you use")
- [x] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.
<!--
The following aspects might also come up during review:
* Does the change reduce the performance of the code (more CPU time or more memory) and is this justified by the benefits
* Does the change improve the performance? (if yes, add this aspect to the MR description)
* Is the code is a gross violation of programming best practices such as DRY (don't repeat yourself / code duplication, see https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself, the SOLID principles (https://en.wikipedia.org/wiki/SOLID), or the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)?
* Is the code well-documented, concise, easily readable? (e.g. variables are well-named, the logic is split into small & well-named functions)
-->Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3044WIP: compositional freeflow analytical solution2023-10-26T08:46:22ZNed ColtmanWIP: compositional freeflow analytical solutionThis is an extension of the sincos test with added source terms for the compositional case.
needs !2986 firstThis is an extension of the sincos test with added source terms for the compositional case.
needs !2986 first3.9Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2930WIP: New Staggered Rans (TwoEq)2023-09-27T08:49:43ZNed ColtmanWIP: New Staggered Rans (TwoEq)fixes #807
fixes #538
fixes #951
closes !1248 (becomes obsolete)
Todos (Updated):
- [ ] For the SST Model, update the Finner, Fouter interface and remove from volvars.
- [ ] Introduce more meaningful boundary conditions, includin...fixes #807
fixes #538
fixes #951
closes !1248 (becomes obsolete)
Todos (Updated):
- [ ] For the SST Model, update the Finner, Fouter interface and remove from volvars.
- [ ] Introduce more meaningful boundary conditions, including tke and dissipation constraints
- [ ] Update spatial params to fit to !2888 with !2984
- [ ] Make runtime call an enum
- [ ] Figure out any circular dependencies between the two problems
- [ ] Include the second term of the linear eddy viscosity reynolds stress: [cfdOnline](https://www.cfd-online.com/Wiki/Linear_eddy_viscosity_models)
```math
\tau_t = 2 \mu_t S - 2/3 \rho k \delta_{ij}
```
Next MRs:
- [ ] Introduce the Kepsilon model(s) again
- [ ] Introduce the Compositional models (Separate MR)
- [ ] Introduce the Zeroeq and oneeq models (Separate MR)3.9Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2926[WIP] [staggered] Higher Order V22023-09-27T16:15:27ZKilian Weishaupt[WIP] [staggered] Higher Order V2* Use local index mapping to find relevant scvs
__TODO__
- [ ] boundary handling: Dirichlet, slip velocity -> do we need higher order at boundaries?
- [ ] implement for lateral fluxes
- [ ] Add the kovasnay tests and review tests* Use local index mapping to find relevant scvs
__TODO__
- [ ] boundary handling: Dirichlet, slip velocity -> do we need higher order at boundaries?
- [ ] implement for lateral fluxes
- [ ] Add the kovasnay tests and review tests3.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2868Draft: [TEMP] first draft of cff file generator2023-10-25T12:19:02ZDennis GläserDraft: [TEMP] first draft of cff file generatorGenerator for a cff for dumux, which could be used when tagging a new release, see https://citation-file-format.github.io/
cf !2796Generator for a cff for dumux, which could be used when tagging a new release, see https://citation-file-format.github.io/
cf !27963.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2796WIP [citation] Draft2023-06-23T19:04:32ZTimo Kochtimokoch@math.uio.noWIP [citation] Drafthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2519WIP Feature/new assembler2023-06-13T16:46:51ZDennis GläserWIP Feature/new assemblerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2494WIP Test/nonisothermal2023-07-24T13:12:10ZTimo Kochtimokoch@math.uio.noWIP Test/nonisothermalSee !2473. Based on !2471
Shows ~~unphysical~~ temperature gradient. Edit: This is expected. Even for an incompressible fluid viscous dissipation leads to small temperature changes. However, this term is not correctly implemented (see ...See !2473. Based on !2471
Shows ~~unphysical~~ temperature gradient. Edit: This is expected. Even for an incompressible fluid viscous dissipation leads to small temperature changes. However, this term is not correctly implemented (see #1256)
![Screenshot_2021-03-02_at_14.00.47](/uploads/97d41ded8307b900fa2ea99a54400903/Screenshot_2021-03-02_at_14.00.47.png)
* [x] See if we can get a better solution by adding $`\vec{v}\cdot\nabla p`$ in the energy balance somehow
Edit: adding this term leads to ignoring viscous dissipation. But does not correct the original mistake in the implementation (see #1256)
~~For incompressible fluids we have at least two options:~~
~~* Assemble internal energy fluxes instead of enthalpy fluxes, the volume work term disappears (not generic)~~
~~* Add the missing term and keep assembling enthalpy fluxes~~
The solution is to include the gravity contribution (see #1256)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1989[WIP] [linear] Add first draft of SIMPLE preconditioner2023-11-28T14:57:40ZKilian Weishaupt[WIP] [linear] Add first draft of SIMPLE preconditioner__SIMPLE__
Goal: solve
```math
\begin{pmatrix}
A & B\\
C & D
\end{pmatrix}
\begin{pmatrix}
u\\
p
\end{pmatrix}
=
\begin{pmatrix}
f\\
g
\end{pmatrix}
```
__Equations__
Exact velocity: $`~~~~~~u = u^* + \delta u ~~~~~~~ (1)`$
Ex...__SIMPLE__
Goal: solve
```math
\begin{pmatrix}
A & B\\
C & D
\end{pmatrix}
\begin{pmatrix}
u\\
p
\end{pmatrix}
=
\begin{pmatrix}
f\\
g
\end{pmatrix}
```
__Equations__
Exact velocity: $`~~~~~~u = u^* + \delta u ~~~~~~~ (1)`$
Exact pressure: $`~~~~~~p = p^* + \delta p ~~~~~~~ (2)`$
Exact velocity equation: $`~~~~~~A u + B p = f ~~~~~~~ (3)`$
Approximate velocity equation using some pressure guess $`p^*`$: $`~~~~~~A u^* + B p^* = f ~~~~~~~ (4)`$
Substract: (3-4) : $`~~~~~~A (u - u^*) + B (p-p^*) = 0 ~~~~~~~ (5)`$
$`~~~~~~A \delta u + B \delta p = 0 ~~~~~~~ (6)`$
Assumption (SIMPLE): $`~~~~~~diag(A) \approx A ~~~~~~~ (7)`$
Rearrange (6) and insert (7): $`~~~~~~\delta u = - diag(A)^{-1} B \delta p~~~~~~~ (7)`$
Mass conservation: $`~~~~~~C u = g~~~~~~~ (8)`$
$`~~~~~~C (u^* + \delta u) = g~~~~~~~ (9)`$
$`~~~~~~C (u^* + - C diag(A)^{-1} B \delta p) = g~~~~~~~ (10)`$
$`~~~~~~C u^* = g + C diag(A)^{-1} B \delta p~~~~~~~ (11)`$
Schur complement $`~~~~~~C diag(A)^{-1} B \delta p = C u^* - g ~~~~~~~ (12)`$
__Algorithm__
1.) Solve (4) for $`u^*`$
2.) Solve (12) for $`\delta p`$
3.) Get $`\delta u`$ from (7)
4.) update $`p=p^* + \alpha \delta p`$
5.) update $`u= u^* +\delta u`$
Naive implementation of https://www.cs.umd.edu/~elman/papers/tax.pdf
Converges, but is slower than Uzawa.
The internal GMRES solver to invert the Schur complement is not preconditioned yet (Richardson, w = 1).
Richardson seems to be the only preconditioner that does not require an assembled matrix.
Maybe we can write our own Jacobi preconditioner? If one can apply the action of the Schur complement without a matrix (what we do right now), is it also possible to apply the inverse of its diagonal without having the matrix?
__Udpate__ : There seem to be various matrix-free preconditioning methods
http://www2.cs.cas.cz/~tuma/ps/cutu06.pdf
https://hal.inria.fr/inria-00074080/document
http://www2.cs.cas.cz/semincm/lectures/2009-05-15-DuintjerTebbens.pdf
https://arxiv.org/pdf/1805.11930.pdf
https://arxiv.org/pdf/2006.06052.pdf
https://gitlab.dune-project.org/exadune/exadune-appl/-/blob/feature/blockiterative-preconditioner-FlexibleGMRES/src/blockiterativesolver/blockdiagonalpreconditioner.hh
A very simple (and probably expensive) option to test if preconditioning helps inverting the approximate Schur $`\tilde{S}`$ complement would be
```math
\tilde{S}^{-1}_{0,0} = \left(\tilde{S} \cdot (1, 0, ... ,n)^T \right) \cdot (1, 0, ... ,n)^T \\
\tilde{S}^{-1}_{1,1} = \left(\tilde{S} \cdot (0, 1, ... ,n)^T \right) \cdot (0, 1, ... ,n)^T \\
....
```
With that, one could construct a Jacobi preconditioner after doing n matrix vector operations.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1716WIP: Feature/explicit flashs of compositional models2023-02-22T19:17:52ZBeatrix BeckerWIP: Feature/explicit flashs of compositional models**What this MR does / why does DuMux need it**:
Introduces a 2p2c-specific constraint solver, that explicitly calculates mass fractions for two-phase state, assuming ideal mixtures (as does the generic mpnc constraint solver for two-phas...**What this MR does / why does DuMux need it**:
Introduces a 2p2c-specific constraint solver, that explicitly calculates mass fractions for two-phase state, assuming ideal mixtures (as does the generic mpnc constraint solver for two-phase state).
Changes in volumevariables: The new constraint solver is used for two-phase state. In the one-phase state the `ComputeFromReferencePhase` solver is used, since it does the simplest thing possible for ideal mixtures.
`useConstraintSolver` is deleted because it's not needed anymore.
Resolves #761
**Special notes for your reviewer**:
Is it okay to have a new header for the 2p2c-specific constraint solver or should I integrate it as a special case in the generic one? I guess this is not backward compatible (deleted `useConstraintSolver`)? Do I have to deprecate the entire old volumevariables? @holle : The 2p2c tests parse with the new constraint solver (they did so before with the old, in my opinion slightly less correct/buggy version, too, although that was never tested...). Does it look good to you, too?Holger ClassHolger Class