
[Sponsors] 
September 2, 2009, 12:55 
Possible Incompressible Turbulence Model Bugs

#1 
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 10 
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 wallfunctions on patch face_2 should be zeroGradient From function wallfunction evaluation in file OpenFOAM1.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 runtime selectable wall functions Writing new nut Supposed to be lowRe model so doesn't use wall functions. 3) Foam::incompressible::RASModels::LamBremhorstKE Should be lowRe (I think?), but seems to autocorrect 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/OpenFOAM1.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?
__________________
Symscape, Computational Fluid Dynamics for all 

September 4, 2009, 04:55 

#2 
Super Moderator
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 18 
Thanks. We pushed some fixes to the incompressible turbulence models in 1.6.x It all should work now as intended.


September 11, 2009, 17:28 
Might be more

#3 
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 10 
Good work mattijs,
I checked the incompressible lowRe 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 readconstructor 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.
__________________
Symscape, Computational Fluid Dynamics for all 

September 14, 2009, 12:11 

#4 
Super Moderator
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 18 
Thanks. We pushed (to 1.6.x) a fix for the LaunderSharmaKE. The nonlinear keps hasn't been converted yet to the new 'boundary conditions on nut' treatment so uses the old zerogradient method.
Thanks for reporting, Mattijs 

November 24, 2009, 14:55 

#6 
Member
Sven Schweikert
Join Date: Jun 2009
Posts: 38
Rep Power: 9 
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 uduct 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 

November 24, 2009, 16:51 
Initial Velocity Sensitivity

#7 
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 10 
Hi Sven,
I haven't performed detailed comparisons between the turbulence models. However, for a internal flow calculation using simpleFoam (steadystate) I noticed that the Launder Gibson RSTM was sensitive to the initial velocity condition. I found that whereas the kepsilon 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 KE calculation to reach a steady state.
__________________
Symscape, Computational Fluid Dynamics for all Last edited by gocarts; November 24, 2009 at 16:57. Reason: Added details 

November 24, 2009, 19:08 

#8 
Member
Sven Schweikert
Join Date: Jun 2009
Posts: 38
Rep Power: 9 
Thanks Richard
I'm using a converged kepsilon 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 uduct  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 

November 24, 2009, 21:28 

#9 
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 10 
Yes, I believe you are right ubends 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 loglaw 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.
__________________
Symscape, Computational Fluid Dynamics for all 

November 25, 2009, 15:22 

#10 
Member
Sven Schweikert
Join Date: Jun 2009
Posts: 38
Rep Power: 9 
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 

November 25, 2009, 17:00 
1st vs 2nd Order RSTM

#11 
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 10 
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: Code:
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; }
__________________
Symscape, Computational Fluid Dynamics for all 

November 25, 2009, 18:34 

#12 
Member
Sven Schweikert
Join Date: Jun 2009
Posts: 38
Rep Power: 9 
Hey Richard  that's amazing! Thanks for your illustration.
Another little question to understand completely  you'r using Code:
div(phi,U) Gauss linearUpwindV Gauss linear; Thank you very much for great help! Sven 

November 26, 2009, 15:58 
div upwindLinearV scheme requires grad scheme

#13 
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 10 
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: Code:
> FOAM FATAL IO ERROR: Grad scheme not specified Valid grad schemes are : 8 ( fourth cellMDLimited Gauss cellLimited faceMDLimited faceLimited extendedLeastSquares leastSquares )
__________________
Symscape, Computational Fluid Dynamics for all 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Adding a Turbulence Model  doug  OpenFOAM Running, Solving & CFD  10  October 2, 2012 06:55 
EulEul flow, kekpepTheta Turbulence model  us  FLUENT  5  April 5, 2011 02:29 
What is advection term of incompressible turbulence model  waynezw0618  OpenFOAM Running, Solving & CFD  2  December 6, 2008 08:46 
Turbulence Model  GG  CDadapco  3  March 3, 2008 20:06 
SSG Reynolds Turbulence Model  Georges  CFX  1  February 28, 2007 17:15 