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.

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
• Required Software
• Computer Setup
  • For Microsoft Windows 10
    • ReEDS Repository Configuration
    • Python Configuration
    • GAMS Configuration
  • For MacOS
    • GAMS Configuration
    • Python Configuration
    • ReEDS Repository Configuration
  • Special Case Setup Requirements
• Executing the Model
  • Prompts for user input during "runbatch.py"
  • Runbatch.py Execution Protocol
  • Case-specific Batch File Execution Protocol
• Documentation
• Model Architecture
  • Modules
  • Tracking Capital Stock
• Frequently Asked Questions
  • How much are the GAMS licensing fees?
  • Is there a trial version of the GAMS license so I can test ReEDS?
  • What computer hardware is necessary to run ReEDS?
  • Can I configure a ReEDS case to run as an isolated interconnect?
• Contact Us
• Appendix
  • ReEDS Model Switches
  • Tips for reducing solve time

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.

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.

The setup and execution 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 document). For example, initiating the Windows Command Prompt application, i.e., cmd.exe, will launch a terminal window (Figure 1). (Note: If you have issues using command prompt, try using anaconda prompt or a git bash window)

Figure 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" (Figure 2). Alternatively, right click on the executable for the command line interface (e.g., Command Prompt) and click on "Run as administrator" (Figure 3). Then run the required software installer executables from the command line.

Figure 2. Screenshot of running an installer executable using "Run as administrator".

Figure 3. Screenshot of running "Command Prompt" with "Run as administrator".

The ReEDS source code is hosted on GitHub: https://github.com/NREL/ReEDS-2.0

1. From the Git command line run the following command to enable large file storage.

git lfs install

2. Clone the ReEDS-2.0 repository on your desktop. Alternatively, download a ZIP from GitHub (Figure 4).

Figure 4. Screenshot of GitHub links to clone the ReEDS repository or download ZIP of the ReEDS files.

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" (Figure 5). This will open the "System Properties" window (Figure 6).

Figure 5. Screenshot of a search for "environment variables" in the Windows start menu.

Figure 6. Screenshot of the "System Properties" window.

2. Click the "Environment Variables" button on the bottom right of the window (Figure 6). This will open the "Environment Variables" window (Figure 7).

Figure 7. Edit the Path environment variable.

3. Highlight the Path variable and click "Edit" (Figure 7). This will open the "Edit environment variable" window (Figure 8).

Figure 8. Append the Path environment.

4. Click "New" (Figure 8) 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 (Figure 9).

Figure 9. 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

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 (Figure 10).

Figure 10. Screenshot of a test of GAMS from the terminal window.

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.

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 Figure 10.

Download the latest version of Anaconda: https://www.anaconda.com/download

During Installation, select to install Anaconda for your machine only.

To have the installer automatically add anaconda to PATH, ensure that you've selected the box to "Add conda initialization to the shell"

To validate Python was installed properly execute the following command from a new terminal (without quotes): "python"

Python should initiate, looking similar to Figure 9.

The ReEDS source code is hosted on GitHub: https://github.com/NREL/ReEDS-2.0

1. From the Git command line run the following command to enable large file storage.

git lfs install

2. Clone the ReEDS-2.0 repository on your desktop and use the repository with GitHub Desktop. Alternatively, download a ZIP from GitHub (Figure 4).

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

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

For users outside the NREL network, 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, under inputs/variability/multi-year in the locally cloned ReEDS repository. The input_processing scripts have also been updated to check for these files for any county-level runs. For users within the NREL network, the scripts are designed to automatically copy the data from the network storage location. The 'cases_spatialflex.csv' file provides examples of specific switch settings to run ReEDS at county-level.

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.

Step 1 : Specify the ReEDS case name(s) and configuration(s) in the case configuration file. (Figure 11). The default case configuration file name is called "cases.csv", but the user may create custom case configuration files by using a suffix in the file name (e.g., "cases_test.csv"). The file "cases_test.csv" can be used to execute a "test" version of the model for the ERCOT system.

Within "cases.csv", The data in Column A are the model "switches" (also referred to as "options"). The data in Column B are brief descriptions of the switches. The data in Column C are the default values of the switches. The case configuration (or set of switches that define a case) begin with Column D. Each case configuration is represented by a single column. 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, default value from Column C is used. A complete list of switches is provided in the Appendix of this document.

Figure 11. Screenshot of cases.csv.

Step 2 : Initiate the case batching program

1. Navigate to the ReEDS model directory in the file explorer or command prompt/window.
2. Activate the reeds2 conda environment: conda activate reeds2. For details on creating this environment, see the #ConfigPy section above.
3. Enter python runbatch.py in a command prompt (be sure to be in the ReEDS directory) to run the ReEDS case batching program (Figure 12).
4. Provide responses to the suite of prompts in the command line (Figure 13). Please refer to the Prompts for user input during runbatch.py section below for more information about the prompts.
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"). A separate terminal window will be launched for each case (Figure 14).

Step 3 : Wait for each case to finish, check for successful completion, and view outputs. Once a case has finished (either from successful completion or from an error), the case-specific terminal window will close and a message in the main terminal window (i.e., where "runbatch.py" was initiated) will appear stating that the case has completed (Figure 15).

Figure 12. Screenshot of initiating "runbatch.py" from the command line.

Figure 13. Screenshot of prompts for user input during "runbatch.py".

Figure 14. Screenshot of a separate terminal window being launched for a case.

Figure 15. Screenshot of a message in the main terminal window stating when a case has finished.

When a user initiates a batch of ReEDS cases through "runbatch.py", a suite of prompts will appear in the terminal window. Additional details about these prompts are provided below.

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_seq", then all files and directories related to this case will be named test_ref_seq. All files and directories for ReEDS cases are stored in a directory called "\runs"
• WARNING! A batch prefix cannot start with a number given incompatibility with GAMS. The GAMS model declaration statement is as follows:

model {batch prefix}_{case} /all/ ;

Therefore, "batch prefix" CANNOT begin with a numeric and SHOULD begin with an alpha character (e.g., a, A, b, B, …).

• Entering a value of "0" (zero, no quotes) will assign the current date and time for the batch prefix in the form of v{YYYYMMDD}_{HHMM}. Note the preceding letter vee 'v' is necessary to ensure the batch prefix begins with an alpha character. For example, if batch prefix="0" and case="ref_seq" on September 30, 2019 at 3:00 PM (1500 hours military time), then all files and directories related to this case will be named v20190930_1500_ref_seq
• WARNING! Avoid re-using a (batch prefix, case) pair. If a directory "\runs{batch prefix}_{case}" already exists, a warning will be issued in the case-specific terminal window, but "runbatch.py" will overwrite data in the existing case directory (Figure 16). In some instances, the case execution will pause, and a message will appear in the case-specific terminal window "mv: replace […] overriding mode 0666?" (Figure 17). Pressing "Enter/Return" will continue the execution. NREL plans to address this overwriting issue in the future by requiring user approval to overwrite an existing case directory.

Figure 16. Screenshot of warning message that appears in the main terminal window when reusing a (batch prefix, case) pair.

Figure 17. Screenshot of warning message that occurs in the case-specific terminal window when reusing a (batch prefix, case) pair.

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.
• SUGGESTION : Users may want to create a custom case configuration file ("cases_{…}.csv") when executing scenarios that vary from the default case configuration file ("case.csv").

Number of Simultaneous Runs [integer] – Indicates how many cases should be run simultaneously in parallel.

• "runbatch.py" uses a queue to execute multiple cases.
• If there are four (4) cases and the Number of Simultaneous Runs=1, then "runbatch.py" will execute the cases one at a time.
• If there are four (4) cases and the Number of Simultaneous Runs=2, then "runbatch.py" will start two (2) cases simultaneously. Then as each case finishes a new one will start until all cases have been run.
• WARNING! Be mindful about the amount of CPU and RAM usage needed for each case.
  • Table 4 in the What computer hardware is necessary to run ReEDS? section below provides some initial data points for CPU and RAM usage.
  • An Intertemporal solve will take significant resources unless simplified (through the case configuration).
  • A Sequential solve has default value of four (4) threads in "cplex.opt". The number of threads can be reduced, requiring less CPU resource usage.

Number of simultaneous CC/Curt runs [integer] – Indicates how many threads are to be used for the capacity credit (CC) and curtailment (curt) batching program ("reflowbatch.py").

• This question is only asked when running intertemporal cases (i.e., timetype="int" in the case configuration file).
• With the intertemporal case, the linear program is formulated and solved for all years at once. Then the capacity credit and curtailment calculations are executed in parallel based on the Number of simultaneous CC/Curt runs specified by the user.

How many iterations between the model and CC/Curt scripts [integer]– For an intertemporal case, the "runbatch.py" will execute an LP solve and then call the cc/curt scripts. The value assigned here determines how many of these iterations between the LP and the cc/curt scripts occur.

• This question is only asked when running intertemporal cases (i.e., timetype="int" in the case configuration file).
• SUGGESTION : When executing an intertemporal case, it is good practice to set "cc_curt_load = 1" in "cases.csv" to enable pre-computed starting values for capacity credit and curtailment.
• Currently, there is no convergence criterion enforced. Typically, 5-6 iterations are enough for convergence, i.e., the capacity credit and curtailment values have "small" deviations since the prior iteration.

Below are the key steps that occur when a user initiates "runbatch.py". Knowing these steps may help the user understand the source code of "runbatch.py" if modifications need to be made to the batching program.

1. Request input from user though the command prompt.
2. Ingest case names and case switches from the user-specified case configuration file (e.g., "cases.csv")
3. Create a new directory for each case (\runs{batch_prefix}_{case}).
4. Create a batch file of execution statements for each case: (\runs{batch_prefix}_{case}\call_{batch_prefix}_{case}.bat)
5. All files from "runfiles.csv" are copied to "\runs{batch_prefix}_{case}\ "
   • Any files from the root of the repository will be copied to "\runs{batch_prefix}_{case}\ "
   • Any files from "\inputs\ " will be copied to "\runs{batch_prefix}_{case}\inputs_case\ "
6. Execute the batch file for each case in a new, case-specific window. This window will close when the case is finished. GAMS will produced files unique to each case that can help the user with error debugging:
   • GAMS Log File
     • Path: "\runs{batch_prefix}_{case}\gamslog.txt "
     • Purpose: contains the log outputs for all execution statements from the case batch file
     • SUGGESTION : This is a good place to check in which execution step errors may have occurred.
   • GAMS listing files (*.lst)
     • Path: "\runs{batch_prefix}_{case}\lstfiles\ "
     • Purpose: contains the listing files for GAMS executions
     • SUGGESTION : This is a good place to check in which line of the source code errors may have occurred
   • GAMS workfile (*.g00)
     • 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.
     • For more information about GAMS work files: https://www.gams.com/latest/docs/UG_SaveRestart.html
     • SUGGESTION : A failed case can be restarted from this snapshot point. The user can rerun the batch file for the case (\runs{batch_prefix}_{case}\call_{batch_prefix}_{case}.bat) after commenting out execution statements that completed successfully.
7. Build outputs and standard visualization reports for each case that completes successfully.

• Following a successful run, a suite of .csv output files are created in: "\runs{batch_prefix}_{case}\outputs\ "
• A standard .html visualization report is stored in: "\runs{batch prefix}_{case}\outputs\reeds-report\ "

Execute CreateModel.gms:

1. Execute B_Inputs.gms – ingest data from the files created by the input_processing scripts and format the data to be useful for the GAMS execution
2. Execute C_SupplyModel.gms – declare the variables and constraints for the linear program
3. Execute C_SupplyObjective.gms – declare the objective function for the linear program, broken into two parts (investment and operations)
4. Execute D_SolvePrep.gms – initiate the LP solve and compute parameters based on switch values in the case configuration file (e.g., "cases.csv")
5. Create a GAMS work file at the completion of CreateModel.gms
6. Path: "\runs{batch_prefix}_{case}\g00files{batch_prefix}_{case}.g00"
7. For more information about GAMS work files: https://www.gams.com/latest/docs/UG_SaveRestart.html

Execute the sequential solve structure (Figure 18)

For every year in the model horizon, execute d_solveoneyear.gms:

1. Execute solve
2. Execute d_callreflow.gms – Compute capacity credit and curtailment:
3. Execute ReEDS_capacity_credit.gms - compute the parameters necessary for ReEDS_capacity_credit.py (which computes the capacity credit)
4. Execute REflow_RTO_2_params.gms – translate the parameters from ReEDS 2.0 into their equivalents from ReEDS Heritage
5. Execute REflow_RTO_3.gms – compute curtailment using the syntax and structure from ReEDS Heritage
6. Execute d4_Translate_Variability.R – Translate the values from REflow_RTO_3.gms (ReEDS Heritage) back to the syntax and structure used in ReEDS 2.0

Figure 18. Depiction of execution sequence for the "sequential" solve.

Execute the intertemporal solve structure (Figure 19)

For each iteration (specified via the runbatch.py prompt),

1. Execute d_solveallyears.gms
2. Execute reflowbatch.py
3. Execute d_callreflow.gms – Compute capacity credit and curtailment; same process as for sequential, but for all years
4. Once all cc/curt calculations are done, files are merged via the GAMS gdxmerge utility
5. Execute d5_mergevariability.R – The resulting file from the gdxmerge execution is restructured for use in GAMS during the next iteration of the intertemporal solve.

Figure 19. Depiction of execution sequence for the "intertemporal" solve.

The ReEDS Version 2020 Documentation is available at no cost from the National Renewable Energy Laboratory: https://www.nrel.gov/docs/fy21osti/78195.pdf

Detailed documentation of ReEDS 2.0 input files are available here.

The source code in this repository is the ReEDS Version 2020 model.

Table 1 summarizes difference between Versions 2019 and 2020.

Table 1. differences between ReEDS Versions 2019 and 2020.

• Cole, Wesley, Daniel Greer, Jonathan Ho, and Robert Margolis. "Considerations for maintaining resource adequacy of electricity systems with high penetrations of PV and storage." Applied Energy 279 (2020): 115795.
• U. S. Department of Energy 2016. "Hydropower Vision: A New Chapter for America’s 1st Renewable Electricity Source." Technical Report DOE/GO-102016-4869. Washington, D.C.: U. S. Department of Energy. http://energy.gov/eere/water/articles/hydropower-vision-new-chapter-america-s-1st-renewable-electricity-source.
• Lopez, A., B. Roberts, D. Heimiller, N. Blair, and G. Porro. 2012. "US Renewable Energy Technical Potentials: A GIS-Based Analysis." Golden, CO: National Renewable Energy Laboratory. https://www.nrel.gov/docs/fy12osti/51946.pdf

The ReEDS model is comprised of several modules with one and two-way data exchange between the modules. Figure 20 depicts these modules, including linkages between the modules and directions of data exchange. The supply module is the core module for ReEDS. Within a ReEDS execution, the key data exchanges occur between (1) the Supply Module and the Variable Resource Renewable (VRR) Modules for estimating Capacity Credit and Curtailment; and (2) the Supply Module and the Demand Module. These module interactions are dictated by the model execution approach, i.e., sequential solves, sliding window solves, or intertemporal solves. Figure 21 illustrates the sequential approach; Figure 22 the sliding window and intertemporal approaches.

Figure 20. Depiction of ReEDS modules; arrows indicate directions of data exchange.

Figure 21. Schematic illustrating the model structure with a sequential solve.

Figure 22. Schematic illustrating the model structure with sliding window or intertemporal solves.

Because ReEDS is a long-term capacity planning model, electricity generation capacity (capital stock) must be tracked over time, including initial capacity, new investments, refurbishment investments, lifetime retirements, and endogenous retirements. Figure 23 depicts time resolution terminology and capital stock terminology. "Historical" years are 2010-2018, inclusive. "Future" years are 2019 and beyond. "Pre-modeled" years are years prior to 2010 and are not represented in the model decision making. "Modeled" years are years beginning in 2010, the first year of the model to the end of the model horizon. Users can specify the frequency of modeled years as depicted in Figure 24 in "\inputs\user_input\modeledyears_default.csv" and the horizon is specified in "cases.csv".

Figure 23. Depiction of time resolution terminology and capital stock terminology

Figure 24. Depiction of user-specified model years.

Capital stock added during the model execution is tracked by a vintage classification based on the time frame when the capacity is installed (e.g., capacity installed between 2030 and 2035 could be defined as a vintage class). The user can specify the vintage class resolution by technology type to control the model size (see "\inputs\userinput\ivt.csv"). All capacity of a technology type (e.g., nuclear) within the same vintage class has the same operating characteristics. Regardless of the vintage class, new investments incur capital cost associated with the year that the investment occurs.

Distinction is made between vintage classes for capacity built during the pre-modeled years---i.e., the initial vintage classes---and vintage classes for capacity built during the modeled years, i.e., the added vintage classes, (Figure 23). The initial vintage classes are categorized based on plant performance, specifically, heat rate (Figure 25). Whereas, added vintage classes are categorized based on when the capacity is installed.

Initial capacity is tracked based on the capacity remaining in each model year after planned retirements have been removed. Planned capacity additions made during historical modeled years, i.e., 2010-2018, are prescribed exactly, thus the model must build exactly the prescribed amount. Planned capacity built during future modeled years, i.e., 2019-2050, are prescribed as a lower bound for new investments, thus the model must build at least the prescribed amount (Figure 23).

Figure 25. Example of categorizing model plants for the existing fleet based on heat rate.

Please contact GAMS for more information.

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.

NREL uses Windows servers to execute the ReEDS model. These servers have Intel(R) Xeon(R) CPUs at 2-2.4GHz and 10-14 cores with 160-320GB of RAM. These servers can execute multiple ReEDS cases in parallel.

Table 4 summarizes RAM usage and total clock time necessary to execute the default ReEDS configuration for the three different solve structures (sequential, window, and intertemporal) using one of these servers.

Table 4. Ballpark RAM usage and clock time for select model configurations executed on NREL servers.

Table Notes:

• Default solve window configuration: 11 windows and 5 iterations per window (see "\inputs\userinput\windows_default.csv"). The problem size is taken from last iteration. The problem size varies by about 5% across iterations.
• Intertemporal: 8-12 hours per iteration, 5-7 iterations total

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 (WSC) census division which includes Texas, Oklahoma, Arkansas, and Louisiana. Or we could assume the gas price in the WSC 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

If you have comments and/or questions, please contacts the ReEDS team:

ReEDS.Inquiries@nrel.gov

ReEDS model switches are set in the cases.csv file. The "Choices" column lists allowable options for that switch, with N/A meaning that no error checking is performed for the options selected. Additional notes on switch functionality are provided below.

• 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.

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 and GSw_HierarchyFile = default, or agg2
  • Aggregate the native 134 zones into fewer, larger zones. GSw_HierarchyFile = default aggregates the 134 zones into 69 zones (obeying state, interconnect, NERC, and FERC region boundaries); GSw_HierarchyFile = agg2 aggregates the 134 zones into 54 zones (obeying state boundaries).