ZoneControl:Thermostat is missing the Temperature Difference Between Cutout And Setpoint field

[macumber]

In the OpenStudio ProposedEnergy+.idd the ZoneControl:Thermostat is missing the Temperature Difference Between Cutout And Setpoint field at the end of the object. This is because OpenStudio treated this object as extensible when really it is not (it does look like it should be extensible).

[macumber]

Reported by @ebonnema

[bonnema]

Reverting back to 2.5.0 makes the issue go away.

[macumber]

This is a tough one, we need to change the ProposedE+.idd back to match E+ (e.g. no extensible groups). However, ReverseTranslateZone.cpp is looping over the extensible fields. This needs to be addressed so @bonnema can move forward to the current version.

[macumber]

I don't fully understand all the stuff going on with thermostats, it seems that OS wraps only a few types and there are some conversions at translation time. Assigning to @jmarrec, Julien if there is another ticket you'd like to trade with me let's do that.

[jmarrec]

@macumber I am going to think about the best way to do this

@tijcolem you might be interested in reading this if you can spare the time:

• EnergyPlus has several thermostat types [1]: ThermostatSetpoint:DualSetpoint, ThermostatSetpoint:SingleCooling and ThermostatSetpoint:SingleHeating.
• These are used in a ZoneControl:Thermostat object, where you can reference several different ones and you can use a schedule to tell which of them to use on a given simulation timestep (I/O Ref guide)
• Someone (=kyle most likely) had a good idea and decided that the DualSetpoint was more than enough, and that you could for example just put a Cooling Schedule with a very high value (say 60C) to effectively turn off Cooling. You don't need ZoneControl:Thermostat, because you have some cool Schedule:Ruleset objects that easily allow you to do what you want.
• The Caveat here was that at the time if you did not input BOTH a heating AND a cooling Schedule on the thermostat, it would not be translated at all => Zone ends up unconditioned, and unless you check the resulting IDF you don't even know about it.
• Later on, and due to multiple post on UnmetHours where people were confused why their zones were not conditioned, we modified the FT (Fix 2379 #2813):
  • If our model thermostat had a both a cooling and heating schedule => DualSetpoint
  • If only a heating schedule => SingleHeating
  • If only a cooling schedule => SingleCooling

[1] (I am omitting ThermostatSetpoint:SingleHeatingOrCooling because it's not very important)

---

ZoneControl:Thermostat is pretty weird, because it has not-so extensible groups and an extra regular field...

here's the current E+ IDD, notes excluded

ZoneControl:Thermostat,
  A1 , \field Name
  A2 , \field Zone or ZoneList Name
  A3 , \field Control Type Schedule Name
  A4 , \field Control 1 Object Type
  A5 , \field Control 1 Name
  A6 , \field Control 2 Object Type
  A7 , \field Control 2 Name
  A8 , \field Control 3 Object Type
  A9 , \field Control 3 Name
  A10, \field Control 4 Object Type
  A11, \field Control 4 Name
  N1 ; \field Temperature Difference Between Cutout And Setpoint

The Control type Schedule Name takes only 5 discrete values , I/O Ref guide)

Field: Control Type Schedule Name
Schedule which defines what type of control is active during the simulation. Valid Control Types are:
0 - Uncontrolled (No specification or default)
1 - Single Heating Setpoint
2 - Single Cooling SetPoint
3 - Single Heating Cooling Setpoint
4 - Dual Setpoint with Deadband (Heating and Cooling)
Each non-zero control type which is used in this schedule must appear in the following fields which list the specific thermostat control objects to be used for this zone.

So it's not *really extensible (it's limited to 4 entries...) but I still think the N1 ; \field Temperature Difference Between Cutout And Setpoint should ideally be moved before these seemingly extensible groups.

[jmarrec]

@macumber There are two options here regarding the Temperature Difference Between Cutout And Setpoint:

1. We are fine not adding this field yet, and wait for the next E+ release that would ideally move this field up before the "extensible" groups (cf ZoneControl:Thermostat should move the extensible fields at the end EnergyPlus#7484)
2. We want this field in 2.9.0, in which case the least hassle is that we add it to the model API, change the ProposedEnergy+.idd to no longer have extensible fields, and write it out if not zero (I wouldn't make it an optional, just initialize to zero in the model Ctor). (Groups Control N Object Type & Control N Object Name where N in [2, 4] would always be blank).

Obviously, I'd advocate for 1 if we can.

[jmarrec]

@bonnema Do you need this field in the Workspace (<=> EnergyPlus Measures) or do you also need it to be added to the OpenStudio Model API? (I would add it to the OS:ThermostatSetpoint:DualSetpoint object and handle logic in the FT)

[jmarrec]

Fixed via #3663