dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2019-05-04T20:09:50Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/510Introduce WallFunction Boundary condition for FF2019-05-04T20:09:50ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deIntroduce 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/538[RANS] Make calculation of velocity gradients and wall functions more general2021-11-24T10:04:15ZNed 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.Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/763[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high Re2021-03-25T08:39:24ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[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.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/807[RANS] Evaluate possibility to chose turbulence model at runtime2021-11-24T10:04:15ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[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.5Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/839[freeflow][test] Add analytical solution to non-isothermal test2021-03-25T08:20:25ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[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.5Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/846[staggered] Memory requirements2020-04-29T08:41:16ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[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/926Discussion: Boundary condition types in new staggered implementation2020-09-03T13:23:21ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deDiscussion: 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/951[freeflow] Introduce full shear stress terms, or document assumptions properly2021-03-25T08:38:24ZNed 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 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.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1081Port free flow tests to new staggered2021-11-30T10:47:38ZBernd 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`: @nedc
- [ ] `navierstokes/kovaszny`: @yue (needs higher order upwinding)3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1085Staggered problem dirichlet/neumann return convention2021-10-19T14:07: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.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1108Face data and restart for new staggered2021-12-15T11:09:46ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deFace 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).