What
Wire NREL's MixedUpgradeScenario (buildstock-fetch v1.6.5) into the rate design pipeline so each CAIRO run can represent a specific year in a multi-year HP adoption trajectory rather than always using a single upgrade (all-baseline or all-HP).
Why
Today every run is either 100% baseline (upgrade=0) or 100% HP (upgrade=2). To model how rates perform as heat pump adoption grows over time — e.g. NYISO's NYCA electrification forecast from the Gold Book 2025 — we need runs where a fraction of buildings have adopted each upgrade in each calendar year.
How
- Adoption config YAML (
config/adoption/<name>.yaml): specifies per-upgrade adoption fractions for each year index and a year_labels list mapping indices to calendar years.
utils/pre/materialize_mixed_upgrade.py: assigns buildings to upgrades per year using MixedUpgradeScenario, writes year=<N>/metadata-sb.parquet (combined rows from each upgrade) and year=<N>/loads/ (symlinks to correct load parquets). No changes to run_scenario.py.
utils/pre/generate_adoption_scenario_yamls.py: generates scenarios_<utility>_adoption.yaml by copying selected runs from a base scenario YAML and rewriting path_resstock_metadata / path_resstock_loads per year.
- Justfile recipes:
materialize-adoption, generate-adoption-scenarios, run-adoption-scenario, run-adoption-all.
- Tests in
tests/pre/test_materialize_mixed_upgrade.py: building assignment fractions, metadata combination, symlink targets, scenario CSV, and validation error paths.
Prerequisites (separate tasks): download and process upgrades 01, 04, 05 through the data/resstock/ pipeline. Until available, the trajectory works with upgrade 02 only.
Deliverables
- Implemented
materialize_mixed_upgrade.py and generate_adoption_scenario_yamls.py with passing tests
- NYCA adoption config with fractions derived from NYISO Gold Book 2025
- Justfile recipes wired end-to-end
just check and just test pass
What
Wire NREL's
MixedUpgradeScenario(buildstock-fetch v1.6.5) into the rate design pipeline so each CAIRO run can represent a specific year in a multi-year HP adoption trajectory rather than always using a single upgrade (all-baseline or all-HP).Why
Today every run is either 100% baseline (upgrade=0) or 100% HP (upgrade=2). To model how rates perform as heat pump adoption grows over time — e.g. NYISO's NYCA electrification forecast from the Gold Book 2025 — we need runs where a fraction of buildings have adopted each upgrade in each calendar year.
How
config/adoption/<name>.yaml): specifies per-upgrade adoption fractions for each year index and ayear_labelslist mapping indices to calendar years.utils/pre/materialize_mixed_upgrade.py: assigns buildings to upgrades per year usingMixedUpgradeScenario, writesyear=<N>/metadata-sb.parquet(combined rows from each upgrade) andyear=<N>/loads/(symlinks to correct load parquets). No changes torun_scenario.py.utils/pre/generate_adoption_scenario_yamls.py: generatesscenarios_<utility>_adoption.yamlby copying selected runs from a base scenario YAML and rewritingpath_resstock_metadata/path_resstock_loadsper year.materialize-adoption,generate-adoption-scenarios,run-adoption-scenario,run-adoption-all.tests/pre/test_materialize_mixed_upgrade.py: building assignment fractions, metadata combination, symlink targets, scenario CSV, and validation error paths.Prerequisites (separate tasks): download and process upgrades 01, 04, 05 through the
data/resstock/pipeline. Until available, the trajectory works with upgrade 02 only.Deliverables
materialize_mixed_upgrade.pyandgenerate_adoption_scenario_yamls.pywith passing testsjust checkandjust testpass