simpleFoam k-omegaSST convergence problem

 Register Blogs Members List Search Today's Posts Mark Forums Read

 February 22, 2011, 05:35 simpleFoam k-omegaSST convergence problem #1 New Member   Carl Join Date: Jan 2011 Location: Bremen /Gothenburg Posts: 11 Rep Power: 15 HEj community, I am using a k-omegaSST model on a quite complex geometry. Meshed it with sHM in 0.8M, 1.6M and 3.2M cells with okay quality (still some skewFaces left but cannot get rid of them). The problem now is another thing. It seems that the omega has problems with the y-plus values of the coarser grids. The first two coarse grids do not converge (viewing the residuals) - the last one does. All of them have high peaks in the omega residuals now and then, which seems to cause the instabilities later on of the rest residuals (U,p,k). Any ideas how to solve the omega fluctuations? Relaxing factor is 0.7 for all except for p (0.3). Schemes limitedLinear 0.2 (except for gradSchemes which are linear) Solution: GAMG for p and PBICG for the rest Thanks for any hints Last edited by cjm; February 22, 2011 at 06:34.

 February 22, 2011, 07:18 #2 Senior Member   Felix L. Join Date: Feb 2010 Location: Hamburg Posts: 165 Rep Power: 18 Hello, cjm, since you didn't provide enough information I can only guess: try lowering the omega equation solver tolerance inside fvSolution to a value of ~1e-12. The residuals of the omega equation tend to fall below solver tolerance relatively quickly leading to a similar behaviour you described. If that ain't helping, a little more information would be helpful: - fvSolution and fvSchemes - max and average yPlus-values of the three meshes - are you using wall Functions? - residual plot - ... Greetings, Felix.

February 22, 2011, 08:02
#3
New Member

Carl
Join Date: Jan 2011
Location: Bremen /Gothenburg
Posts: 11
Rep Power: 15
Yes sure. Should have done it before...

yPlus (start values after meshing):
coarse: y+ : min: 24.8727 max: 6849.56 average: 579.113
medium: y+ : min: 16.1537 max: 5377.99 average: 525.403
fine: y+ : min: 16.2789 max: 4406.01 average: 396.97

Yes, I´m using wallfunctions (omegaWallFunction, nutWallFunction and kqRWallFunction - but no R-file at all [shouldnt be bad,right?])

Schemes:
Code:
```ddtSchemes
{
}
{
default         Gauss linear;
//    grad(U)         cellLimited Gauss linear 1;
}
divSchemes
{
default         none;
div(phi,U)      Gauss linearUpwindV Gauss linear;
div(phi,k)      Gauss limitedLinear 0.2;
div(phi,omega)  Gauss limitedLinear 0.2;
}
laplacianSchemes
{
//    default         Gauss linear corrected;
default         Gauss linear limited 0.2;
//    default         Gauss linear limited 0.333;
}
interpolationSchemes
{
default         linear;
interpolate(U)  linear;
}
{
default         corrected;
}
fluxRequired
{
default         no;
p;
}```
Solution:
Code:
```solvers
{
p
{
solver           GAMG;
tolerance        1e-7;
relTol           0.1;
smoother         GaussSeidel;
nPreSweeps       0;
nPostSweeps      2;
cacheAgglomeration on;
agglomerator     faceAreaPair;
nCellsInCoarsestLevel 10;
mergeLevels      1;
};
"(U|k|omega)"
{
solver          PBiCG;
preconditioner  DILU;
tolerance       1e-05;
relTol          0.1;
};
}
SIMPLE
{
nNonOrthogonalCorrectors 0;
}
relaxationFactors
{
p               0.3;
U               0.7;
k               0.7;
omega           0.7;
}```
Any Ideas (your first ones seem to be quite good already) - Thanks...

und liebste Grüße in die Hansestadt
Attached Images
 coarse.png (45.2 KB, 318 views) medium.png (75.5 KB, 313 views) fine.png (33.9 KB, 313 views)

 February 22, 2011, 09:19 #4 Senior Member   Felix L. Join Date: Feb 2010 Location: Hamburg Posts: 165 Rep Power: 18 Hello, cjm, thanks for the additional intel. It doesn't look like my first guess is the source of your problems, so let's focus on the mesh. Since the finest grid is the only one working I presume it's got something to do with first wall grid spacing, i.e. y+ values. Could you run yPlus after a specific amount of iterations, e.g. 100 to 200 iterations? y+ depends upon the solution of the flow field and running yPlus on your initial field (i.e. the directory ./0 ) leads to incorrect values. Ideally - when using wall functions - yPlus should bei minimum 30 and maximum ~100-300. Grüße in die andere Hansestadt, Felix.

 February 22, 2011, 09:35 #5 New Member   Carl Join Date: Jan 2011 Location: Bremen /Gothenburg Posts: 11 Rep Power: 15 Yeah I tought about that as well, but since I´m a bit new in oF I have no idea how to fix this. My y+ values for the medium grid: 100iter - min: 0.356183 max: 21491.4 average: 680.631 200iter - min: 0.361893 max: 5.62512e+06 average: 1735.06 300iter - min: 1.28251e-05 max: 1.793e+08 average: 26298.9 400iter - min: 22.0961 max: 1.53668e+09 average: 408808 -- After this my solution blows up (naturally) and the fine grid (converged): 100iter - min: 0.108308 max: 15008.5 average: 514.67 200iter - min: 0.0509058 max: 15674.4 average: 481.019 300iter - min: 0.27685 max: 15694.7 average: 473.707 400iter - min: 0.176655 max: 15710.4 average: 471.746 500iter - min: 0.0535633 max: 15699.4 average: 470.722 Maybe even that is too much. Can you explain how to control these values (with SnappyHexMesh?) ? Thanks again for the quick responses...

 February 22, 2011, 10:15 #6 Senior Member   Felix L. Join Date: Feb 2010 Location: Hamburg Posts: 165 Rep Power: 18 Yeah, unfortunately your first cell layer heights are much too big, these y+ values are inacceptable. On the other hand, the minimum y+ values are too small to allow usage of wall functions! So you have problems on both sides of the y+ margin... Sorry, I never used snappyHexMesh before so I can't help you with how to control the first cell layer height. There have to be options inside the snappyHexMeshDict that might be helpful to control this height, but I have no idea what optiones these could be. Searching the forums or waiting for someone else to reply hopefully solves your problem! Good luck with that, Felix.

 February 23, 2011, 05:50 #7 Senior Member   stephane sanchi Join Date: Mar 2009 Posts: 314 Rep Power: 18 Hi Carl, With sHM you can modify and control the following 3 parameters: --------------------------------- // Settings for the layer addition. relativeSizes true; expansionRatio 1.2; finalLayerThickness 0.3; --------------------------------- relativeSizes false; means absolute size. See sHM user guide for more details. Best regards, Stephane.

 June 8, 2011, 23:26 #8 New Member   farahidayu Join Date: Aug 2010 Posts: 20 Rep Power: 15 Hi Stefane & Felix, I am running a external aerodynamics case of a car and I also experience with the bounding k and omega values during iteration. My y+ values are also similar to what Carl obtained with min y+ of between 0-1 and max y+ of about 100. I am using the k-w SST turbulence model and I've done the near-wall layers closest to the car surface. Do I also need to meet the y+ target of min 30 and max 100-300? How can I increase the min value margin to 30? I am not really sure what I should do with the nearest-wall layer thickness to improve this y+ values. Hope to get some help on this. Regards, Ayu

June 9, 2011, 07:14
#9
Senior Member

Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 368
Rep Power: 20
Quote:
 Originally Posted by cjm Yes sure. Should have done it before... yPlus (start values after meshing): coarse: y+ : min: 24.8727 max: 6849.56 average: 579.113 medium: y+ : min: 16.1537 max: 5377.99 average: 525.403 fine: y+ : min: 16.2789 max: 4406.01 average: 396.97 Yes, I´m using wallfunctions (omegaWallFunction, nutWallFunction and kqRWallFunction - but no R-file at all [shouldnt be bad,right?]) Schemes: Code: ```ddtSchemes { default steadyState; } gradSchemes { default Gauss linear; grad(p) Gauss linear; grad(U) Gauss linear; // grad(U) cellLimited Gauss linear 1; } divSchemes { default none; div(phi,U) Gauss linearUpwindV Gauss linear; div(phi,k) Gauss limitedLinear 0.2; div(phi,omega) Gauss limitedLinear 0.2; div((nuEff*dev(grad(U).T()))) Gauss linear; } laplacianSchemes { // default Gauss linear corrected; default Gauss linear limited 0.2; // default Gauss linear limited 0.333; } interpolationSchemes { default linear; interpolate(U) linear; } snGradSchemes { default corrected; } fluxRequired { default no; p; }``` Solution: Code: ```solvers { p { solver GAMG; tolerance 1e-7; relTol 0.1; smoother GaussSeidel; nPreSweeps 0; nPostSweeps 2; cacheAgglomeration on; agglomerator faceAreaPair; nCellsInCoarsestLevel 10; mergeLevels 1; }; "(U|k|omega)" { solver PBiCG; preconditioner DILU; tolerance 1e-05; relTol 0.1; }; } SIMPLE { nNonOrthogonalCorrectors 0; } relaxationFactors { p 0.3; U 0.7; k 0.7; omega 0.7; }``` Any Ideas (your first ones seem to be quite good already) - Thanks... und liebste Grüße in die Hansestadt
Well, apart from the grid-quality issue, I think that there are some changes to try on the fvSolution/Schemes dictionaries...

1) lower the relaxationFactors for k and omega to 0.5
2) change div(phi,U) to linearUpwindV cellMDLimited Gauss linear 1
3) change div(phi,k/omega) to Gauss upwind (I know it is only first order, but usually the convective terms inherent to the turbulent quantities are quite unstable and sensitive to higher order discretization schemes, while you can improve a lot the accuracy of the solution using a higher order scheme only on div(phi,U) )
4) change the laplacian schemes to Gauss linear limited 0.5 (usually there's no need to force the limiter value below 0.5, as it will simply slower the convergence without any benefits on stability) and coherently the snGradSchemes to default limited 0.5.
5) lower the tolerance value of the solvers for k,omega,U to at least 1e-10 (this is important especially for omega, as sometimes the residuals for the omega equation fall very quickly to pretty low values and the risk of stop in solving the equation too soon should be avoided)

Hope this helps

V.