[gocarts]

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:

1) Foam::incompressible::RASModels::NonlinearKEShih

Issues error:

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?

2) Foam::incompressible::RASModels::LaunderSharmaKE

Issues warning:

--> Creating nut to employ run-time selectable wall functions
Writing new nut

Supposed to be low-Re model so doesn't use wall functions.

3) Foam::incompressible::RASModels::LamBremhorstKE

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.

4) Foam::incompressible::RASModels::LienLeschzinerLowRe

Always fails for same standard case as I've used, successfully, for all other turbulence models.

Solution fails:

DILUPBiCG: Solving for k: solution singularity

Anybody else seeing these issues?

[mattijs]

Thanks. We pushed some fixes to the incompressible turbulence models in 1.6.x It all should work now as intended.

[gocarts]

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:
Foam::compressible::RASModels::LaunderSharmaKE

which failed with the error:
NO_READ specified for read-constructor of object k of class IOobject

The traceback pointed to the constructor:
Foam::compressible::RASModels::LaunderSharmaKE::La underSharmaKE

Again some of these issues could well be related to my lack of understanding.

[mattijs]

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,

Mattijs

[gocarts]

Hi Mattijs,

Thanks for the update, great work from the OpenCFD team.

[svens]

Hi Richard

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
Sven

[gocarts]

Hi Sven,

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.

[svens]

Thanks Richard

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
Sven

[gocarts]

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.

[svens]

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.
Sven

[gocarts]

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:

divSchemes
{
    default         Gauss linearUpwind Gauss linear;
    div(phi,U)      Gauss linearUpwindV Gauss linear;
    div((nuEff*dev(grad(U).T()))) Gauss linear;

    div(phi,k) Gauss upwind;
    div(phi,epsilon) Gauss upwind;
    div(phi,R) Gauss upwind;
    div(R) Gauss linear; 
    div((mu*dev2(grad(U).T()))) Gauss linear; 
    div((rho*R)) Gauss linear;
}

Attached is a comparison on the same relatively coarse grid of Launder Gibson RSTM 1st vs 2nd order - as you can see there are significant differences downstream of the bend.

[svens]

Hey Richard - that's amazing! Thanks for your illustration.

Another little question to understand completely - you'r using

  div(phi,U)      Gauss linearUpwindV Gauss linear;

How can I understand the usage of 2 times a discretisation and interpolation scheme? Is one for phi and the other for U?

Thank you very much for great help!
Sven

[gocarts]

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:

--> FOAM FATAL IO ERROR: 
Grad scheme not specified

Valid grad schemes are :

8
(
fourth
cellMDLimited
Gauss
cellLimited
faceMDLimited
faceLimited
extendedLeastSquares
leastSquares
)