dumux issues
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues
2024-03-27T18:38:06Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1361
Follow-up from "pore network model: 2pnc test"
2024-03-27T18:38:06Z
Timo Koch
timokoch@math.uio.no
Follow-up from "pore network model: 2pnc test"
The following discussion from !3197 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3197#note_97135): (+1 comment)
> ```suggestion:-6+0
> #inc...
The following discussion from !3197 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3197#note_97135): (+1 comment)
> ```suggestion:-6+0
> #include <iostream>
>
> #include <dune/common/parallel/mpihelper.hh>
> ```
> These don't seem to be used
and also https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3197#note_97134 (add changelog entry and fix filename)
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1351
[md][ffporenetwork][snappygridmanager] rename parameters to make clear that p...
2024-03-27T13:50:19Z
Anna Mareike Kostelecky
[md][ffporenetwork][snappygridmanager] rename parameters to make clear that pore bodies are coupled to interface (not throat)
In the [snappygridmanager.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/boundary/freeflowporenetwork/snappygridmanager.hh?ref_type=heads) the parameters `"Grid.CellsPerThroat"` and `"Grid.F...
In the [snappygridmanager.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/boundary/freeflowporenetwork/snappygridmanager.hh?ref_type=heads) the parameters `"Grid.CellsPerThroat"` and `"Grid.FixedCellsBetweenThroats"` ([here](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/boundary/freeflowporenetwork/snappygridmanager.hh?ref_type=heads#L577)) indicate that throats are coupled to the interface. However, `points[i].radius` (e.g used for specifying the width of the coupled free-flow cells [here](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/boundary/freeflowporenetwork/snappygridmanager.hh?ref_type=heads#L589)) is the pore body radius (see [here](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/boundary/freeflowporenetwork/snappygridmanager.hh?ref_type=heads#L185)).
I think it would be good to rename the parameters (and respective variables, error messages etc) to indicate clearly that pore bodies instead of throats are coupled to the free-flow cells.
Or did I not see something such that the current parameter names are meaningful?
Anna Mareike Kostelecky
Anna Mareike Kostelecky
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/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/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/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/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/1323
[doc] Large number of uncategorized files in Fluidmatrixinteractions group
2024-03-25T10:37:27Z
Lars Kaiser
[doc] Large number of uncategorized files in Fluidmatrixinteractions group
<!--
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**
I propose to add more subgroups to the Fluidmatrixinteractions group to make it easier to see what kind of constitutive relations are contained in this group.
**What does this feature / why does DuMux need it**:
Currently, there is a large number of files directly in the Fluidmatrixinteractions group and it is hard to get an overview of what is available. Introducing the subgroups will also bring the organization of the documentation closer to the internal folder structure of Dumux, where the files are already grouped.
Lars Kaiser
Lars Kaiser
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/1315
Regroup parameters to other group
2024-03-25T10:30:31Z
Ivan Buntic
Regroup parameters to other group
The parameters `Problem.PoissonRatio`, `Problem.SandGrainRoughness`, `Problem.UsePrimaryVariableSwitch` and `Problem.YoungsModulus` should not be part of the `Problem` group as the Problem group should only contain parameters of the FVPr...
The parameters `Problem.PoissonRatio`, `Problem.SandGrainRoughness`, `Problem.UsePrimaryVariableSwitch` and `Problem.YoungsModulus` should not be part of the `Problem` group as the Problem group should only contain parameters of the FVProblem and model agnostic problem base classes. Therefore, the four parameters should be regrouped. Once regrouped, the [parameter file](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/doc/doxygen/extradoc/parameters.json) should be updated accordingly for these parameters.
3.9
Yue Wang
yue.wang@iws.uni-stuttgart.de
Yue Wang
yue.wang@iws.uni-stuttgart.de
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/1330
DuMux Day 13.12.2023
2024-03-25T10:28:33Z
Bernd Flemisch
DuMux Day 13.12.2023
- [ ] #1255 Potential inconsistency in component enthalpies: @DennisGlaeser
- [ ] #1256: Energy balance implementation @timok, @tufan, see !3616
- [ ] #1257: Generalize ff-pm coupling @martins
- [ ] #1258: Upscaling of two-phase flow ...
- [ ] #1255 Potential inconsistency in component enthalpies: @DennisGlaeser
- [ ] #1256: Energy balance implementation @timok, @tufan, see !3616
- [ ] #1257: Generalize ff-pm coupling @martins
- [ ] #1258: Upscaling of two-phase flow properties using pore network @Maziar, @hanchuan
- [x] Automate Darus publication @houkili
- [ ] Add user guidelines, IDE (VSC) @root
- [ ] Volume averaging @nedc !3626
- [ ] #1324, #1325 @anna_m_kostelecky
- [x] #1328: @utz (issues), @RoWin (merge requests), @stefaniekiemle (lecture and course)
- [ ] #1329: everyone will look at their branches, @mathis will delete branches stale >3 years, @leonidas @lkaiser will look at automation
- [ ] #1327: @mathis !3744
- [ ] #1315: @yue
- [ ] #1314: @lkaiser
- [ ] #1323, !3734: add explanations for subgroups @Maziar (pore network), @RoWin (dispersion), @utz (friction laws)
- [ ] #1331, see !3745 : Dumux message update: @IvBu, everyone
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/792
MultiDomain does not work for solution-dependent spatial params in instationa...
2024-03-25T10:26:16Z
Dennis Gläser
MultiDomain does not work for solution-dependent spatial params in instationary problems
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), ...
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.X
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/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/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/1358
Move special case treatments to appropriate classes: VelocityGradients
2024-03-01T10:54:56Z
Mathis Kelm
Move special case treatments to appropriate classes: VelocityGradients
For (fcstaggered) freeflow a normal velocity gradient at the boundary can only be computed if the velocity is specified through Dirichlet boundary conditions. While the `velocityGradients` uses `outsideVolVars` (=inside at non-Dirichlet ...
For (fcstaggered) freeflow a normal velocity gradient at the boundary can only be computed if the velocity is specified through Dirichlet boundary conditions. While the `velocityGradients` uses `outsideVolVars` (=inside at non-Dirichlet boundaries?), the slip velocity momentum flux allows to specify this gradient as an optional parameter. Instead, the `velocityGradients` could specify treatment of edge cases in a central spot such that other classes can apply it in a consistent manner.
This should be accompanied with an easily accessible option to switch such classes if you adapted them, e.g. through access to publicly readable model traits.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1359
[freeflow] Momentum boundary flux helpers: Inertia terms in slip velocity mom...
2024-03-01T10:54:26Z
Mathis Kelm
[freeflow] Momentum boundary flux helpers: Inertia terms in slip velocity momentum flux
In [dumux/freeflow/navierstokes/momentum/fluxhelper.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/freeflow/navierstokes/momentum/fluxhelper.hh)
- [ ] Are the inertia terms correct and consistent betwee...
In [dumux/freeflow/navierstokes/momentum/fluxhelper.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/freeflow/navierstokes/momentum/fluxhelper.hh)
- [ ] Are the inertia terms correct and consistent between the two cases considered in the slip velocity momentum flux and compared to the outflow momentum flux?
- [ ] Currently the user has to apply the correct flux helper function in the correct part of the Neumann boundary (both helper functions compute inertia terms). If neither scv nor scvf lie on a slip boundary, the slip velocity helper currently returns 0 but should perhaps throw an exception, or assert/assume it's used correctly.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1346
[doc] fix as much typos as possible unto next release
2024-02-28T10:42:39Z
Kai Wendel
[doc] fix as much typos as possible unto next release
**Description**
when one reads through the DuMux core codes comments and other documentation, one can find sometimes comments that are obviously not correctly describing the underlining code, or there are typos. It would be worth to try...
**Description**
when one reads through the DuMux core codes comments and other documentation, one can find sometimes comments that are obviously not correctly describing the underlining code, or there are typos. It would be worth to try keeping this as tidy as we could as typos and incorrect comments are limiting the readability.
It is worth the effort, to fix as much obvious (and possbibly also some less obvious) typos or inconsistencies until the upcoming release.
Branch, that focuses on the `freeflow` part: [cleanup/smallCleanups](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/cleanup/smallCleanups?ref_type=heads). The changes are currently all limited to `freeflow`
Branch focusing on fluidsystems: [cleanup/fluidsAndFluidsystems](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/cleanup/fluidsAndFluidsystems?ref_type=heads)
Kai Wendel
Kai Wendel