Analysis Tools: Transmission Analysis Module

Introduction

Transmission Analysis tool (TAT) is an incorporated module of Deep-Edit software since version 3.3. TAT allows the user with transmission system analysis tools for a given operating condition. TAT module in its version 3.3 incorporates a transmission detector congestion that estimates:

1. Congestion frequency in transmission lines and transformers in a given power system.

2. Theoretical quantification of affected agents in a competitive spot market (with bilateral financial contracts).

Methodology

From a given dispatch solution, product of an operational simulation of power systems, obtain a list of lines and transformers that show signs of congestion. Congestion is defined as “operating conditions in which active transmission limits are detected”. It means, all branches (AC transmission lines and 2-wind transformers) that represent a “bottleneck” for the generated power to “reach” the consumption nodes at minimum cost.

The commonly Congestion signals are:

• Technical: Transmission line charge level, i.e., of the charge margin of a line in a given operating condition.

• Economical: Difference between marginal cost between buses excede a tolerance.

The 8 steps algorithm for line congestion detection and affected contractual market participants valuation, is summarized in the following figure:

Figure 103: Data scheme and Transmission Analysis Tools outputs

Details of every step of congestion detection algorithm are explained next.

Marginal Cost Differences

This step consists in checking, for each of the lines, for each of the time periods, for each of the hydrology’s samples, if the difference between the marginal cost of the emitting bar “i” and the receiving bar “k (line or transformer end) is greater than a specified tolerance. Specifically, detection occurs when, for any of the branches between bars “i”, “k”, one of the following is true:

1. Absolute difference exceeds tolerance: or,

2. Relative difference exceeds tolerance:

The product of the difference of the marginal costs between busbars (at the end of the transmission line), multiplied by the flow of active power of the same is known as “tariff income”.

Transmission Line's Loading Level

This step consists in checking, for each of the lines, for each of the time periods, for each of the hydrology’s samples, if the difference between the maximum active power limit (which can be given by a thermal limit, protections, TTCC, stability or other) and the instantaneous flow, exceeds a given tolerance. In other words, the loading level exceeds a given tolerance:

Synthetic Ranking

A ranking is established based on a synthetic, dimensionless index, calculated using following linear formula:

Where:

• a, b, c and d are configurable by user.

• TRL are theoretic losses on injection balances and bilateral financial contracts retired (Total Revenue Losses).

Results show the following information:

Column	Calculation Procedure	Description
Line	If any ΔCmgb, ΔRCmgb or ΔLoadb exceed user’s defined tolerance.	Full name of lines and transformers with congestion (including name of emitting and receiving bars as defined in the schematic).
Probability	, Where: t=Congestion period T=Total time periods (blocks) H=Total hydrology samples	It is a frequency indicator. If H = 1 (deterministic case) then it corresponds to the time portion of the evaluation horizon in which the line is congested.
Ranking	Where: a, b, c and d are configurable by user. TRL are theoretic losses on injection balances and bilateral financial contract retired (Total Revenue Losses).	A synthetic customizable “index” (i) indicator is established, from the main input trends to measure the “depth” of the congestion.

Affected Market Agents Estimation

This is an algorithm that balances injections and withdrawals. For each of the bilateral financial contracts, the balance of injections and withdrawals valued at the LMP (Spot Market Revenue) is calculated and compared with a theoretical balance. The theoretical balance is the one that results from a valuation of injections and withdrawal using marginal cost values per bar if there were no congestion.

Calculating Spot Market Revenue

Spot Market Revenue to “i” (SMRi) contract is calculated as total entrance:

i.e., Spot Market Revenue is calculated from the supplier's point of view. Note that SRMi> 0 indicates gains, while SRMi <0 indicates losses. Also note that it is a net balance in the spot market, it does not represent gains or losses in the final balance of the companies, since it does not include production costs or income (prices) from contracts.

Calculation of Theoretical Financial Balance (Unconstrained Market Revenue)

An alternative measure the impact of "lifting" (alleviating) a congestion would be to adjust the new transmission limit of one or more lines (for example, expanding the transmission system or installing SPS equipment) and running a new operational simulation. From the point of view of central planning, the expansion of the transmission system is beneficial for the system if the operating cost, after adjusting the limit, plus the investment value is less than the original operating cost.

From the point of view of competitive markets, the expansion of the transmission system would be beneficial for some of the market agents with bilateral contracts if it is fulfilled that:

SMR_i^T − SMR_i > Inv

Where SMR_i^T is the financial spot market balance after the transmission expansion at investment cost Inv. Note that SMR is dependent on prices (marginal costs in injection and withdrawal bars) and quantities (G and D). Then, a redispatch of the system would imply modifications in both variables of the SMR_i^T.

Deep-Edit uses an approach that significantly reduces the computational complexity of this procedure (which may require several extra hours of calculation when solving complex np-complete mathematical problems of Unit Commitment and / or Hydro-thermal Coordination), delivering, alternatively, approximate signals of the SMR_i^T. These signals can be directly visualized in the Transmission Analysis result interface and the quantifiable economic effects can be included in the ranking index formula.

Marginal Cost Without Congestion Estimation

There are two main transmission system effects on power system operation:

1. Introduce ohms losses (more generation is required).

2. Power transfer limitations.

Examining the KKT conditions of the nodal power balance restrictions of an economic dispatch with transmission losses and restrictions and also assuming that the economic dispatch is far from the optimal “uninodal” only due to the 2 previous transmission effects, the following marginal cost decomposition is given at the optimal solution:

Where,

λ	System Marginal Cost (Lambda)
	Incremental system losses for an incremental injection at the busbar “i”
μb	Dual variable of the Flow constraint of line “b”
fb	Line “b” active power flow

Then, if it is desired to decompose the marginal cost into its 3 components, which is consistent with the previous assumption:

Cmg_i = λ + β_i + γ_i

Where,

Given that we want to find the unconstrained marginal costs (“not affected” to the congestion component), that is, with γ_i = 0, the marginal cost without congestion, which we will call theoretical marginal cost Cmg_i^T complies with the following formulation:

If the slack busbar marginal cost is assumed to be equal to the λ of the system, then the marginal cost without congestion is stated as:

Where pf_i is commonly known as the penalty factor. The calculation of penalty factors does not require the redispatch of the system and it can be calculated by simple inspection of the nodal impedance matrix and the operating point. The most common formula for calculating the penalty factors, from the quadratic losses’ formulation, is the following:

Where,

rb	Line “b” resistance
fb	Dual variable of the line “b” Flow limit
	It is the sensitivity vector of injection "i" on the line "b" power flow. Also known as the shift factor or "A" or "GSDF" factor.

Considering the previous theoretical foundations, DeepEdit calculates the theorical marginal costs (or marginal costs without congestion components) as shown in next pseudo-code.

Figure 104: Theoretical Marginal Cost Algorithm

Finally, the theoretical balance (unconstrained spot market revenue SMR_i^T is calculated as follows:

That is, the theoretical balance for contract "i" is calculated with the theoretical marginal costs only if it is satisfied that the relative difference between the marginal costs of any of the supply and consumption bars exceeds a tolerance established by the user.

Note that the meaning of using a relative tolerance as a point to determine the use of the theoretical marginal cost is explained from the assumption that the contract "i" between supplier and consumption will be subject to congestion only if the injection and withdrawal points are at different sides of the congested branch (since Tol_Rel is the same tolerance used to detect congestions due to price differences).

Calculating Potential Losses and affected Agents

Theoretical Losses ΔLoss_i are calculated just as difference between the theoretical (unconstrained) and real incomes:

ΔLoss_i = SMR_i^T − SMR_i

Then, for each bilateral financial contract, time period (and hydrology samples) with congestion, affected participants are determined as follows:

Technical Specification

The TAT module technical requirements are the same needed to use Deep-Edit tool. Notwithstanding the foregoing, the following summarizes specific technical specification sheet of the TAT module:

• Algorithm developed on JAVA 11 – 64 bits.

• Management of dispatch information and storage in MS Access databases (JODBC) and xml files.

• TAT can be executed in personal computer or laptop. Tested on Windows 10 64bits.

• Memory Requirement Examples:

  • 200 nodes (3 years and 50 hydro samples) ≈ 500MB.

  • 150 nodes (1 year, deterministic) ≤ 100MB

Uses of TAT:

• SPS opportunities and/or transmission system expansion for a given and quickly way.

• Users can analyze the transmission system congestion every time ISO publishes its operational results (eg. Daily, weekly, long term, etc),

• Since scenarios can be loaded unilinear, it is easy to perform sensitivity analysis by running power flows (or one of the many other tools in Deep-Edit).

• Affected participants are directly drawn from financial contract information.

• Using the line limit information (source), the most suitable type of SPS can be associated to alleviate congestion.

• Graphic User Interface: Easy to use and configure. Export report Possibility to Excel. “Tie” graphics (Duration curve), customizable ranking, configurable parameters.

Study Case Structure

Study case requires two data sources:

1. Schematic with Unilinear System: Contains topological information of the system under study.

2. TPDB3.3 database: Contains the data and the dispatch solution (operational details).

Figure 105: Dataflow and outputs for the Transmission Analysis Tool

Figure 105 shows the data sources and output interfaces of the analysis tool. Note that it is also shown the (optional) user’s defined xml database with transmission limit descriptive information This database is unique, and it can be shared by all steady cases or another Deep-Edit application.

Results produced by the tool are:

1. DeepEdit Interface: Forms and windows:

   • Congestion Summary: Ubication, general information, frequency, and impact depth (provided by the index).

   • Congestion Details: Congestion detection details per period (and Hydrology sample).

   • Spot Market Balance: Spot Market Balance and most-affected market agents (provided by the defined bilateral contracts).

   • Transmission flow duration curves: load duration charts (“tie” charts) and chronological power flow in congested lines.

2. Report File: Write results on folder with congestion detailed information (default to . DEEPEDIT_RESULTS_FOLDER/ TACongestion.csv).

NOTE: It is important to highlight that the results in DeepEdit’s forms (interface) are exportable to MS Excel or MS Word through clipboard operations (copy / paste).

Preparing Study Cases

It is important to note that Deep-Edit has a dedicated GUI to prepare all the required input data. The data for each case study is essentially prepared in three steps:

1. Prepare the schematic using the Deep-Edit interface:

   • Network editor: Generators, lines, demands, transformers. See section “Network Editor” for details of the network editor and the basic components of the schematic.

   • Market editor: Suppliers, consumers, bilateral contracts. See section "Market Editor" of this manual.

2. Fill the database by importing the dispatch results from external runs (input and output files) of PLEXOS, PLP or PLP to the TPDB using the import tool. This step is performed automatically by DeepEdit. It does NOT require that the TPDB database is “manually populated” by the user. The user will need to (simply) specify the full path to the dispatch files. Section Analysis Tools configuration provides further details.

3. Validation: Since both data sources (schematic and dispatch data in TPDB), have to belong to the same system (identical elements of both network and market), Deep-Edit provides a tool that allows the user to validate the schematic and create a report with all the "mismatches" found. See section “Synchronize (validate) the schematic with the dispatch database” in “Analysis Tools configuration”.

Preparing Analysis Tools

Load Schematic from Disk

The first step to use the transmission analysis tool is to load (open) the schematic of the case study. In this case, it is done through the Open File option.

Figure 106: Open existing schematic

It is mandatory that the names of the transmission lines (and transformers) and those from the dispatch files be consistent, otherwise name errors may be observed, as described in the section “Synchronize (validate) the schematic with the dispatch database”.

Figure 107: Loaded schematic1

For more information on how to open study cases in DeepEdit, see section “Getting Started” on User Guide.

Financial Information

This section allows configuring the contractual relationships between Suppliers and Consumers, in addition to the options of the Brokers and the System Operators. For more information on how to use this tool, see the “Market Editor” section of the User Manual.

Using Transmission Congestion Analysis

This DeepEdit toolbox can be called from the Ribbon’s “Analysis Tool” menu.

Figure 108: Transmission Congestion Analysis Execution

Analysis Tools configuration

At first glance, it is necessary to configure the simulation parameters. To do this, click on the "Options" button in the window and a window (with 5 tabs) will be displayed, which are described below:

• Horizon: allows you to control the period to be subjected to the

congestion analysis.

• Options: allows you to configure the parameters that define

congestion: Tolerances.

• Database: allows you to configure the source of the data (full path

to the TPDB database).

• Input Files: allows you to configure the reading and loading of

external dispatches.

• Ranking: configuration of the personalized congestion ranking.

Each of the tabs is explained in detail below with illustrative examples.

CONFIGURATION OF CONGESTION DETECTOR OPTIONS (HORIZON, TOLERANCES AND REPORT)

The first (and easiest) step in running the TAT is the optional horizon setting. In Figure 109, the periods available from the preloaded database are shown in blue and with arrows, where the user can choose the range of dates they want to analyze. This step is optional. Only required if it is required to analyze a “portion” of the total data stored in the database.

Note: It is important to note that the evaluation horizon is loaded by default from the TPDB dispatch database. It is NOT necessary to configure "manually" in each execution.

Figure 109: Configuration Option: handling simulation horizon

Figure 110 shows the global settings and congestion criteria used by the tool. The first parameter establishes the load tolerance of the line and is characterized with a value in per unit, where the specified value corresponds to the value from which it will be considered as a line with congestion. The second and third parameters fix the differences of the marginal costs between 2 busbars where the tolerance represents the difference in absolute value and in relative absolute value. These criteria are considered independently during the analysis, that is, that line that meets any of the 3 previous criteria will be considered “congested”.

Figure 110: Configuration Option: Defining congestion parameters

Data Origin

Figure 111: TPDB dispatch storage database parameters

Figure 111 shows the database configuration options. In case of requiring greater security regarding access to information, user permissions can be configured providing a password, or the database can be kept on a network server. DeepEdit is distributed with a TPDB database (located in the default database path) configured with free local access (that is, without username or password).

Synchronize (validate) the schematic with the dispatch database

It is relevant that the schematic and dispatch data refer to the same power system. For this reason, TAT provides a tool that checks and reports the compatibility of the schematic nomenclature with respect to the nomenclature in the dispatch database and reports all differences. This optional step allows the user to inquire about the compatibility between the schematic and the TPDB database before running the congestion analysis.

1. Check that there is data in TPDB for the schematic network objects.

1. Check that the objects with data in TPDB exist in the schematic.

2. Disables (inservice = false) all those network elements in the schematic that do not have any data in the TPDB database.

3. DO NOT create new objects on the schematic. He only notices (writes in report) its non-existence in schematic.

To run the synchronizer, simply click on the "Update Sch" button (see Figure 72)

Figure 112: Example report schematic compatibility with TPDB dispatch database

This report is automatically opened with DeepEdit's ZFileViewer (DeepEdit's native text file viewer) and is also stored in the DEEPEDIT_FOLDER / results / TADB-schematic.log folder.

Considering the automatic updating of the schematic, it is recommended to have redundant elements and not to delete objects from the schematic each time the user updates it manually (e.g. Lines with obsolete names or recent topological changes).

Load Dispatch Data

This section explains the process of storing data into the TPDB database. TAT incorporates 3 ad-hoc modules specifically developed to open, read and extract relevant dispatch information from the following dispatch software.

Figure 113: Dispatch file importer configuration with input databases

To start the data import process, the user needs to follow this sequence:

1. Select the type of dispatch software.

2. Full path to the folder containing the dispatch software case input files.

3. Full path to the folder containing the dispatch software case output files.

4. Name of the dispatch software case output database. (PLEXOS only).

5. Click on the “Update TA-Database” button to start the migration process

PERFORMANCE NOTES:

• This process may require handling very large files and traffic large information volumes.

• This process is not designed for maximum efficiency but for maximum data volume so it can handle very large files, at the cost of running in high processing times.

• JDBC connections can result in high execution times. The “typical” dispatch cases from PLP software medium-term programming can take up to 15 minutes.

Deep-Editor Transmission Pricing database (TPDB)

TPDB database is that structure for storing dispatch data over time. Considering the volume of data that must be handled to store dispatch information, DeepEdit v3.3 restructures the dispatch storage system called TPDB (from the acronym of the first tool that required dispatch data Transmission Pricing Database). The design requirements arise from the following shortcoming:

• Need to store a larger volume of data. TAT requires storing input data such as transmission limits, maintenance, demand, as well as new outputs such as marginal costs and power flows. The storage volume was unmanageable for a non-standardized database.

• The previous TPDB version assumed constant periods (blocks of duration): 2 blocks per month. The dispatch information that TAT handles requires considering time-varying blocks (i.e., each block of different duration in hours).

• The previous TPDB version did not have a standardized design: efficiency, information security (integrality relations), file size and query design.

This new standardized scheme is shown in Figure 114. Similarly, the original TPDB design is shown in Figure 115.

Figure 114: Relational schema TPDB database version 3.3 (For Deep-Edit version 3.3 or higher)

Figure 115: Original relational schema TPDB database (For Deep-Edit older versions)

Index Configuration (Ranking)

The table presented in the "Ranking" tab of the options GUI allows the user (see Figure 116) to customize the coefficients for calculating the custom congestion ranking index. It is suggested to see the theoretical background in the "Synthetic Ranking" section of the "Metodology" section.

Figure 116: Option showing the coefficients to be applied to the ranking according to the different criteria

In the case of Figure 116, the ranking index “I” is calculated by the following linear formula:

Congestion Detector Calculation [Analysis Tools]

Clicking the "Execute" button in the main window (see Figure 117) starts the calculation algorithm:

• Validate schematic.

• Read dispatch data from database.

• Calculate marginal cost differences.

• Calculate load levels of lines and transformers.

• Calculate financial balance per contract.

• Calculate theoretical financial balance.

• Estimate affected market agents.

• Presentation of results forms and output file writing.

Please refer to the Methodology section for further details of the algorithm and its assumptions.

Figure 117: Option that allows to run the Transmission Congestion Analysis tool according to the options specified above

TAT implements a new progress window as shown in Figure 118.

NOTES:

• TAT is a process running in a separate thread (i.e., it does not block the operation of the windows). However, it does not implement a pause or abrupt termination method. The user must wait for its complete execution to work with the TAT or return to the schematic.

• Closing the progress window does NOT stop the execution. Once closed, it is not displayed again for the remainder of the run. However, progress and error messages are printed independently in the Deep-Edit output console ("Output" tab).

Figure 118: Calculation stage of the TAT tool

Results Visualization

The results provided by the TAT are as follows:

• Congestion summary: General information on location, frequency, and impact.

• Congestion details: Detail by period (and Hydrology) of the congestion reason(s).

• Balance: Information by contracts of the affected agents and their estimate of theoretical (economic) losses.

• Balance Detail: Details of frequency, depth, and limitation ratio.

• Flow duration curves: Duration graph (or tie graphs) of power flows for lines showing congestion.

Main Result Form

The main results window displays the congested lines along with their frequency (Probabiity column) and impact (determined by the customizable index in the ranking column).

Figure 119: Results display: TAT main window

The sub windows (or dependent forms) show details of the line showing congestion. The display process is very simple:

1. The user must select the line from the list of congested lines (only one).

2. Click on any of the 3 detail buttons.

Details of these sub windows are described below.

Line Usage (Flow) Visualization

The flow duration curves show in decreasing order (from highest to lowest along the x-axis) the flows on the selected line.

Note: This graph shows ALL flow values for the lines, including those periods of non-congestion.

Figure 120: Results display: Show flow duration curves

Spot Market Financials

This subform shows, for the congestion periods of the selected line, a summary of all the contracts that may be affected by the congestion and an economic valuation of the impact on the affected market agents (see details in the "Methodology" section of the TAT).

Figure 121: Results display: Balance sheet window for all congestion periods of the selected line

GUI Details

This window displays:

• Time: Periods (time blocks or stages) where congestion was detected.

• Sample: Hydrology (or stochastic sample) where congestion was detected.

• Reason: Reasons for the congestion. Possible values are:

  • BranchLoadMargin: By line load level (exceeding tolerance).

  • MarginalDiff: For difference between marginal costs at the ends greater than the tolerance.

• Value: Congestion value. Values are presented in pu (dimensionless).

• Limit Description: Limitation ratio from limitation database.

Figure 122: Results display: Congestion details

From this window, two visualization tools can be executed:

• Detailed financial balance ("Show Balance" button).

• Load scenario (dispatch) in unilinear ("Load Scenario" button).

  Both are described below.

Detailed Spot Market Balance

Shows the filtered financial balance for the selected block (period) and hydrology. See explanation and window details in the "Financial Balances" section.

Load dispatch to Schematic

This is a tool for updating and loading the dispatch to the unilinear elements. It is recommended for those cases that require more detailed analysis, such as performing power flows at certain sensitivities. Since a power flow solution is loaded, visualizations are available (see simulation animation menu).

This process performs the following actions automatically:

1. Queries the TPDB database and extracts the dispatch information for the selected period and hydrology.

2. It updates in the schematic:

• Pini: Initial demand.

• P0: PV and PQ busbar generation.

• P12: Power flows on the line from receiver to transmitter.

• spotp : All busbar’s Locational marginal price.

• Inservice: Deactivates lines with maintenance, demands without consumption and generators with P0 = 0MW.

Figure 123: Results display: Load scenario (dispatch) in unilinear

Future Developments

Future developments in the TAT module include the following work:

• Analysis (filtering) of contracts affected by transmission system usage: that is, making use of the GGDF and GLDF factors to determine whether the injection and withdrawal points of each contract are affected by congestion (they are topologically located at opposite ends of the congested lines). TAT version 3.3 determines whether the contract is affected (i.e., need to calculate notional marginal costs and unconstrained revenue) if the difference in marginal costs on either bus is greater than the relative congestion tolerance.

• Accuracy of the theoretical balance calculation (Unconstrained Market Revenue)4:

  • The theoretical balance is obtained from a redispatch.

  • Normal execution.

  • Congestion analysis.

  • Relax dynamic limits.

  • Re-execute dispatch (external software).

  • Accurate SPS profit calculation.

1. Some schematics load with the default’s zoom level. Therefore, if the use do not see the diagram in the DeepEdit viewer, use the mouse wheel to control the zoom level or use the “Overview” tab to locate the viewer on the components area.↩︎

2. Transmission Limits can be defined as:

   • Line.Export Limit and Line.Import Limit in mdb by period.

   • Line.Export Limit and Line.Import Limit in the mdb by daily summary.

   • "Name-band-in-columns" type csv files.↩︎

3. It requires external software to perform the new operational simulation. DeepEdit will perform the case preparation with relaxed limits and calculate the post-simulation profit.↩︎