dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2024-02-28T08:34:38Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1344Release 3.92024-02-28T08:34:38ZLeon KeimRelease 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 missing3.9Leon KeimLeon Keimhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1330DuMux Day 13.12.20232023-12-14T13:49:10ZBernd FlemischDuMux 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, everyone3.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1329Stale branches2023-12-13T10:36:52ZBernd FlemischStale branchesLet'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?3.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1327Remove deprecations for 3.82023-12-13T14:27:04ZBernd FlemischRemove deprecations for 3.8There 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.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1326Brinkman porosity influence2024-02-27T16:25:42ZTimo Kochtimokoch@math.uio.noBrinkman porosity influenceThe 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.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1315Regroup parameters to other group2023-12-13T14:07:32ZIvan BunticRegroup parameters to other groupThe 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.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1301[porousmediumflow][2pncmin] Use correct time step size for problem file2023-12-11T14:53:06ZAnna Mareike Kostelecky[porousmediumflow][2pncmin] Use correct time step size for problem fileIn 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.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1256[porousmedia] Energy balance implementation2024-02-27T16:24:17ZTimo Kochtimokoch@math.uio.no[porousmedia] Energy balance implementationWe 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.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1255Potential inconsistency in component enthalpies of ideal gases2024-01-31T09:38:42ZDennis GläserPotential inconsistency in component enthalpies of ideal gasesFor 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).pdf3.9Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1213Metadata collection2023-10-20T13:57:37ZMartin SchneiderMetadata collectionImprove metadata collection of dumux.
TODOs:
- [ ] Add test case that collects metadata from dumux objects
- [ ] Add parameter tree to collectorImprove metadata collection of dumux.
TODOs:
- [ ] Add test case that collects metadata from dumux objects
- [ ] Add parameter tree to collector3.9Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1197CodeMeta Data: Authors/contributors?2023-10-26T11:16:22ZTimo Kochtimokoch@math.uio.noCodeMeta 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 contributors3.9Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1173Remove scv/scvf.geometry()/corner()2023-12-13T14:27:03ZTimo Kochtimokoch@math.uio.noRemove 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.9Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1156FluxVariables is a misnomer2023-10-26T08:07:56ZTimo Kochtimokoch@math.uio.noFluxVariables is a misnomerThe 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.9Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1154Add high-level documentation on the main concepts in Dumux2024-02-01T14:08:23ZDennis GläserAdd high-level documentation on the main concepts in DumuxI 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 !3583.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1071Tracer is not conserved2023-10-25T10:57:12ZBernd 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.3.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/826Diffusion confusion (implementation)2023-10-13T13:09:20ZTimo 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.3.9https://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...2023-10-13T13:10:48ZDennis 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.3.9https://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/1360Best Accountancy Courses and AAT Courses at Future Connect Training2024-03-02T07:43:33Zainah royBest Accountancy Courses and AAT Courses at Future Connect Training
[best accountancy courses](https://www.fctraining.org/?utm_source=SEO&utm_medium=referral_accounting&utm_id=SEO) play a pivotal role in shaping the careers of aspiring accountants. As the financial landscape evolves, individuals seeking...
[best accountancy courses](https://www.fctraining.org/?utm_source=SEO&utm_medium=referral_accounting&utm_id=SEO) play a pivotal role in shaping the careers of aspiring accountants. As the financial landscape evolves, individuals seeking a solid foundation in accountancy turn to reputable training institutions. One such institute that stands out is Future Connect Training, offering not only the best accountancy courses but also specialized AAT courses. Let's dive into why these courses are essential and how Future Connect Training sets itself apart in this competitive landscape.
Introduction
------------
### Why Choose Future Connect Training?
In the vast realm of accountancy training, Future Connect Training has emerged as a beacon for career enthusiasts. The institute prides itself on its unique approach to teaching, focusing on practical applications and skill development.
### Importance of Accountancy Courses
The demand for skilled accountants is on the rise, making [**accountancy courses**](https://www.fctraining.org/?utm_source=SEO&utm_medium=referral_accounting&utm_id=SEO) more crucial than ever. These courses not only impart theoretical knowledge but also equip individuals with the practical skills needed in the real-world financial environment.
Overview of Accountancy Courses
-------------------------------
### AAT Courses Explained
AAT (Association of Accounting Technicians) courses are designed to provide a comprehensive understanding of accounting principles. These courses cater to individuals at various career stages, from entry-level to those seeking specialized knowledge.
### Diverse Fields in Accountancy
Accountancy is not a one-size-fits-all profession. It spans across diverse fields, including taxation, auditing, financial analysis, and management accounting. Future Connect Training recognizes this diversity and tailors its courses accordingly.
Benefits of Pursuing AAT Courses
--------------------------------
### Industry Recognition
AAT courses are widely recognized in the industry, offering a credible qualification that opens doors to various career opportunities. Employers value the practical skills and knowledge gained through AAT training.
### Skill Enhancement
Future Connect Training goes beyond traditional teaching methods, focusing on enhancing practical skills. Students not only grasp theoretical concepts but also apply them to real-world scenarios, preparing them for the challenges of the accounting profession.
### Job Opportunities
The successful completion of AAT courses from [future connect training](https://www.fctraining.org/?utm_source=SEO&utm_medium=referral_accounting&utm_id=SEO) opens doors to a plethora of job opportunities. Whether you aspire to work in a corporate setting, public accounting, or as a freelance accountant, the institute's courses cater to diverse career paths.
Future Connect Training Approach
--------------------------------
### Unique Teaching Methods
What sets Future Connect Training apart is its innovative teaching methods. The institute combines traditional classroom learning with hands-on practical experiences, ensuring that students are well-prepared for the dynamic world of accountancy.
### Practical Application of Skills
Beyond theoretical knowledge, Future Connect Training emphasizes the practical application of skills. This approach ensures that graduates not only understand accounting concepts but can also apply them to solve real-world financial challenges.
Best Accountancy Courses Offered
--------------------------------
### Tailored for Career Growth
Future Connect Training offers a range of accountancy courses tailored to different career stages. Whether you're just starting or looking to specialize, the institute provides a roadmap for career growth.
### Examining Course Syllabus
Prospective students can review the detailed course syllabus to understand the topics covered. The transparency in outlining the curriculum reflects Future Connect Training's commitment to providing a comprehensive education.
AAT Courses for Career Aspirants
--------------------------------
### Entry-Level Courses
For those starting their accounting journey, Future Connect Training provides entry-level AAT courses. These courses lay the foundation for a successful career in accounting, covering fundamental concepts and principles.
### Specialized Courses
Recognizing the diverse interests within the field of accountancy, Future Connect Training also offers specialized [aat courses](https://www.fctraining.org/?utm_source=SEO&utm_medium=referral_accounting&utm_id=SEO). These courses delve deeper into specific areas, allowing individuals to carve a niche in their chosen specialization.
Success Stories from Future Connect Training
--------------------------------------------
### Testimonials from Students
The success stories of past students highlight the effectiveness of Future Connect Training's approach. Testimonials showcase how graduates have seamlessly transitioned from the classroom to the professional world, thriving in their accounting careers.
### Real-world Application of Knowledge
Future Connect Training's focus on real-world application ensures that students don't just memorize facts but understand how to apply them. This practical knowledge becomes invaluable when graduates enter the workforce.
Industry Demand for Accountants
-------------------------------
### Current Trends
The accountancy profession is witnessing evolving trends, with an increasing demand for professionals well-versed in modern accounting practices, technology, and regulatory compliance. Future Connect Training aligns its courses with these current industry demands.
### Future Job Market Predictions
As the business landscape evolves, the need for skilled accountants is expected to grow. Future Connect Training equips students with the foresight to navigate future challenges, ensuring their relevance in the ever-changing job market.
Admission Process and Requirements
----------------------------------
### How to Enroll
Future Connect Training simplifies the enrollment process, making it accessible for aspiring accountants. The institute provides clear guidance on how to start the journey toward a rewarding accountancy career.
### Necessary Prerequisites
Understanding the prerequisites for enrollment is crucial. Future Connect Training ensures that prospective students are aware of any requirements, allowing for a smooth admission process.
Flexibility of Learning
-----------------------
### Online Learning Options
Recognizing the need for flexibility, Future Connect Training offers online learning options. This ensures that individuals can pursue accountancy courses while managing other commitments.