Question-and-Answer Resource for the Building Energy Modeling Community
Get started with the Help page
Ask Your Question

Revision history [back]

I solved this problem by placing the heat pump coils as a single component inside the AirLoopHVAC:UnitarySystem. Essentially using the AirLoopHVAC:UnitarySystem like you would the DX coil wrapper model. I used one unitary for each coil. I encountered one issue getting the unitary to size the inner coils appropriately and that has been resolved here.

I solved this problem by placing the heat pump coils as a single component inside the AirLoopHVAC:UnitarySystem. Essentially using the AirLoopHVAC:UnitarySystem AirLoopHVAC:UnitarySystem like you would the DX coil wrapper model. I used one unitary for each coil. I encountered one issue getting the unitary to size the inner coils appropriately and that has been resolved here.

I solved this problem by placing the heat pump coils as a single component inside the AirLoopHVAC:UnitarySystem. Essentially using the AirLoopHVAC:UnitarySystem like you would the DX coil wrapper model. I used one unitary for each coil. I encountered one issue getting the unitary to size the inner coils appropriately and that has been resolved here.

I solved this problem by placing the heat pump coils as a single component inside the AirLoopHVAC:UnitarySystem. Essentially using the AirLoopHVAC:UnitarySystem like you would the DX coil wrapper model. I encountered one issue getting the unitary to size the inner coils appropriately and that has been resolved here.

It is possible to place the coils inside the unitary using OpenStudio, but you will need to use the API to accomplish it. I can provide an example in Ruby if you want to go down that path.

I solved this problem by placing the heat pump coils as a single component inside the AirLoopHVAC:UnitarySystem. Essentially using the AirLoopHVAC:UnitarySystem like you would the DX coil wrapper model. I encountered one issue getting the unitary to size the inner coils appropriately and that has been resolved here.

It is possible to place the coils inside the unitary using OpenStudio, but you will need to use the API to accomplish it. I can provide an example in Ruby if you want to go down that path.

(update) I should have pointed out that AirLoopHVAC:UnitarySystem is unique from most (all?) other unitary systems because it allows you to use setpoint managers for control instead of using internal (single zone) control logic. This is the key feature that allows you to use it in a multi zone situation like you have in mind.

I solved this problem by placing the heat pump coils as a single component inside the AirLoopHVAC:UnitarySystem. Essentially using the AirLoopHVAC:UnitarySystem like you would the DX coil wrapper model. I encountered one issue getting the unitary to size the inner coils appropriately and that has been resolved here.

It is possible to place the coils inside the unitary using OpenStudio, but you will need to use the API to accomplish it. I can provide an example in Ruby if you want to go down that path.

(update) I should have pointed out that AirLoopHVAC:UnitarySystem is unique from most (all?) other unitary systems because it allows you to use setpoint managers for control instead of using internal (single zone) control logic. This is the key feature that allows you to use it in a multi zone situation like you have in mind.

(Update 2) here is an example in Ruby.

  m = OpenStudio::Model::Model.new
  air_loop = OpenStudio::Model::AirLoopHVAC.new m
  node = air_loop.supplyOutletNode
  coil  = OpenStudio::Model::CoilHeatingWaterToAirHeatPumpEquationFit.new m
  unitary = OpenStudio::Model::AirLoopHVACUnitarySystem.new m
  unitary.setHeatingCoil coil
  unitary.addToNode node

There is just one little problem. You need access to the "Control Type" field in the AirLoopHVACUnitarySystem object so that you can set the value to "SetPoint". That field is private in OpenStudio Model. In C++ you can get to the private method through a sneaky back door. No such trick in Ruby. So I'm going to show you an even more sneaky trick and please use it this one time and pretend you never saw it after that.

unitary.setString 2, 'SetPoint'

That setString method lets you access the private data fields directly. This is almost always a bad idea, but in this case it is ok. The two indicates that you are setting the third field (they are indexed from 0) to the value "SetPoint". The outlet node of the unitary system will now require a setpoint manager for things to run. Disclaimer we could close this loop hole at any moment. More likely we will just give proper public access to the control field, but that requires some thought because typically you will need set point managers on all of the internal nodes between components in the unitary.