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/)
-   -   rhosimplefoam : error in solving the energy equation (https://www.cfd-online.com/Forums/openfoam-solving/172190-rhosimplefoam-error-solving-energy-equation.html)

Zal May 25, 2016 12:33

rhosimplefoam : error in solving the energy equation
 
1 Attachment(s)
Hi,
I am trying to use openfoam for a compressible case with rhosimplefoam solver but I have always the same error after 3 iterations. It seems that the error happens with the energy equation during the calculation of the pressure.

I'am studying the drag coefficient on an intake.

I have tried to make a calculation without my geometry. (only a simple blockmesh) and I obtain the same error ...

I try to change my boundary conditions and the different solvers/schemes but i always obtain the same result.

The calculation works with the incompressible solver simplefoam.

I am sorry, i have not internet on the computer with openfoam so i post a screen of the error message
Attachment 47737

Have you any idea about a way to solve my probleme ?

Thank you for your attention

fvsolution :
Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  v3.0+                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.com                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      dictionary;
    location    "system";
    object      fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
    p
    {
        solver          GAMG;
        tolerance      1e-08;
        relTol          0.1;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps    2;
        nFinestSweeps  2;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 20;
        agglomerator    faceAreaPair;
        mergeLevels    1;
    }

    "(U|e|k|epsilon)"
    {
        solver          GAMG;
        tolerance      1e-08;
        relTol          0.1;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps    2;
        nFinestSweeps  2;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 20;
        agglomerator    faceAreaPair;
        mergeLevels    1;
    }
}

SIMPLE
{
    nNonOrthogonalCorrectors 0;
    rhoMin          0.1;
    rhoMax          1.0;
    transonic      yes;
    consistent      yes;

    residualControl
    {
        p              1e-3;
        U              1e-4;
        e              1e-3;

        // possibly check turbulence fields
        "(k|epsilon|omega)" 1e-3;
    }
}

relaxationFactors
{
    fields
    {
        p              0.3;
        rho            0.3;
    }
    equations
    {
        p              0.3;
        U              0.7;
        e              0.7;
        k              0.7;
        epsilon        0.7;
    }
}

fvSchemes :
Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  v3.0+                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.com                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      dictionary;
    location    "system";
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
    default            steadyState;
}

gradSchemes
{
    default            Gauss linear;
}

divSchemes
{
    default            none;

    div(phi,U)          bounded Gauss upwind;
    div(((rho*nuEff)*dev2(T(grad(U)))))      Gauss linear;
    div(phi,e)          bounded Gauss upwind;
    div(phi,epsilon)    bounded Gauss upwind;
    div(phi,k)          bounded Gauss upwind;

    div(phid,p)        bounded Gauss upwind;
    div(phi,Ekp)        bounded Gauss upwind;
    div((phi|interpolate(rho)),p)  Gauss upwind;
}

laplacianSchemes
{
    default        Gauss linear corrected;
}

interpolationSchemes
{
    default        linear;
}

snGradSchemes
{
    default        corrected;
}

fluxRequired
{
    default        no;
    p;
}

// ************************************************************************* //

thermophysicalproperties :
Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  v3.0+                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.com                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      dictionary;
    location    "constant";
    object      thermophysicalProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

thermoType
{
    type            hePsiThermo;
    mixture        pureMixture;
    transport      sutherland;
    thermo          hConst;
    equationOfState perfectGas;
    specie          specie;
    energy          sensibleInternalEnergy;
}

mixture
{
    specie
    {
        nMoles      1;
        molWeight  28.9;
    }
    thermodynamics
    {
        Cp          1004;
        Hf          2.544e+06;
    }
    transport
    {
        As          1.4792e-06;
        Ts          116;
    }
}


// ************************************************************************* //

turbulenceProperties :
Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  v3.0+                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.com                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      dictionary;
    location    "constant";
    object      turbulenceProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

simulationType  RAS;

RAS
{
    RASModel        kEpsilon;

    turbulence      on;

    printCoeffs    on;
}


// ************************************************************************* //


p :
Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  v3.0+                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.com                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      volScalarField;
    object      p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [1 -1 -2 0 0 0 0];

internalField  uniform 7.5e+3;

boundaryField
{
    walls_2
    {
        type            zeroGradient;
    }
   

    inlet
    {
        type            zeroGradient;
    }

    outlet
    {
        type            fixedValue;
            value                uniform 7.5e+3;

    }
}


// ************************************************************************* //

U :
Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  v3.0+                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.com                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      volVectorField;
    object      U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 1 -1 0 0 0 0];

internalField  uniform (0.7 0 0);

boundaryField
{
    walls_2
    {
        type            fixedValue;
        value          uniform (0 0 0);
    }   

    inlet
    {
        type            fixedValue;
        value          uniform (0.7 0 0);
    }
   
    outlet
    {
        type            zeroGradient;
    }

}


// ************************************************************************* //


McCharles May 26, 2016 08:44

I'm using rhoSimpleFoam as well and facing almost the same problem, my calculation breaks down after 30 iterations while calculating the pressure. My fvSchemes and fv Solution folders are almost identical than yours.

I managed to prolongate the number of iterations before breakdown by strongly decreasing the relaxation Factors (for p, down to 0.1). Maybe try to initialize the fields with a potential calculation by adding

Code:

potentialFlow
{
    nNonOrthogonalCorrectors 3;
}

in the fvSolution file. It had a positive effect on my Simulation.

I see that you're using GAMG solvers. I don't know how many cells your mesh has and on how many cores your simulation is running, but maybe you should adapt ''nCellsInCoarsestLevel'' to the size of your mesh. The GAMG solver coarsens the initial Mesh by aglomerating cells together and nCellsInCoarsestLevel represents the number of cells in the coarsest level. A good approach is to set it to approx. sqrt(Number of Mesh Cells). If possible, don't use more than 16 cores with this kind of solver, otherwise, switch to a PCG solver.

I ran out of ideas how to fix this case, i tried almost everything and it keeps crashing after a few iterations. Is anyone else facing this issue with rhoSimpleFoam or knows how to keep it running until convergence?

Cheers!
Charles

Zal May 28, 2016 05:07

Hi,
thank you for your reply.

I have a mesh with only 1 million of cells and I work with a quadcore.

I will try to apply your advices to see if they improve the calculation.


I don't understand why it doesn't work .. I have no problem with the tutorial.
Maybe it comes from the openfoam version ? I use the 3.01 version .

One of my professor asked a Phd student who used openfoam in compressible case to see if he understands what's the problem; I am waiting for his answer.

cordially
Zal

McCharles May 28, 2016 08:46

Ok, then set nCellsInCoarsestLevel to 1024 and see if it is running faster.

I didn't solve the problem either... I created a very simple geometry to test the rhoSimpleFoam solver with the identical settings. The calculation broke down after a few iterations, so same problem here... I tried with many different fvSolution settings and finally managed to keep the calculation runing by finding the correct relaxationFactors in the SIMPLEL Loop. Also nNonOrthogonalCorrectors has an important effect. The rhoSimpleFoam solver is a real pain in the neck :rolleyes: Of course it could also have something to do with your OF version but i'm using the 2.3.1 version and i'm facing the same issue...

Now i'm trying to find the correct settings for my real case.
Please let me know if you find a better way to keep the simulation stable.

Cheers!

Zal May 31, 2016 07:54

Hi,

I think I solved my problem ..
I applied your advices and I corrected some stupid mistakes in my blockmeshdict and now the calculation is working (900 iterations) .

I have not changed anything else so I don't know if I can help you but if you want I can post again my files.


I don't know if you are aware but with compressible cases openfoam works with the mach number in U and not the speed in m/s. I didn't know it so maybe it's your problem ?

thank you for your help and your advices

Zal

McCharles May 31, 2016 08:27

I'm happy that I could help you! Hope it's going to converge now.
It would be great if you could post your fvSolution file again, i would like to see which relaxationFactors worked for your case.

In your first post, I noticed that you set rhoMin & rhoMax in the SIMPLE Loop to 0.1 & 1. I don't know what Fluid you're using but with these settings, your calculation is quite constricted because the density can't grow above 1.

Cheers

Zal May 31, 2016 12:41

2 Attachment(s)
I am sorry I have not internet on the computer where i use Openfoam.

I can only post screens.

Attachment 47894

Attachment 47895

good luck to solve your problems !
Don't hesitate if I can help you.

Zal June 1, 2016 04:08

I am sorry but I have an other question.

My teacher says me that it's better to use the mach number with compressible cases but in several examples on the internet people use the speed in m/s.

So I don't know what i should choose.

My calculation works well when I use the mach number but my density has significant and anomalous variations when I use the speed in m/s.

Other question : if I use mach number in my U file, I have to use the mach number in my forcesCoeff file ?

cordially

Zal

McCharles June 1, 2016 04:33

Hi Zal and thanks for your pictures.
Unfortunately, I don't know if it's possible to define the Ma-Number in the U file. As default, the dimensions in U are always [0 1 -1 0 0 0 0], so m/s. Setting the Ma-Number right away seems to be impossible, as far as I know.


There is a Mach utility in OpenFoam for post processing which allows you to calculate Ma out of your results for U. Maybe there is a special boundary condition that takes the Ma-Number as an entry value. Have you looked in the user Guide?
If you're working with high Ma-Numbers, you should try do use sonicFoam and compare your results.

Cheers!
Charles

Zal June 6, 2016 07:11

Hi,

I remark that the problem doesn't come from the fvsolution file but from the boundary conditions in the 0 file.

By example, if I used an uniform fixedvalue for U at inlet, my calculation doesn't work. But if I use the airflow (in order to have the same speed at inlet), I have no more problem.


Zal

McCharles June 6, 2016 07:19

Yes, same for me! I changed the pressure BC for the Inlet patch from fixed value to zeroGradient and specified the pressure for the Outlet patch and managed to keep the simulation running.

I think that the most instability problems occur because of problematic BC combination, even if they appear to be correct. With relaxation factors lower than 0.3, there shouldn't be any instability issues if the BC are set correctly.

Charles

Zal June 14, 2016 10:32

Hi,

Juste a message to say that I find a new way to improve the stability of the calcualtion.
If I use the "faceMDLimited Gauss linear 0.5;" for the gradSchemes it can help to solve some stability problemes.

McCharles June 15, 2016 04:00

Ok Thanks, I will give it a try!

Aeronautics El. K. August 10, 2016 04:55

Hi there Charles,
regarding the GAMG solver I'd like some clarification if you can :)

Quote:

Originally Posted by McCharles (Post 601936)
A good approach is to set it to approx. sqrt(Number of Mesh Cells).

I've seen that elsewhere but I don't have a convincing explanation. Is there some reasoning for this?

Quote:

Originally Posted by McCharles (Post 601936)
If possible, don't use more than 16 cores with this kind of solver, otherwise, switch to a PCG solver.

Why? :)


Thanks a lot.

Lefteris

Aeronautics El. K. August 10, 2016 05:00

Quote:

Originally Posted by Zal (Post 602790)
I am sorry but I have an other question.

My teacher says me that it's better to use the mach number with compressible cases but in several examples on the internet people use the speed in m/s.

So I don't know what i should choose.

My calculation works well when I use the mach number but my density has significant and anomalous variations when I use the speed in m/s.

Other question : if I use mach number in my U file, I have to use the mach number in my forcesCoeff file ?

cordially

Zal


Hi Zal,

I'm a bit confused as to how you set your Mach number in the 0/U file. Mach is dimensionless and the velocity in U is in m/s as Charles mentioned.
The only way that I'm aware to get your velocity is to calculate the speed of sound from the freestream conditions and work out your freestream V from the Mach number.

Zal August 10, 2016 06:07

Sorry, it was an error, I suppose that my teacher didn't use the same solver as me.

McCharles August 10, 2016 09:47

Hi Lefteris,

I can't justify why sqrt(Number of Mesh Cells) is a good approach to set the number of cells. In my opinion it would be bad to define a number of cells that is much smaller than the real number of cells (huge jumps between coarsening steps). So maybe the square root is a good compromise.

What i said about the nr. of cores for the GAMG solver wasn't exactly true. In fact, the GAMG algorithm agglomerates the cells of your mesh in bigger packs to form a coarser grid. Now if you decompose your Mesh for a parallel calculation, you also increase the amount of necessary communication between each CPU. OpenFOAM even tells you the number of neighbors a decomposed region has. So i believe that the GAMG algorithm, which also divides a mesh in certain region, is not ideal for strong parallelisation as the communication effort between each processor increases. But i recently heard that this characteristic is negligible for moderate parallelisation, which means under 100 or 150 CPUs. I am currently using GAMG with 24 processors and am able to calculate twice as fast, compared to calculations with a PCG solver.

Cheers :)

Aeronautics El. K. August 10, 2016 11:15

Hi Charles,
Thanks for your reply!

I believe we are on the same wavelength for the GAMG solver.
I don't like using only few cells as in some cases it messes up the solution altogether. I'm just trying to find the optimum setting and the explanation here ;)

As for the decomposition, I normally use no more than 24 cores as, like you said, there's no benefit for my simulations if I use more. I think however, that decomposition and the time the simulation takes (taking into account communication etc) is very system dependent.

Once again, thanks for your reply.

y_jiang September 13, 2018 14:40

Hello Antoine,


I got the same issue as you had. The calculation stopped at 9th iteration and came up with the error when solving energy equation.

My goal is to solve a pressure driven problem for a tank with 1 inlet and 2 outlet. As you guys discussed here, I knew that a given value of outlet pressure should work fine with a flow rate inlet. So I set my boundary conditions like below. But I still got the error.

Do you have any idea on it?

Any of your input would be appreciated. Thank you!


Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  5                                    |
|  \\  /    A nd          | Web:      www.OpenFOAM.org                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      volScalarField;
    object      p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [1 -1 -2 0 0 0 0];

internalField  uniform 600000;

boundaryField
{

    geofull_inlet1
    {
        type            zeroGradient;
        refValue        uniform 600000;
        refGradient    uniform 0;
    }

    geofull_outlet2
    {
        type            fixedValue;
        value          uniform 600000;
    }

    geofull_outlet3
    {
        type            fixedValue;
        value          uniform 600000;
    }

    geofull_needle1
    {
        type            zeroGradient;
    }

    geofull_needle2
    {
        type            zeroGradient;
    }

    geofull_needle3
    {
        type            zeroGradient;
    }

    geofull_tank
    {
        type            zeroGradient;

Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  5                                    |
|  \\  /    A nd          | Web:      www.OpenFOAM.org                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      volVectorField;
    object      U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 1 -1 0 0 0 0];

internalField  uniform (0 0 0);

boundaryField
{

    geofull_inlet1
    {
        type            flowRateInletVelocity;
        volumetricFlowRate    constant 0.5;
        rhoInlet        1;
//        massFlowRate    0.5;
//        rhoInlet        0.5;
    }

    geofull_outlet2
    {
        type            pressureInletOutletVelocity;
        value          uniform (0 0 0);
    }

    geofull_outlet3
    {
        type            pressureInletOutletVelocity;
        value          uniform (0 0 0);
    }

    geofull_needle1
    {
        type          noSlip;
    }

    geofull_needle2
    {
        type          noSlip;
    }

    geofull_needle3
    {
        type          noSlip;
    }

    geofull_tank
    {
        type          noSlip;
    }

}

// ************************************************************************* //


sufjanst October 5, 2018 07:43

I habe two suggestions:
1.) Try using sensibleEnthalpy instead of sensibleInternalEnergy in your thermophysicalProperties
2.) OpenFoam's Steady-State-Solver is not that stable as Fluent for example. It helps to give a initialisation so that the solver does not have to calculate the field from 0. I would try to use potentalFoam for your case.
It calculates really fast a first velocity field and overwrites the U in your 0-Folder (so make a backup). You can use the initial field for rhoSimpleFoam. The setup for potentialFoam should be somewhere in the tutorials.


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