Update GSHP curves

[jmaguire1]

Pull Request Description

Since our curves are based on a product that's > 20 years old, seems like it's time for a refresh of the curves. I've been taking the spec sheet from the latest single speed product in the ClimateMaster product line: https://www.climatemaster.com/download/18.274be999165850ccd5b5b73/1535543867815/lc377-climatemaster-commercial-tranquility-20-single-stage-ts-series-water-source-heat-pump-submittal-set.pdf

And trying to use this data along with the EnergyPlus spreadsheet tools for generating appropriate curves that represent the performance of this product. The curves weren't able to be completely renormalized to 1.0 at rated conditions as the spreadsheet tool doesn't let users easily constrain the curves to this, although they are closer to 1.0 at rated conditions.

The overall impact here is a slight INCREASE in heating energy consumption (11% in Denver) and no substantial change in cooling (<1%, although in other climate zones it can be up to a 5% DECREASE in energy consumption), with some differences in impact depending on climate. It was pretty tricky to get the heating curves updated as the curve generation process is very sensitive to the rated conditions entered. The trick is to actually enter the conditions in the point with maximum heat output rather than what's truly a rated condition (which for water to air HP there's actually a few sets of rated conditions depending on the application).

Checklist

PR Author: Check these when they're done. Not all may apply. strikethrough and check any that do not apply.

PR Reviewer: Verify each has been completed.

• Schematron validator (EPvalidator.xml) has been updated
• Sample files have been added/updated (via tasks.rb)
• Tests have been added/updated (e.g., HPXMLtoOpenStudio/tests and/or workflow/tests/hpxml_translator_test.rb)
• Documentation has been updated
• Changelog has been updated
• openstudio tasks.rb update_measures has been run
• No unexpected changes to simulation results of sample files

[shorowit]

@jmaguire1 If this addresses the warning, you should be able to delete this line where we were exempting this warning. (The CI tests will throw an error for any warning that we don't exempt.)

[joseph-robertson]

This is the current "base -> feature" scheme for ghp-related branches: master -> (1) fan/pump adjustment -> (2) ground_temperatures -> (3) geothermal loop -> (4) gshp curves

From the above, these are ready for cursory review by @shorowit:

• ground_temperatures
• geothermal loop

@joseph-robertson will pull "(3) geothermal loop" into a resstock branch. Should we do the same for (1) and (2)? Yes, we do.

Then @prsh5175 can:

• either:
  • a) create new TSV file(s) (resstock-estimation) to control various arguments, e.g., soil conductivity, bore spacing, etc, or
  • b) use upgrades defined in yml files (this may not be a long term solution)
• subsequently update the options_lookup

If we want to compare the new branch vs develop, and we're making TSV file changes, we'll need to either

• a) ensure samples are the same across the two branches, or
• b) use precomputed buildstock CSV files.

To handle (a) here (preferred approach), we could probably introduce the new TSVs to develop, and they wouldn't actually do anything.

Perhaps this can be something like a sensitivity/parametric analysis.

[afontani]

@prsh5175 : Please reach out about TSV changes. I will have some guidance around how to make sure the tests pass and we get the comparisons to run.

@joseph-robertson : For the comparisons approach "a) ensure samples are the same across the two branches" , we could base the PR off another branch (not develop) that has the TSV changes already in the branch. This way the comparisons would have the same samples.

[jmaguire1]

Impact of these changes on our GSHP annual energy consumption/COP predictions:

<style> </style>

		Heating Energy	Heating COP	Cooling Energy	Cooling COP
Denver	Original	5.37	3.61	3.97	3.35
Denver	Updated	5.96	3.30	3.98	3.36
Denver	% Difference	-11%	9%	0%	0%
Baltimore	Original	4.02	3.63	6.29	3.21
Baltimore	Updated	4.43	3.32	6.09	3.34
Baltimore	% Difference	-10%	8%	3%	-4%
Dallas	Original	0.63	3.86	13.86	3.00
Dallas	Updated	0.68	3.61	13.34	3.14
Dallas	% Difference	-9%	6%	4%	-5%
ALL	Nominal	-	3.64	-	5.36

Overall impact across a few climate zones is that COP during heating slightly decreased (6%) and during cooling it slightly increased (-4%). However, the performance maps aren't strictly a bias in this fashion, it has more to do with where on the performance map we land:

The heating performance map is closer to a biased result, I've spent a LONG time messing with how to generate the curves (using different rated conditions in the spreadsheet, looking at expanding the dataset a few different ways based on the approach in Tang's thesis). It's worth point out that the COP curves aren't direct inputs here: there's curves for heating capacity and power, which you can use to calculate COP given rated conditions. It's also worth pointing out that since the incoming water temperature depends on the deep ground temperature more than anything, we wouldn't expect to see that we're hitting the full range I'm plotting unless we went to some rather extreme climates.

[jmaguire1]

One more thing I forgot to mention: it wasn't possible to easily get rid of the warnings around curves not being centered at the nominal point. We're closer than we were, but there's still several curves that are > 5% different than the nominal at rated conditions. Since there's no way to force the curve generation to set the 1.0 value at rated conditions, I can't easily remove those warnings as much as I'd like to.