Hello Everyone!
I think everybody faces to problem, which is called “Floating point exception”.
It is interesting to know, what do you usually do to solve such problem?
1 Like
Hi
But are you getting that error in our platform or you mean like in simulation in general?
Best,
Hi @Igarizza
this is a very interesting question and I have been affected by this many times myself. I decided to write down some of my personal experience with floating point exceptions in CFD, hoping that it will be helpful to others as well.
“Floating point exception” means that the solver detects an arithmetic operation which it cannot compute, for example, division by zero, or if the numbers exceed the bounds for the numerical data types used in the code. Mathematically speaking, we are dealing with divergence here.
Since I found it to have many potential causes, I have no 100% proven solution but a few suggestions that you could try.
Use upwind convection schemes
Upwind schemes introduce numerical diffusion but ensure convergence in certain cases. For steady-state simulations, the “bounded Gauss upwind” schemes are more appropriate since they ensure boundedness. Try to avoid higher-order schemes since they are more susceptible to divergence.
Double-check the initial and boundary conditions
I found that sometimes my initial or boundary conditions led to FPEs. Check that you’re not using zero for any of
- turbulent kinetic energy
- temperature
- pressure in compressible simulations (note that zero pressure is absolutely fine in incompressible simulations where no equation of state is solved)
The general rule is: unphysical values which cannot exist in reality (e.g. T=0 Kelvin, p=0 Pa) will also not work in simulations.
Limit the time step
Many simulation types (most notably multiphase simulations using the VOF method) are susceptible to a large time step. Especially during the first iterations, the flow velocities are often still low and the CFL criterion will cause the time step to be chosen too big. SimScale has the option to set a maximum timestep under “Simulation Control”. Here is a picture of how it looks:
Apply under-relaxation
Under-relaxation is a simple yet effective technique for updating the fields between iterations. The default way to update the field values in a new iteration would be to simply ignore the old value and replace it with the new values. Imagine you’re starting a simulation and have made an estimation for initial conditions. Most likely, this will be far off the final results, so you hope that the iterations will gradually change the values to make them converge to the final result. But what if the new field values are actually worse than the old ones? And what if the values for the next iteration will be even worse? This will lead to divergence.
The standard way to deal with this is called under-relaxation and is very effective. Instead of replacing the field values with the new result, it gets updated with a weighted average between the old and the new values. An under-relaxation factor of 1 corresponds to fully accepting the new result (hence no under-relaxation at all) while an under-relaxation factor of 0 corresponds to completely ignoring the new result (hence no updating with subsequent iterations). Values between 0 and 1 are used to stabilize the convergence process. Typically, we suggest starting with
- 0.7 for velocity
- 0.3 for pressure and other scalar fields
If the simulation diverges, try using lower relaxation factors (say 0.3 for velocity and 0.1 for pressure).
Try other linear equation system solvers
GAMG and smoothSolver could be worth a try. Especially smoothSolver performs quite well when the matrices have bad condition.
Please let me know if any of these approaches worked for you. Maybe others can share their experiences, too? I’m also interested to learn other things to try.
Happy simulating!
Hannes
12 Likes
@jprobst, awesome! Thanks for sharing! Regarding the convection schemes, I would add to this point:
that I would avoid higher-order schemes for the initial simulation setup until the simulation is running. Once the setup is stable, it might make sense to use higher order schemes to check/validate the accuracy/quality of the gained results.
1 Like
@dheiny good that you point this out - one should only trade off accuracy against stability where needed. Convergence can be treacherous sometimes. If one tries too hard to make a simulation converge, he could end up with a very inaccurate (or even wrong) result.
1 Like
@e0625598, unfortunately not yet. Right now you’d need to restart the sim from scratch with your adapted settings. But restarting from a paused state is something we are working on! I can not yet give you an exact release date though but will keep you posted!
Decrease the time step size when the courant number is increasing can also help.
1 Like