SGIP1 Analysis Example
Problem Description and Analysis Goals
The Smart Grid Interoperability Panel (SGIP), as a part of its work, defined a number of scenarios for use in understanding ways in which transactive energy can be applicable. The first of these (hereafter referred to as “SGIP1”) is a classic use case for transactive energy [2]:
The weather has been hot for an extended period, and it has now reached an afternoon extreme temperature peak. Electricity, bulk-generation resources have all been tapped and first-tier DER resources have already been called. The grid operator still has back-up DER resources, including curtailing large customers on interruptible contracts. The goal is to use TE designs to incentivize more DER to participate in lowering the demand on the grid.
To flesh out this example the following additions and/or assumptions were made:
The scenario will take place in Tucson Arizona where hot weather events that stress the grid are common.
The scenario will span two days with similar weather but the second day will include a bulk power system generator outage that will drive real-time prices high enough to incentivize participation by transactively enabled DERs.
Only HVACs will be used to respond to transactive signals
Roughly 50% of the HVACs on one particular feeder will participate in the transactive system. All other feeders will be modeled by a loadshape that is not price-responsive.
The goal of this analysis are as follows:
Evaluate the effectiveness of using transactively enabled DERs for reducing peak load.
Evaluate the value exchange for residential customers in terms of comfort lost and monetary compensation.
Evaluate the impacts of increasing rooftop solar PV penetration and energy storage on the transactive system performance.
Demonstrate the capabilities of TESP to perform transactive system co-simulations.
The software version of this study implemented in TESP is similar to but not identical to earlier versions used to produce results found in [22] and [13]. As such the specific values presented here may differ from those seen in the aforementioned publications.
Valuation Model
Use Case Diagram
A Use Case Diagram is helpful in providing a broad overview of the activities taking place in the system being modeled. It shows the external actors and the specific use cases in which each participates as well as any sequencing between specific use cases.
Value Flow Diagram
Value flows define the exchanges between actors in the system. For transactive systems, these value exchanges are essential in defining and enabling the transactive system to operate effectively. These value exchanges are often used when defining the key valuation metrics used to evaluate the performance of the system. The diagrams below show the key value exchanges modeled in this system.
Metrics Identification
To guide the development of the analysis, it is important that key metrics are identified in the value model. The diagram below shows the specific metrics identified as sub-elements of the Accounting Table object. Though this diagram does not define the means by which these metrics are calculated, it does define the need for such a defintion, leading to a data requirement from the analysis process.
Value exchanges modeled during the transactive system operation
Transactive Mechanism Flowchart (Sequence Diagram)
Key Performance Metrics Definitions
Some (but not all) of the key performance metrics used in this analysis are as follows. A list of the final metrics collected can be found in tabular form in Appendix C of [22].
Key Performance Variable Definitions:
Electrical energy per day
Electrical energy per day per customer:
Electrical energy fee per day:
Electrical energy per day per customer:
Accounting Table Metrics Definitions
From the value model, it is possible to define metrics that will reveal the value-based outcomes of the individual participants in the transactive system. These metrics often have a financial dimension but not always. The following equations were used to produce the metrics calculated for the Accounting Table. These equations use the following definitions:
Accounting Table Variable Definitions:
Wholesale electricity purchases for test feeder (MWh/d):
Wholesale electricity purchase cost for test feeder ($/day)
Total wholesale generation revenue ($/day)
Transmission and Distribution Losses (% of MWh generated):
Average PV energy transacted (kWh/day):
Average PV energy revenue ($/day):
Average ES energy transacted (kWh/day):
Average ES energy net revenue:
Emissions:
CO2 |
SOX |
NOX |
|
---|---|---|---|
coal |
2074.2013 |
1.009 |
0.6054 |
combined cycle |
898.0036 |
0.00767 |
0.057525 |
single cycle |
1331.1996 |
0.01137 |
0.085275 |
K |
|
---|---|
CO2 |
0.000453592 |
SOx |
0.453592 |
NOx |
0.453592 |
Total CO2, SOx, NOx emissions (MT/day, kg/day, kg/day):
Analysis Design Model
The analysis design model is a description of the planned analysis process showing how all the various analysis steps lead towards the computation of the key performance metrics. The data requirements of the valuation and validation metrics drive the definition of the various analysis steps that must take place in order to be able to calculate these metrics.
The level of detail is in this model is somewhat subjective and up to those leading the analysis. There must be sufficient detail to avoid the biggest surprises when planning the execution of the analysis but a highly detailed plan is likely to be more effort than it is worth. The analysis design model supports varying levels of fidelity by allowing any individual activity block to be defined in further detail through the definition of subactivities
Top Level
The top level analysis diagram (shown in Fig. 13) is the least detailed model and shows the analysis process at the coarsest level. On the left-hand side of the diagram is the source data (which includes assumptions) and is the only analysis activity with no inputs. The analysis activity blocks in the middle of the diagram show the creation of various outputs from previously created inputs with the terminal activities being the presentation of the final data in the form of tables, graphs, and charts.
Source Data
The green source data block in the top level diagram (see Fig. 13) is defined in further detail in a sub-diagram shown in Fig. 14. Many of these items are more than single values and are more complex data structures themselves.
Develop Transmission and Generation Model
The “Develop T+G model” activity block in the top level diagram (see Fig. 13) is defined in further detail in a sub-diagram shown in Fig. 15. The diagram shows that both generation and transmission network information is used to create a PYPOWER model.
Develop Distribution Model
The “Develop dist. model” activity block in the top level diagram (see Fig. 13) is defined in further detail in a sub-diagram shown in Fig. 16. The distribution model uses assumptions and information from the Residential Energy Consumer Survey (RECS) to define the properties of the modeled houses as well as the inclusion of rooftop solar PV and the participation in the transactive system. These inputs are used to generate a GridLAB-D model.
Develop Commercial Building Model
The “Develop commercial building model” activity block in the top level diagram (see Fig. 13) is defined in further detail in a sub-diagram shown in Fig. 17. The commercial building model is a predefined Energy+ model paired with a particular TMY3 weather file (converted to EPW for use in Energy+).
Prepare co-simulation
The “Prepare co-simulation” activity block in the top level diagram (see Fig. 13) is defined in further detail in a sub-diagram shown in Fig. 18. The core activity is the “Create co-sim config files” which are used by their respective simulation tools. Additionally, a special metadata file is created from the GridLAB-D model and is used by several of the metrics calculations directly.
Co-simulation
The “Co-simulation” activity block in the top level diagram (see Fig. 13) is defined in further detail in a sub-diagram shown in Fig. 19. The GridLAB-D model plays a central role as a significant portion of the modeling effort is centered around enabling loads (specifically HVACs) to participate in the transactive system. In addition to the previously shown information flows between the activities the dynamic data exchange that takes place during the co-simulation run; this is shown by the “<<flow>>” arrows.
Accounting Table
The “Accounting table” presentation block in the top level diagram (see Fig. 13) is defined in further detail in a series of sub-diagrams shown below. Each line of the accounting table shown in Fig. 11 is represented by a gray “presentation” block, showing the required inputs to produce that metric.
Analysis Validation
The “Analysis validation” presentation block in the top level diagram (see Fig. 13) is defined in further detail in a series of sub-diagrams shown below. These are metrics similar to those in the Accounting Table section but they are not necessarily defined by the value exchanges and thus fall outside the value model. These metrics are identified by the analysis designer in cooperation with analysis team as a whole and are used to validate the correct execution of the analysis.
Simulated System Model
Fig. 29 shows the types of assets and stakeholders considered for the use cases in this version. The active market participants include a double-auction market at the substation level, the bulk transmission and generation system, a large commercial building with one-way (price-responsive only) HVAC thermostat, and single-family residences that have a two-way (fully transactive) HVAC thermostat. Transactive message flows and key attributes are indicated in orange.
In addition, the model includes residential rooftop solar PV and electrical energy storage resources at some of the houses, and waterheaters at many houses. These resources can be transactive, but are not in this version. The rooftop solar PV has a nameplate efficiency of 20% and inverters with 100% efficiency. inverters are set to operate at a constant power factor of 1.0. The rated power of the rooftop solar PV installations varies from house to house and ranges from roughly 2.7 kW to 4.5 kW.
The energy storage devices also have inverters with 100% efficiency and operate in an autonomous load-following mode that performs peak-shaving and valley-filling based on the total load of the customer’s house to which it is attached. All energy storage devices are identical with a capacity of 13.5 kWh and a rated power of 5 kW (both charging and discharging). The batteries are modeled as lithium-ion batteries with a round-trip efficiency of 86%. Other details can be found in Table 4.
The Circuit Model
Fig. 30 shows the bulk system model in PYPOWER. It is a small system with three generating units and three load buses that comes with PYPOWER, to which we added a high-cost peaking unit to assure convergence of the optimal power flow in all cases. In SGIP-1 simulations, generating unit 2 was taken offline on the second day to simulate a contingency. The GridLAB-D model was connected to Bus 7, and scaled up to represent multiple feeders. In this way, prices, loads and resources on transmission and distribution systems can impact each other.
Fig. 31 shows the topology of a 12.47-kV feeder based on the western region of PNNL’s taxonomy of typical distribution feeders [26]. We use a MATLAB feeder generator script that produces these models from a typical feeder, including random placement of houses and load appliances of different sizes appropriate to the region. The model generator can also produce small commercial buildings, but these were not used here in favor of a detailed large building modeled in EnergyPlus. The resulting feeder model included 1594 houses, 755 of which had air conditioning, and approximately 4.8 MW peak load at the substation. We used a typical weather file for Arizona, and ran the simulation for two days, beginning midnight on July 1, 2013, which was a weekday. A normal day was simulated in order for the auction market history to stabilize, and on the second day, a bulk generation outage was simulated. See the code repository for more details.
Fig. 32 shows the building envelope for an elementary school model that was connected to the GridLAB-D feeder model at a 480-volt, three-phase transformer secondary. The total electric load varied from 48 kW to about 115 kW, depending on the hour of day. The EnergyPlus agent program collected metrics from the building model, and adjusted the thermostat setpoints based on real-time price, which is a form of passive response.
The Growth Model
This version of the growth model has been implemented for yearly increases in PV adoption, storage adoption, new (greenfield) houses, and load growth in existing houses. For SGIP-1, only the PV and storage growth has actually been used. A planned near-term extension will cover automatic transformer upgrades, making use of load growth more robust and practical.
Table 4 summarizes the growth model used in this report for SGIP-1. In row 1, with no (significant) transactive mechanism, one HVAC controller and one auction market agent were still used to transmit PYPOWER’s LMP down to the EnergyPlus model, which still responded to real-time prices. In this version, only the HVAC controllers were transactive. PV systems would operate autonomously at full output, and storage systems would operate autonomously in load-following mode.
Case |
Houses |
HVAC Controllers |
Waterheaters |
PV Systems |
Storage Systems |
---|---|---|---|---|---|
|
1594 |
1 |
1151 |
0 |
0 |
|
1594 |
755 |
1151 |
0 |
0 |
|
1594 |
755 |
1151 |
159 |
82 |
|
1594 |
755 |
1151 |
311 |
170 |
|
1594 |
755 |
1151 |
464 |
253 |
Simulation Architecture Model
The SGIP1 analysis, being a co-simulation, has a multiplicity of executables that are used to set-up the co-simulation, run the co-simulation, and process the data coming out of the co-simulation. The Analysis Design Model provides hints at which tools are used and how they interact but is not focused on how the tools fit together but rather how they can be used to achieve the necessary analysis objectives. This section fleshes out some of those details so that users are better able to understand the analysis process without having to resort to looking at the scripts, configuration files, and executable source code to understand the execution flow of the analysis.
Simulated Functionalities
The functionalities shown in Fig. 29 are implemented in simulation through a collection of software entities. Some of these entities perform dual roles (such as PYPOWER), solving equations that define the physical state of the system (in this case by solving the powerflow problem) and in also performing market operations to define prices (in this case by solving the optimal power flow problem).
GridLAB-D
Simulates the physics of the electrical distribution system by solving the power flow of the specified distribution feeder model. To accomplish this it must provide the total distribution feeder load to PYPOWER (bulk power system simulator) and receives from it the substation input voltage.
Simulates the thermodynamics and HVAC thermostat control for all residential buildings in the specified distribution feeder model. Provides thermodynamic state information to the Substation Agent to allow formation of real-time energy bids.
Simulates the production of the solar PV panels and their local controller (for the cases that include such devices).
Simulates the physics of the energy storage devices and the behavior of their local controllers.
- Substation Agent
Contains all the transactive agents for the residential customers. Using the current state of the individual customers’ residences (e.g. indoor air temperature) These agents form real-time energy bids for their respective customers and adjust HVAC thermostat setpoints based on the cleared price.
Aggregates all individual HVAC agents’ real-time energy bids to form a single bid to present to the wholesale real-time energy market.
- EnergyPlus
Simulates the thermodynamics of a multi-zone structure (an elementary school in this case)
Simulates the integrated controller of said structure
Communicates electrical load of said structure to GridLAB-D for its use in solving the powerflow of the distribution feeder model.
- PYPOWER
After collecting the load information from GridLAB-D (and scaling it up to a value representative of an entire node in the transmission model) solves the bulk power system power flow to define the nodal voltages, communicating the appropriate value to GridLAB-D.
Using the bid information from the generation natively represented in the bulk power system model and the price-responsive load bids provided by the Substation Agent, find the real-time energy price for each node the bulk power system (the LMP) by solving the optimal power flow problem to find the least-cost dispatch for generation and flexible load. Communicate the appropriate LMP to the Substation Agent.
Figure Fig. 33 is a sequence diagram showing the order of events and communication of information between the software entities.
Due to limitations in the load modeling provided by Energy+, some expected interactions are not included in this system model. Specifically:
The loads modeled internally in Energy+ are not responsive to voltage and thus the interaction between it and GridLAB-D is only one way: Energy+ just provides a real power load; GridLAB-D does not assume a power factor and the the Energy Plus Agent (which is providing the value via FNCS) does not assume one either.
The Energy Plus agent is only price responsive and does not provide a bid for real-time energy.
Software Execution
As is common in many analysis that utilize co-simulation, the SGIP1 analysis contains a relatively large number of executables, input, and output files. Though there are significant details in the Analysis Design Model showing the software components and some of the key data flows and interactions between them, it does not provide details of how the software is executed and interacts with each other. These details are provided below, focusing on the input and output files created and used by each executable.
Software Architecture Overview
Figure Fig. 34 provides the broadest view of the analysis execution. The central element is the “runSGIPn.sh” script which handles the launching of all individual co-simulation elements. To do this successfully, several input and configuration files need to be in place; some of these are distributed with the example and others are generated as a part of preparing for the analysis. Once the co-simulation is complete, two different post-processing scripts can be run to process and present that results.
Inherited Files
Figure Fig. 35 provides a simple list of files that are distributed with the analysis and are necessary inputs. The provenance of these files is not defined and thus this specific files should be treated as blessed for the purpose of the SGIP1 analysis.
prepare_cases.py
Figure Fig. 36 shows the process by which the co-simulation-specific files are generated. The weather agent uses a specially-formatted weather file that is generated by the “weathercsv” method in “TMY3toCSV.py”. After this completes the “glm_dict.py” script executes to create the GridLAB-D metadata JSON. Lastly, the “prep_substation.py” script runs to create co-simulation configuration files. “prepare_cases.py” does this for all the cases that the SGIP1 analysis supports.
runSGIPn.sh
Figure Fig. 37 shows series of executables launched to run the SGIP1 co-simulation analysis. All of the activity blocks denote a specific executable with all being run in parallel to enable co-simulation. Each executable has its own set of inputs and outputs that are required and generated (respectively). Though most of these inputs are files (as denoted by the file icon), a few are parameters that are hard-coded into this script (e.g. the EnergyPlus Agent). Some input files have file dependencies of their own and these are shown as arrows without the “<<flow>>” tag. The outputs generated by each executable generally consist of a log file and any data collected in a metrics file.
validation_plot.py
Figure Fig. 38 shows the inputs files generated by the co-simulation that are used to generate plots used to validate the correct operation of the co-simulation. TESP provides scripts for post-processing the metrics files produced by the simulation tools and these are used to create Python dictionaries which can be manipulated to produce the validation plots.
createAccountingTable.py
Figure Fig. 39 shows the input metrics files to used to calculate the final accounting table output from the metrics identified by the Valuation Model.
Data Collection
The data collection for TESP is handled in a largely standardized way. Each simulation tool produces an output dataset with key measurements. This data is typically stored in a JSON file (with an exception or two where the datasets are large and HDF5 is used). The specific data collected is defined in the metrics section of the TESP Design Reference.
The JSON data files are post-processed by Python scripts (one per simulation tool) to produce Python dictionaries that can then be queried to further post-process the data or used directly to create graphs, charts, tables or other presentations of the data from the analysis. Metadata files describing the models used in the analysis are also used when creating these presentations.
Running the Example
As shown in Table 4, the SGIP1 example is actually a set of five separate co-simulation runs. Performing each run takes somewhere around two hours (depending on the hardware) though they are entirely independent and thus can be run in parallel if sufficient computation resources are available. To avoid slowdowns due to swapping, it is recommended that each run be allocated 16Gb of memory.
To launch one of these runs, only a few simple commands are needed:
cd ~/tesp/examples/sgip1
python3 prepare_cases.py # Prepares all SGIP1 cases
# run and plot one of the cases
./runSGIP1b.sh
./runSGIP1b.sh
will return a command prompt with the co-simulation running in the background. To check how far along the co-simulation monitoring one of the output files is the most straight-forward way:
tail -f SGIP1b.csv
The first entry in every line of the file is the number of seconds in the co-simulation that have been completed thus far. The co-simulation is finished at 172800 seconds. After that is complete, a set of summary plots can be created with the following command:
python3 plots.py SGIP1b
Analysis Results - Model Validation
The graphs below were created by running validation_plots.py
(TODO: Update default path to match where the data will be) to validate the performance of the models in the co-simulation. Most of these plots involve comparisons across the cases evaluated in this study (see Table 4).
Analysis Results - Key Performance Metrics
The final results for the key performance metrics are presented below in Table 5 and Table 6. These tables are provided to help benchmark results.
Metric Description |
SGIP1a Day 1 |
SGIP1b Day 1 |
SGIP1c Day 1 |
SGIP1d Day 1 |
SGIP1e Day 1 |
---|---|---|---|---|---|
Wholesale electricity purchases for test feeder (MWh/d) |
1394 |
1363 |
1261 |
1159 |
1065 |
Wholesale electricity purchase cost for test feeder ($/day) |
$31,414.83 |
$33,992.28 |
$30,940.02 |
$27,869.27 |
$25,287.68 |
Total wholesale generation revenue ($/day) |
$213,441.28 |
$237,176.68 |
$230,705.91 |
$224,178.12 |
$218,903.29 |
Transmission and Distribution Losses (% of MWh generated) |
0.03 |
0.03 |
0.03 |
0.03 |
0.03 |
Average PV energy transacted (kWh/day) |
0.0 |
0.0 |
17.6 |
34.3 |
51.2 |
Average PV energy revenue ($/day) |
$0.00 |
$0.00 |
$127.65 |
$242.23 |
$353.86 |
Average ES energy transacted (kWh/day) |
0.00 |
0.00 |
0.68 |
0.98 |
0.88 |
Average ES energy net revenue |
$0.00 |
$0.00 |
$4.98 |
$7.84 |
$8.16 |
Total CO2 emissions (MT/day) |
0.70 |
0.79 |
0.78 |
0.76 |
0.75 |
Total SOx emissions (kg/day) |
0.01 |
0.01 |
0.01 |
0.01 |
0.01 |
Total NOx emissions (kg/day) |
0.05 |
0.05 |
0.05 |
0.05 |
0.05 |
Metric Description |
SGIP1a Day 2 |
SGIP1b Day 2 |
SGIP1c Day 2 |
SGIP1d Day 2 |
SGIP1e Day 2 |
---|---|---|---|---|---|
Wholesale electricity purchases for test feeder (MWh/d) |
1458 |
1421 |
1314 |
1213 |
1112 |
Wholesale electricity purchase cost for test feeder ($/day) |
$197,668.90 |
$162,838.08 |
$125,429.86 |
$95,077.07 |
$70,833.33 |
Total wholesale generation revenue ($/day) |
$1,219,691.44 |
$1,065,540.53 |
$884,707.64 |
$724,209.63 |
$581,815.57 |
Transmission and Distribution Losses (% of MWh generated) |
0.03 |
0.03 |
0.03 |
0.03 |
0.03 |
Average PV energy transacted (kWh/day) |
0.0 |
0.0 |
18.5 |
36.0 |
53.8 |
Average PV energy revenue ($/day) |
$0.00 |
$0.00 |
$667.30 |
$1,034.39 |
$1,188.40 |
Average ES energy transacted (kWh/day) |
0.00 |
0.00 |
0.08 |
0.09 |
0.02 |
Average ES energy net revenue |
$0.00 |
$0.00 |
$4.77 |
$8.56 |
$11.76 |
Total CO2 emissions (MT/day) |
3.61 |
3.21 |
2.72 |
2.27 |
1.86 |
Total SOx emissions (kg/day) |
0.03 |
0.03 |
0.02 |
0.02 |
0.02 |
Total NOx emissions (kg/day) |
0.23 |
0.21 |
0.17 |
0.15 |
0.12 |
The following graphs were created by running createAccountingTable.py
and plotAccountingTable.py
, which calls the function lca_standard_graphs.py
. These plots involve comparisons across the cases evaluated in this study (see Table 5 and Table 6). As shown in :numref: tbl_sgip1, the cases a through e correspond to a growth model of progressive adoption of transactive energy. Case a is no transactive energy and case b is the control year with transactive. Cases c through e account for increased adoption of PV and energy storage systems. These cases are analyzed over two days of operation, where the first day is a control with regular operations, and the second experiences the trip of a generator. These graphs convey the respective results from the simulation.
The wholesale energy purchased at the test feeder reduces with the growth model, however with the generator trip on day two, energy demand increases slightly.
The cost of wholesale energy decreases slightly on day one with adoption of PV and energy storage. This decrease in cost is more dramatic on the second day with the generator trip.
The total revenue to the generators is much more on the second day with the generator failure, although this revenue reduces with the growth model.
The average PV energy transacted in the system increases with adoption, and this amount progressively diverges with the generator trip on the second day.
The average revenue to households with PV markedly increases on the second day with the generator trip.
The average energy storage energy transacted is much larger on day one compared with day two. The impact of the generator trip is nonlinear with increasing adoption of storage.
Regardless of the average energy transacted, the average revenue to households is much larger on day two.
The following graph dispays the total daily emissions by greenhouse gas type (CO2 is in units of MT, or 1000 kg). Between case a (no transactive) and case b (transactive year 0), the CO2 emissions jump by 100 MT in day one. The emissions in day two increase between these two cases as well by about half as much. Across all cases, the total emissions on day one are higher with transactive compared to without. On day two, the growth model cases experience less total emissions than the non-transactive case.
Social Welfare: