dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2020-09-03T13:23:21Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/926Discussion: Boundary condition types in new staggered implementation2020-09-03T13:23:21ZKilian 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/1108Face data and restart for new staggered2021-12-15T11:09:46ZKilian 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/951[freeflow] Introduce full shear stress terms, or document assumptions properly2022-05-10T12:07:41ZNed 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)
```
- 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.6https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/763[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high Re2022-03-28T11:30:41ZKilian Weishaupt[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high ReFor simple pipe flow, setting Dirichlet BCs for the pressure both at the inlet and outlet
works well for low Re. For higher Re, the Newton scheme does not converge anymore.
Setting the inlet BCs to Dirichlet for velocity works.
This sh...For simple pipe flow, setting Dirichlet BCs for the pressure both at the inlet and outlet
works well for low Re. For higher Re, the Newton scheme does not converge anymore.
Setting the inlet BCs to Dirichlet for velocity works.
This should be investigated. Maybe the assumption of
$`\nabla \mathbf{v} \cdot \mathbf{n} = 0 `$
and
$`\nabla p \cdot \mathbf{n} = 0 `$
used for the pressure BC causes this problem?3.6https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/839[freeflow][test] Add analytical solution to non-isothermal test2022-03-28T09:20:16ZKilian Weishaupt[freeflow][test] Add analytical solution to non-isothermal testThere are analytical solutions for some non-isothermal porous medium tests.
We could do the same for the free flow model.There are analytical solutions for some non-isothermal porous medium tests.
We could do the same for the free flow model.3.6Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/510Introduce WallFunction Boundary condition for FF2019-05-04T20:09:50ZKilian 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/807[RANS] Evaluate possibility to chose turbulence model at runtime2022-03-28T09:07:50ZKilian 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.6Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/538[RANS] Make calculation of velocity gradients and wall functions more general2022-03-28T09:08:08ZNed 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.6Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/846[staggered] Memory requirements2020-04-29T08:41:16ZKilian 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.