diff --git a/docs/build/doctrees/additional_model_information.doctree b/docs/build/doctrees/additional_model_information.doctree deleted file mode 100644 index 8a33611e..00000000 Binary files a/docs/build/doctrees/additional_model_information.doctree and /dev/null differ diff --git a/docs/build/doctrees/bokehpivot.doctree b/docs/build/doctrees/bokehpivot.doctree deleted file mode 100644 index 5bbda791..00000000 Binary files a/docs/build/doctrees/bokehpivot.doctree and /dev/null differ diff --git a/docs/build/doctrees/documentation_tools/README.doctree b/docs/build/doctrees/documentation_tools/README.doctree deleted file mode 100644 index 89b50336..00000000 Binary files a/docs/build/doctrees/documentation_tools/README.doctree and /dev/null differ diff --git a/docs/build/doctrees/environment.pickle b/docs/build/doctrees/environment.pickle deleted file mode 100644 index a6a8d746..00000000 Binary files a/docs/build/doctrees/environment.pickle and /dev/null differ diff --git a/docs/build/doctrees/faq.doctree b/docs/build/doctrees/faq.doctree deleted file mode 100644 index 27065e60..00000000 Binary files a/docs/build/doctrees/faq.doctree and /dev/null differ diff --git a/docs/build/doctrees/index.doctree b/docs/build/doctrees/index.doctree deleted file mode 100644 index 6da0d85c..00000000 Binary files a/docs/build/doctrees/index.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/additional_setup.doctree b/docs/build/doctrees/internal/additional_setup.doctree deleted file mode 100644 index 224f2fc9..00000000 Binary files a/docs/build/doctrees/internal/additional_setup.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/coding_standards_and_conventions.doctree b/docs/build/doctrees/internal/coding_standards_and_conventions.doctree deleted file mode 100644 index f8ce388b..00000000 Binary files a/docs/build/doctrees/internal/coding_standards_and_conventions.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/developer_best_practices.doctree b/docs/build/doctrees/internal/developer_best_practices.doctree deleted file mode 100644 index f0761811..00000000 Binary files a/docs/build/doctrees/internal/developer_best_practices.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/developer_tips.doctree b/docs/build/doctrees/internal/developer_tips.doctree deleted file mode 100644 index f1c0889f..00000000 Binary files a/docs/build/doctrees/internal/developer_tips.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/documentation_guidelines.doctree b/docs/build/doctrees/internal/documentation_guidelines.doctree deleted file mode 100644 index b647f976..00000000 Binary files a/docs/build/doctrees/internal/documentation_guidelines.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/hourlize.doctree b/docs/build/doctrees/internal/hourlize.doctree deleted file mode 100644 index 44b29305..00000000 Binary files a/docs/build/doctrees/internal/hourlize.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/onboarding.doctree b/docs/build/doctrees/internal/onboarding.doctree deleted file mode 100644 index 50911c82..00000000 Binary files a/docs/build/doctrees/internal/onboarding.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/pull_request_best_practices.doctree b/docs/build/doctrees/internal/pull_request_best_practices.doctree deleted file mode 100644 index 6c0b7cd1..00000000 Binary files a/docs/build/doctrees/internal/pull_request_best_practices.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/reeds_training_homework.doctree b/docs/build/doctrees/internal/reeds_training_homework.doctree deleted file mode 100644 index 2fcc61f4..00000000 Binary files a/docs/build/doctrees/internal/reeds_training_homework.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/ssh_setup.doctree b/docs/build/doctrees/internal/ssh_setup.doctree deleted file mode 100644 index 53f2081f..00000000 Binary files a/docs/build/doctrees/internal/ssh_setup.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/version_control_and_testing.doctree b/docs/build/doctrees/internal/version_control_and_testing.doctree deleted file mode 100644 index ff53e9fb..00000000 Binary files a/docs/build/doctrees/internal/version_control_and_testing.doctree and /dev/null differ diff --git a/docs/build/doctrees/internal/yampa_guide.doctree b/docs/build/doctrees/internal/yampa_guide.doctree deleted file mode 100644 index 812f57ab..00000000 Binary files a/docs/build/doctrees/internal/yampa_guide.doctree and /dev/null differ diff --git a/docs/build/doctrees/model_documentation.doctree b/docs/build/doctrees/model_documentation.doctree deleted file mode 100644 index 593ac14d..00000000 Binary files a/docs/build/doctrees/model_documentation.doctree and /dev/null differ diff --git a/docs/build/doctrees/postprocessing_tools.doctree b/docs/build/doctrees/postprocessing_tools.doctree deleted file mode 100644 index 46676993..00000000 Binary files a/docs/build/doctrees/postprocessing_tools.doctree and /dev/null differ diff --git a/docs/build/doctrees/retail_rate_module.doctree b/docs/build/doctrees/retail_rate_module.doctree deleted file mode 100644 index 93dd0576..00000000 Binary files a/docs/build/doctrees/retail_rate_module.doctree and /dev/null differ diff --git a/docs/build/doctrees/revalue.doctree b/docs/build/doctrees/revalue.doctree deleted file mode 100644 index 8e9ac14b..00000000 Binary files a/docs/build/doctrees/revalue.doctree and /dev/null differ diff --git a/docs/build/doctrees/setup.doctree b/docs/build/doctrees/setup.doctree deleted file mode 100644 index 814ab692..00000000 Binary files a/docs/build/doctrees/setup.doctree and /dev/null differ diff --git a/docs/build/doctrees/sources.doctree b/docs/build/doctrees/sources.doctree deleted file mode 100644 index c401387e..00000000 Binary files a/docs/build/doctrees/sources.doctree and /dev/null differ diff --git a/docs/build/doctrees/tableau.doctree b/docs/build/doctrees/tableau.doctree deleted file mode 100644 index bee52a8a..00000000 Binary files a/docs/build/doctrees/tableau.doctree and /dev/null differ diff --git a/docs/build/html/.buildinfo b/docs/build/html/.buildinfo deleted file mode 100644 index cbdba407..00000000 --- a/docs/build/html/.buildinfo +++ /dev/null @@ -1,4 +0,0 @@ -# Sphinx build info version 1 -# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done. -config: 4e6277f5a604d841152fedc2b9b03f4f -tags: 645f666f9bcd5a90fca523b33c5a78b7 diff --git a/docs/build/html/_images/ReEDS-structure.png b/docs/build/html/_images/ReEDS-structure.png deleted file mode 100644 index 06e81917..00000000 Binary files a/docs/build/html/_images/ReEDS-structure.png and /dev/null differ diff --git a/docs/build/html/_images/ac-transmission-capacity.png b/docs/build/html/_images/ac-transmission-capacity.png deleted file mode 100644 index d7333b1f..00000000 Binary files a/docs/build/html/_images/ac-transmission-capacity.png and /dev/null differ diff --git a/docs/build/html/_images/anaconda-custom-install-mac.png b/docs/build/html/_images/anaconda-custom-install-mac.png deleted file mode 100644 index cdcd5a82..00000000 Binary files a/docs/build/html/_images/anaconda-custom-install-mac.png and /dev/null differ diff --git a/docs/build/html/_images/anaconda-install-mac.png b/docs/build/html/_images/anaconda-install-mac.png deleted file mode 100644 index 56a4e7fa..00000000 Binary files a/docs/build/html/_images/anaconda-install-mac.png and /dev/null differ diff --git a/docs/build/html/_images/anaconda-intel.png b/docs/build/html/_images/anaconda-intel.png deleted file mode 100644 index e0e498ba..00000000 Binary files a/docs/build/html/_images/anaconda-intel.png and /dev/null differ diff --git a/docs/build/html/_images/annual-growth-penalties.png b/docs/build/html/_images/annual-growth-penalties.png deleted file mode 100644 index 6167af8b..00000000 Binary files a/docs/build/html/_images/annual-growth-penalties.png and /dev/null differ diff --git a/docs/build/html/_images/available-region-options.png b/docs/build/html/_images/available-region-options.png deleted file mode 100644 index 66449499..00000000 Binary files a/docs/build/html/_images/available-region-options.png and /dev/null differ diff --git a/docs/build/html/_images/biomass-supply-curve-regions.png b/docs/build/html/_images/biomass-supply-curve-regions.png deleted file mode 100644 index 9f3b3135..00000000 Binary files a/docs/build/html/_images/biomass-supply-curve-regions.png and /dev/null differ diff --git a/docs/build/html/_images/canada-imports-exports.png b/docs/build/html/_images/canada-imports-exports.png deleted file mode 100644 index 243ce418..00000000 Binary files a/docs/build/html/_images/canada-imports-exports.png and /dev/null differ diff --git a/docs/build/html/_images/capacity-binning-example.png b/docs/build/html/_images/capacity-binning-example.png deleted file mode 100644 index 40703ec2..00000000 Binary files a/docs/build/html/_images/capacity-binning-example.png and /dev/null differ diff --git a/docs/build/html/_images/capital-cost-financial-multipliers.png b/docs/build/html/_images/capital-cost-financial-multipliers.png deleted file mode 100644 index 93ed324c..00000000 Binary files a/docs/build/html/_images/capital-cost-financial-multipliers.png and /dev/null differ diff --git a/docs/build/html/_images/cases-csv.png b/docs/build/html/_images/cases-csv.png deleted file mode 100644 index 591299d7..00000000 Binary files a/docs/build/html/_images/cases-csv.png and /dev/null differ diff --git a/docs/build/html/_images/census-division-values.png b/docs/build/html/_images/census-division-values.png deleted file mode 100644 index 48dfce1e..00000000 Binary files a/docs/build/html/_images/census-division-values.png and /dev/null differ diff --git a/docs/build/html/_images/cmd-prompt.png b/docs/build/html/_images/cmd-prompt.png deleted file mode 100644 index 5aed4742..00000000 Binary files a/docs/build/html/_images/cmd-prompt.png and /dev/null differ diff --git a/docs/build/html/_images/csp-resource-availability.png b/docs/build/html/_images/csp-resource-availability.png deleted file mode 100644 index 53b8127a..00000000 Binary files a/docs/build/html/_images/csp-resource-availability.png and /dev/null differ diff --git a/docs/build/html/_images/cv-calculation-ldc-approach.png b/docs/build/html/_images/cv-calculation-ldc-approach.png deleted file mode 100644 index 5a0dd1be..00000000 Binary files a/docs/build/html/_images/cv-calculation-ldc-approach.png and /dev/null differ diff --git a/docs/build/html/_images/edit-env-var-win.png b/docs/build/html/_images/edit-env-var-win.png deleted file mode 100644 index 1d2f4311..00000000 Binary files a/docs/build/html/_images/edit-env-var-win.png and /dev/null differ diff --git a/docs/build/html/_images/energy-capacity-requirements-for-storage.png b/docs/build/html/_images/energy-capacity-requirements-for-storage.png deleted file mode 100644 index 361a409e..00000000 Binary files a/docs/build/html/_images/energy-capacity-requirements-for-storage.png and /dev/null differ diff --git a/docs/build/html/_images/env-var-win.png b/docs/build/html/_images/env-var-win.png deleted file mode 100644 index cdf8f77a..00000000 Binary files a/docs/build/html/_images/env-var-win.png and /dev/null differ diff --git a/docs/build/html/_images/exe-runbatch.png b/docs/build/html/_images/exe-runbatch.png deleted file mode 100644 index 12c23056..00000000 Binary files a/docs/build/html/_images/exe-runbatch.png and /dev/null differ diff --git a/docs/build/html/_images/gams-install-mac.png b/docs/build/html/_images/gams-install-mac.png deleted file mode 100644 index 93f66174..00000000 Binary files a/docs/build/html/_images/gams-install-mac.png and /dev/null differ diff --git a/docs/build/html/_images/gams-test.png b/docs/build/html/_images/gams-test.png deleted file mode 100644 index 5be8a2f0..00000000 Binary files a/docs/build/html/_images/gams-test.png and /dev/null differ diff --git a/docs/build/html/_images/github-download.png b/docs/build/html/_images/github-download.png deleted file mode 100644 index ad2848a9..00000000 Binary files a/docs/build/html/_images/github-download.png and /dev/null differ diff --git a/docs/build/html/_images/github_add_ssh_key.png b/docs/build/html/_images/github_add_ssh_key.png deleted file mode 100644 index 0a8ffdd2..00000000 Binary files a/docs/build/html/_images/github_add_ssh_key.png and /dev/null differ diff --git a/docs/build/html/_images/github_settings.png b/docs/build/html/_images/github_settings.png deleted file mode 100644 index dd835d23..00000000 Binary files a/docs/build/html/_images/github_settings.png and /dev/null differ diff --git a/docs/build/html/_images/github_ssh_gpg_keys.png b/docs/build/html/_images/github_ssh_gpg_keys.png deleted file mode 100644 index b6c2b7d0..00000000 Binary files a/docs/build/html/_images/github_ssh_gpg_keys.png and /dev/null differ diff --git a/docs/build/html/_images/hpc_request_form.png b/docs/build/html/_images/hpc_request_form.png deleted file mode 100644 index 4f53b05e..00000000 Binary files a/docs/build/html/_images/hpc_request_form.png and /dev/null differ diff --git a/docs/build/html/_images/hydro-supply-curve.png b/docs/build/html/_images/hydro-supply-curve.png deleted file mode 100644 index 35e5f7ec..00000000 Binary files a/docs/build/html/_images/hydro-supply-curve.png and /dev/null differ diff --git a/docs/build/html/_images/hydro-vision-npd-resource-potential.png b/docs/build/html/_images/hydro-vision-npd-resource-potential.png deleted file mode 100644 index 3d2abd87..00000000 Binary files a/docs/build/html/_images/hydro-vision-npd-resource-potential.png and /dev/null differ diff --git a/docs/build/html/_images/hydro-vision-nsd-resource-potential.png b/docs/build/html/_images/hydro-vision-nsd-resource-potential.png deleted file mode 100644 index 38193854..00000000 Binary files a/docs/build/html/_images/hydro-vision-nsd-resource-potential.png and /dev/null differ diff --git a/docs/build/html/_images/hydro-vision-upgrade-resource-potential.png b/docs/build/html/_images/hydro-vision-upgrade-resource-potential.png deleted file mode 100644 index 30d79146..00000000 Binary files a/docs/build/html/_images/hydro-vision-upgrade-resource-potential.png and /dev/null differ diff --git a/docs/build/html/_images/hydrogen-storage-availability.png b/docs/build/html/_images/hydrogen-storage-availability.png deleted file mode 100644 index 326d440e..00000000 Binary files a/docs/build/html/_images/hydrogen-storage-availability.png and /dev/null differ diff --git a/docs/build/html/_images/hydrogen-storage-cost-estimate.png b/docs/build/html/_images/hydrogen-storage-cost-estimate.png deleted file mode 100644 index bfd2c33e..00000000 Binary files a/docs/build/html/_images/hydrogen-storage-cost-estimate.png and /dev/null differ diff --git a/docs/build/html/_images/input-fuel-price-assumptions.png b/docs/build/html/_images/input-fuel-price-assumptions.png deleted file mode 100644 index f7ef8ed6..00000000 Binary files a/docs/build/html/_images/input-fuel-price-assumptions.png and /dev/null differ diff --git a/docs/build/html/_images/installed-battery-capacity.png b/docs/build/html/_images/installed-battery-capacity.png deleted file mode 100644 index 363f0666..00000000 Binary files a/docs/build/html/_images/installed-battery-capacity.png and /dev/null differ diff --git a/docs/build/html/_images/interconnection-cost-distribution.png b/docs/build/html/_images/interconnection-cost-distribution.png deleted file mode 100644 index cddc46ee..00000000 Binary files a/docs/build/html/_images/interconnection-cost-distribution.png and /dev/null differ diff --git a/docs/build/html/_images/land-based-wind-costs.png b/docs/build/html/_images/land-based-wind-costs.png deleted file mode 100644 index ff17a7c3..00000000 Binary files a/docs/build/html/_images/land-based-wind-costs.png and /dev/null differ diff --git a/docs/build/html/_images/land-based-wind.png b/docs/build/html/_images/land-based-wind.png deleted file mode 100644 index 278a33ae..00000000 Binary files a/docs/build/html/_images/land-based-wind.png and /dev/null differ diff --git a/docs/build/html/_images/local-generation-interconnection-components.png b/docs/build/html/_images/local-generation-interconnection-components.png deleted file mode 100644 index 3516e3ea..00000000 Binary files a/docs/build/html/_images/local-generation-interconnection-components.png and /dev/null differ diff --git a/docs/build/html/_images/natural-gas-futures-prices-by-season.png b/docs/build/html/_images/natural-gas-futures-prices-by-season.png deleted file mode 100644 index 5961b3f3..00000000 Binary files a/docs/build/html/_images/natural-gas-futures-prices-by-season.png and /dev/null differ diff --git a/docs/build/html/_images/natural-gas-futures-prices.png b/docs/build/html/_images/natural-gas-futures-prices.png deleted file mode 100644 index ae1478eb..00000000 Binary files a/docs/build/html/_images/natural-gas-futures-prices.png and /dev/null differ diff --git a/docs/build/html/_images/new-ac-transmission-cost-assumptions.png b/docs/build/html/_images/new-ac-transmission-cost-assumptions.png deleted file mode 100644 index 551ad0ef..00000000 Binary files a/docs/build/html/_images/new-ac-transmission-cost-assumptions.png and /dev/null differ diff --git a/docs/build/html/_images/ng-price-consumption-model.png b/docs/build/html/_images/ng-price-consumption-model.png deleted file mode 100644 index fef70a0b..00000000 Binary files a/docs/build/html/_images/ng-price-consumption-model.png and /dev/null differ diff --git a/docs/build/html/_images/nodal-transmission-network-data.png b/docs/build/html/_images/nodal-transmission-network-data.png deleted file mode 100644 index 7cfd9018..00000000 Binary files a/docs/build/html/_images/nodal-transmission-network-data.png and /dev/null differ diff --git a/docs/build/html/_images/offshore-wind-resource.png b/docs/build/html/_images/offshore-wind-resource.png deleted file mode 100644 index 26aa84fb..00000000 Binary files a/docs/build/html/_images/offshore-wind-resource.png and /dev/null differ diff --git a/docs/build/html/_images/py-test.png b/docs/build/html/_images/py-test.png deleted file mode 100644 index 30ae6503..00000000 Binary files a/docs/build/html/_images/py-test.png and /dev/null differ diff --git a/docs/build/html/_images/reeds-load-adjustment-method.png b/docs/build/html/_images/reeds-load-adjustment-method.png deleted file mode 100644 index ccb3ddf2..00000000 Binary files a/docs/build/html/_images/reeds-load-adjustment-method.png and /dev/null differ diff --git a/docs/build/html/_images/reeds-regional-structure.png b/docs/build/html/_images/reeds-regional-structure.png deleted file mode 100644 index fc111dfb..00000000 Binary files a/docs/build/html/_images/reeds-regional-structure.png and /dev/null differ diff --git a/docs/build/html/_images/regional-capital-cost-multipliers.png b/docs/build/html/_images/regional-capital-cost-multipliers.png deleted file mode 100644 index 277bbada..00000000 Binary files a/docs/build/html/_images/regional-capital-cost-multipliers.png and /dev/null differ diff --git a/docs/build/html/_images/run-as-admin-2.png b/docs/build/html/_images/run-as-admin-2.png deleted file mode 100644 index 52fcf6cb..00000000 Binary files a/docs/build/html/_images/run-as-admin-2.png and /dev/null differ diff --git a/docs/build/html/_images/run-as-admin.png b/docs/build/html/_images/run-as-admin.png deleted file mode 100644 index 83f335e9..00000000 Binary files a/docs/build/html/_images/run-as-admin.png and /dev/null differ diff --git a/docs/build/html/_images/search-env-var.png b/docs/build/html/_images/search-env-var.png deleted file mode 100644 index 12670991..00000000 Binary files a/docs/build/html/_images/search-env-var.png and /dev/null differ diff --git a/docs/build/html/_images/storage-capacity-credit-allocation-example.png b/docs/build/html/_images/storage-capacity-credit-allocation-example.png deleted file mode 100644 index 110a370e..00000000 Binary files a/docs/build/html/_images/storage-capacity-credit-allocation-example.png and /dev/null differ diff --git a/docs/build/html/_images/storage-capacity-credit-allocation-example2.png b/docs/build/html/_images/storage-capacity-credit-allocation-example2.png deleted file mode 100644 index 30183c5a..00000000 Binary files a/docs/build/html/_images/storage-capacity-credit-allocation-example2.png and /dev/null differ diff --git a/docs/build/html/_images/storage-peak-capacity-determination.png b/docs/build/html/_images/storage-peak-capacity-determination.png deleted file mode 100644 index de5bbaff..00000000 Binary files a/docs/build/html/_images/storage-peak-capacity-determination.png and /dev/null differ diff --git a/docs/build/html/_images/sys-prop-win.png b/docs/build/html/_images/sys-prop-win.png deleted file mode 100644 index 95d087ee..00000000 Binary files a/docs/build/html/_images/sys-prop-win.png and /dev/null differ diff --git a/docs/build/html/_images/transfer-limits.png b/docs/build/html/_images/transfer-limits.png deleted file mode 100644 index 6396a501..00000000 Binary files a/docs/build/html/_images/transfer-limits.png and /dev/null differ diff --git a/docs/build/html/_images/transmission-cost-input-data.png b/docs/build/html/_images/transmission-cost-input-data.png deleted file mode 100644 index 973c653f..00000000 Binary files a/docs/build/html/_images/transmission-cost-input-data.png and /dev/null differ diff --git a/docs/build/html/_images/upv-resource-availability.png b/docs/build/html/_images/upv-resource-availability.png deleted file mode 100644 index 14ed1f8c..00000000 Binary files a/docs/build/html/_images/upv-resource-availability.png and /dev/null differ diff --git a/docs/build/html/_images/utility-scale-pv-costs.png b/docs/build/html/_images/utility-scale-pv-costs.png deleted file mode 100644 index ad40231e..00000000 Binary files a/docs/build/html/_images/utility-scale-pv-costs.png and /dev/null differ diff --git a/docs/build/html/_images/water-availability-and-cost.png b/docs/build/html/_images/water-availability-and-cost.png deleted file mode 100644 index 84c18b05..00000000 Binary files a/docs/build/html/_images/water-availability-and-cost.png and /dev/null differ diff --git a/docs/build/html/_images/yampa_add_machine.png b/docs/build/html/_images/yampa_add_machine.png deleted file mode 100644 index 7ef5c6bb..00000000 Binary files a/docs/build/html/_images/yampa_add_machine.png and /dev/null differ diff --git a/docs/build/html/_images/yampa_bashrc_file.png b/docs/build/html/_images/yampa_bashrc_file.png deleted file mode 100644 index e2c7d1e7..00000000 Binary files a/docs/build/html/_images/yampa_bashrc_file.png and /dev/null differ diff --git a/docs/build/html/_images/yampa_file_preferences.png b/docs/build/html/_images/yampa_file_preferences.png deleted file mode 100644 index 00479ac0..00000000 Binary files a/docs/build/html/_images/yampa_file_preferences.png and /dev/null differ diff --git a/docs/build/html/_images/zotero_citation_example.png b/docs/build/html/_images/zotero_citation_example.png deleted file mode 100644 index 013a6e93..00000000 Binary files a/docs/build/html/_images/zotero_citation_example.png and /dev/null differ diff --git a/docs/build/html/_sources/additional_model_information.md.txt b/docs/build/html/_sources/additional_model_information.md.txt deleted file mode 100644 index 5e4e664e..00000000 --- a/docs/build/html/_sources/additional_model_information.md.txt +++ /dev/null @@ -1,61 +0,0 @@ -#Additional Model Information -## Model Switches -```{eval-rst} -.. include:: ../../input_processing/README.md - :parser: myst_parser.sphinx_ -``` - -## Troubleshooting -This section provides guidance on identifying and resolving common issues encountered during model execution. By checking the locations and files listed below, users can better pinpoint errors. - -### Key Areas for Error Checking -* GAMS Log File - * Path: "/runs/{batch_prefix}_{case}/gamslog.txt" - * Purpose: contains the log outputs for all execution statements from the case batch file - * What to look for: - * 'ERROR': will provide more information into the specific file or line in the source code that failed or has an error - * 'LP status' and 'Status': can provide more insight into the model run - * 'Cur_year': can help you determine which year the model run failed in - -* GAMS Listing Files - * Path: "/runs//{batch_prefix}_{case}/lstfiles/" - * Purpose: contains the listing files for GAMS executions - * What to look for: - * '1_inputs.lst': errors will be preceded by '****' - * '{batch_prefix}_{case}_{year}i0.lst': there should be one file for each year of the model run - * 'Augur_errors_{year}': this file will appear in the event that there is an augur-related issue - -* GAMS Workfiles - * Path: "/runs/{batch_prefix}_{case}/g00files/" - * Purpose: stores a snapshot of all the model information available to GAMS at that point in the case execution. More information about GAMS work files can be found here: [https://www.gams.com/latest/docs/UG_SaveRestart.html](https://www.gams.com/latest/docs/UG_SaveRestart.html) - * What to look for: - * '{batch_prefix}_{case}_{last year run}i0.g00': should exist for the last year run - -* Output Directory - * Path: "/runs/{batch_prefix}_{case}/outputs/" - * Purpose: the outputs folder contains the generated output files from the model run - * What to look for: - * '*.csv' files: there should be many '.csv' files in this folder - * these files should contain data, an error message "GDX file not found" indicates an issue with the reporting script at the end of the model - * 'reeds-report/' and 'reeds-report-reduced/': if these folders are not present, it can indicate a problem with the post-processing scripts - -* Augur Data - * Path: "/runs/{batch_prefix}_{case}/ReEDS_Augur/augur_data/" - * What to look for: - * 'ReEDS_Augur_{year}.gdx': there should be a file for each year of the model run = - * 'reeds_data_{year}.gdx': there should be a file for each year of the model run - -* Case Inputs - * Path: "/runs/{batch_prefix}_{case}/inputs_case/" - * What to look for: - * '*.csv' files: there should be many '.csv' files in this folder, if there isn't, it could indicate a problem with the pre-processing scripts - * 'inputs.gdx': if this doesn't exist, it could indicate a problem with the pre-processing scripts - -### Re-running a Failed ReEDS Case -To re-run a failed case from the year it failed: -1. Comment out all the execution statements that completed successfully in "/runs/{batch_prefix}_{case}/call_{batch_prefix}_{case}.bat" (or *.sh file if on Mac) - * Shortcut for commenting multiple lines: Ctrl + '/' (Command + '/' if on Mac) - -2. Re-run "/runs/{batch_prefix}_{case}/call_{batch_prefix}_{case}.bat" - -Additionally, 'restart_runs.py' is a helper script that can be used to restart any failed runs. For more information on how to use this script, see the section on [Helper Scripts and Tools](postprocessing_tools.md#helper-scripts-and-tools). \ No newline at end of file diff --git a/docs/build/html/_sources/bokehpivot.md.txt b/docs/build/html/_sources/bokehpivot.md.txt deleted file mode 100644 index c5017078..00000000 --- a/docs/build/html/_sources/bokehpivot.md.txt +++ /dev/null @@ -1,10 +0,0 @@ ---- -orphan: true ---- - - - -```{include} ../../postprocessing/bokehpivot/README.md -``` \ No newline at end of file diff --git a/docs/build/html/_sources/documentation_tools/README.md.txt b/docs/build/html/_sources/documentation_tools/README.md.txt deleted file mode 100644 index 43d15343..00000000 --- a/docs/build/html/_sources/documentation_tools/README.md.txt +++ /dev/null @@ -1,15 +0,0 @@ -### How to Use Sources Documentation - -1. Before running the .bat script, please ensure the sources.csv file is closed. If open, the script will be unable to replace the file and will throw an error. -2. Run **generate_sources_md_file.bat** script (for Mac and Linux users **generate_sources_md_file.sh**)located within the documentation_tools folder (ReEDS-2.0/docs/source/documentation_tools). You will need navigate to that directory prior to running. -3. This will run the first script **generate_new_sources.py**. generating a new **sources.csv** file at the top directory of the repository, please note,the existing sources.csv in your Repository root will be renamed to sources_{timestamp}.csv format. This can be deleted manually if no longer required; or can be held on to if required for comparison. Tree change files are generated in the documentations_tools folder to indicate files not included in the prior sources file (**sources_files_added.csv**), files removed from the prior sources file (**sources_files_deleted.csv**), and files not included in the sources file because they aren't committed (**sources_untracked_files.csv**). These change files should not be committed and can be deleted when no longer needed. -4. Once this has finished running, please proceed to update relevant fields in the *sources.csv* file -5. Once relevant fields have been updated, please save sources.csv and close it. -6. Run **generate_markdown.bat** (for Mac and Linux users **generate_markdown.sh**)located within the documentation_tools folder. This will generate a README file *sources_documentation.md* with all the Source files and their details for the Repository by running the script **generate_markdown.py**. The markdown file will be generated in the ReEDS-2.0/docs/source/ location. -7. Commit and push the updated **sources.csv** and **sources_documenation.md** files. ---- - -#### How to Update Relevant Fields in sources.csv -1. Once prompted by the .bat script, open **sources.csv** (found at the Repository root). -2. Using the Added Files List, **sources_files_added.csv** (found within the documentation_tools folder) which displays all the input files added by the user, enter relevant details in corresponding columns of **sources.csv**. Fields that do not apply can be left blank. Do not add new columns to sources.csv without also updating the scripts to support the expanded fields. -3. Save the sources.csv and close the file. diff --git a/docs/build/html/_sources/faq.md.txt b/docs/build/html/_sources/faq.md.txt deleted file mode 100644 index 95900571..00000000 --- a/docs/build/html/_sources/faq.md.txt +++ /dev/null @@ -1,123 +0,0 @@ -# FAQ -## Table of Contents -- [FAQ](#faq) - - [Table of Contents](#table-of-contents) - - [How much are the GAMS licensing fees?](#how-much-are-the-gams-licensing-fees) - - [Is there a trial version of the GAMS license so that I can test ReEDS?](#is-there-a-trial-version-of-the-gams-license-so-that-i-can-test-reeds) - - [What computer hardware is necessary to run ReEDS?](#what-computer-hardware-is-necessary-to-run-reeds) - - [Can I configure a ReEDS case to run as an isolated interconnect?](#can-i-configure-a-reeds-case-to-run-as-an-isolated-interconnect) - - [Is there a way to reduce solve time?](#is-there-a-way-to-reduce-solve-time) - - [How often are updates made to ReEDS?](#how-often-are-updates-made-to-reeds) - - [What are the limitations, caveats, and known issues?](#what-are-the-limitations-caveats-and-known-issues) - - [Capabilities that don't currently work](#capabilities-that-dont-currently-work) - - [Assumptions](#assumptions) - - [Input data and processing](#input-data-and-processing) - - [Core optimization](#core-optimization) - - [Output processing](#output-processing) - - -### How much are the GAMS licensing fees? - -Please contact GAMS for more information. - - -### Is there a trial version of the GAMS license so that I can test ReEDS? - -We have created a reduced size version of the ReEDS model that has less than 5,000 rows and columns, and therefore should be compatible with the GAMS community license ([https://www.gams.com/try_gams/](https://www.gams.com/try_gams/) -- Please contact GAMS if you need additional information regarding the community license). You can run this reduced model version by using the cases_small.csv input file. This reduced model uses a smaller technology subset, smaller geographic extent, and simplifies several model constraints. - - -### What computer hardware is necessary to run ReEDS? - -Running ReEDS using the reference case (located in cases.csv) is feasible on a laptop with 32GB of RAM. However, for running ReEDS with enhanced features such as explicit H2 modeling, C02 networks, increased temporal/spatial resolution, etc., it is recommened to utlize a higher-performance workstation or High-Performance Computing (HPC) machine. - -National-scale ReEDS scenarios can be run on a laptop with 32GB of RAM. However, if you would like to run ReEDS with more detailed options (explicit H2 modeling, C02 networks, higher temporal/spatial resolution, etc.), it is recommended to use a higher-performance workstation or HPC. - - -### Can I configure a ReEDS case to run as an isolated interconnect? - -Yes, you can configure ReEDS as a single interconnect. Limiting the spatial extent may be beneficial for modeling more difficult instances. - -**WARNING!:** The default case configurations were designed for modeling the lower 48 United States. Therefore, the user should be aware of possible issues with executing an interconnect in isolation, including but not limited to the following: - -* Natural gas prices are based on either national or census division supply curves. The natural gas prices are computed as a function of the quantity consumed relative to a reference quantity. Consuming less than the reference quantity drives the price downward; consuming more drives the price upward. When modeling a single interconnection, the user should either modify the reference gas quantity to account for a smaller spatial extent or use fixed gas prices in every census division (i.e., case configuration option [GSw\_GasCurve](#SwOther) = 2). For example, if we execute ERCOT in isolation using census division supply curves, we may want to reduce the reference gas quantity for the West South Central (West_South_Central) census division which includes Texas, Oklahoma, Arkansas, and Louisiana. Or we could assume the gas price in the West_South_Central region is fixed. - -* Infeasibilities may arise in state-level constraints when only part of a state is represented in an interconnect. For example, the Western interconnection includes a small portion of Texas (El Paso). State-level constraints will be enforced for Texas, but El Paso may not be able to meet the requirement for all of Texas. - -* Certain constraints may not apply in every interconnect. Some examples include: - * California State RPS REC trading constraints only apply to the West - * CAIR and CSAPR only apply to certain states, so the emission limits may need to be adjusted - * RGGI only applies to a subset of states in the northeast - * California policies (e.g., SB32, California Storage Mandate) only apply to California - - -### Is there a way to reduce solve time? - -If you'd like to reduce the model solve time, consider making some of the following changes: -* `yearset_suffix = 4yr` or `yearset_suffix = 5yr` - * Solve in 4- or 5-year steps -* `GSw_OpRes = 0` - * Turn off operating reserves -* `GSw_MinLoading = 0` - * Turn off the sliding-window representation of minimum-generation limits -* `GSw_HourlyNumClusters = 25` (or lower) - * Reduce the number of representative periods -* `GSw_RegionResolution = aggreg` - * Aggregate the native 134 zones into fewer (larger) zones, with the amount of aggregation controlled by `GSw_HierarchyFile` - * `GSw_HierarchyFile = default`: 133 zones: merges p119 -> p122 (obeys state, interconnect, NERC, and FERC region boundaries) - * `GSw_HierarchyFile = agg1`: 126 zones: p119 -> p122; p49 -> p50; p124 -> p99; p19 -> p20; p44 -> p68; p120 -> p122; p29 -> p28; p71 -> p72 (obeys state, interconnect, NERC, and FERC region boundaries) - * `GSw_HierarchyFile = agg2`: 69 zones (obeys state, interconnect, NERC, and FERC region boundaries) - * `GSw_HierarchyFile = agg3`: 54 zones (obeys state boundaries) - - -### How often are updates made to ReEDS? - -Every year we target June 1 for the bulk of model changes to be completed, which allows us to meet the hard deadline for having a working, updated version of the model by June 30. We typically make minor updates to the model over the summer and tag a final version for that year in August or September. This version is then used to produce the Standard Scenarios and Cambium data products. - -Additionally, changes are made throughout the year and a new version is created and published roughly every month. You can find current and past ReEDS versions here: {{ '[ReEDS-2.0 Releases]({}/releases)'.format(base_github_url) }} - -If you would like to run ReEDS with a previous version, you can either download the source code directly or check out that version using the tag. - -To check out a previous version using its tag, you can run the following command from your command line or terminal (ensure you have the main branch of the repo checked out): -``` -git checkout tags/{version number} -``` - -Here is an example of what this would look like: -``` -git checkout tags/v2024.0.0 -``` - - -### What are the limitations, caveats, and known issues? - -ReEDS is a big model with lots of limitations and caveats. Many higher-level limitations are discussed in the [documentation](https://www.nrel.gov/docs/fy21osti/78195.pdf); more code-facing issues are listed here. - -**Note: The following limitations, caveats, and known issues are incomplete and will evolve as the model changes** - -#### Capabilities that don't currently work -- Climate impacts on hydropower (`GSw_ClimateHydro`), electricity demand (`Gsw_ClimateDemand`), and water cooling (`GSw_ClimateWater`) -- `endyear` beyond 2050 (processed in forecast.py) -- Demand flexibility via the `GSw_EFS_Flex` switch -- County-level runs for regions with Canadian imports/exports and stress-period PRM formulation (`GSw_PRM_CapCredit == 0) - -#### Assumptions -- Hydrogen production tax credit - - One of the requirements of the hydrogen production tax credit is that the generation capacity must be no more than 3 years older than the electrolyzer to satisfy the "incrementality" or "additionality" condition. - - To avoid comparing vintages of the generator and the electrolyzer and increasing computational intensity, we make a simplifying assumption that all new clean generators (2024 and onwards) satisfy the incrementality condition. - -#### Input data and processing -- copy_files.py - - copy_files.py currently copies data to a ReEDS run's inputs_case folder that might not be relevant to the run based on the run's configured switch settings (e.g. `upv_220AC-reference_ba.h5` is copied into the inputs_case folder even if PVB is turned off or GSw_PVB_ILR only contains '130' as value(s)). This leads to bloating of the inputs_case folder due to inclusion of data that is irrelevant to a given run, which could also be misleading for users. This issue can be solved by including a new column to the runfiles.csv that controls whether or not a given runfile is copied into inputs_case based on a corresponding switch setting. -- hourly_repperiods.py - - We use available-capacity-weighted average solar and wind profiles to select representative days, so we include lots of low-resource-quality sites that realistically probably wouldn't be built. We may obtain different representative days if we were to downselect to higher-quality sites, but before running ReEDS it's hard to say where the cutoff should be. So for now we stick with the available-capacity-weighted average across all sites. -- Move distpv capacity trajectory from "exogenous capacity" into "prescribed builds" - - Currently, distpv capacity prescriptions are captured in the the "exogenous capacity" construct which represents capacity remaining in year t for capacity that existed prior to the first solve year. The data in this construct should be monotonically decreasing over time to reflect retirements. However, the distpv capacity prescription is monotonically increasing. We should move distpv capacity prescriptions to the "prescriptive capacity" construct which represents the cumulative capacity installed in each year. - -#### Core optimization - -#### Output processing -- Land use - - Land-use calculations use a static map of current land types; we do not project changes in land type (e.g. urbanization, changes to forestry and agriculture practices, etc) when assessing the land types utilized by new wind and solar. -- Retail rates - - High-level limitations and caveats are discussed in [Brown et al 2022](https://www.nrel.gov/docs/fy22osti/78224.pdf) - - When using a 5-year model step (for example), the value of the PTC is evenly split over all 5 years in the step. We don't try to assess in which year within the step a capacity investment is made. diff --git a/docs/build/html/_sources/index.md.txt b/docs/build/html/_sources/index.md.txt deleted file mode 100644 index b34f5c89..00000000 --- a/docs/build/html/_sources/index.md.txt +++ /dev/null @@ -1,26 +0,0 @@ -% ReEDS documentation master file, created by -% sphinx-quickstart on Fri Jan 12 12:05:28 2024. -% You can adapt this file completely to your liking, but it should at least -% contain the root `toctree` directive. - -# Welcome to ReEDS's documentation! - -```{include} ../../README.md -``` - -```{toctree} -:caption: Contents -:hidden: - -setup -model_documentation -additional_model_information -sources -postprocessing_tools -faq -``` - - - \ No newline at end of file diff --git a/docs/build/html/_sources/internal/additional_setup.md.txt b/docs/build/html/_sources/internal/additional_setup.md.txt deleted file mode 100644 index 30cff669..00000000 --- a/docs/build/html/_sources/internal/additional_setup.md.txt +++ /dev/null @@ -1,302 +0,0 @@ -# Additional ReEDS Setup -## Yampa Guide -```{include} yampa_guide.md -``` - -## Cloud and HPC Environments -### Running ReEDS on HPC -This guide explains how to get ReEDS running on NREL's HPC platform Kestrel. -#### Prerequisites -If you are new to HPC environments, you may wish to first visit [NREL's HPC website](https://www.nrel.gov/hpc/index.html). There are also some [courses from the Computational Sciences Tutorial Team](https://teams.microsoft.com/l/entity/2a527703-1f6f-4559-a332-d8a7d288cd88/_djb2_msteams_prefix_1371960825?context=%7B%22channelId%22%3A%2219%3A6nLmPDt9QHQMEuLHVBaxfsitEZSGH6oXT6lyVauMvXY1%40thread.tacv2%22%7D&groupId=22ad3c7b-a45a-4880-b8b4-b70b989f1344&tenantId=a0f29d7e-28cd-4f54-8442-7885aee7c080) that might be useful. - -First, you will need a [user account](https://www.nrel.gov/hpc/user-accounts.html) on HPC. Then, you will need an [allocation](https://www.nrel.gov/hpc/resource-allocations.html). Your PI or mentor should tell you which allocation to use and add you to the relevant groups. - -After getting an account and allocation, there are a few different options for accessing the HPCs. Most users interact with the HPCs through a combination of [WinSCP](https://winscp.net/eng/index.php) and SSH with either GitBash or VSCode. - -You should now be able to [SSH into Kestrel](https://www.nrel.gov/hpc/system-connection.html) with the command: -``` -$ ssh username@kestrel.hpc.nrel.gov -``` - -You will be prompted to enter your password, you will need to use for HPC password here. - - -#### Setup -1. Load GAMS with the following commands: - * `module use /nopt/nrel/apps/software/gams/modulefiles` - * `module load gams/45.2.0` - -2. Set up your SSH key with NREL github: - * Copy the contents in `/home/[username]/.ssh/id_rsa.pub - * To print the contents of this file to the terminal, you can use the following command: `cat /home/[username]/.ssh/id_rsa.pub` - * Open [https://github.nrel.gov](https://github.nrel.gov) and open your account settings - * In the top right of the page, click on your git ID > Edit your Profile > SSH Keys > Add SSH Key - * Paste the copied contents of `id_rsa.pub` into the "Add an SSH Key" window - -3. Clone the repository - * ReEDS requires git-lfs to clone the repository. To install and load git-lfs, use the following commands: - * `source /nopt/nrel/apps/env.sh` - * `module load git` - * `module load git-lfs` - - * From the terminal that you connected to Kestrel with, run the following command to clone the ReEDS repo: `git clone git@github.nrel.gov:ReEDS/ReEDS-2.0.git` - * **Note:** some users have to run `git lfs pull` after this step as the hd5 files are incomplete - -4. Create the reeds2 environment - * From within your cloned repo, run the following commands: - * `module load anaconda3` - * `conda env create -f environment.yml` - * Creating the environment can take several hours on Kestrel. If you don't want to wait that long, An has been testing an alternative approach for creating the environment: - * Navigate to your project folder and stay there for the duration of these commands: `cd /projects/[project-name]/ReEDS-2.0` - * create your own miniconda which allows you to install libmamba (since we cannot alter the base environment on Kestrel): - ``` - curl -sL \ "https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh" > \ "Miniconda3.sh" - ``` - * find out where your envs are stored: `conda list` - * change the conda environment path to your miniconda file paths: - ``` - echo "export CONDA_ENVS_PATH=$SCRATCH/home/[username]/miniconda3/envs" >> ~/.bashrc - echo "export CONDA_ENVS_PATH=$SCRATCH/home/[username]/miniconda3/pkgs" >> ~/.bashrc - ``` - * install libmamba on the base environment miniconda env: - ``` - conda install -n base conda-libmamba-solver - conda config --set solver libmamba - ``` - * create the ReEDS environment: - ``` - module load anaconda3 - conda env create -f environment.yml - ``` - * finally, activate it: `conda activate reeds2` - -5. Add `REEDS_USE_SLURM=1` to your list of environment variables at `~/.bashrc`. The commands below give an example of how to do so using the ‘nano’ text editor in bash. - * Open the `~/.bashrc` file using nano: `nano ~/.bashrc` - * At the end of the file add the following two lines: - ``` - ## Indicate that ReEDS jobs should be submitted via SLURM - export REEDS_USE_SLURM=1 - ``` - * Write the file: `^o ⏎` - * Exit nano: `^x` - * Run the `.bashrc file` (only needs to be done once; later it will run whenever you start a bash session): `source ~/.bashrc` - -6. Create a `gamslice.txt` file in the root of your ReEDS directory with the following contents ( You can do this using nano by typing `nano gamslice.txt`, then paste in the license text): - - {{ '```\n {} \n```'.format(gamslice) }} - -7. Edit the `ReEDS-2.0/srun_template.sh` file in your local copy of the ReEDS repo. Fields indicated by curly braces {} must be changed; you can edit fields with brackets [] based on your preferences for the runs you’re submitting (be sure to remove the {} and [] brackets): - - ``` - #!/bin/bash - #SBATCH --account={your HPC allocation} - #SBATCH --time=[walltime for your run; e.g., 2-00:00:00 = 2 days] - #SBATCH --nodes=1 - #SBATCH --ntasks-per-node=1 - #SBATCH --mail-user={your email address} - #SBATCH --mail-type=[BEGIN,END,FAIL] - #SBATCH --mem=[172000] # RAM in MB - ### OPTIONAL next line if you want to redirect the slurm log file and keep your ReEDS root directly clean - # #SBATCH --output=/projects/{your HPC allocation}/logs/slurm-%j.out - - #load your default settings - . $HOME/.bashrc - ``` - -8. Edit the cplex.opt file to optimize performance on the HPC. - * If you’re running 1 task per node you can set threads = -1 to use all available cores for the job. (If you’re running a very large model, like hourly or individual sites, using all threads may lead to memory issues; in that case you may want to use 8 or 12.) - * You may want to remove reslim 50000, or set it to a higher value, to prevent long solve years from timing out - - -ReEDS should now be usable in from the command line using the python script `runbatch.py`. - -#### Running ReEDS -Run ReEDS using runbatch.py the same way you would on any machine. Slurm jobs will be submitted for each case in the specified cases file. To understand the differences from a normal run, read the `if hpc` code blocks in runbatch.py. - -#### Notes -##### Helpful shortcuts -The following commands can be added to your '~/.bashrc' file for your convenience. Please note, you should change 'your_alloc' to one of your own allocations, 'yourname' to your own HPC username, and the ReEDS directory to whatever path you've chosen for the repository. - -``` -## Format squeue output to include more information -alias squ='squeue -u yourname -o "%.10i %.15P %.65j %.2t %.10M %.6D %R"' -alias sq='squ; echo "running:" $(squ | grep " R" | wc -l) "| pending:" $(squ | grep " PD" | wc -l) "| total:" $(squ | grep ":" | wc -l)' - -## Switch to my main ReEDS project folder, activate ReEDS environment -alias reeds='cd /projects/your_alloc/github/ReEDS-2.0 && module load conda && module load gams && conda activate reeds2' - -## Get a specified number of hours on a node -sr () { srun -t "$1:00:00" -A your_alloc --pty "$SHELL"; } - -## Get memory and CPU usage for recently-completed jobs -alias sacc='sacct --format="JobID,JobName,Partition,AllocCPUS,STATE,Elapsed,CPUTime,AveCPU,TotalCPU,NCPUS,MaxRSS" | grep "JobID\|--\|batch"' -``` - -After saving your changes, you'll need to run the following command once more to save your changes: `source ~/.bashrc`. You can then switch to your ReEDS directory and activate conda, gams, and your python environment by just typing reeds on login node. - -**To be able to access the HPC without entering your password every time**, paste the contents of the `~/.ssh/id_ed25519.pub` file on your laptop into the `/.ssh/authorized_keys` file on the HPC. - -##### GAMS -In February 2023, there were some issues with getting access to the GAMS HPC group. The following is a workaround: - * run `newgrp gams` on the login node before submitting your job - * you'll be put in a new special shell, so you'll need to run `source activate reeds` even if you previously activated the reeds environment - * Note: it will be `source activate reeds` and not `conda activate reeds2` as usual - * you should now be able to submit your job using runbatch.py as usual - -##### Files and File Transfers -The supply curve data has been ported over to `projects/shared-projects-reeds/reeds/Supply_Curve_Data` for the time being, but the rev paths have not yet been updated so for now some features like `reeds_to_rev.py` won't work. - -If you need to transfer files between the HPC and your local machine, there are a few different options: - * For file transfers on Windows: - * WinSCP can be used to transfer files between a Windows machine and the HPC. Draco has WinSCP already installed. See [https://www.nrel.gov/hpc/winscp-file-transfer.html](https://www.nrel.gov/hpc/winscp-file-transfer.html) for information on using WinSCP to transfer files. - * For file transfers on Mac: - * FileZilla can be used to transfer files between a Mac and the HPC. You can download the FileZilla Client at [https://filezilla-project.org/](https://filezilla-project.org/). - * Host: '[username]@kestrel.hpc.nrel.gov' - * More information on how to use FileZilla can be found in the [Yampa guide](yampa_guide.md#transferring-data-from-yampa-to-your-machine). - * Using rsync: - * You can also use rsync to transfer files; an example of a rsync transfer command: - ``` - rsync -aOP --exclude=**/225*/ --exclude=**/cpx*/ --exclude=*.dat --exclude=*.pkl --exclude=*.g00 --include=[batch_prefix]** --exclude=* --modify-window=5 --ignore-existing [hpc_user_name]@kestrel.nrel.gov:[path_to_run_folder] [destination_path] - ``` - * Using Globus: - * If the above methods for file transfers don't work for you, another option is to use Globus - * For more information, see: [Globus File Transfer Services](https://www.nrel.gov/hpc/globus-file-transfer.html) - -You can also transfer individual files to your machine using VSCode by right-clicking a file and selecting "download." - -##### VSCode setup -[This guide](https://code.visualstudio.com/docs/remote/ssh) provides a good overview of how to log on to a remote machine with VSCode. - -To set up SSH keys so that you don't have to enter your password each time you log in (note: this works for mac; Windows should be similar but it hasn't been tested): - 1. Open a terminal on your computer (not the HPC!) and then type: - ``` - cd ~/.ssh - vim config - ``` - - 2. Inside the config file type the following: - ``` - Host - User - Hostname kl1.hpc.nrel.gov - ``` - - Windows users should also add the following: - ``` - MACs hmac-sha2-512 - ``` - - 3. Save the file, then generate RSA key in ~/.ssh: `ls ~/.ssh/id_rsa || ssh-keygen` [note: you can skip this step if you already have a key] - - 4. Lastly copy the key over to Kestrel: `ssh-copy-id ` (where nickname is whatever you've set for Kestrel in the config file above) - - -##### Git -The HPC now requires repositories to be cloned via SSH; if you have a repo that was cloned using HTTPS you may encounter issues configuring git. If you do want to preserve your cloned repository, you can update via the following: -1. `nano .git/config` -2. change `url: https://github.nrel.gov/ReEDS/ReEDS-2.0.git` to `url: git@github.nrel.gov:ReEDS/ReEDS-2.0.git` - -The HPC also has restrictions on the permissions for your github SSH key... you can change these to the correct settings via `chmod 600 ~/.ssh/id_rsa.pub` - -#### Troubleshooting -##### Running on the HPC's 'debug' partition -It can be helpful to kick off a test run on the HPC's `debug` partition before submitting a full set. The `debug` queue is limited to 1 hour and 2 nodes per user but a run will typically start running immediately. To submit a run to the `debug` queue make the following changes to the `ReEDS-2.0/srun_template.sh` file: -* Set the runtime to 1 hour: `#SBATCH --time=1:00:00` -* Add the following line: `#SBATCH --partition=debug` - -##### Restarting a run from a previous solve year -Failed runs can be restarted by adding a `--restart` flag to the runbatch.py call. The call should include the same cases file and batch name as the failed runs (e.g. `python runbatch.py -c [case] -b [batch] --restart`). The restart functionality picks up with the last GAMS restart file. Input files are not recopied. - -Alternately, an individual run can be restarted with the following steps: -1. Navigate to the directory with the run: `cd runs/[batch]_[case]` - -2. Copy the original call shell script to a new call shell script: `cp call_[batch]_[case].sh call_[batch]_[case]_redo.sh` - -3. Remove the lines in the new call shell script that have already successfully run. (This step is probably best done by opening the file with WinSCP and manually removing lines.) - -4. Open the sbatch shell script to edit: `nano [batch]_[case].sh` - -5. Insert the new call shell script where the original was: - - Original: - ``` - #SBATCH --job-name=[job name] - sh {your directory}/ReEDS-2.0/runs/[batch]_[case]/call_[batch]_[case].sh - ``` - New: - ``` - #SBATCH --job-name=[job name] - sh {your directory}/ReEDS-2.0/runs/[batch]_[case]/call_[batch]_[case]_redo.sh - ``` - -6. Save the sbash shell script - -7. Re-submit the run: `sbatch [batch]_[case].sh` - - -##### General HPC -Make sure you have enough available storage in the directory where you are running ReEDS; otherwise the run will fail. The user directories on the HPC are very small; in general it's best to run ReEDS in a project folder. - -* You can check the storage quota for your project, and whether you're over it, using the procedure described here: [https://www.nrel.gov/hpc/project-storage-quotas.html](https://www.nrel.gov/hpc/project-storage-quotas.html) - * Run `lfs project -d /projects/YOUR_PROJECT` to get your project id number - * Run `lfs quota -h -p YOUR_PROJECT_ID /projects/YOUR_PROJECT` to get your current usage and quota - - -##### Runs in a standby partition -Currently runs in a standby partition won't show up with squeue unless you flag the partition (e.g., `squeue -u [username] -p standard-stdby`) - - - -### Running ReEDS on AWS -To run ReEDS on AWS, you'll need to set up an account on Amazon Web Servies. Once you have done that, you will be able to run ReEDS on AWS's Elastic Compute Cloud (EC2), their virtual computation service. The goal here is to be able to flexibly scale computing power to the needs of the moment and to avoid bottlenecks presented by HPC downtime and limited server space. - -#### Requesting an allocation -First, somebody needs to request an allocation for a project. There's a regular allocation request period each spring for the upcoming fiscal year, but out-of-cycle (ad-hoc) allocation requests are also allowed through a similar process. Go to [CSC Cloud Portal](https://thesource.nrel.gov/cloud-computing) to read more. - -#### Getting an AWS account -Request an AWS account by emailing CSC.CloudHelp@nrel.gov and including the name of the cloud project your account will be associated with. (Cloud projects are similar to HPC allocations and use a keyword identifier, e.g. UberNodalReEDS.) - -You may also want to join the Cloud Computing User Group on Microsoft Teams—just ask in your initial email to be added. - -CSC, the cloud computing team, has a [CSC Cloud Portal](https://thesource.nrel.gov/cloud-computing) site on theSOURCE that contains lots of useful information. You should read through the information there on sizing, pricing, billing, etc. It's quite useful. - -#### Running ReEDS scenarios on AWS -To run ReEDS scenarios, we spin up at least one virtual machine—an "instance" in Amazon-speak—of AWS's EC2 service. Often, it makes sense to spin up multiple EC2 instances when you have multiple runs since costs scale nonlinearly as the size of your chosen EC2 machine increases in memory and CPU. For storage on hard disk, we create an Elastic Block Storage (EBS) drive and connect it to the EC2 instance. - -#### Launching your first instance -CSC has set up a template Amazon Machine Image (AMI) that specifies required information about the EC2 instance and security settings that have been approved by NREL's cybersecurity team. CSC will set up an AMI template and give you a link to it. - - - -## Hourly Resolution and Additional Setups - -### Hourly resolution quick-start guide - -If you'd like to run the model with hourly resolution, here is the minimal set of switches to change in cases.csv: -* `GSw_Hourly = 1` - * Turn on hourly resolution -* `GSw_Canada = 2` - * Turn on hourly resolution for Canadian imports/exports -* `GSw_AugurCurtailment = 0` - * Turn off the Augur calculation of curtailment -* `GSw_StorageArbitrageMult = 0` - * Turn off the Augur calculation of storage arbitrage value -* `GSw_Storage_in_Min = 0` - * Turn off the Augur calculation of storage charging -* `capcredit_szn_hours = 3` - * The current default hourly representation is 18 representative 5-day weeks. Each representative period is treated as a 'season' and is thus active in the planning-reserve margin constraint. In h17 ReEDS we set `capcredit_szn_hours = 10`, giving 40 total hours considered for planning reserves (the top 10 hours in each of the 4 quarterly seasons). 18 'seasons' with 10 hours each would give 180 hours, so we switch to 3 hours per 'season' (for 54 hours total). - -If you'd like the model to solve in less than 2 days, you can also make the following changes: -* `yearset_suffix = fiveyear` - * Solve in 5-year steps -* `GSw_OpRes = 0` - * Turn off operating reserves -* `GSw_MinLoading = 0` - * Turn off the sliding-window representation of minimum-generation limits -* `GSw_PVB = 0` - * Turn off PV-battery hybrids -* `GSw_calc_powfrac = 0` - * Turn off a post-processing calculation of power flows - -### Hourlize -Hourlize processes hourly resource and load data into ReEDS inputs. For more information on getting started with Hourlize, you can find more information here: [Using Hourlize](hourlize.md) \ No newline at end of file diff --git a/docs/build/html/_sources/internal/coding_standards_and_conventions.md.txt b/docs/build/html/_sources/internal/coding_standards_and_conventions.md.txt deleted file mode 100644 index c82c2c35..00000000 --- a/docs/build/html/_sources/internal/coding_standards_and_conventions.md.txt +++ /dev/null @@ -1,209 +0,0 @@ -## Coding Standards and Conventions -The following are naming, rounding, and coding conventions that should be followed when making changes to ReEDS. All new code contributed to the repo should follow these conventions. - -**Note:** Because these conventions were not written until after the model development began, you will notice that some of these conventions are violated in the current code base. The conventions are far from comprehensive. Our hope is that this light approach can help bring consistency to the model code without being burdensome to those writing the code. - - -### Naming, Rounding, and Coding Conventions -#### Naming Conventions -* File names (GAMS files, input files, output files) - * Folders are lower case - * Files are lower case with underscores separating words (atb_mid_wind_2018.csv) - * GAMS files are proceeded by a letter and underscore, with each letter representing a file category and letters in alpha-order of file execution whenever possible (a_write_data.gms). When there are multiple GAMS files in the same category, they should be numbered to show the order in which they are called (a1_write_data, a2_inputs, a3_inputs_demand) - * Output files start with a noun indicator for the general output category to make it easier to find (curt_marg rather than marg_curt, gen_ann rather than ann_gen) - -* Parameters - * Use lower case with underscores separating words - * Like the output files, the first word of parameters should be a noun indicator of the parameter type (curt_marg rather than marg_curt) - * Cost parameters should generally start with “cost” (e.g., cost_fom, cost_cap) - -* Variables - * Use capital letters (example: INV) - * Where possible, use the same naming for related variables (e.g., INV; INV_TRANS) - * The first indicator in a variable name should be a noun or noun abbreviation for the variable type or category - -* equations (model constraints) - * Begin with the prefix “eq_” - * Use all lower-case letters with underscores separating words (example: eq_reserve_margin) - -* switches - * Begin with the prefix “Sw_” - * Use descriptive names with upper camel case (e.g., Sw_ReserveMargin) - * For on/off switches, "OFF" = 0 and "ON" =1 - -* indices/sets - * Use lower case - * Use short rather than descriptive (e.g., “i” instead of “tech”) – preference for one or two letter names. - -* aliases - * Use the same alpha character as the original set followed by a number (example: alias(r,r2)) - -* subsets - * Use lowercase - * Use short but descriptive text - * example: conv(i) is the subset of technologies that are “conventional” - -* crosswalk sets - * Use the set names and separated by an underscore - * example: r_st(r,st) is the crosswalk between region “r” and state “st” - -* Choosing names for parameters and variables - * Names should be descriptive (e.g., “curt_marg” rather than “cm”) - * Shorter names are generally preferred (e.g., “curt_marg” rather than “curtailment_marginal”) - -#### Rounding Conventions -As a general rule, costs or prices should be rounded to two decimal places. All other parameters should be rounded to no more than 3 decimal places. - -**Note:** Some exceptions to this might exsist due to number scaling (e.g., emission rates) - -#### Coding Conventions -* Generally, each line in GAMS should be no longer than a standard page width (255 characters) - -* Declarations - * Blocks of declarations are preferred to individual line declarations - * Comments are required for each declaration - * Units should always be defined first (even if they are unitless) enclosed in "--" - * Example: cap_out(i,r,t) "--MW-- capacity by region" - * Comments need not be comprehensive - * CAP(i,v,r,t) "--MW-- capacity by technology i of vintage v in region r in year t" - * CAP(i,v,r,t) "--MW-- capacity by technology" - -* Ordering of indices - * The following indices should always appear first in the following order: (1)ortype (2)i (3)v (4)r (5)h - * The t (year) index should always be last - * Other sets should generally be ordered alphabetically, respecting the two conventions above - -* Qualifiers - * Enclosed with brackets “[]” - * No space between qualifiers - * example: $[qual1$qual2] - * Parenthesis should be used to make order of operations explicit - * Incorrect: $[not qual1 $not qual2] - * Correct: $[(not qual1)$(not qual2)] - * Operators “and”, “not”, and “or” should be lower case - -* Equations (this applies to pre- and post-processing; model constraints) - * Each term should begin with a plus (+) or minus (-) sign, even the first term - * Summations - * Summation arguments should be bookended with braces “{}” sum{…} - * The summation will generally be separated into three parts that will appear on three different lines, with the closing } lining up with the opening { - ``` - [+/-] sum{ ([indices]) $ [qualifiers] , - [parameter] * [variable] - } - ``` - ``` - + sum{(i,c,r,t)$[Qual1$Qual2 … $Qual3], - cv_avg(i,r,t) * CAP(i,c,r,t) - } - ``` - * For equations, sums should generally be split with terms on multiple lines. In some cases it will be more readable to leave the sum on one line (e.g., a short sum inside of a long sum). - * Each term of an equation should be separated by a new line; white space should be inserted between terms - * When reasonable, only one parameter should be multiplied by one variable - * for example, “heatrate [MBtu/MWh] * emissions rate of fuel [tons CO2/MBtu] * GENERATION [MWh]” should be “emissions rate of plant [tons CO2/MWh] * GENERATION [MWh]” - * this will help us limit numerical issues that result from the multiplication of two small numbers - * When multiplying parameters and variables, parameters should appear on the left and variables on the right - * Keep one space on either end of a mathematical operator (*, /, +, -). example: “curt_marg * GEN” rather than “curt_marg*GEN” - -* Do not use recursive calculations; new parameters should be created - * Example: “load = load * 1.053” should be written as “busbarload = enduseload * 1.053” - * This will create consistency between the units specified in the parameter declaration and the use of the parameter - -* Comments - * Do not use inline comments (comments proceeded by //). This helps to make it easier to find comments - * Do not use $ontext/$offtext except for headers at the beginning of files - * Include a space after the “*” to start a comment - * Do not use a comment to note an issue. Use GitHub to put the issue instead. - * Example: Don’t do this: - ``` - *!!!! this will need to be updated to the tophrs designation after the 8760 cv/curt method is implemented - ``` - -* Other - * GAMS functions such as sum, max, smax, etc. should use {}; Example: avg_outage(i) = sum{h,hours(h)*outage(i,h)} / 8760 ; - * When including the semicolon on the end of a line there should be a space between the semicolon and the last character of the line (see previous example) - * When using `/ /` for a parameter declaration, place the closing semicolon on the same line as the final slash: `/ ;` - * Sums outside of equations (e.g., in e_reports) need not be split over multiple lines if they do not exceed the line limit - * Do not use hard-coded numbers in equations or calculations. Values should be assigned to an appropriate parameter name that is subsequently used in the code. - * Large input data tables should be loaded from individual data files for each table, preferably in *.csv format. Large data tables should not be manually written into the code but can be written dynamically by scripts or inserted with a $include statement. - * Compile-time conditionals should always use a tag (period + tag name) to clearly define the relationships between compile-time conditional statements. Failure to do so hurts readability sometimes leads to compilation errors. Example: - ``` - $ifthen.switch1 Sw_One==A - Do Something - $elseif.switch1 Sw_One==B - Do Something - $else.switch1 Sw_One==C - Do Something - $endif.switch1 - ``` - - -### Input Conventions and Data Handling -#### Input Conventions -* Data read into b_inputs should already be filtered. E.g., if you are running ERCOT, only data for ERCOT should be included. - * We did not structure things this way when we first built ReEDS, and it might not be possible to always meet this recommendation without a large amount of work. This recommendation represents the vision we are working toward rather than a requirement. - * The same applies to scenarios. If there are multiple scenario options in a single file (e.g. inputs/carbonconstraints/co2_cap.csv), only the single scenario used in a model run should be copied to inputs_case and loaded in b_inputs.gms. - -* Input csv files that are written to inputs_case should have the same name as the GAMS parameter that reads that csv file. - * Example: trancap_init(r,rr,trtype) reads in trancap_init.csv - -* Parameters read into b_inputs should also include a header that has the set names and then units for the values. An asterisk is required to keep GAMS from reading the header and throwing an error. Example: - - ![image](https://github.nrel.gov/storage/user/284/files/a65d3fc7-99e2-40d2-8d57-bb9bcbab0fcf) - -* Parameters read into b_inputs should be surrounded by $offlisting and $onlisting so that they are not written to the .lst files. - * Example: - ``` - parameter ev_static_demand(r,allh,allt) "--MW-- static electricity load from EV charging by timeslice" - / - $offlisting - $ondelim - $include inputs_case%ds%ev_static_demand.csv - $offdelim - $onlisting - / ; - ``` - -* When a file read into b_inputs was created by an upstream script within the repository, include a note indicating which script created the file. - * Example: “* Written by hourly_process.py” - -* In general, parameter declarations (which are in long format) are preferred to table declarations. Table declarations are acceptable when the table format can significantly reduce the files size or when the format of the native data better matches the table format. - -* Files used as inputs for the repository are always placed in an appropriate location within the “inputs” folder. Input files are grouped topically. - -* When there are multiple input options for a given input, the input file name should be “{file}_{option}”. For example: - * battery_ATB_2022_moderate - * battery_ATB_2022_conservative - -* If preprocessing is needed to create the input file that is placed in the ReEDS repository, the preprocessing scripts or workbooks should be included in the ReEDS-2.0_Input_Processing repository ([https://github.nrel.gov/ReEDS/ReEDS-2.0_Input_Processing](https://github.nrel.gov/ReEDS/ReEDS-2.0_Input_Processing)). Raw data files should be placed in that repository if their file size permits. Otherwise, raw data files should be placed in \\nrelnas01\ReEDS\ _ReEDS Documentation. - -* Any scripts that preprocess data after a ReEDS run is started should be placed in the input_processing folder. - * Input processing scripts should start with a block of descriptive comments describing the purpose and methodology, and internal functions should use docstrings and liberal comments on functionality and assumptions. - -* Any costs read into b_inputs should already be in 2004$. Cost adjustments in preprocessing scripts should rely on the deflator.csv file rather than have hard-coded conversions. - -* In general, if inputs require calculations before they are ingested into b_inputs, those calculations should be done in Python rather than in GAMS. GAMS can be used for calculations where the GAMS syntax simplifies the calculation or where upstream dependencies make it challenging for the calculations to happen in Python preprocessing scripts. - -* In Python, file paths should be added using os.path.join() rather than writing out the filepath with slashes. - -* Data column headers should use the ReEDS set names when practical. For example, data that include regions should use “r” for the column name rather than “ba,” “reeds_ba,” or “region.” - -* Preprocessing scripts in input_processing should not change the working directory or use relative filepaths; absolute filepaths should be used wherever possible. - -#### Input Data -* In general, all inputs less than ~10 MB should be in .csv format. - * If the csv file would be larger than ~10 MB, then write it as a h5 file unless accessibility is especially important (e.g., the ReEDS_generator_database file needs to be easily accessible, so is kept as a csv file). - * In some cases .txt files may be used as inputs if their format is especially convenient for the application. -* Input files should be included in the repository when possible. - * Files too large to include in the repository or unnecessary for the repository (e.g., files used only for special circumstances, such as individual sites for wind and solar) should be included in the appropriate folder on nrelnas and can be copied to the local repository in the preprocessing steps. - * Files stored on nrelnas should have unique names that identify the version of the file and data. For example, you would use “special_input_data_2022_11_28” rather than “special_input_data.” - -* Add units to raw data files - * When adding a new raw data file, include units in the column name to avoid confusion - * As an example, look at '/inputs/plant_characteristics/conv_ATB_2023.csv' - * The data in the "capcost" column are in unit of k$/MW or $/kW, although the units are not labeled - * As a best practice, "capcost" should be named "capcost_usd.per.kw" to make units clear - -* Add comments to raw data files that represent GAMS subsets - * When adding a new raw data file that represents a GAMS subset, include column headers representing the GAMS set that each column's entries belong to, with the first column header being prepended by an asterisk (this allows GAMS to parse the first row of the .csv file as a comment) - * For an example, see '/inputs/sets/fuel2tech.csv' diff --git a/docs/build/html/_sources/internal/developer_best_practices.md.txt b/docs/build/html/_sources/internal/developer_best_practices.md.txt deleted file mode 100644 index 661638e5..00000000 --- a/docs/build/html/_sources/internal/developer_best_practices.md.txt +++ /dev/null @@ -1,15 +0,0 @@ -# Developer Resources -```{include} coding_standards_and_conventions.md -``` - -```{include} version_control_and_testing.md -``` - -```{include} documentation_guidelines.md -``` - -```{include} pull_request_best_practices.md -``` - -```{include} developer_tips.md -``` \ No newline at end of file diff --git a/docs/build/html/_sources/internal/developer_tips.md.txt b/docs/build/html/_sources/internal/developer_tips.md.txt deleted file mode 100644 index f9b05dee..00000000 --- a/docs/build/html/_sources/internal/developer_tips.md.txt +++ /dev/null @@ -1,80 +0,0 @@ -## ReEDS Development Tips -### Debugging Python Code -When working with python code, there are a couple of useful methods for debugging. The first is using the Python Interactive Window. - -Cells are denoted by `#%%`, and you can run the code in a given file by cells in the interactive window. This allows you to view data and variables, as well as create graphs and visuals. This can be very helpful in stepping through a script to see what is happening in your code. - -For more information, see the [Python Interactive Window documentation](https://code.visualstudio.com/docs/python/jupyter-support-py#:~:text=For%20the%20whole%20notebook%2C%20open,the%20code%20in%20that%20cell.). - -Another way to debug is to use the Python Debugger Extension in VS Code. For more information on how to set up and use the python debugger, see [Python debugging in VS Code](https://code.visualstudio.com/docs/python/debugging). - -When using the python debugger, you will need to set a configuration. Here's an example of what that might look like (`launch.json` file): - -``` -{ - // Use IntelliSense to learn about possible attributes. - // Hover to view descriptions of existing attributes. - // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 - "version": "0.2.0", - "configurations": [ - { - "name": "Python Debugger: calc_financial_inputs.py with arguments", - "type": "debugpy", - "request": "launch", - "program": "${file}", - "console": "integratedTerminal", - "args": [ - "/Users/kminderm/ReEDS-2.0", - "/Users/kminderm/ReEDS-2.0/runs/main_Pacific/inputs_case" - ], - "purpose": ["debug-in-terminal"] - }, - - ] -} -``` - -For more on debugging, you can watch the following video: [GPAC's WEI Tips and Tricks Series: Introduction to Debugging](https://nrel.sharepoint.com/:v:/s/6A90-GridPlanningandAnalysisCenterGPAC/ERsyIuWezH1Mix2ZoGiGJk4B3S8u0KNqsIDG6QVbPQK3rw?e=FhUWGx&nav=eyJyZWZlcnJhbEluZm8iOnsicmVmZXJyYWxBcHAiOiJTdHJlYW1XZWJBcHAiLCJyZWZlcnJhbFZpZXciOiJTaGFyZURpYWxvZy1MaW5rIiwicmVmZXJyYWxBcHBQbGF0Zm9ybSI6IldlYiIsInJlZmVycmFsTW9kZSI6InZpZXcifX0%3D) - - -### Debugging GAMS Code -When making changes to the GAMS code, something that can be helpful when debugging an issue is to compare the data before and after your change. You can do that by inserting an 'execute unload' statement into the gams code. Example of what this looks like: - -``` -execute_unload 'before.gdx' ; -``` - -If you're interested in only a specific variable, you can specify it like this: -``` -execute_unload 'before.gdx' valcap ; -``` - -Additionally, if you want to re-run a given scenario without having to run all of the input processing again, you can open the `call_{batch name}_{case}.bat/.sh` file, delete all of the lines you don't want to run again, and then run that file from the command line. **Note: be sure to edit/run the `call_{batch name}_{case}.bat/.sh` file from within the specific run folder** - - - -### Additional Development Tips -* To avoid the prompts when kicking off a run, you can use the command line arguments: - * The following example runs the scenarios in cases_test.csv with the batch name '20240717_test'. The '-r -1' means that all cases will run simultaneously. - ``` - python runbatch.py -c test -b 20240717_test -r -1 - ``` - * All options for command line arguments that can be used: - | Flag | | - | --- | --- | - | `--BatchName` / `-b` | Name for batch of runs | - | `--cases_suffix` / `-c` | Suffix for cases CSV file | - | `--single` / `-s` | Name of a single case to run (or comma-delimited list) | - | `--simult_runs` / `-r` | Number of simultaneous runs. If negative, run all simultaneously | - | `--forcelocal` / `-l` | Force model to run locally instead of submitting a slurm job | - | `--restart` / `-r` | Switch to restart existing ReEDS runs | - | `--skip_checks` / `-f` | Force run, skipping checks on conda environment and switches | - | `--debug` / `-d` | Run in debug mode (same behavior as debug switch in cases.csv) | - | `--debugnode` / `-n` | Run using debug specifications for slurm on an hpc system | - - - - -* If you're on Mac and would like to have the terminal always show what branch you're on, you can set up Git Bash for Mac with the following: [Git Bash for Mac](https://github.com/fabriziocucci/git-bash-for-mac) - -* Using the following run name format keeps your runs folder organized: 'vYYYYMMDD' \ No newline at end of file diff --git a/docs/build/html/_sources/internal/documentation_guidelines.md.txt b/docs/build/html/_sources/internal/documentation_guidelines.md.txt deleted file mode 100644 index c0f48105..00000000 --- a/docs/build/html/_sources/internal/documentation_guidelines.md.txt +++ /dev/null @@ -1,40 +0,0 @@ - -## Documentation Guidelines -When making changes to ReEDS, you should generate and update the sources.csv and sources_documentation.md files before merging. - -```{include} ../documentation_tools/README.md -``` - -### Updating the ReEDS Documentation -Additionally, the general ReEDS documentation lives in the "docs/source" folder within the repo. Depending on the changes you're making to the model, please update the documentation here accordingly. - -To edit the ReEDS documentation: -1. Find the markdown file you would like to modify under the "docs/source" folder -2. Make any necessary changes and save the file -3. Commit and push your changes as you normally would. - * **When your pull request gets merged into main, there is a github action that will automatically recompile the documentation with your changes and publish the updated site.** - -If you would like to see what the documentation will look like when developing locally, you can do that with the following process: -1. Navigate to the "docs/" folder - -2. Run the command `make html` to build the documentation locally - * Ensure you have the 'reeds2' environment activated - -3. From Finder/File Explorer, open the folder "/ReEDS-2.0/docs/build/html" then click on "index.html" - * This will launch the documentation in a new internet window - * If you make changes and wish to see how they are reflected in the documentation, you can run the `make html` command again and refresh the window you already have open - -4. If you would like to remove the generated files, you can run the command `make clean` from the "docs/" folder - -### Adding Citations in the Documentation -To add an in-text citation, find the citation key of the citation you would like to add in Zotero. The format to include an in-text citation in markdown is as follows: -* Regular citation: ``` {cite}`citation key` ``` -* Citation with just the year: ``` {cite:year}`citation key` ``` -* Multiple citations: ``` {cite:p}`citation key 1, citation key 2` ``` - -```{figure} ../../../images/zotero_citation_example.png - -Example of citation key in Zotero -``` - -Alternatively, you can use the "Zotero Citation Picker" VS Code extension for finding/adding references to the documentation. This extension requires Zotero to be installed, as well as Better BibTex for Zotero (the Better BibTex for Zotero installation guide can be found [here](https://retorque.re/zotero-better-bibtex/installation/)). diff --git a/docs/build/html/_sources/internal/hourlize.md.txt b/docs/build/html/_sources/internal/hourlize.md.txt deleted file mode 100644 index c799e971..00000000 --- a/docs/build/html/_sources/internal/hourlize.md.txt +++ /dev/null @@ -1,11 +0,0 @@ ---- -orphan: true ---- -## Using Hourlize - -```{eval-rst} -.. include:: ../../../hourlize/README.md - :parser: myst_parser.sphinx_ -``` - -For additional information on using Hourlize, you can watch the training video: [Hourlize wind/solar resource preprocessing tutorial](https://nrel-my.sharepoint.com/:v:/r/personal/bsergi_nrel_gov/Documents/Misc/Recordings/Hourlize%20wind_solar%20resource%20preprocessing%20tutorial-20240212_150245-Meeting%20Recording.mp4?csf=1&web=1&e=vIds6r&nav=eyJyZWZlcnJhbEluZm8iOnsicmVmZXJyYWxBcHAiOiJTdHJlYW1XZWJBcHAiLCJyZWZlcnJhbFZpZXciOiJTaGFyZURpYWxvZy1MaW5rIiwicmVmZXJyYWxBcHBQbGF0Zm9ybSI6IldlYiIsInJlZmVycmFsTW9kZSI6InZpZXcifX0%3D) diff --git a/docs/build/html/_sources/internal/onboarding.md.txt b/docs/build/html/_sources/internal/onboarding.md.txt deleted file mode 100644 index 808df032..00000000 --- a/docs/build/html/_sources/internal/onboarding.md.txt +++ /dev/null @@ -1,151 +0,0 @@ -# Onboarding Guide -Welcome to the team! - -New ReEDS team members should go over this guide to get set up with ReEDS. This onboarding guide is designed to be walked through independently, but please don't hesitate to reach out to your PI if you run into issues or have questions. - -## General NREL Setup -### Software Setup -You'll need to get the following software installed by IT: - * Anaconda ([https://www.anaconda.com/download](https://www.anaconda.com/download)) - * VS Code ([https://code.visualstudio.com/download](https://code.visualstudio.com/download)) - * GitHub Desktop ([https://desktop.github.com](https://desktop.github.com)) - * GAMS ([https://www.gams.com/download/](https://www.gams.com/download/)) - IT might ask you if you want to purchase a license or for a charge code. This is NOT needed. We already have a license, IT just needs to install the software. - * Git Bash - * Git ([https://git-scm.com/downloads](https://git-scm.com/downloads)) - -To get software installed, you should follow this process to submit IT tickets: - 1. Go to the [IT Services Site](https://nrel.servicenowservices.com/sp) - 2. Click on 'Get Help' - * Assistance Type: 'Order or install something new' - * Give them the website to the software that you need - -IT will reply to your ticket when they are ready to install it. Typically, then you give them a call and they will take over your computer and install it. - - -### GitHub Setup -NREL uses both github.com and github.nrel.gov (where ReEDS is). You will need both so please make accounts for both using your NREL email address. - -If you're unfamiliar with Git, you should start learning more about it. The following resources might be helpful: - * [Git and GitHub Introduction](https://www.w3schools.com/git/git_intro.asp?remote=github) - * [Computational Sciences Tutorials: Intro to Git](https://nrel-my.sharepoint.com/personal/eharrell_nrel_gov/_layouts/15/stream.aspx?id=%2Fpersonal%2Feharrell%5Fnrel%5Fgov%2FDocuments%2FRecordings%2FESIF%5F%20Intro%20to%20Git%2Emp4&referrer=StreamWebApp%2EWeb&referrerScenario=AddressBarCopied%2Eview) - * [Git cheat sheet](https://nrel.sharepoint.com/:w:/s/ReEDS/EVMrQkD6191Mgh40ha4e1U4Bu-HO-Z_Mkh4x5Y7TvfYmig?e=FLzB7g) - -Additionally, Visual Studio Code has integrated source control management, allowing you to connect with GitHub directly from within the editor. For more information on how to do this, please refer to the following guide: [Using Git source control in VS Code](https://code.visualstudio.com/docs/sourcecontrol/overview). - -### Mapping a Network Drive -**On a Mac:** - 1. Open up Finder - 2. Command + K - 3. Type in 'smb://nrelnas01/reeds' - 4. You are now connected! - -Make a folder in the drive that reflects your project work. Preffered format is "FYXX-{project}-{your initials}" - -**On a PC:** - 1. Start on your local computer -> go to 'This PC', right click and select 'Map network drive' - - 2. Chose whatever letter (it doesn't matter which one) you want as your drive name, then type '\\\\\nrelnas01\reeds' into the Folder. Press Finish. - -Make a folder in the drive that reflects your project work. Preffered format is "FYXX-{project}-{your initials}" - -### Additional Items -The following items should be talked about with your PI: - * How to schedule a meeting in Teams - * How to book an on-campus room - -You should also review the [GPAC Technical Guide](https://nrel.sharepoint.com/:w:/s/6A90-GridPlanningandAnalysisCenterGPAC/Ec_7fHBAnfBFh6A3aJodJuoBwJwHoKpZy5hzupG03NKHmQ?e=rrOMXO). - - -## ReEDS Specific Setup & Learning -Prior to getting ReEDS set up and running, you'll want to ensure you have access to the [ReEDS repo](https://github.nrel.gov/ReEDS/ReEDS-2.0). If you do not have access, reach out to your PI to get added to the repository. - -### ReEDS Training Videos -NREL has a youtube channel that contains tutorial videos for ReEDS. The following are recommended videos for getting started with ReEDS: - * Overview of ReEDS: - * [Introduction to the ReEDS Model: 2023 Version](https://www.youtube.com/watch?v=6SNxMWoBVr0&list=PLmIn8Hncs7bG558qNlmz2QbKhsv7QCKiC&index=11) - * [Powered by ReEDS](https://www.youtube.com/watch?v=qLHdWh3uoHk) - * Getting started with ReEDS: [2023 ReEDS Training for User Group Meeting](https://www.youtube.com/watch?v=tDLwqH6YZ_E&list=PLmIn8Hncs7bG558qNlmz2QbKhsv7QCKiC&index=12) - * How to change inputs: [Training on Changing and Adding Inputs](https://www.youtube.com/watch?v=QxwEs0ZC5ns&list=PLmIn8Hncs7bG558qNlmz2QbKhsv7QCKiC&index=9) - * Debugging of ReEDS: [Training on Debugging ReEDS](https://www.youtube.com/watch?v=4I0V5F8fzDU&list=PLmIn8Hncs7bG558qNlmz2QbKhsv7QCKiC&index=8) - -**Note: if you have further questions after watching these videos, please follow up with your PI** - -### Getting ReEDS Running Locally -After watching the youtube trainings, you should have a better sense of how ReEDS works and how to use it. - -To get ReEDS running on your local machine, follow the [setup guide](../setup.md). If you have questions, or run into issues with setup, please reach out to your PI. - -Finally, now that you have ReEDS setup, you can run default ReEDS by walking through the following steps: - 1. Open a new command line or terminal - 2. Activate the ReEDS conda environment (can be doine with this command: `conda activate reeds2`) - 3. Run runbatch.py (with the command: `python runbatch.py`) - * Enter the batch prefix (or batch name) - * Enter the case suffix - this will specify which scenario(s) should be run. You can leave this blank to use the default (cases.csv). - -**How do you make sure your ReEDS run was successful?** - * Are there outputs? - * Check in the '/runs/[specific run name]/outputs' folder, are there csv files? If not, something went wrong with the run. - * Did the ReEDS reports build? - * Check in the '/runs/[specific run name]/outputs' folder, are are subfolders named 'reeds-report' and 'reeds-report-reduced'? - - -**Additional ReEDS Scenarios:** -After running default ReEDS, you should take a look at some of the other common scenarios: - * Cases_test: contains some basic test scenarios for ReEDS - * Cases_standardscenarios: contains the scenarios used for the Standard Scenarios report that is released yearly. - - -### Getting ReEDS Running on Yampa -Some ReEDS runs are large and take a decent amount of memory to run. The remote machines have significantly more memory and are often used for this purpose. - -To get started with Yampa, you'll have to get access. To do so, you can follow this guide: [Yampa Guide - Getting Access to Machines](yampa_guide.md#getting-access-to-machines) - -After you have access, you can continue with the [Yampa Guide](yampa_guide.md#getting-started) to get ReEDS set up and running on the remote machines. - - -### Additional Setup -#### Additional Software -There is other standard software available in the "Ivanti Portal Manager" if you would like to download them. - * On a PC, find the Portal Manager in the Windows Start menu under 'Ivanti'. - * On a Mac, go to Applications and then click 'Portal Manager' - -#### Running ReEDS on the HPC -In additional to running locally and on Yampa, you can also run ReEDS on the HPC. Instructions for getting started with the HPC can be found here: [Advanced Setup - Running ReEDS on HPC](advanced_setup.md#running-reeds-on-hpc) - -#### VS Code Extensions -The following extensions can be added to VS Code to make it easier to work with the ReEDS code: - * Edit CSV (let's you edit CSV files outside of Excel) - * Rainbow CSV (makes it easier to see columns when viewing CSV files in VS Code) - * gms (gams syntax highlighter that gives meaningful formatting when viewing gams code) - * Remote - SSH (lets you connect to Kestrel from VS Code) - * Git focused extensions: - * GitHub Pull Requests - * GitLens - * GitLens - Git supercharged - * Git History - * Git Graph - * Ruff (python linter that looks at your code and tells you surface level errors or formatting issues) - * H5Web (opens h5 files so you can inspect them from within VS Code) - * Conflict Squeezer (helpful for managing merge conflicts) - * Indent-rainbow (colors the vertical indent lines in code, making it easier to follow) - * Python - * Diff Folders (used to compare two folders in VS Code) - * vscode-copy-github-permalink - * gms (for GAMS syntax formatting) - * Zotero Citation Picker - -In order to improve bracket formatting in GAMS, you can copy "lolow.gams-0.0.1" from \\nrelnas01\ReEDS\Users\pbrown\lolow.gams-0.0.1 into your vscode extensions folder. Simply unzip this folder into C:\Users\\[username]\\.vscode\extensions. - -#### Set Up SSH Key -In order to make commits to ReEDS, you will have to set up an SSH key. To do so, follow the [SSH Key Setup](ssh_setup.md) guide. - -## Additional Resources & Learning -* [Optional ReEDS Training Homework](reeds_training_homework.md) -* [General information on ReEDS](https://www.nrel.gov/analysis/reeds/) -* [ReEDS POC list](https://nrel.sharepoint.com/:w:/s/ReEDS/ES6GQTyzXo1DnnCPlnAhg5QB8cPY--_01HkQkiOnrPskxw?e=flEAtY) -* [GitHub README](https://github.nrel.gov/ReEDS/ReEDS-2.0/blob/main/README.md) -* [YouTube tutorials](https://www.youtube.com/playlist?list=PLmIn8Hncs7bG558qNlmz2QbKhsv7QCKiC) -* [GAMS language information](https://www.gams.com/latest/docs/UG_MAIN.html#UG_Language_Environment) -* [Advanced ReEDS setup](advanced_setup.md) -* [Tips and tricks for the bash shell](https://nrel-my.sharepoint.com/:p:/r/personal/ssundar_nrel_gov/Documents/Microsoft%20Teams%20Chat%20Files/02062024_what_the_shell.pptx?d=wa7aea3514f814d51924bf2dfa737d414&csf=1&web=1&e=qr1YuP) -* [ReEDS Development Tips and Best Practices](https://nrel-my.sharepoint.com/:v:/g/personal/kminderm_nrel_gov/EYbKIRBxQMJAlGVjQ5cI8LoBaaVKLD3NRPhWucwmUtIQ0w?e=SV0pvK&nav=eyJyZWZlcnJhbEluZm8iOnsicmVmZXJyYWxBcHAiOiJTdHJlYW1XZWJBcHAiLCJyZWZlcnJhbFZpZXciOiJTaGFyZURpYWxvZy1MaW5rIiwicmVmZXJyYWxBcHBQbGF0Zm9ybSI6IldlYiIsInJlZmVycmFsTW9kZSI6InZpZXcifX0%3D) \ No newline at end of file diff --git a/docs/build/html/_sources/internal/pull_request_best_practices.md.txt b/docs/build/html/_sources/internal/pull_request_best_practices.md.txt deleted file mode 100644 index 67725c45..00000000 --- a/docs/build/html/_sources/internal/pull_request_best_practices.md.txt +++ /dev/null @@ -1,83 +0,0 @@ -## Pull Request Best Practices -### Best Practices for Creating PRs -To ensure a smooth process and maintain quality of the ReEDS model, the following are best practices that should be followed when creating a pull request: -* Prior to creating a pull request, perform the appropriate level of testing on your branch - * The Full U.S. test (in cases.csv) will be used in most cases - * For more information on testing, see the [Testing Guidlines section](#testing-guidelines) - -* Ensure the title of your pull request is both descriptive and concise - * This is crucial, as the title of your pull request will be used in the summary of changes for each new version of ReEDS - -* Fill out the pull request template in detail - * The description should be clear enough for someone not directly involved in your work to grasp the changes being proposed - * Assign and contact reviewers - * Best practice is to have 2 reviewers from the ReEDS team - -* Keep your pull request in draft mode until it is ready to be merged into the main branch, indicating to reviewers that it is still a work in progresss - -* Provide a charge code to your reviewers for their time spent reviewing - -* Create smaller pull requests more frequently when possible - * This helps avoid merge conflicts and simplifies the review process, making it more manageable for reviewers - -* After creating the pull request, monitor the status of the automated tests - * This runs the R2X test automatically - -* Prior to merging your pull request, make sure to update the relevant documentation to reflect your changes. There are two places that should be updated (more information on this can be found in the [documentation guidelines](#documentation-guidelines)): - 1. Sources_documentation - 2. The 'docs/' folder within the repository - -### Resolving Merge Conflicts -Sometimes you might run into merge conflicts when trying to merge your branch into another branch. Merge conflicts happen when there are competing commits that Git needs you to help decide which changes should be kept in the final merge. - -Merge conflicts must be resolved prior to merging a pull request and there are different ways to handle merge conflicts: - * Simple merge conflicts can be resolved on GitHub. To learn more about how to do this, refer to GitHub's documentation on [Resolving merge conflicts on GitHub](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github) - - * Larger or more complex merge conflicts will need to be resolved using the command line and a text editor (e.g., VSCode). To learn more about how to do this, refer to GitHub's documentation on [Resolving merge conflicts using the command line](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line) - -### Tips and Best Practices for PR Reviews -The following are best practices that should be considered when reviewing pull requests: -1. Understand the context of the pull request - * Prior to reviewing any code changes, read the PR thoroughly - * Is the title descriptive? - * Does the summary accurately state what the PR is trying to accomplish? - * Is there sufficient information in the pull request to accurately convey the changes being made? Because the PR is documenting the change, part of your review entails ensuring that the model changes are properly reflected in the PR text. - * What is the high-level impact of this PR? Can you summarize the change on the run results in 1-2 sentences? - * Look at any linked issues or pull requests and understand what is being fixed in this pull request and which issues or incompatibilities are not being addressed. - -2. Look at the compare report and any other figures included in the PR - * Do you understand why these code/file changes resulted in these results? - * What is the high-level impact of this PR? Can you summarize the change on the run results in 1-2 sentences? - * Are these changes explainable/justifiable to both our internal and external audiences? - -3. Review the code - * Look at each file that has changed - * Do code changes or new code added make sense? - * Ensure newly added code is documented (even if it's just a single-line comment) - * Flag any instances where you notice that the code does not follow the [Coding Conventions](#coding-conventions) - * Identify if/how these code changes could cause problems later. - * What other parts of the model do these changes interact with? Is that interaction broken or no longer an accurate representation with these changes? - * What could break if we ran different scenarios with these changes? We typically look at the impact of our changes on "main" or "Standard Scenarios Mid-Case" type runs but also consider the potential impact on decarbonization scenarios, county level runs, smaller region runs, scenarios with hydrogen enabled, etc. We want to foresee any possible impacts this might have. If you have a concern or are curious about how this change might impact a certain type of run, ask the PR author, they might have looked at similar scenarios. - -4. Look at any input files that have changed - * Reviewing the commit history can sometimes be helpful in determining what has changed - * Do the input changes make sense? Are they consistent with the PR descriptions? - * There are a couple tools that help with comparing two different csv files: - * [VSCode diff panel](https://vscode.one/diff-vscode/) - * [csvdiff](https://pypi.org/project/csvdiff/#:~:text=csvdiff%20allows%20you%20to%20compare,look%20at%20just%20what's%20changed.) - -5. Check out the branch locally (optional) - * You should check the branch out locally and run the test scenario(cases_test.csv) to ensure there are no issues - * If there are a large amount of changes to one of the scripts or code files (ex. input_processing scripts or GAMS files), it could be helpful to run just that script and walk through it line by line with a debugging tool (ex. [pdb](https://docs.python.org/3/library/pdb.html)) to more deeply understand how the revised script functions and any issues we might face with the way that script is now written. - -**A few notes on reviewing pull requests:** - * When reviewing PRs, be sure to provide constructive feedback and highlight positive aspects as well. Reviewing PRs is an opportunity to learn from one another and support each other's development as developers! - * Ask clarifying questions if something is unclear - * Reviewing PRs can be daunting if you are new to the team or to the code development process. Remember that this is an opportunity for you to learn more about the model as much as it is about getting the code changes integrated into the model. Even experienced developers make errors, hence the importance of getting a second set of eyes on the code changes. Your input and insights are valuable. - * If you don't understand what is going on with a code change, chances are high that others won't understand either, so ask for clarification, including asking for more comments or explanation in the PR text. - * If there is a section of the PR that you don't feel comfortable reviewing, you should request a review from another team member - * Request changes as necessary and explain your reasoning - * Remember that the PR submitter is ultimately responsible for the changes in the PR, not you, so give the PR review a good effort, but don't agonize over every detail. - * If reviewing a PR becomes too large of a chore, feel free to reach out to others on the team to be able to tackle the PR review jointly - * If necessary, make sure the [ReEDS documentation](https://pages.github.nrel.gov/ReEDS/ReEDS-2.0/index.html) was updated to reflect the code changes - * Instructions for how to update the documentation can be found [here](#updating-the-reeds-documentation) diff --git a/docs/build/html/_sources/internal/reeds_training_homework.md.txt b/docs/build/html/_sources/internal/reeds_training_homework.md.txt deleted file mode 100644 index 3f6fa273..00000000 --- a/docs/build/html/_sources/internal/reeds_training_homework.md.txt +++ /dev/null @@ -1,80 +0,0 @@ ---- -orphan: true ---- -### Task 1: Perform a ReEDS run with the default settings in ERCOT at the BA and county resolutions -#### Run the model -1. Create your own branch off main and name it XX_homework where XX are your initials - -2. Navigate to the folder where the repo has been cloned on your local machine - -3. Open the cases_spatialflex.csv file - -4. Change the 'ignore' row value to be 1 for all columns except ERCOT_county which you can either set to 0 or leave blank - -5. Add a new column with 'ERCOT_BA' in row 1. - - Copy the contents of rows 2-6 from the ERCOT_county column - - Replace 'county' with 'ba' in row 5 (GWs_RegionResolution) - - Save cases_spatialflex.csv in the ReEDS-2.0 folder (you can overwrite the existing file) - -6. Open VS Code - - Open the folder where your repo is located (File -> Open Folder -> navigate to ReEDS-2.0 folder) - - Open a new terminal and activate the reeds2 environment - -7. Start a new run - - `python runbatch.py` - - when prompted for case file name, enter 'spatialflex' - - when prompted for how many simultaneous runs you would like to execute, enter 2 - - The 'ERCOT_county' and 'ERCOT_BA' runs should start - - -#### Review the results -1. Navigate to 'ReEDS-2.0/runs/{your run name}/outputs/reeds-report' and open 'report.html' -2. Learn to create your own plots of the results using bokehpivot - - See [Bokeh Pivot](../postprocessing_tools.md#bokehpivot) - -#### Create an informal slide deck -Create an informal slide deck with the following results: - - Stacked bar chart of total installed capacity in 2030 - - Include a stacked bar chart of the differences - - Stacked bar chart of total installed firm capacity in 2030 - - Stacked bar chat of generation in all modeled years - - Stacked bar chart of total system costs discounted - - Plots of the locational capacity build out by technology (maps of where capacity is located) - - Plots of the curtailment rates - - -### Task 2: Perform a ReEDS run with enforced decarbonization at the BA resolution in the Western Interconnection. -#### Run the model -1. Ensure you are on your XX_homework branch, then navigate to the folder where the repo has been cloned on your local machine - -2. Open the cases_spatialflex.csv file - -3. Add a new column with 'Western_BA_Decarb' in row 1 - - Copy the contents of rows 2-6 from the ERCOT_county column - - Replace 'county' with 'ba' in row 5 (GSw_RegionResolution) - - Replace 'ercot' with 'western' in row 4 (GSw_Region) - - Add 2 additional rows, populating column A with 'GSw_AnnualCapScen' and 'GSw_AnnualCap' in rows 7 and 8 respectively - - Under the 'Western_BA_Decarb' column, populate these rows with 'start2023_100pct2035' and '1' respectively (leave these rows blank in all other columns) - -4. Change the ‘ignore’ row value to be 1 for all columns except ‘Western_BA_Decarb’ which you can either set to 0 or leave blank - -5. Save cases_spatialflex.csv in ReEDS-2.0 folder - -6. Open VS Code - - Open the folder where your repo is located (File -> Open Folder -> navigate to ReEDS-2.0 folder) - - Open a new terminal and activate the reeds2 environment - -7. Start a new run - - `python runbatch.py` - - when prompted for case file name, enter 'spatialflex' - - The 'Western_BA_Decarb' run should start - -#### Create an informal slide deck -Create an informal slide deck with the following results: - - Stacked bar chart of total installed capacity in 2030 - - Include a stacked bar chart of the differences - - Stacked bar chart of total installed firm capacity in 2030 - - Stacked bar chat of generation in all modeled years - - Stacked bar chart of total system costs discounted - - Plots of the locational capacity build out by technology (maps of where capacity is located) - - Plots of the curtailment rates \ No newline at end of file diff --git a/docs/build/html/_sources/internal/ssh_setup.md.txt b/docs/build/html/_sources/internal/ssh_setup.md.txt deleted file mode 100644 index 6bc0d140..00000000 --- a/docs/build/html/_sources/internal/ssh_setup.md.txt +++ /dev/null @@ -1,143 +0,0 @@ ---- -orphan: true ---- -# SSH Key Setup -If you're looking to set up a new SSH key on Yampa, jump to [Setting up a new SSH key on Yampa](#setting-up-a-new-ssh-key-on-yampa). - -## Generating a new SSH key -1. Open Git Bash (Windows) or Terminal (Mac & Linux) - -2. Paste the following text to create a new SSH key: `ssh-keygen -t ed25519 -C "your_email@nrel.gov"` - * It will ask for a file to save the key, press **Enter** to accept the default location - * When asked for a passphrase, leave it empty and hit **Enter**. If you decide to use a passphrase, you will have to enter it any time you need to push or pull from GitHub. - -## Add SSH key to the ssh-agent -Since the ssh-agent manages your keys, you now have to add the newly generated SSH key to the ssh-agent. - -### Windows -1. Open a new admin elevated PowerShell window - * You can do this by clicking 'Start', typing 'PowerShell', and then right-clicking on it and selecting 'Run as Administrator'. - * If you don't already have temporary admin access for your machine, you will need to contact IT and request this. - -2. Ensure the ssh-agent is running by running the following command: - ``` - Get-Service -Name ssh-agent | Set-Service -StartupType Manual - Start-Service ssh-agent - ``` - -3. Open a new PowerShell window (open it normally, it doesn't need to have admin rights) and add your SSH key to the ssh-agent with the command: - ``` - ssh-add c:/Users/[your account name]/.ssh/id_ed25519 - ``` - -4. Copy the SSH key with the command: `clip < ~/.ssh/id_ed25519.pub` - * Note: this might fail on newer versions of Windows, if it does, use this command: `cat ~/.ssh/id_ed25519.pub | clip` - -### Mac -1. Start the ssh-agent with the following command: `eval "$(ssh-agent -s)"` - -2. Modify your `~/.ssh/config` file to automatically load keys into the ssh-agent by following these steps: - a. Check to see if the file exists: `open ~/.ssh/config` - b. If it does not exist, you can create it with this command: `touch ~/.ssh/config` - c. Open the file and modify the contents to contain the following lines (you can open it with the command `open ~/.ssh/config`): - ``` - Host github.com - AddKeysToAgent yes - IdentityFile ~/.ssh/id_ed25519 - ``` -3. Add your SSH key to the ssh-agent with the following command: - ``` - ssh-add --apple-use-keychain ~/.ssh/id_ed25519 - ``` - -4. Copy the SSH key with the command: `pbcopy < ~/.ssh/id_ed25519.pub` - -## Add SSH key to your GitHub account -Now that you have created a new SSH key and added it to the ssh-agent, you need to add the SSH key to your GitHub account. - -1. Log on to github.nrel.gov and go to your account settings -```{figure} ../../../images/github_settings.png -:name: figure-github-settings - -GitHub account settings -``` - - -2. Click on "SSH and GPG keys" on the left sidebar, then click on `New SSH key` -```{figure} ../../../images/github_ssh_gpg_keys.png -:name: figure-github-ssh-gpg-keys - -GitHub SSH and GPG keys -``` - -```{figure} ../../../images/github_add_ssh_key.png -:name: figure-github-add-ssh-key - -GitHub Add New SSH Key -``` - -3. Create a title and paste the SSH key into the "Key" field - - -## Setting up a new SSH key on Yampa -1. Open a new terminal window - -2. Create a .ssh directory in your personal projects directory with the command: `mkdir /data/shared/projects/[username]/.ssh` - -3. Run the following command to create a new SSH key: `ssh-keygen -t ed25519 -C "[youremail@nrel.gov]"` - -4. When asked to enter the file in which to save the key, you can hit enter to accept the default. - * The key will be saved in `/home/[username]/.ssh/id_ed25519` - -5. When asked to enter a passphrase, hit enter to skip this step. If you decide to create a passphrase, you will need to enter this passphrase upon every push/pull. - -6. Run the command: `ssh-add id_ed25519` - -7. Open the key in gedit with the command: `gedit /home/[username]/.ssh/id_ed25519.pub`. Then copy the text contents of this file to the clipboard with a Ctrl+C keyboard command. - -8. Log on to github.nrel.gov and go to your account settings - -```{figure} ../../../images/github_settings.png -:name: figure-github-settings-2 - -GitHub account settings -``` - -9. Click on "SSH and GPG keys" on the left sidebar, then click on `New SSH key` - -```{figure} ../../../images/github_ssh_gpg_keys.png -:name: figure-github-ss-gpg-keys-2 - -GitHub SSH and GPG keys -``` - -```{figure} ../../../images/github_add_ssh_key.png -:name: figure-github-add-ssh-key-2 - -GitHub Add New SSH Key -``` - -10. Create a title for your key (e.g. yampa) and paste the text from the clipboard into the text box below, then click "Add SSH Key" to save. - * To check that your key was added, go back to the terminal on Yampa and run the command `ssh -T git@github.nrel.gov`. If successful, you should get the message "Hi [username]! You've successfully authenticated, but GitHub does not provide shell access." - * **Note:** you might get a message saying "The authenticity of host 'github.nrel.gov ()' can't be established... Are you sure you want to continue connecting (yes/no/[fingerprint])?" Entering 'yes' will add github.nrel.gov to your list of know hosts, found in this file: '/home/[username]/.ssh/known_hosts - -11. You can now clone the ReEDS repository where you can then install the environments from the yml file. - -## Troubleshooting -If you run into issues while setting up a new ssh key, see the GitHub docs for [Troubleshooting SSH](https://docs.github.com/en/authentication/troubleshooting-ssh) - - -### What if I still can't push/pull from the command line after setting up the SSH key? -After creating an SSH key and adding it to your GitHub account, you should be able to push/pull from the terminal without entering your github credentials. - -If you're still being asked for your credentials, it's likely due to the fact that you haven't configured the correct URL for the repo locally. To fix this: -1. Check what your remote URL is, run the command `git remote -v` - * This should list out your existing remote repositories - * If you're seeing them as "https://...." you will need to switch the remote URL from HTTPS to SSH - -2. To switch the remote URL, run the command `git remote set-url origin git@github.nrel.gov:ReEDS/ReEDS-2.0.git` - -3. Verify the remote URL has been changed, run the command `git remote -v` again - * You should not see the origin as "git@github...." - -More information on this can be found in the [GitHub Docs](https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories#switching-remote-urls-from-ssh-to-https) \ No newline at end of file diff --git a/docs/build/html/_sources/internal/version_control_and_testing.md.txt b/docs/build/html/_sources/internal/version_control_and_testing.md.txt deleted file mode 100644 index 73f409c7..00000000 --- a/docs/build/html/_sources/internal/version_control_and_testing.md.txt +++ /dev/null @@ -1,74 +0,0 @@ -## Version Control and Testing -### ReEDS Versioning & Releases -This section outlines the current ReEDS approach to versioning. You can find current and past ReEDS versions here: {{ '[ReEDS-2.0 Releases]({}/releases)'.format(base_github_url) }} - -#### Versioning overview - -GitHub Releases are used to create ReEDS versions on a monthly cadence after a suite of tests are performed. More on ReEDS testing can be found [here](./Testing). More information on GitHub Releases can be found in the [GitHub Doc](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases). - -Releases are based on Git tags, and the proposed versioning scheme is `EPOCH.RELEASE.PATCH`. The components are: -- `EPOCH`: The current year, this will be incremented in January of each year (e.g., 2023) -- `RELEASE`: Restarts from 0 when EPOCH is increased, then increased by 1 each month when the newest version is created -- `PATCH`: Typically will just be 0, but could increment if an important update or bug fix needs to be merged in prior to the next monthly release. - -#### Tagging versions - -Tagging with GitHub releases is not done manually with each pull request. After a new release has been created, a tag will be generated. - -How to use tags: -- You can check them out like any other commit: `git checkout tags/2023.1.0` - - You may need to fetch tags to your machine first: `git fetch --tags` - - If you plan to develop from an older tag (i.e., you’re not checking out main on the most recent tag and you plan to commit new changes), you’ll also want to specify a branch or create a new one: `git checkout -b ` -- ReEDS2X tool versions should reference the last ReEDS version they're known to work for in their tag text or README - - Each ReEDS run produces a meta.csv file with information on the branch, commit, and version of that run which can be used to determine the vintage of any given ReEDS run. -- If you're using ReEDS2X for a side project and would like to tag versions for them to refer to, the suggested format is: `EPOCH.RELEASE.PATCH.PROJECTNAME`, where `EPOCH.RELEASE.PATCH` refers to the last version of main that has been merged into your project branch. - - The same format can be used to tag specific versions of the model that are used for published analyses that are not merged into main, e.g. 2023.4.0.hybrids. - - In general, please add custom components to the tail of the version number instead of the beginning to keep them easy to sort. - - -### Testing Guidelines -This section outlines the recommended testing that should be performed on ReEDS prior to creating a pull request or a new version. - -#### Post-process Test -**This testing should be performed when a change is made that does not change model code or data that might impact model outputs. Ex: changing the color styles in bokeh output plot, or adjusting a post-processing script such as runstatus.py** - -1. Ensure the post-processing capabilities operate correctly on outputs from the most recent version of main - - A demonstration of this should be included in the pull request -2. Verify that R2X pytest passes - -#### Light Test (Pacific Region) -**This testing should be performed for changes to model code that are not expected to have any meaningful impact on the model solution. Examples include:** - -* **Rounding an input parameter** - -* **Changing the name of a column or model parameter** - -* **Updating code within an if statement where the if statement does not apply under default settings (e.g., "if int(sw.GSw_calc_powfrac):" where the default value of sw.GSw_calc_powfrac is 0)** - -* **Adding a missing entry to run files.csv** - -1. Do a comparison run of the default test case (cases_test.csv) against a test run from main and produce a comparison report. - - The report should be examined for any unexpected outputs and included in the pull request for review -2. Verify that R2X pytest passes - -#### Regular Test (Full U.S.) -**This testing should be performed for all other cases not covered by the post-process or light test** - -1. Do a comparison run of the default case (cases.csv) against a run from main and produce a comparison report. - - You should be able to reasonably explain changes in capacity, generation, transmission capacity, bulk system electricity price, system cost, and runtime - - The report should be included in the pull request -2. Verify that R2X pytest passes - -#### New Version Test -**This testing is required for a new tagged and released version** - -The full set of scenarios in `cases_test.csv` is run on HPC and Yampa (tests are also run locally on Mac or Windows, with the exception of the USA_decarb scenario). All test scenarios, with the exception of the following, must succeed in order for a new version to be created: - * Pacific test case with water constraints - * Pacific test case with PVB turned on - * Pacific test case with detailed CO2 transport & storage - * Pacific test case with representatives weks - * Pacific test case with full chronological year - -For any error in the output processing scripts, a new GitHub issue should be created. Additionally, the issue should be noted in the release notes for the new version. - -Lastly, comparison reports are created for the USA and USA_decarb scenarios to compare the current version with the previous released version. Those comparison reports should be attached to the release notes for reference. \ No newline at end of file diff --git a/docs/build/html/_sources/internal/yampa_guide.md.txt b/docs/build/html/_sources/internal/yampa_guide.md.txt deleted file mode 100644 index 21b83b53..00000000 --- a/docs/build/html/_sources/internal/yampa_guide.md.txt +++ /dev/null @@ -1,206 +0,0 @@ ---- -orphan: true ---- -### List of Machines -| Machine Name | RAM | -| --- | --- | -| constellation01.hpc.nrel.gov | 120 GB | -| cepheus.hpc.nrel.gov | 250 GB | -| corvus.hpc.nrel.gov | 250 GB | -| delphinus.hpc.nrel.gov | 500 GB | -| dorado.hpc.nrel.gov | 500 GB | - -### Getting Access to Machines -Access to the servers is controlled through the "reedsos" allocation. To request an HPC account, complete this [request form](https://www.nrel.gov/hpc/user-accounts.html). When asked if you intend to request a new project/allocation, select "no" and request to join "reedsos". - -```{figure} ../../../images/hpc_request_form.png - -HPC account form, request to join "reedsos" allocation -``` -**Note:** the 'reedsos' allocation isn't an active allocation for HPC, which can cause some confusion with the HPC team, but it is still used to manage access to yampa. - -If you have access issues after requesting an account, you can contact HPC help at [HPC-Help@nrel.gov](HPC-Help@nrel.gov). - - -### Getting Started -#### Get started with Microsoft Remote Desktop -Connections to the machines can be made using Microsoft Remote Desktop. To download: -* On Windows: -* On Mac: You can download Microsoft Remote Desktop from the app store. You will need to create an apple id using your nrel email to start using the app store. - -From the Remote Desktop client, you will need to click on the '+' then 'Add PC'. In the 'PC name' field, put the machine name that you would like to connect to, then click 'Add'. - -```{figure} ../../../images/yampa_add_machine.png - -Example of how to add a new machine in Microsoft Remote Desktop -``` - -**Username and Password**: Same as HPC credentials. - -**Note:** Check to make sure that nrel_nt is NOT inlcluded in your username, this sometimes gets added automatically to some users at first login by Microsoft Remote Desktop. - - -#### Drive Configuration -Unlike the old servers, storage is shared across the machines: as a result, you should only need to complete setup once, and it should be automatically reflected on other machines. There is a limited amount of space in your home directory with enforced storage limits. Only files essential to configuring your account should be kept here (e.g. path configurations). - - -The rest of the data is stored in the following folders: - * /data/shared/apps - contains programs - * /data/shared/projects - contains user project folders: you'll need to create one similar to the D: drives on the constellation machines - -Create a projects folder by running the following command: `mkdir /data/shared/projects/[your user name]` - -#### Initial Setup -After getting connected to the machine and creating your projects directory, you'll need to do two additional steps to complete setup. - -##### Add installed programs to PATH -To add installed programs to the $PATH environment variable, use the following command in the terminal: `gedit ~/.bashrc` - -This will open up a text editor with your .bashrc file which contains the path locations. Here you will need to add gams, anaconda, and smartgit to $PATH. - -Add the following line separated by colons to the path: - -``` -/data/shared/apps/gams/gams45.2_linux_x64_64_sfx:/data/shared/apps/gams/gams45.2_linux_x64_64_sfx/studio:/data/shared/apps/anaconda3/bin:/data/shared/apps/GitAhead -``` - -**Important:** Make sure you don't delete the original PATH contents or the ":$PATH" as part of PATH - -Once completed, your bashrc file should look like the following screenshot. Save the file, then log off and log back on to ensure $PATH settings are updated. - - -```{figure} ../../../images/yampa_bashrc_file.png - -Example of bashrc file with updated $PATH -``` - -##### Set up conda folders/environments -You'll want to create a folder within your projects folder to store conda environments and packages. Run the following commands: - * `mkdir /data/shared/projects/[username]/.conda` - * `mkdir /data/shared/projects/[usename]/.conda/pkgs` - * `mkdir /data/shared/projects/[username]/.conda/envs` - -Now, direct conda to look in these folders for packages and environments by running the following commands: - * `conda config --add pkgs_dirs /data/shared/projects/[username]/.conda/pkgs` - * `conda config --add envs_dirs /data/shared/projects/[username]/.conda/envs` - -Next, create and activate the conda environment. From the terminal, run the following commands from within the ReEDS repo: - * `conda env create -f environment.yml` - this step may take a while - * `conda activate reeds` - if this steps causes issues, you can try running `source activate reeds2` instead - -##### Create SSH key and add it to your GitHub account -Follow the [ssh setup guide](ssh_setup.md) to create a new SSH key and add it to your GitHub account. - -### Applications -#### Adding Links to Application Launcher -You can add executables including programs and scripts to the application launcher by adding .desktop files to the directory "~/.local/share/applications". These follow a standard Linux format. More info can be found [here](https://wiki.archlinux.org/title/desktop_entries). - -We've prepopulated links for GAMS Studio, RStudio, and SmartGit kept in "/data/shared/apps/setup/application". You can copy these to your home directory using the following command: `rsync -avu /data/shared/apps/setup/applications ~/.local/share/ ` - -#### GAMS Studio -GAMS Studio is the IDE packaged with GAMS. It can be used for GAMS development and supports code markup and executing GAMS code from the developer environment. The other major application of GAMS Studio is to open .gdx files. - -The GAMS studio executable is stored in the folder "/data/shared/apps/gams/gams45.2_linux_x64_64_sfx/studio/studio.AppImage". - -If the folder containing the executable was added to the path it can be run by using the following command from the terminal: `Studio.AppImage` - -Note: If if hasn't been added to your path, you can run the following command instead: `/data/shared/apps/gams/gams45.2_linux_x64_64_sfx/studio/studio.AppImage` - -Navigate to postprocessing/bokehpivot and make sure your reeds environment has been activated. - -Run this command (which is the contents of launch.sh): - -`bokeh serve . --sh --port 0`` - -Note that you can copy the file path using the “Copy Location” option in the drop-down menu from the filepath in Files. - -#### GitAhead -Github desktop has compatibility issues on Linux with Github enterprise. For a GUI interface for git use smartgit. - -GitAhead can be launched by running the following command in the command line if you included in in your path environmental variable. - -`GitAhead` - -If it hasn’t been added to your path run the following - -`/data/shared/apps/GitAhead/GitAhead` - -#### Transferring Data to nrelnas01 -Since at this time we can’t use the Linux servers to talk to Yampa we’re going to use an the HPC file system as a reasonably fast intermediary. The following instructions are for how to transfer data from Yampa to nrelnas01 but could easily be reversed by switching the target and destination. - -1. Install or get access to winscp if on Windows. This will make interacting with the HPC file system easier. Transfers will be limited by your connection speed to the nrel network. If you aren’t on campus I would recommend getting access to the GPAC Windows (Azure) VM. It’s primarily intended for PLEXOS use but you won’t have a problem getting access, and this use will not be burdensome. You can download winscp at the link below, if you don’t have admin rights you can download the portable executable which doesn’t require installation. -[https://winscp.net/eng/downloads.php](https://winscp.net/eng/downloads.php) - * **Note:** If you are planning on connect to the Azure VM, Windows users may need to install a different client for the machine to appear in Workspaces. - * To install, go to the link in the paragraph above, use the "Windows 64-bit" link to the installer. Download and run it. - * After installation, open Remote Desktop, and click the Subscribe button. The ASCR machine should show up if you've been added to the group "Constellation Azure Servers" group. - If you're not already a member, you will need to get added, then Unsubscribe via the dropdown in the General Workspaces tab and subscribe again - -2. You can connect to winscp using your hpc credentials and a valid host name (kestrel.hpc.nrel.gov). Once connected you can see the file system. You will want to navigate to the root and then to the following directory: `/scratch/[username]` - * All HPC users are allocated a reasonable amount of temporary space in this folder and it’s a useful place for performing a transfer. - -3. Connect to Yampa and run the following command with your required changes: - ``` - rsync -avz -e ssh /data/shared/projects/[SOURCE FOLDER PATH]/ jho@kestrel.nrel.gov:/scratch/[DESTINATION FOLDER PATH]/ - ``` - - * Here's an example: - ``` - rsync -avz -e ssh /data/shared/projects/jho/Target_Folder/ jho@kestrel.nrel.gov:/scratch/jho/Destination_Folder/ - ``` - -4. Once executed, you'll get a login for the HPC. Once you've entered your credentials the transfer will start. - -5. After the transfer is completed, the new files will be viewable on the HPC file system. They can then be transferred to a local files system including //nrelnas01/ReEDS/ - -#### Transferring Data From Yampa to Your Machine -If you want to directly transfer files between Yampa and your local machine, you can use the tool FileZilla. You can download the FileZilla Client at [https://filezilla-project.org/](https://filezilla-project.org/). - -Once downloaded, you can connect using the following settings: - * Host: cepheus.hpc.nrel.gov (you can connect to any of the five VM hosts and filezilla will automatically add the connection protocol) - * Username: Your HPC username - * Password: Your HPC password - * Port: You can leave this blank (if you have issues connecting you can use '22' as the port) - -You can then transfer data between machines - local machine is on the left and remote machine is on the right. The common project folders are retained in '/data/shared/projects/...' - -#### Spyder -Spyder is an open-source integrated development environment (IDE) that is very useful for interactively running Python scripts and viewing variables, pandas dataframes, plots, etc. in the middle of script execution. Python can be launched from the Anaconda-Navigator Launcher, which can be opened by running the following command in a Terminal: - -`python /data/shared/apps/anaconda3/bin/anaconda-navigator` - -This will open the Anaconda-Navigator Launcher. From there, you can use the dropdown in the upper center of the screen to choose a conda environment to work out of or install/launch Spyder. - -### General Tips -#### Creating Shortcuts -When opening the terminal, Linux defaults to your home directory as an initial starting location. You can create a shortcut to another folder for faster access using the following command: - -`ln -s /data/shared/projects/[username] ~/projects` - -The general implementation of this is: - -ln -s filepath linkpath - -Once created you can use the shortcut as if it were a directory. - - -#### Sorting Folders Before Files - -If you want the file viewer to adopt sorting behavior where folders are sorted alphabetically before files. You can make that change by opening the preferences menu in the folder viewer. - -```{figure} ../../../images/yampa_file_preferences.png - -File preferences on Yampa -``` - -Then select the option for Sort Folders before Files. - -#### Issues Activating Conda Environment -If you're having issues activating the reeds2 conda environment, you can try one of these options: - 1. Use `source activate reeds2` instead of `conda activate reeds2` - 2. Run the following command prior to running `conda activate reeds2` (note: if you don't want to run this command every time, do step 3): - ``` - source /data/shared/apps/anaconda3/etc/profile.d/conda.sh - ``` - 3. Add the following line to the bottom of your bashrc file with the following command (you can open your bashrc file with the command `gedit ~/.bashrc`): - ``` - $ source /data/shared/apps/anaconda3/etc/profile.d/conda.sh - ``` \ No newline at end of file diff --git a/docs/build/html/_sources/model_documentation.md.txt b/docs/build/html/_sources/model_documentation.md.txt deleted file mode 100644 index e2adaa8d..00000000 --- a/docs/build/html/_sources/model_documentation.md.txt +++ /dev/null @@ -1,5593 +0,0 @@ -# Model Documentation -## Overview -ReEDS is a mathematical programming model of the electric power sector. Given a set of input assumptions, ReEDS models the evolution and operation of generation, storage, transmission, and production technologies. - -The model consists of two separate but interrelated modules: - * Supply module - this module solves a linear program for the cost-minimizing levels of power sector investment - * Operation and storage (VRE) module - this module calculates key parameters for assessing the - value of VRE generators and storage - -The latest, detailed documentation of the ReEDS model can be found in the latest version of the published documentation: [Regional Energy Deployment System (ReEDS) Model Documentation: Version 2020](https://www.nrel.gov/docs/fy21osti/78195.pdf). - -Detailed documentation of ReEDS 2.0 input files are available [here](./sources.md) - - -## Acknowledgments - -We gratefully acknowledge the many people whose efforts contributed to -this report. The ReEDS modeling and analysis team at the National -Renewable Energy Laboratory (NREL) was active in developing and testing -the ReEDS model version 2023. We also acknowledge the vast number of -current and past NREL employees on and beyond the ReEDS team who have -participated in data and model development, testing, and analysis. We -are especially grateful to Walter Short who first envisioned and -developed the Wind Deployment System (WinDS) and ReEDS models. We thank -Walter Short, Owen Zinaman, Laura Vimmerstedt, Jeffrey Logan, Cara -Marcy, Gokul Iyer, and Mike Meshek for their comments and improvements -on successive versions of this report. Finally, we are grateful to all -those who helped sponsor ReEDS model development and analysis, -particularly supporters from the U.S. Department of Energy (DOE) but -also others who have funded our work over the years. This report was -funded by the DOE Office of Energy Efficiency and Renewable Energy under -contract number DE-AC36-08GO28308. Any errors or omissions are the sole -responsibility of the authors. - - -## List of Abbreviations and Acronyms - -| Abbreviation/Acronym | | -| --- | --- | -AC | alternating current -AEO | Annual Energy Outlook -ATB | Annual Technology Baseline -BA | balancing area -BECCS | Bioenergy with Carbon Capture and Storage -CAES | compressed-air energy storage -CAIR | Clean Air Interstate Rule -CC | combined cycle -CCS | carbon capture and sequestration -CES | clean energy standard -CF | capacity factor -CFL | compact fluorescent lamp -CO2 | carbon dioxide -CO2e | carbon dioxide equivalent -CMIP | Coupled Model Intercomparison Project -CPP | Clean Power Plan -CPUC | California Public Utilities Commission -CSAPR | Cross-State Air Pollution Rule -CSP | concentrating solar power -CT | combustion turbine -CV | capacity value -DAC | Direct Air Capture -DC | direct current -DG | distributed generation -DNI | direct normal insolation -DOE | U.S. Department of Energy -DSIRE | Database of State Incentives for Renewables & Efficiency -DUPV | distribution-side utility-scale photovoltaic -EAC | early action credit -EGR | enhanced gas recovery -EGS | enhanced geothermal system -EIA | U.S. Energy Information Administration -ELCC | effective load carrying capability -EMM | Electricity Market Module -EOR | enhanced oil recovery -EPA | U.S. Environmental Protection Agency -ERC | emission rate credit -ERCOT | Electric Reliability Council of Texas -FERC | Federal Energy Regulatory Commission -FOM | fixed operation and maintenance -GCM | general circulation model -GHG | greenhouse gas -GIS | geographic information systems -GW | gigawatt -H2 or H2 | Hydrogen -HMI | U.S. Bureau of Reclamation Hydropower Modernization Initiative -HSIP | Homeland Security Infrastructure Project -HVDC | high-voltage direct current -IGCC | integrated gasification combined cycle -IOU | investor-owned utility -IPM | U.S. Environmental Protection Agency Integrated Planning Model -IPP | independent power producer -ISO | independent system operator -IRS | Internal Revenue Service -ITC | investment tax credit -JEDI | Jobs and Economic Development Impact model -km2 | square kilometer -kV | kilovolt -kW | kilowatt -kWh | kilowatt hour -LCOE | levelized cost of energy -LDC | load-duration curve -LED | light-emitting diode -LOLP | loss of load probability -MACRS | Modified Accelerated Cost Recovery System -MATS | Mercury and Air Toxic Standards -MMBtu | million British thermal units -MPI | materials price index -MW | megawatt -MWh | megawatt hour -NaS | sodium-sulfur -NEB | Canadian National Energy Board -NEMS | National Energy Modeling System -NERC | North American Electric Reliability Corporation -NG | natural gas -NHAAP | National Hydropower Asset Assessment Program -NLDC | net load-duration curve -NOx | nitrogen oxide -NPD | non-powered dam -NRC | Nuclear Regulatory Commission -NREL | National Renewable Energy Lab -NSD | new stream-reach development -NSRDB | National Solar Radiation Database -O&M | operation and maintenance -OGS | oil-gas steam -PCM | production-cost model -POI | point of interconnection -PRM | planning reserve margin -PRODESEN | Mexican Programa de Desarrollo del Sistema Eléctrico Nacional -PSH | pumped storage hydropower -PTC | production tax credit -PV | photovoltaic -PVB | photovoltaic and battery -RA | resource adequacy -RCP | representative concentration pathway -REC | renewable energy certificate -ReEDS | Regional Energy Deployment System -reV | Renewable Energy Potential tool -RGGI | Regional Greenhouse Gas Initiative -RLDC | residual load-duration curve -RPS | renewable portfolio standard -RROE | rate of return on equity -RTO | regional transmission organization -SAM | System Advisor Model -SENER | Secretaría de Energía for Mexico -SM | solar multiple -SO2 | sulfur dioxide -T&D | transmission and distribution -TEPPC | Transmission Expansion Planning Policy Committee -tCO2 | metric ton of carbon dioxide -TW | terawatt -TWh | terawatt hour -UPV | utility-scale photovoltaic -VOM | Variable Operation and Maintenance -VRE | variable renewable energy -WACC | weighted average cost of capital -WECC | Western Electricity Coordination Council -WIND | Wind Integration National Dataset -WinDS | Wind Deployment System - - -## Introduction - -This document describes the structure and key data elements of the -Regional Energy Deployment System model architecture 2.0 (ReEDS 2.0, or -simply ReEDS) version 2023, which is maintained and operated by the -National Renewable Energy Laboratory (NREL).[^ref1] ReEDS 2.0 builds upon -the original ReEDS model architecture (hereafter, Heritage ReEDS), -adding more flexibility and additional capabilities while maintaining -the features that have contributed to the model’s attractiveness as a -decision-support tool. In the past, Heritage ReEDS has been used in -support of both public and private sector clients to analyze the -evolution of the U.S. (and in some cases, North American) power sector -in response to policies and technological change. In this introduction, -we provide a high-level overview of ReEDS 2.0 objectives, capabilities, -and applications. We also briefly describe the history of the Heritage -ReEDS model and discuss major changes introduced by the transition to -ReEDS 2.0. Finally, we provide a short discussion of important caveats -that apply to any ReEDS analysis. - -The ReEDS model code and input data can be accessed at -. - - -### Overview - -ReEDS is a mathematical programming model of the electric power sector. -Given a set of input assumptions, ReEDS models the evolution and -operation of generation, storage, transmission, and production[^ref2] -technologies. The results can be used to explore the impacts of a -variety of future technological and policy scenarios on, for example, -economic and environmental outcomes for the entire power sector or for -specific stakeholders. ReEDS employs a modular structure to maximize -user flexibility. Currently, the model consists of two separate but -interrelated modules: a supply module, which solves a linear program for -the cost-minimizing levels of power sector investment; and operation and -a storage (VRE) module,[^ref3] which calculates key parameters for -assessing the value of VRE generators and storage. - -Power markets are represented in the model by separating the continent -into model regions, each of which has sources of supply and demand. -Regions are connected by a representation of the transmission network, -which includes existing transmission capacity and endogenous new -capacity. The model represents all existing generating units, planned -future builds, and endogenous new capacity within each region. The model -is intended to solve on the decadal scale, though the time horizon for a -particular model run (and the intervening model solve years) can be -selected by the user. Within each year, a selected representative -timeslices and stress periods are used to characterize seasonal and -diurnal patterns in supply and demand. - - -### ReEDS History - -The ReEDS model heritage traces back to National Renewable Energy -Laboratory’s (NREL’s) seminal electric sector capacity expansion model, -called the Wind Deployment System (WinDS) model. The WinDS model was -developed beginning in 2001 to examine long-term market penetration of -wind in the electric power sector {cite}`shortModelingLongTermMarket2003`. From 2003 -to 2008, WinDS was used in a variety of wind-related analyses, including -the production of hydrogen from wind power, the impacts of state-level -policies on wind deployment, the role of plug-in hybrid electric -vehicles in wind markets, the impacts of high wind penetration on U.S -wind manufacturing, the potential for offshore wind, the benefits of -storage to wind power, and the feasibility of producing 20% of U.S. -electricity from wind power by 2030 {cite}`doe20WindEnergy2008`. -In 2006, a variation of -WinDS was developed to analyze concentrating solar power (CSP) potential -and its response to state and federal incentives. In 2009, WinDS was -recast as ReEDS—a generalized tool for examining the long-term -deployment interactions of multiple technologies in the power sector {cite}`blairRenewableEnergyEfficiency2009`. - -Since 2009, ReEDS has been the primary analytical tool in several -studies, including the Hydropower Vision {cite}`u.s.departmentofenergy2016BillionTonReport2016`, Wind Vision {cite}`doeWindVisionNew2015`, SunShot Vision {cite}`doeSunShotVisionStudy2012`, Geothermal Vision {cite}`doeGeoVisionHarnessingHeat2019`, and -Renewable Electricity Futures {cite}`nrelRenewableElectricityFutures2012`. NREL currently uses ReEDS to -publish an annual *Standard Scenarios* report, which provides a U.S. -electric sector outlook under a wide range of possible futures {cite}`cole2020StandardScenarios2020`. ReEDS has also been used to examine impacts of a range of -existing and proposed energy policies {cite:p}`lantzImplicationsPTCExtension2014, maiImpactFederalTax2015, gagnonImpactRetailElectricity2017`. Other recent studies have used ReEDS to -examine the role of natural gas, high renewable scenarios, and other -important issues for the U.S. electricity sector {cite:p}`mignoneCosteffectivenessEconomicIncidence2012, loganNaturalGasScenarios2013, clemmerModelingLowcarbonUS2013, maiEnvisioningRenewableElectricity2014, sullivan2015StandardScenarios2015, coleConsideringRoleSolar2015, coleInteractionsRooftopPV2016, richardsAssessingImpactNuclear2017, coleEnvisioningLowcostSolar2018`. The ReEDS website[^ref4] includes an up-to-date list of publications that use ReEDS. - - -### Summary of Major Changes - -Since the inception of WinDS and ReEDS, NREL has conducted a diverse -suite of analyses. Within each analysis, new capabilities were -developed, thereby improving the sophistication of the model. The -incremental development was often completed by different analysts with -unique intentions and coding preferences. Over time, the model became -increasingly difficult to maintain. Additionally, as the model evolved, -so did the research questions. Therefore, in the fall of 2016, NREL -began to rebuild Heritage ReEDS from the ground up. After three years, -the resulting product was a cleaner, more flexible, and more advanced -tool called ReEDS 2.0. Though ReEDS’ fundamental structure and -functionality have remained constant, ReEDS 2.0 introduces several -changes to the heritage version of the model. The most notable changes -include the following: - -- Representative Hours and stress periods - -- Hourly ReEDS/Flexible Temporal Resolution - -- Decarbonization Scenarios - -- Spatial Flexibility? - -- Policy Representation (IRA) - -- Newer Technology representation - -- Transmission (intrazonal, initial capacity, and HVDC macrogrids) - -While there are major architectural changes with ReEDS 2.0, many of the -incumbent data and methods supporting ReEDS were updated incrementally. -This documentation describes the data and methods for the 2023 version -of ReEDS. The “Differences from the 2020 Model Version” section of the -appendix summarizes more of the specific changes to made to ReEDS since -the 2020 version. - - -### Summary of Caveats - -Though ReEDS represents many aspects of the U.S. electricity system, it -necessitates simplifications, as all models do. We offer a list of some -important limitations and caveats that result from these -simplifications. - -**System-wide optimization:** ReEDS takes a system-wide, least-cost -perspective that does not necessarily reflect the perspectives of -individual decision makers, including specific investors, regional -market participants, or corporate or individual consumers; nor does it -model contractual obligations or noneconomic decisions. In addition, -like other optimization models, ReEDS finds the absolute (deterministic) -least-cost solution that does not fully reflect real distributions or -uncertainties in the parameters; however, the heterogeneity resulting -from the high spatial resolution of ReEDS mitigates this effect to some -degree. - -- **Resolution:** Though ReEDS has high spatial, temporal, and process - resolution for models of its class and scope, it cannot generally - represent individual units and transmission lines, and it does not - have the temporal resolution to characterize detailed operating - behaviors, such as ramp rates and minimum plant runtime. It also does - not represent all intra-annual time scales, such as weekly or monthly - trends, as ReEDS intra-annual time slices are designed to characterize - one day in each season. Many of the time slice shortcomings are - addressed by using hourly data in VRE modules, but non-VRE generators - do not get that higher resolution. - -- **Foresight and behavior:** Except when running with intertemporal - optimization, the model has limited foresight, so model - decision-making does not account for anticipated changes to markets - and policies. For example, non-intertemporal runs in ReEDS do not - endogenously model banking and borrowing of credits for carbon, - renewable, or clean energy policy between solve periods. - -- **Project pipeline:** The model incorporates data of planned or - under-construction projects, but these data likely do not include - *all* projects in progress. - -- **Manufacturing, supply chain, and siting:** The model does not - explicitly simulate manufacturing, supply chain, or siting and - permitting processes. Potential bottlenecks or delays in project - development stages for new generation or transmission are not fully - reflected in the results. All technologies are assumed to be available - at their defined capital cost in any quantity up to their technical - resource potential. Penalties for rapid growth are applied in ReEDS; - however, these do not fully consider all potential manufacturing or - deployment limits. Dates associated with cost inputs in the model - reflect project costs for the commercial operation date but not - necessarily when equipment is ordered. - -- **Financing:** Though the model can use annually varying financing - parameters to capture near-term market conditions and - technology-specific financing to account for differences in typical - investment strategies across technologies, ReEDS cannot fully - represent differences in project financing terms across markets or - ownership types and thus does not allow multiple financing options for - a given technology. - -- **Technology learning:** Future technology improvements are considered - exogenously and thus are not a function of deployment in each - scenario. - -- **Power sector:** ReEDS models only the power sector within its - defined regional scope (contiguous United States or United States with - Canada and/or Mexico), and it does not represent the broader U.S. or - global energy economy. For example, competing uses of resources (e.g., - natural gas) across sectors are not dynamically represented in ReEDS, - and end-use electricity demand is exogenously input into ReEDS. - -Notwithstanding these limitations—many of which exist in other similar -tools—the modeling approach considers complex interactions among -numerous policies and technologies while ensuring electric system -reliability requirements are maintained within the resolution and scope -of the model. In doing so, ReEDS can comprehensively estimate the system -cost and value of a wide range of technology options given a set of -assumptions, and we can use the model to generate self-consistent future -deployment portfolios. - -A comparison against historical data using ReEDS was completed by Cole -and Vincent {cite:year}`coleHistoricalComparisonCapacity2019` and is useful for providing context for how ReEDS can -perform relative to what actually occurred in historical years. - -## Modeling Framework - -In this section, we describe the modeling framework underlying ReEDS, -including the modular structure of the model (and how outputs are passed -between modules and convergence is achieved), spatial resolution, -temporal resolution, technology represented, and the model formulations. - - -### Model Structure - -ReEDS combines an optimization module, representing electricity supply, -with a simulation module, which uses a dispatch algorithm and multiple -years of chronological hourly wind, solar, and load data to estimate the -contribution of storage and VRE units to capacity (see [Resource Adequacy](#resource-adequacy)) -and the level of curtailment for VRE units. - -The model can be run sequentially, intertemporally, or using a sliding -window. {numref}`figure-ReEDS-structure` illustrates how the modules -interact when the model is run in sequential solve mode. Within an -iteration, the supply and VRE modules are run in sequence for each model -solve year. For a given model year *t*, the supply module, which has -been provided with a set of inputs dependent on the results from -previous model years, is solved and a subset of the outputs are passed -along to the VRE and storage module. Using these inputs, the module then -calculates the capacity value of VRE and storage, and curtailment rates -for VRE units, which are then applied to the next model year solve -(t+1).[^ref5] - -```{figure} ../../images/ReEDS-structure.png -:name: figure-ReEDS-structure - -Schematic illustrating the ReEDS structure with a sequential solve -``` - -When the model is run with sliding window or perfect foresight. -Each iteration begins with an -execution of the supply module for all model years. The outer cycle (red -arrows) illustrates the order in which the modules are executed: -starting with the supply module followed by the VRE module, after which -the next iteration begins with the supply module. This process is -repeated until convergence. The inner cycles (orange arrows) illustrate -how information is shared by the modules. The types of information -shared by the two modules are the same as for the sequential solve mode. -The major difference is that the supply module passes information for -all model years to the VRE and storage module (and vice versa), and that -an iterative process occurs between the two modules. - -Regardless of which foresight mode is chosen, the modular structure -allows each part of the model to be executed independently. However, the -supply and VRE and storage modules are unlikely to be executed without -each other, except for testing purposes. This is because one of the key -strengths of ReEDS resides in its detailed representation of VRE -integration and valuation. - - -### Model Formulation - -The supply module is a linear program that governs the evolution and operation of the -generation and transmission system. This module seeks to minimize power -sector costs as it makes various operational and investment decisions, -subject to a set of constraints on those decisions. - -The objective function is a minimization of both capital and operating -costs for the U.S. electric sector, including: - -- The net present value of the cost of adding new generation, storage, - and transmission capacity (including project financing) - -- The present value of operating expenses over the evaluation period[^ref6] - (e.g., expenditures for fuel and operation and maintenance \[O&M\]) - for all installed capacity - -- The cost of several categories of ancillary services and storage - -- The cost or incentive applied by any policies that directly charge or - credit generation or capacity - -- Penalties for rapid capacity growth as a proxy for manufacturing, - supply chain, and siting/permitting limitations. - -By minimizing these costs and meeting the system constraints (discussed -below), the linear program determines the types of new capacity to -construct in each region during each model year to minimize systemwide -cost. Simultaneously, the linear program determines how generation and -storage capacity should be dispatched to provide the necessary grid -services in each of the selected representative timeslices. The capacity -factor for each dispatchable technology, therefore, is an output of the -model and not an input assumption. - -The constraints that govern how ReEDS builds and operates capacity fall -into several main categories: - -- **Load Balance Constraints**: Sufficient power must be generated - within or imported by the transmission system to meet the projected - load in each of the 134 balancing areas (BAs) in each of the - representative time-slices. The annual demand and the - time-slice-specific electricity demand in future years are scaled - based on load growth inputs. - -- **Planning Reserve Constraints**: Each region must have sufficient - available capacity to meet the forecasted peak demand as well as an - additional planning reserve margin {cite}`northamericanelectricreliabilitycorporation2021LongTermReliability2021`. Dispatchable technologies - contribute their full capacity toward planning reserves. For variable - renewable energy (VRE) technologies, ReEDS uses a load-duration curve - (LDC) approximation to estimate the effective load-carrying capacity - of both existing capacity and potential capacity additions to - determine their contribution to meeting the reserve margin. For - storage, a chronological simulation using hourly data is used to - assess its contribution. Planning reserve capacity can also be traded - between regions if transmission capacity is available.[^ref7] - -- **Operating Reserve Constraints:** These constraints ensure enough - capacity is available to meet unexpected changes in generation and - load in each reserve-sharing group ([Operational Reliability](#operational-reliability)) and time-slice. ReEDS - accounts for the following operating reserve requirements: regulation - reserves, spinning reserves, and flexibility reserves. - -- **Generator Operating Constraints:** Technology-specific constraints - bound the minimum and maximum power production and capacity commitment - based on physical limitations and assumed average outage rates. - -- **Transmission Constraints:** Power transfers among regions are - constrained by the nominal carrying capacity of transmission corridors - that connect the regions. Transfers of planning reserves are also - subject to transmission limits. A detailed description of the - transmission constraints can be found in [Transmission](#transmission). - -- **Resource Constraints:** Many renewable technologies, including wind, - solar, geothermal, biopower, and hydropower, are spatially - heterogeneous and constrained by the quantity available at each - location. Several of the technologies include cost- and - resource-quality considerations in resource supply curves to account - for depletion, transmission, and competition effects. The resource - assessments that seed the supply curves come from various sources; - these are discussed in [Technology Descriptions](#technology-descriptions), where characteristics of each - technology are also provided. - -- **Emissions Constraints:** ReEDS can limit or cap the emissions from - fossil-fueled generators for sulfur dioxide (SO2), nitrogen - oxide (NOx), and carbon dioxide (CO2). - The emission limit and the emission per megawatt-hour by fuel and - plant type are inputs to the model. Negative emissions are allowed - using biomass with carbon capture and storage (BECCS) or direct air - capture (DAC), and the emission constraint is based on net emissions. - Emissions can be either capped or taxed, with flexibility for applying - either. Alternatively, emissions intensities can also be limited to - certain bounds in ReEDS. The emissions constraints can be applied to - stack emissions, or can be based on CO2 equivalent - emissions, with the later including emissions from upstream methane - leakage.[^ref8] Methane leakage rates are input by the user. - -- **Renewable Portfolio Standards or Clean Electricity Standards:** - ReEDS can represent renewable portfolio standards (RPSs) and clean - electricity standards constraints at the national and state levels. - All renewable generation is considered eligible under a national RPS - requirement. The renewable generation sources include hydropower, - wind, CSP, geothermal, PV, and biopower (including the biomass - fraction of cofiring plants). The eligibility of technologies for - state RPSs depends on the state’s specific requirements and thus - varies by state. RPS targets over time are based on an externally - defined profile. Penalties for noncompliance can be imposed for each - megawatt-hour shortfall occurring in the country or a given state. In - the same way, a clean energy standard constraint can be implemented to - include non-renewable clean energy resources, such as nuclear, fossil - fuels with carbon capture and sequestration (CCS), or natural gas. - - -### Spatial Resolution - -ReEDS is typically used to study the contiguous United States.[^ref9] -Within the contiguous United States, ReEDS models capacity -expansion and grid service requirements in 134 model BAs, shown in -{numref}`figure-reeds-regional-structure`. The model BAs are not designed to represent or align perfectly -with real balancing authority areas; they are county aggregates intended -to represent model nodes where electricity supply and demand is -balanced. The model’s synthetic transmission network connects the BAs -and is composed of roughly 300 representative corridors across the three -asynchronous interconnections: the Western Interconnection, the Eastern -Interconnection, and Electric Reliability Council of Texas (ERCOT). The -BAs also respect state boundaries, allowing the model to represent -individual state regulations and incentives. Additional geographical -layers used for defining model characteristics include 3 synchronous -interconnections, 18 model regional transmission operators designed -after existing regional transmission operators, 19 North American -Electric Reliability Corporation (NERC) reliability subregions, 9 census -divisions as defined by the U.S. Census Bureau, and 48 states.[^ref10] The -spatial configuration in the model is flexible, such that the model can -be run at various resolutions (e.g., aggregations of balancing areas), -and data within the model are filtered to only include data for the -regions being modeled in a given scenario. - -For more information on the spatial flexibility in the model, see the -“Spatial Resolution Capabilities” section of the appendix.[^ref11] - -```{figure} ../../images/reeds-regional-structure.png -:name: figure-reeds-regional-structure - -ReEDS regional structure -``` - -ReEDS includes 134 zones (used for most model decisions), 18 -transmission groups (used for grouped-interface flow constraints), 11 -planning regions (used by default for representative period selection -and capacity credit calculations), 11 NERC regions (used to define -planning reserve margin constraints), 10 USDA regions (used for -bioenergy supply curves), 9 census divisions (used for fossil gas supply -curves), and 3 synchronous interconnections (used to set the boundaries -for AC transmission expansion). - - -### Temporal Resolution - -- Thematic overview - - Representative periods - - 2007-2013; 2012 is default for rep periods while 2007-2013 used for RA - - Representative period selection - - Optimized - - Hierarchical - -Many energy system models often solve a full chronological year at -hourly resolution in order to capture the time dependent variability -that pervades increasingly renewable systems. However, high temporal -resolution coupled with high spatial resolution can lead to intractable -optimization problems. For instance, in ReEDS, solving model years in -chronological 4-hour steps is only possible when the model regions are -aggregated and the complexity of the scenario is reduced to eliminate -some constraints. Given the computational challenges, power system -planning models typically forgo full annual temporal resolution and -instead select representative periods to capture variability {cite}`fleischerMinimisingEffectsSpatial2020`. A -common approach as described in the literature {cite:p}`teichgraeberClusteringMethodsFind2019, marcyComparisonTemporalResolution2022, liuHierarchicalClusteringFind2018` -identify these periods uses hierarchical clustering which builds a -hierarchy of clusters based on dissimilarity between sets of -observations in wind capacity factor, solar capacity factor, and demand -time series data. In Reichenberg and Hedenus {cite:year}`Reichenberg2022` the authors demonstrate that hierarchical -clustering is unable to capture regional trends in large systems such as -the United States, motivating an optimization based approach to -determine representative periods in the ReEDS model. The two-step -optimization first weights periods to minimize error in regional -capacity factor and load data over all features (wind capacity factor, -solar capacity factor, and load) and all regions as described by (1). -The error is defined as the difference between the sum of the weighted -regional profiles for wind, solar, and load and the actual regional -profiles over all periods and all regions as described in (2). The -result of this minimization is a selection of representative days -weighted by number of total days in the year. - -$$\min \sum_{f,r}^{F,R} E_{1+}(f,r) + E_{1-}(f,r)$$ - -\(1\) - -$$E_{1+}(f,r) + E_{1-}(f,r) = \sum_{p}^{P} W(p)x(p,f,r) - \sum_{p}^{P} x(p,f,r) \quad \forall \ f,r$$ - -\(2\) - -In the second step of the optimization, actual periods are mapped to the -most similar representative period by again minimizing the sum of -absolute error over all periods, features, and regions. The error in -this minimization problem is defined as the difference between the -actual profile for a given actual period, $_{}$,and the representative -profile for the period that actual period is mapped to, -$\left(_{} \right)$. Since each actual period can only be mapped to a -single representative day, the problem is formulated as a mixed integer -linear program as described in (3) and (4). - -$$\min [ \sum_{p_a,f,r}^{P,F,R} x(p_a,f,r) - \sum_{p_r}^{P_r} M(p_a,p_r) x(p_r,f,r)]$$ - -\(3\) - -$$\sum_{p_r}^{P_r} M(p_a, p_r) = 1 \quad \forall \ p_a$$ - -\(4\) - -In conjunction, the results of both optimizations lead to a set of -representative periods where the weighting determined in step one -indicates the number of times a representative period will be used over -the course of the year. For example, a representative day weighted by 36 -will be used to replace the 36 actual days of the year which are most -similar. Ultimately this optimization-based approach to identify -representative periods helps to reduce the required number of periods -while also capturing regional trends. - -- Period resolution: days, 5-day “weeks”, or chronological year - -- Timeslice chunks: 4-hour default but can use 1-, 2-, or 3-hour chunks - for smaller system - -- Inter-period linkages - - 1. Diurnal storage cycles within periods - - 2. “Seasonal” storage (currently just H2) level is tracked between - periods - - 3. Linearized startup costs apply between periods - - -## Technology Descriptions - -This section describes the electricity generating technologies included -in ReEDS. Cost and performance assumptions for these technologies are -not included in this report but are taken directly from the 2023 Annual -Technology Baseline (ATB) {cite}`nrel2023AnnualTechnology2023`. - - -### Renewable Energy Resources and Technologies - -Because renewable energy technologies are a primary focus area of the -ReEDS model, they are characterized in detail. Their characterization -encompasses resource assessments,[^ref12] projected technology -improvements, grid interconnection costs, and operational implications -of integration. Renewable energy technologies modeled include land-based -and offshore wind power, solar PV (both distributed and utility-scale), -CSP with and without thermal storage,[^ref13] hydrothermal geothermal, -near-field enhanced geothermal systems (EGS), deep EGS, run-of-the-river -and traditional hydropower (including upgrades and non-powered dams), -dedicated biomass, cofired biomass, land-fill gas, renewable energy -combustion turbines, and marine hydrokinetic wave technologies. The -input assumptions, data sources, and treatments of these technologies -are discussed in the following sections. Transmission considerations for -renewable energy technologies are discussed in [Interzonal Transmission](#interzonal-transmission).[^ref14] - - -#### Land-Based Wind - -Wind technologies are modeled using representative turbine technologies -by region depending on wind resource quality. Details of the wind -resource data and technology representation can be found in Appendix H -of the Wind Vision study {cite}`doeWindVisionNew2015`. In the current version of ReEDS, we -have relied on the same data sources and approach; however, we extend -the wind resource data to lower-quality wind sites. - -The resource assessment for land-based wind uses a resource map of -hourly wind speeds for the United States and offshore areas (for -offshore wind, see [Offshore Wind](#offshore-wind)) and -considers land use exclusions {cite}`lopezLandUseTurbine2021b`. The Reference Access -resource totals more than 7,700 gigawatts (GW), although a Limited -Access and Open Access supply curves are also available. - -Individual wind sites are grouped into ten resource classes for ReEDS, -based on average wind speed ({numref}`land-based-wind-class-def`).[^ref15] The modeling and assessment of individual wind sites -was facilitated using NREL’s Renewable Energy Potential (reV) tool -{cite}`maclaurinRenewableEnergyPotential2021`. The meteorological data for onshore wind are -from the Wind Integration National Dataset (WIND) Toolkit, using -long-term average data for the resource assessment. {numref}`figure-land-based-wind` shows the -land-based wind resource data modeled in ReEDS for all 10 classes, where -the highest average wind speeds belong to class 1 and the lowest to -class 10 {cite}`maiInteractionsWindEnergy2021`. Each class is then further differentiated by -a supply curve for grid interconnection costs in each region. See -[Interzonal Transmission](#interzonal-transmission) for a discussion of interconnection supply curves for -accessing the wind resource. - -Distinct wind production profiles are also modeled for each class and -region. In addition, to inform capacity credit and curtailment -calculations, we use hourly production data for each region and class. -Timeslice profiles are based on the 2012 weather year (though this can -be changed by the user), and hourly profiles are from the 2007-2013 -weather years. - -```{table} Land-Based Wind Class Definitions -:name: land-based-wind-class-def - -| Wind Class | Wind Speed Range (m/s) | Potential Wind Plant Capacity (GW) | -|------------|-----------------------:|-----------------------------------:| -| | | | -| 1 | \> 9.01 | 106 | -| 2 | 8.77 - 9.01 | 91 | -| 3 | 8.57 - 8.77 | 188 | -| 4 | 8.35 - 8.57 | 356 | -| 5 | 8.07 - 8.35 | 684 | -| 6 | 7.62 - 8.07 | 1,266 | -| 7 | 7.10 - 7.62 | 1,191 | -| 8 | 6.53 - 7.10 | 1,159 | -| 9 | 5.90 - 6.53 | 1,144 | -| 10 | \< 5.90 | 1,587 | - -``` - -More information can be found in the NREL Annual Technology Baseline -{cite}`nrel2020AnnualTechnology2020`. - -```{figure} ../../images/land-based-wind.png -:name: figure-land-based-wind - -Land-based wind resource availability and capacity factor for the three siting scenarios included in ReEDS. -``` - - -#### Offshore Wind - -There is substantial diversity in offshore wind generators, in distance -from shore, water depth, and resource quality. ReEDS subdivides offshore -wind potential into fourteen resource classes: seven each for -fixed-bottom and floating turbine designs. Fixed bottom offshore wind -development is limited to resources \< 60 meters \[m\] in depth using -either current-technology monopile foundations (0–30 m); or jacket -(truss-style) foundations (30–60 m). Offshore wind using a floating -anchorage could be developed for greater depths and are assumed the only -feasible technology for development for resource deeper than 60 m. -Within each category, the classes are distinguished by resource quality, -and then supply curves differentiate resource by cost of accessing -transmission in a similar fashion as land-based wind. - -Eligible offshore area for wind development includes open water within -the U.S.-exclusive economic zone having a water depth less than 1,000 m, -including the Great Lakes. As with land-based resource, offshore zones -are filtered to remove areas considered unsuitable for development, -including national marine sanctuaries, marine protected areas, wildlife -refuges, shipping and towing lanes, offshore platforms, and ocean -pipelines. The offshore technology selection is made using the Offshore -Wind Cost Model, which selects the most economically feasible technology -for developing a wind resource {cite}`beiterSpatialEconomicCostReductionPathway2016`. More than 4,900 -GW of technical offshore wind potential remain after applying the -exclusions. - -Current-day cost data are derived from the published data of the global -offshore wind industry as well as estimates from recent development -activity on the Atlantic Coast of the United States {cite:p}`musial2018OffshoreWind2019, nrel2019AnnualTechnology2019`. These data are coupled with engineering assessments and -distance-based cost functions (specific to the offshore export cable and -incremental construction cost associated with moving farther from shore) -to determine expected site-specific costs for technology across a broad -range of water depths and distances from shore {cite}`beiterAssessmentEconomicPotential2017`. -Cost and performance for offshore wind plants are based on assuming a -representative plant size of 600 MW. - -Other aspects of our model representations for offshore wind follow the -same methods as those for land-based wind {cite}`lopezLandUseTurbine2021b`. -{numref}`figure-offshore-wind-resource` shows the offshore wind resource potential -modeled in ReEDS for each of the 14 classes. Classes 1-7 represent fixed-bottom -offshore wind resources with class 1 representing the highest wind speeds. Classes -8-14 represent floating offshore wind resources with class 8 being the -highest wind speeds. The higher speed classes have smaller bin sizes to -capture the highest quality resources with greater resolution. - - - -```{table} Offshore Wind Class Definitions -:name: offshore-wind-class-def - -| Wind Class | | Wind Speed Range (m/s) | Potential Wind Plant Capacity (GW) | -|--------------|-----|-----------------------:|-----------------------------------:| -| Fixed-Bottom | 1 | \> 9.98 | 24 | -| | 2 | 9.31 - 9.98 | 23 | -| | 3 | 9.13 - 9.31 | 53 | -| | 4 | 8.85 - 9.13 | 97 | -| | 5 | 7.93 - 8.85 | 197 | -| | 6 | 7.07 - 7.93 | 396 | -| | 7 | \< 7.07 | 445 | -| Floating | 8 | \> 10.30 | 73 | -| | 9 | 10.18 - 10.30 | 71 | -| | 10 | 10.01 - 10.18 | 152 | -| | 11 | 9.60 - 10.01 | 293 | -| | 12 | 8.84 - 9.60 | 590 | -| | 13 | 7.43 - 8.84 | 1189 | -| | 14 | \< 7.43 | 1320 | -``` - -More information can be found in the NREL Annual Technology Baseline -{cite}`nrel2020AnnualTechnology2020`. - -```{figure} ../../images/offshore-wind-resource.png -:name: figure-offshore-wind-resource - -Offshore wind resource availability (fixed-bottom and floating) and capacity factor for the contiguous United States -``` - - -#### Solar Photovoltaics - -ReEDS differentiates among three solar photovoltaic technologies: -large-scale utility PV (UPV), distribution-side utility-scale PV (DUPV), -and rooftop PV. Investments in UPV and DUPV are evaluated directly in -ReEDS, while rooftop PV deployment and performance are exogenously input -into ReEDS from the dGen model. ReEDS further allows for investment in -hybrid systems comprising coupled UPV and battery technologies (PVB). - -UPV in ReEDS represents utility-scale, single-axis-tracking PV systems -with a representative size of 100 megawatts (MW), an array density of 39 -MW per square kilometer (km2), and an inverter loading ratio -of 1.3. Resource potential is assumed to be located on large parcels -outside urban boundaries, excluding federally protected lands, -inventoried “roadless” areas, U.S. Bureau of Land Management areas of -critical environmental concern, and areas with slope greater than 5%. -Each eligible UPV site is characterized by a raw hourly (8,760) -irradiance profile that is representative of the solar resource within a -10 km2 contiguous area. Each of these UPV sites are compiled -into supply curves for each of the 134 ReEDS BAs with 9 PV resource -classes, which are further differentiated by cost to connect to the -transmission network (process described in [Interzonal Transmission](#interzonal-transmission)). -The resource classes reflect different -resource qualities based on the annual average global horizontal -irradiance (GHI) reported by the latest National Solar Radiation -Database (NSRDB), assuming a tilt angle equal to the latitude ({numref}`upv-dupv-resource-classes`). -The UPV supply curves input into ReEDS for the conterminous U.S. include -156 terawatts (TW) of potential. - -```{table} UPV and DUPV Resource Classes -:name: upv-dupv-resource-classes - -| Class | GHI (kWh/m^2/day) | Potential UPV Capacity (GW) | Potential DUPV Capacity (GW) | -|---------|-------------------|-----------------------------|------------------------------| -| 1 | 3.0 - 3.5| 167| 14| -| 2 | 3.5 - 4.0| 16,870| 184| -| 3 | 4.0 - 4.5| 30,238| 434| -| 4 | 4.5 - 5.0| 37,438| 511| -| 5 | 5.0 - 5.5| 20,372| 222| -| 6 | 5.5 - 6.0| 11,868| 116| -| 7 | 6.0 - 6.5| 332| 4| - -``` - -Investment options along the UPV supply curve can take the form of -either standalone UPV systems or PVB systems. The default PVB technology -represents a loosely DC-coupled system: the PV and battery technologies -share a bi-directional inverter and point of interconnection, and the -battery can charge from either the coupled PV or the grid. The PVB -design characteristics can be user defined for up to three different -configurations, but the default configuration involves an inverter -loading ratio of 2.2 (slightly higher than standalone PV), and a coupled -battery with 4hr duration, whose power-rated capacity is 50% of the -inverter capacity. - -The PVB investment option leverages the existing representations of the -independent component technologies, but the cost and performance -characteristics differ from the simple sum of the separate (PV and -battery) parts. For example, the capital costs associated with the fully -integrated PVB hybrid system are reduced based on the cost of a shared -inverter and other balance-of-system components; as a result, the -percentage savings varies by PVB configuration. Improved performance -characteristics are captured through slightly enhanced battery round -trip efficiencies and explicit time series generation profiles; the -latter enables a representation of the PVB system’s ability to divert -otherwise-clipped energy to the coupled battery (during periods where -solar output exceeds the inverter capacity) and avoid curtailment. -Finally, a joint capacity credit results in a greater localized -contribution to resource adequacy, which is comparable overall to the -sum of capacity credits for separate PV and battery systems. - -```{figure} ../../images/upv-resource-availability.png -:name: figure-upv-resource-availabililty - -UPV resource availability and DC capacity factor -\[MWACavailable/MWDCnameplate\] -for the three siting scenarios included in ReEDS -``` - -DUPV systems have lower infrastructure requirements than large-scale -rural UPV systems; we assume they connect to existing nearby -distribution substations at about 13 kilovolts (kV), whereas the -representative UPV system connects to a high-voltage bus at 230 kV and -may require a spur line several miles long to reach that connection -point. The cost of the spur line is handled separately in the -accessibility supply curve ([Interzonal transmission](#interzonal-transmission)), but -the additional transformers and power electronics associated with the -larger systems and higher-voltage interconnections add cost and losses -to the UPV systems. On the other hand, the larger UPV systems benefit -from economies of scale. On balance, we assume a per-kW capital cost -penalty of 29%[^ref16] and 5% higher delivered energy (i.e., reduced -losses) for DUPV relative to UPV. - -Performance characteristics for UPV and DUPV were developed using NREL’s -reV Tool, using multiyear hourly weather files from the National Solar -Radiation Database[^ref17] at 4-km by 4-km parcels throughout the -contiguous United States from 1998 to 2016. No changes or improvements -in capacity factor over time are assumed for PV technologies. For each -ReEDS BA region, resource quality classifications were made by averaging -across the 1998–2016 period for all available parcels. Hourly generation -profiles were taken from 2007-2013. The generation profiles from 2012 -from all the regions in a BA for each resource class were averaged to -provide ReEDS with average capacity factors by time-slice and resource -class. - -To mitigate excessive wheeling of distributed PV generation, ReEDS -assumes all power generated by both DUPV and rooftop PV systems is -permitted to be exported to neighboring BAs only when total generation -in the source region exceeds the load for a given time-slice. -UPV-generated electricity, in contrast, can be exported in all -time-slices and regions. - -Degradation of the efficiency of solar PV capacity over time is also -modeled at 0.7%/year {cite}`nrel2020AnnualTechnology2020`. This degradation is modeled by reducing the generating capacity of PV by 0.7%/year. - -Rooftop PV includes commercial, industrial, and residential systems. -These systems are assumed to have an inverter loading ratio of 1.1. The -Distributed Generation Market Demand model (dGen), a consumer adoption -model for the contiguous U.S. rooftop PV market, is used to develop -future scenarios for rooftop PV capacity, including the capacity -deployed by BA and the pre-curtailment energy production by that -capacity {cite}`sigrinDistributedGenerationMarket2016`. The default dGen trajectories used in -this version of ReEDS are based on the residential and commercial PV -cost projections as described in the 2020 {cite}`nationalrenewableenergylaboratoryAnnualTechnologyBaseline2020`. There are 11 -unique rooftop PV trajectories available in ReEDS that are from the 2020 -Standard Scenarios report {cite}`cole2020StandardScenarios2020`. These -trajectories were created by running a ReEDS scenario and feeding the -electricity price outputs from ReEDS back into dGen. The trajectories -incorporate existing net metering policy as of spring 2020, and they -include the investment tax credit (ITC) as discussed in [Federal and State Tax Incentives](#federal-and-state-tax-incentives). - -Assumptions for each dGen scenario are made consistent with the ReEDS -scenario assumptions as much as is possible. For example, the Tax Credit -Extension scenario also includes an extension of the ITC in dGen, and -the Low PV Cost scenario uses low trajectory from ATB for commercial and -rooftop PV costs. - - -#### Concentrating Solar Power - -Concentrating solar power (CSP) technology options in ReEDS encompass a -subset of possible thermal system configurations, with and without -thermal storage, as shown in {numref}`csp-tech-characteristics`. The various system types access -the same resource potential, which is divided into 3 resource classes -based on direct normal insolation (DNI) ({numref}`csp-solar-resource-classes`). The CSP resource and -technical potential are based on the latest version of NSRDB. Details of -the CSP resource data and technology representation can be found in -Appendix B of Murphy et al. {cite:year}`murphyPotentialRoleConcentrating2019a`. By default, recirculating and dry -cooling systems are allowed for future CSP plants getting built in -ReEDS. CSP cost and performance estimates are a based on an assumed -plant size of 100 MW. - -```{table} Characteristics of CSP Technology Options -:name: csp-tech-characteristics - -| Storage Duration (hours) | Solar Multiple[^ref18] | Dispatchability | Capacity Credit | Curtailment | -|----|----|----|----|----| -| None | 1.4 | insolation-dependent | Calculated based on hourly insolation | Allowed | -| 6 | 1.0 | dispatchable | Calculated based on storage duration and hourly insolation | Not allowed | -| 8 | 1.3 | dispatchable | Calculated based on storage duration and hourly insolation | Not allowed | -| 10 | 2.4 | dispatchable | Calculated based on storage duration and hourly insolation | Not allowed | -| 14 | 2.7 | dispatchable | Calculated based on storage duration and hourly insolation | Not allowed | - -``` - -The CSP resource classes are defined by power density of DNI, -developable land area having been filtered based on land cover type, -slope, and protected status. CSP resource in each region is therefore -represented as a supply curve of megawatts of solar collector potential, -assuming a power density of 14.9 MW/km.2 Performance for each -CSP resource class is developed using 2012 hourly resource data -{cite}`senguptaNationalSolarRadiation2018` from representative sites of each region. The -2012 weather files are processed through the CSP modules of the System -Advisor Model (SAM) to develop performance characteristics for each CSP -resource class and representative CSP system considered in ReEDS. CSP -capacity credit calculations are based on hourly profiles from -2007-2013. As with wind and PV technologies, CSP resources are further -distinguished by grid accessibility in each region ([Interzonal Transmission](#interzonal-transmission)). - -```{table} Resource Classes for CSP Plants Using a Solar Multiple (SM) of 2.4 -:name: csp-solar-resource-classes - -| Resource Class | DNI (kWh/m^2/day) | Weighted Average Field CF for SM=1 system (%)^a | Available Resource (GW) | -|------------------|-------------------|-------------------------------------------------|-------------------------| -| Class 1 | 5 - 5.25| 17| 2,641| -| Class 2 | 5.25 - 5.5| 18| 1,925| -| Class 3 | 5.5 - 5.75| 19| 1,495| -| Class 4 | 5.75 - 6| 20| 1,725| -| Class 5 | 6 - 6.25| 21| 1,850| -| Class 6 | 6.25 – 6.5| 22| 1,282| -| Class 7 | 6.5 – 6.75| 23| 1,252| -| Class 8 | 6.75 – 7| 24| 1,098| -| Class 9 | 7 – 7.25| 26| 1,381| -| Class 10 | 7.25 – 7.5| 27| 1,251| -| Class 11 | 7.5 – 7.75| 28| 677| -| Class 12 | >7.75| 29| 114| - -``` - -Resources are then scaled in ReEDS by the ratio of the model-determined -SM and 2.4. - -a The field capacity factors (CF) shown here are from SAM -(version 2017.09.05, SDK version 181) simulation assuming an SM=1 -system. This field capacity factor is meant to represent the upper limit -of corresponding turbine capacity factor for all systems with SM\>1. - -The representative CSP system without storage used to define system -performance in ReEDS is a 100-MW trough system with a SM of 1.4. As CSP -systems without storage are non-dispatchable, output capacity factors -are defined directly from SAM results. The average annual capacity -factors for the solar fields of these systems range from 20% (Class 1 -resource) to 29% (Class 12 resource). - -```{figure} ../../images/csp-resource-availability.png -:name: figure-csp-resource-availability - -CSP resource availability and solar field capacity factor for the contiguous United States -``` - -The representative system for any new CSP with thermal energy storage is -a tower-based configuration with a molten-salt heat-transfer fluid and a -thermal storage tank between the heliostat array and the steam -turbine.[^ref19] Two CSP with storage configurations are available as shown -in {numref}`csp-tech-characteristics`. - -For CSP with storage, plant turbine capacity factors by time-slice are -an output of the model, not an input, as ReEDS can dispatch collected -CSP energy independent of irradiation. Instead, the profile of power -input from the collectors (solar field) of the CSP plants are model -inputs, based on SAM simulations from 2012 weather files. - -The capacity credit of CSP with storage is calculated using the same -method as the calculation of the capacity credit of other storage -technologies, except that rather than using net load to show -opportunities to charge, DNI resource is used to show opportunities to -charge the storage. See ["Stress periods” formulation](#stress-periods-formulation) for details. - - -#### Geothermal - -The ReEDS representation of geothermal power was substantial -restructured compared to the prior ReEDS documentation. - -The geothermal resource has two distinct subcategories in ReEDS: - -- The hydrothermal resource represents potential sites with appropriate - geological characteristics for the extraction of heat energy. The - hydrothermal potential included in the base supply curve consists of - only identified sites, with a separate supply curve representing the - undiscovered hydrothermal resource. - -- EGS sites are geothermal resources that have sufficient temperature - but lack the natural permeability, in-situ fluids, or both to be - hydrothermal systems. Developing these sites with water injection - wells could create engineered geothermal reservoirs appropriate for - harvesting heat. - -EGS is further separated into Near-Field EGS and Deep EGS based upon -proximity to known hydrothermal features. Near-Field EGS represents -additional geothermal resource available near hydrothermal fields -which have been identified. Deep EGS represents available geothermal -resource not tied to existing hydrothermal sites and at depths below -3.5 km. - -Geothermal in ReEDS represents a geothermal power production with -representative size up to 100 megawatts electric (MWe). -Geothermal resource classes are defined by reservoir temperature -ranges which are closely linked to the cost of a plant normalized by -generation capacity. Energy conversion processes, binary and flash -cycles are linked to reservoir temperature and are specified by -resource class. Plants with reservoir temperatures \< 200 °C (Class -7-10) use a binary cycle, which uses a heat exchanger and secondary -working fluid with a lower boiling point to drive a turbine. All other -reservoir temperatures assume that a turbine is driven directly by -working fluid from the geothermal wells. These assumptions are aligned -with those in ATB 2023. - -{numref}`technical-resource-potential` lists the technical resource potential for the different geothermal categories. - -```{table} Technical Resource Potential (GW) -:name: technical-resource-potential - -| **Resource Class** | Reservoir Temperature **(°C)** | **Hydrothermal** | **Near-Field EGS** | **Deep EGS** | -|:--:|:--:|:--:|:--:|:--:| -| Class 1 | \> 325 | \- | 0.2 | \- | -| Class 2 | 300 – 325 | 1.8 | 0.2 | \- | -| Class 3 | 275 – 300 | 9.3 | 0.1 | 1.2 | -| Class 4 | 250 – 275 | 0.7 | 0.1 | 8.2 | -| Class 5 | 225 – 250 | 1.1 | 0.1 | 74 | -| Class 6 | 200 – 225 | 2.4 | 0.2 | 320 | -| Class 7 | 175 – 200 | 0.2 | 0.3 | 709 | -| Class 8 | 150 – 175 | 2.6 | 0.3 | 995 | -| Class 9 | 125 – 150 | 1.1 | 0.03 | 1270 | -| Class 10 | \< 125 | 4.7 | \- | \- | -| Total | | 23.9 | 1.4 | 3,375 | -``` - -The default geothermal resource assumptions allow for hydrothermal -sites. Hydrothermal resources have a defined fraction which are -considered identified resources based upon the U.S. Geological Survey’s -2008 geothermal resource assessment. The undiscovered portion of the -hydrothermal resource is limited by a discovery rate defined as part of -the GeoVision Study {cite}`doeGeoVisionHarnessingHeat2019`. The geothermal supply curves are based -on the analysis described by Augustine et al. {cite:year}`augustineGeoVisionAnalysisSupporting2019` and are shown in -{numref}`figure-csp-resource-availability`. The hydrothermal and near-field EGS resource potential is -derived from the U.S. Geological Survey’s 2008 geothermal resource -assessment {cite}`williamsReviewMethodsApplied2008a`, while the deep EGS -resource potential is based on an update of the EGS potential from the -Massachusetts Institute of Technology {cite}`testerFutureGeothermalEnergy2006`. As -with other technologies, geothermal cost and performance projections are from -the ATB {cite}`nrel2023AnnualTechnology2023`. Alternate resource supply curves can be -incorporated from reV analysis but are currently not part of the default -resource representation. Spurline transmission costs are available when -using reV based supply curves. - - -#### Hydropower - -The existing hydropower fleet representation is informed by historical -performance data. From the nominal hydropower capacity in each BA, -seasonal capacity adjustments are used for Western Electricity -Coordinating Council (WECC) regions based on data from the Transmission -Expansion Planning Policy Committee (TEPPC) 2024 Common Case -{cite:p}`wecc2013InterconnectionwidePlan2013a, weccTEPPCStudyReport2015`. Seasonal capacity adjustments allow more realistic seasonal -variations in maximum capacity due to changes in water availability and -operating constraints. These data are not available for non-WECC -regions. Future energy availability for the existing fleet is defined -seasonally using plant-specific hydropower capacity factors averaged for -2010–2019 as reported by Oak Ridge National Laboratory HydroSource data -(). Capacity factors for historical -years are calibrated from the same data source so that modeled -generation matches historical generation. PSH, both existing and new, is -discussed in [Storage Technologies](#storage-technologies). Generally, the -seasonal energy allocation for hydropower must remain in the predefined -season, but ReEDS has the option of allowing a fraction of available -energy to be shifted across seasons, up to 100% of the total. - -Three categories of new hydropower resource potential are represented in -the model: - -1. Upgrade and expansion potential for existing hydropower - -2. Potential for powering non-powered dams (NPD) - -3. New stream-reach development potential (NSD). - -The supply curves for each are discussed in detail in the Hydropower -Vision report {cite}`doeHydropowerVisionNew2016`, particularly Chapter 3 and Appendix B. - -ReEDS does not currently distinguish between different types of -hydropower upgrades, so upgrade potential is nominally represented -generically as a potential for capacity growth that is assumed to have -the same energy production potential per capacity (i.e., capacity -factor) as the corresponding existing hydropower capacity in the region. -An optional representation of hydropower upgrades decouples capacity and -energy upgrades so that the model can choose either type of upgrade -independently. The quantity of available upgrades is derived from a -combination of limited resource assessments and case studies by the U.S. -Bureau of Reclamation Hydropower Modernization Initiative (HMI), U.S. -Army Corps of Engineers (Corps), and NHAAP Hydropower Advancement -Project {cite:p}`montgomeryHydropowerModernizationInitiative2009, bureauofreclamationHydropowerResourceAssessment2011`. -Upgrade availability at federal facilities not included in the -HMI is assumed to be the HMI average of 8% of the rated capacity, and -upgrade availability at non-federal facilities is assumed to be the -NHAAP average of 10% of the rated capacity. Rather than making all -upgrade potential available immediately, upgrade potential is made -available over time at the earlier of either (1) the Federal Energy -Regulatory Commission (FERC) license expiration (if applicable) or (2) -the turbine age reaching 50 years. This feature better reflects -institutional barriers and industry practices surrounding hydropower -facility upgrades. The total upgrade potential from this methodology is -6.9 GW (27 TWh/yr). - -```{figure} ../../images/hydro-vision-upgrade-resource-potential.png -:name: figure-hydro-vision-upgrade-resource-potential - -Modeled hydropower upgrade resource potential {cite}`doeHydropowerVisionNew2016` -``` - -NPD resource is derived from the 2012 NHAAP NPD resource assessment -{cite}`kaoNewStreamreachDevelopment2014, hadjeriouaAssessmentEnergyPotential2013`, where the -modeled resource of 5.0 GW (27 TWh/yr) reflects an updated site sizing -methodology, data corrections, and an exclusion of sites under 500 kW to -allow better model resolution for more economic sites. - -```{figure} ../../images/hydro-vision-npd-resource-potential.png -:name: figure-hydro-vision-npd-resource-potential - -Modeled non-powered dam resource potential {cite}`doeHydropowerVisionNew2016` -``` - -NSD resource is based on the 2014 NHAAP NSD resource assessment {cite}`kaoNewStreamreachDevelopment2014`, where the modeled resource of 30.7 GW (176 TWh/yr) reflects -the same sizing methodology as NPD and a sub-1 MW site exclusion, again -to improve model resolution for lower-cost resource. The NSD resource -assumes “low head” sites inundating no more than the 100-year flood -plain and excludes sites within areas statutorily barred from -development—national parks, wild and scenic rivers, and wilderness -areas. - -```{figure} ../../images/hydro-vision-nsd-resource-potential.png -:name: figure-hydro-vision-nsd-resource-potential - -Modeled new stream-reach development resource potential {cite}`doeHydropowerVisionNew2016` -``` - -The combined hydropower capacity coupled with the costs from the ATB {cite}`nrel2023AnnualTechnology2023` results in the supply curve shown in {numref}`figure-hydro-vision-nsd-resource-potential`. - -```{figure} ../../images/hydro-supply-curve.png -:name: figure-hydro-supply-curve - -National hydropower supply curve of capital cost versus cumulative capacity potential -``` - -The hydropower operating parameters and constraints included in ReEDS do -not fully reflect the complex set of operating constraints on hydropower -in the real world. Detailed site-specific considerations involving a -full set of water management challenges are not easily represented in a -model with the scale and scope of ReEDS, but several available -parameters allow a stylized representation of actual hydropower -operating constraints {cite}`stollHydropowerModelingChallenges2017`. - -Each hydropower category can be differentiated into “dispatchable” or -“non-dispatchable” capacity, with “dispatchable” defined in ReEDS as the -ability to provide the following services: - -1. Diurnal load following within the capacity and average daily energy limits for each season - -2. Planning (adequacy) reserves with full rated capacity - -3. Operating reserves up to a specified fraction of rated capacity if - the capacity is not currently being utilized for energy production. - -“Non-dispatchable” capacity, on the other hand, provides: - -1. Constant energy output in each season such that all available energy is utilized - -2. Planning reserves equal to the output power for each season - -3. No operating reserves. - -Dispatchable capacity is also parameterized by a fractional minimum -load, with the maximum fractional capacity available for operating -reserves as one minus the fractional minimum load. The existing fleet -and its corresponding upgrade potential are differentiated by -dispatchability using data from the Oak Ridge National Laboratory -Existing Hydropower Assets Plant Database -(), which classifies plants -by operating mode. Plants with operating modes labeled as Peaking, -Intermediate Peaking, Run-of-River/Upstream Peaking, and -Run-of-River/Peaking are classified as dispatchable in ReEDS, and plants -with other operating modes are classified as non-dispatchable. In total, -47% of existing capacity and 49% of upgrade potential is assumed -non-dispatchable. ReEDS also includes the option to enable hydropower -upgrade pathways where existing non-dispatchable hydropower can be -upgraded to be dispatchable hydropower, or existing dispatchable -hydropower can be upgraded to add pumping and become a pump-back -hydropower facility. A pump-back facility is constrained similarly to a -PSH facility except that input energy can come from natural water -inflows in addition to the grid. These upgrade options can be made -available at a user-specified capital cost. Hydropower upgrades are -unavailable by default because it there is high uncertainty about where -such upgrades are feasible, but these optional features allow users to -explore the potential and value of increasing hydropower fleet -flexibility, which is discussed in detail in {cite}`cohenAdvancedHydropowerPSH2022`. - -The same TEPPC database is used to define region-specific fractional -minimum capacity for dispatchable existing and upgrade hydropower in -WECC. Lacking minimum capacity data for non-WECC regions, 0.5 is chosen -as a reasonable fractional minimum capacity. - -Both the NPD and NSD resource assessments implicitly assume inflexible, -run-of-river hydropower, so all NPD and NSD resource potential is -assumed non-dispatchable. Additional site-specific analysis could allow -re-categorizing portions of these resources as dispatchable, but 100% -non-dispatchable remains the default assumption. - - -#### Biopower - -ReEDS can generate electricity from biomass either in dedicated biomass -integrated gasification combined cycle (IGCC) plants or cofired with -coal in facilities that have been retrofitted with an auxiliary fuel -feed. These cofire-ready coal plants can use biomass in place of coal to -supply the fuel for up to 15% of the plant’s electricity generation. A -cofire retrofit costs 305 \$2017/kW based on EIA’s Electricity Market -Module assumptions {cite}`eiaElectricityMarketModule2017a{101}`. - -Dedicated and cofired plants source feedstock from the same biomass -supply curves, which are derived from the Oak Ridge National -Laboratory’s *2016 Billion-Ton Report* {cite}`u.s.departmentofenergy2016BillionTonReport2016`. -Data from this report includes estimates of biomass feedstock costs and -total resource availability. Only woody biomass resources are allowed to -be used for biopower plants. No other resource constraints are applied -for nonrenewable energy technologies. - -{numref}`figure-biomass-supply-curve-regions` illustrates the resource map and total supply curve by region -as derived from the *2016 Billion-Ton Report* and used in ReEDS. -Nationally, approximately 116 million dry tons of woody biomass are -assumed to be available to the power sector. In addition to the supply -curve price (which represents the cost of the resource in the field), -ReEDS also assumes costs of \$15 per dry ton for collection and -harvesting, as well as an additional \$15 per dry ton for transport, as -based on estimates from a 2014 INL study {cite}`jacobsonFeedstockConversionSupply2014`. -Pathways with more limited biomass model the impact of a halving of the -available resource and a doubling of collection, harvesting, and -transport costs (58 million dry tons and \$60 per ton), whereas the -enhanced resource scenario models the opposite (doubling the available -resource to 232 million dry tons and halving collection, harvesting, and -transport costs to \$15 per ton). - -```{figure} ../../images/biomass-supply-curve-regions.png -:name: figure-biomass-supply-curve-regions - -Depiction of the regions used for the biomass supply curves (map, top left), based on U.S. Department of Agriculture regional divisions. The line plots to the right indicate the woody biomass supply curves for each region as used in ReEDS, as derived from data in 2016 Billion-Ton Report. The bottom-left plot summarizes the total national supply curve. -``` - -Because the model assumes zero lifecycle emissions for biomass, -generation sources that use biomass with carbon capture and storage -(BECCS) are assumed to be negative emissions. {numref}`beccs-assumptions` summarizes cost -and performance assumptions for BECCS plants. The uncontrolled emissions -rate of woody biomass fuel is assumed to be 88.5 kg/MMBtu {cite}`bainBiopowerTechnicalAssessment2003`; -after accounting for the heat rate of a BECCS plant and a 90% CCS -capture rate, the negative emissions are approximately -1.22 to -1.11 -tonnes/MWh of generation. Fuel consumed in BECCS plants is counted -against the total biomass supply curve described above. - -```{table} Cost and Performance Assumptions for BECCS -:name: beccs-assumptions - -| BECCS | Capital Cost (\$/kW) | Variable O&M (\$/kWh) | Fixed O&M (\$/kW-yr) | Heat Rate (MMBtu/MWh) | Emissions Rate (tonnes CO2/MWh) | -|----|:--:|:--:|:--:|:--:|:--:| -| 2020 | 5,580 | 16.6 | 162 | 15.295 | -1.22 | -| 2035 | 5,333 | 16.6 | 162 | 14.554 | -1.16 | -| 2050 | 5,100 | 16.6 | 162 | 13.861 | -1.11 | -``` - -#### Marine Hydrokinetic Wave - -ReEDS does have a representation of marine hydrokinetic wave -technologies, but this capability is not utilized in any of the recent -or current ReEDS modeling work. - - -### Conventional Energy Technologies - -ReEDS includes all major categories of conventional generation -technologies within its operating fleet or its investment choices. In -the context of ReEDS, “conventional” is defined as thermal generating -technologies driven by coal, gas, oil, or nuclear fuel. Coal -technologies are subdivided into pulverized and gasified (IGCC) -categories, with the pulverized plants further distinguished by 1) -whether SO2 scrubbers are installed and 2) their vintage[^ref20] -as pre- or post-1995. Pulverized coal plants have the option of adding a -second fuel feed for biomass. New coal plants can be added with or -without CCS technology. Existing coal units built after 1995 with -SO2 scrubbers installed also have the option of retrofitting -CCS capability. - -Natural gas generators are categorized as combustion turbine (CT), -combined cycle (CC), or gas-CC with CCS.[^ref21] There are also nuclear -(steam) generators, landfill gas generators,[^ref22] and oil/gas steam -generators, though the latter two are not offered as options for new -construction besides those that are already under construction. The -model distinguishes each conventional-generating technology by costs, -efficiency, and operational constraints. - -Where renewable energy technologies have many unique characteristics, -ReEDS conventional technologies are characterized more generally by the -following parameters: - -- Capital cost (\$/MW) - -- Fixed and variable operating costs (dollars per megawatt-hour - \[\$/MWh\]) - -- Fuel costs (dollars per million British thermal units - \[\$/MMBtu\]) - -- Heat rate (MMBtu/MWh) - -- Construction period (years) and expenses - -- Equipment lifetime (years) - -- Financing costs (such as interest rate, loan period, debt fraction, - and debt-service-coverage ratio) - -- Tax credits (investment or production) - -- Minimum turndown ratio (%) - -- Ramp rate (fraction per minute) - -- Planned and unplanned outage rates (%). - -Cost and performance assumptions for all new conventional technologies -are taken from the ATB {cite}`nrel2023AnnualTechnology2023`. Regional variations and adjustments -are included and described in [Hydrogen](#hydrogen). Fixed operation and -maintenance costs for coal and nuclear plants increase over time with -the plants age. These escalation factors are taken from the -AEO2023. - -In addition to the performance parameters listed above, technologies -are differentiated by their ability to provide operating reserves. In -general, natural gas plants, especially combustion turbines, are better -suited for ramping and reserve provision, while coal and nuclear plants -are typically designed for steady operation. See [Operational Reliability](#operational-reliability) for more -details. - -The existing fleet of generators in ReEDS is taken from the NEMS unit -database from AEO2023 {cite}`eiaAnnualEnergyOutlook2023`, with data supplemented from the June -2023 EIA 860M. In particular, ReEDS uses the net summer capacity, net -winter capacity,[^ref23] location, heat rate, variable O&M, and fixed O&M -to characterize the existing fleet. ReEDS uses a modified “average” heat -rate for any builds occurring after 2010: a small, technology-specific -increase on the full-load heat rate is applied to accommodate for units -not always operating at their design point. The modifiers, shown in -{numref}`heat-rate-adjustments`, are based on the relationship between the reported heat rate -the ATB, and the actual observed heat rate, calculated on a fleet-wide -basis for each fuel type. - -```{table} Multipliers Applied to Full-Load Heat Rates to Approximate Actual Observed Heat Rates -:name: heat-rate-adjustments - -| **Technology** | **Adjustment Factor** | -|----|:--:| -| Coal (all) | 1.066 | -| Gas-CC | 1.076 | -| Gas-CT | 1.039 | -| OGS | 0.875 | -``` - -Emissions rates from conventional plants are a function of the fuel -emission rate and the plant heat rate. Burner-tip emissions rates are -shown in {numref}`emissions-rate-by-generator-type`. Because ReEDS does not differentiate coal fuel types, -the coal CO2 emissions rate in the model is the average of -the bituminous and subbituminous emissions -rate.[^ref24] - -```{table} Emissions Rate by Generator Type in Pounds per MMBtu a b -:name: emissions-rate-by-generator-type - -| Generator | SO2 Emissions Rate | NOx Emissions Rate | CO2 Emissions Rate | -|-------------|-------------------------------|-------------------------------|-------------------------------| -| Hydropower | 0.0 | 0.0 | 0.0 | -| Gas-CT | 0.0098 | 0.15 | 117.00 | -| Gas-CC | 0.0033 | 0.02 | 117.00 | -| Gas-CC-CCS | 0.0033 | 0.02 | 11.70 | -| Pulverized Coal with Scrubbers (pre-1995) | 0.2 | 0.19 | 210.55 | -| Pulverized Coal with Scrubbers (post-1995) | 0.1 | 0.08 | 210.55 | -| Pulverized Coal without Scrubbers | 1.11 | 0.19 | 210.55 | -| IGCC Coal | 0.0555 | 0.085 | 210.55 | -| Coal-CCS | 0.0555 | 0.085 | 21.06 | -| Oil/Gas Steam | 0.299 | 0.1723 | 137.00 | -| Nuclear | 0.0 | 0.0 | 0.0 | -| Geothermal | 0.0 | 0.0 | 0.0 | -| Biopower | 0.08 | 0.0 | 0.0 | - -``` -> a {cite}`epaEGRID2007Version1Year2008` - -> b The assumed CO2 pollutant rate for land-fill -> gas is zero, so ReEDS does not see the emissions benefits of land-fill -> gas. However, ReEDS can track land-fill gas emissions and the -> associated benefits as a post-processing calculation. Land-fill gas is -> assumed to have negative effective carbon emissions because the -> methane gas would be flared otherwise, thereby it produces the less -> potent greenhouse gas. - -Not all parameter data are given in this document. For those values not -included here, see the NREL ATB {cite}`nrel2023AnnualTechnology2023`, or see the values in the -ReEDS repository.[^ref25]. Financing parameters and calculations are -discussed in [Capital Financing, System Costs, and Economic Metrics](#capital-financing-system-costs-and-economicmetrics). - - -### Storage Technologies - -ReEDS includes three utility-scale energy storage options[^ref26]: PSH, -batteries, and CAES. All three storage options are capable of load -shifting (arbitrage), providing planning and operating reserves, and -reducing curtailment of VRE. By default, load shifting can be done only -within a season’s representative day, but ReEDS has options to allow -load shifting across representative days while requiring a specified -fraction of charging energy to be deployed as generation in that day. -Generally, load shifting is accomplished by charging the reservoir -during inexpensive low-demand time-slices and discharging at peak times. -The nameplate capacity of storage can contribute toward planning -reserves (though at a potentially reduced rate, see [Network reinforcement](#network-reinforcement)), and -capacity not being used for charge or discharging can be utilized to -provide any of the operating reserves products represented in ReEDS (see -[Electricity System Operation and Reliability](#electricity-system-operation-and-reliability) -on how reserves are differentiated in ReEDS). An energy -penalty is associated with storage to provide regulation reserves that -reflect losses due to charging and discharging. Storage is also required -to have sufficient charge to provide operating reserves in addition to -any charge already required for generation in appropriate timeslice. -Batteries are represented with durations of 2, 4, 6, 8, and 10 hours, -CAES is assumed to have a duration of 12 hours, and the PSH storage -duration is either 8, 10, or 12 hours depending on the chosen PSH supply -curve. - -The ReEDS framework also allows for standalone thermal energy storage, -though this technology is inactive by default because its site-specific -nature makes it difficult to include in a nationwide optimization -framework. This technology is representative of chilled water and ice -storage units in buildings where, during the summer, cold water or ice -is produced during cooler hours when loads are lower and used to replace -or supplement the air conditioning during the warmer hours. Only units -for commercial buildings are considered. A supply curve for thermal -energy storage units was developed at the NERC subregions level. The -model restricts the use of thermal energy storage devices by the -regional cooling load profile, with power delivered from thermal energy -storage available only during times of high cooling load (e.g., summer -afternoons). Thermal energy storage technologies can contribute to -operating and planning reserves and reduce -curtailment. - -Although storage is neither directly linked nor assumed co-located with -renewable energy technologies in ReEDS, it can play an important role in -reducing curtailed electricity from variable generation resources by -charging during time-slices with excess renewable generation. The -ability of storage to reduce curtailment is calculated endogenously. - -Existing PSH totals 22 GW, and ReEDS includes the existing CAES -facility in Alabama. New PSH and CAES are location-restricted due to -hydrology and topography (for PSH) and geology (for CAES). There is also -an option to require new PSH to purchase water access from water supply -curves in order to fill new PSH reservoirs, and this constraint can add -cost and further restrict PSH deployment. In contrast, utility-scale -batteries are not restricted to any subset of -regions. - -New PSH potential is derived from a national PSH resource assessment -described in Rosenlieb and Cohen 2022 and at -. Several PSH supply -curves are available in ReEDS, including alternative storage durations -(8, 10, or 12 hours) and alternative environmental site exclusions, -specifically whether or not new PSH reservoir construction can occur -where there are ephemeral streams as defined by the National Hydrography -Dataset. The PSH resource assessment includes site-level capital costs -calculated from a parametric model that incorporates dam, reservoir, and -other site characteristics. PSH fixed O&M costs and round-trip -efficiency are taken from Mongird et al., 2020, and PSH cost and -resource assumptions are also documented on the NREL ATB website -(www.atb.nrel.gov). - -CAES site development costs are estimated based on the underground -geology, where domal salt is the least costly resource at \$1170/kW -(22.6 GW available), bedded salt is the next most costly resource at -\$1,420/kW (37.0 GW), and aquifers (porous rock) are the most costly -resource at \$1,680/kW (61.6 GW) {cite:p}`blackveatchCostPerformanceData2012b, lazardLazardLevelizedCost2016`. -[^ref27] CAES requires a natural gas fuel input when supplying power -output, and its heat rate is assumed to be 4.91 MMBtu/MWh. This -additional fuel input (to the electrical power input during compression) -results in a round-trip efficiency of 125%. - -Battery cost and performance assumptions are based on lithium-ion -battery systems, with costs taken from Cole and Frazier {cite:year}`coleCostProjectionsUtilityScale2020`. Low, mid, and high cost projections are available and scale with the -user-defined battery duration. In contrast to all other generator -technologies in ReEDS which have lifetimes that meet or exceed typical -model evaluation windows for book life, the battery is assumed to last -15 years. As a result, its capital cost is uprated by the ratio of a -15-year evaluation window and the evaluation window used by the run. The -batteries are assumed to have a round-trip efficiency of 85%. The -contribution of storage toward the reserve margin requirement is -discussed in [Resource Adequacy](#resource-adequacy). Battery storage has a representative size of -60 MW. Finally, we apply a minimum VOM of \$0.01/MWh (in 2004\$) to all -storage to avoid degeneracy with renewable energy -curtailment. - - -### Hydrogen - -ReEDS has the capability of modeling the use of hydrogen, both as a -form of seasonal storage to meet power system requirements and as a -clean fuel produced by the power sector for use in other -sectors. - -In the power sector, hydrogen can be consumed as a fuel in Hydrogen -Combustion Turbines (H2-CTs). H2-CTs are comparable to commercial gas -turbines but can be fired with hydrogen {cite:p}`mitsubishiIntermountainPowerAgency2020, ruthTechnicalEconomicPotential2020`. -H2-CTs are assumed to have the same heat rate and operation and -maintenance (O&M) cost as regular gas-fired combustion turbines (see -[Conventional Energy Technologies](#conventional-energy-technologies)) but with a 20% higher overnight capital cost, slightly -higher than the 10% value reported by Ruth et al. {cite:year}`ruthTechnicalEconomicPotential2020` in order to -allow the H2-CT to be clutched and act as a synchronous generator. -Existing gas generators can be upgraded to this H2-CT technology by -paying the 20% difference in capital cost between the two -generators. - -Power sector hydrogen use is determined by the model’s optimization; as -with natural gas plants and other fuel-based generators, weighs the -costs of investment in H2-CTs and procuring hydrogen against other -options for serving load and meeting other power system constraints. In -contrast, demand for hydrogen produced by the power sector but used -externally in other sectors is specifically exogenously as an input. -This demand is intended to capture hydrogen used in sector such as -transportation or industry and can be specified in terms of a total -national hydrogen by year. - -The model includes a range of options for representing the production, -transport and storage or hydrogen, as well as the spatial resolution of -at which hydrogen demand is serviced. These options include: (1) as a -drop-in renewable fuel with a fixed price, (2) endogenous representation -of production with national balancing, and (3) endogenous representation -of production with zonal balancing. Each of these representations is -discussed in more detail below. - - -#### Drop-in renewable fuel - -The first approach models hydrogen as a drop-in renewable fuel that is -available in unlimited quantity at a fixed price (\$/MMBtu). The default -fuel costs for this approach are assumed to be \$20/MMBtu, which is -consistent with estimates of the costs for hydrogen produced using an -electrolyzer powered by dedicated wind or PV; for example, Mahone et al. -{cite:year}`mahoneHydrogenOpportunitiesLowCarbon2020` report a range of \$7–35/MMBtu. This estimate also falls within -the range of current ethanol (\$12/MMBtu) and biodiesel (\$30/MMBtu) -prices {cite}`doeAlternativeFuelPrice2020`. It is also consistent with Hargreaves and Jones -{cite:year}`hargreavesLongTermEnergy2020` which reports \$20/MMBtu for carbon-neutral biogas. As this is -the only hydrogen cost modeled with this approach, this fuel cost -represents an “all-in” cost that includes the cost of production, -delivery, and storage of hydrogen. Users can specify different -trajectories for fuel costs over time. - -Under the drop-in renewable fuel approach, the use of curtailed -renewable energy for H2-CT fuel production is not explicitly considered; -to capture this dynamic the production of hydrogen must be endogenously -modeled in ReEDS, which is described in the next section. - - -#### Endogenous production with national balancing - -In this approach hydrogen production is explicitly represented via two -pathways: electrolysis and steam methane reforming (SMR). For either -pathway, ReEDS must invest in sufficient electrolyzer or SMR capacity to -meet hydrogen demands. {numref}`hydrogen-production-assumptions-a`, {numref}`hydrogen-production-assumptions-b`, -and {numref}`hydrogen-production-assumptions-c` summarize the cost and performance data -on the hydrogen production technologies represented in ReEDS. - -```{table} Cost and Performance Assumptions for Hydrogen Production Technologies. Costs are reported in \$2022. -:name: hydrogen-production-assumptions-a - -| Electrolyzer | Capital Cost (\$/kW) | Variable O&Ma (\$/kWh) | Fixed O&M (\$/kW-yr) | Electricity Use (kWh/kg) | Natural Gas Use (MMBtu/kg) | -|:--:|:--:|:--:|:--:|:--:|:--:| -| 2020 | 1,750 | 0 | 101.9 | 56.1 | -- | -| 2035 | 550 | 0 | 32.0 | 53.8 | -- | -| 2050 | 550 | 0 | 25.0 | 51.5 | -- | - -``` - -```{table} Cost and Performance Assumptions for Hydrogen Production Technologies. Costs are reported in \$2022. -:name: hydrogen-production-assumptions-b -| SMR | Capital Cost (\$/kg/day) | Variable O&M (\$/kg) | Fixed O&M (\$/kg/day-yr) | Electricity Use (kWh/kg) | Natural Gas Use (MMBtu/kg) | -|:--:|:--:|:--:|:--:|:--:|:--:| -| 2020 | 649 | 0.087 | 20.9 | 0.88 | 0.192 | -| 2035 | 634 | 0.087 | 20.4 | 0.88 | 0.192 | -| 2050 | 622 | 0.087 | 20.0 | 0.88 | 0.192 | -``` - -```{table} Cost and Performance Assumptions for Hydrogen Production Technologies. Costs are reported in \$2022. -:name: hydrogen-production-assumptions-c - -| SMR-CCS | Capital Cost (\$/kg/day) | Variable O&M (\$/kg) | Fixed O&M (\$/kg/day-yr) | Electricity Use (kWh/kg) | Natural Gas Use (MMBtu/kg) | -|:--:|:--:|:--:|:--:|:--:|:--:| -| 2020 | 1,408 | 0.089 | 45.3 | 1.9 | 0.192 | -| 2035 | 1,239 | 0.089 | 39.8 | 1.9 | 0.192 | -| 2050 | 1,239 | 0.089 | 39.8 | 1.9 | 0.192 | - -``` - -a operation and maintenance - -Under this representation of hydrogen, ReEDS ensures sufficient -hydrogen production to match total annual demand at a national level. -This means that hydrogen demand from H2-CTs and external sources is -represented on an annual basis, and that hydrogen can be produced in any -location or time period in the model to serve that demand. Users have -the option to apply an adder to the production of hydrogen to represent -additional costs of transporting and storing hydrogen, but these are not -explicitly represented in this formulation. - - - -#### Endogenous production with zonal balancing, transport, and storage - -In this approach hydrogen production is explicitly represented, but -instead of matching hydrogen supply and demand at the national level is -matched zonally in each of the model’s balancing areas. The equation -below reflects how for each region *r* in each time period *h* the model -balances hydrogen supply, which includes production (Prod), storage -withdrawals (StorOut), and transfers from neighboring regions *rr* -(Flow), with hydrogen demand, including storage injections (StorIn), -transfers to neighboring regions, and demand from H2CTs and other -sectors. - -$$Prod_(h,r) + StorOut_(h,r) + \sum_(rr) Flow_(h,rr,r) \\ -= StorIn_(h,r) + \sum_(rr) Flow_(h,rr,r) + H2CT_(h,r) + Exog_(h,r)$$ - -Hydrogen demand from the power sector is attributed to balancing area -based on H2-CTs usage, whereas exogenous hydrogen demand is allocated to -balancing using regional demand fractions. - -To store hydrogen a balancing area must invest in storage capacity. -ReEDS currently represents two forms of geological hydrogen -storage—either in salt caverns or hard rock formations—as well as the -ability to construct storage in underground pipe systems. Data on the -availability of geological storage are taken from , depicted in {numref}`figure-hydrogen-storage-availability`. -Because of the lack of credible estimates on available reservoir -capacity, ReEDS does not impose limits on the amount of storage that a -balancing area connected to reservoir can -build. - -Costs of hydrogen storage are based on estimates from , shown in {numref}`figure-hydrogen-storage-cost-estimate`. -For geological storage ReEDS assumes \$/kg based on the -economies-of-scale from constructing 2-3 caverns. To reduce model -complexity, ReEDS assumes that each balancing area can only build the -cheapest storage option that it has available to -it. - -ReEDS also allows for the modeling of interzonal hydrogen transport. -Transport requires the construction of hydrogen pipelines, and the model -assumes costs estimates based on from the H2 SERA model[^ref28]. Modeling -hydrogen transport in ReEDS is an experimental feature, and because this -feature adds significant runtime the model includes the option for -modeling zonal balancing with transport disabled or a fixed \$/kg -hydrogen transport cost. - -```{figure} ../../images/hydrogen-storage-availability.png -:name: figure-hydrogen-storage-availability - -Assumed availability of geological hydrogen storage -reservoirs. Data are from Lord et al. {cite:year}`lordGeologicStorageHydrogen2014a`. -``` - -```{figure} ../../images/hydrogen-storage-cost-estimate.png -:name: figure-hydrogen-storage-cost-estimate - -Cost estimates for hydrogen storage. Data taken from Papadias and Ahluwalia {cite:year}`papadiasBulkStorageHydrogen2021`. -``` - - -### Direct Air Capture - -The model can also procure negative emissions by removing and storing -CO2 from the atmosphere using direct air capture (DAC). For -this study, DAC in the ReEDS model is a sorbent design that uses only -electricity as an input, with an energy consumption of 3.72 MWh per -tonne of CO2 removed. Overnight capital costs are assumed to -be \$1,932 per tonne-year capture capacity, with annual fixed O&M costs -of 4.6% of the capital costs and nonfuel variable O&M cost of \$21 per -tonne. - - -### CO2 Transport and Storage - -ReEDS has the option to use a detailed CO2 network representation that, -when turned on, requires all CO2 captured at CCS facilities (gen-CCS, -SMR-CCS, and DAC) to be transported via liquid CO2 pipelines and -sequestered in underground saline aquifers. "Trunk" pipelines can be -built between BA transmission endpoints and "spur" pipelines can be -build from BA transmission endpoints to the edge of any nearby (\<200 -mi) aquifer. These pipelines can be assigned different capital and FO&M -costs, and the several hundred saline aquifers identified by NETL have -\$/tonne breakeven costs that represent the cost of sequestering CO2 in -the aquifer (i.e. permitting, injection facilities, monitoring, and a -100-year trust fund for maintenance). - -The network representation includes only saline aquifers with a -reservoir cost of \<\$20/tonne at a 90% capacity factor. The explicit -representation is turned off by default. - - -### Capital Stock -#### Initial Capital Stock, Prescribed Builds, and Restrictions - -Existing electricity generation capacity is taken from the EIA NEMS -unit database {cite}`eiaAnnualEnergyOutlook2023`. Units are mapped to ReEDS technologies based -on a combination of fuel source and prime mover of the generation -technology. Units of the same technology type within a region can be -aggregated or represented individually.[^ref29] If they are aggregated, the -aggregation is done by clustering the units based on heat -rates. - -The binning structure is designed flexibly such that users can choose -the appropriate levels of model fidelity and computational speed for -each application. Historical units are binned using a k-means clustering -algorithm for each BA and technology category (e.g., coal with or -without SO2 scrubbers, and natural gas combined cycle) -combination. The user specifies a maximum number of bins and a minimum -deviation across unit heat rates. Any two plants are eligible to form -separate bins if the difference between their heat rates is greater than -the minimum deviation parameter. The number of bins formed is then equal -to the smaller of the maximum bin number parameter and the number of -units after applying the minimum deviation criteria. For each bin, the -assigned heat rate is equal to the capacity-weighted average of the heat -rates for the units inside the bin. An illustrative example of the -results is depicted for two BAs in {numref}`figure-capacity-binning-example`, assuming a maximum of -seven bins and minimum deviation of 50 BTU per kWh. The horizontal axis -corresponds to the heat rate for a given power plant unit from the NEMS -database, while the vertical axis corresponds to the heat rate each bin -is assigned in ReEDS. Points on the 45-degree line illustrate units for -which the ReEDS heat rate is the same as the NEMS heat rate. The more -tightly clustered the points are around this line, the less the model -will suffer from aggregation bias. The figure illustrates that, in -general, the fewer the number of units in a given technology category -(in this example, nuclear and scrubbed coal), the closer the binned heat -rates are to the actual heat rates. - -```{figure} ../../images/capacity-binning-example.png -:name: figure-capacity-binning-example - -Example of capacity binning results for two BAs -``` - -Hydropower has additional subcategories to differentiate -dispatchability as discussed in [Hydropower](#hydropower). In addition, any plants -that are listed as under construction become prescribed builds. In other -words, ReEDS builds any under-construction units, with the units coming -online in the anticipated online year listed in -the database. - -For wind technologies, near-term regional growth restrictions reflect -the difficulty of immediately scaling the wind industry. Specifically, -wind plant construction through the 2020 solve year is limited to plants -that are planned to be installed before the end of 2020. After 2020, no -wind capacity limits are implemented. - - -#### Retirements - -Renewable energy generator and battery retirements are (by -default)[^ref30] based on assumed lifetimes. Once a generator has reached -its lifetime, it is retired. Renewable energy and battery lifetime -assumptions are shown in {numref}`generator-and-battery-lifetimes`. -When renewable energy capacity is retired, the resource -associated with that capacity is made available, and ReEDS can choose to -rebuild a renewable energy generator using the newly available resource, -without the need to rebuild the grid interconnection infrastructure. A -consequence of this assumption is that retired renewable capacity can be -replaced without incurring interconnection costs and, with all other -considerations being equal, re-powered or re-built renewable capacity -has lower cost than new “green-field” capacity of the same type.[^ref31] -One exception to this procedure is hydropower, which due to assumed -non-power requirements is never retired unless there is an announced -hydropower capacity retirement listed in the NEMS unit -database. - -```{table} Lifetimes of Renewable Energy Generators and Batteries -:name: generator-and-battery-lifetimes - -| **Technology** | Lifetime (Years) | **Source** | -|----|:--:|----| -| Land-based Wind | 30 | LBNL Survey {cite}`wiserBenchmarkingAnticipatedWind2019` | -| Offshore Wind | 30 | LBNL Survey {cite}`wiserBenchmarkingAnticipatedWind2019` | -| Solar Photovoltaic | 30 | SunShot Vision {cite}`doeSunShotVisionStudy2012` | -| Concentrating Solar Power | 30 | SunShot Vision {cite}`doeSunShotVisionStudy2012` | -| Geothermal | 30 | Renewable Electricity Futures Study, Vol. 1 {cite}`maiExplorationHighPenetrationRenewable2012` | -| Hydropower | 100 | Hydropower Vision {cite}`doeHydropowerVisionNew2016` | -| Biopower | 50 | ABB {cite:year}`abbABBVelocitySuite2018a` | -| Marine Hydrokinetic | 20 | Previsic et al. {cite:year}`previsicFuturePotentialWave2012` | -| Battery | 15 | Cole and Frazier {cite:year}`coleCostProjectionsUtilityScale2020` | -``` - -Retirements of existing conventional energy generators in ReEDS are -primarily a function of announced retirement dates and -technology-specific estimated lifetimes, taken from the NEMS plant -database. Estimated retirement dates depend on the size of the unit, and -the most common lifetimes are shown in {numref}`conventional-energy-generator-lifetimes` -for plants that are smaller or larger than 100 MW. Nuclear plants are assumed to have a mix -of 60- and 80-year lifetimes as explained below. All conventional -generators that are economically built in ReEDS are given the lifetime -of plants greater than 100 MW, and these lifetimes are used as necessary -when the solution period extends beyond 2050. - -```{table} Lifetimes of Conventional Energy Generators a -:name: conventional-energy-generator-lifetimes - -| **Technology** | Lifetime less than 100 MW (Years) | **Lifetime greater or equal to 100 MW (Years)** | -|----|:--:|:--:| -| Gas Combustion Turbine | 50 | 50 | -| Gas Combined Cycle and CCS | 60 | 60 | -| Coal, all techs, including cofired | 65 | 75 | -| Oil-Gas-Steam | 50 | 75 | -| Compressed-Air Energy Storage | 100 | 100 | -``` -a {cite}`abbABBVelocitySuite2018a` - -In addition to age-based retirements, ReEDS includes the option to -endogenously retire technologies (this option is turned on by default). -When doing endogenous retirements, ReEDS is trading off the value -provided to the system by the plant versus the costs incurred by keeping -the plant online. If the value is not sufficient to recover the costs, -ReEDS will choose to retire the plant. ReEDS includes a “retirement -friction” parameter that allows a plant to stay online as long as it is -recovering at least a portion of its fixed operating costs. For example, -if this retirement friction parameter is set to 0.5, then a plant will -only retire if it does not recover at least half of its fixed costs. -Additionally, ReEDS includes a minimum retirement age for existing -conventional plants of 20 years, meaning that a conventional plant is -not allowed to be endogenously retired until it is at least 20 years -old. - -ReEDS includes four exogenous nuclear retirement scenario settings. The -four settings are defined by first dividing the currently operating -reactors into two bins. Any plants participating in a restructured -market and all single-reactor plants are assigned to Bin 1. The -remaining plants, which are all multi-reactor plants in a traditional -regulated environment, are assigned to Bin 2. The only exception to -these categorizations is that plants that have announced their intent to -seek a second operating license renewal from the Nuclear Regulatory -Commission (NRC) are included in Bin 2. {numref}`nuclear-plant-capacity` breaks down the bins -and shows total capacity in each case. These bins are categorizations -that reflect the current discussion pointing to more economic pressure -on restructured and single-reactor units {cite:p}`haratykEarlyNuclearRetirements2017, nicholasstecklerHalfNuclearPower2017`. - - -```{table} Amount of Nuclear Power Plant Capacity (in GW) in Each Bin -:name: nuclear-plant-capacity - -| **Plant Category** | **Bin 1** | **Bin 2** | -|----|---:|---:| -| Restructured, Single Reactor | 8.7 | — | -| Restructured, Multi Reactor | 27.5 | 2.0a | -| Regulated, Single Reactor | 15.7 | — | -| Regulated, Multi Reactor | — | 42.1 | -| Total | **51.9** | **44.1** | -``` - -a The Peach Bottom plant (2.0 GW) has announced its intent -to seek a second license renewal. Therefore, it is moved from Bin 1 to -Bin 2 even though it is in a restructured -market. - -The four nuclear retirement scenarios are: (1) Early Retirement, (2) -60-Year Lifetime, (3) Mid-Case (mix of 60 and 80-year lifetimes), and -(4) 80-Year Lifetime (see {numref}`nuclear-plant-lifetime`). The Early Retirement scenario -retires nuclear capacity in Bin 1 when its lifetime reaches 50 years, -and capacity in Bin 2 at 60 years. The 50-year lifetime emulates the -retirements of recent plants that did have a renewed operating license -but retired before they reached the end of their license. The 60-Year -Lifetime scenario retires all plants at 60 years, which would be at the -end of their first operating license renewal. The 80-Year Lifetime -scenario retires all plants at 80 years, simulating a successful -completion of a second operating license renewal from the NRC. The -Mid-Case scenario serves as the default setting in ReEDS and retires -capacity in Bin 1 at 60 years and capacity in Bin 2 at 80 -years. - -```{table} Nuclear Power Plant Lifetime for Each Scenario by Bin (years) -:name: nuclear-plant-lifetime - -| **Scenario Name** | **Bin 1** | **Bin 2** | -|----|:--:|:--:| -| Early Retirement | 50 | 60 | -| 60-Year Lifetime | 60 | 60 | -| Mid-Case | 60 | 80 | -| 80-Year Lifetime | 80 | 80 | -``` - - -#### Growth Constraints - -The ReEDS model can represent either absolute growth constraints (e.g., -wind builds cannot exceed 100 GW per year) or relative growth -constraints (e.g., wind capacity cannot grow by more than 50% per year). -The growth constraints are designed to target a broader technology group -as opposed to the individual classes of wind, PV, and CSP; as an -example, the growth constraint would restrict the builds of all wind -technologies and classes and not just a specific class. The default -values for the absolute growth constraints are the highest -year-over-year changes of each technology type’s capacity from 2010 to -2020 (computed by appending the necessary EIA AEOs). For CSP, the -default absolute growth limit is assigned the same as PV, as it has not -seen the capacity buildout as PV or wind have as of 2020. The relative -growth limits are applied on a state-level and are based on historical -compounded annual growth rate estimates observed for solar PV from -2012-2022. The penalties are assessed in ReEDS based on the maximum -previous growth observed in the model. For example, if a state -experienced 1,000 MW of new capacity in 2024 and 500 MW of new capacity -in 2025, then the growth penalty would be applied using the 1,000 MW -value even though it is older. - -```{figure} ../../images/annual-growth-penalties.png -:name: figure-annual-growth-penalties - -Annual growth penalties applied on a state level in ReEDS when the relative growth penalties are enabled. -``` - -ReEDS also includes minimum growth sizes, specified by technology type. -Those minimum growth sizes are shown in {numref}`min-growth-size-per-tech` and are generally based -on representative plant sizes. - -```{table} Minimum growth size for each technology group. Growth below this level will never incur a rowth penalty regardless of starting capacity. -:name: min-growth-size-per-tech - -| Technology group | Minimum growth size before a penalty is incurred (MW) | -|----|---:| -| CCS | 300 | -| CSP | 100 | -| Uncontrolled Natural Gas | 300 | -| Hydrogen | 100 | -| Nuclear | 600 | -| Solar PV | 100 | -| Storage | 100 | -| Wind-Offshore | 600 | -| Wind-Onshore | 100 | -``` - - -### Regional Parameter Variations and Adjustments - -For most generation technologies, regional cost multipliers are applied -to reflect variations in installation costs across the United States -(see {numref}`figure-regional-capital-cost-multipliers`). These regional multipliers are applied to the base -overnight capital cost presented in earlier sections. The regional -multipliers are technology-specific and are derived primarily from the -EIA/Leidos Engineering report {cite}`eiaCapitalCostEstimates2016` that is the source of capital -cost assumptions for the NEMS model. While the regional costs presented -in the EIA/Leidos Engineering report are based on particular cities, the -regional multipliers for ReEDS are calculated by interpolating between -these cities and using the average value over the ReEDS regions for each -technology. For technologies such as CSP that are not included in the -newer report, we rely on the older EIA/Science Applications -International Corporation report {cite}`eiaUpdatedCapitalCost2013`. - -```{figure} ../../images/regional-capital-cost-multipliers.png -:name: figure-regional-capital-cost-multipliers - -Maps of regional capital cost multipliers for the various technology types -``` - -Regions shown in white for offshore wind indicate that there is not -offshore wind resource in that region. - - -## Fuel Prices - -Natural gas, coal, and uranium prices in ReEDS are based on the most -recent AEO. Coal prices are provided for each of the nine EIA census -divisions. Low and high natural gas price alternatives are taken from -the Low and High Oil and Gas Resource and Technology scenarios. ReEDS -includes only a single national uranium price trajectory. Base fuel -price trajectories are shown in {numref}`figure-input-fuel-price-assumptions` for -the AEO2023 {cite}`eiaAnnualEnergyOutlook2023`. -Biomass fuel prices are represented using supply curves with five bins -in each region. The costs and resource availability are based on the -*U.S. Billion-Ton Update* study {cite}`doeUSBilliontonUpdate2011`. Biomass costs range from -\$2.02/MMBtu to \$19.43/MMBtu (in 2018\$). - -```{figure} ../../images/input-fuel-price-assumptions.png -:name: figure-input-fuel-price-assumptions - -Input fuel price assumptions. -``` - -Natural gas fuel prices are adjusted by the model as explained -below. - -Coal and uranium are assumed to be perfectly inelastic; the price is -predetermined and insensitive to the ReEDS demand for the fuel. With -natural gas, however, the price and demand are linked. Actual natural -gas prices in ReEDS are based on the AEO scenario prices but are not -exactly the same; instead, they are price-responsive to ReEDS natural -gas demand. In each year, each census division is characterized by a -price-demand “set point” taken from the AEO Reference scenario but also -by two elasticity coefficients: regional (βr) and national -(βn) elasticity coefficients for the rate of regional price -change with respect to (1) the change in the regional gas demand from -its set-point and (2) the overall change in the national gas demand from -the national price-demand set point respectively. The set of regional -and national elasticity coefficients are developed through a linear -regression analysis across an ensemble of AEO -scenarios[^ref32],[^ref33] to estimate changes in fuel prices -driven solely by electric sector natural gas demand (as described in -Logan et al. {cite:year}`loganNaturalGasScenarios2013` and Cole, Medlock III, and Jani {cite:year}`coleViewFutureNatural`, though the -coefficients have since been updated for the latest AEO data). Though -there is no explicit representation of natural gas demand beyond the -electricity sector, the regional supply curves reflect natural gas -resource, infrastructure, and nonelectric sector demand assumptions -embedded within the AEO modeling. For details, see the Natural Gas -Supply Curves section of the appendix. - -ReEDS includes options for other types of fuel supply curve -representations. Supply curves can be national-only, census-region-only, -or static. With the national-only supply curve, there are census -division multipliers to adjust prices across the census divisions. In -the static case, fuel prices are not responsive to -demand. - -The natural gas fuel prices also include a seasonal price adjustor, -making winter prices higher than the natural gas prices seen during the -other seasons of the year. For details, see the Seasonal Natural Gas -Price Adjustments section of the appendix. - - -## Power System Water Use - -The 2020 ReEDS version includes an updated representation of power -system water use that improves upon the formulation described in the -ReEDS version 2019 documentation {cite}`brownRegionalEnergyDeployment2020` as well as {cite}`macknickWaterConstraintsElectric2015`. Though inactive by default to limit computational -complexity, users can activate a power system water use formulation that -characterizes the existing fleet and new generation investments by both -their cooling technology and water source type, if applicable. Cooling -technology affects power system cost and performance, and water use is -constrained using technology withdrawal and consumption rates in -conjunction with water availability and cost data from {cite}`tidwellMappingWaterAvailability2018`. -The rest of this section describes each component of this formulation. - - -### Existing Fleet Cooling Technology and Water Source - -Thermal generating technologies in ReEDS are differentiated by the -following cooling technology types: once-through, recirculating, pond, -and dry(air)-cooled. Cooling technologies determine water withdrawal and -consumption rates as well as capital cost, operating cost, and heat rate -as described in [Cooling System Cost and Performance](#cooling-system-cost-and-performance). -Generating technologies without cooling -systems are designated as having no cooling; however, these technologies -can still be assigned water use rates to account for processes such as -evaporation from hydropower reservoirs or cleaning PV arrays. All -power-cooling technology combinations (including water-using -technologies without cooling) are also assigned one of the following six -water source types included in the model: fresh surface water that is -currently appropriated, unassigned/unappropriated fresh surface water, -fresh groundwater, brackish or saline groundwater, saline surface water, -and wastewater treatment facility effluent. These water source types -align with the water supply curves described in [Water Availability and Cost](#water-availability-and-cost). -Representing both cooling technology and water source allows a -high-fidelity representation of water source-sink relationships and -constraints. - -Cooling technology and water source of the baseline 2010 generation -fleet and subsequent prescribed builds is assigned using several data -sources mapped to the unit database that exogenously defines capital -stock in ReEDS. The EIA NEMS unit database is -first merged with the 2018 version of the EIA thermoelectric cooling -water dataset {cite}`useiaThermoelectricCoolingWater2018`. Cooling technology assignment uses the “860 -Cooling Type 1” field where possible, followed by the “860 Cooling Type -2” and finally “923 Cooling Type”. Hybrid cooling systems are assigned -as recirculating except for hybrid dry/induced draft systems, which are -assigned as dry cooling. Any remaining gaps in cooling technology -assignment are filled using the UCS EW3 Energy-Water Database -{cite}`unionofconcernedscientistsUCSEW3EnergyWater2012`. This procedure -enables annual updates through yearly reporting of EIA thermoelectric cooling -water data. Thermal units with no available information on cooling -technology are assigned recirculating cooling by default. - -Water source in ReEDS is assigned where possible using the “Water Type” -and “Water Source” fields in the EIA cooling water dataset and then -supplemented using raw EIA Form 860 plant-level data {cite}`FormEIA860Detailed2018`. -When the water source is unclear from the type and source, the “Water Source -Name” is used to help discern additional water source types and -determine which units use municipal water. Municipal water is treated as -an intermediary of the ultimate water source, which is defined using -U.S. Geological Survey (USGS) water use data for 2015 that includes -water sources for municipal use {cite}`dieterEstimatedUseWater2017`. Generating -units that use municipal water are assigned the water source that -supplies the majority of municipal water use in the USGS database. The -UCS EW3 database is also used to assign water sources unavailable in EIA -data {cite}`unionofconcernedscientistsUCSEW3EnergyWater2012`. Remaining unknown water -source types are assigned from USGS data using the majority water source -for the power sector, further differentiated by once-through or -recirculating cooling. If there is no USGS data for power sector water -use in the relevant county, the majority source of overall water use is -applied. - -Beyond this multi-database approach to assign cooling technology and -water source, water source must be reassigned for some prescribed new -builds if the water availability described in [Water Availability and Cost](#water-availability-and-cost) is -insufficient for that unit’s water needs. For these instances, a final -adjustment procedure that temporary relaxes water use constraints is -used to identify these units and manually modify water source types to -use the BA’s least-cost water source with sufficient availability for -the prescribed unit. - - -### Cooling System Cost and Performance - -Alternative cooling technologies are represented for the following -power system types: - -- Coal: all types, including coal with CCS and biomass-cofired -coal -- Gas-CC: including Gas-CC with CCS -- Oil-Gas-Steam: also allows “no cooling” to represent capacity that does not use thermal cooling water (e.g., internal combustion engines) -- Nuclear -- Biopower: also allows “no cooling” to represent capacity that does not use thermal cooling water -- Landfill Gas: also allows “no cooling” to represent capacity that does not use thermal cooling water -- CSP: all thermal storage durations and resource classes - -Water use is also characterized and constrained for hydropower, Gas-CT, geothermal, and distributed rooftop PV technologies, albeit without cooling technology disaggregation. This construct allows -total power sector water use to be estimated and could be expanded upon -in later model versions, particularly for geothermal technologies. - -Some power-cooling technology pairs are also prohibited for new -construction by default. New, non-prescribed capacity for all -technologies cannot use once-through cooling due to U.S. Environmental -Protection Agency (EPA) regulations and industry trends {cite}`epa40CFRParts2014`. In addition, all new non-prescribed capacity cannot -choose pond cooling because pond cooling designs are site-dependent, and -ReEDS does not have sufficient detail to characterize location-specific -cooling pond design. The model also prevents new nuclear and coal-CCS -capacity from using dry cooling because existing designs have very high -cooling requirements where dry cooling is considered -impractical. - -Cooling technology affects capital cost, variable operating cost, heat -rate, water withdrawal rate, and water consumption rate. Cost and heat -rate are adjusted for cooling technology by multiplying baseline -technology data by the factors in {numref}`capital-cost-multipliers`, -{numref}`variable-operations-capital-cost-multipliers`, and {numref}`heat-rate-multipliers`, -where recirculating cooling is the reference cooling technology {cite}`macknickOperationalWaterConsumption2012`. -Typically, once-through cooling systems are less expensive -and allow higher overall thermal efficiency, while dry cooling is more -expensive and results in lower net thermal efficiency. Pond cooling -systems are typically intermediate to once-through and recirculating -cooling, but the model uses once-through cooling characteristics as an -approximation because actual cost and performance is site-specific. No -data exists for some power-cooling technology combinations (Gas-CC-CCS + -once-through and pond; Coal-CCS + pond, CSP + once-through and pond) -because no existing or planned units of those types -exist. - -```{table} Capital Cost Multipliers for Power-Cooling Technology Combinations -:name: capital-cost-multipliers - -| Power Technology | Once-Through | Recirculating | Dry | Cooling Pond | -|----------------------|------------------|-------------------|---------|------------------| -| Gas-CC| 0.978| 1.000| 1.102| 0.978| -| Gas-CC-CCS| n/a| 1.000| 1.075| n/a| -| Pulverized coal with scrubbers (pre-1995) | 0.981| 1.000| 1.045| 0.981| -| Pulverized coal without scrubbers | 0.981| 1.000| 1.045| 0.981| -| Pulverized coal with scrubbers (post-1995)| 0.981| 1.000| 1.045| 0.981| -| IGCC coal| 0.988| 1.000| 1.033| 0.988| -| Coal-CCS| 0.982| 1.000| n/a| n/a| -| Oil/gas steam| 0.981| 1.000| 1.045| 0.981| -| Nuclear| 0.981| 1.000| n/a| 0.981| -| Biopower| 0.981| 1.000| 1.045| 0.981| -| Cofired coal (pre-1995)| 0.981| 1.000| 1.045| 0.981| -| Cofired coal (post-1995)| 0.981| 1.000| 1.045| 0.981| -| CSP| n/a| 1.000| 1.050| n/a| -``` - -```{table} Variable Operations and Maintenance Cost Multipliers for Power-Cooling Technology Combinations -:name: variable-operations-capital-cost-multipliers - -| Power Technology | Once-Through | Recirculating | Dry | Cooling Pond | -|---------------------------------------------|--------------|---------------|-------|--------------| -| Gas-CC | 0.996 | 1.000 | 1.021 | 0.996 | -| Gas-CC-CCS | n/a | 1.000 | 1.107 | n/a | -| Pulverized coal with scrubbers (pre-1995) | 0.989 | 1.000 | 1.051 | 0.989 | -| Pulverized coal without scrubbers | 0.989 | 1.000 | 1.051 | 0.989 | -| Pulverized coal without scrubbers (post-1995)| 0.989 | 1.000 | 1.051 | 0.989 | -| IGCC coal | 0.996 | 1.000 | 1.021 | 0.996 | -| Coal-CCS | 0.993 | 1.000 | n/a | n/a | -| Oil/gas steam | 0.989 | 1.000 | 1.051 | 0.989 | -| Nuclear | 0.989 | 1.000 | n/a | 0.989 | -| Biopower | 0.989 | 1.000 | 1.051 | 0.989 | -| Cofired coal (pre-1995) | 0.989 | 1.000 | 1.051 | 0.989 | -| Cofired coal (post-1995) | 0.989 | 1.000 | 1.051 | 0.989 | -| CSP | n/a | 1.000 | 1.050 | n/a | -``` - -```{table} Heat Rate Multipliers for Power-Cooling Technology Combinations -:name: heat-rate-multipliers - -| Power Technology | Once-Through | Recirculating | Dry | Cooling Pond | -|---------------------------------------------|--------------|---------------|--------|--------------| -| Gas-CC | 0.980 | 1.000 | 1.050 | 0.980 | -| Gas-CC-CCS | n/a | 1.000 | 1.075 | n/a | -| Pulverized coal with scrubbers (pre-1995) | 0.985 | 1.000 | 1.050 | 0.985 | -| Pulverized coal without scrubbers | 0.985 | 1.000 | 1.050 | 0.985 | -| Pulverized coal with scrubbers (post-1995) | 0.985 | 1.000 | 1.050 | 0.985 | -| IGCC Coal | 0.980 | 1.000 | 1.050 | 0.980 | -| Coal-CCS | 0.800 | 1.000 | n/a | n/a | -| Oil/Gas Steam | 0.985 | 1.000 | 1.050 | 0.985 | -| Nuclear | 0.973 | 1.000 | n/a | 0.973 | -| Biopower | 0.985 | 1.000 | 1.050 | 0.985 | -| Cofired Coal (pre-1995) | 0.985 | 1.000 | 1.050 | 0.985 | -| Cofired Coal (post-1995) | 0.985 | 1.000 | 1.050 | 0.985 | -| CSP | n/a | 1.000 | 1.000a | n/a | -``` - -a There are currently no data to inform a heat rate -multiplier for CSP. - -More efficient-less expensive cooling technologies typically require -greater volumes of water withdrawal and consumption, creating a tradeoff -between cost and water use. Withdrawal and consumption rates for -power-cooling technology combinations are shown in {numref}`water-withdrawal-rates` and {numref}`water-consumption-rates` -{cite}`macknickOperationalWaterConsumption2012`. {numref}`water-withdrawal-and-consumption-rates` includes water use rates for power -technologies that are not differentiated by cooling technology; aside -from geothermal these values are negligible but could be modified by the -user if desired. Further, the model can accommodate BA-specific -withdrawal and consumption rates, so the values shown below could be -made regionally heterogeneous with sufficient data. Water withdrawal and -consumption rates coupled with assignment of water source type allow -ReEDS to characterize power system water demand for each technology, BA, -and water source combination. - -```{table} Water Withdrawal Rates for Power-Cooling Technology Combinations (gal/MWh) -:name: water-withdrawal-rates - -| Power Technology | Once-Through | Recirculating | Dry | Cooling Pond | -|----|----|----|----|----| -| Gas-CC | 11,380 | 255 | 2 | 5950 | -| Gas-CC-CCS | n/a | 506 | n/a | n/a | -| Pulverized coal with scrubbers (pre-1995) | 36,350 | 1,005 | 0 | 12,225 | -| Pulverized coal without scrubbers | 36,350 | 1,005 | 0 | 12,225 | -| Pulverized coal with scrubbers (post-1995) | 27,088 | 587 | 0 | 17,914 | -| IGCC Coal | 18,136 | 393 | 0 | 9,635 | -| Coal-CCS | 56,483 | 1,224 | n/a | n/a | -| Oil/gas steam | 35,000 | 1,203 | 0 | 5,950 | -| Nuclear | 44,350 | 1,101 | n/a | 7,050 | -| Biopower | 35,000 | 878 | 0 | 450 | -| Cofired coal (pre-1995) | 35,000 | 878 | 0 | 450 | -| Cofired coal (post-1995) | 35,000 | 878 | 0 | 450 | -| CSP | n/a | 786 | 26 | n/a | -``` - -```{table} Water Consumption Rates for Power-Cooling Technology Combinations (gal/MWh) -:name: water-consumption-rates - -| Power Technology | Once-Through | Recirculating | Dry | Cooling Pond | -|----|----|----|----|----| -| Gas-CC | 100 | 205 | 2 | 240 | -| Gas-CC-CCS | n/a | 378 | n/a | n/a | -| Pulverized coal with scrubbers (pre-1995) | 250 | 687 | 0 | 545 | -| Pulverized coal without scrubbers | 250 | 687 | 0 | 545 | -| Pulverized coal with scrubbers (post-1995) | 113 | 479 | 0 | 545 | -| IGCC coal | 90 | 380 | 0 | 32 | -| Coal-CCS | 217 | 921 | n/a | n/a | -| Oil/gas steam | 240 | 826 | 0 | 240 | -| Nuclear | 269 | 672 | n/a | 610 | -| Biopower | 300 | 553 | 0 | 390 | -| Cofired coal (pre-1995) | 300 | 553 | 0 | 390 | -| Cofired coal (post-1995) | 300 | 553 | 0 | 390 | -| CSP | n/a | 786 | 26 | n/a | -``` - -```{table} Water withdrawal and consumption rates for technologies that are undifferentiated by cooling technology (gal/MWh) -:name: water-withdrawal-and-consumption-rates - -| Power Technology | Withdrawal Rate | Consumption Rate | -|----|----|----| -| Hydropower | 1 | 1 | -| Gas-CT | 1 | 1 | -| Geothermal | 40 | 40 | -| Landfill-Gas | 1 | 1 | -| Distributed rooftop PV | 1 | 1 | -``` - -### Water Availability and Cost - -All generating capacity that exists in a given model year is required -to have access to water if that technology uses water. The quantity of -required water access is defined conservatively to ensure sufficient -water is available to generate at maximum power output during the -expected annual low water flow condition. To align with annualized water -availability data, this requirement is formulated as the annual volume -of water needed to operate continuously at maximum output for the entire -year (100% capacity factor), i.e., the product of generating capacity -(MW), water use rate (gal/MWh), and 8760 hours per year. For capacity -that uses surface water, requirements are based on the water consumption -rate to account for the return of most withdrawn water directly to the -water source at the site of withdrawal. For all other water sources, -water access requirements are based on withdrawal rates because these -water types (e.g., groundwater, wastewater effluent) are not generally -returned to the site of withdrawal. - -Generating capacity in the initial 2010 model year is assumed to have -secured sufficient water access prior to 2010. However, any new -prescribed or optimized investments must procure water access from a -power sector water availability supply curve developed by Sandia -National Laboratories {cite}`tidwellMappingWaterAvailability2018`. For use in ReEDS, water -availability and cost are aggregated to the BA resolution for each of -five water source types: fresh surface water that is currently -appropriated, unassigned/unappropriated fresh surface water, fresh -groundwater, brackish or saline groundwater, and wastewater treatment -facility effluent. Saline surface water is available to -existing capacity that currently uses it, but this water source is -assumed unavailable to new capacity due to current regulatory -constraints and industry expectations {cite}`epa40CFRParts2014`. -Tidwell et al. {cite:year}`tidwellMappingWaterAvailability2018` use a unique resource assessment and costing methodology -for each water source type, based on technical and legal considerations. -Costs include both capital and annualized operating costs associated -with each water source. Unassigned/unappropriated fresh surface water is -assumed to have negligible access cost, and costs typically increase in -the order of fresh groundwater, appropriated fresh surface water, -wastewater, and brackish/saline groundwater. Appropriated water is only -relevant to western U.S. water law, so there is no appropriated water in -the east, and many western regions lack unappropriated water (i.e., 100% -of total water is appropriated). - -When capacity retires, its water access is automatically available to -any new capacity at the cost associated with the capacity’s water source -and region. For the initial 2010 fleet, all capacity that uses fresh -surface water is designated as using the “appropriated fresh surface -water” category so that retired water access is given the cost of other -appropriated water in that region. For the eastern U.S. where water -appropriation is inapplicable, retired fresh surface water access is -assigned a small nominal cost to avoid over procurement of water in the -model. This structure implies that any water access owned by the power -sector remains in the power sector and that increased competition does -not affect water supply or cost. Scenario analysis and future model -development could explore this assumption in greater -detail. - -Similar to retirements, changes in water needs due to upgrades or -refurbishments are also accounted for in the water access -requirement. - -```{figure} ../../images/water-availability-and-cost.png -:name: figure-water-availability-and-cost - -Water availability and cost for each water type in each ReEDS balancing area. -``` - - -### Water Constraints - -Several model constraints govern the ReEDS power sector water use -formulation. Water withdrawal and consumption quantities are tracked for -each power technology, cooling technology, water source, power -technology vintage, BA, timeslice, and year, providing high resolution -with which to examine power sector water use. Separately, water access -requirements are related explicitly to the capacity available for each -power technology, cooling technology, water source, power technology -vintage, BA, and year based on either the withdrawal or consumption rate -as described in [Water Availability and Cost](#water-availability-and-cost). This water access is then limited by the -total access available for each water source and region as defined by -the water allocation in 2010 and the supply available to post-2010 -capacity. - -Quantities of water used for each power technology, cooling technology, -water source, power technology vintage, and BA are then constrained -within each season based on the seasonal allocation of available water -access. Water access must be purchased from the water availability -supply curve before water can be used. Hydrology data is used to define -the seasonal allocation of unassigned/unappropriated fresh surface water -{cite}`macknickWaterConstraintsElectric2015`, and all other water types are assumed -available uniformly throughout the year. Additional detail on seasonal -water allocation and the potential for changes over time requires -additional data, but the framework generally allows the capability for -incentivizing water sources that are more available when electricity -demands are higher. - - -## Transmission - -ReEDS considers two categories of transmission: “local interconnection” of generation -resources within the 134 model zones, and “interzonal” or -“long-distance” transmission between the model zones. These two -categories of transmission share underlying cost data but are -represented differently within the model. We begin with a discussion of -transmission costs, then describe the separate representations of -“interconnection” and “long-distance” transmission within ReEDS. - - -### Transmission costs - -Estimated costs for transmission lines are generated by defining a -high-geographic-resolution cost surface, then utilizing a -least-cost-path algorithm to identify a representative transmission line -path between two points {cite}`lopezSolarPhotovoltaicsLandBased2024a`. The final \$/MW cost for a -particular route is then given by the integrated \$/MW-mile values for -the cost surface points traversed by the least-cost -route. - -Base voltage-dependent \$/MW-mile transmission costs are taken from -four sources: Southern California Edison for CAISO and the Northeast, -WECC/TEPPC for non-CAISO areas in the Western Interconnection, MISO for -the Midwest, and a representative utility for the Southeast. These base -transmission costs are shown on the left side of {numref}`figure-transmission-cost-input-data`. Cost -multipliers based on terrain type (hilly, with 2% ≤ land slope \< 8%, -and mountainous, with 8% ≤ land slope) and land class (pasture/farmland, -wetland, suburban, urban, and forest) are taken from the same four -sources. A separate 90m-resolution CONUS dataset of terrain and land -classes is then combined with the base transmission costs, terrain -multipliers, and land class multipliers to generate the cost surface -used in the least-cost-path routing algorithm. - -```{figure} ../../images/transmission-cost-input-data.png -:name: figure-transmission-cost-input-data - -Overview of transmission cost input data used in reV model calculations, used to generate ReEDS model inputs. -``` - -All transmission also incurs FOM costs, which are approximated as 1.5% -of the upfront capital cost per year. - - -### Local generator interconnection - -There are three components of local generator interconnection -represented in ReEDS: geographically resolved spur lines and substation -upgrades, geographically resolved reinforcement of the existing -transmission network, and a geographically independent cost adder for -all technologies. - - -#### Spur lines and substation upgrades - -Spur lines represent short-distance transmission built to connect new -wind and solar generation capacity to a “point of interconnection” (POI) -on the existing transmission system. For a given wind/solar site (the -~50,000 reV supply curve points discussed above), substations within the -same state are considered as possible POIs. Least-cost paths are -calculated to all candidate substations, and the substation with the -lowest resulting path-dependent spur-line cost is taken as the POI for -that wind/solar site. An appropriate spur-line voltage is chosen based -on the available wind or solar capacity at that site, with lower -available capacity leading to a lower spur-line voltage and a higher -associated \$/MW-mile cost. The cost of upgrading the POI substation is -included in the spur-line cost. Additional sources and details are -provided by Lopez et al {cite:year}`lopezImpactSitingOrdinances2023`. - - -#### Network reinforcement - -Network reinforcement represents upgrades to the existing transmission -network required to avoid congestion when moving power from the POI to -load centers. It is intended to represent the costs associated with -interconnection queues, which represent a major bottleneck for the -deployment of new wind and solar in the US. We estimate network -reinforcement costs by tracing a path along existing transmission lines -from each substation POI to each zone “center” within the same state; -the zone center is usually taken as the largest population center in the -model zone, but is sometimes (for zones without large urban centers) -assigned to a high-voltage substation within the zone. A cost for each -reinforcement route is calculated using the cost surface described in -[Transmission costs](#transmission-costs), with capex costs multiplied by 50% to represent the lower -cost for reconductoring compared to greenfield transmission -construction. The single lowest-cost route for each POI is then -selected; the associated reinforcement cost \\$/MW\] and transmission -distance \MW-miles\] are incurred for every MW of new wind/solar -capacity added at all reV sites associated with that -POI.[^ref34] - -{numref}`figure-local-generation-interconnection-components` illustrates the concepts of spur lines and reinforcement -lines, and {numref}`figure-interconnection-cost-distribution` shows the resulting distribution of interconnection -costs for land-based wind and utility-scale PV under the three siting -regimes. {numref}`figure-utility-scale-pv-costs` and {numref}`figure-land-based-wind-costs` show maps of the estimated spur-line -costs, reinforcement costs, total interconnection costs, and total -supply curve costs (including land-cost adders) for utility-scale PV and -land-based wind under reference-access siting assumptions. - -```{figure} ../../images/local-generation-interconnection-components.png -:name: figure-local-generation-interconnection-components - -Illustration of local generation interconnection components. -``` - -```{figure} ../../images/interconnection-cost-distribution.png -:name: figure-interconnection-cost-distribution - -Interconnection cost distribution for land-based wind (blue) and utility-scale PV (orange) under different siting assumptions. -``` - -```{figure} ../../images/utility-scale-pv-costs.png -:name: figure-utility-scale-pv-costs - -Supply-curve costs for utility-scale PV with reference-access siting. -``` - -```{figure} ../../images/land-based-wind-costs.png -:name: figure-land-based-wind-costs - -Supply-curve costs for land-based wind with reference-access siting. -``` - - -#### Intra-zone transmission cost adder for net increases in generation capacity - -In addition to the interconnection costs described above, we also apply -a flat intra-zone transmission cost adder of \$100/kW to net increases -in generation and AC/DC converter capacity within each model zone. This -value is taken from historical interconnection costs for fossil gas -capacity as reported in Seel et al. 2023 and is taken to represent a -“floor” for network upgrades that are required even if new capacity is -added at the optimal location (assuming that past additions of fossil -capacity have been placed to minimize interconnection costs). The -\$100/kW adder is subtracted from the reinforcement cost applied to wind -and solar to avoid double counting. As we assume that new generation -capacity will reuse the network infrastructure from retiring capacity, -the intra-zone transmission cost adder is only applied to *net* -increases in generation capacity. - - -### Interzonal transmission - -- High level - - Pipe and bubble / transport model - - Distribution losses - - -#### Existing transmission capacity - -```{figure} ../../images/ac-transmission-capacity.png -:name: figure-ac-transmission-capacity - -Existing AC transmission capacity in ReEDS. -``` - -Short description of ITL paper - -The transmission network in ReEDS is a -synthetic network developed from nodal data assembled as part of the -North American Renewable Integration Study (NARIS) \[37\]. This dataset -relies on nodal transmission models developed for the Eastern, Western, -and ERCOT interconnections under the guidance of the North American -Reliability Corporation (NERC) and includes ~56,000 buses, ~94,000 -transmission lines, and ~37,000 transformers. Capacity expansion models, -such as ReEDS, typically use zonal representation to remain tractable, -forgoing the modeling of individual generation, consumption, or -transmission assets and instead grouping them into zones which are -treated as copper plates. Assigning generation and demand units to their -respective zones is intuitive, however deriving the transmission -topology from the resolved nodal data is more involved than aggregating -steady state rated capacity across zonal interfaces due to the physics -of electrical power flow in meshed networks. In \[38\] the authors -propose a method for estimating the interface transfer limits between -zones from nodal transmission data utilizing a DC power flow -approximation. In this approach two independent optimizations are -performed to maximize the sum of flows in the forward direction on the -transmission lines crossing the interface and to minimize the sum of -flows in the reverse direction crossing the interface. The power flow is -constrained by the line ratings as described in -(5). - -$$-k(l) \le F(l) \le k(l) $$ - -(5) - -The relationship between line flows and bus injections or withdrawals -is dictated by the power transfer distribution factor (PTDF) matrix -described in (6). The PTDF relates the change in transaction amount -(amount of power injected at one zone and withdrawn in another zone) to -the change in power flow on a line. For instance, $_{}$ represents that -fraction of power transferred from zone *m* to zone *n* that flows over -a transmission line connecting zone *i* and zone -*j.* - -$$F(l) \sum_{b}^{B} p(l,b)G(b) \quad \forall l$$ - -(6) - -Additional constraints are applied to individual buses for which bus -type data are available, limiting injections for load buses and -withdrawals for generation buses, and both injections and withdrawals -for transmission buses. In conjunction these constraints establish a -more stringent limit for interface transfer capacities as compared to -the approach which sums the line ratings across interfaces. This method -for deriving interface transfer limits is used to create the -transmission networks in both the default BA resolution of ReEDS. -At the BA resolution the optimization -is run within each U.S. interconnection separately as they operate -nearly independently due to limited transfer capacity \[39\]. Due to the -relative density of the eastern interconnection, subsets of the network, -defined by a distance threshold from the interface in questions, are -solved iteratively to reduce the complexity of the optimization -\[38\]. - -We also drop sub-230 kV lines from interfaces where they make up less -than half of the total interface transfer capacity (which isn’t -described in the ITL paper) - -- Map of existing capacity (r and transgrp -resolution) - - - Extra constraint on inter-transgrp flows - -- Existing B2B and LCC HVDC - - -#### Costs and routes for new AC transmission additions - -```{figure} ../../images/new-ac-transmission-cost-assumptions.png -:name: figure-new-ac-transmission-cost-assumptions - -Costs assumed for new AC transmission additions. -``` - -- 500 kV single circuit -- Losses -- Least-cost paths -- FOM costs -- Financial multipliers / CRF -- Options for limiting new capacity - - -#### High-voltage direct current (HVDC) “macrogrids” - -- LCC (point-to-point) - - Costs and losses -- VSC (meshed) - - Costs and losses - - Operational constraints - - -### User-adjustable transmission assumptions - -- Hurdle rates - -ReEDS includes a default hurdle rate of \$0.01/MWh (in -2004\$) in order to reduce degeneracy between curtailment and -transmission losses. Users can adjust the hurdle rate to any value that -might meet their needs. - -- PRM trading -- Transmission investment and capacity limits -- Lots of other stuff - - -### Transmission System - -ReEDS uses a synthetic network with 134 nodes -defined by roughly 300 corridors for the contiguous 48 states. Each -corridor has a nominal carrying capacity limit that is -determined for the start-year (2010) based on power-flow analysis using -ABB’s GridView model and NERC-reported line limits {cite}`nerc2010LongtermReliability2010`. The -carrying capacity of DC transmission connections are taken from project -websites. A few notable DC transmission connections that are modeled in -ReEDS are listed in {numref}`dc-transmission-connections`. - -In later years, ReEDS can expand these carrying capacities, though the -model cannot build new node-to-node pathways. Transmission expansion is -limited before 2022 based on new construction that is already planned -{cite}`abbABBVelocitySuite2013`. After 2022, that limitation is dropped. ReEDS constrains -transmission flows in each of the representative time-slices when -dispatching generation and contracting operating reserves, and available -transmission capacity can also be used for firm power contracts to meet -system adequacy needs. - -```{table} List of Notable DC Transmission Connections Modeled in ReEDS -:name: dc-transmission-connections - -| **Project** | **Capacity (MW)** | -|-------------------------------------|------------------:| -| Pacific DC Intertie | 2,780 | -| Intermountain Power Project | 1,920 | -| Miles City Intertie (West-East) | 200 | -| Virginia Smith Intertie (West-East) | 200 | -| Segall Intertie (West-East) | 110 | -| Artesia Intertie (West-ERCOT) | 200 | -| Blackwater Intertie (West-East) | 200 | -| Rapid City Intertie (West-East) | 200 | -| Lamar Intertie (West-East) | 210 | -| CU HVDC | 1,500 | -| Square Butte | | -| Oklaunion Intertie (ERCOT-East) | 220 | -| Welsh Intertie (ERCOT-East) | 600 | -``` - - -In general, the modeled nodes are located at the largest population -center of each BA, although some manual adjustments are made.[ref^35] -Distances between BA nodes are estimated by tracing the “shortest path” -distance along existing transmission lines, giving preference for the -trace follow higher voltage lines. Voltages for each transmission line -were defined using the Homeland Security Infrastructure Project (HSIP) -transmission database and converted into 1-km grid. The maximum voltage -in each grid cell was identified and assigned a weight based on the -voltage classification per {numref}`voltage-class-weights` to create a tension grid. Using this -tension grip, a least “cost” (lowest weight) path was traced between -every BA-to-BA corridor was determined using the tension grid. Finally, -the great circle formula is used to calculate the distance of the traced -paths. The lengths of DC corridors are taken from values -reported on project websites. - -```{table} Weights for Each Voltage Class -:name: voltage-class-weights - -| **Voltage Class (kV)** | **Weight** | -|----|---:| -| No line | 1,000 | -| 100–161 | 10 | -| 230–300 | 5 | -| 345 | 3 | -| 500 | 2 | -| 735 and above | 1 | -``` - -Transmission network flows in ReEDS are limited based on the nominal -carrying capacity of the corridors. ReEDS can choose to -build additional transmission capacity on the existing network to reduce -congestion, but expansion of AC-DC-AC interconnection ties are not -allowed under default assumptions. New long-distance HVDC lines are not -allowed by default, but can be specified in the model inputs. ReEDS does -not represent reactive power and does not address AC-power-flow issues -of voltage, frequency, or limiting phase angle differences. Intra-BA T&D -networks are similarly ignored, effectively ignoring the effects of -transmission congestion within each region. - -Transmission and distribution losses are -considered in the model. There are bulk transmission losses of 1% per -100 miles for power that flows between BAs. In addition, distribution -losses of 5% are assumed and thus added to the end-use demand ([Electricity Load](#electricity-load)) -to scale end-use demand to busbar load. Distribution losses do not -apply to rooftop PV, as they are assumed to be downstream within -distribution networks, but they do apply at a lower rate to DUPV -systems, which are assumed to connect directly to low-voltage -distribution substations ([Electricity Load](#electricity-load)). - - -### International Electricity Trade - -ReEDS is capable of endogenously representing Canada and Mexico, -but our default model configuration only covers the -contiguous United States and represents electricity trade with Canada -exogenously. In the default configuration, imports and exports are -specified by Canadian province based on the National Energy Board’s -(NEB) Canadian Electricity Futures Reference Scenario {cite}`nebCanadaEnergyFutures2018`, -with net exports across all regions shown in {numref}`figure-canada-imports-exports` (values beyond NEB -projections to 2040 are held constant at the 2040 value). Each province -is required to send electricity to or receive electricity from any of -the ReEDS BAs that have connecting transmission lines to that province, -with the split among BAs approximated based on the transmission -connecting the BAs to the provinces. Seasonal and time slice estimates -for imports and exports are based on the historical monthly flows -between the countries.[^ref36] Canadian imports are assumed to be from -hydropower and are counted toward RPS requirements where allowed by -state RPS regulations. Canadian imports also count toward reserve margin -requirements. - -```{figure} ../../images/canada-imports-exports.png -:name: figure-canada-imports-exports - -Imports from Canada to the United States and exports from the United States to Canada -``` - - -## Electricity System Operation and Reliability - -ReEDS finds the least-cost way of building and operating the -electricity system while meeting certain requirements that are dominated -by the need to meet electricity load while maintaining system adequacy -and operational reliability. - - -### Electricity Load - -The primary constraint in ReEDS is to serve electricity load in each -hour and BA. The end-use electricity load projection used in ReEDS is -exogenously defined. There are many exogenous load profiles available in -the model, designed to accommodate various study needs and -sensitivities. Especially as the electrification of non-electric energy -uses creates significant regional and temporal shifts to the electric -sector load representation, the choice of load profile is important as -it contributes to the technology deployment mix and -quantity. - -The ReEDS load profiles are all hourly, and at the ReEDS BA level -resolution, However, their sources and processing through the model vary -slightly, as are described in the following -subsections. - - -#### Evolved Energy Research Load Profiles - -The newest load profile addition to the model is the adoption of new -load profiles from Evolved Energy Research (EER) which feature the -impacts of the Inflation Reduction Act. EER’s EnergyPATHWAYS model has -been the source of previous ReEDS load profiles, as described in [Electrification Futures Study Load Profiles](#electrification-futures-study-load-profiles). -It uses a bottom-up methodology, building load profiles for each -end-use sector before aggregating them together, yielding an hourly, -state, subsector level load profile. Their results were disaggregated to -the ReEDS BA level and aggregated to reflect total end-use load in the -ReEDS model. The default load profile in ReEDS Version 2023 “reflects -relatively conservative assumptions about the impact of demand-side -provisions in the Inflation Reduction Act (relative, compared to other -scenarios developed by EER)” {cite}`gagnon2023StandardScenarios2024a`. -The Inflation Reduction Act (IRA) features many tax credits and -subsidies for electric end-use technologies such as electric vehicles -and heat pumps, to name only a couple. More information about the -provisions in the IRA can be found in X. Other EER load profiles feature -100% economy wide decarbonization by 2050 or business as usual -electrification assumptions. Compound annual growth rates and 2050 -CONUS-wide annual demand for these profiles are shown in {numref}`growth-rates-and-electric-load`. One -benefit of these load profiles is that they feature 7 weather years of -data (2007-2013), allowing us to compute resource adequacy based on -various weather conditions. - - -```{table} Compound annual growth rates and 2050 electric load values for a variety of EER load profiles available in ReEDS. -:name: growth-rates-and-electric-load - -| | CAGR (2024 through 2050) | 2050 CONUS-wide Electric Load (TWh/year) | -|----|----|----| -| IRA Low (default) | 1.8% | 6,509 | -| Business as Usual | 0.9% | 5,054 | -| 100% economy-wide decarbonization by 2050 | 2.8% | 8,354 | -``` - - -#### Historical Load Data + AEO Growth Factor Profiles - -The second method with which load can be modeled in ReEDS is with a -historical (until 2010), hourly data set, which is then multiplied by -load growth factors from AEO. The historical data are sourced directly -from regional transmission organization (RTO) and independent system -operator (ISO) websites for the applicable regions, with load data being -requested at the most granular resolution available and for weather year -2012. For regions served by utilities, FERC Form 714 hourly load data -are used. Hourly BA-level profiles are averaged to the selected -representative time-slice level. These 2012 weather year profiles are -then scaled to ensure a match with the 2010 state-level annual retail -energy load data from EIA’s Electricity Data Browser {cite}`eiaElectricPowerDetailed2015`. Within -a state in ReEDS, further adjustments to load profiles use county level -load participation factors from Ventyx {cite:year}`ventyxVentyxVelocitySuite2014`. -The regional growth factors for years after 2010 are from the AEO scenario -electricity consumption by state. For each model year in ReEDS, the regional -load profiles are scaled by regional growth factors, but the shape of the -load profile is assumed to be constant throughout the study period. For -capacity credit calculations, hourly load from the 2007-2013 weather -years are used (see [Resource Adequacy](#resource-adequacy)). - -The end-use load, described in the previous paragraph, is defined at -the meter level. ReEDS includes inter-BA transmission system losses in -the optimization but does not represent distribution losses, so the -end-use load must be scaled up to busbar load to account for -distribution losses. The 5% distribution loss factor used for this -conversion is estimated based on a combination of EIA and ReEDS numbers. -ReEDS is required to generate sufficient power in each time-slice and BA -(allowing for transmission of power but accounting for losses) to meet -this busbar load. [^ref37] - - -#### Electrification Futures Study Load Profiles - -The ReEDS model also contains detailed electrification load profiles -were developed as part of the Electrification Futures Study (EFS) using -EnergyPATHWAYS {cite}`sunElectrificationFuturesStudy2020a`. There are three levels of -electrification load. Reference matches the ReEDS reference load using -AEO 2018 disaggregated to the subsector level reaching 4790 TWh of -annual demand and 860 GW peak demand. The Medium and High -electrification cases layer on top of the Reference electrification case -the incremental growth from EnergyPATHWAYS. Medium electrification -reaches 5800 TWh of annual demand and 1130 GW of peak demand and High -6700 TWh of annual demand and 1320 GW of peak demand. Hourly load -representation with electrification scenarios uses a single 2012 weather -year. This demand data is duplicated to match 7-year weather profiles, -which results in loss of synchronicity between weather and demand data -but we are able to capture greater interannual variability during peak -hours. - -Electrification of natural gas consuming end uses impacts natural gas -demand beyond the electric power sector. Alternate economy wide natural -gas scenarios are available for use with electrification cases, which -improve the representation of changing natural gas consumption outside -of the electric sector. - - -#### Load Adjustment Method for End Use Profiles - -ReEDS includes a methodology to incorporate changes to hourly electric -load shapes derived from analysis of other modeling tools. Regional -hourly load changes are paired with a defined regional adoption -trajectory for this load change by year. Combining these two factors -allows for ReEDS to changes to load profiles specific to region, year, -and hour. A further unique capability of this method is that an -arbitrary number of load changes and adoption trajectories can be -provided allowing for sophisticated changes to load shapes with a small -number of provided parameters. - -```{figure} ../../images/reeds-load-adjustment-method.png -:name: figure-reeds-load-adjustment-method - -ReEDS Load adjustment method. -``` - -This methodology is that it allows for ReEDS load profiles to be -adjusted quickly within an analysis scenario. This methodology is based -upon methods developed to incorporate changes to electric power demand -associated with geothermal heat pumps (GHP) and example hourly change -profiles and adoption scenarios derived from that analysis are -available. - - -### Resource Adequacy - -Resource adequacy is “the ability of supply- and demand-side resources -to meet the aggregate electrical demand” {cite}`nercGlossaryTermsUsed2016`. Planning reserve -requirements in ReEDS ensure adequate resource is available at all -times, within an acceptable probability of failing to do so. In -practice, this constraint is enforced by requiring the system to have -sufficient firm capacity to meet the forecasted peak demand plus a -reserve margin. This constraint is enforced for each season to -accommodate the potential for peak net load to shift seasons as -renewable penetration increases. - -Each technology is assigned a capacity credit[^ref38] reflecting its -expected availability when power is needed, typically during the -highest-risk hours, which are ideally identified as the hours with -highest loss of load probability (LOLP)[^ref39]. For conventional -non-variable generators in ReEDS, the CC is -one. - - -#### Capacity credit formulation -**VRE Capacity Credit** - -For VRE technologies (i.e., wind and solar), ReEDS estimates a seasonal -capacity credit for each region/class combination via an hourly LDC -approximation of expected load carrying capability (ELCC)[^ref40] performed -between solve years.[^ref41] ELCC can be described as the amount of -additional load that can be accommodated by adding those generators -while maintaining a constant reliability level. The “8760-based” -methodology can capture the highest load and net load hours, which -typically represent the highest risk hours, and can thereby support a -reasonable representation of capacity credit. Details of this LDC -approach, as well as a comparison against a former statistical method, -can be found in Frew et al. {cite:year}`frew8760BasedMethodRepresenting2017a`, though that approach has been -expanded to consider 7 years of wind, solar, and load data (2007-2013) -rather than just a single year. - -The LDC approach for calculating capacity credit is based on explicit -hourly (8,760 hours x 7 years) tracking of time-synchronous load and VRE -resources. The capacity method uses a capacity factor proxy that is -applied to top 10 hours in load and net load-duration curves (LDCs and -NLDCs) in each season to estimate ELCC by season. {numref}`figure-cv-calculation-ldc-approach` graphically -represents the ReEDS capacity credit methodology. The LDC reflects the -total load in a given modeling region, which is sorted from the hours of -highest load to lowest load and is shown by the blue line. The NLDC -represents the total load minus the time-synchronous contribution of -VRE, where the resulting net load is then sorted from highest to lowest, -as shown by the solid red line.[^ref42] The NLDC(δ), which represents -further addition of VRE resources, can be created by subtracting -the time-synchronous generation of an incremental capacity addition from -the NLDC, where the resulting time series is again sorted from highest -to lowest; this is shown by the dashed red -line. - -```{figure} ../../images/cv-calculation-ldc-approach.png -:name: figure-cv-calculation-ldc-approach - -LDC-based approach to calculating CV -``` - -ReEDS calculates the ELCC as the difference in the areas between the -LDC and NLDC during the top 10 hours of the duration curves in each -season, as represented by the dark blue shaded area in {numref}`figure-cv-calculation-ldc-approach`. These -10 hours are a proxy for the hours with the highest risk for loss of -load (i.e., the LOLP).[^ref43] Similarly, the contribution of an additional -unit of capacity to meeting peak load is the difference in the areas -between the NLDC and the NLDC(δ), as shown by the light blue shaded area -in {numref}`figure-cv-calculation-ldc-approach`. To ensure resource adequacy, ReEDS calculates capacity -credit based on a 1,000-MW incremental capacity size of new solar and -wind builds. These areas are then divided by the corresponding installed -capacity and number of top hours (10 hours per season in this case, -although the number of hours can be adjusted by the user) to obtain a -fractional seasonal-based capacity credit. - -The resulting existing and marginal capacity credit[^ref44] values then -feed into ReEDS to quantify each VRE resource’s capacity contribution to -the planning reserve requirement. Existing VRE capacity credit -calculations are performed by region and technology. For all candidate -VRE resources that might be built in the coming year, the *marginal* -capacity credit is calculated by region, technology, and resource class. -In all cases, the VRE profile is compared against the aggregated -resource assessment region (RAR) load profile for determining the -capacity credit ({numref}`figure-cv-calculation-ldc-approach`). We use the RAR-level load profile to -simplify the challenge of representing the ability of transmission to -wheel VRE capacity from one BA to another. Essentially, we assume a -copper plate within each RAR for the purpose of sharing VRE capacity. We -use RAR regions rather than NERC regions for this assumption because -transmission and trading tend to be more closely related to RAR regions -than NERC regions. - -**Storage Capacity Credit** - -The storage capacity credit method in ReEDS characterizes the increase -in storage duration that is needed to serve peak demand as a function of -storage penetration. The potential of storage to serve peak demand is -considered by performing several simulated dispatches against the load -profiles within each of the resource assessment regions shown in {numref}`figure-cv-calculation-ldc-approach`. - -Load profiles net of wind and PV generation are used to capture the -effects of VRE resources on the overall net load profile shape in a -region using the load, wind, and solar data from -2007-2013. - -For each season and reliability assessment zone, a storage dispatch is -simulated with peaking capacity prioritized over all other services -(reflecting capacity market prioritization as discussed by Sioshansi, et -al. {cite:year}`sioshansiDynamicProgrammingApproach2014`).Transmission constraints are ignored within each reliability -assessment zone for computational efficiency; this copper plate -transmission assumption only applies to the capacity credit -calculation—all transmission constraints are enforced in the actual -planning reserve margin constraint and other system planning and -operation modelling in ReEDS. Optimal coordination of dispatch among -energy storage resources is also assumed. The transmission and -coordination assumptions together allow for all storage within a -reliability assessment zone to be represented as a single aggregate -resource. The round-trip efficiency of this aggregated storage resource -is assumed to be equal to the energy-capacity-weighted average -round-trip efficiency of all installed storage capacity in that -region. - -All round-trip efficiency losses are included in storage charging. For -example, a storage resource with a round-trip efficiency of 85% and a -power capacity of 10,000 MW can dispatch 10,000 MW to the grid for 1 -hour using 10,000 MWh of energy capacity. However, when the same -resource draws 10,000 MW from the grid for 1 hour, its state-of-charge -increases by only 8,500 MWh. - -{numref}`figure-energy-capacity-requirements-for-storage` illustrates the dispatch and calculation of the energy -requirement for 5,000 MW of storage to receive full capacity credit in -the NYISO region in 2020. First, the storage power capacity is -subtracted from the peak load to set a net load maximum. Storage is -required to discharge whenever the load profile exceeds this maximum, to -ensure the peak net load (load minus storage in this example) is equal -to the peak load minus the power capacity of the storage device. The -storage is allowed to charge at all other times while ensuring the load -maximum is not exceeded. - -```{figure} ../../images/energy-capacity-requirements-for-storage.png -:name: figure-energy-capacity-requirements-for-storage - -**Model results for determining energy capacity requirements for storage in NYISO in 2020 for a 3-day example in August.** 47,000 MWh is determined to be the necessary energy capacity for 5,000 MW of storage to receive full capacity credit. A depth of discharge of 0 indicates that the storage is full. -``` - -This dispatch is then used to calculate the energy requirement for -storage to receive full capacity credit. At the beginning of the season, -the state-of-charge of storage within the region is assumed to be full. -The state-of-charge (or depth of discharge, as it is shown in {numref}`figure-energy-capacity-requirements-for-storage`) -is tracked over the course of the time-series with the maximum -depth of discharge left unconstrained. This means the maximum depth of -discharge value over the course of the season is equal to the amount of -energy capacity that is needed for storage to receive full capacity -credit. Dividing this energy by the power capacity used produces the -minimum fleet-wide average duration (hours) for storage to receive full -capacity credit. In the example in {numref}`figure-energy-capacity-requirements-for-storage`, 5,000 MW of peak demand -reduction from storage would require 47,000 MWh of energy to receive -full capacity credit, or a duration of 9.4 -hours. - -We repeat this process in each region for each season over a large -range of storage power capacities (from 0% to 90% of peak demand in -100-MW increments). The result of each dispatch is used to produce the -“power-energy curve” in {numref}`figure-storage-peak-capacity-determination`, which allows us to calculate the -marginal capacity credit for additional storage. The curve gives storage -energy capacity that is required for full capacity credit as a function -of storage penetration.[^ref45] At any point along the curve, the slope of -the tangent to the curve represents the number of hours needed for -marginal storage to receive full capacity credit. The incremental -capacity credit of an additional unit of storage is equal to the -duration of the additional unit installed divided by the duration -requirement (slope) at the point on the curve corresponding to the -installed storage penetration. - -```{figure} ../../images/storage-peak-capacity-determination.png -:name: figure-storage-peak-capacity-determination - -Determining storage peaking capacity potential in ReEDS. -The slope of each dashed line is the power-to-energy ratio for the -duration specified. Model results are for ERCOT in 2050. Note these -capacities are cumulative, starting from the shortest duration and -moving to the longest. -``` - -{numref}`figure-storage-peak-capacity-determination` also illustrates how -we create a more tractable solution by -reducing the number of combinations considered. Storage in ReEDS is -considered in several discrete durations, and these discrete durations -are used to define the requirements needed to receive full capacity -credit. Instead of a continuous function represented by the constantly -varying slope of the power-energy curve, we create several discrete peak -duration “bins” representing duration requirements. We start by plotting -a line with constant slope equal to the shortest duration considered and -find where it intersects with the power-energy curve. Then, starting -from that point, we plot a line with the next shortest duration and find -the point where it intersects with the power-energy curve, and so on, -until we have obtained the cumulative limit for each discrete duration -of storage to serve peak demand. - -As an example, the first segment (having a slope of two) requires two -hours to provide full capacity credit, even though it may be physically -possible for some small amount of storage with a duration less than two -hours to receive full capacity credit. In this example, at the point -where 4,309 of 2-hour storage has been added, the lines intersect and -the interpolation shifts to a slope of 4 hours, so a device with 4 hours -is now required to achieve full capacity credit. The model is still -allowed to build 2 hours storage, but it will only receive a 50% (2/4) -capacity credit, or the duration of the installed storage device divided -by the discrete peak duration “bin”. At each point, the marginal -capacity credit is calculated by the physical capacity of the -incremental unit, divided by the discrete duration requirement slope at -any point along the curve. - -The limit for each duration to serve peak demand from {numref}`figure-storage-peak-capacity-determination` is -passed back to the ReEDS model, and the model optimizes the capacity -credit of all storage (existing and new investments) together. One -advantage of this is that it informs the model of when the capacity -credit of storage should go up or down in response to changes in the net -load profile shape. Another advantage is that total storage peaking -capacity can be assessed in conjunction with other services storage can -provide such as curtailment recovery, energy arbitrage, and operating -reserves[^ref46], and a least-cost solution can be obtained -overall. - -Building on the results in the example above, {numref}`figure-installed-battery-capacity` shows the -actual installed capacities in ERCOT from the low battery cost -sensitivity scenario (discussed further in the results section). For -each battery storage duration available to the model, installed battery -capacity as well as the resource adequacy contribution determined by the -model are shown. This resource adequacy contribution is the result of -the model optimizing all grid services storage can provide, with -capacity credit of all storage subject to the constraints of the peaking -capacity limits from {numref}`figure-storage-peak-capacity-determination`. - -```{figure} ../../images/installed-battery-capacity.png -:name: figure-installed-battery-capacity - -Installed battery capacity and resource adequacy contribution (capacity derated by capacity credit) in ReEDS. -Model results for ERCOT in 2050. -``` - -This dynamic assessment of storage capacity credit enables the model to -identify the limitations of energy storage to provide peaking capacity. -It allows the model to identify the benefits, if they exist, of -deploying short-duration resources at reduced capacity credit for energy -arbitrage purposes or other grid services captured in the model. -Alternatively, the model is also free to deploy longer-duration storage -even when shorter durations would receive full capacity credit if this -leads to a least-cost solution for meeting all grid services. It also -allows the model to respond to changes in net load shape from wind and -PV deployment. The capacity credit of storage can change from one solve -year to the next as a result of these net load profile shape -changes. - -Peaking capacity potential for longer durations of storage are also -assessed within the model. The potential for 12- and 24-hour storage is -included in the assessments described in {numref}`figure-energy-capacity-requirements-for-storage` -and {numref}`figure-storage-peak-capacity-determination`. This -is meant to accommodate the potential to derate the capacity credit of -ten-hour batteries and capture the capacity credit of pumped-hydro and -compressed-air energy storage (which are assumed to have 12 hours of -duration in ReEDS). - -After this potential is determined, the actual storage capacity credit -in ReEDS is determined within the optimization. The durations of storage -devices that are installed by the model are evaluated based on the -peaking capacity potential of storage ({numref}`figure-energy-capacity-requirements-for-storage`). When determining the -contribution of storage toward resource adequacy, two constraints were -added to the model to make the capacity credit of storage dynamic and -flexible to the many changes in the system that can affect storage -capacity credit. The constraints for the formulation of storage capacity -credit in ReEDS are as follows: - -$$\sum_{pd}^{}{C_{pd,id} = C_{id}}$$ - -$$\sum_{id}^{}{C_{pd,id}*{cc}_{pd,id} \leq L_{pd}}$$ - -where L is the limit of peaking storage capacity (i.e. the megawatt -values from Figure 5), C is the installed storage capacity, id is the -duration of installed storage, pd is the duration of the peak demand -contribution being considered, and cc is the capacity credit of an -installed duration (id) of storage when applied to a specific peaking -duration (pd). Storage capacity credit is equal to installed duration / -peak duration, with a maximum of 1. For each duration of installed -storage id, its capacity can contribute to any duration of peak demand -pd, but the total installed storage capacity Cid must be -equal to the sum of its contributions toward each duration of peak -demand. And for each duration of peak demand pd, the total contribution -of each installed duration id of storage capacity (adjusted for their -capacity credit cc) cannot exceed the limit of peaking storage capacity -L of that pd. - -For example, consider a simple example where there is 100 MW of peaking -storage potential for each storage duration considered in ReEDS: two, -four, six, eight, ten, 12, and 24 hours. In this example, 200 MW of -two-hour storage, 100 MW of four-hour storage, and 50 MW of six-hour -storage are already installed. The model would optimize the capacity -credit of storage by giving 100 MW of two-hour storage full capacity -credit for its two-hour contribution, the 100 MW of four-hour storage -full capacity credit for its four-hour contribution, and the 50 MW of -six-hour storage full capacity credit for its six-hour contribution -({numref}`figure-storage-capacity-credit-allocation-example`). In this example, -the peaking potential limit of two- and -four-hour storage have been reached, so the remaining 100 MW of two-hour -storage would receive a capacity credit of 1/3 and contribute 33.3 MW -for its six-hour peak demand contribution. The model could then build -16.7 MW of six-hour storage at full capacity credit, at which point the -potential for six-hour storage to meet peak demand would be reached as -well. The model would then be able to build two-, four-, or six-hour -storage at a derated capacity credit with their contribution going -toward the eight-hour peak demand “bin,” or it could build 8-hour -storage with full capacity credit. - -```{figure} ../../images/storage-capacity-credit-allocation-example.png -:name: figure-storage-capacity-credit-allocation-example - -An example of storage capacity credit allocation in ReEDS. -200 MW of 2-hour batteries exist but there is only 100 MW of 2-hour -peaking capacity potential. Since there is also 100 MW of 4-hour -batteries serving all 100 MW of 4-hour peaking storage potential, the -remaining 100 MW of 2-hour storage provides 33.3 MW towards the 6-hour -peaking storage potential. -``` - -Now consider the same example but in addition to the two-, four-, and -six-hour storage installed, there is also 300 MW of pumped-hydro storage -in this region ({numref}`figure-storage-capacity-credit-allocation-example2`). -Pumped-hydro storage in ReEDS has a duration -of 12 hours, but the potential for 12-hour storage to serve peak demand -is only 100 MW. Rather than giving the remaining 200 MW of pumped-hydro -a capacity credit of ½ for its contribution to the 24-hour peak demand -period, it is optimal for the model to fill the 10- and 8-hour peak -demand “bins” with the remaining pumped-hydro capacity at full capacity -credit since there is no other storage allocated to those peak demand -periods. Now, after the model builds 16.7 MW of six-hour storage at full -capacity credit, the 8-, 10-, and 12-hour bins are already filled by -pumped-hydro storage. So, if the model wants to build additional storage -capacity, it will shuffle around the allocated storage capacity to the -optimal “bins” as it fills the 24-hour bin. In this example, if any -8-hour storage is built it will be allocated to the 8-hour bin and some -pumped-hydro capacity will be pushed out of that bin and re-allocated to -the 24-hour bin at ½ capacity credit (12 hours / 24 hours). So, even -though the duration required for storage to receive full capacity credit -at this point is 24 hours, 8-hour storage would receive a marginal -capacity credit of ½ because there is an excess of 12-hour storage -already installed in the system. - -```{figure} ../../images/storage-capacity-credit-allocation-example2.png -:name: figure-storage-capacity-credit-allocation-example2 - -The same example from {numref}`figure-storage-capacity-credit-allocation-example` but this time with 300 MW of 12-hour pumped hydro storage. Since there is only 100 MW of 12-hour peaking potential, remaining pumped-hydro capacity is allocated to serve shorter peak durations. -``` - -Storage capacity credit is sensitive to a variety of factors on the -power system, so rather than ignoring the many factors that can -influence storage capacity credit we simply pass the model information -on what storage *could* do to serve peaking capacity based on load shape -and storage duration and then allow the model to choose the least-cost -option based on the suite of available resources and the entire set of -storage revenue streams that are represented within the ReEDS -model. - -Denholm et al. {cite:year}`denholmPotentialBatteryEnergy2019` and Frazier et al. {cite:year}`frazierAssessingPotentialBattery2020` demonstrated how the -storage peaking potential of storage interacts with VRE -penetration. - - -#### "Stress periods” formulation - -- Thematic overview - - Use the same dispatch constraints as representative -periods, but: - - Scale up load by PRMN - - No weighting to hours (so they don’t -count toward VOM costs, fuel costs, emissions constraints; same as -capacity credit) - - Inter-period operation of storage is not currently -supported - - ReEDS2PRAS - - Typical generator sizes - - PRAS – probabilistic outages - - Stress metrics and iteration - -Several shortcomings arise under the capacity credit-based approach for -evaluating resource adequacy. In -ReEDS, planning resource can be traded between the Federal Energy -Regulatory Commission (FERC) Order 1000 regions, however the capacity -credit is still assessed where the resource is sited, misrepresenting -the evaluation for some generation assets. Additionally, identifying -stress periods using peak net load hours can potentially miss system -stress that results from events spanning consecutive days, such as -extreme weather. The alternative stress period formulation in ReEDS -attempts to mitigate some of these deficiencies. In this approach, a -probabilistic resource adequacy suite (PRAS) developed by NREL is -brought into the loop, allowing ReEDS to pass the system design to the -resource adequacy model after every solve year. The PRAS model is -described in a separate publication \[42\] , but its use in conjunction -with the ReEDS model is included briefly here. Essentially PRAS ingests -the ReEDS build out and utilizes 7 years of load and weather data to -identify the periods with the highest risk of unserved energy, these -periods are then passed back to ReEDS to ensure sufficient capacity is -built. Within PRAS the expected unserved energy is evaluated by running -a sequential Monte Carlo model to simulate the probability of individual -assets failing over the full multi-year optimization horizon producing -results for unserved energy. The simulation is run for multiple outage -draws after which the collective system stress periods can be -identified. - - -#### Planning Reserve Margins - -The planning reserve margin fractions applied in ReEDS are based on -reserve margin requirements for NERC reliability subregions {cite}`nerc2010LongtermReliability2010` -(see {numref}`figure-offshore-wind-resource`). Each ReEDS BA must meet the requirement, but regions can -engage in bilateral contracts for firm capacity subject to transmission -limits on AC or DC corridors. The planning reserve margin is enforced -seasonally such that each BA much meet the reserve margin requirement in -each of the four seasons. - -The planning reserve margin is constant over time for all regions -except ERCOT. Because ERCOT was below its NERC-recommended level in -2018-2020, the ERCOT reserve margin is set to the actual levels of 10.9% -and 8.6% for 2018 and 2019, respectively, and at the projected level of -10.6% for 2020 {cite}`ercotNewsReleaseERCOT2019`. The years from 2021 and onward are set at -13.75%, and future planning reserve margin levels are anticipated to -meet or exceed that target from 2021 and -onward. - - -### Operational Reliability - -In addition to ensuring adequate capacity to satisfy long-term planning -reserve requirements, ReEDS requires operational reliability—that is, -the ability to continue operating the bulk-power system in the event of -a sudden disturbance {cite}`nercGlossaryTermsUsed2016`. In practice, ancillary reserve -requirements ensure there is sufficient flexibility from supply-side and -demand-side technologies to rebalance fluctuations in generation and -demand. - -ReEDS represents three type of operating reserve products, including, -spinning, regulation, and flexibility reserves {cite}`coleOperatingReservesLongTerm2018`. The requirement specified for each product in each time-slice is -a function of load, wind generation, and photovoltaic capacity (during -daytime hours).[^ref47] Technologies providing these reserve products must -be able to ramp their output within a certain amount of time ({numref}`operating-reserve-reqs`). - -```{table} Summary of Operating Reserve Requirements -:name: operating-reserve-reqs - -| Reserve Product | Load Requirement (% of load)a | Wind Requirement (% of generation)b | PV Requirement (% of capacity)b | Time Requirement to Ramp (minutes) | -|----|---:|---:|---:|---:| -| Spinning | 3% | — | — | 10 | -| Regulation | 1% | 0.5%c | 0.3%c | 5 | -| Flexibility | — | 10% | 4% | 60 | -``` - -a See Lew et al. {cite:year}`lewWesternWindSolar2013`. -b Reserve requirements for wind and PV are derived from the -outcomes from Lew et al. {cite:year}`lewWesternWindSolar2013`. The flexibility requirement for wind is -estimated as the ratio of the change in the reserve requirement to the -change in wind generation from the Lew et al. High Wind scenario; the -requirement was estimated similarly for PV using the Lew et al. High -Solar scenario. -c The estimated regulation requirements (0.5% wind generation -and 0.3% PV capacity) are based on incremental increases in regulation -reserves across all scenarios in Lew et al. -{cite:year}`lewWesternWindSolar2013`. - -All ancillary reserve requirements must be satisfied in each BA for -each time-slice; however, reserve provision can be traded between BAs -using AC transmission corridors. Trades are only allowed within an RTO -and not across RTO boundaries. The amount of reserves that can be traded -is limited by the amount of carrying capacity of an AC transmission -corridor that is not already being used for trading -energy. - -The ability of technologies to contribute to reserves is limited by the -ramping requirement for a given reserve product, the plant ramp rate, -and online capacity ({numref}`generation-techs-flexability-params`). Online capacity is approximated in ReEDS -as the maximum generation from all time-slices within a modeled day. -Reserves can be provided by generation and storage technologies that are -turned on but not fully dispatched in a time-slice. In addition, -demand-side interruptible load can also contribute to reserve -requirements, if enabled in a scenario. Nuclear, PV, and wind are not -allowed to contribute toward the supply of -reserves. - -The cost for providing regulation reserves is represented in ReEDS -using data from {cite}`hummonFundamentalDriversCost2013`; see {numref}`cost-regulation-reserves`. Because ReEDS does -not clearly distinguish between coal fuel types, \$12.5/MWh is the -assumed regulation cost for all coal technologies. The cost of providing -regulation reserves from Gas-CT, geothermal, biopower, land-fill gas, -and CAES is assumed to be the same as oil/gas -steam. - -```{table} Flexibility Parameters of the ReEDS Generation Technologies -:name: generation-techs-flexability-params - -| | Assumed Ramp Rate (%/min) | Upper Bound (% of online capacity) = Ramp Rate (%/min) × Ramp Requirement (min) | | | -|----|:--:|:--:|:--:|:--:| -|   | | Spinning | Regulation | Flexibility | -| Gas-CTa | 8 | 8×10=80 | 8×5=40 | 8×60=480, so 100 | -| Gas-CCa | 5 | 5×10=50 | 5×5=-25 | 5×60=300, so 100 | -| Coala | 4 | 4×10=40 | 4×5=20 | 4×60=240, so 100 | -| Geothermalb | 4 | 4×10=40 | 4×5=20 | 4×60=240, so 100 | -| CSP with Storagec | 10 | 10×10=100 | 10×5=50 | 10×60=600, so 100 | -| Biopowerb | 4 | 4×10=40 | 4×5=20 | 4×60=240, so 100 | -| Oil/Gas Steama | 4 | 4×10=40 | 4×5=20 | 4×60=240, so 100 | -| Hydro | 100 | No Upper Bound | No Upper Bound | No Upper Bound | -| Storage | 100 | No Upper Bound | No Upper Bound | No Upper Bound | -``` - -a See {cite}`bloomEasternRenewableGeneration2016`. -b Geothermal and biopower values are assumed to be the same -as oil/gas steam units. In practice, geothermal plants typically do not -ramp given their zero or near-zero variable costs, and therefore only -provide energy and not operating reserves. -c. See {cite}`jorgensonEstimatingPerformanceEconomic2013`. - -```{table} Cost of Regulation Reserves -:name: cost-regulation-reserves - -| Generator Type | Cost of Regulation Reserves (2013$/MWh) | -|-----------------------------|----------------------------------------| -| Supercritical Coal | 15 | -| Subcritical Coal | 10 | -| Combined Cycle | 6 | -| Gas/Oil Steam | 4 | -| Hydro | 2 | -| Pumped Storage Hydropower | 2 | -``` - - -## Climate Impacts - -Previous versions of ReEDS, including the 2018 version {cite}`cohenRegionalEnergyDeployment2019`, -included a representation of climate impacts, and Section 7 of -the 2018 ReEDS documentation describes that capability. Recent changes -to the ReEDS time resolution are not compatible with the former climate -impacts representation, and it is expected that ReEDS climate impacts -capabilities will be restored for the 2024 model -version. - - -## Policy Descriptions - -Policies modeled in ReEDS include federal and state-level emission -regulations, tax incentives, and portfolio standards. This section -primarily focuses on existing policies, but additional frameworks -that exist in the model are discussed in [Other Policy Capabilities](#other-policy-capabilities). - - -### Federal and State Emission Standards -#### Cross-State Air Pollution Rule - -ReEDS applies the Cross-State Air Pollution Rule (CSAPR) using caps on -power plant emissions to the states in the eastern half of the United -States over which the rules are imposed. From 2017 onward, CSAPR annual -emission allowance budgets for NOx are applied at the state -level using the Phase 2 caps {cite}`epaEGRID2007Version1Year2008`. The caps are applied only -during the ozone season. ReEDS applies a seasonal estimate of these -ozone season caps that adjusts for the overlap of ReEDS season -definitions and ozone season definitions. States can trade allowance -credits within the eligible trading groups, but must keep emissions -below the required assurance levels. - -Sulphur Dioxide (SO2) emission limits are not represented in -the model because the caps would not be binding in the model except in -historical years. - - -#### Mercury and Air Toxic Standards - -Because compliance with the Mercury and Air Toxic Standards (MATS) has -already been largely achieved, we do not represent MATS in the ReEDS -model. - - -#### California Carbon Cap - -California’s Global Warming Solution Act of 2016 (referred to as -Assembly Bill 398 or AB 398) established a program to reduce -economy-wide greenhouse gas emissions to 1990 levels by 2020. In 2016, -legislation was passed that codified the 2030 greenhouse gas target to -40% below 1990 levels. In ReEDS, these state carbon caps are modeled as -a cap on electricity-system CO2 emissions from generators -either located in California or serving load in the state. Direct -CO2 emissions from generators located in California count -toward the cap. Imported electricity is assumed to have a emissions rate -of 0.26 ton CO2/MWh {cite}`carbCaliforniaGreenhouseGas2019`. - -Because California’s greenhouse gas reduction targets are legislated -for all economic sectors while ReEDS only models the electricity sector, -we rely on published economy-wide modeling results to estimate electric -sector-specific caps that are used in ReEDS. In particular, we apply -power sector caps based on the annual CA electric sector emissions (from -in-state and imported electricity) from California Public Utilities -Commission {cite}`cpucDecisionSettingRequirements2018`, which provides guidance for a 42 million -tCO2 cap by 2030. We enforce that cap from 2030 to 2050. The -pre-2030 cap ramps linearly from 60 million tCO2 in 2020 to -the 42 million tCO2 in 2030. Note that we also model -California’s RPS policy. - - -#### Regional Greenhouse Gas Initiative - -The Regional Greenhouse Gas Initiative (RGGI) cap-and-trade program -limits the CO2 emissions for fossil fuel-fired power plants -in eleven states: Connecticut, Delaware, Maine, Maryland, Massachusetts, -New Hampshire, New Jersey, New York, Rhode Island, Vermont, and -Virginia. - -We enforce allowance budgets from the updated model rule adopted in -2017.[^ref48] We ignore the provision for privately banked allowances and -therefore use the unadjusted budgets: 165 million short tons in 2012 -declining to 91 million by 2014, then declining 2.5% per year from 2015 -to 2020. According to the 2017 Model Rule, the 2021 cap is set at 75 -million short tons and decreases by 2.275 million tons per year until -2030. Beginning in 2020, we also enforce an additional budget of 18 -million short tons for the addition of New Jersey to the set of states -included in the RGGI[^ref49]. The budget for New Jersey is set to decline -by 30% through 2030[^ref50]. Similarly, beginning in 2021, we apply an -additional cap of 27.16 million short tons for the addition of Virginia -as a RGGI state. This cap is set to decline at a rate of 0.84 short tons -per year.[^ref51] We assume the budget remains constant beyond 2030. We do -not model banking of allowances, emissions offsets, or recycling of -initiative allowance revenues. - - -### Federal and State Tax Incentives -#### Federal Tax Credits for Clean Electricity and Captured Carbon - -Existing federal tax incentives are included in ReEDS, aligned with the -Inflation Reduction Act of 2022 (IRA). These include the PTC and the ITC -for clean electricity, the 45U credits for existing nuclear generation, -the 45Q credit for capturing and storing carbon, and the Modified -Accelerated Cost Recovery System (MACRS) depreciation schedules. [^ref52] -Current technology-specific depreciation schedules are modeled for all -years, because we assume they are permanent parts of the tax -code. - -Four clean electricity production and investment tax credits are -represented in ReEDS: - -- **Clean Electricity Production Tax Credit (PTC):** \$26/MWh for 10 -years (2022 dollars) plus a bonus credit that starts at \$1.3/MWh and -increases to \$2.6/MWh by 2028 -- **Clean Electricity Investment Tax Credit (ITC):** 30%, plus a bonus credit that starts at an additional 5% and -increases to 10% by 2028 (for totals of 35% and 40% respectively) -- **Captured CO2 Incentive (45Q):** \$85 per metric ton of -CO2 for 12 years for fossil-CCS and bioenergy-CCS, and \$180 -per metric ton of CO2 for 12 years for direct air capture; -nominal through 2026 and inflation adjusted after that -- **Existing Nuclear Production Tax Credit (45U):** This tax credit is \$15/MWh (2022 -dollars), but it is reduced if the market value of the electricity -produced by the generator exceeds \$25/MWh. As a simplification, this -dynamic calculation was not directly represented in ReEDS. Instead, to -represent the effect of this provision, existing nuclear generators are -not subject to economic retirement in ReEDS through 2032. - - -Note that IRA allows for bonus credits for both the clean electricity PTC and ITC (but -not applicable to 45U or 45Q) if a project either meet certain domestic -manufacturing requirements or is in an “energy community.” Projects can -obtain both bonus credits if they meet both requirements, which would -equate to \$5.2/MWh for the PTC and 20% for the ITC. In ReEDS, we assume -projects will, on average, capture one of the bonus credits by 2028, the -value of which is expressed in the summary above. In practice, there -will likely be greater diversity of captured credits amongst projects. -Relatedly, the values above are based on the assumption that all -projects will meet the prevailing wage -requirements. - -Under IRA, eligible clean electricity projects can select whether to -take the PTC or the ITC. As implemented in ReEDS, however, an a priori -analysis was performed to estimate which credit was most likely to be -more valuable, and the technology was assigned that credit. The -assignments are: - -- **PTC:** Onshore wind, utility-scale PV, and biopower -- **ITC:** Offshore wind, CSP, geothermal, hydropower, new nuclear, pumped storage -hydropower, distributed PV, and batteries. - -As represented in ReEDS, the -value of the tax credits is reduced by 10% for non-CCS technologies and -7.5% for CCS technologies, as a simple approximation of the costs of -monetizing the tax credits (such as tax equity financing).[^ref53] These -cost penalties are not reflected in the values given for each incentive -above. - -The clean electricity PTC and ITC are scheduled to start phasing out -when electricity sector greenhouse gas emissions fall below 25% of 2022 -levels, or 2032, whichever is later. Once the tax credits phase out, -they remain at zero—there is no reactivation of the credits if the -emissions threshold is exceeded at a later point. The exact value of the -threshold that would trigger the IRA clean electricity tax credits -phasing out has not been announced but is estimated at 386 million -metric tons of CO2e in this modeling. The 45Q and 45U credits -do not have a dynamic phaseout and are instead just scheduled to end at -the end of 2032. - -In the dGen model, distributed PV was assumed to take an ITC: the 25D -credit for residential, and the Section 48 credit for commercial and -industrial. For residential projects placed in service through 2032 the -ITC was assumed to be 30%, declining to zero for projects placed in -service in 2036. For commercial and industrial projects coming online -through 2035 the ITC was assumed to be 40%, dropping to zero after that. -These representations are simplifications, as there can be greater -diversity in captured value depending on factors such as ownership type -and tax status. Furthermore, due to limitations of the models used in -this study, the dynamic phase-out of the Section 48 ITC was not -reflected. In practice, most scenarios did not cross the emissions -threshold specified in IRA at this point, and therefore the adoption of -commercial and industrial distributed PV in the later years of those -scenarios was potentially underestimated. - -IRA includes additional bonus credits (up to 20%) for up to 1.8 GW per -year for solar facilities that are placed in service in low-income -communities. The dGen model runs used in this analysis did not have an -explicit representation of that additional bonus credit. Instead, 0.9 GW -per year of distributed PV was added to the original dGen estimates -through 2032. The estimate of 0.9 GW reflects the assumption that some -of the projects capturing the bonus credit may not be additional (i.e., -they would have occurred anyway even if the bonus credit was not -available). - -All the IRA tax credits are assumed to have safe harbor periods, -meaning a technology can capture a credit as long as it started -construction before the expiration of the tax credit. The maximum safe -harbor periods are assumed to be 10 years for offshore wind, 6 years for -CCS and nuclear, and 4 years for all other technologies. Generators will -obtain the largest credit available within their safe harbor window, -meaning that once a credit starts to phase down or terminate, ReEDS -assumes that efforts were made to start construction at the maximum -length of the safe harbor window before the unit came online. In -practice this means ReEDS will show generators coming online and -capturing the tax credits for several years beyond the nominal year in -which they expired. - - -### State Renewable Portfolio Standards - -ReEDS models state RPSs, including technology set-asides and renewable -energy certificates (RECs) that can count toward RPS compliance. RPS -rules are complex and can vary significantly between states. The RPS -representation in ReEDS attempts to model the primary impacts of these -RPS rules but includes many simplifying assumptions. In addition, in -recent years there have been numerous changes to RPS legislation. We -periodically update our representation to capture the recent changes to -the legislation; however, the numerous and frequent changes to state -laws create challenges to having a precise representation of all RPS -legislation. - -{numref}`cost-regulation-reserves` shows the respective RPS targets and technology set-asides for -years 2020, 2030, and 2050 as a percentage of state electricity sales as -modeled within ReEDS. These values—along with many other data that we -use to represent nuanced RPS rules—are based on data compiled by -Lawrence Berkeley National Laboratory, which takes into account the -in-state REC multiplier incentives and load adjustments (e.g., -sales-weighted RPS targets considering different load-serving entities -subject to compliance, such as investor-owned utilities, municipal -utilities, and cooperatives).[^ref54] Solar includes UPV and ro­oftop PV, -wind includes both land-based and offshore technologies, and distributed -generation (DG) includes rooftop PV and ground-mounted PV systems -located within the distribution network.[^ref55] ReEDS also models -alternative compliance payments for unmet RPS requirement for both main -RPS targets and solar set-asides as is consistent with the available -data.69 - -Technology eligibility for state RPS requirements is appropriately -modeled for each state.69 For instance, California’s RPS does -not allow in-state rooftop solar technologies to contribute toward its -RPS. Additionally, every state has specific rules regarding hydropower -generation’s eligibility toward contributing RECs, which are usually -based on each unit’s vintage and size (e.g., small hydro with specific -capacity cut-offs are eligible in some states). ReEDS models these as -allowable generation fractions from Barbose {cite:year}`barboseStateRenewablesPortfolio2023`, -which is imposed on each state’s total hydropower generation thereby limiting -the amount of hydropower RECs that each state could produce. - -{numref}`cost-regulation-reserves` also lists the allowable states from which each state may -import RECs; interstate REC transactions that are required to be bundled -with energy are marked with an asterisk. Except for California, ReEDS -enforces an upper limit on the total RECs (both bundled and unbundled) -that can be imported for that state’s RPS compliance. For California -alone, due to its unique out-of-state rules, ReEDS enforces two upper -limits, one on the total unbundled REC imports and the other on the -total bundled REC imports. There is a myriad of possibilities of -interstate REC transactions, in terms of both which two states can -transact and the quantity of those transactions. To constrain the -solution space of ReEDS to credible values, the interstate REC trading -modeling is based on historical observations {cite}`holtPotentialRPSMarkets2016`, as shown in -the final two columns of {numref}`cost-regulation-reserves`. The out-of-state total REC import -percentages for each state in are limited to those observed in 2012–2013 -{cite}`heeterCrossstateRPSVisualization2015`. - -Several states have implemented policies directed at offshore wind. To -represent these actions in ReEDS, we prescribe a floor to offshore wind -capacity based on known projects and policy mandates. Specifically, we -include offshore wind capacity that meets at least one of three -criteria: (1) currently operating capacity; (2) projects in active -solicitation processes; and (3) to meet statutory policy requirements. -The projects are based on tracking conducted for the NREL Offshore Wind -Technologies Market Report and state totals are shows in {numref}`offshore-wind-capacity`. -The model allows for economic deployment of offshore wind capacity beyond -these levels. All prescribed offshore wind projects are assumed to be -rebuilt once they are retired. - -Finally, voluntary renewable energy credits are also represented in -ReEDS. Only renewable energy technologies are allowed to supply -voluntary RECs, and Canadian imports are not allowed. -The voluntary REC requirement is based on the -observed amount of voluntary RECs from Heeter et al. {cite:year}`heeterStatusTrendsVoluntary2021` -and the requirement is assumed to grow by the smallest amount that has been -observed year-over-year (0.1624% in absolute terms). The voluntary -requirement includes an alternative compliance payment of \$10/MWh (in -2004\$). - -```{table} Cumulative Offshore Wind Capacity (MW) Mandated in ReEDS -:name: offshore-wind-capacity - -| State | 2020 | 2030 | 2040 | 2050 | -|----|---:|---:|---:|---:| -| CA | — | 3,100 | 4,707 | 4,707 | -| MA | — | 4,092 | 6,492 | 6,492 | -| MD | — | 5,044 | 8,500 | 8,500 | -| ME | — | 144 | 144 | 144 | -| NC | — | 2,800 | 2,800 | 2,800 | -| NJ | — | 5,100 | 11,000 | 11,000 | -| NY | — | 4,362 | 9,000 | 9,000 | -| RI | 30 | 1,538 | 1,538 | 1,538 | -| VA | 12 | 2,599 | 5,200 | 5,200 | -| Total | **42** | **28,779** | **49,381** | **49,381** | -``` - - -### 9.4. 9.4 Clean Energy Standards - -As of July 2023, 15 states had clean energy standards (CESs) (see Table -29). CES values are effective values[^ref56] and are taken from Barbose -{cite:year}`barboseStateRenewablesPortfolio2023`. These CESs are in effect -generalized versions of RPSs; their model representations are very similar -with technology eligibility being the only difference. For all but one of -the CES policies (Massachusetts), we assume all zero-carbon-emitting sources -(on a direct emissions basis) can contribute to the CES requirement. This -includes all renewable energy technologies (including hydropower and distributed -PV), nuclear power, and imports from Canada.[^ref57] The modeled CES -policies set a floor on electricity generated from clean energy -technologies but does not cap generation from nonclean sources. As a -result, in the model representation, a state can continue to generate -from existing fossil plants if the amount of clean energy generation -exceeds the requirement (even if the requirement approaches 100% of -sales). Most of the CES policies are assumed to start in 2030 and ramp -to their final targets by 2040 or 2050.[^ref58] For other aspects of the -CES model representation, we use the same assumptions as the -corresponding state RPS. These include assumptions about credit trading -and variations in load-serving entity requirements. In the case of -Virginia, fossil plants are required to retire per the schedule -indicated in the clean energy policy.[^ref59] Based on discussions with -stakeholders, fossil plants in Illinois and New York are also required -to retire once the policy reaches the nominal 100% -target. - -```{table} Clean Energy Requirement as a Percentage of In-State Sales -:name: clean-energy-req - -| **State** | **2020** | **2025** | **2030** | **2035** | **2040** | **2045** | **2050** | -|----|---:|---:|---:|---:|---:|---:|---:| -| CA | 0% | 0% | 55% | 70% | 85% | 100% | 100% | -| CO | 19% | 32% | 44% | 47% | 50% | 52% | 55% | -| MA | 20% | 28% | 37% | 45% | 54% | 63% | 71% | -| NM | 0% | 0% | 45% | 60% | 75% | 90% | 100% | -| NY | 0% | 0% | 75% | 87% | 100% | 100% | 100% | -| WA | 0% | 0% | 80% | 87% | 93% | 100% | 100% | -| VA | 0% | 24% | 39% | 56% | 76% | 96% | 100% | -``` - -### Storage Mandates - -Seven state storage mandates are represented in ReEDS. The storage -mandate are summarized in {numref}`energy-storage-mandates`. The mandates are required to be met -with battery storage, and any duration of storage -qualifies. - -```{table} Energy storage mandates, with required capacity listed in MW. -:name: energy-storage-mandates - -| **State** | **2020** | **2030** | **2050** | -|----|:--:|:--:|:--:| -| CA | 1,325 | 2,325 | 2,325 | -| MA | 50 | 50 | 50 | -| NJ | 600 | 2,000 | 2,000 | -| NV | | 1,000 | 1,000 | -| NY | 500 | 3,000 | 3,000 | -| OR | 2.5 | 2.5 | 2.5 | -| VA | 42.7 | 1,350 | 3,100 | -``` - - -### Nuclear Power Plant Policies - -There are four states that have enacted that provide compensation or -other assistance for in-state nuclear power plants: Connecticut, -Illinois, New Jersey, and New York. For these states, the nuclear power -plants are not allowed to retire until after the policy expires, unless -the power plant already has an announced retirement date. The policy -end-dates are taken from EIA {cite:year}`eiaElectricPowerMonthly2019a`. - -Additionally, there are several states that do not allow new nuclear -power.[^ref60] These states include California, Connecticut, Illinois, -Maine, Massachusetts, Minnesota, New Jersey, New York (Long Island -only), Oregon, Rhode Island, and Vermont. - - -### Other Policy Capabilities -In addition to the existing policies described above, ReEDS also -includes several optional policy implementations that are useful for -exploring alternative futures or the impact of existing policies. These -additional policy frameworks include: - -- **National Clean Energy Standard:** This framework allows the user to - specify which technologies count as “clean energy” and enforce a - minimum limit for the penetration of these clean energy - technologies. - -- **National Renewable Portfolio Standard:** This standard enforces a - national RPS, with the RPS trajectory defined by the - user. - -- **Carbon Cap-and-Trade:** This feature allows the user to specify - national-or subnational carbon cap-and-trade policies, including - options to represent trading limitations and banking and borrowing of - allowances. - -- **Carbon Tax:** This feature implements a user-specified carbon tax - on burner-tip emissions from the power - sector. - -- **National Emissions Limit:** This framework limits the total - national emissions according to user-specified values. The limit is - often referred to as a carbon cap or CO2 - cap. - -- **Alternative ITC and PTC Schedules:** In addition to the ITC and PTC - schedules described in [Federal and State Tax Incentives](#federal-and-state-emission-standards), - the ITC and PTC can be modified to apply for any number of years and to any - technology. - -- **Alternative Financing Measures:** Policy-related financing impacts - such as MACRS or the under-construction provisions for the ITC and PTC - can be modified as specified by the user. - - -## Capital Financing, System Costs, and Economic Metrics -### Financing of Capital Stock - -The financing assumptions used in ReEDS are taken directly from the -2023 ATB spreadsheet {cite}`nrel2023AnnualTechnology2023`, using the -“Market Factor Financials” and the 20-year capital recovery period options. -The ATB has technology-specific and time-varying financing parameters, -including interest rate, rate of return on equity, debt fraction, and tax -rate. Other elements of the ATB included in ReEDS include construction -schedules, MACRS depreciation schedules, and inflation rates. These -values are further defined and explained in the ATB, with additional -explanation of our financing implementation detailed in the Capital Cost -Financial Multipliers appendix of this -document. - -In previous versions of ReEDS, technology-specific costs of capital -were reflected through technology-specific discount rates. Due to the -different model structure of the intertemporal mode, and the desire to -keep the financial representations the same between modes, since the -2019 version the model has had only a single technology-agnostic -discount rate. Instead of varying the discount rate, the impact of any -difference between a technology’s weighted average cost of capital -(WACC) and the system average WACC is captured in a lump-sum adjustment -that represents the present-value of the higher (or lower) return to -capital. This representation implicitly assumes that differences in -financing terms primarily come from diversifiable risk, as opposed to -non-diversifiable risk. - - -### Electric Sector Costs - -Two system-wide cost metrics are calculated from each ReEDS run: a -present value of direct electric sector system costs and electricity -price. These cost calculations are not part of the ReEDS optimization -process; they are calculated after the ReEDS optimizations have been -conducted. ReEDS also includes a postprocessing option for estimating -the health costs of air pollution, described further -below. - - -#### Present Value of Direct Electric Sector Cost - -The present value system cost metric accounts for capital and operating -expenditures incurred over the entire study horizon for all technology -types considered, including generation, transmission, and storage. The -cost in each future year is discounted by a user-defined discount rate, -and by default it is set to 5%. Not to be confused with the discount -rate used in the optimization for investment decisions, the *investment* -discount rate is selected to represent private-sector investment -decisions for electric system infrastructure, and it approximates the -expected market rate of return of investors. All costs incurred before -the start of the specified economic horizon are assumed to be sunk and -are therefore not included in the system cost metric. Details about how -the system costs are calculated in ReEDS can be found in the Present -Value of Direct Electric Sector Cost section of the -appendix. - - -#### Electricity Price - -ReEDS calculates “competitive” electricity prices at different regional -aggregation levels -{cite:p}`murphyGenerationCapacityExpansion2005, ventosaElectricityMarketModeling2005, eiaAnnualEnergyOutlook2017a`. This calculation takes advantage of the linear programming -formulation of the model. Specifically, the marginal price on a model -constraint represents how much the objective function would change given -a change in the right side of the constraint. Each constraint can be -viewed as a market with a marginal price and quantity. At optimality, -the total revenue (i.e., the product of price and quantity) across all -constraints equals the objective function value. The constraints within -ReEDS are written such that the marginal values from the load -constraints can be used as a proxy for the competitive electricity -price. The load constraints are linked to the supply-demand balance -constraints, capacity constraints, operating reserve constraints, and -others through load variables. Taking the marginal value from the load -balance constraint, we can find the marginal value of an additional unit -of load (e.g., MWh) to the system, accounting for other requirements. -Specifically, the reported competitive prices in ReEDS capture five -categories of requirements, including energy, capacity, operating -reserves, and state-level and national-level RPS requirements (see Table -31). The competitive prices can be reported at different regional -aggregation level, scaled by requirement quantities. Details about how -these prices are calculated in ReEDS can be found in the Marginal -Electricity Prices section of the appendix. - -```{table} Relationships of Constraints to Grid Services Used to Calculate the Competitive Electricity Price -:name: grid-service-constraints - -| Constraint Category | Grid Service (s) | Region (r) | Time (h) | Units - Price (p_srht) | Units - Quantity (q_srht) | -|---------------------|-----------------------|-------------|-------------|------------------------|---------------------------| -| Operation | Energy | BA | Time-slice | $/MWh | MWh | -| Operation | Flexibility Reserve | BA | Time-slice | $/MW-h | MW-h | -| Operation | Regulation Reserve | BA | Time-slice | $/MW-h | MW-h | -| Operation | Spinning Reserve | BA | Time-slice | $/MW-h | MW-h | -| Resource Adequacy | Capacity | BA | Season | $/kW-yr | kW | -| Policy | State RPS | State | Annual | $/MWh | MWh | -| Policy | National RPS | National | Annual | $/MWh | MWh | -| Policy | CO2 Cap | National | Annual | $/metric ton | metric ton | -| Policy | RGGI CO2 Cap | Regional | Annual | $/metric ton | metric ton | -| Policy | SB32 CO2 Cap | Regional | Annual | $/metric ton | metric ton | -``` - -Besides “competitive electricity prices”, ReEDS also calculates the -average cost of electricity at the national, BA-level or state-level by -taking the annualized total costs of building and operating the system -in a specific geographic area and divided that by the electricity load -in that area. Annualized costs for existing (i.e., pre-2010) power -plants are also considered given plants’ initial investment costs and -the built year. BA-level average electricity prices also consider the -impact of energy and capacity trading. These prices reflect the average -costs to serve the load in certain areas. Detailed calculation equations -can be found in the Average Electricity Prices section of the -appendix. - - -#### Cost of Health Damages from Air Pollution - -In addition to direct system costs, ReEDS also includes a -postprocessing step for estimating health damages associated with air -pollution. Currently this focuses on mortality from long-term exposure -to fine particulate matter (PM2.5)[^ref61] from fossil fuel -combustion in the electric sector. - -To estimate health damages, ReEDS relies on estimates of the mortality -risk per tonne of emissions from three reduced complexity air quality -models (AP2, EASIUR, and InMAP).[^ref62] Each of these models estimates -PM2.5 formation associated with emissions of precursor -pollutants (NOx and SO2). To generate annualized -premature mortality, each model applies a concentration response -function from one of two studies linking exposure to PM2.5 to -increased mortality risk. These two studies, referred to as the American -Cancer Society Study (ACS) and Harvard Six-Cities Study (H6C) provide -estimates of the relationship between pollution exposure and premature -mortality {cite}`gilmoreIntercomparisonSocialCosts2019`. The result is an estimate of the -mortality risk per tonne of pollutant emitted in each U.S. county. This -marginal damage estimate can be aggregated to the ReEDS balancing area -level and multiplied by total emissions to estimate total -mortality. - -As a final step, annual premature deaths from air pollution can be -translated into a monetary value by applying a value of a statistical -life. For this ReEDS relies on the U.S. Environmental Protection -Agency’s estimate of \$7.4 million in 2006 dollars {cite}`epau.s.environmentalprotectionagencyMortalityRiskValuation2014` inflated to a -present-day dollar value (\$9.9 million in 2021 dollars). These costs can -then be translated into costs per unit of generation and cumulative (discounted) -cost over the study period. - -The approach described here focuses on direct emissions from the -electric power sector, and thus does not capture estimates from other -sectors (such as transportation, buildings, and industry) or upstream -emissions (such as from fossil fuel extraction or power plant -manufacturing). It also does not quantify any social costs of climate -change from CO2 or other greenhouse gas -emissions. - - -### Modeled Economic Metrics - -ReEDS calculates multiple economic metrics for analyzing investment -decisions in the model, including: - -- Levelized cost of energy (LCOE) - -- Technology value - -- Net value of energy (NVOE) - -- Net value of capacity (NVOC) - -- System profitability - -These metrics are described in detail below. - - -#### Levelized Cost of Energy - -LCOE measures the unit cost of electricity of a specific technology, -which is normally calculated as lifetime costs divided by energy -production. Specifically, the LCOE is calculated as follows -{cite}`nrel2019AnnualTechnology2019`: - -$$LCOE = \frac{FCR \times CAPEX + FOM}{CF \times 8,760} + VOM + FUEL$$ - -where FCR is the fixed charge rate; CAPEX is the capital expenditures; -FOM is the fixed operations and maintenance costs; CF is the capacity -factor; 8,760 is the number of hours in a year; VOM is variable -operations and maintenance costs; and FUEL is fuel costs (if -applicable). - -In each model year, ReEDS reports the LCOE for all technology options -considering different variations in tax credit treatments and capacity -factor assumptions. ReEDS also calculates the LCOE for technologies that -are built in this model year using the generation from these -technologies. - - -#### Technology Value - -ReEDS reports the value that generators receive from providing grid -services. Value is calculated as the product of service prices and -service provision quantities. For example, the value of a generator that -comes from providing energy service to meet planning reserve margin -requirement is calculated as the price of capacity multiplied by the -amount of firm capacity the generator can provide. The reported revenues -capture energy, capacity, operating reserve, and state-level and -national RPS requirements. Revenues can be normalized either by the -amount of generation or by the amount of installed -capacity. - -Revenues are closely related to, but are different from the electricity -price and service requirement quantity parameters. Revenues consider the -*provision* of different services from a certain generator in a region, -whereas service requirement quantities calculate the *demand* of -different services in a region. The sum of revenues from all generating -technologies in a specific region does not necessarily equal the sum of -products of all service prices and corresponding service -requirements. - - -#### Net Value - -ReEDS reports different economic viability metrics that consider both -*costs* and *values* of generating technologies to fully evaluate the -economic competitiveness of a certain technology, and to provide -intuitive explanations about investment decisions in the model. “Values” -of a generator reflect the potential economic benefit from displacing or -avoiding the cost of providing the services from other (marginal) -assets, while “costs” aggregate all different sources of costs needed to -build and operate a power plant to provide services. We define “net -value” as the difference between values and costs. Net value is related -to a concept in linear programming called “reduced cost.” Mills and -Wiser {cite:year}`millsEvaluationSolarValuation2012` describe reduced -cost in the context of electricity system modeling. - -We report three types of such metrics to assess the economic viability -of generators: net value of energy, net value of capacity, and system -profitability metrics ({numref}`net-value-metrics`). These metrics are reported both for -new investments in certain model year and for existing generators that -have been built. - -```{table} Summary of Net Value Metrics -:name: net-value-metrics - -| Metric | Conceptual Expression [Typical Units] | -|------------------------------|---------------------------------------| -| Net value of energy (NVOE) | (Value – Cost)/Energy [$/MWh] | -| Net value of capacity (NVOC) | (Value – Cost)/Capacity [$/kW-yr] | -| System profitability | f(Value/Cost) [unitless] | -``` - -Net value of energy (NVOE) measures the unit profit of a specific -technology, calculated as the difference between generator revenue and -costs, then normalized by the energy production. The typical unit is -dollars per megawatt-hour (\$/MWh). Similarly, net value of capacity -(NVOC) measures the unit profit of a specific technology, calculated as -the difference between generator revenue and costs, then normalized by -the installed capacity. The typical unit is dollars per megawatt -(\$/MW). - -Both of these two metrics are normalized metrics; because the -denominators vary broadly for different generator types, they may not -reflect the competitiveness of technologies consistently. Therefore, we -report a third type of economic viability metric, namely system -profitability metrics, which are essentially unitless functions of the -ratio between values and costs. Examples include profitability index -(value/cost) and return on investment (value/cost minus one). We report -both metrics in ReEDS, acknowledging that there are other formats of -system profitability metrics. - -These economic viability metrics help explain investment decisions in -the model. Specifically, for all types of new investment in a certain -model year, the model considers all the costs to build and operate a -certain technology as *costs*, and the contribution of the technology to -all binding constraints as *values* (i.e., service provision). Typical -value sources are discussed above in [Technology Value](#technology-value). In calculations of -economic viability metrics, however, other types of “values” -are included to fully reflect model decisions. For example, an increase -of ancillary service requirements that are due to higher wind -penetration is counted as a negative value stream for wind, and it is -included in the metrics calculation here. Therefore, these metrics fully -reflect all the model constraints related to the investment -decision. - - -## Model Linkages -### ReEDS-PLEXOS - -The ReEDS reduced-form dispatch and variable renewable parameterization -aims to represent enough operational detail for realistic capacity -expansion decisions, but the model cannot explicitly represent detailed -power system operations. To verify the feasibility of ReEDS solutions -and better inform its representation of system operation, NREL has -developed utilities to implement a ReEDS capacity expansion solution for -any solve year in the PLEXOS production-cost model -(PCM). - -PLEXOS is a commercial PCM tool capable of representing individual -generating units and transmission nodes for least-cost dispatch -optimization at hourly or subhourly time resolution. It can incorporate -unit-commitment decisions and detailed operating constraints (e.g., ramp -rates, minimum runtime) to simulate realistic power system operations. -NREL has previously used PLEXOS in several analyses such as the Western -Wind and Solar Renewable Integration Study and the Eastern Renewable -Grid Integration Study {cite:p}`lewWesternWindSolar2013, bloomEasternRenewableGeneration2016`. - -The ReEDS-PLEXOS linkage involves disaggregating the ReEDS solution and -adding necessary parameters for to the resolution necessary for PLEXOS. -To facilitate the translation, the existing linkage maintains the -spatial resolution of ReEDS and operates PLEXOS as a zonal model -matching ReEDS BAs to PLEXOS transmission zones. PLEXOS uses the ReEDS -transmission line capacity, and reactance and resistance are calculated -from ReEDS transmission properties to represent the aggregated -transmission system. Generating capacity within each zone is, however, -converted from aggregate ReEDS capacity to individual units in PLEXOS -using a characteristic unit size for each technology. For consistency, -ReEDS cost and performance parameters are used when possible and -reasonable, but values are taken from the average across WECC data when -parameters are not available from ReEDS or are available but used -inconsistently in ReEDS due to structural differences between the -models.[^ref63] - -Once the ReEDS solution is converted to a PLEXOS database, one can -simulate hourly dispatch over a full year and compare results with ReEDS -outcomes. A consistent solution builds confidence in the effectiveness -of ReEDS capacity expansion decisions, while inconsistencies and -reliability concerns such as load shedding indicate the need for -improving capacity expansion model structures. Additional details are -available in Frew et al. {cite:year}`frewSunnyChanceCurtailment2019`. - - -### ReEDS-Cambium - -Leveraging the capabilities of the ReEDS-PLEXOS linkage, a third -model—Cambium—has been developed. Cambium draws from ReEDS and PLEXOS -model solutions to assemble a structured database of hourly cost and -operational data for modeled futures of the U.S. electric sector. In -addition to directly reporting some metrics from both ReEDS and PLEXOS -(e.g., capacity buildouts from ReEDS and generation by technology from -PLEXOS), Cambium post-processes the outputs from both models to develop -new metrics that are designed to be useful for long-term -decision-making, such as a long-run marginal emission -rate.[^ref64] - -Data sets derived through Cambium can be viewed and downloaded at -. The documentation for Cambium contains -descriptions of the metrics reported in the databases and the methods -for calculating those metrics. - - -### ReEDS-JEDI - -A linkage between ReEDS outputs and the Jobs and Economic Development -Impact Models (JEDI) allows the analysis of technology-specific economic -results (jobs, earnings, value added, total output) to ReEDS scenarios. -Currently, linkages have been built for the JEDI land-based wind, -photovoltaics, natural gas, and coal models, so economic results are -limited to these technologies alone. ReEDS outputs of capacity, -generation, fuel use, capital cost, O&M cost, and fuel cost by BA are -processed through the JEDI models to produce state-level economic -results. - - -### ReEDS-reV - -The ReEDS supply curve for renewable technologies, including onshore -wind, CSP, utility scale PV, and geothermal are produced by reV. The -ReEDS-reV linkage allows for regional ReEDS investment decisions to be -mapped backed to individual reV supply curve sites. Site-specific supply -curve data from reV is binned for the ReEDS supply curve into five spur -line cost bins, from which investment decisions are made. By tracking -the timing and investment decisions within each of these bins, the -ReEDS-rev linkage maps regional capacity back to the individual sites -from which the bins were derived. - -The resulting siting data is used to further the understanding of the -ReEDS capacity expansion decisions and identify areas for improvement -for resource siting in reV. The ReEDS-reV linkage is a key component in -the translation of ReEDS capacity expansion results to a nodal -production cost modeling databases. - - -## References -```{bibliography} -:cited: -``` - - -## Appendix -### Natural Gas Supply Curves - -The ReEDS model does not explicitly model the U.S. natural gas (NG) -system, which involves multiple sectors of the economy and includes -complex infrastructure and markets. Rather, a regional supply curve -representation is a used to approximate the NG system as it interacts -with the electric sector. For more information on the impact of natural -gas representation in ReEDS, see Cole et al. -{cite:year}`coleViewFutureNatural`. - -The premise of using regional supply curves is that the price in each -region will be a function of both the regional and national NG demand. -The supply curves are parameterized from AEO scenarios for each of the -nine EIA census divisions (see {numref}`figure-offshore-wind-resource`). Two methods exist to -parameterize the natural gas supply curves and both are discussed here. -The first method which involves estimating a linear regression of prices -on regional and national quantities has been used in previous version in -ReEDS and is discussed first. The second method is relatively new to -ReEDS and involves parameterizing a constant elasticity of supply curve -and is discussed second. Through multiple tests, we have found minimal -differences in results between the two versions (1% or less of a change -in national generation by technology). - -**Linear Regression Approach** - -The AEO scenarios were used to estimate parameters for the following NG -price-consumption model: - -```{figure} ../../images/ng-price-consumption-model.png -:name: 1-ng-price-consumption-model - -[1] -``` - -where *Pi,j* is the price of natural gas (in \$/MMBtu) in -region *i* and year *j*, the *α* parameters are the intercept terms of -the supply curves with adjustments made based on region -(*αi*), year (*αj*), and the region-year -interaction (*αi,j*), *βnat* is the coefficient -for the national NG demand (*Qnat*, in quads), -*βi* is the coefficient for the regional NG demand -(*Qi,j*) in region *i*. Note that the four *α* parameters in -\[1\] can in practice be represented using only -*αi,j*. - -The β terms are regressed from AEO2014 scenarios, with nine of the 31 -AEO2014 scenarios removed as outliers {cite}`eiaAnnualEnergyOutlook2014`. These outlier -scenarios typically include cases of very low or very high natural gas -resource availability, which are useful for estimating NG price as a -function of supply but not for estimating NG price as a function of -demand—for given supply scenarios. The national and regional β terms are -reported in {numref}`figure-census-division-values`. We made a specific post-hoc adjustment to the -regression model’s outputs for one region; the βi term for the West -North Central division was originally an order of magnitude higher than -the other βi values because the West North Central usage in the -electricity sector is so low (0.05 quad[^ref65] in 2013, compared to -~0.5 quad or more in most regions). The overall natural gas usage (i.e., -not just electricity sector usage) in West North Central is similar to -the usage in East North Central, so intuitively it makes sense to have a -βi for West North Central relatively close to that of East North -Central. We therefore manually adjusted the West North Central βi term -to be 0.6 (in 2004\$/MMBtu/quad) and recalculated the alpha terms with -the new beta to achieve the AEO2014 target prices. The situation in West -North Central whereby such a small fraction of NG demand goes to -electricity is unique; we do not believe that the other regions warrant -similar treatment. - - -```{figure} ../../images/census-division-values.png -:name: figure-census-division-values - -*β* values for the nine census divisions -``` - -The “National” value at the far left is *βnat*. A *β* of 0.2 -means that if demand increases by one quad, the price will increase by -\$0.20/MMBtu (see Equation \[1\]). - -The *α* terms are then regressed for each individual scenario assuming -the same *β* values for all scenarios. Although the *β* terms are -derived from AEO2014 data, *α* terms are regressed using AEO2018 data -for the scenario they are intended to represent {cite}`eiaAnnualEnergyOutlook2019a`. Thus, we -assume natural gas price elasticity has remained constant while price -projections shift over time as represented by the *α* -values. - -**Comparison of Elasticities from Regression Approach to Literature Values** - -Technical literature tends to report the price elasticity of supply and -the price elasticity of demand, which are estimates of the supply and -demand, respectively, of a good given a change in price. In the -formulation given by Equation \[1\], we attempt to estimate a value that -is similar to the price elasticity of demand—we estimate a change in -price given a change in demand. Therefore, we present here a comparison -against the price elasticity of demand as the closest available proxy, -noting however that it is not necessarily identical to estimates of β. -Price elasticity of demand is typically negative but is reported here as -a positive number for convenience. - -External sources are varied and often vague in their estimates of price -sensitivity of natural gas. Using the reported domestic NG market demand -given for 2012 in AEO2014, the β values reported here yield an overall -NG sector elasticity value of 0.36–0.92 (higher values of β correspond -to lower elasticity values). Arora {cite:year}`aroraEstimatesPriceElasticities2014` estimated the price elasticity -of demand for NG to be 0.11–0.70, depending on the granularity and time -horizon of the NG price data considered. Bernstein and Griffin {cite:year}`bernsteinRegionalDifferencesPriceelasticity2006` -examined the price elasticity of demand for residential NG usage, and -they estimated the long-run elasticity to be 0.12–0.63 depending on the -region. The Energy Modeling Forum at Stanford University reports NG -price elasticity of demand for 13 different energy models {cite}`huntingtonEMF26Changing2013`. -The reported elasticity ranges from 0 to 2.20 depending on the -year, model, and scenario considered. For the NEMS model, which is used -for the AEO, the elasticity ranges from 0.22 to 0.81 depending on the -year and scenario {cite}`huntingtonEMF26Changing2013`. - -The EPA’s proposed Clean Power Plan included a projection that natural -gas usage will increase by 1.2 quads in 2020, resulting in an 8%–12% -increase in NG prices for the electric sector {cite}`smithEPACleanPower2014`. This -corresponds to a *βnat* of 0.38–0.51 in -2004\$/MMBtu/quad. - -**Constant Elasticity of Supply** - -The second method for representing gas price adjustments leverages a -constant elasticity of supply curve for census division prices as a -function of the quantities consumed. The general form of the equation -relies on a reference price ($\overline{p}$), a reference quantity -($\overline{q}$), and a price elasticity of supply ($\epsilon$)[^ref66] to -determine the endogenous price ($p$) based on an endogenous quantity -($q$) such that: - -$$p = \overline{p}\left( \frac{q}{\overline{q}} \right)^{\epsilon}$$ - -When parameterizing for the census division representations, the supply -curve should reflect the change in price given a change in the census -division’s quantity consumed in the electricity sector. To the best of -our knowledge, no published studies estimate the elasticity of supply -for natural gas specific to each sector and region. Therefore, the -calibrated curve needs to consider the change in the census division’s -price given a change in the consumption of natural gas in the region’s -electricity sector with respect to other regions and sectors. To do -this, the reference price, numerator, and denominator in the previous -equation are adjusted to reflect the consumption change only in the -electricity sector. Explicitly, the constant elasticity of supply -parameters are now indexed by census division ($r$) and sector -$s \in \{ electricity,\ \ industrial,\ \ residential,\ \ commercial,\ \ vehicles\}$). -The equation used to populate the supply curve in the model -becomes: - -$$p_{ele,r} = {\overline{p}}_{ele,r}\left( \frac{\sum_{s^{'} \notin ele,r^{'} \notin r}^{}{\overline{q}}_{s^{'},r^{'}} + q_{ele,r}}{\sum_{s,r}^{}{\overline{q}}_{s,r}} \right)^{\epsilon}$$ - -A potential addition to this representation, included as a switch in -the model, also includes national price adjustments as deviations from -the reference point. By denoting the national price as $p_{ele,nat}$, -the deviation from the benchmark price based on national quantities -consumed in the electricity sector can be computed -as: - -$$\Delta p_{ele,nat} = {\overline{p}}_{ele,nat}\left( 1 - \frac{\sum_{s^{'} \notin ele,r}^{}{{\overline{q}}_{s^{'},r} + \sum_{r}^{}q_{ele,r}}}{\sum_{s,r}^{}{\overline{q}}_{s,r}} \right)^{\epsilon}$$ - - -### Seasonal Natural Gas Price Adjustments - -We use natural gas futures prices to estimate the ratio of winter to -non-winter natural gas prices to implement seasonal gas price -differences in ReEDS. We chose futures prices for two reasons: (1) ReEDS -represents a system with no unforeseen disturbances, which is similar to -futures prices and (2) historical natural gas prices have fluctuated -greatly since the deregulation of natural gas -prices. - -{numref}`figure-natural-gas-futures-prices` shows the cyclical nature of the natural gas futures prices. -{numref}`figure-natural-gas-futures-prices-by-season` breaks the same prices out into seasons, showing that the -non-winter seasons have nearly the same price while wintertime prices -are consistently higher. Wintertime prices are on average 1.054 times -higher than non-winter prices. The standard deviation of this price -ratio is 0.004, indicating that the ratio shows very little year-to-year -variation. - -```{figure} ../../images/natural-gas-futures-prices.png -:name: figure-natural-gas-futures-prices - -Natural gas futures prices from the New York Mercantile Exchange for July 10, 2014 -``` - -The prices show the higher wintertime prices and the cyclical nature of -the prices. - -```{figure} ../../images/natural-gas-futures-prices-by-season.png -:name: figure-natural-gas-futures-prices-by-season - -Natural gas futures prices from {numref}`figure-natural-gas-futures-prices` separated by season. -``` - -Non-winter prices are nearly the same while wintertime prices are -consistently higher. - -A seasonal natural gas price multiplier is calculated in ReEDS based on -the natural gas price ratio such that wintertime prices are 1.054 times -higher than non-winter prices without changing the year-round average -price. Mathematically, this can be expressed as - -| $$P_{year - round} = W_{winter}P_{winter} + \left( 1 - W_{winter} \right)P_{non - winter}$$ | \[2\] | -|----|----| -| $$P_{winter} = 1.054P_{non - winter}$$ | \[3\] | -| $$P_{winter} = \rho P_{year - round}$$ | \[4\] | -| $$P_{non - winter} = \sigma P_{year - round}$$ | \[5\] | - -where P is the natural gas price for the period indicated by the -subscript, Wwinter is the fraction of natural gas consumption -that occurs in the winter months, and $\rho$ and $\sigma$ are the -seasonal multipliers for winter and non-winter, respectively. The -multipliers $\rho$ and $\sigma$ are determined by solving Equations -\[2\] through \[5\]. - - -### Capital Cost Financial Multipliers - -The financial multiplier represents the present value of revenue -requirements necessary to finance a new investment, including -construction financing, return to equity holders, interest on debt, -taxes, and depreciation. The formula is based on {cite}`shortManualEconomicEvaluation1995`. - -```{figure} ../../images/capital-cost-financial-multipliers.png -:name: figure-capital-cost-financial-multipliers - -``` - -1. **Construction cost multiplier:** additional cost for finance -construction -2. **Financing multiplier:** adjust required returns for -diversifiable risk -3. **Depreciation Expense:** reduce the taxable income by -the depreciation expense -4. **Depreciable Basis:** reduce the depreciable -basis due to the investment tax credit -5. **Investment tax credit:** reduce -the tax liability by the ITC -6. **Taxes:** additional revenues are required -to pay taxes - -**Construction Cost Multiplier:** The construction cost multiplier -(CCmult) captures the cost to finance the construction of the -plant at construction interest rate *i*. We use a mid-year discounting -and account for the deduction of interest payments for -taxes. - -$$CC_{mult} = 1 + \sum_{t}^{}{x_{t}\ \bullet \left\{ (1\ + \ i)^{t} - \ 1 \right\} \bullet (1 - T)}$$ - -The derivation of the construction cost multiplier is given -below. - -The total payment (*TP)* required to finance *x* percent of -construction investment (*Inv*) at interest rate *i* in construction -year *t---*where *t* is defined relative to the in-service date (t=0 is -the final year of construction; t=1 is penultimate year of construction; -etc.)---is the following: - -$${TP}_{t} = \ x_{t}\ \bullet \ Inv\ \bullet \ (1\ + \ i)^{t}$$ - -Define the interest payment (*I*) in year *t* as a function of the -total payment (*TP*) and the principal payment -(*P*): - -$$I_{t}\ = \ {TP}_{t}\ - \ P_{t}$$ - -$\ \ \ \ \ = \ x_{t}\ \bullet \ Inv\ \bullet \ (1\ + \ i)^{t}\ - \ x_{t}\ *\ Inv$ - -$\ \ \ \ \ = \ x_{t}\ \bullet \ Inv\ \bullet \left\{ (1\ + \ i)^{t}\ - \ 1 \right\}$ - -The tax savings (*S*) from interest deductions in year *t* at tax rate -*T* is equal to: - -$$S_{t}\ = \ I_{t}\ \bullet T$$ - -Therefore, the absolute net change in the investment cost due to -construction financing is the interest payments less the tax -savings: - -$$\Delta\ cost\ (absolute)\ = \sum_{t}^{}{I_{t} - S_{t}}$$ - -$$= \sum_{t}^{}{I_{t} - I_{t} \bullet T}$$ - -$$= \sum_{t}^{}{I_{t} \bullet (1 - T)}$$ - -$$= \sum_{t}^{}{x_{t}\ \bullet \ Inv\ \bullet \left\{ (1\ + \ i)^{t} - \ 1 \right\} \bullet (1 - T)}$$ - -Finally, the total relative change in the investment cost due to -construction financing is: - -$\Delta\ cost\ (relative)$ = - -$$= \left( Inv + \sum_{t}^{}{I_{t} - S_{t}} \right)\ /\ Inv\ $$ - -$$= 1 + \frac{1}{Inv} \bullet \sum_{t}^{}{x_{t}\ \bullet \ Inv\ \bullet \left\{ (1\ + \ i)^{t} - \ 1 \right\} \bullet (1 - T)}$$ - -$$= 1 + \sum_{t}^{}{x_{t}\ \bullet \left\{ (1\ + \ i)^{t} - \ 1 \right\} \bullet (1 - T)}$$ - -**Financing Multiplier:** The financing multiplier (not to be confused -with the financial multiplier) is an adjustment to reflect either higher -or lower returns to capital, relative to the system-wide average return -to capital. Conceptually, it is a multiplier that reflects the total -present-value of a stream of higher (or lower) payments to capital, -relative to what the payments would be at the system’s average cost of -capital. For example, if a technology’s WACC ($WACC_{tech})$ is 7% and -the system-wide WACC is 5% ($WACC_{sys})$, and the technology is being -evaluated for a 20-year horizon (l) at a real discount rate of 5% -($d_{r})$, the financing multiplier (${fin}_{mult})$ would be 1.25, per -the equation below. This multiplier represents that the total -present-value of the returns to capital for this technology must be -higher (by an amount equal to 25% of the initial investment), relative -to a technology with average financing terms. The difference is the -technology WACC and system WACC represents the difference is returns to -capital due to diversifiable risk. - -$${fin}_{mult} = 1 + \left( WACC_{tech} - WACC_{sys} \right) \bullet \frac{1 - \frac{1}{\left( {1 + d}_{r} \right)^{l}}}{d_{r}}$$ - -To derive the above equation, begin with the definition of the capital -recovery factor (*CRF*) for real discount rate ($d_{r})$ and economic -horizon (*l*): - -$$CRF = \frac{Annuity}{Present\ Value\ of\ Annunity} = \frac{d_{r}}{1 - \frac{1}{\left( {1 + d}_{r} \right)^{l}}}$$ - -$$Present\ Value\ of\ Annuity = \frac{1}{CRF} \bullet Annuity$$ - -Therefore, for every dollar invested in a technology, the absolute -difference in required return is: - -$\Delta\ returns\ (absolute) = \$ 1 \bullet WACC_{tech} \bullet \frac{1}{CRF} - \$ 1 \bullet WACC_{sys}*\frac{1}{CRF}$ - -Finally, the relative difference in required return per dollar invested -is: - -$$\Delta\ returns\ (relative) = \frac{\$ 1 + \Delta}{\$ 1} = 1 + \Delta$$ - -**Depreciation Expense:** The present value of depreciation (PVdepr) -expense is computed based on the fraction of the plant value that is -depreciable in each year. All investments use a MACRS depreciation -schedule with $f_{t}^{depr}$ representing deprecation fraction in year -t. This depreciation is sheltered from taxes, which is reflected by the -term $1 - T*PV_{depr}$ in the financial multiplier equation -above. - -$$PV_{depr} = \sum_{t}^{}{\frac{1}{\left( 1 + d_{n} \right)^{t}} \bullet f_{t}^{depr}}$$ - -**Depreciable Basis:** The eligible cost basis for MACRS depreciation -expense is reduced by one-half the effective value of the tax -credit: - -$$PV_{depr}*\left( 1 - \frac{{ITC}_{eff}}{2} \right)$$ - -**Investment Tax Credit:** The value of the ITC is reduced, to reflect -the costs of monetizing it ($m_{ITC}$). The effective investment tax -credit value (${ITC}_{eff})$ reduces the tax burden of the -investments. - -$${ITC}_{eff} = ITC \bullet m_{ITC}$$ - -**Taxes:** The denominator term of the financial multiplier equation, -“1-T”, reflects the additional revenues necessary to pay taxes. The tax -burden is adjusted for depreciation expenses as well as the effective -investment tax credit. - -**Weighted Average Cost of Capital:** The technology-agnostic, nominal -discount rate is represented as the average WACC. Where, df -is the debt fraction, *roren* is the nominal rate of return -on equity, *T* is the effective tax rate, and *In* is the -nominal interest rate on debt. - -$$d_{n} = (1 - df)*{rore}_{n} + (1 - T)*df*I_{n}$$ - -### Present Value of Direct Electric Sector Cost - -The equations in this section are used to calculate the present value -cost of building and operating the system for some defined economic -analysis period. To calculate the present value of total system cost, -the cost in each future year $t$ is discounted to the initial year of -the economic analysis period, $t_{0}$, by a social discount rate, -$d_{social}$. The real social discount rate used here for present value -calculation is different from the investment discount rate assumptions, -or cost of capital (WACC) assumptions. - -The present value, or $PV$ in the equation, consists of two cost -components: 1) the present value of all operational costs in the model -for the analysis period, $PV_{operational}$, including fixed and -variable operating and maintenance costs for all sectors, as well as -fuel costs and 2) the present value of all new capital investments, -$PV_{capital}$. The present value of energy system costs is then -calculated as: - -$$PV = PV_{operational} + PV_{capital}$$ - -Operational costs, $PV_{operational}$, and capital costs -category,$\ PV_{capital}$, are discounted from year $t$ by -$\frac{1}{\left( 1 + d_{social} \right)^{t - t_{0}}}$ for each year in -the analysis period: - -$$PV_{operational} = \sum_{t = t_{0}}^{t_{f}}{C_{op,t} \times \frac{1}{\left( 1 + d_{social} \right)^{t - t_{0}}}}$$ - -$$PV_{capital} = \sum_{t = t_{0}}^{t_{f}}{C_{cap,t} \times \frac{1}{\left( 1 + d_{social} \right)^{t - t_{0}}}}$$ - -where $C_{op,t}$ is the operational costs in year t, and $C_{cap,t}$ is -the capital costs in year $t$. For all ReEDS system cost results, we -assume the operational costs for the non-modeled year are the same as -the closest model year. - -In this present value calculation, the economic analysis period is -2018–2050. The social discount rate used for present value calculations, -$d_{social}$, is assumed to be 7% (real). This is different from the -WACC assumption for investment decisions - - -### Marginal Electricity Prices - -ReEDS marginal “competitive” electricity prices are derived from the -linear programming formulation. - -In standard form, the primal formulation of a linear program -is: - -$$(P)\ \ \ \ \min{c^{T}x}$$ - -$${s.t.}{\ \ \ \ \ Ax \geq b}$$ - -$$\ \ \ \ \ \ \ \ \ \ \ \ \ \ x \geq 0$$ - -The associated dual formulation of the primal -is: - -$$(D)\ \ \ \ \max{y^{T}b}$$ - -$${s.t.}{\mathbf{\ \ \ \ \ }y^{T}A \leq c^{T}}$$ - -$$\ \ \ \ \ \ \ \ \ \ \ \ \ \ y \geq 0$$ - -Consider a simplified formulation of the ReEDS model with a subset of -constraints: (1) resource limits, (2) capacity limits, (3) supply/demand -balance, (4) planning reserve margin requirement, (5) operating reserve -requirement, and (6) national and/or state-level RPS requirements. The -primal formulation is: - -**Parameters** - -$capcost_{i}$: capital cost of model plant i (\$/MW) - -$vomcost_{i}$: variable O&M cost of model plant i (\$/MWh) - -$s_{i}$: available supply of model plant i (MW) - -$load$: electric load (MW) - -$cv_{i}$: capacity value of model plant i (MW) - -$f^{prm}$: planning reserve margin (unitless) - -$f^{or}$: operating reserve requirement (unitless) - -$f^{RPS}$: national and/or state-level RPS requirement (unitless) - -**Variables** - -$C_{i}$: capacity of model plant i (MW) - -$G_{i}$: generation of model plant i (MWh) - -$OR_{i}$: operating reserve allocation of plant *i* (MWh) - -$$minimize\ \sum_{i}^{}{capcost_{i} \bullet C_{i} + vomcost_{i} \bullet G_{i}}$$ - -Subject to: - -$$C_{i} \leq s_{i}\ \ \ \ \ \forall i\ \ \ \ \ \lbrack 1\rbrack$$ - -$$\frac{G_{i}}{8,760} + \frac{OR_{i}}{8,760} - C_{i} \leq 0\ \ \ \ \ \forall i\ \ \ \ \ \lbrack 2\rbrack$$ - -$$\sum_{i}^{}{G_{i} = load}\ \ \ \ \ \lbrack 3\rbrack$$ - -$$\sum_{i}^{}{{cv_{i} \bullet C}_{i} \geq \frac{\left( 1 + f^{prm} \right)}{8760} \bullet load}\ \ \ \ \ \ \lbrack 4\rbrack$$ - -$$\sum_{i}^{}{OR_{i} \geq f^{or} \bullet load}\ \ \ \ \ \lbrack 5\rbrack$$ - -$$\sum_{i \in RE}^{}{G_{i} \geq f^{RPS} \bullet load}\ \ \ \ \ \lbrack 6\rbrack$$ - -$$C_{i}, G_{i},OR_{i} \geq 0\ \ \ \ \ \forall i \ \ \ \ \ \lbrack 7\rbrack $$ - -Constraints \[1\] define the resource limits for each model plant. -Constraints \[2\] limit how capacity is allocated for each model plant -(i.e., for energy or reserves). Constraint \[3\] requires the total -generation supplied to equal the load. Constraint \[4\] ensures the -total firm capacity meets the planning reserve margin requirement. -Constraint \[5\] ensures the total operating reserves meet the operating -reserve requirement. Constraint \[6\] requires that total generation -from renewable technologies meets the state-level and national RPS -requirements. - -From the dual formulation of the primal, the objective function is*:* - -$$y^{T}b = y_{1} \bullet s + y_{2} \bullet 0 + y_{3} \bullet load + y_{4} \bullet \frac{(1 + prm)}{8760} \bullet load + y_{5} \bullet f^{or} \bullet load + y_{6} \bullet f^{RPS} \bullet load$$ - -Reformulating the primal with Constraints \[3\], \[4\], \[5\], and -\[6\] “linked” with a “load” variable, *L*, an alternative, but -equivalent, primal formulation is the following: - -$$minimize\ \sum_{i}^{}{capcost_{i} \bullet C_{i} + vomcost_{i} \bullet G_{i}}$$ - -Subject to: - -$$C_{i} \leq s_{i}\ \ \ \ \ \forall i\ \ \ \ \ \lbrack 1\rbrack$$ - -$$\frac{G_{i}}{8760} + \frac{OR_{i}}{8760} - C_{i} \leq 0\ \ \ \ \ \forall i\ \ \ \ \ \lbrack 2\rbrack$$ - -$$\sum_{i}^{}{G_{i} - L \geq 0}\ \ \ \ \ \lbrack 3^{'}\rbrack$$ - -$$\sum_{i}^{}{{cv_{i} \bullet C}_{i} - \frac{\left( 1 + f^{prm} \right)}{8760} \bullet L \geq}0\ \ \ \ \ \ \lbrack 4^{'}\rbrack$$ - -$$\sum_{i}^{}{OR_{i} - f^{or} \bullet L \geq 0}\ \ \ \ \ \lbrack 5'\rbrack$$ - -$$\ \sum_{i \in RE}^{}{G_{i} - f^{RPS} \bullet L} \geq 0\ \ \lbrack 6'\rbrack$$ - -$$C_{i}, G_{i},OR_{i} \geq 0\ \ \ \ \ \lbrack 7\rbrack$$ - -$$L = load\ \ \ \ \ \lbrack 8'\rbrack$$ - -From the dual formulation of the alternative primal, the objective -function is: - -$$y^{T}b = y_{1} \bullet s + y_{2} \bullet 0 + y_{3^{'}} \bullet 0 + y_{4^{'}} \bullet 0 + y_{5^{'}} \bullet 0 + y_{6^{'}} \bullet 0 + y_{8^{'}} \bullet load$$ - -Equating the dual objective functions from the two equivalent primal -formulations, we find that the marginal off the linking constraint -\[8’\] is a blending of all constraints containing the “load” variable, -including, constraints \[3\], \[4\], \[5\], and \[6\]: - -$$y_{8^{'}} \bullet load\mathbf{=}y_{3} \bullet load + y_{4} \bullet \frac{\left( 1 + f^{prm} \right)}{8760} \bullet load + y_{5} \bullet f^{or} \bullet load + y_{6} \bullet f^{RPS} \bullet load$$ - -$$y_{8^{'}} = y_{3} + y_{4} \bullet \frac{\left( 1 + f^{prm} \right)}{8760} + y_{5} \bullet f^{or} + y_{6} \bullet f^{RPS}$$ - -Therefore, we define the marginal off the linking constraint -$\lbrack y_{8^{'}}\rbrack$ as the “all-in” marginal price of electricity -(i.e., change in total cost \[objective function\] given a small change -in load). This marginal electricity price includes the energy price, -capacity price, operating reserve prices, and potential RPS prices. -Marginal electricity prices are reported at BA level with different -requirement categories. These prices can be aggregated at different -regional level, weighted by corresponding requirement quantities for -certain category. - - -### Average Electricity Prices - -Average electricity prices are calculated as the annualized total costs -of building and operating the system in certain geographic area, divided -by the electricity load in that area. At national level, the prices are -calculated as: - -$$p(costtype,\ year) = \frac{systemcost_{costtype,year}}{load_{year}}$$ - -where system costs include both annualized capital and operational -costs. Annualized costs for existing (i.e. pre-2010) power plants are -also considered given plants’ initial investment costs and the built -year. - -At BA-level, average electricity prices also consider the impact of -energy and capacity trading: - -$$p(costtype,BA,year)$$ -$$ = ca{pital}_{costtype,BA,year} + o{peartional}_{costtype,BA,year}$$ -$$ + \lbrack \sum_{n}^{}{import_{n,p,h,year} \times price_{n,h,year}}$$ -$$ - \sum_{n}^{}{export_{p,n,h,year} \times price_{p,h,year}} \rbrack _{energy} $$ -$$ + \lbrack \sum_{n}^{}{import_{n,p,szn,year} \times price_{n,szn,year}} $$ -$$ - \sum_{n}^{}{export_{p,n,h,year} \times price_{p,szn,year}} \rbrack _{capacity}$$ - -Where n, p and BA all indicate balancing areas, $import_{n,p,h,t}$ -indicates energy or capacity transfer from n top;$\ export_{p,n,h,t}$ -indicates energy or capacity transfer from p to n. Capital costs also -include annualized costs for pre-2010 power plants. - -Specifically, the energy import/export is calculated as: - -$$\sum_{n}^{}{import_{n,p,h,t} \times price_{n,h,t}} = \sum_{n}^{}{powerfracupstream_{n,p,h,t} \times gen_{p,h,t} \times price_{n,h,t} \times hours_{h} \times (1 + loss_{n,p,h,t})}$$ - -$$\sum_{n}^{}{export_{p,n,h,t} \times price_{p,h,t}} = \sum_{n}^{}{powerfracdownstream_{p,n,h,t} \times gen_{p,h,t} \times price_{p,h,t} \times hours_{h}}$$ - -where t is year, p and n are both balancing areas, h indicates time -slices. - - -### Spatial Resolution Capabilities - -The ReEDS model has four default spatial resolutions, shown in -{numref}`figure-available-region-options`. The default settings use the model balancing areas (bottom -left of {numref}`figure-available-region-options`). The model also includes a custom aggregation -capability that enables users to select any aggregation of regions built -from counties or balancing areas. National-scale county-level resolution -runs are extremely computationally intensive, so require simplifications -in other aspects of the model (e.g., fewer timesteps, solve years, or -technologies) to be able to produce a solution, and even with -simplifications it requires hundreds of gigabytes of memory to process -the county-level inputs. Any runs that use aggregated states require -that state policies be turned off because the model does not have any -built-in features for aggregating state policies for states that have -been combined. - -```{figure} ../../images/available-region-options.png -:name: figure-available-region-options - -Region options available in the ReEDS model for doing model runs. -``` - -The spatial framework built into the ReEDS model allows for other -spatial resolutions. For example, nodal datasets can be represented in -the model. When running with nodal data, each renewable energy resource -site can only be associated with a single node, so the node assignments -have to be done before a model run is -performed. - -The model also has the capability to use mixed resolutions. For -example, California can be represented using model balancing areas, -while the rest of the United States is represented at state resolution. -This can enable finer detail for a specific region of interest, while -still capturing trades with neighboring regions as lower resolution, but -with a reasonable solution time. - - -#### Data Inputs and Handling - -Nearly all ReEDS data inputs that include a spatial dimension are -specified at the model balancing area resolution.[^ref67] In order to be -able to perform runs at county-level resolution, some inputs are -included at both the county-level and balancing area-level -resolution. - - -#### Transmission Data - -Transmission capacity between counties is based on nodal transmission -network data (see {numref}`figure-nodal-transmission-network-data`) collected as part of the North American -Renewable Integration Study {cite}`brinkmanNorthAmericanRenewable2021a`. Nodes from -the data set are spatially matched to counties using nodal coordinates and -a shapefile of U.S. counties (described below). With this dataset there -are a few dozen counties have no transmission nodes or capacity, which -may be the result of missing data. To address this, nodes and lines are -added to ensure that every county has at least one transmission -interface. This is done by either adding a node on existing lines that -cross a county but did previously have nodes in that county, or if there -are no transiting lines by adding a node to the county centroid and -matching to the closest node in a neighboring -county. - -```{figure} ../../images/nodal-transmission-network-data.png -:name: figure-nodal-transmission-network-data - -Nodal transmission network data. Black lines are those from the dataset, and red lines are the lines that were added to ensure that every county included at least one interface. -``` - -Power flow constraints imposed by the topology of the network can limit -the true transfer capacity between two counties to a level below the -physical capacity of the lines connecting those counties. ReEDS -estimates these interface capacity limits using an optimization method -that finds the maximum transfer values given network characteristics, -the location of generators and load, and other constraints {cite}`brownGeneralMethodEstimating2023`. -Because interface limits are typically less influenced by parts -of the network that are further away, the method is run on a subset of -the network. This subset is selected by including all parts of the -network that are a specified number of “hops” away from the interface -being optimized. A comparison of the results from the optimization -method with different hops found that total transfer capacity saturated -after 6 hops, so this value was used when calculating the county-level -transfer limits used in ReEDS. Since the transfer capacity can differ -depending on the direction, the optimization is run once in each -direction (forward and reverse) for each interface. - -After the optimization, some counties have zero transfer capacity in -one or both directions; these are replaced with either the transfer -capacity estimated in the other direction if it is non-zero or the -thermal capacity of the line. To estimate metrics such as TW-mi of -transfer capacity, ReEDS uses the distance between the centroids of the -two counties in the interface. The final transmission limits calculated -using this method are show in {numref}`figure-transfer-limits`. - -```{figure} ../../images/transfer-limits.png -:name: figure-transfer-limits - -Final transfer limits used in the county-level input dataset for the forward direction. -``` - - -#### Wind and Solar Supply Curve Data - -Supply curves for wind and solar are based on data from the renewable -energy potential model (reV), which provides total resource potential, -representative resource profiles, and any location-dependent supply -curve costs {cite}`maclaurinRenewableEnergyPotential2021`. Each supply curve -point from the reV model is mapped directly to its corresponding county. These -supply curve points are then aggregated by ReEDS to produce county level supply -curves. - -The reV model includes estimates of the cost of investments needed to -reinforce the transmission network with the addition of more wind and -solar. For the ReEDS balancing area spatial representation, these -network reinforcement costs are calculated by determining the least cost -interconnection point and then estimating the transmission upgrades -needed between that point and balancing area’s interregional network -node. Since the county-level resolution now explicitly represents -transmission investments between counties, the network reinforcement -costs from reV are not included in the transmission cost estimates of -the county supply curves. Spur line costs, or the cost to build from the -resource site to the interconnection point, are still taken from reV. In -the future the reV model may be adapted to produce network reinforcement -costs at the county level, though they might be sufficiently small that -ignoring them would be appropriate. - - -#### Power Plant Capacity Data - -Capacity data in ReEDS for existing units, prescribed builds, and -prescribed retirements[^ref68] are taken from the National Electricity -Modeling System (NEMS) power plant database. The power plants in this -database include latitude and longitude to give their location. These -locations are mapped to counties to provide the county assignment for -the power plants. In a few isolated cases, hydropower units that were on -a county boundary were manually assigned to a county to better align -with the jurisdiction that operates that plant. For example, the -Columbia River serves as a boundary line for several counties, and -hydropower plants on the Columbia were assigned to the county’s public -utility district that owns and operates that dam, rather than to the -county that mapped to the specific latitude and longitude -value. - - -#### Shape Files - -Matching transmission nodes to counties and plotting maps of -county-level results requires shapefiles of U.S. counties. For this -purpose, ReEDS relies on the 2022 vintage of TIGER/Line Files published -by the Census Bureau, which includes all legal boundaries and names as -of January 1, 2022 {cite}`u.s.censusbureau2022TIGERLine2022`. The shapefiles -are converted to the ESRI:102008 coordinate reference system and any -counties outside the continental U.S. are dropped. - - -#### Scaling Datasets to County Resolution - -All datasets besides those described above were downscaled from the -balancing area resolution to county level resolution using one of five methods: - -**Uniform Disaggregation:** - -All counties within a balancing area are assigned the same value as the -one used for the balancing area. - -**Downscaling based on population:** - -The “population” disaggregation method uses population fractions as -multipliers to calculate county-level data from BA-level inputs. The -multipliers used in this method represent the fraction of a county’s -population with respect to its corresponding ReEDS BA. Population data -used to create the multipliers are sourced from the 2021 Population -Totals dataset provided by the US Census Bureau \[link\]. Example data -for ReEDS BAs p29 and p30 are shown below in {numref}`population-fraction-ex-data`. - -```{table} Example data of population fractions used in downscaling ReEDS input data based on population. -:name: population-fraction-ex-data - -| ReEDS Balancing Area (BA) | County | Population Fraction | -|----|----|----| -| p29 | p04001 | 1 | -| p30 | p04019 | 0.956 | -| p30 | p04023 | 0.044 | -``` - -Since only one county exists in the ReEDS BA “p29,” the population -fraction for that county is 1. On the other hand, two counties exist in -the ReEDS BA “p30”: the population fractions show that 95.6% of the -population of p30 live in county p04019, while 4.4% of the population -lives in p04023. To disaggregate by population, the dataset is mapped to -regionally-indexed BA-level ReEDS input data and the Population Fraction -is multiplied by the values of the BA-level dataset. - -**Downscaling based on geographic size:** - -The geographic size disaggregation method operates similarly to the -“population” disaggregation method but instead uses the fraction of a -county’s geographic area with respect to its corresponding ReEDS BA as -fractional multipliers for downscaling BA-level input data to county -level. Geographic area data used to create the multipliers are sourced -from the 2022 TIGER/Line US County Shapefile provided by the US Census -Bureau \[link\] and found in the inputs folder of the ReEDS -repository. - -**Downscaling based on the existing hydropower capacity:** - -The existing hydropower disaggregation method uses the fraction of -existing hydropower capacity in a given county with respect to the total -hydropower capacity of the county’s corresponding ReEDS BA as fractional -multipliers for downscaling BA-level input data to county level. -Existing hydropower capacity data used to calculate these fractional -multipliers are sourced from the EIA-NEMS generator database included in -the ReEDS inputs. This down-scaling method is used for -hydropower-specific data, such as hydropower upgrades. - -**Downscaling based on transmission line size:** - -Fractional multipliers used in the transmission line size -disaggregation method represents the ratio of transmission capacity -between a given US county and a Canadian balancing area in relation to -the total transmission capacity of the county’s corresponding US -balancing area. As an example: if US balancing area p1 is comprised of 2 -counties, and 300 MW of transmission capacity exists between county 1 -and the Canadian balancing area and 100 MW of transmission capacity -exists between county 2 and Canadian balancing area, then the ratio of -3/4 (0.75) is used to disaggregate data between county 1 and the -Canadian balancing area while a ratio of 1/4 (0.25) is used to -disaggregate data between county 2 and the Canadian balancing area. -Transmission data used to create these multipliers are sourced from the -same nodal dataset used to create the transmission interface limits -described above. Note that transmission lines found in the source data -are considered to be bidirectional: therefore, when calculating the -total transmission capacity between a US BA and Canadian BA both -directions must be considered. This down-scaling method is applied to -Canadian import and export inputs. - -We selected one of the 5 downscaling methods above for each of the -inputs that included a spatial dimension. The choice was made using -analyst judgement. The input structure of ReEDS is such that if an -appropriate county-level dataset becomes available, it can be used in -place of the downscaled dataset. - - -#### Input Data Handling - -Because some input data are specified at both the balancing area -resolution and the county resolution, the inputs used for a given run -will depend on the spatial resolution selected for that run. The input -scripts include logic that will read in the file with the appropriate -spatial resolution, and use that for the remainder of the run. In the -case of mixed resolutions, both files will be read in, and the -appropriate regions will be concatenated to create a single input file -with the specified spatial resolutions. - -ReEDS has been set up to run so that only data for the regions being -modeled will be included in the model. For example, if doing a run that -includes only the state of North Dakota, the inputs processing step of -ReEDS will filter all input data to include only the data for North -Dakota.[^ref69] - -Spatial datasets are dynamic within the model itself, so the model is -agnostic to the region names. - - -#### Challenges and Benefits of Enhanced Spatial Resolution - -The greater spatial resolution available in ReEDS with county-level -inputs creates a variety of opportunities to apply the ReEDS model to -answer questions. It enables specific regions of the country to be -captured to greater resolution, enabling more granular outputs of power -plant siting, transmission expansion, and emission impacts. The higher -resolution can also highlight key regional boundaries or interfaces that -might not have been present in a lower resolution model run. Our testing -has also shown that county-level resolution can lead to better estimates -of curtailment because there is more detail on the underlying -transmission system. - -The enhanced spatial resolution also comes with a variety of -challenges. These include runtime, especially as the number of regions -considered grows. Much of our testing showed that a 10-fold increase in -the number of regions led to at least a 10-fold increase in solve time, -though runtime ultimately depends on the machine specifications and the -model options selected for that particular run. Another major challenge -is sourcing appropriate input data. If the down-scaling methods -described above are not suitable for answering the questions of a -particular analysis, then new data will be to be procured. Additionally, -even the best transmission datasets we had available still had -omissions, so it is unclear if key data will be missing for studying a -particular region. - -Finally, enhanced spatial resolution can lead to false precision, where -users see model solutions at high spatial resolution, and put more stock -into that model solution than is warranted due to uncertainty in the -data or methods used. For example, Mehrtash et al. {cite:year}`mehrtashDoesChoicePower2023` -show that the choice of transmission power flow representation can have -significant impact on the model solution. - - -### Differences from the 2020 Model Version - -{numref}`model-differences` summarizes the key differences from the 2020 model version. -{numref}`dgen-model-differences` summarizes the key differences in the dGen model, which is -used to provide the rooftop PV input projections for ReEDS. - -```{table} Key Differences in Model Inputs and Treatments for ReEDS Model Versions -:name: model-differences - -| Inputs and Treatments | 2020 Version (July 2020) | 2023 Version (July 2023) | -|----|----|----| -| Fuel prices | AEO2020 | AEO2023 | -| Demand growth | AEO2020 | AEO2023? | -| Generator technology cost, performance, and financing | ATB 2020a | ATB 2023a | -| Endogenous retirements | On by default; when turned on, plants retire when they cannot recover at least half of their fixed O&M | On by default; when turned on, plants retire when they cannot recover at least half of their fixed O&M | -| Coal fixed O&M | Escalates from 2019 using assumptions from AEO2019 | Escalates from 2019 using assumptions from AEO2019 | -| Nuclear fixed O&M | Escalates from 2019 using assumptions from AEO2019 | Escalates from 2019 using assumptions from AEO2019 | -| Wind, solar, and load data | Includes data for 2007–2013; dispatch is done using 2012 data and capacity credit calculations are done using 2007–2013 data {cite}`coleConsiderationsMaintainingResource2020`| Includes data for 2007–2013; dispatch is done using 2012 data and capacity credit calculations are done using 2007–2013 data {cite}`coleConsiderationsMaintainingResource2020` | -| Electrification | Includes three levels of electrification | Includes three levels of electrification | -| Demand-side flexibility | Includes three levels of flexibility | Includes three levels of flexibility | -| Renewable fuel combustion turbine | Includes combustion turbine that runs on a generic renewable fuel with a minimum 6% capacity factor | Includes combustion turbine that runs on a generic renewable fuel with a minimum 6% capacity factor | -| Upgrades | Thermal technologies can be upgraded (e.g., by adding CCS). | Thermal technologies can be upgraded (e.g., by adding CCS). | -| Storage curtailment recovery | Uses hourly net load profiles and a dispatch algorithm to determine the amount of curtailment that can be recovered by storage | Uses hourly net load profiles and a dispatch algorithm to determine the amount of curtailment that can be recovered by storage | -| Battery storage durations | Includes 2-, 4-, 6-, 8-, and 10-hour battery storage | Includes 2-, 4-, 6-, 8-, and 10-hour battery storage | -| Storage capacity credit | Calculated using seven years of hourly data; capacity credit bins by duration allow for nonlinear changes in the optimization model; one-hour buffer accounts for uncertainty in forecasts and ability to dispatch | Calculated using seven years of hourly data; capacity credit bins by duration allow for nonlinear changes in the optimization model; one-hour buffer accounts for uncertainty in forecasts and ability to dispatch | -| Wind and solar capacity credit | Calculated using seven years of hourly resource and load data | Calculated using seven years of hourly resource and load data | -| Wind supply curve | Spatially-explicit modeling of multiple exclusions and setbacks from buildings, roads, transmission rights-of-way, and radar along with other exclusion layers | Spatially-explicit modeling of multiple exclusions and setbacks from buildings, roads, transmission rights-of-way, and radar along with other exclusion layers | -| Wind degradation | Annual degradation of 0.27% per year represented based on empirical data {cite}`hamiltonHowDoesWind2020` | Annual degradation of 0.27% per year represented based on empirical data {cite}`hamiltonHowDoesWind2020` | -| PV degradation | 0.7%/yr per the ATB 2020 | 0.7%/yr per the ATB 2020 | -| Wind and solar curtailment | Modeled using a simplified hourly dispatch model | Modeled using a simplified hourly dispatch model | -| Pumped-hydro capital cost | Declines over time per Hydropower Vision {cite}`doeHydropowerVisionNew2016` | Declines over time per Hydropower Vision {cite}`doeHydropowerVisionNew2016` | -| Storage energy arbitrage value | Calculated using hourly prices | Calculated using hourly prices | -| Minimum capacity factor for NGCT | 1% per PLEXOS runs of the 2019 Standard Scenarios | 1% per PLEXOS runs of the 2019 Standard Scenarios | -| Tax credits | Use a four-year safe harbor construction period; December 2019 production tax credit update represented; tax credits for CCS represented (use of captured carbon is not considered) | Use a four-year safe harbor construction period; December 2019 production tax credit update represented; tax credits for CCS represented (use of captured carbon is not considered) | -| State policies | Policies as of June 2020 | Policies as of June 2020 | -| Nuclear power plant assistance | Assistance for Connecticut, Illinois, New Jersey, New York, and Ohio represented | Assistance for Connecticut, Illinois, New Jersey, New York, and Ohio represented | -| Outage rates | Outage rates based on 2014–2018 Generating Availability Data System data | Outage rates based on 2014–2018 Generating Availability Data System data | -``` - -a The default cost recovery period is 20 years in ReEDS and -30 years in the ATB. - -```{table} Key Differences in dGen Model Versions** -:name: dgen-model-differences - -| Inputs and Treatments | 2019 Version | 2020 Version | -|----|----|----| -| Demand growth | AEO2019 | AEO2020 | -| Technology cost | ATB 2019 | ATB 2020 | -| Tariff set | Curated in January 2019 | Curated in June 2020 | -| Wholesale electricity prices | ReEDS 2019 | ReEDS 2020 | -| State and utility net energy metering policies | Updated in March 2019 | Updated in June 2020a | -``` - -a If states have no mandated NEM expiry dates, a distributed -solar penetration threshold was implemented, which was determined from -values of peer states. - - -[^ref1]: “Regional Energy Deployment System Model,” NREL, - - -[^ref2]: Production technologies include those that produce hydrogen or - caption carbon from the air. - -[^ref3]: VRE is also sometimes referred to as Variable Renewable Energy - Resource - -[^ref4]: “Regional Energy Deployment System Model,” NREL, - - -[^ref5]: Here, the t+1 notation is used heuristically, as the model year - subsequent to *t* can be *t+1, t+2, t+3,* etc. - -[^ref6]: The current default is 20 years, but it can be adjusted by the - user. - -[^ref7]: Hydropower’s contribution to planning reserves depends on its - categorization as dispatchable or non-dispatchable, which is - discussed in [Hydropower](#hydropower). - -[^ref8]: CO2 equivalent emissions from upstream methane are - sensitive to assumptions regarding leakage rate and the time horizon - for methane global warming potential. Other life cycle emissions - (often with considerable uncertainty) are not included here, - including methane from hydropower, biomass net emissions, CO2 - leakage from CCS, and other emissions. Methane leakage is not - included in emissions estimates for transportation or - residential/commercial/ industrial end-use applications, or in - historical estimates of electricity sector emissions. - -[^ref9]: A ReEDS-India model version has also been developed. Details of - the implementation are not discussed here. - -[^ref10]: These additional geographical layers defined in ReEDS do not - necessarily align perfectly with the actual regions, except for - state boundaries, which are accurately represented. - -[^ref11]: The full spatial resolution capability with county-level data was - not available publicly until version 2024.1.0 - (). - -[^ref12]: All renewable resource assessments are independent and mutually - exclusive of each other due to their unique nature and to allow - ReEDS to dynamically evaluate cost-optimal capacity expansion - without any upstream ranking of which technologies would be - preferred at a given site. This implementation ignores any possible - land-use conflicts between multiple technologies at the same site, - but spatial aggregation and resource heterogeneity is expected to - alleviate this limitation. - -[^ref13]: CSP refers to solar thermal power and not concentrating PV. - -[^ref14]: Where given in the sections below, renewable energy resource - potential values refer to the resource potential represented in - ReEDS and not the total technical resource potential. The renewable - potential capacity modeled in ReEDS includes exclusions in the - pre-processing steps for the model, such as site exclusions, assumed - transmission access limits, or a narrower set of technologies - considered. Lopez et al. {cite:year}`lopezLandUseTurbine2021b` present - renewable technical potential for the United States. - -[^ref15]: Individual wind sites are grouped into ten resource classes for - ReEDS, based on average wind speed (The wind resource is not evenly - binned into the 10 classes, as the better classes have higher - resolution (smaller bins)). - -[^ref16]: Represents the difference in overnight capital cost from the 5 MW - system (the smallest reported) and the 100 MW system from {numref}`figure-cv-calculation-ldc-approach` - of Fu, Feldman, and Margolis {cite:year}`fuSolarPhotovoltaicSystem2018`. - -[^ref17]: - -[^ref18]: The solar multiple (SM) is defined as the ratio of the design - solar field aperture area to the aperture area required to produce - the power cycle design thermal input (and power output) under - reference environmental conditions. - -[^ref19]: Historical and announced trough-based systems are characterized - with technology-appropriate characteristics. - -[^ref20]: While differentiating pre- and post-1995 is somewhat arbitrary, - it allows the model to better represent performance differences - between relatively old and new coal technologies. - -[^ref21]: Retrofits from Gas-CC to Gas-CC-CCS are also allowed. - Additionally, Gas-CT plants are allowed to be retrofitted to burn a - renewable energy fuel, such as hydrogen, green methane, or - biodiesel. These retrofits can occur with existing Gas-CT plants or - with new builds. Within ReEDS these plants are called RE-CT plants, - and have the same O&M and heat rate as Gas-CT plants. - -[^ref22]: Landfill gas generators are classified as conventional generators - but can count toward renewable portfolio standard requirements. - -[^ref23]: Net winter capacity is used to adjust the capacity available in - ReEDS during winter timeslices. It is applied as a ratio between net - winter capacity and net summer capacity. - -[^ref24]: See , accessed - November 11, 2016. - -[^ref25]: See to - get access to the repository. - -[^ref26]: Hydrogen can also be deployed to meet seasonal storage needs and - is discussed more in [Hydrogen](#hydrogen). - -[^ref27]: Values in 2016\$ - -[^ref28]: For details see . - -[^ref29]: The level of plant aggregation is a scenario input option. Plants - can be aggregated to one plant type per region or left at their - native unit-level resolution. - -[^ref30]: When running with endogenous retirements, any technology type can - be eligible to be retired endogenously by the model. However, some - technologies are not represented properly to be appropriately - considered for endogenous retirements. - -[^ref31]: ReEDS does not account for any decommissioning costs for - renewable or any other capacity type. - -[^ref32]: Supply curves are nonlinear in practice, but a linear regression - approximation has been observed to be satisfactory under most - conditions. - -[^ref33]: The elasticity coefficients are derived from all scenarios of - AEO2018, but the price-demand set points are taken from any one - single scenario of the AEO. - -[^ref34]: This heuristic method of tracing a path from the POI to the - largest load center in the zone is highly simplified and does not - represent all the considerations involved in an actual - interconnection study. - -[^ref35]: For example, Vancouver and Portland are the largest populations - centers in the southern Washington and northern Oregon regions - respectively. However, these centers are only about 10 miles apart. - Modeling such a short distance between these nodes would potentially - create a bias for transmission investments between Washington and - Oregon. So Yakima was used in lieu of Vancouver as the node location - for southern Washington. - -[^ref36]: See . - -[^ref37]: Load balancing is implemented with equality constraints, so there - is no physical representation of lost load and an associated cost. - -[^ref38]: In ReEDS, capacity credit is defined as the fraction of nameplate - capacity that contributes to the planning reserve requirement. - -[^ref39]: LOLP is defined as the probability of a loss-of-load event in - which the system load is greater than available generating capacity - during a given period. - -[^ref40]: ELCC is the contribution (units of MW that can then be reported - as a fraction of the installed capacity to represent CV) that an - additional resource provides toward meeting the system’s load while - maintaining a fixed system-wide reliability level. - -[^ref41]: When running intertemporally, these values are calculated after - each intertemporal solve. The model solves, recomputes these values, - then solves again, and continues until convergence is reached. - -[^ref42]: Residual LDC, or RLDC, is an equivalent term to NLDC and is used - in the literature. - -[^ref43]: We currently use only a single year of wind, solar, and load data - to calculate capacity. Expansion of this method to use multiple - years of data would increase the robustness of this calculation, and - it is currently under development. - -[^ref44]: We refer to “existing” CV as the reliable capacity contribution - from resources that have already been deployed in the model before - the buildout of additional “marginal” resources. - -[^ref45]: To account for forecasting errors and uncertainty in future - loads, this curve is shifted by one hour of storage duration. Thus, - 2-hour storage gets full capacity credit for meeting peaks that are - 1 hour in duration, 4-hour storage gets full capacity credit for - peaks that are 3 hours or shorter, etc. - -[^ref46]: It is worth noting that storage resources can provide resources - to the electricity grid beyond peaking capacity and energy - arbitrage. A capacity-expansion model like ReEDS has limited - representation of these services, but to the extent that they are - represented in the model these services are captured when assessing - energy storage. See the ReEDS documentation {cite}`brownRegionalEnergyDeployment2020` - for more information on operating reserve representation in ReEDS. - -[^ref47]: The PV reserve requirement is only valid during daytime hours - when the PV systems are operating. In addition, the requirement is a - function of capacity rather than generation because reserves are - especially important around sunrise and sunset when PV generation is - low. - -[^ref48]: “2017 Model Rule,” accessed April 26, 2018, - . - For more information, see: - - “About the Regional Greenhouse Gas Initiative (RGGI),” fact sheet - updated August 2016, - - - “The RGGI CO2 Cap,” - - - “Regional Greenhouse Gas Initiative,” December 2013, - . - -[^ref49]: RGGI press release officially adding New Jersey to the set of - RGGI states, - - -[^ref50]: New Jersey State press release, specifying New Jersey’s RGGI - budget, - -[^ref51]: See . - -[^ref52]: Note that the eligible cost basis for MACRS is reduced by - one-half the value of the tax credit. - -[^ref53]: CCS projects are eligible for a direct pay option for the first 5 - years of the 45Q credit or until 2032 (whichever comes first), with - the credits returning to non-refundable status after that point. The - lower monetization penalty is meant to approximate the benefit of - the direct pay option. - -[^ref54]: See Barbose {cite:year}`barboseStateRenewablesPortfolio2023` and - . - -[^ref55]: See Database of State Incentives for Renewables & Efficiency - (DSIRE) website at [dsireusa.org](http://www.dsireusa.org/) . If - data are unavailable, ReEDS forces RPS target to be met by using a - default alternative compliance payment and solar alternative - compliance payments of \$200/MWh and \$400/MWh respectively. - -[^ref56]: Not all electricity produced in a state is subject to the state - law. For example, electricity co-ops or federal entities might not - be required to comply with the CES, leading to an effective CES - fraction that is smaller than the one stated in the law. - -[^ref57]: For Massachusetts, we assume CCS technologies are also eligible, - but we disallow hydropower because of the post-2010 commercial - operation date requirement in the state policy {cite}`doerElectricitySectorRegulations2018`. - -[^ref58]: The modeled CES for CO2 is assumed to start in 2020 - and includes the clean energy commitments from the largest electric - utility in the state (Xcel Energy), which were codified into law in - 1. The modeled CES for Massachusetts begins at 16% in 2018 and - increases to 80% by 2050. - -[^ref59]: To provide ReEDS with foresight to know that the phaseout is - coming in Virginia, we implement an increasing capital cost - financing multiplier to plants that are being phased out. This - multiplier shortens the cost recovery period of the plant. For - example, when evaluating whether to build a Gas-CC unit in 2040 (5 - years before the scheduled phaseout), the financial multiplier for - Gas-CC includes a 5-year cost recovery period. - -[^ref60]: See . - -[^ref61]: Previous work has found that accounting for mortality results in - the largest component of monetized benefits {cite:p}`epau.s.environmentalprotectionagencyBenefitsCostsClean1999, nrcnationalresearchcouncilHiddenCostsEnergy2010` that - PM2.5 exposure is the driver of 90%–95% of all - mortalities related to air pollution {cite:p}`tessumInMAPModelAir2017, tschofenFineParticulateMatter2019`. - -[^ref62]: Additional description of the models and the marginal damage - estimates used in ReEDS can be found at - https://www.caces.us/data. - -[^ref63]: Minimum load is an example of one such parameter. The aggregate - representation of minimum load in ReEDS at the technology-BA level - does not effectively reflect unit-level operating constraints used - in PLEXOS, so PLEXOS uses native assumptions for minimum load. - -[^ref64]: The long-run marginal emission rate is a metric designed to help - estimate the emissions induced (or avoided) by a persistent change - in electricity consumption. Unlike the short-run marginal emission - rate, the long-run marginal emission rate reflects the structural - changes to the grid that can be induced by a persistent change in - electricity consumption. - -[^ref65]: A quad is a quadrillion Btu, or 1015 Btu. - -[^ref66]: The default value of $\epsilon$ is assumed to be 0.76 from values - estimated by Ponce and Neuman {cite:year}`ponceElasticitiesSupplyUS2014a` - -[^ref67]: Exceptions include state-level policies, which are specified at - the state level, NOx emission trading groups, and transmission - interface limits between system operator boundaries. - -[^ref68]: Prescribed builds are builds that are forced into the model - because they have already been built or are under construction, such - as the Vogtle nuclear power plant. Prescribed retirements are power - plant retirements that are forced into the model based on actual - retirements or retirement announcements. - -[^ref69]: Older versions of the ReEDS model (version 2022 and earlier) - included the full spatial dataset, and then subset the model - equations to only include equations for the region of interest. diff --git a/docs/build/html/_sources/postprocessing_tools.md.txt b/docs/build/html/_sources/postprocessing_tools.md.txt deleted file mode 100644 index 28e808cf..00000000 --- a/docs/build/html/_sources/postprocessing_tools.md.txt +++ /dev/null @@ -1,176 +0,0 @@ -# Post-Processing and Analysis Tools -There are several tools that can be found in the ReEDS repository. - -## Helper Scripts and Tools -### Comparison - -**postprocessing/compare_cases.py** - -Compare_cases.py will take two ReEDS case paths and create a powerpoint comparing the cases. - -Command to run this script: `python postprocessing/compare_cases.py [path to ReEDS run #1] [path to ReEDS run #2]` - -Example: -``` -$ python postprocessing/compare_cases.py /Users/km/ReEDS-2.0/runs/v20231221_USA /Users/km/ReEDS-2.0/runs/v20231221_USA_ref -``` - -**postprocessing/compare_casegroup.py** - -Compare_casegroup.py will take any number of ReEDS case paths and create a powerpoint comparing all cases. The only required argument is a comma-delimited list of ReEDS case paths. - -Example: - -``` -$ python postprocessing/compare_casegroup.py /Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_ref,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_lim,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_open,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_transgrp --casenames=Ref,Lim,Open,transgrp -``` - -or similarly: - -``` -$ python postprocessing/compare_casegroup.py /Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_ref,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_lim,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_open,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_transgrp --titleshorten=26 -``` - -Other optional arguments are: - -``` - --casenames CASENAMES, -n CASENAMES - comma-delimited list of shorter case names to use in plots (default: ) - --titleshorten TITLESHORTEN, -s TITLESHORTEN - characters to cut from start of case name (only used if no casenames) (default: 0) - --startyear STARTYEAR, -y STARTYEAR - First year to show (default: 2020) -``` - -### Run Management - -**runstatus.py** - -runstatus.py can be used to print details about runs that are currently running on the HPC. - -Command to run this script: `python runstatus.py [batch prefix]` - -Example: -``` -$ python runstatus.py v20231112 -``` - -Adding the `-f` flag will print the names of the finished runs: `$ python runstatus.py v20231112 -f` - -If you increase the verbosity by adding `-v` flags, it prints a number of lines from the end of that run's gamslog.txt equal to the number of v's in the flag: `$ python runstatus.py v20231112 -vvvvv` - -**restart_runs.py** - -restart_runs.py can be used to restart any failed runs for a given batch. **This only works on HPC currently.** - -Command to run this script: `python restart_runs.py [batch prefix]` - -Example: -``` -$ python restart_runs.py v20231112 -``` - -**interim_report.py** - -interim_report.py can be used to [**todo: fill in additional details**] - -Command to run this script: `python interim_report.py [path to ReEDS run]` - -Example: -``` -$ python interim_report.py /Users/km/ReEDS-2.0/runs/v20231221_USA_ref -``` - -**runs/{case}/meta.csv** - -The meta.csv file is generated for each run. - -Information found in the meta.csv file: - 1. Computer & Github information for the run (computer, repo, branch, commit, description) - 2. Information for each process of the run (year, process, starttime, stoptime, processtime) - - -### Preprocessing - -**preprocessing/casemaker.py** - -**[todo: add additional information]** - -Example: -``` -$ python casemaker.py ... -``` - -**preprocessing/get_case_periods.py** - -**[todo: add additional information]** - -Example: -``` -$ python get_case_periods.py ... -``` - - -### Tool Linkages - -**postprocessing/run_reeds2pras.py** - -run_reeds2pras.py can be used to [**todo: fill in additional details**] - -Example: -``` -$ python postprocessing/run_reeds2pras.py ... -``` - -### Visualization - -**postprocessing/plots.py** - -**[todo: add additional information]** - -Example: -``` -$ python postprocessing/plots.py -``` - -**postprocessing/reedsplots.py** - -**[todo: add additional information]** - -Example: -``` -$ python postprocessing/reedsplots.py -``` - -**postprocessing/transmission_maps.py** - -**[todo: add additional information]** - -Example: -``` -$ python postprocessing/transmission_maps.py -``` - - -## Analysis Modules -### BokehPivot -Bokehpivot can be used for visualizing the outputs of ReEDS runs. For more information on how to use bokehpivot, see the [bokehpivot guide](bokehpivot.md). - -If you're new to BokehPivot, the following YouTube video will be a good starting point: [Viewing ReEDS Outputs Using the BokehPivot Module](https://www.youtube.com/watch?v=8Xi59M4bB6I&list=PLmIn8Hncs7bG558qNlmz2QbKhsv7QCKiC&index=3) - -### reValue -reValue is used for two main things: - * extracting regional hourly prices from ReEDS scenarios and years - * (Optional) using extracted prices to calculate value and competitiveness-related metrics for a set of regional generation or load profiles. - -More more information on reValue, see the [reValue documentation](revalue.md). - -### retail_rate_module -The retail rate module can be used after finishing a ReEDS run to calculate retail electricity rates by state and year, where each state is served by its own investor-owned utility (IOU). - -For more information on this module, see the [retail_rate_module documentation](retail_rate_module.md). - -### Analysis of ReEDS in Tableau -Tableau can be used for the analysis of ReEDS and ReEDS-to-PLEXOS results in Tableau. - -For more information on how to use Tableau with ReEDS, see the [Tableau documentation](tableau.md). \ No newline at end of file diff --git a/docs/build/html/_sources/retail_rate_module.md.txt b/docs/build/html/_sources/retail_rate_module.md.txt deleted file mode 100644 index 35e9c725..00000000 --- a/docs/build/html/_sources/retail_rate_module.md.txt +++ /dev/null @@ -1,9 +0,0 @@ ---- -orphan: true ---- - - -```{include} ../../postprocessing/retail_rate_module/README.md -``` \ No newline at end of file diff --git a/docs/build/html/_sources/revalue.md.txt b/docs/build/html/_sources/revalue.md.txt deleted file mode 100644 index dbfc3479..00000000 --- a/docs/build/html/_sources/revalue.md.txt +++ /dev/null @@ -1,9 +0,0 @@ ---- -orphan: true ---- - - -```{include} ../../postprocessing/reValue/README.md -``` \ No newline at end of file diff --git a/docs/build/html/_sources/setup.md.txt b/docs/build/html/_sources/setup.md.txt deleted file mode 100644 index 2a6601ad..00000000 --- a/docs/build/html/_sources/setup.md.txt +++ /dev/null @@ -1,331 +0,0 @@ -# Getting Started -The ReEDS model source code is available at no cost from the National Renewable Energy Laboratory. The ReEDS model can be downloaded or cloned from [https://github.com/NREL/ReEDS-2.0](https://github.com/NREL/ReEDS-2.0). - -New users may also wish to start with some ReEDS training videos which are available on the NREL YouTube channel at [https://youtu.be/aGj3Jnspk9M?si=iqCRNn5MbGZc8ZIO](https://youtu.be/aGj3Jnspk9M?si=iqCRNn5MbGZc8ZIO). - -## Computer Setup for Microsoft Windows 10 -The setup and execustion of the ReEDS model can be accomplished using a command-line interpreter application and launching a command line interface (referred to as a "terminal window" in this documentation). For example, initiating the Windows Command Prompt application, i.e., cmd.exe, will launch a terminal window {numref}`figure-windows-command-prompt`. (Note: If you have issues using command prompt, try using anaconda prompt or a git bash window) - -```{figure} ../../images/cmd-prompt.png -:name: figure-windows-command-prompt - -Screenshot of a Windows Command Prompt terminal window -``` - -**SUGGESTON:** use a command line emulator such as ConEmu ([https://conemu.github.io/](https://conemu.github.io/)) for a more user-friendly terminal. The screenshots of terminal windows shown in this document are taken using ConEmu. - -**IMPORTANT:** Users should exercise Administrative Privileges when installing software. For example, right click on the installer executable for one of the required software (e.g., Anaconda3-2019.07-Windows-x86\_64.exe) and click on "Run as administrator" ({numref}`figure-run-as-admin`). Alternatively, right click on the executable for the command line interface (e.g., Command Prompt) and click on "Run as administrator" ({numref}`figure-run-as-admin-2`). Then run the required software installer executables from the command line. - -```{figure} ../../images/run-as-admin.png -:name: figure-run-as-admin - -Screenshot of running an installer executable using "Run as administrator" -``` - -```{figure} ../../images/run-as-admin-2.png -:name: figure-run-as-admin-2 - -Screenshot of running "Command Prompt" with "Run as administrator" -``` - -### Python Configuration - -Install Anaconda: [https://www.anaconda.com/download](https://www.anaconda.com/download). - -**IMPORTANT** : Be sure to download the Windows version of the installer. - -Add Python to the "path" environment variable - -1. In the Windows start menu, search for "environment variables" and click "Edit the system environment variables" ({numref}`figure-search-env-var`). This will open the "System Properties" window ({numref}`figure-sys-prop-win`). - -```{figure} ../../images/search-env-var.png -:name: figure-search-env-var - -Screenshot of a search for "environment variables" in the Windows start menu -``` - -```{figure} ../../images/sys-prop-win.png -:name: figure-sys-prop-win - -Screenshot of the "System Properties" window. -``` - - -2. Click the "Environment Variables" button on the bottom right of the window ({numref}`figure-sys-prop-win`). This will open the "Environment Variables" window ({numref}`figure-env-var-wind`). - - -```{figure} ../../images/env-var-win.png -:name: figure-env-var-wind - -Edit the Path environment variable -``` - - -3. Highlight the Path variable and click "Edit" ({numref}`figure-env-var-wind`). This will open the "Edit environment variable" window ({numref}`figure-edit-env-var-win`). - -```{figure} ../../images/edit-env-var-win.png -:name: figure-edit-env-var-win - -Append the Path environment -``` - - -4. Click "New" ({numref}`figure-edit-env-var-win`) and add the directory locations for \Anaconda\ and \Anaconda\Scripts to the environment path. - -**IMPORTANT** : Test the Python installation from the command line by typing "python" (no quotes) in the terminal window. The Python program should initiate ({numref}`figure-python-test`). - -```{figure} ../../images/py-test.png -:name: figure-python-test - -Screenshot of a test of Python in the terminal window -``` - -It is highly recommended to run ReEDS using the conda environment provided in the repository. This environment (named `reeds2`) is specified by the `environment.yml` and can be built with the following command: - -``` -conda env create -f environment.yml -``` - -You can verify that the environment was successfully created using the following (you should see `reeds2` in the list): - -``` -conda env list -``` - -When creating the reeds2 environment locally, you might run into an SSL error that looks like: `CondaSSLError: Encountered an SSL error. Most likely a certificate verification issue.` To resolve this issue, run the following command before creating the environment again: `conda config --set ssl_verify false`. - - -### GAMS Configuration - -Install GAMS: [https://www.gams.com/download/](https://www.gams.com/download/). NREL uses GAMS versions 45.2.0 and 34.3. Older versions might also work. A valid GAMS license must be installed. Please refer to the [Required Software](#Software) section above for more information. - -Add GAMS to the "path" environment variable. Follow the same instructions as for adding Python to the path in the [Python Configuration](#ConfigPy) section above. Append the environment path with the directory location for the _gams.exe_ application (e.g., C:\GAMS\win64\34). - - -**IMPORTANT** : Test the GAMS installation from the command line by typing "gams" (no quotes) in the terminal window. The GAMS program should initiate ({numref}`figure-gams-test`). - -```{figure} ../../images/gams-test.png -:name: figure-gams-test - -Screenshot of a test of GAMS from the terminal window -``` - - -### ReEDS Repository Setup -The ReEDS source code is hosted on GitHub: [https://github.com/NREL/ReEDS-2.0](https://github.com/NREL/ReEDS-2.0) - - -1. Install Git Large File Storage, instructions can be found here: [Installing Git Large File Storage](https://docs.github.com/en/repositories/working-with-files/managing-large-files/installing-git-large-file-storage?platform=windows) - -1. From the Git command line run the following command to enable large file storage. -``` -git lfs install -``` - -1. Clone the ReEDS-2.0 repository on your desktop. Alternatively, download a ZIP from GitHub ({numref}`figure-github-download`). - -```{figure} ../../images/github-download.png -:name: figure-github-download - -Screenshot of GitHub links to clone the ReEDS repository or download ZIP of the ReEDS files -``` - - - -## Computer Setup for MacOS -### Python Configuration -Download the latest **Intel** version of Anaconda: [https://www.anaconda.com/download](https://www.anaconda.com/download) - -**IMPORTANT**: Make sure to download the Intel version even if your machine has an Apple Silicon / ARM processor. - -```{figure} ../../images/anaconda-intel.png -:name: figure-anaconda-intel -``` - -During Installation, select to install Anaconda for your machine only. - -```{figure} ../../images/anaconda-install-mac.png -:name: figure-anaconda-install-mac - -Image of Anaconda Install Mac -``` - -To have the installer automatically add anaconda to PATH, ensure that you've selected the box to "Add conda initialization to the shell" - -```{figure} ../../images/anaconda-custom-install-mac.png -:name: figure-anaconda-custom-insatll-mac - -Image of Anaconda Install Mac - Customize Installation Type -``` - -**To validate Python was installed properly** execute the following command from a new terminal (without quotes): "python" - -Python should initiate, looking similar to {numref}`figure-python-test`. - -It is highly recommended to run ReEDS using the conda environment provided in the repository. This environment (named `reeds2`) is specified by the `environment.yml` and can be built with the following command - make sure you navigate to the ReEDS repository from terminal first: - -``` -conda env create -f environment.yml -``` - -You can verify that the environment was successfully created using the following (you should see `reeds2` in the list): - -``` -conda env list -``` - - -### GAMS Configuration -Install GAMS: [https://www.gams.com/download/](https://www.gams.com/download/). A valid GAMS license must be installed. Please refer to the [Required Software](#Software) section above for more information. - -**IMPORTANT**: When installing on Mac, on the 'Installlation Type' page, click 'customize' and ensure the box to 'Add GAMS to PATH' is checked. - -```{figure} ../../images/gams-install-mac.png -:name: figure-gams-install-mac - -Image of GAMS Install Mac -``` - -**To validate GAMS was installed properly** execute the following command from a new terminal (without quotes): "gams" - -GAMS should initiate, you should see something similar to {numref}`figure-gams-test`. - - - -### ReEDS Repository Setup -The ReEDS source code is hosted on GitHub: [https://github.com/NREL/ReEDS-2.0](https://github.com/NREL/ReEDS-2.0) - -1. Install Git Large File Storage, instructions can be found here: [Installing Git Large File Storage](https://docs.github.com/en/repositories/working-with-files/managing-large-files/installing-git-large-file-storage?platform=mac) - -2. From the Git command line run the following command to enable large file storage. -``` -git lfs install -``` - -3. Clone the ReEDS-2.0 repository on your desktop and use the repository with GitHub Desktop. Alternatively, download a ZIP from GitHub ({numref}`figure-github-download`). - -## ReEDS2PRAS, julia, and stress periods setup -Since ReEDS uses stress periods by default, julia will need to be installed and set up to run the model. To get julia and stress periods set up: -1. Install Julia. There are different procedures for mac/linux and windows. - 1. [mac/linux]: Julia is included in the conda environment so you should be all set. - 2. [windows]: Install Julia from [https://julialang.org/downloads/](https://julialang.org/downloads/). -2. From the ReEDS-2.0 directory, run `julia --project=. instantiate.jl` - -Set `GSw_PRM_CapCredit=0` in your ReEDS cases file to use the coupled ReEDS/PRAS stress periods model, or just set `pras=2` to run PRAS without necessarily using stress periods. - -### Troubleshooting Issues with Julia Setup -When setting up julia on Windows, you may run into some issues when running `julia --project=. instantiate.jl`. The following steps can be followed to help resolve issues and get julia set up sucessfully: -1. Manually install [Random123](https://github.com/JuliaRandom/Random123.jl) - -2. Re-run `julia --project=. instantiate.jl` - - - -If that doesn't resolve the issue, the following may help: -1. If you previously installed julia, uninstall it: `winget uninstall julia` - -2. Manually install [Julia 1.8.5](https://julialang.org/downloads/oldreleases/#:~:text=ea85e0489c36324c4da62163aa1b82fcf2f52f72d173ee7dd213a3a92992cab7-,Windows,-x86_64) - -3. Add the julia bin path to your environment PATH variable - -4. Install [MinGW](https://www.mingw-w64.org/downloads/) - -5. Open the julia interactive command line: `julia` - -6. Enter the julia package manager by pressing `]`, then run the following commands: - * `add Random123` - * `registry add https://github.com/JuliaRegistries/General.git` - * `registry add https://github.com/NREL/JuliaRegistires.git` - * `instantiate` - -7. Leave the package manager by pressing backspace or Ctrl+C - -8. Run the following commands to finish setup: - * `import PRAS` - * `import TimeZones` - * `TimeZones.build()` - -9. You can then leave the julia command line by typing `exit()` - - -**If you're experiencing issues on Mac, a possible solution is:** -1. Update the version of julia - -2. Create the 'reeds2' conda environment with the environment.yml file - -3. Run `julia` from the terminal to open the interactive command line - -4. Run `import Pkg; Pkg.add("PRAS")` - -5. Run `Pkg.add("TimeZones")` - -6. Exit julia with the command `exit()`, then run `julia instantiate.jl` - -7. Manually move the Manifest.toml file from the julia environment (~/miniconda3/envs/reeds2/share/julia/environments/reeds2/Manifest.toml) to the ReEDS repo - - -## Executing the Model -A ReEDS case (also referred to as a "run", "scenario" or "instance") is executed through a python-based case batching program called `runbatch.py` after the repository was setup. The user can execute a single case or a batch of cases using this program. - -### Understanding the cases.csv file -ReEDS model switches are set in the cases.csv file and need to be specified by the user. The default case configuration file is called "cases.csv". - -Within "cases.csv", the data in column A are the model "switches". Column B contains a brief description of each switch. Column C contains the choices available for the given switch (please note, this is not available for all switches). Column D contains the default value for the switch. Finally, the case configuration (or set of switches that define a case) is in column E. - -Within column E, the case name is specified in row 1. The value for each switch is specified beginning in row 2. If a switch value is left blank, the default value from column D is used. - -**Note:** all monetary switches should be entered in 2004 dollars. - -```{figure} ../../images/cases-csv.png -:name: figure-cases-csv - -Screenshot of cases.csv -``` - -There are additional cases_*.csv files that can also be used to run different ReEDS scenarios. The two most commonly used are: - * cases_standardscenarios.csv: contains all the scenarios that were used for Standard Scenarios - * cases_test.csv: contains a group of "test" cases that vary specific settings within the model for testing various capabilities - -The user may also create custom case configuration files by using the suffix in the file name (e.g., "cases_smalltests.csv"). It should follow the same column formatting as cases.csv, but does not need to include all available switches. - -### Calling runbatch.py to run ReEDS -1. Navigate to the ReEDS directory from a new command prompt or terminal. -2. Activate the `reeds2` conda environment: `conda activate reeds2` -3. Call runbatch.py: `python runbatch.py` - * It should look similar to {numref}`figure-exe-runbatch` -4. Provide responses to the suite of prompts in the command line. For more information about the prompts, see the [Prompts for user input during runbatch.py section](#prompts-for-user-input-during-runbatchpy). -5. Once all responses have been received, the batching program will execute the case(s) specified in the case configuration file (e.g., "cases.csv"). - * Please note, if you're running ReEDS on Windows, a separate terminal window will be launched for each case. - -For each case that is run, a new subfolder will be created under the "runs/" subdirectory of ReEDS. If you run the default case found in "cases.csv", you can expect to find the outputs from the run at "/ReEDS-2.0/runs/{batch prefix}_Ref/outputs". - -```{figure} ../../images/exe-runbatch.png -:name: figure-exe-runbatch - -Screenshot of initiating "runbatch.py" from the command line -``` - - -### Prompts for user input during runbatch.py -**Batch Prefix [string]** - Defines the prefix for files and directories that will be created for the batch of cases to be executed (as listed in a case configuration file, e.g., "cases.csv") - * All files and directories related to a case will be named "{batch prefix}_{case}". For example, if *batch prefix = "test"* and *case = "Ref"*, then all files and directories related to this case will be named *test_Ref*. - * **Important:** A batch prefix cannot start with a number given incompatibility with GAMS. - * Entering the value of "0" (zero, no quotes) will assign the current date and time for the batch prefix in the form of *v{YYYMMDD}_{HHMM}*. - * If you re-use a (batch prefix, case) pair, a new prompt will appear asking if you want to overwrite the existing output directories. - -**Case Suffix [string]** - Indicates which case configuration file (in the form "cases_{case suffix}.csv") is ingested into "runbatch.py" for processing. - * Entering an empty value(i.e., pressing "Enter/Return") will cause the default case configuration file "cases.csv" to be used - -**Number of Simultaneous Runs [integer]** - Indicated how many cases should be run simultaneously. - * "runbatch.py" uses a queue to execute multiple cases - * If there are 4 cases and the *Number of Simultaneous Runs = 1*, then "runbatch.py" will execute the cases one at a time - * However, if there are 4 cases and the *Number of Simultaneous Runs = 2*, then "runbatch.py" will start 2 cases simultaneously - * As each case finishes, it will start a new one until all cases have been run - * **WARNING! Be mindful about the amount of CPU and RAM usage needed for each case** - - -### Special Case Setup Requirements - -For non-NREL users, some additional data is required to run the ReEDS model at the 'county' spatial resolution. This is currently considered a special case and some data was required to be kept outside the ReEDS repository because the data is simply too large. The hourly renewable capacity factor data is now available to all at : https://data.openei.org/submissions/5986. - -If you would like to run the model at county resolution, you are requested to download the files available from the link provided, unzip each folder, and place the files obtained into inputs/variability/multi-year in your locally cloned ReEDS repository. The input_processing scripts have also been updated to check for these files for any county-level runs. The 'cases_spatialflex.csv' file provides examples of specific switch settings to run ReEDS at county-level. \ No newline at end of file diff --git a/docs/build/html/_sources/sources.md.txt b/docs/build/html/_sources/sources.md.txt deleted file mode 100644 index 49f33c06..00000000 --- a/docs/build/html/_sources/sources.md.txt +++ /dev/null @@ -1,7 +0,0 @@ -## Sources and Data - -```{eval-rst} -.. include:: ../../sources_documentation.md - :parser: myst_parser.sphinx_ -``` - \ No newline at end of file diff --git a/docs/build/html/_sources/tableau.md.txt b/docs/build/html/_sources/tableau.md.txt deleted file mode 100644 index d11acf2e..00000000 --- a/docs/build/html/_sources/tableau.md.txt +++ /dev/null @@ -1,9 +0,0 @@ ---- -orphan: true ---- - - -```{include} ../../postprocessing/tableau/README.md -``` \ No newline at end of file diff --git a/docs/build/html/_static/_sphinx_javascript_frameworks_compat.js b/docs/build/html/_static/_sphinx_javascript_frameworks_compat.js deleted file mode 100644 index 81415803..00000000 --- a/docs/build/html/_static/_sphinx_javascript_frameworks_compat.js +++ /dev/null @@ -1,123 +0,0 @@ -/* Compatability shim for jQuery and underscores.js. - * - * Copyright Sphinx contributors - * Released under the two clause BSD licence - */ - -/** - * small helper function to urldecode strings - * - * See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/decodeURIComponent#Decoding_query_parameters_from_a_URL - */ -jQuery.urldecode = function(x) { - if (!x) { - return x - } - return decodeURIComponent(x.replace(/\+/g, ' ')); -}; - -/** - * small helper function to urlencode strings - */ -jQuery.urlencode = encodeURIComponent; - -/** - * This function returns the parsed url parameters of the - * current request. Multiple values per key are supported, - * it will always return arrays of strings for the value parts. - */ -jQuery.getQueryParameters = function(s) { - if (typeof s === 'undefined') - s = document.location.search; - var parts = s.substr(s.indexOf('?') + 1).split('&'); - var result = {}; - for (var i = 0; i < parts.length; i++) { - var tmp = parts[i].split('=', 2); - var key = jQuery.urldecode(tmp[0]); - var value = jQuery.urldecode(tmp[1]); - if (key in result) - result[key].push(value); - else - result[key] = [value]; - } - return result; -}; - -/** - * highlight a given string on a jquery object by wrapping it in - * span elements with the given class name. - */ -jQuery.fn.highlightText = function(text, className) { - function highlight(node, addItems) { - if (node.nodeType === 3) { - var val = node.nodeValue; - var pos = val.toLowerCase().indexOf(text); - if (pos >= 0 && - !jQuery(node.parentNode).hasClass(className) && - !jQuery(node.parentNode).hasClass("nohighlight")) { - var span; - var isInSVG = jQuery(node).closest("body, svg, foreignObject").is("svg"); - if (isInSVG) { - span = document.createElementNS("http://www.w3.org/2000/svg", "tspan"); - } else { - span = document.createElement("span"); - span.className = className; - } - span.appendChild(document.createTextNode(val.substr(pos, text.length))); - node.parentNode.insertBefore(span, node.parentNode.insertBefore( - document.createTextNode(val.substr(pos + text.length)), - node.nextSibling)); - node.nodeValue = val.substr(0, pos); - if (isInSVG) { - var rect = document.createElementNS("http://www.w3.org/2000/svg", "rect"); - var bbox = node.parentElement.getBBox(); - rect.x.baseVal.value = bbox.x; - rect.y.baseVal.value = bbox.y; - rect.width.baseVal.value = bbox.width; - rect.height.baseVal.value = bbox.height; - rect.setAttribute('class', className); - addItems.push({ - "parent": node.parentNode, - "target": rect}); - } - } - } - else if (!jQuery(node).is("button, select, textarea")) { - jQuery.each(node.childNodes, function() { - highlight(this, addItems); - }); - } - } - var addItems = []; - var result = this.each(function() { - highlight(this, addItems); - }); - for (var i = 0; i < addItems.length; ++i) { - jQuery(addItems[i].parent).before(addItems[i].target); - } - return result; -}; - -/* - * backward compatibility for jQuery.browser - * This will be supported until firefox bug is fixed. - */ -if (!jQuery.browser) { - jQuery.uaMatch = function(ua) { - ua = ua.toLowerCase(); - - var match = /(chrome)[ \/]([\w.]+)/.exec(ua) || - /(webkit)[ \/]([\w.]+)/.exec(ua) || - /(opera)(?:.*version|)[ \/]([\w.]+)/.exec(ua) || - /(msie) ([\w.]+)/.exec(ua) || - ua.indexOf("compatible") < 0 && /(mozilla)(?:.*? rv:([\w.]+)|)/.exec(ua) || - []; - - return { - browser: match[ 1 ] || "", - version: match[ 2 ] || "0" - }; - }; - jQuery.browser = {}; - jQuery.browser[jQuery.uaMatch(navigator.userAgent).browser] = true; -} diff --git a/docs/build/html/_static/basic.css b/docs/build/html/_static/basic.css deleted file mode 100644 index f316efcb..00000000 --- a/docs/build/html/_static/basic.css +++ /dev/null @@ -1,925 +0,0 @@ -/* - * basic.css - * ~~~~~~~~~ - * - * Sphinx stylesheet -- basic theme. - * - * :copyright: Copyright 2007-2024 by the Sphinx team, see AUTHORS. - * :license: BSD, see LICENSE for details. - * - */ - -/* -- main layout ----------------------------------------------------------- */ - -div.clearer { - clear: both; -} - -div.section::after { - display: block; - content: ''; - clear: left; -} - -/* -- relbar ---------------------------------------------------------------- */ - -div.related { - width: 100%; - font-size: 90%; -} - -div.related h3 { - display: none; -} - -div.related ul { - margin: 0; - padding: 0 0 0 10px; - list-style: none; -} - -div.related li { - display: inline; -} - -div.related li.right { - float: right; - margin-right: 5px; -} - -/* -- sidebar --------------------------------------------------------------- */ - -div.sphinxsidebarwrapper { - padding: 10px 5px 0 10px; -} - -div.sphinxsidebar { - float: left; - width: 230px; - margin-left: -100%; - font-size: 90%; - word-wrap: break-word; - overflow-wrap : break-word; -} - -div.sphinxsidebar ul { - list-style: none; -} - -div.sphinxsidebar ul ul, -div.sphinxsidebar ul.want-points { - margin-left: 20px; - list-style: square; -} - -div.sphinxsidebar ul ul { - margin-top: 0; - margin-bottom: 0; -} - -div.sphinxsidebar form { - margin-top: 10px; -} - -div.sphinxsidebar input { - border: 1px solid #98dbcc; - font-family: sans-serif; - font-size: 1em; -} - -div.sphinxsidebar #searchbox form.search { - overflow: hidden; -} - -div.sphinxsidebar #searchbox input[type="text"] { - float: left; - width: 80%; - padding: 0.25em; - box-sizing: border-box; -} - -div.sphinxsidebar #searchbox input[type="submit"] { - float: left; - width: 20%; - border-left: none; - padding: 0.25em; - box-sizing: border-box; -} - - -img { - border: 0; - max-width: 100%; -} - -/* -- search page ----------------------------------------------------------- */ - -ul.search { - margin: 10px 0 0 20px; - padding: 0; -} - -ul.search li { - padding: 5px 0 5px 20px; - background-image: url(file.png); - background-repeat: no-repeat; - background-position: 0 7px; -} - -ul.search li a { - font-weight: bold; -} - -ul.search li p.context { - color: #888; - margin: 2px 0 0 30px; - text-align: left; -} - -ul.keywordmatches li.goodmatch a { - font-weight: bold; -} - -/* -- index page ------------------------------------------------------------ */ - -table.contentstable { - width: 90%; - margin-left: auto; - margin-right: auto; -} - -table.contentstable p.biglink { - line-height: 150%; -} - -a.biglink { - font-size: 1.3em; -} - -span.linkdescr { - font-style: italic; - padding-top: 5px; - font-size: 90%; -} - -/* -- general index --------------------------------------------------------- */ - -table.indextable { - width: 100%; -} - -table.indextable td { - text-align: left; - vertical-align: top; -} - -table.indextable ul { - margin-top: 0; - margin-bottom: 0; - list-style-type: none; -} - -table.indextable > tbody > tr > td > ul { - padding-left: 0em; -} - -table.indextable tr.pcap { - height: 10px; -} - -table.indextable tr.cap { - margin-top: 10px; - background-color: #f2f2f2; -} - -img.toggler { - margin-right: 3px; - margin-top: 3px; - cursor: pointer; -} - -div.modindex-jumpbox { - border-top: 1px solid #ddd; - border-bottom: 1px solid #ddd; - margin: 1em 0 1em 0; - padding: 0.4em; -} - -div.genindex-jumpbox { - border-top: 1px solid #ddd; - border-bottom: 1px solid #ddd; - margin: 1em 0 1em 0; - padding: 0.4em; -} - -/* -- domain module index --------------------------------------------------- */ - -table.modindextable td { - padding: 2px; - border-collapse: collapse; -} - -/* -- general body styles --------------------------------------------------- */ - -div.body { - min-width: 360px; - max-width: 800px; -} - -div.body p, div.body dd, div.body li, div.body blockquote { - -moz-hyphens: auto; - -ms-hyphens: auto; - -webkit-hyphens: auto; - hyphens: auto; -} - -a.headerlink { - visibility: hidden; -} - -a:visited { - color: #551A8B; -} - -h1:hover > a.headerlink, -h2:hover > a.headerlink, -h3:hover > a.headerlink, -h4:hover > a.headerlink, -h5:hover > a.headerlink, -h6:hover > a.headerlink, -dt:hover > a.headerlink, -caption:hover > a.headerlink, -p.caption:hover > a.headerlink, -div.code-block-caption:hover > a.headerlink { - visibility: visible; -} - -div.body p.caption { - text-align: inherit; -} - -div.body td { - text-align: left; -} - -.first { - margin-top: 0 !important; -} - -p.rubric { - margin-top: 30px; - font-weight: bold; -} - -img.align-left, figure.align-left, .figure.align-left, object.align-left { - clear: left; - float: left; - margin-right: 1em; -} - -img.align-right, figure.align-right, .figure.align-right, object.align-right { - clear: right; - float: right; - margin-left: 1em; -} - -img.align-center, figure.align-center, .figure.align-center, object.align-center { - display: block; - margin-left: auto; - margin-right: auto; -} - -img.align-default, figure.align-default, .figure.align-default { - display: block; - margin-left: auto; - margin-right: auto; -} - -.align-left { - text-align: left; -} - -.align-center { - text-align: center; -} - -.align-default { - text-align: center; -} - -.align-right { - text-align: right; -} - -/* -- sidebars -------------------------------------------------------------- */ - -div.sidebar, -aside.sidebar { - margin: 0 0 0.5em 1em; - border: 1px solid #ddb; - padding: 7px; - background-color: #ffe; - width: 40%; - float: right; - clear: right; - overflow-x: auto; -} - -p.sidebar-title { - font-weight: bold; -} - -nav.contents, -aside.topic, -div.admonition, div.topic, blockquote { - clear: left; -} - -/* -- topics ---------------------------------------------------------------- */ - -nav.contents, -aside.topic, -div.topic { - border: 1px solid #ccc; - padding: 7px; - margin: 10px 0 10px 0; -} - -p.topic-title { - font-size: 1.1em; - font-weight: bold; - margin-top: 10px; -} - -/* -- admonitions ----------------------------------------------------------- */ - -div.admonition { - margin-top: 10px; - margin-bottom: 10px; - padding: 7px; -} - -div.admonition dt { - font-weight: bold; -} - -p.admonition-title { - margin: 0px 10px 5px 0px; - font-weight: bold; -} - -div.body p.centered { - text-align: center; - margin-top: 25px; -} - -/* -- content of sidebars/topics/admonitions -------------------------------- */ - -div.sidebar > :last-child, -aside.sidebar > :last-child, -nav.contents > :last-child, -aside.topic > :last-child, -div.topic > :last-child, -div.admonition > :last-child { - margin-bottom: 0; -} - -div.sidebar::after, -aside.sidebar::after, -nav.contents::after, -aside.topic::after, -div.topic::after, -div.admonition::after, -blockquote::after { - display: block; - content: ''; - clear: both; -} - -/* -- tables ---------------------------------------------------------------- */ - -table.docutils { - margin-top: 10px; - margin-bottom: 10px; - border: 0; - border-collapse: collapse; -} - -table.align-center { - margin-left: auto; - margin-right: auto; -} - -table.align-default { - margin-left: auto; - margin-right: auto; -} - -table caption span.caption-number { - font-style: italic; -} - -table caption span.caption-text { -} - -table.docutils td, table.docutils th { - padding: 1px 8px 1px 5px; - border-top: 0; - border-left: 0; - border-right: 0; - border-bottom: 1px solid #aaa; -} - -th { - text-align: left; - padding-right: 5px; -} - -table.citation { - border-left: solid 1px gray; - margin-left: 1px; -} - -table.citation td { - border-bottom: none; -} - -th > :first-child, -td > :first-child { - margin-top: 0px; -} - -th > :last-child, -td > :last-child { - margin-bottom: 0px; -} - -/* -- figures --------------------------------------------------------------- */ - -div.figure, figure { - margin: 0.5em; - padding: 0.5em; -} - -div.figure p.caption, figcaption { - padding: 0.3em; -} - -div.figure p.caption span.caption-number, -figcaption span.caption-number { - font-style: italic; -} - -div.figure p.caption span.caption-text, -figcaption span.caption-text { -} - -/* -- field list styles ----------------------------------------------------- */ - -table.field-list td, table.field-list th { - border: 0 !important; -} - -.field-list ul { - margin: 0; - padding-left: 1em; -} - -.field-list p { - margin: 0; -} - -.field-name { - -moz-hyphens: manual; - -ms-hyphens: manual; - -webkit-hyphens: manual; - hyphens: manual; -} - -/* -- hlist styles ---------------------------------------------------------- */ - -table.hlist { - margin: 1em 0; -} - -table.hlist td { - vertical-align: top; -} - -/* -- object description styles --------------------------------------------- */ - -.sig { - font-family: 'Consolas', 'Menlo', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', monospace; -} - -.sig-name, code.descname { - background-color: transparent; - font-weight: bold; -} - -.sig-name { - font-size: 1.1em; -} - -code.descname { - font-size: 1.2em; -} - -.sig-prename, code.descclassname { - background-color: transparent; -} - -.optional { - font-size: 1.3em; -} - -.sig-paren { - font-size: larger; -} - -.sig-param.n { - font-style: italic; -} - -/* C++ specific styling */ - -.sig-inline.c-texpr, -.sig-inline.cpp-texpr { - font-family: unset; -} - -.sig.c .k, .sig.c .kt, -.sig.cpp .k, .sig.cpp .kt { - color: #0033B3; -} - -.sig.c .m, -.sig.cpp .m { - color: #1750EB; -} - -.sig.c .s, .sig.c .sc, -.sig.cpp .s, .sig.cpp .sc { - color: #067D17; -} - - -/* -- other body styles ----------------------------------------------------- */ - -ol.arabic { - list-style: decimal; -} - -ol.loweralpha { - list-style: lower-alpha; -} - -ol.upperalpha { - list-style: upper-alpha; -} - -ol.lowerroman { - list-style: lower-roman; -} - -ol.upperroman { - list-style: upper-roman; -} - -:not(li) > ol > li:first-child > :first-child, -:not(li) > ul > li:first-child > :first-child { - margin-top: 0px; -} - -:not(li) > ol > li:last-child > :last-child, -:not(li) > ul > li:last-child > :last-child { - margin-bottom: 0px; -} - -ol.simple ol p, -ol.simple ul p, -ul.simple ol p, -ul.simple ul p { - margin-top: 0; -} - -ol.simple > li:not(:first-child) > p, -ul.simple > li:not(:first-child) > p { - margin-top: 0; -} - -ol.simple p, -ul.simple p { - margin-bottom: 0; -} - -aside.footnote > span, -div.citation > span { - float: left; -} -aside.footnote > span:last-of-type, -div.citation > span:last-of-type { - padding-right: 0.5em; -} -aside.footnote > p { - margin-left: 2em; -} -div.citation > p { - margin-left: 4em; -} -aside.footnote > p:last-of-type, -div.citation > p:last-of-type { - margin-bottom: 0em; -} -aside.footnote > p:last-of-type:after, -div.citation > p:last-of-type:after { - content: ""; - clear: both; -} - -dl.field-list { - display: grid; - grid-template-columns: fit-content(30%) auto; -} - -dl.field-list > dt { - font-weight: bold; - word-break: break-word; - padding-left: 0.5em; - padding-right: 5px; -} - -dl.field-list > dd { - padding-left: 0.5em; - margin-top: 0em; - margin-left: 0em; - margin-bottom: 0em; -} - -dl { - margin-bottom: 15px; -} - -dd > :first-child { - margin-top: 0px; -} - -dd ul, dd table { - margin-bottom: 10px; -} - -dd { - margin-top: 3px; - margin-bottom: 10px; - margin-left: 30px; -} - -.sig dd { - margin-top: 0px; - margin-bottom: 0px; -} - -.sig dl { - margin-top: 0px; - margin-bottom: 0px; -} - -dl > dd:last-child, -dl > dd:last-child > :last-child { - margin-bottom: 0; -} - -dt:target, span.highlighted { - background-color: #fbe54e; -} - -rect.highlighted { - fill: #fbe54e; -} - -dl.glossary dt { - font-weight: bold; - font-size: 1.1em; -} - -.versionmodified { - font-style: italic; -} - -.system-message { - background-color: #fda; - padding: 5px; - border: 3px solid red; -} - -.footnote:target { - background-color: #ffa; -} - -.line-block { - display: block; - margin-top: 1em; - margin-bottom: 1em; -} - -.line-block .line-block { - margin-top: 0; - margin-bottom: 0; - margin-left: 1.5em; -} - -.guilabel, .menuselection { - font-family: sans-serif; -} - -.accelerator { - text-decoration: underline; -} - -.classifier { - font-style: oblique; -} - -.classifier:before { - font-style: normal; - margin: 0 0.5em; - content: ":"; - display: inline-block; -} - -abbr, acronym { - border-bottom: dotted 1px; - cursor: help; -} - -.translated { - background-color: rgba(207, 255, 207, 0.2) -} - -.untranslated { - background-color: rgba(255, 207, 207, 0.2) -} - -/* -- code displays --------------------------------------------------------- */ - -pre { - overflow: auto; - overflow-y: hidden; /* fixes display issues on Chrome browsers */ -} - -pre, div[class*="highlight-"] { - clear: both; -} - -span.pre { - -moz-hyphens: none; - -ms-hyphens: none; - -webkit-hyphens: none; - hyphens: none; - white-space: nowrap; -} - -div[class*="highlight-"] { - margin: 1em 0; -} - -td.linenos pre { - border: 0; - background-color: transparent; - color: #aaa; -} - -table.highlighttable { - display: block; -} - -table.highlighttable tbody { - display: block; -} - -table.highlighttable tr { - display: flex; -} - -table.highlighttable td { - margin: 0; - padding: 0; -} - -table.highlighttable td.linenos { - padding-right: 0.5em; -} - -table.highlighttable td.code { - flex: 1; - overflow: hidden; -} - -.highlight .hll { - display: block; -} - -div.highlight pre, -table.highlighttable pre { - margin: 0; -} - -div.code-block-caption + div { - margin-top: 0; -} - -div.code-block-caption { - margin-top: 1em; - padding: 2px 5px; - font-size: small; -} - -div.code-block-caption code { - background-color: transparent; -} - -table.highlighttable td.linenos, -span.linenos, -div.highlight span.gp { /* gp: Generic.Prompt */ - user-select: none; - -webkit-user-select: text; /* Safari fallback only */ - -webkit-user-select: none; /* Chrome/Safari */ - -moz-user-select: none; /* Firefox */ - -ms-user-select: none; /* IE10+ */ -} - -div.code-block-caption span.caption-number { - padding: 0.1em 0.3em; - font-style: italic; -} - -div.code-block-caption span.caption-text { -} - -div.literal-block-wrapper { - margin: 1em 0; -} - -code.xref, a code { - background-color: transparent; - font-weight: bold; -} - -h1 code, h2 code, h3 code, h4 code, h5 code, h6 code { - background-color: transparent; -} - -.viewcode-link { - float: right; -} - -.viewcode-back { - float: right; - font-family: sans-serif; -} - -div.viewcode-block:target { - margin: -1px -10px; - padding: 0 10px; -} - -/* -- math display ---------------------------------------------------------- */ - -img.math { - vertical-align: middle; -} - -div.body div.math p { - text-align: center; -} - -span.eqno { - float: right; -} - -span.eqno a.headerlink { - position: absolute; - z-index: 1; -} - -div.math:hover a.headerlink { - visibility: visible; -} - -/* -- printout stylesheet --------------------------------------------------- */ - -@media print { - div.document, - div.documentwrapper, - div.bodywrapper { - margin: 0 !important; - width: 100%; - } - - div.sphinxsidebar, - div.related, - div.footer, - #top-link { - display: none; - } -} \ No newline at end of file diff --git a/docs/build/html/_static/css/badge_only.css b/docs/build/html/_static/css/badge_only.css deleted file mode 100644 index c718cee4..00000000 --- a/docs/build/html/_static/css/badge_only.css +++ /dev/null @@ -1 +0,0 @@ -.clearfix{*zoom:1}.clearfix:after,.clearfix:before{display:table;content:""}.clearfix:after{clear:both}@font-face{font-family:FontAwesome;font-style:normal;font-weight:400;src:url(fonts/fontawesome-webfont.eot?674f50d287a8c48dc19ba404d20fe713?#iefix) format("embedded-opentype"),url(fonts/fontawesome-webfont.woff2?af7ae505a9eed503f8b8e6982036873e) format("woff2"),url(fonts/fontawesome-webfont.woff?fee66e712a8a08eef5805a46892932ad) format("woff"),url(fonts/fontawesome-webfont.ttf?b06871f281fee6b241d60582ae9369b9) format("truetype"),url(fonts/fontawesome-webfont.svg?912ec66d7572ff821749319396470bde#FontAwesome) format("svg")}.fa:before{font-family:FontAwesome;font-style:normal;font-weight:400;line-height:1}.fa:before,a .fa{text-decoration:inherit}.fa:before,a .fa,li .fa{display:inline-block}li .fa-large:before{width:1.875em}ul.fas{list-style-type:none;margin-left:2em;text-indent:-.8em}ul.fas li .fa{width:.8em}ul.fas li .fa-large:before{vertical-align:baseline}.fa-book:before,.icon-book:before{content:"\f02d"}.fa-caret-down:before,.icon-caret-down:before{content:"\f0d7"}.fa-caret-up:before,.icon-caret-up:before{content:"\f0d8"}.fa-caret-left:before,.icon-caret-left:before{content:"\f0d9"}.fa-caret-right:before,.icon-caret-right:before{content:"\f0da"}.rst-versions{position:fixed;bottom:0;left:0;width:300px;color:#fcfcfc;background:#1f1d1d;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;z-index:400}.rst-versions a{color:#2980b9;text-decoration:none}.rst-versions .rst-badge-small{display:none}.rst-versions .rst-current-version{padding:12px;background-color:#272525;display:block;text-align:right;font-size:90%;cursor:pointer;color:#27ae60}.rst-versions .rst-current-version:after{clear:both;content:"";display:block}.rst-versions .rst-current-version .fa{color:#fcfcfc}.rst-versions .rst-current-version .fa-book,.rst-versions .rst-current-version .icon-book{float:left}.rst-versions .rst-current-version.rst-out-of-date{background-color:#e74c3c;color:#fff}.rst-versions .rst-current-version.rst-active-old-version{background-color:#f1c40f;color:#000}.rst-versions.shift-up{height:auto;max-height:100%;overflow-y:scroll}.rst-versions.shift-up .rst-other-versions{display:block}.rst-versions .rst-other-versions{font-size:90%;padding:12px;color:grey;display:none}.rst-versions .rst-other-versions hr{display:block;height:1px;border:0;margin:20px 0;padding:0;border-top:1px solid #413d3d}.rst-versions .rst-other-versions dd{display:inline-block;margin:0}.rst-versions .rst-other-versions dd a{display:inline-block;padding:6px;color:#fcfcfc}.rst-versions.rst-badge{width:auto;bottom:20px;right:20px;left:auto;border:none;max-width:300px;max-height:90%}.rst-versions.rst-badge .fa-book,.rst-versions.rst-badge .icon-book{float:none;line-height:30px}.rst-versions.rst-badge.shift-up .rst-current-version{text-align:right}.rst-versions.rst-badge.shift-up .rst-current-version .fa-book,.rst-versions.rst-badge.shift-up .rst-current-version .icon-book{float:left}.rst-versions.rst-badge>.rst-current-version{width:auto;height:30px;line-height:30px;padding:0 6px;display:block;text-align:center}@media screen and (max-width:768px){.rst-versions{width:85%;display:none}.rst-versions.shift{display:block}} \ No newline at end of file diff --git a/docs/build/html/_static/css/fonts/Roboto-Slab-Bold.woff b/docs/build/html/_static/css/fonts/Roboto-Slab-Bold.woff deleted file mode 100644 index 6cb60000..00000000 Binary files a/docs/build/html/_static/css/fonts/Roboto-Slab-Bold.woff and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/Roboto-Slab-Bold.woff2 b/docs/build/html/_static/css/fonts/Roboto-Slab-Bold.woff2 deleted file mode 100644 index 7059e231..00000000 Binary files a/docs/build/html/_static/css/fonts/Roboto-Slab-Bold.woff2 and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/Roboto-Slab-Regular.woff b/docs/build/html/_static/css/fonts/Roboto-Slab-Regular.woff deleted file mode 100644 index f815f63f..00000000 Binary files a/docs/build/html/_static/css/fonts/Roboto-Slab-Regular.woff and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/Roboto-Slab-Regular.woff2 b/docs/build/html/_static/css/fonts/Roboto-Slab-Regular.woff2 deleted file mode 100644 index f2c76e5b..00000000 Binary files a/docs/build/html/_static/css/fonts/Roboto-Slab-Regular.woff2 and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/fontawesome-webfont.eot b/docs/build/html/_static/css/fonts/fontawesome-webfont.eot deleted file mode 100644 index e9f60ca9..00000000 Binary files a/docs/build/html/_static/css/fonts/fontawesome-webfont.eot and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/fontawesome-webfont.svg b/docs/build/html/_static/css/fonts/fontawesome-webfont.svg deleted file mode 100644 index 855c845e..00000000 --- a/docs/build/html/_static/css/fonts/fontawesome-webfont.svg +++ /dev/null @@ -1,2671 +0,0 @@ - - - - -Created by FontForge 20120731 at Mon Oct 24 17:37:40 2016 - By ,,, -Copyright Dave Gandy 2016. All rights reserved. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/build/html/_static/css/fonts/fontawesome-webfont.ttf b/docs/build/html/_static/css/fonts/fontawesome-webfont.ttf deleted file mode 100644 index 35acda2f..00000000 Binary files a/docs/build/html/_static/css/fonts/fontawesome-webfont.ttf and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/fontawesome-webfont.woff b/docs/build/html/_static/css/fonts/fontawesome-webfont.woff deleted file mode 100644 index 400014a4..00000000 Binary files a/docs/build/html/_static/css/fonts/fontawesome-webfont.woff and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/fontawesome-webfont.woff2 b/docs/build/html/_static/css/fonts/fontawesome-webfont.woff2 deleted file mode 100644 index 4d13fc60..00000000 Binary files a/docs/build/html/_static/css/fonts/fontawesome-webfont.woff2 and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/lato-bold-italic.woff b/docs/build/html/_static/css/fonts/lato-bold-italic.woff deleted file mode 100644 index 88ad05b9..00000000 Binary files a/docs/build/html/_static/css/fonts/lato-bold-italic.woff and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/lato-bold-italic.woff2 b/docs/build/html/_static/css/fonts/lato-bold-italic.woff2 deleted file mode 100644 index c4e3d804..00000000 Binary files a/docs/build/html/_static/css/fonts/lato-bold-italic.woff2 and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/lato-bold.woff b/docs/build/html/_static/css/fonts/lato-bold.woff deleted file mode 100644 index c6dff51f..00000000 Binary files a/docs/build/html/_static/css/fonts/lato-bold.woff and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/lato-bold.woff2 b/docs/build/html/_static/css/fonts/lato-bold.woff2 deleted file mode 100644 index bb195043..00000000 Binary files a/docs/build/html/_static/css/fonts/lato-bold.woff2 and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/lato-normal-italic.woff b/docs/build/html/_static/css/fonts/lato-normal-italic.woff deleted file mode 100644 index 76114bc0..00000000 Binary files a/docs/build/html/_static/css/fonts/lato-normal-italic.woff and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/lato-normal-italic.woff2 b/docs/build/html/_static/css/fonts/lato-normal-italic.woff2 deleted file mode 100644 index 3404f37e..00000000 Binary files a/docs/build/html/_static/css/fonts/lato-normal-italic.woff2 and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/lato-normal.woff b/docs/build/html/_static/css/fonts/lato-normal.woff deleted file mode 100644 index ae1307ff..00000000 Binary files a/docs/build/html/_static/css/fonts/lato-normal.woff and /dev/null differ diff --git a/docs/build/html/_static/css/fonts/lato-normal.woff2 b/docs/build/html/_static/css/fonts/lato-normal.woff2 deleted file mode 100644 index 3bf98433..00000000 Binary files a/docs/build/html/_static/css/fonts/lato-normal.woff2 and /dev/null differ diff --git a/docs/build/html/_static/css/theme.css b/docs/build/html/_static/css/theme.css deleted file mode 100644 index 19a446a0..00000000 --- a/docs/build/html/_static/css/theme.css +++ /dev/null @@ -1,4 +0,0 @@ -html{box-sizing:border-box}*,:after,:before{box-sizing:inherit}article,aside,details,figcaption,figure,footer,header,hgroup,nav,section{display:block}audio,canvas,video{display:inline-block;*display:inline;*zoom:1}[hidden],audio:not([controls]){display:none}*{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}html{font-size:100%;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%}body{margin:0}a:active,a:hover{outline:0}abbr[title]{border-bottom:1px dotted}b,strong{font-weight:700}blockquote{margin:0}dfn{font-style:italic}ins{background:#ff9;text-decoration:none}ins,mark{color:#000}mark{background:#ff0;font-style:italic;font-weight:700}.rst-content code,.rst-content tt,code,kbd,pre,samp{font-family:monospace,serif;_font-family:courier new,monospace;font-size:1em}pre{white-space:pre}q{quotes:none}q:after,q:before{content:"";content:none}small{font-size:85%}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}sup{top:-.5em}sub{bottom:-.25em}dl,ol,ul{margin:0;padding:0;list-style:none;list-style-image:none}li{list-style:none}dd{margin:0}img{border:0;-ms-interpolation-mode:bicubic;vertical-align:middle;max-width:100%}svg:not(:root){overflow:hidden}figure,form{margin:0}label{cursor:pointer}button,input,select,textarea{font-size:100%;margin:0;vertical-align:baseline;*vertical-align:middle}button,input{line-height:normal}button,input[type=button],input[type=reset],input[type=submit]{cursor:pointer;-webkit-appearance:button;*overflow:visible}button[disabled],input[disabled]{cursor:default}input[type=search]{-webkit-appearance:textfield;-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box}textarea{resize:vertical}table{border-collapse:collapse;border-spacing:0}td{vertical-align:top}.chromeframe{margin:.2em 0;background:#ccc;color:#000;padding:.2em 0}.ir{display:block;border:0;text-indent:-999em;overflow:hidden;background-color:transparent;background-repeat:no-repeat;text-align:left;direction:ltr;*line-height:0}.ir br{display:none}.hidden{display:none!important;visibility:hidden}.visuallyhidden{border:0;clip:rect(0 0 0 0);height:1px;margin:-1px;overflow:hidden;padding:0;position:absolute;width:1px}.visuallyhidden.focusable:active,.visuallyhidden.focusable:focus{clip:auto;height:auto;margin:0;overflow:visible;position:static;width:auto}.invisible{visibility:hidden}.relative{position:relative}big,small{font-size:100%}@media print{body,html,section{background:none!important}*{box-shadow:none!important;text-shadow:none!important;filter:none!important;-ms-filter:none!important}a,a:visited{text-decoration:underline}.ir a:after,a[href^="#"]:after,a[href^="javascript:"]:after{content:""}blockquote,pre{page-break-inside:avoid}thead{display:table-header-group}img,tr{page-break-inside:avoid}img{max-width:100%!important}@page{margin:.5cm}.rst-content .toctree-wrapper>p.caption,h2,h3,p{orphans:3;widows:3}.rst-content .toctree-wrapper>p.caption,h2,h3{page-break-after:avoid}}.btn,.fa:before,.icon:before,.rst-content .admonition,.rst-content .admonition-title:before,.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .code-block-caption .headerlink:before,.rst-content .danger,.rst-content .eqno .headerlink:before,.rst-content .error,.rst-content .hint,.rst-content .important,.rst-content .note,.rst-content .seealso,.rst-content .tip,.rst-content .warning,.rst-content code.download span:first-child:before,.rst-content dl dt .headerlink:before,.rst-content h1 .headerlink:before,.rst-content h2 .headerlink:before,.rst-content h3 .headerlink:before,.rst-content h4 .headerlink:before,.rst-content h5 .headerlink:before,.rst-content h6 .headerlink:before,.rst-content p.caption .headerlink:before,.rst-content p .headerlink:before,.rst-content table>caption .headerlink:before,.rst-content tt.download span:first-child:before,.wy-alert,.wy-dropdown .caret:before,.wy-inline-validate.wy-inline-validate-danger .wy-input-context:before,.wy-inline-validate.wy-inline-validate-info .wy-input-context:before,.wy-inline-validate.wy-inline-validate-success .wy-input-context:before,.wy-inline-validate.wy-inline-validate-warning .wy-input-context:before,.wy-menu-vertical li.current>a button.toctree-expand:before,.wy-menu-vertical li.on a button.toctree-expand:before,.wy-menu-vertical li button.toctree-expand:before,input[type=color],input[type=date],input[type=datetime-local],input[type=datetime],input[type=email],input[type=month],input[type=number],input[type=password],input[type=search],input[type=tel],input[type=text],input[type=time],input[type=url],input[type=week],select,textarea{-webkit-font-smoothing:antialiased}.clearfix{*zoom:1}.clearfix:after,.clearfix:before{display:table;content:""}.clearfix:after{clear:both}/*! - * Font Awesome 4.7.0 by @davegandy - http://fontawesome.io - @fontawesome - * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License) - */@font-face{font-family:FontAwesome;src:url(fonts/fontawesome-webfont.eot?674f50d287a8c48dc19ba404d20fe713);src:url(fonts/fontawesome-webfont.eot?674f50d287a8c48dc19ba404d20fe713?#iefix&v=4.7.0) format("embedded-opentype"),url(fonts/fontawesome-webfont.woff2?af7ae505a9eed503f8b8e6982036873e) format("woff2"),url(fonts/fontawesome-webfont.woff?fee66e712a8a08eef5805a46892932ad) format("woff"),url(fonts/fontawesome-webfont.ttf?b06871f281fee6b241d60582ae9369b9) format("truetype"),url(fonts/fontawesome-webfont.svg?912ec66d7572ff821749319396470bde#fontawesomeregular) format("svg");font-weight:400;font-style:normal}.fa,.icon,.rst-content .admonition-title,.rst-content .code-block-caption .headerlink,.rst-content .eqno .headerlink,.rst-content code.download span:first-child,.rst-content dl dt .headerlink,.rst-content h1 .headerlink,.rst-content h2 .headerlink,.rst-content h3 .headerlink,.rst-content h4 .headerlink,.rst-content h5 .headerlink,.rst-content h6 .headerlink,.rst-content p.caption .headerlink,.rst-content p .headerlink,.rst-content table>caption .headerlink,.rst-content tt.download span:first-child,.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand,.wy-menu-vertical li button.toctree-expand{display:inline-block;font:normal normal normal 14px/1 FontAwesome;font-size:inherit;text-rendering:auto;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale}.fa-lg{font-size:1.33333em;line-height:.75em;vertical-align:-15%}.fa-2x{font-size:2em}.fa-3x{font-size:3em}.fa-4x{font-size:4em}.fa-5x{font-size:5em}.fa-fw{width:1.28571em;text-align:center}.fa-ul{padding-left:0;margin-left:2.14286em;list-style-type:none}.fa-ul>li{position:relative}.fa-li{position:absolute;left:-2.14286em;width:2.14286em;top:.14286em;text-align:center}.fa-li.fa-lg{left:-1.85714em}.fa-border{padding:.2em .25em .15em;border:.08em solid #eee;border-radius:.1em}.fa-pull-left{float:left}.fa-pull-right{float:right}.fa-pull-left.icon,.fa.fa-pull-left,.rst-content .code-block-caption .fa-pull-left.headerlink,.rst-content .eqno .fa-pull-left.headerlink,.rst-content .fa-pull-left.admonition-title,.rst-content code.download span.fa-pull-left:first-child,.rst-content dl dt .fa-pull-left.headerlink,.rst-content h1 .fa-pull-left.headerlink,.rst-content h2 .fa-pull-left.headerlink,.rst-content h3 .fa-pull-left.headerlink,.rst-content h4 .fa-pull-left.headerlink,.rst-content h5 .fa-pull-left.headerlink,.rst-content h6 .fa-pull-left.headerlink,.rst-content p .fa-pull-left.headerlink,.rst-content table>caption .fa-pull-left.headerlink,.rst-content tt.download span.fa-pull-left:first-child,.wy-menu-vertical li.current>a button.fa-pull-left.toctree-expand,.wy-menu-vertical li.on a button.fa-pull-left.toctree-expand,.wy-menu-vertical li button.fa-pull-left.toctree-expand{margin-right:.3em}.fa-pull-right.icon,.fa.fa-pull-right,.rst-content .code-block-caption .fa-pull-right.headerlink,.rst-content .eqno .fa-pull-right.headerlink,.rst-content .fa-pull-right.admonition-title,.rst-content code.download span.fa-pull-right:first-child,.rst-content dl dt .fa-pull-right.headerlink,.rst-content h1 .fa-pull-right.headerlink,.rst-content h2 .fa-pull-right.headerlink,.rst-content h3 .fa-pull-right.headerlink,.rst-content h4 .fa-pull-right.headerlink,.rst-content h5 .fa-pull-right.headerlink,.rst-content h6 .fa-pull-right.headerlink,.rst-content p .fa-pull-right.headerlink,.rst-content table>caption .fa-pull-right.headerlink,.rst-content tt.download span.fa-pull-right:first-child,.wy-menu-vertical li.current>a button.fa-pull-right.toctree-expand,.wy-menu-vertical li.on a button.fa-pull-right.toctree-expand,.wy-menu-vertical li button.fa-pull-right.toctree-expand{margin-left:.3em}.pull-right{float:right}.pull-left{float:left}.fa.pull-left,.pull-left.icon,.rst-content .code-block-caption .pull-left.headerlink,.rst-content .eqno .pull-left.headerlink,.rst-content .pull-left.admonition-title,.rst-content code.download span.pull-left:first-child,.rst-content dl dt .pull-left.headerlink,.rst-content h1 .pull-left.headerlink,.rst-content h2 .pull-left.headerlink,.rst-content h3 .pull-left.headerlink,.rst-content h4 .pull-left.headerlink,.rst-content h5 .pull-left.headerlink,.rst-content h6 .pull-left.headerlink,.rst-content p .pull-left.headerlink,.rst-content table>caption .pull-left.headerlink,.rst-content tt.download span.pull-left:first-child,.wy-menu-vertical li.current>a button.pull-left.toctree-expand,.wy-menu-vertical li.on a button.pull-left.toctree-expand,.wy-menu-vertical li button.pull-left.toctree-expand{margin-right:.3em}.fa.pull-right,.pull-right.icon,.rst-content .code-block-caption .pull-right.headerlink,.rst-content .eqno .pull-right.headerlink,.rst-content .pull-right.admonition-title,.rst-content code.download span.pull-right:first-child,.rst-content dl dt .pull-right.headerlink,.rst-content h1 .pull-right.headerlink,.rst-content h2 .pull-right.headerlink,.rst-content h3 .pull-right.headerlink,.rst-content h4 .pull-right.headerlink,.rst-content h5 .pull-right.headerlink,.rst-content h6 .pull-right.headerlink,.rst-content p .pull-right.headerlink,.rst-content table>caption .pull-right.headerlink,.rst-content tt.download span.pull-right:first-child,.wy-menu-vertical li.current>a button.pull-right.toctree-expand,.wy-menu-vertical li.on a button.pull-right.toctree-expand,.wy-menu-vertical li button.pull-right.toctree-expand{margin-left:.3em}.fa-spin{-webkit-animation:fa-spin 2s linear infinite;animation:fa-spin 2s linear infinite}.fa-pulse{-webkit-animation:fa-spin 1s steps(8) infinite;animation:fa-spin 1s steps(8) infinite}@-webkit-keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}to{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}@keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}to{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}.fa-rotate-90{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=1)";-webkit-transform:rotate(90deg);-ms-transform:rotate(90deg);transform:rotate(90deg)}.fa-rotate-180{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=2)";-webkit-transform:rotate(180deg);-ms-transform:rotate(180deg);transform:rotate(180deg)}.fa-rotate-270{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=3)";-webkit-transform:rotate(270deg);-ms-transform:rotate(270deg);transform:rotate(270deg)}.fa-flip-horizontal{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=0, mirror=1)";-webkit-transform:scaleX(-1);-ms-transform:scaleX(-1);transform:scaleX(-1)}.fa-flip-vertical{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=2, mirror=1)";-webkit-transform:scaleY(-1);-ms-transform:scaleY(-1);transform:scaleY(-1)}:root .fa-flip-horizontal,:root .fa-flip-vertical,:root .fa-rotate-90,:root .fa-rotate-180,:root .fa-rotate-270{filter:none}.fa-stack{position:relative;display:inline-block;width:2em;height:2em;line-height:2em;vertical-align:middle}.fa-stack-1x,.fa-stack-2x{position:absolute;left:0;width:100%;text-align:center}.fa-stack-1x{line-height:inherit}.fa-stack-2x{font-size:2em}.fa-inverse{color:#fff}.fa-glass:before{content:""}.fa-music:before{content:""}.fa-search:before,.icon-search:before{content:""}.fa-envelope-o:before{content:""}.fa-heart:before{content:""}.fa-star:before{content:""}.fa-star-o:before{content:""}.fa-user:before{content:""}.fa-film:before{content:""}.fa-th-large:before{content:""}.fa-th:before{content:""}.fa-th-list:before{content:""}.fa-check:before{content:""}.fa-close:before,.fa-remove:before,.fa-times:before{content:""}.fa-search-plus:before{content:""}.fa-search-minus:before{content:""}.fa-power-off:before{content:""}.fa-signal:before{content:""}.fa-cog:before,.fa-gear:before{content:""}.fa-trash-o:before{content:""}.fa-home:before,.icon-home:before{content:""}.fa-file-o:before{content:""}.fa-clock-o:before{content:""}.fa-road:before{content:""}.fa-download:before,.rst-content code.download span:first-child:before,.rst-content tt.download span:first-child:before{content:""}.fa-arrow-circle-o-down:before{content:""}.fa-arrow-circle-o-up:before{content:""}.fa-inbox:before{content:""}.fa-play-circle-o:before{content:""}.fa-repeat:before,.fa-rotate-right:before{content:""}.fa-refresh:before{content:""}.fa-list-alt:before{content:""}.fa-lock:before{content:""}.fa-flag:before{content:""}.fa-headphones:before{content:""}.fa-volume-off:before{content:""}.fa-volume-down:before{content:""}.fa-volume-up:before{content:""}.fa-qrcode:before{content:""}.fa-barcode:before{content:""}.fa-tag:before{content:""}.fa-tags:before{content:""}.fa-book:before,.icon-book:before{content:""}.fa-bookmark:before{content:""}.fa-print:before{content:""}.fa-camera:before{content:""}.fa-font:before{content:""}.fa-bold:before{content:""}.fa-italic:before{content:""}.fa-text-height:before{content:""}.fa-text-width:before{content:""}.fa-align-left:before{content:""}.fa-align-center:before{content:""}.fa-align-right:before{content:""}.fa-align-justify:before{content:""}.fa-list:before{content:""}.fa-dedent:before,.fa-outdent:before{content:""}.fa-indent:before{content:""}.fa-video-camera:before{content:""}.fa-image:before,.fa-photo:before,.fa-picture-o:before{content:""}.fa-pencil:before{content:""}.fa-map-marker:before{content:""}.fa-adjust:before{content:""}.fa-tint:before{content:""}.fa-edit:before,.fa-pencil-square-o:before{content:""}.fa-share-square-o:before{content:""}.fa-check-square-o:before{content:""}.fa-arrows:before{content:""}.fa-step-backward:before{content:""}.fa-fast-backward:before{content:""}.fa-backward:before{content:""}.fa-play:before{content:""}.fa-pause:before{content:""}.fa-stop:before{content:""}.fa-forward:before{content:""}.fa-fast-forward:before{content:""}.fa-step-forward:before{content:""}.fa-eject:before{content:""}.fa-chevron-left:before{content:""}.fa-chevron-right:before{content:""}.fa-plus-circle:before{content:""}.fa-minus-circle:before{content:""}.fa-times-circle:before,.wy-inline-validate.wy-inline-validate-danger .wy-input-context:before{content:""}.fa-check-circle:before,.wy-inline-validate.wy-inline-validate-success .wy-input-context:before{content:""}.fa-question-circle:before{content:""}.fa-info-circle:before{content:""}.fa-crosshairs:before{content:""}.fa-times-circle-o:before{content:""}.fa-check-circle-o:before{content:""}.fa-ban:before{content:""}.fa-arrow-left:before{content:""}.fa-arrow-right:before{content:""}.fa-arrow-up:before{content:""}.fa-arrow-down:before{content:""}.fa-mail-forward:before,.fa-share:before{content:""}.fa-expand:before{content:""}.fa-compress:before{content:""}.fa-plus:before{content:""}.fa-minus:before{content:""}.fa-asterisk:before{content:""}.fa-exclamation-circle:before,.rst-content .admonition-title:before,.wy-inline-validate.wy-inline-validate-info .wy-input-context:before,.wy-inline-validate.wy-inline-validate-warning .wy-input-context:before{content:""}.fa-gift:before{content:""}.fa-leaf:before{content:""}.fa-fire:before,.icon-fire:before{content:""}.fa-eye:before{content:""}.fa-eye-slash:before{content:""}.fa-exclamation-triangle:before,.fa-warning:before{content:""}.fa-plane:before{content:""}.fa-calendar:before{content:""}.fa-random:before{content:""}.fa-comment:before{content:""}.fa-magnet:before{content:""}.fa-chevron-up:before{content:""}.fa-chevron-down:before{content:""}.fa-retweet:before{content:""}.fa-shopping-cart:before{content:""}.fa-folder:before{content:""}.fa-folder-open:before{content:""}.fa-arrows-v:before{content:""}.fa-arrows-h:before{content:""}.fa-bar-chart-o:before,.fa-bar-chart:before{content:""}.fa-twitter-square:before{content:""}.fa-facebook-square:before{content:""}.fa-camera-retro:before{content:""}.fa-key:before{content:""}.fa-cogs:before,.fa-gears:before{content:""}.fa-comments:before{content:""}.fa-thumbs-o-up:before{content:""}.fa-thumbs-o-down:before{content:""}.fa-star-half:before{content:""}.fa-heart-o:before{content:""}.fa-sign-out:before{content:""}.fa-linkedin-square:before{content:""}.fa-thumb-tack:before{content:""}.fa-external-link:before{content:""}.fa-sign-in:before{content:""}.fa-trophy:before{content:""}.fa-github-square:before{content:""}.fa-upload:before{content:""}.fa-lemon-o:before{content:""}.fa-phone:before{content:""}.fa-square-o:before{content:""}.fa-bookmark-o:before{content:""}.fa-phone-square:before{content:""}.fa-twitter:before{content:""}.fa-facebook-f:before,.fa-facebook:before{content:""}.fa-github:before,.icon-github:before{content:""}.fa-unlock:before{content:""}.fa-credit-card:before{content:""}.fa-feed:before,.fa-rss:before{content:""}.fa-hdd-o:before{content:""}.fa-bullhorn:before{content:""}.fa-bell:before{content:""}.fa-certificate:before{content:""}.fa-hand-o-right:before{content:""}.fa-hand-o-left:before{content:""}.fa-hand-o-up:before{content:""}.fa-hand-o-down:before{content:""}.fa-arrow-circle-left:before,.icon-circle-arrow-left:before{content:""}.fa-arrow-circle-right:before,.icon-circle-arrow-right:before{content:""}.fa-arrow-circle-up:before{content:""}.fa-arrow-circle-down:before{content:""}.fa-globe:before{content:""}.fa-wrench:before{content:""}.fa-tasks:before{content:""}.fa-filter:before{content:""}.fa-briefcase:before{content:""}.fa-arrows-alt:before{content:""}.fa-group:before,.fa-users:before{content:""}.fa-chain:before,.fa-link:before,.icon-link:before{content:""}.fa-cloud:before{content:""}.fa-flask:before{content:""}.fa-cut:before,.fa-scissors:before{content:""}.fa-copy:before,.fa-files-o:before{content:""}.fa-paperclip:before{content:""}.fa-floppy-o:before,.fa-save:before{content:""}.fa-square:before{content:""}.fa-bars:before,.fa-navicon:before,.fa-reorder:before{content:""}.fa-list-ul:before{content:""}.fa-list-ol:before{content:""}.fa-strikethrough:before{content:""}.fa-underline:before{content:""}.fa-table:before{content:""}.fa-magic:before{content:""}.fa-truck:before{content:""}.fa-pinterest:before{content:""}.fa-pinterest-square:before{content:""}.fa-google-plus-square:before{content:""}.fa-google-plus:before{content:""}.fa-money:before{content:""}.fa-caret-down:before,.icon-caret-down:before,.wy-dropdown .caret:before{content:""}.fa-caret-up:before{content:""}.fa-caret-left:before{content:""}.fa-caret-right:before{content:""}.fa-columns:before{content:""}.fa-sort:before,.fa-unsorted:before{content:""}.fa-sort-desc:before,.fa-sort-down:before{content:""}.fa-sort-asc:before,.fa-sort-up:before{content:""}.fa-envelope:before{content:""}.fa-linkedin:before{content:""}.fa-rotate-left:before,.fa-undo:before{content:""}.fa-gavel:before,.fa-legal:before{content:""}.fa-dashboard:before,.fa-tachometer:before{content:""}.fa-comment-o:before{content:""}.fa-comments-o:before{content:""}.fa-bolt:before,.fa-flash:before{content:""}.fa-sitemap:before{content:""}.fa-umbrella:before{content:""}.fa-clipboard:before,.fa-paste:before{content:""}.fa-lightbulb-o:before{content:""}.fa-exchange:before{content:""}.fa-cloud-download:before{content:""}.fa-cloud-upload:before{content:""}.fa-user-md:before{content:""}.fa-stethoscope:before{content:""}.fa-suitcase:before{content:""}.fa-bell-o:before{content:""}.fa-coffee:before{content:""}.fa-cutlery:before{content:""}.fa-file-text-o:before{content:""}.fa-building-o:before{content:""}.fa-hospital-o:before{content:""}.fa-ambulance:before{content:""}.fa-medkit:before{content:""}.fa-fighter-jet:before{content:""}.fa-beer:before{content:""}.fa-h-square:before{content:""}.fa-plus-square:before{content:""}.fa-angle-double-left:before{content:""}.fa-angle-double-right:before{content:""}.fa-angle-double-up:before{content:""}.fa-angle-double-down:before{content:""}.fa-angle-left:before{content:""}.fa-angle-right:before{content:""}.fa-angle-up:before{content:""}.fa-angle-down:before{content:""}.fa-desktop:before{content:""}.fa-laptop:before{content:""}.fa-tablet:before{content:""}.fa-mobile-phone:before,.fa-mobile:before{content:""}.fa-circle-o:before{content:""}.fa-quote-left:before{content:""}.fa-quote-right:before{content:""}.fa-spinner:before{content:""}.fa-circle:before{content:""}.fa-mail-reply:before,.fa-reply:before{content:""}.fa-github-alt:before{content:""}.fa-folder-o:before{content:""}.fa-folder-open-o:before{content:""}.fa-smile-o:before{content:""}.fa-frown-o:before{content:""}.fa-meh-o:before{content:""}.fa-gamepad:before{content:""}.fa-keyboard-o:before{content:""}.fa-flag-o:before{content:""}.fa-flag-checkered:before{content:""}.fa-terminal:before{content:""}.fa-code:before{content:""}.fa-mail-reply-all:before,.fa-reply-all:before{content:""}.fa-star-half-empty:before,.fa-star-half-full:before,.fa-star-half-o:before{content:""}.fa-location-arrow:before{content:""}.fa-crop:before{content:""}.fa-code-fork:before{content:""}.fa-chain-broken:before,.fa-unlink:before{content:""}.fa-question:before{content:""}.fa-info:before{content:""}.fa-exclamation:before{content:""}.fa-superscript:before{content:""}.fa-subscript:before{content:""}.fa-eraser:before{content:""}.fa-puzzle-piece:before{content:""}.fa-microphone:before{content:""}.fa-microphone-slash:before{content:""}.fa-shield:before{content:""}.fa-calendar-o:before{content:""}.fa-fire-extinguisher:before{content:""}.fa-rocket:before{content:""}.fa-maxcdn:before{content:""}.fa-chevron-circle-left:before{content:""}.fa-chevron-circle-right:before{content:""}.fa-chevron-circle-up:before{content:""}.fa-chevron-circle-down:before{content:""}.fa-html5:before{content:""}.fa-css3:before{content:""}.fa-anchor:before{content:""}.fa-unlock-alt:before{content:""}.fa-bullseye:before{content:""}.fa-ellipsis-h:before{content:""}.fa-ellipsis-v:before{content:""}.fa-rss-square:before{content:""}.fa-play-circle:before{content:""}.fa-ticket:before{content:""}.fa-minus-square:before{content:""}.fa-minus-square-o:before,.wy-menu-vertical li.current>a button.toctree-expand:before,.wy-menu-vertical li.on a button.toctree-expand:before{content:""}.fa-level-up:before{content:""}.fa-level-down:before{content:""}.fa-check-square:before{content:""}.fa-pencil-square:before{content:""}.fa-external-link-square:before{content:""}.fa-share-square:before{content:""}.fa-compass:before{content:""}.fa-caret-square-o-down:before,.fa-toggle-down:before{content:""}.fa-caret-square-o-up:before,.fa-toggle-up:before{content:""}.fa-caret-square-o-right:before,.fa-toggle-right:before{content:""}.fa-eur:before,.fa-euro:before{content:""}.fa-gbp:before{content:""}.fa-dollar:before,.fa-usd:before{content:""}.fa-inr:before,.fa-rupee:before{content:""}.fa-cny:before,.fa-jpy:before,.fa-rmb:before,.fa-yen:before{content:""}.fa-rouble:before,.fa-rub:before,.fa-ruble:before{content:""}.fa-krw:before,.fa-won:before{content:""}.fa-bitcoin:before,.fa-btc:before{content:""}.fa-file:before{content:""}.fa-file-text:before{content:""}.fa-sort-alpha-asc:before{content:""}.fa-sort-alpha-desc:before{content:""}.fa-sort-amount-asc:before{content:""}.fa-sort-amount-desc:before{content:""}.fa-sort-numeric-asc:before{content:""}.fa-sort-numeric-desc:before{content:""}.fa-thumbs-up:before{content:""}.fa-thumbs-down:before{content:""}.fa-youtube-square:before{content:""}.fa-youtube:before{content:""}.fa-xing:before{content:""}.fa-xing-square:before{content:""}.fa-youtube-play:before{content:""}.fa-dropbox:before{content:""}.fa-stack-overflow:before{content:""}.fa-instagram:before{content:""}.fa-flickr:before{content:""}.fa-adn:before{content:""}.fa-bitbucket:before,.icon-bitbucket:before{content:""}.fa-bitbucket-square:before{content:""}.fa-tumblr:before{content:""}.fa-tumblr-square:before{content:""}.fa-long-arrow-down:before{content:""}.fa-long-arrow-up:before{content:""}.fa-long-arrow-left:before{content:""}.fa-long-arrow-right:before{content:""}.fa-apple:before{content:""}.fa-windows:before{content:""}.fa-android:before{content:""}.fa-linux:before{content:""}.fa-dribbble:before{content:""}.fa-skype:before{content:""}.fa-foursquare:before{content:""}.fa-trello:before{content:""}.fa-female:before{content:""}.fa-male:before{content:""}.fa-gittip:before,.fa-gratipay:before{content:""}.fa-sun-o:before{content:""}.fa-moon-o:before{content:""}.fa-archive:before{content:""}.fa-bug:before{content:""}.fa-vk:before{content:""}.fa-weibo:before{content:""}.fa-renren:before{content:""}.fa-pagelines:before{content:""}.fa-stack-exchange:before{content:""}.fa-arrow-circle-o-right:before{content:""}.fa-arrow-circle-o-left:before{content:""}.fa-caret-square-o-left:before,.fa-toggle-left:before{content:""}.fa-dot-circle-o:before{content:""}.fa-wheelchair:before{content:""}.fa-vimeo-square:before{content:""}.fa-try:before,.fa-turkish-lira:before{content:""}.fa-plus-square-o:before,.wy-menu-vertical li button.toctree-expand:before{content:""}.fa-space-shuttle:before{content:""}.fa-slack:before{content:""}.fa-envelope-square:before{content:""}.fa-wordpress:before{content:""}.fa-openid:before{content:""}.fa-bank:before,.fa-institution:before,.fa-university:before{content:""}.fa-graduation-cap:before,.fa-mortar-board:before{content:""}.fa-yahoo:before{content:""}.fa-google:before{content:""}.fa-reddit:before{content:""}.fa-reddit-square:before{content:""}.fa-stumbleupon-circle:before{content:""}.fa-stumbleupon:before{content:""}.fa-delicious:before{content:""}.fa-digg:before{content:""}.fa-pied-piper-pp:before{content:""}.fa-pied-piper-alt:before{content:""}.fa-drupal:before{content:""}.fa-joomla:before{content:""}.fa-language:before{content:""}.fa-fax:before{content:""}.fa-building:before{content:""}.fa-child:before{content:""}.fa-paw:before{content:""}.fa-spoon:before{content:""}.fa-cube:before{content:""}.fa-cubes:before{content:""}.fa-behance:before{content:""}.fa-behance-square:before{content:""}.fa-steam:before{content:""}.fa-steam-square:before{content:""}.fa-recycle:before{content:""}.fa-automobile:before,.fa-car:before{content:""}.fa-cab:before,.fa-taxi:before{content:""}.fa-tree:before{content:""}.fa-spotify:before{content:""}.fa-deviantart:before{content:""}.fa-soundcloud:before{content:""}.fa-database:before{content:""}.fa-file-pdf-o:before{content:""}.fa-file-word-o:before{content:""}.fa-file-excel-o:before{content:""}.fa-file-powerpoint-o:before{content:""}.fa-file-image-o:before,.fa-file-photo-o:before,.fa-file-picture-o:before{content:""}.fa-file-archive-o:before,.fa-file-zip-o:before{content:""}.fa-file-audio-o:before,.fa-file-sound-o:before{content:""}.fa-file-movie-o:before,.fa-file-video-o:before{content:""}.fa-file-code-o:before{content:""}.fa-vine:before{content:""}.fa-codepen:before{content:""}.fa-jsfiddle:before{content:""}.fa-life-bouy:before,.fa-life-buoy:before,.fa-life-ring:before,.fa-life-saver:before,.fa-support:before{content:""}.fa-circle-o-notch:before{content:""}.fa-ra:before,.fa-rebel:before,.fa-resistance:before{content:""}.fa-empire:before,.fa-ge:before{content:""}.fa-git-square:before{content:""}.fa-git:before{content:""}.fa-hacker-news:before,.fa-y-combinator-square:before,.fa-yc-square:before{content:""}.fa-tencent-weibo:before{content:""}.fa-qq:before{content:""}.fa-wechat:before,.fa-weixin:before{content:""}.fa-paper-plane:before,.fa-send:before{content:""}.fa-paper-plane-o:before,.fa-send-o:before{content:""}.fa-history:before{content:""}.fa-circle-thin:before{content:""}.fa-header:before{content:""}.fa-paragraph:before{content:""}.fa-sliders:before{content:""}.fa-share-alt:before{content:""}.fa-share-alt-square:before{content:""}.fa-bomb:before{content:""}.fa-futbol-o:before,.fa-soccer-ball-o:before{content:""}.fa-tty:before{content:""}.fa-binoculars:before{content:""}.fa-plug:before{content:""}.fa-slideshare:before{content:""}.fa-twitch:before{content:""}.fa-yelp:before{content:""}.fa-newspaper-o:before{content:""}.fa-wifi:before{content:""}.fa-calculator:before{content:""}.fa-paypal:before{content:""}.fa-google-wallet:before{content:""}.fa-cc-visa:before{content:""}.fa-cc-mastercard:before{content:""}.fa-cc-discover:before{content:""}.fa-cc-amex:before{content:""}.fa-cc-paypal:before{content:""}.fa-cc-stripe:before{content:""}.fa-bell-slash:before{content:""}.fa-bell-slash-o:before{content:""}.fa-trash:before{content:""}.fa-copyright:before{content:""}.fa-at:before{content:""}.fa-eyedropper:before{content:""}.fa-paint-brush:before{content:""}.fa-birthday-cake:before{content:""}.fa-area-chart:before{content:""}.fa-pie-chart:before{content:""}.fa-line-chart:before{content:""}.fa-lastfm:before{content:""}.fa-lastfm-square:before{content:""}.fa-toggle-off:before{content:""}.fa-toggle-on:before{content:""}.fa-bicycle:before{content:""}.fa-bus:before{content:""}.fa-ioxhost:before{content:""}.fa-angellist:before{content:""}.fa-cc:before{content:""}.fa-ils:before,.fa-shekel:before,.fa-sheqel:before{content:""}.fa-meanpath:before{content:""}.fa-buysellads:before{content:""}.fa-connectdevelop:before{content:""}.fa-dashcube:before{content:""}.fa-forumbee:before{content:""}.fa-leanpub:before{content:""}.fa-sellsy:before{content:""}.fa-shirtsinbulk:before{content:""}.fa-simplybuilt:before{content:""}.fa-skyatlas:before{content:""}.fa-cart-plus:before{content:""}.fa-cart-arrow-down:before{content:""}.fa-diamond:before{content:""}.fa-ship:before{content:""}.fa-user-secret:before{content:""}.fa-motorcycle:before{content:""}.fa-street-view:before{content:""}.fa-heartbeat:before{content:""}.fa-venus:before{content:""}.fa-mars:before{content:""}.fa-mercury:before{content:""}.fa-intersex:before,.fa-transgender:before{content:""}.fa-transgender-alt:before{content:""}.fa-venus-double:before{content:""}.fa-mars-double:before{content:""}.fa-venus-mars:before{content:""}.fa-mars-stroke:before{content:""}.fa-mars-stroke-v:before{content:""}.fa-mars-stroke-h:before{content:""}.fa-neuter:before{content:""}.fa-genderless:before{content:""}.fa-facebook-official:before{content:""}.fa-pinterest-p:before{content:""}.fa-whatsapp:before{content:""}.fa-server:before{content:""}.fa-user-plus:before{content:""}.fa-user-times:before{content:""}.fa-bed:before,.fa-hotel:before{content:""}.fa-viacoin:before{content:""}.fa-train:before{content:""}.fa-subway:before{content:""}.fa-medium:before{content:""}.fa-y-combinator:before,.fa-yc:before{content:""}.fa-optin-monster:before{content:""}.fa-opencart:before{content:""}.fa-expeditedssl:before{content:""}.fa-battery-4:before,.fa-battery-full:before,.fa-battery:before{content:""}.fa-battery-3:before,.fa-battery-three-quarters:before{content:""}.fa-battery-2:before,.fa-battery-half:before{content:""}.fa-battery-1:before,.fa-battery-quarter:before{content:""}.fa-battery-0:before,.fa-battery-empty:before{content:""}.fa-mouse-pointer:before{content:""}.fa-i-cursor:before{content:""}.fa-object-group:before{content:""}.fa-object-ungroup:before{content:""}.fa-sticky-note:before{content:""}.fa-sticky-note-o:before{content:""}.fa-cc-jcb:before{content:""}.fa-cc-diners-club:before{content:""}.fa-clone:before{content:""}.fa-balance-scale:before{content:""}.fa-hourglass-o:before{content:""}.fa-hourglass-1:before,.fa-hourglass-start:before{content:""}.fa-hourglass-2:before,.fa-hourglass-half:before{content:""}.fa-hourglass-3:before,.fa-hourglass-end:before{content:""}.fa-hourglass:before{content:""}.fa-hand-grab-o:before,.fa-hand-rock-o:before{content:""}.fa-hand-paper-o:before,.fa-hand-stop-o:before{content:""}.fa-hand-scissors-o:before{content:""}.fa-hand-lizard-o:before{content:""}.fa-hand-spock-o:before{content:""}.fa-hand-pointer-o:before{content:""}.fa-hand-peace-o:before{content:""}.fa-trademark:before{content:""}.fa-registered:before{content:""}.fa-creative-commons:before{content:""}.fa-gg:before{content:""}.fa-gg-circle:before{content:""}.fa-tripadvisor:before{content:""}.fa-odnoklassniki:before{content:""}.fa-odnoklassniki-square:before{content:""}.fa-get-pocket:before{content:""}.fa-wikipedia-w:before{content:""}.fa-safari:before{content:""}.fa-chrome:before{content:""}.fa-firefox:before{content:""}.fa-opera:before{content:""}.fa-internet-explorer:before{content:""}.fa-television:before,.fa-tv:before{content:""}.fa-contao:before{content:""}.fa-500px:before{content:""}.fa-amazon:before{content:""}.fa-calendar-plus-o:before{content:""}.fa-calendar-minus-o:before{content:""}.fa-calendar-times-o:before{content:""}.fa-calendar-check-o:before{content:""}.fa-industry:before{content:""}.fa-map-pin:before{content:""}.fa-map-signs:before{content:""}.fa-map-o:before{content:""}.fa-map:before{content:""}.fa-commenting:before{content:""}.fa-commenting-o:before{content:""}.fa-houzz:before{content:""}.fa-vimeo:before{content:""}.fa-black-tie:before{content:""}.fa-fonticons:before{content:""}.fa-reddit-alien:before{content:""}.fa-edge:before{content:""}.fa-credit-card-alt:before{content:""}.fa-codiepie:before{content:""}.fa-modx:before{content:""}.fa-fort-awesome:before{content:""}.fa-usb:before{content:""}.fa-product-hunt:before{content:""}.fa-mixcloud:before{content:""}.fa-scribd:before{content:""}.fa-pause-circle:before{content:""}.fa-pause-circle-o:before{content:""}.fa-stop-circle:before{content:""}.fa-stop-circle-o:before{content:""}.fa-shopping-bag:before{content:""}.fa-shopping-basket:before{content:""}.fa-hashtag:before{content:""}.fa-bluetooth:before{content:""}.fa-bluetooth-b:before{content:""}.fa-percent:before{content:""}.fa-gitlab:before,.icon-gitlab:before{content:""}.fa-wpbeginner:before{content:""}.fa-wpforms:before{content:""}.fa-envira:before{content:""}.fa-universal-access:before{content:""}.fa-wheelchair-alt:before{content:""}.fa-question-circle-o:before{content:""}.fa-blind:before{content:""}.fa-audio-description:before{content:""}.fa-volume-control-phone:before{content:""}.fa-braille:before{content:""}.fa-assistive-listening-systems:before{content:""}.fa-american-sign-language-interpreting:before,.fa-asl-interpreting:before{content:""}.fa-deaf:before,.fa-deafness:before,.fa-hard-of-hearing:before{content:""}.fa-glide:before{content:""}.fa-glide-g:before{content:""}.fa-sign-language:before,.fa-signing:before{content:""}.fa-low-vision:before{content:""}.fa-viadeo:before{content:""}.fa-viadeo-square:before{content:""}.fa-snapchat:before{content:""}.fa-snapchat-ghost:before{content:""}.fa-snapchat-square:before{content:""}.fa-pied-piper:before{content:""}.fa-first-order:before{content:""}.fa-yoast:before{content:""}.fa-themeisle:before{content:""}.fa-google-plus-circle:before,.fa-google-plus-official:before{content:""}.fa-fa:before,.fa-font-awesome:before{content:""}.fa-handshake-o:before{content:""}.fa-envelope-open:before{content:""}.fa-envelope-open-o:before{content:""}.fa-linode:before{content:""}.fa-address-book:before{content:""}.fa-address-book-o:before{content:""}.fa-address-card:before,.fa-vcard:before{content:""}.fa-address-card-o:before,.fa-vcard-o:before{content:""}.fa-user-circle:before{content:""}.fa-user-circle-o:before{content:""}.fa-user-o:before{content:""}.fa-id-badge:before{content:""}.fa-drivers-license:before,.fa-id-card:before{content:""}.fa-drivers-license-o:before,.fa-id-card-o:before{content:""}.fa-quora:before{content:""}.fa-free-code-camp:before{content:""}.fa-telegram:before{content:""}.fa-thermometer-4:before,.fa-thermometer-full:before,.fa-thermometer:before{content:""}.fa-thermometer-3:before,.fa-thermometer-three-quarters:before{content:""}.fa-thermometer-2:before,.fa-thermometer-half:before{content:""}.fa-thermometer-1:before,.fa-thermometer-quarter:before{content:""}.fa-thermometer-0:before,.fa-thermometer-empty:before{content:""}.fa-shower:before{content:""}.fa-bath:before,.fa-bathtub:before,.fa-s15:before{content:""}.fa-podcast:before{content:""}.fa-window-maximize:before{content:""}.fa-window-minimize:before{content:""}.fa-window-restore:before{content:""}.fa-times-rectangle:before,.fa-window-close:before{content:""}.fa-times-rectangle-o:before,.fa-window-close-o:before{content:""}.fa-bandcamp:before{content:""}.fa-grav:before{content:""}.fa-etsy:before{content:""}.fa-imdb:before{content:""}.fa-ravelry:before{content:""}.fa-eercast:before{content:""}.fa-microchip:before{content:""}.fa-snowflake-o:before{content:""}.fa-superpowers:before{content:""}.fa-wpexplorer:before{content:""}.fa-meetup:before{content:""}.sr-only{position:absolute;width:1px;height:1px;padding:0;margin:-1px;overflow:hidden;clip:rect(0,0,0,0);border:0}.sr-only-focusable:active,.sr-only-focusable:focus{position:static;width:auto;height:auto;margin:0;overflow:visible;clip:auto}.fa,.icon,.rst-content .admonition-title,.rst-content .code-block-caption .headerlink,.rst-content .eqno .headerlink,.rst-content code.download span:first-child,.rst-content dl dt .headerlink,.rst-content h1 .headerlink,.rst-content h2 .headerlink,.rst-content h3 .headerlink,.rst-content h4 .headerlink,.rst-content h5 .headerlink,.rst-content h6 .headerlink,.rst-content p.caption .headerlink,.rst-content p .headerlink,.rst-content table>caption .headerlink,.rst-content tt.download span:first-child,.wy-dropdown .caret,.wy-inline-validate.wy-inline-validate-danger .wy-input-context,.wy-inline-validate.wy-inline-validate-info .wy-input-context,.wy-inline-validate.wy-inline-validate-success .wy-input-context,.wy-inline-validate.wy-inline-validate-warning .wy-input-context,.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand,.wy-menu-vertical li button.toctree-expand{font-family:inherit}.fa:before,.icon:before,.rst-content .admonition-title:before,.rst-content .code-block-caption .headerlink:before,.rst-content .eqno .headerlink:before,.rst-content code.download span:first-child:before,.rst-content dl dt .headerlink:before,.rst-content h1 .headerlink:before,.rst-content h2 .headerlink:before,.rst-content h3 .headerlink:before,.rst-content h4 .headerlink:before,.rst-content h5 .headerlink:before,.rst-content h6 .headerlink:before,.rst-content p.caption .headerlink:before,.rst-content p .headerlink:before,.rst-content table>caption .headerlink:before,.rst-content tt.download span:first-child:before,.wy-dropdown .caret:before,.wy-inline-validate.wy-inline-validate-danger .wy-input-context:before,.wy-inline-validate.wy-inline-validate-info .wy-input-context:before,.wy-inline-validate.wy-inline-validate-success .wy-input-context:before,.wy-inline-validate.wy-inline-validate-warning .wy-input-context:before,.wy-menu-vertical li.current>a button.toctree-expand:before,.wy-menu-vertical li.on a button.toctree-expand:before,.wy-menu-vertical li button.toctree-expand:before{font-family:FontAwesome;display:inline-block;font-style:normal;font-weight:400;line-height:1;text-decoration:inherit}.rst-content .code-block-caption a .headerlink,.rst-content .eqno a .headerlink,.rst-content a .admonition-title,.rst-content code.download a span:first-child,.rst-content dl dt a .headerlink,.rst-content h1 a .headerlink,.rst-content h2 a .headerlink,.rst-content h3 a .headerlink,.rst-content h4 a .headerlink,.rst-content h5 a .headerlink,.rst-content h6 a .headerlink,.rst-content p.caption a .headerlink,.rst-content p a .headerlink,.rst-content table>caption a .headerlink,.rst-content tt.download a span:first-child,.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand,.wy-menu-vertical li a button.toctree-expand,a .fa,a .icon,a .rst-content .admonition-title,a .rst-content .code-block-caption .headerlink,a .rst-content .eqno .headerlink,a .rst-content code.download span:first-child,a .rst-content dl dt .headerlink,a .rst-content h1 .headerlink,a .rst-content h2 .headerlink,a .rst-content h3 .headerlink,a .rst-content h4 .headerlink,a .rst-content h5 .headerlink,a .rst-content h6 .headerlink,a .rst-content p.caption .headerlink,a .rst-content p .headerlink,a .rst-content table>caption .headerlink,a .rst-content tt.download span:first-child,a .wy-menu-vertical li button.toctree-expand{display:inline-block;text-decoration:inherit}.btn .fa,.btn .icon,.btn .rst-content .admonition-title,.btn .rst-content .code-block-caption .headerlink,.btn .rst-content .eqno .headerlink,.btn .rst-content code.download span:first-child,.btn .rst-content dl dt .headerlink,.btn .rst-content h1 .headerlink,.btn .rst-content h2 .headerlink,.btn .rst-content h3 .headerlink,.btn .rst-content h4 .headerlink,.btn .rst-content h5 .headerlink,.btn .rst-content h6 .headerlink,.btn .rst-content p .headerlink,.btn .rst-content table>caption .headerlink,.btn .rst-content tt.download span:first-child,.btn .wy-menu-vertical li.current>a button.toctree-expand,.btn .wy-menu-vertical li.on a button.toctree-expand,.btn .wy-menu-vertical li button.toctree-expand,.nav .fa,.nav .icon,.nav .rst-content .admonition-title,.nav .rst-content .code-block-caption .headerlink,.nav .rst-content .eqno .headerlink,.nav .rst-content code.download span:first-child,.nav .rst-content dl dt .headerlink,.nav .rst-content h1 .headerlink,.nav .rst-content h2 .headerlink,.nav .rst-content h3 .headerlink,.nav .rst-content h4 .headerlink,.nav .rst-content h5 .headerlink,.nav .rst-content h6 .headerlink,.nav .rst-content p .headerlink,.nav .rst-content table>caption .headerlink,.nav .rst-content tt.download span:first-child,.nav .wy-menu-vertical li.current>a button.toctree-expand,.nav .wy-menu-vertical li.on a button.toctree-expand,.nav .wy-menu-vertical li button.toctree-expand,.rst-content .btn .admonition-title,.rst-content .code-block-caption .btn .headerlink,.rst-content .code-block-caption .nav .headerlink,.rst-content .eqno .btn .headerlink,.rst-content .eqno .nav .headerlink,.rst-content .nav .admonition-title,.rst-content code.download .btn span:first-child,.rst-content code.download .nav span:first-child,.rst-content dl dt .btn .headerlink,.rst-content dl dt .nav .headerlink,.rst-content h1 .btn .headerlink,.rst-content h1 .nav .headerlink,.rst-content h2 .btn .headerlink,.rst-content h2 .nav .headerlink,.rst-content h3 .btn .headerlink,.rst-content h3 .nav .headerlink,.rst-content h4 .btn .headerlink,.rst-content h4 .nav .headerlink,.rst-content h5 .btn .headerlink,.rst-content h5 .nav .headerlink,.rst-content h6 .btn .headerlink,.rst-content h6 .nav .headerlink,.rst-content p .btn .headerlink,.rst-content p .nav .headerlink,.rst-content table>caption .btn .headerlink,.rst-content table>caption .nav .headerlink,.rst-content tt.download .btn span:first-child,.rst-content tt.download .nav span:first-child,.wy-menu-vertical li .btn button.toctree-expand,.wy-menu-vertical li.current>a .btn button.toctree-expand,.wy-menu-vertical li.current>a .nav button.toctree-expand,.wy-menu-vertical li .nav button.toctree-expand,.wy-menu-vertical li.on a .btn button.toctree-expand,.wy-menu-vertical li.on a .nav button.toctree-expand{display:inline}.btn .fa-large.icon,.btn .fa.fa-large,.btn .rst-content .code-block-caption .fa-large.headerlink,.btn .rst-content .eqno .fa-large.headerlink,.btn .rst-content .fa-large.admonition-title,.btn .rst-content code.download span.fa-large:first-child,.btn .rst-content dl dt .fa-large.headerlink,.btn .rst-content h1 .fa-large.headerlink,.btn .rst-content h2 .fa-large.headerlink,.btn .rst-content h3 .fa-large.headerlink,.btn .rst-content h4 .fa-large.headerlink,.btn .rst-content h5 .fa-large.headerlink,.btn .rst-content h6 .fa-large.headerlink,.btn .rst-content p .fa-large.headerlink,.btn .rst-content table>caption .fa-large.headerlink,.btn .rst-content tt.download span.fa-large:first-child,.btn .wy-menu-vertical li button.fa-large.toctree-expand,.nav .fa-large.icon,.nav .fa.fa-large,.nav .rst-content .code-block-caption .fa-large.headerlink,.nav .rst-content .eqno .fa-large.headerlink,.nav .rst-content .fa-large.admonition-title,.nav .rst-content code.download span.fa-large:first-child,.nav .rst-content dl dt .fa-large.headerlink,.nav .rst-content h1 .fa-large.headerlink,.nav .rst-content h2 .fa-large.headerlink,.nav .rst-content h3 .fa-large.headerlink,.nav .rst-content h4 .fa-large.headerlink,.nav .rst-content h5 .fa-large.headerlink,.nav .rst-content h6 .fa-large.headerlink,.nav .rst-content p .fa-large.headerlink,.nav .rst-content table>caption .fa-large.headerlink,.nav .rst-content tt.download span.fa-large:first-child,.nav .wy-menu-vertical li button.fa-large.toctree-expand,.rst-content .btn .fa-large.admonition-title,.rst-content .code-block-caption .btn .fa-large.headerlink,.rst-content .code-block-caption .nav .fa-large.headerlink,.rst-content .eqno .btn .fa-large.headerlink,.rst-content .eqno .nav .fa-large.headerlink,.rst-content .nav .fa-large.admonition-title,.rst-content code.download .btn span.fa-large:first-child,.rst-content code.download .nav span.fa-large:first-child,.rst-content dl dt .btn .fa-large.headerlink,.rst-content dl dt .nav .fa-large.headerlink,.rst-content h1 .btn .fa-large.headerlink,.rst-content h1 .nav .fa-large.headerlink,.rst-content h2 .btn .fa-large.headerlink,.rst-content h2 .nav .fa-large.headerlink,.rst-content h3 .btn .fa-large.headerlink,.rst-content h3 .nav .fa-large.headerlink,.rst-content h4 .btn .fa-large.headerlink,.rst-content h4 .nav .fa-large.headerlink,.rst-content h5 .btn .fa-large.headerlink,.rst-content h5 .nav .fa-large.headerlink,.rst-content h6 .btn .fa-large.headerlink,.rst-content h6 .nav .fa-large.headerlink,.rst-content p .btn .fa-large.headerlink,.rst-content p .nav .fa-large.headerlink,.rst-content table>caption .btn .fa-large.headerlink,.rst-content table>caption .nav .fa-large.headerlink,.rst-content tt.download .btn span.fa-large:first-child,.rst-content tt.download .nav span.fa-large:first-child,.wy-menu-vertical li .btn button.fa-large.toctree-expand,.wy-menu-vertical li .nav button.fa-large.toctree-expand{line-height:.9em}.btn .fa-spin.icon,.btn .fa.fa-spin,.btn .rst-content .code-block-caption .fa-spin.headerlink,.btn .rst-content .eqno .fa-spin.headerlink,.btn .rst-content .fa-spin.admonition-title,.btn .rst-content code.download span.fa-spin:first-child,.btn .rst-content dl dt .fa-spin.headerlink,.btn .rst-content h1 .fa-spin.headerlink,.btn .rst-content h2 .fa-spin.headerlink,.btn .rst-content h3 .fa-spin.headerlink,.btn .rst-content h4 .fa-spin.headerlink,.btn .rst-content h5 .fa-spin.headerlink,.btn .rst-content h6 .fa-spin.headerlink,.btn .rst-content p .fa-spin.headerlink,.btn .rst-content table>caption .fa-spin.headerlink,.btn .rst-content tt.download span.fa-spin:first-child,.btn .wy-menu-vertical li button.fa-spin.toctree-expand,.nav .fa-spin.icon,.nav .fa.fa-spin,.nav .rst-content .code-block-caption .fa-spin.headerlink,.nav .rst-content .eqno .fa-spin.headerlink,.nav .rst-content .fa-spin.admonition-title,.nav .rst-content code.download span.fa-spin:first-child,.nav .rst-content dl dt .fa-spin.headerlink,.nav .rst-content h1 .fa-spin.headerlink,.nav .rst-content h2 .fa-spin.headerlink,.nav .rst-content h3 .fa-spin.headerlink,.nav .rst-content h4 .fa-spin.headerlink,.nav .rst-content h5 .fa-spin.headerlink,.nav .rst-content h6 .fa-spin.headerlink,.nav .rst-content p .fa-spin.headerlink,.nav .rst-content table>caption .fa-spin.headerlink,.nav .rst-content tt.download span.fa-spin:first-child,.nav .wy-menu-vertical li button.fa-spin.toctree-expand,.rst-content .btn .fa-spin.admonition-title,.rst-content .code-block-caption .btn .fa-spin.headerlink,.rst-content .code-block-caption .nav .fa-spin.headerlink,.rst-content .eqno .btn .fa-spin.headerlink,.rst-content .eqno .nav .fa-spin.headerlink,.rst-content .nav .fa-spin.admonition-title,.rst-content code.download .btn span.fa-spin:first-child,.rst-content code.download .nav span.fa-spin:first-child,.rst-content dl dt .btn .fa-spin.headerlink,.rst-content dl dt .nav .fa-spin.headerlink,.rst-content h1 .btn .fa-spin.headerlink,.rst-content h1 .nav .fa-spin.headerlink,.rst-content h2 .btn .fa-spin.headerlink,.rst-content h2 .nav .fa-spin.headerlink,.rst-content h3 .btn .fa-spin.headerlink,.rst-content h3 .nav .fa-spin.headerlink,.rst-content h4 .btn .fa-spin.headerlink,.rst-content h4 .nav .fa-spin.headerlink,.rst-content h5 .btn .fa-spin.headerlink,.rst-content h5 .nav .fa-spin.headerlink,.rst-content h6 .btn .fa-spin.headerlink,.rst-content h6 .nav .fa-spin.headerlink,.rst-content p .btn .fa-spin.headerlink,.rst-content p .nav .fa-spin.headerlink,.rst-content table>caption .btn .fa-spin.headerlink,.rst-content table>caption .nav .fa-spin.headerlink,.rst-content tt.download .btn span.fa-spin:first-child,.rst-content tt.download .nav span.fa-spin:first-child,.wy-menu-vertical li .btn button.fa-spin.toctree-expand,.wy-menu-vertical li .nav button.fa-spin.toctree-expand{display:inline-block}.btn.fa:before,.btn.icon:before,.rst-content .btn.admonition-title:before,.rst-content .code-block-caption .btn.headerlink:before,.rst-content .eqno .btn.headerlink:before,.rst-content code.download span.btn:first-child:before,.rst-content dl dt .btn.headerlink:before,.rst-content h1 .btn.headerlink:before,.rst-content h2 .btn.headerlink:before,.rst-content h3 .btn.headerlink:before,.rst-content h4 .btn.headerlink:before,.rst-content h5 .btn.headerlink:before,.rst-content h6 .btn.headerlink:before,.rst-content p .btn.headerlink:before,.rst-content table>caption .btn.headerlink:before,.rst-content tt.download span.btn:first-child:before,.wy-menu-vertical li button.btn.toctree-expand:before{opacity:.5;-webkit-transition:opacity .05s ease-in;-moz-transition:opacity .05s ease-in;transition:opacity .05s ease-in}.btn.fa:hover:before,.btn.icon:hover:before,.rst-content .btn.admonition-title:hover:before,.rst-content .code-block-caption .btn.headerlink:hover:before,.rst-content .eqno .btn.headerlink:hover:before,.rst-content code.download span.btn:first-child:hover:before,.rst-content dl dt .btn.headerlink:hover:before,.rst-content h1 .btn.headerlink:hover:before,.rst-content h2 .btn.headerlink:hover:before,.rst-content h3 .btn.headerlink:hover:before,.rst-content h4 .btn.headerlink:hover:before,.rst-content h5 .btn.headerlink:hover:before,.rst-content h6 .btn.headerlink:hover:before,.rst-content p .btn.headerlink:hover:before,.rst-content table>caption .btn.headerlink:hover:before,.rst-content tt.download span.btn:first-child:hover:before,.wy-menu-vertical li button.btn.toctree-expand:hover:before{opacity:1}.btn-mini .fa:before,.btn-mini .icon:before,.btn-mini .rst-content .admonition-title:before,.btn-mini .rst-content .code-block-caption .headerlink:before,.btn-mini .rst-content .eqno .headerlink:before,.btn-mini .rst-content code.download span:first-child:before,.btn-mini .rst-content dl dt .headerlink:before,.btn-mini .rst-content h1 .headerlink:before,.btn-mini .rst-content h2 .headerlink:before,.btn-mini .rst-content h3 .headerlink:before,.btn-mini .rst-content h4 .headerlink:before,.btn-mini .rst-content h5 .headerlink:before,.btn-mini .rst-content h6 .headerlink:before,.btn-mini .rst-content p .headerlink:before,.btn-mini .rst-content table>caption .headerlink:before,.btn-mini .rst-content tt.download span:first-child:before,.btn-mini .wy-menu-vertical li button.toctree-expand:before,.rst-content .btn-mini .admonition-title:before,.rst-content .code-block-caption .btn-mini .headerlink:before,.rst-content .eqno .btn-mini .headerlink:before,.rst-content code.download .btn-mini span:first-child:before,.rst-content dl dt .btn-mini .headerlink:before,.rst-content h1 .btn-mini .headerlink:before,.rst-content h2 .btn-mini .headerlink:before,.rst-content h3 .btn-mini .headerlink:before,.rst-content h4 .btn-mini .headerlink:before,.rst-content h5 .btn-mini .headerlink:before,.rst-content h6 .btn-mini .headerlink:before,.rst-content p .btn-mini .headerlink:before,.rst-content table>caption .btn-mini .headerlink:before,.rst-content tt.download .btn-mini span:first-child:before,.wy-menu-vertical li .btn-mini button.toctree-expand:before{font-size:14px;vertical-align:-15%}.rst-content .admonition,.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .danger,.rst-content .error,.rst-content .hint,.rst-content .important,.rst-content .note,.rst-content .seealso,.rst-content .tip,.rst-content .warning,.wy-alert{padding:12px;line-height:24px;margin-bottom:24px;background:#e7f2fa}.rst-content .admonition-title,.wy-alert-title{font-weight:700;display:block;color:#fff;background:#6ab0de;padding:6px 12px;margin:-12px -12px 12px}.rst-content .danger,.rst-content .error,.rst-content .wy-alert-danger.admonition,.rst-content .wy-alert-danger.admonition-todo,.rst-content .wy-alert-danger.attention,.rst-content .wy-alert-danger.caution,.rst-content .wy-alert-danger.hint,.rst-content .wy-alert-danger.important,.rst-content .wy-alert-danger.note,.rst-content .wy-alert-danger.seealso,.rst-content .wy-alert-danger.tip,.rst-content .wy-alert-danger.warning,.wy-alert.wy-alert-danger{background:#fdf3f2}.rst-content .danger .admonition-title,.rst-content .danger .wy-alert-title,.rst-content .error .admonition-title,.rst-content .error .wy-alert-title,.rst-content .wy-alert-danger.admonition-todo .admonition-title,.rst-content .wy-alert-danger.admonition-todo .wy-alert-title,.rst-content .wy-alert-danger.admonition .admonition-title,.rst-content .wy-alert-danger.admonition .wy-alert-title,.rst-content .wy-alert-danger.attention .admonition-title,.rst-content .wy-alert-danger.attention .wy-alert-title,.rst-content .wy-alert-danger.caution .admonition-title,.rst-content .wy-alert-danger.caution .wy-alert-title,.rst-content .wy-alert-danger.hint .admonition-title,.rst-content .wy-alert-danger.hint .wy-alert-title,.rst-content .wy-alert-danger.important .admonition-title,.rst-content .wy-alert-danger.important .wy-alert-title,.rst-content .wy-alert-danger.note .admonition-title,.rst-content .wy-alert-danger.note .wy-alert-title,.rst-content .wy-alert-danger.seealso .admonition-title,.rst-content .wy-alert-danger.seealso .wy-alert-title,.rst-content .wy-alert-danger.tip .admonition-title,.rst-content .wy-alert-danger.tip .wy-alert-title,.rst-content .wy-alert-danger.warning .admonition-title,.rst-content .wy-alert-danger.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-danger .admonition-title,.wy-alert.wy-alert-danger .rst-content .admonition-title,.wy-alert.wy-alert-danger .wy-alert-title{background:#f29f97}.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .warning,.rst-content .wy-alert-warning.admonition,.rst-content .wy-alert-warning.danger,.rst-content .wy-alert-warning.error,.rst-content .wy-alert-warning.hint,.rst-content .wy-alert-warning.important,.rst-content .wy-alert-warning.note,.rst-content .wy-alert-warning.seealso,.rst-content .wy-alert-warning.tip,.wy-alert.wy-alert-warning{background:#ffedcc}.rst-content .admonition-todo .admonition-title,.rst-content .admonition-todo .wy-alert-title,.rst-content .attention .admonition-title,.rst-content .attention .wy-alert-title,.rst-content .caution .admonition-title,.rst-content .caution .wy-alert-title,.rst-content .warning .admonition-title,.rst-content .warning .wy-alert-title,.rst-content .wy-alert-warning.admonition .admonition-title,.rst-content .wy-alert-warning.admonition .wy-alert-title,.rst-content .wy-alert-warning.danger .admonition-title,.rst-content .wy-alert-warning.danger .wy-alert-title,.rst-content .wy-alert-warning.error .admonition-title,.rst-content .wy-alert-warning.error .wy-alert-title,.rst-content .wy-alert-warning.hint .admonition-title,.rst-content .wy-alert-warning.hint .wy-alert-title,.rst-content .wy-alert-warning.important .admonition-title,.rst-content .wy-alert-warning.important .wy-alert-title,.rst-content .wy-alert-warning.note .admonition-title,.rst-content .wy-alert-warning.note .wy-alert-title,.rst-content .wy-alert-warning.seealso .admonition-title,.rst-content .wy-alert-warning.seealso .wy-alert-title,.rst-content .wy-alert-warning.tip .admonition-title,.rst-content .wy-alert-warning.tip .wy-alert-title,.rst-content .wy-alert.wy-alert-warning .admonition-title,.wy-alert.wy-alert-warning .rst-content .admonition-title,.wy-alert.wy-alert-warning .wy-alert-title{background:#f0b37e}.rst-content .note,.rst-content .seealso,.rst-content .wy-alert-info.admonition,.rst-content .wy-alert-info.admonition-todo,.rst-content .wy-alert-info.attention,.rst-content .wy-alert-info.caution,.rst-content .wy-alert-info.danger,.rst-content .wy-alert-info.error,.rst-content .wy-alert-info.hint,.rst-content .wy-alert-info.important,.rst-content .wy-alert-info.tip,.rst-content .wy-alert-info.warning,.wy-alert.wy-alert-info{background:#e7f2fa}.rst-content .note .admonition-title,.rst-content .note .wy-alert-title,.rst-content .seealso .admonition-title,.rst-content .seealso .wy-alert-title,.rst-content .wy-alert-info.admonition-todo .admonition-title,.rst-content .wy-alert-info.admonition-todo .wy-alert-title,.rst-content .wy-alert-info.admonition .admonition-title,.rst-content .wy-alert-info.admonition .wy-alert-title,.rst-content .wy-alert-info.attention .admonition-title,.rst-content .wy-alert-info.attention .wy-alert-title,.rst-content .wy-alert-info.caution .admonition-title,.rst-content .wy-alert-info.caution .wy-alert-title,.rst-content .wy-alert-info.danger .admonition-title,.rst-content .wy-alert-info.danger .wy-alert-title,.rst-content .wy-alert-info.error .admonition-title,.rst-content .wy-alert-info.error .wy-alert-title,.rst-content .wy-alert-info.hint .admonition-title,.rst-content .wy-alert-info.hint .wy-alert-title,.rst-content .wy-alert-info.important .admonition-title,.rst-content .wy-alert-info.important .wy-alert-title,.rst-content .wy-alert-info.tip .admonition-title,.rst-content .wy-alert-info.tip .wy-alert-title,.rst-content .wy-alert-info.warning .admonition-title,.rst-content .wy-alert-info.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-info .admonition-title,.wy-alert.wy-alert-info .rst-content .admonition-title,.wy-alert.wy-alert-info .wy-alert-title{background:#6ab0de}.rst-content .hint,.rst-content .important,.rst-content .tip,.rst-content .wy-alert-success.admonition,.rst-content .wy-alert-success.admonition-todo,.rst-content .wy-alert-success.attention,.rst-content .wy-alert-success.caution,.rst-content .wy-alert-success.danger,.rst-content .wy-alert-success.error,.rst-content .wy-alert-success.note,.rst-content .wy-alert-success.seealso,.rst-content .wy-alert-success.warning,.wy-alert.wy-alert-success{background:#dbfaf4}.rst-content .hint .admonition-title,.rst-content .hint .wy-alert-title,.rst-content .important .admonition-title,.rst-content .important .wy-alert-title,.rst-content .tip .admonition-title,.rst-content .tip .wy-alert-title,.rst-content .wy-alert-success.admonition-todo .admonition-title,.rst-content .wy-alert-success.admonition-todo .wy-alert-title,.rst-content .wy-alert-success.admonition .admonition-title,.rst-content .wy-alert-success.admonition .wy-alert-title,.rst-content .wy-alert-success.attention .admonition-title,.rst-content .wy-alert-success.attention .wy-alert-title,.rst-content .wy-alert-success.caution .admonition-title,.rst-content .wy-alert-success.caution .wy-alert-title,.rst-content .wy-alert-success.danger .admonition-title,.rst-content .wy-alert-success.danger .wy-alert-title,.rst-content .wy-alert-success.error .admonition-title,.rst-content .wy-alert-success.error .wy-alert-title,.rst-content .wy-alert-success.note .admonition-title,.rst-content .wy-alert-success.note .wy-alert-title,.rst-content .wy-alert-success.seealso .admonition-title,.rst-content .wy-alert-success.seealso .wy-alert-title,.rst-content .wy-alert-success.warning .admonition-title,.rst-content .wy-alert-success.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-success .admonition-title,.wy-alert.wy-alert-success .rst-content .admonition-title,.wy-alert.wy-alert-success .wy-alert-title{background:#1abc9c}.rst-content .wy-alert-neutral.admonition,.rst-content .wy-alert-neutral.admonition-todo,.rst-content .wy-alert-neutral.attention,.rst-content .wy-alert-neutral.caution,.rst-content .wy-alert-neutral.danger,.rst-content .wy-alert-neutral.error,.rst-content .wy-alert-neutral.hint,.rst-content .wy-alert-neutral.important,.rst-content .wy-alert-neutral.note,.rst-content .wy-alert-neutral.seealso,.rst-content .wy-alert-neutral.tip,.rst-content .wy-alert-neutral.warning,.wy-alert.wy-alert-neutral{background:#f3f6f6}.rst-content .wy-alert-neutral.admonition-todo .admonition-title,.rst-content .wy-alert-neutral.admonition-todo .wy-alert-title,.rst-content .wy-alert-neutral.admonition .admonition-title,.rst-content .wy-alert-neutral.admonition .wy-alert-title,.rst-content .wy-alert-neutral.attention .admonition-title,.rst-content .wy-alert-neutral.attention .wy-alert-title,.rst-content .wy-alert-neutral.caution .admonition-title,.rst-content .wy-alert-neutral.caution .wy-alert-title,.rst-content .wy-alert-neutral.danger .admonition-title,.rst-content .wy-alert-neutral.danger .wy-alert-title,.rst-content .wy-alert-neutral.error .admonition-title,.rst-content .wy-alert-neutral.error .wy-alert-title,.rst-content .wy-alert-neutral.hint .admonition-title,.rst-content .wy-alert-neutral.hint .wy-alert-title,.rst-content .wy-alert-neutral.important .admonition-title,.rst-content .wy-alert-neutral.important .wy-alert-title,.rst-content .wy-alert-neutral.note .admonition-title,.rst-content .wy-alert-neutral.note .wy-alert-title,.rst-content .wy-alert-neutral.seealso .admonition-title,.rst-content .wy-alert-neutral.seealso .wy-alert-title,.rst-content .wy-alert-neutral.tip .admonition-title,.rst-content .wy-alert-neutral.tip .wy-alert-title,.rst-content .wy-alert-neutral.warning .admonition-title,.rst-content .wy-alert-neutral.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-neutral .admonition-title,.wy-alert.wy-alert-neutral .rst-content .admonition-title,.wy-alert.wy-alert-neutral .wy-alert-title{color:#404040;background:#e1e4e5}.rst-content .wy-alert-neutral.admonition-todo a,.rst-content .wy-alert-neutral.admonition a,.rst-content .wy-alert-neutral.attention a,.rst-content .wy-alert-neutral.caution a,.rst-content .wy-alert-neutral.danger a,.rst-content .wy-alert-neutral.error a,.rst-content .wy-alert-neutral.hint a,.rst-content .wy-alert-neutral.important a,.rst-content .wy-alert-neutral.note a,.rst-content .wy-alert-neutral.seealso a,.rst-content .wy-alert-neutral.tip a,.rst-content .wy-alert-neutral.warning a,.wy-alert.wy-alert-neutral a{color:#2980b9}.rst-content .admonition-todo p:last-child,.rst-content .admonition p:last-child,.rst-content .attention p:last-child,.rst-content .caution p:last-child,.rst-content .danger p:last-child,.rst-content .error p:last-child,.rst-content .hint p:last-child,.rst-content .important p:last-child,.rst-content .note p:last-child,.rst-content .seealso p:last-child,.rst-content .tip p:last-child,.rst-content .warning p:last-child,.wy-alert p:last-child{margin-bottom:0}.wy-tray-container{position:fixed;bottom:0;left:0;z-index:600}.wy-tray-container li{display:block;width:300px;background:transparent;color:#fff;text-align:center;box-shadow:0 5px 5px 0 rgba(0,0,0,.1);padding:0 24px;min-width:20%;opacity:0;height:0;line-height:56px;overflow:hidden;-webkit-transition:all .3s ease-in;-moz-transition:all .3s ease-in;transition:all .3s ease-in}.wy-tray-container li.wy-tray-item-success{background:#27ae60}.wy-tray-container li.wy-tray-item-info{background:#2980b9}.wy-tray-container li.wy-tray-item-warning{background:#e67e22}.wy-tray-container li.wy-tray-item-danger{background:#e74c3c}.wy-tray-container li.on{opacity:1;height:56px}@media screen and (max-width:768px){.wy-tray-container{bottom:auto;top:0;width:100%}.wy-tray-container li{width:100%}}button{font-size:100%;margin:0;vertical-align:baseline;*vertical-align:middle;cursor:pointer;line-height:normal;-webkit-appearance:button;*overflow:visible}button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0}button[disabled]{cursor:default}.btn{display:inline-block;border-radius:2px;line-height:normal;white-space:nowrap;text-align:center;cursor:pointer;font-size:100%;padding:6px 12px 8px;color:#fff;border:1px solid rgba(0,0,0,.1);background-color:#27ae60;text-decoration:none;font-weight:400;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;box-shadow:inset 0 1px 2px -1px hsla(0,0%,100%,.5),inset 0 -2px 0 0 rgba(0,0,0,.1);outline-none:false;vertical-align:middle;*display:inline;zoom:1;-webkit-user-drag:none;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none;-webkit-transition:all .1s linear;-moz-transition:all .1s linear;transition:all .1s linear}.btn-hover{background:#2e8ece;color:#fff}.btn:hover{background:#2cc36b;color:#fff}.btn:focus{background:#2cc36b;outline:0}.btn:active{box-shadow:inset 0 -1px 0 0 rgba(0,0,0,.05),inset 0 2px 0 0 rgba(0,0,0,.1);padding:8px 12px 6px}.btn:visited{color:#fff}.btn-disabled,.btn-disabled:active,.btn-disabled:focus,.btn-disabled:hover,.btn:disabled{background-image:none;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false);filter:alpha(opacity=40);opacity:.4;cursor:not-allowed;box-shadow:none}.btn::-moz-focus-inner{padding:0;border:0}.btn-small{font-size:80%}.btn-info{background-color:#2980b9!important}.btn-info:hover{background-color:#2e8ece!important}.btn-neutral{background-color:#f3f6f6!important;color:#404040!important}.btn-neutral:hover{background-color:#e5ebeb!important;color:#404040}.btn-neutral:visited{color:#404040!important}.btn-success{background-color:#27ae60!important}.btn-success:hover{background-color:#295!important}.btn-danger{background-color:#e74c3c!important}.btn-danger:hover{background-color:#ea6153!important}.btn-warning{background-color:#e67e22!important}.btn-warning:hover{background-color:#e98b39!important}.btn-invert{background-color:#222}.btn-invert:hover{background-color:#2f2f2f!important}.btn-link{background-color:transparent!important;color:#2980b9;box-shadow:none;border-color:transparent!important}.btn-link:active,.btn-link:hover{background-color:transparent!important;color:#409ad5!important;box-shadow:none}.btn-link:visited{color:#9b59b6}.wy-btn-group .btn,.wy-control .btn{vertical-align:middle}.wy-btn-group{margin-bottom:24px;*zoom:1}.wy-btn-group:after,.wy-btn-group:before{display:table;content:""}.wy-btn-group:after{clear:both}.wy-dropdown{position:relative;display:inline-block}.wy-dropdown-active .wy-dropdown-menu{display:block}.wy-dropdown-menu{position:absolute;left:0;display:none;float:left;top:100%;min-width:100%;background:#fcfcfc;z-index:100;border:1px solid #cfd7dd;box-shadow:0 2px 2px 0 rgba(0,0,0,.1);padding:12px}.wy-dropdown-menu>dd>a{display:block;clear:both;color:#404040;white-space:nowrap;font-size:90%;padding:0 12px;cursor:pointer}.wy-dropdown-menu>dd>a:hover{background:#2980b9;color:#fff}.wy-dropdown-menu>dd.divider{border-top:1px solid #cfd7dd;margin:6px 0}.wy-dropdown-menu>dd.search{padding-bottom:12px}.wy-dropdown-menu>dd.search input[type=search]{width:100%}.wy-dropdown-menu>dd.call-to-action{background:#e3e3e3;text-transform:uppercase;font-weight:500;font-size:80%}.wy-dropdown-menu>dd.call-to-action:hover{background:#e3e3e3}.wy-dropdown-menu>dd.call-to-action .btn{color:#fff}.wy-dropdown.wy-dropdown-up .wy-dropdown-menu{bottom:100%;top:auto;left:auto;right:0}.wy-dropdown.wy-dropdown-bubble .wy-dropdown-menu{background:#fcfcfc;margin-top:2px}.wy-dropdown.wy-dropdown-bubble .wy-dropdown-menu a{padding:6px 12px}.wy-dropdown.wy-dropdown-bubble .wy-dropdown-menu a:hover{background:#2980b9;color:#fff}.wy-dropdown.wy-dropdown-left .wy-dropdown-menu{right:0;left:auto;text-align:right}.wy-dropdown-arrow:before{content:" ";border-bottom:5px solid #f5f5f5;border-left:5px solid transparent;border-right:5px solid transparent;position:absolute;display:block;top:-4px;left:50%;margin-left:-3px}.wy-dropdown-arrow.wy-dropdown-arrow-left:before{left:11px}.wy-form-stacked select{display:block}.wy-form-aligned .wy-help-inline,.wy-form-aligned input,.wy-form-aligned label,.wy-form-aligned select,.wy-form-aligned textarea{display:inline-block;*display:inline;*zoom:1;vertical-align:middle}.wy-form-aligned .wy-control-group>label{display:inline-block;vertical-align:middle;width:10em;margin:6px 12px 0 0;float:left}.wy-form-aligned .wy-control{float:left}.wy-form-aligned .wy-control label{display:block}.wy-form-aligned .wy-control select{margin-top:6px}fieldset{margin:0}fieldset,legend{border:0;padding:0}legend{width:100%;white-space:normal;margin-bottom:24px;font-size:150%;*margin-left:-7px}label,legend{display:block}label{margin:0 0 .3125em;color:#333;font-size:90%}input,select,textarea{font-size:100%;margin:0;vertical-align:baseline;*vertical-align:middle}.wy-control-group{margin-bottom:24px;max-width:1200px;margin-left:auto;margin-right:auto;*zoom:1}.wy-control-group:after,.wy-control-group:before{display:table;content:""}.wy-control-group:after{clear:both}.wy-control-group.wy-control-group-required>label:after{content:" *";color:#e74c3c}.wy-control-group .wy-form-full,.wy-control-group .wy-form-halves,.wy-control-group .wy-form-thirds{padding-bottom:12px}.wy-control-group .wy-form-full input[type=color],.wy-control-group .wy-form-full input[type=date],.wy-control-group .wy-form-full input[type=datetime-local],.wy-control-group .wy-form-full input[type=datetime],.wy-control-group .wy-form-full input[type=email],.wy-control-group .wy-form-full input[type=month],.wy-control-group .wy-form-full input[type=number],.wy-control-group .wy-form-full input[type=password],.wy-control-group .wy-form-full input[type=search],.wy-control-group .wy-form-full input[type=tel],.wy-control-group .wy-form-full input[type=text],.wy-control-group .wy-form-full input[type=time],.wy-control-group .wy-form-full input[type=url],.wy-control-group .wy-form-full input[type=week],.wy-control-group .wy-form-full select,.wy-control-group .wy-form-halves input[type=color],.wy-control-group .wy-form-halves input[type=date],.wy-control-group .wy-form-halves input[type=datetime-local],.wy-control-group .wy-form-halves input[type=datetime],.wy-control-group .wy-form-halves input[type=email],.wy-control-group .wy-form-halves input[type=month],.wy-control-group .wy-form-halves input[type=number],.wy-control-group .wy-form-halves input[type=password],.wy-control-group .wy-form-halves input[type=search],.wy-control-group .wy-form-halves input[type=tel],.wy-control-group .wy-form-halves input[type=text],.wy-control-group .wy-form-halves input[type=time],.wy-control-group .wy-form-halves input[type=url],.wy-control-group .wy-form-halves input[type=week],.wy-control-group .wy-form-halves select,.wy-control-group .wy-form-thirds input[type=color],.wy-control-group .wy-form-thirds input[type=date],.wy-control-group .wy-form-thirds input[type=datetime-local],.wy-control-group .wy-form-thirds input[type=datetime],.wy-control-group .wy-form-thirds input[type=email],.wy-control-group .wy-form-thirds input[type=month],.wy-control-group .wy-form-thirds input[type=number],.wy-control-group .wy-form-thirds input[type=password],.wy-control-group .wy-form-thirds input[type=search],.wy-control-group .wy-form-thirds input[type=tel],.wy-control-group .wy-form-thirds input[type=text],.wy-control-group .wy-form-thirds input[type=time],.wy-control-group .wy-form-thirds input[type=url],.wy-control-group .wy-form-thirds input[type=week],.wy-control-group .wy-form-thirds select{width:100%}.wy-control-group .wy-form-full{float:left;display:block;width:100%;margin-right:0}.wy-control-group .wy-form-full:last-child{margin-right:0}.wy-control-group .wy-form-halves{float:left;display:block;margin-right:2.35765%;width:48.82117%}.wy-control-group .wy-form-halves:last-child,.wy-control-group .wy-form-halves:nth-of-type(2n){margin-right:0}.wy-control-group .wy-form-halves:nth-of-type(odd){clear:left}.wy-control-group .wy-form-thirds{float:left;display:block;margin-right:2.35765%;width:31.76157%}.wy-control-group .wy-form-thirds:last-child,.wy-control-group .wy-form-thirds:nth-of-type(3n){margin-right:0}.wy-control-group .wy-form-thirds:nth-of-type(3n+1){clear:left}.wy-control-group.wy-control-group-no-input .wy-control,.wy-control-no-input{margin:6px 0 0;font-size:90%}.wy-control-no-input{display:inline-block}.wy-control-group.fluid-input input[type=color],.wy-control-group.fluid-input input[type=date],.wy-control-group.fluid-input input[type=datetime-local],.wy-control-group.fluid-input input[type=datetime],.wy-control-group.fluid-input input[type=email],.wy-control-group.fluid-input input[type=month],.wy-control-group.fluid-input input[type=number],.wy-control-group.fluid-input input[type=password],.wy-control-group.fluid-input input[type=search],.wy-control-group.fluid-input input[type=tel],.wy-control-group.fluid-input input[type=text],.wy-control-group.fluid-input input[type=time],.wy-control-group.fluid-input input[type=url],.wy-control-group.fluid-input input[type=week]{width:100%}.wy-form-message-inline{padding-left:.3em;color:#666;font-size:90%}.wy-form-message{display:block;color:#999;font-size:70%;margin-top:.3125em;font-style:italic}.wy-form-message p{font-size:inherit;font-style:italic;margin-bottom:6px}.wy-form-message p:last-child{margin-bottom:0}input{line-height:normal}input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;*overflow:visible}input[type=color],input[type=date],input[type=datetime-local],input[type=datetime],input[type=email],input[type=month],input[type=number],input[type=password],input[type=search],input[type=tel],input[type=text],input[type=time],input[type=url],input[type=week]{-webkit-appearance:none;padding:6px;display:inline-block;border:1px solid #ccc;font-size:80%;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;box-shadow:inset 0 1px 3px #ddd;border-radius:0;-webkit-transition:border .3s linear;-moz-transition:border .3s linear;transition:border .3s linear}input[type=datetime-local]{padding:.34375em .625em}input[disabled]{cursor:default}input[type=checkbox],input[type=radio]{padding:0;margin-right:.3125em;*height:13px;*width:13px}input[type=checkbox],input[type=radio],input[type=search]{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}input[type=search]::-webkit-search-cancel-button,input[type=search]::-webkit-search-decoration{-webkit-appearance:none}input[type=color]:focus,input[type=date]:focus,input[type=datetime-local]:focus,input[type=datetime]:focus,input[type=email]:focus,input[type=month]:focus,input[type=number]:focus,input[type=password]:focus,input[type=search]:focus,input[type=tel]:focus,input[type=text]:focus,input[type=time]:focus,input[type=url]:focus,input[type=week]:focus{outline:0;outline:thin dotted\9;border-color:#333}input.no-focus:focus{border-color:#ccc!important}input[type=checkbox]:focus,input[type=file]:focus,input[type=radio]:focus{outline:thin dotted #333;outline:1px auto #129fea}input[type=color][disabled],input[type=date][disabled],input[type=datetime-local][disabled],input[type=datetime][disabled],input[type=email][disabled],input[type=month][disabled],input[type=number][disabled],input[type=password][disabled],input[type=search][disabled],input[type=tel][disabled],input[type=text][disabled],input[type=time][disabled],input[type=url][disabled],input[type=week][disabled]{cursor:not-allowed;background-color:#fafafa}input:focus:invalid,select:focus:invalid,textarea:focus:invalid{color:#e74c3c;border:1px solid #e74c3c}input:focus:invalid:focus,select:focus:invalid:focus,textarea:focus:invalid:focus{border-color:#e74c3c}input[type=checkbox]:focus:invalid:focus,input[type=file]:focus:invalid:focus,input[type=radio]:focus:invalid:focus{outline-color:#e74c3c}input.wy-input-large{padding:12px;font-size:100%}textarea{overflow:auto;vertical-align:top;width:100%;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif}select,textarea{padding:.5em .625em;display:inline-block;border:1px solid #ccc;font-size:80%;box-shadow:inset 0 1px 3px #ddd;-webkit-transition:border .3s linear;-moz-transition:border .3s linear;transition:border .3s linear}select{border:1px solid #ccc;background-color:#fff}select[multiple]{height:auto}select:focus,textarea:focus{outline:0}input[readonly],select[disabled],select[readonly],textarea[disabled],textarea[readonly]{cursor:not-allowed;background-color:#fafafa}input[type=checkbox][disabled],input[type=radio][disabled]{cursor:not-allowed}.wy-checkbox,.wy-radio{margin:6px 0;color:#404040;display:block}.wy-checkbox input,.wy-radio input{vertical-align:baseline}.wy-form-message-inline{display:inline-block;*display:inline;*zoom:1;vertical-align:middle}.wy-input-prefix,.wy-input-suffix{white-space:nowrap;padding:6px}.wy-input-prefix .wy-input-context,.wy-input-suffix .wy-input-context{line-height:27px;padding:0 8px;display:inline-block;font-size:80%;background-color:#f3f6f6;border:1px solid #ccc;color:#999}.wy-input-suffix .wy-input-context{border-left:0}.wy-input-prefix .wy-input-context{border-right:0}.wy-switch{position:relative;display:block;height:24px;margin-top:12px;cursor:pointer}.wy-switch:before{left:0;top:0;width:36px;height:12px;background:#ccc}.wy-switch:after,.wy-switch:before{position:absolute;content:"";display:block;border-radius:4px;-webkit-transition:all .2s ease-in-out;-moz-transition:all .2s ease-in-out;transition:all .2s ease-in-out}.wy-switch:after{width:18px;height:18px;background:#999;left:-3px;top:-3px}.wy-switch span{position:absolute;left:48px;display:block;font-size:12px;color:#ccc;line-height:1}.wy-switch.active:before{background:#1e8449}.wy-switch.active:after{left:24px;background:#27ae60}.wy-switch.disabled{cursor:not-allowed;opacity:.8}.wy-control-group.wy-control-group-error .wy-form-message,.wy-control-group.wy-control-group-error>label{color:#e74c3c}.wy-control-group.wy-control-group-error input[type=color],.wy-control-group.wy-control-group-error input[type=date],.wy-control-group.wy-control-group-error input[type=datetime-local],.wy-control-group.wy-control-group-error input[type=datetime],.wy-control-group.wy-control-group-error input[type=email],.wy-control-group.wy-control-group-error input[type=month],.wy-control-group.wy-control-group-error input[type=number],.wy-control-group.wy-control-group-error input[type=password],.wy-control-group.wy-control-group-error input[type=search],.wy-control-group.wy-control-group-error input[type=tel],.wy-control-group.wy-control-group-error input[type=text],.wy-control-group.wy-control-group-error input[type=time],.wy-control-group.wy-control-group-error input[type=url],.wy-control-group.wy-control-group-error input[type=week],.wy-control-group.wy-control-group-error textarea{border:1px solid #e74c3c}.wy-inline-validate{white-space:nowrap}.wy-inline-validate .wy-input-context{padding:.5em .625em;display:inline-block;font-size:80%}.wy-inline-validate.wy-inline-validate-success .wy-input-context{color:#27ae60}.wy-inline-validate.wy-inline-validate-danger .wy-input-context{color:#e74c3c}.wy-inline-validate.wy-inline-validate-warning .wy-input-context{color:#e67e22}.wy-inline-validate.wy-inline-validate-info .wy-input-context{color:#2980b9}.rotate-90{-webkit-transform:rotate(90deg);-moz-transform:rotate(90deg);-ms-transform:rotate(90deg);-o-transform:rotate(90deg);transform:rotate(90deg)}.rotate-180{-webkit-transform:rotate(180deg);-moz-transform:rotate(180deg);-ms-transform:rotate(180deg);-o-transform:rotate(180deg);transform:rotate(180deg)}.rotate-270{-webkit-transform:rotate(270deg);-moz-transform:rotate(270deg);-ms-transform:rotate(270deg);-o-transform:rotate(270deg);transform:rotate(270deg)}.mirror{-webkit-transform:scaleX(-1);-moz-transform:scaleX(-1);-ms-transform:scaleX(-1);-o-transform:scaleX(-1);transform:scaleX(-1)}.mirror.rotate-90{-webkit-transform:scaleX(-1) rotate(90deg);-moz-transform:scaleX(-1) rotate(90deg);-ms-transform:scaleX(-1) rotate(90deg);-o-transform:scaleX(-1) rotate(90deg);transform:scaleX(-1) rotate(90deg)}.mirror.rotate-180{-webkit-transform:scaleX(-1) rotate(180deg);-moz-transform:scaleX(-1) rotate(180deg);-ms-transform:scaleX(-1) rotate(180deg);-o-transform:scaleX(-1) rotate(180deg);transform:scaleX(-1) rotate(180deg)}.mirror.rotate-270{-webkit-transform:scaleX(-1) rotate(270deg);-moz-transform:scaleX(-1) rotate(270deg);-ms-transform:scaleX(-1) rotate(270deg);-o-transform:scaleX(-1) rotate(270deg);transform:scaleX(-1) rotate(270deg)}@media only screen and (max-width:480px){.wy-form button[type=submit]{margin:.7em 0 0}.wy-form input[type=color],.wy-form input[type=date],.wy-form input[type=datetime-local],.wy-form input[type=datetime],.wy-form input[type=email],.wy-form input[type=month],.wy-form input[type=number],.wy-form input[type=password],.wy-form input[type=search],.wy-form input[type=tel],.wy-form input[type=text],.wy-form input[type=time],.wy-form input[type=url],.wy-form input[type=week],.wy-form label{margin-bottom:.3em;display:block}.wy-form input[type=color],.wy-form input[type=date],.wy-form input[type=datetime-local],.wy-form input[type=datetime],.wy-form input[type=email],.wy-form input[type=month],.wy-form input[type=number],.wy-form input[type=password],.wy-form input[type=search],.wy-form input[type=tel],.wy-form input[type=time],.wy-form input[type=url],.wy-form input[type=week]{margin-bottom:0}.wy-form-aligned .wy-control-group label{margin-bottom:.3em;text-align:left;display:block;width:100%}.wy-form-aligned .wy-control{margin:1.5em 0 0}.wy-form-message,.wy-form-message-inline,.wy-form .wy-help-inline{display:block;font-size:80%;padding:6px 0}}@media screen and (max-width:768px){.tablet-hide{display:none}}@media screen and (max-width:480px){.mobile-hide{display:none}}.float-left{float:left}.float-right{float:right}.full-width{width:100%}.rst-content table.docutils,.rst-content table.field-list,.wy-table{border-collapse:collapse;border-spacing:0;empty-cells:show;margin-bottom:24px}.rst-content table.docutils caption,.rst-content table.field-list caption,.wy-table caption{color:#000;font:italic 85%/1 arial,sans-serif;padding:1em 0;text-align:center}.rst-content table.docutils td,.rst-content table.docutils th,.rst-content table.field-list td,.rst-content table.field-list th,.wy-table td,.wy-table th{font-size:90%;margin:0;overflow:visible;padding:8px 16px}.rst-content table.docutils td:first-child,.rst-content table.docutils th:first-child,.rst-content table.field-list td:first-child,.rst-content table.field-list th:first-child,.wy-table td:first-child,.wy-table th:first-child{border-left-width:0}.rst-content table.docutils thead,.rst-content table.field-list thead,.wy-table thead{color:#000;text-align:left;vertical-align:bottom;white-space:nowrap}.rst-content table.docutils thead th,.rst-content table.field-list thead th,.wy-table thead th{font-weight:700;border-bottom:2px solid #e1e4e5}.rst-content table.docutils td,.rst-content table.field-list td,.wy-table td{background-color:transparent;vertical-align:middle}.rst-content table.docutils td p,.rst-content table.field-list td p,.wy-table td p{line-height:18px}.rst-content table.docutils td p:last-child,.rst-content table.field-list td p:last-child,.wy-table td p:last-child{margin-bottom:0}.rst-content table.docutils .wy-table-cell-min,.rst-content table.field-list .wy-table-cell-min,.wy-table .wy-table-cell-min{width:1%;padding-right:0}.rst-content table.docutils .wy-table-cell-min input[type=checkbox],.rst-content table.field-list .wy-table-cell-min input[type=checkbox],.wy-table .wy-table-cell-min input[type=checkbox]{margin:0}.wy-table-secondary{color:grey;font-size:90%}.wy-table-tertiary{color:grey;font-size:80%}.rst-content table.docutils:not(.field-list) tr:nth-child(2n-1) td,.wy-table-backed,.wy-table-odd td,.wy-table-striped tr:nth-child(2n-1) td{background-color:#f3f6f6}.rst-content table.docutils,.wy-table-bordered-all{border:1px solid #e1e4e5}.rst-content table.docutils td,.wy-table-bordered-all td{border-bottom:1px solid #e1e4e5;border-left:1px solid #e1e4e5}.rst-content table.docutils tbody>tr:last-child td,.wy-table-bordered-all tbody>tr:last-child td{border-bottom-width:0}.wy-table-bordered{border:1px solid #e1e4e5}.wy-table-bordered-rows td{border-bottom:1px solid #e1e4e5}.wy-table-bordered-rows tbody>tr:last-child td{border-bottom-width:0}.wy-table-horizontal td,.wy-table-horizontal th{border-width:0 0 1px;border-bottom:1px solid #e1e4e5}.wy-table-horizontal tbody>tr:last-child td{border-bottom-width:0}.wy-table-responsive{margin-bottom:24px;max-width:100%;overflow:auto}.wy-table-responsive table{margin-bottom:0!important}.wy-table-responsive table td,.wy-table-responsive table th{white-space:nowrap}a{color:#2980b9;text-decoration:none;cursor:pointer}a:hover{color:#3091d1}a:visited{color:#9b59b6}html{height:100%}body,html{overflow-x:hidden}body{font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;font-weight:400;color:#404040;min-height:100%;background:#edf0f2}.wy-text-left{text-align:left}.wy-text-center{text-align:center}.wy-text-right{text-align:right}.wy-text-large{font-size:120%}.wy-text-normal{font-size:100%}.wy-text-small,small{font-size:80%}.wy-text-strike{text-decoration:line-through}.wy-text-warning{color:#e67e22!important}a.wy-text-warning:hover{color:#eb9950!important}.wy-text-info{color:#2980b9!important}a.wy-text-info:hover{color:#409ad5!important}.wy-text-success{color:#27ae60!important}a.wy-text-success:hover{color:#36d278!important}.wy-text-danger{color:#e74c3c!important}a.wy-text-danger:hover{color:#ed7669!important}.wy-text-neutral{color:#404040!important}a.wy-text-neutral:hover{color:#595959!important}.rst-content .toctree-wrapper>p.caption,h1,h2,h3,h4,h5,h6,legend{margin-top:0;font-weight:700;font-family:Roboto Slab,ff-tisa-web-pro,Georgia,Arial,sans-serif}p{line-height:24px;font-size:16px;margin:0 0 24px}h1{font-size:175%}.rst-content .toctree-wrapper>p.caption,h2{font-size:150%}h3{font-size:125%}h4{font-size:115%}h5{font-size:110%}h6{font-size:100%}hr{display:block;height:1px;border:0;border-top:1px solid #e1e4e5;margin:24px 0;padding:0}.rst-content code,.rst-content tt,code{white-space:nowrap;max-width:100%;background:#fff;border:1px solid #e1e4e5;font-size:75%;padding:0 5px;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;color:#e74c3c;overflow-x:auto}.rst-content tt.code-large,code.code-large{font-size:90%}.rst-content .section ul,.rst-content .toctree-wrapper ul,.rst-content section ul,.wy-plain-list-disc,article ul{list-style:disc;line-height:24px;margin-bottom:24px}.rst-content .section ul li,.rst-content .toctree-wrapper ul li,.rst-content section ul li,.wy-plain-list-disc li,article ul li{list-style:disc;margin-left:24px}.rst-content .section ul li p:last-child,.rst-content .section ul li ul,.rst-content .toctree-wrapper ul li p:last-child,.rst-content .toctree-wrapper ul li ul,.rst-content section ul li p:last-child,.rst-content section ul li ul,.wy-plain-list-disc li p:last-child,.wy-plain-list-disc li ul,article ul li p:last-child,article ul li ul{margin-bottom:0}.rst-content .section ul li li,.rst-content .toctree-wrapper ul li li,.rst-content section ul li li,.wy-plain-list-disc li li,article ul li li{list-style:circle}.rst-content .section ul li li li,.rst-content .toctree-wrapper ul li li li,.rst-content section ul li li li,.wy-plain-list-disc li li li,article ul li li li{list-style:square}.rst-content .section ul li ol li,.rst-content .toctree-wrapper ul li ol li,.rst-content section ul li ol li,.wy-plain-list-disc li ol li,article ul li ol li{list-style:decimal}.rst-content .section ol,.rst-content .section ol.arabic,.rst-content .toctree-wrapper ol,.rst-content .toctree-wrapper ol.arabic,.rst-content section ol,.rst-content section ol.arabic,.wy-plain-list-decimal,article ol{list-style:decimal;line-height:24px;margin-bottom:24px}.rst-content .section ol.arabic li,.rst-content .section ol li,.rst-content .toctree-wrapper ol.arabic li,.rst-content .toctree-wrapper ol li,.rst-content section ol.arabic li,.rst-content section ol li,.wy-plain-list-decimal li,article ol li{list-style:decimal;margin-left:24px}.rst-content .section ol.arabic li ul,.rst-content .section ol li p:last-child,.rst-content .section ol li ul,.rst-content .toctree-wrapper ol.arabic li ul,.rst-content .toctree-wrapper ol li p:last-child,.rst-content .toctree-wrapper ol li ul,.rst-content section ol.arabic li ul,.rst-content section ol li p:last-child,.rst-content section ol li ul,.wy-plain-list-decimal li p:last-child,.wy-plain-list-decimal li ul,article ol li p:last-child,article ol li ul{margin-bottom:0}.rst-content .section ol.arabic li ul li,.rst-content .section ol li ul li,.rst-content .toctree-wrapper ol.arabic li ul li,.rst-content .toctree-wrapper ol li ul li,.rst-content section ol.arabic li ul li,.rst-content section ol li ul li,.wy-plain-list-decimal li ul li,article ol li ul li{list-style:disc}.wy-breadcrumbs{*zoom:1}.wy-breadcrumbs:after,.wy-breadcrumbs:before{display:table;content:""}.wy-breadcrumbs:after{clear:both}.wy-breadcrumbs>li{display:inline-block;padding-top:5px}.wy-breadcrumbs>li.wy-breadcrumbs-aside{float:right}.rst-content .wy-breadcrumbs>li code,.rst-content .wy-breadcrumbs>li tt,.wy-breadcrumbs>li .rst-content tt,.wy-breadcrumbs>li code{all:inherit;color:inherit}.breadcrumb-item:before{content:"/";color:#bbb;font-size:13px;padding:0 6px 0 3px}.wy-breadcrumbs-extra{margin-bottom:0;color:#b3b3b3;font-size:80%;display:inline-block}@media screen and (max-width:480px){.wy-breadcrumbs-extra,.wy-breadcrumbs li.wy-breadcrumbs-aside{display:none}}@media print{.wy-breadcrumbs li.wy-breadcrumbs-aside{display:none}}html{font-size:16px}.wy-affix{position:fixed;top:1.618em}.wy-menu a:hover{text-decoration:none}.wy-menu-horiz{*zoom:1}.wy-menu-horiz:after,.wy-menu-horiz:before{display:table;content:""}.wy-menu-horiz:after{clear:both}.wy-menu-horiz li,.wy-menu-horiz ul{display:inline-block}.wy-menu-horiz li:hover{background:hsla(0,0%,100%,.1)}.wy-menu-horiz li.divide-left{border-left:1px solid #404040}.wy-menu-horiz li.divide-right{border-right:1px solid #404040}.wy-menu-horiz a{height:32px;display:inline-block;line-height:32px;padding:0 16px}.wy-menu-vertical{width:300px}.wy-menu-vertical header,.wy-menu-vertical p.caption{color:#55a5d9;height:32px;line-height:32px;padding:0 1.618em;margin:12px 0 0;display:block;font-weight:700;text-transform:uppercase;font-size:85%;white-space:nowrap}.wy-menu-vertical ul{margin-bottom:0}.wy-menu-vertical li.divide-top{border-top:1px solid #404040}.wy-menu-vertical li.divide-bottom{border-bottom:1px solid #404040}.wy-menu-vertical li.current{background:#e3e3e3}.wy-menu-vertical li.current a{color:grey;border-right:1px solid #c9c9c9;padding:.4045em 2.427em}.wy-menu-vertical li.current a:hover{background:#d6d6d6}.rst-content .wy-menu-vertical li tt,.wy-menu-vertical li .rst-content tt,.wy-menu-vertical li code{border:none;background:inherit;color:inherit;padding-left:0;padding-right:0}.wy-menu-vertical li button.toctree-expand{display:block;float:left;margin-left:-1.2em;line-height:18px;color:#4d4d4d;border:none;background:none;padding:0}.wy-menu-vertical li.current>a,.wy-menu-vertical li.on a{color:#404040;font-weight:700;position:relative;background:#fcfcfc;border:none;padding:.4045em 1.618em}.wy-menu-vertical li.current>a:hover,.wy-menu-vertical li.on a:hover{background:#fcfcfc}.wy-menu-vertical li.current>a:hover button.toctree-expand,.wy-menu-vertical li.on a:hover button.toctree-expand{color:grey}.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand{display:block;line-height:18px;color:#333}.wy-menu-vertical li.toctree-l1.current>a{border-bottom:1px solid #c9c9c9;border-top:1px solid #c9c9c9}.wy-menu-vertical .toctree-l1.current .toctree-l2>ul,.wy-menu-vertical .toctree-l2.current .toctree-l3>ul,.wy-menu-vertical .toctree-l3.current .toctree-l4>ul,.wy-menu-vertical .toctree-l4.current .toctree-l5>ul,.wy-menu-vertical .toctree-l5.current .toctree-l6>ul,.wy-menu-vertical .toctree-l6.current .toctree-l7>ul,.wy-menu-vertical .toctree-l7.current .toctree-l8>ul,.wy-menu-vertical .toctree-l8.current .toctree-l9>ul,.wy-menu-vertical .toctree-l9.current .toctree-l10>ul,.wy-menu-vertical .toctree-l10.current .toctree-l11>ul{display:none}.wy-menu-vertical .toctree-l1.current .current.toctree-l2>ul,.wy-menu-vertical .toctree-l2.current .current.toctree-l3>ul,.wy-menu-vertical .toctree-l3.current .current.toctree-l4>ul,.wy-menu-vertical .toctree-l4.current .current.toctree-l5>ul,.wy-menu-vertical .toctree-l5.current .current.toctree-l6>ul,.wy-menu-vertical .toctree-l6.current .current.toctree-l7>ul,.wy-menu-vertical .toctree-l7.current .current.toctree-l8>ul,.wy-menu-vertical .toctree-l8.current .current.toctree-l9>ul,.wy-menu-vertical .toctree-l9.current .current.toctree-l10>ul,.wy-menu-vertical .toctree-l10.current .current.toctree-l11>ul{display:block}.wy-menu-vertical li.toctree-l3,.wy-menu-vertical li.toctree-l4{font-size:.9em}.wy-menu-vertical li.toctree-l2 a,.wy-menu-vertical li.toctree-l3 a,.wy-menu-vertical li.toctree-l4 a,.wy-menu-vertical li.toctree-l5 a,.wy-menu-vertical li.toctree-l6 a,.wy-menu-vertical li.toctree-l7 a,.wy-menu-vertical li.toctree-l8 a,.wy-menu-vertical li.toctree-l9 a,.wy-menu-vertical li.toctree-l10 a{color:#404040}.wy-menu-vertical li.toctree-l2 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l3 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l4 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l5 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l6 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l7 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l8 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l9 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l10 a:hover button.toctree-expand{color:grey}.wy-menu-vertical li.toctree-l2.current li.toctree-l3>a,.wy-menu-vertical li.toctree-l3.current li.toctree-l4>a,.wy-menu-vertical li.toctree-l4.current li.toctree-l5>a,.wy-menu-vertical li.toctree-l5.current li.toctree-l6>a,.wy-menu-vertical li.toctree-l6.current li.toctree-l7>a,.wy-menu-vertical li.toctree-l7.current li.toctree-l8>a,.wy-menu-vertical li.toctree-l8.current li.toctree-l9>a,.wy-menu-vertical li.toctree-l9.current li.toctree-l10>a,.wy-menu-vertical li.toctree-l10.current li.toctree-l11>a{display:block}.wy-menu-vertical li.toctree-l2.current>a{padding:.4045em 2.427em}.wy-menu-vertical li.toctree-l2.current li.toctree-l3>a{padding:.4045em 1.618em .4045em 4.045em}.wy-menu-vertical li.toctree-l3.current>a{padding:.4045em 4.045em}.wy-menu-vertical li.toctree-l3.current li.toctree-l4>a{padding:.4045em 1.618em .4045em 5.663em}.wy-menu-vertical li.toctree-l4.current>a{padding:.4045em 5.663em}.wy-menu-vertical li.toctree-l4.current li.toctree-l5>a{padding:.4045em 1.618em .4045em 7.281em}.wy-menu-vertical li.toctree-l5.current>a{padding:.4045em 7.281em}.wy-menu-vertical li.toctree-l5.current li.toctree-l6>a{padding:.4045em 1.618em .4045em 8.899em}.wy-menu-vertical li.toctree-l6.current>a{padding:.4045em 8.899em}.wy-menu-vertical li.toctree-l6.current li.toctree-l7>a{padding:.4045em 1.618em .4045em 10.517em}.wy-menu-vertical li.toctree-l7.current>a{padding:.4045em 10.517em}.wy-menu-vertical li.toctree-l7.current li.toctree-l8>a{padding:.4045em 1.618em .4045em 12.135em}.wy-menu-vertical li.toctree-l8.current>a{padding:.4045em 12.135em}.wy-menu-vertical li.toctree-l8.current li.toctree-l9>a{padding:.4045em 1.618em .4045em 13.753em}.wy-menu-vertical li.toctree-l9.current>a{padding:.4045em 13.753em}.wy-menu-vertical li.toctree-l9.current li.toctree-l10>a{padding:.4045em 1.618em .4045em 15.371em}.wy-menu-vertical li.toctree-l10.current>a{padding:.4045em 15.371em}.wy-menu-vertical li.toctree-l10.current li.toctree-l11>a{padding:.4045em 1.618em .4045em 16.989em}.wy-menu-vertical li.toctree-l2.current>a,.wy-menu-vertical li.toctree-l2.current li.toctree-l3>a{background:#c9c9c9}.wy-menu-vertical li.toctree-l2 button.toctree-expand{color:#a3a3a3}.wy-menu-vertical li.toctree-l3.current>a,.wy-menu-vertical li.toctree-l3.current li.toctree-l4>a{background:#bdbdbd}.wy-menu-vertical li.toctree-l3 button.toctree-expand{color:#969696}.wy-menu-vertical li.current ul{display:block}.wy-menu-vertical li ul{margin-bottom:0;display:none}.wy-menu-vertical li ul li a{margin-bottom:0;color:#d9d9d9;font-weight:400}.wy-menu-vertical a{line-height:18px;padding:.4045em 1.618em;display:block;position:relative;font-size:90%;color:#d9d9d9}.wy-menu-vertical a:hover{background-color:#4e4a4a;cursor:pointer}.wy-menu-vertical a:hover button.toctree-expand{color:#d9d9d9}.wy-menu-vertical a:active{background-color:#2980b9;cursor:pointer;color:#fff}.wy-menu-vertical a:active button.toctree-expand{color:#fff}.wy-side-nav-search{display:block;width:300px;padding:.809em;margin-bottom:.809em;z-index:200;background-color:#2980b9;text-align:center;color:#fcfcfc}.wy-side-nav-search input[type=text]{width:100%;border-radius:50px;padding:6px 12px;border-color:#2472a4}.wy-side-nav-search img{display:block;margin:auto auto .809em;height:45px;width:45px;background-color:#2980b9;padding:5px;border-radius:100%}.wy-side-nav-search .wy-dropdown>a,.wy-side-nav-search>a{color:#fcfcfc;font-size:100%;font-weight:700;display:inline-block;padding:4px 6px;margin-bottom:.809em;max-width:100%}.wy-side-nav-search .wy-dropdown>a:hover,.wy-side-nav-search>a:hover{background:hsla(0,0%,100%,.1)}.wy-side-nav-search .wy-dropdown>a img.logo,.wy-side-nav-search>a img.logo{display:block;margin:0 auto;height:auto;width:auto;border-radius:0;max-width:100%;background:transparent}.wy-side-nav-search .wy-dropdown>a.icon img.logo,.wy-side-nav-search>a.icon img.logo{margin-top:.85em}.wy-side-nav-search>div.version{margin-top:-.4045em;margin-bottom:.809em;font-weight:400;color:hsla(0,0%,100%,.3)}.wy-nav .wy-menu-vertical header{color:#2980b9}.wy-nav .wy-menu-vertical a{color:#b3b3b3}.wy-nav .wy-menu-vertical a:hover{background-color:#2980b9;color:#fff}[data-menu-wrap]{-webkit-transition:all .2s ease-in;-moz-transition:all .2s ease-in;transition:all .2s ease-in;position:absolute;opacity:1;width:100%;opacity:0}[data-menu-wrap].move-center{left:0;right:auto;opacity:1}[data-menu-wrap].move-left{right:auto;left:-100%;opacity:0}[data-menu-wrap].move-right{right:-100%;left:auto;opacity:0}.wy-body-for-nav{background:#fcfcfc}.wy-grid-for-nav{position:absolute;width:100%;height:100%}.wy-nav-side{position:fixed;top:0;bottom:0;left:0;padding-bottom:2em;width:300px;overflow-x:hidden;overflow-y:hidden;min-height:100%;color:#9b9b9b;background:#343131;z-index:200}.wy-side-scroll{width:320px;position:relative;overflow-x:hidden;overflow-y:scroll;height:100%}.wy-nav-top{display:none;background:#2980b9;color:#fff;padding:.4045em .809em;position:relative;line-height:50px;text-align:center;font-size:100%;*zoom:1}.wy-nav-top:after,.wy-nav-top:before{display:table;content:""}.wy-nav-top:after{clear:both}.wy-nav-top a{color:#fff;font-weight:700}.wy-nav-top img{margin-right:12px;height:45px;width:45px;background-color:#2980b9;padding:5px;border-radius:100%}.wy-nav-top i{font-size:30px;float:left;cursor:pointer;padding-top:inherit}.wy-nav-content-wrap{margin-left:300px;background:#fcfcfc;min-height:100%}.wy-nav-content{padding:1.618em 3.236em;height:100%;max-width:800px;margin:auto}.wy-body-mask{position:fixed;width:100%;height:100%;background:rgba(0,0,0,.2);display:none;z-index:499}.wy-body-mask.on{display:block}footer{color:grey}footer p{margin-bottom:12px}.rst-content footer span.commit tt,footer span.commit .rst-content tt,footer span.commit code{padding:0;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;font-size:1em;background:none;border:none;color:grey}.rst-footer-buttons{*zoom:1}.rst-footer-buttons:after,.rst-footer-buttons:before{width:100%;display:table;content:""}.rst-footer-buttons:after{clear:both}.rst-breadcrumbs-buttons{margin-top:12px;*zoom:1}.rst-breadcrumbs-buttons:after,.rst-breadcrumbs-buttons:before{display:table;content:""}.rst-breadcrumbs-buttons:after{clear:both}#search-results .search li{margin-bottom:24px;border-bottom:1px solid #e1e4e5;padding-bottom:24px}#search-results .search li:first-child{border-top:1px solid #e1e4e5;padding-top:24px}#search-results .search li a{font-size:120%;margin-bottom:12px;display:inline-block}#search-results .context{color:grey;font-size:90%}.genindextable li>ul{margin-left:24px}@media screen and (max-width:768px){.wy-body-for-nav{background:#fcfcfc}.wy-nav-top{display:block}.wy-nav-side{left:-300px}.wy-nav-side.shift{width:85%;left:0}.wy-menu.wy-menu-vertical,.wy-side-nav-search,.wy-side-scroll{width:auto}.wy-nav-content-wrap{margin-left:0}.wy-nav-content-wrap .wy-nav-content{padding:1.618em}.wy-nav-content-wrap.shift{position:fixed;min-width:100%;left:85%;top:0;height:100%;overflow:hidden}}@media screen and (min-width:1100px){.wy-nav-content-wrap{background:rgba(0,0,0,.05)}.wy-nav-content{margin:0;background:#fcfcfc}}@media print{.rst-versions,.wy-nav-side,footer{display:none}.wy-nav-content-wrap{margin-left:0}}.rst-versions{position:fixed;bottom:0;left:0;width:300px;color:#fcfcfc;background:#1f1d1d;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;z-index:400}.rst-versions a{color:#2980b9;text-decoration:none}.rst-versions .rst-badge-small{display:none}.rst-versions .rst-current-version{padding:12px;background-color:#272525;display:block;text-align:right;font-size:90%;cursor:pointer;color:#27ae60;*zoom:1}.rst-versions .rst-current-version:after,.rst-versions .rst-current-version:before{display:table;content:""}.rst-versions .rst-current-version:after{clear:both}.rst-content .code-block-caption .rst-versions .rst-current-version .headerlink,.rst-content .eqno .rst-versions .rst-current-version .headerlink,.rst-content .rst-versions .rst-current-version .admonition-title,.rst-content code.download .rst-versions .rst-current-version span:first-child,.rst-content dl dt .rst-versions .rst-current-version .headerlink,.rst-content h1 .rst-versions .rst-current-version .headerlink,.rst-content h2 .rst-versions .rst-current-version .headerlink,.rst-content h3 .rst-versions .rst-current-version .headerlink,.rst-content h4 .rst-versions .rst-current-version .headerlink,.rst-content h5 .rst-versions .rst-current-version .headerlink,.rst-content h6 .rst-versions .rst-current-version .headerlink,.rst-content p .rst-versions .rst-current-version .headerlink,.rst-content table>caption .rst-versions .rst-current-version .headerlink,.rst-content tt.download .rst-versions .rst-current-version span:first-child,.rst-versions .rst-current-version .fa,.rst-versions .rst-current-version .icon,.rst-versions .rst-current-version .rst-content .admonition-title,.rst-versions .rst-current-version .rst-content .code-block-caption .headerlink,.rst-versions .rst-current-version .rst-content .eqno .headerlink,.rst-versions .rst-current-version .rst-content code.download span:first-child,.rst-versions .rst-current-version .rst-content dl dt .headerlink,.rst-versions .rst-current-version .rst-content h1 .headerlink,.rst-versions .rst-current-version .rst-content h2 .headerlink,.rst-versions .rst-current-version .rst-content h3 .headerlink,.rst-versions .rst-current-version .rst-content h4 .headerlink,.rst-versions .rst-current-version .rst-content h5 .headerlink,.rst-versions .rst-current-version .rst-content h6 .headerlink,.rst-versions .rst-current-version .rst-content p .headerlink,.rst-versions .rst-current-version .rst-content table>caption .headerlink,.rst-versions .rst-current-version .rst-content tt.download span:first-child,.rst-versions .rst-current-version .wy-menu-vertical li button.toctree-expand,.wy-menu-vertical li .rst-versions .rst-current-version button.toctree-expand{color:#fcfcfc}.rst-versions .rst-current-version .fa-book,.rst-versions .rst-current-version .icon-book{float:left}.rst-versions .rst-current-version.rst-out-of-date{background-color:#e74c3c;color:#fff}.rst-versions .rst-current-version.rst-active-old-version{background-color:#f1c40f;color:#000}.rst-versions.shift-up{height:auto;max-height:100%;overflow-y:scroll}.rst-versions.shift-up .rst-other-versions{display:block}.rst-versions .rst-other-versions{font-size:90%;padding:12px;color:grey;display:none}.rst-versions .rst-other-versions hr{display:block;height:1px;border:0;margin:20px 0;padding:0;border-top:1px solid #413d3d}.rst-versions .rst-other-versions dd{display:inline-block;margin:0}.rst-versions .rst-other-versions dd a{display:inline-block;padding:6px;color:#fcfcfc}.rst-versions.rst-badge{width:auto;bottom:20px;right:20px;left:auto;border:none;max-width:300px;max-height:90%}.rst-versions.rst-badge .fa-book,.rst-versions.rst-badge .icon-book{float:none;line-height:30px}.rst-versions.rst-badge.shift-up .rst-current-version{text-align:right}.rst-versions.rst-badge.shift-up .rst-current-version .fa-book,.rst-versions.rst-badge.shift-up .rst-current-version .icon-book{float:left}.rst-versions.rst-badge>.rst-current-version{width:auto;height:30px;line-height:30px;padding:0 6px;display:block;text-align:center}@media screen and (max-width:768px){.rst-versions{width:85%;display:none}.rst-versions.shift{display:block}}.rst-content .toctree-wrapper>p.caption,.rst-content h1,.rst-content h2,.rst-content h3,.rst-content h4,.rst-content h5,.rst-content h6{margin-bottom:24px}.rst-content img{max-width:100%;height:auto}.rst-content div.figure,.rst-content figure{margin-bottom:24px}.rst-content div.figure .caption-text,.rst-content figure .caption-text{font-style:italic}.rst-content div.figure p:last-child.caption,.rst-content figure p:last-child.caption{margin-bottom:0}.rst-content div.figure.align-center,.rst-content figure.align-center{text-align:center}.rst-content .section>a>img,.rst-content .section>img,.rst-content section>a>img,.rst-content section>img{margin-bottom:24px}.rst-content abbr[title]{text-decoration:none}.rst-content.style-external-links a.reference.external:after{font-family:FontAwesome;content:"\f08e";color:#b3b3b3;vertical-align:super;font-size:60%;margin:0 .2em}.rst-content blockquote{margin-left:24px;line-height:24px;margin-bottom:24px}.rst-content pre.literal-block{white-space:pre;margin:0;padding:12px;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;display:block;overflow:auto}.rst-content div[class^=highlight],.rst-content pre.literal-block{border:1px solid #e1e4e5;overflow-x:auto;margin:1px 0 24px}.rst-content div[class^=highlight] div[class^=highlight],.rst-content pre.literal-block div[class^=highlight]{padding:0;border:none;margin:0}.rst-content div[class^=highlight] td.code{width:100%}.rst-content .linenodiv pre{border-right:1px solid #e6e9ea;margin:0;padding:12px;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;user-select:none;pointer-events:none}.rst-content div[class^=highlight] pre{white-space:pre;margin:0;padding:12px;display:block;overflow:auto}.rst-content div[class^=highlight] pre .hll{display:block;margin:0 -12px;padding:0 12px}.rst-content .linenodiv pre,.rst-content div[class^=highlight] pre,.rst-content pre.literal-block{font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;font-size:12px;line-height:1.4}.rst-content div.highlight .gp,.rst-content div.highlight span.linenos{user-select:none;pointer-events:none}.rst-content div.highlight span.linenos{display:inline-block;padding-left:0;padding-right:12px;margin-right:12px;border-right:1px solid #e6e9ea}.rst-content .code-block-caption{font-style:italic;font-size:85%;line-height:1;padding:1em 0;text-align:center}@media print{.rst-content .codeblock,.rst-content div[class^=highlight],.rst-content div[class^=highlight] pre{white-space:pre-wrap}}.rst-content .admonition,.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .danger,.rst-content .error,.rst-content .hint,.rst-content .important,.rst-content .note,.rst-content .seealso,.rst-content .tip,.rst-content .warning{clear:both}.rst-content .admonition-todo .last,.rst-content .admonition-todo>:last-child,.rst-content .admonition .last,.rst-content .admonition>:last-child,.rst-content .attention .last,.rst-content .attention>:last-child,.rst-content .caution .last,.rst-content .caution>:last-child,.rst-content .danger .last,.rst-content .danger>:last-child,.rst-content .error .last,.rst-content .error>:last-child,.rst-content .hint .last,.rst-content .hint>:last-child,.rst-content .important .last,.rst-content .important>:last-child,.rst-content .note .last,.rst-content .note>:last-child,.rst-content .seealso .last,.rst-content .seealso>:last-child,.rst-content .tip .last,.rst-content .tip>:last-child,.rst-content .warning .last,.rst-content .warning>:last-child{margin-bottom:0}.rst-content .admonition-title:before{margin-right:4px}.rst-content .admonition table{border-color:rgba(0,0,0,.1)}.rst-content .admonition table td,.rst-content .admonition table th{background:transparent!important;border-color:rgba(0,0,0,.1)!important}.rst-content .section ol.loweralpha,.rst-content .section ol.loweralpha>li,.rst-content .toctree-wrapper ol.loweralpha,.rst-content .toctree-wrapper ol.loweralpha>li,.rst-content section ol.loweralpha,.rst-content section ol.loweralpha>li{list-style:lower-alpha}.rst-content .section ol.upperalpha,.rst-content .section ol.upperalpha>li,.rst-content .toctree-wrapper ol.upperalpha,.rst-content .toctree-wrapper ol.upperalpha>li,.rst-content section ol.upperalpha,.rst-content section ol.upperalpha>li{list-style:upper-alpha}.rst-content .section ol li>*,.rst-content .section ul li>*,.rst-content .toctree-wrapper ol li>*,.rst-content .toctree-wrapper ul li>*,.rst-content section ol li>*,.rst-content section ul li>*{margin-top:12px;margin-bottom:12px}.rst-content .section ol li>:first-child,.rst-content .section ul li>:first-child,.rst-content .toctree-wrapper ol li>:first-child,.rst-content .toctree-wrapper ul li>:first-child,.rst-content section ol li>:first-child,.rst-content section ul li>:first-child{margin-top:0}.rst-content .section ol li>p,.rst-content .section ol li>p:last-child,.rst-content .section ul li>p,.rst-content .section ul li>p:last-child,.rst-content .toctree-wrapper ol li>p,.rst-content .toctree-wrapper ol li>p:last-child,.rst-content .toctree-wrapper ul li>p,.rst-content .toctree-wrapper ul li>p:last-child,.rst-content section ol li>p,.rst-content section ol li>p:last-child,.rst-content section ul li>p,.rst-content section ul li>p:last-child{margin-bottom:12px}.rst-content .section ol li>p:only-child,.rst-content .section ol li>p:only-child:last-child,.rst-content .section ul li>p:only-child,.rst-content .section ul li>p:only-child:last-child,.rst-content .toctree-wrapper ol li>p:only-child,.rst-content .toctree-wrapper ol li>p:only-child:last-child,.rst-content .toctree-wrapper ul li>p:only-child,.rst-content .toctree-wrapper ul li>p:only-child:last-child,.rst-content section ol li>p:only-child,.rst-content section ol li>p:only-child:last-child,.rst-content section ul li>p:only-child,.rst-content section ul li>p:only-child:last-child{margin-bottom:0}.rst-content .section ol li>ol,.rst-content .section ol li>ul,.rst-content .section ul li>ol,.rst-content .section ul li>ul,.rst-content .toctree-wrapper ol li>ol,.rst-content .toctree-wrapper ol li>ul,.rst-content .toctree-wrapper ul li>ol,.rst-content .toctree-wrapper ul li>ul,.rst-content section ol li>ol,.rst-content section ol li>ul,.rst-content section ul li>ol,.rst-content section ul li>ul{margin-bottom:12px}.rst-content .section ol.simple li>*,.rst-content .section ol.simple li ol,.rst-content .section ol.simple li ul,.rst-content .section ul.simple li>*,.rst-content .section ul.simple li ol,.rst-content .section ul.simple li ul,.rst-content .toctree-wrapper ol.simple li>*,.rst-content .toctree-wrapper ol.simple li ol,.rst-content .toctree-wrapper ol.simple li ul,.rst-content .toctree-wrapper ul.simple li>*,.rst-content .toctree-wrapper ul.simple li ol,.rst-content .toctree-wrapper ul.simple li ul,.rst-content section ol.simple li>*,.rst-content section ol.simple li ol,.rst-content section ol.simple li ul,.rst-content section ul.simple li>*,.rst-content section ul.simple li ol,.rst-content section ul.simple li ul{margin-top:0;margin-bottom:0}.rst-content .line-block{margin-left:0;margin-bottom:24px;line-height:24px}.rst-content .line-block .line-block{margin-left:24px;margin-bottom:0}.rst-content .topic-title{font-weight:700;margin-bottom:12px}.rst-content .toc-backref{color:#404040}.rst-content .align-right{float:right;margin:0 0 24px 24px}.rst-content .align-left{float:left;margin:0 24px 24px 0}.rst-content .align-center{margin:auto}.rst-content .align-center:not(table){display:block}.rst-content .code-block-caption .headerlink,.rst-content .eqno .headerlink,.rst-content .toctree-wrapper>p.caption .headerlink,.rst-content dl dt .headerlink,.rst-content h1 .headerlink,.rst-content h2 .headerlink,.rst-content h3 .headerlink,.rst-content h4 .headerlink,.rst-content h5 .headerlink,.rst-content h6 .headerlink,.rst-content p.caption .headerlink,.rst-content p .headerlink,.rst-content table>caption .headerlink{opacity:0;font-size:14px;font-family:FontAwesome;margin-left:.5em}.rst-content .code-block-caption .headerlink:focus,.rst-content .code-block-caption:hover .headerlink,.rst-content .eqno .headerlink:focus,.rst-content .eqno:hover .headerlink,.rst-content .toctree-wrapper>p.caption .headerlink:focus,.rst-content .toctree-wrapper>p.caption:hover .headerlink,.rst-content dl dt .headerlink:focus,.rst-content dl dt:hover .headerlink,.rst-content h1 .headerlink:focus,.rst-content h1:hover .headerlink,.rst-content h2 .headerlink:focus,.rst-content h2:hover .headerlink,.rst-content h3 .headerlink:focus,.rst-content h3:hover .headerlink,.rst-content h4 .headerlink:focus,.rst-content h4:hover .headerlink,.rst-content h5 .headerlink:focus,.rst-content h5:hover .headerlink,.rst-content h6 .headerlink:focus,.rst-content h6:hover .headerlink,.rst-content p.caption .headerlink:focus,.rst-content p.caption:hover .headerlink,.rst-content p .headerlink:focus,.rst-content p:hover .headerlink,.rst-content table>caption .headerlink:focus,.rst-content table>caption:hover .headerlink{opacity:1}.rst-content p a{overflow-wrap:anywhere}.rst-content .wy-table td p,.rst-content .wy-table td ul,.rst-content .wy-table th p,.rst-content .wy-table th ul,.rst-content table.docutils td p,.rst-content table.docutils td ul,.rst-content table.docutils th p,.rst-content table.docutils th ul,.rst-content table.field-list td p,.rst-content table.field-list td ul,.rst-content table.field-list th p,.rst-content table.field-list th ul{font-size:inherit}.rst-content .btn:focus{outline:2px solid}.rst-content table>caption .headerlink:after{font-size:12px}.rst-content .centered{text-align:center}.rst-content .sidebar{float:right;width:40%;display:block;margin:0 0 24px 24px;padding:24px;background:#f3f6f6;border:1px solid #e1e4e5}.rst-content .sidebar dl,.rst-content .sidebar p,.rst-content .sidebar ul{font-size:90%}.rst-content .sidebar .last,.rst-content .sidebar>:last-child{margin-bottom:0}.rst-content .sidebar .sidebar-title{display:block;font-family:Roboto Slab,ff-tisa-web-pro,Georgia,Arial,sans-serif;font-weight:700;background:#e1e4e5;padding:6px 12px;margin:-24px -24px 24px;font-size:100%}.rst-content .highlighted{background:#f1c40f;box-shadow:0 0 0 2px #f1c40f;display:inline;font-weight:700}.rst-content .citation-reference,.rst-content .footnote-reference{vertical-align:baseline;position:relative;top:-.4em;line-height:0;font-size:90%}.rst-content .citation-reference>span.fn-bracket,.rst-content .footnote-reference>span.fn-bracket{display:none}.rst-content .hlist{width:100%}.rst-content dl dt span.classifier:before{content:" : "}.rst-content dl dt span.classifier-delimiter{display:none!important}html.writer-html4 .rst-content table.docutils.citation,html.writer-html4 .rst-content table.docutils.footnote{background:none;border:none}html.writer-html4 .rst-content table.docutils.citation td,html.writer-html4 .rst-content table.docutils.citation tr,html.writer-html4 .rst-content table.docutils.footnote td,html.writer-html4 .rst-content table.docutils.footnote tr{border:none;background-color:transparent!important;white-space:normal}html.writer-html4 .rst-content table.docutils.citation td.label,html.writer-html4 .rst-content table.docutils.footnote td.label{padding-left:0;padding-right:0;vertical-align:top}html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.field-list,html.writer-html5 .rst-content dl.footnote{display:grid;grid-template-columns:auto minmax(80%,95%)}html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.field-list>dt,html.writer-html5 .rst-content dl.footnote>dt{display:inline-grid;grid-template-columns:max-content auto}html.writer-html5 .rst-content aside.citation,html.writer-html5 .rst-content aside.footnote,html.writer-html5 .rst-content div.citation{display:grid;grid-template-columns:auto auto minmax(.65rem,auto) minmax(40%,95%)}html.writer-html5 .rst-content aside.citation>span.label,html.writer-html5 .rst-content aside.footnote>span.label,html.writer-html5 .rst-content div.citation>span.label{grid-column-start:1;grid-column-end:2}html.writer-html5 .rst-content aside.citation>span.backrefs,html.writer-html5 .rst-content aside.footnote>span.backrefs,html.writer-html5 .rst-content div.citation>span.backrefs{grid-column-start:2;grid-column-end:3;grid-row-start:1;grid-row-end:3}html.writer-html5 .rst-content aside.citation>p,html.writer-html5 .rst-content aside.footnote>p,html.writer-html5 .rst-content div.citation>p{grid-column-start:4;grid-column-end:5}html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.field-list,html.writer-html5 .rst-content dl.footnote{margin-bottom:24px}html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.field-list>dt,html.writer-html5 .rst-content dl.footnote>dt{padding-left:1rem}html.writer-html5 .rst-content dl.citation>dd,html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.field-list>dd,html.writer-html5 .rst-content dl.field-list>dt,html.writer-html5 .rst-content dl.footnote>dd,html.writer-html5 .rst-content dl.footnote>dt{margin-bottom:0}html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.footnote{font-size:.9rem}html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.footnote>dt{margin:0 .5rem .5rem 0;line-height:1.2rem;word-break:break-all;font-weight:400}html.writer-html5 .rst-content dl.citation>dt>span.brackets:before,html.writer-html5 .rst-content dl.footnote>dt>span.brackets:before{content:"["}html.writer-html5 .rst-content dl.citation>dt>span.brackets:after,html.writer-html5 .rst-content dl.footnote>dt>span.brackets:after{content:"]"}html.writer-html5 .rst-content dl.citation>dt>span.fn-backref,html.writer-html5 .rst-content dl.footnote>dt>span.fn-backref{text-align:left;font-style:italic;margin-left:.65rem;word-break:break-word;word-spacing:-.1rem;max-width:5rem}html.writer-html5 .rst-content dl.citation>dt>span.fn-backref>a,html.writer-html5 .rst-content dl.footnote>dt>span.fn-backref>a{word-break:keep-all}html.writer-html5 .rst-content dl.citation>dt>span.fn-backref>a:not(:first-child):before,html.writer-html5 .rst-content dl.footnote>dt>span.fn-backref>a:not(:first-child):before{content:" "}html.writer-html5 .rst-content dl.citation>dd,html.writer-html5 .rst-content dl.footnote>dd{margin:0 0 .5rem;line-height:1.2rem}html.writer-html5 .rst-content dl.citation>dd p,html.writer-html5 .rst-content dl.footnote>dd p{font-size:.9rem}html.writer-html5 .rst-content aside.citation,html.writer-html5 .rst-content aside.footnote,html.writer-html5 .rst-content div.citation{padding-left:1rem;padding-right:1rem;font-size:.9rem;line-height:1.2rem}html.writer-html5 .rst-content aside.citation p,html.writer-html5 .rst-content aside.footnote p,html.writer-html5 .rst-content div.citation p{font-size:.9rem;line-height:1.2rem;margin-bottom:12px}html.writer-html5 .rst-content aside.citation span.backrefs,html.writer-html5 .rst-content aside.footnote span.backrefs,html.writer-html5 .rst-content div.citation span.backrefs{text-align:left;font-style:italic;margin-left:.65rem;word-break:break-word;word-spacing:-.1rem;max-width:5rem}html.writer-html5 .rst-content aside.citation span.backrefs>a,html.writer-html5 .rst-content aside.footnote span.backrefs>a,html.writer-html5 .rst-content div.citation span.backrefs>a{word-break:keep-all}html.writer-html5 .rst-content aside.citation span.backrefs>a:not(:first-child):before,html.writer-html5 .rst-content aside.footnote span.backrefs>a:not(:first-child):before,html.writer-html5 .rst-content div.citation span.backrefs>a:not(:first-child):before{content:" "}html.writer-html5 .rst-content aside.citation span.label,html.writer-html5 .rst-content aside.footnote span.label,html.writer-html5 .rst-content div.citation span.label{line-height:1.2rem}html.writer-html5 .rst-content aside.citation-list,html.writer-html5 .rst-content aside.footnote-list,html.writer-html5 .rst-content div.citation-list{margin-bottom:24px}html.writer-html5 .rst-content dl.option-list kbd{font-size:.9rem}.rst-content table.docutils.footnote,html.writer-html4 .rst-content table.docutils.citation,html.writer-html5 .rst-content aside.footnote,html.writer-html5 .rst-content aside.footnote-list aside.footnote,html.writer-html5 .rst-content div.citation-list>div.citation,html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.footnote{color:grey}.rst-content table.docutils.footnote code,.rst-content table.docutils.footnote tt,html.writer-html4 .rst-content table.docutils.citation code,html.writer-html4 .rst-content table.docutils.citation tt,html.writer-html5 .rst-content aside.footnote-list aside.footnote code,html.writer-html5 .rst-content aside.footnote-list aside.footnote tt,html.writer-html5 .rst-content aside.footnote code,html.writer-html5 .rst-content aside.footnote tt,html.writer-html5 .rst-content div.citation-list>div.citation code,html.writer-html5 .rst-content div.citation-list>div.citation tt,html.writer-html5 .rst-content dl.citation code,html.writer-html5 .rst-content dl.citation tt,html.writer-html5 .rst-content dl.footnote code,html.writer-html5 .rst-content dl.footnote tt{color:#555}.rst-content .wy-table-responsive.citation,.rst-content .wy-table-responsive.footnote{margin-bottom:0}.rst-content .wy-table-responsive.citation+:not(.citation),.rst-content .wy-table-responsive.footnote+:not(.footnote){margin-top:24px}.rst-content .wy-table-responsive.citation:last-child,.rst-content .wy-table-responsive.footnote:last-child{margin-bottom:24px}.rst-content table.docutils th{border-color:#e1e4e5}html.writer-html5 .rst-content table.docutils th{border:1px solid #e1e4e5}html.writer-html5 .rst-content table.docutils td>p,html.writer-html5 .rst-content table.docutils th>p{line-height:1rem;margin-bottom:0;font-size:.9rem}.rst-content table.docutils td .last,.rst-content table.docutils td .last>:last-child{margin-bottom:0}.rst-content table.field-list,.rst-content table.field-list td{border:none}.rst-content table.field-list td p{line-height:inherit}.rst-content table.field-list td>strong{display:inline-block}.rst-content table.field-list .field-name{padding-right:10px;text-align:left;white-space:nowrap}.rst-content table.field-list .field-body{text-align:left}.rst-content code,.rst-content tt{color:#000;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;padding:2px 5px}.rst-content code big,.rst-content code em,.rst-content tt big,.rst-content tt em{font-size:100%!important;line-height:normal}.rst-content code.literal,.rst-content tt.literal{color:#e74c3c;white-space:normal}.rst-content code.xref,.rst-content tt.xref,a .rst-content code,a .rst-content tt{font-weight:700;color:#404040;overflow-wrap:normal}.rst-content kbd,.rst-content pre,.rst-content samp{font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace}.rst-content a code,.rst-content a tt{color:#2980b9}.rst-content dl{margin-bottom:24px}.rst-content dl dt{font-weight:700;margin-bottom:12px}.rst-content dl ol,.rst-content dl p,.rst-content dl table,.rst-content dl ul{margin-bottom:12px}.rst-content dl dd{margin:0 0 12px 24px;line-height:24px}.rst-content dl dd>ol:last-child,.rst-content dl dd>p:last-child,.rst-content dl dd>table:last-child,.rst-content dl dd>ul:last-child{margin-bottom:0}html.writer-html4 .rst-content dl:not(.docutils),html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple){margin-bottom:24px}html.writer-html4 .rst-content dl:not(.docutils)>dt,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt{display:table;margin:6px 0;font-size:90%;line-height:normal;background:#e7f2fa;color:#2980b9;border-top:3px solid #6ab0de;padding:6px;position:relative}html.writer-html4 .rst-content dl:not(.docutils)>dt:before,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt:before{color:#6ab0de}html.writer-html4 .rst-content dl:not(.docutils)>dt .headerlink,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt .headerlink{color:#404040;font-size:100%!important}html.writer-html4 .rst-content dl:not(.docutils) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt{margin-bottom:6px;border:none;border-left:3px solid #ccc;background:#f0f0f0;color:#555}html.writer-html4 .rst-content dl:not(.docutils) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt .headerlink,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt .headerlink{color:#404040;font-size:100%!important}html.writer-html4 .rst-content dl:not(.docutils)>dt:first-child,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt:first-child{margin-top:0}html.writer-html4 .rst-content dl:not(.docutils) code.descclassname,html.writer-html4 .rst-content dl:not(.docutils) code.descname,html.writer-html4 .rst-content dl:not(.docutils) tt.descclassname,html.writer-html4 .rst-content dl:not(.docutils) tt.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) code.descclassname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) code.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) tt.descclassname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) tt.descname{background-color:transparent;border:none;padding:0;font-size:100%!important}html.writer-html4 .rst-content dl:not(.docutils) code.descname,html.writer-html4 .rst-content dl:not(.docutils) tt.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) code.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) tt.descname{font-weight:700}html.writer-html4 .rst-content dl:not(.docutils) .optional,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .optional{display:inline-block;padding:0 4px;color:#000;font-weight:700}html.writer-html4 .rst-content dl:not(.docutils) .property,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .property{display:inline-block;padding-right:8px;max-width:100%}html.writer-html4 .rst-content dl:not(.docutils) .k,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .k{font-style:italic}html.writer-html4 .rst-content dl:not(.docutils) .descclassname,html.writer-html4 .rst-content dl:not(.docutils) .descname,html.writer-html4 .rst-content dl:not(.docutils) .sig-name,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .descclassname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .sig-name{font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;color:#000}.rst-content .viewcode-back,.rst-content .viewcode-link{display:inline-block;color:#27ae60;font-size:80%;padding-left:24px}.rst-content .viewcode-back{display:block;float:right}.rst-content p.rubric{margin-bottom:12px;font-weight:700}.rst-content code.download,.rst-content tt.download{background:inherit;padding:inherit;font-weight:400;font-family:inherit;font-size:inherit;color:inherit;border:inherit;white-space:inherit}.rst-content code.download span:first-child,.rst-content tt.download span:first-child{-webkit-font-smoothing:subpixel-antialiased}.rst-content code.download span:first-child:before,.rst-content tt.download span:first-child:before{margin-right:4px}.rst-content .guilabel,.rst-content .menuselection{font-size:80%;font-weight:700;border-radius:4px;padding:2.4px 6px;margin:auto 2px}.rst-content .guilabel,.rst-content .menuselection{border:1px solid #7fbbe3;background:#e7f2fa}.rst-content :not(dl.option-list)>:not(dt):not(kbd):not(.kbd)>.kbd,.rst-content :not(dl.option-list)>:not(dt):not(kbd):not(.kbd)>kbd{color:inherit;font-size:80%;background-color:#fff;border:1px solid #a6a6a6;border-radius:4px;box-shadow:0 2px grey;padding:2.4px 6px;margin:auto 0}.rst-content .versionmodified{font-style:italic}@media screen and (max-width:480px){.rst-content .sidebar{width:100%}}span[id*=MathJax-Span]{color:#404040}.math{text-align:center}@font-face{font-family:Lato;src:url(fonts/lato-normal.woff2?bd03a2cc277bbbc338d464e679fe9942) format("woff2"),url(fonts/lato-normal.woff?27bd77b9162d388cb8d4c4217c7c5e2a) format("woff");font-weight:400;font-style:normal;font-display:block}@font-face{font-family:Lato;src:url(fonts/lato-bold.woff2?cccb897485813c7c256901dbca54ecf2) format("woff2"),url(fonts/lato-bold.woff?d878b6c29b10beca227e9eef4246111b) format("woff");font-weight:700;font-style:normal;font-display:block}@font-face{font-family:Lato;src:url(fonts/lato-bold-italic.woff2?0b6bb6725576b072c5d0b02ecdd1900d) format("woff2"),url(fonts/lato-bold-italic.woff?9c7e4e9eb485b4a121c760e61bc3707c) format("woff");font-weight:700;font-style:italic;font-display:block}@font-face{font-family:Lato;src:url(fonts/lato-normal-italic.woff2?4eb103b4d12be57cb1d040ed5e162e9d) format("woff2"),url(fonts/lato-normal-italic.woff?f28f2d6482446544ef1ea1ccc6dd5892) format("woff");font-weight:400;font-style:italic;font-display:block}@font-face{font-family:Roboto Slab;font-style:normal;font-weight:400;src:url(fonts/Roboto-Slab-Regular.woff2?7abf5b8d04d26a2cafea937019bca958) format("woff2"),url(fonts/Roboto-Slab-Regular.woff?c1be9284088d487c5e3ff0a10a92e58c) format("woff");font-display:block}@font-face{font-family:Roboto Slab;font-style:normal;font-weight:700;src:url(fonts/Roboto-Slab-Bold.woff2?9984f4a9bda09be08e83f2506954adbe) format("woff2"),url(fonts/Roboto-Slab-Bold.woff?bed5564a116b05148e3b3bea6fb1162a) format("woff");font-display:block} \ No newline at end of file diff --git a/docs/build/html/_static/doctools.js b/docs/build/html/_static/doctools.js deleted file mode 100644 index 4d67807d..00000000 --- a/docs/build/html/_static/doctools.js +++ /dev/null @@ -1,156 +0,0 @@ -/* - * doctools.js - * ~~~~~~~~~~~ - * - * Base JavaScript utilities for all Sphinx HTML documentation. - * - * :copyright: Copyright 2007-2024 by the Sphinx team, see AUTHORS. - * :license: BSD, see LICENSE for details. - * - */ -"use strict"; - -const BLACKLISTED_KEY_CONTROL_ELEMENTS = new Set([ - "TEXTAREA", - "INPUT", - "SELECT", - "BUTTON", -]); - -const _ready = (callback) => { - if (document.readyState !== "loading") { - callback(); - } else { - document.addEventListener("DOMContentLoaded", callback); - } -}; - -/** - * Small JavaScript module for the documentation. - */ -const Documentation = { - init: () => { - Documentation.initDomainIndexTable(); - Documentation.initOnKeyListeners(); - }, - - /** - * i18n support - */ - TRANSLATIONS: {}, - PLURAL_EXPR: (n) => (n === 1 ? 0 : 1), - LOCALE: "unknown", - - // gettext and ngettext don't access this so that the functions - // can safely bound to a different name (_ = Documentation.gettext) - gettext: (string) => { - const translated = Documentation.TRANSLATIONS[string]; - switch (typeof translated) { - case "undefined": - return string; // no translation - case "string": - return translated; // translation exists - default: - return translated[0]; // (singular, plural) translation tuple exists - } - }, - - ngettext: (singular, plural, n) => { - const translated = Documentation.TRANSLATIONS[singular]; - if (typeof translated !== "undefined") - return translated[Documentation.PLURAL_EXPR(n)]; - return n === 1 ? singular : plural; - }, - - addTranslations: (catalog) => { - Object.assign(Documentation.TRANSLATIONS, catalog.messages); - Documentation.PLURAL_EXPR = new Function( - "n", - `return (${catalog.plural_expr})` - ); - Documentation.LOCALE = catalog.locale; - }, - - /** - * helper function to focus on search bar - */ - focusSearchBar: () => { - document.querySelectorAll("input[name=q]")[0]?.focus(); - }, - - /** - * Initialise the domain index toggle buttons - */ - initDomainIndexTable: () => { - const toggler = (el) => { - const idNumber = el.id.substr(7); - const toggledRows = document.querySelectorAll(`tr.cg-${idNumber}`); - if (el.src.substr(-9) === "minus.png") { - el.src = `${el.src.substr(0, el.src.length - 9)}plus.png`; - toggledRows.forEach((el) => (el.style.display = "none")); - } else { - el.src = `${el.src.substr(0, el.src.length - 8)}minus.png`; - toggledRows.forEach((el) => (el.style.display = "")); - } - }; - - const togglerElements = document.querySelectorAll("img.toggler"); - togglerElements.forEach((el) => - el.addEventListener("click", (event) => toggler(event.currentTarget)) - ); - togglerElements.forEach((el) => (el.style.display = "")); - if (DOCUMENTATION_OPTIONS.COLLAPSE_INDEX) togglerElements.forEach(toggler); - }, - - initOnKeyListeners: () => { - // only install a listener if it is really needed - if ( - !DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS && - !DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS - ) - return; - - document.addEventListener("keydown", (event) => { - // bail for input elements - if (BLACKLISTED_KEY_CONTROL_ELEMENTS.has(document.activeElement.tagName)) return; - // bail with special keys - if (event.altKey || event.ctrlKey || event.metaKey) return; - - if (!event.shiftKey) { - switch (event.key) { - case "ArrowLeft": - if (!DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS) break; - - const prevLink = document.querySelector('link[rel="prev"]'); - if (prevLink && prevLink.href) { - window.location.href = prevLink.href; - event.preventDefault(); - } - break; - case "ArrowRight": - if (!DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS) break; - - const nextLink = document.querySelector('link[rel="next"]'); - if (nextLink && nextLink.href) { - window.location.href = nextLink.href; - event.preventDefault(); - } - break; - } - } - - // some keyboard layouts may need Shift to get / - switch (event.key) { - case "/": - if (!DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS) break; - Documentation.focusSearchBar(); - event.preventDefault(); - } - }); - }, -}; - -// quick alias for translations -const _ = Documentation.gettext; - -_ready(Documentation.init); diff --git a/docs/build/html/_static/documentation_options.js b/docs/build/html/_static/documentation_options.js deleted file mode 100644 index 7e4c114f..00000000 --- a/docs/build/html/_static/documentation_options.js +++ /dev/null @@ -1,13 +0,0 @@ -const DOCUMENTATION_OPTIONS = { - VERSION: '', - LANGUAGE: 'en', - COLLAPSE_INDEX: false, - BUILDER: 'html', - FILE_SUFFIX: '.html', - LINK_SUFFIX: '.html', - HAS_SOURCE: true, - SOURCELINK_SUFFIX: '.txt', - NAVIGATION_WITH_KEYS: false, - SHOW_SEARCH_SUMMARY: true, - ENABLE_SEARCH_SHORTCUTS: true, -}; \ No newline at end of file diff --git a/docs/build/html/_static/file.png b/docs/build/html/_static/file.png deleted file mode 100644 index a858a410..00000000 Binary files a/docs/build/html/_static/file.png and /dev/null differ diff --git a/docs/build/html/_static/jquery.js b/docs/build/html/_static/jquery.js deleted file mode 100644 index c4c6022f..00000000 --- a/docs/build/html/_static/jquery.js +++ /dev/null @@ -1,2 +0,0 @@ -/*! jQuery v3.6.0 | (c) OpenJS Foundation and other contributors | jquery.org/license */ -!function(e,t){"use strict";"object"==typeof module&&"object"==typeof module.exports?module.exports=e.document?t(e,!0):function(e){if(!e.document)throw new Error("jQuery requires a window with a document");return t(e)}:t(e)}("undefined"!=typeof window?window:this,function(C,e){"use strict";var t=[],r=Object.getPrototypeOf,s=t.slice,g=t.flat?function(e){return t.flat.call(e)}:function(e){return t.concat.apply([],e)},u=t.push,i=t.indexOf,n={},o=n.toString,v=n.hasOwnProperty,a=v.toString,l=a.call(Object),y={},m=function(e){return"function"==typeof e&&"number"!=typeof e.nodeType&&"function"!=typeof e.item},x=function(e){return null!=e&&e===e.window},E=C.document,c={type:!0,src:!0,nonce:!0,noModule:!0};function b(e,t,n){var r,i,o=(n=n||E).createElement("script");if(o.text=e,t)for(r in c)(i=t[r]||t.getAttribute&&t.getAttribute(r))&&o.setAttribute(r,i);n.head.appendChild(o).parentNode.removeChild(o)}function w(e){return null==e?e+"":"object"==typeof e||"function"==typeof e?n[o.call(e)]||"object":typeof e}var f="3.6.0",S=function(e,t){return new S.fn.init(e,t)};function p(e){var t=!!e&&"length"in e&&e.length,n=w(e);return!m(e)&&!x(e)&&("array"===n||0===t||"number"==typeof t&&0+~]|"+M+")"+M+"*"),U=new RegExp(M+"|>"),X=new RegExp(F),V=new RegExp("^"+I+"$"),G={ID:new RegExp("^#("+I+")"),CLASS:new RegExp("^\\.("+I+")"),TAG:new RegExp("^("+I+"|[*])"),ATTR:new RegExp("^"+W),PSEUDO:new RegExp("^"+F),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+M+"*(even|odd|(([+-]|)(\\d*)n|)"+M+"*(?:([+-]|)"+M+"*(\\d+)|))"+M+"*\\)|)","i"),bool:new RegExp("^(?:"+R+")$","i"),needsContext:new RegExp("^"+M+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+M+"*((?:-\\d)?\\d*)"+M+"*\\)|)(?=[^-]|$)","i")},Y=/HTML$/i,Q=/^(?:input|select|textarea|button)$/i,J=/^h\d$/i,K=/^[^{]+\{\s*\[native \w/,Z=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,ee=/[+~]/,te=new RegExp("\\\\[\\da-fA-F]{1,6}"+M+"?|\\\\([^\\r\\n\\f])","g"),ne=function(e,t){var n="0x"+e.slice(1)-65536;return t||(n<0?String.fromCharCode(n+65536):String.fromCharCode(n>>10|55296,1023&n|56320))},re=/([\0-\x1f\x7f]|^-?\d)|^-$|[^\0-\x1f\x7f-\uFFFF\w-]/g,ie=function(e,t){return t?"\0"===e?"\ufffd":e.slice(0,-1)+"\\"+e.charCodeAt(e.length-1).toString(16)+" ":"\\"+e},oe=function(){T()},ae=be(function(e){return!0===e.disabled&&"fieldset"===e.nodeName.toLowerCase()},{dir:"parentNode",next:"legend"});try{H.apply(t=O.call(p.childNodes),p.childNodes),t[p.childNodes.length].nodeType}catch(e){H={apply:t.length?function(e,t){L.apply(e,O.call(t))}:function(e,t){var n=e.length,r=0;while(e[n++]=t[r++]);e.length=n-1}}}function se(t,e,n,r){var i,o,a,s,u,l,c,f=e&&e.ownerDocument,p=e?e.nodeType:9;if(n=n||[],"string"!=typeof t||!t||1!==p&&9!==p&&11!==p)return n;if(!r&&(T(e),e=e||C,E)){if(11!==p&&(u=Z.exec(t)))if(i=u[1]){if(9===p){if(!(a=e.getElementById(i)))return n;if(a.id===i)return n.push(a),n}else if(f&&(a=f.getElementById(i))&&y(e,a)&&a.id===i)return n.push(a),n}else{if(u[2])return H.apply(n,e.getElementsByTagName(t)),n;if((i=u[3])&&d.getElementsByClassName&&e.getElementsByClassName)return H.apply(n,e.getElementsByClassName(i)),n}if(d.qsa&&!N[t+" "]&&(!v||!v.test(t))&&(1!==p||"object"!==e.nodeName.toLowerCase())){if(c=t,f=e,1===p&&(U.test(t)||z.test(t))){(f=ee.test(t)&&ye(e.parentNode)||e)===e&&d.scope||((s=e.getAttribute("id"))?s=s.replace(re,ie):e.setAttribute("id",s=S)),o=(l=h(t)).length;while(o--)l[o]=(s?"#"+s:":scope")+" "+xe(l[o]);c=l.join(",")}try{return H.apply(n,f.querySelectorAll(c)),n}catch(e){N(t,!0)}finally{s===S&&e.removeAttribute("id")}}}return g(t.replace($,"$1"),e,n,r)}function ue(){var r=[];return function e(t,n){return r.push(t+" ")>b.cacheLength&&delete e[r.shift()],e[t+" "]=n}}function le(e){return e[S]=!0,e}function ce(e){var t=C.createElement("fieldset");try{return!!e(t)}catch(e){return!1}finally{t.parentNode&&t.parentNode.removeChild(t),t=null}}function fe(e,t){var n=e.split("|"),r=n.length;while(r--)b.attrHandle[n[r]]=t}function pe(e,t){var n=t&&e,r=n&&1===e.nodeType&&1===t.nodeType&&e.sourceIndex-t.sourceIndex;if(r)return r;if(n)while(n=n.nextSibling)if(n===t)return-1;return e?1:-1}function de(t){return function(e){return"input"===e.nodeName.toLowerCase()&&e.type===t}}function he(n){return function(e){var t=e.nodeName.toLowerCase();return("input"===t||"button"===t)&&e.type===n}}function ge(t){return function(e){return"form"in e?e.parentNode&&!1===e.disabled?"label"in e?"label"in e.parentNode?e.parentNode.disabled===t:e.disabled===t:e.isDisabled===t||e.isDisabled!==!t&&ae(e)===t:e.disabled===t:"label"in e&&e.disabled===t}}function ve(a){return le(function(o){return o=+o,le(function(e,t){var n,r=a([],e.length,o),i=r.length;while(i--)e[n=r[i]]&&(e[n]=!(t[n]=e[n]))})})}function ye(e){return e&&"undefined"!=typeof e.getElementsByTagName&&e}for(e in d=se.support={},i=se.isXML=function(e){var t=e&&e.namespaceURI,n=e&&(e.ownerDocument||e).documentElement;return!Y.test(t||n&&n.nodeName||"HTML")},T=se.setDocument=function(e){var t,n,r=e?e.ownerDocument||e:p;return r!=C&&9===r.nodeType&&r.documentElement&&(a=(C=r).documentElement,E=!i(C),p!=C&&(n=C.defaultView)&&n.top!==n&&(n.addEventListener?n.addEventListener("unload",oe,!1):n.attachEvent&&n.attachEvent("onunload",oe)),d.scope=ce(function(e){return a.appendChild(e).appendChild(C.createElement("div")),"undefined"!=typeof e.querySelectorAll&&!e.querySelectorAll(":scope fieldset div").length}),d.attributes=ce(function(e){return e.className="i",!e.getAttribute("className")}),d.getElementsByTagName=ce(function(e){return e.appendChild(C.createComment("")),!e.getElementsByTagName("*").length}),d.getElementsByClassName=K.test(C.getElementsByClassName),d.getById=ce(function(e){return a.appendChild(e).id=S,!C.getElementsByName||!C.getElementsByName(S).length}),d.getById?(b.filter.ID=function(e){var t=e.replace(te,ne);return function(e){return e.getAttribute("id")===t}},b.find.ID=function(e,t){if("undefined"!=typeof t.getElementById&&E){var n=t.getElementById(e);return n?[n]:[]}}):(b.filter.ID=function(e){var n=e.replace(te,ne);return function(e){var t="undefined"!=typeof e.getAttributeNode&&e.getAttributeNode("id");return t&&t.value===n}},b.find.ID=function(e,t){if("undefined"!=typeof t.getElementById&&E){var n,r,i,o=t.getElementById(e);if(o){if((n=o.getAttributeNode("id"))&&n.value===e)return[o];i=t.getElementsByName(e),r=0;while(o=i[r++])if((n=o.getAttributeNode("id"))&&n.value===e)return[o]}return[]}}),b.find.TAG=d.getElementsByTagName?function(e,t){return"undefined"!=typeof t.getElementsByTagName?t.getElementsByTagName(e):d.qsa?t.querySelectorAll(e):void 0}:function(e,t){var n,r=[],i=0,o=t.getElementsByTagName(e);if("*"===e){while(n=o[i++])1===n.nodeType&&r.push(n);return r}return o},b.find.CLASS=d.getElementsByClassName&&function(e,t){if("undefined"!=typeof t.getElementsByClassName&&E)return t.getElementsByClassName(e)},s=[],v=[],(d.qsa=K.test(C.querySelectorAll))&&(ce(function(e){var t;a.appendChild(e).innerHTML="",e.querySelectorAll("[msallowcapture^='']").length&&v.push("[*^$]="+M+"*(?:''|\"\")"),e.querySelectorAll("[selected]").length||v.push("\\["+M+"*(?:value|"+R+")"),e.querySelectorAll("[id~="+S+"-]").length||v.push("~="),(t=C.createElement("input")).setAttribute("name",""),e.appendChild(t),e.querySelectorAll("[name='']").length||v.push("\\["+M+"*name"+M+"*="+M+"*(?:''|\"\")"),e.querySelectorAll(":checked").length||v.push(":checked"),e.querySelectorAll("a#"+S+"+*").length||v.push(".#.+[+~]"),e.querySelectorAll("\\\f"),v.push("[\\r\\n\\f]")}),ce(function(e){e.innerHTML="";var t=C.createElement("input");t.setAttribute("type","hidden"),e.appendChild(t).setAttribute("name","D"),e.querySelectorAll("[name=d]").length&&v.push("name"+M+"*[*^$|!~]?="),2!==e.querySelectorAll(":enabled").length&&v.push(":enabled",":disabled"),a.appendChild(e).disabled=!0,2!==e.querySelectorAll(":disabled").length&&v.push(":enabled",":disabled"),e.querySelectorAll("*,:x"),v.push(",.*:")})),(d.matchesSelector=K.test(c=a.matches||a.webkitMatchesSelector||a.mozMatchesSelector||a.oMatchesSelector||a.msMatchesSelector))&&ce(function(e){d.disconnectedMatch=c.call(e,"*"),c.call(e,"[s!='']:x"),s.push("!=",F)}),v=v.length&&new RegExp(v.join("|")),s=s.length&&new RegExp(s.join("|")),t=K.test(a.compareDocumentPosition),y=t||K.test(a.contains)?function(e,t){var n=9===e.nodeType?e.documentElement:e,r=t&&t.parentNode;return e===r||!(!r||1!==r.nodeType||!(n.contains?n.contains(r):e.compareDocumentPosition&&16&e.compareDocumentPosition(r)))}:function(e,t){if(t)while(t=t.parentNode)if(t===e)return!0;return!1},j=t?function(e,t){if(e===t)return l=!0,0;var n=!e.compareDocumentPosition-!t.compareDocumentPosition;return n||(1&(n=(e.ownerDocument||e)==(t.ownerDocument||t)?e.compareDocumentPosition(t):1)||!d.sortDetached&&t.compareDocumentPosition(e)===n?e==C||e.ownerDocument==p&&y(p,e)?-1:t==C||t.ownerDocument==p&&y(p,t)?1:u?P(u,e)-P(u,t):0:4&n?-1:1)}:function(e,t){if(e===t)return l=!0,0;var n,r=0,i=e.parentNode,o=t.parentNode,a=[e],s=[t];if(!i||!o)return e==C?-1:t==C?1:i?-1:o?1:u?P(u,e)-P(u,t):0;if(i===o)return pe(e,t);n=e;while(n=n.parentNode)a.unshift(n);n=t;while(n=n.parentNode)s.unshift(n);while(a[r]===s[r])r++;return r?pe(a[r],s[r]):a[r]==p?-1:s[r]==p?1:0}),C},se.matches=function(e,t){return se(e,null,null,t)},se.matchesSelector=function(e,t){if(T(e),d.matchesSelector&&E&&!N[t+" "]&&(!s||!s.test(t))&&(!v||!v.test(t)))try{var n=c.call(e,t);if(n||d.disconnectedMatch||e.document&&11!==e.document.nodeType)return n}catch(e){N(t,!0)}return 0":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(e){return e[1]=e[1].replace(te,ne),e[3]=(e[3]||e[4]||e[5]||"").replace(te,ne),"~="===e[2]&&(e[3]=" "+e[3]+" "),e.slice(0,4)},CHILD:function(e){return e[1]=e[1].toLowerCase(),"nth"===e[1].slice(0,3)?(e[3]||se.error(e[0]),e[4]=+(e[4]?e[5]+(e[6]||1):2*("even"===e[3]||"odd"===e[3])),e[5]=+(e[7]+e[8]||"odd"===e[3])):e[3]&&se.error(e[0]),e},PSEUDO:function(e){var t,n=!e[6]&&e[2];return G.CHILD.test(e[0])?null:(e[3]?e[2]=e[4]||e[5]||"":n&&X.test(n)&&(t=h(n,!0))&&(t=n.indexOf(")",n.length-t)-n.length)&&(e[0]=e[0].slice(0,t),e[2]=n.slice(0,t)),e.slice(0,3))}},filter:{TAG:function(e){var t=e.replace(te,ne).toLowerCase();return"*"===e?function(){return!0}:function(e){return e.nodeName&&e.nodeName.toLowerCase()===t}},CLASS:function(e){var t=m[e+" "];return t||(t=new RegExp("(^|"+M+")"+e+"("+M+"|$)"))&&m(e,function(e){return t.test("string"==typeof e.className&&e.className||"undefined"!=typeof e.getAttribute&&e.getAttribute("class")||"")})},ATTR:function(n,r,i){return function(e){var t=se.attr(e,n);return null==t?"!="===r:!r||(t+="","="===r?t===i:"!="===r?t!==i:"^="===r?i&&0===t.indexOf(i):"*="===r?i&&-1:\x20\t\r\n\f]*)[\x20\t\r\n\f]*\/?>(?:<\/\1>|)$/i;function j(e,n,r){return m(n)?S.grep(e,function(e,t){return!!n.call(e,t,e)!==r}):n.nodeType?S.grep(e,function(e){return e===n!==r}):"string"!=typeof n?S.grep(e,function(e){return-1)[^>]*|#([\w-]+))$/;(S.fn.init=function(e,t,n){var r,i;if(!e)return this;if(n=n||D,"string"==typeof e){if(!(r="<"===e[0]&&">"===e[e.length-1]&&3<=e.length?[null,e,null]:q.exec(e))||!r[1]&&t)return!t||t.jquery?(t||n).find(e):this.constructor(t).find(e);if(r[1]){if(t=t instanceof S?t[0]:t,S.merge(this,S.parseHTML(r[1],t&&t.nodeType?t.ownerDocument||t:E,!0)),N.test(r[1])&&S.isPlainObject(t))for(r in t)m(this[r])?this[r](t[r]):this.attr(r,t[r]);return this}return(i=E.getElementById(r[2]))&&(this[0]=i,this.length=1),this}return e.nodeType?(this[0]=e,this.length=1,this):m(e)?void 0!==n.ready?n.ready(e):e(S):S.makeArray(e,this)}).prototype=S.fn,D=S(E);var L=/^(?:parents|prev(?:Until|All))/,H={children:!0,contents:!0,next:!0,prev:!0};function O(e,t){while((e=e[t])&&1!==e.nodeType);return e}S.fn.extend({has:function(e){var t=S(e,this),n=t.length;return this.filter(function(){for(var e=0;e\x20\t\r\n\f]*)/i,he=/^$|^module$|\/(?:java|ecma)script/i;ce=E.createDocumentFragment().appendChild(E.createElement("div")),(fe=E.createElement("input")).setAttribute("type","radio"),fe.setAttribute("checked","checked"),fe.setAttribute("name","t"),ce.appendChild(fe),y.checkClone=ce.cloneNode(!0).cloneNode(!0).lastChild.checked,ce.innerHTML="",y.noCloneChecked=!!ce.cloneNode(!0).lastChild.defaultValue,ce.innerHTML="",y.option=!!ce.lastChild;var ge={thead:[1,"","
"],col:[2,"","
"],tr:[2,"","
"],td:[3,"","
"],_default:[0,"",""]};function ve(e,t){var n;return n="undefined"!=typeof e.getElementsByTagName?e.getElementsByTagName(t||"*"):"undefined"!=typeof e.querySelectorAll?e.querySelectorAll(t||"*"):[],void 0===t||t&&A(e,t)?S.merge([e],n):n}function ye(e,t){for(var n=0,r=e.length;n",""]);var me=/<|&#?\w+;/;function xe(e,t,n,r,i){for(var o,a,s,u,l,c,f=t.createDocumentFragment(),p=[],d=0,h=e.length;d\s*$/g;function je(e,t){return A(e,"table")&&A(11!==t.nodeType?t:t.firstChild,"tr")&&S(e).children("tbody")[0]||e}function De(e){return e.type=(null!==e.getAttribute("type"))+"/"+e.type,e}function qe(e){return"true/"===(e.type||"").slice(0,5)?e.type=e.type.slice(5):e.removeAttribute("type"),e}function Le(e,t){var n,r,i,o,a,s;if(1===t.nodeType){if(Y.hasData(e)&&(s=Y.get(e).events))for(i in Y.remove(t,"handle events"),s)for(n=0,r=s[i].length;n").attr(n.scriptAttrs||{}).prop({charset:n.scriptCharset,src:n.url}).on("load error",i=function(e){r.remove(),i=null,e&&t("error"===e.type?404:200,e.type)}),E.head.appendChild(r[0])},abort:function(){i&&i()}}});var _t,zt=[],Ut=/(=)\?(?=&|$)|\?\?/;S.ajaxSetup({jsonp:"callback",jsonpCallback:function(){var e=zt.pop()||S.expando+"_"+wt.guid++;return this[e]=!0,e}}),S.ajaxPrefilter("json jsonp",function(e,t,n){var r,i,o,a=!1!==e.jsonp&&(Ut.test(e.url)?"url":"string"==typeof e.data&&0===(e.contentType||"").indexOf("application/x-www-form-urlencoded")&&Ut.test(e.data)&&"data");if(a||"jsonp"===e.dataTypes[0])return r=e.jsonpCallback=m(e.jsonpCallback)?e.jsonpCallback():e.jsonpCallback,a?e[a]=e[a].replace(Ut,"$1"+r):!1!==e.jsonp&&(e.url+=(Tt.test(e.url)?"&":"?")+e.jsonp+"="+r),e.converters["script json"]=function(){return o||S.error(r+" was not called"),o[0]},e.dataTypes[0]="json",i=C[r],C[r]=function(){o=arguments},n.always(function(){void 0===i?S(C).removeProp(r):C[r]=i,e[r]&&(e.jsonpCallback=t.jsonpCallback,zt.push(r)),o&&m(i)&&i(o[0]),o=i=void 0}),"script"}),y.createHTMLDocument=((_t=E.implementation.createHTMLDocument("").body).innerHTML="
",2===_t.childNodes.length),S.parseHTML=function(e,t,n){return"string"!=typeof e?[]:("boolean"==typeof t&&(n=t,t=!1),t||(y.createHTMLDocument?((r=(t=E.implementation.createHTMLDocument("")).createElement("base")).href=E.location.href,t.head.appendChild(r)):t=E),o=!n&&[],(i=N.exec(e))?[t.createElement(i[1])]:(i=xe([e],t,o),o&&o.length&&S(o).remove(),S.merge([],i.childNodes)));var r,i,o},S.fn.load=function(e,t,n){var r,i,o,a=this,s=e.indexOf(" ");return-1").append(S.parseHTML(e)).find(r):e)}).always(n&&function(e,t){a.each(function(){n.apply(this,o||[e.responseText,t,e])})}),this},S.expr.pseudos.animated=function(t){return S.grep(S.timers,function(e){return t===e.elem}).length},S.offset={setOffset:function(e,t,n){var r,i,o,a,s,u,l=S.css(e,"position"),c=S(e),f={};"static"===l&&(e.style.position="relative"),s=c.offset(),o=S.css(e,"top"),u=S.css(e,"left"),("absolute"===l||"fixed"===l)&&-1<(o+u).indexOf("auto")?(a=(r=c.position()).top,i=r.left):(a=parseFloat(o)||0,i=parseFloat(u)||0),m(t)&&(t=t.call(e,n,S.extend({},s))),null!=t.top&&(f.top=t.top-s.top+a),null!=t.left&&(f.left=t.left-s.left+i),"using"in t?t.using.call(e,f):c.css(f)}},S.fn.extend({offset:function(t){if(arguments.length)return void 0===t?this:this.each(function(e){S.offset.setOffset(this,t,e)});var e,n,r=this[0];return r?r.getClientRects().length?(e=r.getBoundingClientRect(),n=r.ownerDocument.defaultView,{top:e.top+n.pageYOffset,left:e.left+n.pageXOffset}):{top:0,left:0}:void 0},position:function(){if(this[0]){var e,t,n,r=this[0],i={top:0,left:0};if("fixed"===S.css(r,"position"))t=r.getBoundingClientRect();else{t=this.offset(),n=r.ownerDocument,e=r.offsetParent||n.documentElement;while(e&&(e===n.body||e===n.documentElement)&&"static"===S.css(e,"position"))e=e.parentNode;e&&e!==r&&1===e.nodeType&&((i=S(e).offset()).top+=S.css(e,"borderTopWidth",!0),i.left+=S.css(e,"borderLeftWidth",!0))}return{top:t.top-i.top-S.css(r,"marginTop",!0),left:t.left-i.left-S.css(r,"marginLeft",!0)}}},offsetParent:function(){return this.map(function(){var e=this.offsetParent;while(e&&"static"===S.css(e,"position"))e=e.offsetParent;return e||re})}}),S.each({scrollLeft:"pageXOffset",scrollTop:"pageYOffset"},function(t,i){var o="pageYOffset"===i;S.fn[t]=function(e){return $(this,function(e,t,n){var r;if(x(e)?r=e:9===e.nodeType&&(r=e.defaultView),void 0===n)return r?r[i]:e[t];r?r.scrollTo(o?r.pageXOffset:n,o?n:r.pageYOffset):e[t]=n},t,e,arguments.length)}}),S.each(["top","left"],function(e,n){S.cssHooks[n]=Fe(y.pixelPosition,function(e,t){if(t)return t=We(e,n),Pe.test(t)?S(e).position()[n]+"px":t})}),S.each({Height:"height",Width:"width"},function(a,s){S.each({padding:"inner"+a,content:s,"":"outer"+a},function(r,o){S.fn[o]=function(e,t){var n=arguments.length&&(r||"boolean"!=typeof e),i=r||(!0===e||!0===t?"margin":"border");return $(this,function(e,t,n){var r;return x(e)?0===o.indexOf("outer")?e["inner"+a]:e.document.documentElement["client"+a]:9===e.nodeType?(r=e.documentElement,Math.max(e.body["scroll"+a],r["scroll"+a],e.body["offset"+a],r["offset"+a],r["client"+a])):void 0===n?S.css(e,t,i):S.style(e,t,n,i)},s,n?e:void 0,n)}})}),S.each(["ajaxStart","ajaxStop","ajaxComplete","ajaxError","ajaxSuccess","ajaxSend"],function(e,t){S.fn[t]=function(e){return this.on(t,e)}}),S.fn.extend({bind:function(e,t,n){return this.on(e,null,t,n)},unbind:function(e,t){return this.off(e,null,t)},delegate:function(e,t,n,r){return this.on(t,e,n,r)},undelegate:function(e,t,n){return 1===arguments.length?this.off(e,"**"):this.off(t,e||"**",n)},hover:function(e,t){return this.mouseenter(e).mouseleave(t||e)}}),S.each("blur focus focusin focusout resize scroll click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup contextmenu".split(" "),function(e,n){S.fn[n]=function(e,t){return 0",d.insertBefore(c.lastChild,d.firstChild)}function d(){var a=y.elements;return"string"==typeof a?a.split(" "):a}function e(a,b){var c=y.elements;"string"!=typeof c&&(c=c.join(" ")),"string"!=typeof a&&(a=a.join(" ")),y.elements=c+" "+a,j(b)}function f(a){var b=x[a[v]];return b||(b={},w++,a[v]=w,x[w]=b),b}function g(a,c,d){if(c||(c=b),q)return c.createElement(a);d||(d=f(c));var e;return e=d.cache[a]?d.cache[a].cloneNode():u.test(a)?(d.cache[a]=d.createElem(a)).cloneNode():d.createElem(a),!e.canHaveChildren||t.test(a)||e.tagUrn?e:d.frag.appendChild(e)}function h(a,c){if(a||(a=b),q)return a.createDocumentFragment();c=c||f(a);for(var e=c.frag.cloneNode(),g=0,h=d(),i=h.length;i>g;g++)e.createElement(h[g]);return e}function i(a,b){b.cache||(b.cache={},b.createElem=a.createElement,b.createFrag=a.createDocumentFragment,b.frag=b.createFrag()),a.createElement=function(c){return y.shivMethods?g(c,a,b):b.createElem(c)},a.createDocumentFragment=Function("h,f","return function(){var n=f.cloneNode(),c=n.createElement;h.shivMethods&&("+d().join().replace(/[\w\-:]+/g,function(a){return b.createElem(a),b.frag.createElement(a),'c("'+a+'")'})+");return n}")(y,b.frag)}function j(a){a||(a=b);var d=f(a);return!y.shivCSS||p||d.hasCSS||(d.hasCSS=!!c(a,"article,aside,dialog,figcaption,figure,footer,header,hgroup,main,nav,section{display:block}mark{background:#FF0;color:#000}template{display:none}")),q||i(a,d),a}function k(a){for(var b,c=a.getElementsByTagName("*"),e=c.length,f=RegExp("^(?:"+d().join("|")+")$","i"),g=[];e--;)b=c[e],f.test(b.nodeName)&&g.push(b.applyElement(l(b)));return g}function l(a){for(var b,c=a.attributes,d=c.length,e=a.ownerDocument.createElement(A+":"+a.nodeName);d--;)b=c[d],b.specified&&e.setAttribute(b.nodeName,b.nodeValue);return e.style.cssText=a.style.cssText,e}function m(a){for(var b,c=a.split("{"),e=c.length,f=RegExp("(^|[\\s,>+~])("+d().join("|")+")(?=[[\\s,>+~#.:]|$)","gi"),g="$1"+A+"\\:$2";e--;)b=c[e]=c[e].split("}"),b[b.length-1]=b[b.length-1].replace(f,g),c[e]=b.join("}");return c.join("{")}function n(a){for(var b=a.length;b--;)a[b].removeNode()}function o(a){function b(){clearTimeout(g._removeSheetTimer),d&&d.removeNode(!0),d=null}var d,e,g=f(a),h=a.namespaces,i=a.parentWindow;return!B||a.printShived?a:("undefined"==typeof h[A]&&h.add(A),i.attachEvent("onbeforeprint",function(){b();for(var f,g,h,i=a.styleSheets,j=[],l=i.length,n=Array(l);l--;)n[l]=i[l];for(;h=n.pop();)if(!h.disabled&&z.test(h.media)){try{f=h.imports,g=f.length}catch(o){g=0}for(l=0;g>l;l++)n.push(f[l]);try{j.push(h.cssText)}catch(o){}}j=m(j.reverse().join("")),e=k(a),d=c(a,j)}),i.attachEvent("onafterprint",function(){n(e),clearTimeout(g._removeSheetTimer),g._removeSheetTimer=setTimeout(b,500)}),a.printShived=!0,a)}var p,q,r="3.7.3",s=a.html5||{},t=/^<|^(?:button|map|select|textarea|object|iframe|option|optgroup)$/i,u=/^(?:a|b|code|div|fieldset|h1|h2|h3|h4|h5|h6|i|label|li|ol|p|q|span|strong|style|table|tbody|td|th|tr|ul)$/i,v="_html5shiv",w=0,x={};!function(){try{var a=b.createElement("a");a.innerHTML="",p="hidden"in a,q=1==a.childNodes.length||function(){b.createElement("a");var a=b.createDocumentFragment();return"undefined"==typeof a.cloneNode||"undefined"==typeof a.createDocumentFragment||"undefined"==typeof a.createElement}()}catch(c){p=!0,q=!0}}();var y={elements:s.elements||"abbr article aside audio bdi canvas data datalist details dialog figcaption figure footer header hgroup main mark meter nav output picture progress section summary template time video",version:r,shivCSS:s.shivCSS!==!1,supportsUnknownElements:q,shivMethods:s.shivMethods!==!1,type:"default",shivDocument:j,createElement:g,createDocumentFragment:h,addElements:e};a.html5=y,j(b);var z=/^$|\b(?:all|print)\b/,A="html5shiv",B=!q&&function(){var c=b.documentElement;return!("undefined"==typeof b.namespaces||"undefined"==typeof b.parentWindow||"undefined"==typeof c.applyElement||"undefined"==typeof c.removeNode||"undefined"==typeof a.attachEvent)}();y.type+=" print",y.shivPrint=o,o(b),"object"==typeof module&&module.exports&&(module.exports=y)}("undefined"!=typeof window?window:this,document); \ No newline at end of file diff --git a/docs/build/html/_static/js/html5shiv.min.js b/docs/build/html/_static/js/html5shiv.min.js deleted file mode 100644 index cd1c674f..00000000 --- a/docs/build/html/_static/js/html5shiv.min.js +++ /dev/null @@ -1,4 +0,0 @@ -/** -* @preserve HTML5 Shiv 3.7.3 | @afarkas @jdalton @jon_neal @rem | MIT/GPL2 Licensed -*/ -!function(a,b){function c(a,b){var c=a.createElement("p"),d=a.getElementsByTagName("head")[0]||a.documentElement;return c.innerHTML="x",d.insertBefore(c.lastChild,d.firstChild)}function d(){var a=t.elements;return"string"==typeof a?a.split(" "):a}function e(a,b){var c=t.elements;"string"!=typeof c&&(c=c.join(" ")),"string"!=typeof a&&(a=a.join(" ")),t.elements=c+" "+a,j(b)}function f(a){var b=s[a[q]];return b||(b={},r++,a[q]=r,s[r]=b),b}function g(a,c,d){if(c||(c=b),l)return c.createElement(a);d||(d=f(c));var e;return e=d.cache[a]?d.cache[a].cloneNode():p.test(a)?(d.cache[a]=d.createElem(a)).cloneNode():d.createElem(a),!e.canHaveChildren||o.test(a)||e.tagUrn?e:d.frag.appendChild(e)}function h(a,c){if(a||(a=b),l)return a.createDocumentFragment();c=c||f(a);for(var e=c.frag.cloneNode(),g=0,h=d(),i=h.length;i>g;g++)e.createElement(h[g]);return e}function i(a,b){b.cache||(b.cache={},b.createElem=a.createElement,b.createFrag=a.createDocumentFragment,b.frag=b.createFrag()),a.createElement=function(c){return t.shivMethods?g(c,a,b):b.createElem(c)},a.createDocumentFragment=Function("h,f","return function(){var n=f.cloneNode(),c=n.createElement;h.shivMethods&&("+d().join().replace(/[\w\-:]+/g,function(a){return b.createElem(a),b.frag.createElement(a),'c("'+a+'")'})+");return n}")(t,b.frag)}function j(a){a||(a=b);var d=f(a);return!t.shivCSS||k||d.hasCSS||(d.hasCSS=!!c(a,"article,aside,dialog,figcaption,figure,footer,header,hgroup,main,nav,section{display:block}mark{background:#FF0;color:#000}template{display:none}")),l||i(a,d),a}var k,l,m="3.7.3-pre",n=a.html5||{},o=/^<|^(?:button|map|select|textarea|object|iframe|option|optgroup)$/i,p=/^(?:a|b|code|div|fieldset|h1|h2|h3|h4|h5|h6|i|label|li|ol|p|q|span|strong|style|table|tbody|td|th|tr|ul)$/i,q="_html5shiv",r=0,s={};!function(){try{var a=b.createElement("a");a.innerHTML="",k="hidden"in a,l=1==a.childNodes.length||function(){b.createElement("a");var a=b.createDocumentFragment();return"undefined"==typeof a.cloneNode||"undefined"==typeof a.createDocumentFragment||"undefined"==typeof a.createElement}()}catch(c){k=!0,l=!0}}();var t={elements:n.elements||"abbr article aside audio bdi canvas data datalist details dialog figcaption figure footer header hgroup main mark meter nav output picture progress section summary template time video",version:m,shivCSS:n.shivCSS!==!1,supportsUnknownElements:l,shivMethods:n.shivMethods!==!1,type:"default",shivDocument:j,createElement:g,createDocumentFragment:h,addElements:e};a.html5=t,j(b),"object"==typeof module&&module.exports&&(module.exports=t)}("undefined"!=typeof window?window:this,document); \ No newline at end of file diff --git a/docs/build/html/_static/js/theme.js b/docs/build/html/_static/js/theme.js deleted file mode 100644 index 1fddb6ee..00000000 --- a/docs/build/html/_static/js/theme.js +++ /dev/null @@ -1 +0,0 @@ -!function(n){var e={};function t(i){if(e[i])return e[i].exports;var o=e[i]={i:i,l:!1,exports:{}};return n[i].call(o.exports,o,o.exports,t),o.l=!0,o.exports}t.m=n,t.c=e,t.d=function(n,e,i){t.o(n,e)||Object.defineProperty(n,e,{enumerable:!0,get:i})},t.r=function(n){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(n,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(n,"__esModule",{value:!0})},t.t=function(n,e){if(1&e&&(n=t(n)),8&e)return n;if(4&e&&"object"==typeof n&&n&&n.__esModule)return n;var i=Object.create(null);if(t.r(i),Object.defineProperty(i,"default",{enumerable:!0,value:n}),2&e&&"string"!=typeof n)for(var o in n)t.d(i,o,function(e){return n[e]}.bind(null,o));return i},t.n=function(n){var e=n&&n.__esModule?function(){return n.default}:function(){return n};return t.d(e,"a",e),e},t.o=function(n,e){return Object.prototype.hasOwnProperty.call(n,e)},t.p="",t(t.s=0)}([function(n,e,t){t(1),n.exports=t(3)},function(n,e,t){(function(){var e="undefined"!=typeof window?window.jQuery:t(2);n.exports.ThemeNav={navBar:null,win:null,winScroll:!1,winResize:!1,linkScroll:!1,winPosition:0,winHeight:null,docHeight:null,isRunning:!1,enable:function(n){var t=this;void 0===n&&(n=!0),t.isRunning||(t.isRunning=!0,e((function(e){t.init(e),t.reset(),t.win.on("hashchange",t.reset),n&&t.win.on("scroll",(function(){t.linkScroll||t.winScroll||(t.winScroll=!0,requestAnimationFrame((function(){t.onScroll()})))})),t.win.on("resize",(function(){t.winResize||(t.winResize=!0,requestAnimationFrame((function(){t.onResize()})))})),t.onResize()})))},enableSticky:function(){this.enable(!0)},init:function(n){n(document);var e=this;this.navBar=n("div.wy-side-scroll:first"),this.win=n(window),n(document).on("click","[data-toggle='wy-nav-top']",(function(){n("[data-toggle='wy-nav-shift']").toggleClass("shift"),n("[data-toggle='rst-versions']").toggleClass("shift")})).on("click",".wy-menu-vertical .current ul li a",(function(){var t=n(this);n("[data-toggle='wy-nav-shift']").removeClass("shift"),n("[data-toggle='rst-versions']").toggleClass("shift"),e.toggleCurrent(t),e.hashChange()})).on("click","[data-toggle='rst-current-version']",(function(){n("[data-toggle='rst-versions']").toggleClass("shift-up")})),n("table.docutils:not(.field-list,.footnote,.citation)").wrap("
"),n("table.docutils.footnote").wrap("
"),n("table.docutils.citation").wrap("
"),n(".wy-menu-vertical ul").not(".simple").siblings("a").each((function(){var t=n(this);expand=n(''),expand.on("click",(function(n){return e.toggleCurrent(t),n.stopPropagation(),!1})),t.prepend(expand)}))},reset:function(){var n=encodeURI(window.location.hash)||"#";try{var e=$(".wy-menu-vertical"),t=e.find('[href="'+n+'"]');if(0===t.length){var i=$('.document [id="'+n.substring(1)+'"]').closest("div.section");0===(t=e.find('[href="#'+i.attr("id")+'"]')).length&&(t=e.find('[href="#"]'))}if(t.length>0){$(".wy-menu-vertical .current").removeClass("current").attr("aria-expanded","false"),t.addClass("current").attr("aria-expanded","true"),t.closest("li.toctree-l1").parent().addClass("current").attr("aria-expanded","true");for(let n=1;n<=10;n++)t.closest("li.toctree-l"+n).addClass("current").attr("aria-expanded","true");t[0].scrollIntoView()}}catch(n){console.log("Error expanding nav for anchor",n)}},onScroll:function(){this.winScroll=!1;var n=this.win.scrollTop(),e=n+this.winHeight,t=this.navBar.scrollTop()+(n-this.winPosition);n<0||e>this.docHeight||(this.navBar.scrollTop(t),this.winPosition=n)},onResize:function(){this.winResize=!1,this.winHeight=this.win.height(),this.docHeight=$(document).height()},hashChange:function(){this.linkScroll=!0,this.win.one("hashchange",(function(){this.linkScroll=!1}))},toggleCurrent:function(n){var e=n.closest("li");e.siblings("li.current").removeClass("current").attr("aria-expanded","false"),e.siblings().find("li.current").removeClass("current").attr("aria-expanded","false");var t=e.find("> ul li");t.length&&(t.removeClass("current").attr("aria-expanded","false"),e.toggleClass("current").attr("aria-expanded",(function(n,e){return"true"==e?"false":"true"})))}},"undefined"!=typeof window&&(window.SphinxRtdTheme={Navigation:n.exports.ThemeNav,StickyNav:n.exports.ThemeNav}),function(){for(var n=0,e=["ms","moz","webkit","o"],t=0;t0 - var meq1 = "^(" + C + ")?" + V + C + "(" + V + ")?$"; // [C]VC[V] is m=1 - var mgr1 = "^(" + C + ")?" + V + C + V + C; // [C]VCVC... is m>1 - var s_v = "^(" + C + ")?" + v; // vowel in stem - - this.stemWord = function (w) { - var stem; - var suffix; - var firstch; - var origword = w; - - if (w.length < 3) - return w; - - var re; - var re2; - var re3; - var re4; - - firstch = w.substr(0,1); - if (firstch == "y") - w = firstch.toUpperCase() + w.substr(1); - - // Step 1a - re = /^(.+?)(ss|i)es$/; - re2 = /^(.+?)([^s])s$/; - - if (re.test(w)) - w = w.replace(re,"$1$2"); - else if (re2.test(w)) - w = w.replace(re2,"$1$2"); - - // Step 1b - re = /^(.+?)eed$/; - re2 = /^(.+?)(ed|ing)$/; - if (re.test(w)) { - var fp = re.exec(w); - re = new RegExp(mgr0); - if (re.test(fp[1])) { - re = /.$/; - w = w.replace(re,""); - } - } - else if (re2.test(w)) { - var fp = re2.exec(w); - stem = fp[1]; - re2 = new RegExp(s_v); - if (re2.test(stem)) { - w = stem; - re2 = /(at|bl|iz)$/; - re3 = new RegExp("([^aeiouylsz])\\1$"); - re4 = new RegExp("^" + C + v + "[^aeiouwxy]$"); - if (re2.test(w)) - w = w + "e"; - else if (re3.test(w)) { - re = /.$/; - w = w.replace(re,""); - } - else if (re4.test(w)) - w = w + "e"; - } - } - - // Step 1c - re = /^(.+?)y$/; - if (re.test(w)) { - var fp = re.exec(w); - stem = fp[1]; - re = new RegExp(s_v); - if (re.test(stem)) - w = stem + "i"; - } - - // Step 2 - re = /^(.+?)(ational|tional|enci|anci|izer|bli|alli|entli|eli|ousli|ization|ation|ator|alism|iveness|fulness|ousness|aliti|iviti|biliti|logi)$/; - if (re.test(w)) { - var fp = re.exec(w); - stem = fp[1]; - suffix = fp[2]; - re = new RegExp(mgr0); - if (re.test(stem)) - w = stem + step2list[suffix]; - } - - // Step 3 - re = /^(.+?)(icate|ative|alize|iciti|ical|ful|ness)$/; - if (re.test(w)) { - var fp = re.exec(w); - stem = fp[1]; - suffix = fp[2]; - re = new RegExp(mgr0); - if (re.test(stem)) - w = stem + step3list[suffix]; - } - - // Step 4 - re = /^(.+?)(al|ance|ence|er|ic|able|ible|ant|ement|ment|ent|ou|ism|ate|iti|ous|ive|ize)$/; - re2 = /^(.+?)(s|t)(ion)$/; - if (re.test(w)) { - var fp = re.exec(w); - stem = fp[1]; - re = new RegExp(mgr1); - if (re.test(stem)) - w = stem; - } - else if (re2.test(w)) { - var fp = re2.exec(w); - stem = fp[1] + fp[2]; - re2 = new RegExp(mgr1); - if (re2.test(stem)) - w = stem; - } - - // Step 5 - re = /^(.+?)e$/; - if (re.test(w)) { - var fp = re.exec(w); - stem = fp[1]; - re = new RegExp(mgr1); - re2 = new RegExp(meq1); - re3 = new RegExp("^" + C + v + "[^aeiouwxy]$"); - if (re.test(stem) || (re2.test(stem) && !(re3.test(stem)))) - w = stem; - } - re = /ll$/; - re2 = new RegExp(mgr1); - if (re.test(w) && re2.test(w)) { - re = /.$/; - w = w.replace(re,""); - } - - // and turn initial Y back to y - if (firstch == "y") - w = firstch.toLowerCase() + w.substr(1); - return w; - } -} - diff --git a/docs/build/html/_static/minus.png b/docs/build/html/_static/minus.png deleted file mode 100644 index d96755fd..00000000 Binary files a/docs/build/html/_static/minus.png and /dev/null differ diff --git a/docs/build/html/_static/plus.png b/docs/build/html/_static/plus.png deleted file mode 100644 index 7107cec9..00000000 Binary files a/docs/build/html/_static/plus.png and /dev/null differ diff --git a/docs/build/html/_static/pygments.css b/docs/build/html/_static/pygments.css deleted file mode 100644 index 08bec689..00000000 --- a/docs/build/html/_static/pygments.css +++ /dev/null @@ -1,74 +0,0 @@ -pre { line-height: 125%; } -td.linenos .normal { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; } -span.linenos { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; } -td.linenos .special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; } -span.linenos.special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; } -.highlight .hll { background-color: #ffffcc } -.highlight { background: #f8f8f8; } -.highlight .c { color: #3D7B7B; font-style: italic } /* Comment */ -.highlight .err { border: 1px solid #FF0000 } /* Error */ -.highlight .k { color: #008000; font-weight: bold } /* Keyword */ -.highlight .o { color: #666666 } /* Operator */ -.highlight .ch { color: #3D7B7B; font-style: italic } /* Comment.Hashbang */ -.highlight .cm { color: #3D7B7B; font-style: italic } /* Comment.Multiline */ -.highlight .cp { color: #9C6500 } /* Comment.Preproc */ -.highlight .cpf { color: #3D7B7B; font-style: italic } /* Comment.PreprocFile */ -.highlight .c1 { color: #3D7B7B; font-style: italic } /* Comment.Single */ -.highlight .cs { color: #3D7B7B; font-style: italic } /* Comment.Special */ -.highlight .gd { color: #A00000 } /* Generic.Deleted */ -.highlight .ge { font-style: italic } /* Generic.Emph */ -.highlight .gr { color: #E40000 } /* Generic.Error */ -.highlight .gh { color: #000080; font-weight: bold } /* Generic.Heading */ -.highlight .gi { color: #008400 } /* Generic.Inserted */ -.highlight .go { color: #717171 } /* Generic.Output */ -.highlight .gp { color: #000080; font-weight: bold } /* Generic.Prompt */ -.highlight .gs { font-weight: bold } /* Generic.Strong */ -.highlight .gu { color: #800080; font-weight: bold } /* Generic.Subheading */ -.highlight .gt { color: #0044DD } /* Generic.Traceback */ -.highlight .kc { color: #008000; font-weight: bold } /* Keyword.Constant */ -.highlight .kd { color: #008000; font-weight: bold } /* Keyword.Declaration */ -.highlight .kn { color: #008000; font-weight: bold } /* Keyword.Namespace */ -.highlight .kp { color: #008000 } /* Keyword.Pseudo */ -.highlight .kr { color: #008000; font-weight: bold } /* Keyword.Reserved */ -.highlight .kt { color: #B00040 } /* Keyword.Type */ -.highlight .m { color: #666666 } /* Literal.Number */ -.highlight .s { color: #BA2121 } /* Literal.String */ -.highlight .na { color: #687822 } /* Name.Attribute */ -.highlight .nb { color: #008000 } /* Name.Builtin */ -.highlight .nc { color: #0000FF; font-weight: bold } /* Name.Class */ -.highlight .no { color: #880000 } /* Name.Constant */ -.highlight .nd { color: #AA22FF } /* Name.Decorator */ -.highlight .ni { color: #717171; font-weight: bold } /* Name.Entity */ -.highlight .ne { color: #CB3F38; font-weight: bold } /* Name.Exception */ -.highlight .nf { color: #0000FF } /* Name.Function */ -.highlight .nl { color: #767600 } /* Name.Label */ -.highlight .nn { color: #0000FF; font-weight: bold } /* Name.Namespace */ -.highlight .nt { color: #008000; font-weight: bold } /* Name.Tag */ -.highlight .nv { color: #19177C } /* Name.Variable */ -.highlight .ow { color: #AA22FF; font-weight: bold } /* Operator.Word */ -.highlight .w { color: #bbbbbb } /* Text.Whitespace */ -.highlight .mb { color: #666666 } /* Literal.Number.Bin */ -.highlight .mf { color: #666666 } /* Literal.Number.Float */ -.highlight .mh { color: #666666 } /* Literal.Number.Hex */ -.highlight .mi { color: #666666 } /* Literal.Number.Integer */ -.highlight .mo { color: #666666 } /* Literal.Number.Oct */ -.highlight .sa { color: #BA2121 } /* Literal.String.Affix */ -.highlight .sb { color: #BA2121 } /* Literal.String.Backtick */ -.highlight .sc { color: #BA2121 } /* Literal.String.Char */ -.highlight .dl { color: #BA2121 } /* Literal.String.Delimiter */ -.highlight .sd { color: #BA2121; font-style: italic } /* Literal.String.Doc */ -.highlight .s2 { color: #BA2121 } /* Literal.String.Double */ -.highlight .se { color: #AA5D1F; font-weight: bold } /* Literal.String.Escape */ -.highlight .sh { color: #BA2121 } /* Literal.String.Heredoc */ -.highlight .si { color: #A45A77; font-weight: bold } /* Literal.String.Interpol */ -.highlight .sx { color: #008000 } /* Literal.String.Other */ -.highlight .sr { color: #A45A77 } /* Literal.String.Regex */ -.highlight .s1 { color: #BA2121 } /* Literal.String.Single */ -.highlight .ss { color: #19177C } /* Literal.String.Symbol */ -.highlight .bp { color: #008000 } /* Name.Builtin.Pseudo */ -.highlight .fm { color: #0000FF } /* Name.Function.Magic */ -.highlight .vc { color: #19177C } /* Name.Variable.Class */ -.highlight .vg { color: #19177C } /* Name.Variable.Global */ -.highlight .vi { color: #19177C } /* Name.Variable.Instance */ -.highlight .vm { color: #19177C } /* Name.Variable.Magic */ -.highlight .il { color: #666666 } /* Literal.Number.Integer.Long */ \ No newline at end of file diff --git a/docs/build/html/_static/reeds-logo.png b/docs/build/html/_static/reeds-logo.png deleted file mode 100644 index aa5ab2f4..00000000 Binary files a/docs/build/html/_static/reeds-logo.png and /dev/null differ diff --git a/docs/build/html/_static/searchtools.js b/docs/build/html/_static/searchtools.js deleted file mode 100644 index 92da3f8b..00000000 --- a/docs/build/html/_static/searchtools.js +++ /dev/null @@ -1,619 +0,0 @@ -/* - * searchtools.js - * ~~~~~~~~~~~~~~~~ - * - * Sphinx JavaScript utilities for the full-text search. - * - * :copyright: Copyright 2007-2024 by the Sphinx team, see AUTHORS. - * :license: BSD, see LICENSE for details. - * - */ -"use strict"; - -/** - * Simple result scoring code. - */ -if (typeof Scorer === "undefined") { - var Scorer = { - // Implement the following function to further tweak the score for each result - // The function takes a result array [docname, title, anchor, descr, score, filename] - // and returns the new score. - /* - score: result => { - const [docname, title, anchor, descr, score, filename] = result - return score - }, - */ - - // query matches the full name of an object - objNameMatch: 11, - // or matches in the last dotted part of the object name - objPartialMatch: 6, - // Additive scores depending on the priority of the object - objPrio: { - 0: 15, // used to be importantResults - 1: 5, // used to be objectResults - 2: -5, // used to be unimportantResults - }, - // Used when the priority is not in the mapping. - objPrioDefault: 0, - - // query found in title - title: 15, - partialTitle: 7, - // query found in terms - term: 5, - partialTerm: 2, - }; -} - -const _removeChildren = (element) => { - while (element && element.lastChild) element.removeChild(element.lastChild); -}; - -/** - * See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions#escaping - */ -const _escapeRegExp = (string) => - string.replace(/[.*+\-?^${}()|[\]\\]/g, "\\$&"); // $& means the whole matched string - -const _displayItem = (item, searchTerms, highlightTerms) => { - const docBuilder = DOCUMENTATION_OPTIONS.BUILDER; - const docFileSuffix = DOCUMENTATION_OPTIONS.FILE_SUFFIX; - const docLinkSuffix = DOCUMENTATION_OPTIONS.LINK_SUFFIX; - const showSearchSummary = DOCUMENTATION_OPTIONS.SHOW_SEARCH_SUMMARY; - const contentRoot = document.documentElement.dataset.content_root; - - const [docName, title, anchor, descr, score, _filename] = item; - - let listItem = document.createElement("li"); - let requestUrl; - let linkUrl; - if (docBuilder === "dirhtml") { - // dirhtml builder - let dirname = docName + "/"; - if (dirname.match(/\/index\/$/)) - dirname = dirname.substring(0, dirname.length - 6); - else if (dirname === "index/") dirname = ""; - requestUrl = contentRoot + dirname; - linkUrl = requestUrl; - } else { - // normal html builders - requestUrl = contentRoot + docName + docFileSuffix; - linkUrl = docName + docLinkSuffix; - } - let linkEl = listItem.appendChild(document.createElement("a")); - linkEl.href = linkUrl + anchor; - linkEl.dataset.score = score; - linkEl.innerHTML = title; - if (descr) { - listItem.appendChild(document.createElement("span")).innerHTML = - " (" + descr + ")"; - // highlight search terms in the description - if (SPHINX_HIGHLIGHT_ENABLED) // set in sphinx_highlight.js - highlightTerms.forEach((term) => _highlightText(listItem, term, "highlighted")); - } - else if (showSearchSummary) - fetch(requestUrl) - .then((responseData) => responseData.text()) - .then((data) => { - if (data) - listItem.appendChild( - Search.makeSearchSummary(data, searchTerms, anchor) - ); - // highlight search terms in the summary - if (SPHINX_HIGHLIGHT_ENABLED) // set in sphinx_highlight.js - highlightTerms.forEach((term) => _highlightText(listItem, term, "highlighted")); - }); - Search.output.appendChild(listItem); -}; -const _finishSearch = (resultCount) => { - Search.stopPulse(); - Search.title.innerText = _("Search Results"); - if (!resultCount) - Search.status.innerText = Documentation.gettext( - "Your search did not match any documents. Please make sure that all words are spelled correctly and that you've selected enough categories." - ); - else - Search.status.innerText = _( - "Search finished, found ${resultCount} page(s) matching the search query." - ).replace('${resultCount}', resultCount); -}; -const _displayNextItem = ( - results, - resultCount, - searchTerms, - highlightTerms, -) => { - // results left, load the summary and display it - // this is intended to be dynamic (don't sub resultsCount) - if (results.length) { - _displayItem(results.pop(), searchTerms, highlightTerms); - setTimeout( - () => _displayNextItem(results, resultCount, searchTerms, highlightTerms), - 5 - ); - } - // search finished, update title and status message - else _finishSearch(resultCount); -}; -// Helper function used by query() to order search results. -// Each input is an array of [docname, title, anchor, descr, score, filename]. -// Order the results by score (in opposite order of appearance, since the -// `_displayNextItem` function uses pop() to retrieve items) and then alphabetically. -const _orderResultsByScoreThenName = (a, b) => { - const leftScore = a[4]; - const rightScore = b[4]; - if (leftScore === rightScore) { - // same score: sort alphabetically - const leftTitle = a[1].toLowerCase(); - const rightTitle = b[1].toLowerCase(); - if (leftTitle === rightTitle) return 0; - return leftTitle > rightTitle ? -1 : 1; // inverted is intentional - } - return leftScore > rightScore ? 1 : -1; -}; - -/** - * Default splitQuery function. Can be overridden in ``sphinx.search`` with a - * custom function per language. - * - * The regular expression works by splitting the string on consecutive characters - * that are not Unicode letters, numbers, underscores, or emoji characters. - * This is the same as ``\W+`` in Python, preserving the surrogate pair area. - */ -if (typeof splitQuery === "undefined") { - var splitQuery = (query) => query - .split(/[^\p{Letter}\p{Number}_\p{Emoji_Presentation}]+/gu) - .filter(term => term) // remove remaining empty strings -} - -/** - * Search Module - */ -const Search = { - _index: null, - _queued_query: null, - _pulse_status: -1, - - htmlToText: (htmlString, anchor) => { - const htmlElement = new DOMParser().parseFromString(htmlString, 'text/html'); - for (const removalQuery of [".headerlinks", "script", "style"]) { - htmlElement.querySelectorAll(removalQuery).forEach((el) => { el.remove() }); - } - if (anchor) { - const anchorContent = htmlElement.querySelector(`[role="main"] ${anchor}`); - if (anchorContent) return anchorContent.textContent; - - console.warn( - `Anchored content block not found. Sphinx search tries to obtain it via DOM query '[role=main] ${anchor}'. Check your theme or template.` - ); - } - - // if anchor not specified or not found, fall back to main content - const docContent = htmlElement.querySelector('[role="main"]'); - if (docContent) return docContent.textContent; - - console.warn( - "Content block not found. Sphinx search tries to obtain it via DOM query '[role=main]'. Check your theme or template." - ); - return ""; - }, - - init: () => { - const query = new URLSearchParams(window.location.search).get("q"); - document - .querySelectorAll('input[name="q"]') - .forEach((el) => (el.value = query)); - if (query) Search.performSearch(query); - }, - - loadIndex: (url) => - (document.body.appendChild(document.createElement("script")).src = url), - - setIndex: (index) => { - Search._index = index; - if (Search._queued_query !== null) { - const query = Search._queued_query; - Search._queued_query = null; - Search.query(query); - } - }, - - hasIndex: () => Search._index !== null, - - deferQuery: (query) => (Search._queued_query = query), - - stopPulse: () => (Search._pulse_status = -1), - - startPulse: () => { - if (Search._pulse_status >= 0) return; - - const pulse = () => { - Search._pulse_status = (Search._pulse_status + 1) % 4; - Search.dots.innerText = ".".repeat(Search._pulse_status); - if (Search._pulse_status >= 0) window.setTimeout(pulse, 500); - }; - pulse(); - }, - - /** - * perform a search for something (or wait until index is loaded) - */ - performSearch: (query) => { - // create the required interface elements - const searchText = document.createElement("h2"); - searchText.textContent = _("Searching"); - const searchSummary = document.createElement("p"); - searchSummary.classList.add("search-summary"); - searchSummary.innerText = ""; - const searchList = document.createElement("ul"); - searchList.classList.add("search"); - - const out = document.getElementById("search-results"); - Search.title = out.appendChild(searchText); - Search.dots = Search.title.appendChild(document.createElement("span")); - Search.status = out.appendChild(searchSummary); - Search.output = out.appendChild(searchList); - - const searchProgress = document.getElementById("search-progress"); - // Some themes don't use the search progress node - if (searchProgress) { - searchProgress.innerText = _("Preparing search..."); - } - Search.startPulse(); - - // index already loaded, the browser was quick! - if (Search.hasIndex()) Search.query(query); - else Search.deferQuery(query); - }, - - _parseQuery: (query) => { - // stem the search terms and add them to the correct list - const stemmer = new Stemmer(); - const searchTerms = new Set(); - const excludedTerms = new Set(); - const highlightTerms = new Set(); - const objectTerms = new Set(splitQuery(query.toLowerCase().trim())); - splitQuery(query.trim()).forEach((queryTerm) => { - const queryTermLower = queryTerm.toLowerCase(); - - // maybe skip this "word" - // stopwords array is from language_data.js - if ( - stopwords.indexOf(queryTermLower) !== -1 || - queryTerm.match(/^\d+$/) - ) - return; - - // stem the word - let word = stemmer.stemWord(queryTermLower); - // select the correct list - if (word[0] === "-") excludedTerms.add(word.substr(1)); - else { - searchTerms.add(word); - highlightTerms.add(queryTermLower); - } - }); - - if (SPHINX_HIGHLIGHT_ENABLED) { // set in sphinx_highlight.js - localStorage.setItem("sphinx_highlight_terms", [...highlightTerms].join(" ")) - } - - // console.debug("SEARCH: searching for:"); - // console.info("required: ", [...searchTerms]); - // console.info("excluded: ", [...excludedTerms]); - - return [query, searchTerms, excludedTerms, highlightTerms, objectTerms]; - }, - - /** - * execute search (requires search index to be loaded) - */ - _performSearch: (query, searchTerms, excludedTerms, highlightTerms, objectTerms) => { - const filenames = Search._index.filenames; - const docNames = Search._index.docnames; - const titles = Search._index.titles; - const allTitles = Search._index.alltitles; - const indexEntries = Search._index.indexentries; - - // Collect multiple result groups to be sorted separately and then ordered. - // Each is an array of [docname, title, anchor, descr, score, filename]. - const normalResults = []; - const nonMainIndexResults = []; - - _removeChildren(document.getElementById("search-progress")); - - const queryLower = query.toLowerCase().trim(); - for (const [title, foundTitles] of Object.entries(allTitles)) { - if (title.toLowerCase().trim().includes(queryLower) && (queryLower.length >= title.length/2)) { - for (const [file, id] of foundTitles) { - let score = Math.round(100 * queryLower.length / title.length) - normalResults.push([ - docNames[file], - titles[file] !== title ? `${titles[file]} > ${title}` : title, - id !== null ? "#" + id : "", - null, - score, - filenames[file], - ]); - } - } - } - - // search for explicit entries in index directives - for (const [entry, foundEntries] of Object.entries(indexEntries)) { - if (entry.includes(queryLower) && (queryLower.length >= entry.length/2)) { - for (const [file, id, isMain] of foundEntries) { - const score = Math.round(100 * queryLower.length / entry.length); - const result = [ - docNames[file], - titles[file], - id ? "#" + id : "", - null, - score, - filenames[file], - ]; - if (isMain) { - normalResults.push(result); - } else { - nonMainIndexResults.push(result); - } - } - } - } - - // lookup as object - objectTerms.forEach((term) => - normalResults.push(...Search.performObjectSearch(term, objectTerms)) - ); - - // lookup as search terms in fulltext - normalResults.push(...Search.performTermsSearch(searchTerms, excludedTerms)); - - // let the scorer override scores with a custom scoring function - if (Scorer.score) { - normalResults.forEach((item) => (item[4] = Scorer.score(item))); - nonMainIndexResults.forEach((item) => (item[4] = Scorer.score(item))); - } - - // Sort each group of results by score and then alphabetically by name. - normalResults.sort(_orderResultsByScoreThenName); - nonMainIndexResults.sort(_orderResultsByScoreThenName); - - // Combine the result groups in (reverse) order. - // Non-main index entries are typically arbitrary cross-references, - // so display them after other results. - let results = [...nonMainIndexResults, ...normalResults]; - - // remove duplicate search results - // note the reversing of results, so that in the case of duplicates, the highest-scoring entry is kept - let seen = new Set(); - results = results.reverse().reduce((acc, result) => { - let resultStr = result.slice(0, 4).concat([result[5]]).map(v => String(v)).join(','); - if (!seen.has(resultStr)) { - acc.push(result); - seen.add(resultStr); - } - return acc; - }, []); - - return results.reverse(); - }, - - query: (query) => { - const [searchQuery, searchTerms, excludedTerms, highlightTerms, objectTerms] = Search._parseQuery(query); - const results = Search._performSearch(searchQuery, searchTerms, excludedTerms, highlightTerms, objectTerms); - - // for debugging - //Search.lastresults = results.slice(); // a copy - // console.info("search results:", Search.lastresults); - - // print the results - _displayNextItem(results, results.length, searchTerms, highlightTerms); - }, - - /** - * search for object names - */ - performObjectSearch: (object, objectTerms) => { - const filenames = Search._index.filenames; - const docNames = Search._index.docnames; - const objects = Search._index.objects; - const objNames = Search._index.objnames; - const titles = Search._index.titles; - - const results = []; - - const objectSearchCallback = (prefix, match) => { - const name = match[4] - const fullname = (prefix ? prefix + "." : "") + name; - const fullnameLower = fullname.toLowerCase(); - if (fullnameLower.indexOf(object) < 0) return; - - let score = 0; - const parts = fullnameLower.split("."); - - // check for different match types: exact matches of full name or - // "last name" (i.e. last dotted part) - if (fullnameLower === object || parts.slice(-1)[0] === object) - score += Scorer.objNameMatch; - else if (parts.slice(-1)[0].indexOf(object) > -1) - score += Scorer.objPartialMatch; // matches in last name - - const objName = objNames[match[1]][2]; - const title = titles[match[0]]; - - // If more than one term searched for, we require other words to be - // found in the name/title/description - const otherTerms = new Set(objectTerms); - otherTerms.delete(object); - if (otherTerms.size > 0) { - const haystack = `${prefix} ${name} ${objName} ${title}`.toLowerCase(); - if ( - [...otherTerms].some((otherTerm) => haystack.indexOf(otherTerm) < 0) - ) - return; - } - - let anchor = match[3]; - if (anchor === "") anchor = fullname; - else if (anchor === "-") anchor = objNames[match[1]][1] + "-" + fullname; - - const descr = objName + _(", in ") + title; - - // add custom score for some objects according to scorer - if (Scorer.objPrio.hasOwnProperty(match[2])) - score += Scorer.objPrio[match[2]]; - else score += Scorer.objPrioDefault; - - results.push([ - docNames[match[0]], - fullname, - "#" + anchor, - descr, - score, - filenames[match[0]], - ]); - }; - Object.keys(objects).forEach((prefix) => - objects[prefix].forEach((array) => - objectSearchCallback(prefix, array) - ) - ); - return results; - }, - - /** - * search for full-text terms in the index - */ - performTermsSearch: (searchTerms, excludedTerms) => { - // prepare search - const terms = Search._index.terms; - const titleTerms = Search._index.titleterms; - const filenames = Search._index.filenames; - const docNames = Search._index.docnames; - const titles = Search._index.titles; - - const scoreMap = new Map(); - const fileMap = new Map(); - - // perform the search on the required terms - searchTerms.forEach((word) => { - const files = []; - const arr = [ - { files: terms[word], score: Scorer.term }, - { files: titleTerms[word], score: Scorer.title }, - ]; - // add support for partial matches - if (word.length > 2) { - const escapedWord = _escapeRegExp(word); - if (!terms.hasOwnProperty(word)) { - Object.keys(terms).forEach((term) => { - if (term.match(escapedWord)) - arr.push({ files: terms[term], score: Scorer.partialTerm }); - }); - } - if (!titleTerms.hasOwnProperty(word)) { - Object.keys(titleTerms).forEach((term) => { - if (term.match(escapedWord)) - arr.push({ files: titleTerms[term], score: Scorer.partialTitle }); - }); - } - } - - // no match but word was a required one - if (arr.every((record) => record.files === undefined)) return; - - // found search word in contents - arr.forEach((record) => { - if (record.files === undefined) return; - - let recordFiles = record.files; - if (recordFiles.length === undefined) recordFiles = [recordFiles]; - files.push(...recordFiles); - - // set score for the word in each file - recordFiles.forEach((file) => { - if (!scoreMap.has(file)) scoreMap.set(file, {}); - scoreMap.get(file)[word] = record.score; - }); - }); - - // create the mapping - files.forEach((file) => { - if (!fileMap.has(file)) fileMap.set(file, [word]); - else if (fileMap.get(file).indexOf(word) === -1) fileMap.get(file).push(word); - }); - }); - - // now check if the files don't contain excluded terms - const results = []; - for (const [file, wordList] of fileMap) { - // check if all requirements are matched - - // as search terms with length < 3 are discarded - const filteredTermCount = [...searchTerms].filter( - (term) => term.length > 2 - ).length; - if ( - wordList.length !== searchTerms.size && - wordList.length !== filteredTermCount - ) - continue; - - // ensure that none of the excluded terms is in the search result - if ( - [...excludedTerms].some( - (term) => - terms[term] === file || - titleTerms[term] === file || - (terms[term] || []).includes(file) || - (titleTerms[term] || []).includes(file) - ) - ) - break; - - // select one (max) score for the file. - const score = Math.max(...wordList.map((w) => scoreMap.get(file)[w])); - // add result to the result list - results.push([ - docNames[file], - titles[file], - "", - null, - score, - filenames[file], - ]); - } - return results; - }, - - /** - * helper function to return a node containing the - * search summary for a given text. keywords is a list - * of stemmed words. - */ - makeSearchSummary: (htmlText, keywords, anchor) => { - const text = Search.htmlToText(htmlText, anchor); - if (text === "") return null; - - const textLower = text.toLowerCase(); - const actualStartPosition = [...keywords] - .map((k) => textLower.indexOf(k.toLowerCase())) - .filter((i) => i > -1) - .slice(-1)[0]; - const startWithContext = Math.max(actualStartPosition - 120, 0); - - const top = startWithContext === 0 ? "" : "..."; - const tail = startWithContext + 240 < text.length ? "..." : ""; - - let summary = document.createElement("p"); - summary.classList.add("context"); - summary.textContent = top + text.substr(startWithContext, 240).trim() + tail; - - return summary; - }, -}; - -_ready(Search.init); diff --git a/docs/build/html/_static/sphinx_highlight.js b/docs/build/html/_static/sphinx_highlight.js deleted file mode 100644 index 8a96c69a..00000000 --- a/docs/build/html/_static/sphinx_highlight.js +++ /dev/null @@ -1,154 +0,0 @@ -/* Highlighting utilities for Sphinx HTML documentation. */ -"use strict"; - -const SPHINX_HIGHLIGHT_ENABLED = true - -/** - * highlight a given string on a node by wrapping it in - * span elements with the given class name. - */ -const _highlight = (node, addItems, text, className) => { - if (node.nodeType === Node.TEXT_NODE) { - const val = node.nodeValue; - const parent = node.parentNode; - const pos = val.toLowerCase().indexOf(text); - if ( - pos >= 0 && - !parent.classList.contains(className) && - !parent.classList.contains("nohighlight") - ) { - let span; - - const closestNode = parent.closest("body, svg, foreignObject"); - const isInSVG = closestNode && closestNode.matches("svg"); - if (isInSVG) { - span = document.createElementNS("http://www.w3.org/2000/svg", "tspan"); - } else { - span = document.createElement("span"); - span.classList.add(className); - } - - span.appendChild(document.createTextNode(val.substr(pos, text.length))); - const rest = document.createTextNode(val.substr(pos + text.length)); - parent.insertBefore( - span, - parent.insertBefore( - rest, - node.nextSibling - ) - ); - node.nodeValue = val.substr(0, pos); - /* There may be more occurrences of search term in this node. So call this - * function recursively on the remaining fragment. - */ - _highlight(rest, addItems, text, className); - - if (isInSVG) { - const rect = document.createElementNS( - "http://www.w3.org/2000/svg", - "rect" - ); - const bbox = parent.getBBox(); - rect.x.baseVal.value = bbox.x; - rect.y.baseVal.value = bbox.y; - rect.width.baseVal.value = bbox.width; - rect.height.baseVal.value = bbox.height; - rect.setAttribute("class", className); - addItems.push({ parent: parent, target: rect }); - } - } - } else if (node.matches && !node.matches("button, select, textarea")) { - node.childNodes.forEach((el) => _highlight(el, addItems, text, className)); - } -}; -const _highlightText = (thisNode, text, className) => { - let addItems = []; - _highlight(thisNode, addItems, text, className); - addItems.forEach((obj) => - obj.parent.insertAdjacentElement("beforebegin", obj.target) - ); -}; - -/** - * Small JavaScript module for the documentation. - */ -const SphinxHighlight = { - - /** - * highlight the search words provided in localstorage in the text - */ - highlightSearchWords: () => { - if (!SPHINX_HIGHLIGHT_ENABLED) return; // bail if no highlight - - // get and clear terms from localstorage - const url = new URL(window.location); - const highlight = - localStorage.getItem("sphinx_highlight_terms") - || url.searchParams.get("highlight") - || ""; - localStorage.removeItem("sphinx_highlight_terms") - url.searchParams.delete("highlight"); - window.history.replaceState({}, "", url); - - // get individual terms from highlight string - const terms = highlight.toLowerCase().split(/\s+/).filter(x => x); - if (terms.length === 0) return; // nothing to do - - // There should never be more than one element matching "div.body" - const divBody = document.querySelectorAll("div.body"); - const body = divBody.length ? divBody[0] : document.querySelector("body"); - window.setTimeout(() => { - terms.forEach((term) => _highlightText(body, term, "highlighted")); - }, 10); - - const searchBox = document.getElementById("searchbox"); - if (searchBox === null) return; - searchBox.appendChild( - document - .createRange() - .createContextualFragment( - '

' + - '' + - _("Hide Search Matches") + - "

" - ) - ); - }, - - /** - * helper function to hide the search marks again - */ - hideSearchWords: () => { - document - .querySelectorAll("#searchbox .highlight-link") - .forEach((el) => el.remove()); - document - .querySelectorAll("span.highlighted") - .forEach((el) => el.classList.remove("highlighted")); - localStorage.removeItem("sphinx_highlight_terms") - }, - - initEscapeListener: () => { - // only install a listener if it is really needed - if (!DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS) return; - - document.addEventListener("keydown", (event) => { - // bail for input elements - if (BLACKLISTED_KEY_CONTROL_ELEMENTS.has(document.activeElement.tagName)) return; - // bail with special keys - if (event.shiftKey || event.altKey || event.ctrlKey || event.metaKey) return; - if (DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS && (event.key === "Escape")) { - SphinxHighlight.hideSearchWords(); - event.preventDefault(); - } - }); - }, -}; - -_ready(() => { - /* Do not call highlightSearchWords() when we are on the search page. - * It will highlight words from the *previous* search query. - */ - if (typeof Search === "undefined") SphinxHighlight.highlightSearchWords(); - SphinxHighlight.initEscapeListener(); -}); diff --git a/docs/build/html/additional_model_information.html b/docs/build/html/additional_model_information.html deleted file mode 100644 index 494512ad..00000000 --- a/docs/build/html/additional_model_information.html +++ /dev/null @@ -1,296 +0,0 @@ - - - - - - - Model Switches — ReEDS documentation - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -

#Additional Model Information

-
-

Model Switches

-
-

hourly_process.py

-
-

Switches

-
    -

  • GSw_HourlyNumClusters specifies the maximum number of representative periods.

    • -

  • Two other switches, GSw_HourlyPeakLevel and GSw_HourlyMinRElevel, indicate additional “outlying periods” that can be added (peak-load-containing periods for GSw_HourlyPeakLevel, minimum-average-PV-CF and minimum-average-wind-CF periods for GSw_HourlyMinRElevel). If running the US and both are set to “interconnect”, they add the 3 peak-load days, 3 minimum-wind days, and 3 minimum-PV days by interconnect, resulting in 33+9=42 by default if GSw_HourlyNumClusters=33. These “outlying periods” are only included when using capacity credit (GSw_PRM_CapCredit=1) instead of stress periods (GSw_PRM_CapCredit=0).

    • -

  • When using GSw_HourlyClusterAlgorithm=optimized (the default), then depending on the setting of GSw_HourlyClusterRegionLevel there will be a maximum number of days it needs to reproduce the distribution of load/pv/wind. When GSw_HourlyClusterRegionLevel=transreg (the default), there are 11 regions and 3 features, so it needs ~33 days to reproduce the distribution (like an eigenvalue problem).

    -
      -

    • So turning up GSw_HourlyNumClusters on its own won’t increase the temporal coverage. If you want more temporal coverage, the options are:

      -
        -

      • Switch to GSw_HourlyType=wek, which increases the length of the periods from 1 day to 5 days. If all the other switches are left at their defaults, switching to wek would increase the coverage from 42 days to 5*42=210 days.

        • -

      • Reduce GSw_HourlyClusterRegionLevel to something smaller than transreg (like st), and then increase GSw_HourlyNumClusters

        • -

      • Switch to GSw_HourlyClusteAlgorithm=hierarchical and then increase GSw_HourlyNumClusters (although that’s less desirable, because hierarchical clustering doesn’t do as good of a job of reproducing the actual spatial distribution of CF and load)

        • -

      • Switch to Gsw_HourlyType=year. Although if you’re running for the whole US you’ll need to turn on region aggregation (GSw_RegionResolution=aggreg and GSw_HierarchyFile in [default or agg1, or agg2 or agg3]) for it to solve.

        • -
      -
      • -
    -
    • -

  • GSw_HourlyClusterAlgorithm

    -
      -

    • If set to ‘hierarchical’, then hierarchical clustering is used via

      -
      sklearn.cluster.AgglomerativeClustering(
-    n_clusters=int(sw['GSw_HourlyNumClusters']),
-    affinity='euclidean', linkage='ward')
-
      -
      -
      • -

    • If set to ‘optimized’, then a two-step custom optimization is performed using the hourly_repperiods.optimize_period_weights() and hourly_repperiods.assign_representative_days() functions to minimize the deviation in regional load and PV/wind CF between the weighted representative periods and the full year.

      • -

    • If set to a string containing the substring ‘user’, then instead of optimizing the choice of representative periods for this run, we read them from the inputs/variability/period_szn_user.csv file.

      -
        -

      • The scenario name is in the first column, labeled ‘scenario’. ReEDS will use rows with the same label as GSw_HourlyClusterAlgorithm.

        -
          -

        • So if you want to use the example period:szn map, just set GSw_HourlyClusterAlgorithm=user.

          • -

        • If you want to specify a different period:szn map, then add your mapping at the bottom of inputs/variability/period_szn_user.csv with a unique scenario name in the ‘scenario’ column, and set GSw_HourlyClusterAlgorithm to your unique scenario name, which must contain the substring ‘user’. (For example, I could use a mapping called ‘user_myname_20230130’ by adding my period:szn map to inputs/variability/period_szn_user.csv with ‘user_myname_20230130’ in the ‘scenario’ column and setting GSw_HourlyClusterAlgorithm=user_myname_20230130.)

          • -

        • Make sure the settings for GSw_HourlyType and GSw_HourlyWeatherYears match your user-defined map. For example, if your ‘user_myname_20230130’ map includes 365 representative days for weather year 2012, then set GSw_HourlyType=day and GSw_HourlyWeatherYears=2012.

          • -
        -
        • -
      -
      • -
    -
    • -

  • GSw_PRM_StressThreshold: The default setting of ‘transgrp_10_EUE_sum’ means a threshold of “10 ppm NEUE in each transgrp”, with stress periods selected by the daily sum of EUE within each transgrp.

    -
      -

    • The first argument can be selected from [‘country’, ‘interconnect’, ‘nercr’, ‘transreg’, ‘transgrp’, ‘st’, ‘r’] and specifies the hierarchy level within which to compare RA performance against the threshold.

      • -

    • The second argument can be any float and specifies the RA performance threshold in parts per million [ppm].

      • -

    • The third argument can be ‘NEUE’ or ‘EUE’, specifying which metric to use when selecting stress periods. If set to ‘NEUE’ the model will add stress periods with the largest fraction of dropped load; if set to ‘EUE’ the model will add stress periods with the largest absolute MWh of dropped load.

      • -

    • The fourth argument can be ‘sum’ or ‘max’, specifying whether to add stress periods in order of their daily per-hour max dropped load or by their daily sum of dropped load when selecting stress periods.

      • -

    • If desired you can provide /-delimited entries like ‘transgrp_10_EUE_sum/country_1_EUE_sum’, meaning that each transgrp must have ≤10 ppm NEUE and the country overall must have ≤1 ppm NEUE.

      • -
    -
    • -
-
-
-

Conventions

-
    -

  • Timestamps are formatted as y{year}d{day of year}h{hour of day} in hour-ending format in Eastern Standard Time. The numbering of days begins at 1. For example, the hour from 3am-4am on January 3, 2012 would be indicated as y2012d003h004.

    -
      -

    • When using representative weks (5-day periods), timestamps are instead formatted as y{year}w{wek of year}h{hour of wek}. The numbering of weks begins at 1. In this format, the hour from 3am-4am on January 3, 2012 would be indicated as y2012w001h052.

      • -
    -
    • -

  • Representative and stress periods (indexed as szn within ReEDS) are labeled similarly to timestamps but without the h{hour of day} component…

    -
      -

    • Except stress periods and stress timeslices have an ‘s’ prefix. So if the time period above showed up as a stress period, it would be labeled as h=sy2012d003h004 and szn=sy2012d003 for represntative days (or h=sy2012w001h052 and szn=sy2012w001 for representative weks). Stress periods are modeled using different loads and transmission capacities than representative periods, so they need to be indexed separately.

      • -
    -
    • -
-
-
-
-
-

Troubleshooting

-

This section provides guidance on identifying and resolving common issues encountered during model execution. By checking the locations and files listed below, users can better pinpoint errors.

-
-

Key Areas for Error Checking

-
    -

  • GAMS Log File

    -
      -

    • Path: “/runs/{batch_prefix}_{case}/gamslog.txt”

      • -

    • Purpose: contains the log outputs for all execution statements from the case batch file

      • -

    • What to look for:

      -
        -

      • ‘ERROR’: will provide more information into the specific file or line in the source code that failed or has an error

        • -

      • ‘LP status’ and ‘Status’: can provide more insight into the model run

        • -

      • ‘Cur_year’: can help you determine which year the model run failed in

        • -
      -
      • -
    -
    • -

  • GAMS Listing Files

    -
      -

    • Path: “/runs//{batch_prefix}_{case}/lstfiles/”

      • -

    • Purpose: contains the listing files for GAMS executions

      • -

    • What to look for:

      -
        -

      • ‘1_inputs.lst’: errors will be preceded by ‘****’

        • -

      • ‘{batch_prefix}{case}{year}i0.lst’: there should be one file for each year of the model run

        • -

      • ‘Augur_errors_{year}’: this file will appear in the event that there is an augur-related issue

        • -
      -
      • -
    -
    • -

  • GAMS Workfiles

    -
      -

    • Path: “/runs/{batch_prefix}_{case}/g00files/”

      • -

    • Purpose: stores a snapshot of all the model information available to GAMS at that point in the case execution. More information about GAMS work files can be found here: https://www.gams.com/latest/docs/UG_SaveRestart.html

      • -

    • What to look for:

      -
        -

      • ‘{batch_prefix}{case}{last year run}i0.g00’: should exist for the last year run

        • -
      -
      • -
    -
    • -

  • Output Directory

    -
      -

    • Path: “/runs/{batch_prefix}_{case}/outputs/”

      • -

    • Purpose: the outputs folder contains the generated output files from the model run

      • -

    • What to look for:

      -
        -

      • ‘*.csv’ files: there should be many ‘.csv’ files in this folder

        -
          -

        • these files should contain data, an error message “GDX file not found” indicates an issue with the reporting script at the end of the model

          • -
        -
        • -

      • ‘reeds-report/’ and ‘reeds-report-reduced/’: if these folders are not present, it can indicate a problem with the post-processing scripts

        • -
      -
      • -
    -
    • -

  • Augur Data

    -
      -

    • Path: “/runs/{batch_prefix}_{case}/ReEDS_Augur/augur_data/”

      • -

    • What to look for:

      -
        -

      • ‘ReEDS_Augur_{year}.gdx’: there should be a file for each year of the model run =

        • -

      • ‘reeds_data_{year}.gdx’: there should be a file for each year of the model run

        • -
      -
      • -
    -
    • -

  • Case Inputs

    -
      -

    • Path: “/runs/{batch_prefix}_{case}/inputs_case/”

      • -

    • What to look for:

      -
        -

      • ‘*.csv’ files: there should be many ‘.csv’ files in this folder, if there isn’t, it could indicate a problem with the pre-processing scripts

        • -

      • ‘inputs.gdx’: if this doesn’t exist, it could indicate a problem with the pre-processing scripts

        • -
      -
      • -
    -
    • -
-
-
-

Re-running a Failed ReEDS Case

-

To re-run a failed case from the year it failed:

-
    -

  1. Comment out all the execution statements that completed successfully in “/runs/{batch_prefix}{case}/call{batch_prefix}_{case}.bat” (or *.sh file if on Mac)

    -
      -

    • Shortcut for commenting multiple lines: Ctrl + ‘/’ (Command + ‘/’ if on Mac)

      • -
    -
    2. -

  2. Re-run “/runs/{batch_prefix}{case}/call{batch_prefix}_{case}.bat”

    3. -
-

Additionally, ‘restart_runs.py’ is a helper script that can be used to restart any failed runs. For more information on how to use this script, see the section on Helper Scripts and Tools.

-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/bokehpivot.html b/docs/build/html/bokehpivot.html deleted file mode 100644 index 5afe6a4b..00000000 --- a/docs/build/html/bokehpivot.html +++ /dev/null @@ -1,271 +0,0 @@ - - - - - - - Exploding Pivot Charts — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- - -
-

Exploding Pivot Charts

-
-

Intro

-

This python bokeh app creates multiple pivot charts from data. A helpful tutorial is here: https://youtu.be/8Xi59M4bB6I. Note that some of this documentation might be outdated.

-
-
-

Installing Bokeh

-
    -

  1. You can check if you already have bokeh by going to -command line and simply entering:

    -
    bokeh
-
    -
    -

    If you get a message that says

    -
    ERROR: Must specify subcommand...
-
    -
    -

    you already have Bokeh. If not, here are the Bokeh installation instructions: -http://bokeh.pydata.org/en/latest/docs/installation.html. The easiest way is to use conda, -e.g. from the command line:

    -
    conda install bokeh
-
    -
    -
    2. -
-
-
-

Running Bokehpivot (Windows)

-
    -

  1. In the ReEDS repo, simply double click on bokehpivot/launch.bat to launch the tool. This will start a bokeh server in a terminal window and a browser window with an interactive interface.

    2. -

  2. After the tool is launched, go to the Loading Model data section below.

    3. -

  3. When done, simply close the terminal window that is running the server.

    4. -
-
    -

  • If you’re curious about the contents of the .bat files, you can open the Launch.bat in a text editor. The contents will look like:

    -
    call bokeh serve . --sh --port 0
-
    -
    -
    • -

  • Here is a breakdown of the contents of Launch.bat:

    -
      -

    • bokeh serve . --sh: Launch bokeh server and open browser window with the app. See https://docs.bokeh.org/en/latest/docs/user_guide/server.html for more info.

      • -

    • --port 0: This will allow bokehpivot to use an available port, and allows multiple simultaneous bokehpivot sessions (by launching multiple times).

      • -
    -
    • -
-
-
-

Running Bokehpivot (MacOS)

-

In the bokehpivot directory in VSCode or terminal, launch bokehpivot by:

-
/.launch.sh
-
-
-

(if you run into an access/permission restricting issue, allow yourself access to launch.sh by running following command before /.launch.sh:

-
chmod u+x launch.sh
-
-
-

a browser window with an interactive interface will pop up.

-
-
-

Loading data

-

After starting up the app in a browser window, you must enter a path in the Data Source field, either to a CSV file or to a Model run or set of runs:

-
    -

  • CSV: Enter a path to a csv file. This file must be properly formatted, with column headers but no row headers. You can Shift+Right Click on a csv file, then select Copy as Path to get the full path to a file. After that, see the Core Pivot Functionality section below.

    • -

  • Model Run(s): Here are the options:

    -
      -

    • Enter a path to a Model run folder. This works using shared drives too. For example, \nrelqnap01d\ReEDS\someProject\runs\someRun.

      • -

    • Enter a path to a folder containing run folders. For example, \nrelqnap01d\ReEDS\someProject\runs.

      • -

    • Enter any number of the path types above, each separated by a | (pipe) symbol

      • -

    • Enter a path to a csv file that contains a list of runs. Using this method allows scenarios to be ordered as desired and colors to be specified as well. See in/reeds_scenarios.csv for an example. It’s easiest to just copy reeds_scenarios.csv to some other location and edit/use the copy. Note that the file name must end with reeds_scenarios.csv.

      • -

    • After entering one of the above, see the ReEDS Widgets and Core Pivot Functionality sections below.

      • -
    -
    • -
-
-
-

Model Widgets

-
    -

  • Model Variables: Click the Model Variables section to expand, and update any model variables, e.g. dollar year and present value reference and end years.

    • -

  • Meta: Click the Meta section to expand, and see the files used for some default maps (to rename and aggregate different output categories), styles (to reorder categories and style them), and merges (to join more columns, e.g. to add regional aggregations). If you’d like to update any of these files, simply edit the file (only if you’re working locally), or point to a new file. When changing mappings, note that all set elements have been lowercased!

    • -

  • Filter Scenarios: A list of scenarios will be fetched after entering a path in Runs. Use the Filter Scenarios section to reduce the scenarios from which the app will fetch output data. Note that this filter does not have an effect after the data has already been fetched. To do further filtering of scenarios when building/updating figures, use the “scenario” filter in the “Filters” dropdown (described below).

    • -

  • Build Report: Build an HTML/Excel report based on a python file with a list of bokehpivot configurations. A select widget allows any of the reports in the reports\templates\ folder to be chosen, or the path to a custom report may be entered in a text widget (for example, one that is exported using the Export Report Config button described below). If the report references a base case, this may be chosen with a select widget. Click the Build Report button to create one html file and excel file with results for that report, or click Build Separate Reports to split each report configuration into its own html file. In either case, a separate and independent process is initiated each time one of these buttons is clicked. Note that Filter Scenarios may be used to limit the scenarios included in the report.

    • -

  • Result: Select a result from the Result select box. It may take a few seconds to fetch the data, depending on the number of scenarios being analyzed. After the result data is fetched, the following widgets will appear

    • -

  • Presets: You may select a preset result from the Preset select box, and a set of widgets will be automatically set for you. For example, for Generation, Stacked Generation is a preset result. Note that after selecting a preset, you may make further modifications to the widgets.

    • -

  • See the Core Pivot Functionality section below for the rest of the available widgets.

    • -
-
-
-

Core Pivot Functionality

-
    -

  • Chart Type: Dot, Line, Bar, Area, or Map. Note that Map requires that a mapped region (i, n, r, rnew, rto, st) is chosen as x-axis

    • -

  • X-axis (required): Select a column to use as x-axis

    • -

  • Group X By: Select a column to group the x-axis (if both x-axis and grouping columns are discrete).

    • -

  • Y-axis (required): Select a column to use as y-axis

    • -

  • Y-Axis Aggregation: Select Sum, Average, or Weighted Ave, or Weighted Ave Ratio. Weighted Ave requires another field, the Weighting Factor, and Weighted Ave Ratio, a ratio of weighted averages, requires both Weighting Factor (for the numerator of the ratio) and Denominator Weighting Factor. For electricity price, for example, select load as the Weighting Factor.

    • -

  • Series: Pick a column to split the data into separate, color-coded series. If Chart Type (see Plot Adjustments -below) is Area or Bar, series will automatically be stacked. If Chart Type is Line or Dot, the series will not be stacked.

    • -

  • Series Legend: Click on this to see the color and name of each series

    • -

  • Explode By: Select a discrete column to split into multiple charts. The charts’ titles will correspond to the -exploded column values.

    • -

  • Group Exploded Charts By: Select a discrete column to group exploded charts. Play around with plot sizes (see below) -and/or resize your browser screen to make a nice 2d array of charts.

    • -

  • Comparisons: This section allows comparisons across any dimension. You first select the Operation, then the column you’d like to Operate Across, then the Base that you’d like to compare to. Here are a couple examples for results:

    -
      -

    • Generation differences: Select Generation as Result, and select Stacked Gen under Presets. Then, under Comparisons, select Operation=Difference, Operate Across=scenario, and Base=your-base-case.

      • -

    • Generation Fraction: Select Generation as Result, and select Stacked Gen under Presets. Then, under Comparisons, select Operation=Ratio, Operate Across=tech, and Base=Total.

      • -

    • Capacity Differences, solve-year-to-solve-year: Select Capacity as Result, and select Stacked Capacity under Presets. Then, under Comparisons, select Operation=Difference, Operate Across=year, and Base=Consecutive.

      • -
    -
    • -

  • Filters: Each column can be used to filter data with checkboxes. After selecting Filters, you must press the Update Filters button to apply the filters

    • -

  • Update Filters: This is used for updating the charts once filters have been changed

    • -

  • Plot Adjustments: Make additional figure modifications: Size, x-axis/y-axis limits and scale, etc.

    • -

  • Map Adjustments: By default, data is binned using the Auto Equal Num method, which tries to split the data evenly between bins. But bins can also be specified as having equal width, or they can be set fully manually, using comma separated breakpoints. The two auto binning methods can also accept a number of bins and min/max values. Finally, stylistic adjustments to the maps may be made. Different coloring palettes may be used from https://bokeh.pydata.org/en/latest/docs/reference/palettes.html as long as the number of bins is allowed in that palette.

    • -

  • Auto/Manual Update: Setting Auto Update to Disable will disallow plots and data to be updated automatically while widgets are altered. The Manual Update button can be used to manually update plots and data. Setting Render plots to No will disallow rendering of figures. This is useful if, for instance, rendering plots is taking a very long time, and you simply want to download the data for a given widget config.

    • -

  • Download/Export: Download any data you’re viewing with the Download csv of View and Download html of View buttons, or download all data for a given source/result with the Download csv of Source button. It will be downloaded into a timestamped file in the bokehpivot\out\ folder, under your username. Export URL will save any non-default widget configuration as a URL query string (starting with “?”) and create a text file. At a later time, you will be able to load the same view by simply appending the URL query string to your bokehpivot URL (with your bokeh server running). If the URL is from Scorpio/Orion, you may access the URL from any computer connected to the NREL network (while the bokeh server on Scorpio/Orion is still running). Export Report Config will save config as a report section configuration dict in a python file, which can then be loaded as a custom file in the Build Report section above.

    • -
-
-
-

Creating report templates:

-

Report templates are in the reports\templates\ folder. Each of these files consists of a list of configurations. Every configuration has these keys:

-
    -

  • name: The title of this section of the report, shown in both the HTML and Excel sheets

    • -

  • result (optional): The result name (required if using the preset key).

    • -

  • preset (optional): The preset name.

    • -

  • config (optional): Full configuration if not using result or preset keys, or additional configuration to add. See reports\templates\jobs_report.py for examples of the config key used in addition to presets.

    • -

  • modify (optional): This allows comparison charts to be built when a base case has been specified. ‘modify’: ‘diff’ indicates that difference charts should be shown with the base case, while ‘modify’: ‘base_only’ indicates that the result should only be shown for the base case.

    • -
-
-
-

Tips

-
    -

  1. Pressing Alt will collapse all expandable sections.

    2. -

  2. Shift+Right Click on a file or folder in Windows Explorer will show the “Copy as Path” option, which may be pasted directly in the data source field.

    3. -

  3. Shift+Right Click on a folder or in a folder in Windows Explorer will show the “Open Command Window Here” option, which is helpful when running the static report .py files.

    4. -

  4. To suppress the automatic update of the plot while configuring the widgets, simply set Auto-Update to Disable to stop rendering of plots, then make your widget changes, then finally click the Manual Update button.

    5. -

  5. You may interact with the bokeh server with multiple browser windows/tabs, and these interactions will be independent, so you can leave one result open in one tab while you load another in a separate tab, for example.

    6. -

  6. The charts themselves have some useful features shown on the right-hand-side of each chart. For example, hovering over data on a chart will show you the series, x-value, and y-value of the data (not currently working for Area charts). You may also box-zoom or pan (and reset to go back to the initial view). Finally, the charts can be saved as pngs.

    7. -
-
-
-

Troubleshooting

-
    -

  1. If the window becomes unresponsive, simply refresh the page (you may want to export config first).

    2. -

  2. If a page refresh doesn’t work, then restart the bokeh server. If you have time, you can send Matt a screenshot of the error in the terminal window, if there is one.

    3. -
-
-
-

Additional Resources

-

This tool uses bokeh, built on python: -https://docs.bokeh.org/en/latest/. -The site has good documentation in the User Guide and Reference.

-

There is also an active google group for issues: -https://discourse.bokeh.org

-

And of course, python has good documentation too: -https://docs.python.org/2.7/tutorial/

-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/documentation_tools/README.html b/docs/build/html/documentation_tools/README.html deleted file mode 100644 index 4aad2ae3..00000000 --- a/docs/build/html/documentation_tools/README.html +++ /dev/null @@ -1,131 +0,0 @@ - - - - - - - How to Use Sources Documentation — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

How to Use Sources Documentation

-
    -

  1. Before running the .bat script, please ensure the sources.csv file is closed. If open, the script will be unable to replace the file and will throw an error.

    2. -

  2. Run generate_sources_md_file.bat script (for Mac and Linux users generate_sources_md_file.sh)located within the documentation_tools folder (ReEDS-2.0/docs/source/documentation_tools). You will need navigate to that directory prior to running.

    3. -

  3. This will run the first script generate_new_sources.py. generating a new sources.csv file at the top directory of the repository, please note,the existing sources.csv in your Repository root will be renamed to sources_{timestamp}.csv format. This can be deleted manually if no longer required; or can be held on to if required for comparison. Tree change files are generated in the documentations_tools folder to indicate files not included in the prior sources file (sources_files_added.csv), files removed from the prior sources file (sources_files_deleted.csv), and files not included in the sources file because they aren’t committed (sources_untracked_files.csv). These change files should not be committed and can be deleted when no longer needed.

    4. -

  4. Once this has finished running, please proceed to update relevant fields in the sources.csv file

    5. -

  5. Once relevant fields have been updated, please save sources.csv and close it.

    6. -

  6. Run generate_markdown.bat (for Mac and Linux users generate_markdown.sh)located within the documentation_tools folder. This will generate a README file sources_documentation.md with all the Source files and their details for the Repository by running the script generate_markdown.py. The markdown file will be generated in the ReEDS-2.0/docs/source/ location.

    7. -

  7. Commit and push the updated sources.csv and sources_documenation.md files.

    8. -
-
-
-

How to Update Relevant Fields in sources.csv

-
    -

  1. Once prompted by the .bat script, open sources.csv (found at the Repository root).

    2. -

  2. Using the Added Files List, sources_files_added.csv (found within the documentation_tools folder) which displays all the input files added by the user, enter relevant details in corresponding columns of sources.csv. Fields that do not apply can be left blank. Do not add new columns to sources.csv without also updating the scripts to support the expanded fields.

    3. -

  3. Save the sources.csv and close the file.

    4. -
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/faq.html b/docs/build/html/faq.html deleted file mode 100644 index 20a1ab4b..00000000 --- a/docs/build/html/faq.html +++ /dev/null @@ -1,309 +0,0 @@ - - - - - - - FAQ — ReEDS documentation - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

FAQ

-
-

Table of Contents

- -

-
-

How much are the GAMS licensing fees?

-

Please contact GAMS for more information.

-

-
-
-

Is there a trial version of the GAMS license so that I can test ReEDS?

-

We have created a reduced size version of the ReEDS model that has less than 5,000 rows and columns, and therefore should be compatible with the GAMS community license (https://www.gams.com/try_gams/ – Please contact GAMS if you need additional information regarding the community license). You can run this reduced model version by using the cases_small.csv input file. This reduced model uses a smaller technology subset, smaller geographic extent, and simplifies several model constraints.

-

-
-
-

What computer hardware is necessary to run ReEDS?

-

Running ReEDS using the reference case (located in cases.csv) is feasible on a laptop with 32GB of RAM. However, for running ReEDS with enhanced features such as explicit H2 modeling, C02 networks, increased temporal/spatial resolution, etc., it is recommened to utlize a higher-performance workstation or High-Performance Computing (HPC) machine.

-

National-scale ReEDS scenarios can be run on a laptop with 32GB of RAM. However, if you would like to run ReEDS with more detailed options (explicit H2 modeling, C02 networks, higher temporal/spatial resolution, etc.), it is recommended to use a higher-performance workstation or HPC.

-

-
-
-

Can I configure a ReEDS case to run as an isolated interconnect?

-

Yes, you can configure ReEDS as a single interconnect. Limiting the spatial extent may be beneficial for modeling more difficult instances.

-

WARNING!: The default case configurations were designed for modeling the lower 48 United States. Therefore, the user should be aware of possible issues with executing an interconnect in isolation, including but not limited to the following:

-
    -

  • Natural gas prices are based on either national or census division supply curves. The natural gas prices are computed as a function of the quantity consumed relative to a reference quantity. Consuming less than the reference quantity drives the price downward; consuming more drives the price upward. When modeling a single interconnection, the user should either modify the reference gas quantity to account for a smaller spatial extent or use fixed gas prices in every census division (i.e., case configuration option GSw_GasCurve = 2). For example, if we execute ERCOT in isolation using census division supply curves, we may want to reduce the reference gas quantity for the West South Central (West_South_Central) census division which includes Texas, Oklahoma, Arkansas, and Louisiana. Or we could assume the gas price in the West_South_Central region is fixed.

    • -

  • Infeasibilities may arise in state-level constraints when only part of a state is represented in an interconnect. For example, the Western interconnection includes a small portion of Texas (El Paso). State-level constraints will be enforced for Texas, but El Paso may not be able to meet the requirement for all of Texas.

    • -

  • Certain constraints may not apply in every interconnect. Some examples include:

    -
      -

    • California State RPS REC trading constraints only apply to the West

      • -

    • CAIR and CSAPR only apply to certain states, so the emission limits may need to be adjusted

      • -

    • RGGI only applies to a subset of states in the northeast

      • -

    • California policies (e.g., SB32, California Storage Mandate) only apply to California

      • -
    -
    • -
-

-
-
-

Is there a way to reduce solve time?

-

If you’d like to reduce the model solve time, consider making some of the following changes:

-
    -

  • yearset_suffix = 4yr or yearset_suffix = 5yr

    -
      -

    • Solve in 4- or 5-year steps

      • -
    -
    • -

  • GSw_OpRes = 0

    -
      -

    • Turn off operating reserves

      • -
    -
    • -

  • GSw_MinLoading = 0

    -
      -

    • Turn off the sliding-window representation of minimum-generation limits

      • -
    -
    • -

  • GSw_HourlyNumClusters = 25 (or lower)

    -
      -

    • Reduce the number of representative periods

      • -
    -
    • -

  • GSw_RegionResolution = aggreg

    -
      -

    • Aggregate the native 134 zones into fewer (larger) zones, with the amount of aggregation controlled by GSw_HierarchyFile

      -
        -

      • GSw_HierarchyFile = default: 133 zones: merges p119 -> p122 (obeys state, interconnect, NERC, and FERC region boundaries)

        • -

      • GSw_HierarchyFile = agg1: 126 zones: p119 -> p122; p49 -> p50; p124 -> p99; p19 -> p20; p44 -> p68; p120 -> p122; p29 -> p28; p71 -> p72 (obeys state, interconnect, NERC, and FERC region boundaries)

        • -

      • GSw_HierarchyFile = agg2: 69 zones (obeys state, interconnect, NERC, and FERC region boundaries)

        • -

      • GSw_HierarchyFile = agg3: 54 zones (obeys state boundaries)

        • -
      -
      • -
    -
    • -
-

-
-
-

How often are updates made to ReEDS?

-

Every year we target June 1 for the bulk of model changes to be completed, which allows us to meet the hard deadline for having a working, updated version of the model by June 30. We typically make minor updates to the model over the summer and tag a final version for that year in August or September. This version is then used to produce the Standard Scenarios and Cambium data products.

-

Additionally, changes are made throughout the year and a new version is created and published roughly every month. You can find current and past ReEDS versions here: ReEDS-2.0 Releases

-

If you would like to run ReEDS with a previous version, you can either download the source code directly or check out that version using the tag.

-

To check out a previous version using its tag, you can run the following command from your command line or terminal (ensure you have the main branch of the repo checked out):

-
git checkout tags/{version number}
-
-
-

Here is an example of what this would look like:

-
git checkout tags/v2024.0.0
-
-
-

-
-
-

What are the limitations, caveats, and known issues?

-

ReEDS is a big model with lots of limitations and caveats. Many higher-level limitations are discussed in the documentation; more code-facing issues are listed here.

-

Note: The following limitations, caveats, and known issues are incomplete and will evolve as the model changes

-
-

Capabilities that don’t currently work

-
    -

  • Climate impacts on hydropower (GSw_ClimateHydro), electricity demand (Gsw_ClimateDemand), and water cooling (GSw_ClimateWater)

    • -

  • endyear beyond 2050 (processed in forecast.py)

    • -

  • Demand flexibility via the GSw_EFS_Flex switch

    • -

  • County-level runs for regions with Canadian imports/exports and stress-period PRM formulation (`GSw_PRM_CapCredit == 0)

    • -
-
-
-

Assumptions

-
    -

  • Hydrogen production tax credit

    -
      -

    • One of the requirements of the hydrogen production tax credit is that the generation capacity must be no more than 3 years older than the electrolyzer to satisfy the “incrementality” or “additionality” condition.

      • -

    • To avoid comparing vintages of the generator and the electrolyzer and increasing computational intensity, we make a simplifying assumption that all new clean generators (2024 and onwards) satisfy the incrementality condition.

      • -
    -
    • -
-
-
-

Input data and processing

-
    -

  • copy_files.py

    -
      -

    • copy_files.py currently copies data to a ReEDS run’s inputs_case folder that might not be relevant to the run based on the run’s configured switch settings (e.g. upv_220AC-reference_ba.h5 is copied into the inputs_case folder even if PVB is turned off or GSw_PVB_ILR only contains ‘130’ as value(s)). This leads to bloating of the inputs_case folder due to inclusion of data that is irrelevant to a given run, which could also be misleading for users. This issue can be solved by including a new column to the runfiles.csv that controls whether or not a given runfile is copied into inputs_case based on a corresponding switch setting.

      • -
    -
    • -

  • hourly_repperiods.py

    -
      -

    • We use available-capacity-weighted average solar and wind profiles to select representative days, so we include lots of low-resource-quality sites that realistically probably wouldn’t be built. We may obtain different representative days if we were to downselect to higher-quality sites, but before running ReEDS it’s hard to say where the cutoff should be. So for now we stick with the available-capacity-weighted average across all sites.

      • -
    -
    • -

  • Move distpv capacity trajectory from “exogenous capacity” into “prescribed builds”

    -
      -

    • Currently, distpv capacity prescriptions are captured in the the “exogenous capacity” construct which represents capacity remaining in year t for capacity that existed prior to the first solve year. The data in this construct should be monotonically decreasing over time to reflect retirements. However, the distpv capacity prescription is monotonically increasing. We should move distpv capacity prescriptions to the “prescriptive capacity” construct which represents the cumulative capacity installed in each year.

      • -
    -
    • -
-
-
-

Core optimization

-
-
-

Output processing

-
    -

  • Land use

    -
      -

    • Land-use calculations use a static map of current land types; we do not project changes in land type (e.g. urbanization, changes to forestry and agriculture practices, etc) when assessing the land types utilized by new wind and solar.

      • -
    -
    • -

  • Retail rates

    -
      -

    • High-level limitations and caveats are discussed in Brown et al 2022

      • -

    • When using a 5-year model step (for example), the value of the PTC is evenly split over all 5 years in the step. We don’t try to assess in which year within the step a capacity investment is made.

      • -
    -
    • -
-
-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/genindex.html b/docs/build/html/genindex.html deleted file mode 100644 index ae893af8..00000000 --- a/docs/build/html/genindex.html +++ /dev/null @@ -1,114 +0,0 @@ - - - - - - Index — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
-
    -
    • -
  • Index
    • -
  • -
    • -
-
-
-
-
- - -

Index

- -
- -
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/index.html b/docs/build/html/index.html deleted file mode 100644 index f6d7c4a1..00000000 --- a/docs/build/html/index.html +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - Welcome to ReEDS’s documentation! — ReEDS documentation - - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Welcome to ReEDS’s documentation!

-
-
-

ReEDS 2.0

-
-

Welcome to the Regional Energy Deployment System (ReEDS) Model!

-

This GitHub repository contains the source code for NREL’s ReEDS model. The ReEDS model source code is available at no cost from the National Renewable Energy Laboratory. The ReEDS model can be downloaded or cloned from https://github.com/NREL/ReEDS-2.0.

-

For more information about the model, see the open source ReEDS-2.0 Documentation

-

A ReEDS training video (based on the 2020 version of ReEDS) is available on the NREL YouTube channel at https://youtu.be/aGj3Jnspk9M?si=iqCRNn5MbGZc8ZIO.

-

-
-
-
-

Introduction (https://www.nrel.gov/analysis/reeds/)

-

The Regional Energy Deployment System (ReEDS) is a capacity planning and dispatch model for the North American electricity system.

-

As NREL’s flagship long-term power sector model, ReEDS has served as the primary analytic tool for many studies (https://www.nrel.gov/analysis/reeds/publications.html) of important energy sector research questions, including clean energy policy, renewable grid integration, technology innovation, and forward-looking issues of the generation and transmission infrastructure. Data from the most recent base case and a suite of Standard Scenarios are provided.

-

ReEDS uses high spatial resolution and high-fidelity modeling. Though it covers a broad geographic and technological scope, ReEDS is designed to reflect the regional attributes of energy production and consumption. Unique among long-term capacity expansion models, ReEDS possesses advanced algorithms and data to represent the cost and value of variable renewable energy; the full suite of other major generation technologies, including fossil and nuclear; and transmission and storage expansion options. Used in combination with other NREL tools, data, and expertise, ReEDS can provide objective and comprehensive electricity system futures.

-

-
-
-

Required Software

-

The ReEDS model is written primarily in GAMS with auxiliary modules written in Python. R is used for the demand module, which is not active by default, and therefore need not be installed unless you plan on working with that module. At present, NREL uses the following software versions: GAMS 30.3; Python 3.6.5; R 3.4.4. Other versions of these software may be compatible with ReEDS, but NREL has not tested other versions at this time.

-

GAMS is a mathematical programming software from the GAMS Development Corporation. “The use of GAMS beyond the limits of the free demo system requires the presence of a valid GAMS license file.” [1] The ReEDS model requires the GAMS Base Module and a linear programming (LP) solver (e.g., CPLEX). The LP solver should be connected to GAMS with either a GAMS/Solver license or a GAMS/Solver-Link license. “A GAMS/Solver connects the GAMS Base module to a particular solver and includes a license for this solver to be used through GAMS. It is not necessary to install additional software. A GAMS/Solver-Link connects the GAMS Base Module to a particular solver, but does not include a license for the solver. It may be necessary to install additional software before the solver can be used.” [2]

-

NREL subscribes to the GAMS/CPLEX license for the LP solver, but open-source solvers and free, internet-based services are also available.

-
    -

  • The COIN-OR Optimization Suite includes open-source solvers that can be linked with GAMS through the GAMS Base Module. NREL has tested the use of the COIN-OR Linear Programming (CLP) solver for ReEDS. More information about using CLP for ReEDS can be found here.

    • -

  • The NEOS Server is a free, internet-based service for solving numerical optimization problems. Links with NEOS can be made through KESTREL which is included in GAMS Base Module. In its current form, ReEDS cannot be solved using NEOS due to the 16 MB limit on submissions to the server. However, modifications could be made to ReEDS to potentially reduce the data below to the required submission size. Note that some solvers available on the NEOS server are limited to non-commercial use.

    • -
-

Python is “an object-oriented programming language, comparable to Perl, Ruby, Scheme, or Java.” [3] “ Python is developed under an OSI-approved open source license, making it freely usable and distributable, even for commercial use. Python’s license is administered by the Python Software Foundation.” [4]. NREL uses Conda to build the python environment necessary for ReEDS. Conda is a “package, dependency and environment management for any language.” [5]

-

Git is a version-control tool used to manage code repositories. Included in Git is a unix style command line emulator called Git Bash, which is used by ReEDS to perform some initial setup tasks.

-

-
-
-

Contact Us:

-

If you have comments and/or questions, you can contact the ReEDS team at ReEDS.Inquiries@nrel.gov

-

Alternatively, you can post questions at ReEDS repository discussion page.

-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/additional_setup.html b/docs/build/html/internal/additional_setup.html deleted file mode 100644 index 910126e9..00000000 --- a/docs/build/html/internal/additional_setup.html +++ /dev/null @@ -1,781 +0,0 @@ - - - - - - - Additional ReEDS Setup — ReEDS documentation - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Additional ReEDS Setup

-
-

Yampa Guide

-
-

List of Machines

- - - - - - - - - - - - - - - - - - - - - - - -

Machine Name

RAM

constellation01.hpc.nrel.gov

120 GB

cepheus.hpc.nrel.gov

250 GB

corvus.hpc.nrel.gov

250 GB

delphinus.hpc.nrel.gov

500 GB

dorado.hpc.nrel.gov

500 GB

-
-
-

Getting Access to Machines

-

Access to the servers is controlled through the “reedsos” allocation. To request an HPC account, complete this request form. When asked if you intend to request a new project/allocation, select “no” and request to join “reedsos”.

-
-../_images/hpc_request_form.png -
-

Fig. 16 HPC account form, request to join “reedsos” allocation

-
-
-

Note: the ‘reedsos’ allocation isn’t an active allocation for HPC, which can cause some confusion with the HPC team, but it is still used to manage access to yampa.

-

If you have access issues after requesting an account, you can contact HPC help at HPC-Help@nrel.gov.

-
-
-

Getting Started

-
-

Get started with Microsoft Remote Desktop

-

Connections to the machines can be made using Microsoft Remote Desktop. To download:

-
    -

  • On Windows:

    • -

  • On Mac: You can download Microsoft Remote Desktop from the app store. You will need to create an apple id using your nrel email to start using the app store.

    • -
-

From the Remote Desktop client, you will need to click on the ‘+’ then ‘Add PC’. In the ‘PC name’ field, put the machine name that you would like to connect to, then click ‘Add’.

-
-../_images/yampa_add_machine.png -
-

Fig. 17 Example of how to add a new machine in Microsoft Remote Desktop

-
-
-

Username and Password: Same as HPC credentials.

-

Note: Check to make sure that nrel_nt is NOT inlcluded in your username, this sometimes gets added automatically to some users at first login by Microsoft Remote Desktop.

-
-
-

Drive Configuration

-

Unlike the old servers, storage is shared across the machines: as a result, you should only need to complete setup once, and it should be automatically reflected on other machines. There is a limited amount of space in your home directory with enforced storage limits. Only files essential to configuring your account should be kept here (e.g. path configurations).

-

The rest of the data is stored in the following folders:

-
    -

  • /data/shared/apps - contains programs

    • -

  • /data/shared/projects - contains user project folders: you’ll need to create one similar to the D: drives on the constellation machines

    • -
-

Create a projects folder by running the following command: mkdir /data/shared/projects/[your user name]

-
-
-

Initial Setup

-

After getting connected to the machine and creating your projects directory, you’ll need to do two additional steps to complete setup.

-
-
Add installed programs to PATH
-

To add installed programs to the $PATH environment variable, use the following command in the terminal: gedit ~/.bashrc

-

This will open up a text editor with your .bashrc file which contains the path locations. Here you will need to add gams, anaconda, and smartgit to $PATH.

-

Add the following line separated by colons to the path:

-
/data/shared/apps/gams/gams45.2_linux_x64_64_sfx:/data/shared/apps/gams/gams45.2_linux_x64_64_sfx/studio:/data/shared/apps/anaconda3/bin:/data/shared/apps/GitAhead 
-
-
-

Important: Make sure you don’t delete the original PATH contents or the “:$PATH” as part of PATH

-

Once completed, your bashrc file should look like the following screenshot. Save the file, then log off and log back on to ensure $PATH settings are updated.

-
-../_images/yampa_bashrc_file.png -
-

Fig. 18 Example of bashrc file with updated $PATH

-
-
-
-
-
Set up conda folders/environments
-

You’ll want to create a folder within your projects folder to store conda environments and packages. Run the following commands:

-
    -

  • mkdir /data/shared/projects/[username]/.conda

    • -

  • mkdir /data/shared/projects/[usename]/.conda/pkgs

    • -

  • mkdir /data/shared/projects/[username]/.conda/envs

    • -
-

Now, direct conda to look in these folders for packages and environments by running the following commands:

-
    -

  • conda config --add pkgs_dirs /data/shared/projects/[username]/.conda/pkgs

    • -

  • conda config --add envs_dirs /data/shared/projects/[username]/.conda/envs

    • -
-

Next, create and activate the conda environment. From the terminal, run the following commands from within the ReEDS repo:

-
    -

  • conda env create -f environment.yml - this step may take a while

    • -

  • conda activate reeds - if this steps causes issues, you can try running source activate reeds2 instead

    • -
-
-
-
Create SSH key and add it to your GitHub account
-

Follow the ssh setup guide to create a new SSH key and add it to your GitHub account.

-
-
-
-
-

Applications

- -
-

GAMS Studio

-

GAMS Studio is the IDE packaged with GAMS. It can be used for GAMS development and supports code markup and executing GAMS code from the developer environment. The other major application of GAMS Studio is to open .gdx files.

-

The GAMS studio executable is stored in the folder “/data/shared/apps/gams/gams45.2_linux_x64_64_sfx/studio/studio.AppImage”.

-

If the folder containing the executable was added to the path it can be run by using the following command from the terminal: Studio.AppImage

-

Note: If if hasn’t been added to your path, you can run the following command instead: /data/shared/apps/gams/gams45.2_linux_x64_64_sfx/studio/studio.AppImage

-

Navigate to postprocessing/bokehpivot and make sure your reeds environment has been activated.

-

Run this command (which is the contents of launch.sh):

-

`bokeh serve . –sh –port 0``

-

Note that you can copy the file path using the “Copy Location” option in the drop-down menu from the filepath in Files.

-
-
-

GitAhead

-

Github desktop has compatibility issues on Linux with Github enterprise. For a GUI interface for git use smartgit.

-

GitAhead can be launched by running the following command in the command line if you included in in your path environmental variable.

-

GitAhead

-

If it hasn’t been added to your path run the following

-

/data/shared/apps/GitAhead/GitAhead

-
-
-

Transferring Data to nrelnas01

-

Since at this time we can’t use the Linux servers to talk to Yampa we’re going to use an the HPC file system as a reasonably fast intermediary. The following instructions are for how to transfer data from Yampa to nrelnas01 but could easily be reversed by switching the target and destination.

-
    -

  1. Install or get access to winscp if on Windows. This will make interacting with the HPC file system easier. Transfers will be limited by your connection speed to the nrel network. If you aren’t on campus I would recommend getting access to the GPAC Windows (Azure) VM. It’s primarily intended for PLEXOS use but you won’t have a problem getting access, and this use will not be burdensome. You can download winscp at the link below, if you don’t have admin rights you can download the portable executable which doesn’t require installation. -https://winscp.net/eng/downloads.php

    -
      -

    • Note: If you are planning on connect to the Azure VM, Windows users may need to install a different client for the machine to appear in Workspaces.

      • -

    • To install, go to the link in the paragraph above, use the “Windows 64-bit” link to the installer. Download and run it.

      • -

    • After installation, open Remote Desktop, and click the Subscribe button. The ASCR machine should show up if you’ve been added to the group “Constellation Azure Servers” group. - If you’re not already a member, you will need to get added, then Unsubscribe via the dropdown in the General Workspaces tab and subscribe again

      • -
    -
    2. -

  2. You can connect to winscp using your hpc credentials and a valid host name (kestrel.hpc.nrel.gov). Once connected you can see the file system. You will want to navigate to the root and then to the following directory: /scratch/[username]

    -
      -

    • All HPC users are allocated a reasonable amount of temporary space in this folder and it’s a useful place for performing a transfer.

      • -
    -
    3. -

  3. Connect to Yampa and run the following command with your required changes:

    -
    rsync -avz -e ssh /data/shared/projects/[SOURCE FOLDER PATH]/ jho@kestrel.nrel.gov:/scratch/[DESTINATION FOLDER PATH]/ 
-
    -
    -
      -

    • Here’s an example:

      • -
    -
    rsync -avz -e ssh /data/shared/projects/jho/Target_Folder/ jho@kestrel.nrel.gov:/scratch/jho/Destination_Folder/ 
-
    -
    -
    4. -

  4. Once executed, you’ll get a login for the HPC. Once you’ve entered your credentials the transfer will start.

    5. -

  5. After the transfer is completed, the new files will be viewable on the HPC file system. They can then be transferred to a local files system including //nrelnas01/ReEDS/

    6. -
-
-
-

Transferring Data From Yampa to Your Machine

-

If you want to directly transfer files between Yampa and your local machine, you can use the tool FileZilla. You can download the FileZilla Client at https://filezilla-project.org/.

-

Once downloaded, you can connect using the following settings:

-
    -

  • Host: cepheus.hpc.nrel.gov (you can connect to any of the five VM hosts and filezilla will automatically add the connection protocol)

    • -

  • Username: Your HPC username

    • -

  • Password: Your HPC password

    • -

  • Port: You can leave this blank (if you have issues connecting you can use ‘22’ as the port)

    • -
-

You can then transfer data between machines - local machine is on the left and remote machine is on the right. The common project folders are retained in ‘/data/shared/projects/…’

-
-
-

Spyder

-

Spyder is an open-source integrated development environment (IDE) that is very useful for interactively running Python scripts and viewing variables, pandas dataframes, plots, etc. in the middle of script execution. Python can be launched from the Anaconda-Navigator Launcher, which can be opened by running the following command in a Terminal:

-

python /data/shared/apps/anaconda3/bin/anaconda-navigator

-

This will open the Anaconda-Navigator Launcher. From there, you can use the dropdown in the upper center of the screen to choose a conda environment to work out of or install/launch Spyder.

-
-
-
-

General Tips

-
-

Creating Shortcuts

-

When opening the terminal, Linux defaults to your home directory as an initial starting location. You can create a shortcut to another folder for faster access using the following command:

-

ln -s /data/shared/projects/[username] ~/projects

-

The general implementation of this is:

-

ln -s filepath linkpath

-

Once created you can use the shortcut as if it were a directory.

-
-
-

Sorting Folders Before Files

-

If you want the file viewer to adopt sorting behavior where folders are sorted alphabetically before files. You can make that change by opening the preferences menu in the folder viewer.

-
-../_images/yampa_file_preferences.png -
-

Fig. 19 File preferences on Yampa

-
-
-

Then select the option for Sort Folders before Files.

-
-
-

Issues Activating Conda Environment

-

If you’re having issues activating the reeds2 conda environment, you can try one of these options:

-
    -

  1. Use source activate reeds2 instead of conda activate reeds2

    2. -

  2. Run the following command prior to running conda activate reeds2 (note: if you don’t want to run this command every time, do step 3):

    3. -
-
source /data/shared/apps/anaconda3/etc/profile.d/conda.sh
-
-
-
    -

  1. Add the following line to the bottom of your bashrc file with the following command (you can open your bashrc file with the command gedit ~/.bashrc):

    2. -
-
$ source /data/shared/apps/anaconda3/etc/profile.d/conda.sh
-
-
-
-
-
-
-

Cloud and HPC Environments

-
-

Running ReEDS on HPC

-

This guide explains how to get ReEDS running on NREL’s HPC platform Kestrel.

-
-

Prerequisites

-

If you are new to HPC environments, you may wish to first visit NREL’s HPC website. There are also some courses from the Computational Sciences Tutorial Team that might be useful.

-

First, you will need a user account on HPC. Then, you will need an allocation. Your PI or mentor should tell you which allocation to use and add you to the relevant groups.

-

After getting an account and allocation, there are a few different options for accessing the HPCs. Most users interact with the HPCs through a combination of WinSCP and SSH with either GitBash or VSCode.

-

You should now be able to SSH into Kestrel with the command:

-
$ ssh username@kestrel.hpc.nrel.gov
-
-
-

You will be prompted to enter your password, you will need to use for HPC password here.

-
-
-

Setup

-
    -

  1. Load GAMS with the following commands:

    -
      -

    • module use /nopt/nrel/apps/software/gams/modulefiles

      • -

    • module load gams/45.2.0

      • -
    -
    2. -

  2. Set up your SSH key with NREL github:

    -
      -

    • Copy the contents in `/home/[username]/.ssh/id_rsa.pub

      -
        -

      • To print the contents of this file to the terminal, you can use the following command: cat /home/[username]/.ssh/id_rsa.pub

        • -
      -
      • -

    • Open https://github.nrel.gov and open your account settings

      -
        -

      • In the top right of the page, click on your git ID > Edit your Profile > SSH Keys > Add SSH Key

        • -

      • Paste the copied contents of id_rsa.pub into the “Add an SSH Key” window

        • -
      -
      • -
    -
    3. -

  3. Clone the repository

    -
      -

    • ReEDS requires git-lfs to clone the repository. To install and load git-lfs, use the following commands:

      -
        -

      • source /nopt/nrel/apps/env.sh

        • -

      • module load git

        • -

      • module load git-lfs

        • -
      -
      • -

    • From the terminal that you connected to Kestrel with, run the following command to clone the ReEDS repo: git clone git@github.nrel.gov:ReEDS/ReEDS-2.0.git

      • -

    • Note: some users have to run git lfs pull after this step as the hd5 files are incomplete

      • -
    -
    4. -

  4. Create the reeds2 environment

    -
      -

    • From within your cloned repo, run the following commands:

      -
        -

      • module load anaconda3

        • -

      • conda env create -f environment.yml

        • -
      -
      • -

    • Creating the environment can take several hours on Kestrel. If you don’t want to wait that long, An has been testing an alternative approach for creating the environment:

      -
        -

      • Navigate to your project folder and stay there for the duration of these commands: cd /projects/[project-name]/ReEDS-2.0

        • -

      • create your own miniconda which allows you to install libmamba (since we cannot alter the base environment on Kestrel):

        • -
      -
      curl -sL \  "https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh" > \   "Miniconda3.sh"
-
      -
      -
        -

      • find out where your envs are stored: conda list

        • -

      • change the conda environment path to your miniconda file paths:

        • -
      -
      echo "export CONDA_ENVS_PATH=$SCRATCH/home/[username]/miniconda3/envs" >> ~/.bashrc
-echo "export CONDA_ENVS_PATH=$SCRATCH/home/[username]/miniconda3/pkgs" >> ~/.bashrc
-
      -
      -
        -

      • install libmamba on the base environment miniconda env:

        • -
      -
      conda install -n base conda-libmamba-solver
-conda config --set solver libmamba
-
      -
      -
        -

      • create the ReEDS environment:

        • -
      -
      module load anaconda3
-conda env create -f environment.yml
-
      -
      -
        -

      • finally, activate it: conda activate reeds2

        • -
      -
      • -
    -
    5. -

  5. Add REEDS_USE_SLURM=1 to your list of environment variables at ~/.bashrc. The commands below give an example of how to do so using the ‘nano’ text editor in bash.

    -
      -

    • Open the ~/.bashrc file using nano: nano ~/.bashrc

      • -

    • At the end of the file add the following two lines:

      • -
    -
    ## Indicate that ReEDS jobs should be submitted via SLURM
-export REEDS_USE_SLURM=1
-
    -
    -
      -

    • Write the file: ^o ⏎

      • -

    • Exit nano: ^x

      • -

    • Run the .bashrc file (only needs to be done once; later it will run whenever you start a bash session): source ~/.bashrc

      • -
    -
    6. -

  6. Create a gamslice.txt file in the root of your ReEDS directory with the following contents ( You can do this using nano by typing nano gamslice.txt, then paste in the license text):

    7. -
-
  
-
-
-
    -

  1. Edit the ReEDS-2.0/srun_template.sh file in your local copy of the ReEDS repo. Fields indicated by curly braces {} must be changed; you can edit fields with brackets [] based on your preferences for the runs you’re submitting (be sure to remove the {} and [] brackets):

    2. -
-
  #!/bin/bash
-  #SBATCH --account={your HPC allocation}
-  #SBATCH --time=[walltime for your run; e.g., 2-00:00:00 = 2 days]
-  #SBATCH --nodes=1
-  #SBATCH --ntasks-per-node=1
-  #SBATCH --mail-user={your email address}
-  #SBATCH --mail-type=[BEGIN,END,FAIL]
-  #SBATCH --mem=[172000] # RAM in MB
-  ### OPTIONAL next line if you want to redirect the slurm log file and keep your ReEDS root directly clean
-  # #SBATCH --output=/projects/{your HPC allocation}/logs/slurm-%j.out
-  
-  #load your default settings
-  . $HOME/.bashrc
-
-
-
    -

  1. Edit the cplex.opt file to optimize performance on the HPC.

    2. -
-
    -

  • If you’re running 1 task per node you can set threads = -1 to use all available cores for the job. (If you’re running a very large model, like hourly or individual sites, using all threads may lead to memory issues; in that case you may want to use 8 or 12.)

    • -

  • You may want to remove reslim 50000, or set it to a higher value, to prevent long solve years from timing out

    • -
-

ReEDS should now be usable in from the command line using the python script runbatch.py.

-
-
-

Running ReEDS

-

Run ReEDS using runbatch.py the same way you would on any machine. Slurm jobs will be submitted for each case in the specified cases file. To understand the differences from a normal run, read the if hpc code blocks in runbatch.py.

-
-
-

Notes

-
-
Helpful shortcuts
-

The following commands can be added to your ‘~/.bashrc’ file for your convenience. Please note, you should change ‘your_alloc’ to one of your own allocations, ‘yourname’ to your own HPC username, and the ReEDS directory to whatever path you’ve chosen for the repository.

-
## Format squeue output to include more information
-alias squ='squeue -u yourname -o "%.10i %.15P %.65j %.2t %.10M %.6D %R"'
-alias sq='squ; echo "running:" $(squ | grep " R" | wc -l) "| pending:" $(squ | grep " PD" | wc -l) "| total:" $(squ | grep ":" | wc -l)'
-
-## Switch to my main ReEDS project folder, activate ReEDS environment
-alias reeds='cd /projects/your_alloc/github/ReEDS-2.0 && module load conda && module load gams && conda activate reeds2'
-
-## Get a specified number of hours on a node
-sr () { srun -t "$1:00:00" -A your_alloc --pty "$SHELL"; }
-
-## Get memory and CPU usage for recently-completed jobs
-alias sacc='sacct --format="JobID,JobName,Partition,AllocCPUS,STATE,Elapsed,CPUTime,AveCPU,TotalCPU,NCPUS,MaxRSS" | grep "JobID\|--\|batch"'
-
-
-

After saving your changes, you’ll need to run the following command once more to save your changes: source ~/.bashrc. You can then switch to your ReEDS directory and activate conda, gams, and your python environment by just typing reeds on login node.

-

To be able to access the HPC without entering your password every time, paste the contents of the ~/.ssh/id_ed25519.pub file on your laptop into the /.ssh/authorized_keys file on the HPC.

-
-
-
GAMS
-

In February 2023, there were some issues with getting access to the GAMS HPC group. The following is a workaround:

-
    -

  • run newgrp gams on the login node before submitting your job

    • -

  • you’ll be put in a new special shell, so you’ll need to run source activate reeds even if you previously activated the reeds environment

    -
      -

    • Note: it will be source activate reeds and not conda activate reeds2 as usual

      • -
    -
    • -

  • you should now be able to submit your job using runbatch.py as usual

    • -
-
-
-
Files and File Transfers
-

The supply curve data has been ported over to projects/shared-projects-reeds/reeds/Supply_Curve_Data for the time being, but the rev paths have not yet been updated so for now some features like reeds_to_rev.py won’t work.

-

If you need to transfer files between the HPC and your local machine, there are a few different options:

-
    -

  • For file transfers on Windows:

    - -
    • -

  • For file transfers on Mac:

    -
      -

    • FileZilla can be used to transfer files between a Mac and the HPC. You can download the FileZilla Client at https://filezilla-project.org/.

      • -

    • Host: ‘[username]@kestrel.hpc.nrel.gov’

      • -

    • More information on how to use FileZilla can be found in the Yampa guide.

      • -
    -
    • -

  • Using rsync:

    -
      -

    • You can also use rsync to transfer files; an example of a rsync transfer command:

      • -
    -
      rsync -aOP --exclude=**/225*/ --exclude=**/cpx*/ --exclude=*.dat --exclude=*.pkl --exclude=*.g00 --include=[batch_prefix]** --exclude=* --modify-window=5 --ignore-existing [hpc_user_name]@kestrel.nrel.gov:[path_to_run_folder] [destination_path]
-
    -
    -
    • -

  • Using Globus:

    -
      -

    • If the above methods for file transfers don’t work for you, another option is to use Globus

      • -

    • For more information, see: Globus File Transfer Services

      • -
    -
    • -
-

You can also transfer individual files to your machine using VSCode by right-clicking a file and selecting “download.”

-
-
-
VSCode setup
-

This guide provides a good overview of how to log on to a remote machine with VSCode.

-

To set up SSH keys so that you don’t have to enter your password each time you log in (note: this works for mac; Windows should be similar but it hasn’t been tested):

-
    -

  1. Open a terminal on your computer (not the HPC!) and then type:

    2. -
-
```
-cd ~/.ssh
-vim config
-```
-
-
-
    -

  1. Inside the config file type the following:

    2. -
-
```  
-Host <nickname>
-User <username on remote> 
-Hostname kl1.hpc.nrel.gov
-```
-
-Windows users should also add the following:
-```
-MACs hmac-sha2-512
-```
-
-
-
    -

  1. Save the file, then generate RSA key in ~/.ssh: ls ~/.ssh/id_rsa || ssh-keygen [note: you can skip this step if you already have a key]

    2. -

  2. Lastly copy the key over to Kestrel: ssh-copy-id <nickname> (where nickname is whatever you’ve set for Kestrel in the config file above)

    3. -
-
-
-
Git
-

The HPC now requires repositories to be cloned via SSH; if you have a repo that was cloned using HTTPS you may encounter issues configuring git. If you do want to preserve your cloned repository, you can update via the following:

-
    -

  1. nano .git/config

    2. -

  2. change url: https://github.nrel.gov/ReEDS/ReEDS-2.0.git to url: git@github.nrel.gov:ReEDS/ReEDS-2.0.git

    3. -
-

The HPC also has restrictions on the permissions for your github SSH key… you can change these to the correct settings via chmod 600 ~/.ssh/id_rsa.pub

-
-
-
-

Troubleshooting

-
-
Running on the HPC’s ‘debug’ partition
-

It can be helpful to kick off a test run on the HPC’s debug partition before submitting a full set. The debug queue is limited to 1 hour and 2 nodes per user but a run will typically start running immediately. To submit a run to the debug queue make the following changes to the ReEDS-2.0/srun_template.sh file:

-
    -

  • Set the runtime to 1 hour: #SBATCH --time=1:00:00

    • -

  • Add the following line: #SBATCH --partition=debug

    • -
-
-
-
Restarting a run from a previous solve year
-

Failed runs can be restarted by adding a --restart flag to the runbatch.py call. The call should include the same cases file and batch name as the failed runs (e.g. python runbatch.py -c [case] -b [batch] --restart). The restart functionality picks up with the last GAMS restart file. Input files are not recopied.

-

Alternately, an individual run can be restarted with the following steps:

-
    -

  1. Navigate to the directory with the run: cd runs/[batch]_[case]

    2. -

  2. Copy the original call shell script to a new call shell script: cp call_[batch]_[case].sh call_[batch]_[case]_redo.sh

    3. -

  3. Remove the lines in the new call shell script that have already successfully run. (This step is probably best done by opening the file with WinSCP and manually removing lines.)

    4. -

  4. Open the sbatch shell script to edit: nano [batch]_[case].sh

    5. -

  5. Insert the new call shell script where the original was:

    -

    Original:

    -
    #SBATCH --job-name=[job name]
-sh {your directory}/ReEDS-2.0/runs/[batch]_[case]/call_[batch]_[case].sh
-
    -
    -

    New:

    -
    #SBATCH --job-name=[job name]
-sh {your directory}/ReEDS-2.0/runs/[batch]_[case]/call_[batch]_[case]_redo.sh
-
    -
    -
    6. -

  6. Save the sbash shell script

    7. -

  7. Re-submit the run: sbatch [batch]_[case].sh

    8. -
-
-
-
General HPC
-

Make sure you have enough available storage in the directory where you are running ReEDS; otherwise the run will fail. The user directories on the HPC are very small; in general it’s best to run ReEDS in a project folder.

-
    -

  • You can check the storage quota for your project, and whether you’re over it, using the procedure described here: https://www.nrel.gov/hpc/project-storage-quotas.html

    -
      -

    • Run lfs project -d /projects/YOUR_PROJECT to get your project id number

      • -

    • Run lfs quota -h -p YOUR_PROJECT_ID /projects/YOUR_PROJECT to get your current usage and quota

      • -
    -
    • -
-
-
-
Runs in a standby partition
-

Currently runs in a standby partition won’t show up with squeue unless you flag the partition (e.g., squeue -u [username] -p standard-stdby)

-
-
-
-
-

Running ReEDS on AWS

-

To run ReEDS on AWS, you’ll need to set up an account on Amazon Web Servies. Once you have done that, you will be able to run ReEDS on AWS’s Elastic Compute Cloud (EC2), their virtual computation service. The goal here is to be able to flexibly scale computing power to the needs of the moment and to avoid bottlenecks presented by HPC downtime and limited server space.

-
-

Requesting an allocation

-

First, somebody needs to request an allocation for a project. There’s a regular allocation request period each spring for the upcoming fiscal year, but out-of-cycle (ad-hoc) allocation requests are also allowed through a similar process. Go to CSC Cloud Portal to read more.

-
-
-

Getting an AWS account

-

Request an AWS account by emailing CSC.CloudHelp@nrel.gov and including the name of the cloud project your account will be associated with. (Cloud projects are similar to HPC allocations and use a keyword identifier, e.g. UberNodalReEDS.)

-

You may also want to join the Cloud Computing User Group on Microsoft Teams—just ask in your initial email to be added.

-

CSC, the cloud computing team, has a CSC Cloud Portal site on theSOURCE that contains lots of useful information. You should read through the information there on sizing, pricing, billing, etc. It’s quite useful.

-
-
-

Running ReEDS scenarios on AWS

-

To run ReEDS scenarios, we spin up at least one virtual machine—an “instance” in Amazon-speak—of AWS’s EC2 service. Often, it makes sense to spin up multiple EC2 instances when you have multiple runs since costs scale nonlinearly as the size of your chosen EC2 machine increases in memory and CPU. For storage on hard disk, we create an Elastic Block Storage (EBS) drive and connect it to the EC2 instance.

-
-
-

Launching your first instance

-

CSC has set up a template Amazon Machine Image (AMI) that specifies required information about the EC2 instance and security settings that have been approved by NREL’s cybersecurity team. CSC will set up an AMI template and give you a link to it.

-
-
-
-
-

Hourly Resolution and Additional Setups

- -
-

Hourly resolution quick-start guide

-

If you’d like to run the model with hourly resolution, here is the minimal set of switches to change in cases.csv:

-
    -

  • GSw_Hourly = 1

    -
      -

    • Turn on hourly resolution

      • -
    -
    • -

  • GSw_Canada = 2

    -
      -

    • Turn on hourly resolution for Canadian imports/exports

      • -
    -
    • -

  • GSw_AugurCurtailment = 0

    -
      -

    • Turn off the Augur calculation of curtailment

      • -
    -
    • -

  • GSw_StorageArbitrageMult = 0

    -
      -

    • Turn off the Augur calculation of storage arbitrage value

      • -
    -
    • -

  • GSw_Storage_in_Min = 0

    -
      -

    • Turn off the Augur calculation of storage charging

      • -
    -
    • -

  • capcredit_szn_hours = 3

    -
      -

    • The current default hourly representation is 18 representative 5-day weeks. Each representative period is treated as a ‘season’ and is thus active in the planning-reserve margin constraint. In h17 ReEDS we set capcredit_szn_hours = 10, giving 40 total hours considered for planning reserves (the top 10 hours in each of the 4 quarterly seasons). 18 ‘seasons’ with 10 hours each would give 180 hours, so we switch to 3 hours per ‘season’ (for 54 hours total).

      • -
    -
    • -
-

If you’d like the model to solve in less than 2 days, you can also make the following changes:

-
    -

  • yearset_suffix = fiveyear

    -
      -

    • Solve in 5-year steps

      • -
    -
    • -

  • GSw_OpRes = 0

    -
      -

    • Turn off operating reserves

      • -
    -
    • -

  • GSw_MinLoading = 0

    -
      -

    • Turn off the sliding-window representation of minimum-generation limits

      • -
    -
    • -

  • GSw_PVB = 0

    -
      -

    • Turn off PV-battery hybrids

      • -
    -
    • -

  • GSw_calc_powfrac = 0

    -
      -

    • Turn off a post-processing calculation of power flows

      • -
    -
    • -
-
-
-

Hourlize

-

Hourlize processes hourly resource and load data into ReEDS inputs. For more information on getting started with Hourlize, you can find more information here: Using Hourlize

-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/coding_standards_and_conventions.html b/docs/build/html/internal/coding_standards_and_conventions.html deleted file mode 100644 index dee5ffaa..00000000 --- a/docs/build/html/internal/coding_standards_and_conventions.html +++ /dev/null @@ -1,409 +0,0 @@ - - - - - - - Coding Standards and Conventions — ReEDS documentation - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Coding Standards and Conventions

-

The following are naming, rounding, and coding conventions that should be followed when making changes to ReEDS. All new code contributed to the repo should follow these conventions.

-

Note: Because these conventions were not written until after the model development began, you will notice that some of these conventions are violated in the current code base. The conventions are far from comprehensive. Our hope is that this light approach can help bring consistency to the model code without being burdensome to those writing the code.

-
-

Naming, Rounding, and Coding Conventions

-
-

Naming Conventions

-
    -

  • File names (GAMS files, input files, output files)

    -
      -

    • Folders are lower case

      • -

    • Files are lower case with underscores separating words (atb_mid_wind_2018.csv)

      • -

    • GAMS files are proceeded by a letter and underscore, with each letter representing a file category and letters in alpha-order of file execution whenever possible (a_write_data.gms). When there are multiple GAMS files in the same category, they should be numbered to show the order in which they are called (a1_write_data, a2_inputs, a3_inputs_demand)

      • -

    • Output files start with a noun indicator for the general output category to make it easier to find (curt_marg rather than marg_curt, gen_ann rather than ann_gen)

      • -
    -
    • -

  • Parameters

    -
      -

    • Use lower case with underscores separating words

      • -

    • Like the output files, the first word of parameters should be a noun indicator of the parameter type (curt_marg rather than marg_curt)

      • -

    • Cost parameters should generally start with “cost” (e.g., cost_fom, cost_cap)

      • -
    -
    • -

  • Variables

    -
      -

    • Use capital letters (example: INV)

      • -

    • Where possible, use the same naming for related variables (e.g., INV; INV_TRANS)

      • -

    • The first indicator in a variable name should be a noun or noun abbreviation for the variable type or category

      • -
    -
    • -

  • equations (model constraints)

    -
      -

    • Begin with the prefix “eq_”

      • -

    • Use all lower-case letters with underscores separating words (example: eq_reserve_margin)

      • -
    -
    • -

  • switches

    -
      -

    • Begin with the prefix “Sw_”

      • -

    • Use descriptive names with upper camel case (e.g., Sw_ReserveMargin)

      • -

    • For on/off switches, “OFF” = 0 and “ON” =1

      • -
    -
    • -

  • indices/sets

    -
      -

    • Use lower case

      • -

    • Use short rather than descriptive (e.g., “i” instead of “tech”) – preference for one or two letter names.

      • -
    -
    • -

  • aliases

    -
      -

    • Use the same alpha character as the original set followed by a number (example: alias(r,r2))

      • -
    -
    • -

  • subsets

    -
      -

    • Use lowercase

      • -

    • Use short but descriptive text

      • -

    • example: conv(i) is the subset of technologies that are “conventional”

      • -
    -
    • -

  • crosswalk sets

    -
      -

    • Use the set names and separated by an underscore

      • -

    • example: r_st(r,st) is the crosswalk between region “r” and state “st”

      • -
    -
    • -

  • Choosing names for parameters and variables

    -
      -

    • Names should be descriptive (e.g., “curt_marg” rather than “cm”)

      • -

    • Shorter names are generally preferred (e.g., “curt_marg” rather than “curtailment_marginal”)

      • -
    -
    • -
-
-
-

Rounding Conventions

-

As a general rule, costs or prices should be rounded to two decimal places. All other parameters should be rounded to no more than 3 decimal places.

-

Note: Some exceptions to this might exsist due to number scaling (e.g., emission rates)

-
-
-

Coding Conventions

-
    -

  • Generally, each line in GAMS should be no longer than a standard page width (255 characters)

    • -

  • Declarations

    -
      -

    • Blocks of declarations are preferred to individual line declarations

      • -

    • Comments are required for each declaration

      -
        -

      • Units should always be defined first (even if they are unitless) enclosed in “–”

        • -

      • Example: cap_out(i,r,t) “–MW– capacity by region”

        • -
      -
      • -

    • Comments need not be comprehensive

      -
        -

      • CAP(i,v,r,t) “–MW– capacity by technology i of vintage v in region r in year t”

        • -

      • CAP(i,v,r,t) “–MW– capacity by technology”

        • -
      -
      • -
    -
    • -

  • Ordering of indices

    -
      -

    • The following indices should always appear first in the following order: (1)ortype (2)i (3)v (4)r (5)h

      • -

    • The t (year) index should always be last

      • -

    • Other sets should generally be ordered alphabetically, respecting the two conventions above

      • -
    -
    • -

  • Qualifiers

    -
      -

    • Enclosed with brackets “[]”

      • -

    • No space between qualifiers

      • -

    • example: \([qual1\)qual2]

      • -

    • Parenthesis should be used to make order of operations explicit

      -
        -

      • Incorrect: \([not qual1 \)not qual2]

        • -

      • Correct: \([(not qual1)\)(not qual2)]

        • -
      -
      • -

    • Operators “and”, “not”, and “or” should be lower case

      • -
    -
    • -

  • Equations (this applies to pre- and post-processing; model constraints)

    -
      -

    • Each term should begin with a plus (+) or minus (-) sign, even the first term

      • -

    • Summations

      -
        -

      • Summation arguments should be bookended with braces “{}” sum{…}

        • -

      • The summation will generally be separated into three parts that will appear on three different lines, with the closing } lining up with the opening {

        • -
      -
      [+/-] sum{ ([indices]) $ [qualifiers] ,
-                  [parameter] * [variable]
-                }
-
      -
      -
      + sum{(i,c,r,t)$[Qual1$Qual2 … $Qual3], 
-      cv_avg(i,r,t) * CAP(i,c,r,t)
-    }
-
      -
      -
      • -

    • For equations, sums should generally be split with terms on multiple lines. In some cases it will be more readable to leave the sum on one line (e.g., a short sum inside of a long sum).

      • -

    • Each term of an equation should be separated by a new line; white space should be inserted between terms

      • -

    • When reasonable, only one parameter should be multiplied by one variable

      -
        -

      • for example, “heatrate [MBtu/MWh] * emissions rate of fuel [tons CO2/MBtu] * GENERATION [MWh]” should be “emissions rate of plant [tons CO2/MWh] * GENERATION [MWh]”

        • -

      • this will help us limit numerical issues that result from the multiplication of two small numbers

        • -
      -
      • -

    • When multiplying parameters and variables, parameters should appear on the left and variables on the right

      • -

    • Keep one space on either end of a mathematical operator (, /, +, -). example: “curt_marg * GEN” rather than “curt_margGEN”

      • -
    -
    • -

  • Do not use recursive calculations; new parameters should be created

    -
      -

    • Example: “load = load * 1.053” should be written as “busbarload = enduseload * 1.053”

      • -

    • This will create consistency between the units specified in the parameter declaration and the use of the parameter

      • -
    -
    • -

  • Comments

    -
      -

    • Do not use inline comments (comments proceeded by //). This helps to make it easier to find comments

      • -

    • Do not use \(ontext/\)offtext except for headers at the beginning of files

      • -

    • Include a space after the “*” to start a comment

      • -

    • Do not use a comment to note an issue. Use GitHub to put the issue instead.

      • -

    • Example: Don’t do this:

      -
      *!!!! this will need to be updated to the tophrs designation after the 8760 cv/curt method is implemented   
-
      -
      -
      • -
    -
    • -

  • Other

    -
      -

    • GAMS functions such as sum, max, smax, etc. should use {}; Example: avg_outage(i) = sum{h,hours(h)*outage(i,h)} / 8760 ;

      • -

    • When including the semicolon on the end of a line there should be a space between the semicolon and the last character of the line (see previous example)

      • -

    • When using / / for a parameter declaration, place the closing semicolon on the same line as the final slash: / ;

      • -

    • Sums outside of equations (e.g., in e_reports) need not be split over multiple lines if they do not exceed the line limit

      • -

    • Do not use hard-coded numbers in equations or calculations. Values should be assigned to an appropriate parameter name that is subsequently used in the code.

      • -

    • Large input data tables should be loaded from individual data files for each table, preferably in *.csv format. Large data tables should not be manually written into the code but can be written dynamically by scripts or inserted with a $include statement.

      • -

    • Compile-time conditionals should always use a tag (period + tag name) to clearly define the relationships between compile-time conditional statements. Failure to do so hurts readability sometimes leads to compilation errors. Example:

      -
      $ifthen.switch1 Sw_One==A
-  Do Something
-$elseif.switch1 Sw_One==B
-  Do Something
-$else.switch1 Sw_One==C
-  Do Something
-$endif.switch1
-
      -
      -
      • -
    -
    • -
-
-
-
-

Input Conventions and Data Handling

-
-

Input Conventions

-
    -

  • Data read into b_inputs should already be filtered. E.g., if you are running ERCOT, only data for ERCOT should be included.

    -
      -

    • We did not structure things this way when we first built ReEDS, and it might not be possible to always meet this recommendation without a large amount of work. This recommendation represents the vision we are working toward rather than a requirement.

      • -

    • The same applies to scenarios. If there are multiple scenario options in a single file (e.g. inputs/carbonconstraints/co2_cap.csv), only the single scenario used in a model run should be copied to inputs_case and loaded in b_inputs.gms.

      • -
    -
    • -

  • Input csv files that are written to inputs_case should have the same name as the GAMS parameter that reads that csv file.

    -
      -

    • Example: trancap_init(r,rr,trtype) reads in trancap_init.csv

      • -
    -
    • -

  • Parameters read into b_inputs should also include a header that has the set names and then units for the values. An asterisk is required to keep GAMS from reading the header and throwing an error. Example:

    -

    image

    -
    • -

  • Parameters read into b_inputs should be surrounded by \(offlisting and \)onlisting so that they are not written to the .lst files.

    -
      -

    • Example:

      -
      parameter ev_static_demand(r,allh,allt) "--MW-- static electricity load from EV charging by timeslice"
-/
-$offlisting
-$ondelim
-$include inputs_case%ds%ev_static_demand.csv
-$offdelim
-$onlisting
-/ ;
-
      -
      -
      • -
    -
    • -

  • When a file read into b_inputs was created by an upstream script within the repository, include a note indicating which script created the file.

    -
      -

    • Example: “* Written by hourly_process.py”

      • -
    -
    • -

  • In general, parameter declarations (which are in long format) are preferred to table declarations. Table declarations are acceptable when the table format can significantly reduce the files size or when the format of the native data better matches the table format.

    • -

  • Files used as inputs for the repository are always placed in an appropriate location within the “inputs” folder. Input files are grouped topically.

    • -

  • When there are multiple input options for a given input, the input file name should be “{file}_{option}”. For example:

    -
      -

    • battery_ATB_2022_moderate

      • -

    • battery_ATB_2022_conservative

      • -
    -
    • -

  • If preprocessing is needed to create the input file that is placed in the ReEDS repository, the preprocessing scripts or workbooks should be included in the ReEDS-2.0_Input_Processing repository (https://github.nrel.gov/ReEDS/ReEDS-2.0_Input_Processing). Raw data files should be placed in that repository if their file size permits. Otherwise, raw data files should be placed in \nrelnas01\ReEDS\ _ReEDS Documentation.

    • -

  • Any scripts that preprocess data after a ReEDS run is started should be placed in the input_processing folder.

    -
      -

    • Input processing scripts should start with a block of descriptive comments describing the purpose and methodology, and internal functions should use docstrings and liberal comments on functionality and assumptions.

      • -
    -
    • -

  • Any costs read into b_inputs should already be in 2004$. Cost adjustments in preprocessing scripts should rely on the deflator.csv file rather than have hard-coded conversions.

    • -

  • In general, if inputs require calculations before they are ingested into b_inputs, those calculations should be done in Python rather than in GAMS. GAMS can be used for calculations where the GAMS syntax simplifies the calculation or where upstream dependencies make it challenging for the calculations to happen in Python preprocessing scripts.

    • -

  • In Python, file paths should be added using os.path.join() rather than writing out the filepath with slashes.

    • -

  • Data column headers should use the ReEDS set names when practical. For example, data that include regions should use “r” for the column name rather than “ba,” “reeds_ba,” or “region.”

    • -

  • Preprocessing scripts in input_processing should not change the working directory or use relative filepaths; absolute filepaths should be used wherever possible.

    • -
-
-
-

Input Data

-
    -

  • In general, all inputs less than ~10 MB should be in .csv format.

    -
      -

    • If the csv file would be larger than ~10 MB, then write it as a h5 file unless accessibility is especially important (e.g., the ReEDS_generator_database file needs to be easily accessible, so is kept as a csv file).

      • -

    • In some cases .txt files may be used as inputs if their format is especially convenient for the application.

      • -
    -
    • -

  • Input files should be included in the repository when possible.

    -
      -

    • Files too large to include in the repository or unnecessary for the repository (e.g., files used only for special circumstances, such as individual sites for wind and solar) should be included in the appropriate folder on nrelnas and can be copied to the local repository in the preprocessing steps.

      • -

    • Files stored on nrelnas should have unique names that identify the version of the file and data. For example, you would use “special_input_data_2022_11_28” rather than “special_input_data.”

      • -
    -
    • -

  • Add units to raw data files

    -
      -

    • When adding a new raw data file, include units in the column name to avoid confusion

      • -

    • As an example, look at ‘/inputs/plant_characteristics/conv_ATB_2023.csv’

      -
        -

      • The data in the “capcost” column are in unit of k\(/MW or \)/kW, although the units are not labeled

        • -

      • As a best practice, “capcost” should be named “capcost_usd.per.kw” to make units clear

        • -
      -
      • -
    -
    • -

  • Add comments to raw data files that represent GAMS subsets

    -
      -

    • When adding a new raw data file that represents a GAMS subset, include column headers representing the GAMS set that each column’s entries belong to, with the first column header being prepended by an asterisk (this allows GAMS to parse the first row of the .csv file as a comment)

      • -

    • For an example, see ‘/inputs/sets/fuel2tech.csv’

      • -
    -
    • -
-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/developer_best_practices.html b/docs/build/html/internal/developer_best_practices.html deleted file mode 100644 index 8017d498..00000000 --- a/docs/build/html/internal/developer_best_practices.html +++ /dev/null @@ -1,862 +0,0 @@ - - - - - - - Developer Resources — ReEDS documentation - - - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Developer Resources

-
-

Coding Standards and Conventions

-

The following are naming, rounding, and coding conventions that should be followed when making changes to ReEDS. All new code contributed to the repo should follow these conventions.

-

Note: Because these conventions were not written until after the model development began, you will notice that some of these conventions are violated in the current code base. The conventions are far from comprehensive. Our hope is that this light approach can help bring consistency to the model code without being burdensome to those writing the code.

-
-

Naming, Rounding, and Coding Conventions

-
-

Naming Conventions

-
    -

  • File names (GAMS files, input files, output files)

    -
      -

    • Folders are lower case

      • -

    • Files are lower case with underscores separating words (atb_mid_wind_2018.csv)

      • -

    • GAMS files are proceeded by a letter and underscore, with each letter representing a file category and letters in alpha-order of file execution whenever possible (a_write_data.gms). When there are multiple GAMS files in the same category, they should be numbered to show the order in which they are called (a1_write_data, a2_inputs, a3_inputs_demand)

      • -

    • Output files start with a noun indicator for the general output category to make it easier to find (curt_marg rather than marg_curt, gen_ann rather than ann_gen)

      • -
    -
    • -

  • Parameters

    -
      -

    • Use lower case with underscores separating words

      • -

    • Like the output files, the first word of parameters should be a noun indicator of the parameter type (curt_marg rather than marg_curt)

      • -

    • Cost parameters should generally start with “cost” (e.g., cost_fom, cost_cap)

      • -
    -
    • -

  • Variables

    -
      -

    • Use capital letters (example: INV)

      • -

    • Where possible, use the same naming for related variables (e.g., INV; INV_TRANS)

      • -

    • The first indicator in a variable name should be a noun or noun abbreviation for the variable type or category

      • -
    -
    • -

  • equations (model constraints)

    -
      -

    • Begin with the prefix “eq_”

      • -

    • Use all lower-case letters with underscores separating words (example: eq_reserve_margin)

      • -
    -
    • -

  • switches

    -
      -

    • Begin with the prefix “Sw_”

      • -

    • Use descriptive names with upper camel case (e.g., Sw_ReserveMargin)

      • -

    • For on/off switches, “OFF” = 0 and “ON” =1

      • -
    -
    • -

  • indices/sets

    -
      -

    • Use lower case

      • -

    • Use short rather than descriptive (e.g., “i” instead of “tech”) – preference for one or two letter names.

      • -
    -
    • -

  • aliases

    -
      -

    • Use the same alpha character as the original set followed by a number (example: alias(r,r2))

      • -
    -
    • -

  • subsets

    -
      -

    • Use lowercase

      • -

    • Use short but descriptive text

      • -

    • example: conv(i) is the subset of technologies that are “conventional”

      • -
    -
    • -

  • crosswalk sets

    -
      -

    • Use the set names and separated by an underscore

      • -

    • example: r_st(r,st) is the crosswalk between region “r” and state “st”

      • -
    -
    • -

  • Choosing names for parameters and variables

    -
      -

    • Names should be descriptive (e.g., “curt_marg” rather than “cm”)

      • -

    • Shorter names are generally preferred (e.g., “curt_marg” rather than “curtailment_marginal”)

      • -
    -
    • -
-
-
-

Rounding Conventions

-

As a general rule, costs or prices should be rounded to two decimal places. All other parameters should be rounded to no more than 3 decimal places.

-

Note: Some exceptions to this might exsist due to number scaling (e.g., emission rates)

-
-
-

Coding Conventions

-
    -

  • Generally, each line in GAMS should be no longer than a standard page width (255 characters)

    • -

  • Declarations

    -
      -

    • Blocks of declarations are preferred to individual line declarations

      • -

    • Comments are required for each declaration

      -
        -

      • Units should always be defined first (even if they are unitless) enclosed in “–”

        • -

      • Example: cap_out(i,r,t) “–MW– capacity by region”

        • -
      -
      • -

    • Comments need not be comprehensive

      -
        -

      • CAP(i,v,r,t) “–MW– capacity by technology i of vintage v in region r in year t”

        • -

      • CAP(i,v,r,t) “–MW– capacity by technology”

        • -
      -
      • -
    -
    • -

  • Ordering of indices

    -
      -

    • The following indices should always appear first in the following order: (1)ortype (2)i (3)v (4)r (5)h

      • -

    • The t (year) index should always be last

      • -

    • Other sets should generally be ordered alphabetically, respecting the two conventions above

      • -
    -
    • -

  • Qualifiers

    -
      -

    • Enclosed with brackets “[]”

      • -

    • No space between qualifiers

      • -

    • example: \([qual1\)qual2]

      • -

    • Parenthesis should be used to make order of operations explicit

      -
        -

      • Incorrect: \([not qual1 \)not qual2]

        • -

      • Correct: \([(not qual1)\)(not qual2)]

        • -
      -
      • -

    • Operators “and”, “not”, and “or” should be lower case

      • -
    -
    • -

  • Equations (this applies to pre- and post-processing; model constraints)

    -
      -

    • Each term should begin with a plus (+) or minus (-) sign, even the first term

      • -

    • Summations

      -
        -

      • Summation arguments should be bookended with braces “{}” sum{…}

        • -

      • The summation will generally be separated into three parts that will appear on three different lines, with the closing } lining up with the opening {

        • -
      -
      [+/-] sum{ ([indices]) $ [qualifiers] ,
-                  [parameter] * [variable]
-                }
-
      -
      -
      + sum{(i,c,r,t)$[Qual1$Qual2 … $Qual3], 
-      cv_avg(i,r,t) * CAP(i,c,r,t)
-    }
-
      -
      -
      • -

    • For equations, sums should generally be split with terms on multiple lines. In some cases it will be more readable to leave the sum on one line (e.g., a short sum inside of a long sum).

      • -

    • Each term of an equation should be separated by a new line; white space should be inserted between terms

      • -

    • When reasonable, only one parameter should be multiplied by one variable

      -
        -

      • for example, “heatrate [MBtu/MWh] * emissions rate of fuel [tons CO2/MBtu] * GENERATION [MWh]” should be “emissions rate of plant [tons CO2/MWh] * GENERATION [MWh]”

        • -

      • this will help us limit numerical issues that result from the multiplication of two small numbers

        • -
      -
      • -

    • When multiplying parameters and variables, parameters should appear on the left and variables on the right

      • -

    • Keep one space on either end of a mathematical operator (, /, +, -). example: “curt_marg * GEN” rather than “curt_margGEN”

      • -
    -
    • -

  • Do not use recursive calculations; new parameters should be created

    -
      -

    • Example: “load = load * 1.053” should be written as “busbarload = enduseload * 1.053”

      • -

    • This will create consistency between the units specified in the parameter declaration and the use of the parameter

      • -
    -
    • -

  • Comments

    -
      -

    • Do not use inline comments (comments proceeded by //). This helps to make it easier to find comments

      • -

    • Do not use \(ontext/\)offtext except for headers at the beginning of files

      • -

    • Include a space after the “*” to start a comment

      • -

    • Do not use a comment to note an issue. Use GitHub to put the issue instead.

      • -

    • Example: Don’t do this:

      -
      *!!!! this will need to be updated to the tophrs designation after the 8760 cv/curt method is implemented   
-
      -
      -
      • -
    -
    • -

  • Other

    -
      -

    • GAMS functions such as sum, max, smax, etc. should use {}; Example: avg_outage(i) = sum{h,hours(h)*outage(i,h)} / 8760 ;

      • -

    • When including the semicolon on the end of a line there should be a space between the semicolon and the last character of the line (see previous example)

      • -

    • When using / / for a parameter declaration, place the closing semicolon on the same line as the final slash: / ;

      • -

    • Sums outside of equations (e.g., in e_reports) need not be split over multiple lines if they do not exceed the line limit

      • -

    • Do not use hard-coded numbers in equations or calculations. Values should be assigned to an appropriate parameter name that is subsequently used in the code.

      • -

    • Large input data tables should be loaded from individual data files for each table, preferably in *.csv format. Large data tables should not be manually written into the code but can be written dynamically by scripts or inserted with a $include statement.

      • -

    • Compile-time conditionals should always use a tag (period + tag name) to clearly define the relationships between compile-time conditional statements. Failure to do so hurts readability sometimes leads to compilation errors. Example:

      -
      $ifthen.switch1 Sw_One==A
-  Do Something
-$elseif.switch1 Sw_One==B
-  Do Something
-$else.switch1 Sw_One==C
-  Do Something
-$endif.switch1
-
      -
      -
      • -
    -
    • -
-
-
-
-

Input Conventions and Data Handling

-
-

Input Conventions

-
    -

  • Data read into b_inputs should already be filtered. E.g., if you are running ERCOT, only data for ERCOT should be included.

    -
      -

    • We did not structure things this way when we first built ReEDS, and it might not be possible to always meet this recommendation without a large amount of work. This recommendation represents the vision we are working toward rather than a requirement.

      • -

    • The same applies to scenarios. If there are multiple scenario options in a single file (e.g. inputs/carbonconstraints/co2_cap.csv), only the single scenario used in a model run should be copied to inputs_case and loaded in b_inputs.gms.

      • -
    -
    • -

  • Input csv files that are written to inputs_case should have the same name as the GAMS parameter that reads that csv file.

    -
      -

    • Example: trancap_init(r,rr,trtype) reads in trancap_init.csv

      • -
    -
    • -

  • Parameters read into b_inputs should also include a header that has the set names and then units for the values. An asterisk is required to keep GAMS from reading the header and throwing an error. Example:

    -

    image

    -
    • -

  • Parameters read into b_inputs should be surrounded by \(offlisting and \)onlisting so that they are not written to the .lst files.

    -
      -

    • Example:

      -
      parameter ev_static_demand(r,allh,allt) "--MW-- static electricity load from EV charging by timeslice"
-/
-$offlisting
-$ondelim
-$include inputs_case%ds%ev_static_demand.csv
-$offdelim
-$onlisting
-/ ;
-
      -
      -
      • -
    -
    • -

  • When a file read into b_inputs was created by an upstream script within the repository, include a note indicating which script created the file.

    -
      -

    • Example: “* Written by hourly_process.py”

      • -
    -
    • -

  • In general, parameter declarations (which are in long format) are preferred to table declarations. Table declarations are acceptable when the table format can significantly reduce the files size or when the format of the native data better matches the table format.

    • -

  • Files used as inputs for the repository are always placed in an appropriate location within the “inputs” folder. Input files are grouped topically.

    • -

  • When there are multiple input options for a given input, the input file name should be “{file}_{option}”. For example:

    -
      -

    • battery_ATB_2022_moderate

      • -

    • battery_ATB_2022_conservative

      • -
    -
    • -

  • If preprocessing is needed to create the input file that is placed in the ReEDS repository, the preprocessing scripts or workbooks should be included in the ReEDS-2.0_Input_Processing repository (https://github.nrel.gov/ReEDS/ReEDS-2.0_Input_Processing). Raw data files should be placed in that repository if their file size permits. Otherwise, raw data files should be placed in \nrelnas01\ReEDS\ _ReEDS Documentation.

    • -

  • Any scripts that preprocess data after a ReEDS run is started should be placed in the input_processing folder.

    -
      -

    • Input processing scripts should start with a block of descriptive comments describing the purpose and methodology, and internal functions should use docstrings and liberal comments on functionality and assumptions.

      • -
    -
    • -

  • Any costs read into b_inputs should already be in 2004$. Cost adjustments in preprocessing scripts should rely on the deflator.csv file rather than have hard-coded conversions.

    • -

  • In general, if inputs require calculations before they are ingested into b_inputs, those calculations should be done in Python rather than in GAMS. GAMS can be used for calculations where the GAMS syntax simplifies the calculation or where upstream dependencies make it challenging for the calculations to happen in Python preprocessing scripts.

    • -

  • In Python, file paths should be added using os.path.join() rather than writing out the filepath with slashes.

    • -

  • Data column headers should use the ReEDS set names when practical. For example, data that include regions should use “r” for the column name rather than “ba,” “reeds_ba,” or “region.”

    • -

  • Preprocessing scripts in input_processing should not change the working directory or use relative filepaths; absolute filepaths should be used wherever possible.

    • -
-
-
-

Input Data

-
    -

  • In general, all inputs less than ~10 MB should be in .csv format.

    -
      -

    • If the csv file would be larger than ~10 MB, then write it as a h5 file unless accessibility is especially important (e.g., the ReEDS_generator_database file needs to be easily accessible, so is kept as a csv file).

      • -

    • In some cases .txt files may be used as inputs if their format is especially convenient for the application.

      • -
    -
    • -

  • Input files should be included in the repository when possible.

    -
      -

    • Files too large to include in the repository or unnecessary for the repository (e.g., files used only for special circumstances, such as individual sites for wind and solar) should be included in the appropriate folder on nrelnas and can be copied to the local repository in the preprocessing steps.

      • -

    • Files stored on nrelnas should have unique names that identify the version of the file and data. For example, you would use “special_input_data_2022_11_28” rather than “special_input_data.”

      • -
    -
    • -

  • Add units to raw data files

    -
      -

    • When adding a new raw data file, include units in the column name to avoid confusion

      • -

    • As an example, look at ‘/inputs/plant_characteristics/conv_ATB_2023.csv’

      -
        -

      • The data in the “capcost” column are in unit of k\(/MW or \)/kW, although the units are not labeled

        • -

      • As a best practice, “capcost” should be named “capcost_usd.per.kw” to make units clear

        • -
      -
      • -
    -
    • -

  • Add comments to raw data files that represent GAMS subsets

    -
      -

    • When adding a new raw data file that represents a GAMS subset, include column headers representing the GAMS set that each column’s entries belong to, with the first column header being prepended by an asterisk (this allows GAMS to parse the first row of the .csv file as a comment)

      • -

    • For an example, see ‘/inputs/sets/fuel2tech.csv’

      • -
    -
    • -
-
-
-
-
-

Version Control and Testing

-
-

ReEDS Versioning & Releases

-

This section outlines the current ReEDS approach to versioning. You can find current and past ReEDS versions here: ReEDS-2.0 Releases

-
-

Versioning overview

-

GitHub Releases are used to create ReEDS versions on a monthly cadence after a suite of tests are performed. More on ReEDS testing can be found here. More information on GitHub Releases can be found in the GitHub Doc.

-

Releases are based on Git tags, and the proposed versioning scheme is EPOCH.RELEASE.PATCH. The components are:

-
    -

  • EPOCH: The current year, this will be incremented in January of each year (e.g., 2023)

    • -

  • RELEASE: Restarts from 0 when EPOCH is increased, then increased by 1 each month when the newest version is created

    • -

  • PATCH: Typically will just be 0, but could increment if an important update or bug fix needs to be merged in prior to the next monthly release.

    • -
-
-
-

Tagging versions

-

Tagging with GitHub releases is not done manually with each pull request. After a new release has been created, a tag will be generated.

-

How to use tags:

-
    -

  • You can check them out like any other commit: git checkout tags/2023.1.0

    -
      -

    • You may need to fetch tags to your machine first: git fetch --tags

      • -

    • If you plan to develop from an older tag (i.e., you’re not checking out main on the most recent tag and you plan to commit new changes), you’ll also want to specify a branch or create a new one: git checkout -b <new branch name> <tag name>

      • -
    -
    • -

  • ReEDS2X tool versions should reference the last ReEDS version they’re known to work for in their tag text or README

    -
      -

    • Each ReEDS run produces a meta.csv file with information on the branch, commit, and version of that run which can be used to determine the vintage of any given ReEDS run.

      • -
    -
    • -

  • If you’re using ReEDS2X for a side project and would like to tag versions for them to refer to, the suggested format is: EPOCH.RELEASE.PATCH.PROJECTNAME, where EPOCH.RELEASE.PATCH refers to the last version of main that has been merged into your project branch.

    -
      -

    • The same format can be used to tag specific versions of the model that are used for published analyses that are not merged into main, e.g. 2023.4.0.hybrids.

      • -

    • In general, please add custom components to the tail of the version number instead of the beginning to keep them easy to sort.

      • -
    -
    • -
-
-
-
-

Testing Guidelines

-

This section outlines the recommended testing that should be performed on ReEDS prior to creating a pull request or a new version.

-
-

Post-process Test

-

This testing should be performed when a change is made that does not change model code or data that might impact model outputs. Ex: changing the color styles in bokeh output plot, or adjusting a post-processing script such as runstatus.py

-
    -

  1. Ensure the post-processing capabilities operate correctly on outputs from the most recent version of main

    -
      -

    • A demonstration of this should be included in the pull request

      • -
    -
    2. -

  2. Verify that R2X pytest passes

    3. -
-
-
-

Light Test (Pacific Region)

-

This testing should be performed for changes to model code that are not expected to have any meaningful impact on the model solution. Examples include:

-
    -

  • Rounding an input parameter

    • -

  • Changing the name of a column or model parameter

    • -

  • Updating code within an if statement where the if statement does not apply under default settings (e.g., “if int(sw.GSw_calc_powfrac):” where the default value of sw.GSw_calc_powfrac is 0)

    • -

  • Adding a missing entry to run files.csv

    • -
-
    -

  1. Do a comparison run of the default test case (cases_test.csv) against a test run from main and produce a comparison report.

    -
      -

    • The report should be examined for any unexpected outputs and included in the pull request for review

      • -
    -
    2. -

  2. Verify that R2X pytest passes

    3. -
-
-
-

Regular Test (Full U.S.)

-

This testing should be performed for all other cases not covered by the post-process or light test

-
    -

  1. Do a comparison run of the default case (cases.csv) against a run from main and produce a comparison report.

    -
      -

    • You should be able to reasonably explain changes in capacity, generation, transmission capacity, bulk system electricity price, system cost, and runtime

      • -

    • The report should be included in the pull request

      • -
    -
    2. -

  2. Verify that R2X pytest passes

    3. -
-
-
-

New Version Test

-

This testing is required for a new tagged and released version

-

The full set of scenarios in cases_test.csv is run on HPC and Yampa (tests are also run locally on Mac or Windows, with the exception of the USA_decarb scenario). All test scenarios, with the exception of the following, must succeed in order for a new version to be created:

-
    -

  • Pacific test case with water constraints

    • -

  • Pacific test case with PVB turned on

    • -

  • Pacific test case with detailed CO2 transport & storage

    • -

  • Pacific test case with representatives weks

    • -

  • Pacific test case with full chronological year

    • -
-

For any error in the output processing scripts, a new GitHub issue should be created. Additionally, the issue should be noted in the release notes for the new version.

-

Lastly, comparison reports are created for the USA and USA_decarb scenarios to compare the current version with the previous released version. Those comparison reports should be attached to the release notes for reference.

-
-
-
-
-

Documentation Guidelines

-

When making changes to ReEDS, you should generate and update the sources.csv and sources_documentation.md files before merging.

-
-

How to Use Sources Documentation

-
    -

  1. Before running the .bat script, please ensure the sources.csv file is closed. If open, the script will be unable to replace the file and will throw an error.

    2. -

  2. Run generate_sources_md_file.bat script (for Mac and Linux users generate_sources_md_file.sh)located within the documentation_tools folder (ReEDS-2.0/docs/source/documentation_tools). You will need navigate to that directory prior to running.

    3. -

  3. This will run the first script generate_new_sources.py. generating a new sources.csv file at the top directory of the repository, please note,the existing sources.csv in your Repository root will be renamed to sources_{timestamp}.csv format. This can be deleted manually if no longer required; or can be held on to if required for comparison. Tree change files are generated in the documentations_tools folder to indicate files not included in the prior sources file (sources_files_added.csv), files removed from the prior sources file (sources_files_deleted.csv), and files not included in the sources file because they aren’t committed (sources_untracked_files.csv). These change files should not be committed and can be deleted when no longer needed.

    4. -

  4. Once this has finished running, please proceed to update relevant fields in the sources.csv file

    5. -

  5. Once relevant fields have been updated, please save sources.csv and close it.

    6. -

  6. Run generate_markdown.bat (for Mac and Linux users generate_markdown.sh)located within the documentation_tools folder. This will generate a README file sources_documentation.md with all the Source files and their details for the Repository by running the script generate_markdown.py. The markdown file will be generated in the ReEDS-2.0/docs/source/ location.

    7. -

  7. Commit and push the updated sources.csv and sources_documenation.md files.

    8. -
-
-
-

How to Update Relevant Fields in sources.csv

-
    -

  1. Once prompted by the .bat script, open sources.csv (found at the Repository root).

    2. -

  2. Using the Added Files List, sources_files_added.csv (found within the documentation_tools folder) which displays all the input files added by the user, enter relevant details in corresponding columns of sources.csv. Fields that do not apply can be left blank. Do not add new columns to sources.csv without also updating the scripts to support the expanded fields.

    3. -

  3. Save the sources.csv and close the file.

    4. -
-
-
-
-

Updating the ReEDS Documentation

-

Additionally, the general ReEDS documentation lives in the “docs/source” folder within the repo. Depending on the changes you’re making to the model, please update the documentation here accordingly.

-

To edit the ReEDS documentation:

-
    -

  1. Find the markdown file you would like to modify under the “docs/source” folder

    2. -

  2. Make any necessary changes and save the file

    3. -

  3. Commit and push your changes as you normally would.

    -
      -

    • When your pull request gets merged into main, there is a github action that will automatically recompile the documentation with your changes and publish the updated site.

      • -
    -
    4. -
-

If you would like to see what the documentation will look like when developing locally, you can do that with the following process:

-
    -

  1. Navigate to the “docs/” folder

    2. -

  2. Run the command make html to build the documentation locally

    -
      -

    • Ensure you have the ‘reeds2’ environment activated

      • -
    -
    3. -

  3. From Finder/File Explorer, open the folder “/ReEDS-2.0/docs/build/html” then click on “index.html”

    -
      -

    • This will launch the documentation in a new internet window

      • -

    • If you make changes and wish to see how they are reflected in the documentation, you can run the make html command again and refresh the window you already have open

      • -
    -
    4. -

  4. If you would like to remove the generated files, you can run the command make clean from the “docs/” folder

    5. -
-
-
-

Adding Citations in the Documentation

-

To add an in-text citation, find the citation key of the citation you would like to add in Zotero. The format to include an in-text citation in markdown is as follows:

-
    -

  • Regular citation: {cite}`citation key`

    • -

  • Citation with just the year: {cite:year}`citation key`

    • -

  • Multiple citations: {cite:p}`citation key 1, citation key 2`

    • -
-
-../_images/zotero_citation_example.png -
-

Fig. 20 Example of citation key in Zotero

-
-
-

Alternatively, you can use the “Zotero Citation Picker” VS Code extension for finding/adding references to the documentation. This extension requires Zotero to be installed, as well as Better BibTex for Zotero (the Better BibTex for Zotero installation guide can be found here).

-
-
-
-

Pull Request Best Practices

-
-

Best Practices for Creating PRs

-

To ensure a smooth process and maintain quality of the ReEDS model, the following are best practices that should be followed when creating a pull request:

-
    -

  • Prior to creating a pull request, perform the appropriate level of testing on your branch

    -
      -

    • The Full U.S. test (in cases.csv) will be used in most cases

      • -

    • For more information on testing, see the Testing Guidlines section

      • -
    -
    • -

  • Ensure the title of your pull request is both descriptive and concise

    -
      -

    • This is crucial, as the title of your pull request will be used in the summary of changes for each new version of ReEDS

      • -
    -
    • -

  • Fill out the pull request template in detail

    -
      -

    • The description should be clear enough for someone not directly involved in your work to grasp the changes being proposed

      • -

    • Assign and contact reviewers

      -
        -

      • Best practice is to have 2 reviewers from the ReEDS team

        • -
      -
      • -
    -
    • -

  • Keep your pull request in draft mode until it is ready to be merged into the main branch, indicating to reviewers that it is still a work in progresss

    • -

  • Provide a charge code to your reviewers for their time spent reviewing

    • -

  • Create smaller pull requests more frequently when possible

    -
      -

    • This helps avoid merge conflicts and simplifies the review process, making it more manageable for reviewers

      • -
    -
    • -

  • After creating the pull request, monitor the status of the automated tests

    -
      -

    • This runs the R2X test automatically

      • -
    -
    • -

  • Prior to merging your pull request, make sure to update the relevant documentation to reflect your changes. There are two places that should be updated (more information on this can be found in the documentation guidelines):

    -
      -

    1. Sources_documentation

      2. -

    2. The ‘docs/’ folder within the repository

      3. -
    -
    • -
-
-
-

Resolving Merge Conflicts

-

Sometimes you might run into merge conflicts when trying to merge your branch into another branch. Merge conflicts happen when there are competing commits that Git needs you to help decide which changes should be kept in the final merge.

-

Merge conflicts must be resolved prior to merging a pull request and there are different ways to handle merge conflicts:

- -
-
-

Tips and Best Practices for PR Reviews

-

The following are best practices that should be considered when reviewing pull requests:

-
    -

  1. Understand the context of the pull request

    -
      -

    • Prior to reviewing any code changes, read the PR thoroughly

      -
        -

      • Is the title descriptive?

        • -

      • Does the summary accurately state what the PR is trying to accomplish?

        • -

      • Is there sufficient information in the pull request to accurately convey the changes being made? Because the PR is documenting the change, part of your review entails ensuring that the model changes are properly reflected in the PR text.

        • -

      • What is the high-level impact of this PR? Can you summarize the change on the run results in 1-2 sentences?

        • -
      -
      • -

    • Look at any linked issues or pull requests and understand what is being fixed in this pull request and which issues or incompatibilities are not being addressed.

      • -
    -
    2. -

  2. Look at the compare report and any other figures included in the PR

    -
      -

    • Do you understand why these code/file changes resulted in these results?

      • -

    • What is the high-level impact of this PR? Can you summarize the change on the run results in 1-2 sentences?

      • -

    • Are these changes explainable/justifiable to both our internal and external audiences?

      • -
    -
    3. -

  3. Review the code

    -
      -

    • Look at each file that has changed

      -
        -

      • Do code changes or new code added make sense?

        • -

      • Ensure newly added code is documented (even if it’s just a single-line comment)

        • -

      • Flag any instances where you notice that the code does not follow the Coding Conventions

        • -

      • Identify if/how these code changes could cause problems later.

        -
          -

        • What other parts of the model do these changes interact with? Is that interaction broken or no longer an accurate representation with these changes?

          • -

        • What could break if we ran different scenarios with these changes? We typically look at the impact of our changes on “main” or “Standard Scenarios Mid-Case” type runs but also consider the potential impact on decarbonization scenarios, county level runs, smaller region runs, scenarios with hydrogen enabled, etc. We want to foresee any possible impacts this might have. If you have a concern or are curious about how this change might impact a certain type of run, ask the PR author, they might have looked at similar scenarios.

          • -
        -
        • -
      -
      • -
    -
    4. -

  4. Look at any input files that have changed

    -
      -

    • Reviewing the commit history can sometimes be helpful in determining what has changed

      • -

    • Do the input changes make sense? Are they consistent with the PR descriptions?

      • -

    • There are a couple tools that help with comparing two different csv files:

      - -
      • -
    -
    5. -

  5. Check out the branch locally (optional)

    -
      -

    • You should check the branch out locally and run the test scenario(cases_test.csv) to ensure there are no issues

      • -

    • If there are a large amount of changes to one of the scripts or code files (ex. input_processing scripts or GAMS files), it could be helpful to run just that script and walk through it line by line with a debugging tool (ex. pdb) to more deeply understand how the revised script functions and any issues we might face with the way that script is now written.

      • -
    -
    6. -
-

A few notes on reviewing pull requests:

-
    -

  • When reviewing PRs, be sure to provide constructive feedback and highlight positive aspects as well. Reviewing PRs is an opportunity to learn from one another and support each other’s development as developers!

    • -

  • Ask clarifying questions if something is unclear

    -
      -

    • Reviewing PRs can be daunting if you are new to the team or to the code development process. Remember that this is an opportunity for you to learn more about the model as much as it is about getting the code changes integrated into the model. Even experienced developers make errors, hence the importance of getting a second set of eyes on the code changes. Your input and insights are valuable.

      • -

    • If you don’t understand what is going on with a code change, chances are high that others won’t understand either, so ask for clarification, including asking for more comments or explanation in the PR text.

      • -

    • If there is a section of the PR that you don’t feel comfortable reviewing, you should request a review from another team member

      • -
    -
    • -

  • Request changes as necessary and explain your reasoning

    • -

  • Remember that the PR submitter is ultimately responsible for the changes in the PR, not you, so give the PR review a good effort, but don’t agonize over every detail.

    -
      -

    • If reviewing a PR becomes too large of a chore, feel free to reach out to others on the team to be able to tackle the PR review jointly

      • -
    -
    • -

  • If necessary, make sure the ReEDS documentation was updated to reflect the code changes

    -
      -

    • Instructions for how to update the documentation can be found here

      • -
    -
    • -
-
-
-
-

ReEDS Development Tips

-
-

Debugging Python Code

-

When working with python code, there are a couple of useful methods for debugging. The first is using the Python Interactive Window.

-

Cells are denoted by #%%, and you can run the code in a given file by cells in the interactive window. This allows you to view data and variables, as well as create graphs and visuals. This can be very helpful in stepping through a script to see what is happening in your code.

-

For more information, see the Python Interactive Window documentation.

-

Another way to debug is to use the Python Debugger Extension in VS Code. For more information on how to set up and use the python debugger, see Python debugging in VS Code.

-

When using the python debugger, you will need to set a configuration. Here’s an example of what that might look like (launch.json file):

-
{
-    // Use IntelliSense to learn about possible attributes.
-    // Hover to view descriptions of existing attributes.
-    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
-    "version": "0.2.0",
-    "configurations": [
-        {
-            "name": "Python Debugger: calc_financial_inputs.py with arguments",
-            "type": "debugpy",
-            "request": "launch",
-            "program": "${file}",
-            "console": "integratedTerminal",
-            "args": [
-                "/Users/kminderm/ReEDS-2.0",
-                "/Users/kminderm/ReEDS-2.0/runs/main_Pacific/inputs_case"
-            ],
-            "purpose": ["debug-in-terminal"]
-        },
-
-    ]
-}
-
-
-

For more on debugging, you can watch the following video: GPAC’s WEI Tips and Tricks Series: Introduction to Debugging

-
-
-

Debugging GAMS Code

-

When making changes to the GAMS code, something that can be helpful when debugging an issue is to compare the data before and after your change. You can do that by inserting an ‘execute unload’ statement into the gams code. Example of what this looks like:

-
execute_unload 'before.gdx' ;
-
-
-

If you’re interested in only a specific variable, you can specify it like this:

-
execute_unload 'before.gdx' valcap ; 
-
-
-

Additionally, if you want to re-run a given scenario without having to run all of the input processing again, you can open the call_{batch name}_{case}.bat/.sh file, delete all of the lines you don’t want to run again, and then run that file from the command line. Note: be sure to edit/run the call_{batch name}_{case}.bat/.sh file from within the specific run folder

-
-
-

Additional Development Tips

-
    -

  • To avoid the prompts when kicking off a run, you can use the command line arguments:

    -
      -

    • The following example runs the scenarios in cases_test.csv with the batch name ‘20240717_test’. The ‘-r -1’ means that all cases will run simultaneously.

      • -
    -
    python runbatch.py -c test -b 20240717_test -r -1
-
    -
    -
      -

    • All options for command line arguments that can be used:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

      Flag

      --BatchName / -b

      Name for batch of runs

      --cases_suffix / -c

      Suffix for cases CSV file

      --single / -s

      Name of a single case to run (or comma-delimited list)

      --simult_runs / -r

      Number of simultaneous runs. If negative, run all simultaneously

      --forcelocal / -l

      Force model to run locally instead of submitting a slurm job

      --restart / -r

      Switch to restart existing ReEDS runs

      --skip_checks / -f

      Force run, skipping checks on conda environment and switches

      --debug / -d

      Run in debug mode (same behavior as debug switch in cases.csv)

      --debugnode / -n

      Run using debug specifications for slurm on an hpc system

      -
      • -
    -
    • -

  • If you’re on Mac and would like to have the terminal always show what branch you’re on, you can set up Git Bash for Mac with the following: Git Bash for Mac

    • -

  • Using the following run name format keeps your runs folder organized: ‘vYYYYMMDD’

    • -
-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/developer_tips.html b/docs/build/html/internal/developer_tips.html deleted file mode 100644 index 0f4189da..00000000 --- a/docs/build/html/internal/developer_tips.html +++ /dev/null @@ -1,215 +0,0 @@ - - - - - - - ReEDS Development Tips — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

ReEDS Development Tips

-
-

Debugging Python Code

-

When working with python code, there are a couple of useful methods for debugging. The first is using the Python Interactive Window.

-

Cells are denoted by #%%, and you can run the code in a given file by cells in the interactive window. This allows you to view data and variables, as well as create graphs and visuals. This can be very helpful in stepping through a script to see what is happening in your code.

-

For more information, see the Python Interactive Window documentation.

-

Another way to debug is to use the Python Debugger Extension in VS Code. For more information on how to set up and use the python debugger, see Python debugging in VS Code.

-

When using the python debugger, you will need to set a configuration. Here’s an example of what that might look like (launch.json file):

-
{
-    // Use IntelliSense to learn about possible attributes.
-    // Hover to view descriptions of existing attributes.
-    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
-    "version": "0.2.0",
-    "configurations": [
-        {
-            "name": "Python Debugger: calc_financial_inputs.py with arguments",
-            "type": "debugpy",
-            "request": "launch",
-            "program": "${file}",
-            "console": "integratedTerminal",
-            "args": [
-                "/Users/kminderm/ReEDS-2.0",
-                "/Users/kminderm/ReEDS-2.0/runs/main_Pacific/inputs_case"
-            ],
-            "purpose": ["debug-in-terminal"]
-        },
-
-    ]
-}
-
-
-

For more on debugging, you can watch the following video: GPAC’s WEI Tips and Tricks Series: Introduction to Debugging

-
-
-

Debugging GAMS Code

-

When making changes to the GAMS code, something that can be helpful when debugging an issue is to compare the data before and after your change. You can do that by inserting an ‘execute unload’ statement into the gams code. Example of what this looks like:

-
execute_unload 'before.gdx' ;
-
-
-

If you’re interested in only a specific variable, you can specify it like this:

-
execute_unload 'before.gdx' valcap ; 
-
-
-

Additionally, if you want to re-run a given scenario without having to run all of the input processing again, you can open the call_{batch name}_{case}.bat/.sh file, delete all of the lines you don’t want to run again, and then run that file from the command line. Note: be sure to edit/run the call_{batch name}_{case}.bat/.sh file from within the specific run folder

-
-
-

Additional Development Tips

-
    -

  • To avoid the prompts when kicking off a run, you can use the command line arguments:

    -
      -

    • The following example runs the scenarios in cases_test.csv with the batch name ‘20240717_test’. The ‘-r -1’ means that all cases will run simultaneously.

      • -
    -
    python runbatch.py -c test -b 20240717_test -r -1
-
    -
    -
      -

    • All options for command line arguments that can be used:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

      Flag

      --BatchName / -b

      Name for batch of runs

      --cases_suffix / -c

      Suffix for cases CSV file

      --single / -s

      Name of a single case to run (or comma-delimited list)

      --simult_runs / -r

      Number of simultaneous runs. If negative, run all simultaneously

      --forcelocal / -l

      Force model to run locally instead of submitting a slurm job

      --restart / -r

      Switch to restart existing ReEDS runs

      --skip_checks / -f

      Force run, skipping checks on conda environment and switches

      --debug / -d

      Run in debug mode (same behavior as debug switch in cases.csv)

      --debugnode / -n

      Run using debug specifications for slurm on an hpc system

      -
      • -
    -
    • -

  • If you’re on Mac and would like to have the terminal always show what branch you’re on, you can set up Git Bash for Mac with the following: Git Bash for Mac

    • -

  • Using the following run name format keeps your runs folder organized: ‘vYYYYMMDD’

    • -
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/documentation_guidelines.html b/docs/build/html/internal/documentation_guidelines.html deleted file mode 100644 index 84ae90df..00000000 --- a/docs/build/html/internal/documentation_guidelines.html +++ /dev/null @@ -1,184 +0,0 @@ - - - - - - - Documentation Guidelines — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Documentation Guidelines

-

When making changes to ReEDS, you should generate and update the sources.csv and sources_documentation.md files before merging.

-
-

How to Use Sources Documentation

-
    -

  1. Before running the .bat script, please ensure the sources.csv file is closed. If open, the script will be unable to replace the file and will throw an error.

    2. -

  2. Run generate_sources_md_file.bat script (for Mac and Linux users generate_sources_md_file.sh)located within the documentation_tools folder (ReEDS-2.0/docs/source/documentation_tools). You will need navigate to that directory prior to running.

    3. -

  3. This will run the first script generate_new_sources.py. generating a new sources.csv file at the top directory of the repository, please note,the existing sources.csv in your Repository root will be renamed to sources_{timestamp}.csv format. This can be deleted manually if no longer required; or can be held on to if required for comparison. Tree change files are generated in the documentations_tools folder to indicate files not included in the prior sources file (sources_files_added.csv), files removed from the prior sources file (sources_files_deleted.csv), and files not included in the sources file because they aren’t committed (sources_untracked_files.csv). These change files should not be committed and can be deleted when no longer needed.

    4. -

  4. Once this has finished running, please proceed to update relevant fields in the sources.csv file

    5. -

  5. Once relevant fields have been updated, please save sources.csv and close it.

    6. -

  6. Run generate_markdown.bat (for Mac and Linux users generate_markdown.sh)located within the documentation_tools folder. This will generate a README file sources_documentation.md with all the Source files and their details for the Repository by running the script generate_markdown.py. The markdown file will be generated in the ReEDS-2.0/docs/source/ location.

    7. -

  7. Commit and push the updated sources.csv and sources_documenation.md files.

    8. -
-
-
-

How to Update Relevant Fields in sources.csv

-
    -

  1. Once prompted by the .bat script, open sources.csv (found at the Repository root).

    2. -

  2. Using the Added Files List, sources_files_added.csv (found within the documentation_tools folder) which displays all the input files added by the user, enter relevant details in corresponding columns of sources.csv. Fields that do not apply can be left blank. Do not add new columns to sources.csv without also updating the scripts to support the expanded fields.

    3. -

  3. Save the sources.csv and close the file.

    4. -
-
-
-
-

Updating the ReEDS Documentation

-

Additionally, the general ReEDS documentation lives in the “docs/source” folder within the repo. Depending on the changes you’re making to the model, please update the documentation here accordingly.

-

To edit the ReEDS documentation:

-
    -

  1. Find the markdown file you would like to modify under the “docs/source” folder

    2. -

  2. Make any necessary changes and save the file

    3. -

  3. Commit and push your changes as you normally would.

    -
      -

    • When your pull request gets merged into main, there is a github action that will automatically recompile the documentation with your changes and publish the updated site.

      • -
    -
    4. -
-

If you would like to see what the documentation will look like when developing locally, you can do that with the following process:

-
    -

  1. Navigate to the “docs/” folder

    2. -

  2. Run the command make html to build the documentation locally

    -
      -

    • Ensure you have the ‘reeds2’ environment activated

      • -
    -
    3. -

  3. From Finder/File Explorer, open the folder “/ReEDS-2.0/docs/build/html” then click on “index.html”

    -
      -

    • This will launch the documentation in a new internet window

      • -

    • If you make changes and wish to see how they are reflected in the documentation, you can run the make html command again and refresh the window you already have open

      • -
    -
    4. -

  4. If you would like to remove the generated files, you can run the command make clean from the “docs/” folder

    5. -
-
-
-

Adding Citations in the Documentation

-

To add an in-text citation, find the citation key of the citation you would like to add in Zotero. The format to include an in-text citation in markdown is as follows:

-
    -

  • Regular citation: {cite}`citation key`

    • -

  • Citation with just the year: {cite:year}`citation key`

    • -

  • Multiple citations: {cite:p}`citation key 1, citation key 2`

    • -
-
-../_images/zotero_citation_example.png -
-

Example of citation key in Zotero

-
-
-

Alternatively, you can use the “Zotero Citation Picker” VS Code extension for finding/adding references to the documentation. This extension requires Zotero to be installed, as well as Better BibTex for Zotero (the Better BibTex for Zotero installation guide can be found here).

-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/hourlize.html b/docs/build/html/internal/hourlize.html deleted file mode 100644 index 388eae50..00000000 --- a/docs/build/html/internal/hourlize.html +++ /dev/null @@ -1,663 +0,0 @@ - - - - - - - Using Hourlize — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Using Hourlize

-
-

Hourlize

-
-

Overview

-

Hourlize processes hourly resource and load data into ReEDS inputs. The vision is for this module to allow maximum flexibility -temporally and spatially.

-

Hourlize is run by a call to run_hourlize.py, which assembles information on the cases to run and then executes a call to either -resource.py and load.py. The run_hourlize.py script can be used to set up jobs to submit to the HPC to run in parallel or to run hourlize jobs directly in sequence.

-
-

Quickstart: Resource

-
    -

  1. Copy any new reV supply curves to the supply curve folder and update the rev_paths file (details).

    2. -

  2. Update settings in config_base.json as needed (details).

    3. -

  3. Update settings in the relevant config_[tech].json files as needed (details).

    4. -

  4. Specify cases to run in cases.json or create your own cases file (details).

    5. -

  5. If running on the HPC, specify run allocation or other submission settings in hourlize/inputs/configs/srun_template.sh (details).

    6. -

  6. Run using run_hourlize.py resource (details).

    7. -
-
-
-

Quickstart: Load

-
    -

  1. Update settings in config_base.json as needed (details).

    2. -

  2. If running on the HPC, specify run allocation or other submission settings in inputs/configs/srun_template.sh (details).

    3. -

  3. Run using run_hourlize.py load (details).

    4. -
-

For more details and run options see further below.

-
-
-
-

Setup for reV supply curves

-

If you don’t have new reV supply curves you can probably skip this section and go down to running hourlize. However, if you are planning on pushing your supply curve outputs to the repo don’t forget to sync the shared directories.

-
-

1. Copy reV runs to reeds shared directory

-

Before running resource hourlize the reV runs should be copied from their original location to the shared folder. Currently reV data used in ReEDS (along with hourlize inputs and outputs) are stored in three places:

-
    -

  • on the nrelnas01 device at \\nrelnas01\ReEDS\Supply_Curve_Data

    • -

  • on Eagle at /shared-projects/reeds/Supply_Curve_Data

    • -

  • on Kestrel at /projects/shared-projects-reeds/reeds/Supply_Curve_Data

    • -
-

Under the appropriate tech folder (UPV, ONSHORE, OFFSHORE, etc.) create a directory with a descrptive name for the supply curves (e.g., 2023_06_06_Update). Then copy the reV supply curves and profiles into a folder called reV. A good approach is to use rsync; below is an example copying original reV files from Eagle to Kestrel:

-
rsync -aPu [username]@eagle.hpc.nrel.gov://shared-projects/rev/projects/seto/fy23/rev/standard_scenarios/aggregation/  /projects/shared-projects-reeds/reeds/Supply_Curve_Data/UPV/2023_06_06_Update/reV
-
-
-

Note that sometimes all the necessary files are in each supply curve folder and sometimes the reV team creates a separate “post_processed_supply_curves” folder that should also be copied.

-
-
-

2. Update the rev_paths files

-

Update the reV paths file at ReEDS-2.0/inputs/supplycurvedata/rev_paths.csv. Typically this means updating the information for whichever techs (e.g., upv, wind-ons, wind-ofs) and access cases (e.g., reference, open, limited) you want to run.

-

Some details on the additional columns to update:

-
    -

  • sc_path: path to the supply curve folder on the shared drive; should be of the format tech/update_name (e.g. UPV/2023_06_06_Update, ONSHORE/2023_07_28_Update).

    • -

  • rev_case: name of the reV case to be used for this scenario; this should reference a directory in the “reV” folder with the sc_path (e.g., if 02_limited is one of the rev_case values for upv, then there should be a folder called UPV/2023_06_06_Update/reV/02_limited).

    • -

  • original_sc_file: path to the original reV supply curve csv file (i.e., before hourlize pre-processing). Specified relative to the “reV” folder within the corresponding sc_path.

    • -

  • original_rev_folder: full path of the original location of the supply curves passed by the reV team. Not actively used but useful for debugging issues with the reV runs.

    • -

  • cf_path: full path to the generation file used for the reV runs. This can typically be found in the config_aggregation.json file from the reV run as gen_fpath. An exception is for bespoke wind runs, in which case this should point to the reV profiles. Needed for R2P.

    • -
-
-
-

3. Run hourlize

-

Follow setup details here.

-

Hourlize relies on a set of columns being in the reV supply curve. In some cases hourlize can fill in missing columns hourlize in a pre-processing step, but in others these missing columns can cause hourlize to fall. A list of required columns can be found in hourlize/inputs/resource/rev_sc_columns_for_hourlize.csv

-
-
-

4. Synchronize shared directories

-

If you’re copying the hourlize outputs back to the shared repository (copy_to_shared=True) you’ll want to sync up the two shared folders, as the copy function currently only copies to one directory.

-

When starting from the HPC be sure to open up permissions to the supply curve outputs you’ve just created (e.g., chmod -R 777 UPV/2023_06_06_Update). Then from your local computer use WinSCP or rsync to copy the files from Kestrel to nrelnas01:

-
rsync -aPu [username]@kestrel.nrel.gov://projects/shared-projects-reeds/reeds/Supply_Curve_Data/UPV/2023_11_02_LandCover /Volumes/ReEDS/Supply_Curve_Data/UPV
-
-
-

(back to overview)

-
-
-
-

Running hourlize

-
-

run_hourlize.py

-

The run_hourlize.py script serves as a wrapper for calling either load.py or resource.py. It does the following:

-
    -

  • Collect run(s) configuration settings from the relevant config files to build a consolidated config file for each run.

    • -

  • Runs formatting on config file entries.

    -
      -

    • Entries with {variable} in the text will have the {variable} text replaced with the value referenced by ‘variable’, which typically refers to another config entry or a file path.

      • -

    • Entries with {eval_expression} will evaluate ‘expression’ as a python expression; useful for creating lists using ranges.

      • -

    • Combines all configs into a single config.json sent to resource.py.

      • -
    -
    • -

  • Creates an output folder for the supply curve run in hourlize/out/[casename], where casename is defined in the cases.json file.

    • -

  • Creates a .sh or .bat script to run the case with a call to resource.py.

    • -

  • Optionally submits jobs to the HPC or initiates the runs directly.

    • -
-

Example calls:

-
python run_hourlize.py load                  # run load.py
-python run_hourlize.py resource              # run resource.py with default cases
-python run_hourlize.py resource -c suffix    # run resource.py with cases from cases_suffix.json
-python run_hourlize.py resource --local      # if on HPC run all cases sequentially on current node without batch submission to slurm
-python run_hourlize.py resource --nosubmit   # if on HPC create launch scripts and input folders but don't submit runs
-
-
-

To see details on all command line arguments run python run_hourlize.py -h.

-

After setting up the run, if specified run_hourlize.py will launch the .sh or .bat file which performs the following call to resource.py:

-
python resource.py --config /path/to/hourlize/[casename]/inputs/config.json
-
-
-
-
-

Config jsons

-

Hourlize uses a set of json config files to provide information on how to process the supply curves. These files are located in hourlize/inputs/configs:

-
    -

  • Cases file (cases.json): list of resource cases to run (currently not applicable to load.py)

    • -

  • Tech config (config_[tech].json): tech specific settings for the resource.py script for upv, wind-ons, and wind-ofs

    • -

  • Base config (config_base.json): general hourlize settings (shared) as well as specific settings for the resource and load processes

    • -
-

The run_hourlize.py process will generate a final config (config.json) from the relevant base and tech configs for each run, as depicted in the figure below. In general the settings in the cases.json file unique to each run while the settings in the tech and base configs aren’t frequently changed. In the case of duplicated entries across configs hourlize uses the following order of precedence: cases > tech > base.

-

hourlize_configs

-

The srun_template.sh file is used to govern HPC submission settings. Update with your allocation, email, and any other slurm specifications before submitting jobs. There is also a command line argument to via run_hourlize.py for running jobs using the debug partition.

-

For more details on the meaning of the different config settings see the tables at the bottom of this README (link).

-
-
-

Cases json

-

The cases json provides a list of resource supply curve cases to process. The default cases file (case.json) includes all supply curves typically needed for ReEDS for BA- and county-resolution runs. Users can also build their own cases file of the format cases_[case_suffix].json.

-

Each entry should be given a casename for the supply curve run in the format [tech]_[access_case]_[resolution].

-
    -

  • Supported values for tech: upv, wind-ofs, wind-ons.

    • -

  • Supported values for resolution: ba, county.

    -
      -

    • Make sure the entry for resolution aligns with the reg_out_col entry (ba: “ba”, county: “cnty_fips”).

      • -
    -
    • -

  • Typical values for access_case: reference, open, or limited.

    -
      -

    • Other values allowed but must match values in access_case column of the rev_paths file (typically at ReEDS-2.0/inputs/supply_curve/rev_paths.csv but can be specified in config_base.json).

      • -
    -
    • -
-

To link a case to a custom set of config files users can add entries for config_base and config_tech in the case defintion. For example, adding config_base:test would link that case to the settings in config_base_test.json instead of the typical config_base.json file.

-

Other key/value pairs in the cases.json file can also be used as subsetting variables for downselecting relevant rows from the corresponding rev_paths file. This can helpful when running hourlize for cases that don’t just differ by access and tech. To use this add the key/value pair from the rev_paths_file to the relevant cases and to the list of subsetvars in the base config.

-

The current cases.json file in the repository contains all the settings to run the supply curves currently maintained by ReEDS.

-
-
-

Tips

-
    -

  • If you want the hourlize runs to be copied back the shared supply curve folder, set copy_to_shared = true.

    -
      -

    • Note: this script currently only copies to one of the shared folders (the HPC or nrelnas01), so you’ll need to sync up the two after copying.

      • -
    -
    • -

  • By default hourlize is set up to copy outputs into the ReEDS repo (copy_to_reeds = true).

    • -

  • reg_out_col is typically either ‘ba’ for ReEDS regions or ‘cnty_fips’ for county-level supply curves, but can also be set to any column in the file specified by reg_map_path (which will be merged to the supply curve file by county fips code) or to a column in the supply curve file itself.

    • -
-

(back to overview)

-
-
-
-

Resource Logic (resource.py)

-
-

Inputs

-

The main inputs to hourlize are reV outputs for a given reV scenario:

-
    -

  • sc_path (in rev_paths.csv): a supply curve csv file for a given technology, with rows for each resource site and columns of metadata.

    • -

  • rev_path (in rev_paths.csv): A directory that contains h5 file(s) with hourly generation profiles for each site of the supply curve file for weather years 2007-2013.

    • -
-
-
-

Outputs

-

By default, the outputs will be dumped to a subdirectory named results within hourlize/out/[casename]. In addition, with copy_to_reeds set to true (as is default), we’ll copy the results to the ReEDS repo containing this hourlize directory, and withcopy_to_shared set to true (not default), we’ll copy to the shared drive (see Shared Drive Locations below).

-
    -

  • {tech}_supply_curve.csv: A supply curve with rows for each site and columns for region, class, available capacity, and costs. E.g. see inputs/supply_curve/wind-ons_supply_curve-reference_ba.csv (within ReEDS repo)

    • -

  • {tech}_exog_cap.csv: Exogenous (built pre-2010) capacity with columns for region, site and year. This is not capacity builds in each year, but rather cumulative capacity of each existing site over time. E.g. see inputs/capacity_exogenous/wind-ons_exog_cap_reference_ba.csv (within ReEDS repo)

    • -

  • {tech}_prescribed_builds.csv: Capacity prescribed builds (2010 - present) with columns for region, year, capacity. This is the installed capacity in each year rather than cumulative capacity over time. E.g. see inputs/capacity_exogenous/wind-ons_prescribed_builds_reference_ba.csv (within ReEDS repo)

    • -

  • {tech}_.h5: An hourly (7 weather year) generation profile file with a separate profile for each region/class. E.g. see inputs/variability/multi_year/wind-ons-reference_ba.h5 (within ReEDS repo)

    • -
-
-
-

Shared Drive Locations

-

Hourlize resource inputs and outputs in the same places as the copies of the reV supply curves (see details here). Whereas the reV supply curves are stored within a folder called reV, the hourlize runs can be found directly in the corresponding tech folder (e.g., UPV, OFFSHORE, ONSHORE).

-
-
-

Logic

-

The resource.py script follows the following logic (in order of execution):

-
    -

  1. get_supply_curve_and_preprocess()

    -
      -

    • The supply curve is filtered if necessary, based on filter_cols.

      • -

    • A ‘region’ column is added to the supply curve and filled with the selected regionality (reg_out_col).

      • -

    • Existing sites from a generator database (existing_sites) are assigned to supply curve points for exogenous and prescribed capacity outputs.

      • -

    • If we have minimum capacity thresholds for the supply curve points, these are applied to further filter the supply curve.

      • -
    -
    2. -

  2. add_classes()

    -
      -

    • A ‘class’ column is added to the supply curve and filled with the associated class. Classes can be based on statically defined conditions for columns in the supply curve (class_path). Otherwise (or layered on top of static class definitions), dynamic classes can be assigned (class_bin=true) using a binning method (class_bin_method, e.g. “kmeans”), a number of bins (class_bin_num), and the supply curve column to bin (class_bin_col). The binning logic itself is in get_bin(). The current default classes for onshore wind and utility-scale PV are based on national k-means clustering of average annual capacity factor (where higher class number corresponds with higher annual CF). Offshore wind, by contrast, uses statically defined classes from hourlize/inputs/resource/wind-ofs_resource_classes.csv.

      • -
    -
    3. -

  3. add_cost()

    -
      -

    • A column of overall supply curve costs is added to the supply curve (supply_curve_cost_per_mw), as well as certain components of that cost (e.g. trans_adder_per_mw and capital_adder_per_mw). Logic for these costs depends on tech, and the value of cost_out in config (e.g. combined_eos_trans for onshore wind).

      • -

    • A column of overall supply curve costs is added to the supply curve (supply_curve_cost_per_mw), as well as certain components of that cost (e.g. trans_adder_per_mw and capital_adder_per_mw). Logic for these costs depends on tech, and the value of cost_out in config (e.g. combined_eos_trans for onshore wind).

      • -
    -
    4. -

  4. save_sc_outputs()

    -
      -

    • Supply curve outputs are saved ({tech}_supply_curve.csv) as well as exogenous capacity ({tech}_exog_cap.csv), which is built pre-2010, and prescribed builds ({tech}_prescribed_builds.csv), which are built between 2010 and present day.

      • -
    -
    5. -

  5. get_profiles_allyears_weightedave()

    -
      -

    • The hourly generation profiles are gathered, and capacity-weighted average profiles are calculated for each region/class.

      • -
    -
    6. -

  6. shift_timezones()

    -
      -

    • Roll the hourly profiles from resource_source_timezone to output_timezone.

      • -
    -
    7. -

  7. save_time_outputs()

    -
      -

    • Save the weighted average profiles by region/class to a {tech}.h5 file.

      • -
    -
    8. -

  8. map_supplycurve()

    -
      -

    • Create output maps for supply curve

      • -
    -
    9. -

  9. copy_outputs()

    -
      -

    • Copy outputs from the new directory within hourlize/out to the corresponding input files in the ReEDS repo (copy_to_reeds) and/or shared drive (copy_to_shared)

      • -
    -
    10. -
-
-
-
-

Load Logic (load.py, THIS SECTION IS OUTDATED)

-
    -

  • Hourly PLEXOS region load data is first converted into ReEDS BA-level data by plexos_to_reeds/plexos_to_reeds.py

    -
      -

    • See plexos_to_reeds/README.md for more details

      • -
    -
    • -
-
    -

  1. If specified, we reduce the hourly data to one year.

    2. -

  2. If specified, we remove the final day from leap years.

    3. -

  3. If specified, we shift the data into local time of each BA.

    4. -

  4. If specified, we calibrate each year of hourly data to EIA 2010 load data by state combined with load participation factors by BA. These load participation factors are from heritage ReEDS load inputs, which I believe were derived from Ventyx 2006 county-level load data.

    5. -

  5. For each BA we calculate average load by timeslice and peak load by season.

    6. -

  6. The load profiles, means by timeslice, and peaks by season are sent to a new folder in out/

    7. -
-
    -

  • Current inputs and outputs are stored here: \\nrelnas01\ReEDS\Supply_Curve_Data\LOAD\

    • -
-

See comments in those files for more information.

-

(back to overview)

-
-
-

Details on config file settings

-

This section provides some descriptions and typical values for the settings in the config files (see above for a general overview of these config files).

-
-

Shared config

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Setting

Description

Default

compression_opts

file compression options. can select from 0-9: 0 is faster and larger, 9 is slower and smaller, 4 is default

4

filetype

output filetype: ‘csv’ or ‘h5’. Note that load.py uses h5 regardless for default (historical) and EER load

‘h5’

hierarchy_path

Path to ReEDS hiearchy file. Typically used for region mapping for resource.py and calibration/variability outputs for load.py

‘{reeds_path}/inputs/hierarchy.csv’

output_timezone

‘local’ means convert to local standard time of the respective region. UTC is 0. EST is -5.

‘local’

select_year

this is the year used for load and resource profile-derived inputs, although the profile outputs may still be multiyear (see hourly_out_years)

2012

start_1am

False means start at 12am

True

-
-
-

Resource config

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Setting

Description

Default

bin_group_cols

[‘region’,’class’]

bin_method

‘equal_cap_man’, ‘equal_cap_cut’. ‘kmeans’ currently commented out to prevent numpy depracation warnings from sklearn.

‘equal_cap_cut’

copy_to_reeds

Copy hourlize outputs to ReEDS inputs

True

copy_to_shared

Copy hourlize outputs to the shared drive

False

driver

‘H5FD_CORE’, None. H5FD_CORE will load the h5 into memory for better perforamnce, but None must be used for low-memory machines.

‘H5FD_CORE’

dtype

data type used to save hourly profiles

np.float16

existing_sites

None or path to file with existing capacity

this_dir_path + ‘../inputs/capacity_exogenous/ReEDS_generator_database_final_EIA-NEMS.csv’

gather_method

‘list’, ‘slice’, ‘smart’. This setting will take a slice of profile ids from the min to max, rather than using a list of ids, for improved performance when ids are close together for each group.

‘smart’

hourly_out_years

e.g. [2012] for just 2012 or list(range(2007,2014)) for 2007-2013

list(range(2007,2014))

inputfiles

list of files to copy over to hourlize input folder

[“reg_map_file”, “class_path”]

profile_id_col

Unique identifier for reV supply curve and profiles

‘sc_point_gid’

reg_map_path

This file maps counties to reeds regions. By default uses the ReEDS hiearchy file.

‘{hierarchy_path}’

resource_source_timezone

UTC would be 0, Eastern standard time would be -5

0

start_year

The start year of the model, for existing and sites purposes.

2010

state_abbrev

this_dir_path + ‘inputs/resource/state_abbrev.csv’

subsetvars

list of columns in the rev_paths file to use to select the appropriate rev_path

[‘tech’, ‘access_case’]

subtract_exog

Indicate whether to remove exogenous (pre-start_year) capacity from the supply curve [default False]

False

test_filters

dictionary definiting a set of columns and the corresponding values to subset the supply curve on

{‘region’:[‘p97’, ‘p98’]}

test_mode

This limits the supply curve based on the dictionary defined in test_filers

False

-
-
-

Tech configs

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Setting

Description

Default

cost_out

‘combined_eos_trans’ is a computed column from economies of scale and transmission cost. To turn off economies of scale, use ‘trans_cap_cost’. ‘combined_off_ons_trans’ is a computed column from offshore (array and export) as well as onshore transmission cost.

upv, wind-ons: ‘combined_eos_trans’
wind-ofs: ‘combined_off_ons_trans’

capacity_col

Format of the supply curve capacity column

upv: ‘capacity_mw_{upv_type}’
wind-ofs: ‘capacity_mw’
wind-ons: ‘capacity’

class_bin

This will layer dynamic bins. If class_path != None, we add region-specific bins for each of the classes defined in class_path.

upv, wind-ons: true
wind-ofs: false

class_bin_col

The column to be binned (only used if class_bin = True)

upv: ‘mean_cf_{upv_type}’
wind-ofs,wind-ons: ‘mean_cf’

class_bin_method

The bin method, either ‘kmeans’, ‘equal_cap_cut’, or ‘equal_cap_man’ (only used if class_bin = True)

‘kmeans’

class_bin_num

The number of class bins (only used if class_bin = True)

upv: 10
wind-ofs, wind-ons: 10

class_path

null or path to class definitions file

upv, wind-ons: null
wind-ofs: {hourlize_path}/inputs/resource/{tech}_resource_classes.csv

cost_adder_components

Supply curve cost columns to carry over to outputs

upv, wind-ons: [‘trans_adder_per_mw’, ‘capital_adder_per_mw’]
wind-ofs: []

distance_cols

can include distances for spur lin, reinforcements, and offshore wind export cable (typically in km)

upv, wind-ons: [‘dist_spur_km’,’dist_reinforcement_km’]
wind-ofs: [‘dist_spur_km’,’dist_reinforcement_km’,’dist_export_km’]

filter_cols

{} means use the entire dataframe; {‘offshore’:[‘=’,0]} means filter the supply curve to rows for which offshore is 0.

upv, wind-ons: {}
wind-ofs: {‘offshore’:[‘=’,0]}

min_cap

MW (LBNL utility-scale solar report & NREL PV cost benchmarks define utility-scale as ≥5 MW)

upv: 5, wind-ofs: 15, wind-ons: 0

profile_dir

Use ‘’ if .h5 files are in same folder as metadata, else point to them, e.g. f’../{rev_case}’

upv: ‘{access_case}_{upv_type}’
wind-ons, wind-ofs: ‘’

profile_dset

Name of hourly profiles in reV runs

‘rep_profiles_0’

profile_file_format

Format for hourly profiles filename. Note: unused if single_profile

upv: {rev_case}_rep-profiles
wind-ons, wind-ofs: ‘’

profile_weight_col

Name of column to use for weighted average of profiles. Using ‘capacity’ will link to whatever value is specified by ‘capacity_col’

‘capacity’

single_profile

single_profile has different columns and a single h5 profile file (for all years).

upv, wind-ofs: false, wind-ons: true

upv_type

type of UPV capacity and profiles to use; options are ‘ac’ and ‘dc’

upv: ‘dc’; wind-ons, wind-ofs: null

rev_jsons

list of reV json files to copy over

upv: [“config_aggregation.json”, “config_pipeline.json”, “config_supply-curve.json”, “{access_case}_{upv_type}/config_rep-profiles_aggprof.json”]
wind-ofs: [“config_aggregation.json”, “config_pipeline.json”, “config_supply-curve.json”, “config_rep-profiles.json”]
wind-ons: [“config_pipeline.json”, “config_supply-curve.json”, “sam.json”, “config_bespoke.json”]

-
-
-

Load config

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Setting

Description

Default

aeo_default

To calibrate data pre-use_default_before_yr

os.path.join(‘..’,’inputs’,’load’,’demand_AEO_2023_reference.csv’)

ba_frac_path

These are fractions of state load in each ba, unused if calibrate_path is False

os.path.join(this_dir_path,’inputs’,’load’,’load_participation_factors_st_to_ba.csv’)

ba_timezone_path

Should this be used for resource too, rather than site timezone?

os.path.join(this_dir_path,’inputs’,’load’,’ba_timezone.csv’)

calibrate_path

Enter path to calibration file or ‘False’ to leave uncalibrated

os.path.join(this_dir_path,’inputs’,’load’,’EIA_loadbystate.csv’)

calibrate_type

either ‘one_year’ or ‘all_years’. Unused if calibrate_path is False. ‘one_year’ means to only calibrate one year to the EIA data and then apply the same scaling factor to all years. ‘all_years’ will calibrate all each year to the EIA data.

‘all_years’

calibrate_year

This is the year that the outputs of load.py represent, based on the EIA calibration year. Unused if calibrate_path is False.

2010

dtypeLoad

Use int if the file size ends up too large.

np.float32

hourly_out_years

e.g. list(range(2021,2051)) for 2021-2050; must be a list even if only one year

list(range(2021,2051))

hourly_process

If False, skip all hourly processing steps

True

load_source

The load source file’s first column should be datetime, starting at Jan 1, 12am, stepping by 1 hour, and one column for each BA. It should be a csv or a compressed csv.

‘//nrelnas01/ReEDS/Supply_Curve_Data/LOAD/2020_Update/plexos_to_reeds/outputs/load_hourly_ba_EST.csv’

load_source_hr_type

Use ‘end’ if load_source data hour-ending or ‘begin’ for hour-beginning. For instantaneous use ‘end’. For EER load use ‘begin’.

‘begin’

load_source_timezone

UTC would be 0, Eastern standard time would be -5

-5

truncate_leaps

Truncate leap years. This currently needs to be True for mapping properly to timeslices.

True

us_only

Run only US BAs.

True

use_default_before_yr

Either False or a year. If set to a year, this will pull in ReEDS default load data before that year (2012 weather year)

2021

-

(back to overview)

-
-
-
-

For additional information on using Hourlize, you can watch the training video: Hourlize wind/solar resource preprocessing tutorial

-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/onboarding.html b/docs/build/html/internal/onboarding.html deleted file mode 100644 index 14d54348..00000000 --- a/docs/build/html/internal/onboarding.html +++ /dev/null @@ -1,320 +0,0 @@ - - - - - - - Onboarding Guide — ReEDS documentation - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Onboarding Guide

-

Welcome to the team!

-

New ReEDS team members should go over this guide to get set up with ReEDS. This onboarding guide is designed to be walked through independently, but please don’t hesitate to reach out to your PI if you run into issues or have questions.

-
-

General NREL Setup

-
-

Software Setup

-

You’ll need to get the following software installed by IT:

- -

To get software installed, you should follow this process to submit IT tickets:

-
    -

  1. Go to the IT Services Site

    2. -

  2. Click on ‘Get Help’ -* Assistance Type: ‘Order or install something new’ -* Give them the website to the software that you need

    3. -
-

IT will reply to your ticket when they are ready to install it. Typically, then you give them a call and they will take over your computer and install it.

-
-
-

GitHub Setup

-

NREL uses both github.com and github.nrel.gov (where ReEDS is). You will need both so please make accounts for both using your NREL email address.

-

If you’re unfamiliar with Git, you should start learning more about it. The following resources might be helpful:

- -

Additionally, Visual Studio Code has integrated source control management, allowing you to connect with GitHub directly from within the editor. For more information on how to do this, please refer to the following guide: Using Git source control in VS Code.

-
-
-

Mapping a Network Drive

-

On a Mac:

-
    -

  1. Open up Finder

    2. -

  2. Command + K

    3. -

  3. Type in ‘smb://nrelnas01/reeds’

    4. -

  4. You are now connected!

    5. -
-

Make a folder in the drive that reflects your project work. Preffered format is “FYXX-{project}-{your initials}”

-

On a PC:

-
    -

  1. Start on your local computer -> go to ‘This PC’, right click and select ‘Map network drive’

    2. -

  2. Chose whatever letter (it doesn’t matter which one) you want as your drive name, then type ‘\\nrelnas01\reeds’ into the Folder. Press Finish.

    3. -
-

Make a folder in the drive that reflects your project work. Preffered format is “FYXX-{project}-{your initials}”

-
-
-

Additional Items

-

The following items should be talked about with your PI:

-
    -

  • How to schedule a meeting in Teams

    • -

  • How to book an on-campus room

    • -
-

You should also review the GPAC Technical Guide.

-
-
-
-

ReEDS Specific Setup & Learning

-

Prior to getting ReEDS set up and running, you’ll want to ensure you have access to the ReEDS repo. If you do not have access, reach out to your PI to get added to the repository.

-
-

ReEDS Training Videos

-

NREL has a youtube channel that contains tutorial videos for ReEDS. The following are recommended videos for getting started with ReEDS:

- -

Note: if you have further questions after watching these videos, please follow up with your PI

-
-
-

Getting ReEDS Running Locally

-

After watching the youtube trainings, you should have a better sense of how ReEDS works and how to use it.

-

To get ReEDS running on your local machine, follow the setup guide. If you have questions, or run into issues with setup, please reach out to your PI.

-

Finally, now that you have ReEDS setup, you can run default ReEDS by walking through the following steps:

-
    -

  1. Open a new command line or terminal

    2. -

  2. Activate the ReEDS conda environment (can be doine with this command: conda activate reeds2)

    3. -

  3. Run runbatch.py (with the command: python runbatch.py) -* Enter the batch prefix (or batch name) -* Enter the case suffix - this will specify which scenario(s) should be run. You can leave this blank to use the default (cases.csv).

    4. -
-

How do you make sure your ReEDS run was successful?

-
    -

  • Are there outputs?

    -
      -

    • Check in the ‘/runs/[specific run name]/outputs’ folder, are there csv files? If not, something went wrong with the run.

      • -
    -
    • -

  • Did the ReEDS reports build?

    -
      -

    • Check in the ‘/runs/[specific run name]/outputs’ folder, are are subfolders named ‘reeds-report’ and ‘reeds-report-reduced’?

      • -
    -
    • -
-

Additional ReEDS Scenarios: -After running default ReEDS, you should take a look at some of the other common scenarios:

-
    -

  • Cases_test: contains some basic test scenarios for ReEDS

    • -

  • Cases_standardscenarios: contains the scenarios used for the Standard Scenarios report that is released yearly.

    • -
-
-
-

Getting ReEDS Running on Yampa

-

Some ReEDS runs are large and take a decent amount of memory to run. The remote machines have significantly more memory and are often used for this purpose.

-

To get started with Yampa, you’ll have to get access. To do so, you can follow this guide: Yampa Guide - Getting Access to Machines

-

After you have access, you can continue with the Yampa Guide to get ReEDS set up and running on the remote machines.

-
-
-

Additional Setup

-
-

Additional Software

-

There is other standard software available in the “Ivanti Portal Manager” if you would like to download them.

-
    -

  • On a PC, find the Portal Manager in the Windows Start menu under ‘Ivanti’.

    • -

  • On a Mac, go to Applications and then click ‘Portal Manager’

    • -
-
-
-

Running ReEDS on the HPC

-

In additional to running locally and on Yampa, you can also run ReEDS on the HPC. Instructions for getting started with the HPC can be found here: Advanced Setup - Running ReEDS on HPC

-
-
-

VS Code Extensions

-

The following extensions can be added to VS Code to make it easier to work with the ReEDS code:

-
    -

  • Edit CSV (let’s you edit CSV files outside of Excel)

    • -

  • Rainbow CSV (makes it easier to see columns when viewing CSV files in VS Code)

    • -

  • gms (gams syntax highlighter that gives meaningful formatting when viewing gams code)

    • -

  • Remote - SSH (lets you connect to Kestrel from VS Code)

    • -

  • Git focused extensions:

    -
      -

    • GitHub Pull Requests

      • -

    • GitLens

      • -

    • GitLens - Git supercharged

      • -

    • Git History

      • -

    • Git Graph

      • -
    -
    • -

  • Ruff (python linter that looks at your code and tells you surface level errors or formatting issues)

    • -

  • H5Web (opens h5 files so you can inspect them from within VS Code)

    • -

  • Conflict Squeezer (helpful for managing merge conflicts)

    • -

  • Indent-rainbow (colors the vertical indent lines in code, making it easier to follow)

    • -

  • Python

    • -

  • Diff Folders (used to compare two folders in VS Code)

    • -

  • vscode-copy-github-permalink

    • -

  • gms (for GAMS syntax formatting)

    • -

  • Zotero Citation Picker

    • -
-

In order to improve bracket formatting in GAMS, you can copy “lolow.gams-0.0.1” from \nrelnas01\ReEDS\Users\pbrown\lolow.gams-0.0.1 into your vscode extensions folder. Simply unzip this folder into C:\Users\[username].vscode\extensions.

-
-
-

Set Up SSH Key

-

In order to make commits to ReEDS, you will have to set up an SSH key. To do so, follow the SSH Key Setup guide.

-
-
-
-
-

Additional Resources & Learning

- -
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/pull_request_best_practices.html b/docs/build/html/internal/pull_request_best_practices.html deleted file mode 100644 index 7698873e..00000000 --- a/docs/build/html/internal/pull_request_best_practices.html +++ /dev/null @@ -1,253 +0,0 @@ - - - - - - - Pull Request Best Practices — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Pull Request Best Practices

-
-

Best Practices for Creating PRs

-

To ensure a smooth process and maintain quality of the ReEDS model, the following are best practices that should be followed when creating a pull request:

-
    -

  • Prior to creating a pull request, perform the appropriate level of testing on your branch

    -
      -

    • The Full U.S. test (in cases.csv) will be used in most cases

      • -

    • For more information on testing, see the Testing Guidlines section

      • -
    -
    • -

  • Ensure the title of your pull request is both descriptive and concise

    -
      -

    • This is crucial, as the title of your pull request will be used in the summary of changes for each new version of ReEDS

      • -
    -
    • -

  • Fill out the pull request template in detail

    -
      -

    • The description should be clear enough for someone not directly involved in your work to grasp the changes being proposed

      • -

    • Assign and contact reviewers

      -
        -

      • Best practice is to have 2 reviewers from the ReEDS team

        • -
      -
      • -
    -
    • -

  • Keep your pull request in draft mode until it is ready to be merged into the main branch, indicating to reviewers that it is still a work in progresss

    • -

  • Provide a charge code to your reviewers for their time spent reviewing

    • -

  • Create smaller pull requests more frequently when possible

    -
      -

    • This helps avoid merge conflicts and simplifies the review process, making it more manageable for reviewers

      • -
    -
    • -

  • After creating the pull request, monitor the status of the automated tests

    -
      -

    • This runs the R2X test automatically

      • -
    -
    • -

  • Prior to merging your pull request, make sure to update the relevant documentation to reflect your changes. There are two places that should be updated (more information on this can be found in the documentation guidelines):

    -
      -

    1. Sources_documentation

      2. -

    2. The ‘docs/’ folder within the repository

      3. -
    -
    • -
-
-
-

Resolving Merge Conflicts

-

Sometimes you might run into merge conflicts when trying to merge your branch into another branch. Merge conflicts happen when there are competing commits that Git needs you to help decide which changes should be kept in the final merge.

-

Merge conflicts must be resolved prior to merging a pull request and there are different ways to handle merge conflicts:

- -
-
-

Tips and Best Practices for PR Reviews

-

The following are best practices that should be considered when reviewing pull requests:

-
    -

  1. Understand the context of the pull request

    -
      -

    • Prior to reviewing any code changes, read the PR thoroughly

      -
        -

      • Is the title descriptive?

        • -

      • Does the summary accurately state what the PR is trying to accomplish?

        • -

      • Is there sufficient information in the pull request to accurately convey the changes being made? Because the PR is documenting the change, part of your review entails ensuring that the model changes are properly reflected in the PR text.

        • -

      • What is the high-level impact of this PR? Can you summarize the change on the run results in 1-2 sentences?

        • -
      -
      • -

    • Look at any linked issues or pull requests and understand what is being fixed in this pull request and which issues or incompatibilities are not being addressed.

      • -
    -
    2. -

  2. Look at the compare report and any other figures included in the PR

    -
      -

    • Do you understand why these code/file changes resulted in these results?

      • -

    • What is the high-level impact of this PR? Can you summarize the change on the run results in 1-2 sentences?

      • -

    • Are these changes explainable/justifiable to both our internal and external audiences?

      • -
    -
    3. -

  3. Review the code

    -
      -

    • Look at each file that has changed

      -
        -

      • Do code changes or new code added make sense?

        • -

      • Ensure newly added code is documented (even if it’s just a single-line comment)

        • -

      • Flag any instances where you notice that the code does not follow the Coding Conventions

        • -

      • Identify if/how these code changes could cause problems later.

        -
          -

        • What other parts of the model do these changes interact with? Is that interaction broken or no longer an accurate representation with these changes?

          • -

        • What could break if we ran different scenarios with these changes? We typically look at the impact of our changes on “main” or “Standard Scenarios Mid-Case” type runs but also consider the potential impact on decarbonization scenarios, county level runs, smaller region runs, scenarios with hydrogen enabled, etc. We want to foresee any possible impacts this might have. If you have a concern or are curious about how this change might impact a certain type of run, ask the PR author, they might have looked at similar scenarios.

          • -
        -
        • -
      -
      • -
    -
    4. -

  4. Look at any input files that have changed

    -
      -

    • Reviewing the commit history can sometimes be helpful in determining what has changed

      • -

    • Do the input changes make sense? Are they consistent with the PR descriptions?

      • -

    • There are a couple tools that help with comparing two different csv files:

      - -
      • -
    -
    5. -

  5. Check out the branch locally (optional)

    -
      -

    • You should check the branch out locally and run the test scenario(cases_test.csv) to ensure there are no issues

      • -

    • If there are a large amount of changes to one of the scripts or code files (ex. input_processing scripts or GAMS files), it could be helpful to run just that script and walk through it line by line with a debugging tool (ex. pdb) to more deeply understand how the revised script functions and any issues we might face with the way that script is now written.

      • -
    -
    6. -
-

A few notes on reviewing pull requests:

-
    -

  • When reviewing PRs, be sure to provide constructive feedback and highlight positive aspects as well. Reviewing PRs is an opportunity to learn from one another and support each other’s development as developers!

    • -

  • Ask clarifying questions if something is unclear

    -
      -

    • Reviewing PRs can be daunting if you are new to the team or to the code development process. Remember that this is an opportunity for you to learn more about the model as much as it is about getting the code changes integrated into the model. Even experienced developers make errors, hence the importance of getting a second set of eyes on the code changes. Your input and insights are valuable.

      • -

    • If you don’t understand what is going on with a code change, chances are high that others won’t understand either, so ask for clarification, including asking for more comments or explanation in the PR text.

      • -

    • If there is a section of the PR that you don’t feel comfortable reviewing, you should request a review from another team member

      • -
    -
    • -

  • Request changes as necessary and explain your reasoning

    • -

  • Remember that the PR submitter is ultimately responsible for the changes in the PR, not you, so give the PR review a good effort, but don’t agonize over every detail.

    -
      -

    • If reviewing a PR becomes too large of a chore, feel free to reach out to others on the team to be able to tackle the PR review jointly

      • -
    -
    • -

  • If necessary, make sure the ReEDS documentation was updated to reflect the code changes

    -
      -

    • Instructions for how to update the documentation can be found here

      • -
    -
    • -
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/reeds_training_homework.html b/docs/build/html/internal/reeds_training_homework.html deleted file mode 100644 index a08d59db..00000000 --- a/docs/build/html/internal/reeds_training_homework.html +++ /dev/null @@ -1,223 +0,0 @@ - - - - - - - Task 1: Perform a ReEDS run with the default settings in ERCOT at the BA and county resolutions — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
-
    -
    • -
  • Task 1: Perform a ReEDS run with the default settings in ERCOT at the BA and county resolutions
    • -
  • - View page source -
    • -
-
-
-
-
- -
-

Task 1: Perform a ReEDS run with the default settings in ERCOT at the BA and county resolutions

-
-

Run the model

-
    -

  1. Create your own branch off main and name it XX_homework where XX are your initials

    2. -

  2. Navigate to the folder where the repo has been cloned on your local machine

    3. -

  3. Open the cases_spatialflex.csv file

    4. -

  4. Change the ‘ignore’ row value to be 1 for all columns except ERCOT_county which you can either set to 0 or leave blank

    5. -

  5. Add a new column with ‘ERCOT_BA’ in row 1.

    -
      -

    • Copy the contents of rows 2-6 from the ERCOT_county column

      • -

    • Replace ‘county’ with ‘ba’ in row 5 (GWs_RegionResolution)

      • -

    • Save cases_spatialflex.csv in the ReEDS-2.0 folder (you can overwrite the existing file)

      • -
    -
    6. -

  6. Open VS Code

    -
      -

    • Open the folder where your repo is located (File -> Open Folder -> navigate to ReEDS-2.0 folder)

      • -

    • Open a new terminal and activate the reeds2 environment

      • -
    -
    7. -

  7. Start a new run

    -
      -

    • python runbatch.py

      • -

    • when prompted for case file name, enter ‘spatialflex’

      • -

    • when prompted for how many simultaneous runs you would like to execute, enter 2

      • -

    • The ‘ERCOT_county’ and ‘ERCOT_BA’ runs should start

      • -
    -
    8. -
-
-
-

Review the results

-
    -

  1. Navigate to ‘ReEDS-2.0/runs/{your run name}/outputs/reeds-report’ and open ‘report.html’

    2. -

  2. Learn to create your own plots of the results using bokehpivot

    - -
    3. -
-
-
-

Create an informal slide deck

-

Create an informal slide deck with the following results:

-
    -

  • Stacked bar chart of total installed capacity in 2030

    -
      -

    • Include a stacked bar chart of the differences

      • -
    -
    • -

  • Stacked bar chart of total installed firm capacity in 2030

    • -

  • Stacked bar chat of generation in all modeled years

    • -

  • Stacked bar chart of total system costs discounted

    • -

  • Plots of the locational capacity build out by technology (maps of where capacity is located)

    • -

  • Plots of the curtailment rates

    • -
-
-
-
-

Task 2: Perform a ReEDS run with enforced decarbonization at the BA resolution in the Western Interconnection.

-
-

Run the model

-
    -

  1. Ensure you are on your XX_homework branch, then navigate to the folder where the repo has been cloned on your local machine

    2. -

  2. Open the cases_spatialflex.csv file

    3. -

  3. Add a new column with ‘Western_BA_Decarb’ in row 1

    -
      -

    • Copy the contents of rows 2-6 from the ERCOT_county column

      • -

    • Replace ‘county’ with ‘ba’ in row 5 (GSw_RegionResolution)

      • -

    • Replace ‘ercot’ with ‘western’ in row 4 (GSw_Region)

      • -

    • Add 2 additional rows, populating column A with ‘GSw_AnnualCapScen’ and ‘GSw_AnnualCap’ in rows 7 and 8 respectively

      • -

    • Under the ‘Western_BA_Decarb’ column, populate these rows with ‘start2023_100pct2035’ and ‘1’ respectively (leave these rows blank in all other columns)

      • -
    -
    4. -

  4. Change the ‘ignore’ row value to be 1 for all columns except ‘Western_BA_Decarb’ which you can either set to 0 or leave blank

    5. -

  5. Save cases_spatialflex.csv in ReEDS-2.0 folder

    6. -

  6. Open VS Code

    -
      -

    • Open the folder where your repo is located (File -> Open Folder -> navigate to ReEDS-2.0 folder)

      • -

    • Open a new terminal and activate the reeds2 environment

      • -
    -
    7. -

  7. Start a new run

    -
      -

    • python runbatch.py

      • -

    • when prompted for case file name, enter ‘spatialflex’

      • -

    • The ‘Western_BA_Decarb’ run should start

      • -
    -
    8. -
-
-
-

Create an informal slide deck

-

Create an informal slide deck with the following results:

-
    -

  • Stacked bar chart of total installed capacity in 2030

    -
      -

    • Include a stacked bar chart of the differences

      • -
    -
    • -

  • Stacked bar chart of total installed firm capacity in 2030

    • -

  • Stacked bar chat of generation in all modeled years

    • -

  • Stacked bar chart of total system costs discounted

    • -

  • Plots of the locational capacity build out by technology (maps of where capacity is located)

    • -

  • Plots of the curtailment rates

    • -
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/ssh_setup.html b/docs/build/html/internal/ssh_setup.html deleted file mode 100644 index 0f0fbd3f..00000000 --- a/docs/build/html/internal/ssh_setup.html +++ /dev/null @@ -1,285 +0,0 @@ - - - - - - - SSH Key Setup — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

SSH Key Setup

-

If you’re looking to set up a new SSH key on Yampa, jump to Setting up a new SSH key on Yampa.

-
-

Generating a new SSH key

-
    -

  1. Open Git Bash (Windows) or Terminal (Mac & Linux)

    2. -

  2. Paste the following text to create a new SSH key: ssh-keygen -t ed25519 -C "your_email@nrel.gov"

    -
      -

    • It will ask for a file to save the key, press Enter to accept the default location

      • -

    • When asked for a passphrase, leave it empty and hit Enter. If you decide to use a passphrase, you will have to enter it any time you need to push or pull from GitHub.

      • -
    -
    3. -
-
-
-

Add SSH key to the ssh-agent

-

Since the ssh-agent manages your keys, you now have to add the newly generated SSH key to the ssh-agent.

-
-

Windows

-
    -

  1. Open a new admin elevated PowerShell window

    -
      -

    • You can do this by clicking ‘Start’, typing ‘PowerShell’, and then right-clicking on it and selecting ‘Run as Administrator’.

      • -

    • If you don’t already have temporary admin access for your machine, you will need to contact IT and request this.

      • -
    -
    2. -

  2. Ensure the ssh-agent is running by running the following command:

    -
    Get-Service -Name ssh-agent | Set-Service -StartupType Manual
-Start-Service ssh-agent
-
    -
    -
    3. -

  3. Open a new PowerShell window (open it normally, it doesn’t need to have admin rights) and add your SSH key to the ssh-agent with the command:

    -
    ssh-add c:/Users/[your account name]/.ssh/id_ed25519
-
    -
    -
    4. -

  4. Copy the SSH key with the command: clip < ~/.ssh/id_ed25519.pub

    -
      -

    • Note: this might fail on newer versions of Windows, if it does, use this command: cat ~/.ssh/id_ed25519.pub | clip

      • -
    -
    5. -
-
-
-

Mac

-
    -

  1. Start the ssh-agent with the following command: eval "$(ssh-agent -s)"

    2. -

  2. Modify your ~/.ssh/config file to automatically load keys into the ssh-agent by following these steps: -a. Check to see if the file exists: open ~/.ssh/config -b. If it does not exist, you can create it with this command: touch ~/.ssh/config -c. Open the file and modify the contents to contain the following lines (you can open it with the command open ~/.ssh/config):

    -
    Host github.com
-    AddKeysToAgent yes
-    IdentityFile ~/.ssh/id_ed25519
-
    -
    -
    3. -

  3. Add your SSH key to the ssh-agent with the following command:

    -
    ssh-add --apple-use-keychain ~/.ssh/id_ed25519
-
    -
    -
    4. -

  4. Copy the SSH key with the command: pbcopy < ~/.ssh/id_ed25519.pub

    5. -
-
-
-
-

Add SSH key to your GitHub account

-

Now that you have created a new SSH key and added it to the ssh-agent, you need to add the SSH key to your GitHub account.

-
    -

  1. Log on to github.nrel.gov and go to your account settings

    2. -
-
-../_images/github_settings.png -
-

GitHub account settings

-
-
-
    -

  1. Click on “SSH and GPG keys” on the left sidebar, then click on New SSH key

    2. -
-
-../_images/github_ssh_gpg_keys.png -
-

GitHub SSH and GPG keys

-
-
-
-../_images/github_add_ssh_key.png -
-

GitHub Add New SSH Key

-
-
-
    -

  1. Create a title and paste the SSH key into the “Key” field

    2. -
-
-
-

Setting up a new SSH key on Yampa

-
    -

  1. Open a new terminal window

    2. -

  2. Create a .ssh directory in your personal projects directory with the command: mkdir /data/shared/projects/[username]/.ssh

    3. -

  3. Run the following command to create a new SSH key: ssh-keygen -t ed25519 -C "[youremail@nrel.gov]"

    4. -

  4. When asked to enter the file in which to save the key, you can hit enter to accept the default.

    -
      -

    • The key will be saved in /home/[username]/.ssh/id_ed25519

      • -
    -
    5. -

  5. When asked to enter a passphrase, hit enter to skip this step. If you decide to create a passphrase, you will need to enter this passphrase upon every push/pull.

    6. -

  6. Run the command: ssh-add id_ed25519

    7. -

  7. Open the key in gedit with the command: gedit /home/[username]/.ssh/id_ed25519.pub. Then copy the text contents of this file to the clipboard with a Ctrl+C keyboard command.

    8. -

  8. Log on to github.nrel.gov and go to your account settings

    9. -
-
-../_images/github_settings.png -
-

GitHub account settings

-
-
-
    -

  1. Click on “SSH and GPG keys” on the left sidebar, then click on New SSH key

    2. -
-
-../_images/github_ssh_gpg_keys.png -
-

GitHub SSH and GPG keys

-
-
-
-../_images/github_add_ssh_key.png -
-

GitHub Add New SSH Key

-
-
-
    -

  1. Create a title for your key (e.g. yampa) and paste the text from the clipboard into the text box below, then click “Add SSH Key” to save.

    2. -
-
    -

  • To check that your key was added, go back to the terminal on Yampa and run the command ssh -T git@github.nrel.gov. If successful, you should get the message “Hi [username]! You’ve successfully authenticated, but GitHub does not provide shell access.”

    • -

  • Note: you might get a message saying “The authenticity of host ‘github.nrel.gov ()’ can’t be established… Are you sure you want to continue connecting (yes/no/[fingerprint])?” Entering ‘yes’ will add github.nrel.gov to your list of know hosts, found in this file: ‘/home/[username]/.ssh/known_hosts

    • -
-
    -

  1. You can now clone the ReEDS repository where you can then install the environments from the yml file.

    2. -
-
-
-

Troubleshooting

-

If you run into issues while setting up a new ssh key, see the GitHub docs for Troubleshooting SSH

-
-

What if I still can’t push/pull from the command line after setting up the SSH key?

-

After creating an SSH key and adding it to your GitHub account, you should be able to push/pull from the terminal without entering your github credentials.

-

If you’re still being asked for your credentials, it’s likely due to the fact that you haven’t configured the correct URL for the repo locally. To fix this:

-
    -

  1. Check what your remote URL is, run the command git remote -v

    -
      -

    • This should list out your existing remote repositories

      • -

    • If you’re seeing them as “https://….” you will need to switch the remote URL from HTTPS to SSH

      • -
    -
    2. -

  2. To switch the remote URL, run the command git remote set-url origin git@github.nrel.gov:ReEDS/ReEDS-2.0.git

    3. -

  3. Verify the remote URL has been changed, run the command git remote -v again

    -
      -

    • You should not see the origin as “git@github….”

      • -
    -
    4. -
-

More information on this can be found in the GitHub Docs

-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/version_control_and_testing.html b/docs/build/html/internal/version_control_and_testing.html deleted file mode 100644 index b6b39715..00000000 --- a/docs/build/html/internal/version_control_and_testing.html +++ /dev/null @@ -1,215 +0,0 @@ - - - - - - - Version Control and Testing — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Version Control and Testing

-
-

ReEDS Versioning & Releases

-

This section outlines the current ReEDS approach to versioning. You can find current and past ReEDS versions here: ReEDS-2.0 Releases

-
-

Versioning overview

-

GitHub Releases are used to create ReEDS versions on a monthly cadence after a suite of tests are performed. More on ReEDS testing can be found here. More information on GitHub Releases can be found in the GitHub Doc.

-

Releases are based on Git tags, and the proposed versioning scheme is EPOCH.RELEASE.PATCH. The components are:

-
    -

  • EPOCH: The current year, this will be incremented in January of each year (e.g., 2023)

    • -

  • RELEASE: Restarts from 0 when EPOCH is increased, then increased by 1 each month when the newest version is created

    • -

  • PATCH: Typically will just be 0, but could increment if an important update or bug fix needs to be merged in prior to the next monthly release.

    • -
-
-
-

Tagging versions

-

Tagging with GitHub releases is not done manually with each pull request. After a new release has been created, a tag will be generated.

-

How to use tags:

-
    -

  • You can check them out like any other commit: git checkout tags/2023.1.0

    -
      -

    • You may need to fetch tags to your machine first: git fetch --tags

      • -

    • If you plan to develop from an older tag (i.e., you’re not checking out main on the most recent tag and you plan to commit new changes), you’ll also want to specify a branch or create a new one: git checkout -b <new branch name> <tag name>

      • -
    -
    • -

  • ReEDS2X tool versions should reference the last ReEDS version they’re known to work for in their tag text or README

    -
      -

    • Each ReEDS run produces a meta.csv file with information on the branch, commit, and version of that run which can be used to determine the vintage of any given ReEDS run.

      • -
    -
    • -

  • If you’re using ReEDS2X for a side project and would like to tag versions for them to refer to, the suggested format is: EPOCH.RELEASE.PATCH.PROJECTNAME, where EPOCH.RELEASE.PATCH refers to the last version of main that has been merged into your project branch.

    -
      -

    • The same format can be used to tag specific versions of the model that are used for published analyses that are not merged into main, e.g. 2023.4.0.hybrids.

      • -

    • In general, please add custom components to the tail of the version number instead of the beginning to keep them easy to sort.

      • -
    -
    • -
-
-
-
-

Testing Guidelines

-

This section outlines the recommended testing that should be performed on ReEDS prior to creating a pull request or a new version.

-
-

Post-process Test

-

This testing should be performed when a change is made that does not change model code or data that might impact model outputs. Ex: changing the color styles in bokeh output plot, or adjusting a post-processing script such as runstatus.py

-
    -

  1. Ensure the post-processing capabilities operate correctly on outputs from the most recent version of main

    -
      -

    • A demonstration of this should be included in the pull request

      • -
    -
    2. -

  2. Verify that R2X pytest passes

    3. -
-
-
-

Light Test (Pacific Region)

-

This testing should be performed for changes to model code that are not expected to have any meaningful impact on the model solution. Examples include:

-
    -

  • Rounding an input parameter

    • -

  • Changing the name of a column or model parameter

    • -

  • Updating code within an if statement where the if statement does not apply under default settings (e.g., “if int(sw.GSw_calc_powfrac):” where the default value of sw.GSw_calc_powfrac is 0)

    • -

  • Adding a missing entry to run files.csv

    • -
-
    -

  1. Do a comparison run of the default test case (cases_test.csv) against a test run from main and produce a comparison report.

    -
      -

    • The report should be examined for any unexpected outputs and included in the pull request for review

      • -
    -
    2. -

  2. Verify that R2X pytest passes

    3. -
-
-
-

Regular Test (Full U.S.)

-

This testing should be performed for all other cases not covered by the post-process or light test

-
    -

  1. Do a comparison run of the default case (cases.csv) against a run from main and produce a comparison report.

    -
      -

    • You should be able to reasonably explain changes in capacity, generation, transmission capacity, bulk system electricity price, system cost, and runtime

      • -

    • The report should be included in the pull request

      • -
    -
    2. -

  2. Verify that R2X pytest passes

    3. -
-
-
-

New Version Test

-

This testing is required for a new tagged and released version

-

The full set of scenarios in cases_test.csv is run on HPC and Yampa (tests are also run locally on Mac or Windows, with the exception of the USA_decarb scenario). All test scenarios, with the exception of the following, must succeed in order for a new version to be created:

-
    -

  • Pacific test case with water constraints

    • -

  • Pacific test case with PVB turned on

    • -

  • Pacific test case with detailed CO2 transport & storage

    • -

  • Pacific test case with representatives weks

    • -

  • Pacific test case with full chronological year

    • -
-

For any error in the output processing scripts, a new GitHub issue should be created. Additionally, the issue should be noted in the release notes for the new version.

-

Lastly, comparison reports are created for the USA and USA_decarb scenarios to compare the current version with the previous released version. Those comparison reports should be attached to the release notes for reference.

-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/internal/yampa_guide.html b/docs/build/html/internal/yampa_guide.html deleted file mode 100644 index 347c934a..00000000 --- a/docs/build/html/internal/yampa_guide.html +++ /dev/null @@ -1,342 +0,0 @@ - - - - - - - List of Machines — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

List of Machines

- - - - - - - - - - - - - - - - - - - - - - - -

Machine Name

RAM

constellation01.hpc.nrel.gov

120 GB

cepheus.hpc.nrel.gov

250 GB

corvus.hpc.nrel.gov

250 GB

delphinus.hpc.nrel.gov

500 GB

dorado.hpc.nrel.gov

500 GB

-
-
-

Getting Access to Machines

-

Access to the servers is controlled through the “reedsos” allocation. To request an HPC account, complete this request form. When asked if you intend to request a new project/allocation, select “no” and request to join “reedsos”.

-
-../_images/hpc_request_form.png -
-

HPC account form, request to join “reedsos” allocation

-
-
-

Note: the ‘reedsos’ allocation isn’t an active allocation for HPC, which can cause some confusion with the HPC team, but it is still used to manage access to yampa.

-

If you have access issues after requesting an account, you can contact HPC help at HPC-Help@nrel.gov.

-
-
-

Getting Started

-
-

Get started with Microsoft Remote Desktop

-

Connections to the machines can be made using Microsoft Remote Desktop. To download:

-
    -

  • On Windows:

    • -

  • On Mac: You can download Microsoft Remote Desktop from the app store. You will need to create an apple id using your nrel email to start using the app store.

    • -
-

From the Remote Desktop client, you will need to click on the ‘+’ then ‘Add PC’. In the ‘PC name’ field, put the machine name that you would like to connect to, then click ‘Add’.

-
-../_images/yampa_add_machine.png -
-

Example of how to add a new machine in Microsoft Remote Desktop

-
-
-

Username and Password: Same as HPC credentials.

-

Note: Check to make sure that nrel_nt is NOT inlcluded in your username, this sometimes gets added automatically to some users at first login by Microsoft Remote Desktop.

-
-
-

Drive Configuration

-

Unlike the old servers, storage is shared across the machines: as a result, you should only need to complete setup once, and it should be automatically reflected on other machines. There is a limited amount of space in your home directory with enforced storage limits. Only files essential to configuring your account should be kept here (e.g. path configurations).

-

The rest of the data is stored in the following folders:

-
    -

  • /data/shared/apps - contains programs

    • -

  • /data/shared/projects - contains user project folders: you’ll need to create one similar to the D: drives on the constellation machines

    • -
-

Create a projects folder by running the following command: mkdir /data/shared/projects/[your user name]

-
-
-

Initial Setup

-

After getting connected to the machine and creating your projects directory, you’ll need to do two additional steps to complete setup.

-
-

Add installed programs to PATH

-

To add installed programs to the $PATH environment variable, use the following command in the terminal: gedit ~/.bashrc

-

This will open up a text editor with your .bashrc file which contains the path locations. Here you will need to add gams, anaconda, and smartgit to $PATH.

-

Add the following line separated by colons to the path:

-
/data/shared/apps/gams/gams45.2_linux_x64_64_sfx:/data/shared/apps/gams/gams45.2_linux_x64_64_sfx/studio:/data/shared/apps/anaconda3/bin:/data/shared/apps/GitAhead 
-
-
-

Important: Make sure you don’t delete the original PATH contents or the “:$PATH” as part of PATH

-

Once completed, your bashrc file should look like the following screenshot. Save the file, then log off and log back on to ensure $PATH settings are updated.

-
-../_images/yampa_bashrc_file.png -
-

Example of bashrc file with updated $PATH

-
-
-
-
-

Set up conda folders/environments

-

You’ll want to create a folder within your projects folder to store conda environments and packages. Run the following commands:

-
    -

  • mkdir /data/shared/projects/[username]/.conda

    • -

  • mkdir /data/shared/projects/[usename]/.conda/pkgs

    • -

  • mkdir /data/shared/projects/[username]/.conda/envs

    • -
-

Now, direct conda to look in these folders for packages and environments by running the following commands:

-
    -

  • conda config --add pkgs_dirs /data/shared/projects/[username]/.conda/pkgs

    • -

  • conda config --add envs_dirs /data/shared/projects/[username]/.conda/envs

    • -
-

Next, create and activate the conda environment. From the terminal, run the following commands from within the ReEDS repo:

-
    -

  • conda env create -f environment.yml - this step may take a while

    • -

  • conda activate reeds - if this steps causes issues, you can try running source activate reeds2 instead

    • -
-
-
-

Create SSH key and add it to your GitHub account

-

Follow the ssh setup guide to create a new SSH key and add it to your GitHub account.

-
-
-
-
-

Applications

- -
-

GAMS Studio

-

GAMS Studio is the IDE packaged with GAMS. It can be used for GAMS development and supports code markup and executing GAMS code from the developer environment. The other major application of GAMS Studio is to open .gdx files.

-

The GAMS studio executable is stored in the folder “/data/shared/apps/gams/gams45.2_linux_x64_64_sfx/studio/studio.AppImage”.

-

If the folder containing the executable was added to the path it can be run by using the following command from the terminal: Studio.AppImage

-

Note: If if hasn’t been added to your path, you can run the following command instead: /data/shared/apps/gams/gams45.2_linux_x64_64_sfx/studio/studio.AppImage

-

Navigate to postprocessing/bokehpivot and make sure your reeds environment has been activated.

-

Run this command (which is the contents of launch.sh):

-

`bokeh serve . –sh –port 0``

-

Note that you can copy the file path using the “Copy Location” option in the drop-down menu from the filepath in Files.

-
-
-

GitAhead

-

Github desktop has compatibility issues on Linux with Github enterprise. For a GUI interface for git use smartgit.

-

GitAhead can be launched by running the following command in the command line if you included in in your path environmental variable.

-

GitAhead

-

If it hasn’t been added to your path run the following

-

/data/shared/apps/GitAhead/GitAhead

-
-
-

Transferring Data to nrelnas01

-

Since at this time we can’t use the Linux servers to talk to Yampa we’re going to use an the HPC file system as a reasonably fast intermediary. The following instructions are for how to transfer data from Yampa to nrelnas01 but could easily be reversed by switching the target and destination.

-
    -

  1. Install or get access to winscp if on Windows. This will make interacting with the HPC file system easier. Transfers will be limited by your connection speed to the nrel network. If you aren’t on campus I would recommend getting access to the GPAC Windows (Azure) VM. It’s primarily intended for PLEXOS use but you won’t have a problem getting access, and this use will not be burdensome. You can download winscp at the link below, if you don’t have admin rights you can download the portable executable which doesn’t require installation. -https://winscp.net/eng/downloads.php

    -
      -

    • Note: If you are planning on connect to the Azure VM, Windows users may need to install a different client for the machine to appear in Workspaces.

      • -

    • To install, go to the link in the paragraph above, use the “Windows 64-bit” link to the installer. Download and run it.

      • -

    • After installation, open Remote Desktop, and click the Subscribe button. The ASCR machine should show up if you’ve been added to the group “Constellation Azure Servers” group. - If you’re not already a member, you will need to get added, then Unsubscribe via the dropdown in the General Workspaces tab and subscribe again

      • -
    -
    2. -

  2. You can connect to winscp using your hpc credentials and a valid host name (kestrel.hpc.nrel.gov). Once connected you can see the file system. You will want to navigate to the root and then to the following directory: /scratch/[username]

    -
      -

    • All HPC users are allocated a reasonable amount of temporary space in this folder and it’s a useful place for performing a transfer.

      • -
    -
    3. -

  3. Connect to Yampa and run the following command with your required changes:

    -
    rsync -avz -e ssh /data/shared/projects/[SOURCE FOLDER PATH]/ jho@kestrel.nrel.gov:/scratch/[DESTINATION FOLDER PATH]/ 
-
    -
    -
      -

    • Here’s an example:

      • -
    -
    rsync -avz -e ssh /data/shared/projects/jho/Target_Folder/ jho@kestrel.nrel.gov:/scratch/jho/Destination_Folder/ 
-
    -
    -
    4. -

  4. Once executed, you’ll get a login for the HPC. Once you’ve entered your credentials the transfer will start.

    5. -

  5. After the transfer is completed, the new files will be viewable on the HPC file system. They can then be transferred to a local files system including //nrelnas01/ReEDS/

    6. -
-
-
-

Transferring Data From Yampa to Your Machine

-

If you want to directly transfer files between Yampa and your local machine, you can use the tool FileZilla. You can download the FileZilla Client at https://filezilla-project.org/.

-

Once downloaded, you can connect using the following settings:

-
    -

  • Host: cepheus.hpc.nrel.gov (you can connect to any of the five VM hosts and filezilla will automatically add the connection protocol)

    • -

  • Username: Your HPC username

    • -

  • Password: Your HPC password

    • -

  • Port: You can leave this blank (if you have issues connecting you can use ‘22’ as the port)

    • -
-

You can then transfer data between machines - local machine is on the left and remote machine is on the right. The common project folders are retained in ‘/data/shared/projects/…’

-
-
-

Spyder

-

Spyder is an open-source integrated development environment (IDE) that is very useful for interactively running Python scripts and viewing variables, pandas dataframes, plots, etc. in the middle of script execution. Python can be launched from the Anaconda-Navigator Launcher, which can be opened by running the following command in a Terminal:

-

python /data/shared/apps/anaconda3/bin/anaconda-navigator

-

This will open the Anaconda-Navigator Launcher. From there, you can use the dropdown in the upper center of the screen to choose a conda environment to work out of or install/launch Spyder.

-
-
-
-

General Tips

-
-

Creating Shortcuts

-

When opening the terminal, Linux defaults to your home directory as an initial starting location. You can create a shortcut to another folder for faster access using the following command:

-

ln -s /data/shared/projects/[username] ~/projects

-

The general implementation of this is:

-

ln -s filepath linkpath

-

Once created you can use the shortcut as if it were a directory.

-
-
-

Sorting Folders Before Files

-

If you want the file viewer to adopt sorting behavior where folders are sorted alphabetically before files. You can make that change by opening the preferences menu in the folder viewer.

-
-../_images/yampa_file_preferences.png -
-

File preferences on Yampa

-
-
-

Then select the option for Sort Folders before Files.

-
-
-

Issues Activating Conda Environment

-

If you’re having issues activating the reeds2 conda environment, you can try one of these options:

-
    -

  1. Use source activate reeds2 instead of conda activate reeds2

    2. -

  2. Run the following command prior to running conda activate reeds2 (note: if you don’t want to run this command every time, do step 3):

    3. -
-
source /data/shared/apps/anaconda3/etc/profile.d/conda.sh
-
-
-
    -

  1. Add the following line to the bottom of your bashrc file with the following command (you can open your bashrc file with the command gedit ~/.bashrc):

    2. -
-
$ source /data/shared/apps/anaconda3/etc/profile.d/conda.sh
-
-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/model_documentation.html b/docs/build/html/model_documentation.html deleted file mode 100644 index 337b3cde..00000000 --- a/docs/build/html/model_documentation.html +++ /dev/null @@ -1,7816 +0,0 @@ - - - - - - - Model Documentation — ReEDS documentation - - - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Model Documentation

-
-

Overview

-

ReEDS is a mathematical programming model of the electric power sector. Given a set of input assumptions, ReEDS models the evolution and operation of generation, storage, transmission, and production technologies.

-

The model consists of two separate but interrelated modules:

-
    -

  • Supply module - this module solves a linear program for the cost-minimizing levels of power sector investment

    • -

  • Operation and storage (VRE) module - this module calculates key parameters for assessing the -value of VRE generators and storage

    • -
-

The latest, detailed documentation of the ReEDS model can be found in the latest version of the published documentation: Regional Energy Deployment System (ReEDS) Model Documentation: Version 2020.

-

Detailed documentation of ReEDS 2.0 input files are available here

-
-
-

Acknowledgments

-

We gratefully acknowledge the many people whose efforts contributed to -this report. The ReEDS modeling and analysis team at the National -Renewable Energy Laboratory (NREL) was active in developing and testing -the ReEDS model version 2023. We also acknowledge the vast number of -current and past NREL employees on and beyond the ReEDS team who have -participated in data and model development, testing, and analysis. We -are especially grateful to Walter Short who first envisioned and -developed the Wind Deployment System (WinDS) and ReEDS models. We thank -Walter Short, Owen Zinaman, Laura Vimmerstedt, Jeffrey Logan, Cara -Marcy, Gokul Iyer, and Mike Meshek for their comments and improvements -on successive versions of this report. Finally, we are grateful to all -those who helped sponsor ReEDS model development and analysis, -particularly supporters from the U.S. Department of Energy (DOE) but -also others who have funded our work over the years. This report was -funded by the DOE Office of Energy Efficiency and Renewable Energy under -contract number DE-AC36-08GO28308. Any errors or omissions are the sole -responsibility of the authors.

-
-
-

List of Abbreviations and Acronyms

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Abbreviation/Acronym

AC

alternating current

AEO

Annual Energy Outlook

ATB

Annual Technology Baseline

BA

balancing area

BECCS

Bioenergy with Carbon Capture and Storage

CAES

compressed-air energy storage

CAIR

Clean Air Interstate Rule

CC

combined cycle

CCS

carbon capture and sequestration

CES

clean energy standard

CF

capacity factor

CFL

compact fluorescent lamp

CO2

carbon dioxide

CO2e

carbon dioxide equivalent

CMIP

Coupled Model Intercomparison Project

CPP

Clean Power Plan

CPUC

California Public Utilities Commission

CSAPR

Cross-State Air Pollution Rule

CSP

concentrating solar power

CT

combustion turbine

CV

capacity value

DAC

Direct Air Capture

DC

direct current

DG

distributed generation

DNI

direct normal insolation

DOE

U.S. Department of Energy

DSIRE

Database of State Incentives for Renewables & Efficiency

DUPV

distribution-side utility-scale photovoltaic

EAC

early action credit

EGR

enhanced gas recovery

EGS

enhanced geothermal system

EIA

U.S. Energy Information Administration

ELCC

effective load carrying capability

EMM

Electricity Market Module

EOR

enhanced oil recovery

EPA

U.S. Environmental Protection Agency

ERC

emission rate credit

ERCOT

Electric Reliability Council of Texas

FERC

Federal Energy Regulatory Commission

FOM

fixed operation and maintenance

GCM

general circulation model

GHG

greenhouse gas

GIS

geographic information systems

GW

gigawatt

H2 or H2

Hydrogen

HMI

U.S. Bureau of Reclamation Hydropower Modernization Initiative

HSIP

Homeland Security Infrastructure Project

HVDC

high-voltage direct current

IGCC

integrated gasification combined cycle

IOU

investor-owned utility

IPM

U.S. Environmental Protection Agency Integrated Planning Model

IPP

independent power producer

ISO

independent system operator

IRS

Internal Revenue Service

ITC

investment tax credit

JEDI

Jobs and Economic Development Impact model

km2

square kilometer

kV

kilovolt

kW

kilowatt

kWh

kilowatt hour

LCOE

levelized cost of energy

LDC

load-duration curve

LED

light-emitting diode

LOLP

loss of load probability

MACRS

Modified Accelerated Cost Recovery System

MATS

Mercury and Air Toxic Standards

MMBtu

million British thermal units

MPI

materials price index

MW

megawatt

MWh

megawatt hour

NaS

sodium-sulfur

NEB

Canadian National Energy Board

NEMS

National Energy Modeling System

NERC

North American Electric Reliability Corporation

NG

natural gas

NHAAP

National Hydropower Asset Assessment Program

NLDC

net load-duration curve

NOx

nitrogen oxide

NPD

non-powered dam

NRC

Nuclear Regulatory Commission

NREL

National Renewable Energy Lab

NSD

new stream-reach development

NSRDB

National Solar Radiation Database

O&M

operation and maintenance

OGS

oil-gas steam

PCM

production-cost model

POI

point of interconnection

PRM

planning reserve margin

PRODESEN

Mexican Programa de Desarrollo del Sistema Eléctrico Nacional

PSH

pumped storage hydropower

PTC

production tax credit

PV

photovoltaic

PVB

photovoltaic and battery

RA

resource adequacy

RCP

representative concentration pathway

REC

renewable energy certificate

ReEDS

Regional Energy Deployment System

reV

Renewable Energy Potential tool

RGGI

Regional Greenhouse Gas Initiative

RLDC

residual load-duration curve

RPS

renewable portfolio standard

RROE

rate of return on equity

RTO

regional transmission organization

SAM

System Advisor Model

SENER

Secretaría de Energía for Mexico

SM

solar multiple

SO2

sulfur dioxide

T&D

transmission and distribution

TEPPC

Transmission Expansion Planning Policy Committee

tCO2

metric ton of carbon dioxide

TW

terawatt

TWh

terawatt hour

UPV

utility-scale photovoltaic

VOM

Variable Operation and Maintenance

VRE

variable renewable energy

WACC

weighted average cost of capital

WECC

Western Electricity Coordination Council

WIND

Wind Integration National Dataset

WinDS

Wind Deployment System

-
-
-

Introduction

-

This document describes the structure and key data elements of the -Regional Energy Deployment System model architecture 2.0 (ReEDS 2.0, or -simply ReEDS) version 2023, which is maintained and operated by the -National Renewable Energy Laboratory (NREL).[1] ReEDS 2.0 builds upon -the original ReEDS model architecture (hereafter, Heritage ReEDS), -adding more flexibility and additional capabilities while maintaining -the features that have contributed to the model’s attractiveness as a -decision-support tool. In the past, Heritage ReEDS has been used in -support of both public and private sector clients to analyze the -evolution of the U.S. (and in some cases, North American) power sector -in response to policies and technological change. In this introduction, -we provide a high-level overview of ReEDS 2.0 objectives, capabilities, -and applications. We also briefly describe the history of the Heritage -ReEDS model and discuss major changes introduced by the transition to -ReEDS 2.0. Finally, we provide a short discussion of important caveats -that apply to any ReEDS analysis.

-

The ReEDS model code and input data can be accessed at -https://github.com/NREL/ReEDS-2.0.

-
-

Overview

-

ReEDS is a mathematical programming model of the electric power sector. -Given a set of input assumptions, ReEDS models the evolution and -operation of generation, storage, transmission, and production[2] -technologies. The results can be used to explore the impacts of a -variety of future technological and policy scenarios on, for example, -economic and environmental outcomes for the entire power sector or for -specific stakeholders. ReEDS employs a modular structure to maximize -user flexibility. Currently, the model consists of two separate but -interrelated modules: a supply module, which solves a linear program for -the cost-minimizing levels of power sector investment; and operation and -a storage (VRE) module,[3] which calculates key parameters for -assessing the value of VRE generators and storage.

-

Power markets are represented in the model by separating the continent -into model regions, each of which has sources of supply and demand. -Regions are connected by a representation of the transmission network, -which includes existing transmission capacity and endogenous new -capacity. The model represents all existing generating units, planned -future builds, and endogenous new capacity within each region. The model -is intended to solve on the decadal scale, though the time horizon for a -particular model run (and the intervening model solve years) can be -selected by the user. Within each year, a selected representative -timeslices and stress periods are used to characterize seasonal and -diurnal patterns in supply and demand.

-
-
-

ReEDS History

-

The ReEDS model heritage traces back to National Renewable Energy -Laboratory’s (NREL’s) seminal electric sector capacity expansion model, -called the Wind Deployment System (WinDS) model. The WinDS model was -developed beginning in 2001 to examine long-term market penetration of -wind in the electric power sector [Short et al., 2003]. From 2003 -to 2008, WinDS was used in a variety of wind-related analyses, including -the production of hydrogen from wind power, the impacts of state-level -policies on wind deployment, the role of plug-in hybrid electric -vehicles in wind markets, the impacts of high wind penetration on U.S -wind manufacturing, the potential for offshore wind, the benefits of -storage to wind power, and the feasibility of producing 20% of U.S. -electricity from wind power by 2030 [DOE, 2008]. -In 2006, a variation of -WinDS was developed to analyze concentrating solar power (CSP) potential -and its response to state and federal incentives. In 2009, WinDS was -recast as ReEDS—a generalized tool for examining the long-term -deployment interactions of multiple technologies in the power sector [Blair et al., 2009].

-

Since 2009, ReEDS has been the primary analytical tool in several -studies, including the Hydropower Vision [DOE, 2016], Wind Vision [DOE, 2015], SunShot Vision [DOE, 2012], Geothermal Vision [DOE, 2019], and -Renewable Electricity Futures [NREL, 2012]. NREL currently uses ReEDS to -publish an annual Standard Scenarios report, which provides a U.S. -electric sector outlook under a wide range of possible futures [Cole et al., 2020]. ReEDS has also been used to examine impacts of a range of -existing and proposed energy policies [Gagnon et al., 2017, Lantz et al., 2014, Mai et al., 2015]. Other recent studies have used ReEDS to -examine the role of natural gas, high renewable scenarios, and other -important issues for the U.S. electricity sector [Clemmer et al., 2013, Cole et al., 2018, Cole et al., 2016, Cole et al., 2015, Logan et al., 2013, Mai et al., 2014, Mignone et al., 2012, Richards and Cole, 2017, Sullivan et al., 2015]. The ReEDS website[4] includes an up-to-date list of publications that use ReEDS.

-
-
-

Summary of Major Changes

-

Since the inception of WinDS and ReEDS, NREL has conducted a diverse -suite of analyses. Within each analysis, new capabilities were -developed, thereby improving the sophistication of the model. The -incremental development was often completed by different analysts with -unique intentions and coding preferences. Over time, the model became -increasingly difficult to maintain. Additionally, as the model evolved, -so did the research questions. Therefore, in the fall of 2016, NREL -began to rebuild Heritage ReEDS from the ground up. After three years, -the resulting product was a cleaner, more flexible, and more advanced -tool called ReEDS 2.0. Though ReEDS’ fundamental structure and -functionality have remained constant, ReEDS 2.0 introduces several -changes to the heritage version of the model. The most notable changes -include the following:

-
    -

  • Representative Hours and stress periods

    • -

  • Hourly ReEDS/Flexible Temporal Resolution

    • -

  • Decarbonization Scenarios

    • -

  • Spatial Flexibility?

    • -

  • Policy Representation (IRA)

    • -

  • Newer Technology representation

    • -

  • Transmission (intrazonal, initial capacity, and HVDC macrogrids)

    • -
-

While there are major architectural changes with ReEDS 2.0, many of the -incumbent data and methods supporting ReEDS were updated incrementally. -This documentation describes the data and methods for the 2023 version -of ReEDS. The “Differences from the 2020 Model Version” section of the -appendix summarizes more of the specific changes to made to ReEDS since -the 2020 version.

-
-
-

Summary of Caveats

-

Though ReEDS represents many aspects of the U.S. electricity system, it -necessitates simplifications, as all models do. We offer a list of some -important limitations and caveats that result from these -simplifications.

-

System-wide optimization: ReEDS takes a system-wide, least-cost -perspective that does not necessarily reflect the perspectives of -individual decision makers, including specific investors, regional -market participants, or corporate or individual consumers; nor does it -model contractual obligations or noneconomic decisions. In addition, -like other optimization models, ReEDS finds the absolute (deterministic) -least-cost solution that does not fully reflect real distributions or -uncertainties in the parameters; however, the heterogeneity resulting -from the high spatial resolution of ReEDS mitigates this effect to some -degree.

-
    -

  • Resolution: Though ReEDS has high spatial, temporal, and process -resolution for models of its class and scope, it cannot generally -represent individual units and transmission lines, and it does not -have the temporal resolution to characterize detailed operating -behaviors, such as ramp rates and minimum plant runtime. It also does -not represent all intra-annual time scales, such as weekly or monthly -trends, as ReEDS intra-annual time slices are designed to characterize -one day in each season. Many of the time slice shortcomings are -addressed by using hourly data in VRE modules, but non-VRE generators -do not get that higher resolution.

    • -

  • Foresight and behavior: Except when running with intertemporal -optimization, the model has limited foresight, so model -decision-making does not account for anticipated changes to markets -and policies. For example, non-intertemporal runs in ReEDS do not -endogenously model banking and borrowing of credits for carbon, -renewable, or clean energy policy between solve periods.

    • -

  • Project pipeline: The model incorporates data of planned or -under-construction projects, but these data likely do not include -all projects in progress.

    • -

  • Manufacturing, supply chain, and siting: The model does not -explicitly simulate manufacturing, supply chain, or siting and -permitting processes. Potential bottlenecks or delays in project -development stages for new generation or transmission are not fully -reflected in the results. All technologies are assumed to be available -at their defined capital cost in any quantity up to their technical -resource potential. Penalties for rapid growth are applied in ReEDS; -however, these do not fully consider all potential manufacturing or -deployment limits. Dates associated with cost inputs in the model -reflect project costs for the commercial operation date but not -necessarily when equipment is ordered.

    • -

  • Financing: Though the model can use annually varying financing -parameters to capture near-term market conditions and -technology-specific financing to account for differences in typical -investment strategies across technologies, ReEDS cannot fully -represent differences in project financing terms across markets or -ownership types and thus does not allow multiple financing options for -a given technology.

    • -

  • Technology learning: Future technology improvements are considered -exogenously and thus are not a function of deployment in each -scenario.

    • -

  • Power sector: ReEDS models only the power sector within its -defined regional scope (contiguous United States or United States with -Canada and/or Mexico), and it does not represent the broader U.S. or -global energy economy. For example, competing uses of resources (e.g., -natural gas) across sectors are not dynamically represented in ReEDS, -and end-use electricity demand is exogenously input into ReEDS.

    • -
-

Notwithstanding these limitations—many of which exist in other similar -tools—the modeling approach considers complex interactions among -numerous policies and technologies while ensuring electric system -reliability requirements are maintained within the resolution and scope -of the model. In doing so, ReEDS can comprehensively estimate the system -cost and value of a wide range of technology options given a set of -assumptions, and we can use the model to generate self-consistent future -deployment portfolios.

-

A comparison against historical data using ReEDS was completed by Cole -and Vincent 2019 and is useful for providing context for how ReEDS can -perform relative to what actually occurred in historical years.

-
-
-
-

Modeling Framework

-

In this section, we describe the modeling framework underlying ReEDS, -including the modular structure of the model (and how outputs are passed -between modules and convergence is achieved), spatial resolution, -temporal resolution, technology represented, and the model formulations.

-
-

Model Structure

-

ReEDS combines an optimization module, representing electricity supply, -with a simulation module, which uses a dispatch algorithm and multiple -years of chronological hourly wind, solar, and load data to estimate the -contribution of storage and VRE units to capacity (see Resource Adequacy) -and the level of curtailment for VRE units.

-

The model can be run sequentially, intertemporally, or using a sliding -window. Fig. 16 illustrates how the modules -interact when the model is run in sequential solve mode. Within an -iteration, the supply and VRE modules are run in sequence for each model -solve year. For a given model year t, the supply module, which has -been provided with a set of inputs dependent on the results from -previous model years, is solved and a subset of the outputs are passed -along to the VRE and storage module. Using these inputs, the module then -calculates the capacity value of VRE and storage, and curtailment rates -for VRE units, which are then applied to the next model year solve -(t+1).[5]

-
-_images/ReEDS-structure.png -
-

Fig. 16 Schematic illustrating the ReEDS structure with a sequential solve

-
-
-

When the model is run with sliding window or perfect foresight. -Each iteration begins with an -execution of the supply module for all model years. The outer cycle (red -arrows) illustrates the order in which the modules are executed: -starting with the supply module followed by the VRE module, after which -the next iteration begins with the supply module. This process is -repeated until convergence. The inner cycles (orange arrows) illustrate -how information is shared by the modules. The types of information -shared by the two modules are the same as for the sequential solve mode. -The major difference is that the supply module passes information for -all model years to the VRE and storage module (and vice versa), and that -an iterative process occurs between the two modules.

-

Regardless of which foresight mode is chosen, the modular structure -allows each part of the model to be executed independently. However, the -supply and VRE and storage modules are unlikely to be executed without -each other, except for testing purposes. This is because one of the key -strengths of ReEDS resides in its detailed representation of VRE -integration and valuation.

-
-
-

Model Formulation

-

The supply module is a linear program that governs the evolution and operation of the -generation and transmission system. This module seeks to minimize power -sector costs as it makes various operational and investment decisions, -subject to a set of constraints on those decisions.

-

The objective function is a minimization of both capital and operating -costs for the U.S. electric sector, including:

-
    -

  • The net present value of the cost of adding new generation, storage, -and transmission capacity (including project financing)

    • -

  • The present value of operating expenses over the evaluation period[6] -(e.g., expenditures for fuel and operation and maintenance [O&M]) -for all installed capacity

    • -

  • The cost of several categories of ancillary services and storage

    • -

  • The cost or incentive applied by any policies that directly charge or -credit generation or capacity

    • -

  • Penalties for rapid capacity growth as a proxy for manufacturing, -supply chain, and siting/permitting limitations.

    • -
-

By minimizing these costs and meeting the system constraints (discussed -below), the linear program determines the types of new capacity to -construct in each region during each model year to minimize systemwide -cost. Simultaneously, the linear program determines how generation and -storage capacity should be dispatched to provide the necessary grid -services in each of the selected representative timeslices. The capacity -factor for each dispatchable technology, therefore, is an output of the -model and not an input assumption.

-

The constraints that govern how ReEDS builds and operates capacity fall -into several main categories:

-
    -

  • Load Balance Constraints: Sufficient power must be generated -within or imported by the transmission system to meet the projected -load in each of the 134 balancing areas (BAs) in each of the -representative time-slices. The annual demand and the -time-slice-specific electricity demand in future years are scaled -based on load growth inputs.

    • -

  • Planning Reserve Constraints: Each region must have sufficient -available capacity to meet the forecasted peak demand as well as an -additional planning reserve margin [NERC, 2021]. Dispatchable technologies -contribute their full capacity toward planning reserves. For variable -renewable energy (VRE) technologies, ReEDS uses a load-duration curve -(LDC) approximation to estimate the effective load-carrying capacity -of both existing capacity and potential capacity additions to -determine their contribution to meeting the reserve margin. For -storage, a chronological simulation using hourly data is used to -assess its contribution. Planning reserve capacity can also be traded -between regions if transmission capacity is available.[7]

    • -

  • Operating Reserve Constraints: These constraints ensure enough -capacity is available to meet unexpected changes in generation and -load in each reserve-sharing group (Operational Reliability) and time-slice. ReEDS -accounts for the following operating reserve requirements: regulation -reserves, spinning reserves, and flexibility reserves.

    • -

  • Generator Operating Constraints: Technology-specific constraints -bound the minimum and maximum power production and capacity commitment -based on physical limitations and assumed average outage rates.

    • -

  • Transmission Constraints: Power transfers among regions are -constrained by the nominal carrying capacity of transmission corridors -that connect the regions. Transfers of planning reserves are also -subject to transmission limits. A detailed description of the -transmission constraints can be found in Transmission.

    • -

  • Resource Constraints: Many renewable technologies, including wind, -solar, geothermal, biopower, and hydropower, are spatially -heterogeneous and constrained by the quantity available at each -location. Several of the technologies include cost- and -resource-quality considerations in resource supply curves to account -for depletion, transmission, and competition effects. The resource -assessments that seed the supply curves come from various sources; -these are discussed in Technology Descriptions, where characteristics of each -technology are also provided.

    • -

  • Emissions Constraints: ReEDS can limit or cap the emissions from -fossil-fueled generators for sulfur dioxide (SO2), nitrogen -oxide (NOx), and carbon dioxide (CO2). -The emission limit and the emission per megawatt-hour by fuel and -plant type are inputs to the model. Negative emissions are allowed -using biomass with carbon capture and storage (BECCS) or direct air -capture (DAC), and the emission constraint is based on net emissions. -Emissions can be either capped or taxed, with flexibility for applying -either. Alternatively, emissions intensities can also be limited to -certain bounds in ReEDS. The emissions constraints can be applied to -stack emissions, or can be based on CO2 equivalent -emissions, with the later including emissions from upstream methane -leakage.[8] Methane leakage rates are input by the user.

    • -

  • Renewable Portfolio Standards or Clean Electricity Standards: -ReEDS can represent renewable portfolio standards (RPSs) and clean -electricity standards constraints at the national and state levels. -All renewable generation is considered eligible under a national RPS -requirement. The renewable generation sources include hydropower, -wind, CSP, geothermal, PV, and biopower (including the biomass -fraction of cofiring plants). The eligibility of technologies for -state RPSs depends on the state’s specific requirements and thus -varies by state. RPS targets over time are based on an externally -defined profile. Penalties for noncompliance can be imposed for each -megawatt-hour shortfall occurring in the country or a given state. In -the same way, a clean energy standard constraint can be implemented to -include non-renewable clean energy resources, such as nuclear, fossil -fuels with carbon capture and sequestration (CCS), or natural gas.

    • -
-
-
-

Spatial Resolution

-

ReEDS is typically used to study the contiguous United States.[9] -Within the contiguous United States, ReEDS models capacity -expansion and grid service requirements in 134 model BAs, shown in -Fig. 17. The model BAs are not designed to represent or align perfectly -with real balancing authority areas; they are county aggregates intended -to represent model nodes where electricity supply and demand is -balanced. The model’s synthetic transmission network connects the BAs -and is composed of roughly 300 representative corridors across the three -asynchronous interconnections: the Western Interconnection, the Eastern -Interconnection, and Electric Reliability Council of Texas (ERCOT). The -BAs also respect state boundaries, allowing the model to represent -individual state regulations and incentives. Additional geographical -layers used for defining model characteristics include 3 synchronous -interconnections, 18 model regional transmission operators designed -after existing regional transmission operators, 19 North American -Electric Reliability Corporation (NERC) reliability subregions, 9 census -divisions as defined by the U.S. Census Bureau, and 48 states.[10] The -spatial configuration in the model is flexible, such that the model can -be run at various resolutions (e.g., aggregations of balancing areas), -and data within the model are filtered to only include data for the -regions being modeled in a given scenario.

-

For more information on the spatial flexibility in the model, see the -“Spatial Resolution Capabilities” section of the appendix.[11]

-
-_images/reeds-regional-structure.png -
-

Fig. 17 ReEDS regional structure

-
-
-

ReEDS includes 134 zones (used for most model decisions), 18 -transmission groups (used for grouped-interface flow constraints), 11 -planning regions (used by default for representative period selection -and capacity credit calculations), 11 NERC regions (used to define -planning reserve margin constraints), 10 USDA regions (used for -bioenergy supply curves), 9 census divisions (used for fossil gas supply -curves), and 3 synchronous interconnections (used to set the boundaries -for AC transmission expansion).

-
-
-

Temporal Resolution

-
    -

  • Thematic overview

    -
      -

    • Representative periods

      • -

    • 2007-2013; 2012 is default for rep periods while 2007-2013 used for RA

      • -

    • Representative period selection

      • -

    • Optimized

      • -

    • Hierarchical

      • -
    -
    • -
-

Many energy system models often solve a full chronological year at -hourly resolution in order to capture the time dependent variability -that pervades increasingly renewable systems. However, high temporal -resolution coupled with high spatial resolution can lead to intractable -optimization problems. For instance, in ReEDS, solving model years in -chronological 4-hour steps is only possible when the model regions are -aggregated and the complexity of the scenario is reduced to eliminate -some constraints. Given the computational challenges, power system -planning models typically forgo full annual temporal resolution and -instead select representative periods to capture variability [Fleischer, 2020]. A -common approach as described in the literature [Liu et al., 2018, Marcy et al., 2022, Teichgraeber and Brandt, 2019] -identify these periods uses hierarchical clustering which builds a -hierarchy of clusters based on dissimilarity between sets of -observations in wind capacity factor, solar capacity factor, and demand -time series data. In Reichenberg and Hedenus 2022 the authors demonstrate that hierarchical -clustering is unable to capture regional trends in large systems such as -the United States, motivating an optimization based approach to -determine representative periods in the ReEDS model. The two-step -optimization first weights periods to minimize error in regional -capacity factor and load data over all features (wind capacity factor, -solar capacity factor, and load) and all regions as described by (1). -The error is defined as the difference between the sum of the weighted -regional profiles for wind, solar, and load and the actual regional -profiles over all periods and all regions as described in (2). The -result of this minimization is a selection of representative days -weighted by number of total days in the year.

-
-\[\min \sum_{f,r}^{F,R} E_{1+}(f,r) + E_{1-}(f,r)\]
-

(1)

-
-\[E_{1+}(f,r) + E_{1-}(f,r) = \sum_{p}^{P} W(p)x(p,f,r) - \sum_{p}^{P} x(p,f,r) \quad \forall \ f,r\]
-

(2)

-

In the second step of the optimization, actual periods are mapped to the -most similar representative period by again minimizing the sum of -absolute error over all periods, features, and regions. The error in -this minimization problem is defined as the difference between the -actual profile for a given actual period, \(_{}\),and the representative -profile for the period that actual period is mapped to, -\(\left(_{} \right)\). Since each actual period can only be mapped to a -single representative day, the problem is formulated as a mixed integer -linear program as described in (3) and (4).

-
-\[\min [ \sum_{p_a,f,r}^{P,F,R} x(p_a,f,r) - \sum_{p_r}^{P_r} M(p_a,p_r) x(p_r,f,r)]\]
-

(3)

-
-\[\sum_{p_r}^{P_r} M(p_a, p_r) = 1 \quad \forall \ p_a\]
-

(4)

-

In conjunction, the results of both optimizations lead to a set of -representative periods where the weighting determined in step one -indicates the number of times a representative period will be used over -the course of the year. For example, a representative day weighted by 36 -will be used to replace the 36 actual days of the year which are most -similar. Ultimately this optimization-based approach to identify -representative periods helps to reduce the required number of periods -while also capturing regional trends.

-
    -

  • Period resolution: days, 5-day “weeks”, or chronological year

    • -

  • Timeslice chunks: 4-hour default but can use 1-, 2-, or 3-hour chunks -for smaller system

    • -

  • Inter-period linkages

    -
      -

    1. Diurnal storage cycles within periods

      2. -

    2. “Seasonal” storage (currently just H2) level is tracked between -periods

      3. -

    3. Linearized startup costs apply between periods

      4. -
    -
    • -
-
-
-
-

Technology Descriptions

-

This section describes the electricity generating technologies included -in ReEDS. Cost and performance assumptions for these technologies are -not included in this report but are taken directly from the 2023 Annual -Technology Baseline (ATB) [NREL, 2023].

-
-

Renewable Energy Resources and Technologies

-

Because renewable energy technologies are a primary focus area of the -ReEDS model, they are characterized in detail. Their characterization -encompasses resource assessments,[12] projected technology -improvements, grid interconnection costs, and operational implications -of integration. Renewable energy technologies modeled include land-based -and offshore wind power, solar PV (both distributed and utility-scale), -CSP with and without thermal storage,[13] hydrothermal geothermal, -near-field enhanced geothermal systems (EGS), deep EGS, run-of-the-river -and traditional hydropower (including upgrades and non-powered dams), -dedicated biomass, cofired biomass, land-fill gas, renewable energy -combustion turbines, and marine hydrokinetic wave technologies. The -input assumptions, data sources, and treatments of these technologies -are discussed in the following sections. Transmission considerations for -renewable energy technologies are discussed in Interzonal Transmission.[14]

-
-

Land-Based Wind

-

Wind technologies are modeled using representative turbine technologies -by region depending on wind resource quality. Details of the wind -resource data and technology representation can be found in Appendix H -of the Wind Vision study [DOE, 2015]. In the current version of ReEDS, we -have relied on the same data sources and approach; however, we extend -the wind resource data to lower-quality wind sites.

-

The resource assessment for land-based wind uses a resource map of -hourly wind speeds for the United States and offshore areas (for -offshore wind, see Offshore Wind) and -considers land use exclusions [Lopez et al., 2021]. The Reference Access -resource totals more than 7,700 gigawatts (GW), although a Limited -Access and Open Access supply curves are also available.

-

Individual wind sites are grouped into ten resource classes for ReEDS, -based on average wind speed (Table 1).[15] The modeling and assessment of individual wind sites -was facilitated using NREL’s Renewable Energy Potential (reV) tool -[Maclaurin et al., 2021]. The meteorological data for onshore wind are -from the Wind Integration National Dataset (WIND) Toolkit, using -long-term average data for the resource assessment. Fig. 18 shows the -land-based wind resource data modeled in ReEDS for all 10 classes, where -the highest average wind speeds belong to class 1 and the lowest to -class 10 [Mai et al., 2021]. Each class is then further differentiated by -a supply curve for grid interconnection costs in each region. See -Interzonal Transmission for a discussion of interconnection supply curves for -accessing the wind resource.

-

Distinct wind production profiles are also modeled for each class and -region. In addition, to inform capacity credit and curtailment -calculations, we use hourly production data for each region and class. -Timeslice profiles are based on the 2012 weather year (though this can -be changed by the user), and hourly profiles are from the 2007-2013 -weather years.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 1 Land-Based Wind Class Definitions

Wind Class

Wind Speed Range (m/s)

Potential Wind Plant Capacity (GW)

1

> 9.01

106

2

8.77 - 9.01

91

3

8.57 - 8.77

188

4

8.35 - 8.57

356

5

8.07 - 8.35

684

6

7.62 - 8.07

1,266

7

7.10 - 7.62

1,191

8

6.53 - 7.10

1,159

9

5.90 - 6.53

1,144

10

< 5.90

1,587

-

More information can be found in the NREL Annual Technology Baseline -[NREL, 2020].

-
-_images/land-based-wind.png -
-

Fig. 18 Land-based wind resource availability and capacity factor for the three siting scenarios included in ReEDS.

-
-
-
-
-

Offshore Wind

-

There is substantial diversity in offshore wind generators, in distance -from shore, water depth, and resource quality. ReEDS subdivides offshore -wind potential into fourteen resource classes: seven each for -fixed-bottom and floating turbine designs. Fixed bottom offshore wind -development is limited to resources < 60 meters [m] in depth using -either current-technology monopile foundations (0–30 m); or jacket -(truss-style) foundations (30–60 m). Offshore wind using a floating -anchorage could be developed for greater depths and are assumed the only -feasible technology for development for resource deeper than 60 m. -Within each category, the classes are distinguished by resource quality, -and then supply curves differentiate resource by cost of accessing -transmission in a similar fashion as land-based wind.

-

Eligible offshore area for wind development includes open water within -the U.S.-exclusive economic zone having a water depth less than 1,000 m, -including the Great Lakes. As with land-based resource, offshore zones -are filtered to remove areas considered unsuitable for development, -including national marine sanctuaries, marine protected areas, wildlife -refuges, shipping and towing lanes, offshore platforms, and ocean -pipelines. The offshore technology selection is made using the Offshore -Wind Cost Model, which selects the most economically feasible technology -for developing a wind resource [Beiter and Stehly, 2016]. More than 4,900 -GW of technical offshore wind potential remain after applying the -exclusions.

-

Current-day cost data are derived from the published data of the global -offshore wind industry as well as estimates from recent development -activity on the Atlantic Coast of the United States [Musial et al., 2019, NREL, 2019]. These data are coupled with engineering assessments and -distance-based cost functions (specific to the offshore export cable and -incremental construction cost associated with moving farther from shore) -to determine expected site-specific costs for technology across a broad -range of water depths and distances from shore [Beiter et al., 2017]. -Cost and performance for offshore wind plants are based on assuming a -representative plant size of 600 MW.

-

Other aspects of our model representations for offshore wind follow the -same methods as those for land-based wind [Lopez et al., 2021]. -Fig. 19 shows the offshore wind resource potential -modeled in ReEDS for each of the 14 classes. Classes 1-7 represent fixed-bottom -offshore wind resources with class 1 representing the highest wind speeds. Classes -8-14 represent floating offshore wind resources with class 8 being the -highest wind speeds. The higher speed classes have smaller bin sizes to -capture the highest quality resources with greater resolution.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 2 Offshore Wind Class Definitions

Wind Class

Wind Speed Range (m/s)

Potential Wind Plant Capacity (GW)

Fixed-Bottom

1

> 9.98

24

2

9.31 - 9.98

23

3

9.13 - 9.31

53

4

8.85 - 9.13

97

5

7.93 - 8.85

197

6

7.07 - 7.93

396

7

< 7.07

445

Floating

8

> 10.30

73

9

10.18 - 10.30

71

10

10.01 - 10.18

152

11

9.60 - 10.01

293

12

8.84 - 9.60

590

13

7.43 - 8.84

1189

14

< 7.43

1320

-

More information can be found in the NREL Annual Technology Baseline -[NREL, 2020].

-
-_images/offshore-wind-resource.png -
-

Fig. 19 Offshore wind resource availability (fixed-bottom and floating) and capacity factor for the contiguous United States

-
-
-
-
-

Solar Photovoltaics

-

ReEDS differentiates among three solar photovoltaic technologies: -large-scale utility PV (UPV), distribution-side utility-scale PV (DUPV), -and rooftop PV. Investments in UPV and DUPV are evaluated directly in -ReEDS, while rooftop PV deployment and performance are exogenously input -into ReEDS from the dGen model. ReEDS further allows for investment in -hybrid systems comprising coupled UPV and battery technologies (PVB).

-

UPV in ReEDS represents utility-scale, single-axis-tracking PV systems -with a representative size of 100 megawatts (MW), an array density of 39 -MW per square kilometer (km2), and an inverter loading ratio -of 1.3. Resource potential is assumed to be located on large parcels -outside urban boundaries, excluding federally protected lands, -inventoried “roadless” areas, U.S. Bureau of Land Management areas of -critical environmental concern, and areas with slope greater than 5%. -Each eligible UPV site is characterized by a raw hourly (8,760) -irradiance profile that is representative of the solar resource within a -10 km2 contiguous area. Each of these UPV sites are compiled -into supply curves for each of the 134 ReEDS BAs with 9 PV resource -classes, which are further differentiated by cost to connect to the -transmission network (process described in Interzonal Transmission). -The resource classes reflect different -resource qualities based on the annual average global horizontal -irradiance (GHI) reported by the latest National Solar Radiation -Database (NSRDB), assuming a tilt angle equal to the latitude (Table 3). -The UPV supply curves input into ReEDS for the conterminous U.S. include -156 terawatts (TW) of potential.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 3 UPV and DUPV Resource Classes

Class

GHI (kWh/m^2/day)

Potential UPV Capacity (GW)

Potential DUPV Capacity (GW)

1

3.0 - 3.5

167

14

2

3.5 - 4.0

16,870

184

3

4.0 - 4.5

30,238

434

4

4.5 - 5.0

37,438

511

5

5.0 - 5.5

20,372

222

6

5.5 - 6.0

11,868

116

7

6.0 - 6.5

332

4

-

Investment options along the UPV supply curve can take the form of -either standalone UPV systems or PVB systems. The default PVB technology -represents a loosely DC-coupled system: the PV and battery technologies -share a bi-directional inverter and point of interconnection, and the -battery can charge from either the coupled PV or the grid. The PVB -design characteristics can be user defined for up to three different -configurations, but the default configuration involves an inverter -loading ratio of 2.2 (slightly higher than standalone PV), and a coupled -battery with 4hr duration, whose power-rated capacity is 50% of the -inverter capacity.

-

The PVB investment option leverages the existing representations of the -independent component technologies, but the cost and performance -characteristics differ from the simple sum of the separate (PV and -battery) parts. For example, the capital costs associated with the fully -integrated PVB hybrid system are reduced based on the cost of a shared -inverter and other balance-of-system components; as a result, the -percentage savings varies by PVB configuration. Improved performance -characteristics are captured through slightly enhanced battery round -trip efficiencies and explicit time series generation profiles; the -latter enables a representation of the PVB system’s ability to divert -otherwise-clipped energy to the coupled battery (during periods where -solar output exceeds the inverter capacity) and avoid curtailment. -Finally, a joint capacity credit results in a greater localized -contribution to resource adequacy, which is comparable overall to the -sum of capacity credits for separate PV and battery systems.

-
-_images/upv-resource-availability.png -
-

Fig. 20 UPV resource availability and DC capacity factor -[MWACavailable/MWDCnameplate] -for the three siting scenarios included in ReEDS

-
-
-

DUPV systems have lower infrastructure requirements than large-scale -rural UPV systems; we assume they connect to existing nearby -distribution substations at about 13 kilovolts (kV), whereas the -representative UPV system connects to a high-voltage bus at 230 kV and -may require a spur line several miles long to reach that connection -point. The cost of the spur line is handled separately in the -accessibility supply curve (Interzonal transmission), but -the additional transformers and power electronics associated with the -larger systems and higher-voltage interconnections add cost and losses -to the UPV systems. On the other hand, the larger UPV systems benefit -from economies of scale. On balance, we assume a per-kW capital cost -penalty of 29%[16] and 5% higher delivered energy (i.e., reduced -losses) for DUPV relative to UPV.

-

Performance characteristics for UPV and DUPV were developed using NREL’s -reV Tool, using multiyear hourly weather files from the National Solar -Radiation Database[17] at 4-km by 4-km parcels throughout the -contiguous United States from 1998 to 2016. No changes or improvements -in capacity factor over time are assumed for PV technologies. For each -ReEDS BA region, resource quality classifications were made by averaging -across the 1998–2016 period for all available parcels. Hourly generation -profiles were taken from 2007-2013. The generation profiles from 2012 -from all the regions in a BA for each resource class were averaged to -provide ReEDS with average capacity factors by time-slice and resource -class.

-

To mitigate excessive wheeling of distributed PV generation, ReEDS -assumes all power generated by both DUPV and rooftop PV systems is -permitted to be exported to neighboring BAs only when total generation -in the source region exceeds the load for a given time-slice. -UPV-generated electricity, in contrast, can be exported in all -time-slices and regions.

-

Degradation of the efficiency of solar PV capacity over time is also -modeled at 0.7%/year [NREL, 2020]. This degradation is modeled by reducing the generating capacity of PV by 0.7%/year.

-

Rooftop PV includes commercial, industrial, and residential systems. -These systems are assumed to have an inverter loading ratio of 1.1. The -Distributed Generation Market Demand model (dGen), a consumer adoption -model for the contiguous U.S. rooftop PV market, is used to develop -future scenarios for rooftop PV capacity, including the capacity -deployed by BA and the pre-curtailment energy production by that -capacity [Sigrin et al., 2016]. The default dGen trajectories used in -this version of ReEDS are based on the residential and commercial PV -cost projections as described in the 2020 [National Renewable Energy Laboratory, 2020]. There are 11 -unique rooftop PV trajectories available in ReEDS that are from the 2020 -Standard Scenarios report [Cole et al., 2020]. These -trajectories were created by running a ReEDS scenario and feeding the -electricity price outputs from ReEDS back into dGen. The trajectories -incorporate existing net metering policy as of spring 2020, and they -include the investment tax credit (ITC) as discussed in Federal and State Tax Incentives.

-

Assumptions for each dGen scenario are made consistent with the ReEDS -scenario assumptions as much as is possible. For example, the Tax Credit -Extension scenario also includes an extension of the ITC in dGen, and -the Low PV Cost scenario uses low trajectory from ATB for commercial and -rooftop PV costs.

-
-
-

Concentrating Solar Power

-

Concentrating solar power (CSP) technology options in ReEDS encompass a -subset of possible thermal system configurations, with and without -thermal storage, as shown in Table 4. The various system types access -the same resource potential, which is divided into 3 resource classes -based on direct normal insolation (DNI) (Table 5). The CSP resource and -technical potential are based on the latest version of NSRDB. Details of -the CSP resource data and technology representation can be found in -Appendix B of Murphy et al. 2019. By default, recirculating and dry -cooling systems are allowed for future CSP plants getting built in -ReEDS. CSP cost and performance estimates are a based on an assumed -plant size of 100 MW.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 4 Characteristics of CSP Technology Options

Storage Duration (hours)

Solar Multiple[18]

Dispatchability

Capacity Credit

Curtailment

None

1.4

insolation-dependent

Calculated based on hourly insolation

Allowed

6

1.0

dispatchable

Calculated based on storage duration and hourly insolation

Not allowed

8

1.3

dispatchable

Calculated based on storage duration and hourly insolation

Not allowed

10

2.4

dispatchable

Calculated based on storage duration and hourly insolation

Not allowed

14

2.7

dispatchable

Calculated based on storage duration and hourly insolation

Not allowed

-

The CSP resource classes are defined by power density of DNI, -developable land area having been filtered based on land cover type, -slope, and protected status. CSP resource in each region is therefore -represented as a supply curve of megawatts of solar collector potential, -assuming a power density of 14.9 MW/km.2 Performance for each -CSP resource class is developed using 2012 hourly resource data -[Sengupta et al., 2018] from representative sites of each region. The -2012 weather files are processed through the CSP modules of the System -Advisor Model (SAM) to develop performance characteristics for each CSP -resource class and representative CSP system considered in ReEDS. CSP -capacity credit calculations are based on hourly profiles from -2007-2013. As with wind and PV technologies, CSP resources are further -distinguished by grid accessibility in each region (Interzonal Transmission).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 5 Resource Classes for CSP Plants Using a Solar Multiple (SM) of 2.4

Resource Class

DNI (kWh/m^2/day)

Weighted Average Field CF for SM=1 system (%)^a

Available Resource (GW)

Class 1

5 - 5.25

17

2,641

Class 2

5.25 - 5.5

18

1,925

Class 3

5.5 - 5.75

19

1,495

Class 4

5.75 - 6

20

1,725

Class 5

6 - 6.25

21

1,850

Class 6

6.25 – 6.5

22

1,282

Class 7

6.5 – 6.75

23

1,252

Class 8

6.75 – 7

24

1,098

Class 9

7 – 7.25

26

1,381

Class 10

7.25 – 7.5

27

1,251

Class 11

7.5 – 7.75

28

677

Class 12

>7.75

29

114

-

Resources are then scaled in ReEDS by the ratio of the model-determined -SM and 2.4.

-

a The field capacity factors (CF) shown here are from SAM -(version 2017.09.05, SDK version 181) simulation assuming an SM=1 -system. This field capacity factor is meant to represent the upper limit -of corresponding turbine capacity factor for all systems with SM>1.

-

The representative CSP system without storage used to define system -performance in ReEDS is a 100-MW trough system with a SM of 1.4. As CSP -systems without storage are non-dispatchable, output capacity factors -are defined directly from SAM results. The average annual capacity -factors for the solar fields of these systems range from 20% (Class 1 -resource) to 29% (Class 12 resource).

-
-_images/csp-resource-availability.png -
-

Fig. 21 CSP resource availability and solar field capacity factor for the contiguous United States

-
-
-

The representative system for any new CSP with thermal energy storage is -a tower-based configuration with a molten-salt heat-transfer fluid and a -thermal storage tank between the heliostat array and the steam -turbine.[19] Two CSP with storage configurations are available as shown -in Table 4.

-

For CSP with storage, plant turbine capacity factors by time-slice are -an output of the model, not an input, as ReEDS can dispatch collected -CSP energy independent of irradiation. Instead, the profile of power -input from the collectors (solar field) of the CSP plants are model -inputs, based on SAM simulations from 2012 weather files.

-

The capacity credit of CSP with storage is calculated using the same -method as the calculation of the capacity credit of other storage -technologies, except that rather than using net load to show -opportunities to charge, DNI resource is used to show opportunities to -charge the storage. See “Stress periods” formulation for details.

-
-
-

Geothermal

-

The ReEDS representation of geothermal power was substantial -restructured compared to the prior ReEDS documentation.

-

The geothermal resource has two distinct subcategories in ReEDS:

-
    -

  • The hydrothermal resource represents potential sites with appropriate -geological characteristics for the extraction of heat energy. The -hydrothermal potential included in the base supply curve consists of -only identified sites, with a separate supply curve representing the -undiscovered hydrothermal resource.

    • -

  • EGS sites are geothermal resources that have sufficient temperature -but lack the natural permeability, in-situ fluids, or both to be -hydrothermal systems. Developing these sites with water injection -wells could create engineered geothermal reservoirs appropriate for -harvesting heat.

    • -
-

EGS is further separated into Near-Field EGS and Deep EGS based upon -proximity to known hydrothermal features. Near-Field EGS represents -additional geothermal resource available near hydrothermal fields -which have been identified. Deep EGS represents available geothermal -resource not tied to existing hydrothermal sites and at depths below -3.5 km.

-

Geothermal in ReEDS represents a geothermal power production with -representative size up to 100 megawatts electric (MWe). -Geothermal resource classes are defined by reservoir temperature -ranges which are closely linked to the cost of a plant normalized by -generation capacity. Energy conversion processes, binary and flash -cycles are linked to reservoir temperature and are specified by -resource class. Plants with reservoir temperatures < 200 °C (Class -7-10) use a binary cycle, which uses a heat exchanger and secondary -working fluid with a lower boiling point to drive a turbine. All other -reservoir temperatures assume that a turbine is driven directly by -working fluid from the geothermal wells. These assumptions are aligned -with those in ATB 2023.

-

Table 6 lists the technical resource potential for the different geothermal categories.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 6 Technical Resource Potential (GW)

Resource Class

Reservoir Temperature (°C)

Hydrothermal

Near-Field EGS

Deep EGS

Class 1

> 325

-

0.2

-

Class 2

300 – 325

1.8

0.2

-

Class 3

275 – 300

9.3

0.1

1.2

Class 4

250 – 275

0.7

0.1

8.2

Class 5

225 – 250

1.1

0.1

74

Class 6

200 – 225

2.4

0.2

320

Class 7

175 – 200

0.2

0.3

709

Class 8

150 – 175

2.6

0.3

995

Class 9

125 – 150

1.1

0.03

1270

Class 10

< 125

4.7

-

-

Total

23.9

1.4

3,375

-

The default geothermal resource assumptions allow for hydrothermal -sites. Hydrothermal resources have a defined fraction which are -considered identified resources based upon the U.S. Geological Survey’s -2008 geothermal resource assessment. The undiscovered portion of the -hydrothermal resource is limited by a discovery rate defined as part of -the GeoVision Study [DOE, 2019]. The geothermal supply curves are based -on the analysis described by Augustine et al. 2019 and are shown in -Fig. 21. The hydrothermal and near-field EGS resource potential is -derived from the U.S. Geological Survey’s 2008 geothermal resource -assessment [Williams et al., 2008], while the deep EGS -resource potential is based on an update of the EGS potential from the -Massachusetts Institute of Technology [Tester et al., 2006]. As -with other technologies, geothermal cost and performance projections are from -the ATB [NREL, 2023]. Alternate resource supply curves can be -incorporated from reV analysis but are currently not part of the default -resource representation. Spurline transmission costs are available when -using reV based supply curves.

-
-
-

Hydropower

-

The existing hydropower fleet representation is informed by historical -performance data. From the nominal hydropower capacity in each BA, -seasonal capacity adjustments are used for Western Electricity -Coordinating Council (WECC) regions based on data from the Transmission -Expansion Planning Policy Committee (TEPPC) 2024 Common Case -[WECC, 2013, WECC, 2015]. Seasonal capacity adjustments allow more realistic seasonal -variations in maximum capacity due to changes in water availability and -operating constraints. These data are not available for non-WECC -regions. Future energy availability for the existing fleet is defined -seasonally using plant-specific hydropower capacity factors averaged for -2010–2019 as reported by Oak Ridge National Laboratory HydroSource data -(https://hydrosource.ornl.gov/datasets). Capacity factors for historical -years are calibrated from the same data source so that modeled -generation matches historical generation. PSH, both existing and new, is -discussed in Storage Technologies. Generally, the -seasonal energy allocation for hydropower must remain in the predefined -season, but ReEDS has the option of allowing a fraction of available -energy to be shifted across seasons, up to 100% of the total.

-

Three categories of new hydropower resource potential are represented in -the model:

-
    -

  1. Upgrade and expansion potential for existing hydropower

    2. -

  2. Potential for powering non-powered dams (NPD)

    3. -

  3. New stream-reach development potential (NSD).

    4. -
-

The supply curves for each are discussed in detail in the Hydropower -Vision report [DOE, 2016], particularly Chapter 3 and Appendix B.

-

ReEDS does not currently distinguish between different types of -hydropower upgrades, so upgrade potential is nominally represented -generically as a potential for capacity growth that is assumed to have -the same energy production potential per capacity (i.e., capacity -factor) as the corresponding existing hydropower capacity in the region. -An optional representation of hydropower upgrades decouples capacity and -energy upgrades so that the model can choose either type of upgrade -independently. The quantity of available upgrades is derived from a -combination of limited resource assessments and case studies by the U.S. -Bureau of Reclamation Hydropower Modernization Initiative (HMI), U.S. -Army Corps of Engineers (Corps), and NHAAP Hydropower Advancement -Project [Montgomery et al., 2009, Bureau of Reclamation, 2011]. -Upgrade availability at federal facilities not included in the -HMI is assumed to be the HMI average of 8% of the rated capacity, and -upgrade availability at non-federal facilities is assumed to be the -NHAAP average of 10% of the rated capacity. Rather than making all -upgrade potential available immediately, upgrade potential is made -available over time at the earlier of either (1) the Federal Energy -Regulatory Commission (FERC) license expiration (if applicable) or (2) -the turbine age reaching 50 years. This feature better reflects -institutional barriers and industry practices surrounding hydropower -facility upgrades. The total upgrade potential from this methodology is -6.9 GW (27 TWh/yr).

-
-_images/hydro-vision-upgrade-resource-potential.png -
-

Fig. 22 Modeled hydropower upgrade resource potential [DOE, 2016]

-
-
-

NPD resource is derived from the 2012 NHAAP NPD resource assessment -[Hadjerioua et al., 2013, Kao et al., 2014], where the -modeled resource of 5.0 GW (27 TWh/yr) reflects an updated site sizing -methodology, data corrections, and an exclusion of sites under 500 kW to -allow better model resolution for more economic sites.

-
-_images/hydro-vision-npd-resource-potential.png -
-

Fig. 23 Modeled non-powered dam resource potential [DOE, 2016]

-
-
-

NSD resource is based on the 2014 NHAAP NSD resource assessment [Kao et al., 2014], where the modeled resource of 30.7 GW (176 TWh/yr) reflects -the same sizing methodology as NPD and a sub-1 MW site exclusion, again -to improve model resolution for lower-cost resource. The NSD resource -assumes “low head” sites inundating no more than the 100-year flood -plain and excludes sites within areas statutorily barred from -development—national parks, wild and scenic rivers, and wilderness -areas.

-
-_images/hydro-vision-nsd-resource-potential.png -
-

Fig. 24 Modeled new stream-reach development resource potential [DOE, 2016]

-
-
-

The combined hydropower capacity coupled with the costs from the ATB [NREL, 2023] results in the supply curve shown in Fig. 24.

-
-_images/hydro-supply-curve.png -
-

Fig. 25 National hydropower supply curve of capital cost versus cumulative capacity potential

-
-
-

The hydropower operating parameters and constraints included in ReEDS do -not fully reflect the complex set of operating constraints on hydropower -in the real world. Detailed site-specific considerations involving a -full set of water management challenges are not easily represented in a -model with the scale and scope of ReEDS, but several available -parameters allow a stylized representation of actual hydropower -operating constraints [Stoll et al., 2017].

-

Each hydropower category can be differentiated into “dispatchable” or -“non-dispatchable” capacity, with “dispatchable” defined in ReEDS as the -ability to provide the following services:

-
    -

  1. Diurnal load following within the capacity and average daily energy limits for each season

    2. -

  2. Planning (adequacy) reserves with full rated capacity

    3. -

  3. Operating reserves up to a specified fraction of rated capacity if -the capacity is not currently being utilized for energy production.

    4. -
-

“Non-dispatchable” capacity, on the other hand, provides:

-
    -

  1. Constant energy output in each season such that all available energy is utilized

    2. -

  2. Planning reserves equal to the output power for each season

    3. -

  3. No operating reserves.

    4. -
-

Dispatchable capacity is also parameterized by a fractional minimum -load, with the maximum fractional capacity available for operating -reserves as one minus the fractional minimum load. The existing fleet -and its corresponding upgrade potential are differentiated by -dispatchability using data from the Oak Ridge National Laboratory -Existing Hydropower Assets Plant Database -(https://hydrosource.ornl.gov/dataset/EHA2023), which classifies plants -by operating mode. Plants with operating modes labeled as Peaking, -Intermediate Peaking, Run-of-River/Upstream Peaking, and -Run-of-River/Peaking are classified as dispatchable in ReEDS, and plants -with other operating modes are classified as non-dispatchable. In total, -47% of existing capacity and 49% of upgrade potential is assumed -non-dispatchable. ReEDS also includes the option to enable hydropower -upgrade pathways where existing non-dispatchable hydropower can be -upgraded to be dispatchable hydropower, or existing dispatchable -hydropower can be upgraded to add pumping and become a pump-back -hydropower facility. A pump-back facility is constrained similarly to a -PSH facility except that input energy can come from natural water -inflows in addition to the grid. These upgrade options can be made -available at a user-specified capital cost. Hydropower upgrades are -unavailable by default because it there is high uncertainty about where -such upgrades are feasible, but these optional features allow users to -explore the potential and value of increasing hydropower fleet -flexibility, which is discussed in detail in [Cohen and Mowers, 2022].

-

The same TEPPC database is used to define region-specific fractional -minimum capacity for dispatchable existing and upgrade hydropower in -WECC. Lacking minimum capacity data for non-WECC regions, 0.5 is chosen -as a reasonable fractional minimum capacity.

-

Both the NPD and NSD resource assessments implicitly assume inflexible, -run-of-river hydropower, so all NPD and NSD resource potential is -assumed non-dispatchable. Additional site-specific analysis could allow -re-categorizing portions of these resources as dispatchable, but 100% -non-dispatchable remains the default assumption.

-
-
-

Biopower

-

ReEDS can generate electricity from biomass either in dedicated biomass -integrated gasification combined cycle (IGCC) plants or cofired with -coal in facilities that have been retrofitted with an auxiliary fuel -feed. These cofire-ready coal plants can use biomass in place of coal to -supply the fuel for up to 15% of the plant’s electricity generation. A -cofire retrofit costs 305 $2017/kW based on EIA’s Electricity Market -Module assumptions [EIA, 2017, 101].

-

Dedicated and cofired plants source feedstock from the same biomass -supply curves, which are derived from the Oak Ridge National -Laboratory’s 2016 Billion-Ton Report [DOE, 2016]. -Data from this report includes estimates of biomass feedstock costs and -total resource availability. Only woody biomass resources are allowed to -be used for biopower plants. No other resource constraints are applied -for nonrenewable energy technologies.

-

Fig. 26 illustrates the resource map and total supply curve by region -as derived from the 2016 Billion-Ton Report and used in ReEDS. -Nationally, approximately 116 million dry tons of woody biomass are -assumed to be available to the power sector. In addition to the supply -curve price (which represents the cost of the resource in the field), -ReEDS also assumes costs of $15 per dry ton for collection and -harvesting, as well as an additional $15 per dry ton for transport, as -based on estimates from a 2014 INL study [Jacobson et al., 2014]. -Pathways with more limited biomass model the impact of a halving of the -available resource and a doubling of collection, harvesting, and -transport costs (58 million dry tons and $60 per ton), whereas the -enhanced resource scenario models the opposite (doubling the available -resource to 232 million dry tons and halving collection, harvesting, and -transport costs to $15 per ton).

-
-_images/biomass-supply-curve-regions.png -
-

Fig. 26 Depiction of the regions used for the biomass supply curves (map, top left), based on U.S. Department of Agriculture regional divisions. The line plots to the right indicate the woody biomass supply curves for each region as used in ReEDS, as derived from data in 2016 Billion-Ton Report. The bottom-left plot summarizes the total national supply curve.

-
-
-

Because the model assumes zero lifecycle emissions for biomass, -generation sources that use biomass with carbon capture and storage -(BECCS) are assumed to be negative emissions. Table 7 summarizes cost -and performance assumptions for BECCS plants. The uncontrolled emissions -rate of woody biomass fuel is assumed to be 88.5 kg/MMBtu [Bain et al., 2003]; -after accounting for the heat rate of a BECCS plant and a 90% CCS -capture rate, the negative emissions are approximately -1.22 to -1.11 -tonnes/MWh of generation. Fuel consumed in BECCS plants is counted -against the total biomass supply curve described above.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 7 Cost and Performance Assumptions for BECCS

BECCS

Capital Cost ($/kW)

Variable O&M ($/kWh)

Fixed O&M ($/kW-yr)

Heat Rate (MMBtu/MWh)

Emissions Rate (tonnes CO2/MWh)

2020

5,580

16.6

162

15.295

-1.22

2035

5,333

16.6

162

14.554

-1.16

2050

5,100

16.6

162

13.861

-1.11

-
-
-

Marine Hydrokinetic Wave

-

ReEDS does have a representation of marine hydrokinetic wave -technologies, but this capability is not utilized in any of the recent -or current ReEDS modeling work.

-
-
-
-

Conventional Energy Technologies

-

ReEDS includes all major categories of conventional generation -technologies within its operating fleet or its investment choices. In -the context of ReEDS, “conventional” is defined as thermal generating -technologies driven by coal, gas, oil, or nuclear fuel. Coal -technologies are subdivided into pulverized and gasified (IGCC) -categories, with the pulverized plants further distinguished by 1) -whether SO2 scrubbers are installed and 2) their vintage[20] -as pre- or post-1995. Pulverized coal plants have the option of adding a -second fuel feed for biomass. New coal plants can be added with or -without CCS technology. Existing coal units built after 1995 with -SO2 scrubbers installed also have the option of retrofitting -CCS capability.

-

Natural gas generators are categorized as combustion turbine (CT), -combined cycle (CC), or gas-CC with CCS.[21] There are also nuclear -(steam) generators, landfill gas generators,[22] and oil/gas steam -generators, though the latter two are not offered as options for new -construction besides those that are already under construction. The -model distinguishes each conventional-generating technology by costs, -efficiency, and operational constraints.

-

Where renewable energy technologies have many unique characteristics, -ReEDS conventional technologies are characterized more generally by the -following parameters:

-
    -

  • Capital cost ($/MW)

    • -

  • Fixed and variable operating costs (dollars per megawatt-hour -[$/MWh])

    • -

  • Fuel costs (dollars per million British thermal units -[$/MMBtu])

    • -

  • Heat rate (MMBtu/MWh)

    • -

  • Construction period (years) and expenses

    • -

  • Equipment lifetime (years)

    • -

  • Financing costs (such as interest rate, loan period, debt fraction, -and debt-service-coverage ratio)

    • -

  • Tax credits (investment or production)

    • -

  • Minimum turndown ratio (%)

    • -

  • Ramp rate (fraction per minute)

    • -

  • Planned and unplanned outage rates (%).

    • -
-

Cost and performance assumptions for all new conventional technologies -are taken from the ATB [NREL, 2023]. Regional variations and adjustments -are included and described in Hydrogen. Fixed operation and -maintenance costs for coal and nuclear plants increase over time with -the plants age. These escalation factors are taken from the -AEO2023.

-

In addition to the performance parameters listed above, technologies -are differentiated by their ability to provide operating reserves. In -general, natural gas plants, especially combustion turbines, are better -suited for ramping and reserve provision, while coal and nuclear plants -are typically designed for steady operation. See Operational Reliability for more -details.

-

The existing fleet of generators in ReEDS is taken from the NEMS unit -database from AEO2023 [EIA, 2023], with data supplemented from the June -2023 EIA 860M. In particular, ReEDS uses the net summer capacity, net -winter capacity,[23] location, heat rate, variable O&M, and fixed O&M -to characterize the existing fleet. ReEDS uses a modified “average” heat -rate for any builds occurring after 2010: a small, technology-specific -increase on the full-load heat rate is applied to accommodate for units -not always operating at their design point. The modifiers, shown in -Table 8, are based on the relationship between the reported heat rate -the ATB, and the actual observed heat rate, calculated on a fleet-wide -basis for each fuel type.

- - - - - - - - - - - - - - - - - - - - - -
Table 8 Multipliers Applied to Full-Load Heat Rates to Approximate Actual Observed Heat Rates

Technology

Adjustment Factor

Coal (all)

1.066

Gas-CC

1.076

Gas-CT

1.039

OGS

0.875

-

Emissions rates from conventional plants are a function of the fuel -emission rate and the plant heat rate. Burner-tip emissions rates are -shown in Table 9. Because ReEDS does not differentiate coal fuel types, -the coal CO2 emissions rate in the model is the average of -the bituminous and subbituminous emissions -rate.[24]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 9 Emissions Rate by Generator Type in Pounds per MMBtu a b

Generator

SO2 Emissions Rate

NOx Emissions Rate

CO2 Emissions Rate

Hydropower

0.0

0.0

0.0

Gas-CT

0.0098

0.15

117.00

Gas-CC

0.0033

0.02

117.00

Gas-CC-CCS

0.0033

0.02

11.70

Pulverized Coal with Scrubbers (pre-1995)

0.2

0.19

210.55

Pulverized Coal with Scrubbers (post-1995)

0.1

0.08

210.55

Pulverized Coal without Scrubbers

1.11

0.19

210.55

IGCC Coal

0.0555

0.085

210.55

Coal-CCS

0.0555

0.085

21.06

Oil/Gas Steam

0.299

0.1723

137.00

Nuclear

0.0

0.0

0.0

Geothermal

0.0

0.0

0.0

Biopower

0.08

0.0

0.0

-
-

a [EPA, 2008]

-
-
-

b The assumed CO2 pollutant rate for land-fill -gas is zero, so ReEDS does not see the emissions benefits of land-fill -gas. However, ReEDS can track land-fill gas emissions and the -associated benefits as a post-processing calculation. Land-fill gas is -assumed to have negative effective carbon emissions because the -methane gas would be flared otherwise, thereby it produces the less -potent greenhouse gas.

-
-

Not all parameter data are given in this document. For those values not -included here, see the NREL ATB [NREL, 2023], or see the values in the -ReEDS repository.[25]. Financing parameters and calculations are -discussed in Capital Financing, System Costs, and Economic Metrics.

-
-
-

Storage Technologies

-

ReEDS includes three utility-scale energy storage options[26]: PSH, -batteries, and CAES. All three storage options are capable of load -shifting (arbitrage), providing planning and operating reserves, and -reducing curtailment of VRE. By default, load shifting can be done only -within a season’s representative day, but ReEDS has options to allow -load shifting across representative days while requiring a specified -fraction of charging energy to be deployed as generation in that day. -Generally, load shifting is accomplished by charging the reservoir -during inexpensive low-demand time-slices and discharging at peak times. -The nameplate capacity of storage can contribute toward planning -reserves (though at a potentially reduced rate, see Network reinforcement), and -capacity not being used for charge or discharging can be utilized to -provide any of the operating reserves products represented in ReEDS (see -Electricity System Operation and Reliability -on how reserves are differentiated in ReEDS). An energy -penalty is associated with storage to provide regulation reserves that -reflect losses due to charging and discharging. Storage is also required -to have sufficient charge to provide operating reserves in addition to -any charge already required for generation in appropriate timeslice. -Batteries are represented with durations of 2, 4, 6, 8, and 10 hours, -CAES is assumed to have a duration of 12 hours, and the PSH storage -duration is either 8, 10, or 12 hours depending on the chosen PSH supply -curve.

-

The ReEDS framework also allows for standalone thermal energy storage, -though this technology is inactive by default because its site-specific -nature makes it difficult to include in a nationwide optimization -framework. This technology is representative of chilled water and ice -storage units in buildings where, during the summer, cold water or ice -is produced during cooler hours when loads are lower and used to replace -or supplement the air conditioning during the warmer hours. Only units -for commercial buildings are considered. A supply curve for thermal -energy storage units was developed at the NERC subregions level. The -model restricts the use of thermal energy storage devices by the -regional cooling load profile, with power delivered from thermal energy -storage available only during times of high cooling load (e.g., summer -afternoons). Thermal energy storage technologies can contribute to -operating and planning reserves and reduce -curtailment.

-

Although storage is neither directly linked nor assumed co-located with -renewable energy technologies in ReEDS, it can play an important role in -reducing curtailed electricity from variable generation resources by -charging during time-slices with excess renewable generation. The -ability of storage to reduce curtailment is calculated endogenously.

-

Existing PSH totals 22 GW, and ReEDS includes the existing CAES -facility in Alabama. New PSH and CAES are location-restricted due to -hydrology and topography (for PSH) and geology (for CAES). There is also -an option to require new PSH to purchase water access from water supply -curves in order to fill new PSH reservoirs, and this constraint can add -cost and further restrict PSH deployment. In contrast, utility-scale -batteries are not restricted to any subset of -regions.

-

New PSH potential is derived from a national PSH resource assessment -described in Rosenlieb and Cohen 2022 and at -https://www.nrel.gov/gis/psh-supply-curves.html. Several PSH supply -curves are available in ReEDS, including alternative storage durations -(8, 10, or 12 hours) and alternative environmental site exclusions, -specifically whether or not new PSH reservoir construction can occur -where there are ephemeral streams as defined by the National Hydrography -Dataset. The PSH resource assessment includes site-level capital costs -calculated from a parametric model that incorporates dam, reservoir, and -other site characteristics. PSH fixed O&M costs and round-trip -efficiency are taken from Mongird et al., 2020, and PSH cost and -resource assumptions are also documented on the NREL ATB website -(www.atb.nrel.gov).

-

CAES site development costs are estimated based on the underground -geology, where domal salt is the least costly resource at $1170/kW -(22.6 GW available), bedded salt is the next most costly resource at -$1,420/kW (37.0 GW), and aquifers (porous rock) are the most costly -resource at $1,680/kW (61.6 GW) [Lazard, 2016, Veatch, 2012]. -[27] CAES requires a natural gas fuel input when supplying power -output, and its heat rate is assumed to be 4.91 MMBtu/MWh. This -additional fuel input (to the electrical power input during compression) -results in a round-trip efficiency of 125%.

-

Battery cost and performance assumptions are based on lithium-ion -battery systems, with costs taken from Cole and Frazier 2020. Low, mid, and high cost projections are available and scale with the -user-defined battery duration. In contrast to all other generator -technologies in ReEDS which have lifetimes that meet or exceed typical -model evaluation windows for book life, the battery is assumed to last -15 years. As a result, its capital cost is uprated by the ratio of a -15-year evaluation window and the evaluation window used by the run. The -batteries are assumed to have a round-trip efficiency of 85%. The -contribution of storage toward the reserve margin requirement is -discussed in Resource Adequacy. Battery storage has a representative size of -60 MW. Finally, we apply a minimum VOM of $0.01/MWh (in 2004$) to all -storage to avoid degeneracy with renewable energy -curtailment.

-
-
-

Hydrogen

-

ReEDS has the capability of modeling the use of hydrogen, both as a -form of seasonal storage to meet power system requirements and as a -clean fuel produced by the power sector for use in other -sectors.

-

In the power sector, hydrogen can be consumed as a fuel in Hydrogen -Combustion Turbines (H2-CTs). H2-CTs are comparable to commercial gas -turbines but can be fired with hydrogen [Mitsubishi, 2020, Ruth et al., 2020]. -H2-CTs are assumed to have the same heat rate and operation and -maintenance (O&M) cost as regular gas-fired combustion turbines (see -Conventional Energy Technologies) but with a 20% higher overnight capital cost, slightly -higher than the 10% value reported by Ruth et al. 2020 in order to -allow the H2-CT to be clutched and act as a synchronous generator. -Existing gas generators can be upgraded to this H2-CT technology by -paying the 20% difference in capital cost between the two -generators.

-

Power sector hydrogen use is determined by the model’s optimization; as -with natural gas plants and other fuel-based generators, weighs the -costs of investment in H2-CTs and procuring hydrogen against other -options for serving load and meeting other power system constraints. In -contrast, demand for hydrogen produced by the power sector but used -externally in other sectors is specifically exogenously as an input. -This demand is intended to capture hydrogen used in sector such as -transportation or industry and can be specified in terms of a total -national hydrogen by year.

-

The model includes a range of options for representing the production, -transport and storage or hydrogen, as well as the spatial resolution of -at which hydrogen demand is serviced. These options include: (1) as a -drop-in renewable fuel with a fixed price, (2) endogenous representation -of production with national balancing, and (3) endogenous representation -of production with zonal balancing. Each of these representations is -discussed in more detail below.

-
-

Drop-in renewable fuel

-

The first approach models hydrogen as a drop-in renewable fuel that is -available in unlimited quantity at a fixed price ($/MMBtu). The default -fuel costs for this approach are assumed to be $20/MMBtu, which is -consistent with estimates of the costs for hydrogen produced using an -electrolyzer powered by dedicated wind or PV; for example, Mahone et al. -2020 report a range of $7–35/MMBtu. This estimate also falls within -the range of current ethanol ($12/MMBtu) and biodiesel ($30/MMBtu) -prices [DOE, 2020]. It is also consistent with Hargreaves and Jones -2020 which reports $20/MMBtu for carbon-neutral biogas. As this is -the only hydrogen cost modeled with this approach, this fuel cost -represents an “all-in” cost that includes the cost of production, -delivery, and storage of hydrogen. Users can specify different -trajectories for fuel costs over time.

-

Under the drop-in renewable fuel approach, the use of curtailed -renewable energy for H2-CT fuel production is not explicitly considered; -to capture this dynamic the production of hydrogen must be endogenously -modeled in ReEDS, which is described in the next section.

-
-
-

Endogenous production with national balancing

-

In this approach hydrogen production is explicitly represented via two -pathways: electrolysis and steam methane reforming (SMR). For either -pathway, ReEDS must invest in sufficient electrolyzer or SMR capacity to -meet hydrogen demands. Table 10, Table 11, -and Table 12 summarize the cost and performance data -on the hydrogen production technologies represented in ReEDS.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 10 Cost and Performance Assumptions for Hydrogen Production Technologies. Costs are reported in $2022.

Electrolyzer

Capital Cost ($/kW)

Variable O&Ma ($/kWh)

Fixed O&M ($/kW-yr)

Electricity Use (kWh/kg)

Natural Gas Use (MMBtu/kg)

2020

1,750

0

101.9

56.1

–

2035

550

0

32.0

53.8

–

2050

550

0

25.0

51.5

–

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 11 Cost and Performance Assumptions for Hydrogen Production Technologies. Costs are reported in $2022.

SMR

Capital Cost ($/kg/day)

Variable O&M ($/kg)

Fixed O&M ($/kg/day-yr)

Electricity Use (kWh/kg)

Natural Gas Use (MMBtu/kg)

2020

649

0.087

20.9

0.88

0.192

2035

634

0.087

20.4

0.88

0.192

2050

622

0.087

20.0

0.88

0.192

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 12 Cost and Performance Assumptions for Hydrogen Production Technologies. Costs are reported in $2022.

SMR-CCS

Capital Cost ($/kg/day)

Variable O&M ($/kg)

Fixed O&M ($/kg/day-yr)

Electricity Use (kWh/kg)

Natural Gas Use (MMBtu/kg)

2020

1,408

0.089

45.3

1.9

0.192

2035

1,239

0.089

39.8

1.9

0.192

2050

1,239

0.089

39.8

1.9

0.192

-

a operation and maintenance

-

Under this representation of hydrogen, ReEDS ensures sufficient -hydrogen production to match total annual demand at a national level. -This means that hydrogen demand from H2-CTs and external sources is -represented on an annual basis, and that hydrogen can be produced in any -location or time period in the model to serve that demand. Users have -the option to apply an adder to the production of hydrogen to represent -additional costs of transporting and storing hydrogen, but these are not -explicitly represented in this formulation.

-
-
-

Endogenous production with zonal balancing, transport, and storage

-

In this approach hydrogen production is explicitly represented, but -instead of matching hydrogen supply and demand at the national level is -matched zonally in each of the model’s balancing areas. The equation -below reflects how for each region r in each time period h the model -balances hydrogen supply, which includes production (Prod), storage -withdrawals (StorOut), and transfers from neighboring regions rr -(Flow), with hydrogen demand, including storage injections (StorIn), -transfers to neighboring regions, and demand from H2CTs and other -sectors.

-
-\[\begin{split}Prod_(h,r) + StorOut_(h,r) + \sum_(rr) Flow_(h,rr,r) \\ -= StorIn_(h,r) + \sum_(rr) Flow_(h,rr,r) + H2CT_(h,r) + Exog_(h,r)\end{split}\]
-

Hydrogen demand from the power sector is attributed to balancing area -based on H2-CTs usage, whereas exogenous hydrogen demand is allocated to -balancing using regional demand fractions.

-

To store hydrogen a balancing area must invest in storage capacity. -ReEDS currently represents two forms of geological hydrogen -storage—either in salt caverns or hard rock formations—as well as the -ability to construct storage in underground pipe systems. Data on the -availability of geological storage are taken from , depicted in Fig. 27. -Because of the lack of credible estimates on available reservoir -capacity, ReEDS does not impose limits on the amount of storage that a -balancing area connected to reservoir can -build.

-

Costs of hydrogen storage are based on estimates from , shown in Fig. 28. -For geological storage ReEDS assumes $/kg based on the -economies-of-scale from constructing 2-3 caverns. To reduce model -complexity, ReEDS assumes that each balancing area can only build the -cheapest storage option that it has available to -it.

-

ReEDS also allows for the modeling of interzonal hydrogen transport. -Transport requires the construction of hydrogen pipelines, and the model -assumes costs estimates based on from the H2 SERA model[28]. Modeling -hydrogen transport in ReEDS is an experimental feature, and because this -feature adds significant runtime the model includes the option for -modeling zonal balancing with transport disabled or a fixed $/kg -hydrogen transport cost.

-
-_images/hydrogen-storage-availability.png -
-

Fig. 27 Assumed availability of geological hydrogen storage -reservoirs. Data are from Lord et al. 2014.

-
-
-
-_images/hydrogen-storage-cost-estimate.png -
-

Fig. 28 Cost estimates for hydrogen storage. Data taken from Papadias and Ahluwalia 2021.

-
-
-
-
-
-

Direct Air Capture

-

The model can also procure negative emissions by removing and storing -CO2 from the atmosphere using direct air capture (DAC). For -this study, DAC in the ReEDS model is a sorbent design that uses only -electricity as an input, with an energy consumption of 3.72 MWh per -tonne of CO2 removed. Overnight capital costs are assumed to -be $1,932 per tonne-year capture capacity, with annual fixed O&M costs -of 4.6% of the capital costs and nonfuel variable O&M cost of $21 per -tonne.

-
-
-

CO2 Transport and Storage

-

ReEDS has the option to use a detailed CO2 network representation that, -when turned on, requires all CO2 captured at CCS facilities (gen-CCS, -SMR-CCS, and DAC) to be transported via liquid CO2 pipelines and -sequestered in underground saline aquifers. “Trunk” pipelines can be -built between BA transmission endpoints and “spur” pipelines can be -build from BA transmission endpoints to the edge of any nearby (<200 -mi) aquifer. These pipelines can be assigned different capital and FO&M -costs, and the several hundred saline aquifers identified by NETL have -$/tonne breakeven costs that represent the cost of sequestering CO2 in -the aquifer (i.e. permitting, injection facilities, monitoring, and a -100-year trust fund for maintenance).

-

The network representation includes only saline aquifers with a -reservoir cost of <$20/tonne at a 90% capacity factor. The explicit -representation is turned off by default.

-
-
-

Capital Stock

-
-

Initial Capital Stock, Prescribed Builds, and Restrictions

-

Existing electricity generation capacity is taken from the EIA NEMS -unit database [EIA, 2023]. Units are mapped to ReEDS technologies based -on a combination of fuel source and prime mover of the generation -technology. Units of the same technology type within a region can be -aggregated or represented individually.[29] If they are aggregated, the -aggregation is done by clustering the units based on heat -rates.

-

The binning structure is designed flexibly such that users can choose -the appropriate levels of model fidelity and computational speed for -each application. Historical units are binned using a k-means clustering -algorithm for each BA and technology category (e.g., coal with or -without SO2 scrubbers, and natural gas combined cycle) -combination. The user specifies a maximum number of bins and a minimum -deviation across unit heat rates. Any two plants are eligible to form -separate bins if the difference between their heat rates is greater than -the minimum deviation parameter. The number of bins formed is then equal -to the smaller of the maximum bin number parameter and the number of -units after applying the minimum deviation criteria. For each bin, the -assigned heat rate is equal to the capacity-weighted average of the heat -rates for the units inside the bin. An illustrative example of the -results is depicted for two BAs in Fig. 29, assuming a maximum of -seven bins and minimum deviation of 50 BTU per kWh. The horizontal axis -corresponds to the heat rate for a given power plant unit from the NEMS -database, while the vertical axis corresponds to the heat rate each bin -is assigned in ReEDS. Points on the 45-degree line illustrate units for -which the ReEDS heat rate is the same as the NEMS heat rate. The more -tightly clustered the points are around this line, the less the model -will suffer from aggregation bias. The figure illustrates that, in -general, the fewer the number of units in a given technology category -(in this example, nuclear and scrubbed coal), the closer the binned heat -rates are to the actual heat rates.

-
-_images/capacity-binning-example.png -
-

Fig. 29 Example of capacity binning results for two BAs

-
-
-

Hydropower has additional subcategories to differentiate -dispatchability as discussed in Hydropower. In addition, any plants -that are listed as under construction become prescribed builds. In other -words, ReEDS builds any under-construction units, with the units coming -online in the anticipated online year listed in -the database.

-

For wind technologies, near-term regional growth restrictions reflect -the difficulty of immediately scaling the wind industry. Specifically, -wind plant construction through the 2020 solve year is limited to plants -that are planned to be installed before the end of 2020. After 2020, no -wind capacity limits are implemented.

-
-
-

Retirements

-

Renewable energy generator and battery retirements are (by -default)[30] based on assumed lifetimes. Once a generator has reached -its lifetime, it is retired. Renewable energy and battery lifetime -assumptions are shown in Table 13. -When renewable energy capacity is retired, the resource -associated with that capacity is made available, and ReEDS can choose to -rebuild a renewable energy generator using the newly available resource, -without the need to rebuild the grid interconnection infrastructure. A -consequence of this assumption is that retired renewable capacity can be -replaced without incurring interconnection costs and, with all other -considerations being equal, re-powered or re-built renewable capacity -has lower cost than new “green-field” capacity of the same type.[31] -One exception to this procedure is hydropower, which due to assumed -non-power requirements is never retired unless there is an announced -hydropower capacity retirement listed in the NEMS unit -database.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 13 Lifetimes of Renewable Energy Generators and Batteries

Technology

Lifetime (Years)

Source

Land-based Wind

30

LBNL Survey [Wiser and Bolinger, 2019]

Offshore Wind

30

LBNL Survey [Wiser and Bolinger, 2019]

Solar Photovoltaic

30

SunShot Vision [DOE, 2012]

Concentrating Solar Power

30

SunShot Vision [DOE, 2012]

Geothermal

30

Renewable Electricity Futures Study, Vol. 1 [Mai et al., 2012]

Hydropower

100

Hydropower Vision [DOE, 2016]

Biopower

50

ABB 2018

Marine Hydrokinetic

20

Previsic et al. 2012

Battery

15

Cole and Frazier 2020

-

Retirements of existing conventional energy generators in ReEDS are -primarily a function of announced retirement dates and -technology-specific estimated lifetimes, taken from the NEMS plant -database. Estimated retirement dates depend on the size of the unit, and -the most common lifetimes are shown in Table 14 -for plants that are smaller or larger than 100 MW. Nuclear plants are assumed to have a mix -of 60- and 80-year lifetimes as explained below. All conventional -generators that are economically built in ReEDS are given the lifetime -of plants greater than 100 MW, and these lifetimes are used as necessary -when the solution period extends beyond 2050.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 14 Lifetimes of Conventional Energy Generators a

Technology

Lifetime less than 100 MW (Years)

Lifetime greater or equal to 100 MW (Years)

Gas Combustion Turbine

50

50

Gas Combined Cycle and CCS

60

60

Coal, all techs, including cofired

65

75

Oil-Gas-Steam

50

75

Compressed-Air Energy Storage

100

100

-

a [ABB, 2018]

-

In addition to age-based retirements, ReEDS includes the option to -endogenously retire technologies (this option is turned on by default). -When doing endogenous retirements, ReEDS is trading off the value -provided to the system by the plant versus the costs incurred by keeping -the plant online. If the value is not sufficient to recover the costs, -ReEDS will choose to retire the plant. ReEDS includes a “retirement -friction” parameter that allows a plant to stay online as long as it is -recovering at least a portion of its fixed operating costs. For example, -if this retirement friction parameter is set to 0.5, then a plant will -only retire if it does not recover at least half of its fixed costs. -Additionally, ReEDS includes a minimum retirement age for existing -conventional plants of 20 years, meaning that a conventional plant is -not allowed to be endogenously retired until it is at least 20 years -old.

-

ReEDS includes four exogenous nuclear retirement scenario settings. The -four settings are defined by first dividing the currently operating -reactors into two bins. Any plants participating in a restructured -market and all single-reactor plants are assigned to Bin 1. The -remaining plants, which are all multi-reactor plants in a traditional -regulated environment, are assigned to Bin 2. The only exception to -these categorizations is that plants that have announced their intent to -seek a second operating license renewal from the Nuclear Regulatory -Commission (NRC) are included in Bin 2. Table 15 breaks down the bins -and shows total capacity in each case. These bins are categorizations -that reflect the current discussion pointing to more economic pressure -on restructured and single-reactor units [Haratyk, 2017, Nicholas Steckler, 2017].

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 15 Amount of Nuclear Power Plant Capacity (in GW) in Each Bin

Plant Category

Bin 1

Bin 2

Restructured, Single Reactor

8.7

—

Restructured, Multi Reactor

27.5

2.0a

Regulated, Single Reactor

15.7

—

Regulated, Multi Reactor

—

42.1

Total

51.9

44.1

-

a The Peach Bottom plant (2.0 GW) has announced its intent -to seek a second license renewal. Therefore, it is moved from Bin 1 to -Bin 2 even though it is in a restructured -market.

-

The four nuclear retirement scenarios are: (1) Early Retirement, (2) -60-Year Lifetime, (3) Mid-Case (mix of 60 and 80-year lifetimes), and -(4) 80-Year Lifetime (see Table 16). The Early Retirement scenario -retires nuclear capacity in Bin 1 when its lifetime reaches 50 years, -and capacity in Bin 2 at 60 years. The 50-year lifetime emulates the -retirements of recent plants that did have a renewed operating license -but retired before they reached the end of their license. The 60-Year -Lifetime scenario retires all plants at 60 years, which would be at the -end of their first operating license renewal. The 80-Year Lifetime -scenario retires all plants at 80 years, simulating a successful -completion of a second operating license renewal from the NRC. The -Mid-Case scenario serves as the default setting in ReEDS and retires -capacity in Bin 1 at 60 years and capacity in Bin 2 at 80 -years.

- - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 16 Nuclear Power Plant Lifetime for Each Scenario by Bin (years)

Scenario Name

Bin 1

Bin 2

Early Retirement

50

60

60-Year Lifetime

60

60

Mid-Case

60

80

80-Year Lifetime

80

80

-
-
-

Growth Constraints

-

The ReEDS model can represent either absolute growth constraints (e.g., -wind builds cannot exceed 100 GW per year) or relative growth -constraints (e.g., wind capacity cannot grow by more than 50% per year). -The growth constraints are designed to target a broader technology group -as opposed to the individual classes of wind, PV, and CSP; as an -example, the growth constraint would restrict the builds of all wind -technologies and classes and not just a specific class. The default -values for the absolute growth constraints are the highest -year-over-year changes of each technology type’s capacity from 2010 to -2020 (computed by appending the necessary EIA AEOs). For CSP, the -default absolute growth limit is assigned the same as PV, as it has not -seen the capacity buildout as PV or wind have as of 2020. The relative -growth limits are applied on a state-level and are based on historical -compounded annual growth rate estimates observed for solar PV from -2012-2022. The penalties are assessed in ReEDS based on the maximum -previous growth observed in the model. For example, if a state -experienced 1,000 MW of new capacity in 2024 and 500 MW of new capacity -in 2025, then the growth penalty would be applied using the 1,000 MW -value even though it is older.

-
-_images/annual-growth-penalties.png -
-

Fig. 30 Annual growth penalties applied on a state level in ReEDS when the relative growth penalties are enabled.

-
-
-

ReEDS also includes minimum growth sizes, specified by technology type. -Those minimum growth sizes are shown in Table 17 and are generally based -on representative plant sizes.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 17 Minimum growth size for each technology group. Growth below this level will never incur a rowth penalty regardless of starting capacity.

Technology group

Minimum growth size before a penalty is incurred (MW)

CCS

300

CSP

100

Uncontrolled Natural Gas

300

Hydrogen

100

Nuclear

600

Solar PV

100

Storage

100

Wind-Offshore

600

Wind-Onshore

100

-
-
-
-

Regional Parameter Variations and Adjustments

-

For most generation technologies, regional cost multipliers are applied -to reflect variations in installation costs across the United States -(see Fig. 31). These regional multipliers are applied to the base -overnight capital cost presented in earlier sections. The regional -multipliers are technology-specific and are derived primarily from the -EIA/Leidos Engineering report [EIA, 2016] that is the source of capital -cost assumptions for the NEMS model. While the regional costs presented -in the EIA/Leidos Engineering report are based on particular cities, the -regional multipliers for ReEDS are calculated by interpolating between -these cities and using the average value over the ReEDS regions for each -technology. For technologies such as CSP that are not included in the -newer report, we rely on the older EIA/Science Applications -International Corporation report [EIA, 2013].

-
-_images/regional-capital-cost-multipliers.png -
-

Fig. 31 Maps of regional capital cost multipliers for the various technology types

-
-
-

Regions shown in white for offshore wind indicate that there is not -offshore wind resource in that region.

-
-
-
-

Fuel Prices

-

Natural gas, coal, and uranium prices in ReEDS are based on the most -recent AEO. Coal prices are provided for each of the nine EIA census -divisions. Low and high natural gas price alternatives are taken from -the Low and High Oil and Gas Resource and Technology scenarios. ReEDS -includes only a single national uranium price trajectory. Base fuel -price trajectories are shown in Fig. 32 for -the AEO2023 [EIA, 2023]. -Biomass fuel prices are represented using supply curves with five bins -in each region. The costs and resource availability are based on the -U.S. Billion-Ton Update study [DOE, 2011]. Biomass costs range from -$2.02/MMBtu to $19.43/MMBtu (in 2018$).

-
-_images/input-fuel-price-assumptions.png -
-

Fig. 32 Input fuel price assumptions.

-
-
-

Natural gas fuel prices are adjusted by the model as explained -below.

-

Coal and uranium are assumed to be perfectly inelastic; the price is -predetermined and insensitive to the ReEDS demand for the fuel. With -natural gas, however, the price and demand are linked. Actual natural -gas prices in ReEDS are based on the AEO scenario prices but are not -exactly the same; instead, they are price-responsive to ReEDS natural -gas demand. In each year, each census division is characterized by a -price-demand “set point” taken from the AEO Reference scenario but also -by two elasticity coefficients: regional (βr) and national -(βn) elasticity coefficients for the rate of regional price -change with respect to (1) the change in the regional gas demand from -its set-point and (2) the overall change in the national gas demand from -the national price-demand set point respectively. The set of regional -and national elasticity coefficients are developed through a linear -regression analysis across an ensemble of AEO -scenarios[32],[33] to estimate changes in fuel prices -driven solely by electric sector natural gas demand (as described in -Logan et al. 2013 and Cole, Medlock III, and Jani 2016, though the -coefficients have since been updated for the latest AEO data). Though -there is no explicit representation of natural gas demand beyond the -electricity sector, the regional supply curves reflect natural gas -resource, infrastructure, and nonelectric sector demand assumptions -embedded within the AEO modeling. For details, see the Natural Gas -Supply Curves section of the appendix.

-

ReEDS includes options for other types of fuel supply curve -representations. Supply curves can be national-only, census-region-only, -or static. With the national-only supply curve, there are census -division multipliers to adjust prices across the census divisions. In -the static case, fuel prices are not responsive to -demand.

-

The natural gas fuel prices also include a seasonal price adjustor, -making winter prices higher than the natural gas prices seen during the -other seasons of the year. For details, see the Seasonal Natural Gas -Price Adjustments section of the appendix.

-
-
-

Power System Water Use

-

The 2020 ReEDS version includes an updated representation of power -system water use that improves upon the formulation described in the -ReEDS version 2019 documentation [Brown et al., 2020] as well as [Macknick et al., 2015]. Though inactive by default to limit computational -complexity, users can activate a power system water use formulation that -characterizes the existing fleet and new generation investments by both -their cooling technology and water source type, if applicable. Cooling -technology affects power system cost and performance, and water use is -constrained using technology withdrawal and consumption rates in -conjunction with water availability and cost data from [Tidwell et al., 2018]. -The rest of this section describes each component of this formulation.

-
-

Existing Fleet Cooling Technology and Water Source

-

Thermal generating technologies in ReEDS are differentiated by the -following cooling technology types: once-through, recirculating, pond, -and dry(air)-cooled. Cooling technologies determine water withdrawal and -consumption rates as well as capital cost, operating cost, and heat rate -as described in Cooling System Cost and Performance. -Generating technologies without cooling -systems are designated as having no cooling; however, these technologies -can still be assigned water use rates to account for processes such as -evaporation from hydropower reservoirs or cleaning PV arrays. All -power-cooling technology combinations (including water-using -technologies without cooling) are also assigned one of the following six -water source types included in the model: fresh surface water that is -currently appropriated, unassigned/unappropriated fresh surface water, -fresh groundwater, brackish or saline groundwater, saline surface water, -and wastewater treatment facility effluent. These water source types -align with the water supply curves described in Water Availability and Cost. -Representing both cooling technology and water source allows a -high-fidelity representation of water source-sink relationships and -constraints.

-

Cooling technology and water source of the baseline 2010 generation -fleet and subsequent prescribed builds is assigned using several data -sources mapped to the unit database that exogenously defines capital -stock in ReEDS. The EIA NEMS unit database is -first merged with the 2018 version of the EIA thermoelectric cooling -water dataset [USEIA, 2018]. Cooling technology assignment uses the “860 -Cooling Type 1” field where possible, followed by the “860 Cooling Type -2” and finally “923 Cooling Type”. Hybrid cooling systems are assigned -as recirculating except for hybrid dry/induced draft systems, which are -assigned as dry cooling. Any remaining gaps in cooling technology -assignment are filled using the UCS EW3 Energy-Water Database -[Union of Concerned Scientists, 2012]. This procedure -enables annual updates through yearly reporting of EIA thermoelectric cooling -water data. Thermal units with no available information on cooling -technology are assigned recirculating cooling by default.

-

Water source in ReEDS is assigned where possible using the “Water Type” -and “Water Source” fields in the EIA cooling water dataset and then -supplemented using raw EIA Form 860 plant-level data [Form EIA-860 Detailed Data with Previous Form Data (EIA-860A/860B), 2018]. -When the water source is unclear from the type and source, the “Water Source -Name” is used to help discern additional water source types and -determine which units use municipal water. Municipal water is treated as -an intermediary of the ultimate water source, which is defined using -U.S. Geological Survey (USGS) water use data for 2015 that includes -water sources for municipal use [Dieter and Linsey, 2017]. Generating -units that use municipal water are assigned the water source that -supplies the majority of municipal water use in the USGS database. The -UCS EW3 database is also used to assign water sources unavailable in EIA -data [Union of Concerned Scientists, 2012]. Remaining unknown water -source types are assigned from USGS data using the majority water source -for the power sector, further differentiated by once-through or -recirculating cooling. If there is no USGS data for power sector water -use in the relevant county, the majority source of overall water use is -applied.

-

Beyond this multi-database approach to assign cooling technology and -water source, water source must be reassigned for some prescribed new -builds if the water availability described in Water Availability and Cost is -insufficient for that unit’s water needs. For these instances, a final -adjustment procedure that temporary relaxes water use constraints is -used to identify these units and manually modify water source types to -use the BA’s least-cost water source with sufficient availability for -the prescribed unit.

-
-
-

Cooling System Cost and Performance

-

Alternative cooling technologies are represented for the following -power system types:

-
    -

  • Coal: all types, including coal with CCS and biomass-cofired -coal

    • -

  • Gas-CC: including Gas-CC with CCS

    • -

  • Oil-Gas-Steam: also allows “no cooling” to represent capacity that does not use thermal cooling water (e.g., internal combustion engines)

    • -

  • Nuclear

    • -

  • Biopower: also allows “no cooling” to represent capacity that does not use thermal cooling water

    • -

  • Landfill Gas: also allows “no cooling” to represent capacity that does not use thermal cooling water

    • -

  • CSP: all thermal storage durations and resource classes

    • -
-

Water use is also characterized and constrained for hydropower, Gas-CT, geothermal, and distributed rooftop PV technologies, albeit without cooling technology disaggregation. This construct allows -total power sector water use to be estimated and could be expanded upon -in later model versions, particularly for geothermal technologies.

-

Some power-cooling technology pairs are also prohibited for new -construction by default. New, non-prescribed capacity for all -technologies cannot use once-through cooling due to U.S. Environmental -Protection Agency (EPA) regulations and industry trends [EPA, 2014]. In addition, all new non-prescribed capacity cannot -choose pond cooling because pond cooling designs are site-dependent, and -ReEDS does not have sufficient detail to characterize location-specific -cooling pond design. The model also prevents new nuclear and coal-CCS -capacity from using dry cooling because existing designs have very high -cooling requirements where dry cooling is considered -impractical.

-

Cooling technology affects capital cost, variable operating cost, heat -rate, water withdrawal rate, and water consumption rate. Cost and heat -rate are adjusted for cooling technology by multiplying baseline -technology data by the factors in Table 18, -Table 19, and Table 20, -where recirculating cooling is the reference cooling technology [Macknick et al., 2012]. -Typically, once-through cooling systems are less expensive -and allow higher overall thermal efficiency, while dry cooling is more -expensive and results in lower net thermal efficiency. Pond cooling -systems are typically intermediate to once-through and recirculating -cooling, but the model uses once-through cooling characteristics as an -approximation because actual cost and performance is site-specific. No -data exists for some power-cooling technology combinations (Gas-CC-CCS + -once-through and pond; Coal-CCS + pond, CSP + once-through and pond) -because no existing or planned units of those types -exist.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 18 Capital Cost Multipliers for Power-Cooling Technology Combinations

Power Technology

Once-Through

Recirculating

Dry

Cooling Pond

Gas-CC

0.978

1.000

1.102

0.978

Gas-CC-CCS

n/a

1.000

1.075

n/a

Pulverized coal with scrubbers (pre-1995)

0.981

1.000

1.045

0.981

Pulverized coal without scrubbers

0.981

1.000

1.045

0.981

Pulverized coal with scrubbers (post-1995)

0.981

1.000

1.045

0.981

IGCC coal

0.988

1.000

1.033

0.988

Coal-CCS

0.982

1.000

n/a

n/a

Oil/gas steam

0.981

1.000

1.045

0.981

Nuclear

0.981

1.000

n/a

0.981

Biopower

0.981

1.000

1.045

0.981

Cofired coal (pre-1995)

0.981

1.000

1.045

0.981

Cofired coal (post-1995)

0.981

1.000

1.045

0.981

CSP

n/a

1.000

1.050

n/a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 19 Variable Operations and Maintenance Cost Multipliers for Power-Cooling Technology Combinations

Power Technology

Once-Through

Recirculating

Dry

Cooling Pond

Gas-CC

0.996

1.000

1.021

0.996

Gas-CC-CCS

n/a

1.000

1.107

n/a

Pulverized coal with scrubbers (pre-1995)

0.989

1.000

1.051

0.989

Pulverized coal without scrubbers

0.989

1.000

1.051

0.989

Pulverized coal without scrubbers (post-1995)

0.989

1.000

1.051

0.989

IGCC coal

0.996

1.000

1.021

0.996

Coal-CCS

0.993

1.000

n/a

n/a

Oil/gas steam

0.989

1.000

1.051

0.989

Nuclear

0.989

1.000

n/a

0.989

Biopower

0.989

1.000

1.051

0.989

Cofired coal (pre-1995)

0.989

1.000

1.051

0.989

Cofired coal (post-1995)

0.989

1.000

1.051

0.989

CSP

n/a

1.000

1.050

n/a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 20 Heat Rate Multipliers for Power-Cooling Technology Combinations

Power Technology

Once-Through

Recirculating

Dry

Cooling Pond

Gas-CC

0.980

1.000

1.050

0.980

Gas-CC-CCS

n/a

1.000

1.075

n/a

Pulverized coal with scrubbers (pre-1995)

0.985

1.000

1.050

0.985

Pulverized coal without scrubbers

0.985

1.000

1.050

0.985

Pulverized coal with scrubbers (post-1995)

0.985

1.000

1.050

0.985

IGCC Coal

0.980

1.000

1.050

0.980

Coal-CCS

0.800

1.000

n/a

n/a

Oil/Gas Steam

0.985

1.000

1.050

0.985

Nuclear

0.973

1.000

n/a

0.973

Biopower

0.985

1.000

1.050

0.985

Cofired Coal (pre-1995)

0.985

1.000

1.050

0.985

Cofired Coal (post-1995)

0.985

1.000

1.050

0.985

CSP

n/a

1.000

1.000a

n/a

-

a There are currently no data to inform a heat rate -multiplier for CSP.

-

More efficient-less expensive cooling technologies typically require -greater volumes of water withdrawal and consumption, creating a tradeoff -between cost and water use. Withdrawal and consumption rates for -power-cooling technology combinations are shown in Table 21 and Table 22 -[Macknick et al., 2012]. Table 23 includes water use rates for power -technologies that are not differentiated by cooling technology; aside -from geothermal these values are negligible but could be modified by the -user if desired. Further, the model can accommodate BA-specific -withdrawal and consumption rates, so the values shown below could be -made regionally heterogeneous with sufficient data. Water withdrawal and -consumption rates coupled with assignment of water source type allow -ReEDS to characterize power system water demand for each technology, BA, -and water source combination.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 21 Water Withdrawal Rates for Power-Cooling Technology Combinations (gal/MWh)

Power Technology

Once-Through

Recirculating

Dry

Cooling Pond

Gas-CC

11,380

255

2

5950

Gas-CC-CCS

n/a

506

n/a

n/a

Pulverized coal with scrubbers (pre-1995)

36,350

1,005

0

12,225

Pulverized coal without scrubbers

36,350

1,005

0

12,225

Pulverized coal with scrubbers (post-1995)

27,088

587

0

17,914

IGCC Coal

18,136

393

0

9,635

Coal-CCS

56,483

1,224

n/a

n/a

Oil/gas steam

35,000

1,203

0

5,950

Nuclear

44,350

1,101

n/a

7,050

Biopower

35,000

878

0

450

Cofired coal (pre-1995)

35,000

878

0

450

Cofired coal (post-1995)

35,000

878

0

450

CSP

n/a

786

26

n/a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 22 Water Consumption Rates for Power-Cooling Technology Combinations (gal/MWh)

Power Technology

Once-Through

Recirculating

Dry

Cooling Pond

Gas-CC

100

205

2

240

Gas-CC-CCS

n/a

378

n/a

n/a

Pulverized coal with scrubbers (pre-1995)

250

687

0

545

Pulverized coal without scrubbers

250

687

0

545

Pulverized coal with scrubbers (post-1995)

113

479

0

545

IGCC coal

90

380

0

32

Coal-CCS

217

921

n/a

n/a

Oil/gas steam

240

826

0

240

Nuclear

269

672

n/a

610

Biopower

300

553

0

390

Cofired coal (pre-1995)

300

553

0

390

Cofired coal (post-1995)

300

553

0

390

CSP

n/a

786

26

n/a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 23 Water withdrawal and consumption rates for technologies that are undifferentiated by cooling technology (gal/MWh)

Power Technology

Withdrawal Rate

Consumption Rate

Hydropower

1

1

Gas-CT

1

1

Geothermal

40

40

Landfill-Gas

1

1

Distributed rooftop PV

1

1

-
-
-

Water Availability and Cost

-

All generating capacity that exists in a given model year is required -to have access to water if that technology uses water. The quantity of -required water access is defined conservatively to ensure sufficient -water is available to generate at maximum power output during the -expected annual low water flow condition. To align with annualized water -availability data, this requirement is formulated as the annual volume -of water needed to operate continuously at maximum output for the entire -year (100% capacity factor), i.e., the product of generating capacity -(MW), water use rate (gal/MWh), and 8760 hours per year. For capacity -that uses surface water, requirements are based on the water consumption -rate to account for the return of most withdrawn water directly to the -water source at the site of withdrawal. For all other water sources, -water access requirements are based on withdrawal rates because these -water types (e.g., groundwater, wastewater effluent) are not generally -returned to the site of withdrawal.

-

Generating capacity in the initial 2010 model year is assumed to have -secured sufficient water access prior to 2010. However, any new -prescribed or optimized investments must procure water access from a -power sector water availability supply curve developed by Sandia -National Laboratories [Tidwell et al., 2018]. For use in ReEDS, water -availability and cost are aggregated to the BA resolution for each of -five water source types: fresh surface water that is currently -appropriated, unassigned/unappropriated fresh surface water, fresh -groundwater, brackish or saline groundwater, and wastewater treatment -facility effluent. Saline surface water is available to -existing capacity that currently uses it, but this water source is -assumed unavailable to new capacity due to current regulatory -constraints and industry expectations [EPA, 2014]. -Tidwell et al. 2018 use a unique resource assessment and costing methodology -for each water source type, based on technical and legal considerations. -Costs include both capital and annualized operating costs associated -with each water source. Unassigned/unappropriated fresh surface water is -assumed to have negligible access cost, and costs typically increase in -the order of fresh groundwater, appropriated fresh surface water, -wastewater, and brackish/saline groundwater. Appropriated water is only -relevant to western U.S. water law, so there is no appropriated water in -the east, and many western regions lack unappropriated water (i.e., 100% -of total water is appropriated).

-

When capacity retires, its water access is automatically available to -any new capacity at the cost associated with the capacity’s water source -and region. For the initial 2010 fleet, all capacity that uses fresh -surface water is designated as using the “appropriated fresh surface -water” category so that retired water access is given the cost of other -appropriated water in that region. For the eastern U.S. where water -appropriation is inapplicable, retired fresh surface water access is -assigned a small nominal cost to avoid over procurement of water in the -model. This structure implies that any water access owned by the power -sector remains in the power sector and that increased competition does -not affect water supply or cost. Scenario analysis and future model -development could explore this assumption in greater -detail.

-

Similar to retirements, changes in water needs due to upgrades or -refurbishments are also accounted for in the water access -requirement.

-
-_images/water-availability-and-cost.png -
-

Fig. 33 Water availability and cost for each water type in each ReEDS balancing area.

-
-
-
-
-

Water Constraints

-

Several model constraints govern the ReEDS power sector water use -formulation. Water withdrawal and consumption quantities are tracked for -each power technology, cooling technology, water source, power -technology vintage, BA, timeslice, and year, providing high resolution -with which to examine power sector water use. Separately, water access -requirements are related explicitly to the capacity available for each -power technology, cooling technology, water source, power technology -vintage, BA, and year based on either the withdrawal or consumption rate -as described in Water Availability and Cost. This water access is then limited by the -total access available for each water source and region as defined by -the water allocation in 2010 and the supply available to post-2010 -capacity.

-

Quantities of water used for each power technology, cooling technology, -water source, power technology vintage, and BA are then constrained -within each season based on the seasonal allocation of available water -access. Water access must be purchased from the water availability -supply curve before water can be used. Hydrology data is used to define -the seasonal allocation of unassigned/unappropriated fresh surface water -[Macknick et al., 2015], and all other water types are assumed -available uniformly throughout the year. Additional detail on seasonal -water allocation and the potential for changes over time requires -additional data, but the framework generally allows the capability for -incentivizing water sources that are more available when electricity -demands are higher.

-
-
-
-

Transmission

-

ReEDS considers two categories of transmission: “local interconnection” of generation -resources within the 134 model zones, and “interzonal” or -“long-distance” transmission between the model zones. These two -categories of transmission share underlying cost data but are -represented differently within the model. We begin with a discussion of -transmission costs, then describe the separate representations of -“interconnection” and “long-distance” transmission within ReEDS.

-
-

Transmission costs

-

Estimated costs for transmission lines are generated by defining a -high-geographic-resolution cost surface, then utilizing a -least-cost-path algorithm to identify a representative transmission line -path between two points [Lopez et al., 2024]. The final $/MW cost for a -particular route is then given by the integrated $/MW-mile values for -the cost surface points traversed by the least-cost -route.

-

Base voltage-dependent $/MW-mile transmission costs are taken from -four sources: Southern California Edison for CAISO and the Northeast, -WECC/TEPPC for non-CAISO areas in the Western Interconnection, MISO for -the Midwest, and a representative utility for the Southeast. These base -transmission costs are shown on the left side of Fig. 34. Cost -multipliers based on terrain type (hilly, with 2% ≤ land slope < 8%, -and mountainous, with 8% ≤ land slope) and land class (pasture/farmland, -wetland, suburban, urban, and forest) are taken from the same four -sources. A separate 90m-resolution CONUS dataset of terrain and land -classes is then combined with the base transmission costs, terrain -multipliers, and land class multipliers to generate the cost surface -used in the least-cost-path routing algorithm.

-
-_images/transmission-cost-input-data.png -
-

Fig. 34 Overview of transmission cost input data used in reV model calculations, used to generate ReEDS model inputs.

-
-
-

All transmission also incurs FOM costs, which are approximated as 1.5% -of the upfront capital cost per year.

-
-
-

Local generator interconnection

-

There are three components of local generator interconnection -represented in ReEDS: geographically resolved spur lines and substation -upgrades, geographically resolved reinforcement of the existing -transmission network, and a geographically independent cost adder for -all technologies.

-
-

Spur lines and substation upgrades

-

Spur lines represent short-distance transmission built to connect new -wind and solar generation capacity to a “point of interconnection” (POI) -on the existing transmission system. For a given wind/solar site (the -~50,000 reV supply curve points discussed above), substations within the -same state are considered as possible POIs. Least-cost paths are -calculated to all candidate substations, and the substation with the -lowest resulting path-dependent spur-line cost is taken as the POI for -that wind/solar site. An appropriate spur-line voltage is chosen based -on the available wind or solar capacity at that site, with lower -available capacity leading to a lower spur-line voltage and a higher -associated $/MW-mile cost. The cost of upgrading the POI substation is -included in the spur-line cost. Additional sources and details are -provided by Lopez et al 2023.

-
-
-

Network reinforcement

-

Network reinforcement represents upgrades to the existing transmission -network required to avoid congestion when moving power from the POI to -load centers. It is intended to represent the costs associated with -interconnection queues, which represent a major bottleneck for the -deployment of new wind and solar in the US. We estimate network -reinforcement costs by tracing a path along existing transmission lines -from each substation POI to each zone “center” within the same state; -the zone center is usually taken as the largest population center in the -model zone, but is sometimes (for zones without large urban centers) -assigned to a high-voltage substation within the zone. A cost for each -reinforcement route is calculated using the cost surface described in -Transmission costs, with capex costs multiplied by 50% to represent the lower -cost for reconductoring compared to greenfield transmission -construction. The single lowest-cost route for each POI is then -selected; the associated reinforcement cost \$/MW] and transmission -distance \MW-miles] are incurred for every MW of new wind/solar -capacity added at all reV sites associated with that -POI.[34]

-

Fig. 35 illustrates the concepts of spur lines and reinforcement -lines, and Fig. 36 shows the resulting distribution of interconnection -costs for land-based wind and utility-scale PV under the three siting -regimes. Fig. 37 and Fig. 38 show maps of the estimated spur-line -costs, reinforcement costs, total interconnection costs, and total -supply curve costs (including land-cost adders) for utility-scale PV and -land-based wind under reference-access siting assumptions.

-
-_images/local-generation-interconnection-components.png -
-

Fig. 35 Illustration of local generation interconnection components.

-
-
-
-_images/interconnection-cost-distribution.png -
-

Fig. 36 Interconnection cost distribution for land-based wind (blue) and utility-scale PV (orange) under different siting assumptions.

-
-
-
-_images/utility-scale-pv-costs.png -
-

Fig. 37 Supply-curve costs for utility-scale PV with reference-access siting.

-
-
-
-_images/land-based-wind-costs.png -
-

Fig. 38 Supply-curve costs for land-based wind with reference-access siting.

-
-
-
-
-

Intra-zone transmission cost adder for net increases in generation capacity

-

In addition to the interconnection costs described above, we also apply -a flat intra-zone transmission cost adder of $100/kW to net increases -in generation and AC/DC converter capacity within each model zone. This -value is taken from historical interconnection costs for fossil gas -capacity as reported in Seel et al. 2023 and is taken to represent a -“floor” for network upgrades that are required even if new capacity is -added at the optimal location (assuming that past additions of fossil -capacity have been placed to minimize interconnection costs). The -$100/kW adder is subtracted from the reinforcement cost applied to wind -and solar to avoid double counting. As we assume that new generation -capacity will reuse the network infrastructure from retiring capacity, -the intra-zone transmission cost adder is only applied to net -increases in generation capacity.

-
-
-
-

Interzonal transmission

-
    -

  • High level

    -
      -

    • Pipe and bubble / transport model

      • -

    • Distribution losses

      • -
    -
    • -
-
-

Existing transmission capacity

-
-_images/ac-transmission-capacity.png -
-

Fig. 39 Existing AC transmission capacity in ReEDS.

-
-
-

Short description of ITL paper

-

The transmission network in ReEDS is a -synthetic network developed from nodal data assembled as part of the -North American Renewable Integration Study (NARIS) [37]. This dataset -relies on nodal transmission models developed for the Eastern, Western, -and ERCOT interconnections under the guidance of the North American -Reliability Corporation (NERC) and includes ~56,000 buses, ~94,000 -transmission lines, and ~37,000 transformers. Capacity expansion models, -such as ReEDS, typically use zonal representation to remain tractable, -forgoing the modeling of individual generation, consumption, or -transmission assets and instead grouping them into zones which are -treated as copper plates. Assigning generation and demand units to their -respective zones is intuitive, however deriving the transmission -topology from the resolved nodal data is more involved than aggregating -steady state rated capacity across zonal interfaces due to the physics -of electrical power flow in meshed networks. In [38] the authors -propose a method for estimating the interface transfer limits between -zones from nodal transmission data utilizing a DC power flow -approximation. In this approach two independent optimizations are -performed to maximize the sum of flows in the forward direction on the -transmission lines crossing the interface and to minimize the sum of -flows in the reverse direction crossing the interface. The power flow is -constrained by the line ratings as described in -(5).

-
-\[-k(l) \le F(l) \le k(l) \]
-

(5)

-

The relationship between line flows and bus injections or withdrawals -is dictated by the power transfer distribution factor (PTDF) matrix -described in (6). The PTDF relates the change in transaction amount -(amount of power injected at one zone and withdrawn in another zone) to -the change in power flow on a line. For instance, \(_{}\) represents that -fraction of power transferred from zone m to zone n that flows over -a transmission line connecting zone i and zone -j.

-
-\[F(l) \sum_{b}^{B} p(l,b)G(b) \quad \forall l\]
-

(6)

-

Additional constraints are applied to individual buses for which bus -type data are available, limiting injections for load buses and -withdrawals for generation buses, and both injections and withdrawals -for transmission buses. In conjunction these constraints establish a -more stringent limit for interface transfer capacities as compared to -the approach which sums the line ratings across interfaces. This method -for deriving interface transfer limits is used to create the -transmission networks in both the default BA resolution of ReEDS. -At the BA resolution the optimization -is run within each U.S. interconnection separately as they operate -nearly independently due to limited transfer capacity [39]. Due to the -relative density of the eastern interconnection, subsets of the network, -defined by a distance threshold from the interface in questions, are -solved iteratively to reduce the complexity of the optimization -[38].

-

We also drop sub-230 kV lines from interfaces where they make up less -than half of the total interface transfer capacity (which isn’t -described in the ITL paper)

-
    -

  • Map of existing capacity (r and transgrp -resolution)

    -
      -

    • Extra constraint on inter-transgrp flows

      • -
    -
    • -

  • Existing B2B and LCC HVDC

    • -
-
-
-

Costs and routes for new AC transmission additions

-
-_images/new-ac-transmission-cost-assumptions.png -
-

Fig. 40 Costs assumed for new AC transmission additions.

-
-
-
    -

  • 500 kV single circuit

    • -

  • Losses

    • -

  • Least-cost paths

    • -

  • FOM costs

    • -

  • Financial multipliers / CRF

    • -

  • Options for limiting new capacity

    • -
-
-
-

High-voltage direct current (HVDC) “macrogrids”

-
    -

  • LCC (point-to-point)

    -
      -

    • Costs and losses

      • -
    -
    • -

  • VSC (meshed)

    -
      -

    • Costs and losses

      • -

    • Operational constraints

      • -
    -
    • -
-
-
-
-

User-adjustable transmission assumptions

-
    -

  • Hurdle rates

    • -
-

ReEDS includes a default hurdle rate of $0.01/MWh (in -2004$) in order to reduce degeneracy between curtailment and -transmission losses. Users can adjust the hurdle rate to any value that -might meet their needs.

-
    -

  • PRM trading

    • -

  • Transmission investment and capacity limits

    • -

  • Lots of other stuff

    • -
-
-
-

Transmission System

-

ReEDS uses a synthetic network with 134 nodes -defined by roughly 300 corridors for the contiguous 48 states. Each -corridor has a nominal carrying capacity limit that is -determined for the start-year (2010) based on power-flow analysis using -ABB’s GridView model and NERC-reported line limits [NERC, 2010]. The -carrying capacity of DC transmission connections are taken from project -websites. A few notable DC transmission connections that are modeled in -ReEDS are listed in Table 24.

-

In later years, ReEDS can expand these carrying capacities, though the -model cannot build new node-to-node pathways. Transmission expansion is -limited before 2022 based on new construction that is already planned -[ABB, 2013]. After 2022, that limitation is dropped. ReEDS constrains -transmission flows in each of the representative time-slices when -dispatching generation and contracting operating reserves, and available -transmission capacity can also be used for firm power contracts to meet -system adequacy needs.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 24 List of Notable DC Transmission Connections Modeled in ReEDS

Project

Capacity (MW)

Pacific DC Intertie

2,780

Intermountain Power Project

1,920

Miles City Intertie (West-East)

200

Virginia Smith Intertie (West-East)

200

Segall Intertie (West-East)

110

Artesia Intertie (West-ERCOT)

200

Blackwater Intertie (West-East)

200

Rapid City Intertie (West-East)

200

Lamar Intertie (West-East)

210

CU HVDC

1,500

Square Butte

Oklaunion Intertie (ERCOT-East)

220

Welsh Intertie (ERCOT-East)

600

-

In general, the modeled nodes are located at the largest population -center of each BA, although some manual adjustments are made.[ref^35] -Distances between BA nodes are estimated by tracing the “shortest path” -distance along existing transmission lines, giving preference for the -trace follow higher voltage lines. Voltages for each transmission line -were defined using the Homeland Security Infrastructure Project (HSIP) -transmission database and converted into 1-km grid. The maximum voltage -in each grid cell was identified and assigned a weight based on the -voltage classification per Table 25 to create a tension grid. Using this -tension grip, a least “cost” (lowest weight) path was traced between -every BA-to-BA corridor was determined using the tension grid. Finally, -the great circle formula is used to calculate the distance of the traced -paths. The lengths of DC corridors are taken from values -reported on project websites.

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 25 Weights for Each Voltage Class

Voltage Class (kV)

Weight

No line

1,000

100–161

10

230–300

5

345

3

500

2

735 and above

1

-

Transmission network flows in ReEDS are limited based on the nominal -carrying capacity of the corridors. ReEDS can choose to -build additional transmission capacity on the existing network to reduce -congestion, but expansion of AC-DC-AC interconnection ties are not -allowed under default assumptions. New long-distance HVDC lines are not -allowed by default, but can be specified in the model inputs. ReEDS does -not represent reactive power and does not address AC-power-flow issues -of voltage, frequency, or limiting phase angle differences. Intra-BA T&D -networks are similarly ignored, effectively ignoring the effects of -transmission congestion within each region.

-

Transmission and distribution losses are -considered in the model. There are bulk transmission losses of 1% per -100 miles for power that flows between BAs. In addition, distribution -losses of 5% are assumed and thus added to the end-use demand (Electricity Load) -to scale end-use demand to busbar load. Distribution losses do not -apply to rooftop PV, as they are assumed to be downstream within -distribution networks, but they do apply at a lower rate to DUPV -systems, which are assumed to connect directly to low-voltage -distribution substations (Electricity Load).

-
-
-

International Electricity Trade

-

ReEDS is capable of endogenously representing Canada and Mexico, -but our default model configuration only covers the -contiguous United States and represents electricity trade with Canada -exogenously. In the default configuration, imports and exports are -specified by Canadian province based on the National Energy Board’s -(NEB) Canadian Electricity Futures Reference Scenario [NEB, 2018], -with net exports across all regions shown in Fig. 41 (values beyond NEB -projections to 2040 are held constant at the 2040 value). Each province -is required to send electricity to or receive electricity from any of -the ReEDS BAs that have connecting transmission lines to that province, -with the split among BAs approximated based on the transmission -connecting the BAs to the provinces. Seasonal and time slice estimates -for imports and exports are based on the historical monthly flows -between the countries.[35] Canadian imports are assumed to be from -hydropower and are counted toward RPS requirements where allowed by -state RPS regulations. Canadian imports also count toward reserve margin -requirements.

-
-_images/canada-imports-exports.png -
-

Fig. 41 Imports from Canada to the United States and exports from the United States to Canada

-
-
-
-
-
-

Electricity System Operation and Reliability

-

ReEDS finds the least-cost way of building and operating the -electricity system while meeting certain requirements that are dominated -by the need to meet electricity load while maintaining system adequacy -and operational reliability.

-
-

Electricity Load

-

The primary constraint in ReEDS is to serve electricity load in each -hour and BA. The end-use electricity load projection used in ReEDS is -exogenously defined. There are many exogenous load profiles available in -the model, designed to accommodate various study needs and -sensitivities. Especially as the electrification of non-electric energy -uses creates significant regional and temporal shifts to the electric -sector load representation, the choice of load profile is important as -it contributes to the technology deployment mix and -quantity.

-

The ReEDS load profiles are all hourly, and at the ReEDS BA level -resolution, However, their sources and processing through the model vary -slightly, as are described in the following -subsections.

-
-

Evolved Energy Research Load Profiles

-

The newest load profile addition to the model is the adoption of new -load profiles from Evolved Energy Research (EER) which feature the -impacts of the Inflation Reduction Act. EER’s EnergyPATHWAYS model has -been the source of previous ReEDS load profiles, as described in Electrification Futures Study Load Profiles. -It uses a bottom-up methodology, building load profiles for each -end-use sector before aggregating them together, yielding an hourly, -state, subsector level load profile. Their results were disaggregated to -the ReEDS BA level and aggregated to reflect total end-use load in the -ReEDS model. The default load profile in ReEDS Version 2023 “reflects -relatively conservative assumptions about the impact of demand-side -provisions in the Inflation Reduction Act (relative, compared to other -scenarios developed by EER)” [Gagnon et al., 2024]. -The Inflation Reduction Act (IRA) features many tax credits and -subsidies for electric end-use technologies such as electric vehicles -and heat pumps, to name only a couple. More information about the -provisions in the IRA can be found in X. Other EER load profiles feature -100% economy wide decarbonization by 2050 or business as usual -electrification assumptions. Compound annual growth rates and 2050 -CONUS-wide annual demand for these profiles are shown in Table 26. One -benefit of these load profiles is that they feature 7 weather years of -data (2007-2013), allowing us to compute resource adequacy based on -various weather conditions.

- - - - - - - - - - - - - - - - - - - - - - -
Table 26 Compound annual growth rates and 2050 electric load values for a variety of EER load profiles available in ReEDS.

CAGR (2024 through 2050)

2050 CONUS-wide Electric Load (TWh/year)

IRA Low (default)

1.8%

6,509

Business as Usual

0.9%

5,054

100% economy-wide decarbonization by 2050

2.8%

8,354

-
-
-

Historical Load Data + AEO Growth Factor Profiles

-

The second method with which load can be modeled in ReEDS is with a -historical (until 2010), hourly data set, which is then multiplied by -load growth factors from AEO. The historical data are sourced directly -from regional transmission organization (RTO) and independent system -operator (ISO) websites for the applicable regions, with load data being -requested at the most granular resolution available and for weather year -2012. For regions served by utilities, FERC Form 714 hourly load data -are used. Hourly BA-level profiles are averaged to the selected -representative time-slice level. These 2012 weather year profiles are -then scaled to ensure a match with the 2010 state-level annual retail -energy load data from EIA’s Electricity Data Browser [EIA, 2015]. Within -a state in ReEDS, further adjustments to load profiles use county level -load participation factors from Ventyx 2014. -The regional growth factors for years after 2010 are from the AEO scenario -electricity consumption by state. For each model year in ReEDS, the regional -load profiles are scaled by regional growth factors, but the shape of the -load profile is assumed to be constant throughout the study period. For -capacity credit calculations, hourly load from the 2007-2013 weather -years are used (see Resource Adequacy).

-

The end-use load, described in the previous paragraph, is defined at -the meter level. ReEDS includes inter-BA transmission system losses in -the optimization but does not represent distribution losses, so the -end-use load must be scaled up to busbar load to account for -distribution losses. The 5% distribution loss factor used for this -conversion is estimated based on a combination of EIA and ReEDS numbers. -ReEDS is required to generate sufficient power in each time-slice and BA -(allowing for transmission of power but accounting for losses) to meet -this busbar load. [36]

-
-
-

Electrification Futures Study Load Profiles

-

The ReEDS model also contains detailed electrification load profiles -were developed as part of the Electrification Futures Study (EFS) using -EnergyPATHWAYS [Sun et al., 2020]. There are three levels of -electrification load. Reference matches the ReEDS reference load using -AEO 2018 disaggregated to the subsector level reaching 4790 TWh of -annual demand and 860 GW peak demand. The Medium and High -electrification cases layer on top of the Reference electrification case -the incremental growth from EnergyPATHWAYS. Medium electrification -reaches 5800 TWh of annual demand and 1130 GW of peak demand and High -6700 TWh of annual demand and 1320 GW of peak demand. Hourly load -representation with electrification scenarios uses a single 2012 weather -year. This demand data is duplicated to match 7-year weather profiles, -which results in loss of synchronicity between weather and demand data -but we are able to capture greater interannual variability during peak -hours.

-

Electrification of natural gas consuming end uses impacts natural gas -demand beyond the electric power sector. Alternate economy wide natural -gas scenarios are available for use with electrification cases, which -improve the representation of changing natural gas consumption outside -of the electric sector.

-
-
-

Load Adjustment Method for End Use Profiles

-

ReEDS includes a methodology to incorporate changes to hourly electric -load shapes derived from analysis of other modeling tools. Regional -hourly load changes are paired with a defined regional adoption -trajectory for this load change by year. Combining these two factors -allows for ReEDS to changes to load profiles specific to region, year, -and hour. A further unique capability of this method is that an -arbitrary number of load changes and adoption trajectories can be -provided allowing for sophisticated changes to load shapes with a small -number of provided parameters.

-
-_images/reeds-load-adjustment-method.png -
-

Fig. 42 ReEDS Load adjustment method.

-
-
-

This methodology is that it allows for ReEDS load profiles to be -adjusted quickly within an analysis scenario. This methodology is based -upon methods developed to incorporate changes to electric power demand -associated with geothermal heat pumps (GHP) and example hourly change -profiles and adoption scenarios derived from that analysis are -available.

-
-
-
-

Resource Adequacy

-

Resource adequacy is “the ability of supply- and demand-side resources -to meet the aggregate electrical demand” [NERC, 2016]. Planning reserve -requirements in ReEDS ensure adequate resource is available at all -times, within an acceptable probability of failing to do so. In -practice, this constraint is enforced by requiring the system to have -sufficient firm capacity to meet the forecasted peak demand plus a -reserve margin. This constraint is enforced for each season to -accommodate the potential for peak net load to shift seasons as -renewable penetration increases.

-

Each technology is assigned a capacity credit[37] reflecting its -expected availability when power is needed, typically during the -highest-risk hours, which are ideally identified as the hours with -highest loss of load probability (LOLP)[38]. For conventional -non-variable generators in ReEDS, the CC is -one.

-
-

Capacity credit formulation

-

VRE Capacity Credit

-

For VRE technologies (i.e., wind and solar), ReEDS estimates a seasonal -capacity credit for each region/class combination via an hourly LDC -approximation of expected load carrying capability (ELCC)[39] performed -between solve years.[40] ELCC can be described as the amount of -additional load that can be accommodated by adding those generators -while maintaining a constant reliability level. The “8760-based” -methodology can capture the highest load and net load hours, which -typically represent the highest risk hours, and can thereby support a -reasonable representation of capacity credit. Details of this LDC -approach, as well as a comparison against a former statistical method, -can be found in Frew et al. 2017, though that approach has been -expanded to consider 7 years of wind, solar, and load data (2007-2013) -rather than just a single year.

-

The LDC approach for calculating capacity credit is based on explicit -hourly (8,760 hours x 7 years) tracking of time-synchronous load and VRE -resources. The capacity method uses a capacity factor proxy that is -applied to top 10 hours in load and net load-duration curves (LDCs and -NLDCs) in each season to estimate ELCC by season. Fig. 43 graphically -represents the ReEDS capacity credit methodology. The LDC reflects the -total load in a given modeling region, which is sorted from the hours of -highest load to lowest load and is shown by the blue line. The NLDC -represents the total load minus the time-synchronous contribution of -VRE, where the resulting net load is then sorted from highest to lowest, -as shown by the solid red line.[41] The NLDC(δ), which represents -further addition of VRE resources, can be created by subtracting -the time-synchronous generation of an incremental capacity addition from -the NLDC, where the resulting time series is again sorted from highest -to lowest; this is shown by the dashed red -line.

-
-_images/cv-calculation-ldc-approach.png -
-

Fig. 43 LDC-based approach to calculating CV

-
-
-

ReEDS calculates the ELCC as the difference in the areas between the -LDC and NLDC during the top 10 hours of the duration curves in each -season, as represented by the dark blue shaded area in Fig. 43. These -10 hours are a proxy for the hours with the highest risk for loss of -load (i.e., the LOLP).[42] Similarly, the contribution of an additional -unit of capacity to meeting peak load is the difference in the areas -between the NLDC and the NLDC(δ), as shown by the light blue shaded area -in Fig. 43. To ensure resource adequacy, ReEDS calculates capacity -credit based on a 1,000-MW incremental capacity size of new solar and -wind builds. These areas are then divided by the corresponding installed -capacity and number of top hours (10 hours per season in this case, -although the number of hours can be adjusted by the user) to obtain a -fractional seasonal-based capacity credit.

-

The resulting existing and marginal capacity credit[43] values then -feed into ReEDS to quantify each VRE resource’s capacity contribution to -the planning reserve requirement. Existing VRE capacity credit -calculations are performed by region and technology. For all candidate -VRE resources that might be built in the coming year, the marginal -capacity credit is calculated by region, technology, and resource class. -In all cases, the VRE profile is compared against the aggregated -resource assessment region (RAR) load profile for determining the -capacity credit (Fig. 43). We use the RAR-level load profile to -simplify the challenge of representing the ability of transmission to -wheel VRE capacity from one BA to another. Essentially, we assume a -copper plate within each RAR for the purpose of sharing VRE capacity. We -use RAR regions rather than NERC regions for this assumption because -transmission and trading tend to be more closely related to RAR regions -than NERC regions.

-

Storage Capacity Credit

-

The storage capacity credit method in ReEDS characterizes the increase -in storage duration that is needed to serve peak demand as a function of -storage penetration. The potential of storage to serve peak demand is -considered by performing several simulated dispatches against the load -profiles within each of the resource assessment regions shown in Fig. 43.

-

Load profiles net of wind and PV generation are used to capture the -effects of VRE resources on the overall net load profile shape in a -region using the load, wind, and solar data from -2007-2013.

-

For each season and reliability assessment zone, a storage dispatch is -simulated with peaking capacity prioritized over all other services -(reflecting capacity market prioritization as discussed by Sioshansi, et -al. 2014).Transmission constraints are ignored within each reliability -assessment zone for computational efficiency; this copper plate -transmission assumption only applies to the capacity credit -calculation—all transmission constraints are enforced in the actual -planning reserve margin constraint and other system planning and -operation modelling in ReEDS. Optimal coordination of dispatch among -energy storage resources is also assumed. The transmission and -coordination assumptions together allow for all storage within a -reliability assessment zone to be represented as a single aggregate -resource. The round-trip efficiency of this aggregated storage resource -is assumed to be equal to the energy-capacity-weighted average -round-trip efficiency of all installed storage capacity in that -region.

-

All round-trip efficiency losses are included in storage charging. For -example, a storage resource with a round-trip efficiency of 85% and a -power capacity of 10,000 MW can dispatch 10,000 MW to the grid for 1 -hour using 10,000 MWh of energy capacity. However, when the same -resource draws 10,000 MW from the grid for 1 hour, its state-of-charge -increases by only 8,500 MWh.

-

Fig. 44 illustrates the dispatch and calculation of the energy -requirement for 5,000 MW of storage to receive full capacity credit in -the NYISO region in 2020. First, the storage power capacity is -subtracted from the peak load to set a net load maximum. Storage is -required to discharge whenever the load profile exceeds this maximum, to -ensure the peak net load (load minus storage in this example) is equal -to the peak load minus the power capacity of the storage device. The -storage is allowed to charge at all other times while ensuring the load -maximum is not exceeded.

-
-_images/energy-capacity-requirements-for-storage.png -
-

Fig. 44 Model results for determining energy capacity requirements for storage in NYISO in 2020 for a 3-day example in August. 47,000 MWh is determined to be the necessary energy capacity for 5,000 MW of storage to receive full capacity credit. A depth of discharge of 0 indicates that the storage is full.

-
-
-

This dispatch is then used to calculate the energy requirement for -storage to receive full capacity credit. At the beginning of the season, -the state-of-charge of storage within the region is assumed to be full. -The state-of-charge (or depth of discharge, as it is shown in Fig. 44) -is tracked over the course of the time-series with the maximum -depth of discharge left unconstrained. This means the maximum depth of -discharge value over the course of the season is equal to the amount of -energy capacity that is needed for storage to receive full capacity -credit. Dividing this energy by the power capacity used produces the -minimum fleet-wide average duration (hours) for storage to receive full -capacity credit. In the example in Fig. 44, 5,000 MW of peak demand -reduction from storage would require 47,000 MWh of energy to receive -full capacity credit, or a duration of 9.4 -hours.

-

We repeat this process in each region for each season over a large -range of storage power capacities (from 0% to 90% of peak demand in -100-MW increments). The result of each dispatch is used to produce the -“power-energy curve” in Fig. 45, which allows us to calculate the -marginal capacity credit for additional storage. The curve gives storage -energy capacity that is required for full capacity credit as a function -of storage penetration.[44] At any point along the curve, the slope of -the tangent to the curve represents the number of hours needed for -marginal storage to receive full capacity credit. The incremental -capacity credit of an additional unit of storage is equal to the -duration of the additional unit installed divided by the duration -requirement (slope) at the point on the curve corresponding to the -installed storage penetration.

-
-_images/storage-peak-capacity-determination.png -
-

Fig. 45 Determining storage peaking capacity potential in ReEDS. -The slope of each dashed line is the power-to-energy ratio for the -duration specified. Model results are for ERCOT in 2050. Note these -capacities are cumulative, starting from the shortest duration and -moving to the longest.

-
-
-

Fig. 45 also illustrates how -we create a more tractable solution by -reducing the number of combinations considered. Storage in ReEDS is -considered in several discrete durations, and these discrete durations -are used to define the requirements needed to receive full capacity -credit. Instead of a continuous function represented by the constantly -varying slope of the power-energy curve, we create several discrete peak -duration “bins” representing duration requirements. We start by plotting -a line with constant slope equal to the shortest duration considered and -find where it intersects with the power-energy curve. Then, starting -from that point, we plot a line with the next shortest duration and find -the point where it intersects with the power-energy curve, and so on, -until we have obtained the cumulative limit for each discrete duration -of storage to serve peak demand.

-

As an example, the first segment (having a slope of two) requires two -hours to provide full capacity credit, even though it may be physically -possible for some small amount of storage with a duration less than two -hours to receive full capacity credit. In this example, at the point -where 4,309 of 2-hour storage has been added, the lines intersect and -the interpolation shifts to a slope of 4 hours, so a device with 4 hours -is now required to achieve full capacity credit. The model is still -allowed to build 2 hours storage, but it will only receive a 50% (2/4) -capacity credit, or the duration of the installed storage device divided -by the discrete peak duration “bin”. At each point, the marginal -capacity credit is calculated by the physical capacity of the -incremental unit, divided by the discrete duration requirement slope at -any point along the curve.

-

The limit for each duration to serve peak demand from Fig. 45 is -passed back to the ReEDS model, and the model optimizes the capacity -credit of all storage (existing and new investments) together. One -advantage of this is that it informs the model of when the capacity -credit of storage should go up or down in response to changes in the net -load profile shape. Another advantage is that total storage peaking -capacity can be assessed in conjunction with other services storage can -provide such as curtailment recovery, energy arbitrage, and operating -reserves[45], and a least-cost solution can be obtained -overall.

-

Building on the results in the example above, Fig. 46 shows the -actual installed capacities in ERCOT from the low battery cost -sensitivity scenario (discussed further in the results section). For -each battery storage duration available to the model, installed battery -capacity as well as the resource adequacy contribution determined by the -model are shown. This resource adequacy contribution is the result of -the model optimizing all grid services storage can provide, with -capacity credit of all storage subject to the constraints of the peaking -capacity limits from Fig. 45.

-
-_images/installed-battery-capacity.png -
-

Fig. 46 Installed battery capacity and resource adequacy contribution (capacity derated by capacity credit) in ReEDS. -Model results for ERCOT in 2050.

-
-
-

This dynamic assessment of storage capacity credit enables the model to -identify the limitations of energy storage to provide peaking capacity. -It allows the model to identify the benefits, if they exist, of -deploying short-duration resources at reduced capacity credit for energy -arbitrage purposes or other grid services captured in the model. -Alternatively, the model is also free to deploy longer-duration storage -even when shorter durations would receive full capacity credit if this -leads to a least-cost solution for meeting all grid services. It also -allows the model to respond to changes in net load shape from wind and -PV deployment. The capacity credit of storage can change from one solve -year to the next as a result of these net load profile shape -changes.

-

Peaking capacity potential for longer durations of storage are also -assessed within the model. The potential for 12- and 24-hour storage is -included in the assessments described in Fig. 44 -and Fig. 45. This -is meant to accommodate the potential to derate the capacity credit of -ten-hour batteries and capture the capacity credit of pumped-hydro and -compressed-air energy storage (which are assumed to have 12 hours of -duration in ReEDS).

-

After this potential is determined, the actual storage capacity credit -in ReEDS is determined within the optimization. The durations of storage -devices that are installed by the model are evaluated based on the -peaking capacity potential of storage (Fig. 44). When determining the -contribution of storage toward resource adequacy, two constraints were -added to the model to make the capacity credit of storage dynamic and -flexible to the many changes in the system that can affect storage -capacity credit. The constraints for the formulation of storage capacity -credit in ReEDS are as follows:

-
-\[\sum_{pd}^{}{C_{pd,id} = C_{id}}\]
-
-\[\sum_{id}^{}{C_{pd,id}*{cc}_{pd,id} \leq L_{pd}}\]
-

where L is the limit of peaking storage capacity (i.e. the megawatt -values from Figure 5), C is the installed storage capacity, id is the -duration of installed storage, pd is the duration of the peak demand -contribution being considered, and cc is the capacity credit of an -installed duration (id) of storage when applied to a specific peaking -duration (pd). Storage capacity credit is equal to installed duration / -peak duration, with a maximum of 1. For each duration of installed -storage id, its capacity can contribute to any duration of peak demand -pd, but the total installed storage capacity Cid must be -equal to the sum of its contributions toward each duration of peak -demand. And for each duration of peak demand pd, the total contribution -of each installed duration id of storage capacity (adjusted for their -capacity credit cc) cannot exceed the limit of peaking storage capacity -L of that pd.

-

For example, consider a simple example where there is 100 MW of peaking -storage potential for each storage duration considered in ReEDS: two, -four, six, eight, ten, 12, and 24 hours. In this example, 200 MW of -two-hour storage, 100 MW of four-hour storage, and 50 MW of six-hour -storage are already installed. The model would optimize the capacity -credit of storage by giving 100 MW of two-hour storage full capacity -credit for its two-hour contribution, the 100 MW of four-hour storage -full capacity credit for its four-hour contribution, and the 50 MW of -six-hour storage full capacity credit for its six-hour contribution -(Fig. 47). In this example, -the peaking potential limit of two- and -four-hour storage have been reached, so the remaining 100 MW of two-hour -storage would receive a capacity credit of 1/3 and contribute 33.3 MW -for its six-hour peak demand contribution. The model could then build -16.7 MW of six-hour storage at full capacity credit, at which point the -potential for six-hour storage to meet peak demand would be reached as -well. The model would then be able to build two-, four-, or six-hour -storage at a derated capacity credit with their contribution going -toward the eight-hour peak demand “bin,” or it could build 8-hour -storage with full capacity credit.

-
-_images/storage-capacity-credit-allocation-example.png -
-

Fig. 47 An example of storage capacity credit allocation in ReEDS. -200 MW of 2-hour batteries exist but there is only 100 MW of 2-hour -peaking capacity potential. Since there is also 100 MW of 4-hour -batteries serving all 100 MW of 4-hour peaking storage potential, the -remaining 100 MW of 2-hour storage provides 33.3 MW towards the 6-hour -peaking storage potential.

-
-
-

Now consider the same example but in addition to the two-, four-, and -six-hour storage installed, there is also 300 MW of pumped-hydro storage -in this region (Fig. 48). -Pumped-hydro storage in ReEDS has a duration -of 12 hours, but the potential for 12-hour storage to serve peak demand -is only 100 MW. Rather than giving the remaining 200 MW of pumped-hydro -a capacity credit of ½ for its contribution to the 24-hour peak demand -period, it is optimal for the model to fill the 10- and 8-hour peak -demand “bins” with the remaining pumped-hydro capacity at full capacity -credit since there is no other storage allocated to those peak demand -periods. Now, after the model builds 16.7 MW of six-hour storage at full -capacity credit, the 8-, 10-, and 12-hour bins are already filled by -pumped-hydro storage. So, if the model wants to build additional storage -capacity, it will shuffle around the allocated storage capacity to the -optimal “bins” as it fills the 24-hour bin. In this example, if any -8-hour storage is built it will be allocated to the 8-hour bin and some -pumped-hydro capacity will be pushed out of that bin and re-allocated to -the 24-hour bin at ½ capacity credit (12 hours / 24 hours). So, even -though the duration required for storage to receive full capacity credit -at this point is 24 hours, 8-hour storage would receive a marginal -capacity credit of ½ because there is an excess of 12-hour storage -already installed in the system.

-
-_images/storage-capacity-credit-allocation-example2.png -
-

Fig. 48 The same example from Fig. 47 but this time with 300 MW of 12-hour pumped hydro storage. Since there is only 100 MW of 12-hour peaking potential, remaining pumped-hydro capacity is allocated to serve shorter peak durations.

-
-
-

Storage capacity credit is sensitive to a variety of factors on the -power system, so rather than ignoring the many factors that can -influence storage capacity credit we simply pass the model information -on what storage could do to serve peaking capacity based on load shape -and storage duration and then allow the model to choose the least-cost -option based on the suite of available resources and the entire set of -storage revenue streams that are represented within the ReEDS -model.

-

Denholm et al. 2019 and Frazier et al. 2020 demonstrated how the -storage peaking potential of storage interacts with VRE -penetration.

-
-
-

“Stress periods” formulation

-
    -

  • Thematic overview

    -
      -

    • Use the same dispatch constraints as representative -periods, but:

      -
        -

      • Scale up load by PRMN

        • -

      • No weighting to hours (so they don’t -count toward VOM costs, fuel costs, emissions constraints; same as -capacity credit)

        • -

      • Inter-period operation of storage is not currently -supported

        • -
      -
      • -

    • ReEDS2PRAS

      -
        -

      • Typical generator sizes

        • -

      • PRAS – probabilistic outages

        • -
      -
      • -

    • Stress metrics and iteration

      • -
    -
    • -
-

Several shortcomings arise under the capacity credit-based approach for -evaluating resource adequacy. In -ReEDS, planning resource can be traded between the Federal Energy -Regulatory Commission (FERC) Order 1000 regions, however the capacity -credit is still assessed where the resource is sited, misrepresenting -the evaluation for some generation assets. Additionally, identifying -stress periods using peak net load hours can potentially miss system -stress that results from events spanning consecutive days, such as -extreme weather. The alternative stress period formulation in ReEDS -attempts to mitigate some of these deficiencies. In this approach, a -probabilistic resource adequacy suite (PRAS) developed by NREL is -brought into the loop, allowing ReEDS to pass the system design to the -resource adequacy model after every solve year. The PRAS model is -described in a separate publication [42] , but its use in conjunction -with the ReEDS model is included briefly here. Essentially PRAS ingests -the ReEDS build out and utilizes 7 years of load and weather data to -identify the periods with the highest risk of unserved energy, these -periods are then passed back to ReEDS to ensure sufficient capacity is -built. Within PRAS the expected unserved energy is evaluated by running -a sequential Monte Carlo model to simulate the probability of individual -assets failing over the full multi-year optimization horizon producing -results for unserved energy. The simulation is run for multiple outage -draws after which the collective system stress periods can be -identified.

-
-
-

Planning Reserve Margins

-

The planning reserve margin fractions applied in ReEDS are based on -reserve margin requirements for NERC reliability subregions [NERC, 2010] -(see Fig. 19). Each ReEDS BA must meet the requirement, but regions can -engage in bilateral contracts for firm capacity subject to transmission -limits on AC or DC corridors. The planning reserve margin is enforced -seasonally such that each BA much meet the reserve margin requirement in -each of the four seasons.

-

The planning reserve margin is constant over time for all regions -except ERCOT. Because ERCOT was below its NERC-recommended level in -2018-2020, the ERCOT reserve margin is set to the actual levels of 10.9% -and 8.6% for 2018 and 2019, respectively, and at the projected level of -10.6% for 2020 [ERCOT, 2019]. The years from 2021 and onward are set at -13.75%, and future planning reserve margin levels are anticipated to -meet or exceed that target from 2021 and -onward.

-
-
-
-

Operational Reliability

-

In addition to ensuring adequate capacity to satisfy long-term planning -reserve requirements, ReEDS requires operational reliability—that is, -the ability to continue operating the bulk-power system in the event of -a sudden disturbance [NERC, 2016]. In practice, ancillary reserve -requirements ensure there is sufficient flexibility from supply-side and -demand-side technologies to rebalance fluctuations in generation and -demand.

-

ReEDS represents three type of operating reserve products, including, -spinning, regulation, and flexibility reserves [Cole et al., 2018]. The requirement specified for each product in each time-slice is -a function of load, wind generation, and photovoltaic capacity (during -daytime hours).[46] Technologies providing these reserve products must -be able to ramp their output within a certain amount of time (Table 27).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 27 Summary of Operating Reserve Requirements

Reserve Product

Load Requirement (% of load)a

Wind Requirement (% of generation)b

PV Requirement (% of capacity)b

Time Requirement to Ramp (minutes)

Spinning

3%

—

—

10

Regulation

1%

0.5%c

0.3%c

5

Flexibility

—

10%

4%

60

-

a See Lew et al. 2013.
-b Reserve requirements for wind and PV are derived from the -outcomes from Lew et al. 2013. The flexibility requirement for wind is -estimated as the ratio of the change in the reserve requirement to the -change in wind generation from the Lew et al. High Wind scenario; the -requirement was estimated similarly for PV using the Lew et al. High -Solar scenario.
-c The estimated regulation requirements (0.5% wind generation -and 0.3% PV capacity) are based on incremental increases in regulation -reserves across all scenarios in Lew et al. -2013.

-

All ancillary reserve requirements must be satisfied in each BA for -each time-slice; however, reserve provision can be traded between BAs -using AC transmission corridors. Trades are only allowed within an RTO -and not across RTO boundaries. The amount of reserves that can be traded -is limited by the amount of carrying capacity of an AC transmission -corridor that is not already being used for trading -energy.

-

The ability of technologies to contribute to reserves is limited by the -ramping requirement for a given reserve product, the plant ramp rate, -and online capacity (Table 28). Online capacity is approximated in ReEDS -as the maximum generation from all time-slices within a modeled day. -Reserves can be provided by generation and storage technologies that are -turned on but not fully dispatched in a time-slice. In addition, -demand-side interruptible load can also contribute to reserve -requirements, if enabled in a scenario. Nuclear, PV, and wind are not -allowed to contribute toward the supply of -reserves.

-

The cost for providing regulation reserves is represented in ReEDS -using data from [Hummon et al., 2013]; see Table 29. Because ReEDS does -not clearly distinguish between coal fuel types, $12.5/MWh is the -assumed regulation cost for all coal technologies. The cost of providing -regulation reserves from Gas-CT, geothermal, biopower, land-fill gas, -and CAES is assumed to be the same as oil/gas -steam.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 28 Flexibility Parameters of the ReEDS Generation Technologies

Assumed Ramp Rate (%/min)

Upper Bound (% of online capacity) = Ramp Rate (%/min) × Ramp Requirement (min)

Spinning

Regulation

Flexibility

Gas-CTa

8

8×10=80

8×5=40

8×60=480, so 100

Gas-CCa

5

5×10=50

5×5=-25

5×60=300, so 100

Coala

4

4×10=40

4×5=20

4×60=240, so 100

Geothermalb

4

4×10=40

4×5=20

4×60=240, so 100

CSP with Storagec

10

10×10=100

10×5=50

10×60=600, so 100

Biopowerb

4

4×10=40

4×5=20

4×60=240, so 100

Oil/Gas Steama

4

4×10=40

4×5=20

4×60=240, so 100

Hydro

100

No Upper Bound

No Upper Bound

No Upper Bound

Storage

100

No Upper Bound

No Upper Bound

No Upper Bound

-

a See [Bloom et al., 2016].
-b Geothermal and biopower values are assumed to be the same -as oil/gas steam units. In practice, geothermal plants typically do not -ramp given their zero or near-zero variable costs, and therefore only -provide energy and not operating reserves.
-c. See [Jorgenson et al., 2013].

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 29 Cost of Regulation Reserves

Generator Type

Cost of Regulation Reserves (2013$/MWh)

Supercritical Coal

15

Subcritical Coal

10

Combined Cycle

6

Gas/Oil Steam

4

Hydro

2

Pumped Storage Hydropower

2

-
-
-
-

Climate Impacts

-

Previous versions of ReEDS, including the 2018 version [Cohen et al., 2019], -included a representation of climate impacts, and Section 7 of -the 2018 ReEDS documentation describes that capability. Recent changes -to the ReEDS time resolution are not compatible with the former climate -impacts representation, and it is expected that ReEDS climate impacts -capabilities will be restored for the 2024 model -version.

-
-
-

Policy Descriptions

-

Policies modeled in ReEDS include federal and state-level emission -regulations, tax incentives, and portfolio standards. This section -primarily focuses on existing policies, but additional frameworks -that exist in the model are discussed in Other Policy Capabilities.

-
-

Federal and State Emission Standards

-
-

Cross-State Air Pollution Rule

-

ReEDS applies the Cross-State Air Pollution Rule (CSAPR) using caps on -power plant emissions to the states in the eastern half of the United -States over which the rules are imposed. From 2017 onward, CSAPR annual -emission allowance budgets for NOx are applied at the state -level using the Phase 2 caps [EPA, 2008]. The caps are applied only -during the ozone season. ReEDS applies a seasonal estimate of these -ozone season caps that adjusts for the overlap of ReEDS season -definitions and ozone season definitions. States can trade allowance -credits within the eligible trading groups, but must keep emissions -below the required assurance levels.

-

Sulphur Dioxide (SO2) emission limits are not represented in -the model because the caps would not be binding in the model except in -historical years.

-
-
-

Mercury and Air Toxic Standards

-

Because compliance with the Mercury and Air Toxic Standards (MATS) has -already been largely achieved, we do not represent MATS in the ReEDS -model.

-
-
-

California Carbon Cap

-

California’s Global Warming Solution Act of 2016 (referred to as -Assembly Bill 398 or AB 398) established a program to reduce -economy-wide greenhouse gas emissions to 1990 levels by 2020. In 2016, -legislation was passed that codified the 2030 greenhouse gas target to -40% below 1990 levels. In ReEDS, these state carbon caps are modeled as -a cap on electricity-system CO2 emissions from generators -either located in California or serving load in the state. Direct -CO2 emissions from generators located in California count -toward the cap. Imported electricity is assumed to have a emissions rate -of 0.26 ton CO2/MWh [CARB, 2019].

-

Because California’s greenhouse gas reduction targets are legislated -for all economic sectors while ReEDS only models the electricity sector, -we rely on published economy-wide modeling results to estimate electric -sector-specific caps that are used in ReEDS. In particular, we apply -power sector caps based on the annual CA electric sector emissions (from -in-state and imported electricity) from California Public Utilities -Commission [CPUC, 2018], which provides guidance for a 42 million -tCO2 cap by 2030. We enforce that cap from 2030 to 2050. The -pre-2030 cap ramps linearly from 60 million tCO2 in 2020 to -the 42 million tCO2 in 2030. Note that we also model -California’s RPS policy.

-
-
-

Regional Greenhouse Gas Initiative

-

The Regional Greenhouse Gas Initiative (RGGI) cap-and-trade program -limits the CO2 emissions for fossil fuel-fired power plants -in eleven states: Connecticut, Delaware, Maine, Maryland, Massachusetts, -New Hampshire, New Jersey, New York, Rhode Island, Vermont, and -Virginia.

-

We enforce allowance budgets from the updated model rule adopted in -2017.[47] We ignore the provision for privately banked allowances and -therefore use the unadjusted budgets: 165 million short tons in 2012 -declining to 91 million by 2014, then declining 2.5% per year from 2015 -to 2020. According to the 2017 Model Rule, the 2021 cap is set at 75 -million short tons and decreases by 2.275 million tons per year until -2030. Beginning in 2020, we also enforce an additional budget of 18 -million short tons for the addition of New Jersey to the set of states -included in the RGGI[48]. The budget for New Jersey is set to decline -by 30% through 2030[49]. Similarly, beginning in 2021, we apply an -additional cap of 27.16 million short tons for the addition of Virginia -as a RGGI state. This cap is set to decline at a rate of 0.84 short tons -per year.[50] We assume the budget remains constant beyond 2030. We do -not model banking of allowances, emissions offsets, or recycling of -initiative allowance revenues.

-
-
-
-

Federal and State Tax Incentives

-
-

Federal Tax Credits for Clean Electricity and Captured Carbon

-

Existing federal tax incentives are included in ReEDS, aligned with the -Inflation Reduction Act of 2022 (IRA). These include the PTC and the ITC -for clean electricity, the 45U credits for existing nuclear generation, -the 45Q credit for capturing and storing carbon, and the Modified -Accelerated Cost Recovery System (MACRS) depreciation schedules. [51] -Current technology-specific depreciation schedules are modeled for all -years, because we assume they are permanent parts of the tax -code.

-

Four clean electricity production and investment tax credits are -represented in ReEDS:

-
    -

  • Clean Electricity Production Tax Credit (PTC): $26/MWh for 10 -years (2022 dollars) plus a bonus credit that starts at $1.3/MWh and -increases to $2.6/MWh by 2028

    • -

  • Clean Electricity Investment Tax Credit (ITC): 30%, plus a bonus credit that starts at an additional 5% and -increases to 10% by 2028 (for totals of 35% and 40% respectively)

    • -

  • Captured CO2 Incentive (45Q): $85 per metric ton of -CO2 for 12 years for fossil-CCS and bioenergy-CCS, and $180 -per metric ton of CO2 for 12 years for direct air capture; -nominal through 2026 and inflation adjusted after that

    • -

  • Existing Nuclear Production Tax Credit (45U): This tax credit is $15/MWh (2022 -dollars), but it is reduced if the market value of the electricity -produced by the generator exceeds $25/MWh. As a simplification, this -dynamic calculation was not directly represented in ReEDS. Instead, to -represent the effect of this provision, existing nuclear generators are -not subject to economic retirement in ReEDS through 2032.

    • -
-

Note that IRA allows for bonus credits for both the clean electricity PTC and ITC (but -not applicable to 45U or 45Q) if a project either meet certain domestic -manufacturing requirements or is in an “energy community.” Projects can -obtain both bonus credits if they meet both requirements, which would -equate to $5.2/MWh for the PTC and 20% for the ITC. In ReEDS, we assume -projects will, on average, capture one of the bonus credits by 2028, the -value of which is expressed in the summary above. In practice, there -will likely be greater diversity of captured credits amongst projects. -Relatedly, the values above are based on the assumption that all -projects will meet the prevailing wage -requirements.

-

Under IRA, eligible clean electricity projects can select whether to -take the PTC or the ITC. As implemented in ReEDS, however, an a priori -analysis was performed to estimate which credit was most likely to be -more valuable, and the technology was assigned that credit. The -assignments are:

-
    -

  • PTC: Onshore wind, utility-scale PV, and biopower

    • -

  • ITC: Offshore wind, CSP, geothermal, hydropower, new nuclear, pumped storage -hydropower, distributed PV, and batteries.

    • -
-

As represented in ReEDS, the -value of the tax credits is reduced by 10% for non-CCS technologies and -7.5% for CCS technologies, as a simple approximation of the costs of -monetizing the tax credits (such as tax equity financing).[52] These -cost penalties are not reflected in the values given for each incentive -above.

-

The clean electricity PTC and ITC are scheduled to start phasing out -when electricity sector greenhouse gas emissions fall below 25% of 2022 -levels, or 2032, whichever is later. Once the tax credits phase out, -they remain at zero—there is no reactivation of the credits if the -emissions threshold is exceeded at a later point. The exact value of the -threshold that would trigger the IRA clean electricity tax credits -phasing out has not been announced but is estimated at 386 million -metric tons of CO2e in this modeling. The 45Q and 45U credits -do not have a dynamic phaseout and are instead just scheduled to end at -the end of 2032.

-

In the dGen model, distributed PV was assumed to take an ITC: the 25D -credit for residential, and the Section 48 credit for commercial and -industrial. For residential projects placed in service through 2032 the -ITC was assumed to be 30%, declining to zero for projects placed in -service in 2036. For commercial and industrial projects coming online -through 2035 the ITC was assumed to be 40%, dropping to zero after that. -These representations are simplifications, as there can be greater -diversity in captured value depending on factors such as ownership type -and tax status. Furthermore, due to limitations of the models used in -this study, the dynamic phase-out of the Section 48 ITC was not -reflected. In practice, most scenarios did not cross the emissions -threshold specified in IRA at this point, and therefore the adoption of -commercial and industrial distributed PV in the later years of those -scenarios was potentially underestimated.

-

IRA includes additional bonus credits (up to 20%) for up to 1.8 GW per -year for solar facilities that are placed in service in low-income -communities. The dGen model runs used in this analysis did not have an -explicit representation of that additional bonus credit. Instead, 0.9 GW -per year of distributed PV was added to the original dGen estimates -through 2032. The estimate of 0.9 GW reflects the assumption that some -of the projects capturing the bonus credit may not be additional (i.e., -they would have occurred anyway even if the bonus credit was not -available).

-

All the IRA tax credits are assumed to have safe harbor periods, -meaning a technology can capture a credit as long as it started -construction before the expiration of the tax credit. The maximum safe -harbor periods are assumed to be 10 years for offshore wind, 6 years for -CCS and nuclear, and 4 years for all other technologies. Generators will -obtain the largest credit available within their safe harbor window, -meaning that once a credit starts to phase down or terminate, ReEDS -assumes that efforts were made to start construction at the maximum -length of the safe harbor window before the unit came online. In -practice this means ReEDS will show generators coming online and -capturing the tax credits for several years beyond the nominal year in -which they expired.

-
-
-
-

State Renewable Portfolio Standards

-

ReEDS models state RPSs, including technology set-asides and renewable -energy certificates (RECs) that can count toward RPS compliance. RPS -rules are complex and can vary significantly between states. The RPS -representation in ReEDS attempts to model the primary impacts of these -RPS rules but includes many simplifying assumptions. In addition, in -recent years there have been numerous changes to RPS legislation. We -periodically update our representation to capture the recent changes to -the legislation; however, the numerous and frequent changes to state -laws create challenges to having a precise representation of all RPS -legislation.

-

Table 29 shows the respective RPS targets and technology set-asides for -years 2020, 2030, and 2050 as a percentage of state electricity sales as -modeled within ReEDS. These values—along with many other data that we -use to represent nuanced RPS rules—are based on data compiled by -Lawrence Berkeley National Laboratory, which takes into account the -in-state REC multiplier incentives and load adjustments (e.g., -sales-weighted RPS targets considering different load-serving entities -subject to compliance, such as investor-owned utilities, municipal -utilities, and cooperatives).[53] Solar includes UPV and ro­oftop PV, -wind includes both land-based and offshore technologies, and distributed -generation (DG) includes rooftop PV and ground-mounted PV systems -located within the distribution network.[54] ReEDS also models -alternative compliance payments for unmet RPS requirement for both main -RPS targets and solar set-asides as is consistent with the available -data.69

-

Technology eligibility for state RPS requirements is appropriately -modeled for each state.69 For instance, California’s RPS does -not allow in-state rooftop solar technologies to contribute toward its -RPS. Additionally, every state has specific rules regarding hydropower -generation’s eligibility toward contributing RECs, which are usually -based on each unit’s vintage and size (e.g., small hydro with specific -capacity cut-offs are eligible in some states). ReEDS models these as -allowable generation fractions from Barbose 2023, -which is imposed on each state’s total hydropower generation thereby limiting -the amount of hydropower RECs that each state could produce.

-

Table 29 also lists the allowable states from which each state may -import RECs; interstate REC transactions that are required to be bundled -with energy are marked with an asterisk. Except for California, ReEDS -enforces an upper limit on the total RECs (both bundled and unbundled) -that can be imported for that state’s RPS compliance. For California -alone, due to its unique out-of-state rules, ReEDS enforces two upper -limits, one on the total unbundled REC imports and the other on the -total bundled REC imports. There is a myriad of possibilities of -interstate REC transactions, in terms of both which two states can -transact and the quantity of those transactions. To constrain the -solution space of ReEDS to credible values, the interstate REC trading -modeling is based on historical observations [Holt, 2016], as shown in -the final two columns of Table 29. The out-of-state total REC import -percentages for each state in are limited to those observed in 2012–2013 -[Heeter, 2015].

-

Several states have implemented policies directed at offshore wind. To -represent these actions in ReEDS, we prescribe a floor to offshore wind -capacity based on known projects and policy mandates. Specifically, we -include offshore wind capacity that meets at least one of three -criteria: (1) currently operating capacity; (2) projects in active -solicitation processes; and (3) to meet statutory policy requirements. -The projects are based on tracking conducted for the NREL Offshore Wind -Technologies Market Report and state totals are shows in Table 30. -The model allows for economic deployment of offshore wind capacity beyond -these levels. All prescribed offshore wind projects are assumed to be -rebuilt once they are retired.

-

Finally, voluntary renewable energy credits are also represented in -ReEDS. Only renewable energy technologies are allowed to supply -voluntary RECs, and Canadian imports are not allowed. -The voluntary REC requirement is based on the -observed amount of voluntary RECs from Heeter et al. 2021 -and the requirement is assumed to grow by the smallest amount that has been -observed year-over-year (0.1624% in absolute terms). The voluntary -requirement includes an alternative compliance payment of $10/MWh (in -2004$).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 30 Cumulative Offshore Wind Capacity (MW) Mandated in ReEDS

State

2020

2030

2040

2050

CA

—

3,100

4,707

4,707

MA

—

4,092

6,492

6,492

MD

—

5,044

8,500

8,500

ME

—

144

144

144

NC

—

2,800

2,800

2,800

NJ

—

5,100

11,000

11,000

NY

—

4,362

9,000

9,000

RI

30

1,538

1,538

1,538

VA

12

2,599

5,200

5,200

Total

42

28,779

49,381

49,381

-
-
-

9.4. 9.4 Clean Energy Standards

-

As of July 2023, 15 states had clean energy standards (CESs) (see Table -29). CES values are effective values[55] and are taken from Barbose -2023. These CESs are in effect -generalized versions of RPSs; their model representations are very similar -with technology eligibility being the only difference. For all but one of -the CES policies (Massachusetts), we assume all zero-carbon-emitting sources -(on a direct emissions basis) can contribute to the CES requirement. This -includes all renewable energy technologies (including hydropower and distributed -PV), nuclear power, and imports from Canada.[56] The modeled CES -policies set a floor on electricity generated from clean energy -technologies but does not cap generation from nonclean sources. As a -result, in the model representation, a state can continue to generate -from existing fossil plants if the amount of clean energy generation -exceeds the requirement (even if the requirement approaches 100% of -sales). Most of the CES policies are assumed to start in 2030 and ramp -to their final targets by 2040 or 2050.[57] For other aspects of the -CES model representation, we use the same assumptions as the -corresponding state RPS. These include assumptions about credit trading -and variations in load-serving entity requirements. In the case of -Virginia, fossil plants are required to retire per the schedule -indicated in the clean energy policy.[58] Based on discussions with -stakeholders, fossil plants in Illinois and New York are also required -to retire once the policy reaches the nominal 100% -target.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 31 Clean Energy Requirement as a Percentage of In-State Sales

State

2020

2025

2030

2035

2040

2045

2050

CA

0%

0%

55%

70%

85%

100%

100%

CO

19%

32%

44%

47%

50%

52%

55%

MA

20%

28%

37%

45%

54%

63%

71%

NM

0%

0%

45%

60%

75%

90%

100%

NY

0%

0%

75%

87%

100%

100%

100%

WA

0%

0%

80%

87%

93%

100%

100%

VA

0%

24%

39%

56%

76%

96%

100%

-
-
-

Storage Mandates

-

Seven state storage mandates are represented in ReEDS. The storage -mandate are summarized in Table 32. The mandates are required to be met -with battery storage, and any duration of storage -qualifies.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 32 Energy storage mandates, with required capacity listed in MW.

State

2020

2030

2050

CA

1,325

2,325

2,325

MA

50

50

50

NJ

600

2,000

2,000

NV

1,000

1,000

NY

500

3,000

3,000

OR

2.5

2.5

2.5

VA

42.7

1,350

3,100

-
-
-

Nuclear Power Plant Policies

-

There are four states that have enacted that provide compensation or -other assistance for in-state nuclear power plants: Connecticut, -Illinois, New Jersey, and New York. For these states, the nuclear power -plants are not allowed to retire until after the policy expires, unless -the power plant already has an announced retirement date. The policy -end-dates are taken from EIA 2019.

-

Additionally, there are several states that do not allow new nuclear -power.[59] These states include California, Connecticut, Illinois, -Maine, Massachusetts, Minnesota, New Jersey, New York (Long Island -only), Oregon, Rhode Island, and Vermont.

-
-
-

Other Policy Capabilities

-

In addition to the existing policies described above, ReEDS also -includes several optional policy implementations that are useful for -exploring alternative futures or the impact of existing policies. These -additional policy frameworks include:

-
    -

  • National Clean Energy Standard: This framework allows the user to -specify which technologies count as “clean energy” and enforce a -minimum limit for the penetration of these clean energy -technologies.

    • -

  • National Renewable Portfolio Standard: This standard enforces a -national RPS, with the RPS trajectory defined by the -user.

    • -

  • Carbon Cap-and-Trade: This feature allows the user to specify -national-or subnational carbon cap-and-trade policies, including -options to represent trading limitations and banking and borrowing of -allowances.

    • -

  • Carbon Tax: This feature implements a user-specified carbon tax -on burner-tip emissions from the power -sector.

    • -

  • National Emissions Limit: This framework limits the total -national emissions according to user-specified values. The limit is -often referred to as a carbon cap or CO2 -cap.

    • -

  • Alternative ITC and PTC Schedules: In addition to the ITC and PTC -schedules described in Federal and State Tax Incentives, -the ITC and PTC can be modified to apply for any number of years and to any -technology.

    • -

  • Alternative Financing Measures: Policy-related financing impacts -such as MACRS or the under-construction provisions for the ITC and PTC -can be modified as specified by the user.

    • -
-
-
-
-

Capital Financing, System Costs, and Economic Metrics

-
-

Financing of Capital Stock

-

The financing assumptions used in ReEDS are taken directly from the -2023 ATB spreadsheet [NREL, 2023], using the -“Market Factor Financials” and the 20-year capital recovery period options. -The ATB has technology-specific and time-varying financing parameters, -including interest rate, rate of return on equity, debt fraction, and tax -rate. Other elements of the ATB included in ReEDS include construction -schedules, MACRS depreciation schedules, and inflation rates. These -values are further defined and explained in the ATB, with additional -explanation of our financing implementation detailed in the Capital Cost -Financial Multipliers appendix of this -document.

-

In previous versions of ReEDS, technology-specific costs of capital -were reflected through technology-specific discount rates. Due to the -different model structure of the intertemporal mode, and the desire to -keep the financial representations the same between modes, since the -2019 version the model has had only a single technology-agnostic -discount rate. Instead of varying the discount rate, the impact of any -difference between a technology’s weighted average cost of capital -(WACC) and the system average WACC is captured in a lump-sum adjustment -that represents the present-value of the higher (or lower) return to -capital. This representation implicitly assumes that differences in -financing terms primarily come from diversifiable risk, as opposed to -non-diversifiable risk.

-
-
-

Electric Sector Costs

-

Two system-wide cost metrics are calculated from each ReEDS run: a -present value of direct electric sector system costs and electricity -price. These cost calculations are not part of the ReEDS optimization -process; they are calculated after the ReEDS optimizations have been -conducted. ReEDS also includes a postprocessing option for estimating -the health costs of air pollution, described further -below.

-
-

Present Value of Direct Electric Sector Cost

-

The present value system cost metric accounts for capital and operating -expenditures incurred over the entire study horizon for all technology -types considered, including generation, transmission, and storage. The -cost in each future year is discounted by a user-defined discount rate, -and by default it is set to 5%. Not to be confused with the discount -rate used in the optimization for investment decisions, the investment -discount rate is selected to represent private-sector investment -decisions for electric system infrastructure, and it approximates the -expected market rate of return of investors. All costs incurred before -the start of the specified economic horizon are assumed to be sunk and -are therefore not included in the system cost metric. Details about how -the system costs are calculated in ReEDS can be found in the Present -Value of Direct Electric Sector Cost section of the -appendix.

-
-
-

Electricity Price

-

ReEDS calculates “competitive” electricity prices at different regional -aggregation levels -[EIA, 2017, Murphy and Smeers, 2005, Ventosa et al., 2005]. This calculation takes advantage of the linear programming -formulation of the model. Specifically, the marginal price on a model -constraint represents how much the objective function would change given -a change in the right side of the constraint. Each constraint can be -viewed as a market with a marginal price and quantity. At optimality, -the total revenue (i.e., the product of price and quantity) across all -constraints equals the objective function value. The constraints within -ReEDS are written such that the marginal values from the load -constraints can be used as a proxy for the competitive electricity -price. The load constraints are linked to the supply-demand balance -constraints, capacity constraints, operating reserve constraints, and -others through load variables. Taking the marginal value from the load -balance constraint, we can find the marginal value of an additional unit -of load (e.g., MWh) to the system, accounting for other requirements. -Specifically, the reported competitive prices in ReEDS capture five -categories of requirements, including energy, capacity, operating -reserves, and state-level and national-level RPS requirements (see Table -31). The competitive prices can be reported at different regional -aggregation level, scaled by requirement quantities. Details about how -these prices are calculated in ReEDS can be found in the Marginal -Electricity Prices section of the appendix.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 33 Relationships of Constraints to Grid Services Used to Calculate the Competitive Electricity Price

Constraint Category

Grid Service (s)

Region (r)

Time (h)

Units - Price (p_srht)

Units - Quantity (q_srht)

Operation

Energy

BA

Time-slice

$/MWh

MWh

Operation

Flexibility Reserve

BA

Time-slice

$/MW-h

MW-h

Operation

Regulation Reserve

BA

Time-slice

$/MW-h

MW-h

Operation

Spinning Reserve

BA

Time-slice

$/MW-h

MW-h

Resource Adequacy

Capacity

BA

Season

$/kW-yr

kW

Policy

State RPS

State

Annual

$/MWh

MWh

Policy

National RPS

National

Annual

$/MWh

MWh

Policy

CO2 Cap

National

Annual

$/metric ton

metric ton

Policy

RGGI CO2 Cap

Regional

Annual

$/metric ton

metric ton

Policy

SB32 CO2 Cap

Regional

Annual

$/metric ton

metric ton

-

Besides “competitive electricity prices”, ReEDS also calculates the -average cost of electricity at the national, BA-level or state-level by -taking the annualized total costs of building and operating the system -in a specific geographic area and divided that by the electricity load -in that area. Annualized costs for existing (i.e., pre-2010) power -plants are also considered given plants’ initial investment costs and -the built year. BA-level average electricity prices also consider the -impact of energy and capacity trading. These prices reflect the average -costs to serve the load in certain areas. Detailed calculation equations -can be found in the Average Electricity Prices section of the -appendix.

-
-
-

Cost of Health Damages from Air Pollution

-

In addition to direct system costs, ReEDS also includes a -postprocessing step for estimating health damages associated with air -pollution. Currently this focuses on mortality from long-term exposure -to fine particulate matter (PM2.5)[60] from fossil fuel -combustion in the electric sector.

-

To estimate health damages, ReEDS relies on estimates of the mortality -risk per tonne of emissions from three reduced complexity air quality -models (AP2, EASIUR, and InMAP).[61] Each of these models estimates -PM2.5 formation associated with emissions of precursor -pollutants (NOx and SO2). To generate annualized -premature mortality, each model applies a concentration response -function from one of two studies linking exposure to PM2.5 to -increased mortality risk. These two studies, referred to as the American -Cancer Society Study (ACS) and Harvard Six-Cities Study (H6C) provide -estimates of the relationship between pollution exposure and premature -mortality [Gilmore et al., 2019]. The result is an estimate of the -mortality risk per tonne of pollutant emitted in each U.S. county. This -marginal damage estimate can be aggregated to the ReEDS balancing area -level and multiplied by total emissions to estimate total -mortality.

-

As a final step, annual premature deaths from air pollution can be -translated into a monetary value by applying a value of a statistical -life. For this ReEDS relies on the U.S. Environmental Protection -Agency’s estimate of $7.4 million in 2006 dollars [EPA (U.S. Environmental Protection Agency), 2014] inflated to a -present-day dollar value ($9.9 million in 2021 dollars). These costs can -then be translated into costs per unit of generation and cumulative (discounted) -cost over the study period.

-

The approach described here focuses on direct emissions from the -electric power sector, and thus does not capture estimates from other -sectors (such as transportation, buildings, and industry) or upstream -emissions (such as from fossil fuel extraction or power plant -manufacturing). It also does not quantify any social costs of climate -change from CO2 or other greenhouse gas -emissions.

-
-
-
-

Modeled Economic Metrics

-

ReEDS calculates multiple economic metrics for analyzing investment -decisions in the model, including:

-
    -

  • Levelized cost of energy (LCOE)

    • -

  • Technology value

    • -

  • Net value of energy (NVOE)

    • -

  • Net value of capacity (NVOC)

    • -

  • System profitability

    • -
-

These metrics are described in detail below.

-
-

Levelized Cost of Energy

-

LCOE measures the unit cost of electricity of a specific technology, -which is normally calculated as lifetime costs divided by energy -production. Specifically, the LCOE is calculated as follows -[NREL, 2019]:

-
-\[LCOE = \frac{FCR \times CAPEX + FOM}{CF \times 8,760} + VOM + FUEL\]
-

where FCR is the fixed charge rate; CAPEX is the capital expenditures; -FOM is the fixed operations and maintenance costs; CF is the capacity -factor; 8,760 is the number of hours in a year; VOM is variable -operations and maintenance costs; and FUEL is fuel costs (if -applicable).

-

In each model year, ReEDS reports the LCOE for all technology options -considering different variations in tax credit treatments and capacity -factor assumptions. ReEDS also calculates the LCOE for technologies that -are built in this model year using the generation from these -technologies.

-
-
-

Technology Value

-

ReEDS reports the value that generators receive from providing grid -services. Value is calculated as the product of service prices and -service provision quantities. For example, the value of a generator that -comes from providing energy service to meet planning reserve margin -requirement is calculated as the price of capacity multiplied by the -amount of firm capacity the generator can provide. The reported revenues -capture energy, capacity, operating reserve, and state-level and -national RPS requirements. Revenues can be normalized either by the -amount of generation or by the amount of installed -capacity.

-

Revenues are closely related to, but are different from the electricity -price and service requirement quantity parameters. Revenues consider the -provision of different services from a certain generator in a region, -whereas service requirement quantities calculate the demand of -different services in a region. The sum of revenues from all generating -technologies in a specific region does not necessarily equal the sum of -products of all service prices and corresponding service -requirements.

-
-
-

Net Value

-

ReEDS reports different economic viability metrics that consider both -costs and values of generating technologies to fully evaluate the -economic competitiveness of a certain technology, and to provide -intuitive explanations about investment decisions in the model. “Values” -of a generator reflect the potential economic benefit from displacing or -avoiding the cost of providing the services from other (marginal) -assets, while “costs” aggregate all different sources of costs needed to -build and operate a power plant to provide services. We define “net -value” as the difference between values and costs. Net value is related -to a concept in linear programming called “reduced cost.” Mills and -Wiser 2012 describe reduced -cost in the context of electricity system modeling.

-

We report three types of such metrics to assess the economic viability -of generators: net value of energy, net value of capacity, and system -profitability metrics (Table 34). These metrics are reported both for -new investments in certain model year and for existing generators that -have been built.

- - - - - - - - - - - - - - - - - - -
Table 34 Summary of Net Value Metrics

Metric

Conceptual Expression [Typical Units]

Net value of energy (NVOE)

(Value – Cost)/Energy [$/MWh]

Net value of capacity (NVOC)

(Value – Cost)/Capacity [$/kW-yr]

System profitability

f(Value/Cost) [unitless]

-

Net value of energy (NVOE) measures the unit profit of a specific -technology, calculated as the difference between generator revenue and -costs, then normalized by the energy production. The typical unit is -dollars per megawatt-hour ($/MWh). Similarly, net value of capacity -(NVOC) measures the unit profit of a specific technology, calculated as -the difference between generator revenue and costs, then normalized by -the installed capacity. The typical unit is dollars per megawatt -($/MW).

-

Both of these two metrics are normalized metrics; because the -denominators vary broadly for different generator types, they may not -reflect the competitiveness of technologies consistently. Therefore, we -report a third type of economic viability metric, namely system -profitability metrics, which are essentially unitless functions of the -ratio between values and costs. Examples include profitability index -(value/cost) and return on investment (value/cost minus one). We report -both metrics in ReEDS, acknowledging that there are other formats of -system profitability metrics.

-

These economic viability metrics help explain investment decisions in -the model. Specifically, for all types of new investment in a certain -model year, the model considers all the costs to build and operate a -certain technology as costs, and the contribution of the technology to -all binding constraints as values (i.e., service provision). Typical -value sources are discussed above in Technology Value. In calculations of -economic viability metrics, however, other types of “values” -are included to fully reflect model decisions. For example, an increase -of ancillary service requirements that are due to higher wind -penetration is counted as a negative value stream for wind, and it is -included in the metrics calculation here. Therefore, these metrics fully -reflect all the model constraints related to the investment -decision.

-
-
-
-
-

Model Linkages

-
-

ReEDS-PLEXOS

-

The ReEDS reduced-form dispatch and variable renewable parameterization -aims to represent enough operational detail for realistic capacity -expansion decisions, but the model cannot explicitly represent detailed -power system operations. To verify the feasibility of ReEDS solutions -and better inform its representation of system operation, NREL has -developed utilities to implement a ReEDS capacity expansion solution for -any solve year in the PLEXOS production-cost model -(PCM).

-

PLEXOS is a commercial PCM tool capable of representing individual -generating units and transmission nodes for least-cost dispatch -optimization at hourly or subhourly time resolution. It can incorporate -unit-commitment decisions and detailed operating constraints (e.g., ramp -rates, minimum runtime) to simulate realistic power system operations. -NREL has previously used PLEXOS in several analyses such as the Western -Wind and Solar Renewable Integration Study and the Eastern Renewable -Grid Integration Study [Bloom et al., 2016, Lew et al., 2013].

-

The ReEDS-PLEXOS linkage involves disaggregating the ReEDS solution and -adding necessary parameters for to the resolution necessary for PLEXOS. -To facilitate the translation, the existing linkage maintains the -spatial resolution of ReEDS and operates PLEXOS as a zonal model -matching ReEDS BAs to PLEXOS transmission zones. PLEXOS uses the ReEDS -transmission line capacity, and reactance and resistance are calculated -from ReEDS transmission properties to represent the aggregated -transmission system. Generating capacity within each zone is, however, -converted from aggregate ReEDS capacity to individual units in PLEXOS -using a characteristic unit size for each technology. For consistency, -ReEDS cost and performance parameters are used when possible and -reasonable, but values are taken from the average across WECC data when -parameters are not available from ReEDS or are available but used -inconsistently in ReEDS due to structural differences between the -models.[62]

-

Once the ReEDS solution is converted to a PLEXOS database, one can -simulate hourly dispatch over a full year and compare results with ReEDS -outcomes. A consistent solution builds confidence in the effectiveness -of ReEDS capacity expansion decisions, while inconsistencies and -reliability concerns such as load shedding indicate the need for -improving capacity expansion model structures. Additional details are -available in Frew et al. 2019.

-
-
-

ReEDS-Cambium

-

Leveraging the capabilities of the ReEDS-PLEXOS linkage, a third -model—Cambium—has been developed. Cambium draws from ReEDS and PLEXOS -model solutions to assemble a structured database of hourly cost and -operational data for modeled futures of the U.S. electric sector. In -addition to directly reporting some metrics from both ReEDS and PLEXOS -(e.g., capacity buildouts from ReEDS and generation by technology from -PLEXOS), Cambium post-processes the outputs from both models to develop -new metrics that are designed to be useful for long-term -decision-making, such as a long-run marginal emission -rate.[63]

-

Data sets derived through Cambium can be viewed and downloaded at -https://cambium.nrel.gov/. The documentation for Cambium contains -descriptions of the metrics reported in the databases and the methods -for calculating those metrics.

-
-
-

ReEDS-JEDI

-

A linkage between ReEDS outputs and the Jobs and Economic Development -Impact Models (JEDI) allows the analysis of technology-specific economic -results (jobs, earnings, value added, total output) to ReEDS scenarios. -Currently, linkages have been built for the JEDI land-based wind, -photovoltaics, natural gas, and coal models, so economic results are -limited to these technologies alone. ReEDS outputs of capacity, -generation, fuel use, capital cost, O&M cost, and fuel cost by BA are -processed through the JEDI models to produce state-level economic -results.

-
-
-

ReEDS-reV

-

The ReEDS supply curve for renewable technologies, including onshore -wind, CSP, utility scale PV, and geothermal are produced by reV. The -ReEDS-reV linkage allows for regional ReEDS investment decisions to be -mapped backed to individual reV supply curve sites. Site-specific supply -curve data from reV is binned for the ReEDS supply curve into five spur -line cost bins, from which investment decisions are made. By tracking -the timing and investment decisions within each of these bins, the -ReEDS-rev linkage maps regional capacity back to the individual sites -from which the bins were derived.

-

The resulting siting data is used to further the understanding of the -ReEDS capacity expansion decisions and identify areas for improvement -for resource siting in reV. The ReEDS-reV linkage is a key component in -the translation of ReEDS capacity expansion results to a nodal -production cost modeling databases.

-
-
-
-

References

-
-
-
-[For18] -

Form EIA-860 detailed data with previous form data (EIA-860A/860B). https://www.eia.gov/electricity/data/eia860/, 2018.

-
-
-[ABB13] -

ABB. ABB Velocity Suite. https://new.abb.com/enterprise-software/energy-portfolio-management/market-intelligence-services/velocity-suite, 2013.

-
-
-[ABB18] -(1,2) -

ABB. ABB Velocity Suite. http://new.abb.com/enterprise-software/energy-portfolio-management/market-intelligence-services/velocity-suite, 2018.

-
-
-[Aro14] -

Vipin Arora. Estimates of the price elasticities of natural gas supply and demand in the United States. Technical Report MPRA Paper No. 54232, U.S. Energy Information Administration, 2014.

-
-
-[AHB19] -

Chad R. Augustine, Jonathan L. Ho, and Nathan J. Blair. GeoVision Analysis Supporting Task Force Report: Electric Sector Potential to Penetration. Technical Report NREL/TP-6A20-71833, National Renewable Energy Laboratory, Golden, CO, May 2019. doi:10.2172/1524768.

-
-
-[BADP03] -

R. L. Bain, W. A. Amos, M. Downing, and R. L. Perlack. Biopower Technical Assessment: State of the Industry and Technology. Technical Report NREL/TP-510-33123, National Renewable Energy Laboratory, Golden, CO, 2003.

-
-
-[Bar23] -(1,2,3) -

Galen Barbose. U.S. State Renewables Portfolio & Clean Electricity Standards: 2023 Status Update. Technical Report, Lawrence Berkeley National Laboratory, Berkeley, CA, 2023.

-
-
-[BMK+17] -

Philipp Beiter, Walter Musial, Levi Kilcher, Michael Maness, and Aaron Smith. An Assessment of the Economic Potential of Offshore Wind in the United States from 2015 to 2030. Technical Report NREL/TP-6A20-67675, National Renewable Energy Lab. (NREL), Golden, CO (United States), March 2017. doi:10.2172/1349721.

-
-
-[BS16] -

Philipp Beiter and Tyler Stehly. A Spatial-Economic Cost-Reduction Pathway Analysis for U.S. Offshore Wind Energy Development from 2015-2030. Technical Report NREL/PR-6A20-67204, National Renewable Energy Laboratory, Golden, CO, October 2016.

-
-
-[BG06] -

Mark A. Bernstein and James M. Griffin. Regional differences in the price-elasticity of demand for energy. Technical Report NREL/SR-620-39512, National Renewable Energy Laboratory, Golden, CO, 2006.

-
-
-[BJM+09] -

Nate Blair, Thomas Jenkin, James Milford, Walter Short, Patrick Sullivan, David Evans, Elliot Lieberman, Gary Goldstein, Evelyn Wright, Kamala R. Jayaraman, Boddu Venkatesh, Gary Kleiman, Christopher Namovicz, Bob Smith, Karen Palmer, Ryan Wiser, and Frances Wood. Renewable Energy and Efficiency Modeling Analysis Partnership: An Analysis of How Different Energy Models Addressed a Common High Renewable Energy Penetration Scenario in 2025. Technical Report NREL/TP-6A2-45656, National Renewable Energy Laboratory, Golden, CO, 2009.

-
-
-[BTP+16] -(1,2) -

Aaron Bloom, Aaron Townsend, David Palchak, Joshua Novacheck, Jack King, Clayton Barrows, Eduardo Ibanez, Matthew O'Connell, Gary Jordan, Billy Roberts, Caroline Draxl, and Kenny Gruchalla. Eastern Renewable Generation Integration Study. Technical Report NREL/TP-6A20-64472, National Renewable Energy Laboratory, Golden, CO, August 2016. doi:10.2172/1318192.

-
-
-[BBB+21] -

Gregory Brinkman, Dominique Bain, Grant Buster, Caroline Draxl, Paritosh Das, Jonathan Ho, Eduardo Ibanez, Ryan Jones, Sam Koebrich, Sinnott Murphy, Vinayak Narwade, Joshua Novacheck, Avi Purkayastha, Michael Rossol, Ben Sigrin, Gord Stephen, and Jiazi Zhang. The North American Renewable Integration Study (NARIS): A U.S. Perspective. Technical Report, NREL, 2021.

-
-
-[BCE+20] -(1,2) -

Maxwell Brown, Wesley Cole, Kelly Eurek, Jon Becker, Dave Bielen, Ilya Chernyakhovskiy, Stuart Cohen, Will Frazier, Pieter J. Gagnon, Nathaniel Gates, Daniel Greer, Sai Sameera Gudladona, Jonathan Ho, Paige Jadun, Katherine Lamb, Trieu Mai, Matthew Mowers, Caitlin Murphy, Amy Rose, Anna Schleifer, Daniel Steinberg, Yinong Sun, Nina Vincent, Ella Zhou, and Matthew Zwerling. Regional Energy Deployment System (ReEDS) Model Documentation: Version 2019. Technical Report NREL/TP-6A20-74111, National Renewable Energy Laboratory, Golden, CO, March 2020. doi:10.2172/1505935.

-
-
-[BBW+23] -

Patrick R. Brown, Clayton P. Barrows, Jarrad G. Wright, Gregory L. Brinkman, Sourabh Dalvi, Jiazi Zhang, and Trieu Mai. A general method for estimating zonal transmission interface limits from nodal network data. August 2023. arXiv:2308.03612.

-
-
-[CAR19] -

CARB. California Greenhouse Gas Emissions for 2000 to 2017. Technical Report, California Air Resources Board, 2019.

-
-
-[CRS+13] -

S. Clemmer, J. Rogers, S. Sattler, J. Macknick, and T. Mai. Modeling low-carbon US electricity futures to explore impacts on national and regional water use. Environmental Research Letters, 8(1):015004, 2013. doi:10.1088/1748-9326/8/1/015004.

-
-
-[CBB+19] -

Stuart Cohen, Jonathon Becker, David A. Bielen, Maxwell Brown, Wesley J. Cole, Kelly P. Eurek, Allister Frazier, Bethany A. Frew, Pieter J. Gagnon, Jonathan L. Ho, Paige Jadun, Trieu T. Mai, Matthew Mowers, Caitlin Murphy, Andrew Reimers, James Richards, Nicole Ryan, Evangelia Spyrou, Daniel C. (ORCID:0000000317692261) Steinberg, Yinong Sun, Nina M. (ORCID:0000000221442954) Vincent, and Matthew Zwerling. Regional Energy Deployment System (ReEDS) Model Documentation: Version 2018. Technical Report NREL/TP-6A20-72023, National Renewable Energy Laboratory, Golden, CO, April 2019. doi:10.2172/1505935.

-
-
-[CM22] -

Stuart Cohen and Matthew Mowers. Advanced Hydropower and PSH Capacity Expansion Modeling (Final Report on HydroWIRES D1 Improvements to Capacity Expansion Modeling). Technical Report NREL/TP-6A40-80714, 1877873, MainId:77498, National Renewable Energy Laboratory, July 2022. doi:10.2172/1877873.

-
-
-[CCG+20] -(1,2) -

Wesley Cole, Sean Corcoran, Nathaniel Gates, Daniel Mai, Trieu, and Paritosh Das. 2020 Standard Scenarios Report: A U.S. Electricity Sector Outlook. Technical Report NREL/TP-6A20-77442, National Renewable Energy Laboratory, Golden, CO, 2020.

-
-
-[CEV+18] -

Wesley Cole, Kelly P. Eurek, Nina M. Vincent, Trieu T. Mai, Gregory L. Brinkman, and Matthew Mowers. Operating Reserves in Long-Term Planning Models. Technical Report NREL/PR-6A20-71148, National Renewable Energy Laboratory, Golden, CO, June 2018.

-
-
-[CF20] -(1,2) -

Wesley Cole and Allister Frazier. Cost Projections for Utility-Scale Battery Storage: 2020 Update. Technical Report NREL/TP-6A20-75385, National Renewable Energy Lab. (NREL), Golden, CO (United States), June 2020.

-
-
-[CFG+18] -

Wesley Cole, Bethany Frew, Pieter Gagnon, Andrew Reimers, Jarett Zuboy, and Robert Margolis. Envisioning a low-cost solar future: Exploring the potential impact of Achieving the SunShot 2030 targets for photovoltaics. Energy, 155:690–704, July 2018. doi:10.1016/j.energy.2018.04.166.

-
-
-[CGHM20] -(1,2) -

Wesley Cole, Daniel Greer, Jonathan Ho, and Robert Margolis. Considerations for maintaining resource adequacy of electricity systems with high penetrations of PV and storage. Applied Energy, December 2020.

-
-
-[CLSM16] -

Wesley Cole, Haley Lewis, Ben Sigrin, and Robert Margolis. Interactions of rooftop PV deployment with the capacity expansion of the bulk power system. Applied Energy, 168:473–481, April 2016. doi:10.1016/j.apenergy.2016.02.004.

-
-
-[CME+15] -

Wesley Cole, Trieu Mai, Kelly Eurek, Daniel C. Steinberg, and Robert Margolis. Considering the Role of Solar Generation under Rate-Based Targets in the EPA's Proposed Clean Power Plan. The Electricity Journal, 28(8):20–28, October 2015. doi:10.1016/j.tej.2015.09.002.

-
-
-[CMIJ16] -(1,2) -

Wesley J. Cole, Kenneth B. Medlock III, and Aditya Jani. A view to the future of natural gas and electricity: An integrated modeling approach. Energy Economics, 2016. doi:10.1016/j.eneco.2016.03.005.

-
-
-[CV19] -

Wesley J. Cole and Nina M. (ORCID:0000000221442954) Vincent. Historical Comparison of Capacity Build Decisions from the Regional Energy Deployment System (ReEDS) Model. Technical Report NREL/TP-6A20-71916, National Renewable Energy Lab. (NREL), Golden, CO (United States), February 2019. doi:10.2172/1505552.

-
-
-[DNCG19] -

Paul L. (ORCID:0000000171284643) Denholm, Jacob Nunemaker, Wesley J. Cole, and Pieter J. Gagnon. The Potential for Battery Energy Storage to Provide Peaking Capacity in the United States. Technical Report NREL/TP-6A20-74184, National Renewable Energy Laboratory, Golden, CO, June 2019. doi:10.2172/1530173.

-
-
-[DL17] -

Cheryl A. Dieter and Kristin S. Linsey. Estimated Use of Water in the United States County-Level Data for 2015. 2017. doi:10.5066/F7TB15V5.

-
-
-[DOE11] -

DOE. US billion-ton update: biomass supply for a bioenergy and bioproducts industry. Technical Report ORNL/TM-2011/224, U.S. Department of Energy, 2011.

-
-
-[DOE19] -(1,2) -

DOE. GeoVision: Harnessing the Heat Beneath Our Feet. Technical Report, U.S. Department of Energy, Washington, D.C., 2019.

-
-
-[DOE20] -

DOE. Alternative Fuel Price Report. Technical Report, U. S. Department of Energy, Washington, D.C., July 2020.

-
-
-[DOE18] -

DOER. Electricity Sector Regulations: Fact Sheet. Technical Report, Massachusetts Department of Environmental Protection, Boston, MA, 2018.

-
-
-[EIA13] -

EIA. Updated Capital Cost Estimates for Utility Scale Electricity Generating Plants. Technical Report, U.S. DOE Energy Information Administration, Washington, D.C., 2013.

-
-
-[EIA14] -

EIA. Annual Energy Outlook 2014. Technical Report DOE/EIA-0383(2014), U.S. DOE Energy Information Administration, Washington, D.C., 2014.

-
-
-[EIA15] -

EIA. Electric Power Detailed State Data. http://www.eia.gov/electricity/data/state/, 2015.

-
-
-[EIA17a] -

EIA. Annual Energy Outlook 2017. Technical Report DOE/EIA-0383(2017), U.S. DOE Energy Information Administration, Washington, D.C., 2017.

-
-
-[EIA17b] -

EIA. The Electricity Market Module of the National Energy Modeling System: Model Documentation 2016. Technical Report, U.S. Energy Information Administration, Washington, D.C., July 2017.

-
-
-[EIA19a] -

EIA. Annual Energy Outlook 2019. Technical Report, U.S. Energy Information Administration, Washington, D.C., 2019.

-
-
-[EIA19b] -

EIA. Electric Power Monthly. Technical Report, U.S. Energy Information Agency, Washington, D.C., February 2019.

-
-
-[EPA08] -(1,2) -

EPA. eGRID2007 Version1.1 Year 2005 Summary Tables. Technical Report, U.S. Environmental Protection Agency, Washington, D.C., 2008.

-
-
-[ERC19] -

ERCOT. News Release: ERCOT's reserve margin climbs 2% for summer 2020. http://www.ercot.com/news/releases/show/195806, December 2019.

-
-
-[Fle20] -

Christian Etienne Fleischer. Minimising the effects of spatial scale reduction on power system models. Energy Strategy Reviews, 32:100563, November 2020. doi:10.1016/j.esr.2020.100563.

-
-
-[FCD+20] -

A. Will Frazier, Wesley Cole, Paul Denholm, Daniel Greer, and Pieter Gagnon. Assessing the potential of battery storage as a peaking capacity resource in the United States. Applied Energy, 275:115385, October 2020. doi:10.1016/j.apenergy.2020.115385.

-
-
-[FCD+19] -

Bethany Frew, Wesley Cole, Paul Denholm, Will Frazier, Nina Vincent, and Robert Margolis. Sunny with a Chance of Curtailment: Operating the US Grid with Very High Levels of Solar Photovoltaics. iScience, 21:436447, November 2019. doi:10.1016/ j.isci.2019.10.017.

-
-
-[FCS+17] -

Bethany Frew, Wesley Cole, Yinong Sun, James Richards, and Trieu Mai. 8760-Based Method for Representing Variable Generation Capacity Value in Capacity Expansion Models. In 2017 International Energy Workshop. College Park, MD, 2017. International Energy Workshop.

-
-
-[FFM18] -

Ran Fu, David J. Feldman, and Robert M. Margolis. U.S. Solar Photovoltaic System Cost Benchmark: Q1 2018. Technical Report NREL/PR-6A20-72133, National Renewable Energy Lab. (NREL), Golden, CO (United States), November 2018. doi:10.2172/1484344.

-
-
-[GCFM17] -

Pieter Gagnon, Wesley J. Cole, Bethany Frew, and Robert Margolis. The impact of retail electricity tariff evolution on solar photovoltaic deployment. Electricity Journal, November 2017. doi:10.1016/j.tej.2017.10.003.

-
-
-[GPC+24] -

Pieter Gagnon, An Pham, Wesley Cole, Sarah Awara, Anne Barlas, Maxwell Brown, Patrick Brown, Vincent Carag, Stuart Cohen, Anne Hamilton, Jonathan Ho, Sarah Inskeep, Akash Karmakar, Luke Lavin, Anthony Lopez, Trieu Mai, Joseph Mowers, Matthew Mowers, Caitlin Murphy, Paul Pinchuk, Anna Schleifer, Brian Sergi, Daniel Steinberg, and Travis Williams. 2023 Standard Scenarios Report: A U.S. Electricity Sector Outlook. Technical Report NREL/TP-6A40-87724, National Renewable Energy Laboratory, January 2024.

-
-
-[GHM+19] -

Elisabeth A. Gilmore, Jinhyok Heo, Nicholas Z. Muller, Christopher W. Tessum, Jason D. Hill, Julian D. Marshall, and Peter J. Adams. An inter-comparison of the social costs of air quality from reduced-complexity models. Environmental Research Letters, 14(7):074016, July 2019. doi:10.1088/1748-9326/ab1ab5.

-
-
-[HKM+13] -

Boualem Hadjerioua, Shih-Chieh Kao, Ryan A. McManamay, MD Fayzul K. Pasha, Dilruba Yeasmin, Abdoul A. Oubeidillah, Nicole M. Samu, Kevin M. Stewart, Mark S. Bevelhimer, Shelaine L. Hetrick, Yaxing Wei, and Brennan T. Smith. An Assessment of Energy Potential from New Stream-reach Development in the United States: Initial Report on Methodology. Technical Report ORNL/TM-2012/298, Oak Ridge National Laboratory, Oak Ridge, TN, February 2013.

-
-
-[HMB+20] -(1,2) -

Sofia D. Hamilton, Dev Millstein, Mark Bolinger, Ryan Wiser, and Seongeun Jeong. How Does Wind Project Performance Change with Age in the United States? Joule, 4(5):1004–1020, May 2020. doi:10.1016/j.joule.2020.04.005.

-
-
-[Har17] -

Geoffrey Haratyk. Early nuclear retirements in deregulated U.S. markets: Causes, implications and policy options. Energy Policy, 110:150–166, November 2017. doi:10.1016/j.enpol.2017.08.023.

-
-
-[HJ20] -

Jeremy J. Hargreaves and Ryan A. Jones. Long Term Energy Storage in Highly Renewable Systems. Frontiers in Energy Research, 2020. doi:10.3389/fenrg.2020.00219.

-
-
-[Hee15] -

Jenny Heeter. Cross-state RPS Visualization. http://www.nrel.gov/analysis/docs/index.html, 2015.

-
-
-[HOShaughnessyB21] -

Jenny Heeter, Eric O'Shaughnessy, and Rebecca Burd. Status and Trends in the Voluntary Market (2020 Data). Technical Report, National Renewable Energy Lab, 2021.

-
-
-[Hol16] -

Ed Holt. Potential RPS Markets for Renewable Energy Generators. Technical Report, Ed Holt & Associates, Inc., July 2016.

-
-
-[HDJ+13] -

Marissa Hummon, Paul Denholm, Jennie Jorgenson, David Palchak, Brendan Kirby, and Ookie Ma. Fundamental Drivers of the Cost and Price of Operating Reserves. Technical Report NREL/TP-6A20-58491, National Renewable Energy Laboratory, July 2013.

-
-
-[Hun13] -(1,2) -

Hillard Huntington. EMF 26: Changing the Game? Emissions and Market Implications of New Natural Gas Supplies. Technical Report, Energy Modeling Forum, Stanford University, Stanford, CA, 2013.

-
-
-[JMC+14] -

J. Jacobson, R. Mohammad, K. Cafferty, K. Kenney, E. Searcy, and J. Hansen. Feedstock and Conversion Supply System Design and Analysis. Technical Report INL/EXT-14-33227, Idaho National Lab. (INL), Idaho Falls, ID (United States), September 2014. doi:10.2172/1169237.

-
-
-[JDMT13] -

Jennie Jorgenson, Paul Denholm, Mark Mehos, and Craig Turchi. Estimating the Performance and Economic Value of Multiple Concentrating Solar Power Technologies in a Production Cost Model. Technical Report NREL/TP-6A20-58645, National Renewable Energy Lab. (NREL), Golden, CO (United States), December 2013. doi:10.2172/1260920.

-
-
-[KMS+14] -(1,2) -

Shih Chieh Kao, Ryan A. McManamay, Kevin M. Stewart, Nicole M. Samu, Boualem Hadjerioua, Scott T. DeNeale, Dilruba Yeasmin, M. Fayzul, K. Pasha, Abdoul A. Oubeidillah, and Brennan T. Smith. New Stream-reach Development : A Comprehensive Assessment of Hydropower Energy Potential in the United States. Technical Report GPO DOE/EE-1063, U.S. Department of Energy Wind & Water Power Technologies Office, prepared by Oak Ridge National Laboratory, April 2014.

-
-
-[LSM+14] -

Eric Lantz, Daniel Steinberg, Michael Mendelsohn, Owen Zinaman, Ted James, Gian Porro, Maureen Hand, Trieu Mai, Jeffrey Logan, Jenny Heeter, and Lori Bird. Implications of a PTC Extension on U.S. Wind Deployment. Technical Report NREL/TP-6A20-61663, National Renewable Energy Laboratory, Golden, CO, April 2014.

-
-
-[Laz16] -

Lazard. Lazard's Levelized Cost of Storage - Version 2.0. Technical Report, Lazard, December 2016.

-
-
-[LBI+13] -(1,2,3,4) -

D. Lew, G. Brinkman, E. Ibanez, B. M. Hodge, M. Hummon, A. Florita, and M. Heaney. The Western Wind and Solar Integration Study Phase 2. Technical Report NREL/TP-5500-55588, National Renewable Energy Lab. (NREL), Golden, CO (United States), September 2013. doi:10.2172/1095399.

-
-
-[LSC18] -

Yixian Liu, Ramteen Sioshansi, and Antonio J. Conejo. Hierarchical Clustering to Find Representative Operating Periods for Capacity-Expansion Modeling. IEEE Transactions on Power Systems, 33(3):3029–3039, May 2018. doi:10.1109/TPWRS.2017.2746379.

-
-
-[LLM+13] -(1,2) -

Jeffrey Logan, Anthony Lopez, Trieu Mai, Carolyn Davidson, Morgan Bazilian, and Douglas Arent. Natural gas scenarios in the US power sector. Energy Economics, 40:183–195, 2013.

-
-
-[LCS+23] -

Anthony Lopez, Wesley Cole, Brian Sergi, Aaron Levine, Jesse Carey, Cailee Mangan, Trieu Mai, Travis Williams, Pavlo Pinchuk, and Jianyu Gu. Impact of siting ordinances on land availability for wind and solar development. Nature Energy, 8(9):1034–1043, August 2023. doi:10.1038/s41560-023-01319-3.

-
-
-[LML+21] -(1,2,3) -

Anthony Lopez, Trieu Mai, Eric Lantz, Dylan Harrison-Atlas, Travis Williams, and Galen Maclaurin. Land use and turbine technology influences on wind potential in the United States. Energy, 223:120044, 2021. doi:10.1016/j.energy.2021.120044.

-
-
-[LPG+24] -

Anthony Lopez, Pavlo Pinchuk, Michael Gleason, Wesley Cole, Trieu Mai, Travis Williams, Owen Roberts, Marie Rivers, Mike Bannister, Sophie-Min Thomson, Gabe Zuckerman, and Brian Sergi. Solar Photovoltaics and Land-Based Wind Technical Potential and Supply Curves for the Contiguous United States: 2023 Edition. Technical Report NREL/TP-6A20-87843, National Renewable Energy Laboratory, Golden, CO, January 2024. doi:10.2172/2283517.

-
-
-[LKB14] -

Anna S. Lord, Peter H. Kobos, and David J. Borns. Geologic storage of hydrogen: Scaling up to meet city transportation demands. International Journal of Hydrogen Energy, 39(28):15570–15582, September 2014. doi:10.1016/j.ijhydene.2014.07.121.

-
-
-[MNHH12] -(1,2) -

J. Macknick, R. Newmark, G. Heath, and K. C. Hallett. Operational water consumption and withdrawal factors for electricity generating technologies: a review of existing literature. Environmental Research Letters, 7(4):045802, 2012. doi:10.1088/1748-9326/7/4/045802.

-
-
-[MCN+15] -(1,2) -

Jordan Macknick, Stuart Cohen, Robin Newmark, Andrew Martinez, Patrick Sullivan, and Vince Tidwell. Water constraints in an electric sector capacity expansion model. Technical Report NREL/TP-6A20-64270, National Renewable Energy Laboratory, Golden, CO, July 2015.

-
-
-[MGL+21] -(1,2) -

Galen Maclaurin, Nick Grue, Anthony Lopez, Dona Heimiller, Michael Rossol, Grant Buster, and Travis Williams. The Renewable Energy Potential (reV) Model: A Geospatial Platform for Technical Potential and Supply Curve Modeling. Technical Report NREL/TP-6A20-73067, National Renewable Energy Laboratory, Golden, CO, June 2021.

-
-
-[MMS+20] -

Amber Mahone, Liz Mettetal, John Stevens, Sharad Bharadwaj, Anthony Fratto, Manohar Mogadali, Vignesh Venugopal, Mengyao Yuan, and Arne Olson. Hydrogen Opportunities in a Low-Carbon Future. Technical Report, Energy and Environmental Economics, Inc., San Francisco, CA, 2020.

-
-
-[MCKB15] -

Trieu Mai, Wesley Cole, Venkat Krishnan, and Mark Bolinger. Impact of Federal Tax Policy on Utility-Scale Solar Deployment Given Financing Interactions. Presentation NREL/PR-6A20-65014, National Renewable Energy Laboratory, Golden, CO, September 2015.

-
-
-[MLML21] -

Trieu Mai, Anthony Lopez, Matthew Mowers, and Eric Lantz. Interactions of wind energy project siting, wind resource potential, and the evolution of the U.S. power system. Energy, 2021. doi:10.1016/j.energy.2021.119998.

-
-
-[MMHB14] -

Trieu Mai, David Mulcahy, M. Maureen Hand, and Samuel F. Baldwin. Envisioning a renewable electricity future for the United States. Energy, 65:374–386, February 2014. doi:10.1016/j.energy.2013.11.029.

-
-
-[MWS+12] -

Trieu Mai, R. Wiser, D. Sandor, G. Brinkman, G. Heath, P. Denholm, D. J. Hostick, N. Darghouth, A. Schlosser, and K. Strzepek. Exploration of High-Penetration Renewable Electricity Futures. Vol. 1 of Renewable Electricity Futures Study. Technical Report NREL/TP-6A20-52409-1, National Renewable Energy Laboratory, Golden, CO, 2012.

-
-
-[MGNB22] -

Cara Marcy, Teagan Goforth, Destenie Nock, and Maxwell Brown. Comparison of temporal resolution selection approaches in energy systems models. Energy, 251:123969, July 2022. doi:10.1016/j.energy.2022.123969.

-
-
-[MHMC23] -

Mahdi Mehrtash, Benjamin F. Hobbs, Reza Mahroo, and Yankai Cao. Does Choice of Power Flow Representation Matter in Transmission Expansion Optimization? A Quantitative Comparison for a Large-Scale Test System. IEEE Transactions on Industry Applications, 2023.

-
-
-[MAB+12] -

Bryan K. Mignone, Thomas Alfstad, Aaron Bergman, Kenneth Dubin, Richard Duke, Paul Friley, Andrew Martinez, Matthew Mowers, Karen Palmer, Anthony Paul, Sharon Showalter, Daniel Steinberg, Matt Woerman, and Frances Wood. Cost-effectiveness and Economic Incidence of a Clean Energy Standard. Economics of Energy & Environmental Policy, July 2012. doi:10.5547/2160-5890.1.3.5.

-
-
-[MW12] -

Andrew Mills and Ryan Wiser. An Evaluation of Solar Valuation Methods Used in Utility Planning and Procurement Processes. Technical Report, Lawrence Berkeley National Laboratory, Berkeley, CA, 2012.

-
-
-[Mit20] -

Mitsubishi. Intermountain Power Agency Orders MHPS JAC Gas Turbine Technology for Renewable-Hydrogen Energy Hub. https://power.mhi.com/regions/amer/news/200310.html, 2020.

-
-
-[MWH09] -

Montgomery, Watson, and Harza. Hydropower Modernization Initiative, Phase I, Needs and Opportunities Evaluation and Ranking. Report prepared for the U.S. Army Corps of Engineers Northwest Division Hydroelectric Design Center. Technical Report Contract No. W9127N-08-D-0003, Task Order 0013, U.S. Army Corps of Engineers, 2009.

-
-
-[MSC+19] -

Caitlin Murphy, Yinong Sun, Wesley Cole, Galen Maclaurin, Craig Turchi, and Mark Mehos. The Potential Role of Concentrating Solar Power within the Context of DOE's 2030 Solar Cost Targets. Technical Report NREL/TP-6A20-71912, National Renewable Energy Laboratory, Golden, CO, January 2019.

-
-
-[MS05] -

Frederic H. Murphy and Yves Smeers. Generation capacity expansion in imperfectly competitive restructured electricity markets. Operations research, 53(4):646–661, 2005.

-
-
-[MBS+19] -

Walter Musial, Philipp Beiter, Paul Spitsen, Jacob Nunemaker, and Vahan Gevorgian. 2018 Offshore Wind Technologies Market Report. Technical Report 2019, U. S. Department of Energy, Washington, D.C., 2019.

-
-
-[NEB18] -

NEB. Canada's Energy Futures 2018: Energy Supply and Demand Projections through 2040. Technical Report NE2-12/2015E-PDF, National Energy Board, 2018.

-
-
-[NER16] -(1,2) -

NERC. Glossary of Terms Used in NERC Reliability Standards. Technical Report, North American Electric Reliability Corporation, 2016.

-
-
-[NRE19] -(1,2) -

NREL. 2019 Annual Technology Baseline. Technical Report, National Renewable Energy Laboratory, Golden, CO, 2019.

-
-
-[NRE20] -(1,2,3) -

NREL. 2020 Annual Technology Baseline. Technical Report, National Renewable Energy Laboratory, Golden, CO, 2020.

-
-
-[PA21] -

D. D. Papadias and R. K. Ahluwalia. Bulk storage of hydrogen. International Journal of Hydrogen Energy, 46(70):34527–34541, October 2021. doi:10.1016/j.ijhydene.2021.08.028.

-
-
-[PN14] -

Micaela Ponce and Anne Neumann. Elasticities of Supply for the US Natural Gas Market. SSRN Electronic Journal, 2014. doi:10.2139/ssrn.2433002.

-
-
-[PEH+12] -

Mirko Previsic, Jeff Epler, Maureen Hand, Donna Heimiller, Walter Short, and Kelly Eurek. The future potential of wave power in the United States. Technical Report, RE Vision Consulting, August 2012.

-
-
-[RH22] -

Lina Reichenberg and Fredrik Hedenus. The error induced by using representative periods in capacity expansion models: system cost, total capacity mix and regional capacity mix. Energy Systems, 2022. doi:10.1007/s12667-022-00533-4.

-
-
-[RC17] -

James Richards and Wesley J. Cole. Assessing the impact of nuclear retirements on the U.S. power sector. The Electricity Journal, 30(9):14–21, November 2017. doi:10.1016/j.tej.2017.10.007.

-
-
-[RJG+20] -(1,2) -

Mark F. Ruth, Paige Jadun, Nicholas Gilroy, Elizabeth Connelly, Richard Boardman, A. J. Simon, Amgad Elgowainy, and Jarett Zuboy. The Technical and Economic Potential of the H2@Scale Hydrogen Concept within the United States. Technical Report NREL/TP-6A20-77610, National Renewable Energy Laboratory, Golden, CO, October 2020.

-
-
-[SXL+18] -

Manajit Sengupta, Yu Xie, Anthony Lopez, Aron Habte, Galen Maclaurin, and James Shelby. The National Solar Radiation Data Base (NSRDB). Renewable and Sustainable Energy Reviews, 89:51–60, June 2018. doi:10.1016/j.rser.2018.03.003.

-
-
-[SPH95] -

W. Short, D. J. Packey, and T. Holt. A manual for the economic evaluation of energy efficiency and renewable energy technologies. Technical Report NREL/TP-462-5173, National Renewable Energy Lab., Golden, CO (United States), March 1995. doi:10.2172/35391.

-
-
-[SBHS03] -

Walter Short, Nate Blair, Donna Heimiller, and Vikram Singh. Modeling the Long-Term Market Penetration of Wind in the United States. Technical Report NREL/CP-620-34469, National Renewable Energy Laboratory, Golden, CO, 2003.

-
-
-[SGP+16] -

Benjamin Sigrin, Michael Gleason, Robert Preus, Ian Baring-Gould, and Robert Margolis. The Distributed Generation Market Demand Model (dGen): Documentation. Technical Report NREL/TP-6A20-65231, National Renewable Energy Laboratory, Golden, CO, February 2016.

-
-
-[SMD14] -

Ramteen Sioshansi, Seyed Hossein Madaeni, and Paul Denholm. A Dynamic Programming Approach to Estimate the Capacity Value of Energy Storage. IEEE Transactions on Power Systems, 29(1):395–403, January 2014. doi:10.1109/TPWRS.2013.2279839.

-
-
-[Smi14] -

S. Smith. EPA: Clean Power Plan could increase power sector gas use by 1.2 Tcf in 2020. SNL Financial, June 2014.

-
-
-[SAC+17] -

Brady Stoll, Juan Andrade, Stuart Cohen, Greg Brinkman, and Carlo Brancucci Martinez-Anido. Hydropower Modeling Challenges. Technical Report NREL/TP-5D00-68231, National Renewable Energy Lab. (NREL), Golden, CO (United States), April 2017. doi:10.2172/1353003.

-
-
-[SCB+15] -

Patrick Sullivan, Wesley Cole, Nate Blair, Eric Lantz, Venkat Krishnan, Trieu Mai, David Mulcahy, and Gian Porro. 2015 Standard Scenarios Annual Report: U.S. Electric Sector Scenario Exploration. Technical Report NREL/TP-6A20-64072, National Renewable Energy Laboratory, Golden, CO, July 2015.

-
-
-[SJN+20] -

Yinong Sun, Paige Jadun, Brent Nelson, Matteo Muratori, Caitlin Murphy, Jeffrey Logan, and Trieu Mai. Electrification Futures Study: Methodological Approaches for Assessing Long-Term Power System Impacts of End-Use Electrification. Technical Report NREL/TP-6A20-73336, National Renewable Energy Laboratory, 2020.

-
-
-[TB19] -

Holger Teichgraeber and Adam R. Brandt. Clustering methods to find representative periods for the optimization of energy systems: An initial framework and comparison. Applied Energy, 239:1283–1293, April 2019. doi:10.1016/j.apenergy.2019.02.012.

-
-
-[THM17] -

Christopher W. Tessum, Jason D. Hill, and Julian D. Marshall. InMAP: A model for air pollution interventions. PLOS ONE, 12(4):e0176131, April 2017. doi:10.1371/journal.pone.0176131.

-
-
-[TAB+06] -

Jefferson W. Tester, Brian J. Anderson, Anthony S. Batchelor, David D. Blackwell, Ronald DiPippo, Elisabeth M. Drake, John Garnish, Bill Livesay, Michal C. Moore, Kenneth Nichols, Susan Petty, M. Nafi Toksoz, and Veatch. The future of geothermal energy. Technical Report INL/EXT-06-11746, Idaho National Laboratory, Idaho Falls, ID, 2006.

-
-
-[TMSK18] -(1,2,3) -

Vincent C. Tidwell, Barbie D. Moreland, Calvin R. Shaneyfelt, and Peter Kobos. Mapping water availability, cost and projected consumptive use in the eastern United States with comparisons to the west. Environmental Research Letters, 13(1):014023, January 2018. doi:10.1088/1748-9326/aa9907.

-
-
-[TAM19] -

Peter Tschofen, Inês L. Azevedo, and Nicholas Z. Muller. Fine particulate matter damages and value added in the US economy. Proceedings of the National Academy of Sciences, 116(40):19857–19862, October 2019. doi:10.1073/pnas.1905030116.

-
-
-[Vea12] -

Black & Veatch. Cost and Performance Data for Power Generation Technologies. Technical Report, Black & Veatch Corporation, Overland Park, KS, 2012.

-
-
-[VBailloRR05] -

Mariano Ventosa, Álvaro Ba\'ıllo, Andrés Ramos, and Michel Rivier. Electricity market modeling trends. Energy Policy, 33(7):897–913, May 2005. doi:10.1016/j.enpol.2003.10.013.

-
-
-[Ven14] -

Ventyx. Ventyx Velocity Suite. http://www.ventyx.com/en/solutions/business-operations/business-products/velocity-suite, 2014.

-
-
-[WEC13] -

WECC. 2013 Interconnection-wide Plan Tools and Models. Technical Report, Western Electricity Coordinating Council, September 2013.

-
-
-[WEC15] -

WECC. TEPPC Study Report – 2024 PC1 Common Case. Technical Report, Western Electricity Coordinating Council, July 2015.

-
-
-[WRM08] -

Colin F. Williams, Marshall J. Reed, and Robert H. Mariner. A Review of Methods Applied by the U.S. Geological Survey in the Assessment of Identified Geothermal Resources. Technical Report 2008-1296, U.S. Geological Survey, 2008. doi:10.3133/ofr20081296.

-
-
-[WB19] -(1,2) -

Ryan Wiser and Mark Bolinger. Benchmarking Anticipated Wind Project Lifetimes: Results from a Survey of U.S. Wind Industry Professionals. Technical Report, Lawrence Berkeley National Laboratory, Berkeley, CA, September 2019.

-
-
-[BureauoReclamation11] -

Bureau of Reclamation. Hydropower resource Assessment at Existing Reclamation Facilities. Technical Report, U.S. Department of the Interior, Bureau of Reclamation, Power Resources Office, Denver, CO, March 2011.

-
-
-[CPUC18] -

CPUC. Decision Setting Requirements for Load Serving Entities Filing Integrated Resource Plans. February 2018.

-
-
-[DOE08] -

DOE. 20% Wind Energy by 2030: Increasing Wind Energy's Contribution to U.S. Electricity Supply. Technical Report DOE/GO-102008-2567, U. S. Department of Energy, Washington, D.C., July 2008.

-
-
-[DOE12] -(1,2,3) -

DOE. SunShot Vision Study. Technical Report DOE/GO-102012-3037, U. S. Department of Energy, Washington, D.C., February 2012.

-
-
-[DOE15] -(1,2) -

DOE. Wind Vision: A New Era for Wind Power in the United States. Technical Report DOE/GO-102015-4557, U. S. Department of Energy, Washington, D.C., March 2015.

-
-
-[DOE16a] -(1,2) -

DOE. 2016 Billion-Ton Report: Advancing Domestic Resources for a Thriving Bioeconomy. Technical Report, U.S. Department of Energy, 2016.

-
-
-[DOE16b] -(1,2,3,4,5,6,7) -

DOE. Hydropower Vision: A New Chapter for America's 1st Renewable Electricity Source. Technical Report DOE/GO-102016-4869, U. S. Department of Energy, Washington, D.C., July 2016.

-
-
-[EIA16] -

EIA. Capital Cost Estimates for Utility Scale Electricity Generating Plants. Technical Report, U.S. DOE Energy Information Administration, Washington, D.C., November 2016.

-
-
-[EIA23] -(1,2,3) -

EIA. Annual Energy Outlook 2023. Technical Report, U.S. Energy Information Administration, Washington, D.C., March 2023.

-
-
-[EPAUSEPAgency99] -

EPA (U.S. Environmental Protection Agency). The Benefits and Costs of the Clean Air Act, 1990 to 2010. U.S. Environmental Protection Agency. Technical Report EPA-410-R-99-001, U.S. Environmental Protection Agency, 1999.

-
-
-[EPAUSEPAgency14] -

EPA (U.S. Environmental Protection Agency). Mortality Risk Valuation. https://www.epa.gov/environmental-economics/mortality-risk-valuation, April 2014.

-
-
-[EPA14] -(1,2) -

EPA. 40 CFR Parts 122 and 125. Technical Report Vol. 79, U.S. Environmental Protection Agency, 2014.

-
-
-[NationalRELaboratory20] -

National Renewable Energy Laboratory. Annual Technology Baseline 2020. https://atb.nrel.gov/electricity/2020/data.php, 2020.

-
-
-[NERC10] -(1,2) -

NERC. 2010 Long-term reliability assessment. Technical Report, North American Electric Reliability Corporation, October 2010.

-
-
-[NERC21] -

NERC. 2021 Long-Term Reliability Assessment. Technical Report, North American Electric Reliability Corporation, 2021.

-
-
-[NicholasSteckler17] -

Nicholas Steckler. Half of U.S. Nuclear Power Plants Are Underwater. Technical Report, BloombergNEF, 2017.

-
-
-[NRCNationalRCouncil10] -

NRC (National Research Council). Hidden Costs of Energy: Unpriced Consequences of Energy Production and Use. National Academies Press, Washington, D.C., May 2010. ISBN 978-0-309-14640-1. doi:10.17226/12794.

-
-
-[NREL12] -

NREL. Renewable Electricity Futures Study. Technical Report, National Renewable Energy Laboratory, Golden, CO, 2012.

-
-
-[NREL23] -(1,2,3,4,5,6) -

NREL. 2023 Annual Technology Baseline. Technical Report, National Renewable Energy Laboratory, Golden, CO, 2023.

-
-
-[USCBureau22] -

U.S. Census Bureau. 2022 TIGER/Line Shapefiles. https://www.census.gov/geographies/mapping-files/time-series/geo/tiger-line-file.html, 2022.

-
-
-[UnionoCScientists12] -(1,2) -

Union of Concerned Scientists. UCS EW3 Energy-Water Database V.1.3. www.ucsusa.org/ew3database, 2012.

-
-
-[USEIA18] -

USEIA. Thermoelectric cooling water data. https://www.eia.gov/electricity/data/water/, 2018.

-
-
-
-
-
-

Appendix

-
-

Natural Gas Supply Curves

-

The ReEDS model does not explicitly model the U.S. natural gas (NG) -system, which involves multiple sectors of the economy and includes -complex infrastructure and markets. Rather, a regional supply curve -representation is a used to approximate the NG system as it interacts -with the electric sector. For more information on the impact of natural -gas representation in ReEDS, see Cole et al. -2016.

-

The premise of using regional supply curves is that the price in each -region will be a function of both the regional and national NG demand. -The supply curves are parameterized from AEO scenarios for each of the -nine EIA census divisions (see Fig. 19). Two methods exist to -parameterize the natural gas supply curves and both are discussed here. -The first method which involves estimating a linear regression of prices -on regional and national quantities has been used in previous version in -ReEDS and is discussed first. The second method is relatively new to -ReEDS and involves parameterizing a constant elasticity of supply curve -and is discussed second. Through multiple tests, we have found minimal -differences in results between the two versions (1% or less of a change -in national generation by technology).

-

Linear Regression Approach

-

The AEO scenarios were used to estimate parameters for the following NG -price-consumption model:

-
-_images/ng-price-consumption-model.png -
-

Fig. 49 [1]

-
-
-

where Pi,j is the price of natural gas (in $/MMBtu) in -region i and year j, the α parameters are the intercept terms of -the supply curves with adjustments made based on region -(αi), year (αj), and the region-year -interaction (αi,j), βnat is the coefficient -for the national NG demand (Qnat, in quads), -βi is the coefficient for the regional NG demand -(Qi,j) in region i. Note that the four α parameters in -[1] can in practice be represented using only -αi,j.

-

The β terms are regressed from AEO2014 scenarios, with nine of the 31 -AEO2014 scenarios removed as outliers [EIA, 2014]. These outlier -scenarios typically include cases of very low or very high natural gas -resource availability, which are useful for estimating NG price as a -function of supply but not for estimating NG price as a function of -demand—for given supply scenarios. The national and regional β terms are -reported in Fig. 50. We made a specific post-hoc adjustment to the -regression model’s outputs for one region; the βi term for the West -North Central division was originally an order of magnitude higher than -the other βi values because the West North Central usage in the -electricity sector is so low (0.05 quad[64] in 2013, compared to -~0.5 quad or more in most regions). The overall natural gas usage (i.e., -not just electricity sector usage) in West North Central is similar to -the usage in East North Central, so intuitively it makes sense to have a -βi for West North Central relatively close to that of East North -Central. We therefore manually adjusted the West North Central βi term -to be 0.6 (in 2004$/MMBtu/quad) and recalculated the alpha terms with -the new beta to achieve the AEO2014 target prices. The situation in West -North Central whereby such a small fraction of NG demand goes to -electricity is unique; we do not believe that the other regions warrant -similar treatment.

-
-_images/census-division-values.png -
-

Fig. 50 β values for the nine census divisions

-
-
-

The “National” value at the far left is βnat. A β of 0.2 -means that if demand increases by one quad, the price will increase by -$0.20/MMBtu (see Equation [1]).

-

The α terms are then regressed for each individual scenario assuming -the same β values for all scenarios. Although the β terms are -derived from AEO2014 data, α terms are regressed using AEO2018 data -for the scenario they are intended to represent [EIA, 2019]. Thus, we -assume natural gas price elasticity has remained constant while price -projections shift over time as represented by the α -values.

-

Comparison of Elasticities from Regression Approach to Literature Values

-

Technical literature tends to report the price elasticity of supply and -the price elasticity of demand, which are estimates of the supply and -demand, respectively, of a good given a change in price. In the -formulation given by Equation [1], we attempt to estimate a value that -is similar to the price elasticity of demand—we estimate a change in -price given a change in demand. Therefore, we present here a comparison -against the price elasticity of demand as the closest available proxy, -noting however that it is not necessarily identical to estimates of β. -Price elasticity of demand is typically negative but is reported here as -a positive number for convenience.

-

External sources are varied and often vague in their estimates of price -sensitivity of natural gas. Using the reported domestic NG market demand -given for 2012 in AEO2014, the β values reported here yield an overall -NG sector elasticity value of 0.36–0.92 (higher values of β correspond -to lower elasticity values). Arora 2014 estimated the price elasticity -of demand for NG to be 0.11–0.70, depending on the granularity and time -horizon of the NG price data considered. Bernstein and Griffin 2006 -examined the price elasticity of demand for residential NG usage, and -they estimated the long-run elasticity to be 0.12–0.63 depending on the -region. The Energy Modeling Forum at Stanford University reports NG -price elasticity of demand for 13 different energy models [Huntington, 2013]. -The reported elasticity ranges from 0 to 2.20 depending on the -year, model, and scenario considered. For the NEMS model, which is used -for the AEO, the elasticity ranges from 0.22 to 0.81 depending on the -year and scenario [Huntington, 2013].

-

The EPA’s proposed Clean Power Plan included a projection that natural -gas usage will increase by 1.2 quads in 2020, resulting in an 8%–12% -increase in NG prices for the electric sector [Smith, 2014]. This -corresponds to a βnat of 0.38–0.51 in -2004$/MMBtu/quad.

-

Constant Elasticity of Supply

-

The second method for representing gas price adjustments leverages a -constant elasticity of supply curve for census division prices as a -function of the quantities consumed. The general form of the equation -relies on a reference price (\(\overline{p}\)), a reference quantity -(\(\overline{q}\)), and a price elasticity of supply (\(\epsilon\))[65] to -determine the endogenous price (\(p\)) based on an endogenous quantity -(\(q\)) such that:

-
-\[p = \overline{p}\left( \frac{q}{\overline{q}} \right)^{\epsilon}\]
-

When parameterizing for the census division representations, the supply -curve should reflect the change in price given a change in the census -division’s quantity consumed in the electricity sector. To the best of -our knowledge, no published studies estimate the elasticity of supply -for natural gas specific to each sector and region. Therefore, the -calibrated curve needs to consider the change in the census division’s -price given a change in the consumption of natural gas in the region’s -electricity sector with respect to other regions and sectors. To do -this, the reference price, numerator, and denominator in the previous -equation are adjusted to reflect the consumption change only in the -electricity sector. Explicitly, the constant elasticity of supply -parameters are now indexed by census division (\(r\)) and sector -\(s \in \{ electricity,\ \ industrial,\ \ residential,\ \ commercial,\ \ vehicles\}\)). -The equation used to populate the supply curve in the model -becomes:

-
-\[p_{ele,r} = {\overline{p}}_{ele,r}\left( \frac{\sum_{s^{'} \notin ele,r^{'} \notin r}^{}{\overline{q}}_{s^{'},r^{'}} + q_{ele,r}}{\sum_{s,r}^{}{\overline{q}}_{s,r}} \right)^{\epsilon}\]
-

A potential addition to this representation, included as a switch in -the model, also includes national price adjustments as deviations from -the reference point. By denoting the national price as \(p_{ele,nat}\), -the deviation from the benchmark price based on national quantities -consumed in the electricity sector can be computed -as:

-
-\[\Delta p_{ele,nat} = {\overline{p}}_{ele,nat}\left( 1 - \frac{\sum_{s^{'} \notin ele,r}^{}{{\overline{q}}_{s^{'},r} + \sum_{r}^{}q_{ele,r}}}{\sum_{s,r}^{}{\overline{q}}_{s,r}} \right)^{\epsilon}\]
-
-
-

Seasonal Natural Gas Price Adjustments

-

We use natural gas futures prices to estimate the ratio of winter to -non-winter natural gas prices to implement seasonal gas price -differences in ReEDS. We chose futures prices for two reasons: (1) ReEDS -represents a system with no unforeseen disturbances, which is similar to -futures prices and (2) historical natural gas prices have fluctuated -greatly since the deregulation of natural gas -prices.

-

Fig. 51 shows the cyclical nature of the natural gas futures prices. -Fig. 52 breaks the same prices out into seasons, showing that the -non-winter seasons have nearly the same price while wintertime prices -are consistently higher. Wintertime prices are on average 1.054 times -higher than non-winter prices. The standard deviation of this price -ratio is 0.004, indicating that the ratio shows very little year-to-year -variation.

-
-_images/natural-gas-futures-prices.png -
-

Fig. 51 Natural gas futures prices from the New York Mercantile Exchange for July 10, 2014

-
-
-

The prices show the higher wintertime prices and the cyclical nature of -the prices.

-
-_images/natural-gas-futures-prices-by-season.png -
-

Fig. 52 Natural gas futures prices from Fig. 51 separated by season.

-
-
-

Non-winter prices are nearly the same while wintertime prices are -consistently higher.

-

A seasonal natural gas price multiplier is calculated in ReEDS based on -the natural gas price ratio such that wintertime prices are 1.054 times -higher than non-winter prices without changing the year-round average -price. Mathematically, this can be expressed as

- - - - - - - - - - - - - - - - - -

$\(P_{year - round} = W_{winter}P_{winter} + \left( 1 - W_{winter} \right)P_{non - winter}\)$

[2]

$\(P_{winter} = 1.054P_{non - winter}\)$

[3]

$\(P_{winter} = \rho P_{year - round}\)$

[4]

$\(P_{non - winter} = \sigma P_{year - round}\)$

[5]

-

where P is the natural gas price for the period indicated by the -subscript, Wwinter is the fraction of natural gas consumption -that occurs in the winter months, and \(\rho\) and \(\sigma\) are the -seasonal multipliers for winter and non-winter, respectively. The -multipliers \(\rho\) and \(\sigma\) are determined by solving Equations -[2] through [5].

-
-
-

Capital Cost Financial Multipliers

-

The financial multiplier represents the present value of revenue -requirements necessary to finance a new investment, including -construction financing, return to equity holders, interest on debt, -taxes, and depreciation. The formula is based on [Short et al., 1995].

-
-_images/capital-cost-financial-multipliers.png -
-
    -

  1. Construction cost multiplier: additional cost for finance -construction

    2. -

  2. Financing multiplier: adjust required returns for -diversifiable risk

    3. -

  3. Depreciation Expense: reduce the taxable income by -the depreciation expense

    4. -

  4. Depreciable Basis: reduce the depreciable -basis due to the investment tax credit

    5. -

  5. Investment tax credit: reduce -the tax liability by the ITC

    6. -

  6. Taxes: additional revenues are required -to pay taxes

    7. -
-

Construction Cost Multiplier: The construction cost multiplier -(CCmult) captures the cost to finance the construction of the -plant at construction interest rate i. We use a mid-year discounting -and account for the deduction of interest payments for -taxes.

-
-\[CC_{mult} = 1 + \sum_{t}^{}{x_{t}\ \bullet \left\{ (1\ + \ i)^{t} - \ 1 \right\} \bullet (1 - T)}\]
-

The derivation of the construction cost multiplier is given -below.

-

The total payment (TP) required to finance x percent of -construction investment (Inv) at interest rate i in construction -year *t—*where t is defined relative to the in-service date (t=0 is -the final year of construction; t=1 is penultimate year of construction; -etc.)—is the following:

-
-\[{TP}_{t} = \ x_{t}\ \bullet \ Inv\ \bullet \ (1\ + \ i)^{t}\]
-

Define the interest payment (I) in year t as a function of the -total payment (TP) and the principal payment -(P):

-
-\[I_{t}\ = \ {TP}_{t}\ - \ P_{t}\]
-

\(\ \ \ \ \ = \ x_{t}\ \bullet \ Inv\ \bullet \ (1\ + \ i)^{t}\ - \ x_{t}\ *\ Inv\)

-

\(\ \ \ \ \ = \ x_{t}\ \bullet \ Inv\ \bullet \left\{ (1\ + \ i)^{t}\ - \ 1 \right\}\)

-

The tax savings (S) from interest deductions in year t at tax rate -T is equal to:

-
-\[S_{t}\ = \ I_{t}\ \bullet T\]
-

Therefore, the absolute net change in the investment cost due to -construction financing is the interest payments less the tax -savings:

-
-\[\Delta\ cost\ (absolute)\ = \sum_{t}^{}{I_{t} - S_{t}}\]
-
-\[= \sum_{t}^{}{I_{t} - I_{t} \bullet T}\]
-
-\[= \sum_{t}^{}{I_{t} \bullet (1 - T)}\]
-
-\[= \sum_{t}^{}{x_{t}\ \bullet \ Inv\ \bullet \left\{ (1\ + \ i)^{t} - \ 1 \right\} \bullet (1 - T)}\]
-

Finally, the total relative change in the investment cost due to -construction financing is:

-

\(\Delta\ cost\ (relative)\) =

-
-\[= \left( Inv + \sum_{t}^{}{I_{t} - S_{t}} \right)\ /\ Inv\ \]
-
-\[= 1 + \frac{1}{Inv} \bullet \sum_{t}^{}{x_{t}\ \bullet \ Inv\ \bullet \left\{ (1\ + \ i)^{t} - \ 1 \right\} \bullet (1 - T)}\]
-
-\[= 1 + \sum_{t}^{}{x_{t}\ \bullet \left\{ (1\ + \ i)^{t} - \ 1 \right\} \bullet (1 - T)}\]
-

Financing Multiplier: The financing multiplier (not to be confused -with the financial multiplier) is an adjustment to reflect either higher -or lower returns to capital, relative to the system-wide average return -to capital. Conceptually, it is a multiplier that reflects the total -present-value of a stream of higher (or lower) payments to capital, -relative to what the payments would be at the system’s average cost of -capital. For example, if a technology’s WACC (\(WACC_{tech})\) is 7% and -the system-wide WACC is 5% (\(WACC_{sys})\), and the technology is being -evaluated for a 20-year horizon (l) at a real discount rate of 5% -(\(d_{r})\), the financing multiplier (\({fin}_{mult})\) would be 1.25, per -the equation below. This multiplier represents that the total -present-value of the returns to capital for this technology must be -higher (by an amount equal to 25% of the initial investment), relative -to a technology with average financing terms. The difference is the -technology WACC and system WACC represents the difference is returns to -capital due to diversifiable risk.

-
-\[{fin}_{mult} = 1 + \left( WACC_{tech} - WACC_{sys} \right) \bullet \frac{1 - \frac{1}{\left( {1 + d}_{r} \right)^{l}}}{d_{r}}\]
-

To derive the above equation, begin with the definition of the capital -recovery factor (CRF) for real discount rate (\(d_{r})\) and economic -horizon (l):

-
-\[CRF = \frac{Annuity}{Present\ Value\ of\ Annunity} = \frac{d_{r}}{1 - \frac{1}{\left( {1 + d}_{r} \right)^{l}}}\]
-
-\[Present\ Value\ of\ Annuity = \frac{1}{CRF} \bullet Annuity\]
-

Therefore, for every dollar invested in a technology, the absolute -difference in required return is:

-

\(\Delta\ returns\ (absolute) = \$ 1 \bullet WACC_{tech} \bullet \frac{1}{CRF} - \$ 1 \bullet WACC_{sys}*\frac{1}{CRF}\)

-

Finally, the relative difference in required return per dollar invested -is:

-
-\[\Delta\ returns\ (relative) = \frac{\$ 1 + \Delta}{\$ 1} = 1 + \Delta\]
-

Depreciation Expense: The present value of depreciation (PVdepr) -expense is computed based on the fraction of the plant value that is -depreciable in each year. All investments use a MACRS depreciation -schedule with \(f_{t}^{depr}\) representing deprecation fraction in year -t. This depreciation is sheltered from taxes, which is reflected by the -term \(1 - T*PV_{depr}\) in the financial multiplier equation -above.

-
-\[PV_{depr} = \sum_{t}^{}{\frac{1}{\left( 1 + d_{n} \right)^{t}} \bullet f_{t}^{depr}}\]
-

Depreciable Basis: The eligible cost basis for MACRS depreciation -expense is reduced by one-half the effective value of the tax -credit:

-
-\[PV_{depr}*\left( 1 - \frac{{ITC}_{eff}}{2} \right)\]
-

Investment Tax Credit: The value of the ITC is reduced, to reflect -the costs of monetizing it (\(m_{ITC}\)). The effective investment tax -credit value (\({ITC}_{eff})\) reduces the tax burden of the -investments.

-
-\[{ITC}_{eff} = ITC \bullet m_{ITC}\]
-

Taxes: The denominator term of the financial multiplier equation, -“1-T”, reflects the additional revenues necessary to pay taxes. The tax -burden is adjusted for depreciation expenses as well as the effective -investment tax credit.

-

Weighted Average Cost of Capital: The technology-agnostic, nominal -discount rate is represented as the average WACC. Where, df -is the debt fraction, roren is the nominal rate of return -on equity, T is the effective tax rate, and In is the -nominal interest rate on debt.

-
-\[d_{n} = (1 - df)*{rore}_{n} + (1 - T)*df*I_{n}\]
-
-
-

Present Value of Direct Electric Sector Cost

-

The equations in this section are used to calculate the present value -cost of building and operating the system for some defined economic -analysis period. To calculate the present value of total system cost, -the cost in each future year \(t\) is discounted to the initial year of -the economic analysis period, \(t_{0}\), by a social discount rate, -\(d_{social}\). The real social discount rate used here for present value -calculation is different from the investment discount rate assumptions, -or cost of capital (WACC) assumptions.

-

The present value, or \(PV\) in the equation, consists of two cost -components: 1) the present value of all operational costs in the model -for the analysis period, \(PV_{operational}\), including fixed and -variable operating and maintenance costs for all sectors, as well as -fuel costs and 2) the present value of all new capital investments, -\(PV_{capital}\). The present value of energy system costs is then -calculated as:

-
-\[PV = PV_{operational} + PV_{capital}\]
-

Operational costs, \(PV_{operational}\), and capital costs -category,\(\ PV_{capital}\), are discounted from year \(t\) by -\(\frac{1}{\left( 1 + d_{social} \right)^{t - t_{0}}}\) for each year in -the analysis period:

-
-\[PV_{operational} = \sum_{t = t_{0}}^{t_{f}}{C_{op,t} \times \frac{1}{\left( 1 + d_{social} \right)^{t - t_{0}}}}\]
-
-\[PV_{capital} = \sum_{t = t_{0}}^{t_{f}}{C_{cap,t} \times \frac{1}{\left( 1 + d_{social} \right)^{t - t_{0}}}}\]
-

where \(C_{op,t}\) is the operational costs in year t, and \(C_{cap,t}\) is -the capital costs in year \(t\). For all ReEDS system cost results, we -assume the operational costs for the non-modeled year are the same as -the closest model year.

-

In this present value calculation, the economic analysis period is -2018–2050. The social discount rate used for present value calculations, -\(d_{social}\), is assumed to be 7% (real). This is different from the -WACC assumption for investment decisions

-
-
-

Marginal Electricity Prices

-

ReEDS marginal “competitive” electricity prices are derived from the -linear programming formulation.

-

In standard form, the primal formulation of a linear program -is:

-
-\[(P)\ \ \ \ \min{c^{T}x}\]
-
-\[{s.t.}{\ \ \ \ \ Ax \geq b}\]
-
-\[\ \ \ \ \ \ \ \ \ \ \ \ \ \ x \geq 0\]
-

The associated dual formulation of the primal -is:

-
-\[(D)\ \ \ \ \max{y^{T}b}\]
-
-\[{s.t.}{\mathbf{\ \ \ \ \ }y^{T}A \leq c^{T}}\]
-
-\[\ \ \ \ \ \ \ \ \ \ \ \ \ \ y \geq 0\]
-

Consider a simplified formulation of the ReEDS model with a subset of -constraints: (1) resource limits, (2) capacity limits, (3) supply/demand -balance, (4) planning reserve margin requirement, (5) operating reserve -requirement, and (6) national and/or state-level RPS requirements. The -primal formulation is:

-

Parameters

-

\(capcost_{i}\): capital cost of model plant i ($/MW)

-

\(vomcost_{i}\): variable O&M cost of model plant i ($/MWh)

-

\(s_{i}\): available supply of model plant i (MW)

-

\(load\): electric load (MW)

-

\(cv_{i}\): capacity value of model plant i (MW)

-

\(f^{prm}\): planning reserve margin (unitless)

-

\(f^{or}\): operating reserve requirement (unitless)

-

\(f^{RPS}\): national and/or state-level RPS requirement (unitless)

-

Variables

-

\(C_{i}\): capacity of model plant i (MW)

-

\(G_{i}\): generation of model plant i (MWh)

-

\(OR_{i}\): operating reserve allocation of plant i (MWh)

-
-\[minimize\ \sum_{i}^{}{capcost_{i} \bullet C_{i} + vomcost_{i} \bullet G_{i}}\]
-

Subject to:

-
-\[C_{i} \leq s_{i}\ \ \ \ \ \forall i\ \ \ \ \ \lbrack 1\rbrack\]
-
-\[\frac{G_{i}}{8,760} + \frac{OR_{i}}{8,760} - C_{i} \leq 0\ \ \ \ \ \forall i\ \ \ \ \ \lbrack 2\rbrack\]
-
-\[\sum_{i}^{}{G_{i} = load}\ \ \ \ \ \lbrack 3\rbrack\]
-
-\[\sum_{i}^{}{{cv_{i} \bullet C}_{i} \geq \frac{\left( 1 + f^{prm} \right)}{8760} \bullet load}\ \ \ \ \ \ \lbrack 4\rbrack\]
-
-\[\sum_{i}^{}{OR_{i} \geq f^{or} \bullet load}\ \ \ \ \ \lbrack 5\rbrack\]
-
-\[\sum_{i \in RE}^{}{G_{i} \geq f^{RPS} \bullet load}\ \ \ \ \ \lbrack 6\rbrack\]
-
-\[C_{i}, G_{i},OR_{i} \geq 0\ \ \ \ \ \forall i \ \ \ \ \ \lbrack 7\rbrack \]
-

Constraints [1] define the resource limits for each model plant. -Constraints [2] limit how capacity is allocated for each model plant -(i.e., for energy or reserves). Constraint [3] requires the total -generation supplied to equal the load. Constraint [4] ensures the -total firm capacity meets the planning reserve margin requirement. -Constraint [5] ensures the total operating reserves meet the operating -reserve requirement. Constraint [6] requires that total generation -from renewable technologies meets the state-level and national RPS -requirements.

-

From the dual formulation of the primal, the objective function is*:*

-
-\[y^{T}b = y_{1} \bullet s + y_{2} \bullet 0 + y_{3} \bullet load + y_{4} \bullet \frac{(1 + prm)}{8760} \bullet load + y_{5} \bullet f^{or} \bullet load + y_{6} \bullet f^{RPS} \bullet load\]
-

Reformulating the primal with Constraints [3], [4], [5], and -[6] “linked” with a “load” variable, L, an alternative, but -equivalent, primal formulation is the following:

-
-\[minimize\ \sum_{i}^{}{capcost_{i} \bullet C_{i} + vomcost_{i} \bullet G_{i}}\]
-

Subject to:

-
-\[C_{i} \leq s_{i}\ \ \ \ \ \forall i\ \ \ \ \ \lbrack 1\rbrack\]
-
-\[\frac{G_{i}}{8760} + \frac{OR_{i}}{8760} - C_{i} \leq 0\ \ \ \ \ \forall i\ \ \ \ \ \lbrack 2\rbrack\]
-
-\[\sum_{i}^{}{G_{i} - L \geq 0}\ \ \ \ \ \lbrack 3^{'}\rbrack\]
-
-\[\sum_{i}^{}{{cv_{i} \bullet C}_{i} - \frac{\left( 1 + f^{prm} \right)}{8760} \bullet L \geq}0\ \ \ \ \ \ \lbrack 4^{'}\rbrack\]
-
-\[\sum_{i}^{}{OR_{i} - f^{or} \bullet L \geq 0}\ \ \ \ \ \lbrack 5'\rbrack\]
-
-\[\ \sum_{i \in RE}^{}{G_{i} - f^{RPS} \bullet L} \geq 0\ \ \lbrack 6'\rbrack\]
-
-\[C_{i}, G_{i},OR_{i} \geq 0\ \ \ \ \ \lbrack 7\rbrack\]
-
-\[L = load\ \ \ \ \ \lbrack 8'\rbrack\]
-

From the dual formulation of the alternative primal, the objective -function is:

-
-\[y^{T}b = y_{1} \bullet s + y_{2} \bullet 0 + y_{3^{'}} \bullet 0 + y_{4^{'}} \bullet 0 + y_{5^{'}} \bullet 0 + y_{6^{'}} \bullet 0 + y_{8^{'}} \bullet load\]
-

Equating the dual objective functions from the two equivalent primal -formulations, we find that the marginal off the linking constraint -[8’] is a blending of all constraints containing the “load” variable, -including, constraints [3], [4], [5], and [6]:

-
-\[y_{8^{'}} \bullet load\mathbf{=}y_{3} \bullet load + y_{4} \bullet \frac{\left( 1 + f^{prm} \right)}{8760} \bullet load + y_{5} \bullet f^{or} \bullet load + y_{6} \bullet f^{RPS} \bullet load\]
-
-\[y_{8^{'}} = y_{3} + y_{4} \bullet \frac{\left( 1 + f^{prm} \right)}{8760} + y_{5} \bullet f^{or} + y_{6} \bullet f^{RPS}\]
-

Therefore, we define the marginal off the linking constraint -\(\lbrack y_{8^{'}}\rbrack\) as the “all-in” marginal price of electricity -(i.e., change in total cost [objective function] given a small change -in load). This marginal electricity price includes the energy price, -capacity price, operating reserve prices, and potential RPS prices. -Marginal electricity prices are reported at BA level with different -requirement categories. These prices can be aggregated at different -regional level, weighted by corresponding requirement quantities for -certain category.

-
-
-

Average Electricity Prices

-

Average electricity prices are calculated as the annualized total costs -of building and operating the system in certain geographic area, divided -by the electricity load in that area. At national level, the prices are -calculated as:

-
-\[p(costtype,\ year) = \frac{systemcost_{costtype,year}}{load_{year}}\]
-

where system costs include both annualized capital and operational -costs. Annualized costs for existing (i.e. pre-2010) power plants are -also considered given plants’ initial investment costs and the built -year.

-

At BA-level, average electricity prices also consider the impact of -energy and capacity trading:

-
-\[p(costtype,BA,year)\]
-
-\[ = ca{pital}_{costtype,BA,year} + o{peartional}_{costtype,BA,year}\]
-
-\[ + \lbrack \sum_{n}^{}{import_{n,p,h,year} \times price_{n,h,year}}\]
-
-\[ - \sum_{n}^{}{export_{p,n,h,year} \times price_{p,h,year}} \rbrack _{energy} \]
-
-\[ + \lbrack \sum_{n}^{}{import_{n,p,szn,year} \times price_{n,szn,year}} \]
-
-\[ - \sum_{n}^{}{export_{p,n,h,year} \times price_{p,szn,year}} \rbrack _{capacity}\]
-

Where n, p and BA all indicate balancing areas, \(import_{n,p,h,t}\) -indicates energy or capacity transfer from n top;\(\ export_{p,n,h,t}\) -indicates energy or capacity transfer from p to n. Capital costs also -include annualized costs for pre-2010 power plants.

-

Specifically, the energy import/export is calculated as:

-
-\[\sum_{n}^{}{import_{n,p,h,t} \times price_{n,h,t}} = \sum_{n}^{}{powerfracupstream_{n,p,h,t} \times gen_{p,h,t} \times price_{n,h,t} \times hours_{h} \times (1 + loss_{n,p,h,t})}\]
-
-\[\sum_{n}^{}{export_{p,n,h,t} \times price_{p,h,t}} = \sum_{n}^{}{powerfracdownstream_{p,n,h,t} \times gen_{p,h,t} \times price_{p,h,t} \times hours_{h}}\]
-

where t is year, p and n are both balancing areas, h indicates time -slices.

-
-
-

Spatial Resolution Capabilities

-

The ReEDS model has four default spatial resolutions, shown in -Fig. 53. The default settings use the model balancing areas (bottom -left of Fig. 53). The model also includes a custom aggregation -capability that enables users to select any aggregation of regions built -from counties or balancing areas. National-scale county-level resolution -runs are extremely computationally intensive, so require simplifications -in other aspects of the model (e.g., fewer timesteps, solve years, or -technologies) to be able to produce a solution, and even with -simplifications it requires hundreds of gigabytes of memory to process -the county-level inputs. Any runs that use aggregated states require -that state policies be turned off because the model does not have any -built-in features for aggregating state policies for states that have -been combined.

-
-_images/available-region-options.png -
-

Fig. 53 Region options available in the ReEDS model for doing model runs.

-
-
-

The spatial framework built into the ReEDS model allows for other -spatial resolutions. For example, nodal datasets can be represented in -the model. When running with nodal data, each renewable energy resource -site can only be associated with a single node, so the node assignments -have to be done before a model run is -performed.

-

The model also has the capability to use mixed resolutions. For -example, California can be represented using model balancing areas, -while the rest of the United States is represented at state resolution. -This can enable finer detail for a specific region of interest, while -still capturing trades with neighboring regions as lower resolution, but -with a reasonable solution time.

-
-

Data Inputs and Handling

-

Nearly all ReEDS data inputs that include a spatial dimension are -specified at the model balancing area resolution.[66] In order to be -able to perform runs at county-level resolution, some inputs are -included at both the county-level and balancing area-level -resolution.

-
-
-

Transmission Data

-

Transmission capacity between counties is based on nodal transmission -network data (see Fig. 54) collected as part of the North American -Renewable Integration Study [Brinkman et al., 2021]. Nodes from -the data set are spatially matched to counties using nodal coordinates and -a shapefile of U.S. counties (described below). With this dataset there -are a few dozen counties have no transmission nodes or capacity, which -may be the result of missing data. To address this, nodes and lines are -added to ensure that every county has at least one transmission -interface. This is done by either adding a node on existing lines that -cross a county but did previously have nodes in that county, or if there -are no transiting lines by adding a node to the county centroid and -matching to the closest node in a neighboring -county.

-
-_images/nodal-transmission-network-data.png -
-

Fig. 54 Nodal transmission network data. Black lines are those from the dataset, and red lines are the lines that were added to ensure that every county included at least one interface.

-
-
-

Power flow constraints imposed by the topology of the network can limit -the true transfer capacity between two counties to a level below the -physical capacity of the lines connecting those counties. ReEDS -estimates these interface capacity limits using an optimization method -that finds the maximum transfer values given network characteristics, -the location of generators and load, and other constraints [Brown et al., 2023]. -Because interface limits are typically less influenced by parts -of the network that are further away, the method is run on a subset of -the network. This subset is selected by including all parts of the -network that are a specified number of “hops” away from the interface -being optimized. A comparison of the results from the optimization -method with different hops found that total transfer capacity saturated -after 6 hops, so this value was used when calculating the county-level -transfer limits used in ReEDS. Since the transfer capacity can differ -depending on the direction, the optimization is run once in each -direction (forward and reverse) for each interface.

-

After the optimization, some counties have zero transfer capacity in -one or both directions; these are replaced with either the transfer -capacity estimated in the other direction if it is non-zero or the -thermal capacity of the line. To estimate metrics such as TW-mi of -transfer capacity, ReEDS uses the distance between the centroids of the -two counties in the interface. The final transmission limits calculated -using this method are show in Fig. 55.

-
-_images/transfer-limits.png -
-

Fig. 55 Final transfer limits used in the county-level input dataset for the forward direction.

-
-
-
-
-

Wind and Solar Supply Curve Data

-

Supply curves for wind and solar are based on data from the renewable -energy potential model (reV), which provides total resource potential, -representative resource profiles, and any location-dependent supply -curve costs [Maclaurin et al., 2021]. Each supply curve -point from the reV model is mapped directly to its corresponding county. These -supply curve points are then aggregated by ReEDS to produce county level supply -curves.

-

The reV model includes estimates of the cost of investments needed to -reinforce the transmission network with the addition of more wind and -solar. For the ReEDS balancing area spatial representation, these -network reinforcement costs are calculated by determining the least cost -interconnection point and then estimating the transmission upgrades -needed between that point and balancing area’s interregional network -node. Since the county-level resolution now explicitly represents -transmission investments between counties, the network reinforcement -costs from reV are not included in the transmission cost estimates of -the county supply curves. Spur line costs, or the cost to build from the -resource site to the interconnection point, are still taken from reV. In -the future the reV model may be adapted to produce network reinforcement -costs at the county level, though they might be sufficiently small that -ignoring them would be appropriate.

-
-
-

Power Plant Capacity Data

-

Capacity data in ReEDS for existing units, prescribed builds, and -prescribed retirements[67] are taken from the National Electricity -Modeling System (NEMS) power plant database. The power plants in this -database include latitude and longitude to give their location. These -locations are mapped to counties to provide the county assignment for -the power plants. In a few isolated cases, hydropower units that were on -a county boundary were manually assigned to a county to better align -with the jurisdiction that operates that plant. For example, the -Columbia River serves as a boundary line for several counties, and -hydropower plants on the Columbia were assigned to the county’s public -utility district that owns and operates that dam, rather than to the -county that mapped to the specific latitude and longitude -value.

-
-
-

Shape Files

-

Matching transmission nodes to counties and plotting maps of -county-level results requires shapefiles of U.S. counties. For this -purpose, ReEDS relies on the 2022 vintage of TIGER/Line Files published -by the Census Bureau, which includes all legal boundaries and names as -of January 1, 2022 [U.S. Census Bureau, 2022]. The shapefiles -are converted to the ESRI:102008 coordinate reference system and any -counties outside the continental U.S. are dropped.

-
-
-

Scaling Datasets to County Resolution

-

All datasets besides those described above were downscaled from the -balancing area resolution to county level resolution using one of five methods:

-

Uniform Disaggregation:

-

All counties within a balancing area are assigned the same value as the -one used for the balancing area.

-

Downscaling based on population:

-

The “population” disaggregation method uses population fractions as -multipliers to calculate county-level data from BA-level inputs. The -multipliers used in this method represent the fraction of a county’s -population with respect to its corresponding ReEDS BA. Population data -used to create the multipliers are sourced from the 2021 Population -Totals dataset provided by the US Census Bureau [link]. Example data -for ReEDS BAs p29 and p30 are shown below in Table 35.

- - - - - - - - - - - - - - - - - - - - - - -
Table 35 Example data of population fractions used in downscaling ReEDS input data based on population.

ReEDS Balancing Area (BA)

County

Population Fraction

p29

p04001

1

p30

p04019

0.956

p30

p04023

0.044

-

Since only one county exists in the ReEDS BA “p29,” the population -fraction for that county is 1. On the other hand, two counties exist in -the ReEDS BA “p30”: the population fractions show that 95.6% of the -population of p30 live in county p04019, while 4.4% of the population -lives in p04023. To disaggregate by population, the dataset is mapped to -regionally-indexed BA-level ReEDS input data and the Population Fraction -is multiplied by the values of the BA-level dataset.

-

Downscaling based on geographic size:

-

The geographic size disaggregation method operates similarly to the -“population” disaggregation method but instead uses the fraction of a -county’s geographic area with respect to its corresponding ReEDS BA as -fractional multipliers for downscaling BA-level input data to county -level. Geographic area data used to create the multipliers are sourced -from the 2022 TIGER/Line US County Shapefile provided by the US Census -Bureau [link] and found in the inputs folder of the ReEDS -repository.

-

Downscaling based on the existing hydropower capacity:

-

The existing hydropower disaggregation method uses the fraction of -existing hydropower capacity in a given county with respect to the total -hydropower capacity of the county’s corresponding ReEDS BA as fractional -multipliers for downscaling BA-level input data to county level. -Existing hydropower capacity data used to calculate these fractional -multipliers are sourced from the EIA-NEMS generator database included in -the ReEDS inputs. This down-scaling method is used for -hydropower-specific data, such as hydropower upgrades.

-

Downscaling based on transmission line size:

-

Fractional multipliers used in the transmission line size -disaggregation method represents the ratio of transmission capacity -between a given US county and a Canadian balancing area in relation to -the total transmission capacity of the county’s corresponding US -balancing area. As an example: if US balancing area p1 is comprised of 2 -counties, and 300 MW of transmission capacity exists between county 1 -and the Canadian balancing area and 100 MW of transmission capacity -exists between county 2 and Canadian balancing area, then the ratio of -3/4 (0.75) is used to disaggregate data between county 1 and the -Canadian balancing area while a ratio of 1/4 (0.25) is used to -disaggregate data between county 2 and the Canadian balancing area. -Transmission data used to create these multipliers are sourced from the -same nodal dataset used to create the transmission interface limits -described above. Note that transmission lines found in the source data -are considered to be bidirectional: therefore, when calculating the -total transmission capacity between a US BA and Canadian BA both -directions must be considered. This down-scaling method is applied to -Canadian import and export inputs.

-

We selected one of the 5 downscaling methods above for each of the -inputs that included a spatial dimension. The choice was made using -analyst judgement. The input structure of ReEDS is such that if an -appropriate county-level dataset becomes available, it can be used in -place of the downscaled dataset.

-
-
-

Input Data Handling

-

Because some input data are specified at both the balancing area -resolution and the county resolution, the inputs used for a given run -will depend on the spatial resolution selected for that run. The input -scripts include logic that will read in the file with the appropriate -spatial resolution, and use that for the remainder of the run. In the -case of mixed resolutions, both files will be read in, and the -appropriate regions will be concatenated to create a single input file -with the specified spatial resolutions.

-

ReEDS has been set up to run so that only data for the regions being -modeled will be included in the model. For example, if doing a run that -includes only the state of North Dakota, the inputs processing step of -ReEDS will filter all input data to include only the data for North -Dakota.[68]

-

Spatial datasets are dynamic within the model itself, so the model is -agnostic to the region names.

-
-
-

Challenges and Benefits of Enhanced Spatial Resolution

-

The greater spatial resolution available in ReEDS with county-level -inputs creates a variety of opportunities to apply the ReEDS model to -answer questions. It enables specific regions of the country to be -captured to greater resolution, enabling more granular outputs of power -plant siting, transmission expansion, and emission impacts. The higher -resolution can also highlight key regional boundaries or interfaces that -might not have been present in a lower resolution model run. Our testing -has also shown that county-level resolution can lead to better estimates -of curtailment because there is more detail on the underlying -transmission system.

-

The enhanced spatial resolution also comes with a variety of -challenges. These include runtime, especially as the number of regions -considered grows. Much of our testing showed that a 10-fold increase in -the number of regions led to at least a 10-fold increase in solve time, -though runtime ultimately depends on the machine specifications and the -model options selected for that particular run. Another major challenge -is sourcing appropriate input data. If the down-scaling methods -described above are not suitable for answering the questions of a -particular analysis, then new data will be to be procured. Additionally, -even the best transmission datasets we had available still had -omissions, so it is unclear if key data will be missing for studying a -particular region.

-

Finally, enhanced spatial resolution can lead to false precision, where -users see model solutions at high spatial resolution, and put more stock -into that model solution than is warranted due to uncertainty in the -data or methods used. For example, Mehrtash et al. 2023 -show that the choice of transmission power flow representation can have -significant impact on the model solution.

-
-
-
-

Differences from the 2020 Model Version

-

Table 36 summarizes the key differences from the 2020 model version. -Table 37 summarizes the key differences in the dGen model, which is -used to provide the rooftop PV input projections for ReEDS.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 36 Key Differences in Model Inputs and Treatments for ReEDS Model Versions

Inputs and Treatments

2020 Version (July 2020)

2023 Version (July 2023)

Fuel prices

AEO2020

AEO2023

Demand growth

AEO2020

AEO2023?

Generator technology cost, performance, and financing

ATB 2020a

ATB 2023a

Endogenous retirements

On by default; when turned on, plants retire when they cannot recover at least half of their fixed O&M

On by default; when turned on, plants retire when they cannot recover at least half of their fixed O&M

Coal fixed O&M

Escalates from 2019 using assumptions from AEO2019

Escalates from 2019 using assumptions from AEO2019

Nuclear fixed O&M

Escalates from 2019 using assumptions from AEO2019

Escalates from 2019 using assumptions from AEO2019

Wind, solar, and load data

Includes data for 2007–2013; dispatch is done using 2012 data and capacity credit calculations are done using 2007–2013 data [Cole et al., 2020]

Includes data for 2007–2013; dispatch is done using 2012 data and capacity credit calculations are done using 2007–2013 data [Cole et al., 2020]

Electrification

Includes three levels of electrification

Includes three levels of electrification

Demand-side flexibility

Includes three levels of flexibility

Includes three levels of flexibility

Renewable fuel combustion turbine

Includes combustion turbine that runs on a generic renewable fuel with a minimum 6% capacity factor

Includes combustion turbine that runs on a generic renewable fuel with a minimum 6% capacity factor

Upgrades

Thermal technologies can be upgraded (e.g., by adding CCS).

Thermal technologies can be upgraded (e.g., by adding CCS).

Storage curtailment recovery

Uses hourly net load profiles and a dispatch algorithm to determine the amount of curtailment that can be recovered by storage

Uses hourly net load profiles and a dispatch algorithm to determine the amount of curtailment that can be recovered by storage

Battery storage durations

Includes 2-, 4-, 6-, 8-, and 10-hour battery storage

Includes 2-, 4-, 6-, 8-, and 10-hour battery storage

Storage capacity credit

Calculated using seven years of hourly data; capacity credit bins by duration allow for nonlinear changes in the optimization model; one-hour buffer accounts for uncertainty in forecasts and ability to dispatch

Calculated using seven years of hourly data; capacity credit bins by duration allow for nonlinear changes in the optimization model; one-hour buffer accounts for uncertainty in forecasts and ability to dispatch

Wind and solar capacity credit

Calculated using seven years of hourly resource and load data

Calculated using seven years of hourly resource and load data

Wind supply curve

Spatially-explicit modeling of multiple exclusions and setbacks from buildings, roads, transmission rights-of-way, and radar along with other exclusion layers

Spatially-explicit modeling of multiple exclusions and setbacks from buildings, roads, transmission rights-of-way, and radar along with other exclusion layers

Wind degradation

Annual degradation of 0.27% per year represented based on empirical data [Hamilton et al., 2020]

Annual degradation of 0.27% per year represented based on empirical data [Hamilton et al., 2020]

PV degradation

0.7%/yr per the ATB 2020

0.7%/yr per the ATB 2020

Wind and solar curtailment

Modeled using a simplified hourly dispatch model

Modeled using a simplified hourly dispatch model

Pumped-hydro capital cost

Declines over time per Hydropower Vision [DOE, 2016]

Declines over time per Hydropower Vision [DOE, 2016]

Storage energy arbitrage value

Calculated using hourly prices

Calculated using hourly prices

Minimum capacity factor for NGCT

1% per PLEXOS runs of the 2019 Standard Scenarios

1% per PLEXOS runs of the 2019 Standard Scenarios

Tax credits

Use a four-year safe harbor construction period; December 2019 production tax credit update represented; tax credits for CCS represented (use of captured carbon is not considered)

Use a four-year safe harbor construction period; December 2019 production tax credit update represented; tax credits for CCS represented (use of captured carbon is not considered)

State policies

Policies as of June 2020

Policies as of June 2020

Nuclear power plant assistance

Assistance for Connecticut, Illinois, New Jersey, New York, and Ohio represented

Assistance for Connecticut, Illinois, New Jersey, New York, and Ohio represented

Outage rates

Outage rates based on 2014–2018 Generating Availability Data System data

Outage rates based on 2014–2018 Generating Availability Data System data

-

a The default cost recovery period is 20 years in ReEDS and -30 years in the ATB.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 37 Key Differences in dGen Model Versions**

Inputs and Treatments

2019 Version

2020 Version

Demand growth

AEO2019

AEO2020

Technology cost

ATB 2019

ATB 2020

Tariff set

Curated in January 2019

Curated in June 2020

Wholesale electricity prices

ReEDS 2019

ReEDS 2020

State and utility net energy metering policies

Updated in March 2019

Updated in June 2020a

-

a If states have no mandated NEM expiry dates, a distributed -solar penetration threshold was implemented, which was determined from -values of peer states.

-
- -
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/objects.inv b/docs/build/html/objects.inv deleted file mode 100644 index c0742dfe..00000000 Binary files a/docs/build/html/objects.inv and /dev/null differ diff --git a/docs/build/html/postprocessing_tools.html b/docs/build/html/postprocessing_tools.html deleted file mode 100644 index 142a9137..00000000 --- a/docs/build/html/postprocessing_tools.html +++ /dev/null @@ -1,273 +0,0 @@ - - - - - - - Post-Processing and Analysis Tools — ReEDS documentation - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Post-Processing and Analysis Tools

-

There are several tools that can be found in the ReEDS repository.

-
-

Helper Scripts and Tools

-
-

Comparison

-

postprocessing/compare_cases.py

-

Compare_cases.py will take two ReEDS case paths and create a powerpoint comparing the cases.

-

Command to run this script: python postprocessing/compare_cases.py [path to ReEDS run #1] [path to ReEDS run #2]

-

Example:

-
$ python postprocessing/compare_cases.py /Users/km/ReEDS-2.0/runs/v20231221_USA /Users/km/ReEDS-2.0/runs/v20231221_USA_ref
-
-
-

postprocessing/compare_casegroup.py

-

Compare_casegroup.py will take any number of ReEDS case paths and create a powerpoint comparing all cases. The only required argument is a comma-delimited list of ReEDS case paths.

-

Example:

-
$ python postprocessing/compare_casegroup.py /Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_ref,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_lim,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_open,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_transgrp --casenames=Ref,Lim,Open,transgrp
-
-
-

or similarly:

-
$ python postprocessing/compare_casegroup.py /Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_ref,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_lim,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_open,/Volumes/ReEDS/Users/pb/ReEDSruns/20231103_stress/v20231218_casegroupK0_USA_transgrp --titleshorten=26
-
-
-

Other optional arguments are:

-
 --casenames CASENAMES, -n CASENAMES
-      comma-delimited list of shorter case names to use in plots (default: )
- --titleshorten TITLESHORTEN, -s TITLESHORTEN
-      characters to cut from start of case name (only used if no casenames) (default: 0)
- --startyear STARTYEAR, -y STARTYEAR
-      First year to show (default: 2020)
-
-
-
-
-

Run Management

-

runstatus.py

-

runstatus.py can be used to print details about runs that are currently running on the HPC.

-

Command to run this script: python runstatus.py [batch prefix]

-

Example:

-
$ python runstatus.py v20231112
-
-
-

Adding the -f flag will print the names of the finished runs: $ python runstatus.py v20231112 -f

-

If you increase the verbosity by adding -v flags, it prints a number of lines from the end of that run’s gamslog.txt equal to the number of v’s in the flag: $ python runstatus.py v20231112 -vvvvv

-

restart_runs.py

-

restart_runs.py can be used to restart any failed runs for a given batch. This only works on HPC currently.

-

Command to run this script: python restart_runs.py [batch prefix]

-

Example:

-
$ python restart_runs.py v20231112
-
-
-

interim_report.py

-

interim_report.py can be used to [todo: fill in additional details]

-

Command to run this script: python interim_report.py [path to ReEDS run]

-

Example:

-
$ python interim_report.py /Users/km/ReEDS-2.0/runs/v20231221_USA_ref
-
-
-

runs/{case}/meta.csv

-

The meta.csv file is generated for each run.

-

Information found in the meta.csv file:

-
    -

  1. Computer & Github information for the run (computer, repo, branch, commit, description)

    2. -

  2. Information for each process of the run (year, process, starttime, stoptime, processtime)

    3. -
-
-
-

Preprocessing

-

preprocessing/casemaker.py

-

[todo: add additional information]

-

Example:

-
$ python casemaker.py ...
-
-
-

preprocessing/get_case_periods.py

-

[todo: add additional information]

-

Example:

-
$ python get_case_periods.py ...
-
-
-
-
-

Tool Linkages

-

postprocessing/run_reeds2pras.py

-

run_reeds2pras.py can be used to [todo: fill in additional details]

-

Example:

-
$ python postprocessing/run_reeds2pras.py ...
-
-
-
-
-

Visualization

-

postprocessing/plots.py

-

[todo: add additional information]

-

Example:

-
$ python postprocessing/plots.py
-
-
-

postprocessing/reedsplots.py

-

[todo: add additional information]

-

Example:

-
$ python postprocessing/reedsplots.py
-
-
-

postprocessing/transmission_maps.py

-

[todo: add additional information]

-

Example:

-
$ python postprocessing/transmission_maps.py
-
-
-
-
-
-

Analysis Modules

-
-

BokehPivot

-

Bokehpivot can be used for visualizing the outputs of ReEDS runs. For more information on how to use bokehpivot, see the bokehpivot guide.

-

If you’re new to BokehPivot, the following YouTube video will be a good starting point: Viewing ReEDS Outputs Using the BokehPivot Module

-
-
-

reValue

-

reValue is used for two main things:

-
    -

  • extracting regional hourly prices from ReEDS scenarios and years

    • -

  • (Optional) using extracted prices to calculate value and competitiveness-related metrics for a set of regional generation or load profiles.

    • -
-

More more information on reValue, see the reValue documentation.

-
-
-

retail_rate_module

-

The retail rate module can be used after finishing a ReEDS run to calculate retail electricity rates by state and year, where each state is served by its own investor-owned utility (IOU).

-

For more information on this module, see the retail_rate_module documentation.

-
-
-

Analysis of ReEDS in Tableau

-

Tableau can be used for the analysis of ReEDS and ReEDS-to-PLEXOS results in Tableau.

-

For more information on how to use Tableau with ReEDS, see the Tableau documentation.

-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/retail_rate_module.html b/docs/build/html/retail_rate_module.html deleted file mode 100644 index 2689c859..00000000 --- a/docs/build/html/retail_rate_module.html +++ /dev/null @@ -1,303 +0,0 @@ - - - - - - - Retail rate module — ReEDS documentation - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- - -
-

Retail rate module

-

This module can be used after finishing a ReEDS run to calculate retail electricity rates by state and year, -where each state is served by its own investor-owned utility (IOU). The retail rate (in ¢/kWh) is given by -the revenue target for the state IOU divided by the annual retail electricity demand within the state, -where the revenue target is given by the sum of operating expenses, the return to capital, and income taxes.

-

This module translates projected generation and transmission capacities and costs from ReEDS into IOU -balance sheet expenditures, accounting for the distinction between operational and capitalized (or -“rate-based”) expenditures, depreciation schedules, taxes, and other components. Distribution, -administration, and intra-regional transmission costs are projected forward based on empirical trends over -the past decade.

-

Additional information about this module can be found here: -Brown, Patrick R, Pieter J Gagnon, J Sean Corcoran, and Wesley J Cole. 2022. Retail Rate Projections for -Long-Term Electricity System Models. Golden, CO: National Renewable Energy Laboratory. NREL/TP-6A20-78224. -https://www.nrel.gov/docs/fy22osti/78224.pdf.

-
-

Usage

-
    -

  • cd to the REEDS-2.0/postprocessing/retail_rate_module directory

    • -

  • Run the retail_rate_calculations.py script, with the name of a run folder as a required argument input. For example:

    -
      -

    • D:\username\ReEDS-2.0\postprocessing\retail_rate_module> python retail_rate_calculations.py v20200806_retailtest_MidCase

      • -
    -
    • -
-
-
-

Outputs

-

All outputs are written to the outputs/retail/ folder within the provided run folder. Outputs include:

-
    -

  • retail_rate_components.csv: All monetary values are in 2004 dollars. To obtain the retail rate, divide the sum of the cost columns by the ‘retail_load’ column.

    • -

  • costs_over_time.html: Summary plots for national rates.

    • -
-
-
-

Caveats

-
    -

  • The plotting portion of the script will currently fail if technologies are built that are not in the map_i_to_tech.csv file. The main retail_rate_components.csv file will still be produced as usual; this error only affects the production of the costs_over_time.html summary plots.

    • -
-
-
-

Accounting approach

-

Here we describe the accounting methods that we employ to translate yearly costs into estimates of the -revenue to be collected from retail customers through electric bills. This approach is a simplified version -of actual accounting practices for IOUs in the US.

-

The retail rates provided by this module consist of two primary components:

-
    -

  • Annual retail electricity demand, which is an exogenously defined, static input to the ReEDS model

    • -

  • Annual revenue target, which is the amount of revenue that an IOU would collect from ratepayers to cover its costs while achieving a target return to capital

    • -
-

Cost components include capital expenditures (CAPEX) and operational expenditures (OPEX) for generation, -transmission, distribution, and administration; inter-regional trades; and taxes. These costs are grouped -into three categories: operational expenses, return to capital, and income taxes.

-
-

Operational expenses

-

Operating expenses include all generation, distribution, transmission, and administrative OPEX, the -depreciation of capital assets, and the costs of inter-state trading. For all of these expenses, we assume -that each year’s expense is directly passed through to ratepayers during the year in which it is incurred.

-

Operating expenses are equal to the sum of:

-
    -

  • Operations expenses

    • -

  • Non-capitalized maintenance expenses

    • -

  • Depreciation expenses

    • -

  • Expenses incurred by purchasing power and other services

    • -
-
-
-

Return to capital

-

The return to capital is the compensation to shareholders and debtholders. It is driven primarily by an -IOU’s rate base, which consists of the total net plant in service, plus working capital, minus any -accumulated deferred income taxes, described here:

-
    -

  • Net plant in service: Every capital asset has a net plant in service dollar value, where “plant” is a -generic reference to a capital asset. A capital asset’s net plant in service is the original book value of -the capital asset, minus the accumulated depreciation for that capital asset up to that point. Once a -capital asset has fully depreciated its book value, it no longer contributes to the rate base.

    -
      -

    • In our implementation, the original plant investment, ongoing capitalized maintenance expenses, -retrofits, and rebuilds are all tracked as separate investments and can have their own depreciation -schedules if warranted.

      • -
    -
    • -

  • Working capital: Working capital is the net value of current assets minus current liabilities that -the utility needs to conduct its operations — for example, the value of on-site fuel stocks and cash -balances to manage day-to-day expenses.

    -
      -

    • We estimate the total amount of working capital as the equivalent of 45 days of all operating -expenses (i.e., 45/365 × annual operating expenses).

      • -
    -
    • -

  • Accumulated deferred income taxes (ADIT): ADIT is the total value of any deferred income taxes, e.g., -from using a faster depreciation schedule for tax purposes than was used for calculating annual -depreciation expenses.

    • -
-

We assume that the rate base represents the total amount of capital required by the IOU, which is -composed of both debt and equity. We calculate how much equity and debt are required according to the -following equations:

-
    -

  • Return to equity = rate base * equity fraction * equity rate of return

    • -

  • Return to debt = rate base * debt fraction * interest rate

    • -
-
-
-

Income taxes

-

In practice, a corporation would calculate their net income to determine their income tax burden. However, -we make the assumption that the only class of revenue collection that is not exactly offset by an equal -expense is the return to equity, which greatly simplifies our accounting.

-

With this assumption, we start with the year’s calculated return to equity, explained above, and subtract -any income tax credits claimed that year. Then we use the following equation, where T is the effective -tax rate, to calculate the additional amount of revenue that would need to be collected and directed -towards income taxes to maintain the target return to capital while also covering costs:

-

(return to equity - income tax credits) * (\({1 \over 1 - T} - 1\))

-
-
-
-

Cost components

-
-

Generation

-

Generation CAPEX is derived from two sources:

-
    -

  • Historical capacity built from 2010–2019 and projected capacity built from 2020–2050 is provided by the ReEDS model, with annual cost assumptions taken from the ATB.

    • -

  • Capacity and construction dates before 2010 are taken from the EIA NEMS database. As a simplifying assumption, ReEDS/ATB technology-specific CAPEX cost assumptions for 2010 are applied to all capacity built before 2010

    • -
-

Generation OPEX includes multiple components, all derived from ReEDS model outputs:

-
    -

  • Fixed operations and maintenance (FOM)

    • -

  • Fuel

    • -

  • Variable operations and maintenance (VOM)

    • -

  • Operating reserves

    • -

  • Alternative compliance payments (ACP) for state renewable portfolio standards

    • -
-

FOM costs are separated into capitalized and non-capitalized costs, which are treated separately in the -accounting procedure detailed above. Capitalized costs include, for example, capital assets whose costs are -recovered through depreciation over time, such as module replacement for a PV plant or boiler replacement -for a thermal plant. Non-capitalized costs are expenses that are not capital assets, such as maintenance -labor.

-
-
-

Transmission

-

Transmission capacity includes spur lines for wind and solar generators, substations, inter-BA transmission -lines, and intra-BA transmission.

-

Transmission CAPEX is derived from several sources:

-
    -

  • Spur line costs for candidate wind and solar sites are calculated in the Renewable Energy Potential (reV) -model and used as inputs to ReEDS; spur line costs for constructed sites are then obtained from ReEDS -outputs.

    • -

  • Inter-BA transmission capacity is obtained from ReEDS projections. The cost of each inter-BA line is -evenly split between the BAs it connects.

    • -

  • Inter-BA transmission lines incur an additional, voltage-dependent substation cost, drawing from a supply -curve of available substation capacity and cost by voltage within each BA.

    • -

  • Intra-BA transmission capacity and cost (aside from wind/solar spur lines and substations) are not -directly modeled in ReEDS. Intra-BA transmission costs are estimated using from the ABB Velocity Suite -database of Federal Energy Regulatory Commission (FERC) Form 1 responses from 2010–2019.

    • -
-

Existing transmission capacity is assumed to have been built uniformly over the previous 40 years using the -same cost ($/kW-km) as new transmission in ReEDS.

-

Annual transmission OPEX is similarly taken from FERC Form 1 responses.

-
-
-

Distribution & Administration

-

Distribution and administration CAPEX are taken from the “Electric Plant in Service” schedule of FERC Form -1. -Distribution and administration OPEX are taken from the “Electric Operation and Maintenance Expenses” -schedule schedule of FERC Form 1.

-

The data in FERC Form 1 are not comprehensive; for some states (particularly those with a greater -proportion of demand served by non-IOU entities), the data reported by IOUs in FERC Form 1 represent a -small fraction of total retail demand in the state. Therefore, we calculate the ¢/kWh rate contributions -for distribution CAPEX and OPEX, administration CAPEX and OPEX, and transmission OPEX by aggregating the -data in FERC Form 1 across IOUs at three different levels of aggregation (state, region, and nation), -calculating the complete retail rate for each state, and comparing the calculated state retail rate in -2010–2019 to the historical annual state retail rate reported in EIA Form 861. The aggregation level -(state, region, or nation) that minimizes the mean bias error (MBE) over 2010–2019 for each state is then -used when calculating ¢/kWh rate contributions for distribution CAPEX/OPEX, administration CAPEX/OPEX, and -transmission OPEX.

-
-
-

Interregional expenditure flows and tax credits

-

Inter-BA flows and accompanying expenses are tracked for energy, operating reserves, planning reserves, and -RPS credits. Energy flows are also tracked between Canada and adjacent BAs in the US. Inter-regional -expenditure flows are treated as operating expenditures in the importing BA and credits in the exporting -BA, increasing the revenue target (and associated retail rate) in the importing BA and reducing the revenue -target in the exporting BA.

-

Federal tax credits reduce generation CAPEX/OPEX expenditures, thereby reducing utility expenditures and -associated revenue targets and retail rates. The cost to the federal government of these tax incentives is -not included in the rates reported here.

-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/revalue.html b/docs/build/html/revalue.html deleted file mode 100644 index fa33a368..00000000 --- a/docs/build/html/revalue.html +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - reValue — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- - -
-

reValue

-

reValue has two main purposes:

-
    -

  1. Extract regional hourly prices from ReEDS scenarios and years

    2. -

  2. (Optional) Use extracted prices to calculate value and competitiveness-related metrics for a set of regional generation or load profiles.

    3. -
-
-
-

Instructions

-
    -

  1. Edit scenarios.csv. The columns are:

    -
      -

    • name: A unique name for this scenario

      • -

    • activate: Whether or not to activate this scenario for the reValue run. 1 means activate and 0 means de-activate

      • -

    • tech: wind-ons and load are currently the only supported technologies, and only one technology is allowed for a given run of reValue (use activate=0 for other technologies). wind-ons will use reV supply curves and profiles, while load uses BA-level load profiles

      • -

    • year: The year to extract from the ReEDS run

      • -

    • color: This column is currently unused, but could be useful for scenario styling in output visualizations

      • -

    • reeds_run_path: The path to the ReEDS run

      • -

    • rev_sc_path: The path to a reV supply curve. Use none if not using reV site-level profiles, e.g. if using load.

      • -

    • profile_path: The path to a file containing generation profiles, or none if gathering only prices . For onshore wind reV data, this will be the path to an h5 file, and for BA-level load data, this will be a path to a csv file.

      • -

    • profile_timezone: The timezone of the profile relative to UTC (e.g. -5 for EST), or local to indicate that the profiles are in local time of the associated balancing areas.

      • -

    • buildings_file: A file containing number of buildings and sqft by BA, used for calculating additional metrics of GHP-based load adjustments. Otherwise use none

      • -
    -
    2. -

  2. (Optional) Configure switches at the top of reValue.py:

    -
      -

    • output_prices: Set to False if you don’t care about the price outputs, otherwise True.

      • -

    • res_marg_style: max_net_load_2012 is the only currently supported option, and assigns reserve margin prices equally to the peak net load hours. max_load_price, the other option, would assign reserve margin prices to the associated timeslice with max load prices, but this option only works on older versions of ReEDS.

      • -

    • netload_num_hrs: When res_marg_style = max_net_load_2012, this allows the user to specify the number of max net load hours to assign the reserve margin prices (default in ReEDS is 20, but the default here is 50 so that technologies don’t randomly align with peak net load hours as often). Higher netload_num_hrs mean lower reserve margin prices in each hour, such that total value of firm capacity stays constant.

      • -

    • netload_time_style: When res_marg_style = max_net_load_2012, This allows the user to keep reserve margin prices at the hour level (netload_time_style=hour), or to assign prices to the entire timeslice(s) containing the hour(s) (netload_time_style=timeslice).

      • -
    -
    3. -

  3. Run activated scenarios with python reValue.py (from the reeds2 conda environment).

    4. -

  4. Gather price and value metric outputs from output folder at ReEDS-2.0/postprocessing/reValue/outputs_[timestamp]. Here are the main outputs:

    -
      -

    • reValue_out.csv: This file contains the various value metrics:

      -
        -

      • LVOE: Value per unit energy

        • -

      • LVOE_load: Value per unit energy (load, or energy requirement, component. For load technology, this includes influence on operating reserves, state rps, and all model requirements that are linked to the LOAD variable)

        • -

      • LVOE_rm: Value per unit energy (reserve margin component)

        • -

      • LVOE_or: Value per unit energy (operating reserve component, only present if tech is not load)

        • -

      • LVOE_rps: Value per unit energy (state rps component, only present if the tech is not load)

        • -

      • Pb_load_loc: A benchmark price for the load component at this location (assuming flat block technology).

        • -

      • Pb_rm_loc: A benchmark price for the reserve margin component at this location (assuming flat block technology).

        • -

      • Pb_load_nat: A national benchmark price for the load component (assuming flat block technology).

        • -

      • Pb_rm_nat: A national benchmark price for the reserve margin component (assuming flat block technology).

        • -

      • VF: Value factor (LVOE/Pb).

        • -

      • VF_temporal: Temporal component of value factor

        • -

      • VF_spatial: Spatial component of value factor

        • -

      • VF_interaction: Spatio-temporal interaction, where VF=VF_temporal*VF_spatial*VF_interaction

        • -
      -
      • -

    • prices.csv: This file contains prices for each ReEDS run and model year considered. The type column reflects total price by hour, tot, as well as the breakdown by service.

      • -
    -
    5. -
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/search.html b/docs/build/html/search.html deleted file mode 100644 index c8563cde..00000000 --- a/docs/build/html/search.html +++ /dev/null @@ -1,129 +0,0 @@ - - - - - - Search — ReEDS documentation - - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
-
    -
    • -
  • Search
    • -
  • -
    • -
-
-
-
-
- - - - -
- -
- -
-
- -
-
-
-
- - - - - - - - - \ No newline at end of file diff --git a/docs/build/html/searchindex.js b/docs/build/html/searchindex.js deleted file mode 100644 index 37d1dea4..00000000 --- a/docs/build/html/searchindex.js +++ /dev/null @@ -1 +0,0 @@ -Search.setIndex({"alltitles": {" ": [[10, "id4"]], "9.4. 9.4 Clean Energy Standards": [[5, "clean-energy-standards"]], "Accounting approach": [[7, "accounting-approach"]], "Acknowledgments": [[5, "acknowledgments"]], "Adding new outputs to the Tableau postprocessing": [[11, "adding-new-outputs-to-the-tableau-postprocessing"]], "Additional Resources": [[1, "additional-resources"]], "Amount of Nuclear Power Plant Capacity (in GW) in Each Bin": [[5, "nuclear-plant-capacity"]], "Analysis Modules": [[6, "analysis-modules"]], "Analysis of ReEDS in Tableau": [[6, "analysis-of-reeds-in-tableau"]], "Appendix": [[5, "appendix"]], "Assumptions": [[3, "assumptions"]], "Average Electricity Prices": [[5, "average-electricity-prices"]], "Biopower": [[5, "biopower"]], "BokehPivot": [[6, "bokehpivot"]], "CO2 Transport and Storage": [[5, "co2-transport-and-storage"]], "California Carbon Cap": [[5, "california-carbon-cap"]], "Calling runbatch.py to run ReEDS": [[9, "calling-runbatch-py-to-run-reeds"]], "Can I configure a ReEDS case to run as an isolated interconnect?": [[3, "can-i-configure-a-reeds-case-to-run-as-an-isolated-interconnect"]], "Capabilities that don\u2019t currently work": [[3, "capabilities-that-don-t-currently-work"]], "Capacity credit formulation": [[5, "capacity-credit-formulation"]], "Capital Cost Financial Multipliers": [[5, "capital-cost-financial-multipliers"]], "Capital Cost Multipliers for Power-Cooling Technology Combinations": [[5, "capital-cost-multipliers"]], "Capital Financing, System Costs, and Economic\u00a0Metrics": [[5, "capital-financing-system-costs-and-economic-metrics"]], "Capital Stock": [[5, "capital-stock"]], "Caveats": [[7, "caveats"]], "Challenges and Benefits of Enhanced Spatial Resolution": [[5, "challenges-and-benefits-of-enhanced-spatial-resolution"]], "Characteristics of CSP Technology Options": [[5, "csp-tech-characteristics"]], "Clean Energy Requirement as a Percentage of In-State Sales": [[5, "clean-energy-req"]], "Climate Impacts": [[5, "climate-impacts"]], "Comparison": [[6, "comparison"]], "Compound annual growth rates and 2050 electric load values for a variety of EER load profiles available in ReEDS.": [[5, "growth-rates-and-electric-load"]], "Computer Setup for MacOS": [[9, "computer-setup-for-macos"]], "Computer Setup for Microsoft Windows 10": [[9, "computer-setup-for-microsoft-windows-10"]], "Concentrating Solar Power": [[5, "concentrating-solar-power"]], "Contact Us:": [[4, "contact-us"]], "Conventional Energy Technologies": [[5, "conventional-energy-technologies"]], "Conventions": [[0, "conventions"]], "Cooling System Cost and Performance": [[5, "cooling-system-cost-and-performance"]], "Core Pivot Functionality": [[1, "core-pivot-functionality"]], "Core optimization": [[3, "core-optimization"]], "Cost and Performance Assumptions for BECCS": [[5, "beccs-assumptions"]], "Cost and Performance Assumptions for Hydrogen Production Technologies. Costs are reported in $2022.": [[5, "hydrogen-production-assumptions-a"], [5, "hydrogen-production-assumptions-b"], [5, "hydrogen-production-assumptions-c"]], "Cost components": [[7, "cost-components"]], "Cost of Health Damages from Air Pollution": [[5, "cost-of-health-damages-from-air-pollution"]], "Cost of Regulation Reserves": [[5, "cost-regulation-reserves"]], "Costs and routes for new AC transmission additions": [[5, "costs-and-routes-for-new-ac-transmission-additions"]], "Creating report templates:": [[1, "creating-report-templates"]], "Cross-State Air Pollution Rule": [[5, "cross-state-air-pollution-rule"]], "Cumulative Offshore Wind Capacity (MW) Mandated in ReEDS": [[5, "offshore-wind-capacity"]], "Data Inputs and Handling": [[5, "data-inputs-and-handling"]], "Differences from the 2020 Model Version": [[5, "differences-from-the-2020-model-version"]], "Direct Air Capture": [[5, "direct-air-capture"]], "Distribution & Administration": [[7, "distribution-administration"]], "Dollar-year Adjustments": [[11, "dollar-year-adjustments"]], "Drop-in renewable fuel": [[5, "drop-in-renewable-fuel"]], "Electric Sector Costs": [[5, "electric-sector-costs"]], "Electricity Load": [[5, "electricity-load"]], "Electricity Price": [[5, "electricity-price"]], "Electricity System Operation and Reliability": [[5, "electricity-system-operation-and-reliability"]], "Electrification Futures Study Load Profiles": [[5, "electrification-futures-study-load-profiles"]], "Emissions Rate by Generator Type in Pounds per MMBtu a b": [[5, "emissions-rate-by-generator-type"]], "Endogenous production with national balancing": [[5, "endogenous-production-with-national-balancing"]], "Endogenous production with zonal balancing, transport, and storage": [[5, "endogenous-production-with-zonal-balancing-transport-and-storage"]], "Energy storage mandates, with required capacity listed in MW.": [[5, "energy-storage-mandates"]], "Evolved Energy Research Load Profiles": [[5, "evolved-energy-research-load-profiles"]], "Example call:": [[11, "example-call"]], "Example data of population fractions used in downscaling ReEDS input data based on population.": [[5, "population-fraction-ex-data"]], "Executing the Model": [[9, "executing-the-model"]], "Existing Fleet Cooling Technology and Water Source": [[5, "existing-fleet-cooling-technology-and-water-source"]], "Existing transmission capacity": [[5, "existing-transmission-capacity"]], "Exploding Pivot Charts": [[1, "exploding-pivot-charts"]], "FAQ": [[3, "faq"]], "Federal Tax Credits for Clean Electricity and Captured Carbon": [[5, "federal-tax-credits-for-clean-electricity-and-captured-carbon"]], "Federal and State Emission Standards": [[5, "federal-and-state-emission-standards"]], "Federal and State Tax Incentives": [[5, "federal-and-state-tax-incentives"]], "Financing of Capital Stock": [[5, "financing-of-capital-stock"]], "Flexibility Parameters of the ReEDS Generation Technologies": [[5, "generation-techs-flexability-params"]], "Fuel Prices": [[5, "fuel-prices"]], "GAMS Configuration": [[9, "gams-configuration"], [9, "id2"]], "GFDL-ESM2M_RCP4p5_WM ": [[10, "gfdl-esm2m-rcp4p5-wm"]], "Generation": [[7, "generation"]], "Geospatial Mapping in Tableau": [[11, "geospatial-mapping-in-tableau"]], "Geothermal": [[5, "geothermal"]], "Getting Started": [[9, "getting-started"]], "Growth Constraints": [[5, "growth-constraints"]], "HadGEM2-ES_RCP2p6 ": [[10, "hadgem2-es-rcp2p6"]], "HadGEM2-ES_RCP4p5 ": [[10, "hadgem2-es-rcp4p5"]], "HadGEM2-ES_RCP8p5 ": [[10, "hadgem2-es-rcp8p5"]], "HadGEM2-ES_rcp45_AT ": [[10, "hadgem2-es-rcp45-at"]], "HadGEM2-ES_rcp85_AT ": [[10, "hadgem2-es-rcp85-at"]], "Heat Rate Multipliers for Power-Cooling Technology Combinations": [[5, "heat-rate-multipliers"]], "Helper Scripts and Tools": [[6, "helper-scripts-and-tools"]], "High-voltage direct current (HVDC) \u201cmacrogrids\u201d": [[5, "high-voltage-direct-current-hvdc-macrogrids"]], "Historical Load Data + AEO Growth Factor Profiles": [[5, "historical-load-data-aeo-growth-factor-profiles"]], "How much are the GAMS licensing fees?": [[3, "how-much-are-the-gams-licensing-fees"]], "How often are updates made to ReEDS?": [[3, "how-often-are-updates-made-to-reeds"]], "How to Update Relevant Fields in sources.csv": [[2, "how-to-update-relevant-fields-in-sources-csv"]], "How to Use Sources Documentation": [[2, "how-to-use-sources-documentation"]], "Hydrogen": [[5, "hydrogen"]], "Hydropower": [[5, "hydropower"]], "IPSL-CM5A-LR_RCP8p5_WM ": [[10, "ipsl-cm5a-lr-rcp8p5-wm"]], "Income taxes": [[7, "income-taxes"]], "Initial Capital Stock, Prescribed Builds, and Restrictions": [[5, "initial-capital-stock-prescribed-builds-and-restrictions"]], "Input Data Handling": [[5, "input-data-handling"]], "Input Files": [[10, "input-files"]], "Input data and processing": [[3, "input-data-and-processing"]], "Installing Bokeh": [[1, "installing-bokeh"]], "Instructions": [[8, "instructions"]], "International Electricity Trade": [[5, "international-electricity-trade"]], "Interregional expenditure flows and tax credits": [[7, "interregional-expenditure-flows-and-tax-credits"]], "Interzonal transmission": [[5, "interzonal-transmission"]], "Intra-zone transmission cost adder for net increases in generation capacity": [[5, "intra-zone-transmission-cost-adder-for-net-increases-in-generation-capacity"]], "Intro": [[1, "intro"]], "Introduction": [[5, "introduction"]], "Introduction (https://www.nrel.gov/analysis/reeds/)": [[4, "introduction-https-www-nrel-gov-analysis-reeds"]], "Is there a trial version of the GAMS license so that I can test ReEDS?": [[3, "is-there-a-trial-version-of-the-gams-license-so-that-i-can-test-reeds"]], "Is there a way to reduce solve time?": [[3, "is-there-a-way-to-reduce-solve-time"]], "Key Areas for Error Checking": [[0, "key-areas-for-error-checking"]], "Key Differences in Model Inputs and Treatments for ReEDS Model Versions": [[5, "model-differences"]], "Key Differences in dGen Model Versions**": [[5, "dgen-model-differences"]], "Land-Based Wind": [[5, "land-based-wind"]], "Land-Based Wind Class Definitions": [[5, "land-based-wind-class-def"]], "Levelized Cost of Energy": [[5, "levelized-cost-of-energy"]], "Lifetimes of Conventional Energy Generators a": [[5, "conventional-energy-generator-lifetimes"]], "Lifetimes of Renewable Energy Generators and Batteries": [[5, "generator-and-battery-lifetimes"]], "List of Abbreviations and Acronyms": [[5, "list-of-abbreviations-and-acronyms"]], "List of Notable DC Transmission Connections Modeled in ReEDS": [[5, "dc-transmission-connections"]], "Load Adjustment Method for End Use Profiles": [[5, "load-adjustment-method-for-end-use-profiles"]], "Loading data": [[1, "loading-data"]], "Local generator interconnection": [[5, "local-generator-interconnection"]], "Marginal Electricity Prices": [[5, "marginal-electricity-prices"]], "Marine Hydrokinetic Wave": [[5, "marine-hydrokinetic-wave"]], "Mercury and Air Toxic Standards": [[5, "mercury-and-air-toxic-standards"]], "Minimum growth size for each technology group. Growth below this level will never incur a rowth penalty regardless of starting capacity.": [[5, "min-growth-size-per-tech"]], "Model Documentation": [[5, "model-documentation"]], "Model Formulation": [[5, "model-formulation"]], "Model Linkages": [[5, "model-linkages"]], "Model Structure": [[5, "model-structure"]], "Model Switches": [[0, "model-switches"]], "Model Widgets": [[1, "model-widgets"]], "Modeled Economic Metrics": [[5, "modeled-economic-metrics"]], "Modeling Framework": [[5, "modeling-framework"]], "Multipliers Applied to Full-Load Heat Rates to Approximate Actual Observed Heat Rates": [[5, "heat-rate-adjustments"]], "Natural Gas Supply Curves": [[5, "natural-gas-supply-curves"]], "Net Value": [[5, "net-value"]], "Network reinforcement": [[5, "network-reinforcement"]], "Nuclear Power Plant Lifetime for Each Scenario by Bin (years)": [[5, "nuclear-plant-lifetime"]], "Nuclear Power Plant Policies": [[5, "nuclear-power-plant-policies"]], "Offshore Wind": [[5, "offshore-wind"]], "Offshore Wind Class Definitions": [[5, "offshore-wind-class-def"]], "Operational Reliability": [[5, "operational-reliability"]], "Operational expenses": [[7, "operational-expenses"]], "Other Policy Capabilities": [[5, "other-policy-capabilities"]], "Output processing": [[3, "output-processing"]], "Outputs": [[7, "outputs"]], "Overview": [[5, "overview"], [5, "id2"]], "Planning Reserve Margins": [[5, "planning-reserve-margins"]], "Policy Descriptions": [[5, "policy-descriptions"]], "Post-Processing and Analysis Tools": [[6, "post-processing-and-analysis-tools"]], "Power Plant Capacity Data": [[5, "power-plant-capacity-data"]], "Power System Water Use": [[5, "power-system-water-use"]], "Preprocessing": [[6, "preprocessing"]], "Present Value of Direct Electric Sector Cost": [[5, "present-value-of-direct-electric-sector-cost"], [5, "id2156"]], "Prompts for user input during runbatch.py": [[9, "prompts-for-user-input-during-runbatch-py"]], "Python Configuration": [[9, "python-configuration"], [9, "id1"]], "Re-running a Failed ReEDS Case": [[0, "re-running-a-failed-reeds-case"]], "ReEDS 2.0": [[4, "reeds-2-0"], [10, "reeds-2-0"]], "ReEDS History": [[5, "reeds-history"]], "ReEDS Repository Setup": [[9, "reeds-repository-setup"], [9, "id3"]], "ReEDS-Cambium": [[5, "reeds-cambium"]], "ReEDS-JEDI": [[5, "reeds-jedi"]], "ReEDS-PLEXOS": [[5, "reeds-plexos"]], "ReEDS-reV": [[5, "reeds-rev"]], "ReEDS-to-PLEXOS": [[11, "reeds-to-plexos"]], "ReEDS-to-Tableau Postprocessing": [[11, "reeds-to-tableau-postprocessing"]], "ReEDS2PRAS, julia, and stress periods setup": [[9, "reeds2pras-julia-and-stress-periods-setup"]], "ReEDS_Augur ": [[10, "id59"]], "References": [[5, "references"]], "Regional Greenhouse Gas Initiative": [[5, "regional-greenhouse-gas-initiative"]], "Regional Parameter Variations and Adjustments": [[5, "regional-parameter-variations-and-adjustments"]], "Relationships of Constraints to Grid Services Used to Calculate the Competitive Electricity Price": [[5, "grid-service-constraints"]], "Renewable Energy Resources and Technologies": [[5, "renewable-energy-resources-and-technologies"]], "Required Software": [[4, "required-software"]], "Resource Adequacy": [[5, "resource-adequacy"]], "Resource Classes for CSP Plants Using a Solar Multiple (SM) of 2.4": [[5, "csp-solar-resource-classes"]], "Retail rate module": [[7, "retail-rate-module"]], "Retirements": [[5, "retirements"]], "Return to capital": [[7, "return-to-capital"]], "Run Management": [[6, "run-management"]], "Running Bokehpivot (MacOS)": [[1, "running-bokehpivot-macos"]], "Running Bokehpivot (Windows)": [[1, "running-bokehpivot-windows"]], "Scaling Datasets to County Resolution": [[5, "scaling-datasets-to-county-resolution"]], "Seasonal Natural Gas Price Adjustments": [[5, "seasonal-natural-gas-price-adjustments"]], "Shape Files": [[5, "shape-files"]], "Solar Photovoltaics": [[5, "solar-photovoltaics"]], "Sources and Data": [[10, "sources-and-data"]], "Spatial Resolution": [[5, "spatial-resolution"]], "Spatial Resolution Capabilities": [[5, "spatial-resolution-capabilities"]], "Special Case Setup Requirements": [[9, "special-case-setup-requirements"]], "Spur lines and substation upgrades": [[5, "spur-lines-and-substation-upgrades"]], "State Renewable Portfolio Standards": [[5, "state-renewable-portfolio-standards"]], "Storage Mandates": [[5, "storage-mandates"]], "Storage Technologies": [[5, "storage-technologies"]], "Summary of Caveats": [[5, "summary-of-caveats"]], "Summary of Major Changes": [[5, "summary-of-major-changes"]], "Summary of Net Value Metrics": [[5, "net-value-metrics"]], "Summary of Operating Reserve Requirements": [[5, "operating-reserve-reqs"]], "Switches": [[0, "switches"]], "Table of Contents": [[3, "table-of-contents"], [10, "table-of-contents"]], "Tableau Analysis Templates": [[11, "tableau-analysis-templates"]], "Technical Resource Potential (GW)": [[5, "technical-resource-potential"]], "Technology Descriptions": [[5, "technology-descriptions"]], "Technology Value": [[5, "technology-value"]], "Temporal Resolution": [[5, "temporal-resolution"]], "Tips": [[1, "tips"]], "Tool Linkages": [[6, "tool-linkages"]], "Transmission": [[5, "transmission"], [7, "transmission"]], "Transmission Data": [[5, "transmission-data"]], "Transmission System": [[5, "transmission-system"]], "Transmission costs": [[5, "transmission-costs"]], "Troubleshooting": [[0, "troubleshooting"], [1, "troubleshooting"], [11, "troubleshooting"]], "Troubleshooting Issues with Julia Setup": [[9, "troubleshooting-issues-with-julia-setup"]], "UPV and DUPV Resource Classes": [[5, "upv-dupv-resource-classes"]], "USA_VSC_2035 ": [[10, "usa-vsc-2035"]], "Understanding the cases.csv file": [[9, "understanding-the-cases-csv-file"]], "Usage": [[7, "usage"]], "User-adjustable transmission assumptions": [[5, "user-adjustable-transmission-assumptions"]], "Variable Operations and Maintenance Cost Multipliers for Power-Cooling Technology Combinations": [[5, "variable-operations-capital-cost-multipliers"]], "Visualization": [[6, "visualization"]], "WKT_csvs ": [[10, "wkt-csvs"]], "Water Availability and Cost": [[5, "water-availability-and-cost"]], "Water Constraints": [[5, "water-constraints"]], "Water Consumption Rates for Power-Cooling Technology Combinations (gal/MWh)": [[5, "water-consumption-rates"]], "Water Withdrawal Rates for Power-Cooling Technology Combinations (gal/MWh)": [[5, "water-withdrawal-rates"]], "Water withdrawal and consumption rates for technologies that are undifferentiated by cooling technology (gal/MWh)": [[5, "water-withdrawal-and-consumption-rates"]], "Weights for Each Voltage Class": [[5, "voltage-class-weights"]], "Welcome to ReEDS\u2019s documentation!": [[4, "welcome-to-reeds-s-documentation"]], "Welcome to the Regional Energy Deployment System (ReEDS) Model!": [[4, "welcome-to-the-regional-energy-deployment-system-reeds-model"]], "What are the limitations, caveats, and known issues?": [[3, "what-are-the-limitations-caveats-and-known-issues"]], "What computer hardware is necessary to run ReEDS?": [[3, "what-computer-hardware-is-necessary-to-run-reeds"]], "Wind and Solar Supply Curve Data": [[5, "wind-and-solar-supply-curve-data"]], "air_quality ": [[10, "id45"]], "atb_updates_processing ": [[10, "id55"]], "bokehpivot ": [[10, "id46"]], "calc_historical_capex ": [[10, "calc-historical-capex"]], "canada_imports ": [[10, "id12"]], "capacity_exogenous ": [[10, "id13"]], "climate ": [[10, "id14"]], "consume ": [[10, "id15"]], "ctus ": [[10, "id16"]], "dGen_Model_Inputs ": [[10, "id20"]], "dGen_model_inputs ": [[10, "id19"]], "data ": [[10, "data"]], "degradation ": [[10, "id17"]], "demand_response ": [[10, "id18"]], "disaggregation ": [[10, "id21"]], "emission_constraints ": [[10, "id22"]], "financials ": [[10, "id23"]], "fuelprices ": [[10, "id24"]], "geothermal ": [[10, "id25"]], "growth_constraints ": [[10, "id26"]], "hourlize ": [[10, "id5"]], "hourly_process.py": [[0, "hourly-process-py"]], "hydro ": [[10, "id27"]], "in ": [[10, "in"]], "input_files ": [[10, "id56"]], "inputs ": [[10, "id6"]], "inputs ": [[10, "id9"]], "inputs ": [[10, "id11"]], "inputs ": [[10, "id48"]], "inputs ": [[10, "id51"]], "land_use ": [[10, "id47"]], "load ": [[10, "id7"]], "load ": [[10, "id28"]], "multi_year ": [[10, "multi-year"]], "national_generation ": [[10, "id29"]], "plant_characteristics ": [[10, "id30"]], "plexos_to_reeds ": [[10, "id8"]], "plots ": [[10, "id49"]], "postprocessing ": [[10, "id44"]], "preprocessing ": [[10, "id54"]], "r2r_expanded ": [[10, "r2r-expanded"]], "r2r_from_config ": [[10, "r2r-from-config"]], "r2r_integration ": [[10, "r2r-integration"]], "rcm_data ": [[10, "rcm-data"]], "reValue": [[6, "revalue"], [8, "revalue"]], "reValue ": [[10, "id52"]], "reeds2 ": [[10, "reeds2"]], "reeds2pras ": [[10, "id57"]], "reeds_cases ": [[10, "reeds-cases"]], "reserves ": [[10, "id31"]], "resource ": [[10, "resource"]], "retail_rate_module": [[6, "retail-rate-module"]], "retail_rate_module ": [[10, "id50"]], "sets ": [[10, "id32"]], "shapefiles ": [[10, "id33"]], "state_policies ": [[10, "id34"]], "storage ": [[10, "id35"]], "stscen2023_electrification ": [[10, "stscen2023-electrification"]], "stscen2023_highng ": [[10, "stscen2023-highng"]], "stscen2023_highre ": [[10, "stscen2023-highre"]], "stscen2023_lowng ": [[10, "stscen2023-lowng"]], "stscen2023_lowre ": [[10, "stscen2023-lowre"]], "stscen2023_mid_case ": [[10, "stscen2023-mid-case"]], "stscen2023_mid_case_95_by_2035 ": [[10, "stscen2023-mid-case-95-by-2035"]], "stscen2023_mid_case_95_by_2050 ": [[10, "stscen2023-mid-case-95-by-2050"]], "stscen2023_taxcredit_extended2050 ": [[10, "stscen2023-taxcredit-extended2050"]], "supply_curve ": [[10, "id36"]], "tableau ": [[10, "id53"]], "techs ": [[10, "id37"]], "test ": [[10, "id58"]], "tests ": [[10, "id10"]], "transmission ": [[10, "id38"]], "upgrades ": [[10, "id39"]], "userinput ": [[10, "id40"]], "valuestreams ": [[10, "id41"]], "variability ": [[10, "id42"]], "waterclimate ": [[10, "id43"]], "\u201cStress periods\u201d formulation": [[5, "stress-periods-formulation"]]}, "docnames": ["additional_model_information", "bokehpivot", "documentation_tools/README", "faq", "index", "model_documentation", "postprocessing_tools", "retail_rate_module", "revalue", "setup", "sources", "tableau"], "envversion": {"sphinx": 61, "sphinx.domains.c": 3, "sphinx.domains.changeset": 1, "sphinx.domains.citation": 1, "sphinx.domains.cpp": 9, "sphinx.domains.index": 1, "sphinx.domains.javascript": 3, "sphinx.domains.math": 2, "sphinx.domains.python": 4, "sphinx.domains.rst": 2, "sphinx.domains.std": 2, "sphinxcontrib.bibtex": 9}, "filenames": ["additional_model_information.md", "bokehpivot.md", "documentation_tools/README.md", "faq.md", "index.md", "model_documentation.md", "postprocessing_tools.md", "retail_rate_module.md", "revalue.md", "setup.md", "sources.md", "tableau.md"], "indexentries": {}, "objects": {}, "objnames": {}, "objtypes": {}, "terms": {"": [0, 1, 3, 5, 6, 7, 8, 9, 10, 11], "0": [0, 1, 2, 3, 5, 6, 7, 8, 9], "00": 5, "000": [3, 5], "0000000171284643": 5, "0000000221442954": 5, "0000000317692261": 5, "0003": 5, "000a": 5, "001": 5, "0013": 5, "002": 5, "00219": 5, "003": 5, "0033": 5, "004": 5, "005": 5, "00533": 5, "007": 5, "0098": 5, "01": 5, "012": 5, "013": 5, "01319": 5, "014023": 5, "015004": 5, "017": 5, "0176131": 5, "02": 5, "021": 5, "022": 5, "023": 5, "028": 5, "029": 5, "02_limit": [], "03": 5, "033": 5, "03612": 5, "0383": 5, "039": 5, "04": 5, "044": 5, "045": 5, "045802": 5, "05": 5, "050": 5, "051": 5, "053": [], "054": 5, "054p_": 5, "0555": 5, "06": 5, "066": 5, "07": [5, 9], "074016": 5, "075": 5, "076": 5, "08": 5, "085": 5, "087": 5, "088": 5, "089": 5, "08go28308": 5, "09": 5, "092": 5, "098": 5, "0_input_process": [], "1": [0, 3, 4, 5, 6, 7, 8, 9, 10], "10": [0, 5, 10], "100": 5, "1000": 5, "1004": 5, "100563": 5, "1007": 5, "101": 5, "1016": 5, "102": 5, "1020": 5, "102008": 5, "102012": 5, "102015": 5, "102016": 5, "1034": 5, "1038": 5, "1043": 5, "106": 5, "1063": 5, "107": 5, "1073": 5, "1088": 5, "1095399": 5, "10i": [], "10m": [], "11": [0, 5], "110": 5, "1109": 5, "113": 5, "1130": 5, "114": 5, "115": 10, "115385": 5, "116": 5, "1169237": 5, "117": 5, "1170": 5, "11746": 5, "1189": 5, "119998": 5, "12": [5, 10], "120": [], "120044": 5, "121": 5, "122": 5, "1220": 10, "123969": 5, "125": 5, "126": 3, "1260920": 5, "1270": 5, "12794": 5, "1283": 5, "1293": 5, "1296": 5, "12am": [], "13": 5, "130": 3, "1318192": 5, "1320": 5, "133": 3, "134": [3, 5], "1349721": 5, "1353003": 5, "136": 5, "137": 5, "1371": 5, "14": 5, "144": 5, "14640": 5, "1484344": 5, "15": [5, 9], "150": 5, "1505552": 5, "1505935": 5, "152": 5, "1524768": 5, "1530173": 5, "155": 5, "15570": 5, "15582": 5, "156": 5, "159": 5, "15p": [], "16": [4, 5], "161": 5, "162": 5, "1624": 5, "165": 5, "166": 5, "167": 5, "168": 5, "17": [5, 10], "172000": [], "17226": 5, "1723": 5, "1748": 5, "175": [5, 10], "176": 5, "18": 5, "180": 5, "181": 5, "183": 5, "184": 5, "1877873": 5, "188": 5, "19": 5, "1905030116": 5, "191": 5, "192": 5, "195": 5, "195806": 5, "1960": 10, "197": 5, "19857": 5, "19862": 5, "1990": 5, "1993": 10, "1995": 5, "1998": 5, "1999": 5, "1_input": 0, "1st": 5, "2": [1, 2, 3, 6, 7, 8, 9], "20": [5, 8, 10], "200": 5, "2000": 5, "2001": 5, "2003": 5, "200310": 5, "2004": [5, 7, 9, 10, 11], "2005": 5, "2006": 5, "2007": [5, 10], "2008": 5, "2009": [5, 10], "2010": [5, 7, 10], "2011": 5, "2012": [0, 5], "2013": [5, 10], "2014": 5, "2015": [5, 10], "2015e": 5, "2016": 5, "2017": [5, 10], "2018": [5, 10], "2019": [5, 7, 9, 10], "20190617a": 5, "2019_06_17_nj_announcement_releas": 5, "2020": [4, 6, 7, 10], "2020_updat": [], "2021": [5, 10], "2022": [3, 7, 10], "2023": [5, 10], "20231103_stress": 6, "2023_06_06_updat": [], "2023_07_28_updat": [], "2023_11_02_landcov": [], "2024": [3, 5, 10], "20240717_test": [], "2025": 5, "2026": 5, "2028": 5, "203": 5, "2030": [5, 10], "2032": 5, "2035": 5, "2036": 5, "2040": 5, "2045": 5, "205": 5, "2050": [3, 7, 10], "2051": [], "21": 5, "210": [0, 5], "2100": 10, "2139": 5, "2160": 5, "217": 5, "2172": 5, "22": 5, "220": 5, "222": 5, "223": 5, "224": 5, "225": 5, "2279839": 5, "2283517": 5, "23": 5, "230": 5, "2308": 5, "232": 5, "238": 5, "239": 5, "24": [5, 10], "240": 5, "2433002": 5, "25": [3, 5, 11], "250": 5, "251": 5, "252": 5, "255": 5, "2555": 10, "2567": 5, "25d": 5, "26": [5, 6], "266": 5, "269": 5, "27": 5, "2746379": 5, "275": 5, "28": 5, "282": 5, "29": 5, "293": 5, "295": 5, "298": 5, "299": 5, "2_linux_x64_64_sfx": [], "2d": 1, "2t": [], "3": [0, 3, 4, 5, 9], "30": [3, 4, 5, 10], "300": 5, "3029": 5, "3037": 5, "3039": 5, "305": 5, "309": 5, "31": 5, "3133": 5, "32": 5, "320": 5, "325": 5, "32gb": 3, "33": [0, 5], "33123": 5, "332": 5, "33227": 5, "333": 5, "3389": 5, "34": [5, 9], "34469": 5, "345": 5, "34527": 5, "34541": 5, "35": 5, "350": 5, "35391": 5, "354": 5, "356": 5, "36": 5, "362": 5, "365": [0, 7, 10], "37": 5, "372": 5, "374": 5, "375": 5, "378": 5, "38": 5, "380": 5, "381": 5, "386": 5, "38e6610a8c6a92291804598c95c11b707bf187b9": 10, "39": 5, "390": 5, "393": 5, "395": 5, "39512": 5, "396": 5, "398": 5, "3am": 0, "4": [3, 4, 9], "40": [5, 7, 10], "400": 5, "403": 5, "408": 5, "41": 5, "410": 5, "42": [0, 5], "420": 5, "43": 5, "4326": 11, "434": 5, "436447": 5, "438": 5, "44": 5, "445": 5, "45": [5, 7, 9], "450": 5, "4557": 5, "45656": 5, "45q": 5, "45u": 5, "46": 5, "462": 5, "47": 5, "473": 5, "479": 5, "4790": 5, "48": [3, 5], "480": 5, "481": 5, "483": 5, "4869": 5, "49": 5, "492": 5, "495": 5, "4am": 0, "4hr": 5, "4yr": 3, "5": [0, 3, 4, 5, 8, 9], "50": [5, 8], "500": [5, 10], "50000": [], "506": 5, "5066": 5, "509": 5, "51": 5, "510": 5, "511": 5, "512": [], "5173": 5, "52": 5, "52409": 5, "53": 5, "538": 5, "54": [3, 5], "54232": 5, "545": 5, "55": 5, "550": 5, "5500": 5, "553": 5, "554": 5, "5547": 5, "55588": 5, "56": 5, "562019": 5, "57": 5, "58": 5, "580": 5, "5800": 5, "58491": 5, "58645": 5, "587": 5, "5890": 5, "59": 5, "590": 5, "5950": 5, "5986": 9, "599": 5, "5d00": 5, "5x": 10, "5yr": 3, "6": [4, 5, 9, 10], "60": 5, "600": 5, "61": 5, "610": 5, "61663": 5, "62": 5, "620": 5, "622": 5, "63": 5, "634": 5, "635": 5, "64": 5, "64072": 5, "641": 5, "64270": 5, "64472": 5, "646": 5, "649": 5, "65": 5, "65014": 5, "65231": 5, "65j": [], "66": 5, "661": 5, "67": 5, "6700": 5, "672": 5, "67204": 5, "67675": 5, "677": 5, "68": 5, "680": 5, "68231": 5, "684": 5, "687": 5, "69": [3, 5], "690": 5, "6a2": 5, "6a20": [5, 7], "6a40": 5, "6d": [], "7": [1, 5, 9, 10], "70": 5, "700": 5, "704": 5, "707": 5, "709": 5, "71": 5, "71148": 5, "714": 5, "71833": 5, "71912": 5, "71916": 5, "72": 5, "72023": 5, "72133": 5, "725": 5, "73": 5, "73067": 5, "73336": 5, "735": 5, "74": 5, "74111": 5, "74184": 5, "75": 5, "750": 5, "75385": 5, "76": 5, "760": 5, "77": 5, "77442": 5, "77498": 5, "77610": 5, "777": [], "779": 5, "780": 5, "78224": 7, "786": 5, "79": 5, "8": [5, 9, 10], "80": 5, "800": 5, "80714": 5, "81": 5, "826": 5, "830387": [], "84": 5, "85": 5, "850": 5, "860": 5, "860a": 5, "860b": 5, "860m": 5, "861": [5, 7], "868": 5, "87": 5, "870": 5, "875": 5, "8760": 5, "87724": 5, "878": 5, "87843": 5, "88": 5, "89": 5, "897": 5, "8_average_retail_prices_of_electr": 10, "8xi59m4bb6i": 1, "9": [0, 9], "90": 5, "900": 5, "90m": 5, "91": 5, "913": 5, "914": 5, "92": 5, "920": 5, "921": 5, "923": 5, "925": 5, "93": 5, "932": 5, "9326": 5, "94": 5, "95": 5, "950": 5, "956": 5, "96": 5, "97": 5, "973": 5, "978": 5, "98": 5, "980": 5, "981": 5, "982": 5, "985": 5, "988": 5, "989": 5, "99": 5, "993": 5, "995": 5, "996": 5, "A": [1, 4, 5, 7, 8, 9, 10, 11], "And": [1, 5], "As": [4, 5, 7, 9, 10], "At": [1, 4, 5], "Be": 9, "But": 1, "By": [0, 1, 5], "For": [0, 1, 3, 4, 5, 6, 7, 8, 9, 11], "IT": [], "If": [0, 1, 2, 3, 4, 5, 6, 9, 10, 11], "In": [0, 1, 4, 7, 9], "It": [1, 4, 5, 7, 9, 11], "NO": 5, "NOT": [], "Near": 5, "No": [1, 5], "Not": 5, "ON": [], "ONE": 5, "OR": [4, 5], "On": 5, "One": [3, 5, 11], "Or": 3, "The": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11], "Their": 5, "Then": [1, 5, 7, 9], "There": [1, 5, 6, 9, 11], "These": [0, 2, 5, 7, 11], "To": [0, 1, 3, 5, 7, 9], "Will": 5, "With": [5, 7], "_": [0, 5, 9], "_exog_cap": [], "_prescribed_build": [], "_redo": [], "_reed": [], "_ref": 9, "_rep": [], "_resource_class": [], "_supply_curv": [], "a1_write_data": [], "a2_input": [], "a2ce47d4721a477a8701bd0e08495e1d": 10, "a3_inputs_demand": [], "a_write_data": [], "aa9907": 5, "aaron": 5, "ab": 5, "ab1ab5": 5, "abb": [5, 7], "abb13": 5, "abb18": 5, "abbrevi": 10, "abdoul": 5, "abil": 5, "abl": [1, 3, 5], "about": [0, 1, 4, 5, 6, 7, 8, 9], "abov": [0, 1, 5, 7, 9, 11], "abrupt": 10, "absolut": [0, 5], "ac": 10, "ac36": 5, "academi": 5, "acceler": 5, "accept": [1, 5], "access": [1, 5, 10], "access_cas": [], "accommod": 5, "accompani": 7, "accomplish": [5, 9], "accord": [5, 7], "accordingli": 11, "account": [3, 5], "accumul": 7, "accur": 5, "achiev": [5, 7], "aclik": 10, "acp": 7, "acp_disallow": 10, "acp_pric": 10, "across": [1, 3, 5, 7, 10, 11], "act": 5, "action": 5, "activ": [1, 4, 5, 8, 9, 10], "actual": [0, 7], "ad": [0, 2, 5, 6, 9], "adam": 5, "adapt": 5, "add": [0, 1, 2, 5, 6, 9, 11], "add_class": [], "add_cost": [], "adder": 10, "addit": [0, 3, 4, 6, 7, 8, 9, 10], "addition": [0, 3, 5], "addkeystoag": [], "address": 5, "adequ": 5, "adit": 7, "aditya": 5, "adjac": [7, 10], "adjust": [1, 3, 8, 10], "adjustor": 5, "admin": [], "administ": 4, "administr": [5, 9], "adopt": 5, "adoption_trajectories_commerci": 10, "adoption_trajectories_residenti": 10, "advanc": [4, 5, 10], "advantag": 5, "advisor": 5, "aeo": 10, "aeo2014": 5, "aeo2018": 5, "aeo2019": 5, "aeo2020": 5, "aeo2023": [5, 10], "aeo_default": [], "affect": [5, 7, 10], "affin": 0, "after": [1, 5, 6, 7, 9], "afternoon": 5, "ag": [5, 10], "again": [5, 9], "against": [0, 5], "agenc": 5, "agg1": [0, 3], "agg2": [0, 3], "agg3": [0, 3], "agglomerativeclust": 0, "aggreg": [0, 1, 3, 5, 7, 10, 11], "agj3jnspk9m": [4, 9], "agnost": 5, "agon": [], "agricultur": [3, 5], "ahb19": 5, "ahluwalia": 5, "aim": 5, "akash": 5, "al": [3, 5], "alabama": 5, "albeit": 5, "alfstad": 5, "algorithm": [4, 5], "alia": [], "alias": [], "align": [5, 8], "all": [0, 1, 2, 3, 5, 6, 7, 8, 9, 10, 11], "all_year": [], "allevi": 5, "allh": [], "allist": 5, "alloc": 5, "alloccpu": [], "allow": [1, 3, 5, 8, 10], "allt": 10, "alon": 5, "along": [5, 10, 11], "alpha": [5, 10], "alpha_aeo_2022_hog": 10, "alpha_aeo_2022_log": 10, "alpha_aeo_2022_refer": 10, "alpha_aeo_2023_hog": 10, "alpha_aeo_2023_log": 10, "alpha_aeo_2023_refer": 10, "alphabet": [], "alreadi": [1, 5], "also": [1, 2, 3, 4, 5, 7, 9, 11], "alt": 1, "alter": 1, "altern": [4, 5, 7, 9, 10, 11], "although": [0, 5], "alwai": [5, 11], "amazon": [], "amber": 5, "amer": 5, "america": 5, "american": [4, 5], "amgad": 5, "ami": 5, "amo": 5, "among": [4, 5], "amongst": 5, "amount": [3, 7, 9], "an": [0, 1, 2, 4, 5, 7, 8, 9, 10, 11], "anaconda": 9, "anaconda3": 9, "analys": 5, "analysi": 5, "analyst": 5, "analyt": [4, 5], "analyz": [1, 5], "anchorag": 5, "ancillari": 5, "anderson": 5, "andr": 5, "andrad": 5, "andrew": 5, "angl": 5, "ani": [0, 1, 4, 5, 6, 7, 9, 10, 11], "anido": 5, "ann": 5, "ann_gen": [], "anna": 5, "announc": 5, "annual": [7, 10], "annuiti": 5, "annun": 5, "anoth": [1, 5, 10], "answer": 5, "anthoni": [5, 10], "anticip": 5, "antonio": 5, "anymor": 10, "anywai": 5, "aop": [], "ap2": 5, "apenergi": 5, "apertur": 5, "api": 11, "app": [1, 10], "appear": [0, 1, 9, 11], "append": [1, 5, 9, 10], "appendix": 10, "appimag": [], "appl": 9, "appli": [1, 2, 3, 7, 10], "applic": [5, 9], "approach": 5, "appropri": 5, "approv": [4, 5], "april": 5, "apu": [], "aquif": 5, "ar": [0, 1, 2, 4, 6, 7, 8, 9, 10, 11], "arbitrag": 5, "arbitrari": 5, "arcgi": 10, "architectur": 5, "area": [1, 5, 8, 10], "aren": [2, 11], "arent": 5, "arg": [], "argpars": 11, "argument": [0, 6, 7, 11], "aris": [3, 5], "arkansa": 3, "arm": 9, "armi": 5, "arn": 5, "aro14": 5, "aron": 5, "arora": 5, "around": [1, 5], "arrai": [1, 5], "arrow": 5, "artesia": 5, "arxiv": 5, "ascr": [], "asid": [5, 7], "ask": 9, "aspect": 5, "assembl": [5, 11], "assembli": 5, "assess": [3, 5], "asset": [5, 7], "assign": [5, 8, 9, 10, 11], "assign_representative_dai": 0, "assist": 5, "associ": [5, 7, 8], "assum": [3, 5, 7, 8, 10, 11], "assumpt": [7, 10], "assur": 5, "asterisk": 5, "asynchron": 5, "atb": [5, 7, 10], "atb_mid_wind_2018": [], "atla": 5, "atlant": 5, "atmospher": 5, "attach": [], "attempt": 5, "attract": 5, "attribut": [4, 5, 11], "audienc": [], "augur": 0, "augur_data": [0, 10], "augur_errors_": 0, "augur_switch": 10, "august": [3, 5], "augustin": 5, "authent": [], "author": 5, "authorized_kei": [], "auto": 1, "autom": [], "automat": [1, 5, 9, 11], "auxiliari": [4, 5], "av": 1, "avail": [0, 1, 3, 4, 7, 9, 10], "avecpu": [], "averag": [0, 1, 3, 10], "avg_outag": [], "avi": 5, "avoid": [3, 5, 10], "avu": [], "avz": [], "awai": 5, "awar": 3, "awara": 5, "ax": 5, "axi": [1, 5], "azevedo": 5, "azur": [], "b": 9, "b2b": 5, "b_input": 10, "ba": [5, 7, 8, 10, 11], "ba_frac_path": [], "ba_timezon": 10, "ba_timezone_path": [], "back": [1, 5], "backspac": 9, "badp03": 5, "bain": 5, "balanc": [7, 8], "baldwin": 5, "ban": 10, "bank": 5, "bannist": 5, "bar": [1, 5, 10], "bar23": 5, "barbi": 5, "barbos": 5, "bare": 5, "barla": 5, "barrier": 5, "barrow": 5, "base": [1, 3, 4, 7, 8, 9, 10, 11], "base_onli": 1, "baselin": [5, 10], "baseline_load_hourli": 10, "bash": [4, 9], "bashrc": [], "basi": 5, "basic": 11, "bat": [0, 1, 2], "batch": [0, 6, 9], "batch_prefix": 0, "batchelor": 5, "batchnam": [], "batt_plant_char_format": 10, "batteri": 10, "battery_atb_2022_conserv": [], "battery_atb_2022_moder": [], "battery_atb_2023_advanc": 10, "battery_atb_2023_conserv": 10, "battery_atb_2023_moder": 10, "battery_atb_2024_advanc": 10, "battery_atb_2024_conserv": 10, "battery_atb_2024_moder": 10, "bazilian": 5, "bbb": 5, "bbw": 5, "bce": 5, "becam": 5, "becaus": [0, 2, 5, 9], "beccs_bvre_2021_high": 10, "beccs_bvre_2021_low": 10, "beccs_bvre_2021_mid": 10, "beccs_lowcost": 10, "beccs_refer": 10, "becker": 5, "becom": [1, 5, 10], "bed": 5, "been": [1, 2, 5, 7, 9], "befor": [1, 2, 3, 4, 5, 7, 9, 10, 11], "began": 5, "begin": [0, 5, 9], "behavior": 5, "being": [1, 5, 10], "beiter": 5, "believ": 5, "belong": [5, 10], "below": [0, 1, 4], "ben": 5, "benchmark": [5, 8], "beneath": 5, "benefici": 3, "benjamin": 5, "bergman": 5, "berkelei": 5, "bernstein": 5, "besid": 5, "bespok": [], "best": [5, 11], "beta": [5, 10], "bethani": 5, "better": [0, 5, 10], "between": [0, 1, 5, 7, 10, 11], "bevelhim": 5, "beyond": [3, 4, 5, 10, 11], "beyond2050step10": 10, "beyond2050step5": 10, "bg06": 5, "bharadwaj": 5, "bi": 5, "bia": [5, 7], "bibtex": [], "bidirect": 5, "bielen": 5, "big": 3, "bilater": 5, "bill": [5, 7], "billi": 5, "billion": 5, "bin": [1, 9, 10], "bin_group_col": [], "bin_method": [], "binari": 5, "bind": 5, "bio": 10, "bio_supplycurv": 10, "bioclass": 10, "biodiesel": 5, "bioeconomi": 5, "bioenergi": 5, "bioga": 5, "biomass": [5, 10], "bioproduct": 5, "bird": 5, "bit": [], "bitumin": 5, "bjm": 5, "black": 5, "blackwat": 5, "blackwel": 5, "blair": 5, "blank": [2, 9], "blend": 5, "bloat": 3, "blob": 10, "block": [8, 11], "bloom": 5, "bloombergnef": 5, "blue": 5, "bmk": 5, "board": 5, "boardman": 5, "bob": 5, "boddu": 5, "boil": 5, "boiler": 7, "bokeh": [], "bokehpivot": [], "boling": 5, "bonu": [5, 10], "book": [5, 7], "bookend": [], "border": 10, "born": 5, "borrow": 5, "boston": 5, "both": [0, 1, 5, 7, 11], "bottleneck": 5, "bottom": [0, 5, 9], "boualem": 5, "bound": 5, "boundari": [3, 5], "box": [1, 9], "brace": [], "bracket": 10, "brackish": 5, "bradi": 5, "branch": [3, 6, 11], "brancucci": 5, "brandt": 5, "break": 5, "breakdown": [1, 8], "breakeven": 5, "breakpoint": 1, "brendan": 5, "brennan": 5, "brent": 5, "brian": 5, "brief": [5, 9], "briefli": 5, "bring": [], "brinkman": 5, "british": 5, "broad": [4, 5], "broader": 5, "broadli": 5, "broken": [], "brought": 5, "brown": [3, 5, 7], "browser": [1, 5], "bryan": 5, "bs16": 5, "btp": 5, "btu": 5, "bu": [5, 10], "bubbl": 5, "budget": 5, "buffer": 5, "bug": [], "build": [1, 3, 4, 8, 9, 10], "buildings_fil": 8, "buildout": 5, "built": [1, 3, 5, 7, 9], "bulk": [3, 5], "bullet": 5, "bunch": 11, "bundl": [5, 10], "burd": 5, "burden": [5, 7], "burdensom": [], "bureau": 5, "bureauoreclamation11": 5, "burn": 5, "burner": 5, "busbar": 5, "busbarload": [], "buse": 5, "busi": 5, "buster": 5, "butt": 5, "button": [1, 9], "c": [5, 9, 10], "c0": 3, "c02": 3, "c140p7": 5, "c2e": 5, "c_": 5, "ca": 5, "cabl": 5, "cace": 5, "cadenc": [], "cae": [5, 10], "caes_refer": 10, "cafferti": 5, "cagr": 5, "caile": 5, "cair": [3, 5], "caiso": 5, "caitlin": 5, "calc_financial_input": [], "calcul": [3, 6, 7, 8, 10], "calibr": 5, "calibrate_path": [], "calibrate_typ": [], "calibrate_year": [], "california": 3, "call": [0, 1, 4, 5], "call_": [], "calvin": 5, "cambium": 3, "came": 5, "camel": [], "campu": [], "can": [0, 1, 2, 4, 5, 6, 7, 9, 10, 11], "can_export": 10, "can_exports_szn_frac": 10, "can_import": 10, "can_imports_quarter_frac": 10, "canada": [5, 7, 10], "canadian": [3, 5, 10], "cancer": 5, "candid": [5, 7], "cangrowth": 10, "cannot": [4, 5, 9, 10], "cao": 5, "cap": 10, "cap_converter_2035": 10, "cap_cost_mult_for_histor": 10, "cap_exog": 10, "cap_new_bin_out": 10, "cap_new_ivrt_refurb": 10, "cap_out": [], "capabl": [9, 10], "capac": [0, 1, 3, 4, 7, 8, 9, 10], "capacity_col": [], "capacity_exogen": [], "capacity_mw": [], "capacity_mw_": [], "capcost": [], "capcost_": 5, "capcost_usd": [], "capcredit_szn_hour": [], "capex": [5, 7, 10], "capit": 10, "capital_adder_per_mw": [], "capital_financing_assumpt": 10, "cappay": 10, "cappayments_ba": 10, "caption": 5, "captur": 3, "capture_rates_ccs_80": 10, "capture_rates_ccs_95": 10, "capture_rates_ccs_99": 10, "capture_rates_default": 10, "car19": 5, "cara": 5, "carag": 5, "carb": 5, "carbcap": 11, "carbon": 10, "carbonconstraint": [], "care": 8, "carei": 5, "carlo": 5, "carolin": 5, "carolyn": 5, "carri": 5, "case": [1, 4, 5, 6, 10], "case_suffix": [], "casemak": 6, "casenam": 6, "cases_": 9, "cases_github": 10, "cases_hourli": 10, "cases_smal": [3, 10], "cases_smalltest": 9, "cases_spatialflex": [9, 10], "cases_standardscenario": [9, 10], "cases_suffix": [], "cases_test": [9, 10], "cases_usa_vsc_2035": 10, "cash": 7, "cat": [], "categor": 5, "categori": [1, 5, 7, 10], "caus": [5, 9], "cavern": 5, "cbb": 5, "cc": [5, 10], "cc_": 5, "ccg": 5, "ccs_link": 10, "ccseason": 10, "ccsflex_atb_2020_cost": 10, "ccsflex_atb_2020_perf": 10, "ccsflex_cat": 10, "cd": 7, "cd_beta0": 10, "cd_beta0_allsector": 10, "ce": [5, 10], "cell": 5, "cendiv": 10, "cendiv_wkt": 10, "cendivweight": 10, "censu": [3, 5, 10], "center": 5, "central": [3, 5], "centroid": 5, "cepheu": [], "certain": [3, 5, 10], "certif": [5, 9], "ces_fract": 10, "cess": 5, "cev": 5, "cf": [0, 5, 10], "cf20": 5, "cf_path": [], "cfg": 5, "cfl": 5, "cfm": 5, "cfr": 5, "cghm20": 5, "chad": 5, "chain": 5, "challeng": [], "chanc": 5, "chang": [1, 2, 3, 10], "channel": [4, 9], "chapter": 5, "charact": 6, "character": 5, "characterist": 10, "charg": [5, 10], "chart": [], "chat": [], "cheapest": 5, "cheat": [], "check": [1, 3, 9, 11], "checkbox": 1, "checkout": 3, "chernyakhovskii": 5, "cheryl": 5, "chieh": 5, "chill": 5, "chmod": 1, "choic": [0, 5, 9], "choos": 5, "chore": [], "choropleth": 11, "chose": 5, "chosen": [1, 5], "christian": 5, "christoph": 5, "chronolog": 5, "chunk": 5, "circl": 5, "circuit": 5, "circul": 5, "circumst": [], "citat": 10, "cite": [], "citi": 5, "claim": [7, 10], "clarif": [], "clarifi": [], "class": [7, 10], "class_bin": [], "class_bin_col": [], "class_bin_method": [], "class_bin_num": [], "class_map": 10, "class_path": [], "class_styl": 10, "classif": 5, "classifi": 5, "clayton": 5, "clean": [3, 4, 10], "clean2035_load_hourli": 10, "clean2035_lts_load_hourli": 10, "clean2035clip1pct_load_hourli": 10, "cleaner": 5, "clear": [], "clearli": 5, "clemmer": 5, "click": [1, 9], "client": 5, "climat": 3, "climate_heuristics_finalyear": 10, "climate_heuristics_yearfrac": 10, "climate_param": 10, "climb": 5, "clip": 5, "clipboard": [], "clone": [4, 9], "close": [1, 2, 5], "closer": 5, "closest": [5, 11], "cloudhelp": [], "clp": 4, "clsm16": 5, "cluster": [0, 5], "clutch": 5, "cm": [], "cm22": 5, "cmd": 9, "cme": 5, "cmij16": 5, "cmip": 5, "cnty_fip": [], "co": [5, 7], "co2": 10, "co2_cap": 10, "co2_site_char": 10, "co2_tax": 10, "coal": [5, 10], "coal_aeo_2022_refer": 10, "coal_aeo_2023_refer": 10, "coal_fom_adj": 10, "coast": 5, "code": [0, 1, 3, 4, 5, 9, 10], "codesfor": 10, "codifi": 5, "coeffici": 5, "cofir": 5, "cohen": 5, "coin": 4, "col_def": 11, "cold": 5, "cole": [5, 7], "colin": 5, "collaps": 1, "collect": [5, 7, 11], "collector": 5, "colleg": 5, "colon": [], "color": [1, 8, 10], "columbia": 5, "column": [0, 1, 2, 3, 5, 7, 8, 9, 10, 11], "column_typ": 11, "com": [0, 3, 4, 5, 9], "combin": [4, 10, 11], "combined_eos_tran": [], "combined_off_ons_tran": [], "combust": 5, "come": 5, "comfort": [], "comma": [1, 6], "command": [0, 1, 3, 4, 6, 9, 11], "comment": [0, 4, 5, 10], "commerci": [4, 5, 11], "commercial_ghp_delta": 10, "commiss": [5, 7], "commit": [2, 5, 6], "committe": 5, "common": [0, 5], "commonli": 9, "commun": [3, 5, 10], "compact": 5, "compar": [0, 1, 3, 4, 5, 6, 7], "compare_cas": 6, "compare_casegroup": 6, "comparison": [1, 2, 5], "compat": [3, 4, 5], "compens": [5, 7], "compet": 5, "competit": [6, 8], "compil": 5, "complet": [0, 3, 5, 7, 10, 11], "complex": 5, "compli": 5, "complianc": [5, 7, 10], "compon": [0, 5, 8], "compos": [5, 7], "comprehens": [4, 5, 7], "compress": 5, "compression_opt": [], "compris": 5, "comput": [1, 5, 6], "computation": 5, "comun": 10, "con_adj_map": 10, "con_adj_styl": 10, "concaten": 5, "concentr": 10, "concept": 5, "conceptu": 5, "concern": 5, "concis": [], "conda": [1, 4, 8, 9], "conda_envs_path": [], "condasslerror": 9, "condit": [3, 5], "conduct": [5, 7], "conejo": 5, "conemu": 9, "confid": 5, "config": [1, 9], "config_": [], "config_aggreg": [], "config_bas": [], "config_base_test": [], "config_bespok": [], "config_pipelin": [], "config_rep": [], "config_suppli": [], "config_tech": [], "configur": [1, 5, 8, 10], "conflict": 5, "confus": 5, "congest": 5, "conjunct": 5, "connect": [1, 4, 7, 11], "connecticut": 5, "connel": 5, "connelli": 5, "consecut": [1, 5], "consequ": 5, "conserv": [5, 10], "consid": [3, 5, 8, 9], "consider": 5, "consist": [1, 5, 7], "consol": [], "consolid": [], "constant": [5, 8, 10], "constantli": 5, "constel": [], "constellation01": [], "constrain": 5, "constraint": [3, 10], "construct": [3, 5, 7], "construction_schedules_default": 10, "construction_times_default": 10, "consult": 5, "consum": [3, 5], "consume_char_low": 10, "consume_char_ref": 10, "consumecat": 10, "consumpt": [4, 10], "contact": 3, "contain": [0, 1, 3, 4, 5, 8, 9, 10, 11], "content": 1, "contermin": 5, "context": 5, "contigu": 5, "contin": 5, "continent": 5, "continu": 5, "contract": 5, "contractu": 5, "contrast": 5, "contribut": [5, 7, 10], "control": [3, 4], "conu": 5, "conv": [], "conv_atb_2023": 10, "conv_atb_2023_ccs_advanc": 10, "conv_atb_2023_ccs_conserv": 10, "conv_atb_2023_conserv": 10, "conv_atb_2023_low_nuclear_cost": 10, "conv_plant_char_format": 10, "convei": [], "conveni": 5, "convent": [], "converg": 5, "convers": [5, 10], "convert": [5, 10, 11], "cool": [3, 10], "cooler": 5, "coolingwatertech": 10, "coolslop": 10, "cooper": 5, "coord": 10, "coordin": 5, "copi": [1, 3, 10], "copper": 5, "copy_fil": 3, "copy_output": [], "copy_to_re": [], "copy_to_shar": [], "corcoran": [5, 7], "core": [], "corp": 5, "corpor": [4, 5, 7], "correct": [5, 11], "correctli": 11, "correl": 10, "correspond": [1, 2, 3, 5, 10, 11], "corridor": 5, "corvu": [], "cost": [4, 9, 10, 11], "cost_adder_compon": [], "cost_cap": [], "cost_cap_for_histor": 10, "cost_cap_mult": 10, "cost_cat_map": 10, "cost_cat_styl": 10, "cost_fom": [], "cost_hurdle_countri": 10, "cost_opres_default": 10, "cost_opres_market": 10, "cost_out": [], "cost_vom_mult": 10, "costli": 5, "costs_over_tim": 7, "costtyp": 5, "could": [0, 3, 4, 5, 8, 11], "council": 5, "count": 5, "counti": [3, 9, 10], "counties_acs_high_stack_2017": 10, "counties_h6c_high_stack_2017": 10, "countri": [0, 5, 10], "country_1_eue_sum": 0, "country_wkt": 10, "county2zon": 10, "coupl": [1, 5, 9], "cours": [1, 5], "cover": [4, 5, 7], "coverag": [0, 5], "cp": 5, "cplex": 4, "cpp": 5, "cpu": 9, "cpuc": 5, "cpuc18": 5, "cputim": [], "cpx": [], "cr": 5, "craig": 5, "creat": [3, 5, 6, 9, 10, 11], "credenti": [], "credibl": 5, "credit": [0, 3, 10], "crf": 5, "criteria": 5, "critic": 5, "crosswalk": 10, "crucial": [], "csapr": [3, 5, 10], "csapr_cat": 10, "csapr_group": 10, "csapr_group1_ex": 10, "csapr_group2_ex": 10, "csapr_ozone_season": 10, "csc": [], "csp": 10, "csp_atb_2023_advanc": 10, "csp_atb_2023_conserv": 10, "csp_atb_2023_moder": 10, "csp_atb_2024_advanc": 10, "csp_atb_2024_conserv": 10, "csp_atb_2024_moder": 10, "csp_plant_char_format": 10, "csp_sunshot2030": 10, "csp_supply_curv": 10, "csv": [0, 1, 3, 6, 7, 8, 10, 11], "csvdiff": [], "ct": [5, 10], "ct_10": 10, "ct_30": 10, "ct_atb_2023": 10, "ct_plant_char_format": 10, "ct_refer": 10, "ctrl": [0, 9], "ctt": 10, "ctt_map": 10, "ctt_style": 10, "ctus_cs_polygons_bvr": 10, "ctus_r_cs_spurlines_200mi": 10, "cu": 5, "culprit": 11, "cumul": 3, "cur_year": 0, "curat": 5, "curiou": 1, "curl": [], "curli": [], "currency_incent": 10, "current": [1, 4, 6, 7, 8, 9, 11], "curt": [], "curt_marg": [], "curtail": 5, "curtailment_margin": [], "curv": [3, 7, 8, 10], "custom": [0, 1, 5, 7, 9, 10, 11], "customreg_wkt": 10, "cut": [5, 6], "cutoff": 3, "cv": 5, "cv19": 5, "cv_": 5, "cv_avg": [], "cybersecur": [], "cycl": 5, "cyclic": 5, "d": [0, 1, 3, 5, 7, 9, 11], "d1": 5, "d_": 5, "d_szn_1yr": 10, "d_szn_7yr": 10, "da": 5, "dac": [5, 10], "dac_elec_bvre_2021_high": 10, "dac_elec_bvre_2021_low": 10, "dac_elec_bvre_2021_mid": 10, "dac_gas_bvre_2021_high": 10, "dac_gas_bvre_2021_low": 10, "dac_gas_bvre_2021_mid": 10, "dai": [0, 3, 5, 7, 10], "daili": [0, 5], "dakota": 5, "dalvi": 5, "dam": 5, "daniel": 5, "darghouth": 5, "dark": 5, "dash": 5, "dashboard": 11, "dat": [], "data": [0, 4, 7, 8, 9, 11], "databas": [5, 7, 10, 11], "datafram": [], "date": [5, 7, 9, 11], "datetim": [], "daunt": [], "dave": 5, "david": 5, "davidson": 5, "daytim": 5, "dc": 10, "de": [5, 8], "deadlin": 3, "death": 5, "debt": [5, 7], "debthold": 7, "debug": [], "debugg": [], "debugnod": [], "debugpi": [], "decad": [5, 7], "decarbon": [5, 10], "decemb": 5, "decent": [], "decid": [], "decim": [], "decis": 5, "declar": [], "declin": 5, "decommiss": 5, "decoupl": 5, "decreas": [3, 5], "dedic": 5, "deduct": 5, "deep": 5, "deeper": 5, "deepli": [], "default": [0, 1, 3, 4, 5, 6, 8, 9, 10, 11], "defer": 7, "defici": 5, "defin": [0, 5, 7, 9, 10, 11], "definit": 11, "defint": [], "deflat": 10, "degeneraci": 5, "degrad": 5, "degradation_annual_default": 10, "degre": 5, "del": 5, "delai": 5, "delawar": 5, "delet": 2, "delimit": [0, 6], "deliv": 5, "deliveri": 5, "delphinu": [], "delta": [5, 10], "demand": [3, 4, 5, 7, 10], "demand_aeo_2021_high": 10, "demand_aeo_2021_low": 10, "demand_aeo_2021_refer": 10, "demand_aeo_2022_high": 10, "demand_aeo_2022_low": 10, "demand_aeo_2022_refer": 10, "demand_aeo_2023_high": 10, "demand_aeo_2023_low": 10, "demand_aeo_2023_refer": 10, "demand_flat_2020_onward": 10, "demo": 4, "demonstr": [5, 10], "demonstration_pl": 10, "deneal": 5, "denholm": 5, "denomin": [1, 5], "denot": 5, "densiti": 5, "denver": 5, "depart": 5, "depend": [0, 1, 4, 5, 7, 10], "depict": 5, "deplet": 5, "deploi": 5, "deploy": 5, "depr": 5, "deprac": [], "deprec": 5, "depreci": [5, 7], "depreciation_schedules_default": 10, "depth": [5, 10], "deq": 5, "derat": 5, "deregul": 5, "deriv": [5, 7], "desarrollo": 5, "describ": [1, 5, 7, 10], "descript": [6, 9, 10, 11], "descrptiv": [], "design": [3, 4, 5, 10], "desir": [0, 1, 5], "desktop": 9, "desteni": 5, "destin": [], "destination_fold": [], "destination_path": [], "detail": [2, 3, 5, 6, 7], "determin": [0, 5, 7], "determinist": 5, "dev": 5, "develop": [4, 5, 10], "deviat": [0, 5], "devic": 5, "df": 5, "df_capex_init": 10, "df_f861_contigu": 10, "df_f861_state": 10, "df_sc_out_dupv": 10, "df_sc_out_dupv_reduc": 10, "df_sc_out_upv": 10, "df_sc_out_upv_reduc": 10, "df_sc_out_upv_reduced_simul_fil": 10, "df_sc_out_wind": 10, "dg": 5, "diagnos": 11, "dict": 1, "dictat": 5, "dictionari": 11, "did": 5, "dieter": 5, "diff": 1, "differ": [0, 1, 3, 7, 9, 10, 11], "differenti": [5, 10, 11], "difficult": [3, 5], "difficulti": 5, "dilruba": 5, "dimens": [1, 5, 11], "diod": 5, "dioxid": 5, "dipippo": 5, "direct": [7, 10], "directli": [1, 3, 5, 7, 11], "directori": [0, 1, 2, 7, 9, 11], "disabl": [1, 5], "disagg_geos": 10, "disagg_hydroexist": 10, "disagg_popul": 10, "disagg_translines": 10, "disaggreg": 5, "disallow": [1, 5], "discern": 5, "discharg": 5, "discount": 5, "discours": 1, "discoveri": 5, "discret": [1, 5], "discuss": [3, 4, 5], "disk": [], "dispatch": [4, 5], "displac": 5, "displai": 2, "dissimilar": 5, "dist_export_km": [], "dist_reinforcement_km": [], "dist_spur_km": [], "distanc": [5, 10], "distance_col": [], "distinct": [5, 7], "distinguish": 5, "distpv": [3, 10], "distpv_stscen2023_electrif": 10, "distpvcap_stscen2023_highng": 10, "distpvcap_stscen2023_highr": 10, "distpvcap_stscen2023_lowng": 10, "distpvcap_stscen2023_lowr": 10, "distpvcap_stscen2023_mid_cas": 10, "distpvcap_stscen2023_mid_case_95_by_2035": 10, "distpvcap_stscen2023_mid_case_95_by_2050": 10, "distpvcap_stscen2023_taxcredit_extended2050": 10, "distpvcf_hourli": 10, "distribut": [0, 4, 5, 10], "district": 5, "disturb": 5, "diurnal": 5, "divers": 5, "diversifi": 5, "divert": 5, "divid": [5, 7], "divis": [3, 5, 10], "dl17": 5, "dncg19": 5, "dni": 5, "do": [0, 1, 2, 3, 5, 10], "doc": [0, 1, 2, 5, 7], "docstr": [], "document": [1, 3, 6, 9, 10], "documentation_tool": 2, "documentations_tool": 2, "docupload": 5, "doe": [1, 4, 5, 9, 10], "doe08": 5, "doe11": 5, "doe12": 5, "doe15": 5, "doe16a": 5, "doe16b": 5, "doe18": 5, "doe19": 5, "doe20": 5, "doer": 5, "doesn": [0, 1, 9], "doi": 5, "doin": [], "dollar": [1, 5, 7, 9, 10], "dollaryear": 10, "domal": 5, "domest": 5, "domin": 5, "dominiqu": 5, "don": [5, 8, 11], "dona": 5, "done": [1, 5, 11], "donna": 5, "dorado": [], "dot": 1, "doubl": [1, 5, 11], "dougla": 5, "down": 5, "download": [1, 3, 4, 5, 9], "downselect": [3, 10], "downstream": 5, "downtim": [], "downward": 3, "dozen": 5, "dr": 10, "dr_baselin": 10, "dr_baseline_sh": 10, "dr_baseline_shift": 10, "dr_decrease_non": 10, "dr_decrease_profile_baselin": 10, "dr_decrease_profile_baseline_sh": 10, "dr_decrease_profile_baseline_shift": 10, "dr_decrease_profile_non": 10, "dr_increase_non": 10, "dr_increase_profile_baselin": 10, "dr_increase_profile_baseline_sh": 10, "dr_increase_profile_baseline_shift": 10, "dr_increase_profile_non": 10, "dr_none": 10, "dr_rsc_baselin": 10, "dr_rsc_baseline_sh": 10, "dr_rsc_baseline_shift": 10, "dr_rsc_none": 10, "dr_shed_baselin": 10, "dr_shed_baseline_sh": 10, "dr_shed_baseline_shift": 10, "dr_shed_non": 10, "dr_shifts_baselin": 10, "dr_shifts_baseline_sh": 10, "dr_shifts_baseline_shift": 10, "dr_shifts_non": 10, "dr_test": 10, "dr_types_baselin": 10, "dr_types_baseline_sh": 10, "dr_types_baseline_shift": 10, "dr_types_non": 10, "draco": [], "draft": 5, "drake": 5, "draw": [5, 7], "draxl": 5, "drive": [1, 3, 5], "driven": [5, 7], "driver": 5, "drop": [0, 10], "dropdown": 1, "dry": 5, "dsire": 5, "dsireusa": 5, "dtype": [], "dtypeload": [], "dual": 5, "dubin": 5, "due": [3, 4, 5, 10], "duke": 5, "dump": [], "duplic": 5, "dupv": 10, "dupv_ba": 10, "dupv_sc_naris_sc": 10, "dupv_supply_curves_capacity_2018": 10, "dupv_supply_curves_capacity_nari": 10, "dupv_supply_curves_cost_2018": 10, "dupv_supply_curves_cost_nari": 10, "dupv_upv_corr": 10, "durag": 10, "durat": [5, 10], "dure": [0, 5, 7], "dy": 11, "dylan": 5, "dynam": 5, "e": [1, 3, 4, 5, 7, 8, 9, 10, 11], "e0176131": 5, "e_": 5, "e_report": 11, "e_report_dump": 11, "e_report_param": 10, "eac": 5, "each": [0, 1, 3, 6, 7, 8, 9, 10, 11], "eagl": [], "eall": 10, "earli": 5, "earlier": [5, 10], "earn": 5, "easi": [], "easier": 11, "easiest": 1, "easili": 5, "easiur": 5, "east": 5, "eastern": [0, 5], "eb": [], "ec2": [], "echo": [], "economi": 5, "ed": 5, "ed25519": [], "edg": 5, "edison": 5, "edit": [1, 5, 8, 9], "editor": 1, "eduardo": 5, "ee": 5, "eer": [], "eer_100by2050_load_hourli": 10, "eer_baseline_aeo2022_load_hourli": 10, "eer_iralow_load_hourli": 10, "eer_iramoderate_load_hourli": 10, "ef": 5, "eff": 5, "effect": [1, 5, 7], "effici": [5, 10], "effluent": 5, "effort": 5, "eg": 5, "egr": 5, "egrid2007": 5, "eha2023": 5, "eia": [5, 7, 10], "eia13": 5, "eia14": 5, "eia15": 5, "eia16": 5, "eia17a": 5, "eia17b": 5, "eia19a": 5, "eia19b": 5, "eia23": 5, "eia860": 5, "eia861": 10, "eia_2010loadbyst": 10, "eia_loadbyst": 10, "eigenvalu": 0, "eight": 5, "either": [1, 3, 4, 5], "el": [3, 5], "elaps": [], "elast": 5, "elcc": 5, "electr": [1, 3, 4, 6, 7, 10], "electrolysi": 5, "electrolyz": [3, 5, 10], "electron": 5, "element": [1, 5], "elev": [], "eleven": 5, "elgowaini": 5, "elif": 11, "elig": [5, 10], "elimin": [5, 11], "elisabeth": 5, "elizabeth": 5, "ella": 5, "elliot": 5, "els": [], "elseif": [], "el\u00e9ctrico": 5, "email": [], "embed": 5, "emf": 5, "emiss": [3, 10], "emit": [5, 10], "emitr": 10, "emm": 5, "emp": 5, "empir": [5, 7], "emploi": [5, 7], "employe": 5, "empti": 9, "emul": [4, 5, 9], "en": [1, 5], "enabl": [5, 9], "enact": 5, "enclos": [], "encompass": 5, "encount": [0, 9, 11], "end": [0, 1, 6, 10], "endif": [], "endpoint": 5, "enduseload": [], "endyear": [3, 10], "eneco": 5, "energi": [7, 8, 9, 10], "energy_cap_2035": 10, "energy_commun": 10, "energy_sal": 10, "energypathwai": 5, "energ\u00eda": 5, "enforc": [3, 5], "eng": 5, "engag": 5, "engin": 5, "enhanc": 3, "enough": 5, "enpol": 5, "ensembl": 5, "ensur": [2, 3, 5, 9], "entail": [], "enter": [1, 2, 9], "enterpris": 5, "entir": [5, 8], "entiti": [5, 7], "entri": [0, 11], "env": 9, "environ": [4, 5, 8, 9], "environment": 5, "envis": 5, "envs_dir": [], "eor": 5, "epa": 5, "epa08": 5, "epa14": 5, "epausepagency14": 5, "epausepagency99": 5, "ephemer": [5, 10], "ephigh_load_hourli": 10, "epler": 5, "epmedium_load_hourli": 10, "epmediumstretch2040_load_hourli": 10, "epmediumstretch2046_load_hourli": 10, "epoch": [], "epreference_load_hourli": 10, "epsg": 11, "epsilon": 5, "eq_": [], "eq_reserve_margin": [], "eq_rps_ofswind": 10, "equal": [1, 5, 6, 7, 8], "equal_cap_cut": [], "equal_cap_man": [], "equat": [5, 7], "equip": 5, "equiti": [5, 7], "equival": [5, 7], "era": 5, "erc": 5, "erc19": 5, "ercot": [3, 5], "ercot_ba": [], "ercot_counti": [], "eric": 5, "error": [1, 2, 5, 7, 9, 11], "escal": 5, "especi": 5, "esr": 5, "esri": 5, "essenti": 5, "est": 8, "establish": 5, "estim": [5, 7, 10], "et": [3, 5], "etc": [1, 3, 5, 11], "ethanol": 5, "etienn": 5, "euclidean": 0, "eue": 0, "eurek": 5, "ev": 10, "ev_load_baselin": 10, "ev_static_demand": [], "eval": [], "eval_express": [], "evalu": 5, "evan": 5, "evangelia": 5, "evapor": 5, "evelyn": 5, "even": [3, 4, 5, 9], "evenli": [1, 3, 5, 7], "event": [0, 5], "everi": [1, 3, 5, 7], "evmc_rsc_baselin": 10, "evmc_shape_baselin": 10, "evmc_shape_decrease_profile_baselin": 10, "evmc_shape_increase_profile_baselin": 10, "evmc_storage_baselin": 10, "evmc_storage_decrease_profile_baselin": 10, "evmc_storage_energy_baselin": 10, "evmc_storage_increase_profile_baselin": 10, "evolut": 5, "evolv": 3, "ew3": 5, "ew3databas": 5, "ex": 9, "exact": 5, "exactli": [5, 7], "examin": 5, "exampl": [0, 1, 3, 6, 7, 9, 10], "example_custom_styl": 10, "example_data_us_electric_power_gener": 10, "example_reeds_scenario": 10, "exce": 5, "exceed": 5, "excel": 1, "except": [0, 5], "excess": 5, "exchang": 5, "exclud": 5, "exclus": [5, 10], "execust": 9, "execut": [0, 3, 5], "execute_unload": [], "exercis": 9, "exist": [0, 2, 3, 7, 9, 10], "existing_sit": [], "exit": 9, "exog_": 5, "exogen": [3, 5, 7, 10], "expand": [1, 2, 5], "expans": [4, 5], "expect": [5, 9, 11], "expected_result": 10, "expenditur": 5, "expens": [5, 10], "experi": 10, "experienc": [5, 9], "experiencebuild": 10, "experiment": 5, "expertis": 4, "expir": 5, "expiri": 5, "explain": [5, 7], "explan": 5, "explicit": [3, 5], "explicitli": [5, 11], "explor": [1, 5], "export": [1, 3, 5, 7, 10, 11], "export_": 5, "exposur": 5, "express": 5, "exsist": [], "ext": 5, "extend": 5, "extens": [5, 10], "extent": [3, 5], "extern": 5, "extra": [5, 11], "extract": [5, 6, 8, 11], "extrem": 5, "exxon": 10, "ey": [], "f": [5, 6, 9, 10], "f7tb15v5": 5, "f861_cust_count": 10, "f_": 5, "face": 3, "facil": [5, 10], "facilit": [5, 11], "fact": 5, "factor": [1, 8, 9, 10], "fail": [5, 6, 7], "failur": [], "fair": 10, "fair_market_valu": 10, "fall": 5, "fals": [5, 8, 9], "faq": 5, "far": 5, "farmland": 5, "farther": 5, "fashion": 5, "fast": [], "faster": [7, 10], "favor": 10, "fayzul": 5, "fc": 5, "fcd": 5, "fcr": 5, "feasibl": [3, 5], "featur": [0, 1, 3, 5], "februari": 5, "feder": 7, "feed": 5, "feedback": [], "feedstock": 5, "feel": [], "feet": 5, "feldman": 5, "fenrg": 5, "ferc": [3, 5, 7], "fetch": 1, "few": [1, 5], "fewer": [3, 5], "ffm18": 5, "fidel": [4, 5], "field": [1, 5], "field_definit": 10, "fig": [5, 9], "figur": [1, 5], "file": [0, 1, 2, 3, 4, 6, 7, 8, 11], "filenam": [], "filepath": [], "filetyp": [], "filezilla": [], "fill": [5, 6], "filter": [1, 5], "filter_col": [], "fin": 5, "final": [1, 3, 5, 9, 10], "financials_hydrogen": 10, "financials_sys_atb2022": 10, "financials_sys_atb2023": 10, "financials_tech_atb2022": 10, "financials_tech_atb2023": 10, "financials_tech_atb2023_crp20": 10, "financials_transmission_30itc_0pen_2022_2031": 10, "financials_transmission_default": 10, "find": [3, 5, 9], "finder": [], "fine": 5, "finer": 5, "fingerprint": [], "finish": [2, 6, 7, 9], "fip": 10, "fire": 5, "firm": [5, 8], "first": [0, 1, 2, 3, 5, 6, 9, 11], "fiscal": [], "five": 5, "fiveyear": [], "fix": [3, 5, 7, 10, 11], "flag": [6, 11], "flagship": 4, "flare": 5, "flash": 5, "flat": [5, 8], "fle20": 5, "fleet": 10, "fleischer": 5, "flex_typ": 10, "flexibl": [3, 10], "flexibli": 5, "float": [0, 5, 10], "float16": [], "float32": [], "flood": 5, "floor": 5, "florita": 5, "flow": 5, "flow_": 5, "fluctuat": 5, "fluid": 5, "fluoresc": 5, "fo": 5, "focu": 5, "focus": 5, "fold": 5, "folder": [0, 1, 2, 3, 5, 7, 8, 9, 10], "follow": [1, 3, 4, 5, 6, 7, 9, 11], "fom": [5, 7, 10], "for18": 5, "foral": 5, "forc": [5, 10], "forced_outage_2035": 10, "forced_retir": 10, "forceloc": [], "forecast": [3, 5], "forese": [], "foresight": 5, "forest": 5, "forestri": 3, "forg": [], "forget": [], "forgo": 5, "form": [4, 5, 7, 9], "format": [0, 1, 2, 5, 9, 11], "former": 5, "formul": 3, "formula": 5, "forum": 5, "forward": [4, 5, 7], "fossil": [4, 5], "found": [0, 2, 4, 5, 6, 7, 9], "foundat": [4, 5], "four": [5, 10], "fourteen": 5, "fourth": 0, "frac": 5, "fraction": [0, 1, 7, 10], "franc": 5, "francisco": 5, "fratto": 5, "frazier": 5, "freder": 5, "fredrik": 5, "free": [4, 5], "freeli": 4, "frequenc": 5, "frequent": 5, "fresh": 5, "frew": 5, "friction": 5, "friendli": 9, "frilei": 5, "from": [0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11], "frontier": 5, "fu": 5, "fuel": [7, 10], "fuel2tech": 10, "fuelbin": 10, "full": [0, 1, 4], "fulli": [1, 5, 7], "function": [0, 3, 5, 11], "fund": 5, "fundament": 5, "further": [1, 5, 10], "furthermor": 5, "futur": [4, 10], "futurefil": 10, "fwlink": [], "fy22osti": 7, "fy23": [], "fyxx": [], "g": [1, 3, 4, 5, 7, 8, 9], "g00": 0, "g00file": 0, "g_": 5, "ga": [3, 10], "gabe": 5, "gagnon": [5, 7], "galen": 5, "gam": [0, 4, 10], "game": 5, "gams45": [], "gamslic": [], "gamslog": [0, 6], "gap": 5, "gari": 5, "garnish": 5, "gasif": 5, "gasifi": 5, "gate": 5, "gather": 8, "gather_method": [], "gb": 10, "gbin": 10, "gbin_min": 10, "gc": 5, "gcfm17": 5, "gcm": 5, "gdx": 0, "gedit": [], "gen": [1, 5], "gen_": 5, "gen_ann": [], "gen_fpath": [], "gen_mandate_tech_list": 10, "gen_mandate_trajectori": 10, "gener": [0, 1, 2, 3, 4, 6, 8, 9, 10], "generate_markdown": 2, "generate_new_sourc": 2, "generate_sources_md_fil": 2, "geo": 5, "geo_atb_2023_advanc": 10, "geo_atb_2023_conserv": 10, "geo_atb_2023_moder": 10, "geo_cap_cost_for_histor": 10, "geo_discovery_bau": 10, "geo_discovery_factor": 10, "geo_discovery_ti": 10, "geo_fom_plant_char_format": 10, "geo_rsc_atb_2023": 10, "geo_supply_curve_sit": 10, "geoffrei": 5, "geograph": [3, 4, 5, 10], "geographi": [5, 11], "geolog": 5, "geologi": 5, "geometri": 11, "geospati": 5, "geotech": 10, "geovis": 5, "geq": 5, "get": [1, 5, 10], "get_bin": [], "get_case_period": 6, "get_profiles_allyears_weightedav": [], "get_supply_curve_and_preprocess": [], "gevorgian": 5, "ghg": 5, "ghi": 5, "ghm": 5, "ghp": [5, 8], "gi": [5, 10], "gian": 5, "gigabyt": 5, "gigawatt": 5, "gilmor": 5, "gilroi": 5, "gis_centroid_rb": 10, "gis_nercr": 10, "gis_nercr_new": 10, "gis_r": 10, "gis_rb": 10, "gis_rto": 10, "gis_st": 10, "git": [3, 4, 9], "gitbash": [], "github": [4, 5, 6, 9, 10], "gitlen": [], "give": 5, "given": [1, 3, 5, 6, 7, 8, 9, 10], "gleason": 5, "global": 5, "globu": [], "glossari": 5, "gm": [10, 11], "gmt": 10, "go": [1, 5], "goal": [], "goe": 5, "goforth": 5, "gokul": 5, "golden": [5, 7], "goldstein": 5, "good": [0, 1, 5, 6], "googl": 1, "gord": 5, "got": 11, "gould": 5, "gov": [5, 7, 10], "govern": [5, 7], "governor": 5, "gpac": [], "gpc": 5, "gpg": [], "gpo": 5, "grant": 5, "granular": 5, "graph": [], "graphic": 5, "grasp": [], "grate": 5, "gratefulli": 5, "great": 5, "greater": [5, 7], "greatli": [5, 7], "green": 5, "greenfield": 5, "greer": 5, "greg": 5, "gregori": 5, "grep": [], "grid": 4, "gridview": 5, "griffin": 5, "grip": 5, "ground": 5, "groundwat": 5, "group": [1, 7, 9, 10], "grow": 5, "growth": 10, "growth_bin_size_mult": 10, "growth_limit_absolut": 10, "growth_penalti": 10, "gruchalla": 5, "grue": 5, "gsw_annualcap": [], "gsw_annualcapscen": [], "gsw_augurcurtail": [], "gsw_calc_powfrac": [], "gsw_canada": [], "gsw_climatedemand": 3, "gsw_climatehydro": 3, "gsw_climatewat": 3, "gsw_efs_flex": 3, "gsw_gascurv": 3, "gsw_hierarchyfil": [0, 3], "gsw_hourli": [], "gsw_hourlyclustealgorithm": 0, "gsw_hourlyclusteralgorithm": 0, "gsw_hourlyclusterregionlevel": 0, "gsw_hourlyminrelevel": 0, "gsw_hourlynumclust": [0, 3], "gsw_hourlypeaklevel": 0, "gsw_hourlytyp": 0, "gsw_hourlyweatheryear": 0, "gsw_minload": 3, "gsw_nucleardemo": 10, "gsw_opr": 3, "gsw_prm_capcredit": [0, 3, 9], "gsw_prm_stressthreshold": 0, "gsw_pvb": [], "gsw_pvb_ilr": 3, "gsw_region": 10, "gsw_regionresolut": [0, 3], "gsw_storage_in_min": [], "gsw_storagearbitragemult": [], "gu": 5, "gudladona": 5, "gui": [], "guid": [1, 6], "guidanc": [0, 5], "guidelin": [], "guidlin": [], "gw": 10, "gwh": 10, "gws_regionresolut": [], "gz": 10, "h": [0, 3, 5, 10], "h17": [], "h2": [3, 5, 10], "h2_ba_shar": 10, "h2_exogenous_demand": 10, "h2_st": 10, "h2_stor": 10, "h2_storage_rb": 10, "h2_transport_and_storage_cost": 10, "h2ct": 5, "h2ct_": 5, "h5": [3, 8, 10], "h5fd_core": [], "h5plexo": 11, "h5web": [], "h6c": 5, "h_dt_szn": 10, "ha": [0, 1, 2, 3, 4, 5, 7, 8, 9], "habt": 5, "had": 5, "hadjerioua": 5, "halei": 5, "half": 5, "hallett": 5, "halv": 5, "hamilton": 5, "hampshir": 5, "hand": [1, 5], "handl": 11, "hansen": 5, "happen": [], "har": 5, "har17": 5, "haratyk": 5, "harbor": 5, "hard": [3, 5], "hargreav": 5, "harrison": 5, "harvard": 5, "harvest": 5, "harza": 5, "hasn": [], "have": [0, 1, 2, 3, 4, 5, 7, 9, 10, 11], "haven": [], "hd5": [], "hddcdd": 10, "hdj": 5, "head": 5, "header": [1, 10, 11], "heanei": 5, "heat": 10, "heat_rate_adj": 10, "heat_rate_mult": 10, "heat_rate_penalty_spin": 10, "heath": 5, "heatrat": [], "heatslop": 10, "hectar": 10, "hedenu": 5, "hee15": 5, "heeter": 5, "heimil": 5, "heirarchi": 11, "held": [2, 5], "heliostat": 5, "help": [0, 1, 5, 9, 11], "helper": 0, "henc": [], "heo": 5, "here": [0, 1, 3, 4, 5, 7, 8, 9], "hereaft": 5, "heritag": 5, "hesit": [], "heterogen": 5, "hetrick": 5, "heurist": 5, "hh": 10, "hhmm": 9, "hi": [], "hidden": 5, "hiearchi": [], "hierarch": [0, 5], "hierarchi": [0, 5, 10], "hierarchy_agg2": 10, "hierarchy_path": [], "high": [3, 4, 10], "higher": [3, 5, 8], "highest": 5, "highli": [5, 9], "highlight": [5, 9], "hill": 5, "hillard": 5, "hilli": 5, "hintage_char": 10, "hintage_data": 10, "histor": [7, 10], "histori": [], "historic_load_hourli": 10, "hit": [], "hj20": 5, "hkm": 5, "hmac": [], "hmb": 5, "hmi": 5, "ho": 5, "hobb": 5, "hoc": 5, "hodg": 5, "hol16": 5, "holder": 5, "holger": 5, "holt": 5, "home": [], "homeland": 5, "homework": [], "hood": 11, "hop": 5, "hope": [], "horizon": 5, "horizont": 5, "hoshaughnessyb21": 5, "hossein": 5, "host": 9, "hostick": 5, "hostnam": [], "hour": [0, 5, 8, 10], "hourli": [5, 6, 8, 9, 10], "hourlize_path": [], "hourly_operational_characterist": 10, "hourly_out_year": [], "hourly_process": [], "hourly_repperiod": [0, 3], "hours_": 5, "hover": 1, "how": [0, 5, 6, 7, 9, 10, 11], "howev": [3, 4, 5, 7, 9], "hpc": [3, 6], "hpc_user_nam": [], "hsip": 5, "html": [0, 1, 4, 5, 7, 10], "http": [0, 1, 3, 5, 7, 9, 10], "hub": 5, "hummon": 5, "hun13": 5, "hundr": 5, "huntington": 5, "hurdl": [5, 10], "hurt": [], "hybrid": [5, 10], "hyd_add_upg_cap": 10, "hyd_fom": 10, "hydadjann": 10, "hydadjsea": 10, "hydcap": 10, "hydcf": 10, "hydcost": 10, "hydro": 5, "hydro_atb_2019_const": 10, "hydro_atb_2019_low": 10, "hydro_atb_2019_mid": 10, "hydro_mingen": 10, "hydroelectr": 5, "hydrofrac_polici": 10, "hydrogen": [3, 10], "hydrographi": 5, "hydrologi": 5, "hydropow": [3, 10], "hydrosourc": 5, "hydrotherm": 5, "hydrowir": 5, "hyper": 11, "i": [0, 1, 2, 4, 5, 6, 7, 8, 9, 10, 11], "i0": 0, "i_": 5, "i_coolingtech_watersourc": 10, "i_coolingtech_watersource_link": 10, "i_coolingtech_watersource_upgrad": 10, "i_coolingtech_watersource_upgrades_link": 10, "i_geotech": 10, "i_h2_ptc_gen": 10, "i_p": 10, "i_subtech": 10, "i_water_nocool": 10, "ian": 5, "ibanez": 5, "ic": [5, 10], "ice_fom": 10, "id": [5, 10, 11], "id_column": 11, "id_ed25519": [], "id_rsa": [], "idaho": 5, "ideal": 5, "ident": 5, "identifi": [0, 5, 11], "identityfil": [], "ieee": 5, "ifthen": [], "igcc": 5, "ignor": 5, "iii": 5, "ijhyden": 5, "illinoi": 5, "illustr": 5, "ilya": 5, "imag": 9, "immedi": 5, "impact": 3, "imperfectli": 5, "implement": [5, 7], "impli": 5, "implic": 5, "implicitli": 5, "import": [3, 4, 5, 7, 9, 10], "import_": 5, "impos": 5, "impract": 5, "improv": [5, 10], "inaccur": 10, "inact": 5, "inapplic": 5, "inc": 5, "incent": 7, "incentiv": 5, "incentives_annu": 10, "incentives_bienni": 10, "incentives_ira": 10, "incentives_ira_45q_extens": 10, "incentives_ira_hii": 10, "incentives_ira_lii": 10, "incept": 5, "incid": 5, "inclu": 10, "includ": [0, 1, 2, 3, 4, 5, 7, 8, 9, 10, 11], "inclus": 3, "incom": 5, "incompat": 9, "incomplet": 3, "inconsist": 5, "incorpor": [5, 10], "incorrect": 11, "increas": [0, 3, 6, 7, 10], "increasingli": [5, 10], "increment": [3, 5], "incumb": 5, "incur": 7, "indent": [], "independ": [1, 5], "index": [0, 5, 11], "index_hr_map_1": 10, "index_hr_map_7": 10, "india": 5, "indic": [0, 1, 2, 5, 8, 9, 10], "individu": [5, 10], "induc": 5, "industri": [5, 10], "inelast": 5, "inexpens": 5, "infeas": 3, "inflat": 5, "inflation_default": 10, "inflex": 5, "inflow": 5, "influenc": [5, 8], "info": 1, "inform": [0, 3, 4, 5, 6, 7, 9, 10], "infrastructur": [4, 5], "ingest": [5, 9], "initi": [1, 4, 9, 10], "inject": 5, "inl": 5, "inlclud": [], "inlin": [], "inmap": 5, "inner": 5, "innov": 4, "input": [0, 2, 7, 11], "input_process": 9, "inputfil": [], "inputs_cas": [0, 3, 10], "inputs_default": 10, "inquiri": 4, "insensit": 5, "insert": [], "insid": 5, "insight": 0, "inskeep": 5, "insol": 5, "inspect": [], "instal": [3, 4, 5, 9, 11], "install": 9, "instanc": [1, 3, 5, 9], "instantan": [], "instanti": 9, "instead": [0, 5, 11], "institut": 5, "instruct": [1, 9], "insuffici": 5, "int": 0, "integ": [5, 9], "integr": [4, 5], "integratedtermin": [], "intel": 9, "intellig": 5, "intellisens": [], "intend": [5, 11], "intens": [3, 5], "intent": 5, "inter": [5, 7], "interact": [1, 5, 8, 9], "interannu": 5, "intercept": 5, "intercomparison": 5, "interconnect": 0, "interconnect_wkt": 10, "interest": [5, 7], "interfac": [1, 5, 9, 10], "interim_report": 6, "interior": 5, "intermedi": 5, "intermediari": 5, "intermountain": 5, "intern": [], "internet": 4, "interpol": 5, "interpret": 9, "interregion": 5, "interrel": 5, "interrupt": 5, "intersect": 5, "interst": 5, "intertempor": 5, "interti": 5, "interven": 5, "intervent": 5, "intra": 7, "intract": 5, "intrazon": 5, "intro": [], "introduc": 5, "introduct": [], "intuit": 5, "inund": 5, "inv": 5, "inv_tran": [], "inventori": 5, "invert": [5, 10], "invest": [3, 5, 7, 10], "investor": [5, 6, 7], "involv": 5, "io": 9, "ion": 5, "iou": [5, 6, 7, 10], "ipm": 5, "ipp": 5, "iqcrnn5mbgzc8zio": [4, 9], "ir": [5, 10], "ira": 5, "irradi": [5, 10], "irrelev": 3, "isbn": 5, "isci": 5, "iscienc": 5, "island": 5, "isn": [0, 5], "iso": 5, "isol": 5, "issu": [0, 1, 4, 5], "itc": 5, "iter": 5, "itl": 5, "its": [0, 1, 3, 4, 5, 6, 7, 10, 11], "itself": 5, "ivanti": [], "ivt": 10, "ivt_default": 10, "ivt_smal": 10, "ivt_step": 10, "iyer": 5, "j": [5, 7], "jac": 5, "jack": 5, "jacket": 5, "jacob": 5, "jacobson": 5, "jadun": 5, "jame": 5, "jan": [], "jani": 5, "januari": [0, 5], "jarett": 5, "jarrad": 5, "jason": 5, "java": 4, "jayaraman": 5, "jdmt13": 5, "jeff": 5, "jefferson": 5, "jeffrei": 5, "jenkin": 5, "jenni": 5, "jeong": 5, "jeremi": 5, "jersei": 5, "jess": 5, "jho": [], "jianyu": 5, "jiazi": 5, "jinhyok": 5, "jl": 9, "jmc": 5, "job": [0, 5], "jobid": [], "jobnam": [], "jobs_report": 1, "john": 5, "join": [1, 11], "joint": 5, "jointli": [], "jon": 5, "jonathan": 5, "jonathon": 5, "jone": 5, "jordan": 5, "jorgenson": 5, "joseph": 5, "joshua": 5, "joul": 5, "journal": 5, "json": [], "juan": 5, "judgement": 5, "juli": 5, "julialang": 9, "julian": 5, "juliaregistir": 9, "juliaregistri": 9, "jump": [], "june": [3, 5, 10], "jurisdict": 5, "just": [0, 1, 5, 9, 11], "justifi": [], "k": 5, "kamala": 5, "kao": 5, "karen": 5, "karmakar": 5, "katherin": 5, "keep": [5, 8], "kei": 1, "kelli": 5, "kennei": 5, "kenneth": 5, "kenni": 5, "kept": 9, "kestrel": 4, "kevin": 5, "keyboard": [], "keychain": [], "keygen": [], "keyword": [], "kg": 5, "kick": [], "kilcher": 5, "kilomet": 5, "kilovolt": 5, "kilowatt": 5, "king": 5, "kirbi": 5, "kl1": [], "kleiman": 5, "km": [5, 6, 7], "kmean": [], "kminderm": [], "know": 5, "knowledg": 5, "known": 5, "known_host": [], "kobo": 5, "koebrich": 5, "krishnan": 5, "kristin": 5, "kv": [5, 10], "kw": [5, 7], "kwh": [5, 7], "l": 5, "l_": 5, "lab": 5, "label": [0, 5], "labor": 7, "laboratori": [4, 5, 7, 9], "lack": 5, "lake": 5, "lamar": 5, "lamb": 5, "lamp": 5, "land": [3, 10], "landfil": 5, "lane": 5, "languag": 4, "lantz": 5, "laptop": 3, "larg": [5, 9], "larger": [3, 5], "largest": [0, 5, 10], "last": [0, 5], "lastli": [], "later": [1, 5], "latest": [0, 1, 5, 9], "latitud": 5, "latter": 5, "launch": [1, 9], "laura": 5, "lavin": 5, "law": 5, "lawrenc": 5, "layer": 5, "laz16": 5, "lazard": 5, "lbi": 5, "lbl": 5, "lbnl": 5, "lbrack": 5, "lc": 5, "lcc": 5, "lcc_1000miles_demand1_wind1_subferc_20230629": 10, "lcc_all": 10, "lcc_seamsd2b": 10, "lcc_seamsd3_certain": 10, "lcc_seamsd3_poss": 10, "lcc_seamsd3_possible_unconstrain": 10, "lcclike": 10, "lcoe": [5, 10], "lctrct": 5, "lctrctysmmr": 5, "ldc": 5, "le": 5, "lead": [3, 5, 10], "leakag": 5, "leap": [], "learn": 5, "least": 5, "leav": [1, 9], "led": 5, "left": [0, 2, 5, 9], "legal": 5, "legend": 1, "legisl": 5, "leido": 5, "length": [0, 5], "leq": 5, "less": [0, 3, 5], "let": [], "letter": 5, "level": [0, 3, 7, 8, 9, 10], "leverag": 5, "levi": 5, "levin": 5, "lew": 5, "lewi": 5, "lf": 9, "liabil": [5, 7], "liber": [], "libmamba": [], "licens": [4, 5, 9, 11], "lieberman": 5, "life": 5, "lifecycl": [5, 10], "light": 5, "like": [0, 1, 3, 5, 9, 11], "likelihood": 10, "lim": 6, "limit": [1, 4, 5, 10], "limited_ba": 10, "limited_counti": 10, "lin": [], "lina": 5, "line": [0, 1, 3, 4, 6, 7, 9, 10, 11], "line_map": 11, "linear": [4, 5], "linearli": 5, "link": [4, 5, 8, 9], "linkag": 0, "linkid": [], "linkpath": [], "linsei": 5, "linter": [], "linux": [2, 9], "liquid": 5, "list": [0, 1, 2, 3, 6, 9, 10, 11], "literatur": 5, "lithium": 5, "littl": 5, "liu": 5, "live": 5, "livesai": 5, "liz": 5, "lkb14": 5, "ll": [0, 11], "llm": 5, "llo": 5, "lml": 5, "ln": [], "load": [0, 6, 8], "load_": 5, "load_by_state_eia": 10, "load_hourly_ba_est": [], "load_participation_factors_st_to_ba": 10, "load_sourc": [], "load_source_hr_typ": [], "load_source_timezon": [], "loan": 5, "local": [1, 8, 9], "locat": [0, 1, 2, 3, 5, 8, 9, 10, 11], "log": [0, 11], "logan": 5, "logic": [5, 11], "login": [], "lolow": [], "lolp": 5, "long": [1, 4, 5, 7, 11], "longer": [2, 5, 7], "longest": 5, "longitud": 5, "look": [0, 1, 3, 4, 9, 11], "loop": [5, 10], "loos": 5, "lopez": [5, 10], "lord": 5, "lori": 5, "loss": 5, "loss_": 5, "lost": 5, "lot": [3, 5], "louisiana": 3, "low": [3, 5, 10], "lower": [3, 5, 8], "lowercas": 1, "lowest": 5, "lp": [0, 4], "lpg": 5, "lsc18": 5, "lsm": 5, "lst": 0, "lstfile": 0, "luke": 5, "lump": 5, "lvaro": 5, "lvoe": 8, "lvoe_load": 8, "lvoe_or": 8, "lvoe_rm": 8, "lvoe_rp": 8, "m": [5, 10], "m_": 5, "m_bar_width": 10, "m_map": 10, "m_style": 10, "ma": 5, "mab": 5, "mac": [0, 2, 9], "machin": [3, 5, 9], "macknick": 5, "maclaurin": 5, "macr": 5, "madaeni": 5, "made": [1, 4, 5], "magnitud": 5, "mahdi": 5, "mahon": 5, "mahroo": 5, "mai": [1, 3, 4, 5, 9, 10], "mail": [], "main": [3, 5, 6, 7, 8, 11], "main_pacif": [], "mainid": 5, "maintain": [5, 7], "mainten": 7, "major": 4, "make": [0, 1, 3, 4, 5, 7, 9, 11], "maker": 5, "manag": [4, 5, 7, 9], "manajit": 5, "mandat": [3, 10], "mandatori": 10, "maness": 5, "mangan": 5, "mani": [0, 3, 4, 5, 9], "manifest": 9, "manohar": 5, "manual": [1, 2, 5, 9], "manufactur": 5, "map": [0, 1, 3, 5, 10], "map_i_to_tech": [7, 10], "map_supplycurv": [], "march": [5, 10], "marci": 5, "marg_curt": [], "margin": [8, 10], "marginal_damages_by_reeds_ba": 10, "margoli": 5, "mari": 5, "mariano": 5, "marissa": 5, "mark": 5, "markdown": [2, 10], "market": [5, 10], "markup": [], "marshal": 5, "martinez": 5, "maryland": 5, "massachusett": 5, "mat": 5, "match": [0, 5], "materi": 5, "mathbf": 5, "mathemat": [4, 5], "matrix": 5, "matt": [1, 5], "matteo": 5, "matter": 5, "matthew": 5, "maureen": 5, "max": [0, 1, 5, 8], "max_cap_2035": 10, "max_load_pric": 8, "max_net_load_2012": 8, "maxag": 10, "maxim": 5, "maximum": [0, 5, 10], "maxrss": [], "maxwel": 5, "mb": [4, 5], "mbe": 7, "mbtu": [], "mckb15": 5, "mcmanamai": 5, "mcn": 5, "md": [2, 5], "me": 5, "mean": [0, 5, 7, 8, 10, 11], "mean_cf": [], "mean_cf_": [], "meanbiaserror_r": 10, "meaning": [], "meant": 5, "measur": 5, "medium": 5, "medlock": 5, "meet": [3, 5, 10], "megawatt": 5, "meho": 5, "mehrtash": 5, "mem": [], "member": [], "memori": 5, "mendelsohn": 5, "mengyao": 5, "mentor": [], "menu": 9, "mercantil": 5, "merg": [1, 3, 5], "mesh": 5, "meshek": 5, "messag": [0, 1], "met": 5, "meta": [1, 6, 10], "metadata": 11, "meteorolog": 5, "meter": 5, "methan": 5, "methane_leakage_r": 10, "method": [1, 7, 10], "methodolog": 5, "methodologi": 5, "metric": [0, 6, 8, 10], "mettet": 5, "mex_growth_r": 10, "mexican": 5, "mexico": [5, 10], "mgl": 5, "mgnb22": 5, "mhi": 5, "mhmc23": 5, "mhp": 5, "mi": 5, "micaela": 5, "michael": 5, "michal": 5, "michel": 5, "microsoft": [], "mid": [5, 10], "middl": [], "midwest": 5, "might": [1, 3, 5, 9], "mignon": 5, "mike": 5, "mile": 5, "milford": 5, "mill": 5, "million": [0, 5], "millstein": 5, "min": [1, 5], "min_cap": [], "min_retire_ag": 10, "mincf": 10, "mind": 9, "mingen_fix": 10, "mingw": 9, "miniconda": [], "miniconda3": 9, "minim": [0, 5, 7], "minimis": 5, "minimum": [0, 3, 10], "minloadb": 10, "minloadfrac0": 10, "minnesota": 5, "minor": 3, "minu": [5, 7], "minut": 5, "mirko": 5, "mislead": 3, "miso": 5, "misrepres": 5, "miss": 5, "mit20": 5, "mitig": 5, "mitsubishi": 5, "mix": 5, "mkdir": [], "mlml21": 5, "mm": 5, "mmbtu": 10, "mmhb14": 5, "mnhh12": 5, "mobil": 10, "mode": 5, "model": [3, 7, 8, 10], "modeled_region": 10, "modeledyear": 10, "moder": 10, "moderate_noflo": 10, "modern": 5, "modif": [1, 4], "modifi": [1, 3, 5], "modul": [4, 5], "modular": 5, "modulefil": [], "mogadali": 5, "mohammad": 5, "molten": 5, "moment": [], "monet": 5, "monetari": [5, 7, 9], "mongird": 5, "monitor": 5, "monopil": 5, "monoton": 3, "mont": 5, "montgomeri": 5, "month": [3, 5, 10], "month_to_season": 10, "monthli": [5, 10], "moor": 5, "more": [0, 1, 3, 4, 5, 6, 9], "moreland": 5, "morgan": 5, "mortal": 5, "most": [4, 5, 9, 11], "motiv": 5, "mount": 5, "mountain": 5, "move": [3, 5, 9], "mover": 5, "mower": 5, "mpi": 5, "mpra": 5, "ms05": 5, "msc": 5, "much": [5, 7, 10], "mulcahi": 5, "muller": 5, "mult": [5, 10], "multi": [5, 9], "multi_year": [], "multipl": [0, 1, 7, 9, 11], "multiple_priority_input": 10, "multipli": 10, "multiyear": 5, "municip": 5, "muratori": 5, "murphi": 5, "musial": 5, "must": [0, 1, 3, 5, 9, 10, 11], "mutual": 5, "mw": 10, "mw12": 5, "mwh": [0, 10], "mwh09": 5, "my": 0, "myriad": 5, "n": [1, 5, 6, 10], "n_cluster": 0, "na": 5, "nacion": 5, "nafi": 5, "name": [0, 1, 5, 6, 7, 8, 9, 11], "namepl": 5, "namovicz": 5, "nano": [], "nari": [5, 10], "naris2024": 10, "narrow": 5, "narwad": 5, "nat": 5, "nate": 5, "nathan": 5, "nathaniel": 5, "nation": [3, 4, 7, 8, 9, 10], "national_rps_frac_allscen": 10, "nationalrelaboratory20": 5, "nationwid": [5, 10], "nativ": [3, 5], "natur": [3, 10], "navig": [2, 9], "nc": 5, "ncpu": [], "ncsl": 5, "ne2": 5, "nearbi": 5, "nearli": 5, "neb": 5, "neb18": 5, "necessari": [4, 5], "necessarili": [5, 9], "necessit": 5, "need": [0, 2, 3, 4, 5, 7, 9, 10, 11], "neg": 5, "neglig": 5, "neighbor": 5, "neither": 5, "nelson": 5, "nem": [5, 7, 10], "neo": 4, "ner16": 5, "nerc": [3, 5, 10], "nerc10": 5, "nerc21": 5, "nerc_new_wkt": 10, "nerc_wkt": 10, "nercr": 0, "net": [7, 8], "net_firm_transfers_nerc": 10, "netl": [5, 10], "netload_num_hr": 8, "netload_time_styl": 8, "network": [1, 3], "neue": 0, "neuman": 5, "neumann": 5, "neutral": 5, "never": 10, "new": [1, 2, 3, 6, 7, 9, 10], "newer": 5, "newest": 5, "newgrp": [], "newli": 5, "newmark": 5, "next": [5, 11], "ng": [5, 10], "ng_aeo_2022_hog": 10, "ng_aeo_2022_log": 10, "ng_aeo_2022_refer": 10, "ng_aeo_2023_hog": 10, "ng_aeo_2023_log": 10, "ng_aeo_2023_refer": 10, "ng_crf_penalti": 10, "ng_crf_penalty_st": 10, "ng_demand_aeo_2022_hog": 10, "ng_demand_aeo_2022_log": 10, "ng_demand_aeo_2022_refer": 10, "ng_demand_aeo_2023_hog": 10, "ng_demand_aeo_2023_log": 10, "ng_demand_aeo_2023_refer": 10, "ng_tot_demand_aeo_2022_hog": 10, "ng_tot_demand_aeo_2022_log": 10, "ng_tot_demand_aeo_2022_refer": 10, "ng_tot_demand_aeo_2023_hog": 10, "ng_tot_demand_aeo_2023_log": 10, "ng_tot_demand_aeo_2023_refer": 10, "ngct": 5, "nhaap": 5, "nice": 1, "nichol": 5, "nichola": 5, "nicholassteckler17": 5, "nick": 5, "nicknam": [], "nicol": 5, "nina": 5, "nine": 5, "nitrogen": 5, "nj": 5, "nlcd_categori": 10, "nlcd_combined_categori": 10, "nldc": 5, "nm": 5, "no_bin_constraint": 10, "nock": 5, "nodal": 5, "node": 5, "nomin": 5, "non": [1, 4, 5, 7, 9, 10], "nonclean": 5, "noncompli": 5, "none": [5, 8], "none_ba": 10, "noneconom": 5, "nonelectr": 5, "nonfuel": 5, "nonlinear": 5, "nonlinearli": [], "nonrenew": 5, "nopt": [], "nor": 5, "noretir": 10, "normal": 5, "north": [4, 5], "northeast": [3, 5], "northwest": 5, "nosubmit": [], "notat": 5, "note": [1, 2, 3, 4, 5, 9, 10, 11], "notebook": 11, "notic": 11, "notin": 5, "notvsc": 10, "notwithstand": 5, "noun": [], "novacheck": 5, "novemb": 5, "now": [3, 5, 9], "nox": [5, 10], "np": [], "npd": 5, "nrc": 5, "nrcnationalrcouncil10": 5, "nre19": 5, "nre20": 5, "nrel": [1, 5, 7, 9, 10], "nrel12": 5, "nrel23": 5, "nrel_nt": [], "nrelna": [], "nrelnas01": 11, "nrelqnap01d": 1, "nrg": 5, "nsd": 5, "nsrdb": [5, 10], "ntask": [], "nuanc": 5, "nuclear": [4, 10], "nuclear_ba_ban_list": 10, "nuclear_subsidi": 10, "nuke_fom_adj": 10, "null": [], "num": 1, "number": [0, 1, 3, 5, 6, 8, 9], "numer": [1, 4, 5], "numpi": [], "nunemak": 5, "nv": 5, "nvoc": 5, "nvoe": 5, "ny": 5, "nyiso": 5, "o": [5, 10, 11], "oak": 5, "obei": 3, "object": [4, 5], "oblig": 5, "obtain": [3, 5, 7, 9], "occur": 5, "ocean": 5, "octob": 5, "off": [3, 5, 10], "offdelim": [], "offer": 5, "offic": 5, "offici": 5, "offlist": [], "offset": [5, 7], "offshor": 10, "offshore_req_30by30": 10, "offshore_req_default": 10, "offtext": [], "ofr20081296": 5, "ofs": 10, "ofs_0_open_moder": 10, "ofs_prescribed_builds_limited_ba": 10, "ofs_prescribed_builds_limited_counti": 10, "ofs_prescribed_builds_open_ba": 10, "ofs_prescribed_builds_open_counti": 10, "ofs_reduc": 10, "ofs_resource_class": 10, "ofs_supply_curv": 10, "ofs_supply_curve_raw": 10, "ofstyp": 10, "ofstype_i": 10, "often": [5, 8, 11], "oftop": 5, "og": 5, "ohio": 5, "oil": [5, 10], "oklahoma": 3, "oklaunion": 5, "old": 5, "older": [3, 5, 8, 9], "olson": 5, "omiss": 5, "onc": [1, 2, 5, 7, 9, 11], "ondelim": [], "one": [0, 1, 5, 8, 9, 11], "one_year": [], "ongo": 7, "onli": [0, 1, 3, 5, 6, 7, 8, 9, 10], "onlin": 5, "onlist": [], "ons": [8, 10], "ons_6mw_input": 10, "ons_exog_cap_limited_ba": 10, "ons_exog_cap_limited_counti": 10, "ons_exog_cap_open_ba": 10, "ons_exog_cap_open_counti": 10, "ons_exog_cap_reference_ba": 10, "ons_exog_cap_reference_counti": 10, "ons_prescribed_builds_limited_ba": 10, "ons_prescribed_builds_limited_counti": 10, "ons_prescribed_builds_open_ba": 10, "ons_prescribed_builds_open_counti": 10, "ons_prescribed_builds_reference_ba": 10, "ons_prescribed_builds_reference_counti": 10, "ons_reduc": 10, "ons_refer": 10, "ons_resource_class": 10, "ons_supply_curv": 10, "ons_supply_curve_raw": 10, "onshor": [5, 8, 10], "ontext": [], "onward": [3, 5], "oo": 10, "ooki": 5, "oosfrac": 10, "op": 5, "open": [1, 2, 4, 5, 6, 9, 10, 11], "open_ba": 10, "open_counti": 10, "openei": 9, "oper": [1, 3, 8, 10, 11], "opex": 7, "opportun": 5, "oppos": 5, "opposit": 5, "opres_period": 10, "opt": [], "optim": [0, 4, 5, 11], "optimize_period_weight": 0, "option": [0, 1, 3, 4, 6, 8, 10, 11], "or_": 5, "orang": 5, "orcat": 10, "orcid": 5, "order": [0, 1, 5, 11], "ordin": 5, "oregon": 5, "org": [1, 5, 9], "organ": 5, "orient": [4, 10], "origin": [5, 7, 10], "original_rev_fold": [], "original_sc_fil": [], "orion": 1, "ornl": 5, "orperc": 10, "ortyp": 10, "osi": 4, "other": [0, 1, 4, 6, 7, 8, 10], "otherwis": [5, 8], "oubeidillah": 5, "our": [5, 7, 11], "out": [0, 1, 3, 5, 10], "outag": [5, 10], "outage_forced_stat": 10, "outage_planned_stat": 10, "outcom": 5, "outdat": [1, 10], "outer": 5, "outli": 0, "outlier": 5, "outlin": [], "outlook": [5, 10], "output": [0, 1, 5, 6, 8, 9, 10], "output_pric": 8, "output_timezon": [], "outputs_": 8, "outsid": [5, 9], "over": [1, 3, 5, 7, 10], "overal": [0, 5], "overland": 5, "overlap": 5, "overlin": 5, "overnight": 5, "overview": [], "overwrit": [9, 10], "owen": 5, "own": [0, 1, 5, 6, 7, 11], "ownership": 5, "oxid": 5, "ozon": 5, "p": [5, 10, 11], "p04001": 5, "p04019": 5, "p04023": 5, "p1": 5, "p119": 3, "p120": 3, "p122": 3, "p124": 3, "p19": 3, "p20": 3, "p28": 3, "p29": [3, 5], "p30": 5, "p44": 3, "p49": 3, "p50": 3, "p68": 3, "p71": 3, "p72": 3, "p97": [], "p98": [], "p99": 3, "p_": 5, "p_a": 5, "p_r": 5, "p_srht": 5, "pa21": 5, "pacif": [5, 10], "packag": [4, 9, 11], "packei": 5, "page": [1, 4, 9], "pai": 5, "paig": 5, "pair": [5, 9], "palchak": 5, "palett": 1, "palmer": 5, "pan": 1, "panda": [], "panel": [], "papadia": 5, "paper": 5, "paragraph": 5, "parallel": [], "paramet": 10, "parameter": 5, "parametr": 5, "parcel": 5, "parenthesi": [], "paritosh": 5, "park": 5, "pars": [], "part": [0, 3, 5], "particip": [5, 10], "particul": 5, "particular": [4, 5, 10], "particularli": [5, 7], "partit": [], "partnership": 5, "pasha": 5, "paso": 3, "pass": [5, 7, 11], "passphras": [], "password": [], "past": [1, 3, 5, 7], "pastur": 5, "patch": [], "path": [0, 1, 5, 6, 8, 9, 11], "path_to_run_fold": [], "pathwai": 5, "patrick": [5, 7], "pattern": [5, 11], "paul": 5, "pavlo": 5, "payment": [5, 7, 10], "pb": [6, 8], "pb_load_loc": 8, "pb_load_nat": 8, "pb_rm_loc": 8, "pb_rm_nat": 8, "pbcopi": [], "pbrown": [], "pc": [], "pc1": 5, "pcat": 10, "pcm": 5, "pd": 5, "pdb": [], "pdf": [5, 7, 10], "peach": 5, "peak": [0, 5, 8], "peartion": 5, "peer": 5, "peh": 5, "pend": [], "penetr": 5, "penultim": 5, "peopl": 5, "per": [0, 8, 10, 11], "percent": 5, "perfect": 5, "perfectli": 5, "perforamnc": [], "perform": [0, 3, 4, 10], "period": [0, 3], "period_szn_us": [0, 10], "perl": 4, "perlack": 5, "permalink": [], "perman": 5, "permeabl": 5, "permiss": 1, "permit": 5, "persist": 5, "person": [], "perspect": 5, "pervad": 5, "peter": 5, "petti": 5, "pham": 5, "phase": 5, "phaseout": 5, "philipp": 5, "photovolta": 10, "php": 5, "physic": 5, "pi": [], "pick": 1, "picker": [], "pieter": [5, 7], "pinchuk": 5, "pinpoint": 0, "pip": 11, "pipe": [1, 5], "pipelin": [5, 10], "pipeline_cost_mult": 10, "pital": 5, "pivot": 11, "pivot_def": 11, "pivot_definit": 11, "pkg": 9, "pkgs_dir": [], "pkl": [], "place": [5, 9, 10, 11], "plai": [1, 5], "plain": 5, "plan": [4, 7, 10], "plant": [7, 10], "plant_characterist": [], "plantcat": 10, "plate": 5, "platform": 5, "pleas": [2, 3, 9], "plexo": 6, "plexos_export": 11, "plexos_node_monthly_lpf_ercot": 10, "plexos_node_seasonal_lpf_wi": 10, "plexos_node_to_reeds_ba": 10, "plexos_node_to_zone_ei": 10, "plexos_to_re": [], "plo": 5, "plot": [1, 5, 6, 7], "plu": [5, 7], "plug": 5, "pm": 5, "pn14": 5, "pna": 5, "png": 1, "poc": [], "poi": 5, "point": [0, 1, 5, 6, 7, 10], "polici": [3, 4, 10], "ponc": 5, "pond": 5, "pone": 5, "pop": 1, "popul": [10, 11], "porou": 5, "porro": 5, "port": 1, "portabl": [], "portal": [5, 10], "portfolio": 7, "portion": [3, 5, 7], "posit": 5, "possess": 4, "possibl": [3, 5, 9], "post": [0, 4, 5], "post_processed_supply_curv": [], "postcal": 10, "postprocess": [5, 6, 7, 8], "postprocess_for_tableau": 11, "potent": 5, "potenti": [4, 7, 10], "power": [4, 7, 10], "powerfracdownstream_": 5, "powerfracupstream_": 5, "powerpoint": 6, "powershel": [], "ppm": 0, "pr": 5, "pra": [5, 9], "practic": [3, 5, 7], "pras_load_2035": 10, "pras_vre_gen_2035": 10, "pre": [0, 5, 10], "preced": 0, "precis": 5, "precursor": 5, "predefin": 5, "predetermin": 5, "prefer": 5, "preffer": [], "prefix": [0, 6, 9], "prematur": 5, "premis": 5, "prepar": 5, "prepend": [], "prepopul": [], "prepost": 10, "preprocess": [], "prescrib": [3, 10], "prescript": 3, "prescriptivelink0": 10, "presenc": 4, "present": [0, 1, 4, 8, 11], "preserv": [], "preset": 1, "press": [1, 5, 9], "pressur": 5, "preu": 5, "prevail": 5, "prevent": 5, "previou": [3, 5, 7], "previous": [5, 9], "previs": 5, "price": [1, 3, 6, 8, 10], "price_": 5, "primal": 5, "primari": [4, 5, 7], "primarili": [4, 5, 7], "prime": 5, "princip": 5, "print": 6, "prior": [2, 3, 5], "priori": 5, "priorit": 5, "priority_input": 10, "privat": 5, "privileg": 9, "prm": [3, 5, 10], "prm_annual": 10, "prmn": 5, "probabilist": 5, "probabl": [3, 5], "problem": [0, 4, 5, 11], "proce": 2, "procedur": [5, 7, 9], "proceed": 5, "process": [0, 1, 5, 9], "process_styl": 10, "processor": 9, "processtim": 6, "procur": 5, "prod": 5, "prod_": 5, "prodesen": 5, "produc": [3, 5, 7, 10], "product": [3, 4, 7, 10], "profession": 5, "profil": [3, 6, 8, 10], "profile_dir": [], "profile_dset": [], "profile_file_format": [], "profile_id_col": [], "profile_path": 8, "profile_timezon": 8, "profile_weight_col": [], "profiles_aggprof": [], "profit": 5, "program": [4, 5, 9], "programa": 5, "progress": 5, "progresss": [], "prohibit": 5, "project": [3, 5, 7, 9, 10], "projectnam": [], "prompt": 2, "properli": [1, 5, 9], "properti": [5, 9], "proport": 7, "propos": 5, "proprietari": 11, "protect": 5, "protocol": [], "provid": [0, 4, 5, 7, 9, 10], "provinc": 5, "provis": 5, "proxi": 5, "proxim": 5, "psh": [5, 10], "psh_supply_curves_capacity_10hr_ref_dec2022": 10, "psh_supply_curves_capacity_10hr_ref_mar2024": 10, "psh_supply_curves_capacity_10hr_wephemeral_dec2022": 10, "psh_supply_curves_capacity_10hr_wephemeral_mar2024": 10, "psh_supply_curves_capacity_10hr_wexist_mar2024": 10, "psh_supply_curves_capacity_10hr_wexist_weph_mar2024": 10, "psh_supply_curves_capacity_12hr_ref_dec2022": 10, "psh_supply_curves_capacity_12hr_ref_mar2024": 10, "psh_supply_curves_capacity_12hr_wephemeral_dec2022": 10, "psh_supply_curves_capacity_12hr_wephemeral_mar2024": 10, "psh_supply_curves_capacity_12hr_wexist_mar2024": 10, "psh_supply_curves_capacity_12hr_wexist_weph_mar2024": 10, "psh_supply_curves_capacity_8hr_ref_dec2022": 10, "psh_supply_curves_capacity_8hr_ref_mar2024": 10, "psh_supply_curves_capacity_8hr_wephemeral_dec2022": 10, "psh_supply_curves_capacity_8hr_wephemeral_mar2024": 10, "psh_supply_curves_capacity_8hr_wexist_mar2024": 10, "psh_supply_curves_capacity_8hr_wexist_weph_mar2024": 10, "psh_supply_curves_cost_10hr_ref_dec2022": 10, "psh_supply_curves_cost_10hr_ref_mar2024": 10, "psh_supply_curves_cost_10hr_wephemeral_dec2022": 10, "psh_supply_curves_cost_10hr_wephemeral_mar2024": 10, "psh_supply_curves_cost_10hr_wexist_mar2024": 10, "psh_supply_curves_cost_10hr_wexist_weph_mar2024": 10, "psh_supply_curves_cost_12hr_ref_dec2022": 10, "psh_supply_curves_cost_12hr_ref_mar2024": 10, "psh_supply_curves_cost_12hr_wephemeral_dec2022": 10, "psh_supply_curves_cost_12hr_wephemeral_mar2024": 10, "psh_supply_curves_cost_12hr_wexist_mar2024": 10, "psh_supply_curves_cost_12hr_wexist_weph_mar2024": 10, "psh_supply_curves_cost_8hr_ref_dec2022": 10, "psh_supply_curves_cost_8hr_ref_mar2024": 10, "psh_supply_curves_cost_8hr_wephemeral_dec2022": 10, "psh_supply_curves_cost_8hr_wephemeral_mar2024": 10, "psh_supply_curves_cost_8hr_wexist_mar2024": 10, "psh_supply_curves_cost_8hr_wexist_weph_mar2024": 10, "psh_supply_curves_dur": 10, "ptc": [3, 5], "ptdf": 5, "pty": [], "pub": 10, "public": [4, 5], "publicli": 5, "publish": [3, 5, 10], "pull": [10, 11], "pulver": 5, "pump": 5, "purchas": [5, 7, 10, 11], "purkayastha": 5, "purpos": [0, 5, 7, 8], "push": [2, 5], "put": 5, "pv": [0, 5, 7, 10], "pv_": 5, "pvb": [3, 5, 10], "pvb_agg": 10, "pvb_benchmark2020": 10, "pvb_config": 10, "pvdepr": 5, "py": [1, 2, 3, 6, 7, 8, 11], "pydata": 1, "pytest": [], "python": [1, 4, 6, 7, 8, 11], "q": 5, "q1": 5, "q_": 5, "q_srht": 5, "quad": [5, 10], "quadrillion": 5, "qual1": [], "qual2": [], "qual3": [], "qualifi": 5, "qualiti": [3, 5], "quantifi": 5, "quantit": 5, "quantiti": [3, 5], "quarter": 10, "quarterli": [], "queri": 1, "question": [4, 5], "queue": [5, 9], "quickli": 5, "quit": [], "quot": 9, "quota": [], "r": [0, 1, 4, 5, 7, 10, 11], "r2": [], "r2p": [], "r2x": [], "r_c": 10, "r_cs_distance_mi": 10, "r_rr_adj_ba": 10, "r_rr_adj_counti": 10, "r_rr_lines_to_25_nearest_neighbor": 10, "r_st": [], "ra": [0, 5], "radar": 5, "radiat": 5, "rainbow": [], "ram": [3, 9], "ramo": 5, "ramp": [5, 10], "ramprat": 10, "ramptim": 10, "ramteen": 5, "ran": 5, "random123": 9, "randomli": 8, "rang": 5, "rank": 5, "rapid": 5, "rar": 5, "rate": [3, 6, 10], "ratepay": 7, "rather": 5, "ratio": [1, 5, 10], "raw": 5, "rbrack": 5, "rc17": 5, "rcp": 5, "rd": 10, "re": [1, 5, 6, 9, 10, 11], "reach": 5, "reactanc": 5, "reactiv": 5, "reactor": 5, "read": [0, 5], "readabl": [], "readi": 5, "readm": 2, "real": 5, "realist": [3, 5], "realli": 11, "reason": 5, "reassign": 5, "rebal": 5, "rebecca": 5, "rebuild": [5, 7], "rebuilt": 5, "rec": [3, 5, 10], "recalcul": 5, "recast": 5, "receiv": [5, 9], "recent": [4, 5], "recircul": 5, "reclam": 5, "recommen": 3, "recommend": [3, 5, 9], "recompil": [], "recomput": 5, "reconductor": 5, "recopi": [], "recov": [5, 7], "recoveri": 5, "recstyl": 10, "rectabl": 10, "recurs": [], "recycl": 5, "red": 5, "redirect": 11, "reduc": [0, 1, 4, 5, 7, 10], "reduct": [5, 10], "reed": [1, 2, 7, 8], "reeds2": [8, 9], "reeds2pra": 5, "reeds2x": [], "reeds_augur": 0, "reeds_augur_": 0, "reeds_ba": [], "reeds_data_": 0, "reeds_generator_databas": [], "reeds_generator_database_final_eia": 10, "reeds_path": [], "reeds_region_tz_map": 10, "reeds_run_path": 8, "reeds_scenario": 1, "reeds_to_rev": [], "reeds_use_slurm": [], "reedso": [], "reedsplot": 6, "reedsrun": 6, "ref": [5, 6, 9], "refer": [1, 3, 7, 9, 10, 11], "referenc": [], "reference_ba": [3, 10], "reference_counti": 10, "reflect": [3, 4, 5, 8, 10], "reform": 5, "reformul": 5, "refresh": 1, "refs2009": 10, "refug": 5, "refund": 5, "refurbish": 5, "reg_cap_cost_mult_default": 10, "reg_map_fil": [], "reg_map_path": [], "reg_out_col": [], "regard": [3, 5], "regardless": [], "regim": 5, "region": [0, 1, 3, 6, 7, 8, 10, 11], "region_map": 11, "regions_for_histor": 10, "registri": 9, "regress": 5, "regul": 10, "regular": 5, "regulatori": [5, 7], "reichenberg": 5, "reimer": 5, "reinforc": [], "rel": [3, 5, 8, 11], "relat": [0, 5, 6, 8, 9, 10], "relatedli": 5, "relationship": [], "relax": 5, "releas": [3, 5], "relev": [3, 5], "reli": 5, "remain": [3, 5], "remaind": 5, "rememb": [], "remot": [], "remov": [2, 5], "renam": [1, 2], "render": 1, "renew": [4, 7, 9, 10], "reorder": 1, "rep": 5, "rep_profiles_0": [], "repeat": 5, "replac": [2, 5, 7], "repli": [], "repo": [1, 3, 6, 9], "report": [0, 7, 10], "repositori": [2, 4, 5, 6, 10], "repres": [0, 3, 4, 5, 7, 10], "represent": [3, 5], "represnt": 0, "reproduc": 0, "request": [5, 9], "requir": [1, 2, 3, 6, 7, 8, 10, 11], "res_marg_styl": 8, "research": 4, "reserv": [3, 7, 8], "reservoir": [5, 10], "reset": 1, "resid": 5, "residenti": 5, "residential_ghp_delta": 10, "residu": 5, "resist": 5, "resiz": 1, "reslim": [], "resolut": [3, 4, 9, 10], "resolv": [0, 5, 9], "resourc": 3, "resource_source_timezon": [], "resourceclass": 10, "respect": [5, 10], "respond": 5, "respons": [5, 7, 9, 10], "rest": [1, 5], "restart": [0, 1, 6], "restart_run": [0, 6], "restor": 5, "restrict": 1, "restructur": 5, "result": [0, 1, 5, 6, 10, 11], "retail": [3, 5, 6], "retail_load": 7, "retail_rate_calcul": 7, "retail_rate_compon": 7, "retail_rate_modul": 7, "retain": [], "retir": [3, 10], "retire_penalti": 10, "retrofit": [5, 7], "return": [5, 9], "reus": 5, "rev": [7, 8, 10], "rev_cas": [], "rev_json": [], "rev_path": 10, "rev_paths_fil": [], "rev_sc_columns_for_hourl": 10, "rev_sc_path": 8, "rev_supply_curv": 10, "rev_transmission_basecost": 10, "revalue_out": 8, "revenu": [5, 7, 10], "revers": 5, "review": 5, "revis": [], "reza": 5, "rggi": [3, 5, 10], "rggi_fact_sheet": 5, "rggi_stat": 10, "rggicon": 10, "rh22": 5, "rho": 5, "rhode": 5, "ri": 5, "richard": 5, "ridg": 5, "right": [1, 5, 9], "risk": 5, "river": 5, "rivier": 5, "rjg": 5, "rldc": 5, "rnew": 1, "ro": 5, "road": 5, "roadless": 5, "robert": 5, "robin": 5, "robust": 5, "rock": 5, "roger": 5, "role": 5, "roll": [], "ronald": 5, "rooftop": 5, "room": [], "root": 2, "rore": 5, "rose": 5, "rosenlieb": 5, "rossol": 5, "roughli": [3, 5], "round": 5, "row": [0, 1, 3, 9, 11], "rp": [3, 5, 7, 8, 10], "rps_fraction": 10, "rpscat": 10, "rpss": 5, "rr": [5, 10], "rroe": 5, "rsa": [], "rsc_dat_for_histor": 10, "rsc_mult": 10, "rser": 5, "rsmap": 10, "rstudio": [], "rsync": [], "rto": [1, 5, 10], "rto_wkt": 10, "rubi": 4, "ruff": [], "rule": [], "run": [2, 5, 7, 8, 10, 11], "run_reeds2pra": 6, "runbatch": [], "runfil": [3, 10], "runstatu": 6, "runtim": [5, 10], "rural": 5, "ruth": 5, "ryan": 5, "s12667": 5, "s41560": 5, "s_": 5, "sac": 5, "sacc": [], "sacct": [], "safe": 5, "sai": [1, 3, 5, 11], "said": 10, "sale": 10, "salin": 5, "salt": 5, "sam": 5, "same": [0, 1, 5, 7, 9, 10], "sameera": 5, "sampl": 10, "samu": 5, "samuel": 5, "san": 5, "sanctuari": 5, "sandia": 5, "sandor": 5, "sarah": 5, "satisfactori": 5, "satisfi": [3, 5], "sattler": 5, "satur": 5, "save": [1, 2, 5, 11], "save_sc_output": [], "save_time_output": [], "sb32": [3, 5], "sbash": [], "sbatch": [], "sbhs03": 5, "sc": 10, "sc_cat": 10, "sc_path": [], "sc_point_gid": [], "sc_point_grid": 10, "scalar": 10, "scale": [1, 3, 10], "scb": 5, "scen_r_t": 11, "scenario": [0, 1, 3, 4, 6, 8, 9, 10, 11], "scenic": 5, "scghg_annual": 10, "schedul": [5, 7], "schemat": 5, "scheme": 4, "schleifer": 5, "schlosser": 5, "scienc": 5, "scientist": 5, "scm": [], "scope": [4, 5], "scorpio": 1, "scott": 5, "scratch": [], "screen": 1, "screenshot": [1, 9], "script": [0, 2, 5, 7, 9, 11], "scrub": 5, "scrubber": 5, "sdbin": 10, "sdk": 5, "seacapadj_hi": 10, "sean": [5, 7], "search": 9, "searci": 5, "season": 10, "second": [0, 1, 5], "secondari": 5, "secretar\u00eda": 5, "section": [0, 1, 5, 9], "sector": [4, 10], "secur": 5, "see": [0, 1, 4, 5, 6, 9, 10], "seed": 5, "seek": 5, "seel": 5, "seen": 5, "segal": 5, "segment": 5, "segreg": 10, "sei": 5, "select": [0, 1, 3, 5, 9], "select_year": [], "self": [5, 11], "semicolon": [], "semin": 5, "send": [1, 5], "sener": 5, "sengupta": 5, "sens": 5, "sensit": 5, "sent": [], "sentenc": [], "seongeun": 5, "separ": [0, 1, 5, 7, 9], "septemb": [3, 5], "sequenc": 5, "sequenti": 5, "sequest": 5, "sequestr": 5, "sera": 5, "sergi": 5, "seri": [1, 5, 11], "serv": [1, 4, 5, 6, 7], "server": [1, 4], "servi": [], "servic": [4, 7, 8, 10], "session": 1, "set": [0, 1, 3, 5, 6, 8, 9, 11], "set_allszn": 10, "set_szn": 10, "setback": 5, "seto": [], "setup": 4, "seven": 5, "sever": [3, 5, 6, 7, 10, 11], "sgp": 5, "sh": [0, 1, 2], "sha2": [], "shade": 5, "shaneyfelt": 5, "shapefil": [5, 11], "sharad": 5, "share": [1, 5, 9, 11], "sharehold": 7, "sharon": 5, "shaughnessi": 5, "shed": 5, "sheet": [1, 5, 7, 11], "shelain": 5, "shelbi": 5, "shell": 9, "shelter": 5, "shift": [1, 5, 10], "shift_timezon": [], "shih": 5, "ship": 5, "shore": 5, "short": [5, 10], "shortcom": 5, "shortcut": 0, "shorten": 5, "shorter": [5, 6], "shortest": 5, "shortfal": 5, "should": [0, 1, 2, 3, 4, 5, 9], "show": [0, 1, 5, 6, 10], "showalt": 5, "shown": [1, 5, 9], "shtml": 5, "shuffl": 5, "si": [4, 9], "side": [1, 5], "sidebar": [], "sigma": 5, "sign": [], "signific": 5, "significantli": [5, 10], "sigrin": 5, "silicon": 9, "similar": [5, 9], "similarli": [0, 5, 6, 7], "simon": 5, "simpl": [5, 11], "simpli": [1, 5, 9, 11], "simplif": 5, "simplifi": [3, 5, 7], "simul": 5, "simult_run": [], "simultan": [1, 5, 9], "sinc": [5, 9, 10], "singh": 5, "singl": [3, 5, 9, 10, 11], "single_profil": [], "sink": 5, "sinnott": 5, "sioshansi": 5, "sistema": 5, "site": [1, 3, 5, 7, 8, 10], "site_bin_map": 10, "sitemap": 10, "sitemap_offshor": 10, "situ": 5, "situat": 5, "six": 5, "size": [1, 3, 4, 10], "sjn": 5, "skip": [], "skip_check": [], "sklearn": 0, "sl": [], "slash": [], "slice": 5, "slide": [3, 5], "slightli": 5, "slope": 5, "slower": [], "slurm": [], "small": [3, 5, 7], "smaller": [0, 3, 5, 10], "smallest": 5, "smart": [], "smartgit": [], "smax": [], "smb": [], "smd14": 5, "smeer": 5, "smi14": 5, "smith": 5, "smooth": 10, "smr": [5, 10], "snapshot": 0, "snl": 5, "so": [0, 1, 5, 8, 9, 10], "so2": 10, "social": 5, "societi": 5, "sodium": 5, "sofia": 5, "softwar": [5, 9, 11], "solar": [3, 7, 10], "sole": 5, "solicit": 5, "solid": 5, "solut": [5, 9, 11], "solv": [0, 1, 4, 5, 10], "solver": 4, "some": [1, 3, 4, 5, 7, 9, 10, 11], "some_dir_containing_run": 11, "some_directory_containing_run": 11, "somebodi": [], "someon": [], "someproject": 1, "somerun": 1, "someth": [0, 9], "sometim": [5, 11], "somewhat": 5, "sophi": 5, "sophist": 5, "sorbent": 5, "sort": 5, "sourabh": 5, "sourc": [0, 1, 3, 4, 7, 9], "sources_": 2, "sources_documen": 2, "sources_document": 2, "sources_files_ad": 2, "sources_files_delet": 2, "sources_untracked_fil": 2, "south": 3, "southeast": 5, "southern": 5, "space": 5, "span": 5, "spatial": [0, 3, 4, 8, 9, 10, 11], "spatialflex": [], "spatio": 8, "speak": [], "special": [], "special_input_data": [], "special_input_data_2022_11_28": [], "specif": [0, 5, 7, 9, 10], "specifi": [0, 1, 5, 8, 9, 10, 11], "speed": [5, 10], "spent": [], "sph95": 5, "spin": 5, "spitsen": 5, "split": [1, 3, 5, 7], "sponsor": 5, "spreadsheet": 5, "spring": 5, "spur": 7, "spurlin": 5, "spurline_cost": 10, "spyrou": 5, "sq": [], "sqft": 8, "sql": 11, "sqltype": 11, "squ": [], "squar": 5, "squeezer": [], "squeue": [], "sr": 5, "srun": [], "srun_templ": [], "ssl": 9, "ssl_verifi": 9, "ssrn": 5, "st": [0, 1, 10], "st_wkt": 10, "stabl": [], "stack": [1, 5], "stage": 5, "stai": [5, 8], "stakehold": 5, "standalon": 5, "standard": [0, 3, 4, 7, 9, 10, 11], "standard_reeds_analysi": 11, "standard_scenario": [], "stanford": 5, "start": [1, 6, 7, 10], "start2023_100pct2035": [], "start_1am": [], "start_year": [], "startcost": 10, "starttim": 6, "startup": 5, "startuptyp": [], "startyear": 6, "state": [3, 6, 7, 8, 10], "state_abbrev": 10, "state_cap": 10, "state_cod": 10, "state_fips_cod": 10, "statement": [0, 11], "states_acs_high_stack_2017": 10, "states_h6c_high_stack_2017": 10, "static": [1, 3, 5, 7], "statist": 5, "statu": [0, 5], "statutori": 5, "statutorili": 5, "stdby": [], "stderr": 11, "stdout": 11, "stdscen": 10, "steadi": 5, "steam": 5, "steckler": 5, "stehli": 5, "steinberg": 5, "step": [0, 3, 5, 9, 10], "stephen": 5, "steven": 5, "stewart": 5, "stick": 3, "still": [1, 5, 7], "stock": 7, "stoll": 5, "stop": 1, "stoptim": 6, "storag": [3, 4, 9], "storage_dur": 10, "storage_duration_pshdata": 10, "storage_mand": 10, "store": [0, 5, 10], "storin": 5, "storin_": 5, "storinmaxfrac": 10, "storout": 5, "storout_": 5, "stortran_add": 10, "straight": 11, "strategi": 5, "stream": [5, 10], "strength": 5, "stress": [0, 3], "stressperiods_us": 10, "string": [0, 1, 9, 11], "stringent": 5, "structur": 11, "strzepek": 5, "stt": 5, "sttstc": 5, "stuart": 5, "studi": [4, 10], "studio": [], "stuff": 5, "style": [1, 4, 5, 8, 10], "stylist": 1, "styliz": 5, "sub": 5, "subbitumin": 5, "subcategori": 5, "subcommand": 1, "subcrit": 5, "subdirectori": [9, 10], "subdivid": 5, "subfold": 9, "subhourli": 5, "subject": 5, "submiss": [4, 9], "submit": [], "submitt": [], "subnat": 5, "subregion": 5, "subscrib": 4, "subscript": 5, "subsect": 5, "subsector": 5, "subsequ": 5, "subset": [3, 5, 10], "subsetvar": [], "subsidi": 5, "substanti": 5, "substat": 7, "substr": 0, "subtech": 10, "subtract": [5, 7], "subtract_exog": [], "suburban": 5, "succe": [], "success": 5, "successfulli": [0, 9], "sucessfulli": 9, "sudden": 5, "suffer": 5, "suffici": 5, "suffix": 9, "suggest": [], "suggeston": 9, "suit": [4, 5, 7, 9], "suitabl": 5, "sulfur": 5, "sullivan": 5, "sulphur": 5, "sum": [0, 1, 5, 7, 11], "sum_": 5, "summar": 5, "summari": 7, "summat": [], "summer": [3, 5], "sun": 5, "sunk": 5, "sunni": 5, "sunris": 5, "sunset": 5, "sunshot": 5, "sunshot2030": 10, "supercharg": [], "supercrit": 5, "supplement": 5, "suppli": [3, 7, 8, 10], "supply_chain_adjust": 10, "supply_curv": [], "supply_curve_cost_per_mw": [], "supply_curve_data": [], "supplycurve_metadata": 10, "supplycurvedata": [], "support": [2, 5, 8, 11], "suppress": 1, "sure": [0, 9], "surfac": [5, 10], "surround": 5, "survei": 5, "susan": 5, "sustain": 5, "sw": [0, 10], "sw_": [], "sw_one": [], "sw_reservemargin": [], "sw_upgrad": 10, "switch": [3, 5, 8, 9, 10], "switch1": [], "sxl": 5, "sy": 5, "sy2012d003": 0, "sy2012d003h004": 0, "sy2012w001": 0, "sy2012w001h052": 0, "symbol": 1, "sync": [], "synchron": 5, "syntax": [], "synthet": 5, "system": [7, 9, 10], "systemcost": 10, "systemcost_": 5, "systemwid": 5, "szn": [0, 5], "t": [0, 1, 2, 5, 7, 8, 9, 10, 11], "t_": 5, "tab": [1, 5], "tabl": [5, 11], "table_9": 10, "tableauhyperapi": 11, "tables_to_aggreg": [10, 11], "tackl": [], "tag": [3, 5], "tail": [], "take": [1, 5, 6], "taken": [5, 7, 9], "talk": [], "tam19": 5, "tangent": 5, "tank": 5, "target": [3, 5, 7, 10], "target_fold": [], "tariff": 5, "task": [4, 5], "tax": [3, 10], "taxabl": 5, "tb19": 5, "tc_phaseout_schedule_ira2022": 10, "tcf": 5, "tco": 5, "teagan": 5, "team": [4, 5], "tech": [1, 5, 8], "tech_ctt_wst": 10, "tech_map": 10, "tech_resourceclass": 10, "tech_styl": 10, "technic": [], "technolgi": 10, "technolog": [4, 5], "technologi": [3, 4, 7, 8, 10], "techs_ban": 10, "techs_banned_c": 10, "techs_banned_imports_rp": 10, "techs_banned_rp": 10, "techs_default": 10, "techs_subsetfortest": 10, "ted": 5, "teichgraeb": 5, "tej": 5, "tell": 11, "temperatur": [5, 10], "temperature_celsiu": 10, "templat": [], "tempor": [0, 3, 8, 10], "temporari": 5, "ten": 5, "tend": 5, "tension": 5, "teppc": 5, "terawatt": 5, "term": [4, 5, 7, 10], "termin": [1, 3, 5, 9], "terrain": 5, "tessum": 5, "test": [4, 5, 9], "test_fil": [], "test_filt": [], "test_mod": [], "test_ref": 9, "testbatch": 11, "testbatch_carbtax": 11, "testbatch_refseq": 11, "testbatch_suit": 11, "tester": 5, "testin": 10, "texa": [3, 5], "text": [1, 10], "tg": 10, "tg_rsc_cspagg": 10, "tg_rsc_cspagg_tmp": 10, "tg_rsc_upvagg": 10, "than": [0, 3, 5, 7, 10], "thank": 5, "thei": [0, 1, 2, 5, 10, 11], "them": [0, 1, 5, 11], "themat": 5, "themselv": 1, "therebi": [5, 7], "therefor": [3, 4, 5, 7], "thermal": [5, 7, 10], "thermoelectr": 5, "thesourc": [], "thi": [0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11], "thing": 6, "third": [0, 5], "this_dir_path": [], "thm17": 5, "thoma": 5, "thomson": 5, "thoroughli": [], "those": [5, 7, 11], "though": [4, 5], "thread": [], "three": [5, 7], "threshold": [0, 5], "thrive": 5, "through": [4, 5, 7, 9], "throughout": [3, 5], "throw": [2, 11], "thu": 5, "ti": 5, "ticket": [], "tidwel": 5, "tiger": 5, "tightli": 5, "tilt": 5, "time": [0, 1, 4, 5, 7, 8, 9, 10, 11], "timeslic": [0, 5, 8, 10], "timestamp": [0, 1, 2, 8], "timestep": 5, "timezon": [8, 9, 10], "tip": 5, "titl": [1, 11], "titleshorten": 6, "tm": 5, "tmsk18": 5, "tn": 5, "todo": 6, "togeth": 5, "toksoz": 5, "toml": 9, "ton": [5, 10], "tonn": 5, "too": [1, 9], "tool": [0, 1, 4, 5], "toolkit": 5, "top": [2, 5, 8], "tophr": [], "topic": [], "topographi": 5, "topologi": 5, "tot": 8, "total": [1, 5, 7, 8, 10], "totalcpu": [], "touch": [], "tow": 5, "toward": [5, 7, 10], "tower": 5, "townsend": 5, "tp": [5, 7], "tpwr": 5, "trace": 5, "track": [5, 7], "tractabl": 5, "trade": [3, 7, 10], "tradeoff": 5, "tradit": 5, "train": [4, 9], "trajectori": [3, 5], "tran_cap_2035": 10, "trancap_fut_cat": 10, "trancap_init": [], "trans_adder_per_mw": [], "trans_cap_cost": [], "trans_intra_cost_add": 10, "transact": 5, "transfer": 5, "transform": 5, "transgrp": [0, 5, 6, 10], "transgrp_10_eue_sum": 0, "transit": 5, "translat": [5, 7], "transmiss": [0, 4], "transmission_capacity_future_ba_baselin": 10, "transmission_capacity_future_ba_default": 10, "transmission_capacity_future_ba_lcc_al": 10, "transmission_capacity_future_ba_lcc_seamsd2b": 10, "transmission_capacity_future_ba_lcc_seamsd3_certain": 10, "transmission_capacity_future_ba_lcc_seamsd3_poss": 10, "transmission_capacity_future_ba_lcc_seamsd3_possible_unconstrain": 10, "transmission_capacity_future_ba_vsc_al": 10, "transmission_capacity_future_county_baselin": 10, "transmission_capacity_future_county_default": 10, "transmission_capacity_future_lcc_1000miles_demand1_wind1_subferc_20230629": 10, "transmission_capacity_init_ac_ba_naris2024": 10, "transmission_capacity_init_ac_ba_refs2009": 10, "transmission_capacity_init_ac_county_naris2024": 10, "transmission_capacity_init_ac_transgrp_naris2024": 10, "transmission_capacity_init_nonac_ba": 10, "transmission_capacity_init_nonac_counti": 10, "transmission_distance_cost_500kvac_ba": 10, "transmission_distance_cost_500kvac_counti": 10, "transmission_distance_cost_500kvdc_ba": 10, "transmission_distance_cost_500kvdc_counti": 10, "transmission_map": 6, "transport": 10, "transreg": [0, 10], "transreg_wkt": 10, "travers": 5, "travi": 5, "treat": [5, 7], "tree": 2, "trend": [5, 7], "tri": 1, "trick": [], "trieu": 5, "trigger": 5, "trip": 5, "trough": 5, "trtype": 10, "trtype_map": 10, "trtype_styl": 10, "true": [5, 8], "truncat": [], "truncate_leap": [], "trunk": 5, "truss": 5, "trust": 5, "try": [3, 9], "try_gam": 3, "tschofen": 5, "turbin": [5, 10], "turchi": 5, "turn": [0, 3, 5, 10], "turndown": 5, "tutori": 1, "tw": 5, "twb": 11, "twbx": 11, "twh": 5, "two": [0, 1, 5, 6, 7, 8, 9], "txt": [0, 6, 11], "tyler": 5, "type": [1, 3, 8, 9, 10, 11], "typic": [3, 5], "u": [0, 1, 3, 5, 7, 10], "ubernodalre": [], "uc": 5, "ucsusa": 5, "ug_saverestart": 0, "ultim": 5, "unabl": [2, 5], "unadjust": 5, "unapp_water_sea_distr": 10, "unappropri": 5, "unappwatermult": 10, "unappwatermultann": 10, "unappwaterseaanndistr": 10, "unassign": 5, "unavail": 5, "unbundl": [5, 10], "unbundled_limit_c": 10, "unbundled_limit_rp": 10, "uncalibr": [], "uncertainti": 5, "unclear": 5, "unconstrain": 5, "uncontrol": 5, "under": [1, 4, 5, 9, 10, 11], "underestim": 5, "underground": 5, "underli": 5, "underscor": [], "understand": 5, "underwat": 5, "undiscov": 5, "unexpect": 5, "unfamiliar": [], "unforeseen": 5, "uniform": 5, "uniformli": [5, 7], "uninstal": 9, "union": 5, "unionocscientists12": 5, "uniqu": [0, 4, 5, 8], "unit": [3, 5, 8, 10], "unitdata": 10, "unitless": [5, 10], "units": 10, "unitspec_upgrad": 10, "univers": 5, "unix": 4, "unknown": 5, "unless": [4, 5], "unlik": 5, "unlimit": 5, "unload": [], "unmet": 5, "unnecessari": [], "unplan": 5, "unpric": 5, "unrespons": 1, "unserv": 5, "unsubscrib": [], "unsuit": 5, "unsur": [], "until": [5, 9], "unus": 8, "unweight": 10, "unzip": 9, "up": [0, 1, 5, 7, 9, 11], "upcom": [], "updat": [1, 5, 9], "update_nam": [], "upfront": 5, "upgrade_costs_ccs_co": 10, "upgrade_costs_ccs_ga": 10, "upgrade_hintage_char": 10, "upgrade_link": 10, "upgrade_mult_atb23_ccs_adv": 10, "upgrade_mult_atb23_ccs_con": 10, "upgrade_mult_atb23_ccs_mid": 10, "upgradelink_wat": 10, "upload": 5, "upon": 5, "upper": 5, "uprat": 5, "upstream": 5, "upv": 10, "upv_140ac": 10, "upv_220ac": [3, 10], "upv_atb_2023_advanc": 10, "upv_atb_2023_conserv": 10, "upv_atb_2023_moder": 10, "upv_atb_2024_advanc": 10, "upv_atb_2024_conserv": 10, "upv_atb_2024_moder": 10, "upv_exog_cap_limited_ba": 10, "upv_exog_cap_limited_counti": 10, "upv_exog_cap_open_ba": 10, "upv_exog_cap_open_counti": 10, "upv_exog_cap_reference_ba": 10, "upv_exog_cap_reference_counti": 10, "upv_plant_char_format": 10, "upv_prescribed_builds_limited_ba": 10, "upv_prescribed_builds_limited_counti": 10, "upv_prescribed_builds_open_ba": 10, "upv_prescribed_builds_open_counti": 10, "upv_prescribed_builds_reference_ba": 10, "upv_prescribed_builds_reference_counti": 10, "upv_refer": 10, "upv_resource_class": 10, "upv_supply_curv": 10, "upv_supply_curve_raw": 10, "upv_typ": [], "upward": 3, "uranium": 5, "uranium_aeo_2022_refer": 10, "uranium_aeo_2023_refer": 10, "urban": [3, 5], "url": 1, "us": [0, 1, 3, 4, 6, 7, 8, 9, 10, 11], "us_can_mex_pca_polygon": 10, "us_onli": [], "us_transmission_endpoints_and_can_mex_centroid": 10, "usa": [], "usa_decarb": [], "usabl": 4, "usag": [5, 9, 10], "uscbureau22": 5, "usda": 5, "usda_wkt": 10, "use_default_before_yr": [], "useia": 5, "useia18": 5, "usenam": [], "user": [0, 1, 2, 3, 6, 8, 10], "user_guid": 1, "user_myname_20230130": 0, "usernam": [1, 7], "usg": 5, "usgs_categori": 10, "usgs_combined_categori": 10, "usual": [5, 7], "utc": 8, "util": [3, 5, 6, 7, 10], "utliz": 3, "v": [5, 6, 9, 10], "v20200806_retailtest_midcas": 7, "v20231112": 6, "v20231218_casegroupk0_usa_lim": 6, "v20231218_casegroupk0_usa_open": 6, "v20231218_casegroupk0_usa_ref": 6, "v20231218_casegroupk0_usa_transgrp": 6, "v20231221_usa": 6, "v20231221_usa_ref": 6, "v2024": [3, 5], "va": 5, "vagu": 5, "vahan": 5, "valcap": [], "valid": [4, 5, 9], "valu": [1, 3, 4, 6, 7, 8, 9, 10, 11], "valuabl": 5, "valuat": 5, "var": 10, "var_map": 10, "vari": [5, 9, 10], "variabl": [0, 1, 4, 7, 8, 9], "variou": [5, 8, 9, 10], "vast": 5, "vbaillorr05": 5, "ve": [9, 11], "vea12": 5, "veatch": 5, "vehicl": 5, "veloc": [5, 7], "ven14": 5, "venkat": 5, "venkatesh": 5, "ventosa": 5, "ventyx": 5, "venugop": 5, "verbos": 6, "veri": [1, 5], "verif": 9, "verifi": [5, 9], "vermont": 5, "versa": 5, "version": [4, 7, 8, 9, 11], "version1": 5, "versu": 5, "vertic": 5, "vf": 8, "vf_interact": 8, "vf_spatial": 8, "vf_tempor": 8, "via": [0, 3, 5, 11], "viabil": 5, "vice": 5, "video": [4, 6, 9], "view": [1, 5, 6], "viewabl": [], "viewer": [], "vignesh": 5, "vikram": 5, "vim": [], "vimmerstedt": 5, "vinayak": 5, "vinc": 5, "vincent": 5, "vintag": [3, 5], "violat": [], "vipin": 5, "virginia": 5, "virtual": [], "vision": 5, "visit": [], "visual": [5, 8, 10, 11], "visualstudio": [], "vm": [], "vogtl": 5, "vol": 5, "voltag": 7, "volum": [5, 6], "voluntari": 5, "vom": [5, 7, 10], "vomcost_": 5, "vre": [5, 10], "vsc": [5, 10], "vsc_all_cas": 10, "vscode": 1, "vvvvv": 6, "vyyyymmdd": [], "w": [0, 5, 10], "w9127n": 5, "w_": 5, "wa": [5, 7, 9], "wacc": 5, "wacc_": 5, "wage": 5, "wai": [1, 5, 11], "wait": [], "walk": [], "walltim": [], "walter": 5, "want": [0, 1, 3, 5, 9, 11], "ward": 0, "warm": 5, "warmer": 5, "warn": [3, 9], "warrant": [5, 7], "washington": 5, "wastewat": 5, "wat_access_cap_cost": 10, "watch": [], "water": [3, 10], "water_req_psh_10h_1_51": 10, "water_with_cons_r": 10, "watson": 5, "wb19": 5, "wc": [], "we": [0, 3, 5, 7, 10, 11], "weather": [0, 5], "web": [], "websit": [5, 10], "wec13": 5, "wec15": 5, "wecc": 5, "week": 5, "weekli": 5, "wei": 5, "weigh": 5, "weight": [0, 1, 3, 10], "wek": 0, "welcom": [], "well": [1, 5, 8, 10], "welsh": 5, "went": [], "were": [3, 5, 9], "weslei": [5, 7], "west": [3, 5], "west_south_centr": 3, "western": [3, 5], "western_ba_decarb": [], "wetland": 5, "what": [0, 5, 10], "whatev": [], "wheel": 5, "when": [0, 1, 2, 3, 5, 7, 8, 9, 10], "whenev": 5, "where": [3, 5, 6, 7, 8, 10, 11], "wherea": 5, "wherebi": 5, "wherev": 11, "whether": [0, 3, 5, 8], "which": [0, 1, 2, 3, 4, 5, 7, 9, 10, 11], "whichev": [5, 11], "while": [1, 5, 7, 8], "white": 5, "who": 5, "whole": 0, "wholesal": 5, "whose": [5, 7], "why": [], "wide": 5, "width": 1, "wild": 5, "wilder": 5, "wildlif": 5, "william": 5, "win64": 9, "wind": [0, 3, 7, 8, 10], "wind_atb_2023_advanc": 10, "wind_atb_2023_conserv": 10, "wind_atb_2023_moder": 10, "wind_atb_2023_moderate_noflo": 10, "wind_atb_2024_advanc": 10, "wind_atb_2024_conserv": 10, "wind_atb_2024_moder": 10, "wind_atb_2024_moderate_noflo": 10, "wind_plant_char_format": 10, "wind_rsc_mult_plant_char_format": 10, "window": [3, 5, 10], "windows_2100": 10, "windows_default": 10, "windows_step10": 10, "windows_step5": 10, "winget": 9, "winscp": [], "winter": 5, "wintertim": 5, "wiser": 5, "wish": 9, "withdraw": 10, "withdrawn": 5, "within": [0, 2, 3, 5, 7, 9, 10, 11], "without": [0, 2, 5, 9], "wkt": 11, "woerman": 5, "won": 0, "wood": 5, "woodi": 5, "word": 5, "work": [0, 1, 4, 5, 6, 7, 8, 9], "workaround": [], "workbook": [], "workfil": 0, "workflow": 11, "worksheet": 11, "workshop": 5, "workspac": [], "workstat": 3, "world": 5, "worth": 5, "would": [0, 3, 5, 7, 8, 9, 11], "wouldn": 3, "wrapper": [], "wright": 5, "write": [], "written": [4, 5, 7, 11], "wrm08": 5, "wrong": [], "wst": 10, "wst_climat": 10, "wst_map": 10, "wst_style": 10, "www": [0, 3, 5, 7, 9, 10], "x": [1, 5], "x86_64": 9, "x_": 5, "xcel": 5, "xie": 5, "xlsx": 10, "xx": [], "xx_homework": [], "y": [0, 1, 5, 6], "y2012d003h004": 0, "y2012w001h052": 0, "y_": 5, "yampa": [], "yankai": 5, "yax": 5, "ye": 3, "year": [0, 1, 3, 6, 7, 8, 9, 10], "yearaft": 10, "yearli": [5, 7], "years_until_endogen": 10, "yearset_suffix": 3, "yeasmin": 5, "yet": [], "yield": 5, "yinong": 5, "yixian": 5, "yml": 9, "york": 5, "you": [0, 1, 2, 3, 4, 6, 8, 9, 10, 11], "your": [0, 1, 2, 3, 9, 11], "your_alloc": [], "your_email": [], "your_project": [], "your_project_id": [], "youremail": [], "yournam": [], "yourself": 1, "youtu": [1, 4, 9], "youtub": [4, 6, 9], "yr": 5, "yu": 5, "yuan": 5, "yve": 5, "yyymmdd": 9, "z": 5, "zero": [5, 9], "zhang": 5, "zhou": 5, "zinaman": 5, "zip": 9, "zone": 3, "zoom": 1, "zotero": [], "zuboi": 5, "zuckerman": 5, "zwerl": 5, "\u00bd": 5, "\u00e1": 5, "\u00e9": 5, "\u00ea": 5, "\u0131": 5, "\u03b1": 5, "\u03b2": 5, "\u03b2i": 5, "\u03b4": 5}, "titles": ["Model Switches", "Exploding Pivot Charts", "How to Use Sources Documentation", "FAQ", "Welcome to ReEDS\u2019s documentation!", "Model Documentation", "Post-Processing and Analysis Tools", "Retail rate module", "reValue", "Getting Started", "Sources and Data", "ReEDS-to-Tableau Postprocessing"], "titleterms": {"": 4, "0": [4, 10], "1": [], "10": 9, "2": [4, 5, 10], "2020": 5, "2022": 5, "2050": 5, "3": [], "4": 5, "9": 5, "In": 5, "abbrevi": 5, "ac": 5, "access": [], "account": 7, "acknowledg": 5, "acronym": 5, "activ": [], "actual": 5, "ad": 11, "add": [], "adder": 5, "addit": [1, 5], "adequaci": 5, "adjust": [5, 11], "administr": 7, "aeo": 5, "after": [], "agent": [], "air": 5, "air_qual": 10, "alloc": [], "amount": 5, "an": 3, "analysi": [4, 6, 11], "annual": 5, "appendix": 5, "appli": 5, "applic": [], "approach": 7, "approxim": 5, "ar": [3, 5], "area": 0, "assumpt": [3, 5], "atb_updates_process": 10, "avail": 5, "averag": 5, "aw": [], "b": 5, "ba": [], "balanc": 5, "base": 5, "batteri": 5, "becc": 5, "befor": [], "below": 5, "benefit": 5, "best": [], "bin": 5, "biopow": 5, "bokeh": 1, "bokehpivot": [1, 6, 10], "build": 5, "calc_historical_capex": 10, "calcul": 5, "california": 5, "call": [9, 11], "cambium": 5, "can": 3, "canada_import": 10, "cap": 5, "capabl": [3, 5], "capac": 5, "capacity_exogen": 10, "capit": [5, 7], "captur": 5, "carbon": 5, "case": [0, 3, 9], "caveat": [3, 5, 7], "challeng": 5, "chang": 5, "characterist": 5, "chart": 1, "check": 0, "citat": [], "class": 5, "clean": 5, "climat": [5, 10], "cloud": [], "cm5a": 10, "co2": 5, "code": [], "combin": 5, "command": [], "comparison": 6, "competit": 5, "compon": 7, "compound": 5, "comput": [3, 9], "concentr": 5, "conda": [], "config": [], "configur": [3, 9], "conflict": [], "connect": 5, "constraint": 5, "consum": 10, "consumpt": 5, "contact": 4, "content": [3, 10], "control": [], "convent": [0, 5], "cool": 5, "copi": [], "core": [1, 3], "cost": [5, 7], "counti": 5, "creat": 1, "credit": [5, 7], "cross": 5, "csp": 5, "csv": [2, 9], "ctu": 10, "cumul": 5, "current": [3, 5], "curv": 5, "damag": 5, "data": [1, 3, 5, 10], "dataset": 5, "dc": 5, "debug": [], "decarbon": [], "deck": [], "default": [], "definit": 5, "degrad": 10, "demand_respons": 10, "deploy": 4, "descript": 5, "desktop": [], "detail": [], "develop": [], "dgen": 5, "dgen_model_input": 10, "differ": 5, "direct": 5, "directori": [], "disaggreg": 10, "distribut": 7, "document": [2, 4, 5], "dollar": 11, "don": 3, "downscal": 5, "drive": [], "drop": 5, "dupv": 5, "dure": 9, "each": 5, "eagl": [], "econom": 5, "eer": 5, "electr": 5, "electrif": 5, "emiss": 5, "emission_constraint": 10, "end": 5, "endogen": 5, "energi": [4, 5], "enforc": [], "enhanc": 5, "environ": [], "ercot": [], "error": 0, "es_rcp2p6": 10, "es_rcp45_at": 10, "es_rcp4p5": 10, "es_rcp85_at": 10, "es_rcp8p5": 10, "esm2m_rcp4p5_wm": 10, "evolv": 5, "exampl": [5, 11], "execut": 9, "exist": 5, "expenditur": 7, "expens": 7, "explod": 1, "extens": [], "factor": 5, "fail": 0, "faq": 3, "feder": 5, "fee": 3, "field": 2, "file": [5, 9, 10], "financ": 5, "financi": [5, 10], "first": [], "fleet": 5, "flexibl": 5, "flow": 7, "folder": [], "formul": 5, "fraction": 5, "framework": 5, "from": 5, "fuel": 5, "fuelpric": 10, "full": 5, "function": 1, "futur": 5, "ga": 5, "gal": 5, "gam": [3, 9], "gener": [5, 7], "geospati": 11, "geotherm": [5, 10], "get": 9, "gfdl": 10, "git": [], "gitahead": [], "github": [], "gov": 4, "greenhous": 5, "grid": 5, "group": 5, "growth": 5, "growth_constraint": 10, "guid": [], "guidelin": [], "gw": 5, "hadgem2": 10, "handl": 5, "hardwar": 3, "health": 5, "heat": 5, "help": [], "helper": 6, "high": 5, "histor": 5, "histori": 5, "hourli": [], "hourliz": 10, "hourly_process": 0, "how": [2, 3], "hpc": [], "http": 4, "hvdc": 5, "hydro": 10, "hydrogen": 5, "hydrokinet": 5, "hydropow": 5, "i": 3, "impact": 5, "incent": 5, "incom": 7, "increas": 5, "incur": 5, "inform": [], "initi": 5, "input": [3, 5, 9, 10], "input_fil": 10, "instal": 1, "instanc": [], "instruct": 8, "interconnect": [3, 5], "intern": 5, "interregion": 7, "interzon": 5, "intra": 5, "intro": 1, "introduct": [4, 5], "ipsl": 10, "isol": 3, "issu": [3, 9], "item": [], "jedi": 5, "json": [], "julia": 9, "kei": [0, 5], "known": 3, "land": 5, "land_us": 10, "launch": [], "launcher": [], "learn": [], "level": 5, "licens": 3, "lifetim": 5, "light": [], "limit": 3, "line": 5, "link": [], "linkag": [5, 6], "list": 5, "load": [1, 5, 10], "local": 5, "locat": [], "logic": [], "lr_rcp8p5_wm": 10, "mac": [], "machin": [], "maco": [1, 9], "macrogrid": 5, "made": 3, "mainten": 5, "major": 5, "manag": 6, "mandat": 5, "map": 11, "margin": 5, "marin": 5, "mercuri": 5, "merg": [], "method": 5, "metric": 5, "microsoft": 9, "minimum": 5, "mmbtu": 5, "model": [0, 1, 4, 5, 9], "modul": [6, 7], "much": 3, "multi_year": 10, "multipl": 5, "multipli": 5, "mw": 5, "mwh": 5, "name": 10, "nation": 5, "national_gener": 10, "natur": 5, "necessari": 3, "net": 5, "network": 5, "never": 5, "new": [5, 11], "notabl": 5, "note": [], "nrel": 4, "nrelnas01": [], "nuclear": 5, "observ": 5, "offshor": 5, "often": 3, "onboard": [], "oper": [5, 7], "optim": 3, "option": 5, "other": 5, "outdat": [], "output": [3, 7, 11], "overview": 5, "pacif": [], "paramet": 5, "partit": [], "path": [], "penalti": 5, "per": 5, "percentag": 5, "perform": 5, "period": [5, 9], "photovolta": 5, "pivot": 1, "plan": 5, "plant": 5, "plant_characterist": 10, "plexo": [5, 11], "plexos_to_re": 10, "plot": 10, "polici": 5, "pollut": 5, "popul": 5, "portfolio": 5, "post": 6, "postprocess": [10, 11], "potenti": 5, "pound": 5, "power": 5, "pr": [], "practic": [], "preprocess": [6, 10], "prerequisit": [], "prescrib": 5, "present": 5, "previou": [], "price": 5, "process": [3, 6], "product": 5, "profil": 5, "program": [], "prompt": 9, "pull": [], "push": [], "py": [0, 9], "python": 9, "quick": [], "quickstart": [], "r2r_expand": 10, "r2r_from_config": 10, "r2r_integr": 10, "rate": [5, 7], "rcm_data": 10, "re": 0, "reduc": 3, "reed": [0, 3, 4, 5, 6, 9, 10, 11], "reeds2": 10, "reeds2pra": [9, 10], "reeds_augur": 10, "reeds_cas": 10, "refer": 5, "regardless": 5, "region": [4, 5], "regul": 5, "regular": [], "reinforc": 5, "relationship": 5, "releas": [], "relev": 2, "reliabl": 5, "remot": [], "renew": 5, "report": [1, 5], "repositori": 9, "request": [], "requir": [4, 5, 9], "research": 5, "reserv": [5, 10], "resolut": 5, "resolv": [], "resourc": [1, 5, 10], "restart": [], "restrict": 5, "result": [], "retail": 7, "retail_rate_modul": [6, 10], "retir": 5, "return": 7, "rev": 5, "rev_path": [], "revalu": [6, 8, 10], "review": [], "round": [], "rout": 5, "rowth": 5, "rule": 5, "run": [0, 1, 3, 6, 9], "run_hourl": [], "runbatch": 9, "sale": 5, "scale": 5, "scenario": 5, "script": 6, "season": 5, "section": [], "sector": 5, "servic": 5, "set": 10, "setup": 9, "shape": 5, "shapefil": 10, "share": [], "shortcut": [], "size": 5, "slide": [], "sm": 5, "so": 3, "softwar": 4, "solar": 5, "solv": 3, "sort": [], "sourc": [2, 5, 10], "spatial": 5, "special": 9, "specif": [], "spur": 5, "spyder": [], "ssh": [], "standard": 5, "standbi": [], "start": [5, 9], "state": 5, "state_polici": 10, "still": [], "stock": 5, "storag": [5, 10], "stress": [5, 9], "structur": 5, "stscen2023_electrif": 10, "stscen2023_highng": 10, "stscen2023_highr": 10, "stscen2023_lowng": 10, "stscen2023_lowr": 10, "stscen2023_mid_cas": 10, "stscen2023_mid_case_95_by_2035": 10, "stscen2023_mid_case_95_by_2050": 10, "stscen2023_taxcredit_extended2050": 10, "studi": 5, "studio": [], "substat": 5, "summari": 5, "sup": 5, "suppli": 5, "supply_curv": 10, "switch": 0, "synchron": [], "system": [4, 5], "t": 3, "tabl": [3, 10], "tableau": [6, 10, 11], "tag": [], "task": [], "tax": [5, 7], "tech": 10, "technic": 5, "technologi": 5, "templat": [1, 11], "tempor": 5, "test": [3, 10], "thi": 5, "time": 3, "tip": 1, "tool": 6, "toxic": 5, "trade": 5, "train": [], "transfer": [], "transmiss": [5, 7, 10], "transport": 5, "treatment": 5, "trial": 3, "troubleshoot": [0, 1, 9, 11], "type": 5, "u": 4, "understand": 9, "undifferenti": 5, "up": [], "updat": [2, 3], "upgrad": [5, 10], "upv": 5, "us": [2, 5], "usa_vsc_2035": 10, "usag": 7, "user": [5, 9], "userinput": 10, "v": [], "valu": 5, "valuestream": 10, "variabl": [5, 10], "variat": 5, "varieti": 5, "version": [3, 5], "video": [], "visual": 6, "voltag": 5, "vscode": [], "wai": 3, "water": 5, "waterclim": 10, "wave": 5, "weight": 5, "welcom": 4, "western": [], "what": 3, "widget": 1, "wind": 5, "window": [1, 9], "withdraw": 5, "wkt_csv": 10, "work": 3, "www": 4, "yampa": [], "year": [5, 11], "your": [], "zonal": 5, "zone": 5}}) \ No newline at end of file diff --git a/docs/build/html/setup.html b/docs/build/html/setup.html deleted file mode 100644 index 777175b2..00000000 --- a/docs/build/html/setup.html +++ /dev/null @@ -1,456 +0,0 @@ - - - - - - - Getting Started — ReEDS documentation - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Getting Started

-

The ReEDS model source code is available at no cost from the National Renewable Energy Laboratory. The ReEDS model can be downloaded or cloned from https://github.com/NREL/ReEDS-2.0.

-

New users may also wish to start with some ReEDS training videos which are available on the NREL YouTube channel at https://youtu.be/aGj3Jnspk9M?si=iqCRNn5MbGZc8ZIO.

-
-

Computer Setup for Microsoft Windows 10

-

The setup and execustion of the ReEDS model can be accomplished using a command-line interpreter application and launching a command line interface (referred to as a “terminal window” in this documentation). For example, initiating the Windows Command Prompt application, i.e., cmd.exe, will launch a terminal window Fig. 1. (Note: If you have issues using command prompt, try using anaconda prompt or a git bash window)

-
-_images/cmd-prompt.png -
-

Fig. 1 Screenshot of a Windows Command Prompt terminal window

-
-
-

SUGGESTON: use a command line emulator such as ConEmu (https://conemu.github.io/) for a more user-friendly terminal. The screenshots of terminal windows shown in this document are taken using ConEmu.

-

IMPORTANT: Users should exercise Administrative Privileges when installing software. For example, right click on the installer executable for one of the required software (e.g., Anaconda3-2019.07-Windows-x86_64.exe) and click on “Run as administrator” (Fig. 2). Alternatively, right click on the executable for the command line interface (e.g., Command Prompt) and click on “Run as administrator” (Fig. 3). Then run the required software installer executables from the command line.

-
-_images/run-as-admin.png -
-

Fig. 2 Screenshot of running an installer executable using “Run as administrator”

-
-
-
-_images/run-as-admin-2.png -
-

Fig. 3 Screenshot of running “Command Prompt” with “Run as administrator”

-
-
-
-

Python Configuration

-

Install Anaconda: https://www.anaconda.com/download.

-

IMPORTANT : Be sure to download the Windows version of the installer.

-

Add Python to the “path” environment variable

-
    -

  1. In the Windows start menu, search for “environment variables” and click “Edit the system environment variables” (Fig. 4). This will open the “System Properties” window (Fig. 5).

    2. -
-
-_images/search-env-var.png -
-

Fig. 4 Screenshot of a search for “environment variables” in the Windows start menu

-
-
-
-_images/sys-prop-win.png -
-

Fig. 5 Screenshot of the “System Properties” window.

-
-
-
    -

  1. Click the “Environment Variables” button on the bottom right of the window (Fig. 5). This will open the “Environment Variables” window (Fig. 6).

    2. -
-
-_images/env-var-win.png -
-

Fig. 6 Edit the Path environment variable

-
-
-
    -

  1. Highlight the Path variable and click “Edit” (Fig. 6). This will open the “Edit environment variable” window (Fig. 7).

    2. -
-
-_images/edit-env-var-win.png -
-

Fig. 7 Append the Path environment

-
-
-
    -

  1. Click “New” (Fig. 7) and add the directory locations for \Anaconda\ and \Anaconda\Scripts to the environment path.

    2. -
-

IMPORTANT : Test the Python installation from the command line by typing “python” (no quotes) in the terminal window. The Python program should initiate (Fig. 8).

-
-_images/py-test.png -
-

Fig. 8 Screenshot of a test of Python in the terminal window

-
-
-

It is highly recommended to run ReEDS using the conda environment provided in the repository. This environment (named reeds2) is specified by the environment.yml and can be built with the following command:

-
conda env create -f environment.yml
-
-
-

You can verify that the environment was successfully created using the following (you should see reeds2 in the list):

-
conda env list
-
-
-

When creating the reeds2 environment locally, you might run into an SSL error that looks like: CondaSSLError: Encountered an SSL error. Most likely a certificate verification issue. To resolve this issue, run the following command before creating the environment again: conda config --set ssl_verify false.

-
-
-

GAMS Configuration

-

Install GAMS: https://www.gams.com/download/. NREL uses GAMS versions 45.2.0 and 34.3. Older versions might also work. A valid GAMS license must be installed. Please refer to the Required Software section above for more information.

-

Add GAMS to the “path” environment variable. Follow the same instructions as for adding Python to the path in the Python Configuration section above. Append the environment path with the directory location for the gams.exe application (e.g., C:\GAMS\win64\34).

-

IMPORTANT : Test the GAMS installation from the command line by typing “gams” (no quotes) in the terminal window. The GAMS program should initiate (Fig. 9).

-
-_images/gams-test.png -
-

Fig. 9 Screenshot of a test of GAMS from the terminal window

-
-
-
-
-

ReEDS Repository Setup

-

The ReEDS source code is hosted on GitHub: https://github.com/NREL/ReEDS-2.0

-
    -

  1. Install Git Large File Storage, instructions can be found here: Installing Git Large File Storage

    2. -

  2. From the Git command line run the following command to enable large file storage.

    3. -
-
git lfs install
-
-
-
    -

  1. Clone the ReEDS-2.0 repository on your desktop. Alternatively, download a ZIP from GitHub (Fig. 10).

    2. -
-
-_images/github-download.png -
-

Fig. 10 Screenshot of GitHub links to clone the ReEDS repository or download ZIP of the ReEDS files

-
-
-
-
-
-

Computer Setup for MacOS

-
-

Python Configuration

-

Download the latest Intel version of Anaconda: https://www.anaconda.com/download

-

IMPORTANT: Make sure to download the Intel version even if your machine has an Apple Silicon / ARM processor.

-
-_images/anaconda-intel.png -
-

During Installation, select to install Anaconda for your machine only.

-
-_images/anaconda-install-mac.png -
-

Fig. 11 Image of Anaconda Install Mac

-
-
-

To have the installer automatically add anaconda to PATH, ensure that you’ve selected the box to “Add conda initialization to the shell”

-
-_images/anaconda-custom-install-mac.png -
-

Fig. 12 Image of Anaconda Install Mac - Customize Installation Type

-
-
-

To validate Python was installed properly execute the following command from a new terminal (without quotes): “python”

-

Python should initiate, looking similar to Fig. 8.

-

It is highly recommended to run ReEDS using the conda environment provided in the repository. This environment (named reeds2) is specified by the environment.yml and can be built with the following command - make sure you navigate to the ReEDS repository from terminal first:

-
conda env create -f environment.yml
-
-
-

You can verify that the environment was successfully created using the following (you should see reeds2 in the list):

-
conda env list
-
-
-
-
-

GAMS Configuration

-

Install GAMS: https://www.gams.com/download/. A valid GAMS license must be installed. Please refer to the Required Software section above for more information.

-

IMPORTANT: When installing on Mac, on the ‘Installlation Type’ page, click ‘customize’ and ensure the box to ‘Add GAMS to PATH’ is checked.

-
-_images/gams-install-mac.png -
-

Fig. 13 Image of GAMS Install Mac

-
-
-

To validate GAMS was installed properly execute the following command from a new terminal (without quotes): “gams”

-

GAMS should initiate, you should see something similar to Fig. 9.

-
-
-

ReEDS Repository Setup

-

The ReEDS source code is hosted on GitHub: https://github.com/NREL/ReEDS-2.0

-
    -

  1. Install Git Large File Storage, instructions can be found here: Installing Git Large File Storage

    2. -

  2. From the Git command line run the following command to enable large file storage.

    3. -
-
git lfs install
-
-
-
    -

  1. Clone the ReEDS-2.0 repository on your desktop and use the repository with GitHub Desktop. Alternatively, download a ZIP from GitHub (Fig. 10).

    2. -
-
-
-
-

ReEDS2PRAS, julia, and stress periods setup

-

Since ReEDS uses stress periods by default, julia will need to be installed and set up to run the model. To get julia and stress periods set up:

-
    -

  1. Install Julia. There are different procedures for mac/linux and windows.

    -
      -

    1. [mac/linux]: Julia is included in the conda environment so you should be all set.

      2. -

    2. [windows]: Install Julia from https://julialang.org/downloads/.

      3. -
    -
    2. -

  2. From the ReEDS-2.0 directory, run julia --project=. instantiate.jl

    3. -
-

Set GSw_PRM_CapCredit=0 in your ReEDS cases file to use the coupled ReEDS/PRAS stress periods model, or just set pras=2 to run PRAS without necessarily using stress periods.

-
-

Troubleshooting Issues with Julia Setup

-

When setting up julia on Windows, you may run into some issues when running julia --project=. instantiate.jl. The following steps can be followed to help resolve issues and get julia set up sucessfully:

-
    -

  1. Manually install Random123

    2. -

  2. Re-run julia --project=. instantiate.jl

    3. -
-

If that doesn’t resolve the issue, the following may help:

-
    -

  1. If you previously installed julia, uninstall it: winget uninstall julia

    2. -

  2. Manually install Julia 1.8.5

    3. -

  3. Add the julia bin path to your environment PATH variable

    4. -

  4. Install MinGW

    5. -

  5. Open the julia interactive command line: julia

    6. -

  6. Enter the julia package manager by pressing ], then run the following commands:

    -
      -

    • add Random123

      • -

    • registry add https://github.com/JuliaRegistries/General.git

      • -

    • registry add https://github.com/NREL/JuliaRegistires.git

      • -

    • instantiate

      • -
    -
    7. -

  7. Leave the package manager by pressing backspace or Ctrl+C

    8. -

  8. Run the following commands to finish setup:

    -
      -

    • import PRAS

      • -

    • import TimeZones

      • -

    • TimeZones.build()

      • -
    -
    9. -

  9. You can then leave the julia command line by typing exit()

    10. -
-

If you’re experiencing issues on Mac, a possible solution is:

-
    -

  1. Update the version of julia

    2. -

  2. Create the ‘reeds2’ conda environment with the environment.yml file

    3. -

  3. Run julia from the terminal to open the interactive command line

    4. -

  4. Run import Pkg; Pkg.add("PRAS")

    5. -

  5. Run Pkg.add("TimeZones")

    6. -

  6. Exit julia with the command exit(), then run julia instantiate.jl

    7. -

  7. Manually move the Manifest.toml file from the julia environment (~/miniconda3/envs/reeds2/share/julia/environments/reeds2/Manifest.toml) to the ReEDS repo

    8. -
-
-
-
-

Executing the Model

-

A ReEDS case (also referred to as a “run”, “scenario” or “instance”) is executed through a python-based case batching program called runbatch.py after the repository was setup. The user can execute a single case or a batch of cases using this program.

-
-

Understanding the cases.csv file

-

ReEDS model switches are set in the cases.csv file and need to be specified by the user. The default case configuration file is called “cases.csv”.

-

Within “cases.csv”, the data in column A are the model “switches”. Column B contains a brief description of each switch. Column C contains the choices available for the given switch (please note, this is not available for all switches). Column D contains the default value for the switch. Finally, the case configuration (or set of switches that define a case) is in column E.

-

Within column E, the case name is specified in row 1. The value for each switch is specified beginning in row 2. If a switch value is left blank, the default value from column D is used.

-

Note: all monetary switches should be entered in 2004 dollars.

-
-_images/cases-csv.png -
-

Fig. 14 Screenshot of cases.csv

-
-
-

There are additional cases_*.csv files that can also be used to run different ReEDS scenarios. The two most commonly used are:

-
    -

  • cases_standardscenarios.csv: contains all the scenarios that were used for Standard Scenarios

    • -

  • cases_test.csv: contains a group of “test” cases that vary specific settings within the model for testing various capabilities

    • -
-

The user may also create custom case configuration files by using the suffix in the file name (e.g., “cases_smalltests.csv”). It should follow the same column formatting as cases.csv, but does not need to include all available switches.

-
-
-

Calling runbatch.py to run ReEDS

-
    -

  1. Navigate to the ReEDS directory from a new command prompt or terminal.

    2. -

  2. Activate the reeds2 conda environment: conda activate reeds2

    3. -

  3. Call runbatch.py: python runbatch.py

    -
      -

    • It should look similar to Fig. 15

      • -
    -
    4. -

  4. Provide responses to the suite of prompts in the command line. For more information about the prompts, see the Prompts for user input during runbatch.py section.

    5. -

  5. Once all responses have been received, the batching program will execute the case(s) specified in the case configuration file (e.g., “cases.csv”).

    -
      -

    • Please note, if you’re running ReEDS on Windows, a separate terminal window will be launched for each case.

      • -
    -
    6. -
-

For each case that is run, a new subfolder will be created under the “runs/” subdirectory of ReEDS. If you run the default case found in “cases.csv”, you can expect to find the outputs from the run at “/ReEDS-2.0/runs/{batch prefix}_Ref/outputs”.

-
-_images/exe-runbatch.png -
-

Fig. 15 Screenshot of initiating “runbatch.py” from the command line

-
-
-
-
-

Prompts for user input during runbatch.py

-

Batch Prefix [string] - Defines the prefix for files and directories that will be created for the batch of cases to be executed (as listed in a case configuration file, e.g., “cases.csv”)

-
    -

  • All files and directories related to a case will be named “{batch prefix}_{case}”. For example, if batch prefix = “test” and case = “Ref”, then all files and directories related to this case will be named test_Ref.

    • -

  • Important: A batch prefix cannot start with a number given incompatibility with GAMS.

    • -

  • Entering the value of “0” (zero, no quotes) will assign the current date and time for the batch prefix in the form of v{YYYMMDD}_{HHMM}.

    • -

  • If you re-use a (batch prefix, case) pair, a new prompt will appear asking if you want to overwrite the existing output directories.

    • -
-

Case Suffix [string] - Indicates which case configuration file (in the form “cases_{case suffix}.csv”) is ingested into “runbatch.py” for processing.

-
    -

  • Entering an empty value(i.e., pressing “Enter/Return”) will cause the default case configuration file “cases.csv” to be used

    • -
-

Number of Simultaneous Runs [integer] - Indicated how many cases should be run simultaneously.

-
    -

  • “runbatch.py” uses a queue to execute multiple cases

    • -

  • If there are 4 cases and the Number of Simultaneous Runs = 1, then “runbatch.py” will execute the cases one at a time

    • -

  • However, if there are 4 cases and the Number of Simultaneous Runs = 2, then “runbatch.py” will start 2 cases simultaneously

    -
      -

    • As each case finishes, it will start a new one until all cases have been run

      • -
    -
    • -

  • WARNING! Be mindful about the amount of CPU and RAM usage needed for each case

    • -
-
-
-

Special Case Setup Requirements

-

For non-NREL users, some additional data is required to run the ReEDS model at the ‘county’ spatial resolution. This is currently considered a special case and some data was required to be kept outside the ReEDS repository because the data is simply too large. The hourly renewable capacity factor data is now available to all at : https://data.openei.org/submissions/5986.

-

If you would like to run the model at county resolution, you are requested to download the files available from the link provided, unzip each folder, and place the files obtained into inputs/variability/multi-year in your locally cloned ReEDS repository. The input_processing scripts have also been updated to check for these files for any county-level runs. The ‘cases_spatialflex.csv’ file provides examples of specific switch settings to run ReEDS at county-level.

-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/sources.html b/docs/build/html/sources.html deleted file mode 100644 index c437335d..00000000 --- a/docs/build/html/sources.html +++ /dev/null @@ -1,5705 +0,0 @@ - - - - - - - Sources and Data — ReEDS documentation - - - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- -
-

Sources and Data

-
-

ReEDS 2.0

-
-

Table of Contents

- -
-
-

Input Files

-

Note: If you see a ‘#’ before a header it means there may be further subdirectories within it but the Markdown file is only capable of showing 6 levels, so the header sizes are capped to that level and they cannot be any smaller to visually reflect the further subdirectory hierarchy.

-
-
-

-
    -

  • cases.csv

    -
      -

    • File Type: Switches file

      • -

    • Description: Contains the configuration settings for the ReEDS run(s).

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://github.nrel.gov/ReEDS/ReEDS-2.0/blob/38e6610a8c6a92291804598c95c11b707bf187b9/cases.csv)]

      • -
    -
    • -
-
- -
-
    -

  • cases_hourly.csv

    -
      -

    • Description: This cases file contains the settings to demonstrate temporal flexibility (hourly) of ReEDS.

      • -
    -
    • -
-
-
    -

  • cases_small.csv

    -
      -

    • Description: Contains settings to run ReEDS at a smaller scale to test operability of the ReEDS model. Turns off several technologies and reduces the model size to significantly improve solve times.

      • -
    -
    • -
-
-
    -

  • cases_smaller.csv

    -
      -

    • Description: Another cases file which reduces the size of the model by reducing some constraints and operates at the largest spatial hierarchy to favor faster runtimes.

      • -
    -
    • -
-
-
    -

  • cases_spatialflex.csv

    -
      -

    • Description: Contains sample scenarios that use the spatial flexibility capabilities

      • -
    -
    • -
-
-
    -

  • cases_standardscenarios.csv

    -
      -

    • File Type: StdScen Cases file

      • -

    • Description: Contains the configuration settings for the Standard Scenarios ReEDS runs.

      • -
    -
    • -
-
-
    -

  • cases_test.csv

    -
      -

    • Description: Contains the configuration settings for doing test runs including the default Pacific census division test case.

      • -
    -
    • -
-
-
    -

  • e_report_params.csv

    -
      -

    • Description: Contains a parameter list used in the model along with descriptions of what they are and units used.

      • -
    -
    • -
-
-
    -

  • runfiles.csv

    -
      -

    • Description: Contains the locations of input data that is copied from the repository into the runs folder for each respective case.

      • -
    -
    • -
-
-
    -

  • sources.csv

    -
      -

    • Description: CSV file containing a list of all input files (csv, h5, csv.gz)

      • -
    -
    • -
-
-
-

hourlize

-
-
inputs
-
-
load
-
    -

  • ba_timezone.csv

    -
      -

    • Description: Contains timezone information for BAs with respect to GMT.

      • -

    • Indices: r

      • -
    -
    • -
-
-
    -

  • EIA_2010loadbystate.csv

    -
      -

    • Description: Contains 2010 EIA load information (GWh) with respect to each state in the US.

      • -

    • Indices: r

      • -
    -
    • -
-
-
    -

  • EIA_loadbystate.csv

    -
      -

    • Description: Contains historical (2010-2022) EIA load information (GWh) with respect to each state in the US.

      • -

    • Indices: t,r

      • -
    -
    • -
-
- -
-
-
-
resource
-
    -

  • fair_market_value.csv

    -
      -

    • Description: Contains estimates of fair market land value in $ per hectare for each reV supply curve site

      • -

    • Citation: [(Provided by Anthony Lopez in June 2023)]

      • -
    -
    • -
-
- -
-
    -

  • state_abbrev.csv

    -
      -

    • Description: Contains state names and codesfor the US.

      • -
    -
    • -
-
-
    -

  • upv_resource_classes.csv

    -
      -

    • Description: Contains information related to UPV class segregation based on mean irradiance levels.

      • -
    -
    • -
-
-
    -

  • wind-ofs_resource_classes.csv

    -
      -

    • File Type: supply curve input

      • -

    • Description: Contains information related to Offshore wind class segregation and turbine type (fixed vs floating) based on water depth and site lcoe

      • -

    • Indices: n/a

      • -
    -
    • -
-
- -
-
-
-
-
plexos_to_reeds
-
-
inputs
- -
- -
- -
- -
- -
-
-
-
-
tests
-
-
data
-
-
r2r_expanded
-

####### expected_results

- -
-

####### reeds

-

####### inputs_case

- -
- -
- -
- -
-

####### supplycurve_metadata

- -
- -
-

####### outputs

- -
- -
- -
- -
- -
-

####### supply_curves

- -
-
-
-
r2r_from_config
-

####### expected_results

-

####### multiple_priority_inputs

- -
- -
- -
- -
-

####### no_bin_constraint

- -
- -
- -
- -
-

####### priority_inputs

- -
- -
- -
- -
-

####### wind-ons_6mw_inputs

- -
- -
-
-
-
r2r_integration
-

####### expected_results

- -
- -
- -
- -
- -
- -
- -
- -
- -
-

####### reeds

-

####### inputs_case

- -
- -
- -
- -
-

####### supplycurve_metadata

- -
-

####### outputs

- -
- -
- -
- -
- -
-

####### supply_curves

- -
-

####### upv_reference

-

####### results

- -
-

####### wind-ofs_0_open_moderate

-

####### results

- -
-

####### wind-ons_reference

-

####### results

- -
-
-
-
-
-
-

inputs

- -
-
    -

  • energy_communities.csv

    -
      -

    • Description: Contains a list of all county-regions designated as an energy community. The list is created from the NETL Energy Comunity Tax Bonus Website (https://arcgis.netl.doe.gov/portal/apps/experiencebuilder/experience/?id=a2ce47d4721a477a8701bd0e08495e1d) for 2023, and is appended with the list of new counties designated as energy communities published by the IRS in March 2024 (https://www.irs.gov/pub/irs-drop/n-24-30-appendix-2.pdf).

      • -
    -
    • -
-
- -
- -
- -
- -
- -
-
-
canada_imports
-
    -

  • can_exports.csv

    -
      -

    • File Type: Input

      • -

    • Description: Annual exports to Canada by BA

      • -

    • Indices: r,t

      • -

    • Units: MWh

      • -
    -
    • -
-
-
    -

  • can_exports_szn_frac.csv

    -
      -

    • File Type: Input

      • -

    • Description: Fraction of annual exports to Canada by season

      • -

    • Indices: N/A

      • -

    • Units: rate (unitless)

      • -
    -
    • -
-
-
    -

  • can_imports.csv

    -
      -

    • File Type: Input

      • -

    • Description: Annual imports from Canada by BA

      • -

    • Indices: r,t

      • -

    • Units: MWh

      • -
    -
    • -
-
-
    -

  • can_imports_quarter_frac.csv

    -
      -

    • File Type: Input

      • -

    • Description: Fraction of annual imports from Canada by season

      • -

    • Indices: N/A

      • -

    • Units: rate (unitless)

      • -
    -
    • -
-
-
-
-
capacity_exogenous
- -
- -
-
    -

  • demonstration_plants.csv

    -
      -

    • File Type: Prescribed capacity

      • -

    • Description: Nuclear-smr demonstration plants; active when GSw_NuclearDemo=1

      • -

    • Indices: t,r,i,coolingwatertech,ctt,wst,value

      • -

    • Citation: [(See ‘notes’ column in the file)]

      • -

    • Units: MW

      • -
    -
    • -
-
- -
-
    -

  • rsmap.csv

    -
      -

    • Description: Mapping for BAs to resource regions

      • -

    • Indices: r,rs

      • -
    -
    • -
-
-
    -

  • upv_exog_cap_limited_ba.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) UPV capacity with limited siting assumptions at BA resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • upv_exog_cap_limited_county.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) UPV capacity with limited siting assumptions at county resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • upv_exog_cap_open_ba.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) UPV capacity with open siting assumptions at BA resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • upv_exog_cap_open_county.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) UPV capacity with open siting assumptions at county resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • upv_exog_cap_reference_ba.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) UPV capacity with reference siting assumptions at BA resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • upv_exog_cap_reference_county.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) UPV capacity with reference siting assumptions at county resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • upv_prescribed_builds_limited_ba.csv

    -
      -

    • File Type: Prescribed capacity

      • -

    • Description: UPV prescribed builds with limited siting assumptions at BA resolution

      • -

    • Indices: r,t

      • -

    • Units: MW

      • -
    -
    • -
-
- -
-
    -

  • upv_prescribed_builds_open_ba.csv

    -
      -

    • File Type: Prescribed capacity

      • -

    • Description: UPV prescribed builds with open siting assumptions at BA resolution

      • -

    • Indices: r,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • upv_prescribed_builds_open_county.csv

    -
      -

    • File Type: Prescribed capacity

      • -

    • Description: UPV prescribed builds with open siting assumptions at county resolution

      • -

    • Indices: r,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • upv_prescribed_builds_reference_ba.csv

    -
      -

    • File Type: Prescribed capacity

      • -

    • Description: UPV prescribed builds with reference siting assumptions at BA resolution

      • -

    • Indices: r,t

      • -

    • Units: MW

      • -
    -
    • -
-
- -
- -
- -
-
    -

  • wind-ofs_prescribed_builds_open_ba.csv

    -
      -

    • File Type: Prescribed capacity

      • -

    • Description: wind-ofs prescribed builds with open siting assumptions at BA resolution

      • -

    • Indices: r,t

      • -

    • Units: MW

      • -
    -
    • -
-
- -
-
    -

  • wind-ons_exog_cap_limited_ba.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) wind-ons capacity with limited siting assumptions at BA resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • wind-ons_exog_cap_limited_county.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) wind-ons capacity with limited siting assumptions at county resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • wind-ons_exog_cap_open_ba.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) wind-ons capacity with open siting assumptions at BA resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • wind-ons_exog_cap_open_county.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) wind-ons capacity with open siting assumptions at county resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • wind-ons_exog_cap_reference_ba.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) wind-ons capacity with reference siting assumptions at BA resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
-
    -

  • wind-ons_exog_cap_reference_county.csv

    -
      -

    • File Type: Exogenous capacity

      • -

    • Description: Exogenous (pre-2010) wind-ons capacity with reference siting assumptions at county resolution

      • -

    • Indices: tech,r,sc_point_grid,t

      • -

    • Units: MW

      • -
    -
    • -
-
- -
- -
-
    -

  • wind-ons_prescribed_builds_open_ba.csv

    -
      -

    • File Type: Prescribed capacity

      • -

    • Description: wind-ons prescribed builds with open siting assumptions at BA resolution

      • -

    • Indices: r,t

      • -

    • Units: MW

      • -
    -
    • -
-
- -
- -
- -
-
-
-
climate
- -
- -
- -
- -
-
-
GFDL-ESM2M_RCP4p5_WM
- -
- -
- -
- -
- -
- -
-
-
-
HadGEM2-ES_RCP2p6
- -
- -
- -
- -
-
-
-
HadGEM2-ES_rcp45_AT
- -
- -
- -
- -
- -
- -
-
-
-
HadGEM2-ES_RCP4p5
- -
- -
- -
- -
-
-
-
HadGEM2-ES_rcp85_AT
- -
- -
- -
- -
- -
- -
-
-
-
HadGEM2-ES_RCP8p5
- -
- -
- -
- -
-
-
-
IPSL-CM5A-LR_RCP8p5_WM
- -
- -
- -
- -
- -
- -
-
-
-
-
consume
-
    -

  • consume_char_low.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Cost (capex, FOM, VOM) and efficiency (gas and electrical) as well as storage and transmission adder (stortran_adder) inputs for various H2 producing technologies, under Conservative assumptions.

      • -

    • Indices: i,t

      • -

    • Dollar year: Units vary based on the parameter - see commented text in b_inputs.gms.

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • consume_char_ref.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Cost (capex, FOM, VOM) and efficiency (gas and electrical) as well as storage and transmission adder (stortran_adder) inputs for various H2 producing technologies, under Reference assumptions.

      • -

    • Indices: i,t

      • -

    • Dollar year: Units vary based on the parameter - see commented text in b_inputs.gms.

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • dac_elec_BVRE_2021_high.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: DAC costs (capex, FOM, VOM) and conversion rate, over time, using High assumptions.

      • -

    • Indices: i,t

      • -

    • Dollar year: As specified in inputs/consume/dollaryear

      • -

    • Citation: [(Beyond VRE project with Exxon Mobile and NETL.)]

      • -
    -
    • -
-
-
    -

  • dac_elec_BVRE_2021_low.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: DAC costs (capex, FOM, VOM) and conversion rate, over time, using Low assumptions.

      • -

    • Indices: i,t

      • -

    • Dollar year: As specified in inputs/consume/dollaryear

      • -

    • Citation: [(Beyond VRE project with Exxon Mobile and NETL.)]

      • -
    -
    • -
-
-
    -

  • dac_elec_BVRE_2021_mid.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: DAC costs (capex, FOM, VOM) and conversion rate, over time, using Mid assumptions.

      • -

    • Indices: i,t

      • -

    • Dollar year: As specified in inputs/consume/dollaryear

      • -

    • Citation: [(Beyond VRE project with Exxon Mobile and NETL.)]

      • -
    -
    • -
-
-
    -

  • dac_gas_BVRE_2021_high.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: DAC costs (capex, FOM, VOM) and conversion rate, over time, using High assumptions.

      • -

    • Indices: i,t

      • -

    • Dollar year: As specified in inputs/consume/dollaryear

      • -

    • Citation: [(Beyond VRE project with Exxon Mobile and NETL.)]

      • -
    -
    • -
-
-
    -

  • dac_gas_BVRE_2021_low.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: DAC costs (capex, FOM, VOM) and conversion rate, over time, using Low assumptions.

      • -

    • Indices: i,t

      • -

    • Dollar year: As specified in inputs/consume/dollaryear

      • -

    • Citation: [(Beyond VRE project with Exxon Mobile and NETL.)]

      • -
    -
    • -
-
-
    -

  • dac_gas_BVRE_2021_mid.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: DAC costs (capex, FOM, VOM) and conversion rate, over time, using Mid assumptions.

      • -

    • Indices: i,t

      • -

    • Dollar year: As specified in inputs/consume/dollaryear

      • -

    • Citation: [(Beyond VRE project with Exxon Mobile and NETL.)]

      • -
    -
    • -
-
-
    -

  • dollaryear.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Dollar year for various Beyond VRE scenarios.

      • -

    • Indices: N/A

      • -

    • Dollar year: Stated in document.

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • h2_ba_share.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: The fraction of hydrogen demand in that year that corresponds to a particular ReEDS BA.

      • -

    • Indices: r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • h2_exogenous_demand.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Exogenous hydrogen demand by industries other than the power sector per year

      • -

    • Indices: t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • h2_storage_rb.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Mapping of types of storage that exist in various ReEDS BAs.

      • -

    • Indices: r

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • h2_transport_and_storage_costs.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Transport and storage costs of hydrogen per year

      • -

    • Indices: t

      • -

    • Dollar year: 2004

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • pipeline_cost_mult.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Multiplier to the cost of hydrogen pipelines in various r–>r combinations.

      • -

    • Indices: r

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
-
-
ctus
- -
- -
- -
- -
-
-
-
degradation
- -
-
-
-
demand_response
- -
-
    -

  • dr_decrease_profile_Baseline.csv

    -
      -

    • File Type: inputs

      • -

    • Description: Average capacity factor for dr profile which leads to an increase in load in timeslice h for Baseline demand response profile. The demand response profiles are not being actively developed and may be outdated.

      • -

    • Units: fraction

      • -
    -
    • -
-
- -
- -
- -
- -
-
    -

  • dr_increase_profile_Baseline.csv

    -
      -

    • File Type: inputs

      • -

    • Description: Average capacity factor for dr profile which leads to a reduction in load in timeslice h for Baseline demand response profile. The demand response profiles are not being actively developed and may be outdated.

      • -

    • Units: fraction

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
    -

  • ev_load_Baseline.h5

    -
      -

    • File Type: inputs

      • -

    • Description: Baseline electricity load from EV charging by timeslice h and year t

      • -

    • Units: MW

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
-
-
-
dGen_model_inputs
-
    -

  • distPVCF_hourly.csv

    -
      -

    • File Type: distribution PV inputs

      • -

    • Description: Setting for distpv scenario hourly cf

      • -

    • Units: fraction

      • -
    -
    • -
-
-
-
stscen2023_highng
-
    -

  • distpvcap_stscen2023_highng.csv.csv

    -
      -

    • File Type: distribution PV inputs

      • -

    • Description: Setting for distpv scenario capacity - from standard scenarios 2023 with high NG (including distpv) costs

      • -
    -
    • -
-
-
-
-
stscen2023_highre
-
    -

  • distpvcap_stscen2023_highre.csv.csv

    -
      -

    • File Type: distribution PV inputs

      • -

    • Description: Setting for distpv scenario capacity - from standard scenarios 2023 with high RE (including distpv) costs

      • -
    -
    • -
-
-
-
-
stscen2023_lowng
-
    -

  • distpvcap_stscen2023_lowng.csv.csv

    -
      -

    • File Type: distribution PV inputs

      • -

    • Description: Setting for distpv scenario capacity - from standard scenarios 2023 with low NG (including distpv) costs

      • -
    -
    • -
-
-
-
-
stscen2023_lowre
-
    -

  • distpvcap_stscen2023_lowre.csv.csv

    -
      -

    • File Type: distribution PV inputs

      • -

    • Description: Setting for distpv scenario capacity - from standard scenarios 2023 with low RE (including distpv) costs

      • -
    -
    • -
-
-
-
-
stscen2023_mid_case
- -
-
-
-
stscen2023_mid_case_95_by_2035
- -
-
-
-
stscen2023_mid_case_95_by_2050
- -
-
-
-
stscen2023_taxcredit_extended2050
- -
-
-
-
-
dGen_Model_Inputs
-
-
stscen2023_electrification
- -
-
-
-
-
disaggregation
-
    -

  • disagg_geosize.csv

    -
      -

    • Description: The geographic area fraction of each county within a given ReEDS BA, used as multipliers for disaggregating spatial data

      • -

    • Indices: r

      • -
    -
    • -
-
-
    -

  • disagg_hydroexist.csv

    -
      -

    • Description: The hydropower capacity fraction of each county within a given ReEDS BA, used as multipliers for downselecting data

      • -

    • Indices: r

      • -
    -
    • -
-
-
    -

  • disagg_population.csv

    -
      -

    • Description: The population fraction of each county within a given ReEDS BA, used as multipliers for downselecting data

      • -

    • Indices: r

      • -
    -
    • -
-
-
    -

  • disagg_translinesize.csv

    -
      -

    • Description: The ratio of transmission capacity between a given US county and Canadian BA in relation to the total transmission capacity between the Canadian BA and the US BA that said county is in.

      • -

    • Indices: r

      • -
    -
    • -
-
-
-
-
emission_constraints
- -
- -
- -
- -
- -
-
    -

  • co2_cap.csv

    -
      -

    • Description: Annual nationwide carbon cap

      • -
    -
    • -
-
- -
- -
- -
- -
-
    -

  • emitrate.csv

    -
      -

    • Description: Emition rates for thermal generator for SO2, NOx, and CO2

      • -

    • Indices: i,e

      • -
    -
    • -
-
- -
-
    -

  • ng_crf_penalty.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Cost adjustment for NG techs in scenarios with national decarbonization targets

      • -

    • Indices: allt

      • -

    • Dollar year: N/A

      • -

    • Citation: [(https://github.nrel.gov/ReEDS/ReEDS-2.0/pull/1220)]

      • -

    • Units: rate (unitless)

      • -
    -
    • -
-
- -
-
    -

  • rggicon.csv

    -
      -

    • Description: CO2 caps for RGGI states in metric tons

      • -
    -
    • -
-
- -
-
-
-
financials
- -
- -
- -
-
    -

  • deflator.csv

    -
      -

    • Description: Dollar year deflator to convert values to 2004$

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
    -

  • reg_cap_cost_mult_default.csv

    -
      -

    • File Type: parameter

      • -

    • Description: region-specific multipliers for capital cost of all resources. Note: RE resources have values of 1 since their multipliers are incorporated in hourlize

      • -

    • Indices: i,r

      • -
    -
    • -
-
- -
- -
- -
-
-
-
fuelprices
-
    -

  • alpha_AEO_2022_HOG .csv

    -
      -

    • File Type: Input

      • -

    • Description: High Oil and Gas scenario census division alpha values, used in the calculation of natural gas demand curves

      • -

    • Indices: allt,cendiv

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO 2022)]

      • -
    -
    • -
-
-
    -

  • alpha_AEO_2022_LOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: Low Oil and Gas scenario census division alpha values, used in the calculation of natural gas demand curves

      • -

    • Indices: allt,cendiv

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO 2022)]

      • -
    -
    • -
-
-
    -

  • alpha_AEO_2022_reference.csv

    -
      -

    • File Type: Input

      • -

    • Description: reference census division alpha values, used in the calculation of natural gas demand curves

      • -

    • Indices: allt,cendiv

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO 2022)]

      • -
    -
    • -
-
-
    -

  • alpha_AEO_2023_HOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: High Oil and Gas scenario census division alpha values, used in the calculation of natural gas demand curves

      • -

    • Indices: allt,cendiv

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO 2023)]

      • -
    -
    • -
-
-
    -

  • alpha_AEO_2023_LOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: Low Oil and Gas scenario census division alpha values, used in the calculation of natural gas demand curves

      • -

    • Indices: allt,cendiv

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO 2023)]

      • -
    -
    • -
-
-
    -

  • alpha_AEO_2023_reference.csv

    -
      -

    • File Type: Input

      • -

    • Description: reference census division alpha values, used in the calculation of natural gas demand curves

      • -

    • Indices: allt,cendiv

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO 2023)]

      • -
    -
    • -
-
-
    -

  • cd_beta0.csv

    -
      -

    • File Type: Input

      • -

    • Description: reference census division beta levels electric sector

      • -

    • Indices: cendiv

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • cd_beta0_allsector.csv

    -
      -

    • File Type: Input

      • -

    • Description: reference census division beta levels all sectors

      • -

    • Indices: cendiv

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • cendivweights.csv

    -
      -

    • Description: weights to smooth gas prices between census regions to avoid abrupt price changes at the cendiv borders

      • -

    • Indices: r,cendiv

      • -
    -
    • -
-
-
    -

  • coal_AEO_2022_reference.csv

    -
      -

    • Description: reference case census division fuel price of coal

      • -

    • Indices: t,cendiv

      • -

    • Dollar year: 2022

      • -
    -
    • -
-
-
    -

  • coal_AEO_2023_reference.csv

    -
      -

    • Description: reference case census division fuel price of coal

      • -

    • Indices: t,cendiv

      • -

    • Dollar year: 2023

      • -
    -
    • -
-
-
    -

  • dollaryear.csv

    -
      -

    • Description: Dollar year mapping for each fuel price scenario

      • -
    -
    • -
-
- -
- -
- -
-
    -

  • ng_AEO_2022_HOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: High Oil and Gas scenario census division fuel price of natural gas

      • -

    • Indices: cendiv,t

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: 2004$/MMBtu

      • -
    -
    • -
-
-
    -

  • ng_AEO_2022_LOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: Low Oil and Gas scenario census division fuel price of natural gas

      • -

    • Indices: cendiv,t

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: 2004$/MMBtu

      • -
    -
    • -
-
-
    -

  • ng_AEO_2022_reference.csv

    -
      -

    • File Type: Input

      • -

    • Description: Reference scenario census division fuel price of natural gas

      • -

    • Indices: cendiv,t

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: 2004$/MMBtu

      • -
    -
    • -
-
-
    -

  • ng_AEO_2023_HOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: High Oil and Gas scenario census division fuel price of natural gas

      • -

    • Indices: cendiv,t

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: 2004$/MMBtu

      • -
    -
    • -
-
-
    -

  • ng_AEO_2023_LOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: Low Oil and Gas scenario census division fuel price of natural gas

      • -

    • Indices: cendiv,t

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: 2004$/MMBtu

      • -
    -
    • -
-
-
    -

  • ng_AEO_2023_reference.csv

    -
      -

    • File Type: Input

      • -

    • Description: Reference scenario census division fuel price of natural gas

      • -

    • Indices: cendiv,t

      • -

    • Dollar year: 2004

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: 2004$/MMBtu

      • -
    -
    • -
-
-
    -

  • ng_demand_AEO_2022_HOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: High Oil and Gas census division natural gas demand for the electric sector, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_demand_AEO_2022_LOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: Low Oil and Gas census division natural gas demand for the electric sector, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_demand_AEO_2022_reference.csv

    -
      -

    • File Type: Input

      • -

    • Description: Reference census division natural gas demand for the electric sector, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_demand_AEO_2023_HOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: High Oil and Gas census division natural gas demand for the electric sector, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_demand_AEO_2023_LOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: Low Oil and Gas census division natural gas demand for the electric sector, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_demand_AEO_2023_reference.csv

    -
      -

    • File Type: Input

      • -

    • Description: Reference census division natural gas demand for the electric sector, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_tot_demand_AEO_2022_HOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: High Oil and Gas census division natural gas demand across all sectors, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_tot_demand_AEO_2022_LOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: Low Oil and Gas census division natural gas demand across all sectors, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_tot_demand_AEO_2022_reference.csv

    -
      -

    • File Type: Input

      • -

    • Description: Reference census division natural gas demand across all sectors, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_tot_demand_AEO_2023_HOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: High Oil and Gas census division natural gas demand across all sectors, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_tot_demand_AEO_2023_LOG.csv

    -
      -

    • File Type: Input

      • -

    • Description: Low Oil and Gas census division natural gas demand across all sectors, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
-
    -

  • ng_tot_demand_AEO_2023_reference.csv

    -
      -

    • File Type: Input

      • -

    • Description: Reference census division natural gas demand across all sectors, used in the calculation of natural gas demand curves

      • -

    • Indices: cendiv,t

      • -

    • Citation: [(AEO2023: https://www.eia.gov/outlooks/aeo/)]

      • -

    • Units: Quads

      • -
    -
    • -
-
- -
- -
-
-
-
geothermal
- -
- -
- -
- -
-
-
-
growth_constraints
- -
- -
- -
- -
-
-
-
hydro
-
    -

  • hyd_fom.csv

    -
      -

    • Description: Regional FOM costs for hydro

      • -
    -
    • -
-
- -
- -
- -
-
-
-
load
- -
- -
- -
-
    -

  • cangrowth.csv

    -
      -

    • Description: Canada load growth multiplier

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
-
-
national_generation
- -
- -
- -
-
-
-
plant_characteristics
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
    -

  • dollaryear.csv

    -
      -

    • Description: Dollar year mapping for each plant cost scenario

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
    -

  • heat_rate_adj.csv

    -
      -

    • Description: Heat rate adjustment multiplier by technology

      • -
    -
    • -
-
- -
- -
- -
- -
-
    -

  • ice_fom.csv

    -
      -

    • Description: Fixed O&M for ice storage

      • -
    -
    • -
-
-
    -

  • maxage.csv

    -
      -

    • Description: Maximum age allowed for each technology

      • -
    -
    • -
-
- -
-
    -

  • minCF.csv

    -
      -

    • Description: minimum annual capacity factor for each tech fleet - applied to i-rto

      • -
    -
    • -
-
- -
-
    -

  • minloadfrac0.csv

    -
      -

    • Description: characteristics/minloadfrac0 database of minloadbed generator cs

      • -
    -
    • -
-
- -
-
    -

  • ofs-wind_ATB_2023_advanced.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2023 advanced ofs-wind capital, fixed O&M, var O&M costs and rsc_mult (SC cost reduction mult) by class and year. Note: rsc_mult is outdated and not in use from 2024 anymore

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • ofs-wind_ATB_2023_conservative.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2023 conservative ofs-wind capital, fixed O&M, var O&M costs and rsc_mult (SC cost reduction mult) by class and year. Note: rsc_mult is outdated and not in use from 2024 anymore

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • ofs-wind_ATB_2023_moderate.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2023 moderate ofs-wind capital, fixed O&M, var O&M costs and rsc_mult (SC cost reduction mult) by class and year. Note: rsc_mult is outdated and not in use from 2024 anymore

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • ofs-wind_ATB_2023_moderate_noFloating.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2023 moderate capital, fixed O&M and var O&M costs of non-floating type ofs-wind by class and year

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • ofs-wind_ATB_2024_advanced.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2024 advanced ofs-wind capital, fixed O&M, var O&M costs and rsc_mult (SC cost reduction mult) by class and year

      • -

    • Dollar year: 2022

      • -
    -
    • -
-
-
    -

  • ofs-wind_ATB_2024_conservative.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2024 conservative ofs-wind capital, fixed O&M, var O&M costs and rsc_mult (SC cost reduction mult) by class and year

      • -

    • Dollar year: 2022

      • -
    -
    • -
-
-
    -

  • ofs-wind_ATB_2024_moderate.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2024 moderate ofs-wind capital, fixed O&M, var O&M costs and rsc_mult (SC cost reduction mult) by class and year

      • -

    • Dollar year: 2022

      • -
    -
    • -
-
-
    -

  • ofs-wind_ATB_2024_moderate_noFloating.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2024 moderate_noFloating ofs-wind capital (5x floating capital cost), fixed O&M, var O&M costs and rsc_mult (SC cost reduction mult) by class and year

      • -

    • Dollar year: 2022

      • -
    -
    • -
-
-
    -

  • ons-wind_ATB_2023_advanced.csv

    -
      -

    • Description: 2023 advanced ons-wind capacity factor multiplier, capital, fixed O&M and var O&M costs by class and year, with a reference 115 hh, 175 rd turbine type

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • ons-wind_ATB_2023_conservative.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2023 conservative ons-wind capacity factor multiplier, capital, fixed O&M and var O&M costs by class and year, with a reference 115 hh, 175 rd turbine type

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • ons-wind_ATB_2023_moderate.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2023 moderate ons-wind capacity factor multiplier, capital, fixed O&M and var O&M costs by class and year, with a reference 115 hh, 175 rd turbine type

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • ons-wind_ATB_2024_advanced.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: Advanced cost and performance inputs from the 2024 Annual Technology Baseline for land-based wind

      • -

    • Dollar year: 2022

      • -
    -
    • -
-
-
    -

  • ons-wind_ATB_2024_conservative.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: Conservative cost and performance inputs from the 2024 Annual Technology Baseline for land-based wind

      • -

    • Dollar year: 2022

      • -
    -
    • -
-
-
    -

  • ons-wind_ATB_2024_moderate.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: Moderate cost and performance inputs from the 2024 Annual Technology Baseline for land-based wind

      • -

    • Dollar year: 2022

      • -
    -
    • -
-
- -
- -
- -
-
    -

  • ramprate.csv

    -
      -

    • Description: Generator ramp rates by technology

      • -
    -
    • -
-
- -
- -
- -
-
    -

  • upv_ATB_2023_advanced.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2023 advanced UPV capital, FOM and VOM costs, and capacity factor improvement multipliers by year

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • upv_ATB_2023_conservative.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2023 conservative UPV capital, FOM and VOM costs, and capacity factor improvement multipliers by year

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • upv_ATB_2023_moderate.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2023 moderate UPV capital, FOM and VOM costs, and capacity factor improvement multipliers by year

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • upv_ATB_2024_advanced.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2024 advanced UPV capital, FOM and VOM costs, and capacity factor improvement multipliers by year

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • upv_ATB_2024_conservative.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2024 conservative UPV capital, FOM and VOM costs, and capacity factor improvement multipliers by year

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • upv_ATB_2024_moderate.csv

    -
      -

    • File Type: Inputs file

      • -

    • Description: 2024 moderate UPV capital, FOM and VOM costs, and capacity factor improvement multipliers by year

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
- -
-
-
-
reserves
- -
- -
- -
-
    -

  • prm_annual.csv

    -
      -

    • Description: Annual planning reserve margin by NERC region

      • -
    -
    • -
-
- -
-
-
-
sets
-
    -

  • aclike.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of AC transmission capacity types

      • -
    -
    • -
-
-
    -

  • allt.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of all potential years

      • -
    -
    • -
-
-
    -

  • bioclass.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of bio tech classes

      • -
    -
    • -
-
- -
-
    -

  • ccsflex_cat.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of flexible ccs performance parameter categories

      • -
    -
    • -
-
-
    -

  • climate_param.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of parameters defined in climate_heuristics_finalyear

      • -
    -
    • -
-
-
    -

  • consumecat.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of categories for consuming facility characteristics

      • -
    -
    • -
-
-
    -

  • csapr_cat.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of CSAPR regulation categories

      • -
    -
    • -
-
-
    -

  • csapr_group.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of CSAPR trading groups

      • -
    -
    • -
-
-
    -

  • ctt.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of cooling technology types

      • -
    -
    • -
-
-
    -

  • dupv_upv_corr.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: correlation set for cost of capital calculations of dupv

      • -
    -
    • -
-
-
    -

  • e.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of emission categories used in model

      • -
    -
    • -
-
-
    -

  • eall.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of emission categories used in reporting

      • -
    -
    • -
-
-
    -

  • f.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of fuel types

      • -
    -
    • -
-
-
    -

  • flex_type.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of demand flexibility types

      • -
    -
    • -
-
-
    -

  • fuel2tech.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: mapping between fuel types and generations

      • -
    -
    • -
-
-
    -

  • fuelbin.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of gas usage brackets

      • -
    -
    • -
-
-
    -

  • gb.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of gas price bins

      • -
    -
    • -
-
-
    -

  • gbin.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of growth bins

      • -
    -
    • -
-
-
    -

  • geotech.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of geothermal technology categories

      • -
    -
    • -
-
-
    -

  • h2_st.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: defines investments needed to store and transport H2

      • -
    -
    • -
-
-
    -

  • h2_stor.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of H2 storage options

      • -
    -
    • -
-
-
    -

  • hintage_char.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of characteristics available in hintage_data

      • -
    -
    • -
-
-
    -

  • i.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of technologies

      • -
    -
    • -
-
-
    -

  • i_geotech.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: crosswalk between an individual geothermal technology and its category

      • -
    -
    • -
-
-
    -

  • i_h2_ptc_gen.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of technologies which can produce energy for electrolyzers claiming the hydrogen production tax credit due to their low lifecycle carbon emissions

      • -
    -
    • -
-
-
    -

  • i_p.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: mapping from technologies to the products they produce

      • -
    -
    • -
-
-
    -

  • i_subtech.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of categories for subtechs

      • -
    -
    • -
-
-
    -

  • i_water_nocooling.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of technologies that use water, but are not differentiated by cooling tech and water source

      • -
    -
    • -
-
-
    -

  • lcclike.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of transmission capacity types where lines are bundled with AC/DC converters

      • -
    -
    • -
-
- -
-
    -

  • noretire.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of technologies that will never be retired

      • -
    -
    • -
-
-
    -

  • notvsc.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of transmission capacity types that are not VSC

      • -
    -
    • -
-
-
    -

  • ofstype.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of offshore types used in offshore requirement constraint (eq_RPS_OFSWind)

      • -
    -
    • -
-
-
    -

  • ofstype_i.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: crosswalk between ofstype and i

      • -
    -
    • -
-
-
    -

  • orcat.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of operating reserve categories

      • -
    -
    • -
-
-
    -

  • ortype.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of types of operating reserve constraints

      • -
    -
    • -
-
-
    -

  • p.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of products produced

      • -
    -
    • -
-
-
    -

  • pcat.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of prescribed technology categories

      • -
    -
    • -
-
-
    -

  • plantcat.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of categories for plant characteristics

      • -
    -
    • -
-
- -
-
    -

  • prescriptivelink0.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: initial set of prescribed categories and their technologies - used in assigning prescribed builds

      • -
    -
    • -
-
-
    -

  • pvb_agg.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: crosswalk between hybrid pv+battery configurations and technology options

      • -
    -
    • -
-
-
    -

  • pvb_config.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of hybrid pv+battery configurations

      • -
    -
    • -
-
- -
-
    -

  • resourceclass.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of renewable resource classes

      • -
    -
    • -
-
-
    -

  • RPSCat.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of RPS constraint categories, including clean energy standards

      • -
    -
    • -
-
-
    -

  • sc_cat.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of supply curve categories (capacity and cost)

      • -
    -
    • -
-
-
    -

  • sdbin.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of storage durage bins

      • -
    -
    • -
-
-
    -

  • sw.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of surface water types where access is based on consumption not withdrawal

      • -
    -
    • -
-
-
    -

  • tg.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of technology groups

      • -
    -
    • -
-
-
    -

  • tg_rsc_cspagg.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of csp technologies that belong to the same class

      • -
    -
    • -
-
-
    -

  • tg_rsc_upvagg.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of pv and pvb technologies that belong to the same class

      • -
    -
    • -
-
-
    -

  • trancap_fut_cat.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of categories of near-term transmission projects that describe the likelihood of being completed

      • -
    -
    • -
-
-
    -

  • trtype.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of transmission capacity types

      • -
    -
    • -
-
-
    -

  • unitspec_upgrades.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of upgraded technologies that get unit-specific characteristics

      • -
    -
    • -
-
-
    -

  • upgrade_hintage_char.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set to operate over in extension of hintage_data characteristics when sw_upgrades = 1

      • -
    -
    • -
-
-
    -

  • w.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of water withdrawal or consumption options for water techs

      • -
    -
    • -
-
-
    -

  • wst.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of water source types

      • -
    -
    • -
-
-
    -

  • wst_climate.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set of water sources affected by climate change

      • -
    -
    • -
-
-
    -

  • yearafter.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: set to loop over for the final year calculation

      • -
    -
    • -
-
-
-
-
shapefiles
- -
- -
- -
-
    -

  • state_fips_codes.csv

    -
      -

    • Description: Mapping of states to FIPS codes and postcal code abbreviations

      • -
    -
    • -
-
- -
- -
-
-
WKT_csvs
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
-
-
-
state_policies
-
    -

  • acp_disallowed.csv

    -
      -

    • Description: List of states which do not allow alternative compliance payments in place of meeting RPS or CES requirements

      • -
    -
    • -
-
- -
-
    -

  • ces_fraction.csv

    -
      -

    • Description: Annual compliance for states with a CES policy

      • -
    -
    • -
-
-
    -

  • forced_retirements.csv

    -
      -

    • Description: List of regions with mandatory retirement policies for certain technologies

      • -
    -
    • -
-
- -
-
    -

  • ng_crf_penalty_st.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Cost adjustment for NG techs in states where all NG techs must be retired by a certain year

      • -

    • Indices: allt,st

      • -

    • Dollar year: N/A

      • -

    • Citation: [(https://github.nrel.gov/ReEDS/ReEDS-2.0/pull/1220)]

      • -

    • Units: rate (unitless)

      • -
    -
    • -
-
- -
- -
-
    -

  • offshore_req_30by30.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: state mandates of offshore wind capacity, 30 GW total by 2030

      • -

    • Indices: st,allt

      • -
    -
    • -
-
-
    -

  • offshore_req_default.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: default state mandates of offshore wind capacity

      • -

    • Indices: st,allt

      • -
    -
    • -
-
-
    -

  • oosfrac.csv

    -
      -

    • Description: Defines the fraction of renewable and clean energy credits can be purchased from out of state (oos). Applied for RPS and CES

      • -
    -
    • -
-
-
    -

  • recstyle.csv

    -
      -

    • Description: Indication for how to apply state requirement (0 = end-use sales, 1 = bus-bar sales, 2 = generation). Default is 0.

      • -
    -
    • -
-
-
    -

  • rectable.csv

    -
      -

    • Description: Table defining which states are allowed to trade RECs

      • -
    -
    • -
-
-
    -

  • rps_fraction.csv

    -
      -

    • Description: Indicates what fraction of sales or generation (based on recstyle.csv) must be from renewable energy

      • -
    -
    • -
-
- -
-
    -

  • techs_banned.csv

    -
      -

    • Description: Table that bans certain technologies by state

      • -
    -
    • -
-
-
    -

  • techs_banned_ces.csv

    -
      -

    • Description: Indicates which technolgies are not eligible to contribute to CES

      • -
    -
    • -
-
- -
-
    -

  • techs_banned_rps.csv

    -
      -

    • Description: Indicates which technolgies are not eligible to contribute to RPS

      • -
    -
    • -
-
-
    -

  • unbundled_limit_ces.csv

    -
      -

    • Description: Limit on fraction of credits towards CES which can be purchased unbundled from other states

      • -
    -
    • -
-
-
    -

  • unbundled_limit_rps.csv

    -
      -

    • Description: Limit on fraction of credits towards RPS which can be purchased unbundled from other states

      • -
    -
    • -
-
-
-
-
storage
- -
- -
- -
- -
-
-
-
supply_curve
-
    -

  • bio_supplycurve.csv

    -
      -

    • Description: Regional biomass supply and costs by resource class

      • -

    • Dollar year: 2015

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
    -

  • PSH_supply_curves_capacity_10hr_ref_dec2022.csv

    -
      -

    • Description: PSH supply curve capacity assuming 10 hour duration and reference exclusions as used in 2023 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_10hr_ref_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 10 hour duration and reference exclusions as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_10hr_wEphemeral_dec2022.csv

    -
      -

    • Description: PSH supply curve capacity assuming 10 hour duration and allowing sites on ephemeral streams as used in 2023 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_10hr_wEphemeral_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 10 hour duration and allowing sites on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_10hr_wExist_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 10 hour duration and allowing sites using existing reservoirs as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_10hr_wExist_wEph_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 10 hour duration and allowing sites using existing reservoirs and on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_12hr_ref_dec2022.csv

    -
      -

    • Description: PSH supply curve capacity assuming 12 hour duration and reference exclusions as used in 2023 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_12hr_ref_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 12 hour duration and reference exclusions as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_12hr_wEphemeral_dec2022.csv

    -
      -

    • Description: PSH supply curve capacity assuming 12 hour duration and allowing sites on ephemeral streams as used in 2023 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_12hr_wEphemeral_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 12 hour duration and allowing sites on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_12hr_wExist_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 12 hour duration and allowing sites using existing reservoirs as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_12hr_wExist_wEph_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 12 hour duration and allowing sites using existing reservoirs and on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_8hr_ref_dec2022.csv

    -
      -

    • Description: PSH supply curve capacity assuming 8 hour duration and reference exclusions as used in 2023 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_8hr_ref_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 8 hour duration and reference exclusions as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_8hr_wEphemeral_dec2022.csv

    -
      -

    • Description: PSH supply curve capacity assuming 8 hour duration and allowing sites on ephemeral streams as used in 2023 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_8hr_wEphemeral_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 8 hour duration and allowing sites on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_8hr_wExist_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 8 hour duration and allowing sites using existing reservoirs as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_capacity_8hr_wExist_wEph_mar2024.csv

    -
      -

    • Description: PSH supply curve capacity assuming 8 hour duration and allowing sites using existing reservoirs and on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_10hr_ref_dec2022.csv

    -
      -

    • Description: PSH supply curve cost assuming 10 hour duration and reference exclusions as used in 2023 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_10hr_ref_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 10 hour duration and reference exclusions as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_10hr_wEphemeral_dec2022.csv

    -
      -

    • Description: PSH supply curve cost assuming 10 hour duration and allowing sites on ephemeral streams as used in 2023 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_10hr_wEphemeral_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 10 hour duration and allowing sites on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_10hr_wExist_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 10 hour duration and allowing sites using existing reservoirs as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_10hr_wExist_wEph_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 10 hour duration and allowing sites using existing reservoirs and on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_12hr_ref_dec2022.csv

    -
      -

    • Description: PSH supply curve cost assuming 12 hour duration and reference exclusions as used in 2023 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_12hr_ref_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 12 hour duration and reference exclusions as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_12hr_wEphemeral_dec2022.csv

    -
      -

    • Description: PSH supply curve cost assuming 12 hour duration and allowing sites on ephemeral streams as used in 2023 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_12hr_wEphemeral_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 12 hour duration and allowing sites on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_12hr_wExist_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 12 hour duration and allowing sites using existing reservoirs as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_12hr_wExist_wEph_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 12 hour duration and allowing sites using existing reservoirs and on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_8hr_ref_dec2022.csv

    -
      -

    • Description: PSH supply curve cost assuming 8 hour duration and reference exclusions as used in 2023 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_8hr_ref_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 8 hour duration and reference exclusions as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_8hr_wEphemeral_dec2022.csv

    -
      -

    • Description: PSH supply curve cost assuming 8 hour duration and allowing sites on ephemeral streams as used in 2023 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_8hr_wEphemeral_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 8 hour duration and allowing sites on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_8hr_wExist_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 8 hour duration and allowing sites using existing reservoirs as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
-
    -

  • PSH_supply_curves_cost_8hr_wExist_wEph_mar2024.csv

    -
      -

    • Description: PSH supply curve cost assuming 8 hour duration and allowing sites using existing reservoirs and on ephemeral streams as used in 2024 Annual Technology Baseline

      • -

    • Dollar year: 2004

      • -

    • Citation: [(https://www.nrel.gov/gis/psh-supply-curves.html)]

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
-
-
techs
- -
-
    -

  • techs_default.csv

    -
      -

    • Description: List of technologies to be used in the model

      • -
    -
    • -
-
- -
-
-
-
transmission
-
    -

  • cost_hurdle_country.csv

    -
      -

    • File Type: GAMS set

      • -

    • Description: Cost for transmission hurdle rate by country

      • -

    • Indices: country

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
-
    -

  • r_rr_adj_ba.csv

    -
      -

    • Description: Set of adjacent regions at BA resolution

      • -
    -
    • -
-
- -
-
    -

  • rev_transmission_basecost.csv

    -
      -

    • File Type: inputs

      • -

    • Description: Unweighted average base cost across the four regions for which we have transmission cost data.

      • -

    • Indices: Transreg

      • -

    • Dollar year: 2004

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
    -

  • transmission_capacity_init_AC_ba_NARIS2024.csv

    -
      -

    • Description: Initial AC transmission capacity from the NARIS 2024 system at the BA resolution - ‘NARIS2024’ is a better starting point for future-oriented studies, but it becomes increasingly inaccurate for years earlier than 2024

      • -
    -
    • -
-
-
    -

  • transmission_capacity_init_AC_ba_REFS2009.csv

    -
      -

    • Description: Initial AC transmission capacity from the 2009 transmission system for ReEDS at the BA resolution - ‘REFS2009’ does not inclue direction-dependent capacities or differentiated capacities for energy and PRM trading but it better represents historical additions between 2010-2024

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
- -
- -
-
-
-
upgrades
-
    -

  • i_coolingtech_watersource_upgrades.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: List of cooling technologies for water sources that can be upgraded.

      • -

    • Indices: i

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • i_coolingtech_watersource_upgrades_link.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: List of cooling technologies for water sources that can be upgraded + their to, from, ctt (cooling technology type) and wst (water source type)

      • -

    • Indices: i, ctt, wst

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
- -
- -
-
    -

  • upgrade_link.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Techs that can be upgraded including the original technology, the technology it is upgrading to, and the delta.

      • -

    • Indices: i

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • upgrade_mult_atb23_ccs_adv.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Cost adjustment (advanced) over various years for upgrade technologies

      • -

    • Indices: i,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • upgrade_mult_atb23_ccs_con.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Cost adjustment (conservative) over various years for upgrade technologies

      • -

    • Indices: i,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • upgrade_mult_atb23_ccs_mid.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Cost adjustment (Mid) over various years for upgrade technologies

      • -

    • Indices: i,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • upgradelink_water.csv

    -
      -

    • File Type: Inputs

      • -

    • Description: Water techs that can be upgraded including the original technology, the technology it is upgrading to, and the delta (a H2-CT)

      • -

    • Indices: i

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
-
-
userinput
- -
- -
- -
-
    -

  • ivt_step.csv

    -
      -

    • Description: ivt steps for endyears beyond 2050

      • -
    -
    • -
-
-
    -

  • modeled_regions.csv

    -
      -

    • Description: Sets of BA regions that a user can model in a run. Each column is a different region option and can be specified in cases using GSw_Region.

      • -
    -
    • -
-
-
    -

  • windows_2100.csv

    -
      -

    • Description: Window size for using window solve method to 2100

      • -
    -
    • -
-
- -
- -
- -
-
-
-
valuestreams
- -
-
-
-
variability
- -
- -
- -
- -
-
    -

  • index_hr_map_1.csv

    -
      -

    • Description: Mapping for day set to season for a single year (365 days)

      • -
    -
    • -
-
-
    -

  • index_hr_map_7.csv

    -
      -

    • Description: Mapping for day set to season for a 7 years (2555 days)

      • -
    -
    • -
-
- -
- -
- -
- -
- -
-
-
multi_year
-
    -

  • csp-none_ba.h5

    -
      -

    • Description: Concentrated Solar Power resource supply curve. Data is a capacity factor i.e. a fraction.

      • -
    -
    • -
-
-
    -

  • dupv_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Distributed utility scale photovoltaics resource supply curve. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • upv-limited_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Utility scale photovoltaics resource supply curve using Limited access assumptions. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • upv-open_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Utility scale photovoltaics resource supply curve using Open access assumptions. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • upv-reference_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Utility scale photovoltaics resource supply curve using Reference access assumptions. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • upv_140AC-reference_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Utility scale photovoltaics resource supply curve (AC, using a 1.40 Inverter Load Ratio) using Reference access assumptions. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • upv_220AC-reference_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Utility scale photovoltaics resource supply curve (AC, using a 2.20 Inverter Load Ratio) using Reference access assumptions. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • wind-ofs-limited_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Offshore wind resource supply curve using Limited access assumptions. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • wind-ofs-open_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Offshore wind resource supply curve using Open access assumptions. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • wind-ons-limited_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Land-based wind resource supply curve using Limited access assumptions. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • wind-ons-open_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Land-based wind resource supply curve using Open access assumptions. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
    -

  • wind-ons-reference_ba.h5

    -
      -

    • File Type: Resource supply curve

      • -

    • Description: Land-based wind resource supply curve using Reference access assumptions. Data is a capacity factor i.e. a fraction.

      • -

    • Indices: v,r,t

      • -

    • Dollar year: N/A

      • -

    • Citation: [(N/A)]

      • -
    -
    • -
-
-
-
-
-
waterclimate
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
-
-
-

postprocessing

- -
-
-
air_quality
- -
-
-
rcm_data
- -
- -
- -
- -
- -
-
-
-
-
bokehpivot
-
-
in
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
    -

  • state_code.csv

    -
      -

    • Description: Abbreviation and code for each state

      • -
    -
    • -
-
-
-
reeds2
-
    -

  • class_map.csv

    -
      -

    • Description: Class mapping for bokehpivot postprocessing

      • -
    -
    • -
-
-
    -

  • class_style.csv

    -
      -

    • Description: Custom styles for classes in bokehpivot

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
-
    -

  • hours.csv

    -
      -

    • Description: Hours for each of the 17 timeslices

      • -
    -
    • -
-
- -
- -
- -
- -
- -
- -
-
    -

  • tech_style.csv

    -
      -

    • Description: Custom colors for each technology used by bokehpivot

      • -
    -
    • -
-
- -
- -
- -
- -
-
-
-
-
-
land_use
-
-
inputs
- -
- -
- -
- -
- -
- -
-
-
-
-
plots
- -
- -
-
-
-
retail_rate_module
- -
- -
- -
- -
- -
- -
-
    -

  • map_i_to_tech.csv

    -
      -

    • Description: Maps i to tech with custom coloring for each

      • -
    -
    • -
-
-
-
calc_historical_capex
- -
- -
- -
- -
- -
- -
-
-
-
inputs
- -
- -
- -
- -
- -
-
    -

  • rsmap.csv

    -
      -

    • Description: Mapping for BAs to resource regions

      • -

    • Indices: r,rs

      • -
    -
    • -
-
- -
- -
-
-
-
-
reValue
- -
-
-
-
tableau
- -
-
-
-
-

preprocessing

-
-
atb_updates_processing
-
-
input_files
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
-
-
-
-

reeds2pras

-
-
test
-
-
reeds_cases
-
-
USA_VSC_2035
- -
- -
-

####### inputs_case

- -
- -
- -
- -
-

####### ReEDS_Augur

-

####### augur_data

- -
- -
- -
- -
- -
- -
- -
-
-
-
-
-
-

ReEDS_Augur

- -
-
-
-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file diff --git a/docs/build/html/tableau.html b/docs/build/html/tableau.html deleted file mode 100644 index 13e4583f..00000000 --- a/docs/build/html/tableau.html +++ /dev/null @@ -1,161 +0,0 @@ - - - - - - - ReEDS-to-Tableau Postprocessing — ReEDS documentation - - - - - - - - - - - - - - - - - -
- - -
- -
-
-
- -
-
-
-
- - -
-

ReEDS-to-Tableau Postprocessing

-

This directory contains files that facilitate the postprocessing and analysis of ReEDS and ReEDS-to-PLEXOS results in Tableau. Tableau is a commercial software that requires purchase of a license.

-

You can run postprocess_for_tableau.py from the command line to assemble results, metadata, and supporting spatial files from multiple ReEDS (and optionally, ReEDS-to-PLEXOS) scenarios into a single Tableau extract (Tableau’s proprietary .hyper format, which is basically a self-contained SQL database), which is optimized for use within Tableau.

-

postprocess_for_tableau.py creates pivot tables of ReEDS outputs specified in the PIVOT_DEFS dictionary within pivot_definitions.py. You can specify which collections of pivot tables you want to include in your .hyper output file with the -p flag. Most of the outputs in each pivot table are simply the names of csvs created by e_report_dump.py, for which the column formats and the intended names of each as they’ll appear in Tableau are defined in tables_to_aggregate.csv. (If running postprocess_for_tableau.py throws an error The script assembles the pivot tables and combines them into a single Tableau .hyper extract file containing the pivotted tables for visualization and analysis in Tableau. It also creates a csv version of each pivot table.

-

Before running this script for the first time, you’ll need to install the Tableau Hyper API via pip with:

-

pip install tableauhyperapi

-

Note that if you’re pulling ReEDS-to-PLEXOS results into Tableau, you’ll also need to have the h5plexos package installed.

-
-

Example call:

-
python postprocess_for_tableau.py \
-    -d '//nrelnas01/reeds/some_dir_containing_runs' \
-    -o '//nrelnas01/reeds/some_directory_containing_runs/testbatch_suite' \    
-    -s testbatch_refseq,testbatch_carbtax,testbatch,carbcap \
-    -p standard,plexos
-
-
-

Run python postprocess_for_tableau.py –help for descriptions of the flags above and their expected arguments or simply look at the calls to argparse within in the script.

-

Alternatively to explicitly specifying the names of scenarios directly with the -s flag as in the example above, you can automatically include all completed ReEDS scenarios by including the -a flag instead.

-
-
-

Troubleshooting

-

postprocess_for_tableau.py creates a log file in the output directory called tableau.txt and redirects stdout and stderr there. Some error handling is present in the script, but if you encounter an error, the culprit is often an incorrect set of column definitions in tables_to_aggregate.csv. Sometimes the names of outputs and the order of sets they’re based on differ across branches of ReEDS. If columns you’ve defined in a pivot table within pivot_definitions.py aren’t appearing in the .hyper output, check that they’re correctly specified (including the correct path) in tables_to_aggregate.csv and pivot_definitions.py.

-

Often, it’s best to run the script line-by-line in an IDE to diagnose and fix problems. One place to look is the long series of elif statements that define custom operations for any csvs defined in pivot_definitions.py that don’t follow the simple pattern of joining one new column to a pivot table per csv.

-

You’ll notice a bunch of assignments to col_defs in postprocess_for_tableau.py. All dimensions and attributes (i.e. columns of tables) in Tableau must have data types defined, and we specify those to in a list with col_defs. These column types are passed to the tableauhyperapi function along with the location of the pivot table csv that we’ve just created in order for the pivot csv to be written into the Tableau .hyper file (which is really a SQL database under the hood). Those types are defined for all index sets in column_types, and the value column of csvs are by default assumed to be of type SqlType.double(). Where we need a different type, like a date or a geography for mapping, we define the SqlType explicitly in the logic within main().

-
-
-

Adding new outputs to the Tableau postprocessing

-

Say you’ve got a new output csv that’s created in e_report.gms and e_report_dump.py, and you want to export it into Tableau, and it’s indexed on (i,r,t). First, add it as a row in tables_to_aggregate.csv, along with its relative location within a ReEDS scenario directory, the name of the column as you’d like it to appear in Tableau, and the sets it’s indexed on, in the correct order. These index names tell the script the header names of each column in the csv, and they appear in Tableau as defined in column_types within postprocess_for_tableau.py. If you’re adding a new set name, add the set name and the name you’d like to appear in Tableau to that column_types dictionary.

-

Next, you’d add the csv name as defined tables_to_aggregate.csv to the csvs list for whichever pivot tables you’d like it to appear in within pivot_definitions.py. You must also add a corresponding entry to operation to tell the script how to aggregate any index columns that appear in your csv beyond the index columns defined for that pivot table in id_columns. Entries of sum or mean will aggregate across any extra columns accordingly. For example, we could export our (i,r,t)-indexed csv to the scen_r_t pivot table with the operation set to sum, which would tell the script to eliminate the i column by summing across all i. You could also include any string in operation and then use that to explicitly define a custom operation within the series of elifs in the main() block of postprocess_for_tableau.py.

-
-
-

Tableau Analysis Templates

-

There’s also a Tableau template in this directory: standard_reeds_analysis.twb. A .twb file includes the structure of a Tableau notebook (i.e. the structure worksheets and dashboards), but not the data it refers to. The template is set up to connect to a .hyper extract created using this workflow. This way, you can open up standard_reeds_analysis.twb in Tableau, connect to the .hyper data extract you’ve created using the workflow above, and it will populate the sheets with your results. Note that once you’ve done that, you can always save your Tableau notebook as a .twbx, which packages both the twb and the .hyper into one file, making sharing your results easier.

-
-
-

ReEDS-to-PLEXOS

-

You can pull PLEXOS results into their own pivot tables and add them to the Tableau extract simply by including the “plexos” pivot table collection in your call to postprocess_for_tableau.py. The script is currently set up to identify each different directory within <scenario directory>/plexos_export/solutions as its own PLEXOS scenario, which will be differentiated by its name in a “PLEXOS Scenario” column in the Tableau pivot tables that are created.

-
-
-

Geospatial Mapping in Tableau

-

Several pivot tables containing geometry/geography columns are created in the standard pivot table collection. These can be used to create choropleth maps, etc. within Tableau. region_mapping contains the mapping heirarchy of ReEDS regions and BAs, and line_mapping contains straight-line paths between each BA and the 25 BAs closest to it. The pivot tables pull from csvs in inputs/shapefiles that each contain a WKT-formatted geometry column in the EPSG:4326 format.

-
-
-

Dollar-year Adjustments

-

Just as a note, postprocess_for_tableau.py converts any cost to the dollar year specified with the input argument -dy <year>, wherever a column is titled with the string “2004$”.

-
-
- - -
-
- -
-
-
-
- - - - \ No newline at end of file