E+ 25.2.0: Wrap HeatPump:AirToWater

[jmarrec]

Enhancement Request

New object dropped yesterday: HeatPump:AirToWater

Detailed Description

• A new air to water heat pump object EnergyPlus#11001

Possible Implementation

This object has [0, n] (well [0, 5]) speeds for cooling and same for heating. The IDD of the object has no extensible fields, it has a fixed number of speeds (5) for each mode.

Probably need to wrap the wrapper HeatPump:AirToWater with two model object lists, and a HeatPumpAirToWaterSpeed objec (or maybe one for the cooling, one for heating, not sure if they match)

[jmarrec]

I am considering breaking this object into several subobjects for the cooling/heating side, or just add the Speed Data ones.

Here is a spreadsheet that shows the original E+ object (105 fields...), and two alternatives:

• OpenStudio_large: I'm only adding two small objects for HeatPump:AirToWater:HeatingSpeedData and HeatPump:AirToWater:CoolingSpeedData. The main object HeatPump:AirToWater is still quite large with 55 fields.
• OpenStudio_subobjects: In addition to the speed data objects, I'm breaking the object into a wrapper (18 fields) and two subobjects HeatPump:AirToWater:Heating and HeatPump:AirToWater:Cooling (which are exactly the same... 16 fields)

https://docs.google.com/spreadsheets/d/1uCcEdmM4p3M9L7HeihAwL9F9NawK1TR8j3ADBqS6jTs/edit?usp=sharing

@joseph-robertson @shorowit @kbenne I would appreciate a look and opinions on this please.

[joseph-robertson]

@jmarrec Great summary, and layout of possible paths forward.

I definitely like the idea of an alternative, especially since it seems there is so much overlap/duplication between heating and cooling.

For the 2nd alternative, could HeatPump:AirToWater:HeatingSpeedData and HeatPump:AirToWater:CoolingSpeedData be condensed/combined into a single object using generic terminology (e.g., Rated Capacity, and Rated COP). Likewise for HeatPump:AirToWater:XXX (e.g., Availability Schedule Name, and drop all "in XXX Mode"). Leading to significantly less wrapping.

Is there a 3rd alternative here, which is to move fields from the HeatPump:AirToWater wrapper to either HeatPump:AirToWater:Heating or HeatPump:AirToWater:Cooling? (I'm sort of looking at HeatPump:AirToWater:FuelFired:XXX and wondering how those objects are able to get away without a parent wrapper object.)

[jmarrec]

The e+ object ends up creating two separate heat pumps for heating and cooling (if both are specified) in c++.

Currently I've decided to wrap with subobjects. I'm basically doing the heating side to start: SpeedData first, then HeatPumpAirToWaterHeating.
I write unit tests, and once happy I just duplicate for cooling. The fields are named pretty much the same so it's efficient to duplicate.

I thought about using the same object for both, but I could foresee a case where they'd end up having to be different and it would be a hassle to do version translation and updating the c++ class. Also, I think separating into classes/idd objects prevents mistake where you'd create a heating speed and end up adding it to a cooling object.

I do have pending questions I haven't answered yet such as whether the SpeedData classes should be resourceobjects or be cloned along with the heating/cooling object (this is generally the case for the coils with stage/speed data right now).

Also, right now I'm using a ModelObjectList to link a HeatPumpAirToWaterHeating to multiple HeatPumpAirToWaterHeatingSpeedData but I could also use extensible groups for that now that the Heating/Cooling parts are subobjects (both are StraightComponent).

I'm churning along, punting on some of these questions, but if anyone has an opinion already, I'm all ears. Otherwise I'll make sure to flag these in the upcoming PR for review