Provide API for accessing 'internal' nodes for 'virtual' HVAC components in model

[eringold]

Enhancement Request

For 'virtual' components that can be placed on an AirLoopHVAC, node setpoint control is not available because the nodes are not created until forward translation. An API that exposes or enables referencing these nodes would allow for defining more detailed HVAC controls.

@kbenne describes this as 'tricky' here, but I believe it would be highly valuable in enabling complex HVAC controls. I've talked with @jmarrec about wanting this feature and he probably has ideas on how it could happen.

Detailed Description

Here is a (probably incomplete) list of where the internal node limitation crops up:

• AirLoopHVAC:UnitarySystem control type SetPoint requires set points at each coil outlet node, which is not possible in OpenStudio because the nodes don't exist until translation.

• ZoneHVAC:TerminalUnit:VariableRefrigerantFlow can be placed on an AirLoopHVAC (or AirLoopHVAC:OutdoorAirSystem or AirLoopHVAC:DedicatedOutdoorAirSystem), for which the unit control is based on setpoints placed on the coil outlet nodes. Also not possible currently.

• The cooling coils in CoilSystem:Cooling:DX:HeatExchangerAssisted and CoilSystem:Cooling:Water:HeatExchangerAssisted cannot have a humidity setpoint (or any, for that matter) added to the coil outlet node, because it doesn't exist.

Possible Implementation

If, for example, an object ZoneHVAC:TerminalUnit:VariableRefrigerantFlow has a method coolingCoil, could there also be methods coolingCoilInletNode/coolingCoilOutletNode that would point to (optional) Node objects (or some related class without all the Connection/Port stuff) that SetpointManagers can reference, and would be translated accordingly?

[luisclv]

This would be very helpful to interact with UnitarySystems, and as you mentioned, more advanced controls without having to try and mess with E+ measures.

[jmarrec]

I'm having trouble seeing a way to do this properly, as in what the API would look like, without increasing complexity and decreasing ease of use. I'll try to think about it some more.

[tijcolem]

@joseph-robertson Would you be able to look into this and maybe scope out the level of effort to support this?

[eringold]

In a conversation we had on slack, @jmarrec suggested a potential workaround would be something like

Unitary.addSetpointManagerForCoolingCoil(SetpointManager& spm)
Unitary.addSetpointManagerForHeatingCoil(SetpointManager& spm)
Unitary.addSetpointManagerForSupplementalHeatingCoil(SetpointManager& spm)
Unitary.addSetpointManagerForFan(SetpointManager& spm)

which would get added to the correct nodes when they're created at FT.

[kbenne]

@eringold yeah I think that is an option.

Brainstorming here... We could also considering returning actual nodes, e.g.

unitary.coolingCoilOutletNode()

The key would be that the nodes is not "wired" into the network using OS:Connection. A relationship field would need to be setup to link the unitary and the node.

ping @jmarrec

[jmarrec]

What problems would we expect if we actually created real OS:Node and OS:Connection objects?

What do you have in mind for Relationship field here?

[eringold]

Here is another example of a use case that would benefit from this feature: creating an AirFlowNetwork using Unitary Systems: https://unmethours.com/question/80949/is-there-a-way-to-use-a-unitary-system-with-airflownetwork-in-openstudio/