Fixes #1372 by updating VentilationRateProcedure enumerations

[asparke2]

In OpenStudio 3.3.0/EnergyPlus 9.6, the enumerations in the Sizing:System and Controller:MechanicalVentilation objects changed from VentilationRateProcedure to Standard62.1VentilationRateProcedure. When this change is not handled, the setter methods will not change the value, and the default ZoneSum method will be used. This method significantly underestimates the minimum outdoor air requirements for multizone systems, which in turn impacts energy consumption.

The fix is to modify the code to be version-dependent.

[lymereJ]

I don't believe that this is a code requirement, we're currently doing that in model_system_outdoor_air_sizing_vrp_method() in Prototype.SizingSystem.rb. What's the reason for moving it here and below?

[asparke2]

It's not a code requirement, however, the previous approach, which mainly affects ComStock or others using the older prototypes, assumed that historic design practice for the pre-1980 and 1980-2004 templates was simply to not adjust minimum damper positions, which results in higher min OA requirements for those buildings. When the change was made to put the 0.6 minimum limit into model_system_outdoor_air_sizing_vrp_method(), I didn't notice because ComStock was still using OS 2.9.1, so that code never got called. I think that moving the code into standard-specific methods should result in the previous behavior:

• For pre-1980 and 1980-2004, VAV systems get Standard62.1VentilationRateProcedure with no minimum zone ventilation efficiency. This likely means higher minimum OA for those systems.
• For 2004+
  • If using OS =< 3.0.0, minimum damper positions are manually adjusted to achieve a minimum zone ventilation efficiency of 0.6
  • If using OS > 3.0.0, minimum damper positions are set to achieve a minimum zone ventilation efficiency of 0.6 using the newly-available EnergyPlus built-in algorithm.
  • I have tested these two methods on a small number of buildings and confirmed that the E+ algorithm and the manual method create nearly identical results.

[lymereJ]

Ok, I see, thanks for the additional information. So when we worked on that section of the code (in #1112 and #776) we missed that the DOE reference building should not be using a minimum efficiency. Knowing that I think that what you're proposing makes sense but I do see that the regression and performance tests failed. Do you mind if I have a look at why we get diffs before this gets merged? Is it urgent, I might not have time to look at it before next week.

[lymereJ]

I think we might want to consider using 62.1VentilationRateProcedureWithLimit here. That's the intent in ASHRAE 90.1.

[asparke2]

Yeah I agree, didn't see this additional enumeration. I will update branch. Also, this is not urgent to merge, take your time and look through the regression tests.

[mdahlhausen]

@asparke2 @lymereJ the AppG pull request is merged - can you merge in from master and resolve conflicts?

[lymereJ]

@asparke2 - Sorry for the belated response! The proposed changes have more impacts on the prototypes than I would have thought, I think some changes are necessary.

I understand the intent of the changes but I think I should provide some additional details on #776 and #1112 (current approach/intent). First, the ventilation rate procedure come into play at two different levels: sizing and operation ("ventilation optimization").

• Sizing:
  The way we currently handle sizing is to let EnergyPlus size the system outdoor air intake using the built-in VentilationRateProcedure. Once the sizing run is done, we set the Sizing:System object to use the outdoor air intake calculated by EnergyPlus and change the system outdoor air method to ZoneSum. The sizing run needs to take into account the minimum zone ventilation efficiency of 0.6. This of course does not take into account the terminal minimum damper position, which needs to be manually calculated.
• Operation:
  When ventilation optimization is required, we currently use VentilationRateProcedure in the controller mechanical ventilation object and use an EMS programs to mimic/approximate what VentilationRateProcedureWithLimit does.

Issues with the current changes:
The regression tests show that most prototypes with multizone systems are impacted. I looked at two specific ones, the medium office for 90.1-2016 and the hospital in 90.1-2004. With the current proposed changes, systems end-up not being modeled with ventilation optimization, and their MDP not re-calculated to meet the 0.6 minimum zone ventilation efficiency. Their sizing system object end-up having their design minimum outdoor air autosized and not hard sized based on the result of the sizing run. All these input changes have impacts on the simulation results which is shown by the performance tests failures.

Proposed approach:
I proposed to revert all current changes and make the following:

• Change VentilationRateProcedure to Standard62.1VentilationRateProcedureWithLimit in air_loop_hvac_enable_multizone_vav_optimization() (instead of doing it in model_system_outdoor_air_sizing_vrp_method() which is for sizing) for OS version > 3.3, and remove the EMS in ashrae_90_1_2019.AirLoopHVAC.rb if OS version > 3.3 since they aim to approximate the "cap" that Standard62.1VentilationRateProcedureWithLimit models.
• Create a new method called something like air_loop_hvac_minimum_zone_ventilation_efficiency() that would return by default 0 and 0.6 for all ASHRAE versions.

I think this would address the issues I mentioned above, the issue you mentioned in your comment about the pre-1980 and 1980-2004 prototypes, and the original issue (introduction of Standard62.1). What do you think? Happy to jump on a call if you think this would be easier.

[asparke2]

@lymereJ I'm going to test your suggestion, I believe that it will work and if so will implement it on a new branch and close this PR. In testing, I have confirmed an approach that uses more recent EnergyPlus capabilities to autosize minimum damper positions, which would allow us to remove the damper position adjustment code in openstudio-standards. For most models, that approach results in minimum damper positions and OA rates within 1% of the current code. I've documented that approach in a feature request issue here so we don't lose that knowledge: #1391

[asparke2]

Closing this PR, choosing the simpler approach in PR #1394 instead.