dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2020-12-02T08:59:21Zhttps://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/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/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/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/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/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/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.https://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/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/357Implement staggered grid free flow model2018-04-18T12:43:27ZKilian WeishauptImplement staggered grid free flow modelTodo:
- [ ] FluxVars and LocalResidual
- [x] Add support for component transport
- [x] Add support for energy transport
- [ ] Account for extrusion factor
- [ ] fluxes (see !451)
- [x] storage terms
- [ ] Add 2D friction term t...Todo:
- [ ] FluxVars and LocalResidual
- [x] Add support for component transport
- [x] Add support for energy transport
- [ ] Account for extrusion factor
- [ ] fluxes (see !451)
- [x] storage terms
- [ ] Add 2D friction term to mimic 3D flow
- [ ] Implement better tests (e.g. 3D, transient, backward-facing step, etc.)
Kilian WeishauptKilian Weishaupthttps://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/684Fingering in freeflow test test_ff_stokes2c_densitydrivenflow to be expected?2019-08-28T10:21:17ZBeatrix BeckerFingering in freeflow test test_ff_stokes2c_densitydrivenflow to be expected?The freeflow test `test_ff_stokes2c_densitydrivenflow` in `/test/freeflow/navierstokesnc/densitydrivenflow` shows fingers depending on Newton.MaxRelativeShift. As an example, a comparison of the magnitude of the velocity with Newton.MaxR...The freeflow test `test_ff_stokes2c_densitydrivenflow` in `/test/freeflow/navierstokesnc/densitydrivenflow` shows fingers depending on Newton.MaxRelativeShift. As an example, a comparison of the magnitude of the velocity with Newton.MaxRelativeShift = 1e-14 (left) and Newton.MaxRelativeShift = 1e-8 (right) is shown below:
![Screenshot_20190328_103436](/uploads/c41421f0e0d85e05452f35ddbd0aeb6c/Screenshot_20190328_103436.png)
We should investigate if there is a physical basis for the appearance of fingers in this test.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/417Folder names in freeflow2017-12-22T13:12:18ZTimo Kochtimokoch@math.uio.noFolder names in freeflowthe NavierStokes, NavierStokesNC, NavierStokesNI models are defined in the folder staggered, staggerednc, staggeredni which doesn't seem appropriate. In fact the physical models/TypeTags shouldn't know anything about the discretization.
...the NavierStokes, NavierStokesNC, NavierStokesNI models are defined in the folder staggered, staggerednc, staggeredni which doesn't seem appropriate. In fact the physical models/TypeTags shouldn't know anything about the discretization.
So the folder names "navierstokes", "navierstokesnc", "nonisothermal" seem more appropriate.Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/416Issues with staggered properties2017-12-22T13:12:18ZTimo Kochtimokoch@math.uio.noIssues with staggered propertiesThere are some issues with the staggered properties.
* The discretization TypeTag, and the physical TypeTags are not well separated.
For the test/discretization/staggered/test_staggeredfvgeometry I want to inherit from NumericModel an...There are some issues with the staggered properties.
* The discretization TypeTag, and the physical TypeTags are not well separated.
For the test/discretization/staggered/test_staggeredfvgeometry I want to inherit from NumericModel and a discretization TypeTag without knowing anything about physics. This currently seems not possible.
* the staggered properties inherit from LinearSolverTypeTag which it shouldn't
* the staggered properties define a type for SCVs but none for SCV faces. There should be a default type for SCV faces that implements at least the common functions that a staggered scvf needs to haveKilian WeishauptKilian Weishaupt