Heating system -> heat pump backup

[joseph-robertson]

Pull Request Description

Closes #942.

Uses ResStockArguments to add a new boolean argument heat_pump_backup_use_existing_system. When set to true in the lookup (i.e., as an upgrade option) the heating system becomes the heat pump backup:

• "integrated" if heating system type is fuel-fired furnace* and heat pump type is ducted (e.g., ashp, ducted mshp)
• "separate" if heating system type is wall/floor furnace, boiler, electric resistance, stove, portable heater, fireplace, or fixed heater (or furnace and heat pump type is ductless mshp)

*If existing heating system is an electric furnace, it likely wouldn't be used as integrated backup.

Primary System	Backup System	Backup Type	Example
ducted	ducted	integrated	ASHP w/Furnace (non-electric)
ducted	ductless	separate	ASHP w/Boiler
ductless	ducted	separate	Ductless MSHP w/Furnace
ductless	ductless	separate	Ductless MSHP w/Boiler

Fuel type, efficiency, and capacity are all retained.

If the existing heating system is a heat pump or shared system, it does not get set as the heat pump backup.

This PR also updates national_upgrades.yml and testing_upgrades.yml to demonstrate the new Heat Pump Backup|Use Existing System option for the "ASHP" and "MSHP" upgrades. Also, adds a new "Ductless MSHP" upgrade to these yml files.

Checklist

Not all may apply:

• Tests (and test files) have been updated
• Documentation has been updated
• Changelog has been updated
• openstudio tasks.rb update_measures has been run
• No unexpected regression test changes on CI (checked comparison artifacts)

[shorowit]

This feels pretty brittle/risky. It'll be easy for this code to not get updated if new heating properties or system types are added.

I haven't thought about it as hard as you have, but I don't really understand the reason for choosing this approach. Why not keep things how they were but simply preserve the heating capacity when "separate" is chosen and there is an existing system?

[joseph-robertson]

Furnace, for example, is not a valid "second heating system".

[shorowit]

Thinking about it more, I realize part of the motivation is to allow preserving not just capacity but also efficiency/fueltype. So you'd be able to specify a single heat pump upgrade that applies to many different existing fossil fuel systems, rather than a separate heat pump upgrade for each existing system type. I just worry a bit about all the code that is being introduced.

[shorowit]

Furnace, for example, is not a valid "second heating system".

If the furnace is backup to a central ASHP, then it is allowed (as an integrated backup system).

If the furnace is backup to a ductless mini-split, then I agree it's not currently allowed. I would suggest we update BuildResHPXML to allow it. So long as we only end up with one duct system for the home, I think it should be straightforward.

[joseph-robertson]

By "all the code" you are referring to the "integrated" (i.e., furnace, fixed heater) vs "separate" switch, and having all these BuildResHPXML arguments called out explicitly? What would you suggest as an alternative? (Keep in mind that we do already call out quite a few BuildResHPXML and BuildResSchFile arguments in these meta measures.)

[joseph-robertson]

Furnace, for example, is not a valid "second heating system".

If the furnace is backup to a central ASHP, then it is allowed (as an integrated backup system).

If the furnace is backup to a ductless mini-split, then I agree it's not currently allowed. I would suggest we update BuildResHPXML to allow it. So long as we only end up with one duct system for the home, I think it should be straightforward.

By "second heating system", I meant it's not allowed here: https://github.com/NREL/OpenStudio-HPXML/blob/master/BuildResidentialHPXML/measure.rb#L1340-L1354.

[shorowit]

By "second heating system", I meant it's not allowed here: https://github.com/NREL/OpenStudio-HPXML/blob/master/BuildResidentialHPXML/measure.rb#L1340-L1354.

Yeah, I understand. Okay, what I said earlier wasn't quite right, let me try that again.

We should update the BuildResHPXML measure to allow a furnace as a second heating system -- so long as the home doesn't end up with two duct systems.

1. If there is a ducted heat pump w/ backup furnace, the backup type needs to be "integrated". (If it was "separate", that would imply two duct systems. OS-HPXML can handle that, but that's too much complexity for the BuildResHPXML measure and would be a very uncommon situation.)
2. If there is a ductless heat pump w/ backup furnace, the backup type needs to be "separate". (A ductless heat pump can't have ducted "integrated" backup, that wouldn't make any sense. I wonder what OS-HPXML does in that situation...)

[joseph-robertson]

@joseph-robertson From my testing it looks like baseline homes with backup systems will have their backup systems' sizes retained rather than the primary systems' sizes retained. Is this intended? For example, take a look at building ids 9 + 11 of a run_analysis.rb run using your national_upgrades2.yml file.

@whiphi92 You are talking about HP to HP upgrades here?

[joseph-robertson]

@whiphi92 I think this gets complicated when considering upgrades from a primary heating system that serves less than 100% of the heating load (i.e., there is a secondary system in the existing building). This is prompted by the recently merged #1093. I'm not sure if this is related to the issue you bring up above.

I think the main question is: should the fraction of the heating load served by the upgraded heat pump equal the fraction served by the existing system (i.e., we retain the secondary system), or should it be set to 100% regardless (i.e., we ignore the secondary system)? (Perhaps this only applies when the heat pump backup type is integrated; when separate, the backup system fraction is not allowed, and we're forced to ignore the secondary system.)

[whiphi92]

@joseph-robertson my intuition is that we would want the heat pump to serve 100% of the load of the dwelling and its backup be the exact size that the original primary system was (even if it only served a fractional percentage of the full load of the dwelling). Does this make sense? Ideally, I suppose, would be that the user can determine whether the heat pump upgrade will serve 100% of the load or just stay the same. We do this with AC via the partial conditioning argument.

[joseph-robertson]

This is the scenario I was trying to convey above:

Existing

• Fuel Furnace (60%)
• (Secondary) Fireplace (40%)

Upgraded

• ASHP (x%)
• (Integrated Backup) Fuel Furnace
• Fireplace (y%)

Should (A) x=60 and y=40, or (B) x=100 and y=0 (i.e., the Fireplace goes away)?

Sounds like it should be (B). Is that right?

@whiphi92 @shorowit

[shorowit]

There's no single answer, it will depend on the situation. Why not default to A, since the user can choose B if they set secondary heating to None as part of the upgrade (right?).

[joseph-robertson]

There's no single answer, it will depend on the situation. Why not default to A, since the user can choose B if they set secondary heating to None as part of the upgrade (right?).

Good point. I'll try rolling with that.

[joseph-robertson]

@whiphi92 This is ready for another review.

[joseph-robertson]

Plan is to create a new RTD page "Heat Pump Upgrades" (or similar) that addresses the following:

• how heat_pump_backup_use_existing_system operates on all the different types of heating system setups in baseline buildings (PR description above is a good start)
• describe integrated backup vs separate backup
• setting heat_pump_backup_heating_lockout_temp and heat_pump_compressor_lockout_temp arguments (e.g., 40F and 5F)

@whiphi92

[whiphi92]

Approved, this looks great.

We need to work on documentation about default values for compressor and backup lockouts and other heat pump related modeling.

Work on that documentation is being performed here.