About the "floating point exception" error

[Pablo]

Hello everybody:

This is not an original thread as there are many people posting the same error as it seems to be a error related with several sources which may lead to a common end: a division by zero, and this result may be because of a property calculation, a boundary condition mismatch etc.

Am I right or my guesses are innacurate?
...in that case, as there is not more information rather than the error files, is there any "clue" within the generated error files which may help to find the trouble origin?

My case: an OFA mixing optimization in grate-fired Biomass Boilers. A quite simple simulation (in terms of considered mechanisms) but a highly turbulent phenomena requirement.
I have performed several simulations for a fixed geometry (and a fixed mesh) and a fixed flue gases flow (@ 1200ºC) for several OFA entry conditions (increasing air speed for a fixed temperature of 200ºC) but as higher the OFA velocity inlet is (~80 m/s), the more common the "floating point exception" errors become. The density is the only temperature-dependent variable, but I guess as more turbulent the mixture is, the simulation seems to be more critical, so my solutions has been:

- Increase mesh refinement in OFA mixture zone. (several tries has been performed, from a global refinement to a local high refinement strategy)

- Reduce pseudo-timestep and increase the number of iterarions.

- Solver precision reduction in order to avoid "oscilating" residues during calculation stages. (from 10e-8 to 10e-5)

...but although the simulation reachs a higher iteration, it always stops with a "floating point exception" error.

So ...

a) Is there a suggested robust strategy to face these situations?. I have thought (and tested) the using of a "rough" solution (slower OFA velocity based stable solutions) as an initial solution for the simulation, but no improvements has been founds on the results.

b) Is the Standard k-epsilon turbulence model adequate for MOST of the situations or it could be suggestionable to change it in high-turbulent situations (as this one)?

c) How could the "floating point exception" error files analyzed constructively?


Thanks for your attention.

[Yvan Fournier]

Hello,

I assume you also read the "best practice" guidelines in the documentation section of this website.

It may contain a few additional suggestions relative to the ones you listed (if some things we list in this thread are missing, please remind us to add them).

As you may have mesh robustness issues, I would add :

- add reconstruction "sweeps" for the right hand sides (in the GUI, in the numerical options). The defaults (1 for scalars, 2 for pressure) are OK for "very orthogonal" meshes, but you may need more sweeps (or activate the "iswdyn" keyword in cs_user_parameters.f90).

- Adding pressure relaxation is a less precise solution (OK for steady flows, not great for transient flows), but may work also.

The "error*" files are very useful for developers or others very familiar with the code. Combining the adresses with the Linux "addr2line" utility provides the line number where errors occur when the code is configured in debug mode (we recommend a second, "--enable-debug" build, slower ,but very useful for debugging, as it is better instrumented).

The linear-production k-epsilon should be better than the standard variant.

Also, when the computation fails at a given time step, re-running it for "n_time_steps_crash -1" time steps and postprocessing the last few time steps may help understand which variables start to diverge first, which may help.

Regards,

Yvan