OS SDK 3.5.0 API DOE Prototype Issues

[mdahlhausen]

ISSUE 1: zone to space translation Summary: Recent versions of EnergyPlus added Space objects. Some objects attached to a zone get attached to a space upon OpenStudio translation to EnergyPlus. When this happens, it can orphan objects previously attached to specific zone object names, such as EMS controls using zone daylight sensors.

That will generate a confusing error like this: Invalid Actuated Component Unique Name =CAFETERIA_ZN_1_FLR_1 ZN PRIMARYSCHOOL CAFETERIA LIGHTS Entered in EnergyManagementSystem:Actuator=CAFETERIA_ZN_1_FLR_1ZN_LIGHT1_ACTUATOR Component Unique key name not found Use Output:EnergyManagementSystem object to create .edd file for valid component names.\ One fix is to not translate zones to spaces and instead keep them as zones. This is enabled by setting no_space_translation: false in the run_options of an .osw. See example. The fix isn't durable, as it requires all downstream end users add that run option, and still leaves and issue where zone EMS objects may get duplicated to multiple Space objects if the zone has multiple spaces.

The preferred solution is to have a switch statement depending on OS version, and attach lighting sensors or related objects to Space objects directly for recent OS versions. Code that needs to change are the occupancy controls in ASHRAE 90.1-2016 and ASHRAE 90.1-2019.

There may be other locations in the code where this is an issue, particularly around daylight sensor placement.

ISSUE 2: occupant diversity defaults now explicit in OS:Sizing:System Summary: Recent versions of OpenStudio now include an Occupant Diversity field in the OS:Sizing:System object.

  N27; \field Occupant Diversity
       \type real
       \maximum 1.0
       \minimum 0.0
       \autosizable
       \note The Occupant Diversity is used to determine a multi-zone system's outdoor air intake when the System Outdoor Air Method is
       \note Standard62.1VentilationRateProcedure or the Standard62.1SimplifiedProcedure. If set to be autosized, it will be calculated
       \note using the information in the People objects assigned to each zone attached to this system/airloop.
       \required-field

That causing some regression errors and possibly some differences in equipment sizing as well:

For OS:Sizing:System called 'OS:Sizing:System PVAV Outpatient F1'  'Cooling Design Air Flow Rate': true model = '0.0', compare model = ' - '
For OS:Sizing:System called 'OS:Sizing:System PVAV Outpatient F1'  'Heating Design Air Flow Rate': true model = '0.0', compare model = ' - '
For OS:Sizing:System called 'OS:Sizing:System PVAV Outpatient F1'  'Occupant Diversity': true model = ' - ', compare model = 'autosize'

Determine if the new default behavior is appropriate and operating as expected.

ISSUE 3: models not generating in Appendix G tests Summary: Some Appendix G tests are failing out with the message: NoMethodError: undefined methodgetElectricLoadCenterTransformers' for false:FalseClass...`

This in in the remove_transformer, which is the first method called in a series of tests to check the HVAC. If the model doesn't generate for some reason, it fails first in the remove_transformer method. Add a model check and error out gracefully if it doesn't load prior to calling the rest of the check_hvac methods.

[mdahlhausen]

Tim is working on getting you access to the OS 3.5 develop tests results on S3.

[lymereJ]

• @leijerry888 to work on issue 1
• @lymereJ to work on issue 2
• @weilixu (or @dmaddoxwhite) to work on issue 3

[lymereJ]

@mdahlhausen - @leijerry888 and I looked into issue 1.

Unless we've missed something, "load"-based actuators (electric equipment, lights) seem to not be correctly translated by OpenStudio 3.5. The translation is done here. A load-based actuator's actuated component unique name is typically a concatenation of the zone or space name and the name of the load object (Lights or ElectricEquipment objects). OS handles the translation well when only zones are considered but not for spaces: as you mentioned in the issue, the actuator are based on the thermal zone name. Looking at the code doing the translation and running some tests we noticed that we cannot get OS to produce a concatenation of the space name and lights object that EnergyPlus is expecting. It seems like the forward translator code was built to handle ZoneLists but not SpaceLists, the latter being used after translation by OS 3.5. We're happy to file a OS GitHub issue ticket if need be.

[lymereJ]

ISSUE 2: occupant diversity defaults now explicit in OS:Sizing:System Summary: Recent versions of OpenStudio now include an Occupant Diversity field in the OS:Sizing:System object.

  N27; \field Occupant Diversity
       \type real
       \maximum 1.0
       \minimum 0.0
       \autosizable
       \note The Occupant Diversity is used to determine a multi-zone system's outdoor air intake when the System Outdoor Air Method is
       \note Standard62.1VentilationRateProcedure or the Standard62.1SimplifiedProcedure. If set to be autosized, it will be calculated
       \note using the information in the People objects assigned to each zone attached to this system/airloop.
       \required-field

That causing some regression errors and possibly some differences in equipment sizing as well:

For OS:Sizing:System called 'OS:Sizing:System PVAV Outpatient F1'  'Cooling Design Air Flow Rate': true model = '0.0', compare model = ' - '
For OS:Sizing:System called 'OS:Sizing:System PVAV Outpatient F1'  'Heating Design Air Flow Rate': true model = '0.0', compare model = ' - '
For OS:Sizing:System called 'OS:Sizing:System PVAV Outpatient F1'  'Occupant Diversity': true model = ' - ', compare model = 'autosize'

Determine if the new default behavior is appropriate and operating as expected.

I looked into this issue. I appears that the change in boiler size that we're seeing in the Outpatient and Hospital are triggered when changing from EnergyPlus 9.5 to 9.6. That corresponds to when the Occupant Diversity input was added, but I don't think this is triggering the changes in plant equipment sizes. First, because the reported autocalculated diversity is the same in models generated using OS 3.2.1 and OS 3.5.0 (0.9 in the SR), and also we see the plant equipment size changes for both the 2004 and 2019 model version of 90.1. The occupant diversity is only used when ventilation optimization following the VRP is used in the models or when the 62.1 simplified procedure is used to size the minimum primary air flow of the terminals, however, the 2004 version of the model isn't set up with ventilation optimization but does show the difference, and neither the 2004 and 2019 use the EnergyPlus native 62.1 simplified procedure approach to size the minimum primary airflow rate. So, I think this rules out the occupant diversity.

I looked at the release notes for EnergyPlus 9.6, I can imagine how a few of these might be contributing to that change but I can't see the diffs that each PR produced so it's hard to tell.

I believe that the diff in size is due to the fact that some of HW reheat coils were sized with 0 kBtu/h nominal capacity in EnergyPlus 9.5, see figure below. In EnergyPlus 9.6, this increases the load on the loop. The fact that the size of a few terminal reheat coil were 0 in 9.5 makes me more confident in the results produced by 9.6 and 22.1, I think it's unlikely that the terminal reheat coil would have no capacity unless it's serving a datacenter that doesn't need ventilation and has a very large amount of internal gains,

Long story short, I think these diffs are okay.

---

On a side node, it looks like the name of the equipment and efficiency lookup is based on the sizing run results. If we look at the autosized capacity of the boiler in the final run, they are much closer and the capacity used in the equipment name does not correspond with the autosized capacity. This is not a version issue as it happens for both OS 3.5 and 3.2.1 sets of results, but perhaps more of an issue with the way the naming and efficiency look-up is done in openstudio-standards.

[lymereJ]

@mdahlhausen - @leijerry888 and I looked into issue 1.

Unless we've missed something, "load"-based actuators (electric equipment, lights) seem to not be correctly translated by OpenStudio 3.5. The translation is done here. A load-based actuator's actuated component unique name is typically a concatenation of the zone or space name and the name of the load object (Lights or ElectricEquipment objects). OS handles the translation well when only zones are considered but not for spaces: as you mentioned in the issue, the actuator are based on the thermal zone name. Looking at the code doing the translation and running some tests we noticed that we cannot get OS to produce a concatenation of the space name and lights object that EnergyPlus is expecting. It seems like the forward translator code was built to handle ZoneLists but not SpaceLists, the latter being used after translation by OS 3.5. We're happy to file a OS GitHub issue ticket if need be.

Once this is addressed we'll regenerate a set of regression models and performance results.

[mdahlhausen]

@lymereJ I spoke with Tim. I think the first issue is intended - OS will not change names in the EMS objects during translation. So the fix I think is to add a model version check, and for OS versions 3.4.0+ use the space names instead of the zone names.

[mdahlhausen]

All the other issues are a simple matter of just regenerating the regression tests using OS 3.5.1

[mdahlhausen]

Closing this as I think all the issues are addressed or otherwise moved to new single issues.