Update Setpoint and Setpoint Schedule Distributions

[aspeake]

Pull Request Description

Updates the thermostat heating and cooling setpoint distributions (setpoint, has offset, offset magnitude, offset schedule) to be dependent on IECC climate zone instead of AIA zone.

The code used to generate these files is found here: https://github.com/NREL/resstock-estimation/blob/tsp_updates/sources/recs/2009/Setback%20Distributions.ipynb

Checklist

Not all may apply:

• Unit tests have been added or updated
• All rake tasks have been run, and pass
• Documentation has been modified appropriately
• Any new options are added to project_testing
• project_testing runs without any failures
• No unexpected regression test changes
• All tests are passing (green) on circleci
• The changelog has been updated appropriately
• This branch is up-to-date with master

For more information on how to perform these checklist items, see the documentation's Advanced Tutorial.

[afontani]

@ejhw, @aspeake: Are we introducing these changes into the resstock-estimation repo?

[aspeake]

@ejhw, @aspeake: Are we introducing these changes into the resstock-estimation repo?

Eventually we want to incorporate the script into the tsv maker, but I am currently using an existing script I had on this branch to get the tsvs updated and merged ASAP.

[afontani]

@aspeake Thanks for the clarification. Can you add a source tag to the bottom of the TSVs? Something like:

# Source: Constructed using U.S. EIA 2009 Residential Energy Consumption Survey (RECS) microdata.

[aspeake]

@aspeake Thanks for the clarification. Can you add a source tag to the bottom of the TSVs? Something like:

# Source: Constructed using U.S. EIA 2009 Residential Energy Consumption Survey (RECS) microdata.

@afontani Addressed in ec3cf6a

[aspeake]

@afontani @ejhw RECS building type dependency has been added and setback period options were expanded (+/- 5 hour shifts), and the PR should be ready for another review.

[ejhw]

Would it be relatively easy to add a sample_count (and sample_weight) column, so we know how many samples are supporting each distribution?

[ejhw]

It looks like each Option bin is within "+2" not within "+/- 1". i.e., Shouldn't Option=62F represent 61-63F instead of 62-64F?

[aspeake]

It looks like each Option bin is within "+2" not within "+/- 1". i.e., Shouldn't Option=62F represent 61-63F instead of 62-64F?

Our initial approach binned the setpoints into 2 degree bins, then took the nearest integer to the median value in each bin. So the bin [62 - 64) , had a median value closest to 62.

[ejhw]

Our initial approach binned the setpoints into 2 degree bins, then took the nearest integer to the median value in each bin. So the bin [62 - 64) , had a median value closest to 62.

Gotcha, thanks for explaining.

[aspeake]

Would it be relatively easy to add a sample_count (and sample_weight) column, so we know how many samples are supporting each distribution?

addressed in 312d0f4

[ejhw]

Would it be relatively easy to add a sample_count (and sample_weight) column, so we know how many samples are supporting each distribution?

addressed in 312d0f4

Thanks. Some of these sample counts are lower than I'd like (e.g., in 3C). Can you pool samples from 3B and 3C to get a distribution for both? I think that fixes the worst case for me.

[ejhw]

Would it be relatively easy to add a sample_count (and sample_weight) column, so we know how many samples are supporting each distribution?

addressed in 312d0f4

Thanks. Some of these sample counts are lower than I'd like (e.g., in 3C). Can you pool samples from 3B and 3C to get a distribution for both? I think that fixes the worst case for me.

We all decided to not do any lumping at this point. Hopefully these distributions will be replaced by a dataset with more samples (ecobee) in the future.