dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2024-01-31T10:45:00Zhttps://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/3160Draft: Feature/perm upscaling2024-01-31T10:44:59ZTimo Kochtimokoch@math.uio.noDraft: Feature/perm upscaling<!--
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 small permeability up...<!--
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 small permeability upscaling test on a domain with a cutout sphere
* Should also be a test for Stokes domains with convex corners (see #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:
- [ ] 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.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3097Draft: Feature/test templated typetags2023-01-11T18:41:51ZTimo Kochtimokoch@math.uio.noDraft: Feature/test templated typetagshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3081Draft: Fix/parallel adaptive2023-02-22T09:09:54ZTimo Kochtimokoch@math.uio.noDraft: Fix/parallel adaptiveRelated to #264Related to #264https://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/2767fix conservation of 2p tracer2022-03-28T09:30:24ZBernd Flemischfix conservation of 2p tracerAdd a function `equilibrateTracer` which is called after each
update of the flow solution. It adapts the tracer mole fraction
according to the change in phase distribution such that the amount
of tracer in each element is conserved.
Fix...Add a function `equilibrateTracer` which is called after each
update of the flow solution. It adapts the tracer mole fraction
according to the change in phase distribution such that the amount
of tracer in each element is conserved.
Fixes #1071.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2563[components] Add component LinearizedH2O2023-09-27T16:15:58ZTimo Kochtimokoch@math.uio.no[components] Add component LinearizedH2OFixes #1013
I hope this is consistent. Water vapor is modeled as an ideal gas. inner energy and vapor pressure are linearized around the reference state. The evaporation enthalpy should be automatically included now.
I added a new com...Fixes #1013
I hope this is consistent. Water vapor is modeled as an ideal gas. inner energy and vapor pressure are linearized around the reference state. The evaporation enthalpy should be automatically included now.
I added a new component as this implementation will probably yield different results than SimpleH2O.3.9Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://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/2253[WIP] Feature/nonlinear schemes2023-07-20T13:17:36ZTimo Kochtimokoch@math.uio.no[WIP] Feature/nonlinear schemeshttps://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/1821[WIP][md] Implement box staggered coupling2023-07-25T08:58:33ZKilian Weishaupt[WIP][md] Implement box staggered couplingTodos:
- [x] Add test for segment-segment intersection algorithm
- [x] Make segment-segment intersection algorithm more efficient
- [x] Put segment-segment in different MR
- [x] Extract Box-Forchheimer to separate MR
- [x] New BJ test ...Todos:
- [x] Add test for segment-segment intersection algorithm
- [x] Make segment-segment intersection algorithm more efficient
- [x] Put segment-segment in different MR
- [x] Extract Box-Forchheimer to separate MR
- [x] New BJ test (existing test uses indefinite perm. matrix)
- [x] Change convergence script to specify convergence rate
- [ ] It currently only works for `DiffusionCoefficientAveragingType::ffOnly`
- [ ] Maxwell Stefan Diffusion law not yet implemented when using Box
- [ ] Renaming: Use ff/pm instead of stokes/darcy
- [ ] New IC assume specific parameter group "Darcy", generalise this
- [ ] Add missing tests
Suggestions:
- [x] Currently, we retrieve the entire context via `couplingContextVector()`, but the old interface is still there. I would shrink this to only one interface and probably rename it. Currently, there is one context object per coupling segment, so maybe we can find a better name.
- [x] At the moment the coupling segment geometry is stored in both the darcy and the stokes coupling info objects in the mapper. I don't think this is the most memory consuming part of the code, but there is room for memory efficiency improvements.
Fixes #788.Dennis GläserDennis Gläserhttps://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