CFD Online Discussion Forums - Diverging Solution when using turbulentMixingLengthDissipationRateInlet

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)

- - Diverging Solution when using turbulentMixingLengthDissipationRateInlet (https://www.cfd-online.com/Forums/openfoam-solving/237429-diverging-solution-when-using-turbulentmixinglengthdissipationrateinlet.html)

Diverging Solution when using turbulentMixingLengthDissipationRateInlet

Hi everyone!

I'm currently working on a case of an engine with the piston moving according to crank rod angle.

The simulation works fine with rhoPimpleFoam and similar solvers, though I'm encountering this issue:

when using both k-epsilon and k-omega, if I put a fixedValue at inlet, the simulations run nicely, while if I put the specification of turbulentMixingLengthDissipationRateInlet (or turbulentMixingLengthFrequencyInlet) , which is what I really want to use, the solvers crashes in few steps, generating the error of negative temperature.

What do you think can be the main problem in setting this BC?

Tell me if uploading the BC field or some dicts may help.

Thank you very much!

Such complicated b.c. are often developed and tested at a typical test case only. It may happen that they have not the stability which more general b.c. have.

Negative temeratures are the result of instable simulation. You should try two things:

- Store the result frequently and look where the instability first occurs. Look at the mesh there.
- Use more stable simulation conditions.

Thank you for your answer.

I don't think it is a mesh related issue, since I tried many different refinements but the outcome is always the same.

Can i ask you to check is these numerics are stable enough? Do you think I should change something?

Code:

ddtSchemes

{

    default         Euler;

}



gradSchemes

{

    default         Gauss linear;

}



divSchemes

{

    default         bounded Gauss upwind;

    div(phi,U)      Gauss upwind;

    div(phi,e)      Gauss upwind;

    div(phid,p)     Gauss upwind;

    div(phi,K)      Gauss upwind;

    div(phiv,p)     Gauss upwind;

    div(phi,k)      Gauss upwind;

    div(phi,epsilon) bounded Gauss upwind;

    div(phi,burnt) Gauss upwind;

    div(((rho*nuEff)*dev2(T(grad(U))))) Gauss linear;

}



laplacianSchemes

{

    default         Gauss linear limited corrected 0.5;

}



interpolationSchemes

{

    default         linear;

}



snGradSchemes

{

    default         corrected;

}



fluxRequired

{

        p;

}

Code:

solvers

{

    "(p|rho)"

    {

        solver          GAMG;

        smoother          DIC;

        tolerance       1e-8;

        relTol          0.01;

    }



    "(p|rho|pcorr)Final"

    {

        $p;

        //relTol          0;

    }



    "(U|k|epsilon|burnt|h)"

    {

        solver          smoothSolver;

        smoother        GaussSeidel;

        tolerance       1e-8;

        relTol          0.01;

    }



    "(U|k|epsilon|burnt|h)Final"

    {

        $U;

        relTol          0;

    }

}



PIMPLE

{

    nOuterCorrectors    4;

    nCorrectors         3;

    nNonOrthogonalCorrectors 2;

}



relaxationFactors

{

    equations

    {

        "(U|k|epsilon).*"   1;

    }

}



cache

{

    grad(U);

}

You may switch form upwind to linear upwind. It is more stable, but also more diffusive.

Do you have any relaxation? I recommend using it, at least at the beginning.

doesn't relaxation factors induce delay in unsteady simulations?
If not, how do you raccomand to impose them?

Yes, relaxation has an effect. But it is improtant that the simulation starts at all. You may stop it and reduce relaxation at later simulated time.

in fvSolution:

Code:

relaxationFactors

{

    "(U|T|k|epsilon|omega|R)"                     0.7;

     "p"                                          0.3;

}