Details
-
Sub-task
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
None
-
Any version of the simulator running on NumPy.
-
Sprint 1.0.4 & 1.0.5
Description
In the context of the simulator, it is easy to imagine possible combinations of
parameters and models that are unstable, i.e. go to infinity or otherwise
produce NaNs. Specifically, when any of the variables in a simulation reaches a
NaN state, we never want to continue the simulation (this may not be the case
with any other component of the simulator, where NaN might be a placeholder for
legitimately missing information). Numpy's default behavior in the case of
operations resulting in NaNs is to print a RuntimeWarning to sys.stdout, but
provides a mechanism, via the floating point error family of functions [1],
to require NumPy to raise an exception in such cases, which would stop the
execution of a simulation with a FloatingPointError exception. This is far
more informative, e.g. when a simulation goes immediately to NaN everywhere
and then goes for 10 seconds of data full of NaNs.
We suggest as a fix in this issue that overflow, division by zero and invalid
exceptions have as their actions to raise an exception. Underflow is not fatal,
given our current experience and should have the default action. Concretely,
each operation that performs a simulation should adhere to the pattern:
>>> old_fp_error_handling = seterr(over='raise', divide='raise', invalid='raise')
>>> do_simulation_now()
>>> seterr(**old_fp_error_handling)
Please refer to [1] for the four possible floating point exceptions, the
six actions supported by NumPy, and descriptions of the functions.
[1] http://docs.scipy.org/doc/numpy/reference/routines.err.html