CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Courant number go so high

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 12, 2019, 05:04
Post Courant number go so high
  #1
New Member
 
John
Join Date: Mar 2019
Posts: 26
Rep Power: 7
thintn222 is on a distinguished road
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 !
thintn222 is offline   Reply With Quote

Old   April 15, 2019, 03:13
Default
  #2
Senior Member
 
Robert
Join Date: May 2015
Location: Bremen, GER
Posts: 292
Rep Power: 11
RobertHB is on a distinguished road
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.
__________________
If you liked my answer to your question, please consider leaving a "Like" in return
RobertHB is offline   Reply With Quote

Old   April 15, 2019, 03:35
Default
  #3
New Member
 
John
Join Date: Mar 2019
Posts: 26
Rep Power: 7
thintn222 is on a distinguished road
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 !
thintn222 is offline   Reply With Quote

Old   April 15, 2019, 03:43
Default
  #4
Senior Member
 
Robert
Join Date: May 2015
Location: Bremen, GER
Posts: 292
Rep Power: 11
RobertHB is on a distinguished road
Quote:
Originally Posted by thintn222 View Post
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?
__________________
If you liked my answer to your question, please consider leaving a "Like" in return
RobertHB is offline   Reply With Quote

Old   April 15, 2019, 09:31
Default
  #5
New Member
 
John
Join Date: Mar 2019
Posts: 26
Rep Power: 7
thintn222 is on a distinguished road
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 !
thintn222 is offline   Reply With Quote

Old   April 16, 2019, 04:21
Default
  #6
Senior Member
 
Robert
Join Date: May 2015
Location: Bremen, GER
Posts: 292
Rep Power: 11
RobertHB is on a distinguished road
Quote:
Originally Posted by thintn222 View Post
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.
__________________
If you liked my answer to your question, please consider leaving a "Like" in return
RobertHB is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
decomposePar problem: Cell 0contains face labels out of range vaina74 OpenFOAM Pre-Processing 37 July 20, 2020 05:38
[snappyHexMesh] Error snappyhexmesh - Multiple outside loops avinashjagdale OpenFOAM Meshing & Mesh Conversion 53 March 8, 2019 09:42
decomposePar -allRegions stru OpenFOAM Pre-Processing 2 August 25, 2015 03:58
Cluster ID's not contiguous in compute-nodes domain. ??? Shogan FLUENT 1 May 28, 2014 15:03
DecomposePar unequal number of shared faces maka OpenFOAM Pre-Processing 6 August 12, 2010 09:01


All times are GMT -4. The time now is 21:13.