CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Courant number go so high (https://www.cfd-online.com/Forums/openfoam-solving/216575-courant-number-go-so-high.html)

thintn222 April 12, 2019 05:04
Courant number go so high
 
Hi,all Foamers

I'm running a simulation about bubble rising using MPPICInterFoam solver, coupling LPT to VOF method . Everything is going well when i test with a simple domain . But when i tried it with a real domain about 90000 hexahedra of cells, It freezing at time step 4.503 because of the value of Courant number is so high , about XX e+12 .

I tried to decrease the deltaT in the ControlDict to be 1e-8 even 1e-9 but it still not work.

But when i decrease the number of cell from 90000->11250 . It worked well.

So, what is the problem ? How i can run this simulation at 90000 cell .

I attached my fvSolution, fvSchemes and checkMesh belowed.

Any help would be highly appreciated ,

Thank you so much for reading !


checkMesh
Code:
Mesh stats
    points:          97061
    faces:            276900
    internal faces:  263100
    cells:            90000
    faces per cell:  6
    boundary patches: 3
    point zones:      0
    face zones:      0
    cell zones:      0

Overall number of cells of each type:
    hexahedra:    90000
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:    0

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
    Patch              Faces    Points  Surface topology
    inlet              36      49      ok (non-closed singly connected)
    outlet              900      961      ok (non-closed singly connected)
    walls              12864    12936    ok (non-closed singly connected)

Checking geometry...
    Overall domain bounding box (-0.075 -0.075 0) (0.075 0.075 0.5)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (-1.25066e-16 -1.31008e-17 1.48292e-18) OK.
    Max cell openness = 1.35525e-16 OK.
    Max aspect ratio = 1 OK.
    Minimum face area = 2.5e-05. Maximum face area = 2.5e-05.  Face area magnitu                                                                                                                                                            des OK.
    Min volume = 1.25e-07. Max volume = 1.25e-07.  Total volume = 0.01125.  Cell                                                                                                                                                              volumes OK.
    Mesh non-orthogonality Max: 0 average: 0
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 1.11023e-13 OK.
    Coupled point location match (average 0) OK.

Mesh OK.
fvSchemes
Code:
ddtSchemes
{
      default        Euler;
}

gradSchemes
{
    default        Gauss linear;
}

divSchemes
{
    default        none;
    div(rhoPhi,U)              Gauss upwind;
    div(phi,alpha)              Gauss vanLeer;
    div(phirb,alpha)            Gauss linear;
    div(alphaRhoPhic,k)        Gauss upwind;
    div(alphaRhoPhic,epsilon)  Gauss upwind;
    div((((alphac*rho)*nuEff)*dev2(T(grad(U))))) Gauss linear;
    div(phiGByA,kinematicCloud:alpha) Gauss linear;
}

laplacianSchemes
{
    default        Gauss linear corrected;
}

interpolationSchemes
{
    default        linear;
}

snGradSchemes
{
    default        corrected;
}

fluxRequired
{
    default        no;
    p_rgh;
    pcorr;
    alpha.water;
}
fvSolution
Code:
solvers
{
    "alpha.water.*"
    {
        nAlphaCorr      2;
        nAlphaSubCycles 2;
        cAlpha          1;

        MULESCorr      yes;
        nLimiterIter    2;

        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance      1e-7;
        relTol          0;
        maxIter        100;
    }

    pcorr
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance      1e-5;
        relTol          0;
    }

    p_rgh
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance      1e-07;
        relTol          0.05;
    }

    p_rghFinal
    {
        $p_rgh;
        relTol          0;
    }

    "(U|k|epsilon).*"
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance      1e-06;
        relTol          0;
    }

    kinematicCloud:alpha
    {
        solver          GAMG;
        tolerance      1e-06;
        relTol          0.1;
        smoother        GaussSeidel;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 10;
        agglomerator    faceAreaPair;
        mergeLevels    1;
    }
}

PIMPLE
{
    momentumPredictor  no;
    nOuterCorrectors    1;
    nCorrectors        2;
    nNonOrthogonalCorrectors 2;
    pRefCell      0;
    pRefValue    0;

    residualControl
    {
          "(p|U)"
          {
          tolerance 1e-4;
          relTol 0;
          }
    }
  // convergence 1e-08;
}

relaxationFactors
{
    fields
    {
      p  1;
    }
    equations
    {
      U 1;
      k 1;
      epsilon 0.5;
      R      0.5;
      nuTilda 0.5;
      omega  0.5;
    }
}
Once again , thank you so much for reading !

RobertHB April 15, 2019 03:13
If it works with larger cells, but not with your smaller mesh, its likely that your cells are just too small. Either go with a larger mesh or decrease your timestep until it works.

thintn222 April 15, 2019 03:35
Thank you Robert for a kindly answer !

Actually when i try it with Euler-Euler solver with the same number of cells are 90000, it worked . But when i tried it with VOF solver , i didn't work . So i think may be the problem is not about the mesh . I tried to decreased the timestep even 1e-20 it still crashed . With adjustTimeStep (yes) it decreased like about 1e-30 .

Do you have any idea i can look for solving this problem, Sir !

RobertHB April 15, 2019 03:43
Quote:
Originally Posted by thintn222 (Post 730785)
I tried to decreased the timestep even 1e-20 it still crashed . With adjustTimeStep (yes) it decreased like about 1e-30 .
But VOF and adjustTimeStep works, as in does not crash, when the dT is decreased to ~ 1e-30?

thintn222 April 15, 2019 09:31
Yes, sir . It works well but with 1e-30s deltaT time and my total time of simulation is 200s . It will take so so long for that simulation. Do you have any suggestion, Sir .

Thank you for still spending time for me !

RobertHB April 16, 2019 04:21
Quote:
Originally Posted by thintn222 (Post 730827)
Yes, sir . It works well but with 1e-30s deltaT time and my total time of simulation is 200s . It will take so so long for that simulation.
Very well, so not all hope is lost. But if you consider how the Courant number is calculated
Co = \frac{u \cdot \Delta t}{\Delta x}
you can see that there are indeed very few variables that influence Co. I would assume that you dont want to or can not change your velocity because you want to observe a certain process. So the only variables you can change are the mesh size \Delta x or the timestep \Delta t.
If you want to keep your velocity and mesh resolution, you have to go with a timestep of 1e-30s. Want a larger timestep? Than you have to increase the mesh size.
One more option: The more cells you have, the longer a simulation takes. Maybe you can consider reducing your overall domain size.


All times are GMT -4. The time now is 16:35.