CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   simpleFoam k-omegaSST convergence problem (http://www.cfd-online.com/Forums/openfoam-solving/85292-simplefoam-k-omegasst-convergence-problem.html)

cjm February 22, 2011 06:35

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

FelixL February 22, 2011 08: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.

cjm February 22, 2011 09:02

3 Attachment(s)
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, Im 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 Gre in die Hansestadt :)

FelixL February 22, 2011 10:19

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.


Gre in die andere Hansestadt,
Felix.

cjm February 22, 2011 10:35

Yeah I tought about that as well, but since Im 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...

FelixL February 22, 2011 11:15

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.

openfoam_user February 23, 2011 06:50

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.

farahiam June 8, 2011 23:26

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

vkrastev June 9, 2011 07:14

Quote:

Originally Posted by cjm (Post 296417)
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, Im 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 Gre 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.


All times are GMT -4. The time now is 14:53.