floating point exception in external routines can kill OpenFOAM
Already needed a workaround in runTimePostProcessing to avoid this issue. Now found that some bad catalyst pipelines can also trigger floating point exceptions. For example, extracting a contour from a field that does not yet exist. The sigFpe trapping cascades this through and ends the OpenFOAM job. Ideally we'd instead like to ensure that any catalyst failures cannot pull down the simulation.
Activity
Any chance you could share the Python script that caused this issue? I created a script that used the Contour filter of a field that didn't exist and that didn't cause any issues. Granted, there wasn't any output but no warnings even, let alone a sigFpe.
By Andrew Bauer on 2018-06-25T18:27:07 (imported from GitLab project)
It's already there (contourBad2.py) but commented out. It doesn't trigger now after the fix. Note that the pipeline doesn't trigger a FPE directly, but our signal handler (when active) gets triggered. This is what the handler is normally catching sigFpe.C:
feenableexcept ( FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW ); struct sigaction newAction; newAction.sa_handler = sigHandler; newAction.sa_flags = SA_NODEFER; sigemptyset(&newAction.sa_mask);One speculation could be the FE_INVALID since I was contouring a field that did not yet exist. I'm not sure what the standard would say about this
double notInitialized[3]; // ... later notInitialized[2] *= 0.0;
