CFD Online Discussion Forums - simpleFoam k-omegaSST convergence problem

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)

- - simpleFoam k-omegaSST convergence problem (https://www.cfd-online.com/Forums/openfoam-solving/85292-simplefoam-k-omegasst-convergence-problem.html)

simpleFoam k-omegaSST convergence problem

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

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.

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 :)

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.

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

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.

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.

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

Quote:

Originally Posted by cjm (Post 296417)

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.