Possible Incompressible Turbulence Model Bugs
I've been evaluating the OpenFOAM 1.6.x incompressible turbulence models and came across possible bugs/anomalies, though they could also be due to my limited understanding.
My test case was a simple cube with 4 walls, an inlet and an opposing outlet.
The following models worked as I'd expect:
kEpsilon, laminar, RNGkEpsilon, SpalartAllmaras, LRR, LaunderGibsonRSTM, LienCubicKE, qZeta, LienCubicKELowRe, kOmegaSST
The following models had problems:
kqRWallFunction is the wrong k patchField type for wall-functions on patch face_2
should be zeroGradient
From function wall-function evaluation
in file OpenFOAM-1.6.x/src/finiteVolume/lnInclude/checkPatchFieldTypes.H at line 3.
Where face_2 is a wall - is this a special model that uses zeroGradient on a wall instead of kqRWallFunction?
--> Creating nut to employ run-time selectable wall functions
Writing new nut
Supposed to be low-Re model so doesn't use wall functions.
Should be low-Re (I think?), but seems to auto-correct k, epsilon, and adds nut as if wall function model, then runs successfully.
Also issues warning:
--> FOAM Warning :
From function GeometricField<Type, PatchField, GeoMesh>::readIfPresent()
in file /home/rjs/projects/of/of1.6/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude/GeometricField.C at line 107
read option IOobject::MUST_READ suggests that a read constructor for field epsilon would be more appropriate.
Always fails for same standard case as I've used, successfully, for all other turbulence models.
DILUPBiCG: Solving for k: solution singularity
Anybody else seeing these issues?
Thanks. We pushed some fixes to the incompressible turbulence models in 1.6.x It all should work now as intended.
Might be more
Good work mattijs,
I checked the incompressible low-Re incompressible RAS models I mentioned in my previous post and they now seem fine, except for Foam::incompressible::RASModels::LienLeschzinerLowRe - which although I can get it to converge, it still seems sensitive to k values derived from turbulent intensity > 0.01.
I guess too that zeroGradient is the right condition for a wall, where I'd expected kqRWallFunction, for Foam::incompressible::RASModels::NonlinearKEShih?
The compressible RAS Turbulence models I tested:
kEpsilon, RNGkEpsilon, SpalartAllmaras, realizableKE, LaunderSharmaKE, LRR, LaunderGibsonRSTM, kOmegaSST
all seemed fine except for:
which failed with the error:
NO_READ specified for read-constructor of object k of class IOobject
The traceback pointed to the constructor:
Again some of these issues could well be related to my lack of understanding.
Thanks. We pushed (to 1.6.x) a fix for the LaunderSharmaKE. The non-linear k-eps hasn't been converted yet to the new 'boundary conditions on nut' treatment so uses the old zero-gradient method.
Thanks for reporting,
Thanks for the update, great work from the OpenCFD team.
For me it seems to be that you are really delved into OpenFOAMs incompressible RAS models.
I was running some calculation with the LaunderGibsonRSTM and the kEpsilon models. It was a little bit surprising that the RSTM performs really poor compared to the EVM. (I simulated a u-duct geometry.)
It would be nice to her from you about your experiences with the different turbulence models - and of course especially about the RSTMs. Did they perform satisfactorily? Any problems to reach this state?
Thanks pretty much
Initial Velocity Sensitivity
I haven't performed detailed comparisons between the turbulence models. However, for a internal flow calculation using simpleFoam (steady-state) I noticed that the Launder Gibson RSTM was sensitive to the initial velocity condition. I found that whereas the k-epsilon could be initialized with the inlet velocity, the LG RSTM preferred zero.
Hope this helps.
Edit: For the same simple case the LG RSTM calculation took twice as many iterations as the K-E calculation to reach a steady state.
I'm using a converged k-epsilon solution as initials for the RSTM - this leads to satisfactorily behavior in convergence. But as mentioned the comparistion to experimental data and EVM shows not the hoped improvement...
I mean - I'm using a 180deg u-duct - a geometry with strong streamline curvature. I thought on problems like this the RSTMs turn to account!
Do you have some experiences with the fvSchemes? I'm using a lot of 1st order (standard simpleFoam settings) schemes and I'm quite unsure what they should be for RSTMs.
Thank you very much
Yes, I believe you are right u-bends are RSM territory.
My experience with fvSchemes isn't extensive. However, the div scheme settings are critical in determining accuracy - if you are using the default settings from a simpleFoam tutorial (likely upwind) then consider trying (2nd order) linearUpwind for your scalars and linearUpwindV for vectors (i.e., velocity).
Other variables to consider are the mesh density and whether your y+ values are within the log-law limit range - I'm guessing that you are happy with these.
I'm also assuming that you are confident that your boundary conditions (especially at the inlet) are valid for R - likely derived from k.
Thanks for your reply Richard
I just had a look at an evaluation for a finer grid - the values becoming better!
At the moment I'm experimenting with the 'nNonOrthogonalCorrectors' which hopefully also leads to a more reasonable result. As soon as I figured out these influences I'm going to have a run with 2nd order discretication schemes.
Time and cpu resource is rare - does it make sense to restart a already converged simulation with higher fvSchemes or do I have to start from 0 again? A question which bothers me...
Thanks again Richard you are providing me great support.
1st vs 2nd Order RSTM
I've found starting each from scratch to produce the fastest convergence rate.
So when I say try 2nd order I mean for the velocity and pressure. I haven't tried 2nd order for the turbulent variables. I have something like:
Hey Richard - that's amazing! Thanks for your illustration.
Another little question to understand completely - you'r using
Thank you very much for great help!
div upwindLinearV scheme requires grad scheme
For div the upwindLinearV (vector) scheme is special in that it also requires a grad scheme hence the addition of 'Gauss Linear'. You don't need to specify a grad scheme for upwindLinear (scalar) - so my inclusion of it in my sample code is ignored by OpenFOAM.
Again I can't claim to be an expert in these matters. I came across this case by trial and error. For instance if you don't specify a grad scheme for upwindLinearV you'll receive the following error:
|All times are GMT -4. The time now is 18:56.|