|
Problem using single precision in simpleFoam
Hello everybody,
I'm running simpleFoam simulations in double precision and in order to speed them up, I would like to switch to single precision. This works fine in the beginning of the simulation and the simulation is about 40% quicker (in terms of simulation time per iteration), but suddenly the simulation diverges. I get an error message that states that there is a "floating point exception". I don't have bounding epsilon or k before the simulation blows up. Does anyone of you know, what could be the reason? It would help me so much. Best regards, Bastian. |
This was my solution
Dear Bastian,
it is definitely worth running single precision but with turbulence model it is likely that occasional underflow/overflow happens in single precision. This causes exception and ends a computation which was otherwise going fine. To avoid it edit the file bashrc in folder etc and comment the line export FOAM_SIGFPE= so that exception will not be raised anymore. Regards, Luca |
Dear Luca,
that sounds great, but will the change influence the result of the computations in some way or is this just a thing to trick the computer? Thx already and best regards, Bastian |
Dear Bastian,
In my experience it will have absolutely no effect (apart from the slight difference you might anyway find switching from double to float), but you might want to look at the particular turbulence model you are using and figure out which part of it (likely damping function or similars) is causing it, to be sure it will not compromise the results. Regards, Luca |
Dear Luca,
ahh okay, then I will just run some cases in single precision and check out how the results change or if they are still acceptable. :) Best, Bastian |
Hi Luca,
I tried the solution, you supposed, but I still have the same problem. The simulation stops, because of a floating point exception. In the following I attach the error-message, which I get in the log-file. Hopefully somebody else had a similar problem already. Regards, Bastian Here comes the error message: Code:
|
Dear Bastian,
I think you have a different problem here: iteration 191 shows that solution for k and epsilon is alerady diverging so that the successive failing is not a big surprise to me. My experience was for sudden floating point error in a well converging solution. It might be that the switch to single precision is influencing your solution if you are using fine near-wall mesh for k-eps. I do not have much experience on this, but I guess you should check your solution starting from a few iterations before it stops. Regards, Luca |
Dear Luca,
I agree that timestep #191 is already looking strange and that it is not a big surprise that I get divergence. However, timestep #189 looks still perfectly fine. The solution diverges more or less in 2-3 timesteps. Below you can see the last few timesteps. Best regards, Bastian Code:
|
Dear Bastian,
I think the problem is iteration 190: you see that k equation failed to solve, doing 1001 iterations (the default limit) with diverging residual. This is something that sometimes happens when you run in parallel, even in double precision, using DILUPBiCG (I'm quite sure that it would be ok if you could run on a single cpu). I suggest you require a small relative tolerance and either limit the max iter to a small value (5 or 10) which will prevent diverging or you better switch to a smoothSolver for turbulence fields. Regards, Luca |
Dear Luca,
thx for the answer, I will try your suggestions immediately. Running on a single CPU, however, is impossible, since the mesh is rather big (13M cells). I will keep you updated about the progress. Best regards, Bastian |
Quote:
|
Quote:
I guess here there is no issue of compromising with the result. rather the floating point error occurs as at that specific node sudden jump of fall in the value occurs (or might be division by zero i.e by very small quantity). This is causing operator overflow for floating point and thus the error occurs......fooling the comp using edited "bashc" will only ask the solver to go ahead.......!!! :D:confused::confused: In the error posted by basned before i could see that the is a singler solution for solving k...that is the main reason for floating point exception......!!! |
Hello Vishal,
you are right, the entry in the bash forces the solver to continue, which eventually does not solve the problem. :D However, the solution to the problem was for me, as suggested by Luca, to use the smoothSolver instead of the PBiCG solver for turbulence fields. Have a nice weekend! |
i am really sorry i am little weak on this part....can you tell me where can i get reference to these different solvers...as i would love to know the selection criteria for them...or if u have can u maill me.... at
vishalljambhekar@gmail.com |
Quote:
rsingh@knicklenker:~/openfoam/SurgeTank/SymTANKMESHMOD> #0 Foam::error:rintStack(Foam::Ostream&) in "/mnt/opt.net/src/OpenFOAM/OpenFOAM-1.6/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libOpenFOAM.so" #1 Foam::sigFpe::sigFpeHandler(int) in "/mnt/opt.net/src/OpenFOAM/OpenFOAM-1.6/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libOpenFOAM.so" #2 ?? in "/lib64/libc.so.6" #3 void Foam::MULES::limiter<Foam::geometricOneField, Foam::zeroField, Foam::zeroField>(Foam::Field<double>&, Foam::geometricOneField const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::zeroField const&, Foam::zeroField const&, double, double, int) in "/mnt/opt.net/src/OpenFOAM/OpenFOAM-1.6/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libfiniteVolume.so" #4 void Foam::MULES::explicitSolve<Foam::geometricOneField , Foam::zeroField, Foam::zeroField>(Foam::geometricOneField const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>&, Foam::zeroField const&, Foam::zeroField const&, double, double) in "/mnt/opt.net/src/OpenFOAM/OpenFOAM-1.6/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libfiniteVolume.so" #5 Foam::MULES::explicitSolve(Foam::GeometricField<do uble, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>&, double, double) in "/mnt/opt.net/src/OpenFOAM/OpenFOAM-1.6/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libfiniteVolume.so" #6 main in "/mnt/opt.net/src/OpenFOAM/OpenFOAM-1.6/OpenFOAM-1.6.x/applications/bin/linux64GccDPOpt/interFoam" #7 __libc_start_main in "/lib64/libc.so.6" #8 _start at /usr/src/packages/BUILD/glibc-2.10.1/csu/../sysdeps/x86_64/elf/start.S:116 ^C [1]+ Floating point exceptioninterFoam > log |
Hi Everybody,
I am using simpleFoam to solve an incompressible flow. Following some of the suggestions here I commented the line "export FOAM_SIGFPE=" in the bashrc file. After some 290 iterations, the solution was showing solution singularity for the velocity fields. But the simulation was running without giving me any error. I used to get the sigfpe error before I edited the above line in bashrc. I used smoothsolvers for the turbulence fields and they were running fine. For the velocity and pressure fields I had the PBiCG option. Could anybody tell me if there is anything else I could do to improve the solution? Thank you and Regards, Srikara |
| All times are GMT -4. The time now is 12:13. |