User file failing with NAN values in error DualSetPointWithDeadBand: Unanticipated combination of heating and cooling loads

[mjwitte]

Helpdesk ticket 10718 Similar problems were fixed in #4557 #4351 #4791 and #4646 Here is the error message

   ** Severe  ** DualSetPointWithDeadBand: Unanticipated combination of heating and cooling loads - report to EnergyPlus Development Team
   **   ~~~   ** occurs in Zone=L003_C01 During Warmup & Sizing, Environment=SHREVEPORT DOWNTOWN ANN HTG 99.6% CONDNS DB, at Simulation time=01/21 00:00 - 01:00
   **   ~~~   ** LoadToHeatingSetPoint=NAN, LoadToCoolingSetPoint=NAN
   **   ~~~   ** Zone Heating Set-point=15.56
   **   ~~~   ** Zone Cooling Set-point=27.78
   **   ~~~   ** Zone TempDepZnLd=2285.51
   **   ~~~   ** Zone TempIndZnLd=NAN
   **   ~~~   ** Zone ThermostatSetPoint=0.00
   **  Fatal  ** Program terminates due to above conditions.

Nothing else in the error output indicates a problem that may be contributing to this.

[mjwitte]

This error may be a clue, it's the same zone that is failing above.

   ** Warning ** Surfaces in Zone="L003_C01" do not define an enclosure.
   **   ~~~   ** Number of surfaces <= 3, view factors are set to force reciprocity.

[mjwitte]

Here is what the zone looks like. Duplicating the floor surface (and placing is a couple of meters higher) eliminates the error. Still would be good to trap this and quit before writing out NANs. Here is the problem zone.

[JasonGlazer]

@mjwitte: so the Nan is first being triggered in the pow_4() function when a surface temperature of -1.3e206 is overloading the range of the variable. That Nan winds its way through the code until it is getting caught in the Severe message about DualSetPointWithDeadBand. Clearly a surface temperature that low is meaningless and normally would have been caught where it was being generated in CalcHeatBalanceInsideSurf() but the line does not stop it because it is during warmup that this gets caught and the fatal only occurs when it is not warmup. The range of temperatures for that fatal is below -250 and above 250. Do you know why this is limited to providing a fatal error message only when not in warmup?

I was thinking about adding a new error message if the temperature is really ridiculous (below -1000 and above 1000) and it is during warmup. How about something like "The temperature of xx in zone yy for surface zz is very far out of bounds during warmup. This may be an indication of a malformed zone. "?

[mjwitte]

Fascinating. I don't recall why there would be a need to skip the error during warmup. @EnergyArchmage ? Is the -250 to +250 hard coded here? How does that relate to this input?

HeatBalanceAlgorithm,
  N1 , \field Surface Temperature Upper Limit
       \type real
       \minimum 200
       \default 200
       \units C

And curious that HeatBalanceAlgorithm doesn't have a input for Surface Temperature Lower Limit?

[JasonGlazer]

I think that 2.5 times the "Surface Temperature Upper Limit" field overrides the +250 if it is supplied see this code.

[EnergyArchmage]

If I remember correctly, the reason to let it run during warmup is in order to get some results to investigate to see what the underlying reason for the problem is. If you turn on report during warmup you can get some output to see what is going on; were it to fatal right away, nobody could debug the reason for the out of range surface temperature result. Of course now that it doesn't always quit on the first NaN this causes sneaky trouble.

[mjwitte]

So, perhaps the check should produce a non-fatal severe error during warmup? And the error message could include a suggestion to reportduringwarmup to see what is happening. It would probably need to have a limit on how many times it reports out. On the other hand, we really shouldn't let the surface get that cold. What are these limits used for if it only fatals out for 2.5xtheLimit?

[JasonGlazer]

I think it should be fatal to avoid propagation of Nan's maybe the limit for that should be -10,000C and 10,000C but somehow we need to guard against Nans showing up.

[EnergyArchmage]

Attempts to trap this are trickier than might be assumed. The 4th power of temperature in the IR distribution is terribly non-linear and results can get really wild. Sometimes it will produce some crazy numbers early and then settle back down and work out okay in the end. That is why the 2.5 * limit ( I think). This is about the best example of why letting NaNs run is huge problem (insert rant).

Here I think that the underlying reason is the malformed enclosure. When that <3 surface warning triggers AND these out-of-range results happen then it could fatal

[mjwitte]

@EnergyArchmage Understood, but if NANs were trapped, then execution would halt early anyway. So, the compromise is to throw a non-fatal error during warmup and let the NANs propagate, but at least there's information to work from. Or to use a reasonable value that won't overflow the 4th power like -10,000 that's fatal during warmup. But we don't want to add too much extra logic that's getting checked for every surface every iteration.

[JasonGlazer]

Here is the new err file with the proposed error message:

Program Version,EnergyPlus, Version 8.5.0-1e021e9512, YMD=2016.06.03 10:49,IDD_Version 8.5.0
   ** Warning ** Output:PreprocessorMessage="ExpandObjects" has the following Warning condition:
   **   ~~~   ** Cannot find Energy+.idd as specified in Energy+.ini.
   ** Warning ** Output:PreprocessorMessage="ExpandObjects" has the following Warning conditions:
   **   ~~~   ** Since the Energy+.IDD file cannot be read no range or choice checking was
   **   ~~~   ** performed.
   ** Warning ** Timestep: Requested number (1) is less than the suggested minimum of 4.
   **   ~~~   ** Please see entry for Timestep in Input/Output Reference for discussion of considerations.
   ************* Beginning Zone Sizing Calculations
   ** Warning ** Weather file location will be used rather than entered (IDF) Location object.
   **   ~~~   ** ..Location object=SHREVEPORT DOWNTOWN_LA_USA
   **   ~~~   ** ..Weather File Location=Chicago Ohare Intl Ap IL USA TMY3 WMO#=725300
   **   ~~~   ** ..due to location differences, Latitude difference=[9.45] degrees, Longitude difference=[5.83] degrees.
   **   ~~~   ** ..Time Zone difference=[0.0] hour(s), Elevation difference=[265.45] percent, [146.00] meters.
   ** Warning ** ProcessScheduleInput: Schedule:Day:Interval="SCHEDULE DAY COOLING 4180 SPACE TYPE", Blank Schedule Type Limits Name input -- will not be validated.
   ** Warning ** ProcessScheduleInput: Schedule:Day:Interval="SCHEDULE DAY HEATING 4180 SPACE TYPE", Blank Schedule Type Limits Name input -- will not be validated.
   ** Warning ** ProcessScheduleInput: Schedule:Day:Interval="SCHEDULE DAY COOLING 4181 SPACE TYPE", Blank Schedule Type Limits Name input -- will not be validated.
   ** Warning ** ProcessScheduleInput: Schedule:Day:Interval="SCHEDULE DAY HEATING 4181 SPACE TYPE", Blank Schedule Type Limits Name input -- will not be validated.
   ** Warning ** ProcessScheduleInput: Schedule:Year="COOLING SETPOINT SCHEDULE 4180 SPACE TYPE", Blank Schedule Type Limits Name input -- will not be validated.
   ** Warning ** ProcessScheduleInput: Schedule:Year="HEATING SETPOINT SCHEDULE 4180 SPACE TYPE", Blank Schedule Type Limits Name input -- will not be validated.
   ** Warning ** ProcessScheduleInput: Schedule:Year="COOLING SETPOINT SCHEDULE 4181 SPACE TYPE", Blank Schedule Type Limits Name input -- will not be validated.
   ** Warning ** ProcessScheduleInput: Schedule:Year="HEATING SETPOINT SCHEDULE 4181 SPACE TYPE", Blank Schedule Type Limits Name input -- will not be validated.
   ** Warning ** ProcessScheduleInput: Schedule:Compact="OA SCHEDULE", Schedule Type Limits Name="FRACTION" not found -- will not be validated
   ** Warning ** ProcessScheduleInput: Schedule:Compact="OA SCHEDULE" has missing day types in Through=12/31
   **   ~~~   ** Last "For" field=FOR: WINTER DESIGN DAY
   **   ~~~   ** Missing day types="CustomDay1","CustomDay2"
   **   ~~~   ** Missing day types will have 0.0 as Schedule Values
   ** Warning ** GetVertices: Floor is upside down! Tilt angle=[0.0], should be near 180, Surface="L003_C01:0:SURFACE 1", in Zone="L003_C01".
   **   ~~~   ** Automatic fix is attempted.
   ** Warning ** GetVertices: Floor is upside down! Tilt angle=[0.0], should be near 180, Surface="L003_P01:1:SURFACE 1", in Zone="L003_P01".
   **   ~~~   ** Automatic fix is attempted.
   ** Warning ** GetVertices: Roof/Ceiling is upside down! Tilt angle=[180.0], should be near 0, Surface="L003_P01:1:SURFACE 2", in Zone="L003_P01".
   **   ~~~   ** Automatic fix is attempted.
   ** Warning ** GetSurfaceData: The total number of floors, walls, roofs and internal mass surfaces in Zone L003_C01
   **   ~~~   ** is < 6. This may cause an inaccurate zone heat balance calculation.
   ** Warning ** GetSurfaceData: There are 1 coincident/collinear vertices; These have been deleted unless the deletion would bring the number of surface sides < 3.
   **   ~~~   ** For explicit details on each problem surface, use Output:Diagnostics,DisplayExtraWarnings;
   ** Warning ** DetermineShadowingCombinations: There are 3 surfaces which are receiving surfaces and are non-convex.
   **   ~~~   ** ...Shadowing values may be inaccurate. Check .shd report file for more surface shading details
   **   ~~~   ** ...Add Output:Diagnostics,DisplayExtraWarnings; to see individual warnings for each surface.
   ** Warning ** DeterminePolygonOverlap: Too many figures [>15000]  detected in an overlap calculation. Use Output:Diagnostics,DisplayExtraWarnings; for more details.
   ** Warning ** Surfaces in Zone="L003_C01" do not define an enclosure.
   **   ~~~   ** Number of surfaces <= 3, view factors are set to force reciprocity.
   **  Fatal  ** The temperature of [-296658.52] for ="L003_C01", for surface="L003_C01:0:SURFACE 2" is very far out of bounds during warmup. This may be an indication of a malformed zone.
   ...Summary of Errors that led to program termination:
   ..... Reference severe error count=0
   ..... Last severe error=
   ************* Warning:  Node connection errors not checked - most system input has not been read (see previous warning).
   ************* Fatal error -- final processing.  Program exited before simulations began.  See previous error messages.
   *************
   ************* ===== Recurring Surface Error Summary =====
   ************* The following surface error messages occurred.
   *************
   ************* Base Surface does not surround subsurface errors occuring...
   ************* Check that the GlobalGeometryRules object is expressing the proper starting corner and direction [CounterClockwise/Clockwise]
   *************
   ** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=Partial-Overlap
   **   ~~~   **   The base surround errors occurred 1 times.
   **   ~~~   ** Surface "L001_P01:2:SURFACE 6" overlaps SubSurface "L001_P01:2:SURFACE 6:SUBSURFACE 1"
   ** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=Partial-Overlap
   **   ~~~   **   The base surround errors occurred 1 times.
   **   ~~~   ** Surface "L001_P04:4:SURFACE 6" overlaps SubSurface "L001_P04:4:SURFACE 6:SUBSURFACE 1"
   ** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=Partial-Overlap
   **   ~~~   **   The base surround errors occurred 1 times.
   **   ~~~   ** Surface "L002_P01:0:SURFACE 6" overlaps SubSurface "L002_P01:0:SURFACE 6:SUBSURFACE 1"
   ** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=Partial-Overlap
   **   ~~~   **   The base surround errors occurred 1 times.
   **   ~~~   ** Surface "L002_P04:0:SURFACE 6" overlaps SubSurface "L002_P04:0:SURFACE 6:SUBSURFACE 1"
   ** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=Partial-Overlap
   **   ~~~   **   The base surround errors occurred 1 times.
   **   ~~~   ** Surface "L003_P02:1:SURFACE 6" overlaps SubSurface "L003_P02:1:SURFACE 6:SUBSURFACE 1"
   ** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=Partial-Overlap
   **   ~~~   **   The base surround errors occurred 1 times.
   **   ~~~   ** Surface "L003_P01:2:SURFACE 6" overlaps SubSurface "L003_P01:2:SURFACE 6:SUBSURFACE 1"
   ** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=Partial-Overlap
   **   ~~~   **   The base surround errors occurred 1 times.
   **   ~~~   ** Surface "L003_P04:2:SURFACE 5" overlaps SubSurface "L003_P04:2:SURFACE 5:SUBSURFACE 1"
   ** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=Partial-Overlap
   **   ~~~   **   The base surround errors occurred 1 times.
   **   ~~~   ** Surface "L003_P03:0:SURFACE 6" overlaps SubSurface "L003_P03:0:SURFACE 6:SUBSURFACE 1"
   *************
   **   ~~~   **   The base surround errors occurred 8 times (total).
   *************
   ************* EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors.
   ************* EnergyPlus Sizing Error Summary. During Sizing: 25 Warning; 0 Severe Errors.
   ************* EnergyPlus Terminated--Fatal Error Detected. 32 Warning; 0 Severe Errors; Elapsed Time=00hr 08min 29.76sec

I think that gives the user plenty to understand that they have a messed up zone.

[mjwitte]

That works. Add "routinename:" at the beginning, and "Zone" before the zone name, and units on the temperature. And the value doesn't need to be in brackets.

[EnergyArchmage]

Fine with me. But I think it should show a Severe first, then ShowContinueErrorTimeStamp, before Fatal

[Myoldmopar]

Addressed via #5709

[jmarrec]

I've just ran into this issue today with v8.8.0.

   ** Severe  ** DualSetPointWithDeadBand: Unanticipated combination of heating and cooling loads - report to EnergyPlus Development Team
   **   ~~~   ** occurs in Zone=1.OG N During Warmup, Environment=MANNHEIM ANN HTG 99.6% CONDNS DB, at Simulation time=01/21 23:45 - 24:00
   **   ~~~   ** LoadToHeatingSetPoint=NAN, LoadToCoolingSetPoint=NAN
   **   ~~~   ** Zone Heating Set-point=24.00
   **   ~~~   ** Zone Cooling Set-point=26.70
   **   ~~~   ** Zone TempDepZnLd=NAN
   **   ~~~   ** Zone TempIndZnLd=NAN
   **   ~~~   ** Zone ThermostatSetPoint=24.00
   **  Fatal  ** Program terminates due to above conditions.

I am getting also warnings about CalculateZoneVolume: The Zone=XXX is not fully enclosed. To be fully enclosed, each edge of a surface must also be an edge on one other surface. and a view other geometric errors. Not sure what I can do here.

[JasonGlazer]

The CalculateZoneVolume warning you are getting is new and is probably unrelated. All it is saying is that some gaps exist in the model for the surfaces used to define that zone. There are some fallback methods of calculating the zone volume which usually work fine. The warning message should tell you which one it is using and you can decide if that is sufficient.

[jmarrec]

There's still a NaN propagation that is getting my model to fatal at the DualSetpointWithDeadBand step though.

[JasonGlazer]

Could you email me your file and I will run it in the debugger and try to see what is going on.

[JasonGlazer]

I had to add some checks to the code and file still had fatal errors, see

https://github.com/NREL/EnergyPlus/tree/FixNaNrelatedTo5160

Not sure if they really should stay in the code or not.

[nealkruis]

@jmarrec are you using Kiva in this model? I recently came across a similar problem for a small subset of basement cases.

[jmarrec]

@nealkruis I am not using Kiva. (But I have a GroundHX:Surface object and Site:GroundTemp:Shallow)

[nealkruis]

@jmarrec Ok. Those objects shouldn't cause the same problem I was seeing. In my cases, the NAN loads came from surface temperatures that were not calculated properly.

@JasonGlazer have you made any progress on this? Do you have the IDF/EPW files to re-create the problem? I'd be interested to see if there is a more meaningful place where we can raise an error for these cases.

[JasonGlazer]

No new progress since the fixes I provided a few days ago. The first NAN is showing up in WeatherManager.

[mjwitte]

@JasonGlazer @jmarrec Since this issue is closed, please open a new issue for the problems seen in v8.8 and comment here or reference this issue there.