CalTRACK Issue: Heating balance point temperatures abnormally low?

[steevschmidt]

Prerequisites

• Are you opening this issue in the correct repository (caltrack/grid/seat)?
• Did you perform a search of previous Github issues to check if this issue has been previously considered?

Article reference number in CalTRACK documentation (optional): 3.2
(Also: see original issue #95, closed during CalTRACK transition from OEE to EM2, and Appendix 3.1.4.1)

Description

Background: Each building has a specific balance point temperature, an outdoor temperature at which heating or cooling loads engage. Getting this right is critical, due to the non-linear nature of degree days and the importance of accurate heating and cooling coefficients in any building model. This type of model error is indicated in the chart below as type 3: the balance point selected is not accurate for the building.

CalTRACK uses an industry-standard “best R-squared” approach to determine the best balance point temperature for each building. We believe there is a better approach for residential buildings.

Issue: During HEA's first residential EE programs (in 2011) we used the industry standard approach. But our building energy experts and a number of energy-savvy homeowners recognized that our HVAC load analysis was inaccurate in many homes, and by investigating individual buildings (via submetering and other ground truth sources) we determined the inaccuracy was caused by low balance point temperature selection (in the case of heating). We attributed the inaccuracy of this method to two issues:

1. The method is based on the assumption that energy consumption depends linearly on HDDs and/or CDDs. When this occurs the correct balance point temperature linear model will have best R-squared value compared to other linear models. However in HEA’s experience since then (now over 10,000 residential buildings analyzed & vetted by owners and energy coaches) we have seen that pure linear dependencies between energy and weather are quite rare in homes: many homes are "bad buildings". As a result, at least in residential buildings, we believe the best R-squared value does not indicate the correct balance temperature.

2. In the case of heating, the number of non-zero HDD data points decreases as the balance temperature decreases (the same is true for cooling, but in the opposite direction). We suspect -- but have not tested -- that fewer data points may result in better R-squared values. (Clearly, in the extreme case of a very low balance point temperature the R-squared value would become 1.0 with only two data points.) If this hypothesis is true, the R-squared approach to balance point selection will systemically select lower balance temperatures.

After discovering these inaccuracies, we switched to a different approach we believe is superior: our base temperature algorithm utilizes an analysis of Average Temperature vs. Average Energy Use curves, where we identify the HVAC-engagement inflection point.

Below are charts for two homes showing average temp vs electric use:

And here are the corresponding charts for the same two homes showing average temp vs average electric use:

With these last two charts in mind, we'll describe our Cooling Base Temperature algorithm. (Heating works in a similar fashion.)

The algorithm analyzes each AvgTemp point between Min_CDD_Temp and Max_CDD_Temp (currently we use 65F and 90F respectively) and builds two trend lines. The first line crosses two points: the leftmost point of the curve (presumably the lowest temperature and lowest cooling energy use) and the temperature point currently being analyzed. The second line also crosses two points: the currently analyzed temperature point and the rightmost point of the curve (presumably the highest temperature and highest energy use). The algorithm calculates the ratio of the angle coefficients for both lines. Across all temperature points, we identify the temperature where the ratio is maximized. Simply speaking the algorithm attempts to identify the temperature point where the energy use becomes temperature-dependent.

This method is also not ideal, because some homes do not have clearly identifiable inflection points. But HEA has used it for many years and in most cases we (meaning our energy coaches and homeowner-customers) are satisfied with the results. We believe it is significantly better than the R-squared approach.

Validation: Across a cohort of 84 homes in PG&E territory, CalTRACK’s average heating balance point temperature was 59.9F for electricity and 60.95F for natural gas. These figures are abnormally low, and significantly lower than the results of the algorithm described above when run on the same homes (within HEA).

If these balance point temperatures are incorrect the CalTRACK analysis will utilize too few HDDs and underreport weather-dependent loads. This will cause inaccurate savings calculations across all buildings analyzed, which will vary significantly based on weather conditions in the reporting period compared to the baseline period: hotter temperatures in the reporting period will produce one type of inaccuracy, and cooler temps the opposite. The same direction of error will occur for all buildings analyzed during that period, systemically.

Requested CalTRACK changes:

1. Investigate alternative methods to balance point temperature selection such as the one described above; and
2. Identify a method to test the accuracy of balance point temperature selections, such as those described in Issue #73. One possibility is the use of CBECC-Res data, where energy data can be generated for a variety of "virtual home" test cases, with any desired balance temperature, infiltration rate, etc.

Proposed test methodology

[I could use some help here...]

1. Run current methods on a large sample of homes and record "before" balance point temperature values. What is the average? What are the CVRMSE values?
2. Adjust the method to calculate balance points as suggested above.
3. Rerun with the updated method, and compare "after" balance points, and CVRMSE values.

Acceptance Criteria

Balance point averages should improve (closer to industry norms) and CVRMSE values should improve in most cases, and never get worse.

[philngo]

Clarifying question: are you proposing averaging temperatures over calendar months or over billing periods, or in some other way?

[steevschmidt]

In the charts above we are using average daily temperatures, together with the associated daily energy use.

[philngo]

Thanks for clarifying. So you are charting average daily temperatures vs average daily energy use in the charts labeled "Avg Temp vs Avg Electric Use". It didn't look to me like there were 365 points, so I assumed it was a longer period you were averaging over, but it may just be a trick of the chart plotting, or maybe the model wasn't built on a full year of data.

What are you charting in the charts labeled "Avg Temp vs Electric Use"? Are those hourly or sub-hourly energy use data, then? If so, are the temperature values in those charts also averaged over the hourly/sub-hourly energy use periods, or are those also daily average values?

[steevschmidt]

Sorry for not being more clear:
"Avg Temp vs Electric Use" has (at least) 365 points of daily data.
"Avg Temp vs Avg Electric Use" displays only the average daily energy use for each temperature.

[danrubado]

Would this apply to monthly methods as well or just to daily data? Seems like the room for improvement with monthly data is much less and that this proposal might add unnecessary complexity for little or no benefit.

[steevschmidt]

@danrubado Agreed -- not sure how much it would help with monthly data. We have only applied it to daily data.

[philngo-recurve]

Closing stale issue in preparation for new working group