EnergyPlus™ is a whole building energy simulation program that engineers, architects, and researchers use to model both energy consumption and water use in buildings.
Inside the calendar cycle function, it compares the dq variable to zero, but dq is NaN, and it aborts.
double dq =
bilinear(state->average_range, state->n_cycles) - bilinear(state->average_range, state->n_cycles + 1);
if (dq > 0) // <<------ Floating Point Exception
Inside bilinear, a variable n is set to the size of D_unique_vect, which is 1. So inside there, the code drops into an else block and calls C = util::linterp_col(params->cal_cyc->cycling_matrix, 1, cycle_number, 2);. Because n == 1 in there, it drops into this IF block:
if ( ixcol >= mat.ncols()
|| iycol >= mat.ncols()
|| n < 2 )
return std::numeric_limits<double>::quiet_NaN();
And simply returns NaN and attempts to do math on it. Seems odd to be assigning to NaN and just attempting to blindly do math on it.
This revealed itself when I updated our Decent CI machines to Ubuntu 22.04, but I am also seeing it on my 20.04 machine in the debugger.
@shorowit @nmerket @yzhou601 let me know if there's anything I can do to help. Maybe this has been protected in a newer ssc and we just need to update? This is causing the LiIon battery file to fail in our debug tests, and presumably do NaN math quietly in our release build. This may all be contained within the SSC code, but if so, there may need to be an extra compiler setting to hush the FPE trap inside SSC. Or something.
Details
Some additional details for this issue (if relevant):
Platform: Ubuntu 20.04 and 22.04, maybe other platforms as well
Version of EnergyPlus: develop as of today (557201b3c0ec9d8b5e7235cd4c8d893c4e01fef4), DEBUG build
@shorowit @nmerket @yzhou601 let me know if there's anything I can do to help here. This has been failing in our test suite for quite some time now, and as far as I can tell, it's because of an issue inside SSC.
Issue overview
Our debug builds are now showing a floating point exception inside the SSC third party library.
Relevant call stack:
Inside the calendar cycle function, it compares the
dq
variable to zero, butdq
is NaN, and it aborts.Inside
bilinear
, a variablen
is set to the size ofD_unique_vect
, which is 1. So inside there, the code drops into anelse
block and callsC = util::linterp_col(params->cal_cyc->cycling_matrix, 1, cycle_number, 2);
. Becausen == 1
in there, it drops into this IF block:And simply returns NaN and attempts to do math on it. Seems odd to be assigning to NaN and just attempting to blindly do math on it.
This revealed itself when I updated our Decent CI machines to Ubuntu 22.04, but I am also seeing it on my 20.04 machine in the debugger.
@shorowit @nmerket @yzhou601 let me know if there's anything I can do to help. Maybe this has been protected in a newer ssc and we just need to update? This is causing the LiIon battery file to fail in our debug tests, and presumably do NaN math quietly in our release build. This may all be contained within the SSC code, but if so, there may need to be an extra compiler setting to hush the FPE trap inside SSC. Or something.
Details
Some additional details for this issue (if relevant):
Checklist