Addresses #3728, add new DOAS to AHU objects

[joseph-robertson]

Pull request overview

• Implements Add new DOAS to AHU objects #3728
• Design doc: https://docs.google.com/document/d/1HnocSAX1seOSYmALbX6pUCqiuSjyQa42oxx9wmtF5Ls/edit#
• Found this bug in the process: AirLoopHVAC:DedicatedOutoorAirSystem breaks unless AirLoopHVACs are all upper case. EnergyPlus#8581
• Questions:
  • Where to FT from? Decided to do FT directly on AirLoopHVACDedicatedOutdoorAirSystem objects from the top level in ForwardTranslator.cpp.
  • What are the Inlet/Outlet nodes for AirLoopHVACMixer/AirLoopHVACSplitter in FT? Using outboardReliefNode/outboardOANode of AirLoopHVACOutdoorAirSystem on the air loops.
  • Why is RT failing? RT for AirLoopHVACOutdoorAirSystem is commented out, so I supposed RT for this wouldn't work anyway. I commented out the call for RT.
  • What is the Inlet node for AirLoopHVACSplitter? It is outdoorAirModelObject of AirLoopHVACOutdoorAirSystem.
  • What are the output variable names for cpp? None.

Please read OpenStudio Pull Requests to better understand the OpenStudio Pull Request protocol.

Pull Request Author

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

• Model API Changes / Additions
• Any new or modified fields have been implemented in the EnergyPlus ForwardTranslator (and ReverseTranslator as appropriate)
• Model API methods are tested (in src/model/test)
• EnergyPlus ForwardTranslator Tests (in src/energyplus/Test)
• If a new object or method, added a test in NREL/OpenStudio-resources: Add Link
• If needed, added VersionTranslation rules for the objects (src/osversion/VersionTranslator.cpp)
• Checked behavior in OpenStudioApplication, adjusted policies as needed (src/openstudio_lib/library/OpenStudioPolicy.xml)
• Verified that C# bindings built fine on Windows, partial classes used as needed, etc.
• All new and existing tests passes
• If methods have been deprecated, update rest of code to use the new methods

Labels:

• If change to an IDD file, add the label IDDChange
• If breaking existing API, add the label APIChange
• If deemed ready, add label Pull Request - Ready for CI so that CI builds your PR

Review Checklist

This will not be exhaustively relevant to every PR.

• Perform a Code Review on GitHub
• Code Style, strip trailing whitespace, etc.
• All related changes have been implemented: model changes, model tests, FT changes, FT tests, VersionTranslation, OS App
• Labeling is ok
• If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
• If feature, test running new feature, try creative ways to break it
• CI status: all green or justified

[jmarrec]

For ref the E+ NFP is here: https://github.com/NREL/EnergyPlus/blob/develop/design/FY2019/NFP-DOAS_MultiAHUs.md

[jmarrec]

I'm not familiar with this new feature of E+, I just looked into it briefly. This isn't very organized below, mostly brainstorming...

The questions I have aren't about the IDD but are actually about how to implement that as classes and the GUI.

The AirLoopHVAC:DedicatedOutdoorAirSystem is weird in the sense that it appears to be somewhat similar to a unitary system except that it isn't placed on an AirLoopHVAC.

I would have preferred if if it would have been an actual AirLoopHVAC with rule enforcement to ensure that you can only connect AirLoopHVAC:OutdoorAirSystem to it (or Zone Stuff, but not both), but it was probably harder to implement in E+....

Perhaps we could do it this way in OpenStudio? We could merge AirLoopHVAC:ZoneSplitter and AirLoopHVAC:Splitter and enforce connection rules in the model API (check what's existing, and prohibit mixing zones and AirLoopHVACOutdoorAirSystems), and translate to either a ZoneSplitter or Splitter in the Forward Translator? If we implement both, then we probably also need to subclass AirLoopHVAC, or provide a way to change the splitter type in the model API (and GUI) which is going to be painful.

Otherwise if we implement that like E+ does, then it'll be somewhat of a "black box" in the sense that you cannot modify them in the GUI, and they wouldn't be rendered currently.
If we want to render that, how would we do it? Perhaps add a new Tab accessible from that weird dropdown similar to Refrigeration or VRF that would allow you to place fan, heating/cooling coils etc. Could also add a dropdown on the "Control" subtab of AirLoopHVAC for "DOAS Connection" that would also connecting to that AirLoopHVAC:DedicatedOutdoorAirSystem.
Should the DOAS should be the one referencing the AirLoopHVACs it serves via extensible groups, or the other way around? Note that the OS:AirLoopHVAC:OutdoorAirSystem is the one bearing the fields that in E+ are in OutdoorAir:Mixer including the Outdoor Air Stream Node Name which should be referenced by AirLoopHVAC:Splitter

[kbenne]

@joseph-robertson is this still a work in progress?

[joseph-robertson]

Yes, it is.

@kbenne

[anchapin]

I'm interested in a status update on this pull request. Has there been any progress made lately? Any idea on when it might be merged? Thanks

[joseph-robertson]

No, there has not been any progress made lately. My guess is that this will get worked on, and merged. sometime between the 3.1.0 release and the following major release.

[jmarrec]

I pulled #4233 into this one so CI would build and test correctly

[ci-commercialbuildings]

CI Results for 049844b:

• Ubuntu 18.04:

  • OpenStudio-3.1.1-alpha+a7f7357b6d-Ubuntu-18.04.deb
  • OpenStudio-3.1.1-alpha+a7f7357b6d-Ubuntu-18.04.tar.gz

• Ubuntu 20.04:

  • OpenStudio-3.1.1-alpha+049844bf4f-Ubuntu-20.04.deb
  • OpenStudio-3.1.1-alpha+049844bf4f-Ubuntu-20.04.tar.gz

• Darwin:

  • OpenStudio-3.1.1-alpha+049844bf4f-Darwin.dmg
  • OpenStudio-3.1.1-alpha+049844bf4f-Darwin.tar.gz

• Windows:

[jzsustain]

Are there any plans to add AirLoopHVAC:DedicatedOutdoorAirSystem into the OpenStudio GUI?

[jmarrec]

@jzsustain moved your request at openstudiocoalition/OpenStudioApplication#709