dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2023-11-24T08:25:06Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1105(Velocity-dependent) Dispersion for tpfa2023-11-24T08:25:06ZTimo Kochtimokoch@math.uio.no(Velocity-dependent) Dispersion for tpfaConstant dispersion tensor are implemented in !2921.
Velocity-dependency (fully-implicit) could be realized by using a cell velocity-based scheme and harmonic averaging of the dispersion tensor on the face. But this extends the flux ste...Constant dispersion tensor are implemented in !2921.
Velocity-dependency (fully-implicit) could be realized by using a cell velocity-based scheme and harmonic averaging of the dispersion tensor on the face. But this extends the flux stencil of a single flux to the element stencil required for the velocity reconstruction.
Follow-up from #320 and !2921.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1071Tracer is not conserved2024-03-25T10:25:34ZBernd FlemischTracer is not conserved**Problem description:**
In a multi-phase setting, the amount of a tracer in one fluid phase is possibly not conserved from one time step to the next.
**Explanation:**
When solving the flow problem, the phase distribution usually chang...**Problem description:**
In a multi-phase setting, the amount of a tracer in one fluid phase is possibly not conserved from one time step to the next.
**Explanation:**
When solving the flow problem, the phase distribution usually changes. For example, the saturation in one cell increases. Since flow and tracer problems are decoupled, one should assume in this flow step that the added fluid doesn't contain tracer. For conserving the amount of tracer in each cell, the tracer concentration should be adapted to this change. While the concentration should be reduced in case of an increasing saturation, it stays the same and therefore the amount of tracer in the cell is increased. This is not corrected by the tracer solution step, as that step just redistributes the tracer according to the volume flux and the given (possibly wrong) concentration.
**How to reproduce it:**
Check out the branch `fix/tracer-concentration` and consider [test/porousmediumflow/tracer/conservation](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/fix/tracer-conservation/test/porousmediumflow/tracer/conservation). Comment the line
```cpp
equilibrateTracer(xOld, oldSaturation_, saturation_);
```
of `main.cc`.
**Possible fix:**
Equilibrate the tracer after each flow solve and before each tracer solve. To be discussed in !2767.X.Xhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1066Documentation for python bindings2023-02-20T10:54:36ZTimo Kochtimokoch@math.uio.noDocumentation for python bindingsPython bindings are still experimental but we should
* Move pointers to Python installation setup to main readme
* Improve installation and test instructions
* think about how to generate docs for Python. Maybe have a look and follow wh...Python bindings are still experimental but we should
* Move pointers to Python installation setup to main readme
* Improve installation and test instructions
* think about how to generate docs for Python. Maybe have a look and follow what Dune does too. Sphinx is a popular tool for automated doc generation for Python.
* For automated docs we also need to decide on a docstring format (e.g. the google format understood by Sphinx)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1000[freeflow] Properly include the volume work term in the energy balance2023-07-24T13:11:04ZKilian Weishaupt[freeflow] Properly include the volume work term in the energy balanceWe currently implement
$`\frac{\partial}{\partial t}(\rho u) = - \nabla \cdot (\rho \mathbf{v}h) + \nabla \cdot (\lambda \nabla T)`$
with $`h = u + \frac{p}{\rho}`$
However, the a correct form of the energy balance equation is (see ...We currently implement
$`\frac{\partial}{\partial t}(\rho u) = - \nabla \cdot (\rho \mathbf{v}h) + \nabla \cdot (\lambda \nabla T)`$
with $`h = u + \frac{p}{\rho}`$
However, the a correct form of the energy balance equation is (see !2473, !2471)
$`\frac{\partial}{\partial t}(\rho u) = - \nabla \cdot (\rho \boldsymbol{v}u) + \nabla \cdot (\lambda \nabla T) \underbrace{- p \left(\nabla\cdot{\boldsymbol{v}}\right)}_{\text{volume work}} + \underbrace{2\mu\boldsymbol{D}(\boldsymbol{v}) : \boldsymbol{D}(\boldsymbol{v})}_{\text{viscous dissipation}} `$
where $`\vec{D}(\vec{v}) = \frac{1}{2}\left( \nabla{\vec{v}} + \nabla{\vec{v}}^T \right)`$.
Viscous dissipation can often be neglected. Replacing enthalpy with internal energy in the first divergence term is simple but
the discretization of
$`p \nabla \cdot \mathbf{v}`$
is not straight-forward.
A possible simple solution would be:
Include in calculation of flux terms, i.e., evaluate $`\nabla \cdot \mathbf{v}`$
and assume a cell-constant $`p`$ which is just multiplied to the term. This gives a first-order scheme but should be ok since the term is often small. For incompressible flow the term also vanishes discretely since $`\nabla \cdot \mathbf{v} = 0`$.
This seems to work for cell-centered schemes without much additional effort (!2494).
For the box method it seems more difficult since the code assumes that fluxes on scvfs are symmetric. However the energy contribution (assembled on the scvfs) is different depending on the control volume (different control volume pressure).
Another solution is to implement the full conservative form of the energy equation
```math
\frac{\partial}{\partial t}\left( \frac{1}{2}\rho ||{\boldsymbol{v}}||^2 + \rho u \right) =
- \nabla\cdot{\left( \left[\frac{1}{2}\rho ||{\boldsymbol{v}}||^2 + \rho u \right] \boldsymbol{v}\right)}
+ \nabla\cdot{\left( \boldsymbol{T} \boldsymbol{v} + \lambda \nabla T\right)}
+ \rho \boldsymbol{v}\cdot \vec{g},
```
where $`\boldsymbol{T} = 2\mu\boldsymbol{D}(\boldsymbol{v}) - p\boldsymbol{I}`$.
__Edit 24 Jul 23 (@timok):__ included viscous dissipation term, annotations and conservative energy balance.https://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/923Revise use of mappers2021-03-09T12:18:37ZKilian WeishauptRevise use of mappers!2218 allows to use `SingleCodimSingleGeomTypeMapper` instead of our default `MultipleCodimMultipleGeomTypeMapper`, which can be a bit faster.
Using SingleCodimSingleGeomTypeMapper as ElementMapper works fine.
However, the code does no...!2218 allows to use `SingleCodimSingleGeomTypeMapper` instead of our default `MultipleCodimMultipleGeomTypeMapper`, which can be a bit faster.
Using SingleCodimSingleGeomTypeMapper as ElementMapper works fine.
However, the code does not compile when `gridGeometry.vertexMapper()` is passed in the context of `gridView.communicate(...)` or `VectorP0VTKFunction`.
I think in these cases, one is actually forced to use the MCMGMapper because the algorithm iterates over the entities of all codims during runtime.
We should check all of these occurrences. Maybe we should always provide a MultipleCodimMultipleGeomTypeMapper object
for vertices in our BaseGridGeometry which can be used for these special cases.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/908[disc] Implementation of nonlinear fv schemes2023-02-22T08:57:22ZMartin Schneider[disc] Implementation of nonlinear fv schemeshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/839[freeflow][test] Add analytical solution to non-isothermal test2023-02-22T08:55:56ZKilian Weishaupt[freeflow][test] Add analytical solution to non-isothermal testThere are analytical solutions for some non-isothermal porous medium tests.
We could do the same for the free flow model.There are analytical solutions for some non-isothermal porous medium tests.
We could do the same for the free flow model.Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/826Diffusion confusion (implementation)2024-03-25T10:24:47ZTimo Kochtimokoch@math.uio.noDiffusion confusion (implementation)We decided at some point that diffusion laws, e.g. `FicksLaw`, should compute all component fluxes in one go. This means two things
* we can now more efficiently compute the diffusive fluxes depending on the law (Fick / Maxwell-Stefan)
...We decided at some point that diffusion laws, e.g. `FicksLaw`, should compute all component fluxes in one go. This means two things
* we can now more efficiently compute the diffusive fluxes depending on the law (Fick / Maxwell-Stefan)
* `FicksLaw` now depends on the equation system
__Example:__
1. If I want to neglect diffusion in one phase, i can set the diffusion coefficient to zero. However, then the diffusive fluxes are still computed and I can throw them away in the custom local residual.
2. The Richards model is an immiscible two-phase two-component model but the air phase is never balanced. To integrate this in the current framework, we introduced `BalanceEqOpts::mainComponentIsBalanced(phaseIdx)` which is overloaded for the Richards model and used in Fick's law. In this case the dependency is actually there in the code in form of the additional dependency on `BalanceEqOpts`.
__One thought for a possible solution:__
If we would have a class `DiffusionFlux` replacing the current `FicksLaw`, then we could have a custom implementation `RichardsDiffusionFlux` which takes care of special requirements. `DiffusionFlux` would be a class on the level of `LocalResidual` only containing physics/equations. Internally it could use something like `FicksLaw` (new implementation that only contains the transmissibility part and discretization specifics) to compute the actual individual fluxes. `DiffusionFlux` may need to be specialized on the Law type (Fick / Maxwell-Stefan) but not the discretization.
Maybe, this would essentially be a code renaming / reordering. But that needs to be further investigated.X.Xhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/816Do not use term "handle" in mpfa2023-02-22T08:54:35ZDennis GläserDo not use term "handle" in mpfaThe term `DataHandle` used in mpfa should be replaced as it actually stores the data.The term `DataHandle` used in mpfa should be replaced as it actually stores the data.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/814Extract "constraint solvers" from volume variables2023-02-22T09:00:40ZTimo Kochtimokoch@math.uio.noExtract "constraint solvers" from volume variablesThe computation of the secondary variables from the primary variables is currently often coded inside the volume variables' `update` function. For the purpose of potential code reusage, readability, and testability it is IMO better to mo...The computation of the secondary variables from the primary variables is currently often coded inside the volume variables' `update` function. For the purpose of potential code reusage, readability, and testability it is IMO better to move this functionality to constraint solver classes. Even if the computation is quite simple. This is sometimes done in the form of the `computeFluidState` function. However, there is no general interface for all models.
If the constraint solver is in a separate class it is much easier to write unit tests. Volume variables have a lot of dependencies but the constraint solver can easily be tested and mock object are simple to construct for values obtained from e.g. the spatial params or some physical law.Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/807[RANS] Evaluate possibility to chose turbulence model at runtime2023-09-27T08:51:41ZKilian Weishaupt[RANS] Evaluate possibility to chose turbulence model at runtimeCurrently, we have a myriad of different RANS models (zeroeq, oneeq, twoeq-kepsilon, twoeq-komega, twoeq-lowrekepsilon).
Maybe we could choose the turbulence model (at least for the two-eq models) at runtime.
This would decrease the nu...Currently, we have a myriad of different RANS models (zeroeq, oneeq, twoeq-kepsilon, twoeq-komega, twoeq-lowrekepsilon).
Maybe we could choose the turbulence model (at least for the two-eq models) at runtime.
This would decrease the number of executables for the tests and maybe also decrease the effort to add new turbulence models.3.9Ned ColtmanNed Coltmanhttps://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/763[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high Re2023-02-22T08:58:22ZKilian Weishaupt[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high ReFor simple pipe flow, setting Dirichlet BCs for the pressure both at the inlet and outlet
works well for low Re. For higher Re, the Newton scheme does not converge anymore.
Setting the inlet BCs to Dirichlet for velocity works.
This sh...For simple pipe flow, setting Dirichlet BCs for the pressure both at the inlet and outlet
works well for low Re. For higher Re, the Newton scheme does not converge anymore.
Setting the inlet BCs to Dirichlet for velocity works.
This should be investigated. Maybe the assumption of
$`\nabla \mathbf{v} \cdot \mathbf{n} = 0 `$
and
$`\nabla p \cdot \mathbf{n} = 0 `$
used for the pressure BC causes this problem?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/761Cleanup explicit flash of implicit 2p2c model2023-02-22T08:57:13ZBeatrix BeckerCleanup explicit flash of implicit 2p2c modelThe volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included...The volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included in the volumevariables. I would propose implementing it as a separate class in a separate header, like the other constraintsolvers.
* The flash is only used if `useConstraintSolver` is false and the default is true. For the 2p2c model I would make the flash the default, since it is a faster calculation than using the more general `MiscibleMultiPhaseComposition` constraintsolver which solves a linear system of equations. Maybe we should even completely delete `useConstraintSolver` because in my opinion the solver has no benefit here, it solves the same equations, just less efficiently.
* For the case of one phase we may use the `ComputeFromReferencePhase` constraintsolver since it does exactly what the flash does.
* I don't think the flash is currently tested, so this should be added. It should have the same result as the other constraintsolvers.
What do you think? Another solution could be to delete the flash code and always use the solvers that we already have, but as mentioned above, I prefer having a 2p2c-specific flash.
There are a few points that I'm not sure of, maybe @holle can comment on this:
* In my opinion this flash is not as correct as it could be because it uses the assumption that vapor pressure of the liquid component and partial pressure of the liquid component in the gas phase are the same. This is only the case if we neglect the presence of other components in the gas phase. There is an equally quick method to calculate the mass fractions without using this assumption, see the 2p2c flash of the sequential models (note: pre release 3.4)
* It seems that the flash assumes that we deal with one liquid and one gas phase and that the liquid phase is the first phase. I think the 2p2c flash of the sequential models doesn't have this constraint.
* There seems to be a bug in the case that only the first phase is present, in the calculation of the mole fraction of the first component in the second phase. A multiplication with the mole fraction of the first component in the first phase is probably missing.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/707Generic implementation of L2-norm calculation using generic L2-projection2024-01-18T09:27:15ZTimo Kochtimokoch@math.uio.noGeneric implementation of L2-norm calculation using generic L2-projectionWith !1609 we get a generic l2-projection. In order to use it for interpolation between two arbitrary grids (arbitrary function spaces already works), we need to implement
* [x] 2d-2d intersections (!1625)
* [x] 3d-3d intersections (!29...With !1609 we get a generic l2-projection. In order to use it for interpolation between two arbitrary grids (arbitrary function spaces already works), we need to implement
* [x] 2d-2d intersections (!1625)
* [x] 3d-3d intersections (!2977)
That would be a great tool for convergence tests.https://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äserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/538[RANS] Make calculation of velocity gradients and wall functions more general2023-09-27T08:50:30ZNed Coltman[RANS] Make calculation of velocity gradients and wall functions more generalInspired by #532.
When considering a domain that features a pointy tip like illustrated below, it might be the case that the cell at the tip does not have any vertical or horizontal neighbors. Right now, in this case, the gradient in th...Inspired by #532.
When considering a domain that features a pointy tip like illustrated below, it might be the case that the cell at the tip does not have any vertical or horizontal neighbors. Right now, in this case, the gradient in this case will be set to 0 (!1130).
```cpp
++++++
+++
+
```
The should be further generalized to such that all wall functions, gradients, and functions for the boundaries are created in a separate class, rather than in each problem file.3.9Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/524(Re-)Implement CFL criterion2023-02-19T16:20:57ZTimo Kochtimokoch@math.uio.no(Re-)Implement CFL criterionAs a first step of porting the decoupled/sequential models to the new structure, it would be a good thing to implement a CFL criterion for the time step control for the current porousmediumflow models. Add good start is e.g. a CFL is e.g...As a first step of porting the decoupled/sequential models to the new structure, it would be a good thing to implement a CFL criterion for the time step control for the current porousmediumflow models. Add good start is e.g. a CFL is e.g. the 1p_tracer test (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/tree/master/test/porousmediumflow/tracer/1ptracer) that uses an explicit Euler for the transport but currently has a constant time step that is small enough for the test. CFL would be a big improvement.
@martins Maybe you are the best to deal with this?Martin SchneiderMartin Schneider