dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-07-20T13:17:36Zhttps://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/2244Feature/update box couplingdata2020-10-27T13:28:29ZMartin SchneiderFeature/update box couplingdataUpdate the box coupling such that it works for general non-matching grids.
This is done by introducing general projections onto the stokes faces.Update the box coupling such that it works for general non-matching grids.
This is done by introducing general projections onto the stokes faces.Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2203WIP: [test] Add Karman vortex street application2021-10-19T07:59:06ZTimo Kochtimokoch@math.uio.noWIP: [test] Add Karman vortex street applicationRuns way too long to be a good test. Maybe also a good test case for solvers though. And looks fairly cool
![vortexstreet-small](/uploads/9bf4bcf66398ba24bbaccb32d17a00b2/vortexstreet-small.gif)
Update: I got a big speedup by using...Runs way too long to be a good test. Maybe also a good test case for solvers though. And looks fairly cool
![vortexstreet-small](/uploads/9bf4bcf66398ba24bbaccb32d17a00b2/vortexstreet-small.gif)
Update: I got a big speedup by using the SIMPLE-preconditioned BiCGSTABSolver of !1989 https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2201[WIP] Feature/new staggered impl2022-05-05T10:47:41ZKilian Weishaupt[WIP] Feature/new staggered impl__TODO__
_General:_
- [ ] Fix docu (especially copy and paste errors)
- [ ] Rethink assembly strategy (forward / inverse)?
- [x] Introduce coupling stencils per DOF?
- [x] improve design of "dual" problem
- [x] boundary flux helpers
- [ ...__TODO__
_General:_
- [ ] Fix docu (especially copy and paste errors)
- [ ] Rethink assembly strategy (forward / inverse)?
- [x] Introduce coupling stencils per DOF?
- [x] improve design of "dual" problem
- [x] boundary flux helpers
- [ ] prohibit Dirichlet for mass model?
- [x] check difference in Jacobian for compressible fluids (channel)
- [x] periodic grids
- [ ] Look into benefits of caching options
- [ ] Add volume work to energy balance
@nedc:
- [x] Set up higher order geometry
- [x] Port the TVD methods
- [x] Add correct checks for various boundary conditions
- [x] Add useful tests for higher order
- [ ] Update and include the rans models
@kweis:
- [x] coupling (staggered-cellcentered)
- [x] implement Beavers-Joseph BC
- [x] Compositional models (1pnc)
@martins
- [ ] Finalize box-staggered coupling (old staggered)
- [ ] Port box-staggered to new staggered
- [ ] Develop new freeflow discretizations (long term)
@hanchuan
- [x] port and test Navier stokes tests (should have been completed already by @kweis)
- [x] port compositional tests (after 1pnc is updated)
- [ ] port stokes-darcy MD tests (after MD is updated)
- [ ] port rans tests (after rans is updated)
fixes #756Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2162[WIP] Feature/restructure ff fluxvars2020-06-04T09:38:21ZKilian Weishaupt[WIP] Feature/restructure ff fluxvarshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2130WIP Feature/finite element method2020-10-16T08:57:48ZDennis GläserWIP Feature/finite element methodThis is a first draft of an FEM framework. Currently, major limitations/assumptions are:
* assumes Standard-Galerkin approach
* assumes non-composite dune function space bases
I have tried to incorporate suggestions stemming from ...This is a first draft of an FEM framework. Currently, major limitations/assumptions are:
* assumes Standard-Galerkin approach
* assumes non-composite dune function space bases
I have tried to incorporate suggestions stemming from the discussion in #884, in particular it is:
1. The state of the grid variables was always dependent on the problem (e.g. due to BCs) and a current solution. Nevertheless, we had grid variables and problem and cursol as arguments in several assembly-related functions. In particular, we did `assembler.assemble(curSol)`. The assembler introduced here fulfills this interface (for compatibility with NewtonSolver), but does not use curSol. Instead, the assembler is instantiated with grid variables, which are updated with a solution and a problem. Thus, the assembler takes the solution and problem from the grid variables. So, you would want to do `Assembler assembler(gridVariables); assembler.assemble()`. This could help implementing other time stepping schemes, where you create grid variables on different time levels (stages), make an assembler from them and let it assemble the stage. The assembler is basically a copy of `FVAssembler`, which was almost general and non fv-specific. There is one piece of commented code related to parallelism with box (with a todo in the comment) which has to be figured out still.
2. Local assemblers are now a `localView` of the assembler, no which you then call `bind` with only an element. The problem & current solution are extracted from the grid variables with which the assembler was instantiated. This guarantees that a wrong combination of _problem state_, _solution state_ and _grid variables state_ is passed to it.
3. None of the classes use the property system anymore. I wrote a little test solving a poisson equation, which completely works without the property system. See test/discretization/fem/poisson. Therein, a problem and local residual have to be implemented. Currently, I implemented it in a "Dumux conforming" way, also implementing a spatial parameters class that stores the tensor and an "IntegrationPointVariables" class (the equivalent of vol vars in fv schemes), which hold the tensor at an integration point. The test implementation could be simplified very much if the custom local residual simply called `problem.getTensor()` or so - that would get rid of the spatial params and the integration point variables implementations. I did it this way for now to illustrate the complete workflow for implementing a new model and test.
All of this is subject to discussion, and all new headers have "TODOs" all over the place which can be discussed.https://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 Weishaupthttps://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/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/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 Classhttps://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/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/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/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/1248[WIP] Feature/improve rans2022-03-20T21:07:51ZKilian Weishaupt[WIP] Feature/improve ranshttps://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/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/141[WIP] Velocity output for prisms2022-03-28T09:38:52ZKilian Weishaupt[WIP] Velocity output for prismsBernd FlemischBernd Flemisch