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/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/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/1356
[test][porousmediumflow][2pncmin][nonisothermal] Neumann flux at top has to b...
2024-02-16T08:57:42Z
Anna Mareike Kostelecky
[test][porousmediumflow][2pncmin][nonisothermal] Neumann flux at top has to be adapted
Within in the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) a few things for the Neumann BC at the top should be adapted:...
Within in the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) a few things for the Neumann BC at the top should be adapted:
1. In the upwind term ([here](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads#L239)) the reference mass-specific density of air is used, but there should be the molar density of air.
With the mass-specific density $\rho = 1.2 ~\text{kg}/\text{m}^3$ and the molar mass of air $M=28.96 * 10^{-3} ~\text{kg}/\text{mol}$, we have $\rho^{\text{mol}}=\rho/M \approx 41,44 ~\text{mol}/\text{m}^3$
2. The density of air (e.g. [here](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads#L231)) for the liquid flux should generally be harmonic averaged if CCFV is used with TPFA and arithmetic averaged for box method (as flux for liquid phase is purely diffusive and we do upwind just for advective processes)
3. The comments for "gas flux in/out" ([here](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads#L246)) should be switched.
4. For the energy exchange the harmonic mean of the effective heat conductivity within the porous medium and the heat conductivity within the free-flow should be taken. (Note, that applying the same harmonic averaging for the diffusion coefficient is counter-productive as the effective diffusion coefficient, using Millington-Quirk, is small for highly water-saturated porous media. This would lead to a lower evaporation rate for highly water saturated porous-media in comparison to high evaporation rates for almost dried-out porous media. Hence, only the pure binary diffusion coefficient is taken - It could be scaled e.g. linearly with the porosity)
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1352
Print absolute residual when using LineSearch in Newton Solver
2024-02-10T00:00:05Z
Lars Kaiser
Print absolute residual when using LineSearch in Newton Solver
<!--
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**
Print the absolute residual for each step of the newton solver to the console if `useLineSearch=true`.
**What does this feature / why does DuMux need it**:
The residual reduction and relative shift can make it look like we are/could be stuck on a saddle point. The information about the absolute residual can, in most cases, avoid this ambiguity.
```
Newton iteration 1 done, maximum relative shift = 6.4650e-08, residual = 4.2105e-13, residual reduction 1.0000e+00->1.5204e+00@lambda=0.1250
Newton iteration 2 done, maximum relative shift = 5.6569e-08, residual = 3.8752e-13, residual reduction 1.5204e+00->1.3993e+00@lambda=0.1250
Newton iteration 3 done, maximum relative shift = 4.9497e-08, residual = 3.8370e-13, residual reduction 1.3993e+00->1.3855e+00@lambda=0.2500
Newton iteration 4 done, maximum relative shift = 3.7123e-08, residual = 4.1695e-13, residual reduction 1.3855e+00->1.5056e+00@lambda=0.1250
Newton iteration 5 done, maximum relative shift = 3.2482e-08, residual = 3.6522e-13, residual reduction 1.5056e+00->1.3188e+00@lambda=0.5000
Newton iteration 6 done, maximum relative shift = 1.6241e-08, residual = 4.7623e-13, residual reduction 1.3188e+00->1.7196e+00@lambda=0.1250
Newton iteration 7 done, maximum relative shift = 1.4210e-08, residual = 4.2784e-13, residual reduction 1.7196e+00->1.5449e+00@lambda=1.0000
Newton iteration 8 done, maximum relative shift = 4.3042e-13, residual = 4.0635e-13, residual reduction 1.5449e+00->1.4673e+00@lambda=0.5000
Newton iteration 9 done, maximum relative shift = 2.1520e-13, residual = 3.9071e-13, residual reduction 1.4673e+00->1.4108e+00@lambda=0.5000
```
**Which issue does this feature fix (if any)**
**Anything else we need to know?**:
I would propose to print this information if there is no reason against it, with the hope to have an even better user experience.
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/1338
Parameter group and documentation
2024-01-30T14:53:03Z
Timo Koch
timokoch@math.uio.no
Parameter group and documentation
In https://dumux.org/docs/doxygen/master/runtime-parameters.html add a description about the parameter model when dealing with multiple instances of the same class and a global parameter tree. We use group prefixes then to set different ...
In https://dumux.org/docs/doxygen/master/runtime-parameters.html add a description about the parameter model when dealing with multiple instances of the same class and a global parameter tree. We use group prefixes then to set different parameters for the different instances. This could be more transparent for most classes but definitely needs to be documented in the doc page.
We should also think about flexibility and better design to pass param groups. It would be good if the parameter group could be changed after construction. Or maybe we could think about some factory pattern that allows to set the parameter group of a class instance and use this pattern everywhere. Maybe parameterized classes could provide constructor overloads that take the param group as the first parameter (using some named type).
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1335
Dispersion tensors
2024-01-25T14:22:59Z
Martin Schneider
Dispersion tensors
The current implementations of `ScheideggersDispersionTensor` and `FullDispersionTensor` are not very useful for real applications.
This is because of the following interfaces assumed in the spatialParams
- `problem.spatialParams().disp...
The current implementations of `ScheideggersDispersionTensor` and `FullDispersionTensor` are not very useful for real applications.
This is because of the following interfaces assumed in the spatialParams
- `problem.spatialParams().dispersionTensor(scvf.center(), phaseIdx, compIdx)` (`FullDispersionTensor`)
- `std::array<Scalar,2> dispersivity = problem.spatialParams().dispersionAlphas(scvf.center(), phaseIdx, compIdx);` (`ScheideggersDispersionTensor`)
- `velocity = problem.spatialParams().velocity(scvf);` (`ScheideggersDispersionTensor`)
The first two functions assume that the full tensor or the alpha parameters can be determined by the position. However, usually this is not the case but rather by some element marker, etc.
Also for the full tensor it is unlikely that the position is suitable for determining the tensor. E.g. for thermal dispersion, one usually multiplies with fluid density...
The velocity call is one needed when assuming a stationary velocity field. However, when using the Box scheme and having a pre-calculated velocity field on scvfs, just passing the scvf as an argument is not enough for directly accessing a container that stores these velocities, because the Box scvf only knows its local index and not a global one.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1332
Add linting as pre-commit hook
2024-01-08T10:59:32Z
Lars Kaiser
Add linting as pre-commit hook
<!--
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 the linting which is already happening in the Gitlab CI pipeline to a pre-commit hook.
**What does this feature / why does DuMux need it**:
It will prevent Gitlab CI pipelines from failing at the linting stage.
**Anything else we need to know?**:
Related to #1320, but is much easier to implement, as the rules and most syntax already exist and just has to be put into a pre-commit file.
**Implementation**
- codespell: https://calmcode.io/pre-commit/spelling.html
- black: https://black.readthedocs.io/en/stable/integrations/source_version_control.html
- flake8: https://flake8.pycqa.org/en/latest/user/using-hooks.html
- pylint: https://pylint.pycqa.org/en/latest/user_guide/installation/pre-commit-integration.html
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/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/1320
Evaluate code auto-formatting linting (C++)
2023-12-16T00:31:32Z
Timo Koch
timokoch@math.uio.no
Evaluate code auto-formatting linting (C++)
It would be great for developers to be able to check (at least some) formatting rules automatically or use auto-formatting. We have now some clang tools installed in the [CI images](https://git.iws.uni-stuttgart.de/dumux-repositories/dum...
It would be great for developers to be able to check (at least some) formatting rules automatically or use auto-formatting. We have now some clang tools installed in the [CI images](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-docker-ci/-/blame/master/full/ubuntu/Dockerfile#L39) but we still have to evaluate what the best configuration would be.
The idea to go about this would be to start with a configuration file for [clang-format](https://clang.llvm.org/docs/ClangFormat.html) that checks basically nothing and then successively add more rules/styles to enforce (in line with the [style guide](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/doc/styleguide.md).
So far, we only use the Dune pre-commit hook mechanism to check for trailing whitespace.
This issue can be used to track progress or discuss ideas.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1309
Make quad precision type work with Fmt::format
2023-11-20T11:24:00Z
Timo Koch
timokoch@math.uio.no
Make quad precision type work with Fmt::format
Seems like the quad precision type doesn't work with format but as we use it in a couple of central places like the newton this means nothing compiles. The current quad precision test is steady-state+linear and therefore doesn't use the ...
Seems like the quad precision type doesn't work with format but as we use it in a couple of central places like the newton this means nothing compiles. The current quad precision test is steady-state+linear and therefore doesn't use the newton.
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/1290
Add convenience function to construct default gridgeometry given a discretiza...
2023-08-01T21:59:07Z
Timo Koch
timokoch@math.uio.no
Add convenience function to construct default gridgeometry given a discretization scheme
`makeGridGeometry<DiscMethod>(gridView, ...)`
`makeGridGeometry<DiscMethod>(gridView, ...)`
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1259
Add an example for calculating fluxes over codim-1 regions
2023-07-26T08:41:31Z
Bernd Flemisch
Add an example for calculating fluxes over codim-1 regions