dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2023-07-14T14:41:12Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/940Clean incoporation of new time integration methods2023-07-14T14:41:12ZDennis GläserClean incoporation of new time integration methods@timok, @bernd, @kweis, @martins and I are currently discussing/developing the incorporation of a generic time integration framework in Dumux. In general, time handling is currently problematic in Dumux and leads to a bug in MultiDomain ...@timok, @bernd, @kweis, @martins and I are currently discussing/developing the incorporation of a generic time integration framework in Dumux. In general, time handling is currently problematic in Dumux and leads to a bug in MultiDomain (#792, #619).
The following work plan is currently envisioned to incorporate the features into an `Experimental` namespace while guaranteeing that the current features and tests on master still work:
1. [x] introduce new grid variables concept, where they represent the complete state of a simulation - thus, not only secondary but also primary variables and possibly a time level. (see !2285)
2. introduce new assembly concept <br>
- [x] make `NewtonSolver`, `PDESolver` accept both assemblers that assemble around given `SolutionVectors` or more generic `Variables` (see !2291) <br>
- [x] add time step methods (see !2296)<br>
- [ ] add generic version of `FVAssembler`, which assembles around `Variables` and uses the time integration methods (see !2519)<br>
- [ ] Introduce solution state (name is to be discussed) class that substitutes elementSolution during the assembly - that is, as argument to volume variables updates and in spatial parameters interfaces. The concept of this state class is to carry time information in addition to the element solution, that can be used within user interfaces. (!2520)
- [ ] Introduce context class, that wraps the local views after bind in order to pass that into the user interfaces. That reduces the number of arguments in a bunch of interfaces, and moreover, we usually have interfaces like `function(element, fvGeometry, elemVolVars,...)`, but `fvGeometry` makes little sense if not bound to `element` anyway and it also carries the bound element. With the same argument `elemVolVars` are basically unusable if you don't have the `scvs` at hand to access the corresponding volume variables. So in all those interfaces it makes sense to group the arguments. This is also introduced together with the solution state in !2520
- [ ] Extend problem/parameter/volvars interfaces to make it possible to inject some container with additionally required data, which in `MultiDomain` could be used to pass the coupling data. This is probably a lot of work and requires some thought regarding compatibility.<br>
- [ ] port the above concepts to `MultiDomain` (first goal: make `test_el2p` work, fixing the main bug)
Edit 25.03: We may postpone the introduction of the additional container to hold the coupling context for now and first realize multidomain in the new experimental framework but still with the context stored centrally in `CouplingManager` (an outdated but working draft is in !2448). This way, we can still reuse most interfaces in non-experimental namespace. Afterwards, we could address the issue of the central context separately, which would probably involve quite some interface changes... With either approach, the bug of non-converging Newton solver for poromechanics is addressed. Getting the context out of `CouplingManager` would additionally address thread safety in thread-parallel runs.
Problems that might need to be solved:
- The `assemble()` functions in the assembler now receive non-const GridVariables (introduced in 3d7068043ddb1cc7249aa0cd7d95ffa077733524). That was necessary because in the case of global caching we actually deflect the variables that come in. We should maybe think of a concept to circumvent this, and adapt !2519 accordingly.
Intermediate solutions/developments or related stuff, which should be deleted in case we favour the propositions above:
!2297, !2448, !2476, !2498, !2134, !2281, `feature/timestepmethods (now deleted)`
Things that should be revisited and adapted once this is ready:
!2130Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/792MultiDomain does not work for solution-dependent spatial params in instationa...2024-03-25T10:26:16ZDennis GläserMultiDomain does not work for solution-dependent spatial params in instationary problemsThis issue is related to #619, #703 and #788.
**What happened / Problem description**:
If a spatial param, e.g. porosity, depends on the solution of another domain (for example deformation-dependent porosities in poroelastic models), ...This issue is related to #619, #703 and #788.
**What happened / Problem description**:
If a spatial param, e.g. porosity, depends on the solution of another domain (for example deformation-dependent porosities in poroelastic models), there is currently no way to evaluate it on the correct time level during the creation of the previous volume variables. This causes the Newton solver to fail even for simple problems. A local (hacky) bugfix showed that good convergence is obtained when this is fixed.
This means that currently the Geomechanics module cannot be used for time-dependent problems in which deformation-dependent porosities are used, which is a standard capability.
A similar problem is reported in #703, where time-dependent spatial saturation distributions are needed.
Since several issues are related to this, an idea was to think about a more general way of handling time discretization schemes and hopefully fix all three issues at once.
One idea was to have a local view on the spatial parameters as well, and change all __bind__ functions such that they not only bind to an element but also to a time level somehow.X.Xhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/703Spatial parameters cannot be time dependent if not solution-dependent2023-02-22T08:58:07ZTimo Kochtimokoch@math.uio.noSpatial parameters cannot be time dependent if not solution-dependentIf we compute the tracer model in combination with a fluid that changes properties over time, we
need the old properties to evaluate the storage.
The problem is, the volvars currently don't know anything about time, so we can't pass tha...If we compute the tracer model in combination with a fluid that changes properties over time, we
need the old properties to evaluate the storage.
The problem is, the volvars currently don't know anything about time, so we can't pass that information
to the spatial params. That's why we currently assume that all secondary variables are either constant
or solution-dependent but not time-dependent without being solution-dependent. This is a big drawback
in general and a bug or at least an imprecision in the tracer model.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/619Output module doesn't work for multidomain when depending on coupling2021-03-09T12:22:20ZKilian WeishauptOutput module doesn't work for multidomain when depending on couplingf9668a803c076bfb32d2a442d95d3db439f65e80 introduces a call to `neumann()` function.
For coupled StokesDarcy problems, `neumann()` depends on a bound coupling context.f9668a803c076bfb32d2a442d95d3db439f65e80 introduces a call to `neumann()` function.
For coupled StokesDarcy problems, `neumann()` depends on a bound coupling context.Dennis GläserDennis Gläser