turbFoam floating point exception and k-epsilon
 

Hi,

I got two questions:
Does anyone have an idea what the reason for this floating point exception could be:

Courant Number mean: 5.18024e+43 max: 4.56829e+47
DILUPBiCG: Solving for Ux, Initial residual = 0.877633, Final residual = 9.78282e-09, No Iterations 2
DILUPBiCG: Solving for Uy, Initial residual = 0.938388, Final residual = 9.62189e-09, No Iterations 2
DILUPBiCG: Solving for Uz, Initial residual = 0.952206, Final residual = 2.34812e-08, No Iterations 2
DICPCG: Solving for p, Initial residual = 1, Final residual = 0.00298175, No Iterations 1001
time step continuity errors : sum local = 1.19866e+81, global = -3.05383e+62, cumulative = -3.05383e+62
DICPCG: Solving for p, Initial residual = 9.50744e-07, Final residual = 9.50744e-07, No Iterations 0
time step continuity errors : sum local = 2.17993e+170, global = -1.77391e+136, cumulative = -1.77391e+136
#0 Foam::error::printStack(Foam::Ostream&) in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Uninterpreted: [0xffffe420]
#3 Foam::DILUPreconditioner::calcReciprocalD(Foam::Fi eld<double>&, Foam::lduMatrix const&) in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#4 Foam::DILUPreconditioner::DILUPreconditioner(Foam: :lduMatrix::solver const&, Foam::Istream&) in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#5 Foam::lduMatrix::preconditioner::addasymMatrixCons tructorToTable<Foam::DILUPreconditioner>::New(Foam ::lduMatrix::solver const&, Foam::Istream&) in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#6 Foam::lduMatrix::preconditioner::New(Foam::lduMatr ix::solver const&, Foam::Istream&) in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#7 Foam::PBiCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#8 Foam::fvMatrix<double>::solve(Foam::Istream&) in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libfiniteVolume.so"
#9 Foam::lduMatrix::solverPerformance Foam::solve<double>(Foam::tmp<Foam::fvMatrix<doubl e> > const&) in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libincompressibleTurbulenceModels.so"
#10 Foam::turbulenceModels::kEpsilon::correct() in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libincompressibleTurbulenceModels.so"
#11 main in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/turbFoam"
#12 __libc_start_main in "/lib/i686/libc.so.6"
#13 Foam::regIOobject::readIfModified() in "/home/adam/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/turbFoam"
Floating point exception

And my second question:

What is influenced by the choice of InternalField in the file for k und epsilon?
At the moment I had small numbers like 1e-11 for both.
Does someone have literature for this case?


Thanks and best regards.

Hi,

My guess is that your deltaT is very large !

Courant Number mean: 5.18024e+43 max: 4.56829e+47
and
time step continuity errors : sum local = 2.17993e+170, global = -1.77391e+136, cumulative = -1.77391e+136

I would suggest to check your log file and check the Courant number from first time step. If its increasing exponentially( my guess), then use 1/10th of current delta t till you get Courant number near 1 or less. Courant number should be below 1.

Hope this helps
Rishi

Thanks for the really quick answer.

I will decrease my timesteps...and look up Courant number

Still the same problem.

I am trying the solve it with adjustable deltaT as described by niklas in this forum

Looks to me like you have a divergence problem with your solution; you are unlikely to solve this by adjusting the timestep (particularly by the time you get to a courant number e+47! Go back through the log file and see if you can identify which equation is having the problem at the start (you might notice that one of the equations is not converging, or stops converging, or suddenly requires 500 iterations to converge where it used to need 50). Is the mesh strongly non-orthogonal? If so, generate a better one or increase the non-orthogonality corrections. Try running with upwind differencing on the div term for a bit, or use simpleFoam to start the solution off.

Gavin