CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM (http://www.cfd-online.com/Forums/openfoam/)
-   -   Convergence problem with tetrahedral grids (http://www.cfd-online.com/Forums/openfoam/82696-convergence-problem-tetrahedral-grids.html)

Tarak December 2, 2010 17:58

Convergence problem with tetrahedral grids
 
Hii,

I am running the case of flow over a square cylinder using LES by ICEM generated grid. But only after a few time steps, the code diverges, with Courant number crossing 4 or 5. I tried to use Upwind Schemes as well as first order time stepping to tackle the problem, but still the issue wasn't solved. At last, I increased the number of PISO non-orthogonal correctors to 5 (since increasing to 3 didn't help), and now its converging, but its painstakingly slow.

Can you please let me know of a way by which I can run OF with tethrahedral grids smoothly.

Thanks,
Tarak

maddalena December 3, 2010 04:28

I am also facing difficulties on getting a 3D tetra mesh converging with OF 1.6.x.
The case is quite standard: some pipes with two fans that put the fluid in motion. The geometry is complex and I have no possibility to use a hexa mesh. The case is steady state and turbulent (simpleFoam); BC are as tested on similar (working) cases.
fvSchemes are:
Code:

gradSchemes: faceMDLimited Gauss linear 0.5;
divSchemes: Gauss linearUpwind cellLimited Gauss linear 1;
laplacianSchemes: Gauss linear limited 0.5;

fvSolution:
Code:

p
    {
        solver          GAMG;
        tolerance      1e-12;
        relTol          0;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps    2;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 10;
        agglomerator    faceAreaPair;
        mergeLevels    1;
    }

    U - epsilon - k
    {
        solver          smoothSolver;
        smoother        GaussSeidel;
        tolerance      1e-10;
        relTol          0;
    }

SIMPLE
{
    nNonOrthogonalCorrectors 2;
    pRefCell        0;
    pRefValue      0;
}

relaxationFactors  ///really low in the beginning to let the simulation start.
{
    default        0;
    p              0.05;
    U              0.2;
    k              0.2;
    epsilon            0.2;
    nuTilda            0.3;
}

The solution converges for the first 150 steps nicely, but after on it start to get unstable and finally crashes. I really do not know what to do for keep it running...
Suggestions?

mad

vkrastev December 3, 2010 04:54

Quote:

Originally Posted by maddalena (Post 285832)
I am also facing difficulties on getting a 3D tetra mesh converging with OF 1.6.x.
The case is quite standard: some pipes with two fans that put the fluid in motion. The geometry is complex and I have no possibility to use a hexa mesh. The case is steady state and turbulent (simpleFoam); BC are as tested on similar (working) cases.
fvSchemes are:
Code:

gradSchemes: faceMDLimited Gauss linear 0.5;
divSchemes: Gauss linearUpwind cellLimited Gauss linear 1;
laplacianSchemes: Gauss linear limited 0.5;

fvSolution:
Code:

p
    {
        solver          GAMG;
        tolerance      1e-12;
        relTol          0;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps    2;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 10;
        agglomerator    faceAreaPair;
        mergeLevels    1;
    }

    U - epsilon - k
    {
        solver          smoothSolver;
        smoother        GaussSeidel;
        tolerance      1e-10;
        relTol          0;
    }

SIMPLE
{
    nNonOrthogonalCorrectors 2;
    pRefCell        0;
    pRefValue      0;
}

relaxationFactors  ///really low in the beginning to let the simulation start.
{
    default        0;
    p              0.05;
    U              0.2;
    k              0.2;
    epsilon            0.2;
    nuTilda            0.3;
}

The solution converges for the first 150 steps nicely, but after on it start to get unstable and finally crashes. I really do not know what to do for keep it running...
Suggestions?

mad

Hi Maddalena,
if you are using linearUpwind for all the divSchemes, try instead to set div(phi,U) to Gauss linearUpwindV faceMDLimited Gauss linear 1, and div(phi,k/epsilon) to Gauss upwind. By the way, why so strong underrelaxation factors? Have you tried to leave the URF for p at the 0.3 standard value, for U at 0.7 and to set the URF's for k and epsilon to 0.4-0.5?

Best Regards

Vesselin

vkrastev December 3, 2010 04:57

Quote:

Originally Posted by Tarak (Post 285792)
Hii,

I am running the case of flow over a square cylinder using LES by ICEM generated grid. But only after a few time steps, the code diverges, with Courant number crossing 4 or 5. I tried to use Upwind Schemes as well as first order time stepping to tackle the problem, but still the issue wasn't solved. At last, I increased the number of PISO non-orthogonal correctors to 5 (since increasing to 3 didn't help), and now its converging, but its painstakingly slow.

Can you please let me know of a way by which I can run OF with tethrahedral grids smoothly.

Thanks,
Tarak

Hi Tarak,
two hints: 1) use hexa-meshes for LES calculations; 2) you cannot use first order schemes for LES, because they are too diffusive: you'll have to use at least a limited second order scheme, such as limitedLinear.

Best regards

Vesselin

vkrastev December 3, 2010 05:02

Quote:

Originally Posted by vkrastev (Post 285836)
By the way, why so strong underrelaxation factors? Have you tried to leave the URF for p at the 0.3 standard value, for U at 0.7 and to set the URF's for k and epsilon to 0.4-0.5?

Oops, I haven't noticed the comment in the fvSolution dictionary :D So
, let me change the question: what are your URF's after the first n-steps in which you leave so low values?

maddalena December 3, 2010 05:29

Quote:

Originally Posted by vkrastev (Post 285843)
what are your URF's after the first n-steps in which you leave so low values?

Unfortunately, I cannot get too far to have the time to increase them! After 120 steps the solution starts to be unstable, thus increase them sounds as not a good idea...
Quote:

Originally Posted by vkrastev (Post 285843)
div(phi,k/epsilon) to Gauss upwind

you want to increase diffusion of turbulence quantities, do not you?

BTW... sounds a bit weird that, whenever I change my fvSchemes & fvSolution, I cannot get too far with my simulation. May there be something more subtle than this? May be due to the 2 fan BC I imposed?


mad

PS: seems like in the last day we are the only active people in the forum :rolleyes:

vkrastev December 3, 2010 06:37

Quote:

Originally Posted by maddalena (Post 285847)
you want to increase diffusion of turbulence quantities, do not you?

Yes, It's a matter of trade-off between accuracy and stability: I've noticed in some of my runs that changing only the div(phi,U) scheme to something more accurate than the first order upwind, gives very significant improvements to the results comparing with an all-upwind setting for the divSchemes. On the other hand, till now, with tetra-dominant meshes I was not able to reach satisfactory convergemce patterns for k and epsilon with higher order schemes...So, better a quite accurate and converging result, than a very accurate but no-converging-at-all result...;)

Quote:

Originally Posted by maddalena (Post 285847)
BTW... sounds a bit weird that, whenever I change my fvSchemes & fvSolution, I cannot get too far with my simulation. May there be something more subtle than this? May be due to the 2 fan BC I imposed?

Yes, the problem could be easily far from the fvSchemes/Solution tuning (what is your checkMesh "opinion" about it?)...unfortunately I have no experience with fan BC's, so I cannot give you any useful advice...:(


Quote:

Originally Posted by maddalena (Post 285847)
PS: seems like in the last day we are the only active people in the forum :rolleyes:

So it seems...;)

Vesselin

maddalena December 3, 2010 07:33

Quote:

Originally Posted by vkrastev (Post 285857)
better a quite accurate and converging result, than a very accurate but no-converging-at-all result...;)

Especially if you have some close-by deadlines... ;)
Quote:

Originally Posted by vkrastev (Post 285857)
what is your checkMesh "opinion" about it?

Code:

    Overall domain bounding box (-12 -1.804 -7.19731e-17) (14.905 1.804 10.0839)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-3.66027e-18 -7.23166e-17 -1.6178e-15) OK.
    Max cell openness = 2.94713e-16 OK.
    Max aspect ratio = 7.21422 OK.
    Minumum face area = 2.38932e-06. Maximum face area = 0.734457.  Face area magnitudes OK.
    Min volume = 2.87124e-09. Max volume = 0.183334.  Total volume = 327.312.  Cell volumes OK.
    Mesh non-orthogonality Max: 65.408 average: 20.4121
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.763815 OK.

checkMesh says that the problem lies somewhere else... :)
I will give a try to upwind on k and epsilon. Thank you in the meanwhile..

mad

vkrastev December 3, 2010 08:25

Quote:

Originally Posted by maddalena (Post 285864)
Especially if you have some close-by deadlines... ;)

That's for sure! :D

Quote:

Originally Posted by maddalena (Post 285864)
Code:

    Overall domain bounding box (-12 -1.804 -7.19731e-17) (14.905 1.804 10.0839)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-3.66027e-18 -7.23166e-17 -1.6178e-15) OK.
    Max cell openness = 2.94713e-16 OK.
    Max aspect ratio = 7.21422 OK.
    Minumum face area = 2.38932e-06. Maximum face area = 0.734457.  Face area magnitudes OK.
    Min volume = 2.87124e-09. Max volume = 0.183334.  Total volume = 327.312.  Cell volumes OK.
    Mesh non-orthogonality Max: 65.408 average: 20.4121
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.763815 OK.

checkMesh says that the problem lies somewhere else... :)

I agree with "him" ;)

Quote:

Originally Posted by maddalena (Post 285864)
I will give a try to upwind on k and epsilon. Thank you in the meanwhile..

Good luck! :)

V

santiagomarquezd December 6, 2010 12:33

Hi Tarak, Did you try renumberMesh after importing the mesh to FOAM? I've found that meshes imported from Fluent are not very efficient in the numeration and this impacts strongly in iterative solvers.

Regards.

maddalena December 7, 2010 02:09

Quote:

Originally Posted by santiagomarquezd (Post 286236)
Hi Tarak, Did you try renumberMesh after importing the mesh to FOAM? I've found that meshes imported from Fluent are not very efficient in the numeration and this impacts strongly in iterative solvers.

NB: this will not work if you have cyclic patch! When renumbering mesh, the cyclics will be lost!

mad

maddalena February 7, 2011 03:38

suggestions?
 
Hi everybody,
seems like all my problems are still there, on a case that is similar to what posted above. I wrote on a different thread: http://www.cfd-online.com/Forums/ope...tml#post293910
Maybe you can take a look to it and suggest something more on the subject...

mad

tcarrigan February 7, 2011 10:16

This is the thread I meant to post on. I started clicking your links and posted to the wrong one :). I'll repeat my post:

----------------------------------------------------------------
Just curious, have you tried using leastSquares for the gradScheme?

I did some 2D calculations for a NACA airfoil using both structured and unstructured grids. I too suffered convergence issues when running the calculation for the unstructured case. However, switching the gradScheme to a cellLimited leastSquares happened to solve the problem.

Let me know if this works.
----------------------------------------------------------------

And to answer your question, there may not be an advantage to using leastSquares, it's just an observation made from several simulations I've run for unstructured grids. Most of the time I have issues obtaining convergence when using tet grids and the Gauss linear gradScheme. Just and observation, was curious to see if it had any effect on your calculation.

maddalena February 7, 2011 10:20

Quote:

Originally Posted by tcarrigan (Post 293998)
And to answer your question, there may not be an advantage to using leastSquares, it's just an observation made from several simulations I've run for unstructured grids. Most of the time I have issues obtaining convergence when using tet grids and the Gauss linear gradScheme. Just and observation, was curious to see if it had any effect on your calculation.

Ok, I'll give it a try...

mad

Tarak February 7, 2011 11:26

Hii,

I would recommend using Gamma Differencing Scheme with appropriate blending factor for obtaining good convergence/stability for tetrahedral grids. This is how I managed to get the code run.

Thanks,
Tarak

maddalena February 9, 2011 04:27

Quote:

Originally Posted by tcarrigan (Post 293998)
Just curious, have you tried using leastSquares for the gradScheme?

I did some 2D calculations for a NACA airfoil using both structured and unstructured grids. I too suffered convergence issues when running the calculation for the unstructured case. However, switching the gradScheme to a cellLimited leastSquares happened to solve the problem.

So, here an answer to your observations: http://www.cfd-online.com/Forums/ope...tml#post294338

mad

hjasak February 9, 2011 08:57

In 1.6-ext, we've got special discretisation scheme for tet meshes: use it on convection in the momentum equation and on interpolate(U). The scheme is called reconCentral, and the settings for a tet mesh look like this:

gradSchemes
{
default cellLimited leastSquares 1.0;
}

divSchemes
{
div(phi,U) Gauss reconCentral cellLimited leastSquares 1.0;
//...
}

laplacianSchemes
{
default Gauss linear limited 0.5;
}

interpolationSchemes
{
default linear;
interpolate(HbyA) linear;
interpolate(U) reconCentral phi cellLimited leastSquares 1.0;
}

Enjoy,

Hrv


All times are GMT -4. The time now is 11:22.