dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2022-03-28T09:38:52Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/141[WIP] Velocity output for prisms2022-03-28T09:38:52ZKilian Weishaupt[WIP] Velocity output for prismsBernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/484[WIP] Feature/ilupack2020-03-18T10:24:11ZKilian Weishaupt[WIP] Feature/ilupack* [ ] Update to Dumux 3 (Parameters, Properties, get rid of TypeTag)* [ ] Update to Dumux 3 (Parameters, Properties, get rid of TypeTag)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/741WIP: [2p2c] minimize private alias declarations and static variables2018-11-08T12:54:46ZBernd FlemischWIP: [2p2c] minimize private alias declarations and static variablesOn the example of two files/classes.On the example of two files/classes.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/870[WIP] Feature/seq coupl2022-03-28T09:30:28ZKilian Weishaupt[WIP] Feature/seq couplhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1248[WIP] Feature/improve rans2022-03-20T21:07:51ZKilian Weishaupt[WIP] Feature/improve ranshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1485[WIP] Feature/stokesdarcy anisotropy DO NOT MERGE2019-01-30T13:33:37ZKilian Weishaupt[WIP] Feature/stokesdarcy anisotropy DO NOT MERGE__DO NOT MERGE____DO NOT MERGE__https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1510Feature/multidomain auto bind2021-03-25T08:50:33ZDennis GläserFeature/multidomain auto bindI posed this MR into the box-facet-coupling branch so that the diff is easier to read. If we wait for !1492, which itself has to wait for !1431, then we can merge this into master at one point.
@timok, @kweis, maybe you can have a look ...I posed this MR into the box-facet-coupling branch so that the diff is easier to read. If we wait for !1492, which itself has to wait for !1431, then we can merge this into master at one point.
@timok, @kweis, maybe you can have a look at this. If we want to keep this, we would have to:
- [x] deprecate old interfaces
- [x] change all tests where cm now receives grid variables
- [x] ~~create an issue to remove the deprecated interfaces in all __facet coupling managers__ and the __poroelasticcouplingmanager__ until version 3.2 release~~ (edit Timo: don't need an issue for that)
- [x] update reference to `test_md_facet_tracer_box` (velocity is included now, which tests the MD vel output)
- [x] Put a note in the changelog that scvfs now have to implement `neighbor()`
Fixes #619.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1655[WIP] Add first draft of Boussinesq comparison2019-06-28T13:15:59ZKilian Weishaupt[WIP] Add first draft of Boussinesq comparisonDO NOT MERGE YETDO NOT MERGE YETKilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1703WIP Feature/multidomain analytic jac2022-03-28T09:36:21ZTimo Kochtimokoch@math.uio.noWIP Feature/multidomain analytic jacDennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1716WIP: Feature/explicit flashs of compositional models2022-08-31T08:03:48ZBeatrix 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?3.7Holger ClassHolger Classhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1821[WIP][md] Implement box staggered coupling2022-02-01T16:25:01ZKilian 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/1834[WIP] Feature/amg freeflow2020-01-17T14:49:30ZKilian Weishaupt[WIP] Feature/amg freeflowDo not merge this. For testing only.Do not merge this. For testing only.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1950WIP: Block-diagonal AMG in parallel2022-08-31T08:16:30ZBernd FlemischWIP: Block-diagonal AMG in parallelMake 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 GridGeometr...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);
```
So far, only `YaspGrid` works.
1. [x] Make it work for [dumux-sediment](https://git.iws.uni-stuttgart.de/dumux-appl/dumux-sediment).
2. [x] Make it work for `UGGrid` and `ALUGrid`.
3. [x] Decide where to put what.3.7Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1989[WIP] [linear] Add first draft of SIMPLE preconditioner2021-04-13T12:38:00ZKilian 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...__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/2001[WIP] Feature/python fluidsystem2022-03-28T09:40:22ZKilian Weishaupt[WIP] Feature/python fluidsystemThis is only a proof of concept.
We should decide what types of fluidsystems we want (e.g, 2pnc).
Probably, it also makes sense to create python components.This is only a proof of concept.
We should decide what types of fluidsystems we want (e.g, 2pnc).
Probably, it also makes sense to create python components.Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2012[WIP] TEMP: first draft of new staggered fvgridgeometry2020-06-26T06:43:45ZKilian Weishaupt[WIP] TEMP: first draft of new staggered fvgridgeometryThis is a first prototype for a "real" staggered fvGeometry.
Results of discussion so far:
* staggered fvGeometry contains 4 (2D quad cells) scvs and 12 scvfs
This is a first prototype for a "real" staggered fvGeometry.
Results of discussion so far:
* staggered fvGeometry contains 4 (2D quad cells) scvs and 12 scvfs
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2112WIP: Cleanup/assembly properties2021-03-25T08:52:56ZTimo Kochtimokoch@math.uio.noWIP: Cleanup/assembly properties* [ ] test everything
* [ ] update changelog for `ElementBoundaryTypes` in `LocalResidual`
* [ ] think about `NumEqVector`* [ ] test everything
* [ ] update changelog for `ElementBoundaryTypes` in `LocalResidual`
* [ ] think about `NumEqVector`Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2113WIP: Feature/new istl linear solvers2022-09-25T21:13:22ZTimo Kochtimokoch@math.uio.noWIP: Feature/new istl linear solvers* [x] Revisit template arguments
* [x] Introduce linear algebra backend or similar to make usage simpler
* [x] Adapt all linear solvers to provide `norm`
* [x] In Newton call `linearSolver->norm(r)` if available otherwise call `assembler...* [x] Revisit template arguments
* [x] Introduce linear algebra backend or similar to make usage simpler
* [x] Adapt all linear solvers to provide `norm`
* [x] In Newton call `linearSolver->norm(r)` if available otherwise call `assembler->residualNorm();` (depends on !2311 to be merged)
* [x] Deprecate conversion of multitype matrices in Newton (do in solver instead if necessary)
Depends on !2310 to be merged.
The matrix and vector type now have to be known to construct the solver.
This was previously delayed until the solve call but made the structure kind of intransparent because it wasn't really clear which vector type has to come in but only specific types work anyway.
Hard coding the solver hopefully reduces compile times wrt the factory. Also the implementation should be
* more compact than the old backends
* have more runtime option due to parameter tree-based params
* work in parallel as well
If this works out, we would deprecated the old solver backends.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2125WIP: [assembly] Add element view for assembly routines2021-02-25T21:01:55ZTimo Kochtimokoch@math.uio.noWIP: [assembly] Add element view for assembly routinesSuggestion for an element view for assembly rountinesSuggestion for an element view for assembly rountineshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2126[WIP] Feature/ff stokes reverse coupling2021-03-09T12:25:16ZKilian Weishaupt[WIP] Feature/ff stokes reverse coupling__TODO__
- [x] make backwards compatible
- [ ] fix failing tests
- [ ] implement for compositional, compressible flow
depends on !2128 !2133__TODO__
- [x] make backwards compatible
- [ ] fix failing tests
- [ ] implement for compositional, compressible flow
depends on !2128 !2133Kilian WeishauptKilian Weishaupt