For real. What is happening here..... I'll try to log in and check myself.

Alright, let's try some builds on the CI machine for this branch and see what happens.

Running make -j 20

Oh, something weird with EnergyPlusData.cc... a compiler fatal error?

Re-running make -j 20:

Oh, something weird with HeatBalanceSurfaceManager.cc now?

Re-running make -j 20

OK, so now it's SurfaceGeometry.cc. Right.

Re-running make -j 20

Nevermind, it's something in the AFN code?

Let's just try make -j 4:

Hypothesis

So this little issue has popped up on a few branches, but it usually works fine. I am guessing we are running out of memory at some point. The machines are 20 thread, 16 GB of memory. We have set the max number of parallel builds to 16 here, but I think with the extra debug info, we're just barely bumping up against a limit and it's failing rarely. Something about this arithmetic branch is causing it to fail more consistently. I think I'm going to try bumping this down to 14 on this branch and see if it works. Sometime I'll try to tweak Decent to catch the error, because it would be helpful to at least see the cc1plus fatal error.

@jmarrec thoughts?

⚠️ Regressions detected on macos-14 for commit a01536d

• View Results
• Download Regressions

🤞

gcc --version on this?

20 threads and only 16 GB could cause issues indeed. I have 16 threads and 32 GB and am mostly fine. I have a laptop with 6 cores 12 threads and 16 GB and the compiler would regularly run out of memory (on OpenStudio SDK, not E+).

@Myoldmopar the macos 3 regressions has popped up on several PRs now. It's a false positive AFAIK...

One problem at a time @jmarrec ! Looks like CI is happy again, so I'm going to merge this and turn the dashboard green.

OK fine you sniped me. It turns out it's because there's a duplicate table in the E+ outputs. There's a few layers of things going on. One is that table diff seems to be trying to compare the different tables when it looks them up by name in a dictionary.

But to answer your next question, the reason this is just happening now is because I recently made "table size error" into a first-class table diff. This size error may have been here for a little while (not too long I think, or I would have seen it locally), but was just hushed on CI.

Now the next question -- why just in these three files? The problematic table is codenamed FullName:Initialization Summary_Entire Facility_DaySchedule. Taking the DD2009 output tabular file, it has one file that looks like:

<b>DaySchedule</b><br><br>
<!-- FullName:Initialization Summary_Entire Facility_DaySchedule-->
<table border="1" cellpadding="4" cellspacing="0">
  <tr><td></td>
    <td align="right">Name</td>
    <td align="right">ScheduleType</td>
    <td align="right">Interpolated {Yes/No}</td>
    <td align="right">Time (HH:MM) =&gt;</td>
    <td align="right">01:00</td>
    <td align="right">02:00</td>
    <td align="right">03:00</td>

and another that looks like:

<b>DaySchedule</b><br><br>
<!-- FullName:Initialization Summary_Entire Facility_DaySchedule-->
<table border="1" cellpadding="4" cellspacing="0">
  <tr><td></td>
    <td align="right">Name</td>
    <td align="right">ScheduleType</td>
    <td align="right">Interpolated {Yes/No}</td>
    <td align="right">Time (HH:MM) =&gt;</td>
    <td align="right">00:15</td>
    <td align="right">00:30</td>
    <td align="right">00:45</td>
    <td align="right">01:00</td>
    <td align="right">01:15</td>
    <td align="right">01:30</td>

Note that one table has hourly columns and one has timestep level reports. Why? Can confirm that only these three files have multiple Output:Schedule objects, one with hourly and one with timestep.

I took out the Output:Schedule:Hourly from both the baseline and branch IDFs and the regressions are again reporting no diffs happily.

Conclusion

I think the root of the problem here is that EnergyPlus is producing multiple tables with the same name. The table diff code could be made a little more intelligent, but I'm not sure exactly what I'd like it to do? I think the diffs are actually... good? We just need to fix it in the E+ code to give it a unique name.

I think it's worth a defect, but I will hold off until I'm sure. @jmarrec if you want to offer a defect and fix I'm open to it. If not that's fine, I can do it or maybe @JasonGlazer would want to...

Final Summary

Merging this, thanks @jmarrec

@jmarrec @Myoldmopar I had an error like this in the debug build that might be related to changes in this PR. I'm on Mac M2.

./EnergyPlus/src/EnergyPlus/ElectricPowerServiceManager.cc:4134:23: error: use of undeclared identifier 'fegetexcept'
    int old_excepts = fegetexcept();
                      ^

It seems mac doesn't have this function in fenv.h (https://github.com/mstg/iOS-full-sdk/blob/master/iPhoneOS9.3.sdk/usr/include/fenv.h) . Should we handle the case with something like this? Not sure if defaults to 0 is okay or do something else. Also according to the internet, Windows might not have this function either. I haven't tried to compile on windows though.

// Disable floating point exceptions around SSC battery calculations, which uses quiet_NaN in particular
#ifdef DEBUG_ARITHM_GCC_OR_CLANG
    #ifdef __APPLE__
        int old_excepts = 0; // Fallback for unsupported platforms
    #else
        int old_excepts = fegetexcept();
        fedisableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);
    #endif
#endif

@yujiex definitely this PR yes. I guess I'll need to address it, I was hoping @Myoldmopar would do it :)