dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2024-03-25T10:40:04Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1205[freeflow] Spatially varying extrusionFactor causes unphysical results for th...2024-03-25T10:40:04ZFelix Weinhardt[freeflow] Spatially varying extrusionFactor causes unphysical results for the pressure distributionThe issue is illustrated with the following example scenario:
The example is based on the test “test_ff_stokes_channel_pseudo3d” and modified in a way that the domain is a square (0.005 x 0.005) with a lense in the middle which has a d...The issue is illustrated with the following example scenario:
The example is based on the test “test_ff_stokes_channel_pseudo3d” and modified in a way that the domain is a square (0.005 x 0.005) with a lense in the middle which has a different aperture (height) compared to the rest of the domain, the boundary conditions are fixed pressure at the inlet and outlet - the rest of the domain is no-slip. The motivation is, to be able to simulate microfluidic experiments with the pseudo-3D approach with different apertures of the micromodel (caused by precipitates).
For that, the friction source term in the problem.hh file is adapted:
```c
template<class ElementVolumeVariables>
Sources source(const Element& element,
const FVElementGeometry& fvGeometry,
const ElementVolumeVariables& elemVolVars,
const SubControlVolume& scv) const
{
auto source = Sources(0.0);
if constexpr (ParentType::isMomentumProblem() && enablePseudoThreeDWallFriction)
{
auto globalPos = scv.center();
Scalar heightRel = 1. ;
if(globalPos[0] > 0.001 && globalPos[0]< 0.004 && globalPos[1] > 0.001 && globalPos[1] < 0.004)
{
heightRel = relativeFrictionFactorLense_;
}
static const Scalar height = getParam<Scalar>("Problem.Height");
static const Scalar factor = getParam<Scalar>("Problem.PseudoWallFractionFactor", 8.0);
source[scv.dofAxis()] = this->pseudo3DWallFriction(element, fvGeometry, elemVolVars, scv, heightRel*height, factor);
}
return source;
}
```
and the extrusion factor in the spatialParams.hh is adapted:
```c
Scalar extrusionFactorAtPos(const GlobalPosition& globalPos) const
{
Scalar heightRel = 1.;
if(globalPos[0] > 0.001 && globalPos[0]< 0.004 && globalPos[1] > 0.001 && globalPos[1] < 0.004)
{
heightRel = relativeExtrusionFactorLens_; // = 0.5
}
return extrusionFactor_*heightRel;
}
```
In the attached files, three scenarios are compared:
+ a) (blue graphs): only the source term in the problem file is modified.
+ b) (red graphs): only the extrusion factor in the spatialParams file are modified.
+ c) (violette graphs): both, the source term in the problem and the extrusion factor in spatialParams file are modified.
In case of spatially varying extrusionFactors, there are discontinuities in the pressure (plot over line horizontally), while the velocities (plot over line vertically) look reasonable.
![ExtrusionSimTest](/uploads/eca0b5582a0139defdc09238dfdb1333/ExtrusionSimTest.png)3.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1127Possibly wrong gravity implementation for cctpfa2023-07-05T08:42:47ZSebastian HogewegPossibly wrong gravity implementation for cctpfaThe current implementation of the gravity term in flux/cctpfa/Darcy's law.hh seems to be ~~unsuitable for problems with heterogeneous distribution of petrophysical properties~~ unsuitable on grids with convex cells (e.g. corner-point gri...The current implementation of the gravity term in flux/cctpfa/Darcy's law.hh seems to be ~~unsuitable for problems with heterogeneous distribution of petrophysical properties~~ unsuitable on grids with convex cells (e.g. corner-point grids) which can yield negative transmissiblities (edited Timo). Previous versions (<3.0) have a more straightforward implementation and seem to work fine. Potential Solution: [darcyslaw.hh](/uploads/fad4bd181530b0a7cf7f7f41fff45123/darcyslaw.hh) (old Darcy's law implementation but incomplete e.g. on network grids)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/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/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