dumux issues
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues
2024-03-25T10:40:18Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1347
Pore Scale Simulations with Volume Averaging
2024-03-25T10:40:18Z
Ned Coltman
Pore Scale Simulations with Volume Averaging
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
**Feature request**
There are a few merge requests and issues related to the same thing.
Many of u...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
**Feature request**
There are a few merge requests and issues related to the same thing.
Many of us have been using the freeflow models for pore-scale evaluations. Developments to this have been made in a few merge requests and issues.
- !3154 fixed a discretization bug related to convex corners
- !3160 and !3161 would both add a freeflow test that simulates flow within a pore geometry.
- !3626 introduces a few methods for averaging pore-scale solutions. It assumes conforming quadrilateral grids. A single unit averaging method is introduced, as well as a ensemble/convolutional averaging.
There are a few open problems:
- Dune-subgrid does not currently pass periodicity from the host grid to the subgrid. This has been fixed in a branch: https://gitlab.dune-project.org/extensions/dune-subgrid/-/tree/feature/SPGrid-Periodicity?ref_type=heads and has been described in https://gitlab.dune-project.org/extensions/dune-subgrid/-/issues/8. The fix on the branch has not been merged as it causes tests on dune-subgrid to fail.
- If subgrid also allows periodicity, there are a few changes to dumux that can be added. These are addressed in !3166.
- Handling of non-conforming grids needs to be handled.
- Averaging with a kernel function for convolutional averaging.
- Further convolutional averages have been investigated in the context of sfb-A01's dft work, which could be added as well.
- Add a caching method for saving element indicies and volumes that belong to certain averaging volumes to accellerate averaging on multiple time steps.
Larger questions that need to be addressed:
- How do we handle averages over a solid inclusion, where no solution exists?
3.9
Ned Coltman
Ned Coltman
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1345
dofOnBoundary missing for some discretization schemes
2024-03-25T10:40:27Z
Leon Keim
dofOnBoundary missing for some discretization schemes
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/READ...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Add dofOnBoundary function for various discretization schemes.
Currently implemented for box,diamond,pq1bubble,porenetwork.
**What does this feature / why does DuMux need it**:
Some preconditioners require a vector of dirichlet dof's to function properly. For instance StokesSolver's preconditioner (see [Test](test/freeflow/navierstokes/unstructured/main.cc)). In order to use these preconditioners a way to find dirichlet dof's needs to be introduced for various discretization schemes.
**Which issue does this feature fix (if any)**
Makes more preconditioners useable. StokesSolver should be usable with multidomain and staggered.
3.9
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1344
Release 3.9
2024-02-28T08:34:38Z
Leon Keim
Release 3.9
# Issue related for Dumux Day's leading to 3.9
## Introduction
- Second Dumux Day in this release cycle
- Trial of new way to approach Dumux Day
---
## New Approach to Dumux Days
### Few things we think that can be improved:
-...
# Issue related for Dumux Day's leading to 3.9
## Introduction
- Second Dumux Day in this release cycle
- Trial of new way to approach Dumux Day
---
## New Approach to Dumux Days
### Few things we think that can be improved:
- Motivation
- Stop endless discussions
- Reduce the contribution hurdle
### Ideas for this release:
- Identify three main contributions for the next release
- Smaller groups for each contribution
- Group should start by first defining the why,how and how much
+ Avoid to much discussion
+ Avoid doing work for nothing
- Ideally develop a roadmap for that
+ Includes to decide what is realistic and what not
- Group stays in that configuration for the release
- Every Dumux Day each group gets 5 min to present where they are
- To early feedback should be avoided
+ More power/responsibility for individual groups
---
## Main Contributions for this Release
### 1. Documentation @kaiw @stefaniekiemle @houkili @leonidas
- #1154 High-Level-Documentation !3755
- Architectural-Documentation
- #1338 Parameter Group
- #1323 Fluid-Matrix-Interactions
- #1346 Comments and Documentation in General
### 2. Physics @anna_m_kostelecky @yue @tschol @IvBu @RoWin @tufan @Maziar
- #1339 setRelativeHumidity and Fluid States @timok
- #1256 Energy balance implemetation @anna_m_kostelecky @tufan @Maziar
- #1255 Enthalpy of ideal gases @IvBu @RoWin @tschol @yue
- #1221 Anisotropic permeability law
### 3. FreeFlow @nedc @martins @mathis
- #1257 FF-PM Coupling
- #1205 Spatially varying extrusion Factor
- #1347 Pore Scale Simulations with Volume Averaging
- #1345 dofOnBoundary missing
3.9
Leon Keim
Leon Keim
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1329
Stale branches
2024-03-25T10:29:14Z
Bernd Flemisch
Stale branches
Let's delete stale branches that don't have an associated merge request, apart from the release branches. Stale for >12 months?
Let's delete stale branches that don't have an associated merge request, apart from the release branches. Stale for >12 months?
X.X
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1327
Remove deprecations for 3.8
2023-12-13T14:27:04Z
Bernd Flemisch
Remove deprecations for 3.8
There are several deprecations:
```text
dumux/discretization/cellcentered/mpfa/subcontrolvolumeface.hh:197: [[deprecated("Will be removed after 3.8. Use fvGeometry.geometry(scvf).corners().")]]
dumux/discretization/cellcentered/mpfa/s...
There are several deprecations:
```text
dumux/discretization/cellcentered/mpfa/subcontrolvolumeface.hh:197: [[deprecated("Will be removed after 3.8. Use fvGeometry.geometry(scvf).corners().")]]
dumux/discretization/cellcentered/mpfa/subcontrolvolumeface.hh:202: [[deprecated("Will be removed after 3.8. Use fvGeometry.vertexCorner(scvf)")]]
dumux/discretization/cellcentered/mpfa/subcontrolvolumeface.hh:207: [[deprecated("Will be removed after 3.8. Use fvGeometry.facetCorner(scvf)")]]
dumux/porousmediumflow/boxdfm/subcontrolvolume.hh:193: [[deprecated("Will be removed after 3.7. Use fvGeometry.geometry(scv).")]]
dumux/porousmediumflow/boxdfm/subcontrolvolumeface.hh:228: [[deprecated("Will be removed after 3.7. Use fvGeometry.geometry(scvf).")]]
dumux/linear/seqsolverbackend.hh:56: [[deprecated("Removed after 3.8. Use solver from istlsolvers.hh")]]
dumux/linear/seqsolverbackend.hh:77: [[deprecated("Removed after 3.8. Use solver from istlsolvers.hh")]]
dumux/linear/seqsolverbackend.hh:101: [[deprecated("Removed after 3.8. Use solver from istlsolvers.hh")]]
dumux/linear/seqsolverbackend.hh:122: [[deprecated("Removed after 3.8. Use solver from istlsolvers.hh")]]
dumux/multidomain/facet/box/subcontrolvolumeface.hh:179: [[deprecated("Will be removed after 3.7. Use fvGeometry.geometry(scvf).")]]
```
Some are still from 3.7, probably the removal of them is not as straightforward.
3.9
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1326
Brinkman porosity influence
2024-02-27T16:25:42Z
Timo Koch
timokoch@math.uio.no
Brinkman porosity influence
The current Darcy-Brinkman implementation seems to make some assumptions on porosity that should be clarified. Maybe there are some adjustments needed. I think the basic governing equations should be something like (based on theory of po...
The current Darcy-Brinkman implementation seems to make some assumptions on porosity that should be clarified. Maybe there are some adjustments needed. I think the basic governing equations should be something like (based on theory of porous media)
Fluid mass balance:
```math
\begin{equation}
\frac{\partial \left( n_f \rho_f \right)}{\partial t} + \operatorname{div}{\left( \rho_f \vec{w}_f \right)} = 0,
\end{equation}
```
with porosity (fluid volume fraction) $n_f$, Darcy velocity $\vec{w}_f := n_f (\vec{v}_f - \vec{v}_s) = n_f\vec{v}_f$ (rigid solid skeleton, $\vec{v}_s \equiv 0$).
Fluid momentum balance:
```math
\begin{align}
\frac{\partial \left( n_f \rho_f \vec{v}_f \right)}{\partial t}
+ \operatorname{div}{\left( n_f \rho_f \vec{v}_f \otimes \vec{v}_f \right)} &=\operatorname{div}{\underbrace{\left(2 \mu_f \vec{D}(\vec{v}_f) - n_f p \vec{I} \right)}_{\text{fluid stress,}\; \boldsymbol{T}_f}} + n_f\rho_f\vec{g} + \underbrace{p \nabla n_f - n_f^2 \mu_f \epsilon_B \vec{K}^{-1} \vec{v}_f}_{\text{momentum production,}\; \hat{p}_f},
\end{align}
```
with $\vec{D}(\vec{v}_f) = \frac{1}{2}\left( \nabla{\vec{v}_f} + \nabla{\vec{v}_f}^T \right)$, $\epsilon_B$ some scaling factor for the permeability (0 in free-flow, 1 in porous medium, $`0 < \epsilon < 1`$ in transition zone).
This reduces to Darcy's law when inertia and viscous stress can be neglected, and $`\epsilon_B=1`$,
```math
\begin{align}
\vec{0} &= -n_f \nabla{p} + n_f\rho_f\vec{g} - n_f \mu_f \vec{K}^{-1} \vec{w}_f \quad \longrightarrow \quad \vec{w}_f = - \mu_f^{-1}\vec{K} ( \nabla{p} - \rho_f \vec{g}),
\end{align}
```
But various terms containing $n_f$ don't easily simplify otherwise (transition zone and when $`n_f`$ is not constant).
Note: Discussion of the viscous term in https://doi.org/10.1017/S0022112005007998, which indicates $`\vec{D}(\vec{w}_f)`$ should be used instead of $`\vec{D}(\vec{v}_f)`$. Then we can rewrite in terms of Darcy velocity
```math
\begin{align}
\frac{\partial \left( \rho_f \vec{w}_f \right)}{\partial t}
+ \operatorname{div}{\left( n_f^{-1} \rho_f \vec{w}_f \otimes \vec{w}_f \right)} &=\operatorname{div}{\underbrace{\left(2 \mu_f \vec{D}(\vec{w}_f) - n_f p \vec{I} \right)}_{\text{fluid stress,}\; \boldsymbol{T}_f}} + n_f\rho_f\vec{g} + \underbrace{p \nabla n_f - n_f \mu_f \epsilon_B \vec{K}^{-1} \vec{w}_f}_{\text{momentum production,}\; \hat{p}_f},
\end{align}
```
Note: Darcy-Brinkman was introduced after release 3.8 so there is until release 3.9 to fix things if need be.
__Notes:__ [Brinkman.pdf](/uploads/6a79efa6ff10046617f472cc429cdda5/Brinkman.pdf)
3.9
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1301
[porousmediumflow][2pncmin] Use correct time step size for problem file
2023-12-11T14:53:06Z
Anna Mareike Kostelecky
[porousmediumflow][2pncmin] Use correct time step size for problem file
In the [2pncmin](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal) test the time step size is used in the [problem](https://git.iws.uni-stuttgart.de/dumux-repositories/du...
In the [2pncmin](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal) test the time step size is used in the [problem](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads#L331) for calculating the amount of precipitating salt per time. For this the time step is set in the [main file](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/main.cc?ref_type=heads#L140) at the beginning of each new time step. For this case this works so far.
However, @Simon Grether pointed out that for simulations where the [newton solver](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/nonlinear/newtonsolver.hh?ref_type=heads#L340) does not converge and hence reduces the time step, this is not correctly implemented. This modification of the time step is not accounted for in the problem file, when just setting the time step once in the time loop.
Hence this would be nice to adapt already in the 2pncmin test, such that if this test case is copied and gets modified there is one possible error source less.
3.9
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1257
[ff-pm] Generalize ff-pm coupling - allow different schemes and generalize sl...
2024-03-26T09:28:33Z
Martin Schneider
[ff-pm] Generalize ff-pm coupling - allow different schemes and generalize slip condition
- [x] The current implementation for coupling free-flow with porous medium flow is restricted to cctpfa-staggered coupling, this should be generalized to also allow other coupling schemes.
- [x] Generalization of slip condition !3762
- [x] The current implementation for coupling free-flow with porous medium flow is restricted to cctpfa-staggered coupling, this should be generalized to also allow other coupling schemes.
- [x] Generalization of slip condition !3762
3.9
Martin Schneider
Martin Schneider
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1256
[porousmedia] Energy balance implementation
2024-03-25T10:31:55Z
Timo Koch
timokoch@math.uio.no
[porousmedia] Energy balance implementation
We currently have some inconsistencies in the energy balance for porous media. For thermal equilibrium models, we implement
```math
\frac{\partial \left( n_s \rho_s u_s + n_f \rho_f u_f \right)}{\partial t} =
- \nabla\cdot{\left( \rho...
We currently have some inconsistencies in the energy balance for porous media. For thermal equilibrium models, we implement
```math
\frac{\partial \left( n_s \rho_s u_s + n_f \rho_f u_f \right)}{\partial t} =
- \nabla\cdot{\left( \rho_f h_f \boldsymbol{v}_f \right)} + \nabla\cdot{\left( \left\lbrace n_f \lambda_f + n_s \lambda_s \right\rbrace \nabla T \right)}.
```
but the correct balance would be
```math
\frac{\partial \left( n_s \rho_s u_s + n_f \rho_f \left\lbrace u_f - g z \right\rbrace \right)}{\partial t} =
- \nabla\cdot{\left( \left\lbrace \rho_f h_f - \rho_f g z\right\rbrace \boldsymbol{v}_f \right)} + \nabla\cdot{\left( \left\lbrace n_f \lambda_f + n_s \lambda_s \right\rbrace \nabla T \right)}.
```
This might seem like a small change but the difference actually shows some inconsistency. It's not just an omitted term.
Only looking at the fluid balance, the gravity term can also be written like this
```math
\frac{\partial \left( n_f \rho_f u_f \right)}{\partial t} = - \nabla\cdot{\left( \rho_f h_f \boldsymbol{v}_f \right)} + \nabla\cdot{\left(n_f \lambda_f \nabla T \right)} + \rho_f \boldsymbol{v}_f \cdot \boldsymbol{g} = - \nabla\cdot{\left( (\rho_f u_f + p) \boldsymbol{v}_f \right)} + \nabla\cdot{\left(n_f \lambda_f \nabla T \right)} + \rho_f \boldsymbol{v}_f \cdot \boldsymbol{g}.
```
Essentially, if we consider gravity in Darcy's law, we should also consider the corresponding term in the energy balance for consistency.
Subtracting the momentum balance multiplied by the velocity gives the balance of internal energy (non-conservative because only total energy is conserved):
```math
\frac{\partial \left( n_f \rho_f u_f \right)}{\partial t} = - \nabla\cdot{\left( \rho_f u_f \boldsymbol{v}_f \right)} + \nabla\cdot{\left(n_f \lambda_f \nabla T \right)} \underbrace{- p \left(\nabla\cdot{\boldsymbol{v}_f}\right)}_{\text{volume work}} \underbrace{+ \mu_f \boldsymbol{K}^{-1} \boldsymbol{v}_f \cdot \boldsymbol{v}_f}_{\text{viscous dissipation}}
```
This shows that there are conversion terms resulting in modification of the internal energy. Even if we assume that one of these is small, or both of these are small, we don't arrive at the implemented equation. If we don't have the gravity/potential energy term in the original balance, there would be an additional gravity term popping up here that mingles with the other energy conversion terms.
The gravity term vanishes if the fluid only moves perpendicular to the gravity field. However, for scenarios with strong upward/downward movement, this should have an effect.
3.9
Tufan Ghosh
Tufan Ghosh
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1255
Potential inconsistency in component enthalpies of ideal gases
2024-03-19T12:43:26Z
Dennis Gläser
Potential inconsistency in component enthalpies of ideal gases
For ideal gases, enthalpy is independent of pressure (see last paragraph of the introduction [here](https://en.wikipedia.org/wiki/Enthalpy) or [here](https://chem.libretexts.org/Bookshelves/Physical_and_Theoretical_Chemistry_Textbook_Map...
For ideal gases, enthalpy is independent of pressure (see last paragraph of the introduction [here](https://en.wikipedia.org/wiki/Enthalpy) or [here](https://chem.libretexts.org/Bookshelves/Physical_and_Theoretical_Chemistry_Textbook_Maps/Physical_Chemistry_(LibreTexts)/22%3A_Helmholtz_and_Gibbs_Energies/22.04%3A_The_Enthalpy_of_an_Ideal_Gas)). We end up with
```math
dH = c_p dT
```
for enthalpy changes as function of temperature.
Some components implement
```cpp
static const Scalar gasEnthalpy(Scalar temperature, Scalar pressure)
{ return gasHeatCapacity(temperature, pressure) * temperature; }
```
However, with the above equation we should actually from a reference temperature (or state) to the given temperature.
Some Observations:
- `CH4` implements this:
```cpp
// method of Joback
const Scalar cpVapA = 19.25;
const Scalar cpVapB = 0.05213;
const Scalar cpVapC = 1.197e-5;
const Scalar cpVapD = -1.132e-8;
return
1/molarMass()* // conversion from [J/(mol*K)] to [J/(kg*K)]
(cpVapA + T*
(cpVapB/2 + T*
(cpVapC/3 + T*
(cpVapD/4))));
```
it says this is according to the method of Joback but I am having trouble finding out where the magic numbers come from. I cannot relate them to the Joback tables (e.g. Appendix C of [1]). Also, the equation looks as if this actually returns the average cp (integration of cp from 0 to T and then division by T). Sampling enthalpy values at specific temperatures also verifies that, as one gets closer to reported values when one removes the divisors (`/2`, `/3, `/4`)...
If we cannot find out where exactly these values come from, we could use Appendix A, Table Section C, row 26 of [1] for enthalpy computations. Seems to match reported values.
- The current implementation (`cp*T`) vs integration led to differences between 15% and > 30% in for
`150 < T < 600`
I suggest the following for all ideal gases that have this kind of implementation:
- (1) Use Appendix A from [1] or properly implement & cite the Joback method (i.e. Appendix C from [1]) for the heat capacities
- (2) integrate the enthalpy from a reference state to the given temperature using eq 3-1.5 of [1]
- (3) (maybe) re-evaluate the validity bounds (temperature, but also species) of the Joback method, and maybe emit a warning when one leaves the validity range? (Tricky, because it could happen in some Newton iterations but be fine at the end of the solve...)
- [1] also shows other methods than Joback, we could have a look if they provide advantages...
[1] B. Poling et al. (2001, fifth edition, pp A.35) - https://www.eng.uc.edu/~beaucag/Classes/ChEThermoBeaucage/Books/Bruce%20E.%20Poling,%20John%20M.%20Prausnitz,%20John%20P.%20O%27Connell%20-%20The%20properties%20of%20gases%20and%20liquids-McGraw-Hill%20Professional%20(2000).pdf
3.9
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1221
Anisotropic permeability Law
2024-03-25T10:38:56Z
Johannes Hommel
Anisotropic permeability Law
**What does this feature / why does DuMux need it**:
An anisotropic permeability law is needed to account for precipitation having a different impact on the permeability in different directions. This is necessary for modeling a developi...
**What does this feature / why does DuMux need it**:
An anisotropic permeability law is needed to account for precipitation having a different impact on the permeability in different directions. This is necessary for modeling a developing anisotropy due to precipitation as observed in the microfluidic experiments of the CRC1313, Project C04 by Felix Weinhardt.
My goal would be to have a permeability Law that used different exponents in a power law for each of the directions:
kxxFactor = (poro/refPoro)^exponentX
kyyFactor = (poro/refPoro)^exponentY
K = kxxFactor * Kxx_0 0
0 kyyFactor * Kyy_0
I guess the easiest would be to have a matrix multiplication of the initial permeability K_0 with a "factor matrix" F:
K = K_0 * F
with
K_0 = Kxx_0 0
0 Kyy_0
and
F = kxxFactor 0
0 kyyFactor
**Which issue does this feature fix (if any)**
This issue/feature does not fix any other open issues.
**Anything else we need to know?**:
I would like to discuss whether there is an elegant, general solution for implementing anisotropic permeability laws recycling the current permeability laws (assuming isotropic permeability change) or whether I should just implement a new permeability law for my specific case.
Also, my question would be how to do this potentially even more generalized for 2D and 3D in one permeability law, if possible.
3.9
Johannes Hommel
Johannes Hommel
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1213
Metadata collection
2023-10-20T13:57:37Z
Martin Schneider
Metadata collection
Improve metadata collection of dumux.
TODOs:
- [ ] Add test case that collects metadata from dumux objects
- [ ] Add parameter tree to collector
Improve metadata collection of dumux.
TODOs:
- [ ] Add test case that collects metadata from dumux objects
- [ ] Add parameter tree to collector
3.9
Hamza Oukili
Hamza Oukili
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1205
[freeflow] Spatially varying extrusionFactor causes unphysical results for th...
2024-03-25T10:40:04Z
Felix Weinhardt
[freeflow] Spatially varying extrusionFactor causes unphysical results for the pressure distribution
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 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.9
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1197
CodeMeta Data: Authors/contributors?
2023-10-26T11:16:22Z
Timo Koch
timokoch@math.uio.no
CodeMeta Data: Authors/contributors?
The following discussion from !3101 should be addressed:
- [ ] @bernd started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3101#note_75683): (+5 comments)
> The most relevant open quest...
The following discussion from !3101 should be addressed:
- [ ] @bernd started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3101#note_75683): (+5 comments)
> The most relevant open questions concern authorship. CodeMeta distinguishes between "authors" and "contributors". Should we also distinguish? Who will be included? (How) do we automate the update of the file?
Add generic author (Dumux development team / Dumux developers) and list of contributors
3.9
Bernd Flemisch
Bernd Flemisch
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1173
Remove scv/scvf.geometry()/corner()
2023-12-13T14:27:03Z
Timo Koch
timokoch@math.uio.no
Remove scv/scvf.geometry()/corner()
Scv and Scvf do not need to store any corners and/or geometries.
The geometry can be computed on-the-fly given an element geometry.
We could provide such a feature in the element geometries.
Since I assume that this is a hardly used fea...
Scv and Scvf do not need to store any corners and/or geometries.
The geometry can be computed on-the-fly given an element geometry.
We could provide such a feature in the element geometries.
Since I assume that this is a hardly used feature, and all occurrences in Dumux (can be counted on one hand) can use a replacement, I suggest to remove these interfaces without deprecation.
The benefit is much less memory usage when caching the scv/scvfs.
The proposed interface is two free functions
`auto geometry(fvElementGeometry, scv)`
`auto geometry(fvElementGeometry, scvf)`
Alternatively, we can think about
`auto geometry(element_geometry, scv)`
`auto geometry(element_geometry, scvf)`
then all local Dune index information has to be available from the scv/scvf object, while the first version allows to do some additional mapping only known to the `fvElementGeometry` implementation.
3.9
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1156
FluxVariables is a misnomer
2023-10-26T08:07:56Z
Timo Koch
timokoch@math.uio.no
FluxVariables is a misnomer
The classes `[...]FluxVariables` actually computes fluxes for which it uses variables from the `VolumeVariables` and `FluxVariablesCache`. It does store local variable objects in its state but the main interface is all about computing fl...
The classes `[...]FluxVariables` actually computes fluxes for which it uses variables from the `VolumeVariables` and `FluxVariablesCache`. It does store local variable objects in its state but the main interface is all about computing fluxes. Also, they are used directly within `LocalResidal::computeFlux` as a helper to compute fluxes (evaluate the flux-part of the local residual).
Possible better names would be `[...]Flux` `[...]Fluxes`.
3.9
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1154
Add high-level documentation on the main concepts in Dumux
2024-03-25T10:09:45Z
Dennis Gläser
Add high-level documentation on the main concepts in Dumux
I propose a new structure for the High-Level-Design Document (HLDD).
[HLD_Proposal.md](/uploads/613c0e4e889894693fbe5f2611d6538c/HLD_Proposal.md)
After reviewing more sources, I think we mixed here High-Level and Architecture and genera...
I propose a new structure for the High-Level-Design Document (HLDD).
[HLD_Proposal.md](/uploads/613c0e4e889894693fbe5f2611d6538c/HLD_Proposal.md)
After reviewing more sources, I think we mixed here High-Level and Architecture and general Documentation. This could lower the pain of potential double documentation.
One could take the old HLD Branches/MR and:
1. Filter for HLDD
2. Take architectural parts such as interfaces and use this for Architectural Documentation
3. If something is now left behind and interesting think about adding it to the normal Documentation
It was decided to use the diagram added in !3755 as a starting point.
Each class here gets two to three sentences. Not more.
----
#### From here on the old Issue.
----
On Dumux Day, 25th of May, we said that it could be good to have such high-level docu somewhere (e.g. in the handbook?). This could describe generic concepts like grid geometry (is actually nicely described in the last Dumux paper), grid variables, etc...
Current status of this issue is related to !3406 <br>
If you want to work on the high_level_documentation: <br>
For each file you are working on: <br>
- Create a branch from !3406
- Create a MR to !3406
- When you are happy with the description of the class merge that branch in !3406 and tick of the box here. Afterwards tag yourself.Also include the MR number. <br>
Thank you in advance! <br>
Main problem that needs to be resolved: <br>
Doxygen move everything that is included in a group to that group.
One needs to find a way to have high-level docu in the groups while still having a monolithic one source high-level docu.
General approach to tackle this:
1st Describe entities that are modular
- In easy words, possible usage and interface to other entities
- Is this entity necessary to run a simulation
2nd Describe non modular entities
- In easy words, possible usage and interface to other entities
- Is this entity necessary to run a simulation
- Highlight dependencies and why they are necessary
3rd Find out and show how they are interconnected
- Highlight if this entity is necessary (i.e., green vs. red)
The following entities should be modular:
- [ ] Grid @IvBu !3621
- [ ] GridManager @IvBu (review: @DennisGlaeser) !3623
- [ ] Discretization Method
- [ ] GridGeometry @IvBu !3645
- [ ] GridView @kaiw
- [ ] FVElementGeometry
- [ ] VtkOutputModule @kaiw
- [ ] IOFields @kaiw !3587
- [ ] Solver @nedc (review: @leonidas) !3588
- [ ] NonLinearSolver @nedc
- [ ] NewtonLoop @nedc
- [ ] linearPDEsolver @nedc
- [ ] LinearSolver @nedc
- [ ] TimeLoop @kaiw
- [ ] LocalResidual @leonidas @mathis @kaiw
The following entities are not modular:
- [ ] Problem @kaiw
- [ ] BoundaryTypes
- [ ] PrimaryVariables
- [ ] Indices
- [ ] SolutionVector @kaiw
- [ ] NumEqVector
- [ ] GridVariables @leonidas @DennisGlaeser
- [ ] GridVolumeVariables @leonidas @DennisGlaeser
- [ ] Assembler @leonidas @mathis @kaiw
- [ ] localAssembler @leonidas @mathis @kaiw
- [ ] CouplingManager
- [ ] FluidSystem @leonidas
- [ ] FluidState @leonidas
- [ ] FluidMatrix ?
- [ ] SpatialParams @kaiw
General remarks and details about accessing data
- [ ] VolumeVariables @leonidas
- [ ] FluxVariablesCache @leonidas
- [ ] Element
- [ ] GlobalPosition
- [ ] ElementVolumeVariables @leonidas @DennisGlaeser
- [ ] ElementFaceVariables @leonidas
- [ ] ElementFluxVariablesCache @leonidas
- [ ] ControlVolume
- [ ] ControlVolumeFace
- [ ] SubControlVolume
- [ ] SubControlVolumeFace
General remarks on property system
- [ ] TypeTag
- [ ] Traits
- [ ] Model @kaiw !358
3.9
Leon Keim
Leon Keim
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1071
Tracer is not conserved
2024-03-25T10:25:34Z
Bernd Flemisch
Tracer 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.X
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/826
Diffusion confusion (implementation)
2024-03-25T10:24:47Z
Timo Koch
timokoch@math.uio.no
Diffusion 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.X
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/807
[RANS] Evaluate possibility to chose turbulence model at runtime
2023-09-27T08:51:41Z
Kilian Weishaupt
[RANS] Evaluate possibility to chose turbulence model at runtime
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 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.9
Ned Coltman
Ned Coltman