You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Background: In regions with large temperature fluctuations during the day (like the SF Bay Area) residential buildings can have significant HVAC energy use during days when the average daily temperature would indicate none should be required. For example, evening and nighttime temperatures can drop well below 60F on days with average temperatures of 65F or higher. Many homes will run their furnace on nights like these. For this reason it is more accurate to calculate HDDs on an hourly basis whenever possible, instead of using average daily temperatures.
Issue: Current CalTRACK methods calculate degree days (DDs) using the same periodicity as the energy data. In the case of natural gas, this means that daily gas data is matched with daily average temperatures for PG&E homes in the SF Bay Area, but hourly electric data is matched with more accurate hourly temperatures. Because of the nonlinearity of DDs, it is more accurate to always use hourly temperature data whenever hourly data is available; otherwise DDs in regions with high daily temperature variations will be systemically underreported, resulting in poor-fit models.
Validation: A reasonable heating balance point temperature is 65F. The attached example shows hourly temperature variation for a day with an average temperature of 65F. The example demonstrates how using daily average temperatures will underestimate degree days: the day's average temperature results in 0 HDD65s, whereas the hourly data results in 2.4 HDD65s, a meaningful difference even for one day. And if this type of daily weather variation occurs year round, the impact can be much more significant. Hourly vs Daily HDD.xlsx
Requested CalTRACK change: For Daily methods, calculate DDs using hourly weather data whenever it is available. Implementation should be trivial, since the code and data for handling hourly temperate data already exists and is in use for hourly smart meter data.
The text was updated successfully, but these errors were encountered:
Background: In regions with large temperature fluctuations during the day (like the SF Bay Area) residential buildings can have significant HVAC energy use during days when the average daily temperature would indicate none should be required. For example, evening and nighttime temperatures can drop well below 60F on days with average temperatures of 65F or higher. Many homes will run their furnace on nights like these. For this reason it is more accurate to calculate HDDs on an hourly basis whenever possible, instead of using average daily temperatures.
Issue: Current CalTRACK methods calculate degree days (DDs) using the same periodicity as the energy data. In the case of natural gas, this means that daily gas data is matched with daily average temperatures for PG&E homes in the SF Bay Area, but hourly electric data is matched with more accurate hourly temperatures. Because of the nonlinearity of DDs, it is more accurate to always use hourly temperature data whenever hourly data is available; otherwise DDs in regions with high daily temperature variations will be systemically underreported, resulting in poor-fit models.
Validation: A reasonable heating balance point temperature is 65F. The attached example shows hourly temperature variation for a day with an average temperature of 65F. The example demonstrates how using daily average temperatures will underestimate degree days: the day's average temperature results in 0 HDD65s, whereas the hourly data results in 2.4 HDD65s, a meaningful difference even for one day. And if this type of daily weather variation occurs year round, the impact can be much more significant.
Hourly vs Daily HDD.xlsx
Requested CalTRACK change: For Daily methods, calculate DDs using hourly weather data whenever it is available. Implementation should be trivial, since the code and data for handling hourly temperate data already exists and is in use for hourly smart meter data.
The text was updated successfully, but these errors were encountered: