What
Add a new per-building monthly kWh output to run_scenario.py so that post-processing (build_master_bills) can compute elec_load_delta — the kWh difference between a base (non-flex) run and its demand-flex counterpart.
Today CAIRO computes aggregated monthly loads internally (agg_load from process_building_demand_by_period) but never writes them to disk. Only bills ($) and BAT metrics are saved. To compare kWh between the base run (elasticity=0.0) and the flex run (elasticity=-0.1), we need the monthly load per building from both runs.
Why
The ConEd hp_seasonalTOU_flex scenarios (runs 13-16) are the only runs with demand flexibility (elasticity=-0.1). Analysts need to see not just the bill impact but the actual kWh load shift per building/month to understand how much consumption moved between TOU periods. Without this, the only record of the shift is the demand_flex_elasticity_tracker.csv (per-building epsilon values), which doesn't give monthly kWh totals.
How
- Save monthly kWh per building during
run_scenario.py: After bs.simulate() completes, the agg_load DataFrame (output of _vectorized_process_building_demand_by_period) contains grid_cons and load_data by (bldg_id, month, period, tier). Sum grid_cons by (bldg_id, month) and write to bills/elec_load_monthly.csv (or similar) alongside the existing bill CSVs.
- Add
elec_load_delta to build_master_bills.py: For flex run pairs (e.g., 15+16), accept a --base-run-delivery / --base-run-supply argument pointing to the non-flex counterpart (e.g., 3+4). Read elec_load_monthly.csv from both, compute delta = flex - base, and join into the master bills table. For non-flex runs, elec_load_delta = 0.
- Run pairing for ConEd: base run 1 ↔ flex run 13, 2 ↔ 14, 3 ↔ 15, 4 ↔ 16.
Deliverables
What
Add a new per-building monthly kWh output to
run_scenario.pyso that post-processing (build_master_bills) can computeelec_load_delta— the kWh difference between a base (non-flex) run and its demand-flex counterpart.Today CAIRO computes aggregated monthly loads internally (
agg_loadfromprocess_building_demand_by_period) but never writes them to disk. Only bills ($) and BAT metrics are saved. To compare kWh between the base run (elasticity=0.0) and the flex run (elasticity=-0.1), we need the monthly load per building from both runs.Why
The ConEd
hp_seasonalTOU_flexscenarios (runs 13-16) are the only runs with demand flexibility (elasticity=-0.1). Analysts need to see not just the bill impact but the actual kWh load shift per building/month to understand how much consumption moved between TOU periods. Without this, the only record of the shift is thedemand_flex_elasticity_tracker.csv(per-building epsilon values), which doesn't give monthly kWh totals.How
run_scenario.py: Afterbs.simulate()completes, theagg_loadDataFrame (output of_vectorized_process_building_demand_by_period) containsgrid_consandload_databy(bldg_id, month, period, tier). Sumgrid_consby(bldg_id, month)and write tobills/elec_load_monthly.csv(or similar) alongside the existing bill CSVs.elec_load_deltatobuild_master_bills.py: For flex run pairs (e.g., 15+16), accept a--base-run-delivery/--base-run-supplyargument pointing to the non-flex counterpart (e.g., 3+4). Readelec_load_monthly.csvfrom both, compute delta = flex - base, and join into the master bills table. For non-flex runs,elec_load_delta= 0.Deliverables
run_scenario.pysaveselec_load_monthly.csvper CAIRO run (bldg_id, month, grid_cons_kwh)build_master_bills.pyaccepts optional base-run args and addselec_load_deltacolumnelec_load_deltais 0 for non-flex runs, non-zero for flex runs