dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2024-03-27T13:50:19Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1351[md][ffporenetwork][snappygridmanager] rename parameters to make clear that p...2024-03-27T13:50:19ZAnna 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 KosteleckyAnna Mareike Kosteleckyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1184Improve doc of Riemann solver2023-12-13T11:13:10ZTimo Kochtimokoch@math.uio.noImprove doc of Riemann solverThere are some variables which use abbreviations. This might be justified to have it close to how the algorithm is described in a text book. But then all variablenames that are not self-explanatory shoild be documented for better maintai...There are some variables which use abbreviations. This might be justified to have it close to how the algorithm is described in a text book. But then all variablenames that are not self-explanatory shoild be documented for better maintainability of the code.
In case there is no correspondence to the textbook renaiming to self-explantory name is preferred (style guide)Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1168New fcstaggered without caching is extremely slow2023-12-13T11:13:10ZTimo Kochtimokoch@math.uio.noNew fcstaggered without caching is extremely slowThere should be some optimization possible. It's really a crazy lot slower than with caching.There should be some optimization possible. It's really a crazy lot slower than with caching.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1108Face data and restart for new staggered2023-12-13T11:13:09ZKilian WeishauptFace data and restart for new staggeredIn the old staggered implementation, it was possible to write out face data (velocities) as points to a `.vtp` file.
This file could then be used for restarting simulations.
Visualizing and analyzing these point-wise face velocities in ...In the old staggered implementation, it was possible to write out face data (velocities) as points to a `.vtp` file.
This file could then be used for restarting simulations.
Visualizing and analyzing these point-wise face velocities in ParaView is rather cumbersome, so I introduced an `IntersectionWriter` for the new staggered such that the element edges actually appear graphically (looks like the `Surface With Edges` representation in ParaView).
However, this class seems overly complicated and furthermore, interior edges always appear twice (one intersection per element). The latter point may make it difficult to use the resulting `.vtp` files for restarting a simulation, unless we also always write out the `dofIdx`, too.
How should we proceed here?
(a) Stick to the "old" point-wise solution?
(b) Further improve the intersection writer such that it can also be used within our `VTKOutputModule`?
(c) Write out `.vtp` files manually (as done with the points), where the element edges are treated as 2d/1d elements
I guess (c) would be the most readable solution. One could try to figure out the element connectivity stuff for VTK "manually" (don't know yet how complicated that is) or one could use `FoamGrid` which would make the implementation really simple (at the cost of
an additional dependency).https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/926Discussion: Boundary condition types in new staggered implementation2023-12-13T11:13:07ZKilian WeishauptDiscussion: Boundary condition types in new staggered implementationWhile re-implementing the staggered grid scheme, I thought it might be good to discuss which types of BCs we
want to offer. So far, I could implement most of the tests using only `dirichlet` and `neumann` BCs and some helper classes.
We...While re-implementing the staggered grid scheme, I thought it might be good to discuss which types of BCs we
want to offer. So far, I could implement most of the tests using only `dirichlet` and `neumann` BCs and some helper classes.
We could have additionally (as in the old implementation)
* symmetry (technically a combination of Dirichlet with v*n = 0 and zero shear stress)
* beaversJoseph (technically a solution dependent Dirichlet for the tangential velocity)
Symmetry can already be easily achieved by combining `dirichlet` and `neumann`.
This is not so easy for beaversJoseph because we do not support solution dependent Dirichlet BCs.
The old implementation circumvents that by not calling `dirichlet` but `beaversJoseph` with sol-dep arguments in the local residual.
It could be possible to implement beaversJoseph in terms of a Neumann BC, but that might become cumbersome, especially if
inertia terms are considered.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/846[staggered] Memory requirements2023-12-13T11:13:07ZKilian Weishaupt[staggered] Memory requirementsThe (free flow) staggered model requires huge amounts of memory for larger systems, especially in 3D
and when caching is enabled.
As an example, a 3D domain with 4332960 cells takes around 50GB RAM when caching is enabled.
Investigatin...The (free flow) staggered model requires huge amounts of memory for larger systems, especially in 3D
and when caching is enabled.
As an example, a 3D domain with 4332960 cells takes around 50GB RAM when caching is enabled.
Investigating a smaller 2D domain with valgrind massif revealed that 8% of the total memory consumption
is caused by the `StaggeredSubControlVolumeFace`. This kind of makes sense because we store a lot of
information, such a neighboring dof indices and distances within the scvf (needed to calculate velocity gradients, etc.)
We even store large parts of the same information twice (two scvfs per intersection).
Would it make sense to put all the information stored so far in the scvf into a staggered fvGeometry?
We could then store one fvGeometry per intersection and avoid duplication.
I could image something like
```c++
void fu(const FVGeometry& fvGeometry)
{
const auto& ccFVGeometry = fvGeometry.cellCenterFVGeometry(); // regular fvGeometry as for tpfa
const auto& faceFVGeometry = fvGeometry.faceFVGeometry(); // new fvGeometry, centered around element faces
for (const auto& scvf : scvfs(ccFVGeometry))
// do stuff with "normal" scvfs, defined on element faces
for (const auto& scvf: scvfs(faceFVGeometry))
// do stuff with scvf defined for staggered control volume
}
```
As still want element-wise assembly, the faceFVGeometry's scvfs would probably have to know
in which element they lie.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/510Introduce WallFunction Boundary condition for FF2023-12-13T11:13:06ZKilian WeishauptIntroduce WallFunction Boundary condition for FFTo make to use of the wall function more clear and explicit, we could introduce a wall function boundary condition
which can only be set (using `std::enable_if`) if the FF model actually support it.To make to use of the wall function more clear and explicit, we could introduce a wall function boundary condition
which can only be set (using `std::enable_if`) if the FF model actually support it.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1180New Compositional Staggered2023-10-26T08:13:30ZNed ColtmanNew Compositional Staggeredmentioned in #1115
Implementation and ported tests addressed in !2986 .
New Analytical solution and convergence test implemented in !3044 . Also implemented for old staggered in !3561 .
Troubleshooting branch: `feature/misc_naviersto...mentioned in #1115
Implementation and ported tests addressed in !2986 .
New Analytical solution and convergence test implemented in !3044 . Also implemented for old staggered in !3561 .
Troubleshooting branch: `feature/misc_navierstokesnc` .
Using this issue to collect all of the ideas and progress we have made (the MRs are not organized for this)3.8Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/951[freeflow] Introduce full shear stress terms, or document assumptions properly2022-09-19T07:19:07ZNed Coltman[freeflow] Introduce full shear stress terms, or document assumptions properlyWe ran into a few discussions this summer/fall regarding terms that we may have either not implemented in the navier-stokes environment, or terms that we have neglected, but have not documented the assumptions properly.
These should be...We ran into a few discussions this summer/fall regarding terms that we may have either not implemented in the navier-stokes environment, or terms that we have neglected, but have not documented the assumptions properly.
These should be included, in either both new and old staggereds, or only the new staggered.
These terms include:
- the dilataion term
```math
\tau = \mu (\nabla v + \nabla v^T) + ( \lambda \nabla \cdot v ) I
```
- with stokes hypothesis
```math
(\lambda = 2/3 \mu)
```
<<< (MOVED TO RANS) Include the second term of the linear eddy viscosity reynolds stress: [cfdOnline](https://www.cfd-online.com/Wiki/Linear_eddy_viscosity_models) >>>
```math
\tau_t = 2 \mu_t S - 2/3 \rho k \delta_{ij}
```
- any others?
From what I've seen, some of this is already underway. This issue is only a location to collect problems and track progress.3.6Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1085Staggered problem dirichlet/neumann return convention2022-04-01T13:00:12ZTimo Kochtimokoch@math.uio.noStaggered problem dirichlet/neumann return conventionThe following discussion from !2852 should be addressed:
- [ ] @martins started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2852#note_66920): (+2 comments)
> I aggree and I also think ...The following discussion from !2852 should be addressed:
- [ ] @martins started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2852#note_66920): (+2 comments)
> I aggree and I also think that there should be some direct traits mechanics.
>
> However, this issue might also exist for user-defined functions. I think the discrepancy here is between how we actually think of `PrimaryVariables` and how it is used in the test cases. So maybe using for both situations the name `PrimaryVariables` might be confusing?
The staggered Navier-Stokes code expects full velocities fluxes (in all dimensions) from the problem. This makes it easier to set boundary conditions for when complex treatment due to the discretization is needed in the background.
The correct sizes are now statically asserted !2852. Still the problem uses the type names `PrimaryVariables` and `NumEqVector` but means different types than the corresponding types specified via properties and used in the assembly. This makes this error-prone and confusing. Moreover, it is currently necessary to overload all such functions inherited from the `FVProblem` because the type information is not properly propagated into the base class.
One solution would be to overload the functions in the navierstokes problem and actually use different type names such as `Velocity` and `MomentumFlux` so that it's completely clear that these are different.
TODO: how does this generalize to more complex models? Is it always only the momentum model affected by this? How to treat the difference with the mass model since both are currently implemented in one class with template switches.
- [x] Also change numeq confusion in boundarytypes and modeltraits for the momentum problem -> !30373.5Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1081Port free flow tests to new staggered2022-03-30T08:19:13ZBernd FlemischPort free flow tests to new staggeredTests should be ported one by one in separate merge requests. In principle, the new implementations are available in !2201. Move changes from `problem_new.hh` and `main_new.hh` to `problem.hh`, `main.hh`and `properties.hh`. Be careful as...Tests should be ported one by one in separate merge requests. In principle, the new implementations are available in !2201. Move changes from `problem_new.hh` and `main_new.hh` to `problem.hh`, `main.hh`and `properties.hh`. Be careful as !2201 is already partly outdated. !2830 is a port based on the current master.
- [x] `navierstokes/angeli`: @heck
- [x] `navierstokes/channel/1d`: @RoWin
- [x] `navierstokes/channel/pipe`: @hanchuan
- [x] `examples/liddrivencavity`: @nedc3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/947Restrict isOnWall()/isOnWallAtPos() in RANS to wall specific boundaries2021-09-20T00:50:03ZNed ColtmanRestrict isOnWall()/isOnWallAtPos() in RANS to wall specific boundaries**Feature request**
A different format for the isOnWall function (and variations) used in the Rans Models
**What does this feature / why does DuMux need it**:
At the moment the user can set the isOnWall function to any domain boundary f...**Feature request**
A different format for the isOnWall function (and variations) used in the Rans Models
**What does this feature / why does DuMux need it**:
At the moment the user can set the isOnWall function to any domain boundary face, regardless of the boundary conditions set there. This function should not be user defined, but be defined by the locations where wall boundary conditions have been specified.
**Which issue does this feature fix (if any)**
This is related to !2224, !2289, and #941, but addresses a general issue with the Rans models3.5Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/706Add turbulent diffusion to shallow water model2021-02-26T21:39:05ZFrank PlatzekAdd turbulent diffusion to shallow water modelThe preliminary turbulent diffusion implementation in the shallow water model from Issue #657
(Turbulent diffusion in shallow water equations), is to be merged in the new structure for the shallow water model as part of the Freeflow model.The preliminary turbulent diffusion implementation in the shallow water model from Issue #657
(Turbulent diffusion in shallow water equations), is to be merged in the new structure for the shallow water model as part of the Freeflow model.Frank PlatzekFrank Platzekhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/878Outflow conditions2020-12-02T08:59:21ZMartin SchneiderOutflow conditionsWhen setting outflow conditions in the freeflow model, for example for the energy balance equation, this may result in an unexpected solution behavior. The problem is the fact that the outflow conditions only properly work if $`\mathbf{v...When setting outflow conditions in the freeflow model, for example for the energy balance equation, this may result in an unexpected solution behavior. The problem is the fact that the outflow conditions only properly work if $`\mathbf{v}\cdot \mathbf{n} \geq 0`$, because then the upwind quantity is calculated using the cell values. However, if $`\mathbf{v}\cdot \mathbf{n} < 0`$, then the upwind quantity is calculated using boundary values. Currently, for outflow conditions these are equal to the cell values, which means that the upwinding is not done correctly. This could result in oscillations or (as in my test cases) to a very poor Newton convergence.
One solution would be to use Dirichlet values for the case that $`\mathbf{v}\cdot \mathbf{n} < 0`$. However, requiring Dirichlet values at outflow conditions might be confusing....3.4Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/837[freeflow][test] Transfer lid-driven cavity test to an example2020-11-05T15:36:53ZKilian Weishaupt[freeflow][test] Transfer lid-driven cavity test to an example[Ghia 1982](https://ac.els-cdn.com/0021999182900584/1-s2.0-0021999182900584-main.pdf?_tid=e9f7486c-d67c-11e7-96b6-00000aab0f26&acdnat=1512121945_6871c2de3e7d5699f53ef718416dc341) provide reference solutions (plot over line data) for the
...[Ghia 1982](https://ac.els-cdn.com/0021999182900584/1-s2.0-0021999182900584-main.pdf?_tid=e9f7486c-d67c-11e7-96b6-00000aab0f26&acdnat=1512121945_6871c2de3e7d5699f53ef718416dc341) provide reference solutions (plot over line data) for the
lid-driven cavity test.
I have used the data in my thesis and we could maybe also add them to the test.
* [ ] Turn the test into an example
* [ ] Add literature reference data
* [ ] Use `plotoverline` script from `bin` to extract line data
* [ ] Use scipy/gnuplot to plot and compare with the reference data3.3Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/838[freeflow][test] Add analytical solution to channel test2020-08-28T05:02:47ZKilian Weishaupt[freeflow][test] Add analytical solution to channel testAdd parabolic flow profile to low Re channel test.Add parabolic flow profile to low Re channel test.3.3Melanie LippMelanie Lipphttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/675[freeflow] Remove property NormalizePressure2020-08-26T08:00:48ZKilian Weishaupt[freeflow] Remove property NormalizePressureWhen enabled, all pressure related calculations for the momentum equations are done with `p - p_const`. The idea was to lower the numerical values of the pressure in the hope of decreasing numerical errors when further processing the val...When enabled, all pressure related calculations for the momentum equations are done with `p - p_const`. The idea was to lower the numerical values of the pressure in the hope of decreasing numerical errors when further processing the values in for the Jacobian. However, `p - p_const` probably already introduces the same error we wanted to avoid in the first place.
The property and the pressure normalization should therefore be removed after a check of the Matrix' condition number.3.3Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/537[staggered] Connectivity map stores own dofIdx2020-07-29T09:01:59ZKilian Weishaupt[staggered] Connectivity map stores own dofIdxThis is not needed, as the own dof is always known.
Concerns the staggered local assembler, probably the matrix pattern helper and the elementvolvars.This is not needed, as the own dof is always known.
Concerns the staggered local assembler, probably the matrix pattern helper and the elementvolvars.3.1Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/686Improve usage of container types in staggered2020-05-27T06:57:12ZKilian WeishauptImprove usage of container types in staggered* Replace `std::vector` by `Dune::ReservedVector` or even `std::array`, where possible
* most sizes are known at compile time* Replace `std::vector` by `Dune::ReservedVector` or even `std::array`, where possible
* most sizes are known at compile time3.3Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/804[staggered] Matrix block arrangement does not comply with literature standard2020-03-31T11:18:09ZKilian Weishaupt[staggered] Matrix block arrangement does not comply with literature standardPapers dealing with solvers for saddlepoint problems (like the incompressible Navier-Stokes equations, [example](https://epubs.siam.org/doi/abs/10.1137/16M1076770)) usually define the block matrix as
```math
M = \begin{pmatrix}
A & B...Papers dealing with solvers for saddlepoint problems (like the incompressible Navier-Stokes equations, [example](https://epubs.siam.org/doi/abs/10.1137/16M1076770)) usually define the block matrix as
```math
M = \begin{pmatrix}
A & B^T\\
B & C
\end{pmatrix}
```
where $`A`$ is the block for the derivatives of the momentum balance equation residuals w.r.t velocity ("velocity block")
and $`C`$ is is the block for the derivatives of the mass balance equation residuals w.r.t pressure ("pressure block").
For incompressible fluids, $`C`$ is zero.
However, the multitype blockmatrix in Dumux for staggered problems looks like this:
```math
M = \begin{pmatrix}
C & B^T\\
B & A
\end{pmatrix}
```
which causes confusion and requires special care, e.g, for the implementation of the Uzawa solver !1827
I suggest we adapt the matrix structure such that the velocity block is on the upper left. Are there any concerns / objections?3.2Kilian WeishauptKilian Weishaupt