Handle state appliance regulations and codes/building performance standards #534
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jtlangevin
changed the title
* Support new measure attribute, “backup_fuel_fraction” that points to a CSV with information about the portion of annual energy use that remains with backup fuels, for dual fuel measures. These data come from the Stock tools, and CSVs for Stock measures have been added in ./ecm_definitions/energyplus_data/dual_fuel_ratios. For example, a measure input could look like this: backup_fuel_fraction: RTU_other_fossil.csv. * Update the function partition_microsegment to report the amount of energy, carbon, and cost that remains with the baseline fuel for a fuel switching measure b/c the measure has not yet switched over that fuel (see ‘add_fs’ variables ending in ‘_base’) vs. the amounts that remain as backup consumption for stock that has switched over to the measure fuel as primary (see ‘add_fs’ variables ending in ‘_switch’). * Handle these more refined estimates of remaining fuel in Measure results breakouts for attribute ‘mseg_out_break’ (via function ‘breakout_mseg’). * Also handle these refinements in MeasurePackage results breakouts for attribute ‘mseg_out_break‘ (via function ‘find_adj_out_break_cats’). * Update test ecm_prep_test to account for new measure attribute.
A bug in the variable used to record and report remaining baseline fuel costs for dual fuel measures was fixed.
* This is a new measure attribute that is useful in handling the 'add_typ_eff' argument properly, and also will be useful in handling code/BPS provisions as that feature is added down the line.
The changes to ecm_prep reflect the following approach to estimate added cooling energy use when homes without existing cooling switch to a heat pump: 1: Loop through measure heating segments and determine/record the # of heating units that convert to heat pumps by region, building type, and building vintage. 2: Loop through measure cooling segments and pull the following data for each region, building type, and vintage combination (in partition_microsegment function): 2.1: Unit-level baseline cooling energy use (MMBtu/base cooling unit) and 2.2: Measure relative cooling performance vs. baseline cooling unit (%). 3: Calculate total added cooling energy (and emissions/costs) for region/building/vintage; added cooling = #1 * #2.1 * #2.2. 4: Add result from #3 to the measure’s efficient results.
The checks were assuming switching to electric tech in some cases, where users may want to represent switches away from electricity.
For representation of alternate utility rate structures (addresses #411): * Create a database that lists assumptions about electrification-friendly rate structures (e.g., % or absolute reductions in volumetric $/kWh) by state, customer class (res/com), fuel, and start/end year, with applicability factor to map rates that only affect a portion of the state’s area. * Database can include rows for representing rate structure sensitivities that are tested across all or a large grouping of states (e.g., state = “all”; state = ”leading”; state= “usca”). * Use data from the first bullet to modify energy cost application in partition_microsegment function (e.g., reduce volumetric rate for scenario). For enhanced representation of state/utility incentives (addresses #410): * Create a database that lists assumptions about new incentives (e.g., % of total installed cost for given performance threshold; start and end year); extensions of existing incentives (through end year) and/or increases (or, for fossil equipment, removals) of existing incentives (% max ref. case incentive for start/end year) by state, building type, building vintage (new/existing), and technology, with applicability factors to map incentives that affect a portion of the state’s area. * Database can include rows for representing federal incentives (e.g., state = “all”) or in broad groupings of states (e.g., state = ”leading”; state= “usca”). * Apply the assumptions from the first bullet to code that applies first cost incentives: For new incentives, assume new incentive replaces any existing incentives already in the AEO forecast for the applicable segment. For extension, find the first year in the reference case forecast that reaches the maximum incentive level and extend it forward through the end year in (a). For an increase, same as bullet above but then increase by % specified in (a) for subsequent years.
The changes to ecm_prep reflect the following approach to estimate added cooling energy use when homes without existing cooling switch to a heat pump: 1: Loop through measure heating segments and determine/record the # of heating units that convert to heat pumps by region, building type, and building vintage. 2: Loop through measure cooling segments and pull the following data for each region, building type, and vintage combination (in partition_microsegment function): 2.1: Unit-level baseline cooling energy use (MMBtu/base cooling unit) and 2.2: Measure relative cooling performance vs. baseline cooling unit (%). 3: Calculate total added cooling energy (and emissions/costs) for region/building/vintage; added cooling = #1 * #2.1 * #2.2. 4: Add result from #3 to the measure’s efficient results.
* When users specify a new “high_res_comp” option in run.py, measure unit capital and operating costs will be separately calculated for each of its applicable market microsegment (the default is to calculate these measure costs across all its markets.) These more highly resolved cost data will then be used to compete the measure’s microsegments with overlapping measures. * The calculations are supported with uncompeted technical potential case cost data for each microsegment generated in ecm_prep.py. These data are now generated whether or not the technical potential case has been restricted out by the user when running ecm_prep. * Information used to link stock turnover calculations across microsegments is now determined in a separate function, find_join_keys, which is refactored out of the compete_adj_dicts function. In addition to determining stock turnover, this linking information is now used to pull mseg-specific stock cost information when high_res_comp is used. * In run.py, commercial time preference premiums/market share distributions were updated to the latest EIA NEMS docs. When high_res_comp is specified, the latest EIA method of determining life cycle costs is used – this method annualizes capital costs and adds those to annual energy costs for each year. (The legacy method of calculating NPV is retained when users do not use the high_res_comp option.) * The factors used to translate from unit service demand to unit service capacity in ecm_prep are reported through to run to ensure correct processing of unit-level costs for competition. Addresses #408.
jtlangevin
force-pushed
the
409_412-state-appliance-regs_codes-bps
branch
from
9fa88ec to
5c2cc03
Compare
For representation of alternate utility rate structures (addresses #411): * Create a database that lists assumptions about electrification-friendly rate structures (e.g., % or absolute reductions in volumetric $/kWh) by state, customer class (res/com), fuel, and start/end year, with applicability factor to map rates that only affect a portion of the state’s area. * Database can include rows for representing rate structure sensitivities that are tested across all or a large grouping of states (e.g., state = “all”; state = ”leading”; state= “usca”). * Use data from the first bullet to modify energy cost application in partition_microsegment function (e.g., reduce volumetric rate for scenario). For enhanced representation of state/utility incentives (addresses #410): * Create a database that lists assumptions about new incentives (e.g., % of total installed cost for given performance threshold; start and end year); extensions of existing incentives (through end year) and/or increases (or, for fossil equipment, removals) of existing incentives (% max ref. case incentive for start/end year) by state, building type, building vintage (new/existing), and technology, with applicability factors to map incentives that affect a portion of the state’s area. * Database can include rows for representing federal incentives (e.g., state = “all”) or in broad groupings of states (e.g., state = ”leading”; state= “usca”). * Apply the assumptions from the first bullet to code that applies first cost incentives: For new incentives, assume new incentive replaces any existing incentives already in the AEO forecast for the applicable segment. For extension, find the first year in the reference case forecast that reaches the maximum incentive level and extend it forward through the end year in (a). For an increase, same as bullet above but then increase by % specified in (a) for subsequent years.
* When users specify a new “high_res_comp” option in run.py, measure unit capital and operating costs will be separately calculated for each of its applicable market microsegment (the default is to calculate these measure costs across all its markets.) These more highly resolved cost data will then be used to compete the measure’s microsegments with overlapping measures. * The calculations are supported with uncompeted technical potential case cost data for each microsegment generated in ecm_prep.py. These data are now generated whether or not the technical potential case has been restricted out by the user when running ecm_prep. * Information used to link stock turnover calculations across microsegments is now determined in a separate function, find_join_keys, which is refactored out of the compete_adj_dicts function. In addition to determining stock turnover, this linking information is now used to pull mseg-specific stock cost information when high_res_comp is used. * In run.py, commercial time preference premiums/market share distributions were updated to the latest EIA NEMS docs. When high_res_comp is specified, the latest EIA method of determining life cycle costs is used – this method annualizes capital costs and adds those to annual energy costs for each year. (The legacy method of calculating NPV is retained when users do not use the high_res_comp option.) * The factors used to translate from unit service demand to unit service capacity in ecm_prep are reported through to run to ensure correct processing of unit-level costs for competition. Addresses #408.
For representation of alternate utility rate structures (addresses #411): * Create a database that lists assumptions about electrification-friendly rate structures (e.g., % or absolute reductions in volumetric $/kWh) by state, customer class (res/com), fuel, and start/end year, with applicability factor to map rates that only affect a portion of the state’s area. * Database can include rows for representing rate structure sensitivities that are tested across all or a large grouping of states (e.g., state = “all”; state = ”leading”; state= “usca”). * Use data from the first bullet to modify energy cost application in partition_microsegment function (e.g., reduce volumetric rate for scenario). For enhanced representation of state/utility incentives (addresses #410): * Create a database that lists assumptions about new incentives (e.g., % of total installed cost for given performance threshold; start and end year); extensions of existing incentives (through end year) and/or increases (or, for fossil equipment, removals) of existing incentives (% max ref. case incentive for start/end year) by state, building type, building vintage (new/existing), and technology, with applicability factors to map incentives that affect a portion of the state’s area. * Database can include rows for representing federal incentives (e.g., state = “all”) or in broad groupings of states (e.g., state = ”leading”; state= “usca”). * Apply the assumptions from the first bullet to code that applies first cost incentives: For new incentives, assume new incentive replaces any existing incentives already in the AEO forecast for the applicable segment. For extension, find the first year in the reference case forecast that reaches the maximum incentive level and extend it forward through the end year in (a). For an increase, same as bullet above but then increase by % specified in (a) for subsequent years.
Regarding appliance emissions regulations: * Create a database that lists assumed restrictions on fossil fuel use by state, building type/vintage (new/existing), fossil fuel type, end use, and start year, with applicability factors to map policies that only affect a portion of the state’s area. * In run module competition calculations for each baseline microsegment, use data from the first bullet to flag competing measures for characteristics that are prohibited under laws affecting appliances, e.g., restricted fossil-based energy use in new buildings where the measure does not electrify. * When a measure is flagged for a given competed microsegment, determine what fraction of the microsegment’s competition the measure should be excluded from (e.g., 100% ban or a ban that applies to X% of the state’s population/building energy) * Pass the fraction determined to the find_added_sbmkt_fracs function, which will remove that portion from competition and distribute it to other competing measures. Regarding codes/BPS: * Create a database that lists assumptions about code and BPS characteristics (e.g., energy reduction factors vs. current code, % scope 1 emissions reduction) and adoption levels by state, building type, building vintage (new/existing), end use (or whole building), and start/end years, with applicability factor to map codes/standards that only affect a portion of the state’s area. * Apply the assumptions from the first bullet as a post-processing step in run (after existing finalize_outputs function) across all summed scenario results (broken out by the dimensions in the first bullet) that compares scenario efficient-captured results vs. comparable portion of baseline, determines whether relative reductions in the first bullet are met or exceeded, and adjusts efficient results to meet the criteria as needed. * Represent adjustments as separate residential and commercial codes and standards measures in results (with same format as other measures).
* Collection of individually small fixes to the adjustment calculations in compete_adj that were required to address errors discovered when sense-checking Buildings Sector Scenarios resuls.
jtlangevin
force-pushed
the
409_412-state-appliance-regs_codes-bps
branch
from
5c2cc03 to
b1472d8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Where to focus attention:
config_default, for codes/BPS:codes,code_comply_res,code_comply_com,bps,bps_comply_com,bps_comply_res; for state-level appliance regs:state_appl_regs, all under the higher-levelsub_fed_policyoption forecm_prep.runmodule,no_compandtrim_resultsare less important for this feature. The former suppresses any measure competition in cases where the user just wants to see uncompeted results for individual measures. The latter also has another existing PR that will override it (here) but was added here to ensure things ran through.runmodule. For codes/BPS see in particular theprocess_codes_bpsfunction, and for state-level appliance standards, see thestate_app_reg_screenfunction.Overview of approach:
Regarding appliance emissions regulations (addresses #409):
Regarding codes/BPS (addresses #412):