Program Operation Manual Del PSS

PSS®E 34.
2
Program Operation Manual
April 2017
Siemens Industry, Inc.

Siemens Power Technologies International
400 State Street, PO Box 1058
Schenectady, NY 12301-1058 USA
+1 518-395-5000
www.siemens.com/power-technologies
Table of Contents
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xli
Preface
Contacting Siemens PTI for Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Submitting Bug Reports and Feature Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Chapter 1 - Overview
PSS®E Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
PSS®E Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
Extending PSS®E with User DLLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
PSS®E Support for Building User DLLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
1.4.1 COMPILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
1.4.2 CLOAD4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
1.4.3 CreateUsrDll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
1.4.4 CLIPLU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
1.4.5 CLPSSUSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
1.4.6 DSUSR Visual Studio solution file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
To use the DSUSR solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Common Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Chapter 2 - File System

Directories and Files Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1
The PSS®E Working Case and Temporary Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
File Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
2.3.1 Input Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4
2.3.2 Saved Case and Snapshot Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6
2.3.3 Output Listing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7
2.3.4 Channel Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7
2.3.5 Response Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7
2.3.6 PSEB and PSAS Command Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
2.3.7 IPLAN Program Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
2.3.8 Python Program Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
2.3.9 PSS®E Options Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
2.3.10 Results Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9
2.3.11 Temporary Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9
PSS®E Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9
2.4.1 File Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9
2.4.2 Specifying Filenames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15
All material contained in this documentation is proprietary to Siemens Industry, Inc., Siemens Power Technologies International.
i
Creating Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

2.5.1 Via a Text Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
2.5.2 Via Format Conversion Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
2.5.3 Via PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Files Created By PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
File System Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
2.7.1 Multiple Working Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
2.7.2 PSS®E Directory Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
2.7.3 File Search Path Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
2.7.4 Temporary Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
2.7.5 Reserved Filenames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
2.7.6 Master Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
2.7.7 Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Deleting Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
File Usage Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
Chapter 3 - Startup
Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Starting PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.2.1 Startup Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
3.3.1 Specifying the Maximum Number of Buses . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
3.3.2 Setting Program Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
3.3.3 Program Run-Time Option Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Saved Case Specific Option Settings. . . . . . . . . . . . . . . . . . . . . . . . 3-7
User Specified Option Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Installation Dependent Option Settings . . . . . . . . . . . . . . . . . . . . . 3-11
Startup Parameter Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
3.4.1 WINDOWS.PRM Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
3.4.2 INI Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Chapter 4 - Operating Modes

How to Approach PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Activity Selection ............................................................ 4-2
4.2.1 GUI Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
4.2.2 Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.2.3 Automation Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Interruption of PSS®E by the User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Virtual Output Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
4.4.1 User-Written Dynamics Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
4.4.2 Graphical Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Line Mode Output Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Extended Modeling in Dynamics Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
ii
Subsystem Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8

Windows Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Subsystem Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Subsystem Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
Loading the Connection Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
Activity Suffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
Chapter 5 - Power Flow Data Entry, Modification, and Display Activities

Retrieving a Power Flow Saved Case File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1
Activity CASE
Reading Power Flow Raw Data into the Working Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3
Activity READ
5.2.1 Power Flow Raw Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4
5.2.2 Operation of Activity READ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4
Bus Names Input Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Bus Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Plant and Machine Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 5-5
Load Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Fixed Shunt Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Induction Machine Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 5-5
Branch Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Transformer Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
5.2.3 Change Case Data in a Standard READ . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
Merging Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
5.2.4 Subsystem READ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7
5.2.5 Reading Power Flow Raw Data Files Created by Previous Releases of PSS®E
5-8
Reading Power Flow Data Additions from the Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9
Activity TREA
Adding Machine Impedance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10
Activity MCRE
5.4.1 Machine Impedance Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10
5.4.2 Operation of Activity MCRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
5.4.3 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12
Reading Sequence Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13
Activity RESQ
5.5.1 Sequence Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14
5.5.2 Operation of Activity RESQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14
5.5.3 Transformers in the Zero Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14
5.5.4 Auto Transformer Equivalent Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15
5.5.5 Two Winding Transformer Zero Sequence Network Diagrams and Connection
Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16
CC=1 and CC=11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
CC=2 and CC=12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
CC=3 and CC=13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
iii
CC=4 and CC=14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20

CC=5 and CC=15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
CC=6 and CC=16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
CC=7 and CC=17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
CC=8 and CC=18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
CC=9 and CC=19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
CC=20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28
CC=21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
CC=22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
5.5.6 Three Winding Transformer Zero Sequence Network Diagrams and Connection
Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
CC=1 and CC=11 (511) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32
CC=2 and CC=12 (113) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
CC=3 and CC=13 (313) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
CC=4 and CC=14 (333) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35
CC=5 and CC=15 (121) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36
CC=6 and CC=16 (111) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37
CC=17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38
CC=18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
Reading Transactions Raw Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40
Activity REMM
5.6.1 Transactions Raw Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40
Participation Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40
Transaction Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41
5.6.2 Operation of Activity REMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42
5.6.3 Implications of the Participation Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42
Reading / Changing Power Flow Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43
Activity RDCH
5.7.1 Operation of Activity RDCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44
5.7.2 Reading RDCH Data Files Created by Previous Releases of PSS®E . . . . 5-45
5.7.3 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45
Producing Power Flow and Fault Analysis Data Checking Reports . . . . . . . . . . . . . . . . . . . . . 5-46
Activity PFCHK
Activity SCCHK
Changing Service Status and Power Flow Parametric Data . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47
Activity CHNG
5.9.1 Equipment Status Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
5.9.2 Solution Parameter Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-50
5.9.3 Interarea Transfer Data Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-50
Scaling Loads, Generators, and/or Shunts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-50
Activity SCAL
5.10.1 Operation of Activity SCAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-52
5.10.2 Scaling Fixed Shunts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-52
5.10.3 Scaling Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-53
5.10.4 Scaling Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-53
5.10.5 Scaling Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-54
iv
Electrically Disconnecting a Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-56

Activity DSCN
Electrically Reconnecting a Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-57
Activity RECN
Outage "Stalled" and "Tripped" Induction Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-59
Activity ImOutage
Removing Specified Buses and Connected Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-60
Activity EXTR
Deleting Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-61
Activity PURG
5.15.1 Removing Individual Equipment Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-62
5.15.2 Removing Outaged Equipment in a Subsystem . . . . . . . . . . . . . . . . . . . . . .5-63
5.15.3 Example of Activity PURG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-64
Joining Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-65
Activity JOIN
5.16.1 Operation of Activity JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-67
5.16.2 Example Progress Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-68
Splitting Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-69
Activity SPLT
5.17.1 Operation of Activity SPLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-69
5.17.2 Example of Activity SPLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-70
Tapping a Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-71
Activity LTAP
Changing Equipment Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-72
Activity MBID
Moving Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-74
Activity MOVE
5.20.1 Operation of Activity MOVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-75
Renumbering Buses in Auxiliary Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-77
Activity RNFI
5.21.1 Bus Renumbering Translation Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-78
5.21.2 Operation of Activity RNFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-78
Changing Owner Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-80
Activity OWNM
5.22.1 Operation of Activity OWNM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-80
Changing Owner Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-83
Activity OWNM
5.23.1 Operation of Activity OWNM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-83
v

Changing Zone Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-86
Activity ZONM
Activity LDZO
5.24.1 Operation of Activity ZONM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-87
Reading Sequence Data Additions from the Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-87
Activity TRSQ
Changing Sequence Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-88
Activity SQCH
Checking Branch Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-89
Activity BRCH
5.27.1 Branch Parameter Checks Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-90
5.27.2 Operation of Activity BRCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-92
Check for Islands Without a Swing Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-93
Activity TREE
5.28.1 Operation of Activity TREE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-94
Checking/Changing Controlled Bus Scheduled Voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-95
Activity CNTB
5.29.1 Operation of Activity CNTB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-96
Checking/Changing Transformer Adjustment Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-99
Activity TPCH
5.30.1 Operation of Activity TPCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-100
5.30.2 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-102
Changing Adjustment Enable Flags of Transformers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-102
Activity TFLG
5.31.1 Operation of Activity TFLG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-103
Performing Unit Commitment and Economic Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-103
Activity ECDI
5.32.1 Economic Dispatch Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-105
Standard Record Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-105
Supplementary Units of Dispatch Groups . . . . . . . . . . . . . . . . . . 5-106
5.32.2 Operation of Activity ECDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-107
5.32.3 Viewing Economic Dispatch Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-110
5.32.4 Dispatch Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-110
Displaying the Long Case Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-112
Activity PRTI
Managing Case Titles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-113
vi
5.34.1 Importing a Long Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-114

Activity RETI
5.34.2 Changing the Long Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-115
Activity CHTI
5.34.3 Editing the Two-Line Case Title or the Long Title . . . . . . . . . . . . . . . . . . . .5-116
Activity EDTR
Counting System Components in the Working Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-116
Activity SIZE
Listing Unused Bus Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-119
Activity BUSN
Displaying Power Flow Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-121
Activity LIST
5.37.1 Operation of Activity LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-121
5.37.2 Listing Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-122
Case Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-122
Bus Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-126
Load Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-126
Plant Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-126
Generator Unit Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-126
Induction Machine Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-127
Fixed Bus Shunt Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-127
Switched Shunt Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-127
Branch Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-128
Line Shunt Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-128
Two-Winding Transformer Data . . . . . . . . . . . . . . . . . . . . . . . . . . 5-128
Three-Winding Transformer Data . . . . . . . . . . . . . . . . . . . . . . . . . 5-129
Transformer Impedance Correction Table Data . . . . . . . . . . . . . . 5-130
Multi-Section Line Grouping Data . . . . . . . . . . . . . . . . . . . . . . . . . 5-130
DC Line Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-131
Area Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-131
Interarea Transfer Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-131
Zone Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-132
Owner Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-132
FACTS Device Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-132
GNE Device Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-132
Listing Components of a Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-133
Activity EXAM
5.38.1 Operation of Activity EXAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-133
5.38.2 Listing Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-133
Listing Buses in Alphabetical Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-134
Activity ALPH
Listing Buses using Partial Bus Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-135
Activity FIND
Listing Bus Shunts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-137
Activity SHNT
vii
Listing Outaged Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-138

Activity OUTS
Listing Sequence Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-140
Activity SQLI
5.43.1 Operation of Activity SQLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-140
5.43.2 Listing Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-141
Load Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-141
Generator Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-141
Induction Machine Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-142
Fixed Shunt Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-142
Switched Shunt Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-142
Non-Transformer Branch Data . . . . . . . . . . . . . . . . . . . . . . . . . . 5-143
Line Shunt Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-143
Two-Winding Transformer Data . . . . . . . . . . . . . . . . . . . . . . . . . . 5-143
Three-Winding Transformer Data. . . . . . . . . . . . . . . . . . . . . . . . . 5-144
Mutual Impedance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-144
Listing Sequence Data for a Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-145
Activity SQEX
5.44.1 Operation of Activity SQEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-145
5.44.2 Listing Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-146
Creating a Saved Case File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-147
Activity SAVE
Bus Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-148
Activity BSNM
5.46.1 Renumbering Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-149
All Buses Without Area Blocking . . . . . . . . . . . . . . . . . . . . . . . . . 5-149
All Buses With Area Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-149
Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-149
Bus Number to Bus Number Translation . . . . . . . . . . . . . . . . . . . 5-150
Bus Name to Bus Number Translation . . . . . . . . . . . . . . . . . . . . . 5-150
Bus Number Packing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-151
5.46.2 Output Tabulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-151
5.46.3 Examples of Activity BSNM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-152
Saving the Working Case in an IEEE Common Format File . . . . . . . . . . . . . . . . . . . . . . . . . 5-153
Activity RWCM
Saving Machine Impedance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-155
Activity RWMA
5.48.1 Operation of Activity RWMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-156
Transfer Machine Data to Another Case . . . . . . . . . . . . . . . . . . . 5-156
Stability Data in IEEE Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-157
Machine Status Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 5-157
Split Fractions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-157
Creating a Power Flow Raw Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-158
Activity RAWD
viii
5.49.1 Operation of Activity RAWD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-160

5.49.2 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-161
Creating a Sequence Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-162
Activity RWSQ
5.50.1 Operation of Activity RWSQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-164
Creating a Transactions Raw Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-165
Activity RWMM
5.51.1 Operation of Activity RWMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-165
Chapter 6 - Power Flow Solution Activity Descriptions

About Power Flow Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1
Power Flow Solution Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2
6.2.1 Using Acceleration Factors and Solution Tolerances . . . . . . . . . . . . . . . . . . .6-4
6.2.2 Automatic Power Flow Solution Adjustments . . . . . . . . . . . . . . . . . . . . . . . . .6-5
Adjusting Transformer Off-Nominal Tap Ratio . . . . . . . . . . . . . . . . . 6-5
Adjusting Transformer Voltage Control . . . . . . . . . . . . . . . . . . . . . . . 6-6
Adjusting Transformer Mvar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Adjusting Transformer Phase Shift Angle . . . . . . . . . . . . . . . . . . . . . 6-7
Adjusting Transformer Direct Current (DC) Converter Taps . . . . . . . 6-7
Adjusting Net Interchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Adjusting Switched Shunt Admittance. . . . . . . . . . . . . . . . . . . . . . . . 6-8
Applying Gauss-Seidel Power Flow Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12
Activity SOLV
6.3.1 About Power Flow Iterative Solution Algorithms . . . . . . . . . . . . . . . . . . . . . .6-12
6.3.2 About Power Flow Boundary Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13
6.3.3 Boundary Conditions of Constant MVA Loads . . . . . . . . . . . . . . . . . . . . . . .6-14
6.3.4 Boundary Conditions of Constant Current Loads . . . . . . . . . . . . . . . . . . . . .6-16
6.3.5 Boundary Conditions of Constant Impedance Loads . . . . . . . . . . . . . . . . . .6-17
6.3.6 Boundary Conditions of Composite Loads . . . . . . . . . . . . . . . . . . . . . . . . . .6-17
6.3.7 Boundary Conditions of the Swing Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17
6.3.8 Boundary Conditions of Standard Generators . . . . . . . . . . . . . . . . . . . . . . .6-18
6.3.9 Boundary Conditions of Multiple Identical Generators . . . . . . . . . . . . . . . . .6-19
6.3.10 Boundary Conditions of Multiple Non-Identical Generators . . . . . . . . . . . . .6-19
6.3.11 Operation of Activity SOLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-20
6.3.12 Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-23
6.3.13 Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-23
6.3.14 Induction Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25
6.3.15 Switched Shunt Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25
6.3.16 FACTS Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-26
Normal Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
Bypassed Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
Constant Series Impedance Mode . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Constant Series Voltage Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
IPFC Master and Slave Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
All Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
6.3.17 DC Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-30
ix
Capacitor Commutated DC Lines. . . . . . . . . . . . . . . . . . . . . . . . . . 6-30

VSC dc Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-30
6.3.18 AC Voltage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Swing Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Setpoint Voltage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33
Band Mode Voltage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-34
6.3.19 Characteristics of Activity SOLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-35
6.3.20 Automatic Adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37
Applying Modified Gauss-Seidel Power Flow Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38
Activity MSLV
Applying Fully-Coupled Newton-Raphson Power Flow Solution . . . . . . . . . . . . . . . . . . . . . . . 6-40
Activity FNSL
6.5.1 Characteristics of Activity FNSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-42
Convergence Testing Used in Prior Releases . . . . . . . . . . . . . . . . 6-45
6.5.2 Automatic Adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47
Automatic Transformer Adjustments . . . . . . . . . . . . . . . . . . . . . . . 6-47
Voltage Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-48
Mvar Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50
DC Line Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50
Phase Shift Angle Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-51
Area Interchange Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-52
Switched Shunt Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-53
Oscillating Tap Ratio and/or Switched Shunt Adjustments . . . . . . 6-54
Automatic Adjustment Solution Parameters . . . . . . . . . . . . . . . . . . 6-54
6.5.3 Non-Divergent Solution Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-54
Non-Divergent Solution Methodology. . . . . . . . . . . . . . . . . . . . . . . 6-55
Convergence Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-56
Applying Decoupled Newton-Raphson Power Flow Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6-59
Activity NSOL
Applying Fixed Slope Decoupled Newton-Raphson Power Flow Solution . . . . . . . . . . . . . . . . 6-61
Activity FDNS
Applying Newton-Raphson Power Flow Solution with Inertial / Governor Dispatch . . . . . . . . . 6-64
Activity INLF
6.8.1 Inertia and Governor Response Data File Contents . . . . . . . . . . . . . . . . . . 6-65
6.8.2 Operation of Activity INLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-66
6.8.3 Inertial Power Flow Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-67
6.8.4 Governor Response Power Flow Solution . . . . . . . . . . . . . . . . . . . . . . . . . 6-68
6.8.5 Example of a Generator Contingency Analysis Solution . . . . . . . . . . . . . . . 6-70
Overview: Contingency Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-73
6.9.1 Reliability Testing Criteria for Contingency Analysis . . . . . . . . . . . . . . . . . . 6-74
6.9.2 Applying Deterministic Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-78
Applying Transmission Transfer Limit Analysis . . . . . . . . . . . . . . . 6-78
Applying Voltage Stability Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6-78
6.9.3 Applying Probabilistic Reliability Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-79
6.9.4 About Generation Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-79
6.9.5 Tripping Simulation and Corrective Action Analysis . . . . . . . . . . . . . . . . . . 6-81
x
6.9.6 Substation Reliability Assessment Analysis . . . . . . . . . . . . . . . . . . . . . . . . .6-81

Performing AC Contingency Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-82
Activity ACCC
6.10.1 AC Contingency Solution Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-83
6.10.2 Running AC Contingency Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-87
6.10.3 AC Contingency Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-87
6.10.4 AC Contingency Post Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-89
6.10.5 AC Contingency Result Retrieval Routines . . . . . . . . . . . . . . . . . . . . . . . . .6-89
6.10.7 Implementing Generation Dispatch Algorithm in Contingency Analysis . . . .6-91
6.10.8 Appending Data to a Contingency Solution Output File . . . . . . . . . . . . . . . .6-92
6.10.9 AC Contingency Single Run Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-93
6.10.10 Single Run Report Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-97
Overload Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-97
Loading Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-99
Available Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-101
Non-converged Network Conditions . . . . . . . . . . . . . . . . . . . . . . . 6-105
Corrective Action Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-108
6.10.11 AC Contingency Multiple Run Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-112
6.10.12 Multiple Run Output Report Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-115
Contingency Solution Output Files Report . . . . . . . . . . . . . . . . . . 6-116
Monitored Element Summary Report . . . . . . . . . . . . . . . . . . . . . . 6-116
Missing Monitored Elements Report . . . . . . . . . . . . . . . . . . . . . . . 6-117
Missing Monitored Voltage Buses Report . . . . . . . . . . . . . . . . . . . 6-117
Contingency Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-117
Missing Contingencies Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-117
Non-converged Contingencies Report . . . . . . . . . . . . . . . . . . . . . 6-117
Base Case Loading Violations Report. . . . . . . . . . . . . . . . . . . . . . 6-118
Contingency Case All Loading Violations Report . . . . . . . . . . . . . 6-118
Contingency Case Worst Case Loading Violations Report . . . . . . 6-118
Base Case Voltage Violations Reports . . . . . . . . . . . . . . . . . . . . . 6-119
Contingency Case All Voltage Violations Reports. . . . . . . . . . . . . 6-119
Contingency Case Worst Case Voltage Violations Reports . . . . . 6-120
6.10.13 ZIP Archive Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-121
RunDetails.txt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-121
Listing System Conditions Represented in a ZIP Archive Output File. 6-
121
Bringing Contingency Case Conditions into the Working Case. . . 6-121
AC Corrective Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-122
6.11.1 Constraints and Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-122
6.11.2 Weighting and Penalty Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-124
6.11.3 AC Corrective Action Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-127
6.11.4 Viewing AC Corrective Actions Results. . . . . . . . . . . . . . . . . . . . . . . . . . . .6-130
PSCOPF Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-132
6.12.1 About PSCOPF analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-132
6.12.2 PSCOPF solution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-135
6.12.3 Perform PSCOPF Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-139
6.12.4 Application notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-145
xi
Performing Multi-Level AC Contingency Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-147

Activity Multi-Level AC Contingency Solution
6.13.1 Terms Used in Multiple-Level Contingency Analysis . . . . . . . . . . . . . . . . 6-149
6.13.2 Power Flow Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-150
6.13.3 Multiple Contingency Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-151
6.13.4 Classification of Contingency Analysis Results . . . . . . . . . . . . . . . . . . . . . 6-153
6.13.5 About Contingency List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-155
6.13.6 Wind Chime Algorithm for Multiple Level Contingency Analysis . . . . . . . . 6-156
6.13.7 About Tripping Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-158
6.13.8 Tripping Simulation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-158
6.13.9 Tripping Element Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-160
Monitored Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-160
Trip Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-162
Automatic Single Tripping Record . . . . . . . . . . . . . . . . . . . . . . . . 6-163
6.13.10 Corrective Actions Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-165
6.13.11 Operation of Multiple Contingency Analysis Activity . . . . . . . . . . . . . . . . . 6-168
6.13.12 Contingency Analysis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-168
N-1-1 Contingency Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-169
6.14.1 About N-1-1 AC contingency analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-169
N-1-1 contingency solution options . . . . . . . . . . . . . . . . . . . . . . . 6-172
6.14.2 Perform N-1-1 Contingency Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-177
Running in the Local Control Mode . . . . . . . . . . . . . . . . . . . . . . . 6-178
6.14.3 Running in the Corrective Action Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-179
6.14.4 Running in the Security Constrained OPF Mode . . . . . . . . . . . . . . . . . . . 6-182
Calculating Probabilistic Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-187
6.15.1 Probabilistic Reliability Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-189
6.15.2 Outage Statistics Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-190
6.15.3 Analyzing Probabilistic Assessment Results . . . . . . . . . . . . . . . . . . . . . . . 6-195
System Probabilistic Index Summary . . . . . . . . . . . . . . . . . . . . . . 6-195
System Loss of Load Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-197
Branch Flow Overloading Indices. . . . . . . . . . . . . . . . . . . . . . . . . 6-197
Calculating Substation Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-200
6.16.1 Substation Reliability Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-200
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-200
Run Options: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-201
Input Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-202
6.16.2 Modeling the Substation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-202
6.16.3 Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-203
Performing the Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-205
Analyzing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-207
Substation Component Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-207
Contingency Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-209
Bus Load Curtailment Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-215
Substation Load Curtailment Report . . . . . . . . . . . . . . . . . . . . . . 6-215
Performing PV/QV Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-215
PV Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-215
6.18.1 Retrieving Results from a Previous PV Analysis . . . . . . . . . . . . . . . . . . . . 6-223
xii
6.18.2 Implementing a Specific PV Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-223

QV Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-224
6.19.1 Retrieving Results from a Previous QV Analysis . . . . . . . . . . . . . . . . . . . .6-226
Basic Engineering Guide to PV and QV Curves Applications . . . . . . . . . . . . . . . . . . . . . . . . .6-227
6.20.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-227
6.20.2 PV Analysis (PV Curves) Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-227
6.20.3 QV Analysis (QV Curves) Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-232
Sensitivity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-241
6.21.1 Options of Sensitivity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-242
6.21.2 Sensitivity analysis output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-244
Chapter 7 - Geomagnetically Induced Currents

GIC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1
Activity GIC
GIC Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
7.2.1 GIC Data File Identification Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7
7.2.2 Substation Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7
7.2.3 Bus Substation Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9
7.2.4 Transformer Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9
7.2.5 Bus Fixed Shunt Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12
7.2.6 Branch Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13
7.2.7 User Earth Model Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13
Chapter 8 - Linear Network Analysis

Building the Distribution Factor Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1
Activity DFAX
8.1.1 Linear Network Analysis Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2
File Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Special Data Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
8.1.2 Subsystem Description Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . .8-3
8.1.3 Monitored Element Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6
Flow Monitoring Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
Voltage Monitoring Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
8.1.4 Contingency Description Data File Contents . . . . . . . . . . . . . . . . . . . . . . . .8-12
Contingency Case Block Structure . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Automatic Contingency Specification . . . . . . . . . . . . . . . . . . . . . . . 8-16
8.1.5 NB contingencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-19
Automatic Contingency Specification . . . . . . . . . . . . . . . . . . . . . . . 8-21
8.1.6 Operation of Activity DFAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-22
Calculating Distribution Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-24
Activity OTDF
8.2.1 Operation of Activity OTDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-25
8.2.2 Output Report Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-26
xiii
Estimating Severity Rankings for Single Line Outage Contingencies . . . . . . . . . . . . . . . . . . . 8-29

Activity RANK
8.3.1 Contingency Ranking Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
8.3.2 Contingency Ranking Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
8.3.3 Operation of Activity RANK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
8.3.4 Analyzing AC Contingency Ranking Results . . . . . . . . . . . . . . . . . . . . . . . . 8-34
Applying the DC Linearized Network Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
Activity DCLF
8.4.1 DC Linearized Network Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
8.4.2 Operation of Activity DCLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37
8.4.3 Output Report Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-39
Calculating Linearized Network Contingency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-42
Activity DCCC
8.5.1 Operation of Activity DCCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-44
8.5.2 Overload Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-45
8.5.3 Linear Network DC Loading Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-47
8.5.4 Contingency Case Flow Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-47
Performing DC Corrective Action Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
Activity DC Corrective Action Analysis
8.6.1 About DC Corrective Action Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
8.6.2 Operation of DC Corrective Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-49
8.6.3 DC Corrective Action Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50
Calculating Transmission Interchange Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-52
Activity TLTG
8.7.1 Overview: Transmission Transfer Limit Analysis . . . . . . . . . . . . . . . . . . . . . 8-52
8.7.2 Calculating Transmission Transfer Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 8-53
8.7.3 Transmission Transfer Limit Analysis Options . . . . . . . . . . . . . . . . . . . . . . 8-54
8.7.4 Operation of Activity TLTG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-56
8.7.5 Analyzing Transfer Limit Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-58
8.7.7 Transfer Limit Analysis Flows For Contingency Cases . . . . . . . . . . . . . . . . 8-61
Calculating Sequential Participation Interchange Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-65
Activity SPIL
8.8.1 Subsystem Participation Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . 8-66
8.8.2 Interchange Limits Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-68
8.8.3 Operation of Activity SPIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-70
8.8.4 Analyzing Interchange Limit Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-72
8.8.6 Example Activity SPIL Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-73
8.8.7 Interchange Limits Contingency Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
xiv
Performing Interchange Limit Analysis with Two Opposing Systems . . . . . . . . . . . . . . . . . . . .8-78

Activity POLY
8.9.1 Interchange Limit Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-79
8.9.2 Operation of Activity POLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-81
8.9.3 Output Report Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-83
8.9.4 Interchange Limit (Two-Opposing Systems) Graphical Output . . . . . . . . . .8-84
Midwest MW-Mile Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-87
Activity MWMI
Chapter 9 - Network Reduction

Overview: Equivalent (Reduced) Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1
Activity Overview
9.1.1 Nomenclature of Equivalents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1
Methodology of the Electrical Equivalent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
Activity Methodology
9.2.1 Defining Boundaries and Boundary Buses . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
9.2.2 Handling DC Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
9.2.3 Approaching the Network Equivalent Process . . . . . . . . . . . . . . . . . . . . . . . .9-5
Building an Electrical Equivalent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
Activity EEQV
9.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.2 Network Equivalence Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
9.3.3 Operation of Activity EEQV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
9.3.4 Equivalencing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
9.3.5 Example: Equivalencing a Power Flow Case . . . . . . . . . . . . . . . . . . . . . . . .9-11
Net Generation with Load In a Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15
Activity GNET
9.4.1 Example of Net Generation with Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-17
Net Generation with Load Outside of a Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-18
Activity NETG
Convert Induction Machines to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-19
Activity ImNet
Activity NetIm
Equivalencing Radial Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20
Activity EQRD
9.7.1 Operation of Activity EQRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23
9.7.2 Example: Equivalencing Radial Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23
Equivalencing Radial Buses, with Exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-25
Activity RDEQ
xv

Converting Net Boundary Bus Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28
Activity BGEN
Building a Three-Sequence Electrical Equivalent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
Activity SCEQ
9.10.1 Creating Short Circuit Equivalents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
9.10.2 Constructing a Short Circuit Equivalent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-34
9.10.3 Short Circuit Equivalent Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-35
9.10.4 Operation of Activity SCEQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-35
9.10.5 Form of the Equivalent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-36
9.10.6 Example: Short Circuit Equivalencing of a Power Flow Case . . . . . . . . . . . 9-37
Chapter 10 - Unbalanced Fault Analysis

Overview: Short-Circuit Fault Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
Appending Sequence Data to the Power Flow Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Activity Appending Sequence Data to the Power Flow Case
Fault Calculation Modeling Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
10.3.1 Detailed Fault Calculation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
10.3.2 Detailed Fault Calculation Models for DC Lines and FACTS Devices . . . . 10-4
10.3.3 Simplified Fault Calculation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
Detailed Unbalanced Fault Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
Activity Detailed Unbalanced Fault Types
10.4.1 Bus Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
10.4.2 Phase Closed Unbalances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
10.4.3 Line Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Preparing Sequence Network for Unbalanced Network Solution . . . . . . . . . . . . . . . . . . . . . . . 10-7
Activity SEQD
Performing Fault Analysis with Multiple Unbalances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11
Activity SCMU
10.6.1 Unbalanced Fault Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12
10.6.2 Bus Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12
10.6.3 Line Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13
10.6.4 Branch with One Open End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14
10.6.5 Phase Closed Unbalances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14
10.6.6 Pre-Calculation Network Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15
10.6.7 Operation of Activity SCMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17
10.6.8 Unbalance Condition Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-18
10.6.9 Example: Unbalance Condition Summary Report . . . . . . . . . . . . . . . . . . . 10-19
10.6.10 Unbalanced Fault Analysis Detailed Report . . . . . . . . . . . . . . . . . . . . . . . 10-22
10.6.11 Observation of Transformer Currents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-23
10.6.12 Working with a Two-Wire System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27
10.6.13 Transmission Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28
10.6.14 Transformers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28
xvi
10.6.15 Secondary Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-31

10.6.16 Faults on a Two-Phase System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-33
10.6.17 Examples of Two-Wire Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-33
Multiple Unbalanced Fault Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-49
Activity SCOP
Calculating Automatic Sequencing Fault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-50
Activity ASCC
10.8.1 Automatic Sequencing Fault Selection Options . . . . . . . . . . . . . . . . . . . . .10-57
10.8.2 Fault Control Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-61
10.8.3 Operation of Activity ASCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-62
10.8.4 Detailed Bus Output Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-63
10.8.5 Example: Automatic Sequencing, 3-Phase Faults, ASCC API . . . . . . . . . .10-65
10.8.6 Example: Automatic Sequencing, 3-Phase & Single L-G Faults, ASCC API .10-
67
10.8.7 Relay File Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-70
Calculating Fault Currents to ANSI Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-72
Activity ANSI
10.9.1 ANSI Fault Specification Data File Contents . . . . . . . . . . . . . . . . . . . . . . .10-73
10.9.2 Operation of Activity ANSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-74
10.9.3 ANSI Fault Calculation Output Report . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-74
Setting up Classical Fault Analysis Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-78
Activity FLAT
10.10.1 Change Voltages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-78
10.10.2 Set Classical Fault Analysis Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . .10-78
10.10.3 Set IEC 909 Fault Analysis Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-80
Calculating Short Circuit Currents According to IEC 60909 Standard . . . . . . . . . . . . . . . . . . .10-80
Activity IECS
10.11.1 IEC Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-84
GSU, Equivalent Generator and Motor Data . . . . . . . . . . . . . . . . . 10-85
Transformer Nameplate Winding MVA Data . . . . . . . . . . . . . . . . . 10-86
10.11.2 Fault Control Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-87
Calculating Circuit Breaker Interrupting Duty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-88
Activity BKDY
10.12.1 How PSS®E Calculates Circuit Breaker Duty . . . . . . . . . . . . . . . . . . . . . .10-93
10.12.2 Breaker Duty Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-95
10.12.3 Fault Specification Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-96
10.12.4 Breaker Duty Calculation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-97
10.12.5 Operation of Activity BKDY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-97
10.12.6 Circuit Breaker Interrupting Duty Report . . . . . . . . . . . . . . . . . . . . . . . . . .10-98
10.12.7 Example: Breaker Duty Results Analysis . . . . . . . . . . . . . . . . . . . . . . . . .10-100
10.12.8 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-102
xvii
Calculating pi-Equivalent, Single Transmission Line Unbalance . . . . . . . . . . . . . . . . . . . . . 10-103

Activity SPCB
10.13.1 Calculating pi-Equivalent for Unbalanced Switching . . . . . . . . . . . . . . . . 10-103
10.13.2 Separate Pole Circuit Breaker Calculation Options . . . . . . . . . . . . . . . . . 10-105
10.13.3 Transmission Line Unbalances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-105
10.13.4 Operation of Activity SPCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-106
10.13.5 Output of Activity SPCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-106
10.13.6 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-108
Chapter 11 - Power Flow Reports

Analyzing Power Flow Solution Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Activity Analyzing Power Flow Solution Results
Producing a Standard Power Flow Solution Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Activity POUT
Bus Quantities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
FACTS Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Series GNE Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
DC Lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Branch Quantities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9
Fault MVA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
Producing a Wide-Format Power Flow Solution Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12
Activity LOUT
Bus Quantities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
FACTS Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
GNE Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16
DC Lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
Branch Quantities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18
Fault MVA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21
Producing a Wide-Format Power Flow Solution Report in Amps . . . . . . . . . . . . . . . . . . . . . . 11-21
Activity LAMP
Bus Quantities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22
FACTS Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22
GNE Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24
DC Lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25
Branch Quantities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28
Fault MVA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-29
Summarizing Subsystem Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-30
Activity SUBS
System Swing Bus Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-31
Area Slack Bus Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-31
Component Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-31
Subsystem Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-32
Branch Totals by Voltage Level . . . . . . . . . . . . . . . . . . . . . . . . . . 11-32
Summarizing Load Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-34
Activity LODR
xviii
11.6.1 Operation of Activity LODR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-34

Summarizing Area Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-37
Activity AREA
Summarizing Owner Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-43
Activity OWNR
Summarizing Zone Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-46
Activity ZONE
Reporting Interchange by Area/Owner/Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-52
Summarizing Area-to-Area Interchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-52
Activity INTA
Summarizing Zone-to-Zone Interchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-54
Activity INTZ
Summarizing Loadings on Ties from Interchange Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-56
Activity TIES
Summarizing Loadings on Ties from Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-58
Activity TIEZ
Viewing Network Limit Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-60
Producing a Branch Overload Checking Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-61
Activity RAT3
Producing a Transformer Overload Checking Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-65
Activity OLTR
Producing a Transmission Line Overload Checking Report . . . . . . . . . . . . . . . . . . . . . . . . . .11-67
Activity OLTL
Producing a Branch Current Ratings Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-72
Activity RATE
Producing Out-of-Limits Bus Voltage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-74
11.20.1 Activity VCHK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-74
Activity VCHK
11.20.2 Activity VLIMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-77
Activity VLIMS
Producing a Machine Reactive Capability Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-78
Activity GCAP
11.21.1 Machine Capability Curve Data File Contents . . . . . . . . . . . . . . . . . . . . . .11-78
11.21.2 Operation of Activity GCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-80
Producing a Generator Bus Limits Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-84
Activity GENS
Producing a Machine Terminal Limits Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-90
Activity GEOL
xix

Producing a Regulated Bus Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-95
Activity REGB
Producing a Controlling Transformer Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-100
Activity TLST
Comparing Power Flow Case Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-104
Activity CMPR
Comparing Power Flow Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-107
Activity DIFF
11.27.1 Operation of Activity DIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-108
11.27.2 Bus Related Data Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-111
11.27.3 Branch Related Data Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-114
Displaying Power Flow Solution Differences on a Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 11-118
Activity GDIF
Comparing AC Tie Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-120
Activity DFTI
Generating a Graphical Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-125
Activity GRPG
11.30.1 GRPG Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-126
Setup Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-126
Miscellaneous Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-128
Drawing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-129
Text Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-135
Assignment Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-137
Conditional Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-139
Termination Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-140
Viewing Graphical Output of Fault Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-141
11.31.1 Display Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-141
11.31.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-144
Exporting Power Flow Results to Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-159
Activity Exporting Power Flow Results to Excel
Displaying Power Flow Solution on the Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-160
Activity GOUT
Displaying Power Flow Data on the Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-161
Activity GEXM
Chapter 12 - Balanced Switching

Overview: Balanced Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
12.1.1 Objectives of a Balanced Switching Study . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
12.1.2 Preparing a Power Flow Case for Balanced Switching . . . . . . . . . . . . . . . . 12-4
12.1.3 Establishing the Power Flow Base Case for Balanced Switching . . . . . . . . 12-4
12.1.4 Performing a Balanced Switching Study . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
xx
Converting Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6

Activity CONG
12.2.1 Converting Machines for Balanced Switching . . . . . . . . . . . . . . . . . . . . . . .12-7
12.2.2 Generator Apparent Impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-8
12.2.3 Generator Step-Up Transformers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-8
12.2.4 Operation of Activity CONG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-11
Converting Load Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13
Activity CONL
12.3.1 Modeling Load Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13
12.3.2 Basic Load Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14
12.3.3 Converting Load Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14
12.3.4 Converting Loads for Balanced Switching . . . . . . . . . . . . . . . . . . . . . . . . .12-16
12.3.5 Operation of Activity CONL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-16
12.3.6 Example of Load Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-16
Reconverting Load Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18
Activity RCNL
12.4.1 Reconverting Load Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18
12.4.2 Operation of Activity RCNL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-20
12.4.3 Example of Load Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-20
Ordering Network Buses for Matrix Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-21
Activity ORDR
Factorizing the Network Admittance Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-23
Activity FACT
12.6.1 About the Power Flow Network Admittance Matrix . . . . . . . . . . . . . . . . . .12-23
12.6.2 Operation of Activity FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-25
12.6.3 Exporting the Power Flow Network Admittance Matrix . . . . . . . . . . . . . . . .12-26
Solving the Converted Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-27
Activity TYSL
12.7.1 Example: Voltage Rise on Open Line End . . . . . . . . . . . . . . . . . . . . . . . . .12-29
12.7.2 Example: Open Line End Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-31
12.7.3 Example: Motor Starting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-31
12.7.4 Example: Fault Current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-33
Chapter 13 - Transmission Pricing and Open Access

Overview: Open Access and Pricing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-1
Activity Open Access and Pricing
Managing Transaction Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2
Activity Transaction Data
13.2.1 Transmission Access Calculators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-3
Calculating Transaction Event Impact on Monitored Elements . . . . . . . . . . . . . . . . . . . . . . . . .13-3
Activity IMPC
xxi

13.3.2 Example: Transaction Event Impact on Monitored Elements . . . . . . . . . . . 13-5
Calculating Line Loading Relief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6
Activity LLRF
13.4.1 Operation of Activity LLRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
Curtailing and Restoring Transactions . . . . . . . . . . . . . . . . . . . . . . 13-9
Distribution Factor Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
Making Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
Activity ALOC
13.5.1 Output Report Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11
Chapter 14 - Optimal Power Flow

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Conventional Power Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2
Optimal Power Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2
Activity NOPF
14.3.1 Objective Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
14.3.2 Constraints and Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
14.3.3 Sensitivities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
Conventional Power Flow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
14.4.1 Bus Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
14.4.2 Load Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
14.4.3 Fixed Shunt Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
14.4.4 Generator Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
14.4.5 Non-Transformer Branch Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
14.4.6 Transformer Adjustment Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
14.4.7 Area Interchange Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
14.4.8 Two Terminal DC Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
14.4.9 Voltage Source Converter Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
14.4.10 Transformer Impedance Correction Data . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
14.4.11 Multi-Terminal DC Line Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
14.4.12 FACTS Device Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
14.4.13 Induction Generators and Motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7
14.4.14 Switched Shunt Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
Modeling Power Flow Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
14.5.1 Scalar Quadratic Penalties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
14.5.2 Soft Limit Penalties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
14.5.3 Treatment of Transformers and Switched Shunts . . . . . . . . . . . . . . . . . . . . 14-9
14.5.4 Treatment of Local Generator Voltage Controls . . . . . . . . . . . . . . . . . . . . . 14-9
Treatment of Optimized Generators. . . . . . . . . . . . . . . . . . . . . . . 14-10
Treatment of Non-optimized Generators . . . . . . . . . . . . . . . . . . . 14-10
14.5.5 Reactive Generation Reserve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13
xxii
OPF Modeling Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-14

14.6.1 Active Power Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-14
14.6.2 Adjustable Bus Shunt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-14
14.6.3 Load Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-15
14.6.4 Adjustable Branch Reactance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-16
14.6.5 Generator Reactive Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-16
14.6.6 Generator Period Reserve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-20
14.6.7 Regulated Area Interchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-21
14.6.8 Linear Constraint Dependency Equation . . . . . . . . . . . . . . . . . . . . . . . . . .14-22
14.6.9 Other Dependent Variable Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-23
Solution Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-23
14.7.1 The Nonlinear Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-23
14.7.2 Accommodating Inequality Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . .14-24
Soft Limit Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-24
Hard Limit Barrier Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25
14.7.3 Formulating the Equation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-28
Iterative Solution Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31
Solution Convergence Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-34
Data Input and Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-36
14.8.1 PSS®E Saved Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-36
14.8.2 Optimal Power Flow Raw Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-37
Activity ROPF
14.8.3 Optimal Power Flow Options File: PSSOPF.OPT . . . . . . . . . . . . . . . . . . .14-37
14.8.4 Optimal Power Flow Spreadsheet View . . . . . . . . . . . . . . . . . . . . . . . . . . .14-38
14.8.5 Optimal Power Flow Data Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-38
Constraint and Control Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-38
Optimal Power Flow Solution Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-38
14.10.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-39
14.10.2 General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-41
14.10.3 Tolerance Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-44
14.10.4 Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-47
14.10.5 Reporting Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-48
Solution Results and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-48
14.11.1 OPF Progress Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-49
Problem Size Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-49
Solution Iteration Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-51
Solution Termination Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-52
Labeling Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-53
14.11.2 OPF Solution Results Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-55
14.11.3 OPF Optimization Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-55
Infeasible Variable Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-56
Post Solution Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-56
Lagrange Multipliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-58
Examining OPF Data and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-58
Listing Control and Constraint Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-59
Activity LSTO
Optimal Power Flow Solution Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-62
xxiii
14.14.1 Solution Termination Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-62

14.14.2 Interface Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-62
14.14.3 Bounded, Infeasible and Opened Voltage Magnitudes . . . . . . . . . . . . . . . 14-63
14.14.4 Bounded and Infeasible Reactive Generation . . . . . . . . . . . . . . . . . . . . . . 14-64
14.14.5 Bounded or Infeasible Line Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-64
14.14.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-65
14.14.7 Generator Fuel Cost Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-65
14.14.8 Generation Reserve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-67
14.14.9 Regulated Voltage Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-67
14.14.10Tap Changing Transformers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-69
14.14.11Phase Shifting Transformers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-70
14.14.12Added Shunts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-71
14.14.13Switched Shunts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-71
14.14.14Load Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-72
14.14.15Series Compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-73
14.14.16Regulated Area Interchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-73
14.14.17Linear Dependency Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-74
Chapter 15 - Dynamic Simulation Activity Descriptions

Reading Dynamics Model Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
Activity DYRE
15.1.1 Dynamics Model Raw Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
Device, Protection, and Other type models associated with machines .
15-4
Generator Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4
Current Compensating Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5
Stabilizer and Excitation Limiter Models. . . . . . . . . . . . . . . . . . . . . 15-5
Excitation System Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6
Turbine Governor Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6
Turbine Load Controller Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6
Machine and Wind machine Protection Models . . . . . . . . . . . . . . . 15-7
Load Characteristic Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-7
Load Relay (a.k.a, load protection) Models . . . . . . . . . . . . . . . . . . 15-7
Branch and 2-winding transformer device models . . . . . . . . . . . . . 15-8
Branch Relay and 2-winding transformer protection Models . . . . . 15-8
3-winding transformer device models. . . . . . . . . . . . . . . . . . . . . . . 15-9
Auxiliary-Signal Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-9
DC Line Device Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-10
2-Terminal DC Line other Models . . . . . . . . . . . . . . . . . . . . . . . . 15-10
FACTS Device Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-10
Wind Generator Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-10
Wind Electrical Control Models . . . . . . . . . . . . . . . . . . . . . . . . . . 15-10
Wind Turbine Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-11
Wind Pitch Control Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-11
Switched Shunt Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-11
Miscellaneous “other” Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-11
CONEC and CONET Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-12
User-Written Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-12
Machine Related Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-17
Load-Related Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-17
Line Relay Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-18
xxiv
Auxiliary Signal Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-18

DC Line Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-19
FACTS Device Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-19
Wind Machine Related Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-19
Switched Shunt Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-19
CONEC Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-20
CONET Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-20
15.1.2 Operation of Activity DYRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-20
15.1.3 Adding Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22
15.1.4 Subsystem Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-24
15.1.6 Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-25
Assigning Simulation Variables to Output Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-31
Activity CHAN
15.2.1 Operation of Activity CHAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-31
15.2.3 Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-36
Saving Dynamics Working Memory in a Binary File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-37
Activity SNAP
Restoring Dynamics Working Memory from a Binary Snapshot File . . . . . . . . . . . . . . . . . . . .15-38
Activity RSTR
15.4.1 Restarting From a Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-40
Restoring Dynamics Working Memory from a Snapshot File Created in PSS®E-26 or Earlier .15-
41
Activity SRRS
Modifying Data in Dynamics Working Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-43
Activity ALTR
Modifying Dynamics Model Pointer Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-44
Activity DYCH
15.7.1 List Unconnected Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-45
15.7.2 Remove Unconnected Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-45
15.7.3 Pack Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-45
15.7.4 List User Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-45
15.7.5 Remove Unused User Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-45
15.7.6 Consistency Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-46
15.7.7 List Plant Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-48
15.7.8 Change Model Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-48
15.7.9 Remove Plant Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-49
15.7.10 List CHAN Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-49
15.7.11 Remove Unused CHAN Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-50
Linking to Power Flow Activities from Dynamic Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . .15-50
Activity LOFL
xxv
Initializing Models for State-Space Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-52

Activity STRT
Performing State-Space Simulation in Time Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-57
Activity RUN
Initializing Excitation System Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-60
Activity ESTR
15.11.1 Response Ratio Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-61
15.11.2 Open Circuit Step Response Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-61
Performing Exciter Simulation in Time Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-62
Activity ERUN
15.12.1 Response Ratio Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-63
15.12.2 Open Circuit Step Response Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-63
Initializing Turbine Governor Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-65
Activity GSTR
Performing Governor Response Simulation in Time Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 15-66
Activity GRUN
Building a State Variable Matrix for Linear Dynamic Analysis (LSYSAN) . . . . . . . . . . . . . . . 15-68
Activity ASTR
Activity
Listing Dynamics Model Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-73
Activity DOCU
Listing Dynamics Data Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-77
Activity DLST
Creating a Dynamics Model Raw Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-78
Activity DYDA
Dumping Dynamic Simulation Output Channels into a Response File . . . . . . . . . . . . . . . . . . 15-82
Activity DMPC
Creating Dynamic Data Records for Use by Other Activities . . . . . . . . . . . . . . . . . . . . . . . . . 15-83
Activity RWDY
Listing Dynamics Model Storage Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-85
Activity MLST
xxvi
Initializing Models for Extended Term Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-86

Activity MSTR
Performing Extended Term Simulation in Time Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-91
Activity MRUN
Changing Dynamics Model Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-95
Activity CCON
Assigning Subsystem Simulation Data to Output Channels . . . . . . . . . . . . . . . . . . . . . . . . . .15-96
Activity CHSB
15.25.1 Operation of Activity CHSB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-97
15.25.3 Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-100
Chapter 16 - Program Automation

What is Program Automation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-1
Controlling PSS®E Execution Using the API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-1
Activity Application Program Interface
Automation Methods in PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-2
Activity Automation Methods
Python Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-2
16.4.1 PSS®E Extension Modules For Python . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3
16.4.2 The Embedded Interpreter Environment . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5
16.4.3 The External Interpreter Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
16.4.4 The Embedded Interpreter Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7
16.4.5 Finding user-created modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7
Batch Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7
Activity Batch Commands
Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8
Activity Recording
Argument Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9
Activity Argument Passing
16.7.1 Arguments in Python Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9
16.7.2 Arguments in Response Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-10
16.7.3 Arguments in IPLAN Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-10
Default Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-11
Activity Default Values
16.8.1 Defaults in Python Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-11
16.8.2 Defaults and Keywords in Module psspy . . . . . . . . . . . . . . . . . . . . . . . . . .16-11
16.8.3 Defaults in Recorded Python Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12
16.8.4 Defaults in Response Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12
xxvii
Unattended Execution of PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12

Activity Unattended Execution of PSS®E
Running a Python Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14
Line Mode Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14
16.11.1 Mixing Line Mode and Batch Commands . . . . . . . . . . . . . . . . . . . . . . . . . 16-15
16.11.2 Immediate Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-15
16.11.3 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-16
Running a Response File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-16
Recording User Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17
Activity ECHO
Building a Response File, Power Flow Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19
Activity PSEB
16.14.1 PSS®E PSEB Macro Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19
16.14.2 PSEB Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20
Building a Response File, Dynamic Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-27
Activity PSAS
16.15.1 PSS®E PSAS Macro Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-27
16.15.2 PSAS Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-28
16.15.3 Operation of Activity PSAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-42
Launching an IPLAN Program File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-44
Activity EXEC
16.16.1 IPLAN Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-44
16.16.2 Interaction With PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-45
16.16.3 The IPLAN Stand-Alone Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-45
16.16.4 Operation of Activity EXEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-45
Chapter 17 - Result Retrieval

Python Modules for Result Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1
Activity Python Lists
pssarrays.accc_summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2
Activity pssarrays.accc_summary
17.2.1 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2
17.2.2 Automation File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-3
pssarrays.accc_solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-4
Activity pssarrays.accc_solution
pssarrays.accc_violations_report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-6
pssexcel.accc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-6
Activity pssexcel.accc
xxviii
pssexcel.pv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-8
Activity pssexcel.pv
excelpy Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-8
Activity excelpy Examples
17.7.1 Export QV Solution to Excel Spreadsheet . . . . . . . . . . . . . . . . . . . . . . . . . .17-8
17.7.2 Write Data to Excel Spreadsheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-12
Chapter 18 - Implementing the Powerflow Customization Interface (PCI)

Contents of pssuserpf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-1
18.1.1 on_case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-1
18.1.2 pre_accc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-2
18.1.3 post_accc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-2
18.1.4 pre_solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-2
18.1.5 post_solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-2
18.1.6 pre_ca_solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3
18.1.7 post_ca_soln_eval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3
18.1.8 post_ca_soln_adj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3
18.1.9 pre_iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3
18.1.10 post_iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4
Importing pssuserpf and Progress information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4
Use of the psspy module in pssuserpf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4
Using other PSS®E modules from pssuserpf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
18.4.1 pfcontrol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
18.4.2 ppsppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
18.4.3 others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
Chapter 19 - Using the Remedial Action Scheme API

Minimal Contents of the User-defined pssuserpf.py Module for RAS Simulation . . . . . . . . . . .19-1
Contents of the User-defined ras.py File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-2
Explanation of the Typical RAS Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-3
Python Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4
Available RAS Getter Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4
Available Setter Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8
Settings and other Utility Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-10
Chapter 20 - Miscellaneous Activity Descriptions

Terminating PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-1
Activity STOP
Applying a User-Written Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-2
Activity USER
Displaying Help Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-2
Activity HELP
xxix
Selecting Prompt Output Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-3

Activity ODEV
Selecting Alert Output Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-4
Activity ODEV
Selecting Progress Output Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5
Activity PDEV
Selecting Report Output Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-6
Activity OPEN
Closing Report Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-7
Activity CLOS
Setting the Path for Use with & Filenames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-7
Activity PATH
Changing PSS®E Program Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-8
Activity OPTN
Returning Activity Selection to Dynamic Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
Activity RTRN
Editing the Case Heading or Long Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-10
Activity EDTR
Listing Directory Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-13
Activity CATA
Listing Saved Case or Snapshot Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-13
Activity SHOW
Displaying Timing Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-14
Activity TIME
Inserting Comments into the Progress Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-15
Activity TEXT
Chapter 21 - Dynamic Simulation Setup and Procedures

Simulation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1
21.1.1 Program Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1
21.1.2 Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-4
Linkage to Power Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-8
The Network Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-9
The Dynamic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-10
21.4.1 Subroutines TBLCNC and CONEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-11
21.4.2 Subroutines TBLCNT and CONET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-12
21.4.3 Data Assimilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-12
21.4.4 Program Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-14
Model Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-14
21.5.1 Parameter Range Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-15
xxx
21.5.2 Performance Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-16

Generator Reactances and Saturation Data . . . . . . . . . . . . . . . . . 21-16
Exciter Response Ratio Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-17
Excitation System Open Circuit Step Response Test . . . . . . . . . . 21-17
Governor Response Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-18
Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-19
21.5.3 Simulation Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-20
Simulation Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-21
21.6.1 Output Channel Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-22
21.6.2 Channel Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-23
Running a Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-24
21.7.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-24
21.7.2 Applying Disturbances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-26
21.7.3 Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-27
Procedural Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-28
21.8.1 The Executable Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-28
21.8.2 The Converted Saved Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-29
21.8.3 Initial Model Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-29
21.8.4 Retrieving System Model Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-30
21.8.5 Selecting Output Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-31
21.8.6 Running a Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-31
21.8.7 Modifying the Network Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-31
21.8.8 Modifying the Dynamic Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-32
21.8.9 A Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-33
Advanced Uses of CONEC and CONET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-33
21.9.1 Manual Model Addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-33
21.9.2 Accessing Machine and Load Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-37
21.9.3 Getting Bus Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-38
21.9.4 Run Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-40
Extended Term Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-40
Creating and Viewing the Results of Dynamic Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . .21-42
21.11.1 General Workflow to View Dynamic Results . . . . . . . . . . . . . . . . . . . . . . .21-42
21.11.2 Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-43
Chapter 22 - Example Data Files

SAVNW Case Data Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-1
Sample Case Data Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-1
PSS®E File Planning Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-2
Chapter 23 - Model Writing

Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-1
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-1
Model Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-2
Model Calling Sequence Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-6
xxxi
Writing the Basic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-11

Model Writing Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-18
Extended Term Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-21
Coordinated Call Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-21
Writing a Basic Load Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-22
Chapter 24 - Event Studies

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-1
24.1.1 Event Item Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-1
24.1.2 Event Study Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-2
24.1.3 Adding an Event Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-3
24.1.4 Running an Event Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-4
Chapter 25 - Scenarios
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-1
Scenario Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-2
Scenario Population and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-3
Using a Scenario in PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-3
Saving and Packing a Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-4
Opening and Unpacking a Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-4
Scenario Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-5
Chapter 26 - Node-breaker Modeling

About the Node-breaker Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-1
Node-breaker Modeling in PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-2
STREE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-5
Operation of STREE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-7
Topology processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-8
Activity SLIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-9
SPOUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-10
Appendix A - Activity Summary
Appendix B - PSS®E Documentation
Appendix C - Legacy Activities

DRED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
GRED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
SCGR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
DRAW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
xxxii
C.4.1 Drawing Coordinate Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2

Header Record - HD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3
Terminator Record - EN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-4
Voltage Level Record - VO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-4
Bus Records - BU and BN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-4
Branch Record - LI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-6
Transformer Record - TR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10
Three-Winding Transformer Record - TT . . . . . . . . . . . . . . . . . . . C-10
Two-Terminal dc Transmission Line Record - DC. . . . . . . . . . . . . C-11
Multi-Terminal dc Transmission Line Record - MD . . . . . . . . . . . . C-12
Load Records - LO, LP, LC, and LY . . . . . . . . . . . . . . . . . . . . . . . C-13
Shunt Record - SH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-14
Generator Record - GE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-15
Facts Device Record - FD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-15
Straight Line Record - SL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-16
Text Specification Record - TX . . . . . . . . . . . . . . . . . . . . . . . . . . . C-17
Clip Specification Record - CL. . . . . . . . . . . . . . . . . . . . . . . . . . . . C-17
Grid Record - GR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-18
Color Specification Record - CO . . . . . . . . . . . . . . . . . . . . . . . . . . C-18
Symbol Record - SY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-19
Rating Specification Record - RA . . . . . . . . . . . . . . . . . . . . . . . . . C-21
Voltage Limits Specification Record - VL . . . . . . . . . . . . . . . . . . . C-21
Diagram Annotation Record - AN . . . . . . . . . . . . . . . . . . . . . . . . . C-22
Line Annotation Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-22
Bus Annotation Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-23
Equipment Annotation Record . . . . . . . . . . . . . . . . . . . . . . . . . . . C-24
Activity Annotation Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-24
Transformer Annotation Record . . . . . . . . . . . . . . . . . . . . . . . . . . C-24
Summation Block Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-25
BMAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-27
MENU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-27
WORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-27
XLIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-27
C.8.1 Equipment Status Changes and the Spreadsheet View . . . . . . . . . . . . . . C-27
Appendix D - Command Line Options
xxxiii
xxxiv
List of Figures
3-1 Specifying the -buses Option in the PSSE-33 Command Prompt Window . . . . . . . . .3-3
5-1 Auto-transformer Equivalent Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15
5-2 YNyn transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17
5-3 YNyn with neutral impedance transformer zero sequence network . . . . . . . . . . . . . .5-17
5-4 YNd transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18
5-5 Znyn, Zny, or ZNd transformer zero sequence network . . . . . . . . . . . . . . . . . . . . .5-18
5-6 YNy core type transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . .5-18
5-7 Dyn transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19
5-8 YNzn, Yzn or Dzn transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . .5-19
5-9 Yyn core type transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . .5-19
5-10 Yy, Yd, Dy, Dd, Yyn or YNy transformer zero sequence network . . . . . . . . . . . . . . .5-20
5-11 Ya ungrounded auto transformer zero sequence network . . . . . . . . . . . . . . . . . . . . .5-20
5-12 CC=5 or CC=15 zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-21
5-13 YNd transformer with Zigzag or YNd earthing transformer on winding 2 side zero
sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-21
5-14 YNzn or Dzn core type transformer zero sequence network . . . . . . . . . . . . . . . . . . .5-22
5-15 Dyn transformer with Zigzag or YNd earthing transformer on winding 1 side zero
sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-22
5-16 ZNyn or ZNd core type transformer zero sequence network . . . . . . . . . . . . . . . . . . .5-23
5-17 YNa core type auto transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . .5-24
5-18 YNa core type auto transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . .5-26
5-19 YNyn with or without neutral impedance core type transformer zero sequence network
5-28
5-20 YNa auto transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-29
5-21 Ya ungrounded core type auto transformer zero sequence network . . . . . . . . . . . . .5-30
5-22 YNynyn with magnetising impedance modelled transformer zero sequence network . .5-
32
5-23 YNynd transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-33
5-24 Dynd transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-34
5-25 Ddd, Ddy, Dyd, Dyy, Ydd, Ydy, Yyd or Yyy transformer zero sequence network . . .5-35
5-26 Dynd auto transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-36
5-27 YNynyn transformer zero sequence network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-37
5-28 Ynad (grounded) auto transformer zero sequence network . . . . . . . . . . . . . . . . . . . .5-38
5-29 Yad (ungrounded) auto transformer zero sequence network . . . . . . . . . . . . . . . . . . .5-39
xxxiii
5-30 Pre-Scaling Load, Generation, Losses and Swing Bus Output . . . . . . . . . . . . . . . . 5-55
5-31 Post-Scaling Load, Generation, Losses and Swing Bus Output . . . . . . . . . . . . . . . . 5-55
5-32 Bus Disconnect Progress Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-57
5-33 Purging the Branches Data Category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-64
5-34 Join Buses Summary Report on Relocation of Load . . . . . . . . . . . . . . . . . . . . . . . . 5-68
5-35 Output Report Summary for Bus Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-70
5-36 Output Summary of Line Tap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-72
5-37 Branch Move Output Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-77
5-38 Example Output Report of Owner Reassignment . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-81
5-39 Example Output Report of Owner Reassignment . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-84
5-40 Results of Example Transformer Flow Band Check . . . . . . . . . . . . . . . . . . . . . . . . 5-102
5-41 Incremental Heat Rate Curves Provided in the PSS®E savnw.sav Case . . . . . . . . 5-106
5-42 Summary of the Predispatch Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-108
5-43 Summary Results of the Economic Dispatch Process . . . . . . . . . . . . . . . . . . . . . . 5-109
5-44 Before and After Machine Terminal Conditions for Economic Dispatch Example . 5-110
5-45 Assignments for Supplementary Machine Economic Dispatch . . . . . . . . . . . . . . . . 5-111
5-46 Example Output of Activity SIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-118
5-47 Example Output of Activity BUSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-119
5-48 Case Summary for the savnw.sav Saved Case File . . . . . . . . . . . . . . . . . . . . . . . . 5-125
5-49 Packing Bus Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-152
5-50 Progress Output Indicating Number of Buses Modified . . . . . . . . . . . . . . . . . . . . . 5-152
5-51 Result of Block Renumbering by Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-153
6-1 Constant MVA Load Characteristic (Top) and Resultant Form of Current/Voltage Curve
(Bottom) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
6-2 Constant Power Load Characteristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
6-3 Constant Current Load Characteristic (Top) and Resultant Form of Load MVA/Voltage
Curve (Bottom) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
6-4 Standard PSS®E Generator Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
6-5 Identical Generators at Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
6-6 Constant Power Load Characteristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
6-7 Constant Current Load Characteristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
6-8 Dependence of Power Flow Convergence on Acceleration Factors . . . . . . . . . . . . . 6-36
6-9 Newton-Raphson Convergence Monitor (Fully Coupled) . . . . . . . . . . . . . . . . . . . . . 6-42
6-10 Activity FNSL Convergence Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-57
6-11 Decoupled Newton-Raphson Convergence Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 6-60
6-12 NSOL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-61
6-13 Activity FDNS Convergence Monitor: Non-Divergent Solution Option Enabled . . . . 6-63
6-14 Progress Reports for Inertial and Governor Power Flow Solutions . . . . . . . . . . . . . 6-71
xxxiv
6-15 Initial Dispatch Compared to Inertial and Governor Power Flow Redispatch Levels .6-72
6-16 File Path and Process for AC Contingency Analysis . . . . . . . . . . . . . . . . . . . . . . . . .6-83
6-17 Sample Monitored Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-99
6-18 Overload Report from AC Contingency Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . .6-100
6-19 Sample Loading Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-101
6-20 Sample Capacity Report from the savnw.sav Power Flow Case . . . . . . . . . . . . . . .6-104
6-21 Non-Converged Network Report Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-107
6-22 Sample Corrective Action Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-111
6-23 Active Power Generation Control Default Weighting Function . . . . . . . . . . . . . . . . .6-124
6-24 Load Shedding Control Default Weighting Function . . . . . . . . . . . . . . . . . . . . . . . .6-125
6-25 Phase Shifter Angle Control Default Weighting Function . . . . . . . . . . . . . . . . . . . . .6-125
6-26 Branch/Interface Flow Overload Penalty Function . . . . . . . . . . . . . . . . . . . . . . . . . .6-126
6-27 Bus Voltage Violation Penalty Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-126
6-28 Sample Report from Corrective Action Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . .6-131
6-29 Two level structure used in the Bender’s decomposition method . . . . . . . . . . . . . .6-134
6-30 Flow chart of PSCOPF process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-139
6-31 Chart for testing of contingencies and selection of cut set . . . . . . . . . . . . . . . . . . . .6-141
6-32 Sample of progress outputs of PSCOPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-142
6-33 The process to determine the control adjustments . . . . . . . . . . . . . . . . . . . . . . . . .6-143
6-34 Sample of progress outputs of PSCOPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-145
6-35 Outline of Evaluation Procedure Using AC Power Flows for a Single Contingency 6-148
6-36 Contingency List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-156
6-37 Wind Chime Approach for 2 Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-157
6-38 Flow chart to test a pair of N-1 contingencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-170
6-39 Flow chart of evaluation process under local control mode for a pair of N-1 contingencies
6-178
6-40 Progress output from N-1-1 contingency analysis in local control mode . . . . . . . . .6-179
6-41 Flow chart of evaluation process under corrective action mode for a pair of N-1
contingencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-180
6-42 Exampe of progress output from an N-1-1 contingency solution corrective action control
mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-182
6-43 Flow chart of evaluation process with PSCOPF mode for a pair of N-1 contingencies .6-
183
6-44 Progress output from an N-1-1 contingency solution in PSCOPF mode . . . . . . . . .6-185
6-45 Sample of non-converged network report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-186
6-46 Sample of spreadsheet overload report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-186
6-47 Sample of corrective action report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-187
6-48 Process of Probabilistic Reliability Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-188
xxxv
6-49 System Reliability Indices Summary in Post-Contingency Mode . . . . . . . . . . . . . . 6-196

6-49 System Reliability Indices Summary in Post-Corrective Action Mode . . . . . . . . . . 6-196
6-50 System Load Curtailment Probabilistic Indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-197
6-51 Branch Flow Overloading Probabilistic Indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-197
6-52 Branch Flow Overloading Probabilistic Indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-198
6-53 Three-State Component Fault Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-203
6-54 Time Line Illustrating the Steps in a Fault Simulation . . . . . . . . . . . . . . . . . . . . . . . 6-204
6-55 Two-State Model for Scheduled and Unscheduled Outage . . . . . . . . . . . . . . . . . . 6-205
6-56 Example of Outage Statistics Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-205
6-57 Process to Assess a Failure Mode of a Component in SRA . . . . . . . . . . . . . . . . . . 6-206
6-58 Sample Substation Component Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-208
6-59 Sample Contingency Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-211
6-60 Sample Descriptions of the Contingencies in the Summary Report . . . . . . . . . . . . 6-214
6-61 Sample of Substation Load Curtailment Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-215
6-62 Two Terminals Simple Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-227
6-63 PV Curves Voltage and Incremental Power Transfer Characteristics . . . . . . . . . . 6-228
6-64 PV Curves Voltage and Incremental Power Transfer Characteristics for Bus 203 under
Different Network Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-230
6-65 PV Curves Voltage and Incremental Power Transfer Characteristics for Different Buses
in Base Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-231
6-66 Generator Output Versus Power Transfer Curves . . . . . . . . . . . . . . . . . . . . . . . . . 6-232
6-67 QV Curves for a Range of System Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-233
6-68 QV Curves and Characteristics of a Capacitor Bank Required at Stable Operating Point
6-234
6-69 Compensator Operations and Size on Voltage Stability using QV Curves . . . . . . . 6-235
6-70 QV Curves under Various Contingencies for Bus 103 . . . . . . . . . . . . . . . . . . . . . . 6-236
6-71 QV Curve in Base Case with Increase in Load on Bus 103 . . . . . . . . . . . . . . . . . . 6-238
6-72 S-Shaped QV Curve on Bus 108 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-240
6-73 QV Curves for Different Load Type with Consideration of LTC . . . . . . . . . . . . . . . 6-241
6-74 Sample of sensitivity analysis report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-245
8-1 Example Report Listing Distribution Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27
8-2 Application of Line Outage Distribution Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-29
8-3 Output from Activity DCLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-39
8-4 Summary Contingency Report from the DC Contingency Checking Process . . . . . 8-46
8-5 Sample Output of DC Corrective Action Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-51
8-6 Linear Projection Technique Used in Transfer Limit Analysis . . . . . . . . . . . . . . . . . . 8-53
8-7 Study System (A) and Opposing System (C). Area B Potentially Limiting . . . . . . . . 8-54
8-8 Subsystem file and Power Flow Condition for Transfer Analysis . . . . . . . . . . . . . . . 8-58
xxxvi
8-9 Partial Listing of Report for Two Area Transfer Limits for Contingency Cases . . . . .8-63
8-10 Participation Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-74
8-11 Sequential Participation Interchange Limit Output for Base Case . . . . . . . . . . . . . . .8-75
8-12 Graphical Output from Calculation of Interchange Limit with Two Opposing Systems .8-
85
9-1 Separation of Complete Network into Study System and External Systems by Boundaries
9-3
9-2 Components of the WORLD Area in the savnw.sav Power Flow Case . . . . . . . . . . .9-11
9-3 Pre-Equivalence Power Flow Diagram for the WORLD Area . . . . . . . . . . . . . . . . . .9-12
9-4 Reduced Components of the WORLD Area after Building an Electrical Equivalent .9-13
9-5 Redrawn One-Line Diagram to Match Topology after Building an Electrical Equivalent .
9-14
9-6 Generation and Load in Power Flow Case savnw.sav . . . . . . . . . . . . . . . . . . . . . . . .9-17
9-7 Result of Netting Generation in the LIGHTCO Area . . . . . . . . . . . . . . . . . . . . . . . . .9-18
9-8 Result of Radial Equivalencing Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-24
9-9 Pictorial Image of Power Flow Case with Equivalenced Sequence Networks . . . . . .9-30
9-10 Form of Sequence Equivalents Built the Short-Circuit Equivalencing Process . . . . .9-33
9-11 Pre-Equivalence Power Flow One-Line Diagram Showing the FLAPCO Area Buses . .9-
37
9-12 Equivalent FLAPCO Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-38
10-1 Output when Appending Sequence Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
10-2 Using L-G and L-L-G Fault Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6
10-3 Phase Closed Series Unbalances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6
10-4 Allocation of Dummy Buses for In-Line Slider Faults . . . . . . . . . . . . . . . . . . . . . . . . .10-7
10-5 Unbalances Modeled in Activity SCMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-12
10-6 Generator Conversion to Norton Equivalent for Fault Calculations . . . . . . . . . . . . .10-16
10-7 Summary from Network Ordering Prior to Fault Calculations . . . . . . . . . . . . . . . . .10-17
10-8 Sequence Thevenin Impedance for Two Line-to-Ground Faults . . . . . . . . . . . . . . .10-20
10-9 Summary Output at Bus 151 with L-G Faults at Buses 151 in Power Flow Case savnw.sav
10-22
10-10 Lead Current Flowing Into and Out of a Wye-Delta Transformer . . . . . . . . . . . . . . .10-24
10-11 Transformer Zero-Sequence Currents Appearing in Alternative Network Representations
of the Transformer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-25
10-12 Assignment of Zero-Sequence Shunt Branch for Typical Tapped Delta-Wye
Transformers, Solidly Grounded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-26
10-13 Two-Phase System Configuration for Railway Application . . . . . . . . . . . . . . . . . . .10-27
10-14 Behavior of Transformer with Secondary Windings Parallel to Single-Phase Load .10-29
10-15 Sequence Connections Corresponding to Figure 10-14 . . . . . . . . . . . . . . . . . . . . .10-30
10-16 Sequence Circuits for Loads on Two-Phase System . . . . . . . . . . . . . . . . . . . . . . . .10-32
xxxvii
10-17 Sample System for Two-Phase Example Calculations . . . . . . . . . . . . . . . . . . . . . . 10-33

10-18 Raw Data Files for Two-Phase System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-36
10-19 Data Listings for Two-Phase System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-38
10-20 Initial Condition Power Flow Solution for Two-Phase Sample System . . . . . . . . . . 10-41
10-21 Output from Short-Circuit Solution Reporting Corresponding to Figure 10-19 . . . . 10-42
10-22 Simple L-G Fault at Bus 300 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-43
10-23 Simple Ground Connection at Bus 330 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-44
10-24 Secondary System Grounded at Buses 330 and 550 . . . . . . . . . . . . . . . . . . . . . . . 10-45
10-25 Current Flows (per unit) from Figure 10-24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-46
10-26 Home Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-57
10-27 Faults at Home Bus for Each Outgoing Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-58
10-28 Home Bus and Open Line End Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-59
10-29 Clarification of Home Bus and < n > Levels Away . . . . . . . . . . . . . . . . . . . . . . . . . 10-60
10-30 Location of Bus 151 and Buses One Level Away in savnw.sav . . . . . . . . . . . . . . . 10-63
10-31 Report Output at the Home Bus ( 0 level) for a 3-Phase Fault . . . . . . . . . . . . . . . . 10-65
10-32 Current Flows 1 Level Away from Home Bus 151 for Three-Phase Fault . . . . . . . 10-66
10-33 Fault Summary Report with 3-Phase Fault on Bus 151 . . . . . . . . . . . . . . . . . . . . . 10-67
10-34 Results for Three-Phase and Single Phase fault at bus 151 . . . . . . . . . . . . . . . . . 10-69
10-35 Summary and Detailed Report of ANSI Fault Calculation . . . . . . . . . . . . . . . . . . . 10-76
10-36 Transient Phase Currents in Suddenly Applied Short Circuit . . . . . . . . . . . . . . . . . 10-90
10-37 Forms of Expression of Fault Current at Instant of Circuit Breaker Opening . . . . . 10-91
10-38 Relationships Between Machine Time Constants in Radial System . . . . . . . . . . . . 10-95
10-39 Relationship of Outputs to Offset Fault Current Wave (amps) . . . . . . . . . . . . . . . 10-101
10-40 Examples of Unbalanced Network Conditions Requiring a PI Equivalent . . . . . . 10-104
10-41 Output Report for pi-Equivalent shown in Figure 10-42 . . . . . . . . . . . . . . . . . . . . 10-107
10-42 Diagram of pi-Equivalent and the Branch Power Flow Data . . . . . . . . . . . . . . . . . 10-108
11-1 Example Output From Activity POUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8
11-2 Power Flow Output for Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
11-3 Wide Format Power Flow Output including Branch Currents . . . . . . . . . . . . . . . . . 11-14
11-4 Example Output From Activity LOUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18
11-5 Example Output From Activity LAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-27
11-6 Example of Load Reduction Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-36
11-7 Area Total Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-42
11-8 Owner Totals Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-45
11-9 Zone Totals Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-51
11-10 Inter-Area Flows by Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-54
11-11 Inter-Zone Flows by Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-56
xxxviii
11-12 Inter-Area Tie Line Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-58

11-13 Inter-Zone Tie Line Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-60
11-14 Report for Branch Loadings, All Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-65
11-15 Report on Transformer Overloads Based on 80% of RATE A . . . . . . . . . . . . . . . . .11-67
11-16 Report on Transmission Line Overloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-70
11-17 Output Format for Branch Overloads Based on 80% of Rate A . . . . . . . . . . . . . . . .11-74
11-18 Report for Voltages Out-of-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-76
11-19 Capability Curve Example for savnw.sav Case . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-80
11-20 Report Output for Reactive Power Checking with Capability Curve . . . . . . . . . . . .11-83
11-21 Generator Bus Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-88
11-22 Report Tabulation for Machine Terminal Conditions in savnw.sav File . . . . . . . . . .11-93
11-23 Assumed Capability Curve of Activity GEOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-94
11-24 Regulated Bus Report from the Savnw.sav Power Flow Case . . . . . . . . . . . . . . . .11-99
11-25 Controlling Transformers Report for savnw.sav Power Flow Case . . . . . . . . . . . .11-103
11-26 Result of the Compare Case Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-106
11-27 Plotting Device Popup Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-126
11-28 STANDARD Font . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-133
11-29 LOWERCASE Font . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-134
11-30 ASCC Fault Analysis Annotation Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-143
11-31 Fault Analysis Annotation Dialog, Total Fault Currents . . . . . . . . . . . . . . . . . . . . .11-144
11-32 Slider Diagram, Total Fault Currents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-145
11-33 Fault Analysis Annotation Dialog, Contributions at Home Bus . . . . . . . . . . . . . . .11-146
11-34 Slider Diagram, Fault Current Contributions at Home Bus . . . . . . . . . . . . . . . . . .11-147
11-35 Fault Analysis Annotation Dialog, Selected Fault . . . . . . . . . . . . . . . . . . . . . . . . .11-148
11-36 Slider Diagram, Fault Currents for a Selected Fault . . . . . . . . . . . . . . . . . . . . . . .11-149
11-37 Fault Analysis Annotation Dialog, Line Outage Fault . . . . . . . . . . . . . . . . . . . . . . .11-150
11-38 Slider Diagram, Line Outage Fault Currents . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-151
11-39 Fault Analysis Annotation Dialog, Three Winding Transformer Winding Outage . .11-152
11-40 Slider Diagram, Three Winding Transformer Winding Outage Fault Currents . . . .11-153
11-41 Fault Analysis Annotation Dialog, Three Winding Transformer, 1st Line End Fault . .11-
154
11-42 Slider Diagram, Three Winding Transformer, 1st Line End Fault Currents . . . . . .11-155
11-43 Fault Analysis Annotation Dialog, Three Winding Transformer, 2nd Line End Fault . .11-
156
11-44 Slider Diagram, Three Winding Transformer Winding, 2nd Line End Fault Currents .11-
157
11-45 Fault Analysis Annotation Dialog, Unbalanced Fault Currents . . . . . . . . . . . . . . .11-158
11-46 Slider Diagram, Selected Fault, Unbalanced Fault Currents . . . . . . . . . . . . . . . . .11-159
xxxix
12-1 Time Regimes Considered in Power System Simulations . . . . . . . . . . . . . . . . . . . . 12-2

12-2 Standard Power Flow Model and Norton Equivalent Used for Switching and Dynamic
Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
12-3 Switching Analysis – Sequence of Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
12-4 Relationship Between PSS®E Generator Equivalent and Thevenin Equivalent . . . 12-10
12-5 Change of Generator Boundary Condition for Switching . . . . . . . . . . . . . . . . . . . . 12-11
12-6 Re-allocation of Constant MVA Bus Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15
12-7 Reference Load Values in Savnw.sav Power Flow Case . . . . . . . . . . . . . . . . . . . . 12-17
12-8 Converted Loads Re-allocations as per Figure 12-7 . . . . . . . . . . . . . . . . . . . . . . . 12-17
12-9 Load Collection and Re-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19
12-10 Reconstruction of Loads Based on Global 10% Reallocation . . . . . . . . . . . . . . . . . 12-20
12-11 Equipment Connected at Bus, i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23
12-12 Equivalent Circuit for Node i of Transmission Network Model . . . . . . . . . . . . . . . . 12-24
12-13 Example – Circuits from Bus 151 to Bus 152 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-29
12-14 Opening a Line at One End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-30
12-15 Producing an Open Line End with Activity SPLT . . . . . . . . . . . . . . . . . . . . . . . . . . 12-30
12-16 Motor Starting Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-32
12-17 Bus Based Report Following Motor Starting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-32
12-18 Calculation of Branch Currents Flowing into a Bus Faulted through Zero-Impedance 12-
33
12-19 Bus Based Output for Three-phase Balanced Fault on Bus 3006 . . . . . . . . . . . . . 12-34
13-1 Results of Impact Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6
14-1 Generator and Area Designations from the savnw.sav Case . . . . . . . . . . . . . . . . . 14-10
14-2 Conventional Power Flow Generator Voltage Regulation . . . . . . . . . . . . . . . . . . . . 14-11
14-3 Feasible Clamp Region for Non-zero t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13
14-4 Reactive Capability, Qgen vs. Pgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-17
14-5 Alternate Generator Model (Injection Behind Synchronous Reactance, Xd) . . . . . 14-17
14-6 Is vs. Efd Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-18
14-7 Vector Arithmetic for Deriving Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-19
14-8 Logarithmic Barrier Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25
14-9 Objective Function with Barrier Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27
14-10 Effects of Reducing the Barrier Coefficient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29
14-11 Quadratic Approximation to Combined Objective . . . . . . . . . . . . . . . . . . . . . . . . . . 14-30
14-12 Diminishing the Barrier Coefficient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33
16-1 Response File Recorded by PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9
16-2 Python File Recorded by PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9
21-1 Dynamic Simulation Basic Logic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-2
21-2 Branch Flow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-36
xl
21-3 Bus Frequency Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-38

21-4 Multiple Bus Frequency Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-39
23-1 Simple Excitation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-12
23-2 Basic DEMOEX Model Routine (Part 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-16
23-5 FLECS Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-18
23-6 Basic DEMOBL Model Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-26
25-1 Sample Scenario File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-2
26-1 PSS®E Basis Node-breaker Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-2
26-2 Automatic Substation Node-breaker Topology Generator Dialog . . . . . . . . . . . . . . .26-3
26-3 Bus-branch View of a Bus with Underlying Node-breaker Topology . . . . . . . . . . . . .26-4
26-4 Detailed node-breaker view linked to the Bus-branch View . . . . . . . . . . . . . . . . . . . .26-4
26-5 Bus Connection in Bus-branch Model versus Terminal Connections in the Substation
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-5
26-6 Sectionalized Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-6
26-7 Topological Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-7
26-8 STREE Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-7
26-9 STREE errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-8
26-10 SLIST activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-9
26-11 List Substation Data report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-10
26-12 SPOUT activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-10
26-13 Substation Flow report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-11
C-1 Graphics Character Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-20
xli
xlii
List of Tables
Table P-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Table 2-1. PSS®E File Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
Table 2-2. Summary of PSS®E Input Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4
Table 2-3. Restorable Data Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6
Table 2-4. PSS®E Data File Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10
Table 2-5. PSS®E Subdirectories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-16
Table 2-6. PSS®E Paths and Default Master Directory . . . . . . . . . . . . . . . . . . . . . . . . . .2-18
Table 2-7. Reserved Filenames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19
Table 2-8. PSS®E Paths and Default Master Directory . . . . . . . . . . . . . . . . . . . . . . . . . .2-20
Table 2-9. PSS®E Default Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-20
Table 3-1. Standard Maximum PSS®E Program Capacities . . . . . . . . . . . . . . . . . . . . . . .3-4
Table 3-2. Saved Case Specific PSS®E Program Option Settings . . . . . . . . . . . . . . . . . .3-7
Table 3-3. User Specific PSS®E Program Option Settings . . . . . . . . . . . . . . . . . . . . . . .3-11
Table 3-4. Installation Dependent Option Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11
Table 3-5. Program Parameter Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12
Table 3-6. WINDOWS.PRM Parameter Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12
Table 3-7. Font Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14
Table 3-8. Font Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14
Table 4-1. Interrupt Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
Table 5-1. Branch Parameter Data Check Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-90
Table 6-1. Available Iteration Schemes in PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2
Table 6-2. Power Flow Iteration Acceleration Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
Table 6-3. Power Flow Convergence Tolerances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
Table 6-4. Available Automatic Adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5
Table 6-5. Transformer Tap Adjustment Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
Table 6-6. Power Flow Solution Activities—Selection Guide . . . . . . . . . . . . . . . . . . . . . . .6-9
Table 6-7. Inertial Power Flow Solution Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-70
Table 6-8. Deterministic Reliability Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-77
Table 6-9. AC Contingency Solution Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-84
Table 6-10. AC Contingency Single Run Report Options . . . . . . . . . . . . . . . . . . . . . . . . . .6-93
Table 6-11. AC Contingency Multiple Run Report Options . . . . . . . . . . . . . . . . . . . . . . . .6-112
Table 6-12. AC Corrective Action Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-122
xli
Table 6-13. AC Corrective Action Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-123

Table 6-14. AC Corrective Action Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-127
Table 6-15. Weighting Functions and Factors of Controls . . . . . . . . . . . . . . . . . . . . . . . . 6-129
Table 6-16. PSCOPF Solution Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-135
Table 6-17. Multi-Level AC Contingency Solution Power Flow Control Options . . . . . . . 6-150
Table 6-18. Multi-Level AC Contingency Solution Multiple Contingency Analysis Options . . 6-
151
Table 6-19. Classification of Contingency Evaluation Based on Power Flow Solution . . 6-154
Table 6-20. Types of Problems Qualifying a Category I Contingency as a Failure . . . . . 6-154
Table 6-21. Groups within Contingency List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-155
Table 6-22. Multi-Level Contingency Solution Tripping Simulation Options . . . . . . . . . . 6-158
Table 6-23. Multi-Level Contingency Solution Corrective Actions Options . . . . . . . . . . . 6-165
Table 6-24. Running Modes for Multiple Contingency Analysis . . . . . . . . . . . . . . . . . . . . 6-168
Table 6-25. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-171
Table 6-26. Probabilistic Reliability Assessment Options . . . . . . . . . . . . . . . . . . . . . . . . 6-189
Table 6-27. Substation Reliability Assessment Options . . . . . . . . . . . . . . . . . . . . . . . . . 6-201
Table 6-28. PV Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-216
Table 6-29. QV Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-224
Table 6-30. Sensitivity Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-242
Table 8-1. Contingency Ranking Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Table 8-2. Linearized Network Contingency Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-43
Table 8-3. DC Corrective Actions Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-49
Table 8-4. Transmission Transfer Limit Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . 8-54
Table 8-5. Sequential Participation Interchange Limits Options . . . . . . . . . . . . . . . . . . . 8-68
Table 8-6. Interchange Limits Analysis Options for Two Opposing Systems . . . . . . . . . 8-79
Table 9-1. Network Equivalence Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
Table 9-2. Electrical Equivalencing of Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
Table 9-3. Radial Bus Equivalencing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
Table 9-4. Radial Bus Equivalencing Options, with Exception . . . . . . . . . . . . . . . . . . . . 9-26
Table 9-5. Net Boundary Bus Mismatch Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28
Table 9-6. Short Circuit Equivalent Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-35
Table 10-1. Automatic Sequencing Short Circuit Calculation Options . . . . . . . . . . . . . . . 10-52
Table 10-2. Short Circuit Calculation Options for IEC 60909 . . . . . . . . . . . . . . . . . . . . . . 10-82
Table 10-3. Breaker Duty Calculation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-97
Table 10-4. Separate Pole Circuit Breaker Calculation Options . . . . . . . . . . . . . . . . . . 10-105
Table 11-1. Summary of Available PSS®E Power Flow Reports . . . . . . . . . . . . . . . . . . . . 11-1
Table 11-2. Information Provided in Interchange Reports for Areas and Zones . . . . . . . 11-52
Table 11-3. Subsystem Accumulations in Activity CMPR . . . . . . . . . . . . . . . . . . . . . . . 11-106
Table 11-4. Case Comparison Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-109
Table 11-5. Case Comparison Specifications, Bus Data Checks . . . . . . . . . . . . . . . . . 11-111
xlii
PSS®E 34
Table 11-6. Case Comparison Specifications, Branch Data Checks . . . . . . . . . . . . . . .11-114

Table 11-7. Case Comparison Specifications, AC Tie Branch Data Checks . . . . . . . . .11-121
Table 11-8. ASCC Fault Analysis Annotation Options . . . . . . . . . . . . . . . . . . . . . . . . . .11-142
Table 11-9. PSS®E to Excel Export Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-159
Table 12-1. Results of Line Open End Balanced Switching Calculation . . . . . . . . . . . . . .12-31
Table 13-1. Example of Transaction Data for Two Transactions . . . . . . . . . . . . . . . . . . . .13-2
Table 13-2. Line Loading Relief Calculator Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8
Table 14-1. Local Generator Voltage Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-10
Table 14-2. Optimal Power Flow (OPF) Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-39
Table 14-3. Optimal Power Flow (OPF) Parameters - General Options . . . . . . . . . . . . . .14-41
Table 14-4. Optimal Power Flow (OPF) Parameters - Tolerance Options . . . . . . . . . . . .14-44
Table 14-5. Optimal Power Flow (OPF) Parameters - Control Options . . . . . . . . . . . . . .14-47
Table 14-6. Optimal Power Flow (OPF) Parameters - Reporting Options . . . . . . . . . . . .14-48
Table 14-7. Problem Size Label Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-50
Table 14-8. Jacobian Column Label Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-54
Table 14-9. Jacobian Row Label Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-54
Table 14-10. Variable State Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-57
Table 14-11. Optimal Power Flow (OPF) Data Output Options . . . . . . . . . . . . . . . . . . . . .14-59
Table 15-1. Load-Related Model Subsystem Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-17
Table 15-2. Activity CHAN Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-31
Table 15-3. Dynamic Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-44
Table 15-4. PSS®E Models Unavailable for Extended Term SimulationPOM_DynSim.fm .15-
90
Table 21-1. Dynamic Simulation Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-5
Table 24-1. Supported Event Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-1
Table 24-2. Dynamics Event Study Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-2
Table 24-3. Event Item Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-3
Table A-1. PSS®E Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Table C-1. Options For Branch Coordinate Data Records . . . . . . . . . . . . . . . . . . . . . . . . C-8
Table C-2. Special Options for Open Ended Radial Lines . . . . . . . . . . . . . . . . . . . . . . . . C-9
xliii
xliv
Preface
The Siemens PTI Power System Simulator (PSS®E) is a package of programs for studies of power
system transmission network and generation performance in both steady-state and dynamic condi-
tions. PSS®E handles power flow, fault analysis (balanced and unbalanced), network equivalent
construction, and dynamic simulation.
PSS®E is bundled with a number of program sections that vary from user to user. The base config-
uration for all installations of PSS®E is made up of the Power Flow and Libraries program sections.
Other available program sections are:
• Optimal Power Flow (OPF)

• Fault Analysis (Short Circuit)
• Dynamic Simulation
• Dynamics Model Library Source
• Transmission Line Constant Calculation (TMLC) and Line Properties (LINEPROP)
• Linear System Dynamic Analysis (LSYSAN)
• WECC Data Conversion Programs
• Graphic Model Builder (GMB) - installed separately
• NEVA Eigenvalue Analysis - installed separately
PSS®E achieves its broad capabilities by a highly modular structure and, in dynamic simulation, by
encouraging the engineer to introduce user-written subroutines describing the problem of interest
whenever the standard calculation procedures are not appropriate. PSS®E is not set up to solve
any specific problem. Rather, it is a carefully optimized data structure associated with a comprehen-
sive array of computational tools that are directed by the user in an interactive manner. By applying
these tools in the appropriate sequence, the engineer can handle a wide range of variations on the
basic power flow and stability theme.
PSS®E is designed on the premise that the engineer can derive the greatest benefit from compu-
tational tools by retaining the most intimate control over their application. The interactive structure
of PSS®E, therefore, encourages the user to examine the results of each step in the computation
process before proceeding to the next. This assists the engineer in understanding the engineering
capabilities of these tools without having to become a master of the mathematical fine points of
computation. The execution of standard studies such as power flow and basic transient stability on
PSS®E requires no programming expertise. An engineer who is able to translate a problem formu-
lation into simple FORTRAN statements will find, however, that PSS®E can handle virtually any
system dynamics problem for which the requisite equipment models and input data can be
produced.
The standard maximum capacities of PSS®E in terms of buses, branches, generators, and other
system components are the same in all of its activities. Table 3-1, Standard Maximum PSS®E
Program Capacities lists the dimensional capacities of the various PSS®E arrays at the standard
size levels (1,000, 4,000, 12,000 and 50,000 buses) and at the largest size level (200,000 buses).
Section 3.3 Environment provides details setting dimensional capacities of the various PSS®E
i
PSS®E 34.2
arrays at size levels other than the four standard size levels and the interpolation, extrapolation, and
rounding down (the I/E or S column of Table 3-1) calculations made at non-standard bus size levels.
All PSS®E manuals and reference guides are in PDF format and readily available and viewable with
the Adobe Acrobat Reader (freely downloadable from the Adobe web site).
The PSS®E manuals and reference guides are located on the installation CD in the DOCS folder.
If the option to install documentation with PSS®E is selected during the PSS®E installation, a
shortcut to the PSS®E documentation will be placed on the PSS®E Start menu.
Chapters 1 through 4 of this manual describe the interface of PSS®E and the user with the
computer’s operating system. Chapters 5 through 17 contain detailed information on the operation
of each PSS®E activity. Chapter 18 defines the procedures involved in establishing a system model
for dynamic simulation runs. Chapter 19 contains samples of some of the more commonly used
PSS®E data input files. Chapter 20 documents the requirements of user-written dynamic models.
Chapter 21 describes the use of event studies in which the series of events (e.g., faults, switchings,
etc.) to be employed in a dynamics or power flow study are specified, and Chapter 22 describes the
use of scenarios to identify the set of data files to be used in a given study.
The PSS®E Program Operation Manual assumes throughout that the reader is familiar with the
content of the PSS®E Program Application Guide. This manual and all its references to the
PSS®E Program Application Guide apply only to the standard form of the PSS®E package.
Contacting Siemens PTI for Support

If after consulting the documentation and online help you find that additional assistance with PSS®E
is needed, you may contact Siemens PTI via any of the following methods (please send a thorough
description of the problem or question, including files):
• Send an e-mail to technical support at [email protected].

• Send a fax to (518) 346-2777, attention PSS®E Support.
• Call the telephone support number between the hours of 8:00 a.m. and 5:00 p.m.
Eastern Time, Monday through Friday. Dial (518) 395-5075 and select option 1 for
PSS®E support.
• Visit the Siemens PTI Web Site at www.siemens.com/power-technologies and the PSS®E
User Support Web Page.
Please note that access to the PSS®E User Support Web Page and to technical PSS®E
support is only available to those users whose companies have purchased or renewed their
PSS®E maintenance and support agreement for the current calendar year.
Submitting Bug Reports and Feature Requests

Bug reports and feature requests should be submitted directly to PSS ® E support at
[email protected]. Please provide as much detail as possible. If submitting a
report for a potential bug please include the steps taken, along with pertinent data files and scripts
so that we may accurately reproduce the problem. If an issue does turn out to be a program bug,
one of the following priorities will be assigned to it:
• High priority is given to issues that cause the program to crash or produce incorrect
results with no published work around.
ii
PSS®E 34.2
• Medium priority is given to issues that cause incorrect functionality, however the
problem can be remedied by a published work around.
• Low priority is given to those issues that do not fall into the above categories, or are
purely cosmetic in nature.
Every effort is made to address high and medium issues in a PSS®E point release. Some low
priority items may also be include in a point release although this cannot be guaranteed.
Feature requests are evaluated on the basis of whether it benefits a wide majority of PSS®E users.
If it does, it will likely be considered for implementation in a point release or major release of PSS®E.
If several users have the same feature request, the feature may sit higher in the queue than others
for implementation in PSS®E.
Document Conventions
The following conventions are used in PSS®E manuals:
Table P-1.
Examples Description
Power Flow > Solution > Parameters… Navigation path in a PSS®E GUI menu
[Solution Parameters] dialog Interactive dialog in Graphical User Interface (GUI)
[Spreadsheet]
Interface windows and views
[Diagram]
SOLV,OPT User entry the line mode in the Command Line Interface
LIST (CLI) dialog
[F10], [Enter] Keys found on a standard computer keyboard

[OK], [ … ], [Close] Action buttons available on a dialog
GUI toolbar button that starts an activity sequence
Set tap ratios to Unity Activity option
Print outaged branches Program option
GENERATOR CONVERSION COMPLETED Message sent to Progress tab

<quantity>, <bus number> Variable in message sent to Progress tab
ENTER OUTPUT DEVICE CODE: Line mode dialog request/response
Progress tab, Report tab Activity results displayed in [Output] view
OPEN PSS®E activity name with hyperlink to source information
Section 5.15.2 Removing Outaged Equip-
Cross-reference with hyperlink to source information
ment in a Subsystem, Figure 12-4
Creating a Power Flow Raw Data File Short reference with hyperlink to source information
iii
PSS®E 34.2
Table P-1.
Examples Description
®
PSS E Program Operation Manual, Section
20.14, Listing Saved Case or Snapshot Full reference with hyperlink to source information
Files
Indicates report output example clipped to fit the page
PSS®E Program Application Guide PSS®E manual reference
Indicates additional information of interest.
Indicates important information.
n.a. Abbreviation meaning "not applicable".
iv
Chapter 1
Overview
Chapter 1 - Overview
1.1 PSS®E Functional Description

PSS®E is an integrated set of computer programs that handles the following power system analysis
calculations:
• Power flow and related network analysis functions.

• Balanced and unbalanced fault analysis.
• Network equivalent construction.
• Dynamic simulation.
PSS®E is structured around its own array address space (called the working case) along with a
carefully designed set of temporary data files (called the temporary files). These data structures
are set up in a way that optimizes the computational aspects of the key power system simulation
functions: network solution and equipment dynamic modeling. The working case and/or one or
more of the temporary files are operated upon by a comprehensive set of functional program
modules called activities. Each activity performs a distinct computational, input, output, or data
manipulation function needed in the course of power flow, short circuit, equivalent construction, or
dynamic simulation work.
PSS®E is entered by starting its master program module (see Section 3.2 Starting PSS®E: Starting
PSS®E). The master module immediately invites the user to select an activity. The selected activity
is immediately executed, performing its processing operation on the working case and/or one or
more of the temporary files. The activity retains control until either:
• Its processing is successfully completed.

• Its processing encounters an error condition.
• It is interrupted and terminated by the user.
Each of these conditions returns control back to the master module, leaving the working case and
the temporary files such that they reflect the results of the processing by this activity. The master
module again invites the user to select another activity. Any activity may be selected at any time,
but the determination of which activities are meaningful must be made by the user on the basis of
the recent sequencing of activities and the present condition of the working case and the temporary
files.
Complementing the working case and the set of temporary files, each user will generate a library of
power flow Saved Cases and dynamic simulation Snapshots. These, in conjunction with the
temporary files, form a working database. The PSS®E user quickly becomes adept at manipulating
1-1
Overview PSS®E 34.2
PSS®E Operations Program Operation Manual
these database elements (i.e., files), resulting in the efficient management and execution of any
power system analysis studies.
Refer to Additional Resources for PSS®E for details on PSS®E auxiliary programs.
1.2 PSS®E Operations

The use of PSS®E requires several types of operation on its host computer. Among these are:
• Creating and filling files to be used as input files to PSS®E.

• Compiling and linking the connection subroutines, CONEC and CONET, and any user-
written dynamic simulation equipment models into the main body of PSS®E.
• Running the PSS®E programs.
• Running the auxiliary programs.
The first two of these operations require the use of commands and functional programs of the host
computer’s operating system. The user of PSS®E does not need to be an expert in the use of the
host’s operating system, but a brief study of those computer system manuals covering basic
terminal keyboard and text editor operations will generally be beneficial.
The PSS®E user needs only a very minimal knowledge of computer system protocol in order to
make productive use of the PSS®E package. The user does not need to become proficient with a
complicated computer command language and is therefore able to apply effort to the task at hand:
solving the engineering problem. The casual PSS®E user will need to become comfortable with the
basic capabilities of the text editor and a small subset of system keyboard commands. More
advanced users will find it to their advantage to familiarize themselves with the various disk file and
related utility programs; a fundamental understanding of the host computer’s file system organiza-
tion will also be useful.
The purpose of this manual is to specify input data formats for PSS®E, to present detailed descrip-
tions on the input requirements and operation of each PSS®E activity, and to assist the user in
interpreting PSS®E’s output messages.
1.3 Extending PSS®E with User DLLs

PSS®E advanced features involving user-written code are implemented through the use of user-
written dynamically linked libraries, or DLLs. When the user starts PSS®E, the program searches
for the user-written DLL by name. These library names are:
DSUSR.DLL This library may contain CONEC, CONET, and/or user-written dynamics mod-
els.
IPLUSR.DLL This library may contain user-defined routines for IPLAN (see IPLAN Program
Manual).
PSSUSR.DLL This library may contain a user-written USERAC subroutine that will be called
the USER activity.
If you have a user-written DLL in your directory, or anywhere on the load path, PSS®E will automat-
ically find it and load it. For example, say you build a DSUSR.DLL in C:\WORKING\ONE. If you start
PSS®E with C:\WORKING\ONE set as your working directory, your custom DSUSR.DLL will be
loaded. If, on the other hand, you start PSS®E with C:\WORKING\TWO set as your working direc-
tory (and C:\WORKING\ONE is not on the load path), then DSUSR.DLL will not be loaded.
1-2
PSS®E 34.2 Overview
Program Operation Manual PSS®E Support for Building User DLLs
You can modify your PSS®E installation to always have your customized DLL’s available by placing
them in the PSSBIN directory of your PSS®E installation. Files that are in PSSBIN will always be
located by PSS®E, and always located first should a DLL with the same name be anywhere else
on the load search paths.
If your results are not what you expect, first make certain that you are loading the correct copies of
the DLL(s) you wish to use.
If you create a customized DLL for the use of PSS®E, you can create a corresponding icon or
shortcut in order to use that DLL. The new icon or shortcut should identify as the working direc-
tory the directory that contains the customized DLL. Alternatively, if you choose to start
programs from the PSS®E 33 Command Prompt, simply change directories into your working
directory before starting the program and the correct DLL will be loaded.
Instead of creating new shortcuts, it is possible to change the working directory (i.e., the Start
In directory) of the existing PSS®E 33 shortcuts. PSS®E 33 includes a program called
STARTIN, which should be run from the PSS®E 33 Command Line. When executed, this
program (after prompting) will change the working directories of all standard (non-custom)
shortcuts associated with PSS®E 33 to be the current directory (i.e., the directory from which
the STARTIN command was given.) The STARTIN command may be used to switch the
working directories as frequently as desired. To return the working directories to the original
settings, use the shortcut PSSE-33 Example Directory in the PSS®E Utilities menu, to bring
up a command prompt and give the STARTIN command.
1.4 PSS®E Support for Building User DLLs
COMPILE Batch file used to compile the connection subroutines CONEC and CONET.
Batch file used to link the compiled code of the user's connection subroutines into
CLOAD4
DSUSR.DLL in the user's directory, used by the PSSDS4, the Dynamics entry point.
A program, with a GUI, used for building a User DLL. By default it combines the func-
Createusrdll
tionality of COMPILE and CLOAD4, below, but can be used to create any DLL.
Batch file used to compile and link user-written routines into IPLUSR.DLL in the user’s
CLIPLU
directory, used by IPLAN and by power flow and dynamics entry points.
Batch file used to compile and link a user activity into PSSUSR.DLL in the user’s direc-
CLPSSUSR
tory, used by the power flow and dynamics entry points.
PARSE32 Utility program used by CLOAD4.BAT
PARSEXT Utility program used by CMDLUSR.BAT.
1-3
PSS®E Support for Building User DLLs Program Operation Manual
1.4.1 COMPILE
The compiling file generated by activities DYRE and SRRS for compiling the connection subrou-
tines CONEC and CONET is in the form of a BATCH file. The file can be named anything, but the
sample provided in the EXAMPLE directory is named COMPILE; so we will use that name here.
The name of this file must have the extension .BAT. If no extension is specified when this file is
created, the extension .BAT is automatically appended to the filename. The compiling file is
executed by entering the command:
filename.bat
which will compile the CONEC and CONET subroutines. The compilation must be run from a
PSS®E-33 Command Prompt. When the compilation is complete, you must execute CLOAD4 at
the PSS®E-33 Command Prompt to create a new DSUSR.DLL file.
In addition to compiling CONEC.FLX and CONET.FLX, the PSS®E-generated COMPILE.BAT file

will allow a single user written-model to be compiled at the same time. If you have such a model,
which must be written in the FLECS language, simply specify it on the COMPILE command line,
e.g.:
COMPILE MY_MODEL.FLX
The result will be a correctly compiled MY_MODEL.OBJ, ready to process with the CLOAD4 step.
The CMDLUSR command can be used if you have more than one user-written model, or if some of
the files are not in FLECS. This command, new for PSS®E-27, can compile any number of FLX,
FOR, F90, F, C, and CPP files at one time. For example, the command:
CMDLUSR MY_MODEL.FLX EXTRA1.FLX EXTRA2.FOR
will FLECS and compile MY_MODEL.FLX and EXTRA1.FLX, and then compile EXTRA2.FOR. The
object files MY_MODEL.OBJ, EXTRA1.OBJ and EXTRA2.OBJ should be generated in the current
directory.
When compiling FLX, FOR, F90, and F files, CMDLUSR will search the current directory and
the PSSLIB directory in an attempt to find any INCLUDEd files or MOD files. If other directories
are to be searched, make sure that your INCLUDE environment variable defines those extra
directories.
When compiling C and CPP files, only the current directory will be automatically searched for
#include files. Therefore, you will almost certainly need to set your INCLUDE variable appro-
priately before compiling such files!
The top section of the CMDLUSR.BAT file discusses the INCLUDE variable in more detail.
1.4.2 CLOAD4
CLOAD4 is a batch program that is delivered with PSS®E. It can be run from the PSS®E-33 Com-
mand Prompt. The CLOAD4 linking procedures create a custom DSUSR.DLL, which allows for
inclusion of user- written models in the dynamics program. The CLOAD4 command will automati-
cally link in the CONEC.OBJ and CONET.OBJ files. Up to 35 additional object files may be specified
on the CLOAD4 command line, for example:
CLOAD4 MYMDL.OBJ E:\PSSE31W\PSSLIB\MOREMDLS.OBJ

The result of running CLOAD4 is a new DSUSR.DLL.
1-4
1.4.3 CreateUsrDll
CreateUsrDll is a GUI driven application that is delivered with PSS®E. It can be run from the
shortcut in the Start Menu.
CreateUsrDll combines the functionality of COMPILE and CLOAD4. It can handle several types of
source files, and includes a file browser so that input files can be located in any directory. It can
create a dll of any name, although it defaults to DSUSR.DLL. It analyses the input files for external
names and exports them for you (CLOAD4 only exports the CONEC and CONET program names);
names must be exported in order to be referenced directly from outside of the DLL.
Use the Browse buttons to locate the files you want to include. These will be added to a list that is
shown to you. You can remove files from that list later if you wish. If you wish to create a file other
than DSUSR.DLL, the output file name is shown at the top of the GUI and can be changed. Once
all your files are listed, use the “Compile + CreateDLL” button at the bottom of the GUI to build the
file.
1.4.4 CLIPLU
CLIPLU provides a means for incorporating user-written Fortran routines into IPLAN. If your license
includes IPLAN, nine dummy files (USREX1.FOR through USREX9.FOR) are placed in the
IPLUSR subdirectory of PSS®E. You may edit these files to incorporate your own routines and, in
addition, you may include routines on the command line as with CLOAD4. CLIPLU will compile and
link these routines to create a new IPLUSR.DLL.
1.4.5 CLPSSUSR
CLPSSUSR enables the user to include a new activity in PSS®E. By editing USERAC.FOR (found
in the PSSLIB subdirectory of PSS®E) and then running CLPSSUSR, you can compile and link your
new activity into a new PSSUSR.DLL. Starting PSS®E from the directory containing PSSUSR.DLL
will automatically include the new user function, which can then be executed by the API routine
USER or the line mode command USER.
1.4.6 DSUSR Visual Studio solution file

Interactive debugging can be a very helpful tool when developing any program. The simple tools
described above do not provide access to interactive debugging.
The project supplied, and described below, can be used if the version of Microsoft Visual Studio and
Intel Visual Fortran used to build PSSE are installed. A knowledgeable person can modify this
project for other versions, for other dll's, or copy the files to use in another directory location. The
instructions provided here only account for the circumstance where the project is used as is where
it is installed and with the expected versions of the software. This documentation does not explain
how to perform debugging tasks using Microsoft Visual Studio.
All directory references are relative to the installed location of PSSE, usually "C:\program
files\pti\pssexx" where "xx" is the major release number of PSSE.
1-5
To use the DSUSR solution
1. Open dsusr\dsusr.sln (either double click on the file if you have the filetype associations
established, or start up Microsoft Visual Studio, select File > Open > Project/Solution and
navigate to the file).
2. The Microsoft Visual Studio GUI is composed of several windows. You should see one titled
"Solution Explorer". If you do not, go to the menu and select View > Solution Explorer.
3. In the Solution Explorer window you should see two projects, dsusr and dsusrlib. Select the
dsusr project.
a. Select "Project > Properties" from the menu.

b. Select "Debugging" under "Configuration properties".
c. In the field "Command" enter ..\pssbin\psse33.exe
d. In Environment enter the following: path=$(TargetDir);%path%
e. Check that Merge Environment is set to Yes.
f. In Command Arguments you can enter command line arguments, if you wish, such
as -buses 50000
g. In Working Directory you can set the working, or start-up, directory, if you wish (by
default it is the project directory). If you have data files that you plan to use in
testing, you may want to set this value to that directory.
h. Save changes by clicking OK.
4. In the Solution Explorer window now select the dsusrlib project.
a. Select the Source Files folder, and bring up the context menu (click the secondary
mouse button).
i. Select Add, then either:
1-6
ii. Select Existing Item.
1. Navigate to your source file and select it.
b. --- or ---
iii. Select New Item
1. Select source form (free or fixed).
2. Modify the Name and Location fields at the bottom of the form.
c. Repeat step (a) as many times as needed.

5. If necessary, make any code modifications needed.
6. Select "Build > Configuration Manager…" from the menu.
a. Select "Debug" in the "Active solution configuration" pull-down list. (there is a pull-
down list in the menu that is a shortcut to this).
1-7
b. Click Close.
7. Select Build > Build Solution (usually F7 will do this).
8. If there are errors, make corrections and repeat step (7).
9. Select Debug > Start Debugging from the menu (usually F5 will do this). This will cause the
program specified in Command (step 3c above) to run.
Notes:
• You may find, in some cases, that the above instructions tell you to set a value that is
already the current value of that field. This is not a problem; it is simply that those
values could have been changed by a prior use of Visual Studio.
• It is not necessary to copy your source files from wherever you would otherwise have
liked to keep them. In step 4 above you can navigate to wherever the files are.
• It is not necessary to copy your data files from wherever you would otherwise have liked
to keep them. In step 3g above you can set the working directory to wherever you like.
• If you have standard tests that you want to run, if you set them up in an automation file,
you can specify that as a command argument (3f, above)
• You will only be able to debug your code, i.e. the code that you compile and build in
your library.
• When looking at variable values in the debugger, you will not be able to see allocated
arrays that are exported from PSSE. You can, of course, write code to copy them to
local variables to assist in the debugging process.
• You are debugging, but starting an application that was not built for debugging (only
your new library is built for debugging, not PSSE itself). Therefore Visual Studio will put
up a messageBox and tell you that "Debugging information for 'psse33.exe' cannot be
found [...]"; this is informational and not an error - just hit Yes.
• As you work on your project you can add or remove source files, change the working
directory (step 3g), change the command line arguments (step 3f), or modify your code
(step 5). If you make changes or change files, rebuild your project (step 7). If you only
change parameters (working directory, command line, etc) you can run the program
(step 9) without rebuilding.
Common Questions
1. Can I make a copy of the dsusr project so that I can work with more than one dynamics set-
up?
a. Yes. Copy the entire dsusr tree. In fact, it is a fine idea to do that all the time and
leave the original dsusr tree in its original state for comparison purposes. It is eas-
iest if you copy it within the PSSE installation. The projects do not care what the
name of the directory tree is (i.e. whether it is dsusr or not). If you move the project
outside of the PSSE installation tree then there will several directory settings that
you will need to find and update.
2. I follow the directions but PSSE doesn't stop at a breakpoint in my program.
a. There are several possibilities:
1-8
i. You are looking at the wrong source. Check this by opening your source program
by double clicking on the file name as listed in Solution Explorer.
ii. PSSE has loaded a different dsusr.dll. Check this by looking at Help > Loaded
Libraries in PSSE. You should see an entry to dsusr.dll, and the directory reference
should be to dsusr\debug in your PSSE installation tree (or, if you have copied the
dsusr tree to, say, mydsusr, then mydsusr\debug should be there). If it is different,
you need to move/rename the file that it found, or change your system PATH.
iii. Are you running a function in PSSE that you are certain will call your model pro-
gram? Similarly, is your breakpoint set in a location that must be executed if the
model program is called?
3. My source file is FLECS (*.flx). How do I use that in the dsusr project?
a. We recommend converting your program to Fortran. If that is not practical, you can
do one of the following:
i. Use the CMDLUSR command (see section 1.4.1)
ii. Use CreateUsrDll (see section 1.4.3), enter your FLECS program under "Compile
Files" and select Compile.
iii. In each case add the resulting .f file to your project (see step 4 above). If you sub-
sequently change the FLECS source you will have to repeat the conversion (i.e.
recreate the .f file) but you will not have to add the .f file to the project again.
4. What is the significance of the settings in step 3 of the instructions?
a. The Command field (c) tells studio what program to run when instructed to "run" or
"debug". By default it attempts to run the product of the build, but dsusr.dll cannot
be run directly. Instead we instruct it to run the PSSE GUI.
• The Environment field can be used to override or set Environment variables
when "running" or "debugging". In this case, we set the PATH variable so
that PSSE will find the dsusr.dll file we just created.
• The Merge Environment field determines whether the variables that are
specified in the Environment box will be merged with the environment that
is defined by the operating system.
• The Command Arguments specify the Command Line Options for PSSE
(see Appendix D).
• The Working Directory specifies the working directory of the program being
debugged, relative to the project directory where your EXE is located. If you
leave this blank, the working directory is the project directory. This will be
the current directory when PSSE starts running.
5. Do we need to add all the custom code or only the code we are debugging into source folder
under dsuserlib? What about conec and conet?
a. No, you do not need to add all the custom code (i.e. user written models, possibly
supporting functions, maybe conec and conet) to dsusrlib, although it will probably
be simplest if you do. You can build any number of user libraries and load them all
in PSSE. If your dynamics data indicates a model is needed then it will search all
loaded libraries for it. However (1) all libraries other than dsusr.dll will have to be
loaded explicitly, i.e. you will have to tell PSSE to load the library whereas it looks
for and loads dsusr.dll automatically; (2) if you have custom code that you want
1-9
PSSE to use then you have to build it into a library - if not dsusr.dll then some other
library. Unless you already have a library of your other code, or have some other
reason to build them separately, you might have fewer steps if you just build them
all in dsusr.
1-10
Chapter 2
File System
The power system calculations applied by the PSS®E program system require large quantities of
Chapter 2 - File System
different types of data. Consequently, the user of PSS®E must have some familiarity with the file
structure of the host computer. The purpose of this chapter is to describe the relationship between
the PSS®E programs and the file system in sufficient detail to allow the engineer to effectively
perform studies using PSS®E without having to handle cumbersome program/file details.
2.1 Directories and Files Overview

To execute PSS®E (or any other program), the user must have a path to a directory or folder. A
directory may be viewed as a catalog of files that are somehow related (e.g., they apply to a specific
study). A directory may contain an unlimited number of files and subdirectories. PSS®E always
operates out of a working directory. By default this is the EXAMPLE subdirectory in the main PSS®E
directory.
It is perfectly reasonable, for example, to set up one directory for running the PSS®E programs (a
working directory) and another for the storage of base case power flow and dynamics data files.
Various other working directories may also be established in which to run PSS®E on a variety of
different studies or investigations, each with its own set of data files (see Section 2.7.1, Multiple
Working Directories).
The files containing input data for PSS®E and output, Saved Case and Snapshot Files generated
by PSS®E, may be located in the directory in which PSS®E is started up. However, this is not
required; they may be placed in another directory. See Section 2.4.2, Specifying Filenames for
further details.
If the user specifies a filename without an extension, PSS®E automatically appends a default file-
name extension to the specified filename. The three-character combination comprising the
extension is dependent upon the type of file being accessed and/or the host computer’s conven-
tions. See Section 2.4.1, File Usage for further details.
There are several types of files accessed by PSS®E for which a directory search sequence is auto-
matically applied if the file to be opened is not found in the user’s current directory. In these cases,
PSS®E then searches the user’s home directory and, if the file is not found there, it looks in the
appropriate subdirectory of the PSS®E master directory. Reference is made to this directory search
sequence throughout the remainder of this manual where the files to which it applies are discussed.
See Section 2.7.3, File Search Path Rules for further details.
2-1
File System PSS®E 34.2
The PSS®E Working Case and Temporary Files Program Operation Manual
2.2 The PSS®E Working Case and Temporary Files

Each PSS®E activity may operate upon the PSS®E working case and/or one or more of its tempo-
rary files.
A set of arrays in PSS®E’s address space contains a complete set of power flow data. The content
of these arrays is referred to throughout this manual as the working case. The working case is modi-
fied by the power flow activities and is always a valid working case even though its voltages may
not represent a solution of Kirchhoff’s laws.
Several PSS®E activities create and access one or more temporary files that are used strictly as
scratch files; each such file is deleted by the activity that created it prior to its termination. The user
of PSS®E does not need to be concerned with names and contents of these files.
There are, however, three temporary files that are often used to preserve the results of certain activ-
ities for subsequent use by other activities. Contents of the files are variable depending upon the
recent sequencing and context of activity executions. The user of PSS®E does not need to be
concerned with the specific contents of these files as long as the prerequisites listed for each activity
are observed. These temporary files are an integral part of the PSS®E package. The user never
needs to reference these files by name but must be aware that these files may be processed every
time PSS®E is used. The names and general functions of these temporary files are:
YMATnnn Created by the triangular factorization activity FACT, and used by the
triangularized Y matrix network solution activity TYSL, and the dynamic
simulation activities. It is also used as a scratch file by the Newton-
Raphson based power flow solution activities and the circuit breaker
duty analysis activity BKDY.
SEQDnnn Created by the sequence network setup activity SEQD, and used by
the multiply unbalanced network solution activity SCMU, and the sepa-
rate pole circuit breaker duty activity SPCB. It is also used as a scratch
file by the automatic sequencing short circuit calculation activity ASCC,
by the ANSI and IECS fault current calculation activities, and by the
three sequence equivalencing activity SCEQ.
SCMUnnn Created by the multiply unbalanced network solution activity SCMU,
and used by the unbalanced network solution output activity SCOP,
and by the short circuit data retrieval routines SCINIT, SC3WND,
SCBRN2, SCBUS2 and SCMAC2 described in PSS®E Application
Programming Interface (API).
When temporary files are created, < nnn > is set to a three-digit integer such that the filename is
unique in the directory in which it is created. See also Section 2.7.4, Temporary Files.
2.3 File Classes

The user of PSS®E must understand the categories of files that are used by PSS®E. PSS®E takes
full advantage of the file management capabilities of the host operating system. This allows PSS®E
to be used at all times without the need to select file assignments before it is started up. As a result,
the user has a great degree of flexibility in the use of files during an interactive problem-solving
session with PSS®E. The user can instruct PSS®E to read from or write into virtually any existing
file at any time, and can have PSS®E create a new file at any time that it is needed. The prerequisite
for full use of this capability is a sound understanding of the distinct classes of files used by PSS®E.
2-2
PSS®E 34.2 File System
Program Operation Manual File Classes
Note that a file class is a distinction imposed by PSS®E, not by the computer’s file manage-
ment system.
The two major types of files are:
1. Files created by the user – These include: files specifying data that is required by one or
more of the PSS®E activities; and batch and program control files used for directing the
execution of PSS®E.
2. Files created by PSS®E – These include: files generated when the user’s working case and
dynamics working memory are preserved; and output and results files that are either
requested by the user or automatically generated.
The classes of files used by PSS®E are summarized in Table 2-1 PSS®E File Classes. With the
exception of the temporary files and the PSS®E and OPF Options Files, the user may assign any
name to any file. The maximum filename or pathname length that PSS®E can handle is determined
by the Windows® operating system. Both the computer’s file management system and PSS®E
activities always identify a file by this user-assigned name. Section 2.2, The PSS®E Working Case
and Temporary Files and the following subsections discuss these file classes in some detail.
Table 2-1. PSS®E File Classes
File Class Created By Type Accessible To

User via text editor or auxiliary
Input data files Source PSS®E and user
program
Saved Case and Snapshot Files PSS®E Binary PSS®E
Output listing files PSS®E Source User
Channel Output Files PSS®E Binary PSS®E and PSSPLT
User via text editor or PSS®E
Response Files activities ECHO, PSEB, and Source PSS®E and user
PSAS
PSEB and PSAS Command Files User via text editor Source PSS®E and user
IPLAN Source Program Files User via text editor Source IPLAN compiler and user
IPLAN Executable Program Files IPLAN compiler Binary PSS®E
Python Program Files User via text editor Source PSS®E and other Python
supported applications
(e.g., IDLE)
Options Files PSS®E Binary PSS®E
Source or PSS®E and other
Results files PSS®E
Binary programs
Source or
Temporary files PSS®E PSS®E
Binary
2-3
File Classes Program Operation Manual
2.3.1 Input Data Files

PSS®E must, from time to time, accept large volumes of data from external sources. Such large
volumes of data could be entered directly into the PSS®E working case using the Spreadsheet
View. For other than very small systems, this is not practical; voluminous data is best assembled in
an input data file independently of PSS®E before PSS®E is started up. This file may then be used
as the input source for PSS®E to feed the data through the appropriate input activity into the PSS®E
working case.
Input data files may be obtained by reading from storage mediums (e.g., CDs) or e-mail attach-
ments from external sources (e.g., other computer installations), or by the typing and file editing
facilities of the host computer. In the case of power flow and dynamics data input, the input data
files may often be created by reading and reformatting data obtained from other computer installa-
tions. While they are not accessible from the PSS ®E master program module, reformatting
programs are available for translating several widely used power flow and stability data formats into
the PSS®E input format. Section 2.4.2, Specifying Filenames discusses the alternative methods of
creating input data files.
Table 2-2 Summary of PSS®E Input Data Files defines the principal PSS®E input data files.
Table 2-2. Summary of PSS®E Input Data Files
File Type Description

Power flow system specification data for the establishment of an initial working case
via activity READ.
Power Flow Raw
Data Files Several of these files may have to be read by activities READ and/or RDCH when
a new power flow case is being built from subsystem data being provided by several
different power companies or organizations.
Machine Impedance Data describing the unit configurations at generator buses (plants) for input into the
Data Files working case via activity MCRE.
Files that contain dynamics data on synchronous machines and other system
Dynamics Data Files components for input to the PSS®E dynamic simulation working memory via
activity DYRE.
Negative and zero sequence data needed by activity RESQ to build the working
Sequence Data Files case from a basic positive sequence model into a full symmetrical component trans-
mission system model for unbalanced fault analysis.
Data on constraints and controls for input into the working case via activity ROPF.
Optimal Power Flow
When added to the power flow model, this data is used for defining and solving the
Raw Data Files
optimal power flow problem.
Machine incremental heat rate data, fuel costs, and other data used by activity
Economic Dispatch ECDI in applying its unit commitment and economic dispatch calculation.
Data Files These files are also used by the auxiliary program PLINC to plot incremental heat-
rate curves (see Additional Resources for PSS®E, PLINC).
Inertia and Governor Machine inertia and governor response data for the generator redispatch used in the
Response Data Files inertial and governor response power flow activity INLF.
Drawing Coordinate Coordinates of busbars, line ends, generators, loads, etc. for the construction of a
Data Files one-line diagram via the obsolete activities DRAW, GDIF and SCGR.
2-4
Table 2-2. Summary of PSS®E Input Data Files (Cont.)
File Type Description

Positional data for geometric elements and PSS®E power flow data and solution
Graphical Report
results used for the construction of a user-defined graphics display via the obsolete
Definition Files
activity GRPG.
Data defining monitored elements, contingencies, and subsystems used by activity
DFAX in constructing a Distribution Factor Data File. A Distribution Factor Data File
is required by activities OTDF, DCCC, TLTG, SPIL, POLY, IMPC, LLRF, the
Contingency Analysis
various ac contingency calculation functions (e.g., ACCC, AC Corrective Actions,
Data Files
etc.), the PV Analysis function, the QV Analysis function, the Probabilistic Reli-
ability Assessment function, and the Substation Reliability Assessment
function.
Tripping Element Tripping event specifications that are required when multiple level contingency anal-
Data Files ysis is initiated with the tripping simulation option enabled.
Outage statistics data in the form of frequency and duration required by the Proba-
Outage Statistics
bilistic Reliability Assessment function and the Substation Reliability
Data Files
Assessment function.
Data defining participation blocks for one or more of the subsystems defined in the
Subsystem Participa-
Distribution Factor Data File that is being used in the transfer limit analysis of activity
tion Data Files
SPIL.
Breaker Duty Data Machine parameters used by the circuit breaker current interrupting duty analysis
Files activity BKDY.
Fault Specification Fault locations and fault duty times used by the circuit breaker current interrupting
Data Files duty analysis activity BKDY.
ANSI Fault Specifica- Fault locations, maximum operating voltages, and contact parting times used by the
tion Data Files ANSI fault current calculation activity, ANSI.
Additional data for the modeling of machines and transformers used by the IEC fault
IEC Short Circuit Data
current calculation activity IECS.
Fault Control Data Data specifying various faulting and reporting options for use by the fault calculation
Files activities ASCC and IECS.
Machine Capability Machine capability curves for use by the reactive power limit checking and updating
Curve Data Files activity GCAP.
Bus load throwover data for use by the various ac contingency calculation functions
Load Throwover Data
(e.g., ACCC, AC Corrective Actions, etc.), the PV Analysis function, and the
Files
QV Analysis function.
Transaction event definitions that are entered into PSS®E working memory by
Transactions Raw
activity REMM for use in Transmission Access studies by activities ALOC, IMPC,
Data Files
and LLRF.
Bus Location Data Bus location data that is used in creating or modifying a one-line diagram by Speci-
FIles fying Bus Locations from a File.
Reading basic power flow and stability data from input data files should be a relatively infrequent
occurrence in PSS®E. When an initial working case has been built, the input data files should be
set aside and all data changes and small additions should be made directly on the working case
from the Spreadsheet View and the data modification activities such as CHNG, RDCH, SQCH,
ALTR, and CCON. Attempts to keep a large input data file up to date with an ongoing power system
2-5
study are usually both error prone and time consuming. PSS®E Saved Cases and Snapshots, as
described below, are far more efficient vehicles for maintaining the power flow and dynamic system
database of a study. Table 2-3 Restorable Data Input Files shows PSS®E activities that may be
used to write portions of PSS®E’s working memory in the corresponding Input Data File format.
Table 2-3. Restorable Data Input Files
Read by PSS®E Written by PSS®E

Input Data File Activity Activity
Power Flow Raw Data File READ RAWD
Machine Impedance Data File MCRE RWMA
Sequence Data File RESQ RWSQ
Dynamics Data File DYRE DYDA
Optimal Power Flow Raw Data File ROPF RWOP
2.3.2 Saved Case and Snapshot Files

Because all PSS®E activities always operate upon the working case, it is necessary to load the
required data into the working case before starting any sequence of simulation work. Even though
it is possible to load the working case on a routine basis by using activities such as READ, RESQ,
and DYRE to read input data files, this is discouraged because it would:
1. Be grossly inefficient because input data files are organized for people and must be reorga-
nized by the data input activities to match the computational data structure of PSS®E.
2. Require continuous updating of the input data files as interactive data changes are made in
PSS®E to ensure that the problem data is available for future use.
PSS®E overcomes these problems by using Saved Case and Snapshot Files. These files are
binary images of the power flow working case and dynamics data memory, respectively. To
conserve disk space and minimize the time required to store and retrieve these files, Saved Cases
and Snapshots are compressed in the sense that they do not record unoccupied parts of the data
structure if the system model is smaller than the capacity limits of the program.
Saved Case and Snapshot Files are loaded with copies of these memory images by activities SAVE
and SNAP respectively. Activities SAVE and SNAP require a filename at the time they are selected.
The user may create as many Saved Cases and Snapshots as desired. Each Saved Case is a
complete power flow description that may be returned to the working case as a new base case at
any time with activity CASE. Each Snapshot File records the exact instantaneous condition of all
dynamic simulation models at the time activity SNAP is executed. Returning a Snapshot to
dynamics working memory and its corresponding Saved Case to the power flow working case
allows an interrupted dynamic simulation run to be continued from the time point at which activity
SNAP was executed, just as if the run had not been stopped in the first place.
2-6
2.3.3 Output Listing Files

The majority of PSS®E report-generating activities, such as LIST and POUT, may direct output to
the user terminal, to a high-speed printing unit, or to a named file. When an output listing file is
selected, the report is written into that file in exactly the same format as if it was being printed
directly to a printing device.
The output listing file is available to all standard file manipulation functions; it may be printed, trans-
ferred to a backup medium, examined with a text editor, or simply discarded.
The user may instruct PSS®E to create as many output listing files as are needed. It is good prac-
tice, however, to limit the number of such files because they can use a large amount of disk storage
capacity. Soon after being created, output listing files should be processed (e.g., copied from disk
to a backup medium for archival purposes) and then deleted from the disk (see Section 2.8,
Deleting Files).
2.3.4 Channel Output Files

Channel Output Files are produced by the PSS®E dynamic simulation activities. They are named
and created in activities STRT, ESTR, GSTR, MSTR, and ALTR in response to a user name spec-
ification and receive the values of the PSS®E output channels at regular time intervals during a
simulation run. Unlike output listing files, Channel Output Files are of binary type and cannot be
intelligibly printed by the standard file management functions of the computer. Rather, the Channel
Output Files are organized as required for input to the plot page processing capability of the PSS®E
master program module, and to the Channel Output File processing program, PSSPLT.
As with output listing files, it is advisable to minimize the number of Channel Output Files by copying
them to an off-line bulk storage medium if necessary for archival purposes and deleting or reusing
them as soon as the plotting of a simulation run has been completed.
2.3.5 Response Files

Response Files allow the PSS®E user to automate the execution of a sequence of activities. A
Response File is an ordinary source file that the user creates with a text editor before starting up
PSS®E. A Response File for the performance of a given calculation contains either or both of the
following:
1. An exact image of the line mode activity command and all of its inputs just as they would be
entered by the user at the console in executing the activity through PSS®E’s command line
interface (see Section 4.2.2, Command Line Interface).
2. The batch commands (BAT_), as described in PSS®E Application Program Interface (API),
corresponding to activities and menu bar functions executed from the menu bar of the
Graphical User Interface (GUI) (see Section 4.2.1, GUI Windows).
Response Files may be used to execute an entire program run where the requirements are able to
be determined completely in advance. They may also be used as a convenience to save typing of
a specific subgrouping of activity commands that is found by a user to be needed frequently in the
application of PSS®E.
Constructing a Response File requires familiarity with details of the PSS®E BAT_ commands and/or
its line mode dialog. Response files in batch command format can be recorded in the PSS®E GUI.
Terminal input, including line mode commands, can be recorded using activity ECHO in PSSECMD.
2-7
2.3.6 PSEB and PSAS Command Files

PSEB and PSAS Command Files allow the PSS®E user to specify many routine power flow and
dynamic simulation runs, respectively, in English sentence form. These files are ordinary source
files that the user creates with a text editor before starting up PSS®E. Each record is in the form of
a command starting with a verb from a defined vocabulary.
The PSS®E run assembler activities, PSEB and PSAS, accept such commands, either from a data
input file or directly from the user’s terminal, and translate them into a PSS®E Response File for
immediate execution or for subsequent processing as a standard PSS®E Response File (see
Section 2.3.5, Response Files).
2.3.7 IPLAN Program Files

The user may define and implement processing and/or reporting functions in PSS®E via the IPLAN
programming language. Programs written in this language are created by the user with a text editor
and compiled with the IPLAN compiler program before starting up PSS®E. The resulting IPLAN
Executable Program File may then be specified to the PSS®E activity EXEC for execution.
For details on the IPLAN language, its hooks into the PSS®E working case, and the use of its
compiler, refer to the IPLAN Program Manual.
2.3.8 Python Program Files

The user may define and implement processing and/or reporting functions in PSS®E via the Python
programming language. Python scripts or programs written in this language are generated by using
a text editor or created by PSS®E’s program automation capability. Python scripts may be executed
from the PSS®E menu option I/O Control > Run Program Automation File…. Python commands may
also be entered directly through PSS®E’s command line interface.
2.3.9 PSS®E Options Files

When PSS®E is installed on the system, a set of default run-time options is established (refer to
Section 3.3.3 Program Run-Time Option Settings). Activity OPTN may be used to modify the
current option settings. Activity OPTN may then be instructed to write the current option settings
into a file; this options file is given the name PSSE with the extension OPT (i.e., PSSE.OPT).
Similarly, an Optimal Power Flow Options File, PSSOPF.OPT, may be used to preserve the current
optimal power flow solution parameter settings (see Section 14.10 Optimal Power Flow Solution
Options). The OPF options settings may be modified by selecting the OPF > Parameters... menu
entry or by executing the functions (i.e., the APIs; see Section 3.1 Optimal Power Flow Program
Operation APIs of PSS®E Application Program Interface (API)) called from the [OPF - Change
Parameters] dialog.
Then, whenever PSS®E is subsequently started up, it searches for options files of these names
using the directory search sequence described in Section 2.1 Directories and Files Overview. If
either options file is found, it is read in, establishing new default options settings.
2-8
Program Operation Manual PSS®E Data Files
2.3.10 Results Files

Several PSS®E activities produce binary files intended to be used either by other PSS®E activities
(e.g., the Distribution Factor Data File of activity DFAX for use by activity DCCC) or by other
programs (e.g., the Matrix Output File of activity ASTR for use by LSYSAN).
Similarly, several PSS®E activities produce source files intended to be used either by other PSS®E
activities (e.g., the Bus Number Translation File of activity BSNM for use by activity RNFI) or by
other programs (e.g., the Relay Output File of activity ASCC for use by an external relay coordina-
tion program).
2.3.11 Temporary Files

Any temporary file that is preserved following the completion of the activity that created and filled it
(see Section 2.2, The PSS®E Working Case and Temporary Files) is similar in purpose to the Results
Files. The differences are that: the temporary files are volatile (i.e., they are automatically deleted
when PSS®E is terminated); and the user has no naming control over the temporary files.
2.4 PSS®E Data Files
2.4.1 File Usage

Before PSS®E can be started up, the user must create and fill those files needed for its input. Files
needed for PSS®E output, Saved Cases, and Snapshots will be created by PSS®E as needed. The
importance of planning and noting the contents of PSS®E-created files, as well as user input files,
cannot be overemphasized. It is strongly recommended that, along with study notes, the engineer
keep a record identifying the names and contents of all significant files used in the study. A PSS®E
File Planning Sheet is suggested.
The definitions of the various input data files used by PSS®E are contained in this manual in the
activity descriptions of the PSS®E activities that utilize them. On completion of problem data collec-
tion, the user will have a completed file planning sheet giving the names of all files to be used in the
initial phases of a study. The user will also have written out (in study notes, in spreadsheets, etc.)
the input data that must be placed into the PSS®E input files. A typical completed PSS®E File Plan-
ning Sheet and a sample of the data to be placed in the user-supplied files is given in Chapter 22
of this manual.
The types of data files used by PSS®E, the activities that use them, and the default extensions used
when specifying filenames are summarized in Table 2-4 PSS®E Data File Summary. Except as
described below, whenever a file type listed in Table 2-4 PSS®E Data File Summary is being spec-
ified to PSS®E, the extension designated in the table is automatically appended to the filename if
the user specifies a filename without an extension. For file types not listed in Table 2-4 PSS®E Data
File Summary, as well as for those activities listed below, a default extension compatible with the
Windows® operating system is used.
The following activities write various types of data in the form of input files and use Windows®
compatible default extensions: activities BSNM, DYDA, RAWD, RNFI, RWCM, RWDY, RWMA,
RWMM, RWOP, and RWSQ.
Some input files need not be created if the activities that use them are not going to be
executed.
2-9
PSS®E Data Files Program Operation Manual
Table 2-4. PSS®E Data File Summary
File Essential/ Used by Activities/

PSS®E File Designation Extension Type Optional Functions
SAV One is essen-

CASE, DIFF, GDIF, DFTI,
Saved Case sav Binary tial. More are
and CMPR. Built by SAVE.
optional.
SNP For dynamics,

one is essen-
Snapshot snp Binary RSTR. Built by SNAP.
tial. More are
optional.
SRS SRRS. Built by SRSN of

Source Form Snapshot srs Source Optional
PSS®E-26 or earlier.
OUT For dynamics, Plot page processing capability

one is essen- of PSS®E and program
Channel Output out Binary
tial. More are PSSPLT. Built by dynamic
optional. simulation.
RAW READ. Built by RAWD or

Power Flow Raw Data raw Source Optional
format conversion program.
DYR DYRE. Built by DYDA or

Dynamics Data dyr Source Optional
RWM MCRE. Built by RWMA or

Machine Impedance Data rwm Source Optional
SEQ RESQ. Built by RWSQ or

Sequence Data seq Source Optional
Optimal Power Flow Raw Data rop ROP Source Optional ROPF. Built by RWOP.
DRW Obsolete one-line diagram
definition format file that may
Drawing Coordinate Data drw Source Optional
be imported into the Diagram
View.
Drawing Coordinate Binary Data drb DRB Binary Optional
Graphical Report Data grp GRP Source Optional GRPG.

Binary Graphical Report Definition GRB
grb Binary Optional GRPG.
Data
GRED Library sgf GRL Binary Optional GRPG.
Inertia and Governor Response INL
inl Source Optional INLF. Built by RWDY.
Data
Breaker Duty Data bkd BKD Source Optional BKDY. Built by RWDY.
Fault Specification Data bkf BKF Source Optional BKDY.
Fault Control Data fcd FCD Source Optional ASCC, ASCC2 and IECS.
REL Built by ASCC, ASCC2 and
Relay Output rel Source Optional
IECS.
2-10
Table 2-4. PSS®E Data File Summary (Cont.)

SUB Recall function. Built by memo-

Bus Subsystem Selection Data sbs Source Optional rize function of the bus
subsystem selector.
Subsystem Description Data sub MON Source Optional RANK and DFAX.
Monitored Element Data mon CON Source Optional RANK and DFAX.
Contingency Description Data con Source Optional DFAX. Built by RANK.
DFX OTDF, DCCC, TLTG, SPIL,
POLY, IMPC, LLRF, the
various ac contingency calcu-
lation functions (e.g., ACCC,
ac corrective actions, etc.), the
PV Analysis function, the QV
Distribution Factor Data dfx Binary Optional
Analysis function, and the
Probabilistic Reliability
Assessment function and the
Substation Reliability
Assessment function. Built by
DFAX.
Multi-level ac contingency
Tripping Element Data trp Source Optional
analysis.
The probabilistic reliability
Reliability Outage Statistics Data prb Source Optional function and the substation
reliability function.
THR The various ac contingency

calculation functions, the PV
Load Throwover Data thr Source Optional
Analysis function, and the QV
Analysis function.
Subsystem Participation Data prt PRT Source Optional SPIL.
Machine Capability Curve gcp GCP Source Optional GCAP.
Transactions Raw Data mwm MWM Source Optional REMM. Built by RWMM.
TRN BSNM and RNFI. Built by
Bus Renumbering Translation trn Source Optional
BSNM.
RLC Dynamics channel output file

Relay Characteristic Data rlc Source Optional processing functions. Built by
RWDY.
IDV Built by ECHO, PSEB and
Response idv Source Optional
PSAS.
PSEB Command pse PSE Source Optional PSEB.
PSAS Command psa PSA Source Optional PSAS.
IPLAN Source Program ipl Source Optional IPLAN compiler.
2-11

IRF EXEC. Built by IPLAN

IPLAN Executable Program irf Binary Optional
compiler.
LSA Program LSYSAN. Built by

Matrix Output lsa Binary Optional
ASTR.
Economic Dispatch Data ecd ECD ECD Source ECDI
SBS Recall function. Built by memo-
Bus Subsystem Selection Data sbs SBS Optional rize function of the bus
subsystem selector.
ACC The various ac contingency

calculation reporting functions.
AC Contingency Solution Output acc ACC Optional
Built by the various ac contin-
gency calculation functions.
LOG Several data conversion

Conversion Program Log log Source Optional
programs.
ANSI Fault Specification Data ans ANS ANS Optional ANSI
DAT Built by various functions (e.g.,
RWCM,
Miscellaneous Output Data dat Source Optional
OUTPUT_Y_MATRIX,
section 1.190API Guide).
Python Program py PYT Source Optional Run program automation file
function. Built by recording
function.
PV Solution Output pv PVA Binary Optional The various PV analysis

reporting functions. Built by
PV Analysis function.
QV Solution Output qv QVA Binary Optional The various QV analysis

reporting functions. Built by
QV Analysis function.
POLY Results Output pol POL Binary Optional section / POLY and POLY
previous results plotting. Built
by POLY.
Bus Location Data loc LOC Source Optional GUI one-line diagram.
Tripping Element Data trp TRP Source Optional Multi-level ac contingency

analysis.
FLECS Output flx FLX Source Optional Built by section / DYRE.
Compiling Command bat COM Source Optional Built by section / DYRE and
section / SRRS.
LNTSA Solution Output lnt LNT Binary Optional
IEC Short Circuit Data iec IEC Source Optional section / IECS.
2-12

Reliability Outage Statistics Data prb PRB Source Optional The probabilistic reliability
function and the substation
reliability function.
Event Study evs EVS Binary Optional Event study functions.
Short Circuit Results sc OSC Binary Optional Slider diagram. Built by

ASCC2 and section / IECS.
Slider Template Data slt SLT Binary Optional
EPC Data epc EPC Source Optional
Dynamic Model Library dll DLL Binary Optional
Slider Data sld SLD Binary Optional Slider diagram. Built by

slider.
Power Flow Change Data raw RAC Source Optional section / RDCH. Built by
section / RAWD or format
conversion program.
Slider XML Data sldxml SLX Source Optional Slider diagram in readable
XML format. Built by slider.
Scenario Data pssxml PEX Source Optional Scenario Manager. Built by

Scenario Manager.
Dynamics Add Data dyr DYA Source Optional section / DYRE, ADD. Built by
section / DYDA or format
conversion program.
Compiled Python Program pyc PYC Binary Optional Run program automation file
function. Built by compiling a
python file.
Python Program (no console) pyw PYW Source Optional Run program automation file
function.
Zipped Scenario Archive zip ZIP Binary Optional Scenario Manager. Built by
Scenario manager
Google Earth Data kml KML Binary Optional
Plot Attributes Data plt PLT Binary Optional
Text txt TXT Source Optional Built by various functions
Database Data pdb PDB Binary Optional
Aspen Raw Data dxt DXT Source Optional
Coordinate Pair Data gcp COP Source Optional
MWMI Data dat MMI Source Optional
2-13

Transactions Data dat TRA Source Optional
Detailed Branch Data log DBR Source Optional
Long Title Data txt RET Source Optional
Short Circuit Summery Data dat SCM Source Optional
Comma Separated Value Data csv CVS Source Optional
Python Dynamic Library pyd PYD Binary Optional
PSSE XML Configuration Data xml XML Source Optional PSS®E Import options. Built
by PSS®E Export options.
PSS®E start-up. Built by
PSS®E Options OPT CFG Binary Optional
OPTN.
PSS®E start-up. Built from the
Optimal Power Flow Options OPT Binary Optional [OPF - Change Parameters]
dialog.
Temporary Files * Binary Essential Created and used as needed.
2-14
Program Operation Manual Creating Input Files
2.4.2 Specifying Filenames

In specifying filenames to PSS®E, entering a simple filename always results in PSS®E attempting
to access the specified file in the user’s current directory; specifying the complete pathname of a
file allows the user access to other directories for which appropriate privileges are assigned. In addi-
tion, PSS®E provides a shorthand method of designating the directory path component of a
complete pathname. Activity PATH allows the user to specify such a path. Then, anytime a simple
filename preceded by an ampersand ( & ) is specified to PSS®E (e.g., &case1), the ampersand is
replaced by the specified directory path component and the resulting pathname is used as the
filename.
PSS®E files over which the user has no naming control are generally accessed from the current
directory or from some other system default directory (e.g., the Temp directory on Windows
systems). This includes files such as the PSS®E temporary files (see Section 2.2, The PSS®E Working
Case and Temporary Files), temporary files used during graphics-related activities, and so on.
(PSS®E also looks to the user’s home directory and to its own master directories for PSS®E
Options Files, for output device parameter files, and for several other types of files if they are not
found in the user’s current directory; see Section 2.7.3, File Search Path Rules).
2.5 Creating Input Files

As is seen from Table 2-4 PSS®E Data File Summary, there are several source files that are desig-
nated as input files to various PSS®E activities. Such files must be created prior to executing the
PSS®E activities that utilize them. A source file must be filled with some data at the time it is
created. The initial fill of data need not be the final content of the file because additional data and
corrections may be placed in the file by a text editor at a later time if desired. The content and
formats of the various PSS®E data files are described in this manual in the descriptions of the activ-
ities that use them.
Input records may not exceed 256 characters.
2.5.1 Via a Text Editor

The primary tool for creating and preparing input data files for PSS®E is a host computer’s text
editor. A detailed description of text editors is beyond the scope of this manual. The user is referred
to the appropriate computer system documentation.
2.5.2 Via Format Conversion Programs

It is often desirable to be able to utilize data for a system model that might have been set up for
another program. To that end, a group of auxiliary programs is supplied with PSS®E which, though
not accessible from the PSS®E master program module, are valuable data preparation tools.
Details on format conversion programs may be found in Additional Resources for PSS®E, Section 1.2,
Auxiliary Program Descriptions.
2.5.3 Via PSS®E

As shown in Table 2-4 PSS®E Data File Summary, several PSS®E activities replicate portions of
working memory in the form of PSS®E input data files. Details on the applications of such activities
are provided by individual descriptions contained in this manual.
2-15
Files Created By PSS®E Program Operation Manual
2.6 Files Created By PSS®E

Files into which PSS®E is to write its output need not be created or specified prior to initiating
PSS®E. The name of an output file is requested at the time the activity utilizing it is ready for it. If
the specified file does not already exist, it is created and used.
For the case in which the selected file already exists, the user may elect to have PSS®E operate in
either of two modes:
1. The specified file is utilized.
2. The user is informed that the file exists and is given the option of either specifying another
filename or using the designated file.
Generally, whenever an existing file is used for output, its previous contents are overwritten and
the file is lengthened or truncated as required.
It is the responsibility of the user to ensure that files that are needed for future reference are
not overwritten.
2.7 File System Details
2.7.1 Multiple Working Directories

A simple way of setting up PSS®E to run in a variety of working directories is to create a shortcut
icon for each one and alter the [PSS®E Properties] dialog for the shortcut to indicate the directory in
which the program is to start. Refer to PSS®E GUI Users Guide, Properties Dialog; the directory
path specified in the Start in: field may be set to the desired directory.
2.7.2 PSS®E Directory Organization

The PSS®E program is usually installed in your Program Files directory; the default installation
directory is C:\Program Files\PTI\PSSE33. However, PSS®E may be installed in any user-named
directory. If you choose to install PSS®E in other than the default directory, substitute your installa-
tion directory for any reference of C:\Program Files\PTI\PSSE33 found in this manual.
This top level PSS®E Master Directory consists of subdirectories that contain the files required for
executing PSS®E; these subdirectories are shown in Table 2-5 PSS®E Subdirectories.
Table 2-5. PSS®E Subdirectories
Name Description
DEMOS Contains demos of Siemens PTI and third party software.
Contains all PSS®E documentation. If, during installation, you choose not to install
DOCS
the documentation, it can be found in the DOCS folder on the CD.
Sample PSS®E data files and batch files for building user versions of the PSS®E
EXAMPLE
programs.
IPLUSR User-written IPLAN files.
Diagram elements for use with CCON (ONLY for installations where the lease
MODELDRW
includes the PSS®E Dynamics section).
2-16
Program Operation Manual File System Details
Table 2-5. PSS®E Subdirectories (Cont.)
Name Description
PSSBIN PSS®E executable files.
PSSHLP PSS®E help files in binary format.
Contains several different types of files:
Files necessary for rebuilding the DLLs:
• Batch files (*.BAT)
• Link libraries (*.LIB)
PSSLIB • Fortran include files (*.INS, *.COD)
• Fortran module files (*.MOD)
• C header files (*.H)
• Some source files (*.FOR)
• Other miscellaneous files
PSSMAP Library of Graphics Report Definition Data Files (*.GRP) for use with activity GRPG.
Parameter files that are used to override the default characteristics of output
PSSPRM
devices supported by PSS®E and the PSS®E Windows environment.
Source files used for Dynamics simulation models (ONLY for installations where the
SRCMDL, SRCTBL
lease includes this option.
Programs and data used in setting up your installation. In general, you should not
need to use the files in this directory unless you are doing a node installation from a
SETUP server. If you call Siemens PTI for assistance, support personnel may ask you to
use programs in this directory to assist in diagnosing and resolving installation-
related issues.
Conductor data files used by TMLC (only for installations where the lease includes
TMLC
the Transmission Line Constants program section).
Source code for selected data conversion routines (Western Electricity Coordinating
WECC
Council, WECC).
2-17
File System Details Program Operation Manual
2.7.3 File Search Path Rules

PSS®E programs use a variety of parameter and binary files from which to gather specific
information.
Parameter files are standard text files that can be customized for either individual or system-wide
use. These files typically have the extensions .DAT or .PRM such as those for printers, plotters, and
the PSS®E Windows® environment. Binary files are created by PSS®E programs from previously
developed input files or from specific user input.
When attempting to open a file, PSS®E tries to locate files by sequentially checking the following
locations:
Current Working Directory. When started via a shortcut, PSS®E uses as its working directory the
Start In directory associated with the shortcut. When started from a command prompt, PSS®E uses
the current directory as the working directory. When a file is opened, the current working directory
will change to the directory the file came from. Refer to Section 2.1 Directories and Files Overview
for details on how the working directory is used.
Current Study. If a study is open, PSS®E will see if the desired file can be found in the study.
Home Directory. By default, this directory is under the personal Documents folder of the current
user, [%USERPROFILE%\Documents\PTI\PSSE34]. Setting this variable does not change the
program working directory (see above).
Master Directories. If the type of file being opened has an associated master directory list, that list
of directories will be searched for the specified file. Refer to Section 2.7.6, Master Directories for
detail on how master directories can be created and used.
Example Directory. By default, this directory is the Example directory under the default Home
Directory.
2.7.4 Temporary Files

The temporary files have the extension BIN and are created in the directory specified by the Temp
parameter in the PSS®E .INI file.
2-18
Program Operation Manual File System Details
2.7.5 Reserved Filenames

There are a number of files that PSS®E and its auxiliary programs access automatically. You must
avoid assigning any of the following reserved filenames to your own files in any directory from which
PSS®E is to be executed. In addition, the filenames ending with .EXE and .BAT located in the subdi-
rectory PSSBIN should be treated as reserved.
Table 2-6. Reserved Filenames
Filename Description
MODELS.BIN Binary data file for activity CCON.
Printing and plotting parameter files; <dv> is either PR for the
Printer Definition Parameter File or a two character device code
PARMdv.DAT
assigned to any of the various graphics output devices supported
by PSS®E on the PC: HP, PS, etc.
PSCRIPT.DAT PostScript parameter file for tabular output.
PSSE3300.INI PSS®E settings file.
IMD3300.INI IMD settings file.
PSSPLT3300.INI PSSPLT settings file.
PSSE.OPT PSS®E options file.
PSSOPF.OPT PSS®E OPF options file.
PSSPLT.OPT PSSPLT options file.
SMRYSC.DAT Fault analysis summary file written to by activity SCMU.
WINDOWS.PRM General Graphical User Interface (GUI) parameter file.
WINIMD.PRM IMD GUI parameter file.
WINPLT.PRM PSSPLT GUI parameter file.
2.7.6 Master Directories

Any number of master directories can be used to search for files on a per file type basis. Refer to
Table 2-4 PSS®E Data File Summary for a list of all file types. Each file type has its own master
directory list which will be searched when looking for a file type associated with that master directory
list. The master directory entry for a specific file type can also incorporate macro variables. Refer
to Section 2.7.7, Macros for details on how macros can be created and used. By default all master
directory lists are empty.
Master directories are stored in the registry under the key "Master Paths". Each entry in a master
directory list must be separated by a semicolon, ';'. If the directory contains a semicolon, the direc-
tory must be quoted.
Some programs rely on an older master directories structure. As such, "hidden" master directory
lists are created for backwards compatibility. Refer to Table 2-7 PSS®E Paths and Default Master
Directory Directory for a list of file and their corresponding master directory name and list.
2-19
Deleting Files Program Operation Manual
File(s) Used By Default Setting

PARMxx graphics and printing Pssprm=x:\Program Files (x86)\PTI\PSSE34\pssprm
WINIMD.PRM IMD (GUI only) Pssprm=x:\Program Files (x86)\PTI\PSSE34\pssprm
WINPLT.PRM PSSPLT (GUI only) Pssprm=x:\Program Files (x86)\PTI\PSSE34\pssprm
Table 2-7. PSS®E Paths and Default Master Directory
2.7.7 Macros
Macros are provided to give the user a single place to modify directory variables. Macros are
denoted inside master directories by prefixing the string '$(' and postfixing the string ')' to the macro
name. If the macro name contains any of these special characters, it should be quoted.
Some macros are generated automatically. Refer to Table 2-7 PSSE Default Macros for a list of the
automatically generated macros. A handful of macros are read only as they refer to values that are
defined when the program is installed and cannot be changed without reinstalling the program.
All non-read-only macros are saved in the registry under the key "Macros".
Name Default Value
$(PsseInstallPath) C:\Program Files (x86)\PTI\PSSE34\ (default, read only)

$(HELP) PSSHLP (read only)
$(PSSLIB) PSSLIB (read only)
$(PROGRAMS) PROGRAMS
$(GRPG) PSSMAP
$(PSSPRM) PSSPRM
$(RSPFIL) EXAMPLE
$(PYFILE) EXAMPLE
$(HomePath) C:\Users\[User Name]\Documents\PTI\PSSE34\
$(ExamplePath) C:\Users\[User Name]\Documents\PTI\PSSE34\EXAMPLE\
Table 2-8. PSS®E Default Macros
2.8 Deleting Files

Any file created by the user or by PSS®E may be deleted when it is no longer required. A file should
be purged as a matter of course when its contents have become obsolete or invalid.
Although an unlimited number of files may be contained in a directory, the user should be careful
not to accumulate unneeded files in the working directory. If the user does not exercise discipline in
this regard, confusion could result even if the user is careful in noting the significance of each file
on a File Planning Sheet. Furthermore, disk space is unnecessarily wasted and, although disks
have large capacities, they are finite.
2-20
Program Operation Manual File Usage Summary
Files that are not current but need to be retained for documentation or archival purposes should be
kept on some off-line bulk storage medium.
The user is referred to the appropriate computer system documentation for details on the
mechanics of deleting files.
2.9 File Usage Summary

The use of files by PSS®E gives the user great freedom in adapting the handling of input, the
recording of cases, and the output to suit the work as observed during its progress. As with all
systems that give a user great flexibility and many options, PSS®E also gives the user the respon-
sibility of managing the options, in this case the files.
PSS®E is able, at any time, to write over the contents of a file that had previously been created.
PSS®E does not generally append to files; each time that a user specifies a filename to a PSS®E
file writing activity, such as SAVE or POUT, the writing commences at the start of that file, destroying
the previous contents. Activity OPTN does offer a File overwrite option that can be set to either
Overwrite without asking or Ask first.
This mode of operation has been found in thousands of man-years of use of PSS®E and its prede-
cessors to be the preferred way of handling files. It simply requires that the user keep effective
records of the files created. The best form of record is a concise written catalog to which the user
can refer during the use of PSS®E, together with a systematic way of assigning filenames. The
catalog may take the form of the File Planning Sheet.
2-21
File Usage Summary Program Operation Manual
2-22
Chapter 3
Startup
Chapter 3 - Startup
3.1 Preliminaries
When PSS®E is installed on your workstation (refer to the PSS®E Installation Guide), the following
steps are recommended prior to starting up PSS®E:
• Establish a working directory from which PSS®E is to be executed (see Section 2.1,
Directories and Files Overview). It is strongly recommended that the default working
directory (the EXAMPLE subdirectory of the main PSS®E directory) be used only for
post-installation testing and demonstration purposes, and not for your engineering
studies and investigations.
• Establish in your working directory those initial input data files required for your PSS®E
work session (refer to Section 2.3.1, Input Data Files and Section 2.5, Creating Input
Files).
3.2 Starting PSS®E

PSS®E may be started through one of the following methods:
• From the Windows® Start menu, select Programs > Siemens PTI > PSSE 33 > PSS®E.
This is the default location as established during program installation. Other applica-
tions in the PSS®E suite of tools may also be initiated from this PSS®E Windows® Start
menu.
• From the Windows® Explorer application, double-click the psse33.exe file.
C:\Program Files\PTI\PSSE33\PSSBIN is the default directory location of psse33.exe.
An alternate directory location may be specified during program installation.
• From the Windows® Start menu, select
Programs > Siemens PTI > PSSE 33 > PSS ® E-33 Command Prompt and enter
psse33.exe (or simply psse33) at the DOS prompt, followed by [Enter].
• Start a PSSE-33 Command Prompt and enter prog params where:
prog = name of program (e.g., IPLAN33) that is to be executed.
params = whatever start-up parameters are appropriate for the program.
• Double-click a previously defined PSS®E shortcut icon located on the desktop.
3-1
Startup PSS®E 34.2
Starting PSS®E Program Operation Manual
Do not try to close the copyright start-up window that displays during the GUI version of a
PSS®E-33 program.
3.2.1 Startup Command Options

Additional command options may be appended to the psse33.exe startup command to further direct
and customize program execution. These optional arguments take the form of a keyword, some-
times followed by a value. All keywords begin with a hyphen (-).
The following command line options may be specified:
• -inifile filename
Override the default *.ini file with the one specified by filename.
• -pyfile filename
Begin the program by running the Python program specified.
• -rspfile filename
Begin the program by running the Response File specified.
• -argstr string
When -rspfile filename or -pyfile filename is also specified, use string as the argu-
ment for filename; otherwise the -argstr option is ignored.
• -buses buses
Set the program bus size level. Buses will be rounded to the next multiple of 1000,
up to a maximum of 200,000. If this command line option is omitted or if buses is
specified as zero, the current default size level is used.
• -embed
When -rspfile or -pyfile is also specified, do not display the user interface until that
file has completed its execution; otherwise the -embed option is ignored.
• -resetwrk
Reset the program workspace to system defaults.
The above keywords may be abbreviated to any unique string. The options may be specified in any
order. If the same option is specified more than once, the last one specified is used. The -pyfile and
-rspfile options are mutually exclusive; if both are used, the -rspfile option is ignored.
Filename is interpreted as a pathname relative to the current working directory.
String and filename should be quoted if they contain embedded blanks - use the quote character
( " ). When the string value from -argstr is passed to the Python program or Response File, the
surrounding quotes are removed. Also, any embedded pairs of quotes will be interpreted as a single
quote character. For example, "abc""def" will appear to be the single 7-character string "abc def".
When used with -rspfile, that resulting string will then be parsed according to the normal free-format
parsing rules to assign the individual response file arguments. When used with -pyfile, that resulting
string will be the value of sys.argv[1].
3-2
PSS®E 34.2 Startup
Program Operation Manual Environment
The above keywords may be appended to the PSS®E startup command by appending the argu-
ment to the psse33.exe path name specified in the Target field of the [PSS®E Properties] dialog
associated with the PSSE shortcut icon or the Windows® Start menu
Programs > Siemens PTI > PSSE 33 > PSS®E (see PSS®E GUI Users Guide, Properties Dialog).
The k e y wo rd s may a l s o b e ap pen d e d to th e psse com m a nd p ro mpt b y selecting

Programs > Siemens PTI > PSSE 33 > PSSE-33 Command Prompt from the Windows® Start menu
and appending the command keyword to the psse33.exe command (see Figure 3-1).
Figure 3-1. Specifying the -buses Option in the PSSE-33 Command Prompt Window
3.3 Environment
The principal power system analysis calculations of PSS®E (power flow, equivalent construction,
switching studies, unbalanced fault analysis calculations, linear network analysis, and dynamic
simulation) are all accessible from the main PSS®E entry point. In addition, a set of auxiliary
programs (or utilities) for handling related calculations and various data format conversion applica-
tions are supplied with PSS®E (see Additional Resources for PSS®E, Section 1.2, Auxiliary Program
Descriptions).
3.3.1 Specifying the Maximum Number of Buses

Specifying the token -buses on the command that initiates PSS®E, followed by a number indicating
the maximum number of buses that PSS®E is able to handle, determines the dimensional capacity
of PSS®E. The numeric value specified must be an integer multiple of 1,000, between 1,000 and
200,000 inclusive. If this token and its associated numeric value are omitted, PSS®E is started up
at the size level defined in the PSS®E Options File if one is found (see Section 2.3.9, PSS®E
Options Files, Section 3.3.3, Program Run-Time Option Settings, and PSS®E activity OPTN), or at
the default bus size level determined during program installation if no PSS®E Options File is found.
When the specified maximum bus size level is one of the standard sizes of 1,000, 4,000, 12,000 or
50,000 buses, or the largest size level of 200,000 buses, the maximum dimensional capacities are
3-3
Startup PSS®E 34.2
Environment Program Operation Manual
as shown in Table 3-1 Standard Maximum PSS®E Program Capacities. When a bus size level
between a pair of the standard sizes is specified, the dimensional capacities of some elements are
determined by interpolating between the adjacent standard size dimensions; other elements take
on the dimension of the nearest smaller standard size level. When a bus size level greater than
50,000 buses is specified, the dimensional capacities of some elements are determined by extrap-
olating and others take on the dimension at the 50,000 bus size level. The I/E or S column of Table
3-1 Standard Maximum PSS®E Program Capacities contains IE if interpolation or extrapolation is
used or an S if the dimension of the nearest smaller standard size level is taken. As an example, if
PSS®E is started up at 10,000 buses, the maximum number of loads, transformers, and CONs are
determined by interpolating between the corresponding capacities at the 4,000 and 12,000 bus size
levels, and the maximum number of areas, dc lines, and zero sequence mutuals are the same as
at the 4,000 bus size level.
Table 3-1. Standard Maximum PSS®E Program Capacities

I/E 1,000 4,000 12,000 50,000 200,000
or S Buses Buses Buses Buses Buses
TRANSMISSION NETWORK COMPONENTS
Buses (including star point buses of
- 1,000 4,000 12,000 50,000 200,000
three-winding transformers)
Loads I/E 2,000 8,000 24,000 100,000 400,000
Plants I/E 300 1,200 3,600 10,000 35,260
Machines I/E 360 1,440 4,000 12,000 43,580
Non-conventional (Renewable and
I/E 20 60 120 880 3880
infeed type) machines
Induction machines I/E 20 60 120 240 710
Fixed shunts I/E 1,000 4,000 12,000 50,000 200,000
Switched shunts I/E 126 500 1,500 4,000 13870
Branches (including transformers and
I/E 2,500 10,000 24,000 100,000 400,000
zero impedance lines)
Two-winding transformers (including
I/E 400 1,600 4,800 20,000 80,000
three-winding transformer members)
Three-winding transformers I/E 100 400 1,200 5,000 20,000
Transformer impedance correction
S 16 32 64 96 96
tables
Zero impedance lines I/E 500 2,000 6,000 25,000 100,000
Multisection line groupings I/E 100 400 800 1,600 4760
Multisection line sections I/E 250 1,000 2,000 4,000 11,890
Two-terminal dc transmission lines S 20 40 60 100 100
Voltage source converter (VSC) dc
S 10 20 30 40 40
lines
Multiterminal dc lines S 5 5 5 20 20
Converters per multiterminal dc line S 12 12 12 12 12
dc buses per multiterminal dc line S 20 20 20 20 20
dc circuits per multiterminal dc line S 20 20 20 20 20
3-4
PSS®E 34.2 Startup
Table 3-1. Standard Maximum PSS®E Program Capacities (Cont.)

I/E 1,000 4,000 12,000 50,000 200,000
FACTS devices S 20 50 100 250 250
GNE devices S 10 20 30 40 40
Interchange control areas S 100 250 500 1,200 1,200
Interarea transfers S 300 500 1,000 2,000 2,000
Zones S 999 999 999 9,999 9,999
Owners S 999 999 999 1,200 1,200
Machine owner specifications I/E 720 2,880 8,000 24,000 87,160
Branch owner specifications I/E 5,000 20,000 48,000 200,000 800,000
Zero sequence mutual couplings I/E 500 2,000 3,000 6,000 17,840
Substations I/E 250 1,000 3,000 12,500 50,000
Substation nodes I/E 1,000 4,000 12,000 50,000 200,000
Substation switching devices I/E 2,000 8,000 24,000 100,000 400,000
DYNAMIC SIMULATION ELEMENTS
Constant parameters (CONs) I/E 12,500 40,000 80,000 320,000 999,999
Algebraic variables (VARs) I/E 7,500 16,000 32,000 250,000 999,999
State variables (STATEs) I/E 5,000 20,000 40,000 120,000 435,800
Integer parameters (ICONs) I/E 10,000 20,000 40,000 120,000 435,800
Output channels I/E 750 3,000 8,000 30,000 116,840
User model definitions S 500 500 500 3000 3000
Activity CHAN/CHSB model entries S 500 2,000 2,000 10,000 10,000
Load model table entries I/E 1,000 4,000 12,000 50,000 200,000
Bus type load models I/E 250 1,000 3,000 12,500 50,000
Owner type load models S 999 999 999 1,200 1,200
Zone type load models S 999 999 999 9,999 9,999
Area type load models S 100 250 500 1,200 1,200
All type load models S 5 10 15 25 25
Line relay model connection table
I/E 25 100 240 1,000 4,000
entries
Auxiliary signal models S 20 30 40 50 50
Auxiliary signal injection point per two-
S 4 4 4 4 4
terminal dc line
Auxiliary signal injection point per
S 12 12 12 12 12
multi-terminal dc line
Auxiliary signal injection point per VSC
S 2 2 2 2 2
dc line
Auxiliary signal injection point per
S 1 1 1 1 1
FACTS device
3-5
Startup PSS®E 34.2
Table 3-1. Standard Maximum PSS®E Program Capacities (Cont.)

I/E 1,000 4,000 12,000 50,000 200,000
Maximum number of CCT type
S 100 250 1000 20,000 20,000
dynamic models
3-6
PSS®E 34.2 Startup
3.3.2 Setting Program Preferences

The [Program Preferences] dialog, which is accessible from the Edit > Preferences... menu entry,
allows for the selection of variety of program options regarding its operation from the Graphical User
Interface (GUI). Refer to PSS®E GUI Users Guide, Changing Program Preferences.
3.3.3 Program Run-Time Option Settings

Most PSS®E calculation and reporting functions recognize one or more program run-time option
settings. When PSS®E is installed on the system, default settings for the PSS®E run-time options
are established.
The user may override most of the option settings described below during a PSS®E work session
via activity OPTN. Furthermore, the user may change a given option setting several times during a
PSS®E work session with repeated executions of activity OPTN. These option settings may then
be preserved in a PSS®E Options File (refer to activity OPTN). Such an Options File may then be
accessed on subsequent initiations of PSS®E as described below.
Each time PSS®E is initiated, the option settings are initialized according to:
• An options file if one is found in the user’s current directory; otherwise,

• An options file if one is found in the user’s home directory; otherwise,
• An options file if one is found in the PSS®E master directory PSSLIB; otherwise,
• The defaults established when PSS®E was compiled and linked.
Saved Case Specific Option Settings

The option settings described in Table 3-2 Saved Case Specific PSS®E Program Option Settings
are preserved with the working case when it is saved with activity SAVE. When a power flow case
is retrieved with CASE, the option settings contained in it override those then set in PSS®E working
memory. Whenever an option setting is changed in this manner, an appropriate message is printed.
As described above, these option settings may also be preserved in a PSS®E Options File with
activity OPTN.
PSS®E option settings that pertain only to the Optimal Power Flow program section are described
in Sections 14.8.3 and 14.10. They are preserved with Saved Cases and may also be preserved in
an Optimal Power Flow Options File.
Table 3-2. Saved Case Specific PSS®E Program Option Settings
Default
Option Value Description
Buses are selected in the interactive dialog portions of PSS®E either by
bus number (numbers option) or extended bus name consisting of the
Bus input Numbers twelve-character alphanumeric name plus the bus base voltage (names
option). This option does not apply to the bulk data input activities such as
READ, TREA, RDCH, MCRE, RESQ, and TRSQ.
Buses are ordered in PSS®E reports in either ascending bus number
Bus output Numbers order (numbers option) or alphabetical extended bus name order (names
option).
3-7
Startup PSS®E 34.2
Table 3-2. Saved Case Specific PSS®E Program Option Settings (Cont.)
Default
Power is reported in either MVA or kVA. This option is recognized by the
following power flow reporting activities and functions: AREA, DRAW,
GENS, GEOL, GOUT, INTA, INTZ, LAMP, LOUT, OLTL, OLTR,
Power output MVA OWNR, POUT, RAT3, RATE, SHNT, SUBS, TIES, TIEZ, ZONE, the
load reduction report (Section 11.6 Summarizing Load Reduction). It
is also honored by the single element and subsystem data retrieval
subroutines (refer to PSS®E Application Program Interface (API)).
Voltages are tabulated in either per unit or kV. This applies only to
Voltage output pu activities LIST, EXAM, GENS, TLST, and Listing Control and
Constraint Data
Voltages are reported and entered in the [Spreadsheet]s and activity
Voltage input pu
CHNG in either per unit or kV.
Transmission line (not transformer or generator) impedances are entered
Transmission and/or reported in either per unit or ohms; line capacitances are in per unit
pu
line data input or microfarads. This option is recognized in activities CHNG, LIST,
EXAM, and the nontransformer branch [Spreadsheet].
Fault analysis results are tabulated in either physical units or per unit. This
Fault analysis
pu option is recognized by activities SCMU, SCOP, ASCC, BKDY, ANSI
output units
and IECS.
Fault analysis Fault analysis results are tabulated in either rectangular (e.g., MW, Mvar)
output Rectangular or polar (e.g., MVA, angle) coordinates. This option is recognized by
coordinates activities SCMU, SCOP, ASCC, BKDY, ANSI and IECS.
The fault analysis activities SEQD, SCMU, SCOP, ASCC and IECS
can handle either 3-phase systems modeled by positive, negative, and
Fault analysis
3-phase zero sequence networks, or center-tapped 2-phase systems used in some
modeling
electric traction systems modeled by positive and zero sequence
networks.
Base frequency 60.0 The system base frequency in Hertz (usually 50 or 60 Hz).
Establishes the default rating used by activities POUT, LOUT, and
Default rating
Rate A LAMP. It also is used as the default value for those activities that allow the
set
user to select a rating set.
Sets the mode of tap adjustment in power flow solutions.
• The Disabled mode suppresses transformer adjustments.
• In the Step mode of tap adjustment, transformer taps are adjusted in
multiples of a user-specified tap step.
Tap adjustment Disabled • In the Direct mode of tap adjustment, a simultaneous continuous
adjustment is made of all voltage controlling transformers as well as
all Mvar controlling transformers and all bus voltage magnitudes.
Upon convergence of the main power flow iteration, tap ratios of
controlling transformers are moved to the nearest step and the
solution refined with tap ratios locked at those positions.
3-8
PSS®E 34.2 Startup
Default
Sets the mode of area interchange control in power flow solutions.
• The Disabled mode suppresses area interchange control.
• If Tie lines only is selected, area swings are adjusted with an area’s
Area internet interchange defined as the sum of the flows on all of its tie lines.
change Disabled
• If Tie lines and loads is selected, area swings are adjusted where an
adjustment
area’s net interchange includes tie line flows as well as contributions
from loads connected to area buses that are assigned to areas other
than the bus’ area, and from loads assigned to the area that are
connected to buses assigned to other areas.
Phase shift
Disabled Enables or disables phase shift adjustment during power flow solutions.
adjustment
Sets the mode of switched shunt adjustment during power flow solutions.
• The Lock all mode suppresses all switched shunt adjustments
Switched shunt • The Enable all mode allows adjustment of all in-service switched
Enable all
adjustment shunts that are not locked
• The Enable continuous, disable discrete mode allows adjustment
only of continuous mode switched shunts
Enables or disables the adjustment of dc transformer taps and of ac trans-
DC tap
Enabled formers controlling a converter of a two-terminal dc line during power flow
adjustment
solutions.
Activities FDNS, FNSL and the various ac contingency calculation func-
Non-divergent
tions may optionally be executed in a mode in which the voltage vector of
Newton power Disabled
diverging power flow iterations is captured and the solution terminated
flow solution
prior to blowing up.
The power flow solution activities may be instructed to perform a network
Solution
connectivity check before beginning the voltage solution iterations. This
connectivity Enabled
ensures that all Type 1 and Type 2 buses are connected back to a swing
check
(Type 3) bus by in-service ac branches.
Three-winding When flow into three-winding transformer windings is reported in
transformer to Disabled activities POUT, LOUT, LAMP, and DCLF, the other two buses
bus reporting connected to the transformer may optionally be listed.
Out-of-service
In the bus output blocks of activities POUT, LOUT, and LAMP, out-of-
branch Disabled
service branches connected to the bus may optionally be listed.
reporting
Line shunt Line shunt powers may optionally be reported in activities POUT, LOUT,
Disabled
reporting and LAMP.
Percent loadings on non-transformer branches may be either percent MVA
Non-trans- loadings or percent current loadings in the reports of activities POUT,
Current
former branch LOUT, LAMP, RATE, RAT3, OLTR, and the various ac contingency
expressed as
percent loading calculation reporting functions. It is also honored by the single element and
MVA
units subsystem data retrieval subroutines (refer to PSS®E Application Program
Interface (API)).
3-9
Startup PSS®E 34.2
Default
Transformer percent loadings may be either percent MVA loadings or
percent current loadings in the reports of activities POUT, LOUT, LAMP,
Transformer
RATE, RAT3, OLTR, and the various ac contingency calculation
percent loading MVA
reporting functions. It is also honored by the single element and subsystem
units
data retrieval subroutines (refer to PSS®E Application Program Interface
(API)).
Multisection line groupings are either recognized or ignored in
activities POUT, LOUT, LAMP, OUTS, GEXM, GOUT, BKDY, DCLF,
RANK, DFAX, OTDF, DCCC, TLTG, SPIL, POLY, AREA, ZONE,
Multi-section
Enabled INTA, INTZ, TIES, TIEZ, SUBS, CMPR, CHAN, and CHSB, in the
line reporting
various ac contingency calculation functions, in the area interchange
control option of the power flow solutions, and in the interchange subrou-
tines of the single element data retrieval subroutines.
Certain warning messages can be either printed or suppressed in the fault
Fault analysis
Enabled analysis solution activities (sequence network isolated buses in
warning
activities SEQD, SCMU, ASCC, ANSI and IECS).
Sequence The automatic execution of activity SEQD by activity SCMU is either
Disabled
network setup enabled or disabled.
The matrix growth factor is used in allocating working arrays by activities
Matrix growth involving the ordering, factorization, or triangularization of network
2.0
factor matrices. PSS®E updates this value as required, so that users do not
normally need to be concerned with it.
Graphics output
Beginning with PSS®E-31, this option setting is no longer used.
device
3-10
PSS®E 34.2 Startup
User Specified Option Settings

The option settings described in Table 3-3 User Specific PSS®E Program Option Settings may be
preserved in a PSS®E Options File, but are not preserved in any PSS®E Saved Case File.
Table 3-3. User Specific PSS®E Program Option Settings
Default
Default Newton
power flow The Newton convergence tolerance (MW/Mvar) is initialized to this value
0.1
solution when a new case is read into PSS®E with activity READ.
tolerance
Overwrite PSS®E may operate in either an Overwrite without asking mode or an Ask
File overwrite without first mode when a file that already exists is specified to a PSS®E file
asking writing activity.
Defines the default size level of PSS®E in terms of the maximum number
of buses allowed. The value specified must be an integer multiple of 1,000,
between 1,000 and 200,000 inclusive.
Default PSS®E When a new bus size level is specified and the options setting then saved
size level
12000 to an options file, the new dimensional capacities take effect when PSS®E
is restarted. This setting may be overridden by the user at the time PSS®E
is initiated by specifying the -buses command line token followed by the
desired bus dimension as described in Section 3.3.1 Specifying the
Maximum Number of Buses.
24, 58, 60 The number of lines per page on the user’s terminal (in the Report tab), on
Output device
and 60, the two primary hard copy output devices, and in disk files are recognized
page lengths
respectively when these devices are used as the output destination of PSS®E reports.
Installation Dependent Option Settings

The option settings described in Table 3-4 Installation Dependent Option Settings are not preserved
in any PSS®E Saved Case File or in a PSS®E Options File. To change these requires recompiling
the PSS®E option subroutine PSSOPT.
Table 3-4. Installation Dependent Option Settings
Defines the largest permissible number that may be assigned to a bus.

This is set to 999997 at all size levels of PSS®E as supplied by Siemens
Highest Allowed Bus
PTI. The use of 5 and 6-digit bus numbers should be avoided in cases that
Number
are subsequently processed as special formats where only 4-digit bus
numbers can be accommodated (e.g., IEEE Common Format).
These character codes are written to the user’s terminal at the beginning of
each page of PSS®E output reports when the CRT terminal is selected as
Screen Clearing
the output destination. Where such capability exists, these terminal-depen-
Codes
dent codes should correspond to the character sequence required to clear
the screen and position the cursor at the home position.
3-11
Startup PSS®E 34.2
Startup Parameter Files Program Operation Manual
3.4 Startup Parameter Files

Some PSS® E programs will search for and use certain parameter files at program startup. Those
programs and their parameter files are listing in Table 3-5 Program Parameter Files below.
Table 3-5. Program Parameter Files
Program Parameter File

IMD WINIMD.PRM
PSSPLT WINPLT.PRM
PSSE33 PSSE3300.INI
IMD33 IMD3300.INI
PSSPLT33 PSSPLT3300.INI
3.4.1 WINDOWS.PRM Files

The term WINDOWS.PRM is a generic name for files of the form WIN*.PRM in Table 3-6
WINDOWS.PRM Parameter Descriptions above. The files are used to define certain parameters for
the GUI of those programs, including the toolbar values. Table 3-6 WINDOWS.PRM Parameter
Descriptions describes the parameters in the WINDOWS.PRM file.
Table 3-6. WINDOWS.PRM Parameter Descriptions
Parameter Description
DEBUG = ON/OFF Used to display command line input and output while using the GUI
XSCALE = real_number Used to define x-axis scale factor to adjust for low resolution displays
YSCALE = real_number Used to define y-axis scale factor to adjust for low resolution displays
TOOLBAR = Used to define a toolbar command for PSSPLT. Buttons may be defined for
label,command executing either activity commands or Response Files.
Any parameter can be defined in WINDOWS.PRM. Any TOOLBAR definition will start an entirely
new toolbar definition.
PSS®E programs search for the parameter files using the standard search path rules as described
in Section 2.7.3, File Search Path Rules. You can copy the files from the PSSPRM directory to one
of the alternate search path directories for your own customizing.
Node users may wish to modify the PSSPRM line in corresponding *.INI so that it points to a
local directory where they can store copies of the parameter files in order to allow customizing
their operations.
3-12
PSS®E 34.2 Startup
Program Operation Manual Startup Parameter Files
3.4.2 INI Files

The INI files are installed in the Windows directory. They contain all of the start-up and formatting
instructions such as directory location, report window font, and window placement. Use this file to
change such settings as fonts, printer page margins, or positions of frequently used windows. The
format of the file is: parameter=value, divided into sections whose names are contains in brackets.
The order in which the parameters are located in a given section of the file is unimportant. Any
parameter misspelled or incorrectly specified is either ignored or, as with fonts, partly used. Setup
automatically sets the start-up paths at installation time, but you may change them at any time to
suit your particular directory structure. You can override the default INI file and directory location by
specifying the argument, -INI pathname on the target path found in the properties shortcut field of
the program’s Windows shortcut.
The following sections are valid in all the INI files listed in Table 3-6 WINDOWS.PRM Parameter
Descriptions:
[Startup] Section: This section is used to define startup parameters for PSS®E. The following
parameters are valid:
Home Defines one of the alternate directories used to automatically search for program, user,
and PSS®E system files.
Path Defines the directory path where PSS®E has been installed (required).
Pssmap Defines the directory path for GRPG include files.
Psspgm Defines the directory path for IPLAN programs used by PSS®E.
Pssprm Defines the directory path for PSS®E parameter files such as:
• PARMPR.DAT - the printer definition parameter file.
• PARMPS.DAT - the PostScript definition parameter file.
Initial value is the subdirectory in the installation path.
Temp Defines the directory path for temporary files created by PSS®E. If this parameter is
not defined, the Windows temporary directory will be used.
Unit Used to specify the unit used for defining other values in this file. Valid values are: inch
or mm.
[FileMapping] Section: Filename: This is a special assignment that allows most files opened inter-
nally to PSS®E to be redirected to another location.
The following sections are used by PSSPLT and IMD:
[TextMargins] Section: This section is used to define margins associated with all Windows printing
from PSS®E. Remember that the units are defined in the [Startup] section. The following parame-
ters are valid in this section:
LeftMargin Defines the left margin.
RightMargin Defines the right margin.
TopMargin Defines the top margin.
BottomMargin Defines the bottom margin.
3-13
Startup PSS®E 34.2
[GraphicsMargins] Section: This section is used to define margins associated with all graphics
output using a Windows driver. Remember that the units are defined in the [Startup] section. The
following parameters are valid in this section:
LeftMargin Defines the left margin.
RightMargin Defines the right margin.
TopMargin Defines the top margin.
BottomMargin Defines the bottom margin.
Font Definition Sections: There are several font sections used by PSS®E. Each can be controlled
by defining the appropriate section. The following table lists the valid font sections:
Table 3-7. Font Definitions
Font Description
[PrinterFont] Defines the font when printer output is sent using a Windows driver.
Defines the fixed spacing font used by graphics activities such as DRAW menus
[GraphicsFont]
and GEXM.
[DefaultFont] Default font used in the GUI interface for most controls such as push buttons.
[InputFont] Defines the font used for text input fields in the GUI interface.
Defines the fixed spacing font used for report tabs in the GUI interface, including
[ReportFont]
the Progress tab and help window.
[FormFont] Defines the fixed spacing font used by our forms package.
Each of the font sections can contain one or more of the parameters from Table 3-8 Font Parame-
ters to define the font characteristics (Windows selects the most suitable font based on the
information).
You may use either PointSize or CharsPerInch to specify the font size.
Table 3-8. Font Parameters
Font
Parameter Description Valid Values
Defines the font size using point size.
Depends on the font chosen; 10 or 12 are
PointSize The larger the point size, the larger the
good initial values.
font.
Defines the font size using characters
Depends on the font chosen; 10 or 12 are
CharsPerInch per inch (cpi). The larger the cpi
good initial values.
number, the smaller the font.
Pitch Specifies the pitch of the font. Fixed, variable.
Family Specifies the font family. Decorative, modern, roman, script, swiss.
Quality Specifies the output quality. Draft, proof.
3-14
PSS®E 34.2 Startup
Program Operation Manual Startup Parameter Files
Table 3-8. Font Parameters (Cont.)
Font
Parameter Description Valid Values
Specifies the thickness of the character Thin, extralight, light, normal, medium,
Weight
to be drawn. semibold, bold, extrabold, heavy.
Depends on the fonts installed on your
system. A good initial choice for a variable-
Specifies the font name such as Arial, pitch font is Arial; a good choice for a fixed-
FaceName
Courier New, Helvetica, Times. pitch font is Courier New. These fonts are
installed with Windows and are available on
all machines.
[ReportBufferSize] Section: This section is used to define the size, in bytes, of each report tab
used by the program. The memory allocated for this is the same for other items dynamically allo-
cated within the program and the total is limited to a size defined when the program is linked. The
following parameters with default values are:
Activity Selector: 5000000

Reports: 5000000
Help: 61440
Making these numbers too large could cause the program to crash at startup or fail to allocate
memory later on in its execution.
When examining the *.INI files, keep in mind that anything preceded by a semi-colon (;) repre-
sents a comment and is not read by the program.
3-15
Startup PSS®E 34.2
3-16
Chapter 4
Operating Modes
This chapter describes those procedures necessary to access PSS®E from a terminal workstation.
Chapter 4 - Operating Modes
Included are the methods used to run PSS®E using the graphical user interface (GUI), interactive
command line, or batch mode, to specify the disposition of PSS®E reports, and to incorporate the
user’s connection subroutines into the PSS®E activity structure.
4.1 How to Approach PSS®E

The new user, after reading the preceding sections, may form the impression that PSS®E is a
complex and difficult program. It must be recognized, however, that PSS®E is an extremely
powerful tool that allows its user to handle a very broad range of power system calculations using
a single integrated program system. Its apparent complexity is, accordingly, more a function of the
many different types of data needed in power system work than it is a function of PSS®E itself. The
user will find that, after a very few work sessions with PSS®E, driving PSS®E will have become
quite comfortable; and attention is refocused from concern over which buttons to push to solving
the engineering problem.
The new user approaching PSS®E should recognize the need to gain a firm understanding of three
separate aspects of PSS®E:
1. The roles of the files in handling problem input data and in building up a library of working
cases that represent system conditions at selected stages of a study.
2. The capabilities of the individual PSS®E activities and the sequencing of these activities to
achieve a desired power flow, simulation, or short circuit calculation.
3. The process of setting up the dynamic model of the system to be simulated.
The role of the PSS®E files has been discussed in Chapter 2, File System. The detailed format
requirements of each user-filled file are described in Chapter 5, Power Flow Data Entry, Modifica-
tion, and Display Activities through Chapter 20, Miscellaneous Activity Descriptions in the activity
description of the activity that reads it. The mechanics involved in the second and third aspects
listed above are described in the remainder of this manual, and the corresponding engineering
basis is described in the PSS®E Program Application Guide.
After an understanding of PSS®E has been established, the new user should recognize the
following basic steps in the initiation of any PSS®E dynamics study:
1. Identify all the files that will be needed including input data files, Saved Case Files, Snapshot
Files, and Channel Output Files. Write out a summary listing the names and content of all
of these files using a PSS®E File Planning Sheet such as that suggested in Section 2.9, File
4-1
Operating Modes PSS®E 34.2
Activity Selection Program Operation Manual
Usage Summary.
2. Collect all power flow data and establish one or more valid power flow Saved Case Files
before proceeding to dynamic simulation setup.
3. Develop the dynamic simulation data and equipment modeling subroutines using the meth-
odology given in Chapter 21, Dynamic Simulation Setup and Procedures.
4. Link the connection subroutines into the PSS®E dynamic simulation activities as described
in Section 4.10 Loading the Connection Subroutines.
5. Read the dynamic simulation data into PSS®E working memory and establish one or more
valid initial condition Snapshot Files corresponding to the Saved Case Files from step 2.
6. Use the auxiliary programs VCV and IMD and the PSS®E activities ESTR, ERUN, GSTR,
and GRUN to verify the dynamic simulation data. See also Additional Resources for PSS®E,
Section 1.2.10, V Curves and Section 1.2.3, Motor Parameters, respectively.
7. Make power flow and simulation runs, creating additional Saved Case and Snapshot Files
as needed to accommodate significant system conditions developed during the study.
A typical PSS®E File Planning Sheet for the initial stages of a PSS®E study is provided. The impor-
tance of this file planning cannot be overemphasized.
4.2 Activity Selection

There are two methods of interactive operation of PSS®E: GUI Windows and Command Line Inter-
face. In both of these modes of operation, the user specifies the PSS®E activity or function to be
performed, along with any input data required by it. The manual PSS®E Application Program Inter-
face (API) documents the calling sequences and data requirements of all PSS®E API routines.
When operating PSS®E via the GUI, a single dialog box often provides the equivalent of multiple
API routines or calls to API routines. It can also provide alternatives of several API routines. The
question and answer dialog of the line mode may require several prompts and user responses for
the same functionality. The correspondence between input fields contained in these customized
dialogs to the arguments of the API calls and to the prompts issued when using the line mode
should be self-evident.
When an activity is initiated using either the GUI or command line, it must be completed in the same
mode. The next activity to be executed may then be initiated in either mode.
4.2.1 GUI Windows

The default set of windows displayed when PSS®E is started up is the highest level window in
PSS®E. These windows provide the following options and program feedback:
• Select activities and other functions to be executed (see below).

• Receive progress messages and reports from PSS®E (see Section 4.4 Virtual Output
Devices).
• Issue interrupt control codes (see Section 4.3 Interruption of PSS®E by the User).
Across the top of the PSS®E interface is a menu bar containing several categories of activities.
Activities are grouped together according to the general type of function they perform. Selecting one
4-2
PSS®E 34.2 Operating Modes
Program Operation Manual Interruption of PSS®E by the User
of these menu bar entries causes a pull-down menu to appear. Each pull-down menu contains a list
of submenus and/or a list of application functions and/or activities. Refer to PSS®E GUI Users
Guide for details on activity execution in windows mode.
4.2.2 Command Line Interface

Access to the PSS®E Command Line Interface (CLI) is available by selecting the View > CLI Window
menu entry. Select either PSS®E Response or Python from the Command language: drop-down
list next to the CLI window. When PSS®E Response is selected, either batch commands or line
mode commands may be entered in the Enter command: field. The command is executed by
pressing the [Enter] key. Activities initiated in this manner execute using the command line, with
dialog prompts displayed in the Progress tab of the output view and additional commands or user
responses (in the case of the line mode) entered at the Enter command: field. See Section 16.11,
Line Mode Commands and Section 16.5, Batch Commands for more details.
Refer to PSS®E Command Line Interface (CLI) Users Guide for details on activity execution using
the command line.
4.2.3 Automation Methods

PSS®E may also be operated using any of several program automation methods as described in
Chapter 16, Program Automation.
4.3 Interruption of PSS®E by the User

As an interactive program system, PSS®E activities are sensitive to an interrupt from the user’s
terminal for the purpose of redirecting the course of the computation. This facility gives the user the
ability to terminate nonconvergent iterations, suppress unwanted listings, select convergence
monitor options, and, in general, direct the sequencing of activities based upon the user’s observa-
tion of processing results to date.
PSS®E interrupts are triggered by pressing the [F10] function key on the keyboard. Pressing the
[F10] function key brings up the Interrupt Handler window, which contains:
• A toggle button box containing all the interrupt control codes to which PSS®E activities
are sensitive (see Table 4-1).
• A [Resume] pushbutton through which PSS®E execution is continued with any
selected interrupt control codes passed to the current activity.
The [Interrupt Processing] dialog contains all of the interrupt control codes used throughout PSS®E.
The interrupt control codes to which an individual activity is sensitive are given in the activity
descriptions in Chapter 5, Power Flow Data Entry, Modification, and Display Activities through
Chapter 20, Miscellaneous Activity Descriptions of this manual; any other interrupt control codes
that are specified to the activity are ignored.
In working with large cases, there may be a delay before an [F10] function keystroke is acknowl-
edged by PSS®E. During this delay, there is no visible evidence that the interrupt request has been
received by PSS®E.
In addition, pressing the [F10] function key before running a PSS®E activity will have no effect. For
an activity to acknowledge an interrupt and bring up the Interrupt Handler window, the [F10] key
must be pressed after the activity is invoked.
4-3
Interruption of PSS®E by the User Program Operation Manual
Table 4-1. Interrupt Codes
Interrupt
Action
Code
Depending on type of activity:
• End the activity
• End activity input/output
AB • Abandon solution activity following completion of the next iteration
• Suppress initial conditions summary/reports
• Suppress messages
• Force a pause by setting TPAUSE = now.
CH Tabulate output channel values at each time step.
CL Close all active Response Files.
CM Print the network solution convergence monitor.
Tabulate dc line conditions after each power flow iteration (activity SOLV):
The data printed for each noncapacitor commutative two-terminal dc line includes the dc
line name followed by two lines including the following quantities:
IPR IPI ALPHA GAMMA VDCR VDCI TAPR TAPI DCCUR
PACR QACR PACI QACI
The information printed for each capacitor commutated two-terminal dc line includes the dc
line name, followed by an iteration report of the Newton solution run for one or more oper-
ating modes, followed by:
ALPHA_R MU_R VDC_R(kV) TAP_R PAC_R QAC_R DC_CURRENT
GAMA_I MU_I VDC_I(kV) TAP_I PAC_I QAC_I ALPHA_I
For multi-terminal lines, the dc line number is followed by conditions at each converter bus:
DC bus # ANGLE TAP VDC DCCUR PAC QAC
For VSC dc lines with both converters in-service, the dc line name is followed by line and
converter bus conditions as follows:
• dc voltages at the power and voltage controlling converters and dc current
• if a limit violation is relieved at this iteration, the converter bus at which it occurs, the
present ac injections at that bus, and the reduced values are tabulated, followed by
the new dc voltages and the dc current
• dc power, converter losses, and ac power at the power controlling converter
• dc line losses
• dc power, converter losses, and ac power at the voltage controlling converter
For VSC dc lines with only one converter in-service, the dc line name is followed by the dc
power, converter losses, and ac power at the in-service converter.
Tabulate FACTS device conditions after each power flow iteration.
The data printed for each FACTS device includes conditions at the sending and terminal
FD buses, series voltage and current in polar coordinates, series voltage with respect to both
series current and sending end voltage in rectangular coordinates, and an indication of
those quantities currently at a limit.
4-4
Program Operation Manual Interruption of PSS®E by the User
Table 4-1. Interrupt Codes (Cont.)
Interrupt
Action
Code
Tabulate the conditions for each in-service induction machine after each iteration. The data
printed for each induction machine includes the bus number and machine identifier, the
voltage magnitude at the bus, the voltage error in the induction machine iteration, slip,
mechanical torque, mechanical power, the magnitude of the voltage across the mutual reac-
MO
tance, the saturation multiplier ALFA, the partial derivative of mechanical output power with
respect to slip, the partial derivative of mechanical output power with respect to terminal
voltage, the partial derivative of mechanical load with respect to slip, and the apparent
active and reactive power flowing into the induction machine at the ac bus.
IP End execution of the IPLAN program.
MO Print induction motor local iteration convergence monitor.
NC Suppress convergence monitor.
NM Suppress automatic adjustment monitors.
NV Suppress incorrect plant VAR limit report.
TI Print the present value of simulation TIME.
4-5
Virtual Output Devices Program Operation Manual
4.4 Virtual Output Devices

PSS®E categorizes all text output into four types:
Informational messages. This can include intermediate values of solutions, identifying

Progress data from a file, copies of commands entered in the CLI, and warning about data condi-
tions that may or may not warrant further investigation by the user.
Error messages. Something didn’t work, or some condition was encountered that
Alerts
prevented the program from performing the task it was asked to do.
Results of calculations and or analysis, or summaries of data from the program’s
Reports
memory.
The program is asking you a question. The PSS®E GUI doesn’t use prompts, but they
Prompts
can be generated by automation files.
In concept, PSS®E decides what kind of output it is producing, and the user decides where that
kind of output goes. By default, in the PSS®E GUI, the four output types are handled as follows:
These messages appear in the Progress tab of the output bar. Messages internally
Progress
marked as warnings are copied to the Alerts/Warnings tab.
These messages appear in MsgBoxes to which the user must respond. They are copied
Alerts
to the Progress tab and to the Alerts/Warnings tab.
This output is sent to the Report tab(s) of the output bar (whether one or multiple tabs is
Reports
used is a preferences setting).
These will not be shown until a request for input is generated. Normally a special input
window will then be created showing the prompt(s) and requesting a response. This
Prompts
normal operation is suppressed for line mode dialog, which is strictly directed to the
Progress window.
If there is no GUI, such as in PSSECMD or when using PSS®E’s API from Python, all the virtual
devices default to the console. If there is no console (such as with Pythonw) the output will appear
in a series of MsgBoxes.
Any of the four output types can be redirected in the PSS®E GUI by selecting I/O Control > Direct
xxx output, where xxx is the output type. This functionality can be accomplished via the PSS®E API
as well. The table below lists the API routine to redirect each type of output, and other commands
that pertain to each output type.
Redirection API Redirection Line API routine to IPLAN command to

routine Mode Command write a line of text write a line of text
Progress progress_output PDEV progress PRINT
Alert alert_output ODEV alert
Report report_output OPEN report REPORT
Prompt prompt_output ODEV prompt ASK
When virtual devices are redirected to files, they can each be directed the same file. Output will
appear in the file in the order in which it was generated by the program.
4-6
Program Operation Manual Line Mode Output Commands
Activities that write data files (e.g. RAWD) will write to either a named file (i.e. named by the user)
or the current reporting device.
The Progress and the Report virtual devices can be destinations for any of the other devices,
including each other (circular redirection is checked for and disallowed). One way to collect all the
output in one place is the redirect the other devices to the Progress device, and then redirect the
Progress device to where you want it all to go.
One destination that can be used for any of the devices is None, in which case no output of that
type takes place at all.
4.4.1 User-Written Dynamics Models

Dynamics model programs generally write their output to either the unit number that is stored in the
variable IPRT, or in LPDEV, or in ITERM. This output actually goes to temporary files and then is
read back in and written to the Report device in the case of IPRT, and else to the Progress device.
An alternative method, one that involves less I/O, is to use the Fortran routines defined for the API
routines that write a line of text to a virtual device.
4.4.2 Graphical Output

Graphics are a feature of GUI, and require the GUI to be created. Diagrams and Plots must be
created in the GUI after which they can be copied to a file or to a printer. These operations can be
recorded and controlled through automation files.
4.5 Line Mode Output Commands

When using the GUI or using the API directly report output goes to the current report device. The
line mode, however, recognizes whether the report device has ever been set by the user and, if it
has not, every activity that writes to the report device will explicitly ask where the output should go.
When operating in this mode it is equivalent to setting the report device, running the activity, and
resetting the report device back to the default.
Once the report device has been set explicitly this mode of operation terminates. OPEN is the line
mode command to set the report device.
Line mode activity CLOS is provided to return to the original initial state where each activity in the
line mode will ask for the report device.
PDEV is the line mode activity to redirect the progress device.
The prompt device and the alert device are not distinguished in the line mode, and both are
controlled by the activity ODEV.
Activities that write data files will present the following choices for directing output:
0 FOR NO OUTPUT 1 FOR REPORT DEVICE

2 FOR A FILE:
4-7
Automation Program Operation Manual
Output redirection activities will present the following choices in addition to those above:
3 FOR DEFAULT PRINTER

6 FOR ALTERNATE SPOOL DEVICE
When OPEN has not been run, other reporting activities will display an output selection menu and
will have the following additional choice:
7 FOR PROGRESS DEVICE

In all cases entries of 0 through 7 will be accepted, but values that do not correspond to choices
displayed will default to other valid choices. The values that are skipped represent choices that are
no longer meaningful in the current program, but may still exist in recorded automation files.
4.6 Automation
PSS®E offers several methods of automation, i.e. mechanisms to control PSS®E execution other
than by direct user interaction. These can be used to develop macro-type applications, i.e. files of
set procedures to be used interactively, or for unattended operation (batch), where the PSS®E can
run a pre-set series of operations to completion with no further interaction from the user. The oper-
ations can be fixed, or can be implemented in programming languages to whatever level of
complexity is desired. Chapter 16, Program Automation describes these features in detail.
4.7 Extended Modeling in Dynamics Simulation

PSS®E’s Dynamics Simulation module comes with hundreds of available models that can be used
for network equipment built into the program. No special steps need to be taken by the user beyond
the data requirements for the models.
Additional models can be provided in user-created libraries. Dsusr.dll is assumed as the default
name for a user-created library and is automatically loaded if it is found. Additional model libraries
can be identified to PSS®E via the ADDMODELLIBRARY API routine (see PSS®E Application
Program Interface (API)).
Not every model can be identified to PSS®E by its data requirements. For those models, PSS®E
uses connection routines. These subroutines are called CONEC and CONET, and are normally built
as part of a dsusr.dll file.
Procedures to build user libraries are discussed in Section 1.3, Extending PSS®E with User DLLs
and Section 1.4, PSS®E Support for Building User DLLs. Model writing is discussed in Chapter 23,
Model Writing.
4.8 Subsystem Selection
Windows Mode
Most PSS®E activities allow the user to specify processing the current subsystem. In addition, the
appropriate [Subsystem Selector] dialog may be opened from the PSS®E interface menu and the
current subsystem redefined before the activity is initiated. When a subsystem definition is modi-
fied, it becomes the current subsystem and remains the current subsystem until it is changed.
There are four types of subsystem: bus, area, owner, and zone. Menu items in the Subsystem menu
allow access to the four [Subsystem Selector] dialogs.
4-8
Program Operation Manual Subsystem Reporting
Most reporting and processing activities that operate on a subsystem of the working case operate
on a bus subsystem. The selection criteria available for bus subsystems are buses, areas, zones,
owners, and/or base voltages; these are handled in a manner that is logically equivalent to the OPT
suffix using line mode. Area, owner, and zone subsystems are used for those reports which, by defi-
nition, are naturally restricted to areas, owners, or zones (e.g., GUI menu selection Power
Flow > Reports > Area / owner / zone totals…). The four types of subsystems exist simultaneously,
and changing one has no effect on any of the others; e.g., changing the current area subsystem
does not affect the area selections of the current bus subsystem.
Command Line
Generally, when no suffix is specified in selecting many of PSS®E’s reporting and processing line
mode activities, either all buses are processed or the user specifies the buses on which the
processing is to take place. For details, refer to the individual activity descriptions in PSS®E
Command Line Interface (CLI) Users Guide. When using PSS®E API routines directly through
Batch or Python commands, setting the subsystem is a separate API call which the API routine that
uses the subsystem refers to by number.
Subsystem Numbers
Four different subsystems, of each type, may be defined in PSS®E, numbered 0 through 3. The
Subsystem menu entry in the GUI always sets subsystem 0 and the spreadsheet displays react to
that. Some dialogs require a temporary subsystem that is different from the primary subsystem;
subsystem 1 is used for that purpose. The line mode always uses subsystem 1. API routines can
refer to any subsystem number 0 through 3.
4.9 Subsystem Reporting

When buses are selected by interchange area, buses are displayed in groups that are ordered by
ascending area number, and in numerical or alphabetical order within each selected area grouping,
according to the bus output option in effect (see Section 3.3.3, Program Run-Time Option Settings).
Similarly, when buses are selected by zone or owner, buses are displayed in groups that are
ordered by ascending zone or owner number, and in numerical or alphabetical order within each
selected zone or owner grouping, according to the bus output option in effect.
If both area and zone selection are specified, buses are displayed grouped in ascending area
number order. Within each area grouping, buses are grouped by ascending zone number, and in
numerical or alphabetical order within each selected zone subgrouping, according to the bus output
option in effect.
If both area (or zone) and owner selection are specified, buses are displayed grouped in ascending
area (or zone) number order. Within each area (or zone) grouping, buses are grouped by ascending
owner number, and in numerical or alphabetical order within each selected owner subgrouping,
according to the bus output option in effect.
When area, zone, and owner are all used as subsystem selection criteria, the grouping hierarchy is
area, then zone, then owner.
When selection by bus is specified, buses are displayed in the order specified by user input. If bus
selection has been specified as well as area, zone, and/or owner selection, the buses within each
area, zone, and/or owner groupings are output in the order specified by user input.
4-9
Loading the Connection Subroutines Program Operation Manual
4.10 Loading the Connection Subroutines

To utilize the dynamic simulation activities of PSS®E, two connection subroutines, CONEC and
CONET, must be provided. The function of these two FORTRAN subroutines is to associate
(connect) dynamic equipment and monitoring models with network buses. In addition, six user
model calling routines, USRXXX, USRLOD, USRREL, USRAUX, USRDCL, and USRFCT are
required for the calling of user-written plant, load, line relay, auxiliary signal, dc line, and FACTS
device models, respectively. After being prepared using the methodology given in Chapter 21,
Dynamic Simulation Setup and Procedures, these subroutines must be incorporated into the
PSS®E structure. The procedure is as follows:
1. Compile these subroutines. It is strongly recommended that the command file, which may
optionally be generated by activities DYRE and SRRS, be used for this purpose so that the
correct compiler options are used and the object code is stored in the files expected in step
2.
2. Having compiled error-free object code of these subroutines, link them into PSS®E. Issuing
the command CLOAD4 (for those user models for which the user would write a model code)
executes the linking command procedure CLOAD4, which builds an executable program file
in the user’s directory.
4.11 Activity Suffixes

Command line only. Many output reporting activities and several processing activities make use of
the optional suffixes to enable the user to restrict the activity’s reporting or processing to a selected
subset of the working case. These are described in detail in PSS®E Command Line Interface (CLI)
Users Guide.
4-10
Chapter 5
Power Flow Data Entry, Modification,
and Display Activities
Chapter 5 - Power Flow Data Entry, Modification, and Display Activities
5.1 Retrieving a Power Flow Saved Case File

Activity CASE
Run Activity CASE - GUI

File > Open…
[Open]
Saved Case file (*.sav)
Run Line Mode Activity CASE - CLI
ACTIVITY?
>>CASE
ENTER SAVED CASE FILENAME:
>>
Interrupt Control Codes
None
The case retrieval activity CASE restores the contents of a previously saved power flow Saved
Case File into the working case. The contents of the working case are overwritten while the contents
of the specified Saved Case File are unchanged.
The CASE API routine requires that the user designate the name of the Saved Case File to be
opened; refer to Section 2.4.1, File Usage for the file specification conventions used by activity
CASE.
If an asterisk (  ) is specified as the name of the Saved Case file, the last Saved Case file accessed
by either activity SAVE or activity CASE in the current session of PSS®E is used.
If the file to be used is not in a Saved Case File format recognized by this release of PSS®E, the
following error message is generated:
FILE filename NOT IN SAVED CASE FORMAT
Then activity CASE ends. To recover, simply select activity CASE again, specifying a valid Saved
Case File filename.
5-1
Power Flow Data Entry, Modification, and Display Activities PSS®E 34.2
Retrieving a Power Flow Saved Case File Program Operation Manual
If the Saved Case exceeds the current capacity limits of PSS®E, an appropriate message is printed
along with the case title and dimensional information. PSS®E then redimensions itself to a size level
sufficient to accommodate the Saved Case. If the dynamics data arrays had previously been allo-
cated, dynamics data capacity limits are also increased. Refer to Section 3.3.1, Specifying the
Maximum Number of Buses.
Generally, activity CASE is able to access Saved Case Files filled by activity SAVE of the current
and previous releases of PSS®E. However, a Saved Case File written by the current version of
PSS®E is normally not able to be read by earlier releases of the program.
Activity CASE is able to access Saved Case Files written on other computer platforms.
Activity CASE is designed to access only Saved Case Files written by PSS®E’s activity SAVE; it
should not be used to attempt to read files written by any other programs.
When picking up Saved Case Files created prior to PSS®E-33, the solution parameters MXTPSS
and MXSWIM are set to 99 and 10, respectively. For those Saved Case Files with sequence data,
any buses with non-zero exceptional negative and zero sequence bus shunt loads have these
quantities shared among the in-service loads at the bus. If there are no in-service loads present at
the bus, a new load is introduced at the bus, with negative and zero sequence loads corresponding
to the bus shunt load quantities, and no positive sequence load; this new load is assigned the load
identifier "SC" unless an out-of-service load with that identifier is already present at the bus.
When picking up Saved Case Files created prior to PSS®E-32, branch circuit identifiers are exam-
ined to check that none contain an at sign ( @ ) as their first character (indicating a breaker; refer
to Non-Transformer Branch Data). If any such branches are detected, they are tabulated and the
user is instructed to specify a character to which these at signs are to be changed. A check is made
to ensure that this substitution does not result in two or more branches with the same circuit identi-
fiers connecting a pair of buses; if it does the user specifies another character to be used. Then a
similar check is made for circuit identifiers with an asterisk (  ) as their first character (indicating a
switch; refer to Non-Transformer Branch Data); if any are detected, the user is instructed to specify
a substitute character as described above.
When picking up Saved Case Files created prior to PSS®E-30.3, the solution parameters VCTOLQ
and VCTOLV are set to default values. This results in matching the convergence criteria used by
PSS®E-30.0 through PSS®E-30.2 (refer to Section 6.5.1, Characteristics of Activity FNSL).
When picking up Saved Case Files created prior to PSS®E-27, transformers with non-zero values
of charging and winding 2 side (previously referred to as the untapped side) line shunt in the positive
sequence are logged at the Progress device (refer to Section 4.4, Virtual Output Devices); charging
is set to zero, and the winding 2 side line shunt is added to the winding 1 side line shunt and then
the winding 2 side line shunt set to zero. In the zero sequence, zero sequence transformer line
shunt is converted to the PSS®E-31 transformer model wherever possible; non-zero transformer
charging, and non-zero line shunts that were not converted, generate an alarm and are set to zero.
Non-zero values of line length for transformers are set to zero but are not logged.
When picking up Saved Case Files created prior to PSS®E-20, zone assignments are checked and
any bus assigned to zone zero is reassigned to the zone with the largest permissible zone number.
The number of buses for which zone assignments are so changed is tabulated at the Progress
device.
When picking up Saved Case Files created prior to PSS®E-18, branch circuit identifiers are exam-
ined to check that none contain an ampersand ( & ) as their first character (refer to Non-Transformer
Branch Data and Multi-Section Line Grouping Data). If any such branches are detected, they are
5-2
PSS®E 34.2 Power Flow Data Entry, Modification, and Display Activities
Program Operation Manual Reading Power Flow Raw Data into the Working Case
tabulated and the user specifies a character to which these ampersands are to be changed. A check
is made to ensure that this substitution does not result in two or more branches with the same circuit
identifiers connecting a pair of buses; if it does the user specifies another character to be used.
Very old Saved Case Files created prior to PSS®E-7 cannot be accessed directly by activity CASE.
Such files must be converted to PSS®E-7 Saved Case File format by the auxiliary program
CASCNV, which was supplied with PSS®E-7 through PSS®E-10.
Following the successful restoration of the Saved Case into the working case, the two-line case title
is printed followed by the time and date at which the case was last saved.
Whenever any of the PSS®E run-time option settings contained in the Saved Case File differ
from those set in PSS®E’s working memory, the settings from the Saved Case are established
and an appropriate message is printed (refer to Section 3.3.3, Program Run-Time Option Settings).
Additional Information
®
PSS E GUI Users Guide, Section 5.1, Retrieving a Power Flow Saved Case File
PSS®E Command Line Interface (CLI) Users Guide,
Section 3.2, Retrieving a Power Flow Saved Case File
®
PSS E Application Program Interface (API), Section 1.50, CASE
See also:
Section 5.45, Creating a Saved Case File
Section 18.14, Listing Saved Case or Snapshot Files
5.2 Reading Power Flow Raw Data into the Working Case
Activity READ
Run Activity READ - GUI

File > Open…
[Open]
Power Flow Raw Data File (*.raw)
Power Flow Data File, Options (*.raw)
Run Line Mode Activity READ - CLI
ACTIVITY?
>>READ
ENTER INPUT FILE NAME (0 TO EXIT, 1 FOR TERMINAL):
>>
AB
The bulk power flow data input activities READ and TREA read hand-typed power flow source data
and enter it into the power flow working case, rearranging it from its original format into a computa-
tionally oriented data structure in the process. The source data records are read from a Power Flow
Raw Data File.
5-3
Reading Power Flow Raw Data into the Working Case Program Operation Manual
One of several PSS®E API routines is used to implement these activities, depending on which of
their various options the user selects (see Section 5.2.2, Operation of Activity READ). While several
of them require additional data, each of these API routines requires that the following two data input
items be specified:
• the name of the Power Flow Raw Data File that is to be read.
• a flag for bus number or bus name specification on input data records. When 1 is spec-
ified for this data item, those data items that designate ac buses on all records except
bus data records may be specified as either Extended Bus Names enclosed in single
quotes or bus numbers. Otherwise, bus numbers must be used to designate ac buses
on these data records.
5.2.1 Power Flow Raw Data File Contents

For more information please see Power Flow Raw Data File Contents.
5.2.2 Operation of Activity READ

The following API routines are used to implement activity READ. Each of them includes among its
input data items the name of the Power Flow Raw Data File to be read and the flag for selecting the
bus names input option of activity READ (see Section 5.2, Reading Power Flow Raw Data into the
Working Case and Extended Bus Names).
Read Standard READ of a Power Flow Raw Data File in the format of the
PSS®E release indicated in the file. No other inputs.
ReadRawVersion Standard READ of a Power Flow Raw Data File in the format of the
current or a prior release of PSS®E. It accepts as input a character
string indicating the PSS®E release.
ReadSub Subsystem READ of a Power Flow Raw Data File in the format of the
PSS®E release indicated in the file. It accepts as input several data
items defining the subsystem for which the data records are to be read
and other processing options.
ReadSubRawVersion Subsystem READ of a Power Flow Raw Data File in the format of the
current or a prior release of PSS®E. It accepts as input a character
string indicating the PSS®E release along with several data items
defining the subsystem for which the data records are to be read and
other processing options.
As data records are read, a message is displayed at the Progress device at the start of each new
category of data.
Before it has completed reading its input data, activity READ may be ended by entering the AB inter-
rupt control code (refer to Section 4.3, Interruption of PSS®E by the User). Activity READ checks
for an interrupt following processing of each group of data records corresponding to 50 equipment
items.
Bus Names Input Option

When the bus names input option of activity READ is enabled, data fields designating ac buses on
load, fixed shunt, generator, induction machine, non-transformer branch, transformer, area, two-
terminal dc line, VSC dc line, multi-terminal dc line, multi-section line, FACTS device, switched
shunt, and GNE device data records may be specified as either Extended Bus Names enclosed in
5-4
single quotes or as bus numbers. Otherwise, bus numbers must be used to designate ac buses on
these records.
Use of the bus names input option of activity READ requires that all buses be assigned unique
extended bus names. While reading each bus data record with this option enabled, if a bus with the
same extended bus name but a different bus number is present in the working case, an error
message is printed, the record is ignored, and processing continues.
Bus Sequence Numbers

As each bus data record is read, activity READ assigns to each new bus (i.e., a bus not previously
read) a bus sequence number, which defines the location of data for the bus in the various bus
data arrays. Bus sequence numbers are assigned sequentially starting with 1 in the order in which
bus data records are read.
Plant and Machine Sequence Numbers

Each bus for which a generator data record is read is assigned a plant sequence number, which
defines the location of its plant-related generator data in the plant data arrays. Data for each plant
contains a machine sequence number assigned for each machine for which a generator data
record is read. This number defines the location of its machine-specific data in the machine data
arrays. Plant and machine sequence numbers are assigned sequentially starting with 1 in the order
in which generator data records are read. It is permissible to enter a generator data record for a bus
that was assigned a type code of 1 or 4 during bus data input. (Refer to Generator Data and activity
MCRE.)
Load Sequence Numbers

Each load introduced into PSS®E is assigned a load sequence number, which defines the location
of its data in the load data arrays. Load sequence numbers are assigned sequentially starting with
1 in the order in which load data records are read.
Fixed Shunt Sequence Numbers

Each fixed shunt introduced into PSS®E is assigned a fixed shunt sequence number, which
defines the location of its data in the fixed shunt data arrays. Fixed shunt sequence numbers are
assigned sequentially starting with 1 in the order in which fixed shunt data records are read.
Induction Machine Sequence Numbers

Each induction machine introduced into PSS®E is assigned an induction machine sequence
number, which defines the location of its data in the induction machine data arrays. Induction
machine sequence numbers are assigned sequentially starting with 1 in the order in which induction
machine data records are read.
Branch Sequence Numbers

Each ac branch introduced into PSS®E is assigned a branch sequence number, which defines
the location of its data in the branch data arrays. Branch sequence numbers are assigned sequen-
tially starting with 1 in the order in which branch data and transformer data records are read.
Transformer Sequence Numbers

Each two-winding transformer is assigned a two-winding transformer sequence number, which
defines the location of its data in the two-winding transformer data arrays; it is also assigned a
5-5
branch sequence number. Similarly, each three-winding transformer is assigned a three-winding

transformer sequence number, as well as three two-winding transformer sequence numbers and
three branch sequence numbers (see Three-Winding Transformer Notes). Transformer sequence
numbers are assigned sequentially starting with 1 in the order in which transformer data record
blocks are read.
5.2.3 Change Case Data in a Standard READ

When data is to be added to the network contained in the working case, the IC data item on the first
input record must be set to 1 (refer to Case Identification Data). New buses, loads, fixed shunts,
generators, induction machines, branches, transformers, and other equipment items are treated in
the same manner as in base case data input. Bus sequence numbers, machine sequence numbers,
and so on are assigned starting with the next available location in the respective data arrays.
When entering data for an existing piece of equipment in activity READ, complete data records
must be entered; omitted data items take on their default values rather than retaining their previous
values. Activity RDCH should normally be used for this function rather than activity READ or TREA
(refer to Section 5.7, Reading / Changing Power Flow Data).
When the bus names input option of activity READ is enabled, activity READ checks for the pres-
ence of duplicate extended bus names in the working case before it starts to read bus data records.
Any violations are logged at the Progress device and activity READ is prohibited from executing.
In the change case mode, after reading the case identification data, activity READ prints a warning
message at the Progress device if generators have been converted (see Section 12.2, Converting
Generators). After generators are converted, machine impedance data (MBASE, ZSORCE,
XTRAN, and GTAP; refer to Generator Data) must not be changed.
Merging Cases
When two or more power utility organizations, or any owners of power flow information, wish to
create a jointly representative power flow case, it is likely that they are using the same numbers in
their independent files to represent buses, areas, zones, owners and transformer impedance cor-
rection tables unique to each case. Merging such system models requires the avoidance of
overlapping or conflicting numeric identifiers, as well as conflicting names of dc lines, FACTS
devices, and GNE devices. A pre-requisite, therefore, is to ensure that the system models to be
merged are examined to verify the absence of such data conflicts. If conflicts exist, it is necessary
to apply renumbering operations and/or other data changes in at least one of the cases to be
merged. Refer to activities BSNM, ARNM, OWNM, and ZONM on the methods to apply the renum-
bering function. Similar operations may be required for auxiliary files dependent on bus numbering
(see activity RNFI).
To merge two power flow Saved Cases, designated Case A and Case B, first resolve any
numbering and naming conflicts. Then open Case B (see Section 5.1, Retrieving a Power Flow
Saved Case File), and, using activity RAWD, create a Power Flow Raw Data File representation of
it. This Power Flow Raw Data File must be formatted so as to add data to the working case rather
than to initialize the working case; that is, IC on the first data record must be 1 (see Case Identifi-
cation Data).
Next, open Case A and enter the Power Flow Raw Data representing Case B. At the completion of
activity READ, the newly introduced data from Case B is contained in the working case together
with the existing data of Case A.
5-6
5.2.4 Subsystem READ

Activity READ has a supplementary mode of operation used to add to the working case a
subsystem of the network where the complete representation is contained in a Power Flow Raw
Data File. The subsystem to be read may be defined by area, zone, owner, base voltage, or a
combination of two or more of these subsystem selection criteria.
In a subsystem READ, the IC data item on the first record of the Power Flow Raw Data File is
ignored. Rather, one of the data items entered at the API routine is an append flag that overrides
the IC value specified in the file. Like IC, this flag indicates that either: the working case is to be
cleared and initialized before reading data; or data is to be appended to that already in the working
case.
An input data item allows selection of one of the following data input functions:
1. Add only data from within the subsystem: all buses and their connected equipment in a
specified subsystem contained in the Power Flow Raw Data File are appended to the
working case.
2. Add only the tie branches connected to the subsystem: all branches in the Power Flow Raw
Data File for which both buses are in the working case and only one bus is in a specified
subsystem (ties) are appended to the working case.
3. Add subsystem data and its ties: all buses and their connected equipment in a specified
subsystem as described in (1), along with its ties as described in (2), are appended to the
working case.
An input data item may be used to enable a boundary bus identification option. When this option is
enabled, any in-service bus that is in the specified subsystem and connected to a bus that is not in
the working case may be identified as a boundary bus; the type code of each boundary bus is
changed from 1, 2, or 3 to 5, 6, or 7, respectively. Refer to activity EEQV for further discussion of
boundary buses.
When the subsystem to be processed is specified by voltage level, it is not possible to process
buses at two different voltage levels while omitting those buses at intervening levels. Multiple
executions of activity READ are required to accomplish this.
When appending tie branches to the working case, one (and only one) of the two subsystems that
are to be joined must be specified. Any branch contained in the Power Flow Raw Data File for which
the following conditions are met is appended to the working case:
• Both buses are in the working case, regardless of whether they were placed there
during this execution of READ or were already there.
• One of the buses is in the specified subsystem and the other is not.
• There is not already a branch in the working case between the two buses with the same
circuit identifier or with circuit identifier 99.
This has the effect of joining the separate subsystems contained in the working case by adding all
tie branches running between them.
Data on an area interchange data record is added to the working case if either:
• At least one data record for a bus, load, or induction machine residing in the area was
read during the current execution of activity READ.
5-7
• The area subsystem option was specified in selecting activity READ and the area was
one of those specified by the user.
Data on zone and owner records is handled using similar criteria.
Data on interarea transfer data records is added to the working case if both the from and to areas
satisfy the criteria above.
5.2.5 Reading Power Flow Raw Data Files Created by Previous Releases of
PSS®E
A Power Flow Raw Data File in the format required for a prior release of PSS®E is able to be
processed by activity READ. Both the standard and subsystem READ functions are able to handle
Power Flow Raw Data Files from as far back as PSS®E-15.
Upon being presented with such a file, activity READ first converts the file from its original format to
the format required by the current release of PSS®E. It then reads the converted file just as it would
any file in the format of the current release.
Two methods are available to identify the format in which the records of the Power Flow Raw Data
File had been written.
• From the Power Flow Raw Data File itself

In this method, the information identifying the file format is contained with the data
records to which it applies. Therefore, the user does not need to remember the PSS®E
revision numbers corresponding to the various Power Flow Raw Data Files being used
in a study.
At PSS®E-31, a third data item containing the revision number of the release of PSS®E
to which the file format corresponds was added to the first data record (refer to Case
Identification Data). For files in the format required by PSS®E-15 through PSS®E-30,
the user may add this revision number to the first record in the data file so that it con-
tains the first three data items of the current Power Flow Raw Data File:
IC, SBASE, REV
Thus, the use of this method requires that the REV data item be correctly specified.
• From an input data item of the appropriate API routine
In this method, the old Power Flow Raw Data File does not require any editing. Rather,
the VERNUM input data item of the ReadRawVersion and ReadSubRawVersion API
routines is a character string designating the PSS®E release (e.g., 30.3.3).
When the revision number is specified in the file, use of the Read and ReadSub API routines
is recommended. If either the ReadRawVersion or ReadSubRawVersion API routine is used,
specify the current version for the VERNUM input data item; if some other version is specified, it will
take precedence over that specified as REV on the first record of the Power Flow Raw Data File.
5-8
Program Operation Manual Reading Power Flow Data Additions from the Terminal
®
PSS E GUI Users Guide, Section 6.3, Reading Power Flow Raw Data into the Working Case
Section 3.3, Reading Power Flow Raw Data into the Working Case
PSS®E Application Program Interface (API),
Section 1.258, READ
Section 1.259, READRAWVERSION
Section 1.260, READSUB
Section 1.261, READSUBRAWVERSION
See also:
Section 5.7, Reading / Changing Power Flow Data
Section 5.49, Creating a Power Flow Raw Data File
5.3 Reading Power Flow Data Additions from the Terminal

Activity TREA
Run Line Mode Activity TREA - CLI

ACTIVITY?
>>TREA
ENTER BUS DATA
I, 'BUS NAME', BASKV, IDE, AREA, ZONE, OWNER, VM, VA
>>
AB
Activity TREA is special purpose version of activity READ available only in line mode. It is designed
for the purpose of adding a limited amount of equipment to the system contained in the working
case, with data records read from the dialog input device (the terminal keyboard, a Response File,
or an IPLAN program).
®
PSS E Command Line Interface (CLI) Users Guide,
Section 3.4, Reading Power Flow Data Additions from the Terminal
PSS®E Application Program Interface (API), Section 1.258, READ
See also:
Section 5.2.1, Power Flow Raw Data File Contents
5-9
Adding Machine Impedance Data Program Operation Manual
5.4 Adding Machine Impedance Data

Activity MCRE
Run Activity MCRE - GUI

File > Open…
[Open]
Machine Impedance Data File (*.rwm)
Run Line Mode Activity MCRE - CLI
ACTIVITY?
>>MCRE
>>
None
When establishing an initial working case in PSS®E for basic power flow studies, it is not necessary
to provide detailed modeling of generating plants (see Generator Data). A single equivalent
machine specifying plant totals is sufficient for basic power flow modeling. However, some analyt-
ical activities, including more advanced power flow analysis involving the dispatching or outaging of
individual machines, fault analysis, balanced switching, and dynamic simulation require more
detailed information on generating plants. That data can be entered from a Machine Impedance
Data File.
Activity MCRE can be used to:
• Add machines at an existing generator bus (i.e., at a plant).

• Enter the machine quantities MBASE, ZSORCE, XTRAN, and GENTAP into the
working case.
• Apportion the total plant output and power limits, as contained in the working case,
among the machines at the plant.
5.4.1 Machine Impedance Data File Contents

The machine impedance data input activity MCRE enters source data records from a Machine
Impedance Data File into the power flow working case. The Machine Impedance Data File consists
of a series of free format records with data items separated by a comma or one or more blanks.
Each record is in the following format:
I, ID, FP, FQ, MBASE, ZR, ZX, RT, XT, GENTAP, STAT
where:
I Bus number. Bus I must be specified in the working case with a plant sequence
number assigned to it (refer to Plant and Machine Sequence Numbers). No default
is allowed.
5-10
Program Operation Manual Adding Machine Impedance Data
ID One- or two-character machine identifier used to distinguish among multiple

machines at a plant (i.e., at a generator bus). ID = 1 by default.
FP,FQ Fractions of total plant active and reactive power output, respectively, to be
assigned to this machine. FP and FQ are 1.0 by default.
MBASE Total MVA base of the units represented by this machine; entered in MVA. This
quantity is not needed in normal power flow and equivalent construction work, but is
required for switching studies, fault analysis, and dynamic simulation.
MBASE = system base MVA by default.
ZR,ZX Complex machine impedance, ZSORCE = ZR+jZX; entered in pu on MBASE base.
This data is not needed in normal power flow and equivalent construction work, but
is required for switching studies, fault analysis, and dynamic simulation. For
dynamic simulation, this impedance must be set equal to the unsaturated subtran-
sient impedance for those generators to be modeled by subtransient level machine
models, and to unsaturated transient impedance for those to be modeled by clas-
sical or transient level models. ZR = 0.0 and ZX = 1.0 by default.
RT,XT Complex step-up transformer impedance, XTRAN = RT+jXT; entered in pu on
MBASE base. XTRAN should be entered as zero if the step-up transformer is
explicitly modeled as a network branch and bus I is the terminal bus. RT = 0.0 and
XT = 0.0 by default.
GENTAP Step-up transformer off-nominal turns ratio, GTAP; entered in pu. GENTAP is used
only if XTRAN is non-zero. GENTAP = 1.0 by default.
STAT Machine status of one for in-service and zero for out-of-service. STAT = 1 by
default.
Data records may be entered in any order. Input is terminated with a record specifying an I
value of zero.
5.4.2 Operation of Activity MCRE

The MCRE API routine requires the following as input:
• The name of the Machine Impedance Data File that is to be read.

• A flag indicating how the status of new machines is to be set. These are machines that
are not in the working case at the time activity MCRE is selected, but are added
because of the presence of data records for them in the Machine Impedance Data File.
• A flag indicating the treatment of machines for which no data record is specified and
that are at a bus with at least one machine for which a data record is specified.
As activity MCRE processes data records, If a record is encountered on which bus I is not in the
working case, if it does not have a generator (i.e., plant) slot assigned to it, or if an invalid machine
identifier is specified, an appropriate message is printed at the Progress device, the record is
ignored, and processing continues.
If, in attempting to add a machine to the machine data arrays, the maximum number of machines
or machine ownership specifications for which PSS®E is dimensioned is exceeded, an error
message is printed at the Progress device and the record is ignored. Processing of records
successfully entered is completed prior to terminating activity MCRE.
5-11
Adding Machine Impedance Data Program Operation Manual
When entering data records for machines already contained in the working case, complete data
records must be entered. Omitted data items take on their default values rather than retaining their
previous values.
If sequence data is contained in the working case (i.e., activity RESQ had previously been
executed), for all machines being added to the working case, the three sequence machine imped-
ances used in the fault analysis activities are set to the impedance ZSORCE specified on the data
input record.
After all records have been read, activity MCRE sets the status of each machine that was added to
the working case. The status of these machines is set in accordance with the value specified as the
new machine status input data item:
• When 0 is specified for the new machine status option, the status of each new machine
is set to the value specified as the STAT data item on its data record (refer to
Section 5.4.1 Machine Impedance Data File Contents).
• When 1 is specified for the new machine status option, the STAT data item is ignored
and the status of any machines added to a bus is set as follows:
- if the plant bus has any in-service machines for which no data record was read, the
status of any new machines at the bus is set to in-service.
- otherwise, the status of any new machines at the bus is set to out-of-service.
Activity MCRE cycles through all plants for which at least one machine data record had been
successfully read in the current execution of activity MCRE. The sums of the active and reactive
power split fractions of all the plant’s machines for which a data record was read with a status flag
of one are calculated. Then the plant totals of machine powers and power limits for those machines
with a status flag of one which were initially in the case are calculated. (If any of the above sums
are zero, the corresponding quantities of the out-of-service machines are used.) Finally, the
machine power outputs and limits of all machines at the bus for which a data record was read are
set to the product of the corresponding plant quantity and the ratio of the machine fraction to the
plant’s sum of machine fractions. Plant totals are then updated as the sum of the corresponding
machine quantities of its in-service machines.
In processing each such plant, if any machine is encountered that existed at the plant prior to
entering activity MCRE and for which no data was read, such machine generates an alarm and is
either placed out-of-service with its data items in the working case unchanged or deleted from the
working case, in accordance with the value specified treatment of machines with no data record
input data item. Furthermore, any machine for which the status flag is changed is tabulated. In either
of these cases, the plant totals could be changed and the plant configuration should be examined
to verify that it is as intended.
Prior to terminating, the machine arrays are compacted to eliminate holes resulting from machine
deletions.
5.4.3 Application Notes

The sum of split fractions of all machines at a plant need not sum to unity because the factor used
in setting each machine’s powers is normally taken as the ratio of the machine’s fraction to the sum
of the fractions of all in-service machines at the plant. This is convenient, for example, if machine
outputs are to be set according to their ratings. In this case, each machine’s MBASE may be spec-
ified as its split fractions.
5-12
Program Operation Manual Reading Sequence Data
The power split fractions are used in setting the machine power limits as well as the initial power
output of the machine. Note that the machine split fractions are not retained in the working case or
subsequently written Saved Case Files following termination of activity MCRE.
When a machine is added to the working case by activity MCRE, it inherits the ownership assign-
ment of the bus to which it is attached.
The introduction of multiple machines at a plant into the working case may be accomplished either
via activity MCRE or during the initial input of the network model into the PSS®E working case via
activity READ (refer to Multiple Machine Plants).
Activity MCRE must be executed before any execution of activity CONG.
PSS®E GUI Users Guide,
Section 6.6, Adding Machine Impedance Data
Section 3.6, Adding Machine Impedance Data
Section 1.153, MCRE
5.5 Reading Sequence Data

Activity RESQ
Run Activity RESQ - GUI

File > Open…
[Open]
Sequence Data file (*.seq)
Run Line Mode Activity RESQ - CLI
ACTIVITY?
>>RESQ
>>
AB
The sequence data input activity RESQ appends negative and zero sequence data to the working
case in preparation for unbalanced network solutions (i.e., fault analysis). The source data records
are read from a Sequence Data File for the system where the positive sequence representation is
contained in the working case.
Most of the other unbalanced network analysis activities do not permit themselves to be executed
unless the sequence data arrays in the working case have previously been initialized via the execu-
tion of activities RESQ or TRSQ. This does not imply that activities RESQ or TRSQ must be
executed during any PSS®E work session in which the unbalanced network analysis activities are
to be used; after a set of sequence data has been read into the working case, it is carried along with
5-13
Reading Sequence Data Program Operation Manual
the network as the case is saved and retrieved with activities SAVE and CASE, respectively.
Sequence data may be examined (with activities SQLI and SQEX) and modified (with activity SQCH
or the [Spreadsheet]) in a manner similar to that of standard (positive sequence) power flow data.
5.5.1 Sequence Data File Contents

5.5.2 Operation of Activity RESQ

The RESQ API routine requires as an input the name of the Sequence Data File to be read.
The working case must contain the network for which the sequence data is to be read. If the change
code parameter IC in the first record of the Sequence Data File is set to 1 and sequence data had
not previously been read for the system in the working case, a message is printed at the Progress
device and the data is processed as if IC was set to zero.
category of data.
Except for the change code parameter IC in the first data record read by activity RESQ, specifying
a data record with a Q in column one is used to indicate that no more data records are to be supplied
to activity RESQ.
When the fault analysis warning option is enabled (refer to Saved Case Specific Option Settings),
activity RESQ produces the following tabulations:
• When IC is zero, a listing of all in-service machines at Type 2 and 3 buses for which no
negative sequence generator impedance is entered. The negative sequence generator
impedance, ZNEG, is set to the positive sequence value, ZPOS.
• When IC is zero, a listing of all in-service machines at Type 2 and 3 buses for which no
zero sequence generator impedance is entered. The zero sequence generator imped-
ance, ZZERO, is set to the positive sequence value, ZPOS.
Each of these tabulations may be individually suppressed by entering the AB interrupt control code
(see Section 4.3, Interruption of PSS®E by the User).
5.5.3 Transformers in the Zero Sequence

The fault analysis activities of PSS®E handle the zero sequence representation of two- and three-
winding transformers automatically. Other nonstandard transformer types must be reduced to
combinations of two-winding transformers, three-winding transformers, and/or branches by the use
of dummy buses and equivalent circuits. Note again that the introduction of buses and branches
needed for the modeling of nonstandard transformers is accomplished by their addition to the posi-
tive sequence network via activities READ, TREA, or RDCH, or the [Spreadsheet].
Transformer zero sequence data is entered into the working case by means of zero sequence trans-
former data records in the Sequence Data File (refer to Zero Sequence Transformer Data).
Transformers are represented in the zero sequence as shown in Figures 5-20 and 5-21. The estab-
lishment of the connections and ground paths depicted is handled automatically on the basis of the
impedances and connection code entered and the winding turns ratios.
5-14
Zero sequence transformer default data is such that the transformer appears as an open circuit in
the zero sequence network. Therefore, zero sequence data must be entered for all grounded
transformers.
Connection codes do not indicate the inherent phase shift due to the relative connection of delta
and wye windings. If this phase shift is to be represented, it must be specified in the positive
sequence power flow data.
Virtually any impedance grounded two-winding transformer may be modeled automatically by spec-
ifying its winding and grounding impedances along with the appropriate connection code (refer to
Zero Sequence Transformer Data). Many three-winding transformer configurations may be handled
in a similar manner; others require the addition of 3Zg or other impedances to one or more of the
winding impedances.
The winding numbers specified in zero sequence network diagrams are not directly associated with
the nominal voltage levels of those windings. They are associated with corresponding winding
connection only.
5.5.4 Auto Transformer Equivalent Circuit

The equivalent circuit impedance of an auto transformer can be determined from a short circuit test
performed as shown in Figure 5-1.
S – Series winding Ns – Number of turns on series winding

C – Common winding Nc – Number of turns on common winding
Terminal 1 ter1
I1 I1 S
S Terminal 2
Ns Ns ter2
I2 V1
V1
C C
Nc V2 Nc
(a) Two winding auto transformer circuit (b) Short circuit test for
impedance measurement
ter1
Zt0
I1
S
Ns ter2 ter1 ter2
V1
C Zt0
Nc t1:1 1:t2
(c) Equivalent of test circuit (d) PSS(R)E equivalent circuit
Figure 5-1. Auto-transformer Equivalent Circuit
5-15
Auto transformer ohmic impedance measured across circuit 1 when circuit 2 is short circuted as
shown in (b) and (c) is given by:
V1
Z to = ------- ohms
I1
Auto transformer turns ratio are defined as:
V1 N S  N C NOMV 1
N  
V2 NC NOMV 2
Wdg1 Voltage WINDV 1
t1  
Wdg1 No min al Voltage NOMV 1
Wdg 2 Voltage WINDV 2
t2  
Wdg 2 No min al Voltage NOMV 2
KVA winding N  1

KVA circuit N
5.5.5 Two Winding Transformer Zero Sequence Network Diagrams and

Connection Codes
NOTE: * in grounding impedance notations (like Z*g1) in zero sequence network diagrams means
PSS®E will automatically multiply that grounding impedance by a factor 3.
5-16
CC=1 and CC=11
Series Path, No Ground Path
Winding 1 Winding 2
Zero Sequence Impedance
Correction applied to:
CC1 : R01+jX01
CC11: R01+jX01
Zg1 Zg2
(a) Transformer Winding Connections
wdg1 wdg2 wdg1 wdg2

R01+jX01 = 3(RG1+jXG1) R01+jX01 = 3(RG2+jXG2)
Zt0 + 3 Zg1 + 3 Zg2 = 3 Z*g1 Zt0 = 3 Z*g2
t1:1 1:t2 t1:1 1:t2
(b) Zero Sequence Network for CC=1 (c) Zero Sequence Network for CC=11
Figure 5-2. YNyn transformer zero sequence network
Winding 1 Winding 2 Zero Sequence Impedance

CC11: R01+jX01
wdg1 wdg2
Zg1 Zg2 3(RG1+jXG1) R01+jX01 = 3(RG2+jXG2)
3 Znutrl0
= 3 Z*g1 Zt0 = 3 Z*g2
Znutrl t1:1 1:t2
(a) Transformer Winding Connections (b) Zero Sequence Network for CC=11
Figure 5-3. YNyn with neutral impedance transformer zero sequence network
CC=11 PSS®E calculates pu Znutrl0 as below:

Set:
Z nutrl  S base12
• R01+jX01 = Zt0 Z nutrl pu  ohm
wdg 1 kV 2
• RG1+jXG1 = Zg1
• RG2+jXG2 = Zg2 ( N 21  1) 2
Z nutrl 0  Z nutrl pu
• RNUTRL+jXNUTRL = Znutrl N 21
Winding 2 No min al Voltage NOMV 2
N 21  
5-17
CC=2 and CC=12
No Series Path, Ground Path on Winding 1 side

Winding 1 Winding 2
CC2 : R01+jX01
Zg1 CC12: R01+jX01
wdg1 wdg2 wdg1 wdg2

3(RG1+jXG1) = 3(RG1+jXG1) =
3 Z*g1 3 Z*g1
t1:1 t1:1
R01+jX01 = R01+jX01 =
Zt0 Zt0
Figure 5-4. YNd transformer zero sequence network

Winding 1 Winding 2
Ztzz OR OR OR
Zg1 Zg2
wdg1 wdg2 wdg1 wdg2

3(RG1+jXG1) = 3(RG1+jXG1) =
3 Z*g1 3 Z*g1
R01+jX01 = Ignored: R01+jX01 =

Ztzz RG2+jXG2 = Zg2 Ztzz
Figure 5-5. Znyn, Zny, or ZNd transformer zero sequence network

core type wdg1 wdg2
Winding 1 Winding 2 3(RG1+jXG1) =
3 Z*g1
t1:1
R01+jX01 =
Zphi0 = magnetising Zphi0
Zg1 impedance
Figure 5-6. YNy core type transformer zero sequence network
5-18
CC=3 and CC=13
No Series Path, Ground Path on Winding 2 side

Winding 1 Winding 2
CC3 : R01+jX01
Zg2 CC13: R01+jX01
wdg1 wdg2 wdg1 wdg2
3(RG1+jXG1) = 3(RG2+jXG2) =
3 Z*g2 3 Z*g2
1:t2 1:t2
R01+jX01 = R01+jX01 =
Zt0 Zt0
Figure 5-7. Dyn transformer zero sequence network

Winding 1 Winding 2
OR OR OR Ztzz
Zg1 Zg2
wdg1 wdg2 wdg1 wdg2
3(RG1+jXG1) = 3(RG2+jXG2) =
3 Z*g2 3 Z*g2
R01+jX01 = R01+jX01 =
Ztzz Ignored: Ztzz
RG1+jXG1 = Zg1
Figure 5-8. YNzn, Yzn or Dzn transformer zero sequence network

core type wdg1 wdg2
Winding 1 Winding 2 3(RG2+jXG2) =
3 Z*g2
1:t2
R01+jX01 =
Zphi0 Zphi0 = magnetising
Zg2 impedance
Figure 5-9. Yyn core type transformer zero sequence network
5-19
CC=4 and CC=14
No Series Path, No Ground Path
Winding 1 Winding 2 Winding 1 Winding 2 Winding 1 Winding 2
OR OR

wdg1 wdg2 wdg1 wdg2
Zt0 Zt0
Figure 5-10. Yy, Yd, Dy, Dd, Yyn or YNy transformer zero sequence network
Terminal 1 1
Series Wdg
NS
2 Terminal 2
ter1 ter2
NC Common Wdg
2 2
1 1
Figure 5-11. Ya ungrounded auto transformer zero sequence network
5-20
CC=5 and CC=15
Series Path, Ground Path on Winding 2 side
This connection code is normally used as part of Zero Sequence Impedance

three-winding transformer. Correction applied to:
Refer CC=11 of three-winding transformer. CC5 : R01+jX01
CC15: R01+jX01
wdg1 wdg2 wdg1 wdg2

1:t2 1:t2
R01+jX01 = R01+jX01 =
Zt0 Zt0
t1:1 t1:1
3 (RG1+jXG1) = 3 (RG2+jXG2) =
3 Z*g2 3 Z*g2
Figure 5-12. CC=5 or CC=15 zero sequence network
CC=6 and CC=16
Wye grounded - delta with an earting transformer
No Series Path, Ground Path on Winding 1 side, Earting transformer on Winding 2 Side
Winding 1 Winding 2 Earthing Transformer
Zero Sequence
Ztzz OR Impedance
Correction
applied to:
Zg1 Zg2 CC6 : R01+jX01
Zg2
CC16: R01+jX01
Zig-Zag Wye-Delta
wdg1 wdg2
t1:1
wdg1 wdg2
t1:1
R01+jX01 = R02+jX02 =
Zt0 Ztzz
R01+jX01 = RG1+jXG1 =
Zt0 + 3 Zg1 Ztzz + 3 Zg2 3 (RG1+jXG1) 3 (RG2+jXG2)
= 3 Z*g1 = 3 Z*g2
Figure 5-13. YNd transformer with Zigzag or YNd earthing transformer on winding 2 side zero
sequence network
5-21
No Series Path, Ground Path on Winding 1 side through core magnetizing impedance
Winding 1 Winding 2
OR OR
Ztzz
Zg2
Zphi0 = magnetising impedance wdg1 wdg2
wdg1 wdg2
R01+jX01 = R02+jX02 =
Zphi0 Ztzz
R01+jX01 = RG1+jXG1 = 3 (RG2+jXG2)

Zphi0 Ztzz + 3 Zg2 = 3 Z*g2
Figure 5-14. YNzn or Dzn core type transformer zero sequence network
CC=7 and CC=17
Delta with an earting transformer - Wye grounded
No Series Path, Earting transformer on Winding 1 Side, Ground Path on Winding 2 side
Earthing Transformer Winding 1 Winding 2
OR Zero Sequence
Ztzz
Impedance
Correction
Zg1 applied to:
Zg1 Zg2 CC7 : R01+jX01
CC17: R02+jX02
Zig-Zag Wye-Delta
wdg1 wdg2
1:t2
wdg1 wdg2
1:t2
R01+jX01 = R02+jX02 =
Ztzz Zt0
RG1+jXG1 = R01+jX01 =
3 (RG1+jXG1) 3 (RG2+jXG2)
Ztzz + 3 Zg1 Zt0 + 3 Zg2
= 3 Z*g1 = 3 Z*g2
Figure 5-15. Dyn transformer with Zigzag or YNd earthing transformer on winding 1 side zero
sequence network
5-22
No Series Path, Ground Path on Winding 2 side through core magnetizing impedance
Winding 1 Winding 2
OR OR
Ztzz
Zg1

Zphi0 = magnetising impedance
wdg1 wdg2
wdg1 wdg2
R01+jX01 =
Ztzz R02+jX02 =
RG1+jXG1 = R01+jX01 = Zphi0
Ztzz + 3 Zg1 Zphi0 3 (RG1+jXG1)
= 3 Z*g1
Figure 5-16. ZNyn or ZNd core type transformer zero sequence network
5-23
CC=8 and CC=18
Wye grounded - wye grounded three legged core type auto transformer
Series Path, Ground Path each side
Zero Sequence Impedance Correction applied to:

CC8 : R01+jX01
CC18: R01+jX01, R02+jX02
Terminal 1 1 Terminal 1 1
Series Wdg OR Series Wdg

NS NS
2 Terminal 2 2 Terminal 2
NC Common Wdg NC Common Wdg
2 2 2 2
Zg2
1 1 1 1
ter1 ter2 ter1 ter2

t1:1 1:t2 t1:1 1:t2
R01+jX01 =
ZM0
ZM0
RG1+jXG1 = RG2+jXG2 =
Z10 Z20
Z10 Z20
Figure 5-17. YNa core type auto transformer zero sequence network
5-24
CC=8 CC=18
PSS®E calculates pu values as:
Calculate: N–2 3N – 1
Z 1S = ------------- Zt 0 – ---------------- Zg2
Z10, Z20, ZM0 from equations as in CC=18 2N 2
N
1 3N – 1
Z 2S = --- Z t + ---------------- Z g2
Set: 2 0 N
- R01+jX01 = ZM0
N 1 3
- RG1+jXG1 = Z10 Z SG = ------------- Z phiC – --- Z t + ---- Z g2
N–1 2 0 N
- RG2+jXG2 = Z20
Z 1S Z 2S
Z mo = Z + Z 2S + -------------------
-
1S Z SG
CC=18
Z 1S Z SG
Set: Z 10 = Z + Z SG + -------------------- -
1S Z 2S
- R01+jX01 = Zto
Z 2S Z SG
- R02+jX02 = ZphiC Z 20 = Z + Z SG + --------------------
-
2S Z 1S
- RG2+jXG2 = Zg2
Where:
ZphiC is the magnetising (exciting) impedance as measured on the Common Winding with series
winding on the same core open circuited and zero sequence voltage is applied to Terminal 2.
Refer auto transformer equivalent circuit represention description for definition of N and Zto.
5-25
CC=9 and CC=19

• Series Path on each side, Ground Path at the junction point of the two series paths
• Wye grouned - wye grounded three legged core type auto transformer

CC9 : R01+jX01, R02+jX02, R03+jX03
CC19: R01+jX01, R02+jX02
Series Wdg OR Series Wdg

NS NS
2 2 2 2
Zg2
1 1 1 1
ter1 ter2 ter1 ter2

R01+jX01 = R02+jX02 =
Z1S Z2S
Z1S Z2S
t1:1 1:t2 t1:1 1:t2
RG1+jXG1 =
ZSG
ZSG
Figure 5-18. YNa core type auto transformer zero sequence network
5-26
CC=9 CC=19
Set:
Calculate: - R01+jX01 = Zto
Z1S, Z2S, ZSG from equations as in CC=19 - R02+jX02 = ZphiC
- RG2+jXG2 = Zg2
Set:
- R01+jX01 = Z1S PSS®E calculates pu values as:
- R02+jX02 = Z2S
N 2 3 ( N  1)
- RG1+jXG1 = ZSG Z1 S  Z to  Zg2
2N N2
1 3 N  1
Z 2S  Z to  Zg2
2 N
N 1 3
Z SG  Z phiC  Z to  Z g 2
N 1 2 N
Where:
ZphiC is the magnetising (exciting) impedance as measured on the Common Winding with series
winding on the same core open circuited and zero sequence voltage is applied to Terminal 2.
Refer auto transformer equivalent circuit representation description for definition of N and ZCS.
5-27
CC=20
• Series Path on each side, Ground Path at the junction point of the two series paths
• Wye grouned - wye grounded core type transformer

CC20: R01+jX01, R02+jX02
core type core type
Winding 1 Winding 2 Winding 1 Winding 2
OR
Zg1 Zg2 Zg1 Zg2
Znutrl
wdg1 wdg2
3(RG1+jXG1) = 3(RG2+jXG2) =
Z1S Z2S
3 Z*g1 3 Z*g2
t1:1 1:t2
ZSG
(b) Zero Sequence Network for CC=20
Figure 5-19. YNyn with or without neutral impedance core type transformer zero sequence
network
Set: PSS®E calculates pu values as:

- R01+jX01 = Zt0 Winding 2 No min al Voltage NOMV 2
- R02+jX02 = Zphi0 N 21  
- RG1+jXG1 = Zg1
- RG2+jXG2 = Zg2 S BASE 12
Znutrl  Znutrl pu  Znutrl ohm
- RNUTRL+jXNUTRL = Znutrl wdg1 kv 2
1 N 1
Z 1S  Z t 0  3 21 Z nutrl
2 N 21
1 N 1
Z 2S  Z t 0  3 21 Z nutrl
2 N 21
1 1
Z SG  Z phi 0  Z t0  3 Z nutrl
2 N 21
Where:
Zphi1 is the magnetising (exciting) impedance as measured on Winding 1 with winding 2 on the
same core open circuited and zero sequence voltage is applied to Winding 1.
5-28
Zphi2 is the magnetising (exciting) impedance as measured on Winding 2 with winding 2 on the
same core open circuited and zero sequence voltage is applied to Winding 2.
Zphi0 = Zphi1 or Zphi2, if Zphi1 = Zphi2
Zphi0 = 0.5(Zphi1 + Zphi2) if Zphi1 ≠ Zphi2
CC=21
Series Wdg Series Wdg

NS OR NS
2 2 2 2
Zg2
1 1 1 1
ter1 ter2
t1:1 1:t2 Zero Sequence Impedance
ZM0 CC21: R01+jX01
(b) Zero Sequence Network for CC=21
Figure 5-20. YNa auto transformer zero sequence network

- R01+jX01 = Zto 2
 N 1
- RG2+jXG2 = Zg2 Z MO  Z to  3  Z g2
 N 
Refer auto transformer equivalent circuit represention description fro definition of N and Zto.
5-29
CC=22
Wye - wye ungrounded core type auto transformer
Terminal 1 1
Series Wdg Zero Sequence Impedance

NS Correction applied to:
2 Terminal 2 CC22: R01+jX01
NC Common Wdg ter1 ter2

t1:1 1:t2
ZM0
2 2
1 1
Figure 5-21. Ya ungrounded core type auto transformer zero sequence network

- R01+jX01 = ZphiS
N 1
Z MO  Z phiS
N
Where:
ZphiS is the magnetising (exciting) impedance as measured on the Series Winding with all the other
windings on the same core open circuited and zero sequence voltage is applied to Terminal 1.
Refer auto transformer equivalent circuit representation description for definition of N.
5.5.6 Three Winding Transformer Zero Sequence Network Diagrams and

Connection Codes
Note:
Impedance Notations used in the Zero Sequence Networks:
Z120 = Zero sequence leakage impedance between winding 1 and winding 2
Zg1 = Winding 1 grounding impedance
Znutrl = Neutral grounding impedance
5-30
PSS®E Calculated Equivalent Circuit Impedances used in the Zero Sequence Networks:
Zt10 = Zero sequence impedance between winding 1 and star point
Zt10 = 0.5(Z120 + Z310 - Z230)
Zt20 = 0.5(Z120 + Z230 - Z310)
Zt30 = 0.5(Z230 + Z310 - Z120)
5-31
CC=1 and CC=11 (511)
Series path in all three Windings, Winding 1 ground path at star point bus
Zero Sequence Impedance wdg1 wdg2

t1:1 1:t2
CC1: Z10, Z20, Z30
Zg1 = magnetising Z10 Z20
CC11: Zt10, Zt20, Zt30
impedance
Winding 1 Winding 2 Winding 3
Zg0 Z30
t3:1
wdg3
(a) Transformer Winding Connections (b) Zero Sequence Network
Figure 5-22. YNynyn with magnetising impedance modelled transformer zero sequence
network
CC=1 CC=11
Calculate:
Z10, Z20, Z30 from equations as in Set:

CC=11 - R01+jX01 = Z120
- R02+jX02 = Z230
Set (pu): - R03+jX03 = Z310
- RG1+jXG1 = Zg1
- R01+jX01 = Z10
- R02+jX02 = Z20 PSS®E calculates pu values as:

- Zt10, Zt20, Zt30
- R03+jX03 = Z30
- Z10 = Zt10
- RG1+jXG1 = Zg1
- Z20 = Zt20
- Z30 = Zt30
Assigned:
- Zg0 = 3(RG1+jXG1)
- Z10 = R01+jX01
- Z20 = R02+jX02
- Z30 = R03+jX03
PSS®E automatically multiplies

grounding impedance by 3.
- Zg0 = 3(RG1+jXG1)
5-32
CC=2 and CC=12 (113)

Series path in Windings 1 and 2, Winding 3 ground path at star point bus
(For YNad, refer CC=17)
Winding 1 Winding 2 Winding 3 Zero Sequence Impedance

CC2: Z10, Z20, Z30
CC12: Zt10, Zt20, Zt30
Zg1 Zg2 wdg1 wdg2
t1:1 1:t2
Winding 1 Winding 2 Winding 3 Z10 Z20
Z30
Zg1 Zg2
Znutrl
wdg3
Figure 5-23. YNynd transformer zero sequence network
CC=2 CC=12 Calculated (pu):

Set:
Calculate: (with Znutrl)
- R01+jX01 = Z120
Z1 0 , Z2 0 , Z3 0 from - R02+jX02 = Z230
0 0 0
 calculate Z t1 , Z t 2 , Z t 3
e q u a t i o n s a s i n - R03+jX03 = Z 0
31 Winding 2 No min al Voltage NOMV 2
CC=12 N 21  
- RG1+jXG1 = Zg1 Winding 1 No min al Voltage NOMV 1
- RG2+jXG2 = Zg2 N 1
0 0
Z1  Z t1  3Z g 1  3 21 Z nutrl
Set (pu): N 21
Calculated (pu):
N 21  1
- R01+jX01 = Z10
0 0
(no Znutrl) Z 2  Z t 2  3Z g 2  3 Z nutrl
2
- Zt10, Zt20, Zt30 N 21
- R02+jX02 = Z20
- Z10 = Zt10+ 3Zg1 0 0 1
Z3  Zt3  3 Z nutrl
- R03+jX03 = Z30 - Z20 = Zt20 + 3Zg2 N 21
- Z30 = Zt30
Assigned:
- Z10 = R01+jX01
- Z20 = R02+jX02
- Z30 = R03+jX03
5-33
CC=3 and CC=13 (313)
Series path in Windings 2, ground paths from Windings 1 and 3 at star point bus

wdg1 wdg2
CC3: Z10, Z20, Z30
CC13: Zt10, Zt20, Zt30 1:t2
Z10 Z20
Z30
Zg2
wdg3
Figure 5-24. Dynd transformer zero sequence network
CC=3 CC=13
Set:
Calculate:
- R01+jX01 = Z120
Z10, Z20, Z30 from equations as in CC=13 - R02+jX02 = Z230
- R03+jX03 = Z310
Set (pu):
- RG2+jXG2 = Zg2
- R01+jX01 = Z10
Calculated (pu):
- R02+jX02 = Z20
- Zt10, Zt20, Zt30
- R03+jX03 = Z30 - Z10 = Zt10
Assigned: - Z20 = Zt20 + 3(RG2+jXG2)
- Z30 = Zt30
- Z10 = R01+jX01
- Z20 = R02+jX02
- Z30 = R03+jX03
5-34
CC=4 and CC=14 (333)
No series paths, ground paths from all three Windings at the star point bus

CC4: Z10, Z20, Z30 wdg1 wdg2
CC14: Zt10, Zt20, Zt30
Z10 Z20
OR OR OR
Z30
wdg3
Figure 5-25. Ddd, Ddy, Dyd, Dyy, Ydd, Ydy, Yyd or Yyy transformer zero sequence network
CC=4 CC=14
Set:
Calculate:
- R01+jX01 = Z120
- R03+jX03 = Z310
Set (pu):
- R01+jX01 = Z10 Calculated (pu):

- Zt10, Zt20, Zt30
- R02+jX02 = Z20
- Z10 = Zt10
- R03+jX03 = Z30 - Z20 = Zt20
Assigned: - Z30 = Zt30
- Z10 = R01+jX01
- Z20 = R02+jX02
- Z30 = R03+jX03
5-35
CC=5 and CC=15 (121)

Series path in Windings 1 and 3, ground path at Winding 2 side bus

CC5: Z10, Z20, Z30
CC15: Zt10, Zt20, Zt30 ter1 ter2
t1:1 1:t2
Terminal 1 Z10 Z20
1
Terminal 3 Winding 2
3
Z30 Zg0
t3:1
Zg2
ter3
Figure 5-26. Dynd auto transformer zero sequence network
CC=5 CC=15
Set:
Calculate:
- R01+jX01 = Z120
- R03+jX03 = Z310
- RG2+jXG2 = Zg2
Set (pu):
Calculated (pu):
- R01+jX01 = Z10
- Zt10, Zt20, Zt30
- R02+jX02 = Z20 - Z10 = Zt10
- R03+jX03 = Z30 - Z20 = Zt20
- Z30 = Zt30
- RG2+jXG2 = Zg2 - Zg0 = 3(RG2+jXG2)
Assigned:
- Z10 = R01+jX01
- Z20 = R02+jX02
- Z30 = R03+jX03
Calculated (pu)
- Zg0 = 3(RG2+jXG2)
5-36
CC=6 and CC=16 (111)
Series path in all three Windings, no ground path
Winding 1 Winding 2 Winding 3 Zero Sequence Impedance

CC6: Z10, Z20, Z30
CC16: Zt10, Zt20, Zt30
Zg1 Zg2 Zg3
wdg1 wdg2
t1:1 1:t2
Z10 Z20
Z30
Zg1 Zg2 Zg3
t3:1
Znutrl
wdg3
Figure 5-27. YNynyn transformer zero sequence network
CC=6 CC=16 Calculated (pu):

Set: (with Znutrl)
Calculate:
- R01+jX01 = Z120 - Calculate Zt10, Zt20, Zt30
Z 1 0 , Z 2 0 , Z 3 0 from - R02+jX02 = Z230
e q u a t i o n s a s i n - R03+jX03 = Z 0 NOMV2
31 N 21 = ----------------------
CC=16 NOMV1
- RG1+jXG1 = Zg1
- RG2+jXG2 = Zg2 N 21 – 1
- RG3+jXG3 = Zg3 – Z 0 = Z t1 0 + 3Z g1 + 3 ------------------ Znutrl
Set (pu): 1 N 21
- R01+jX01 = Z10 Calculated (pu): N 21 – 1

(without Znutrl)
– Z 0 = Z 0 + 3Z g2 – 3 ------------------ Znutrl
2 t2 N 2
- R02+jX02 = Z20
- Zt10, Zt20, Zt30 21
- R03+jX03 = Z30 - Z10 = Zt10 + 3 (RG1+jXG1) 1
– Z 0 = Z 0 + 3Z g3 + 3 ---------- Znutrl
- Z20 = Zt20 + 3 (RG2+jXG2) 3 t3 N 21
- Z30 = Zt30 + 3 (RG3+jXG3)
Assigned:
- Z10 = R01+jX01
- Z20 = R02+jX02
- Z30 = R03+jX03
5-37
CC=17
Series path in Windings 1 and 2, Winding 3 ground path at star point bus
(For wye grounded - wye grounded - delta non auto transformer, refer CC=12)

CC17: Zt10, Zt20, Zt30
Terminal 1 1
Winding 3
ter1 ter2
S
NS Terminal 2 t1:1 1:t2
2 Z10 Z20
T
NC C
Z30
C – Common Winding
S – Series Winding
Zg2
T – Tertiary Winding
wdg 3
Figure 5-28. Ynad (grounded) auto transformer zero sequence network
CC=17
Set:
- R01+jX01 = Z120
- R02+jX02 = Z230
- R03+jX03 = Z310
- RG2+jXG2 = Zg2
Calculated (pu):
0 0 0
 calculate Z t1 , Z t 2 , Z t 3
0 0 3 ( N  1)
Z1  Z t1  Zg2
N2
0 0 3 ( N  1)
Z 2  Zt 2  Zg2
N
0 0 3
Z3  Zt 3  Z g 2
N
5-38
CC=18
Terminal 1 1 Correction applied to:
Winding 3
CC18: Zt10, Zt20, Zt30
S
NS Terminal 2
2
ter1 ter2
T
NC C t1:1 1:t2
Z10/2 Z10/2
C – Common Winding
S – Series Winding
wdg3
T – Tertiary Winding
Figure 5-29. Yad (ungrounded) auto transformer zero sequence network
Set:
- R01+jX01 = Z120
- R02+jX02 = Z230
- R03+jX03 = Z310
Calculated (pu):
Calculate Zt10, Zt20, Zt30
0  N 1  0  N 1  0 1 0
Z1    Z 31   2  Z 23  Z12
 N   N  N
Section 6.7, Reading Sequence Data for Fault Analysis
Section 3.7, Reading Sequence Data for Fault Analysis
Section 1.269, RESQ
5-39
Reading Transactions Raw Data Program Operation Manual
5.6 Reading Transactions Raw Data

Activity REMM
Run Activity REMM - GUI

File > Open…
[Open]
Transactions Raw Data File (*.mwm)
Run Line Mode Activity REMM - CLI
ACTIVITY?
>>REMM
>>
None
Transaction data is introduced into working memory using activity REMM. This information consists
of data records presented in a Transactions Raw Data File.
5.6.1 Transactions Raw Data File Contents

The input stream to activity REMM consists of two groups of records. All data is read in free format
with data items separated by a comma or one or more blanks. Each category of data except the
participation flag data is terminated by a record specifying an initial field value of zero.
An initial record presents a participation flag, a single integer field that sets the treatment for some
data values contained in the second data group. The second data group defines transaction events.
Participation Flag
The initial data record consists of a single integer field.
IPF
where:
IPF Participation flag:

0 for bus load/generation fractions.
1 for bus participation factors.
This value is employed to determine the treatment of data fields, contained in the second data
group, which define the participation of buses with transaction events. A value of zero for this field
indicates that the later fields shall be interpreted as load and generation fractions. A non-zero value
(the preferred usage being a value of 1) indicates that the later fields shall be interpreted as bus
participation factors.
5-40
Program Operation Manual Reading Transactions Raw Data
Transaction Events
Each transaction event consists of a single data record that assigns a set of transaction attributes,
followed by one or more data records that associate participating buses with the transaction event.
The set of transaction attributes are introduced using data records of the form:
ID, ISTAT, MAG, 'LABEL', IPR, CURT
where:
ID Transaction event number. ID = 0 by default.

ISTAT Transaction event status:
0 for out-of-service.
1 for in-service.
ISTAT = 0 by default.
MAG Transaction event magnitude in MW. MAG = 0.0 by default.
LABEL Alphanumeric label assigned to the transaction event. The label may be up to
twenty four characters and must be enclosed in single quotes. LABEL may contain
any combination of blanks, uppercase letters, numbers and special characters.
LABEL is twenty four blanks by default.
IPR Transaction event priority. This integer value priority number is used to group trans-
actions into sets. IPR = 0 by default.
CURT Transaction event curtailment magnitude in MW. CURT = 0.0 by default.
Each transaction attribute record is followed with a group of records that identify the buses partici-
pating in the transaction event. The bus participation records take the form:
I, LV, GV
where:
I Bus number. I = 0 by default.

LV Participating bus load value. LV = 0.0 by default.
GV Participating bus generation value. GV = 0.0 by default.
Negative data may be presented for load or generation values. The interpretation of the participating
bus load and generation values is a function of the participation flag, IPF, presented on the initial
data record. The consequence of the differing treatment is discussed in Section 5.6.3 Implications
of the Participation Flag.
Participating bus data input is terminated with a record specifying a bus number of zero.
Transaction event data input is terminated with a record specifying a transaction event number of
zero.
5-41
Reading Transactions Raw Data Program Operation Manual
The following is an example consisting of two transaction events,
1
6 1 200.0000 'UPSTART ' 1 0.
3008 1.0000 .0000
102 .0000 .2667
0
5 1 354.0000 'WORLD ' 1 0.
3008 .0000 1.0000
3007 1.0000 1.0000
3006 1.0000 1.0000
3005 1.0000 1.0000
3004 .0000 1.0000
3003 .0000 1.0000
3002 .0000 1.0000
3001 .0000 1.0000
0
0
5.6.2 Operation of Activity REMM

The user selects the desired Transaction Raw Data File (refer to Section 2.3.1, Input Data Files). If
the file does not exist or some other file system related error occurs, an appropriate error message
is printed. Using line mode the user may enter data directly from the dialog input device. This
applies to both interactive and Response File operation of PSS®E.
Activity REMM processes data records from the selected source input stream. REMM prints a
message each time that it starts processing a new category of data.
5.6.3 Implications of the Participation Flag

Each transaction event includes a magnitude and participating load and generation buses. The
participation flag, IPF, affects both the interpretation of the transaction event participating bus load
and generation values and the interpretation of a zero value transaction magnitude.
The transaction magnitude is apportioned among the participating buses, power injections at partic-
ipating buses with positive generation value or negative load value, and power demand at
participating buses with positive load value or negative generation value. The magnitude of power
injection or demand at each participating bus is in proportion to the transaction magnitude and the
bus participation factor, r:
r
Pi = MAG  i
r
where:
Pi Active power injection (demand) at bus i in MW.

MAG Transaction event magnitude in MW.
ri Participating bus i participation factor.
r Sum of participation factors for injection (demand) buses associated with the trans-
action event.
5-42
Program Operation Manual Reading / Changing Power Flow Data
When IPF = 0, the load and generation values are interpreted as fractions of bus total MW (load or
generation). The bus participation factors are then the product of these fractions with the total bus
load or generation as appropriate. Also when IPF = 0, a transaction magnitude value of zero indi-
cates that the transaction magnitude shall take a value equal to the sum of participating power
demand.
When IPF is non-zero (e.g., IPF = 1) the load and generation values are interpreted as participation
factors and no alternate interpretation is implied for a zero value transaction magnitude.
Activity REMM introduces the transaction data into working memory, but this data is not retained in
the working case. Transaction data is not restored to the working memory by use of activity CASE.
The transaction data makes reference to participating buses by bus number. These references are
not altered or affected by bus modifications made through program dialog. For example, if a trans-
action participating bus is eliminated from the working case by dialog with activity JOIN then the
participating bus reference persists in the working memory but is corrupt. The user should ensure
that transaction data which is consistent with the network model is introduced to working memory
before invoking any open access related procedures.
®
PSS E GUI Users Guide, Section 6.8, Reading Transactions Raw Data
Section 3.9, Entering Transactions Raw Data
See also:
Section 5.51, Creating a Transactions Raw Data File
5.7 Reading / Changing Power Flow Data

Activity RDCH
Run Activity RDCH - GUI

File > Open
[Open]
Power Flow Data File, Options (*.raw)
Run Line Mode Activity RDCH - CLI
ACTIVITY?
>>RDCH
>>
AB
The bulk power flow data input and modification activity RDCH picks up manually-entered power
flow source data and enters it into the power flow working case.
The following API routines are used to implement activity RDCH. Each of them includes among its
input data items the name of the Power Flow Raw Data File to be read and the flag for selecting the
5-43
Reading / Changing Power Flow Data Program Operation Manual
bus names input option of activity RDCH (see Section 5.2, Reading Power Flow Raw Data into the
Working Case and Extended Bus Names).
Rdch Input records are in the format of the PSS®E release indicated in the
file. No other inputs.
RdchRawVersion Input records are in the format of the current or a prior release of
PSS®E. It accepts as input a character string indicating the PSS®E
release.
5.7.1 Operation of Activity RDCH

The input stream to activity RDCH is in the form of a Power Flow Raw Data File (refer to Section
5.2.1, Power Flow Raw Data File Contents), except that the Case Identification Data records are
omitted (i.e., the first data record is expected to be a Bus Data record). All data is read in free format
with data items separated by a comma or one or more blanks. All data categories except the case
identification data must be specified. The end of each category of data is indicated by a record spec-
ifying a value of zero; FACTS device, GNE device, and DC line data input is terminated by
specifying record with a NAME value of either blanks or 0.
Activity RDCH adds a new component to the working case whenever it encounters a data record
for which the corresponding component is not found in the working case. In this case, it behaves
identically to activity READ, and data items omitted on the data record take on the default values
defined in Section 5.2.1, Power Flow Raw Data File Contents.
For all record types except the multi-section line grouping data, when reading a data record corre-
sponding to an existing component, data items that are specified replace those contained in the
working case; data items omitted on the data record have their values unchanged in the working
case (specifically, they are not set to default values as in activity READ).
Activity RDCH prints a warning message at the Progress device if generators have been converted
(see Section 12.2, Converting Generators). After generators are converted, machine impedance
data (MBASE, ZSORCE, XTRAN, and GTAP; refer to Generator Data) must not be changed.
category of data.
Before it has completed reading its input data, activity RDCH may be ended by entering the AB
interrupt control code (refer to Section 4.3, Interruption of PSS®E by the User). Activity RDCH
checks for an interrupt following processing of each group of data records corresponding to 50
equipment items.
Bus Names Option
When the bus names input option of activity RDCH is enabled, data fields designating ac buses on
load, fixed shunt, generator, non-transformer branch, transformer, area, two-terminal dc line, VSC
dc line, multi-terminal dc line, multi-section line, FACTS device, switched shunt, GNE device, and
induction machine data records may be specified as either Extended Bus Names enclosed in single
quotes or as bus numbers. Otherwise, bus numbers must be used to designate ac buses on these
records.
Use of the bus names input option of activity RDCH requires that all buses be assigned unique
extended bus names. Activity RDCH checks for the presence of duplicate extended bus names in
5-44
Program Operation Manual Reading / Changing Power Flow Data
the working case before it starts to read bus data records. Any violations are logged at the Progress
device and activity RDCH is prohibited from executing.
While reading each bus data record with this option enabled, if a bus with the same extended bus
name but a different bus number is present in the working case, an error message is printed, the
record is ignored, and processing continues.
5.7.2 Reading RDCH Data Files Created by Previous Releases of PSS®E

Power Flow Raw Data input in the format required for a prior release of PSS®E is able to be
processed by activity RDCH. The RdchRawVersion API routine is able to handle Power Flow Raw
Data input from as far back as PSS®E-15. The revision number of the release of PSS®E to which
the format of the input records corresponds is specified as an input data item to RdchRawVersion.
Upon being presented with such a file, activity RDCH first converts the file from its original format
to the format required by the current release of PSS®E. It then reads the converted file just as it
would any input stream in the format of the current release.

Activity RDCH always modifies or adds to the working case; it cannot be used to read a new network
model into the working case.
The user has the opportunity to enter all categories of data defined in Section 5.2.1 Power Flow
Raw Data File Contents with the exception of the case identification data.
When specifying a non-transformer branch between buses I and J with circuit identifier CKT, if a
two-winding transformer between buses I and J with a circuit identifier of CKT is already present in
the working case, it is replaced (i.e., the transformer is deleted from the working case and the newly
specified branch is then added to the working case). In this case, omitted data items take on the
standard default values (i.e., none of the data from the deleted transformer is inherited by the non-
transformer branch).
When specifying a two-winding transformer between buses I and J with circuit identifier CKT, if a
non-transformer branch between buses I and J with a circuit identifier of CKT is already present in
the working case, it is replaced (i.e., the non-transformer branch is deleted from the working case
and the newly specified two-winding transformer is then added to the working case). In this case,
omitted data items take on the standard default values (i.e., none of the data from the deleted non-
transformer branch is inherited by the transformer).
In specifying the data records for a multi-terminal dc line I which already exists in the working case,
the values entered for NCONV, NDCBS, and NDCLN on the first data record are the number of
converter, dc bus, and dc link records, respectively, to be read for multi-terminal dc line NAME. If a
component record is then read for a component (e.g., a dc link), which has already been defined as
a part of multi-terminal dc line NAME, the record modifies existing data; if a record is read for a
component not previously included in multi-terminal dc line NAME, the component is added to the
line.
For any multi-section line grouping data records entered in activity RDCH, the complete definition
of the multi-section line must be entered.
In preparing an automation file (Python program, IPLAN program or Response File) that
includes the addition of power flow data to the working case, if long term use of the automation
file is anticipated, the use of the RdchRawVersion API routine rather than RDCH is recommended.
5-45
Producing Power Flow and Fault Analysis Data Checking Reports Program Operation Manual
In this case, no modification of the automation file (at least this portion of it) will be necessary for it
to be used in future releases of PSS®E.
PSS®E GUI Users Guide, Section 6.4, Reading / Changing Power Flow Data
PSS®E Command Line Interface (CLI) Users Guide
Section 3.5, Reading / Changing Power Flow Data
Section 1.254, RAWD_2
Section 1.256, RDCHRAWVERSION
See also:
Section 5.2.1, Power Flow Raw Data File Contents
5.8 Producing Power Flow and Fault Analysis Data Checking

Reports
Activity PFCHK
Activity SCCHK
Run Activity PFCHK and SCCHK - GUI

Power Flow > Check Data > Data checking report
[Power Flow and Fault Analysis Data Checking]
Run Line Mode Activities PFCHK and SCCHK - CLI
ACTIVITY?
>>PFCHK
ACTIVITY?
>>SCCHK
None
When power flow data is input from a Power Flow Raw Data File, as well as when power flow data
is added or modified via the [Spreadsheet] (refer to PSS®E GUI Users Guide, Chapter 2, Spread-
sheet View), many data checks are performed and exceptions reported to the Progress or Alert
device. The CHECK_POWERFLOW_DATA API routine may be used to repeat these checks on
power flow data contained in the working case and provide a report.
Similarly, the CHECK_SEQUENCE_DATA API routine may be used to repeat the checks that are
performed when sequence data is input from a Sequence Data File or when sequence data is modi-
fied via the [Spreadsheet].
This pair of API routines includes the following among its inputs:
5-46
Program Operation Manual Changing Service Status and Power Flow Parametric Data
• A designation of the subsystem for which the data tabulation is to be produced; refer to
Section 4.8, Subsystem Selection.
• A designation of the data category where data values are to be checked
The following data categories are available in activity PFCHK:
• all data categories • bus data

• load data • plant data
• machine data • induction machine data
• fixed bus shunt data • switched shunt data
• non-transformer branch data • two-winding transformer data
• three-winding transformer data • transformer impedance correction data
• multi-section line data • two-terminal dc line data
• multi-terminal dc line data • VSC dc line data
• FACTS device data • GNE device data
• area interchange data • owner data
• zone data
The following data categories are available in activity SCCHK:
• all data categories • load data

• machine data • induction machine data
• fixed bus shunt data • switched shunt data
• non-transformer branch data • two-winding transformer data
• three-winding transformer data • zero sequence mutual data
The report of these activities is directed to the Report device.
When the data checking function is run from the GUI, either or both of these checking API routines
is run, as appropriate.In line mode, the reports are selected independently.
5.9 Changing Service Status and Power Flow Parametric Data

Activity CHNG
Change Data - GUI

Use [Spreadsheet]
Run Line Mode Activity CHNG - CLI
5-47
Changing Service Status and Power Flow Parametric Data Program Operation Manual
ACTIVITY?
>>CHNG
ENTER CHANGE CODE:
0 = EXIT ACTIVITY 1 = BUS DATA
2 = GENERATOR DATA 3 = BRANCH DATA
4 = 2 WINDING TRANSFORMER DATA 5 = AREA INTERCHANGE DATA
6 = TWO-TERMINAL DC LINE DATA 7 = SOLUTION PARAMETERS
8 = CASE HEADING 9 = SWITCHED SHUNT DATA
10 = IMPEDANCE CORRECTION TABLES 11 = MULTI-TERMINAL DC DATA
12 = ZONE NAMES 13 = INTER-AREA TRANSFER DATA
14 = OWNER NAMES 15 = MACHINE OWNERSHIP DATA
16 = BRANCH OWNERSHIP DATA 17 = FACTS CONTROL DEVICE DATA
18 = 3 WINDING TRANSFORMER DATA 19 = VSC DC LINE DATA
20 = FIXED BUS SHUNT DATA 21 = INDUCTION MACHINE DATA:
>>
None
PSS®E permits the user to change all service status, control mode, and other parametric data asso-
ciated with equipment represented in the working case. The appropriate tool for changing working
case data is dependent upon the interface through which PSS®E is being operated.
In the GUI, the primary means of changing individual data items is the [Spreadsheet] (refer to PSS®E
GUI Users Guide, Chapter 2, Spreadsheet View). The [Spreadsheet] may also be used to add new
elements to the working case.
In line mode, the power flow data modification activity CHNG is the primary tool for making data
changes to the working case (refer to PSS®E Command Line Interface (CLI) Users Guide, Section
4.1, Changing Service Status and Power Flow Parametric Data).
In Python programs, the data entry/changing API routines described in Chapter 2, Power Flow Data
Changing of the PSS®E Application Program Interface (API) manual are used to change data asso-
ciated with existing elements in the working case (these routines may also be used to add new
elements to the working case).
In Response Files and IPLAN programs, activity CHNG and/or the data entry/changing API routines
may be used to change power flow data in the working case.
All of these methods modify the working case but do not affect any file. In particular, they do not
affect any Saved Case File or Power Flow Raw Data File. To have data changes incorporated into
a Saved Case File, activity SAVE must be executed following the implementation of changes in the
working case.
5.9.1 Equipment Status Changes

Associated with each ac series branch is a status flag, which is initially set to one (for in-service) or
zero (for out-of-service) as specified on the branch data record or in the transformer record block
when a new branch is introduced into the working case with activities READ, TREA, or RDCH. The
status of a branch may be modified by changing this flag. Out-of-service branches and their data
remain with the case as it is saved and retrieved with activities SAVE and CASE, and are simply
ignored during the execution of other PSS®E activities such as FNSL or POUT.
5-48
Program Operation Manual Changing Service Status and Power Flow Parametric Data
If branch status changes isolate a bus, the user must change the bus type code to 4. Activities
TREE and OUTS and the power flow solution network connectivity check option (refer to Saved
Case Specific Option Settings and activity SOLV) aid the user in identifying isolated buses and
islands.
When the specified branch is a member of a multi-section line grouping (refer to Multi-Section Line
Grouping Data), the same status change is automatically implemented for all branches in the multi-
section line. In addition, the bus type codes of the dummy buses are changed to:
4 When the branch is being removed from service.

1 If the branch is being placed in-service and the bus has no generator data associ-
ated with it.
2 If the branch is being placed in-service and the bus has generator data associated
with it. In this case, the individual machine status flags, which are not changed in
this status processing of multi-section lines, determine which machines are actually
returned to service.
The bus type codes of the endpoint buses of the multi-section line grouping are not changed in the
branch status processing. As with single section lines, it is the user’s responsibility to ensure that
branch statuses and bus type codes are coordinated.
When specifying a branch subject to branch data changes, if a multi-section line grouping is spec-
ified, (i.e., the circuit identifier has an ampersand as its first character; refer to Multi-Section Line
Grouping Data), the user may change the status (and metered end) of the specified multi-section
line grouping. Status changes are implemented as described in the preceding paragraph.
When changing the status of a three-winding transformer, status values of 0 through 4 are permitted
(refer to Transformer Data); the status flags of the three two-winding transformers that comprise the
three-winding transformer are set to the appropriate values. As with multi-section line groupings
and two terminal branches, the bus type codes of the endpoint buses of the three-winding trans-
former are not changed in the branch status processing.
FACTS devices, GNE devices, and dc transmission lines may be blocked in a similar manner. A
value of zero for MODE, the control mode flag, indicates a blocked FACTS device (refer to FACTS
Device Data). A value of zero for STATUS indicates an out-of-service GNE device (refer to GNE
Device Data). A value of zero for MDC, the control mode flag, indicates a blocked dc line (refer to
Two-Terminal DC Transmission Line Data, Multi-Terminal DC Transmission Line Data, and Voltage
Source Converter (VSC) DC Transmission Line Data).
The status of an individual machine at a generator bus may be modified by changing its status flag;
plant total power output and power limits are automatically updated following a change of machine
power or status. A plant may be taken out-of-service either by changing the status of all units at the
bus to zero or by changing the bus type code to 1 or 4 (this is the recommended approach because
power flow solution activities will run slightly faster). Conversely, for a machine to be treated as in-
service, both its status must have the value 1 and the bus type code must be either 2 or 3.
Similarly, the status of an individual load, induction machine fixed shunt, or switched shunt at a bus
may be modified by changing its status. For one of these elements to be treated as in-service, both
its status must have the value 1 and the bus type code must be either 1, 2 or 3. Thus, disconnecting
the bus to which it is connected (i.e., changing the bus type code to 4) also outages any load, induc-
tion machine, fixed shunt, or switched shunt connected to it; it is not necessary to set the device
status to zero.
5-49
Scaling Loads, Generators, and/or Shunts Program Operation Manual
5.9.2 Solution Parameter Changes

The convergence tolerance used by activities SOLV and MSLV (TOL), as well as that of activities
TYSL and BKDY (TOLTY), specifies largest voltage magnitude change in per unit. In activities
FNSL, FDNS, NSOL, and INLF, the mismatch convergence tolerances TOLN and VCTOLQ specify
largest mismatch in MW and Mvar, and the controlled bus voltage error convergence tolerance,
VCTOLV, specifies largest voltage magnitude change in per unit. The blowup threshold (BLOWUP)
is in units of largest voltage magnitude change in per unit and angle change in radians.
5.9.3 Interarea Transfer Data Changes

When modifying interarea transfer data, changes in transfer MW may optionally be applied to the
desired area net interchange values of both the from and to areas (refer to Area Interchange Data).
The new desired net interchange of the from area is set to its old value plus the change in transfer
MW. Similarly, the to area’s desired net interchange is set to its old value minus the transfer MW
change.
Section 7.1, Changing Service Status and Power Flow Parametric Data
See also:
Section 5.2, Reading Power Flow Raw Data into the Working Case
5.10 Scaling Loads, Generators, and/or Shunts

Activity SCAL
Run Activity SCAL - GUI

Power Flow > Changing > Scale generation, load, shunt (SCAL)…
[Scale Powerflow Data]
Run Line Mode Activity SCAL - CLI
ACTIVITY?
>>SCAL
ENTER UP TO 20 BUS NUMBERS
>>
None
System planners and operators need the ability to analyze a wide range of demand and generation
scenarios. Often the need is to study a variety of demand levels that cover a daily, weekly or a
seasonal profile. To facilitate simple and rapid changes in load level, PSS®E provides a means by
which not only loads but also generation and fixed bus shunts can be scaled.
5-50
Program Operation Manual Scaling Loads, Generators, and/or Shunts
The load, generation and shunt scaling activity SCAL enables the user to uniformly increase or
decrease any or all of the following quantities for a specified grouping of loads, fixed shunts, and
synchronous machines:
• Load active power.

• Load reactive power.
• Active component of fixed bus shunt admittance.
• Positive reactive component of fixed bus shunt admittance (capacitors).
• Negative reactive component of fixed bus shunt admittance (reactors).
• Generator active power output (positive generation); excludes induction machines.
• Motor active power output (negative generation); excludes induction machines.
The SCAL_2 API routine includes the following among its inputs:
• A designation of the subsystem in which the generation, load and/or shunt is to be pro-
cessed; refer to Section 4.8, Subsystem Selection.
• An interruptible load scaling caption.
• The methods used to specify scaling targets.
• The scaling targets.
• A flag to either enforce or ignore machine active power limits.
5-51
5.10.1 Operation of Activity SCAL

The user specifies either that the entire working case is to be processed or that the generation, load
and/or shunt in a designated bus subsystem is to be processed. Any machine in the specified
subsystem where the active power output is outside of its active power limits generates an alarm.
The reactive components of in-service fixed bus shunts are separated into capacitors and reactors
(inductors), and different scaling may be applied to each category.
Any in-service machine in the subsystem being processed where the active power output is nega-
tive is treated as a motor. Motor totals are excluded from the generator totals; rather, motors are
handled separately and the user is able to apply different scaling to generators and motors. If no
motors are contained in the subsystem being processed, the motor tabulations are suppressed.
When scaling to new total powers, the following rule is applied in determining the individual bus,
load, or machine powers:
Adjust the power such that, at each load, fixed shunt, or machine, the ratio of
individual load, fixed shunt, or machine power to the total power of all loads,
fixed shunts, or machines being processed remains unchanged.
Details on the scaling of fixed shunts, loads, and generation are given in Sections 5.10.2,
Section 5.10.3 Scaling Loads and Section 5.10.4 Scaling Generation, respectively.
Pre- and post-scaling subsystem totals are tabulated as in the following example:
Present totals:
Load-MW 3200.0 ( Scaling 2700.0: 1500.0 Interruptible + 1200.0 Non-interruptible
+ Unchanged 500.0: 200.0 Interruptible + 300.0 Non-interruptible )
Load-Mvar 1950.0 ( Scaling 1750.0: 850.0 Interruptible + 900.0 Non-interruptible
Generation 3248.9
Shunt-MW 0.0
Reactors -900.0
Capacitors 550.0
New totals:
Load-MW 3220.0 ( Scaling 2720.0: 1511.1 Interruptible + 1208.9 Non-interruptible
Load-Mvar 1963.0 ( Scaling 1763.0: 856.3 Interruptible + 906.7 Non-interruptible
Generation 3268.9
Shunt-MW 0.0
Reactors -900.0
Capacitors 550.0
5.10.2 Scaling Fixed Shunts

Shunt totals include only those fixed shunts at buses in the specified subsystem which would be
modeled during network solutions (i.e., in-service fixed bus shunts at non-Type 4 buses). Shunt
quantities are tabulated and scaled as nominal values (i.e., at unity voltage).
The reactive components of in-service fixed bus shunts are separated into capacitors and inductors,
and different scaling may be applied to each category.
5-52
5.10.3 Scaling Loads

Only loads that are in-service at non-Type 4 buses are included in the load totals and processing of
activity SCAL. Loads that are categorized as non-scalable are not changed by activity SCAL (i.e.,
only scalable loads are scaled). Both interruptible and non-interruptible loads may be scaled, or
load scaling may be restricted either to only interruptible loads or to only non-interruptible loads.
When the entire working case is being processed by activity SCAL, all in-service loads in the
working case are processed.
When the subsystem being processed is selected only by bus, all in-service loads at subsystem
buses for which the Type code is not 4 are included in the load totals and subsequent scaling.
When the subsystem being processed is selected only by base voltage level, activity SCAL pro-
cesses all in-service loads at each non-Type 4 bus for which the base voltage falls within the
specified base voltage band.
When a single subsystem selection criterion of area, zone, or owner is used, each in-service load
assigned to one of the areas, zones, or owners specified is processed (see Load Data). The area,
zone, or owner assignments of buses (see Bus Data) are not considered in these subsystem selec-
tion modes.
When multiple subsystem selection criteria are enabled, the base voltage and/or bus selection cri-
teria, if enabled, dictate those buses where the loads are candidates for processing; otherwise, all
buses are candidates for processing. The area, zone, and/or owner selection criteria, if enabled,
dictate which loads at candidate buses are to be included; otherwise, all loads at candidate buses
are included.
Load totals include voltage dependent effects (e.g., PQBRAK is recognized; see Constant Power
Load Characteristic).
The load totals are the sums of any constant power, current, and admittance components of those
loads being scaled; all of these load components are scaled by the same factor.
Subsystem active and reactive load are scaled separately. Reactive load may be handled in one of
the following ways:
• Modify the reactive component of each load such that the existing P/Q ratio is retained
(i.e., retain the existing load power factor for each load).
• Specify a new total reactive load.
• Specify the percent by which the reactive loads are to be changed.
• Specify a new load power factor to be used at all loads being processed.
• Specify the amount of reactive load by which the total reactive load is to be increased.
• Leave it unchanged.
5.10.4 Scaling Generation

Machines with positive active power generation are included in the generator totals, and those with
negative active power generation are included in the motor totals. The discussion below is in terms
of generator totals, but the same approach is used for motor totals.
5-53
Only machines that are in-service at Type 2 and 3 buses are included in the generator totals and
processing of activity SCAL.
When the entire working case is being processed by activity SCAL, all in-service generators in the
working case are processed.
When the subsystem being processed is selected only by bus, all in-service generators at sub-
system buses for which the Type code is 2 or 3 are included in the generator totals and subsequent
scaling.
When the subsystem being processed is selected only by base voltage level, activity SCAL pro-
cesses all in-service generators at each Type 2 or 3 bus where the base voltage falls within the
specified base voltage band.
When a single subsystem selection criterion of area or zone is used, each in-service generator con-
nected to a bus assigned to one of the areas or zones specified is processed (see Bus Data).
When the single subsystem selection criterion of owner is used, each such machine wholly or partly
owned by any of the owners specified is processed (see Generator Data). The owner assignments
of buses are not considered.
When multiple selection criteria are enabled, the area, zone, base voltage, and/or bus selection cri-
teria, if enabled, dictate those buses for which the machines are candidates for processing;
otherwise, all buses are candidates for processing. The owner selection criterion, if enabled, dic-
tates which machines at candidate buses are to be included; otherwise, all machines with positive
active power generation at candidate buses are included.
When active power limits are enforced, any active power limits of machines being scaled that are
negative are temporarily set to zero. When reducing the subsystem’s active power generation by a
large amount, this prevents any such machines from having their active power settings set to a
negative value as other machines are set at their lower active power limits. The active power limit
totals shown in the display of activity SCAL are calculated using these modified limits.
In scaling generation, it is useful to remember the following points:
• Activity SCAL is not a dispatch activity; it merely scales the existing active power output
of in-service machines such that the ratio of machine to total power is retained.
Machine power limits are recognized only if the user selects that option.
• If a system swing (Type 3) bus is in the subsystem being scaled, the working case
should be solved so that the swing power, which is included in the total generation, is
reasonable.
• If the total generation is being changed by a large amount, the new generator outputs,
as set by activity SCAL, should be examined to verify that machines are set at realistic
operating points. Activities LIST, GENS, and GEOL are helpful for this purpose. (For
these situations, the unit commitment/economic dispatch activity, ECDI may be more
appropriate.)
5.10.5 Scaling Example

In this example, all active power load is scaled by + 2% while maintaining a constant P/Q ratio. No
scaling is be imposed on active power generation. Consequently, the swing bus will need to
generate the increased power as well any additional system losses.
5-54
Figure 5-30 shows the total loads, the swing bus power and the system losses in the savnw.sav
Saved Case File prior to scaling. That data includes the total real load (3,200 MW), the total gener-
ation real power (3,258.7 MW) and the total reactive power for bus connected reactors and
capacitor (600 Mvar and 950 Mvar, respectively). In addition the total reactive component of load is
indicated to be 1,950 Mvar. Figure 5-31 shows the same data after scaling and resolving the case.
Figure 5-30. Pre-Scaling Load, Generation, Losses and Swing Bus Output
Figure 5-31. Post-Scaling Load, Generation, Losses and Swing Bus Output
5-55
Electrically Disconnecting a Bus Program Operation Manual
Section 7.9, Scaling Loads, Generators, and/or Shunts
Section 4.11, Scaling Loads, Generators, and/or Shunts
PSS®E Application Program Interface (API), Section 1.280, SCAL
See also:
Load Data
Fixed Bus Shunt Data
Generator Data
5.11 Electrically Disconnecting a Bus

Activity DSCN
Run Activity DSCN - GUI

Power Flow > Changing > Disconnect / Reconnect bus (DCSN/RECN)…
[Disconnect / Reconnect Bus]
OPTION: Disconnect bus
Run Line Mode Activity DSCN - CLI
ACTIVITY?
>>DSCN
ENTER BUS NUMBER:
>>
None
The bus disconnection activity DSCN automates the data changes required to electrically isolate a
bus.
The only input to the DSCN API routine is the number of the bus to be disconnected. If the specified
bus is not contained in the working case, an appropriate message is printed at the Alert device.
For each bus processed, its Type code is set to 4 and all ac branches, dc lines, series FACTS
devices, and series GNE devices connected to the bus are set to out-of-service. The status flags of
bus connected equipment (e.g., loads, FACTS devices without a series element, etc.) is not
changed by activity DSCN; they are, however, treated as out-of-service because such elements are
in-service only if the Type code of the bus to which they are connected is 1, 2 or 3 (refer to Section
5.9.1, Equipment Status Changes).
If the bus being processed is the endpoint bus of a multi-section line grouping (refer to Multi-Section
Line Grouping Data), the entire multi-section line grouping is removed from service; i.e., each line
section is set to out-of-service and each dummy bus has its type code set to 4.
Similarly, if the bus being processed is a dummy bus of a multi-section line grouping, the multi-
section line is removed from service (refer to Section 5.9.1, Equipment Status Changes).
5-56
Program Operation Manual Electrically Reconnecting a Bus
If a three-winding transformer (refer to Transformer Data) is connected to the bus being processed,
all three windings of the transformer are removed from service.
For each bus disconnected, a summary of bus type code and branch status changes is printed at
the Progress device. Figure 5-32 shows an example in which five circuits have been removed from
service as a result of disconnecting a bus. This summary, however, does not list the bus connected
equipment that is taken out-of-service as a result of the setting of the bus Type code to 4.
Figure 5-32. Bus Disconnect Progress Output
®
PSS E GUI Users Guide, Section 7.1, Changing Service Status and Power Flow Parametric
Data
Section 4.2, Electrically Disconnecting a Bus
PSS®E Application Program Interface (API), DSCN
See also:
Section 5.9.1, Equipment Status Changes
Section 5.12, Electrically Reconnecting a Bus
5.12 Electrically Reconnecting a Bus

Activity RECN
Run Activity RECN - GUI

Power Flow > Changing > Disconnect / Reconnect bus (DCSN/RECN)…
OPTION: Connect bus
Run Line Mode Activity RECN - CLI
ACTIVITY?
>>RECN
ENTER BUS NUMBER:
>>
None
5-57
Electrically Reconnecting a Bus Program Operation Manual
The bus reconnection activity RECN automates the data changes required to electrically reconnect
a disconnected (i.e., Type 4) bus. That is, activity RECN is the logical inverse of activity DSCN.
The only input to the RECN API routine is the number of the bus to be reconnected. If the specified
bus is not contained in the working case, an appropriate message is printed at the Alert device.
For each bus processed, if its Type code is 4, it is set to 2 if there is a plant table entry assigned to
the bus or to 1 if no generator data is associated with the bus. Then all branches and other series
elements connected to the bus for which the to bus is not a Type 4 bus are set to in-service. All two-
terminal and multi-terminal dc lines returned to service are placed in power control mode. All series
FACTS devices returned to service have their control modes set to a positive value as described
below. A summary of bus type code and branch status changes is printed at the Progress tab.
The status flags of bus connected equipment (e.g., loads, FACTS devices without a series element,
etc.) is not changed by activity RECN. If the bus had been disconnected by activity DSCN, they
retain the service status that they had before they were disconnected because DSCN did not
change their status flags (refer to Section 5.11, Electrically Disconnecting a Bus).
If the bus being processed is the endpoint bus of a multi-section line grouping (refer to Multi-Section
Line Grouping Data), the entire multi-section line grouping is returned to service as long as the Type
code of the other endpoint bus is not 4; i.e., each line section is set to in-service and each dummy
bus has its type code set to 1 (if there is no generator data for the dummy bus) or 2 (if there is a
generator slot for the dummy bus).
Similarly, if the bus being processed is a dummy bus of a multi-section line grouping, the multi-
section line is set to in-service as long as the Type codes of neither of the two end point buses is 4
(refer to Section 5.9.1, Equipment Status Changes).
If a three-winding transformer (refer to Transformer Data) is connected to the bus being processed,
all three windings of the transformer are set to in-service as long as the Type codes of neither of the
other two buses connected to the transformer is 4; otherwise, the three-winding transformer
remains out-of-service.
5-58
Program Operation Manual Outage "Stalled" and "Tripped" Induction Machines
Any series FACTS device that is returned to service has its control mode set as follows:
3 if it was previously holding constant series impedance and then was

outaged via activity DSCN.
4 if it was previously holding constant series voltage and then was outaged
via activity DSCN.
5 through 8 as appropriate, if it was previously a series element of an IPFC and then
was outaged via activity DSCN.
1 in all other cases.
Section 4.3, Electrically Reconnecting a Bus
RECN
See also:
Section 5.9.1, Equipment Status Changes
Section 5.11, Electrically Disconnecting a Bus
5.13 Outage "Stalled" and "Tripped" Induction Machines

Activity ImOutage
Run Activity ImOutage - GUI

Power Flow > Changing > Outage "stalled" / "tripped" induction machines…
[Outage "stalled" / "tripped" Induction Machines]
None
The induction machine outaging activity ImOutage allows the user to change the status of induction
machines that are in-service, but that have been set to the "stalled" (for motors) or "tripped" (for
generators) state by the power flow solution, to out-of-service (refer to Section 6.3.14, Induction
Machines).
The ImOutage API routine includes the following among its inputs:
• A designation of the subsystem in which "stalled" and/or "tripped" induction machines

are to be removed from service.
• An option to outage "stalled" induction motors.
• An option to outage "tripped" induction generators.
When processing induction machines in a bus subsystem, the bus and/or base voltage selection
criteria, if enabled, determine those buses whose connected induction machines are candidates for
outaging; otherwise, all buses are candidate buses. The area, owner, and/or zone selection crite-
5-59
Removing Specified Buses and Connected Equipment Program Operation Manual
rion, if enabled, determine which induction machines at candidate buses are checked for outaging;
otherwise, all induction machines at candidate buses are checked for outaging.
Following the processing of activity ImOutage, if the option to outage "stalled" induction motors was
enabled, the number of motors that have been placed out-of-service is printed at the Progress
device. Similarly, if the option to outage "tripped" induction generators was enabled, the number of
generators that have been placed out-of-service is printed at the Progress device.
®
PSS E Application Program Interface (API) Section 1.105, ImOutage
5.14 Removing Specified Buses and Connected Equipment

Activity EXTR
Run Activity EXTR - GUI

Power Flow > Changing > Delete network elements (PURG/EXTR)…
[Delete Buses and Outaged Network Elements]
OPTION: Remove Buses from Case
Run Line Mode Activity EXTR - CLI
ACTIVITY?
>>EXTR
>>
None
The bus removal activity EXTR removes subsystem buses and all equipment connected to them
from the working case, regardless of their service status. Because EXTR irrevocably deletes data
from the working case, it is strongly recommended that a Saved Case File of the working case be
made with activity SAVE prior to using activity EXTR.
The EXTR API routine includes the following among its inputs:
• A designation of the subsystem from which buses and their connected equipment are
to be deleted; refer to RECN.
• An option to remove generator table entries for out-of-service plants. When enabled,
this option results in the removal of plant and machine table entries for all Type 1 buses
in the case (i.e., for all buses in the case at which the plant is currently out-of-service).
The proper selection for this option is dependent upon the application at hand. When
activity EXTR is being used to set up the working case in preparation for building an
equivalent of a subsystem contained within it, the usual procedure is to enable this
option. For other applications, it is often desirable to retain these plant table allocations
if the machines may subsequently be returned to service.
• An option to change the type codes of boundary buses. When enabled, this option
results in adding the value 4 to the bus type codes of boundary buses, which are
5-60
Program Operation Manual Deleting Equipment
retained in the working case following the processing of activity EXTR. A boundary bus
is defined as a bus that is retained in the working case that is connected to a bus that
is deleted. The normal procedure is to disable this option unless some advanced equiv-
alencing operation is to be applied to the resultant working case.
Activity EXTR rebuilds all data arrays in the working case, compacting them to eliminate holes
created by the deleted equipment. New bus sequence numbers, generator sequence numbers, and
so on are assigned.
A three-winding transformer is removed if any of the buses it connects are removed.
A dc transmission line is removed if any of the buses designated as its converter station buses are
deleted.
A FACTS device is removed if either its sending end bus or terminal end bus is deleted.
A GNE device is removed if any bus to which it is connected is deleted.
A multi-section line grouping is deleted if at least one of its line sections is removed. This does not
mean that the remaining line sections and dummy buses are deleted from the working case; only
the information defining the multi-section line grouping itself is removed.
For any bus where voltage is being controlled by a remote generator, switched shunt, FACTS
device shunt element, or VSC dc line converter, an alarm is printed if the controlled bus is deleted
while the voltage controlling equipment is retained. The controlling equipment is then set to control
local bus voltage and the scheduled voltage setpoint or band is not changed.
For any bus with voltage controlling equipment that is being controlled by a remote switched shunt,
an alarm is printed if the controlled bus is deleted while the controlling switched shunt bus is
retained. The switched shunt’s control mode is not changed.
Following the processing of activity EXTR, the number of buses that have been deleted is printed
at the Progress device.
Section 7.8, Removing Buses and Connected Equipment
Section 4.8, Removing Specified Buses and Connected Equipment
PSS®E Application Program Interface (API), EXTR
5.15 Deleting Equipment

Activity PURG
Run Activity PURG - GUI

Power Flow > Changing > Delete network elements (PURG/EXTR)…
[Delete Buses and Outaged Network Elements]
OPTION: Remove outaged equipment
5-61
Deleting Equipment Program Operation Manual
Delete Individual Equipment Elements - GUI

Use [Spreadsheet]
Run Line Mode Activity PURG - CLI
ACTIVITY?
>>PURG
>>
ACTIVITY?
>>PURG,SINGLE
EQUIPMENT ITEMS WHICH MAY BE REMOVED ARE:

1 = AC LINES 2 = SWITCHED SHUNTS
3 = MACHINES 4 = PLANTS
5 = 2-TERMINAL DC LINES 6 = MULTI-TERMINAL DC LINES
7 = MULTI-SECTION LINE 8 = ZERO SEQUENCE MUTUALS
9 = INTER-AREA TRANSFERS 10 = LOADS
11 = FACTS DEVICES 12 = THREE-WINDING TRANSFORMERS
13 = VSC DC LINES 14 = FIXED BUS SHUNTS
ENTER EQUIPMENT CATEGORY CODE (0 TO EXIT):
>>
None
The equipment removal activity PURG deletes designated equipment items from the working case.
Activity PURG may be used to remove either individually specified equipment items or all outaged
items of a specified equipment category that are contained in a specified subsystem of the working
case.
Because PURG irrevocably deletes data from the working case, it is strongly recommended that
a Saved Case File of the working case be made with activity SAVE prior to using activity PURG.
5.15.1 Removing Individual Equipment Items

In the GUI, the primary means of deleting individual equipment items is the [Spreadsheet] (refer to
PSS®E GUI Users Guide, Chapter 2, Spreadsheet View).
In line mode, the equipment removal activity PURG selected with the suffix SINGLE (or simply SI)
is the primary tool for deleting individual equipment items (refer to PSS®E Command Line Interface
(CLI) Users Guide, Section 4.9, Deleting Equipment).
In Python programs, over 20 PURGaaa API routines described in Chapter 1, Power Flow Operation
of the PSS®E Application Program Interface (API) manual are used to remove individual items from
the working case.
In Response Files and IPLAN programs, activity PURG,SINGLE and/or the equipment removal API
routines may be used to delete individual items from the working case.
In removing multi-section line groupings, the branches and dummy buses that are members of a
deleted multi-section line grouping are not removed from the working case; only the definition of the
grouping is deleted.
5-62
Program Operation Manual Deleting Equipment
5.15.2 Removing Outaged Equipment in a Subsystem

Activity PURG may be used to remove from the working case all outaged equipment of a desig-
nated equipment category connected to buses within a specified subsystem.
The PURG API routine includes the following among its inputs:
• A designation of the subsystem from which out-of-service equipment is to be deleted;

refer to Section 4.8, Subsystem Selection.
• An integer indicating the type of equipment to be removed. The following equipment
types are allowed:
- ac branches (non-transformer branches and two-winding transformers)
- Three-winding transformers
- Loads
- Synchronous
- Machines
- Plants
- Induction machines
- Fixed bus shunts
- Switched shunts
- FACTS devices
- Two-terminal dc lines
- Multi-terminal dc lines
- VSC dc lines
- GNE devices
• An integer indicating the treatment of out-of-service tie branches to other subsystems.
Such branches may either be kept in the working case or deleted.
When the entire working case is selected for processing, all out-of-service elements of the selected
category are deleted, and the out-of-service tie branches option is ignored.
Otherwise, the area, zone, and/or owner assignments of buses are used to determine which equip-
ment items are to be processed when subsystem selection by area, zone, and/or owner is enabled.
The owner assignments of synchronous machines, ac branches, three-winding transformers,
FACTS devices, and GNE devices, and the area, zone, and owner assignments of loads, and induc-
tion machines are not considered.
The option indicating the treatment of outaged subsystem ties applies in the processing of ac
branches, three-winding transformers, dc lines, series FACTS devices, and series GNE devices.
When choosing to remove out-of-service ties, any outaged branch with at least one bus in the spec-
ified subsystem is deleted. Otherwise, a branch is deleted only if all buses connected by the branch
are in the specified subsystem. In the case of multi-terminal dc lines, only the ac converter buses
are considered in determining if all buses are in the specified subsystem; specifically, the area,
zone, and owner assignments of the dc buses are not considered.
Each deleted item is reported at the Progress device. As the processing of an equipment category
is completed, the number of items of that category that were deleted is tabulated.
5-63
Deleting Equipment Program Operation Manual
Activity PURG deletes subsystem equipment items as follows:
ac branches The branch status flag is zero or negative.

Switched shunts The switched shunt status flag is zero.
Synchronous The machine status flag is zero or negative.
Machines
Plants The bus type code is 1 or greater than 3.
Induction machines The machine status flag is zero or negative.
Loads The load status flag is zero or negative.
Fixed bus shunts The shunt status flag is zero or negative.
dc lines The control mode is zero.
FACTS devices The control mode is zero.
Three-winding The status flag is zero.
transformers
GNE devices The device status is zero.
5.15.3 Example of Activity PURG

Figure 5-33 displays the output of activity PURG for ac branches.
Figure 5-33. Purging the Branches Data Category

The user must understand the difference between the use of activity PURG and the changing of the
service status of an equipment item as may be done in activity CHNG (refer to Sections 5.9.1 and
Section C.8.1, Equipment Status Changes and the Spreadsheet View) or the [Spreadsheet].
Changing the service status flag simply indicates that the equipment item is to be ignored during
PSS®E network solution and output activities. Activity PURG permanently removes the equipment
item and all its data from the working case.
In deleting loads from the working case, if all loads at a bus are removed, an appropriate message
is printed. Similarly, in deleting fixed bus shunts from the working case, if all fixed shunts at a bus
are removed, an appropriate message is printed. Similarly, in deleting induction machines from the
working case, if all induction machines at a bus are removed, an appropriate message is printed.
In deleting machines from the working case, if all machines at a bus (plant) are removed, an appro-
priate message is printed and the plant data at the bus is also deleted.
If the plant entry of any area swing bus is deleted, an appropriate message is printed and the area
swing bus number is set to zero (refer to Area Interchange Data and Area Interchange Control).
5-64
Program Operation Manual Joining Buses
If a branch that is a member of a multi-section line grouping is deleted, an appropriate message is

printed and the multi-section line grouping is deleted.
Activity PURG does not check that the working case is in the form required by the power flow solu-
tion activities. The user is advised to use activities such as TREE (to check for islands and system
swing bus specification) and LIST (to check the area interchange control parameters) before
attempting to solve the modified case.
®
PSS E GUI Users Guide, Section 7.8, Removing Buses and Connected Equipment
PSS®E Command Line Interface (CLI) Users Guide, Section 4.9, Deleting Equipment
Section 1.211, PURG
Section 1.212, PURG2DC
Section 1.213, PURG3WND
Section 1.214, PURGAREA
Section 1.215, PURGATRN
Section 1.216, PURGBRN
Section 1.217, PURGFACTS
Section 1.218, PURGGNE
Section 1.221, PURGLOAD
Section 1.222, PURGLOADS
Section 1.223, PURGMAC
Section 1.224, PURGMDC
Section 1.225, PURGMSL
Section 1.226, PURGMUT
Section 1.227, PURGOWNER
Section 1.228, PURGPLNT
Section 1.229, PURGSHUNT
Section 1.230, PURGSHUNTS
Section 1.231, PURGSWS
Section 1.232, PURGVSC
Section 1.233, PURGZONE
Section 1.234, PURGE_MULTI_TERM_DC_BUS
Section 1.235, PURGE_MULTI_TERM_DC_CONVR
Section 1.236, PURGE_MULTI_TERM_DC_LINK
5.16 Joining Buses

Activity JOIN
Run Activity JOIN - GUI

Power Flow > Changing > Join buses (JOIN)…
[Join Buses]
Run Line Mode Activity JOIN - CLI
5-65
Joining Buses Program Operation Manual
ACTIVITY?
>>JOIN
ENTER 1 TO ADD LINE SHUNTS OF DELETED
IN-SERVICE BRANCHES TO RETAINED BUS SHUNT:
>>
None
The bus joining activity JOIN enables the user to combine pairs of buses, retaining the identity of
one of the two buses. It is intended primarily to bolt together buses that are connected by a low
impedance jumper branch. However, activity JOIN allows any pair of buses to be joined together,
regardless of the impedance of any connecting branches or whether there is a branch between
them at all.
The JOIN API routine includes the following among its inputs:
• The number of the bus to be retained.

• The number of the bus to be joined to the retained bus; this bus is removed from the
working case.
• An integer indicating the treatment of non-zero line shunts on branches and magne-
tizing admittance on transformers that connect the specified buses; these series
elements are removed from the working case. Line shunts of deleted in-service
branches may be handled using one of the following methods:
- They are added to the retained bus as a fixed bus shunt with the identifier LS; if a
shunt with the identifier LS already exists at either of the buses, an available iden-
tifier is assigned.
- They are neglected.
5-66
Program Operation Manual Joining Buses
5.16.1 Operation of Activity JOIN

The following conditions generate an alarm at the Alert device and the buses are not joined:
• Either of the specified buses is not contained in the working case.

• The resulting retained bus would have more synchronous machines, loads, induction
machines, or fixed shunts than are able to be accommodated with unique identifiers.
• Either of the buses has a type code of 4 or greater.
• The two buses are connected by a three-winding transformer.
• There is not enough room in the bus tables to handle the processing of three-winding
transformers connected to the bus to be deleted
If both buses are accepted, activity JOIN applies the required changes to the working case.
In joining buses together, activity JOIN retains the identity of the first bus entered. This includes the
bus attributes of number, name, base voltage, area, zone, and owner. Any branches between the
buses being joined are removed from the working case, with line connected shunts and magnetizing
admittances handled in accordance with the line shunt treatment input option.
All other branches originally emanating from the bus being removed are rerouted to the retained
bus. If there are branches from the two specified buses to a common third bus with identical circuit
identifiers, branches originally connected to the retained bus keep their original circuit identifiers
and new identifiers are assigned to the rerouted circuits.
All loads at the bus being removed are transferred to the retained bus. In the case of conflicting load
identifiers, those loads originally at the retained bus keep their original identifiers and new identifiers
are assigned to the transferred loads.
Similarly, all fixed bus shunts at the bus being removed are transferred to the retained bus. In the
case of conflicting shunt identifiers, those shunts originally at the retained bus keep their original
identifiers and new identifiers are assigned to the transferred shunts.
Similarly, all induction machines at the bus being removed are transferred to the retained bus. In
the case of conflicting machine identifiers, those induction machines originally at the retained bus
keep their original indetifiers and new identifiers are assigned to the transferred induction machines.
If the retained bus is not a generator bus and the deleted one is, the plant and machine data of the
removed bus is transferred to the retained bus. If both buses are generator buses, machines from
the removed bus are transferred to the retained bus and plant totals are updated. In the case of
conflicting machine identifiers, those machines originally at the retained bus keep their original
machine identifiers and new identifiers are assigned to the transferred machines.
All changes to branch, load, shunt, and machine identifiers are reported at the Progress device
(refer to Section 4.4, Virtual Output Devices). Alternative identifier settings may be implemented via
activity MBID either before or after the execution of activity JOIN.
If the retained bus does not have a switched shunt and the deleted one does, the switched shunt
of the removed bus is transferred to the retained bus.
5-67
Joining Buses Program Operation Manual
If both buses have switched shunts, the switched shunts are merged, with blocks being assigned
in the following order:
1. Reactors from the removed bus.
2. Reactors from the retained bus.
3. Capacitors from the retained bus.
4. Capacitors from the removed bus.
Control parameters from the retained bus are kept unless the switched shunt at the retained bus
controls the admittance setting of the switched shunt at the removed bus. In this case, the control
parameter data items (MODSW, VSWHI, VSWLO, SWREM, RMPCT and RMIDNT) of the removed
bus are transferred to the retained bus.
If either the retained bus or removed bus is involved in multi-section line groupings, each such
grouping is either:
• Redefined if the topology change results in a valid multi-section line grouping.

• Deleted if the redefined grouping violates any of the requirements for multi-section line
groupings (refer to Multi-Section Line Grouping Data).
If sequence data is contained in the working case (refer to RESQ), it is handled appropriately,
including the rerouting or removal of zero sequence mutuals. If the option to move line shunts of
deleted branches to the retained bus is enabled, such zero sequence line shunts are handled in the
same manner as they are in the positive squence. Zero sequence switched shunts are treated in
the same manner as they are in the positive sequence.
5.16.2 Example Progress Output
Figure 5-34. Join Buses Summary Report on Relocation of Load
The example summary report (Figure 5-34) indicates that the load on Bus 3008, with identifier 1,
was moved to bus 154 and its identifier changed to 3 so as to avoid conflict with two existing loads
on that bus.
®
PSS E GUI Users Guide, Section 7.3, Joining Buses
PSS®E Command Line Interface (CLI) Users Guide, Section 4.4, Joining Buses
PSS®E Application Program Interface (API), Section 1.114, JOIN
5-68
Program Operation Manual Splitting Buses
5.17 Splitting Buses

Activity SPLT
Run Activity SPLT - GUI

Power Flow > Changing > Split buses (SPLT)…
[Split Buses]
Run Line Mode Activity SPLT - CLI
ACTIVITY?
>>SPLT
ENTER BUS NUMBER:
>>
None
The bus sectionalizing activity SPLT enables the user to split a bus into two buses connected by a
branch.
The SPLT API routine includes the following among its inputs:
• The number of the bus to be split.

• The number to be assigned to the new bus; the bus number specified must not already
be assigned to another bus in the working case.
• The name to be assigned to the new bus.
• The base voltage to be assigned to the new bus.
5.17.1 Operation of Activity SPLT

The new bus is given the same area, zone, and owner assignments as the original bus. When
generation is moved from the original to the new bus, the new bus is assigned the bus type code of
the original bus. If all machines are moved to the new bus, the original bus becomes a Type 1 bus.
If no machines are moved to the new bus, the original bus type code is unchanged and the new bus
becomes a Type 1 bus with no generator entry.
A new jumper branch is created connecting the original and new buses. If the zero impedance line
threshold tolerance, THRSHZ, is greater than zero, this branch is created as a zero impedance line
(refer to Zero Impedance Lines). Otherwise, a branch with an impedance of j0.0001 is introduced
between the original and new buses. The new branch is given the same owner as the original bus.
If the original bus is an endpoint bus of one or more multi-section line groupings and the adjacent
line section of a multi-section line grouping is rerouted to the new bus, the new bus becomes the
endpoint bus of the multi-section line.
5-69
Splitting Buses Program Operation Manual
Activity SPLT optionally allows some or all of each of the following equipment items connected to
the bus being split to be transferred to the new bus:
• Synchronous machines.
• Induction machines.
• Loads.
• Fixed bus shunts (available only from the GUI; when running activity SPLT in line mode,
any fixed shunts connected to the bus being split remain there).
• Switched shunt.
• Ac branches.
If the original bus is a dummy bus of a multi-section line grouping, the multi-section line grouping is
either:
• Redefined if exactly one of the two branches connected to the original bus is rerouted
to the new bus.
• Deleted if neither or both are rerouted to the new bus.
The new bus is given a type code of 1 (or 2 or 3 if generation is moved to it) and the jumper branch
between the original bus and the new bus is set to in-service unless the new bus becomes a dummy
bus of an out-of-service multi-section line grouping; in this case, the bus type code is set to 4 and
the jumper branch is set to out-of-service.
If sequence data is contained in the working case (refer to RESQ), it is handled appropriately,
including the rerouting of zero sequence mutuals. Branches introduced by activity SPLT have their
zero sequence impedances set to j0.0001.
After they have been created with activity SPLT, the data associated with the new bus and branch
may be modified with activity CHNG or with the [Spreadsheet] (and with activity SQCH if sequence
data is contained in the working case) just as any other bus and branch in the working case.
5.17.2 Example of Activity SPLT

Using the savnw.sav Saved Case File, bus 3003 can be split and circuit 2 from bus 3005 reassigned
to the new bus 3020. In the example, the option to move circuit 2 from bus 3005 to the new bus has
been selected. A summary of the changes is shown in the Progress tab (Figure 5-35).
Figure 5-35. Output Report Summary for Bus Split
5-70
Program Operation Manual Tapping a Line
®
PSS E GUI Users Guide, Section 7.4, Splitting Buses
PSS®E Command Line Interface (CLI) Users Guide, Section 4.5, Splitting Buses
PSS®E Application Program Interface (API)
Section 1.306, SPLT
Section 1.155, MOVE3WND
Section 1.156, MOVEBRN
Section 1.157, MOVELOAD
Section 1.158, MOVELOADS
Section 1.159, MOVEMAC
Section 1.160, MOVEPLNT
Section 1.161, MOVESHUNT
Section 1.162, MOVESHUNTS
Section 1.163, MOVESWS
5.18 Tapping a Line

Activity LTAP
Run Activity LTAP - GUI

Power Flow > Changing > Tap line (LTAP)…
[Tap Line]
Run Line Mode Activity LTAP - CLI
ACTIVITY?
>>LTAP
ENTER FROM BUS, TO BUS, CIRCUIT IDENTIFIER
(FROM BUS = 0 TO EXIT):
>>
None
The line tapping activity LTAP enables the user to introduce a new bus into the working case at a
designated location along a specified ac branch. Any non-transformer branch may be tapped with
activity LTAP.
The LTAP API routine includes the following among its inputs:
• The two buses connected by the branch to be tapped.

• The circuit identifier of the branch to be tapped.
• The location of the new bus relative to the first bus specified in per unit of total line
length.
• The number to be assigned to the new bus; the bus number specified must not already
be assigned to another bus in the working case.
• The name to be assigned to the new bus.
• The base voltage to be assigned to the new bus.
5-71
Changing Equipment Identifiers Program Operation Manual
If the specified branch is not contained in the working case, or if it is a transformer, an appropriate
error message is printed.
The new bus is then introduced into the working case and assigned to the area, zone, and owner
of the nearer bus. The new bus is given a bus type code of 1 if the branch being tapped is in-service,
or a type code of 4 if the branch is out-of-service. It is made a passive node with no load, generation,
or shunt elements.
The original branch is split into two branches: one from the original from bus to the new bus, and
one from the new bus to the original to bus, both with appropriate fractions of the original branch
impedance and charging. Line connected shunts on the new branches are set such that the line
connected shunts from the original branch remain at the original from and to bus. Circuit identifiers,
ratings, status, metered ends, and ownership follow from the original branch.
If the original branch was a member of a multi-section line grouping, the grouping’s definition is
modified to include the two new branches in place of the original branch.
If the working case contains sequence data (refer to RESQ), zero sequence branch parameters are
handled in the same manner as their positive sequence counterparts. If the original branch is
involved in a zero sequence mutual coupling, the mutual data arrays are modified and extended as
appropriate. All mutual data changes are displayed at the Progress device (refer to Section 4.4,
Virtual Output Devices).
In the example (Figure 5-36), the Progress summary report registers the tapping process and also
indicates that the mutual coupling has been modified to take into account the new topology.
Figure 5-36. Output Summary of Line Tap
®
PSS E GUI Users Guide, Section 7.5, Tapping a Line
PSS®E Command Line Interface (CLI) Users Guide, Section 4.6, Tapping a Line
PSS®E Application Program Interface (API), Section 1.124, LTAP
5.19 Changing Equipment Identifiers

Activity MBID
Change Equipment Identifiers - GUI

Use [Spreadsheet]
Run Line Mode Activity MBID - CLI
5-72
Program Operation Manual Changing Equipment Identifiers
ACTIVITY?
>>MBID
ENTER 0 TO EXIT 1 FOR MACHINE ID's
2 FOR CIRCUIT ID's 3 FOR INTER-AREA TRANSFER ID's
4 FOR LOAD ID's 5 FOR TWO-TERMINAL DC LINE NAMES
6 FOR MULTI-TERM DC LINE NAMES 7 FOR FACTS DEVICE NAMES
8 FOR 3-WINDING TRANSFORMER IDs 9 FOR VSC DC LINE NAMES
10 FOR SHUNT ID's:
>>
None
PSS®E permits the user to change the following types of alphanumeric identifiers associated with
equipment represented in the working case:
• Synchronous machine, induction machine, load, and fixed shunt identifiers.

• Circuit identifiers of non-transformer branches, two-winding transformers, three-
winding transformers, and multi-section line groupings.
• Two-terminal, multi-terminal, and VSC dc line names.
• FACTS device names.
• GNE device names.
• Inter-area transfer identifiers.
The appropriate tool for changing working case equipment identifiers is dependent upon the inter-
face through which PSS®E is being operated.
GUI Users Guide, Chapter 2, Spreadsheet View).
In line mode, the equipment identifier modification activity MBID is the primary tool for making these
data changes to the working case (refer to PSS®E Command Line Interface (CLI) Users Guide,
Section 4.15, Changing Equipment Identifiers).
In Python programs, the MBIDaaa identifier changing API routines described in Chapter 1, Power
Flow Operation of the PSS®E Application Program Interface (API) manual are used to change data
associated with existing elements in the working case.
In Response Files and IPLAN programs, activity MBID and/or the identifier changing API routines
may be used to change equipment identifiers in the working case.
Each non-transformer branch is categorized as either a normal branch, a breaker, or a switch by

the first character of its circuit identifier: an at sign ( @ ) for a breaker, an asterisk (  ) for a switch,
and any other character other than an ampersand ( & ) for a normal branch (refer to Non-Trans-
former Branch Data and Multi-Section Line Grouping Data). Making appropriate changes to its
identifier allows the user to change the characterization of a non-transformer branch from its
present category to a different category. For example, a branch with identifier @1 is characterized
as a breaker; changing its identifier to 1 changes its characterization to a normal branch.
In changing the identifier of a multi-section line grouping, the circuit identifier must have an amper-
sand ( & ) as its first character; refer to Multi-Section Line Grouping Data. Similarly, in changing the
5-73
Moving Equipment Program Operation Manual
circuit identifier of a non-transformer branch, two-winding transformer, or three-winding transformer,

the new identifier may not have an ampersand specified as its first character.
In changing the identifier of an equipment item, if there already exists an item of the same type with
the new identifier, an appropriate message is printed and the user is instructed to provide a different
identifier.
®
PSS E GUI Users Guide, Section 7.6, Changing Equipment Identifiers
Section 4.15, Changing Equipment Identifiers
Section 1.138, MBID2DC
Section 1.139, MBID3WND
Section 1.140, MBIDATRN
Section 1.141, MBIDBRN
Section 1.142, MBIDFACTS
Section 1.143, MBIDGNE
Section 1.148, MBIDMAC
Section 1.149, MBIDMDC
Section 1.150, MBIDMSL
Section 1.151, MBIDSHUNT
Section 1.152, MBIDVSC
5.20 Moving Equipment

Activity MOVE
Run Activity MOVE - GUI

Power Flow > Changing > Move network elements (MOVE)…
[Move Network Elements]
Run Line Mode Activity MOVE - CLI
ACTIVITY?
>>MOVE
EQUIPMENT ITEMS WHICH MAY BE MOVED ARE:
1 = AC LINES 2 = SWITCHED SHUNTS
3 = MACHINES 4 = PLANTS
5 = INDIVIDUAL LOADS 6 = ALL LOADS AT A BUS
7 = THREE-WINDING TRANSFORMERS
8 = INDIVIDUAL FIXED SHUNTS 9 = ALL FIXED SHUNTS AT A BUS
ENTER EQUIPMENT CATEGORY CODE:
>>
None
The equipment transferal activity MOVE allows the user to move specified fixed shunts, switched
shunts, loads, synchronous machines, plants, and induction machines from one bus to another. It
5-74
Program Operation Manual Moving Equipment
also provides for connecting the far end of specified branches and one winding of a three-winding
transformer to different to buses.
5.20.1 Operation of Activity MOVE

Following the selection of the equipment category, the user specifies the equipment to be moved
and the bus to which the equipment is to be transferred. Following each move, a summary of the
action taken is printed at the Progress device.
When rerouting a branch for which the circuit identifier matches that of a branch already existing
between the from bus and the new to bus, the existing branch keeps its original identifier and the
user specifies a new identifier for the rerouted branch. A similar approach is used in the rerouting
of three-winding transformers.
The terms from and to in this network element moving process are not related to the
transformer data attributes that relate to windings and taps. Here the from and to are
used merely to select branches, recognizing that the to end is the end that will be relocated.
For three-winding transformers there are three buses to be selected; the from, to and a third
bus. It is the third bus that can be moved.
In rerouting branches and three-winding transformers, if the new to bus is a dummy bus of a multi-
section line grouping, that line grouping is deleted because the new to bus will have three branches
connected to it following the rerouting.
If the branch being rerouted is a member of a multi-section line grouping and the original to bus is
a dummy bus, the multi-section line grouping is deleted; if the original to bus is an endpoint bus of
the multi-section line grouping, either the grouping is deleted if the new to bus is the other endpoint
bus, or the grouping is redefined.
In rerouting a branch that is involved in zero sequence mutual couplings (refer to Zero Sequence
Mutual Impedance Data), the mutual arrays are updated under the assumption that the rerouted
branch retains the same couplings as the original branch.
In moving switched shunts, if the destination bus does not have a switched shunt and the original
one does, the switched shunt of the original bus is transferred to the destination bus. If both buses
have switched shunts, the switched shunts are merged, with blocks being assigned in the following
order:
1. Reactors from the original bus.
2. Reactors from the destination bus.
3. Capacitors from the destination bus.
4. Capacitors from the original bus.
Control parameters from the destination bus are kept unless the switched shunt at the destination
bus controls the admittance setting of the switched shunt at the original bus. In this case, the control
parameter data items (MODSW, VSWHI, VSWLO, SWREM, RMPCT and RMIDNT) of the original
bus are transferred to the destination bus.
When moving synchronous machines, if the destination bus is not a generator bus, the plant data
of the original bus is copied to the destination bus. If both buses are generator buses, the machine
is transferred to the designated bus and plant totals of both buses are updated. In the case of
conflicting machine identifiers, those machines already at the destination bus keep their original
5-75
Moving Equipment Program Operation Manual
machine identifiers and the user must provide a new identifier for the moved machine. If all
machines at a bus are moved to other buses, its plant entry is removed.
In moving plants, the destination bus must not be a generator bus; all machines at a plant may be
moved to another plant only by moving each individual machine.
In moving machines and plants, bus type codes are updated appropriately. If any moves result in
the plant entry of an area swing being deleted, an appropriate message is printed. If the current
destination bus is in the same area as the former area swing bus, it becomes the new area swing.
Otherwise, the area swing bus number is set to zero (refer to Area Interchange Data and Area Inter-
change Control).
When moving individual loads, if both buses are load buses and a load with the same identifier as
the load being moved is already present at the destination bus, the load previously at the destination
bus keeps its original load identifier and the user must provide a new identifier for the moved load.
If all loads at a bus are moved to other buses, an appropriate message is printed. In moving all loads
at a bus to another bus, the destination bus must not have any other loads; all loads at a bus may
be moved to another load bus only by moving each individual load.
When moving individual fixed bus shunts, if both buses are fixed shunt buses and a fixed shunt with
the same identifier as the shunt being moved is already present at the destination bus, the shunt
previously at the destination bus keeps its original shunt identifier and the user must provide a new
identifier for the moved shunt. If all fixed shunts at a bus are moved to other buses, an appropriate
message is printed. In moving all fixed shunts at a bus to another bus, the destination bus must not
have any other fixed shunts; all fixed shunts at a bus may be moved to another fixed shunt bus only
by moving each individual shunt.
When moving individual induction machines, if both buses are induction machine buses and an
induction machine with the same identifier as the induction machine being moved is already present
at the destination bus, the induction machine previously at the destination bus keeps its original
machine identifier and the user must provide a new identifier for the moved induction machine. If all
induction machines at a bus are moved to other buses, an appropriate message is printed. In
moving all induction machines at a bus to another bus, the destination bus must not have any other
induction machines; all induction machines at a bus may be moved to another induction machine
bus only by moving each individual induction machine.
5-76
Program Operation Manual Renumbering Buses in Auxiliary Files
The example displays the savnw.sav Saved Case File. The 500 kV line from bus 151, which termi-
nates at bus 201 will be moved to terminate at bus 202. A summary of the moving action is printed
at the Progress device (Figure 5-37).
Figure 5-37. Branch Move Output Report

Activity MOVE does not check that the working case is in the form required by the power flow solu-
tion activities. The user is advised to use activities such as TREE (to check for islands and system
swing bus specification) and CNTB and EXAM (to check the control parameters of merged plants
and switched shunts) before attempting to solve the modified case.
PSS®E GUI Users Guide, Section 7.7, Moving Equipment
PSS®E Command Line Interface (CLI) Users Guide, Section 4.7, Moving Equipment
Section 1.155, MOVE3WND
Section 1.156, MOVEBRN
Section 1.158, MOVELOADS
Section 1.159, MOVEMAC
Section 1.160, MOVEPLNT
Section 1.161, MOVESHUNT
Section 1.162, MOVESHUNTS
Section 1.163, MOVESWS
5.21 Renumbering Buses in Auxiliary Files

Activity RNFI
Run Activity RNFI - GUI

File > Renumber buses in auxiliary files (RNFI)…
[Renumber Buses in Auxiliary Files]
Run Line Mode Activity RNFI - CLI
ACTIVITY?
>>RNFI
ENTER BUS TRANSLATION FILE NAME (FROM BSNM):
>>
None
5-77
Renumbering Buses in Auxiliary Files Program Operation Manual
The auxiliary data input file bus renumbering activity RNFI reflects changes in bus numbering in
auxiliary data input files. It is used primarily in conjunction with activity BSNM to coordinate bus
renumbering implemented in a Saved Case with auxiliary data input files associated with the Saved
Case and read by other PSS®E activities.
The RNFI API routine includes the following among its inputs:
• The type of data file to be processed.

• The name of the auxiliary data input file to be processed.
• The name of the output file reflecting the bus renumbering.
• The name of a Bus Renumbering Translation Data File.
5.21.1 Bus Renumbering Translation Data File

During the bus renumbering process, PSS®E provides for the creation of an optional Bus Renum-
bering Translation Data File. This file contains a record of which bus numbers were changed and
what the new bus numbers are. The advantage of directing the output of activity BSNM to a file is
that this file may be specified to activity RNFI for the purpose of implementing these bus number
changes in one or more of the auxiliary data input files associated with the original case. The files
constructed by activity RNFI are then compatible with the renumbered case.
Thus, the usual input to activity RNFI is the output file created by activity BSNM. However, a user-
created data input file containing data records of the following form may also be used as the input
to activity RNFI:
old bus number new bus number
5.21.2 Operation of Activity RNFI

The user specifies the Bus Renumbering Translation File and (optionally) the name of an output file
into which activity RNFI is to place data records containing the new bus numbering scheme.
Although the output data file is optional, it is the primary output of activity RNFI. This file will contain
a copy of the processed auxiliary data file reconstructed with the new numbering. Consequently it
will be immediately available for use with the renumbered case. The alternative is to allow the
reconstructed file to be printed at the Report device for previewing purposes.
The same file may not be specified for both the auxiliary data input file and the output data file.
That is, activity RNFI is not able to replace the input file with a modified version of the file that
reflects the bus renumbering.
Activity RNFI is able to process the following auxiliary data files:
• Sequence Data File (used by activity RESQ)

• Drawing Coordinate Data File (obsolete one-line diagram definition format file that may
be imported into the [Diagram] view)
• Dynamics Data File (used by activity DYRE)
• Machine Impedance Data File (used by activity MCRE)
• Economic Dispatch Data File (used by activity ECDI)
• Inertia and Governor Response Data File (used by activity INLF)
• Breaker Duty Data File (used by activity BKDY)
5-78
Program Operation Manual Renumbering Buses in Auxiliary Files
• Fault Specification Data File (used by activity BKDY)

• Fault Control Data (used by activity ASCC and IECS)
• Machine Capability Curve Data (used by activity GCAP)
• Load Throwover Data File (used by the various ac contingency calculation functions,
the P-V Analysis function, and the Q-V analysis function)
• ANSI Fault Specification Data File (used by activity ANSI)
• Subsystem Description Data File (used by activities DFAX and RANK)
• Monitored Element Data File (used by activities DFAX and RANK)
• Contingency Description Data File (used by activity DFAX)
• Tripping Element Data File (see Section 6.13, Performing Multi-Level AC Contingency
Solution)
In processing Dynamics Data Files, data records for User-Written Models are copied to the desti-
nation file without change.
As with all files used in the course of a PSS®E engineering study, the user is urged to note the rela-
tionship between power flow Saved Cases and their various related data files used as input to, and
generated as output by, activity RNFI. Refer to Section 2.5, Creating Input Files, Section 2.6, Files
Created By PSS®E, and Section 2.8, Deleting Files.
®
PSS E GUI Users Guide, Section 7.17, Renumbering Buses in Auxiliary Data Files
Section 4.21.2, Renumbering Buses in Auxiliary Files
PSS®E Application Program Interface (API), Section 1.273, RNFI
See also:
Section 5.46, Bus Renumbering
5-79
Changing Owner Assignments Program Operation Manual
5.22 Changing Owner Assignments

Activity OWNM
Run Activity OWNM - GUI

Power Flow > Renumbering Areas / Owners / Zones …
[Renumbering Areas / Owners / Zones]
Owner assignments Tab
Run Line Mode Activity OWNM - CLI
ACTIVITY?
>>OWNM
ENTER 1 TO CHANGE OWNERSHIP OF BUSES:
>>
None
The owner renumbering activity OWNM reassigns buses, loads, synchronous machines, induction
machines, branches, FACTS devices, VSC dc lines, and/or GNE devices in the working case from
their original owners to a designated owner. All elements of the selected equipment types in the
working case may be reassigned to a designated owner; more typically, all elements of the selected
equipment types in a specified subsystem of the working case (refer to Section 4.8, Subsystem
Selection) are assigned to a designated owner.
The OWNM_3 API routine includes the following among its inputs:
• A designation of the subsystem in which the owner assignments of selected equipment

types are to be reassigned; refer to Section 4.8, Subsystem Selection.
• Eight flags to indicate whether owner assignments of subsystem buses, loads, syn-
chronous machines, induction machines, branches, FACTS devices, VSC dc lines, and
GNE devices are to be changed.
• A flag indicating which subsystem series elements (i.e., branches, FACTS devices with
a series element, VSC dc lines, and series GNE devices) are to be processed:
- Subsystem branches only (all of its terminals are in the specified subsystem).
- Subsystem ties only (at least one of its terminals is in the specified subsystem, and
at least one is in a neighboring subsystem).
- Both subsystem branches and ties.
• The owner to which subsystem elements are to be assigned.
5.22.1 Operation of Activity OWNM

Following the reassignment process, activity OWNM logs the following occurrences and conditions
at the Progress device (refer to Section 4.4, Virtual Output Devices):
• The destination owner has a blank name and activity OWNM assigns to it the owner
name from an owner that has a non-blank name and that is emptied during the owner
reassignment process.
5-80
Program Operation Manual Changing Owner Assignments
• An owner no longer has any equipment assigned to it.

Then activity OWNM then lists the number of buses, loads, synchronous machines, induction
machines, branches, FACTS devices, VSC dc lines, and/or GNE devices transferred to the desti-
nation owner, and the total number of buses, loads, synchronous machines, induction machines,
branches, dc buses, FACTS devices, VSC dc lines, and GNE devices now assigned to the owner
(see Figure 5-39). If no changes were made, activity OWNM displays:
No owner assignment changes are implemented for the selected subsystem
ALL EQUIPMENT REMOVED FROM OWNER 22 [GEN 2 ]
OWNERSHIP CHANGED FOR:

3 BUSES
3 MACHINES
3 BRANCHES
OWNER 2 [TRAN 2 ] CONTAINS:

BUSES LOADS MACHINES BRANCHES DC BUSES FACTS VSC DC GNE
7 2 5 8 0 0 0 0
Figure 5-38. Example Output Report of Owner Reassignment

To determine if an equipment item is processed in subsystem mode, for any active attribute (e.g.,
area), if the equipment item possesses the attribute (e.g., loads have an area attribute), it is used;
otherwise (e.g., machines do not have an area attribute), the corresponding attribute of the bus is
used.
When reassigning ownership for synchronous machines, branches, and VSC dc lines previously
designated as having multiple owners, each ownership block is assigned to the new owner unless
subsystem specification by owner is enabled. When using subsystem specification by owner, only
those ownership blocks previously assigned to the specified owners are reassigned.
When reassigning ownership for FACTS and GNE devices, devices connected to a single bus are
not candidates for processing when using series element renumbering option 2 (subsystem tie
branches). Series FACTS and GNE devices are processed using the same criteria as ac branches
and VSC dc lines (only subsystem branches, only subsystem ties, or both subsystem branches and
ties).
Activity OWNM does not change the owner assignments of dc buses internal to multi-terminal dc
lines (refer to Multi-Terminal DC Transmission Line Data).
5-81
Areas, Zones and Owners
PSS®E GUI Users Guide, Section 7.14, Changing Owner Assignments

Section 4.18, Changing Owner Assignments
PSS®E Application Program Interface (API), Section 1.191, OWNM_3
5-82
5.23 Changing Owner Assignments

Activity OWNM
Run Activity OWNM - GUI

Owner assignments Tab
Run Line Mode Activity OWNM - CLI
ACTIVITY?
>>OWNM
ENTER 1 TO CHANGE OWNERSHIP OF BUSES:
>>
None
The owner renumbering activity OWNM reassigns buses, loads, synchronous machines, induction
machines, branches, FACTS devices, VSC dc lines, and/or GNE devices in the working case from
their original owners to a designated owner. All elements of the selected equipment types in the
working case may be reassigned to a designated owner; more typically, all elements of the selected
equipment types in a specified subsystem of the working case (refer to Section 4.8, Subsystem
Selection) are assigned to a designated owner.
The OWNM_3 API routine includes the following among its inputs:
• A designation of the subsystem in which the owner assignments of selected equipment

types are to be reassigned; refer to Section 4.8, Subsystem Selection.
• Eight flags to indicate whether owner assignments of subsystem buses, loads, syn-
chronous machines, induction machines, branches, FACTS devices, VSC dc lines, and
GNE devices are to be changed.
• A flag indicating which subsystem series elements (i.e., branches, FACTS devices with
a series element, VSC dc lines, and series GNE devices) are to be processed:
- Subsystem branches only (all of its terminals are in the specified subsystem).
- Subsystem ties only (at least one of its terminals is in the specified subsystem, and
at least one is in a neighboring subsystem).
- Both subsystem branches and ties.
• The owner to which subsystem elements are to be assigned.
5.23.1 Operation of Activity OWNM

Following the reassignment process, activity OWNM logs the following occurrences and conditions
• The destination owner has a blank name and activity OWNM assigns to it the owner
name from an owner that has a non-blank name and that is emptied during the owner
reassignment process.
5-83
• An owner no longer has any equipment assigned to it.

Then activity OWNM then lists the number of buses, loads, synchronous machines, induction
machines, branches, FACTS devices, VSC dc lines, and/or GNE devices transferred to the desti-
nation owner, and the total number of buses, loads, synchronous machines, induction machines,
branches, dc buses, FACTS devices, VSC dc lines, and GNE devices now assigned to the owner
(see Figure 5-39). If no changes were made, activity OWNM displays:
No owner assignment changes are implemented for the selected subsystem
ALL EQUIPMENT REMOVED FROM OWNER 22 [GEN 2 ]
OWNERSHIP CHANGED FOR:

3 BUSES
3 MACHINES
3 BRANCHES
OWNER 2 [TRAN 2 ] CONTAINS:

BUSES LOADS MACHINES BRANCHES DC BUSES FACTS VSC DC GNE
7 2 5 8 0 0 0 0
Figure 5-39. Example Output Report of Owner Reassignment

To determine if an equipment item is processed in subsystem mode, for any active attribute (e.g.,
area), if the equipment item possesses the attribute (e.g., loads have an area attribute), it is used;
otherwise (e.g., machines do not have an area attribute), the corresponding attribute of the bus is
used.
When reassigning ownership for synchronous machines, branches, and VSC dc lines previously
designated as having multiple owners, each ownership block is assigned to the new owner unless
subsystem specification by owner is enabled. When using subsystem specification by owner, only
those ownership blocks previously assigned to the specified owners are reassigned.
When reassigning ownership for FACTS and GNE devices, devices connected to a single bus are
not candidates for processing when using series element renumbering option 2 (subsystem tie
branches). Series FACTS and GNE devices are processed using the same criteria as ac branches
and VSC dc lines (only subsystem branches, only subsystem ties, or both subsystem branches and
ties).
Activity OWNM does not change the owner assignments of dc buses internal to multi-terminal dc
lines (refer to Multi-Terminal DC Transmission Line Data).
5-84
PSS®E GUI Users Guide, Section 7.14, Changing Owner Assignments

Section 4.18, Changing Owner Assignments
PSS®E Application Program Interface (API), Section 1.191, OWNM_3
5-85
Changing Zone Assignments Program Operation Manual
5.24 Changing Zone Assignments

Activity ZONM
Activity LDZO
Run Activity ZONM - GUI

Zone assignments Tab
Run Line Mode Activities ZONM and LDZO - CLI
ACTIVITY?
>>ZONM
>>
ACTIVITY?
>>LDZO
>>
None
The zone renumbering activity ZONM reassigns buses, loads, and/or induction machines in the
working case from their original zones to a designated zone. All buses, loads, and/or induction
machines in the working case may be reassigned to a designated zone; more typically, buses,
loads, and/or induction machines in a specified subsystem of the working case (refer to Section 4.8,
Subsystem Selection) are assigned to a designated zone.
The ZONM_2 API routine includes the following among its inputs:
• A designation of the subsystem in which the zone assignments of buses and/or loads
are to be reassigned; refer to Section 4.8, Subsystem Selection.
• A flag to indicate whether zone assignments of subsystem buses are to be changed.
• A flag to indicate whether zone assignments of subsystem loads are to be changed.
• A flag to indicate whether zone assignments of subsystem induction machines are to
be changed.
• The zone to which subsystem elements are to be assigned.
In the GUI, the ZONM_2 API routine is accessed from the Zone assignments tab of the [Renumbering
Area / Owners / Zones] dialog for modifying the zone assignments of buses, loads and induction
machines.
In line mode, zone assignments of buses are changed using activity ZONM, and zone assignments
of loads are modified using activity LDZO.
5-86
Program Operation Manual Reading Sequence Data Additions from the Terminal
5.24.1 Operation of Activity ZONM

Following the reassignment process, activity ZONM logs the following occurrences and conditions
• The destination zone has a blank name and activity ZONM assigns to it the zone name
from a zone that has a non-blank name and that is emptied during the zone reassign-
ment process.
• A zone no longer has any equipment assigned to it.
Then activity ZONM lists the number of buses, loads and induction machines transferred to the
destination zone, and the total number of buses, induction machines, loads, and dc buses now
assigned to the zone. If no changes were made, activity ZONM displays:
No zone assignment changes are implemented for the selected subsystem

Activity ZONM does not change the zone assignments of dc buses internal to multi-terminal dc lines
(refer to Multi-Terminal DC Transmission Line Data).
PSS®E GUI Users Guide, Section 7.15, Changing Zone Assignments

Section 4.19, Changing Zone Assignments of Buses
PSS®E Application Program Interface (API), Section 1.344, ZONM_2
5.25 Reading Sequence Data Additions from the Terminal

Activity TRSQ
Run Line Mode Activity TRSQ - CLI

ACTIVITY?
>>TRSQ
ENTER POSITIVE SEQUENCE MACHINE IMPEDANCES
I, ID, R, X
>>
AB
Activity TRSQ is special purpose version of activity RESQ available only in line mode. It is designed
for the purpose of adding a limited amount of sequence data to the system contained in the working
case, with data records read from the dialog input device (the terminal keyboard, a Response File,
or an IPLAN program).
5-87
Changing Sequence Data Program Operation Manual
®
Section 3.8, Reading Sequence Data Additions from the Terminal
PSS®E Application Program Interface (API), Section 1.269, RESQ
See also:
Section 5.5.1, Sequence Data File Contents
5.26 Changing Sequence Data

Activity SQCH
Change Sequence Data - GUI

Use [Spreadsheet]
Run Line Mode Activity SQCH - CLI
ACTIVITY?
>>SQCH
ENTER CHANGE CODE:
0 = EXIT ACTIVITY 1 = BUS SHUNT LOADS (ZERO & NEG SEQS)
2 = GENERATOR IMPEDANCES 3 = ZERO SEQ NONTRANSFORMER BRANCH DATA
4 = ZERO SEQ SWITCHED SHUNTS 5 = ZERO SEQ 2 WINDING TRANSFORMER DATA
6 = ZERO SEQ 3 WINDING TRANSFORMER DATA 7 = ZERO SEQ FIXED SHUNTS:
>>

None
The sequence data modification activity SQCH allows the user to make changes to the various
sequence data arrays in the working case. The appropriate tool for changing working case data is
dependent upon the interface through which PSS®E is being operated.
GUI Users Guide, Chapter 2, Spreadsheet View). The [Spreadsheet] may also be used to add new
zero sequence mutual elements to the working case.
In line mode, the sequence data modification activity SQCH is the primary tool for making sequence
data changes to the working case (refer to PSS®E Command Line Interface (CLI) Users Guide,
Section 4.14, Changing Sequence Data).
In Python programs, the data entry/changing API routines described in Chapter 2, Power Flow Data
Changing of the PSS®E Application Program Interface (API) manual are used to change data asso-
ciated with existing elements in the working case (the SEQ_MUTUAL_DATA routine may also be
used to add new zero sequence mutuals to the working case). The name of each of the API routines
associated with sequence data starts with SEQ_.
In Response Files and IPLAN programs, activity SQCH and/or the data entry/changing API routines
may be used to change sequence data in the working case.
Activity SQCH allows access to the following items of data:
5-88
Program Operation Manual Checking Branch Parameters
• Zero and negative sequence load elements. Note that the ground paths corresponding
to fixed shunt elements are not included as part of the zero and negative sequence
shunt elements (refer to Zero Sequence Fixed Shunt Data). In the case of zero
sequence loads, note that the ground ties created by grounded transformer windings
are not included as part of the load elements (refer to Load Sequence Data and Section
5.5.3, Transformers in the Zero Sequence). Note also that care is required in manipu-
lating exceptional (i.e., non-zero) negative and zero sequence shunt loads (refer to
Load Sequence Data). In particular, when changing the positive sequence loading at a
bus (with activity CHNG or the [Spreadsheet]), it is the user’s responsibility to ensure that
any corresponding exceptional negative and zero sequence load is coordinated with it.
• Zero, positive, and negative sequence machine impedances (refer to Generator
Sequence Data).
• Zero sequence data for non-transformer branches (refer to Zero Sequence Non-Trans-
former Branch Data).
• Zero sequence switched shunt step admittances (refer to Zero Sequence Switched
Shunt Data).
• Zero sequence data for transformer branches (refer to Zero Sequence Transformer
Data).
• Zero sequence fixed shunt elements (refer to Zero Sequence Fixed Shunt Data). Note
that the ground ties created by grounded transformer windings are not included as part
of the fixed shunt elements (refer to Load Sequence Data and Section 5.5.3, Trans-
formers in the Zero Sequence).
• Zero sequence mutual impedance data (refer to Zero Sequence Mutual Impedance
Data).
Network topological data (e.g., branch status, bus type codes, etc.), positive sequence
loading data, positive sequence branch data, and positive sequence fixed and switched shunt
data changes are handled with the power flow data changing activity CHNG or the [Spreadsheet].
®
PSS E GUI Users Guide, Section 7.18, Changing Sequence Data
PSS®E Command Line Interface (CLI) Users Guide, Section 4.14, Changing Sequence Data
See also: Section 5.5, Reading Sequence Data
5.27 Checking Branch Parameters

Activity BRCH
Run Activity BRCH - GUI

Power Flow > Check Data > Branch parameters (BRCH)…
[Check Branch Parameters]
Run Line Mode Activity BRCH - CLI
ACTIVITY?
>>BRCH
ENTER OUTPUT DEVICE CODE:
5-89
Checking Branch Parameters Program Operation Manual

AB
The branch parameter checking activity BRCH tabulates those branches where impedances or
other characteristics are such that they may be detrimental to the rate of convergence of one or
more of the power flow solution activities (refer to SOLV, MSLV, FNSL, NSOL, FDNS, INLF, and
ACCC).
The BRCH_2 API routine includes the following among its inputs:
• A designation of the subsystem in which branch parameters are to be checked; refer

to Section 4.8, Subsystem Selection.
• The selection of one or more checks to be performed.
• Threshold or limits values used by several of the checks.
5.27.1 Branch Parameter Checks Available

Table 5-1 Examples of Two Winding Transformer Vector Groups describes the branch parameter
checks that can be enabled in activity BRCH. For those checks that use a limit or threshold value,
the default value is listed.
Table 5-1. Branch Parameter Data Check Options
Default Limit or
Data Check Threshold Value Description
Small Reactance 0.0005 pu Any branch where reactance magnitude is less than
threshold value will be listed. Very small impedance
branches not being treated as zero impedance lines may
result in a slowing of the rate of convergence of the power
flow solution activities, and their inability to reach the
default convergence tolerances.
Large Reactance 1.0 pu Any branch where reactance magnitude exceeds this
value will be listed. Large impedance branches in them-
selves do not cause problems with the power flow solution
methods. However, when relatively small impedance
branches are also connected to these buses, convergence
may be slowed and the solution activities may not be able
to reach the default convergence tolerances. In addition,
very large impedances are often present in inefficient net-
work equivalents with some buses having an unusually
large number of branches connected to them. This will
generally result in the loss of the beneficial sparsity char-
acteristics present with real system when the system
matrices are processed, with a corresponding increase in
solution times.
5-90
Program Operation Manual Checking Branch Parameters
Default Limit or
High Resistance 0.66667 Any branch where resistance magnitude exceeds reac-
to Reactance tance magnitude times the threshold will be listed. The
Ratio decoupled Newton-Raphson power flow solution, activity
NSOL, will diverge if there are any branches where resis-
tance is greater than reactance. The other solution
methods are not particularly sensitive to this ratio. The
default value generates an alarm for branches with a
resistance magnitude greater than 2/3 of reactance
magnitude.
Negative n.a. Branches with a negative reactance are listed. If either of
Reactance the buses for such a branch is a generator bus (i.e., its
type code is 2 or 3), an asterisk ( * ) is printed before the
branch circuit identifier. The Gauss-Seidel power flow
solution, activity SOLV usually diverges if the working case
contains any in-service negative reactance branches. The
modified Gauss-Seidel power flow solution, activity MSLV,
is able to handle negative reactance branches between
Type 1 buses, but negative reactances connected to Type
2 or 3 buses usually result in its divergence.
High Reactance 500.0 Activity BRCH scans each bus and tabulates all lines from
Ratio any bus for which the ratio of largest to smallest branch
reactance magnitude exceeds a specified threshold. In
this check, buses connected by Zero Impedance Lines are
treated as the same bus in determining the largest and
smallest connected reactance; zero impedances are
neglected in determining the smallest reactance. The
presence of a bus with a wide range of reactances con-
nected to it may slow the rate of convergence of the power
flow solution activities and result in failure to reach the
default convergence tolerances.
High or Negative 5.0 pu The line charging entry for each branch is checked and
Charging those branches where line charging is greater than the
threshold or negative are tabulated. High values of line
charging do not necessarily cause problems with the
power flow solution methods except in cases of data entry
errors (for example, all charging values entered in Mvar
rather than per unit resulting in abnormally high voltages).
Negative values of line charging are data errors.
5-91
Checking Branch Parameters Program Operation Manual
Default Limit or
Activity BRCH scans parallel branches between pairs of buses
and generates an alarm for:
• Non-transformer and transformer branches in parallel.

• Parallel two-winding transformers with different Winding 1
complex tap ratios.
Parallel • Parallel two-winding transformers with different Winding 2
n.a.
Transformers tap ratios.
• Parallel two-winding transformers with their Winding
1/Winding 2 side relationship reversed.
As in the reactance ratio check, buses connected by zero imped-
ance lines are treated as the same bus. Transformers listed in
this check have an F or T following the Winding 1 tap ratio to indi-
cate the from bus or to bus as the Winding 1 side bus.
High Tap Ratio 1.1 Any transformer branch for which the tap ratio of any winding is
beyond the specified limit is tabulated. Transformers listed in this
Low Tap Ratio 0.9 check have an F or T following the Winding 1 tap ratio to indicate
the from bus or to bus as the Winding 1 side bus.
Any transformer branch for which its copper loss (load loss) is
less than its no-load loss is listed.
No-load loss is derived from the transformer’s per unit magne-
tizing conductance, the nominal winding 1 voltage base, the base
Transformer Loss voltage of the winding 1 bus, and the system MVA base.
Data n.a. For two-winding transformers, copper loss is derived from the
Inconsistencies transformer’s per unit winding resistance, the three phase
winding 1 to winding 2 base MVA, and the system MVA base.
For three-winding transformers, copper loss is derived from the
three winding-to-winding per-unit resistances, the three winding-
to-winding three phase MVA bases, and the system MVA base.
Missing Zero Non-transformer branches with a zero sequence impedance of
Sequence n.a. (0.0 + j 0.0) are listed. This test is bypassed if sequence data is
Impedance not contained in the working case.
When branches are reported by activity BRCH, this does not necessarily mean that their data is
incorrect. Rather, it indicates the potential for difficulties in obtaining a power flow solution which
converges to the specified tolerances.
5.27.2 Operation of Activity BRCH

The user specifies either that the entire working case is to be processed, or that branch data checks
are to be performed for branches that are connected to at least one bus in the specified subsystem.
When a subsystem is being processed and ownership is the only selection criterion, each branch
wholly or partly owned by any of the owners specified is included in subsequent checks (refer to
Non-Transformer Branch Data and Transformer Data). The owner assignments of the branch’s
endpoint buses are not considered.
5-92
Program Operation Manual Check for Islands Without a Swing Bus
When one or more of the other subsystem selection criteria are enabled, the bus, area, zone, and/or
base voltage selection criteria, if enabled, determine those buses whose connected branches are
candidates for processing; otherwise, all buses are candidate buses. The owner selection criterion,
if enabled, determines which such branches at candidate buses are to be processed; otherwise, all
such branches at candidate buses are processed.
For each of the checks, the report contains the from bus and to bus identifiers and areas, and the
circuit identifier and status of each branch tabulated.
For the parallel transformer and high and low tap ratio checks, the transformer’s per unit impedance
is printed, along with the Winding 1 tap ratio and phase shift angle, and the Winding 2 tap ratio. In
the parallel transformer check, transformer ratings are also tabulated.
For the transformer loss data consistency check, separate tabulations are produced for two-winding
and three-winding transformers. In the two-winding transformer report, copper loss at 1.0 per unit
current and no-load loss at 1.0 per unit voltage are listed in watts, along with the per unit values of
transformer resistance and magnetizing conductance from which they are derived. In the three-
winding transformer report, copper loss at 1.0 per unit current and no-load loss at 1.0 per unit
voltage are listed in watts, along with the per unit values of three bus-to-bus resistances and the
magnetizing conductance from which they are derived; the status shown is the status of the three-
winding transformer (0 through 4).
For each of the remaining checks, the report includes the per unit impedance and, for non-trans-
former branches, line charging. Whenever a branch that is treated as a zero impedance line is
tabulated, it is so noted.
Except in the transformer loss data consistency check, each winding of a three-winding transformer
is checked and reported separately. For each such winding reported, the bus to which the winding
is connected is shown as the from bus, and the to bus identifiers include the transformer name in
the bus name column, the winding number in the base voltage column, and the string 3WNDTR in
the bus number column; the charging and Winding 2 tap ratio fields are left blank. The status shown
is the status of the winding (0 or 1).
Except for the reactance ratio check, which is reported in double entry format, branches are listed
in single entry format (refer to Branch Data) and are listed in ascending numerical (using the
numbers output option) or alphabetical (using the names option) order by from bus, and, for each
from bus, in ascending order by to bus and circuit identifier.
PSS®E GUI Users Guide, Section 12.1, Checking Branch Parameters
Section 5.1, Checking/Changing Branch Parameters
PSS®E Application Program Interface (API), Section 1.43, BRCH
5.28 Check for Islands Without a Swing Bus

Activity TREE
Run Activity TREE - GUI

Power Flow > Check Data > Buses not in swing bus tree (TREE)
5-93
Check for Islands Without a Swing Bus Program Operation Manual
Run Line Mode Activity TREE - CLI

ACTIVITY?
>>TREE
AB
The network continuity checking activity TREE enables the user to identify buses not connected
back to a Type 3 (swing) bus through the in-service ac network. It also tabulates in-service branches
connected to Type 4 (disconnected) buses. Each swingless island may optionally be disconnected.
The TREE API routine includes the following among its inputs:
• A flag indicating the calculation phase to be performed during this call of the TREE API
routine:
- Initialization and check for the presence of a swingless island.
- Process the previously detected island as indicated by another input value; then
check for the presence of another swingless island.
• An option describing the handling of the previously detected swingless island.
5.28.1 Operation of Activity TREE

The report produced by activity TREE first lists any Type 4 bus with one or more in-service branches
connected to it. Such error conditions usually result from manually isolating a bus by changing its
bus type code and the branch status flags to the appropriate values (with activity CHNG or in the
[Spreadsheet] view) but overlooking one or more branches connected to it. This error may be avoided
by using activity DSCN to electrically disconnect a bus.
Activity TREE then tabulates all Type 3 buses in the working case, followed by a listing of buses
that do not have a type code of 4 and are not looped back to a swing bus. These buses are grouped
by island, and, within each island, in ascending bus number (using the numbers output option) or
alphabetical (using the names output option) order. The tabulation of each island is followed by a
summary of the number of buses and plants in the island along with total island load, shunt, gener-
ation, and var limits.
The tabulations of activity TREE are printed at the Progress device (refer to Section 4.4, Virtual
Output Devices).
5-94
Program Operation Manual Checking/Changing Controlled Bus Scheduled Voltage
For each swingless island detected in the working case, user input is required to select one of the
following actions:
• Disconnect this island, then check for another swingless island.

• Leave this island unchanged and check for another swingless island.
• Leave this island unchanged and exit activity TREE.
When activity TREE disconnects an island, it performs the required bus type code and branch
status flag changes to disconnect all buses that were listed as not tied back to a swing bus. Any in-
service dc lines connected to such buses are blocked. Any in-service series FACTS devices and
series GNE devices connected to such buses are placed out-of-service.

Activity OUTS flags buses not connected to other buses by in-service branches and for which the
type code is not 4, but is not able to identify islands; activity TREE tabulates both isolated buses
and islands not containing a swing bus.
Activity TREE always scans the entire working case.
Activity TREE permits itself to be executed after generators have been converted with activity
CONG. In this case, at least one island is always present because there should be no Type 3 buses
following the execution of activity CONG.
®
PSS E GUI Users Guide, Section 12.4, Check for Islands Without a Swing Bus
Section 5.4, Check for Islands Without a Swing Bus
PSS®E Application Program Interface (API), Section 1.326, TREE
5.29 Checking/Changing Controlled Bus Scheduled Voltage

Activity CNTB
Run Activity CNTB - GUI

Power Flow > Check Data > Check / Change controlled bus scheduled voltages (CNTB)…
[Check / Change Controlled Bus Scheduled Voltages]
Run Line Mode Activity CNTB - CLI
ACTIVITY?
>>CNTB
ENTER 0 TO INCLUDE ALL ELEMENTS, 1 FOR IN-SERVICE ELEMENTS ONLY:
>>
AB
5-95
Checking/Changing Controlled Bus Scheduled Voltage Program Operation Manual
The bus scheduled voltage checking activity CNTB tabulates the voltage setpoints and desired
voltage bands of voltage controlling equipment in the working case, and, optionally, allows the user
to specify new scheduled voltages. It also performs certain checks on voltage controlling buses that
are not themselves voltage controlled buses. It may be instructed to process all such buses, or only
those with suspect or conflicting voltage schedules or other errors.
The CNTB API routine includes the following among its inputs:
• A designation of the subsystem in which the voltage controlled buses are to be pro-
• A flag indicating the calculation phase to be performed during this call of the CNTB API
routine:
- Initialization.
- Voltage setpoint change for a voltage controlled bus.
- Voltage band change for a load drop compensating transformer.
• In the initialization phase, the following control flags are specified:
- Process either all voltage controlled and voltage controlling buses in the specified
subsystem, or only those with apparent conflicting voltage objective data or other
errors.
- Report only, or allow scheduled voltage changes.
- Process either all subsystem controlling elements and controlled buses, or only in-
service elements.
• In the voltage setpoint change phase, the following are specified:
- A flag to indicate either no change for this voltage setpoint, or that a change is to
be implemented.
- When a change is to be implemented, the new voltage setpoint value.
• In the voltage band change phase for a load drop compensating transformer, the fol-
lowing are specified:
- A flag to indicate either no change for this transformer, or that a change is to be
implemented.
- When a change is to be implemented, the new voltage setpoint band.
5.29.1 Operation of Activity CNTB

Activity CNTB may be instructed to either include or omit Type 4 controlled buses and out-of-service
or disabled controlling equipment in its checking and reporting.
If only in-service elements are to be processed, any bus that is designated as the controlled bus of
some voltage controlling equipment item, but for which the type code is greater than 3, is excluded
from processing by activity CNTB. In addition, the following voltage controlling equipment items are
ignored by activity CNTB:
• Generation at a bus for which the type code is not 2 or 3.

• A switched shunt at a bus for which the type code is greater than 3 or for which the
switched shunt control mode is not 1 (discrete voltage control) or 2 (continuous voltage
control).
5-96
Program Operation Manual Checking/Changing Controlled Bus Scheduled Voltage
• A voltage controlling transformer that is out-of-service or for which the adjustment con-
trol mode is –1 (i.e., control is disabled).
• The shunt element of a FACTS device for which the control mode is zero.
• The series element of a FACTS device for which the control mode is zero.
• A converter of a VSC dc line for which the VSC dc line control mode (MDC) is zero or
for which the converter dc control code (TYPE) is zero.
Activity CNTB requires that the user select the processing of either all voltage controlled buses and
their controlling equipment in the specified subsystem, or only those with apparent conflicting
voltage objective data or other errors.
Activity CNTB may be operated in either an interactive mode in which new voltage schedules may
be specified, or in a reporting mode.
When voltage schedule changes option is enabled, the user responds to prompts, displayed for one
controlled bus or load drop compensating transformer at a time, to specify new voltage schedules.
In this mode, these reports are directed to the Progress device (refer to Section 4.4, Virtual Output
Devices); in reporting mode, these reports are directed to the Report device.
The user specifies either that the entire working case is to be processed, or that voltage schedules
of voltage controlled buses in a designated bus subsystem are to be reported and, if the option is
enabled, modified (refer to Section 4.8, Subsystem Selection).
5-97
Checking/Changing Controlled Bus Scheduled Voltage Program Operation Manual
For each bus tabulated, if it has a generator, switched shunt, VSC dc line converter, or FACTS
device shunt element (again, either all or only in-service and enabled devices) that is controlling the
voltage at some other bus or the reactive power output of a remote device, an appropriate message
is printed. Then activity CNTB lists equipment for which control parameter data is such that it is
controlling the voltage at the bus being processed. Such equipment includes:
• Generation at the bus itself, if it is not remotely controlling the voltage at some other
bus. The type code of the generator bus is printed in the STATUS column.
• Generation at a remote bus, which is controlling the voltage at this bus. The type code
of the remote generator bus is printed in the STATUS column.
• A switched shunt at the bus itself, if it is not remotely controlling the voltage at some
other bus or the reactive power output of some other voltage controlling device. The
control mode of the switched shunt is printed in the STATUS column.
• A switched shunt at a remote bus, which is controlling the voltage at this bus. The type
code of the bus to which the switched shunt is connected and the control mode of the
switched shunt are printed in the STATUS column.
• A FACTS device connected to the bus. The device’s control mode is printed in the
STATUS column.
• A FACTS device at a remote bus, which is controlling the voltage at this bus. The type
code of the bus to which the sending end bus of the FACTS device is connected and
the device’s control mode are printed in the STATUS column.
• A converter of a VSC dc line connected to the bus itself, if the converter is in ac voltage
control mode and is not remotely controlling the voltage at some other bus. The VSC
dc line’s control mode (MDC) and the converter’s dc control code (TYPE) are printed
in the STATUS column.
• A converter of a VSC dc line connected to a remote bus, if the converter is in ac voltage
control mode and is remotely controlling the voltage at this bus. The type code of the
converter bus, the VSC dc line’s control mode (MDC), and the converter’s dc control
code (TYPE) are printed in the STATUS column.
• A voltage controlling transformer without load drop compensation. For two-winding
transformers, transformer status is printed; for three-winding transformers, winding
status is printed in the STATUS column.
For each such equipment, the desired voltage setpoint or voltage band, as appropriate, is tabulated.
Activity CNTB lists any suspect voltage control specifications.
Then, if the voltage schedule changing option was selected, the user has the option of specifying a
new scheduled voltage. If a new value is entered, the control parameters are modified accordingly.
For those devices controlling to a voltage band, the band retains its previous voltage spread with
the designated voltage as the midpoint. These data changes are then echoed for verification.
Each voltage controlling transformer with load drop compensation (refer to Transformer Data and
Voltage Control) for which the controlled bus is being processed is then listed, along with the
compensated voltage it would sense and its voltage limits. If the voltage schedule changing option
was selected, the user then has the option of specifying a new voltage band for each such
transformer.
5-98
Program Operation Manual Checking/Changing Transformer Adjustment Data

Buses connected together by zero impedance lines (refer to Zero Impedance Lines) are treated as
the same bus. Controlling equipment, along with any error and warning messages, apply to the
combined bus. In interactive mode, each group of buses connected together by zero impedance
lines that has at least one of the buses in the specified subsystem is tabulated once, even if more
than one of its buses is in the specified subsystem. In reporting mode, each such bus is reported in
its usual position in the bus collating sequence.
®
PSS E GUI Users Guide, Section 12.2, Checking/Changing Controlled Bus Scheduled Voltage
Section 5.2, Checking/Changing Controlled Bus Scheduled Voltage
PSS®E Application Program Interface (API), Section 1.57, CNTB
5.30 Checking/Changing Transformer Adjustment Data

Activity TPCH
Run Activity TPCH - GUI

Power Flow > Check Data > Check / Change transformer adjustment data (TPCH)…
[Check / Change Transformer Adjustment Data]
Run Line Mode Activity TPCH - CLI
ACTIVITY?
>>TPCH
>>
AB
The controlling transformer parameter checking activity TPCH performs several checks on the
adjustment data (refer to Transformer Data) associated with voltage and flow controlling
transformers.
The TPCH API routine includes the following among its inputs:
• A flag indicating the calculation phase to be performed during this call of the CNTB API
routine:
- Initialization.
- Perform the selected check of transformer adjustment data.
- Modify adjustment data of transformers failing the current check.
- Exit TPCH.
• In the initialization phase, the following is specified:
5-99
Checking/Changing Transformer Adjustment Data Program Operation Manual
- A designation of the subsystem in which regulating transformers are to be pro-

• In the data checking phase, the following are specified:
- A flag to indicate the type of data check to be performed.
- The threshold value to be used in the specified data check.
• In the adjustment data modification phase, the following are specified:
- For tests which can modify either tap steps or voltage bands, a flag to indicate
which of these are to be modified.
- For tests for which both voltage controlling and Mvar controlling transformers were
tabulated, a flag to indicate which types of transformers are to have their data
modified:
• both types
• only voltage controlling transformers
• only Mvar controlling transformers
- For tests for which both MW controlling and Mvar controlling transformers were
tabulated, a flag to indicate which types of transformers are to have their data
modified:
• both types
• only MW controlling transformers
• only Mvar controlling transformers
- The new tap step, voltage band, or flow band, as appropriate.
5.30.1 Operation of Activity TPCH

The user specifies either that the entire working case is to be processed, or that controlling trans-
former windings connected to buses in a designated bus subsystem are to be checked (refer to
Section 4.8, Subsystem Selection).
When a subsystem is being processed and ownership is the only selection criterion, each voltage
or flow controlling transformer wholly or partly owned by any of the owners specified is included in
subsequent checks (refer to Transformer Data). The owner assignments of the transformer’s
endpoint buses are not considered.
base voltage selection criteria, if enabled, determine those buses whose connected transformer
branches are candidates for processing; otherwise, all buses are candidate buses. The owner
selection criterion, if enabled, determines which controlling transformers whose controlling winding
sides are connected to candidate buses are to be processed; otherwise, all controlling transformers
whose controlling winding sides are connected to candidate buses are processed.
The following types of checks may be performed by activity TPCH:
• Three tests check the tap ratio step increment (derived from the ratio limits and the
number of tap positions) of voltage and Mvar controlling transformers:
- Tap step = 0.0
5-100
Program Operation Manual Checking/Changing Transformer Adjustment Data
- Small tap step (0.0 < tap step < user specified threshold)
- Large tap step (tap step > user specified threshold)
• Three tests check the voltage band of voltage controlling transformers:
- Voltage band narrow relative to the tap step (voltage band < two tap steps)
- Narrow voltage band (voltage band < user specified threshold)
- Wide voltage band (voltage band > user specified threshold)
• Two tests check the flow band of MW and Mvar controlling transformers:
- Narrow flow band (flow band < user specified threshold)
- Wide flow band (flow band > user specified threshold)
For each check performed, an appropriate heading is printed followed by a tabulation of any con-
trolling transformers failing the selected check. If any transformers have failed the check, the user
has the option of modifying the data of all transformers tabulated.
Two-winding transformers are listed in the report with their Winding 1 bus as the from bus and with
their Winding 2 bus as the to bus. Three-winding transformers are listed in the report with their
controlling winding bus as the from bus and with their transformer name and winding number as the
to bus. The table is ordered in ascending numerical (using the numbers output option) or alphabet-
ical (using the names option) order by from bus, and, for each from bus, in ascending order by to
bus and circuit identifier, with two-winding transformers first followed by three-winding transformers.
The number of controlling transformer windings failing the check is also reported.
For the tap ratio step increment tests, if any transformers are found failing the test, the user may
elect to modify the steps, and therefore the number of tap positions, of these transformers. If this
option is enabled and there are both voltage and Mvar controlling transformers listed, the user may
have both types changed, only the voltage controlling transformers changed, or only the Mvar
controlling transformers changed to a specified new tap step. From the specified tap step and the
ratio limits of each such transformer, a new value for the number of tap positions is determined.
The remaining checks of activity TPCH are handled in a similar manner. The check for voltage band
less than two tap steps provides for modification of either the voltage band (widened to two tap
steps) or the number of tap positions (increased such that each tap step is no more than half of the
voltage band) of each voltage controlling transformer tabulated.
The tests of the voltage band of voltage controlling transformers against a user specified threshold
provide for the modification of the voltage band of each listed transformer to a specified new band.
For each transformer that has its voltage band adjusted, its voltage limits are set such that the
midpoint of its band is unchanged.
The test of the flow band of MW or Mvar controlling transformers against a user specified threshold
provide for the modification of the flow band of each listed transformer to a specified new band. If
this option is enabled and there are both MW and Mvar controlling transformers listed, the user may
have both types changed, only the MW controlling transformers changed, or only the Mvar control-
ling transformers changed to a specified new flow band. For each transformer that has its flow band
adjusted, its flow limits are set such that the midpoint of its band is unchanged.
As an example use of this function, assume we need to check the controlling Flow band for all MW
controlling transformers in the savnw.sav Saved Case File. Use a threshold Flow band of 5.0 MW.
The result of this example check shows one power controlling transformer with a Flow band of 10
MW compared to the threshold check of 5.0 MW (see Figure 5-40).
5-101
Changing Adjustment Enable Flags of Transformers Program Operation Manual
Figure 5-40. Results of Example Transformer Flow Band Check

Transformers that control dc line quantities are excluded from the parameter checking of activity
TPCH.
When transformers are reported by activity TPCH, this does not necessarily mean that their
data is incorrect.
PSS®E GUI Users Guide, Section 12.3, Checking/Changing Transformer Adjustment Data
Section 5.3, Checking/Changing Transformer Adjustment Data
PSS®E Application Program Interface (API), Section 1.322, TPCH
5.31 Changing Adjustment Enable Flags of Transformers

Activity TFLG
Run Activity TFLG - GUI

Power Flow > Changing > Transformer adjustment flags (TFLG)...
[Transformer Adjustment Flags]
Run Line Mode Activity TFLG - CLI
ACTIVITY?
>>TFLG
ENTER 0 TO DISABLE, 1 TO ENABLE:
>>
None
The transformer adjustment enable flag setting activity TFLG allows the user to either enable or
disable the adjustment status of all automatically adjustable transformer windings contained in the
subsystem specified by the user.
The TFLG API routine includes the following among its inputs:
• A designation of the subsystem in which the adjustment enable flag of adjustable trans-
former windings is to be modified; refer to Section 4.8, Subsystem Selection.
5-102
Program Operation Manual Performing Unit Commitment and Economic Dispatch
• The setting to be assigned to the adjustment enable flags of subsystem adjustable

transformer windings (refer to Transformer Data).
5.31.1 Operation of Activity TFLG

The user specifies either that the entire working case is to be processed, or that adjustable trans-
formers connecting buses in a designated bus subsystem are to be processed (refer to Section 4.8
Subsystem Selection).
When a subsystem is being processed and ownership is the only selection criterion, each adjust-
able transformer wholly or partly owned by any of the owners specified has its adjustment enable
flag set to the designated value. The owner assignments of the transformer’s endpoint buses are
not considered.
base voltage selection criteria, if enabled, determine those buses whose connected transformer
branches are candidates for processing; otherwise, all buses are candidate buses. The owner
selection criterion, if enabled, determines which controlling transformers connecting candidate
buses are to be processed; otherwise, all controlling transformers connecting candidate buses are
processed.
Note that only transformers connecting subsystem buses are processed by activity TFLG;
transformers that are ties from the specified subsystem are not processed.
Activity TFLG sets the sign of the adjustment control mode of those adjustable transformer windings
being processed to the appropriate value.
Activity TFLG logs the total number of transformers in the working case that had their adjustment
enable flags changed:
ADJUSTMENT CONTROL MODE OF nn TRANSFORMERS CHANGED
This log is printed at the Progress device.
Refer to Transformer Data, Automatic Transformer Adjustments, and Phase Shift Angle Adjustment
for additional details on the transformer adjustment control flag.
®
PSS E GUI Users Guide, Section 7.10, Changing Adjustment Enable Flags of Transformers
Section 4.12, Changing Adjustment Enable Flags of Transformers
PSS®E Application Program Interface (API), Section 1.316, TFLG
5.32 Performing Unit Commitment and Economic Dispatch

Activity ECDI
Run Activity ECDI - GUI

Power Flow > Changing > Economic Dispatch (ECDI)…
[Economic Dispatch]
5-103
Performing Unit Commitment and Economic Dispatch Program Operation Manual
Run Line Mode Activity ECDI - CLI

ACTIVITY?
>>ECDI
ENTER ECONOMIC DISPATCH DATA FILE NAME:
>>
AB abandon activity ECDI following the completion of the next dispatch iteration
NC suppress the dispatch convergence monitor
The unit commitment/economic dispatch activity ECDI places machines in a specified subsystem
in- or out-of-service to satisfy a given subsystem minimum capacity. The in-service machines in the
subsystem are then dispatched on the basis of equal incremental cost to meet a specified total
subsystem generation.
Activity ECDI requires minimum and maximum outputs, incremental heat rates, fuel costs, and start-
up priority rankings for all machines to be scheduled. This data exists in source file form in an
Economic Dispatch Data File (*.ecd) that is read during the execution of activity ECDI.
The ECDI API routine includes the following among its inputs:
• A flag indicating the calculation phase to be performed during this call of the ECDI API
routine:
- Initialization.
- Specify subsystem.
- Unit commitment and economic dispatch calculation.
- Perform housekeeping and exit the ECDI API.
• In the initialization phase, the following is specified:
- The name of the Economic Dispatch Data File to be used.
• In the subsystem specification phase, the following is specified:
- A designation of the subsystem in which the generation is to be dispatched; refer
to Section 4.8, Subsystem Selection.
- An initial commitment flag indicating one of the following:
• Begin the unit commitment calculation from the current commitment profile.
• Determine a new commitment profile (i.e., begin the unit commitment with
all dispatchable units out-of-service).
• Disable the unit commitment (i.e., no machine status changes allowed);
normally used only in P-V analysis calculations.
• In the calculation phase, the following is specified:
- The desired loading of the units being dispatched.
- The desired minimum capacity of the units being dispatched.
5-104
5.32.1 Economic Dispatch Data File Contents

Each machine to be dispatched by activity ECDI must have its dispatch data specified in a data
record in an Economic Dispatch Data File. Activity ECDI recognizes two formats of data records in
this file. The majority of machines are specified on records of the form shown in Standard Record
Format. A special record format is used for the supplementary units that are dispatched as part of
a dispatch group; this format is described in Supplementary Units of Dispatch Groups, and dispatch
groups are described in Section 5.32.4, Dispatch Groups.
Records may be in any order, but the last record in the file must be a record with its first data item
( I ) specified as zero.
Standard Record Format

Each machine to be dispatched by activity ECDI, except for those machines that are the supple-
mentary units of a dispatch group, must have a data record specified for it in the Economic Dispatch
Data File in the following format:
I,ID,PRIOR,FUELCO,PMAX,PMIN,HEMIN,X1,Y1,X2,Y2,X3,Y3,X4,Y4,X5,Y5,X6,Y6
where:
I Bus number; bus I must be present in the working case with one or more machines
connected to it.
ID One- or two-character machine identifier of the machine at bus I for which data is
specified by this record. ID = 1 by default.
PRIOR Priority ranking code (> 0). Machines with a priority ranking of zero do not have their
status changed during the unit commitment portion of activity ECDI. Machines with
lowest positive priority ranking codes are switched in-service first even though
machines with higher priority rankings may be more economical to run. Machines
with highest priority ranking codes are switched out-of-service first even though
machines with lower priority rankings may be more expensive to run. PRIOR = 0 by
default.
FUELCO Fuel cost for the machine in dollars per MBtu. No default is allowed.
PMAX Maximum machine active power output; entered in MW. If this machine is the prin-
cipal unit of a dispatch group, this is the sum of the maximum outputs of all
machines in the dispatch group. If PMAX is not specified, PMAX and PMIN for this
machine are set to the power limits contained in the working case (refer to Gener-
ator Data).
PMIN Minimum machine active power output; entered in MW. If this machine is the prin-
cipal unit of a dispatch group, this is the sum of the minimum outputs of all
machines in the dispatch group. If PMAX is not specified, the value specified for
PMIN is ignored and the one from the working case is used; otherwise, no default is
allowed.
HEMIN Minimum heat input required by the machine when in-service; entered in MBtu/hr. If
X1 (see below) is greater than zero, HEMIN should be specified as the heat input
required at X1 MW. No default is allowed.
5-105
Xi,Yi Points on the incremental heat rate curve; Xi values are entered in MW and Yi
values are entered in Btu/kWh. At least two points, and up to six points, may be
entered. Both X and Y must be in ascending order, with X1 < PMIN and
Xn > PMAX. If this machine is the principal unit of a dispatch group, this curve is the
combined curve of all machines in the dispatch group.
The auxiliary program PLINC may be used to plot the incremental heat rate curves of specified
machines. Refer to Additional Resources for PSS®E, PLINC for details on its use.
The PSS®E EXAMPLE directory contains an Economic Dispatch Data File, savnw.ecd, which can
be used in conjunction with the savnw.sav Saved Case File. A plot of those incremental heat rate
curves is shown in Figure 5-41.
Figure 5-41. Incremental Heat Rate Curves Provided in the PSS®E savnw.sav Case
Supplementary Units of Dispatch Groups

A special record format is recognized on which a supplementary unit of a dispatch group is speci-
fied. This record has the following format:
I,ID,PRIOR,FRACT,PRNBUS,PRNMAC,CODFRC
where:
I Bus number; bus I must be present in the working case with one or more machines
connected to it.
ID One- or two-character machine identifier of the machine at bus I for which data is
specified by this record. ID = 1 by default.
PRIOR Priority ranking code (< 0). A negative priority ranking code signifies that this
machine is a supplementary unit of a dispatch group. No default is allowed.
5-106
FRACT When CODFRC is 0 or negative, the fraction of the total power dispatched for the
dispatch group to be assigned to the principal unit. When CODFRC is positive, the
fraction of the total power dispatched for the dispatch group to be assigned to this
supplementary unit. FRACT must be greater than 0.0 and less than 1.0. No default
is allowed.
PRNBUS Bus number of the principal machine associated with the dispatch group of which
this supplementary unit is a member. No default is allowed.
PRNMAC One- or two-character machine identifier of the principal machine at bus PRNBUS
associated with the dispatch group of which this supplementary unit is a member.
PRNMAC = 1 by default.
CODFRC Defines the interpretation of FRACT on this record by activity ECDI. When
CODFRC is 0 or negative, FRACT is the fraction of the total power dispatched for
the dispatch group to be assigned to the principal unit. When CODFRC is positive,
FRACT is the fraction of the total power dispatched for the dispatch group to be
assigned to this supplementary unit. CODFRC = 0 by default.
A standard economic dispatch data record (refer to Standard Record Format) must be included in
the Economic Dispatch Data File for machine PRNMAC at bus PRNBUS. Its power output limits and
incremental heat rate curve must be that corresponding to the combination of all machines in the
dispatch group.
5.32.2 Operation of Activity ECDI

If the specified Economic Dispatch Data File does not exist or some other file system error occurs,
an appropriate error message is printed. Refer to Section 2.4.1, File Usage for the file specification
conventions used by activity ECDI.
If any data inconsistencies are detected during the processing of the Economic Dispatch Data File,
they are logged at the Progress device and the corresponding record is ignored. Activity ECDI
performs its unit commitment and dispatch calculations using only the valid data records.
The user specifies either that the entire working case is to be processed, or that machines in a
designated bus subsystem are to be scheduled and dispatched (refer to Section 4.8, Subsystem
Selection).
When a subsystem is being processed and ownership is included among the selection criteria, the
owners to which machines (rather than buses) are assigned are used in defining the subsystem of
machines to be processed. If a machine has multiple owners (refer to Generator Data), the owner
specified in the owner/fraction pair with the largest ownership fraction is assumed to have dispatch
responsibility. If this largest ownership fraction is identical for two or more owners of a machine, the
first one in the tables, as shown in the machine data listings, in the [Spreadsheet] View, and in activ-
ities such as LIST and EXAM, is used.
If the option for a new commitment profile is specified, all machines in the specified subsystem with
a non-zero priority ranking for which dispatch data had been read are placed out-of-service prior to
commencing the unit commitment calculation. If starting from the current commitment profile, the
current unit status profile is used as the starting point. If the unit commitment calculation is disabled,
all positive priority rankings are set to zero.
Activity ECDI processes only those machines in the specified subsystem for which valid dispatch
data had been read. Other machines retain their initial status and power outputs. Activity ECDI
summarizes the pre-dispatch condition by tabulating the following:
5-107
• the pre-dispatch production cost/hour.

• the minimum generation, maximum generation, and present total generation of in-ser-
vice units that are to be included in the dispatch.
• the present generation of subsystem being dispatched; this includes active power gen-
eration subsystem machines that are to be omitted from the dispatch calculation.
Figure 5-42 shows the result obtained using the savnw.sav Saved Case File and savnw.ecd
Economic Dispatch Data File.
Figure 5-42. Summary of the Predispatch Condition
The first four quantities in the above summary are totals based upon the present power outputs and
dispatch data specified in the Economic Dispatch Data File for those machines initially in-service in
the subsystem to be processed. The final total is the sum of the present power outputs of:
• those machines to be included in the dispatch calculation; and

• those machines in the specified subsystem for which no dispatch data was provided
(the outputs of these machines will not be changed by activity ECDI).
The values specified for the desired loading and minimum capacity of the units to be dispatched
should be entered as values applying to the machines to be dispatched. Specifically, they must not
include the power outputs assigned to those machines in the specified subsystem for which
dispatch data was not read; the outputs of such machines are not changed by activity ECDI.
Activity ECDI then commences the unit commitment portion of its calculation. Note again that the
status of any machine with a priority ranking of zero is not changed during the unit commitment
portion of activity ECDI, but such machines are included in the economic dispatch calculation.
Neither the status nor power outputs of machines for which either no dispatch data was provided or
for which a data error message was generated, and of machines outside of the specified
subsystem, is changed during the execution of activity ECDI.
If the specified desired minimum capacity is greater than the sum of the maximum power outputs
of the machines currently in-service, activity ECDI places additional units in-service. Machines with
lowest priority rankings are connected first, and, within a given priority ranking, units with the lowest
full load average cost per MW are placed in-service first.
If the specified desired loading is less than the sum of the minimum power outputs of the machines
currently in-service, activity ECDI places units out-of-service. Machines with highest priority rank-
ings are disconnected first, and, within a given priority ranking, units with the highest full load
average cost per MW are placed out-of-service first.
Any time activity ECDI changes a machine status, a message is printed at the Progress device.
Any processing errors in the unit commitment portion of activity ECDI generate a message at the
Alert device; different values of desired loading and minimum capacity must be specified.
5-108
After a commitment profile satisfying the desired loading and capacity constraints has been
successfully determined, activity ECDI calculates the power outputs of the machines to be
dispatched. Power outputs are set on the basis of equal incremental costs subject to the machine
power output limits.
The dispatch calculation uses an iterative approach and, at the end of each iteration, activity ECDI
prints a convergence monitor, which tabulates:
• The iteration number.

• The total power mismatch.
• The incremental cost.
• The change in incremental cost.
Following the dispatch calculation, activity ECDI tabulates the production cost and the incremental
cost along with the post-dispatch totals of dispatched power, capacity limits of the dispatched
machines, and subsystem generation; the format is identical to the pre-dispatch tabulation (see
Figure 5-42). Plant power outputs and reactive power limits are updated to reflect the commitment
and dispatch calculation results. Results are summarized at the Progress device.
The example in Figure 5-43 uses the savnw.sav Saved Case FIle, with the desired loading specified
as 4000. The convergence monitor and results summary are shown.
Figure 5-43. Summary Results of the Economic Dispatch Process
5-109
5.32.3 Viewing Economic Dispatch Results

Following completion of the dispatch calculation, plant power outputs and reactive power limits are
updated to reflect the commitment and dispatch calculation results.
One method of examining the results is to use activity GEOL (refer to Section 11.23, Producing a
Machine Terminal Limits Report) to look at machine terminal conditions. In Figure 5-44 those condi-
tions can be seen for the savnw.sav Saved Case File before and after the economic dispatch
calculation example described here.
Figure 5-44. Before and After Machine Terminal Conditions for Economic Dispatch Example
Another method for observing the changes resulting from the execution of activity ECDI is to use
activity DIFF (refer to Section 11.27, Comparing Power Flow Cases). Compare generator active
powers in the working case with those in the Saved Case File which contains the pre-dispatch
Saved Case.
5.32.4 Dispatch Groups

A dispatch group provides a means of handling a group of machines that are to be treated as a
single entity in the unit commitment and economic dispatch calculations. A combined cycle plant,
in which multiple steam units and combustion turbines are to be dispatched as one unit, may be
handled as a dispatch group in activity ECDI. The high pressure, low pressure pair of a cross
compound unit may also be treated as a dispatch group.
To specify a dispatch group, any one (and only one) of the machines in the dispatch group must be
designated on a standard Economic Dispatch Data File record (refer to Standard Record Format);
this machine is referred to as the principal unit of the dispatch group. The dispatch data specified
on this data record must be that for the combination of all machines that are members of the
5-110
dispatch group. Each of the remaining units in the dispatch group must be specified on a supple-
mentary Economic Dispatch Data File record (refer to Supplementary Units of Dispatch Groups);
these machines are referred to as the supplementary units of the dispatch group.
The sum of the FRACT values on all of the supplementary data records of a dispatch group must
be less than one. When a dispatch group contains more than two machines, the data record for
each of its supplementary machines must have CODFRC specified as a positive number, and
FRACT as the fraction of total group power assigned to the supplementary machine. When a
dispatch group contains exactly two machines, CODFRC for the supplementary machine may be
specified as a positive or negative number or zero, and FRACT must be specified accordingly (refer
to Figure 5-45).
Figure 5-45. Assignments for Supplementary Machine Economic Dispatch
The initial service status of each machine in a dispatch group, as determined by the combination of
the type code of the bus to which it is connected and its machine status flag, must be the same:
either all in-service or all out-of-service (refer to Section 5.9.1 Equipment Status Changes). If the
status of a dispatch group is switched during the unit commitment calculation, the status of each
machine in the dispatch group is changed.
At the completion of the dispatch calculation, each dispatch group’s total power output is split
among the machines in the group according to the split fractions FRACT specified on the data
5-111
Displaying the Long Case Title Program Operation Manual
records of the supplementary machines in the group (refer to Supplementary Units of Dispatch
Groups).
Recall that, when no value of PMAX is specified in the Economic Dispatch Data File, the machine
limits contained in the working case are used as the dispatch limits (refer to Standard Record
Format). For a dispatch group, the sums of the limits of all machines in the group are used as the
dispatch limits. In this case, it is possible to violate the individual machine limits as contained in the
working case if FRACT is not coordinated with the individual machine limits.
When a subsystem of the working case is being processed by activity ECDI, the subsystem assign-
ment of the principal unit of a dispatch group is taken as the subsystem assignment of the group. If
the principal unit is in the subsystem being processed, its dispatch group is processed even if one
or more of its supplementary units is not in the subsystem. Conversely, if the principal unit is not in
the subsystem being processed, the dispatch group is not processed even if some or all of its
supplementary units are in the subsystem.

If the value specified for the desired minimum capacity is less than the value specified for the
desired loading, it is assumed to be equal to the specified loading by the unit commitment
calculation.
In specifying the desired loading and minimum capacity, the quantity (minimum capacity - loading)
may be thought of as spinning reserve.
The iterative dispatch calculation in activity ECDI uses a binary search technique with an upper limit
of 40 iterations. Convergence is assumed when the difference between dispatched power and
desired power is less than 0.00001 times the desired power. Convergence failure, which is usually
the result of precision limitations, generates an alarm and activity ECDI continues as if convergence
had been achieved.
The dispatch data as read from the Economic Dispatch Data File is not retained in the working
case following termination of activity ECDI. An Economic Dispatch Data File is required for
each execution of activity ECDI.
PSS®E GUI Users Guide, Section 7.12, Performing Unit Commitment and Economic Dispatch
Section 4.13, Running Unit Commitment and Economic Dispatch
PSS®E Application Program Interface (API), Section 1.74, ECDI
5.33 Displaying the Long Case Title

Activity PRTI
Run Line Mode Activity PRTI - CLI

ACTIVITY?
>>PRTI
5-112
Program Operation Manual Managing Case Titles

AB
The long title output activity PRTI prints the 16-line long title at the Report device and requires no
additional inputs.
Activity PRTI is available only in line mode.
Lines of the long title for which no text has been specified appear as blank lines in the output of
activity PRTI.
®
Section 6.2.4, Long Case Title
Section 1.205, PRTI
5.34 Managing Case Titles

During the initial input of data into PSS®E for a new network model, via either a Power Flow Raw
Data File (see Case Identification Data) or the NEWCAS_2 API routine (see Section 1.178,
NEWCASE_2 of the PSS®E Application Program Interface (API) manual), two 60 character case
title lines are specified. These lines are printed whenever the Saved Case containing this system
model is brought into the working case; they are also included in the reports produced by the various
reporting activities of PSS®E.
In addition, the PSS®E working case provides for a long title containing up to 16 lines of alphanu-
meric data, each of which may contain up to 72 characters. The user may employ the long title to
enter more detailed case descriptive information than the two 60 character case title lines can
accommodate. During the initial input of data into PSS®E for a new network model, the long title
lines are initialized to blanks.
PSS®E includes functions for reading the long title, for modifying the both the case title and the long
title, and for printing the long title.
Both the two line case title and the long title are carried along with the working case as it is saved
and retrieved with activities SAVE and CASE, respectively.
5-113
Managing Case Titles Program Operation Manual
5.34.1 Importing a Long Title

Activity RETI
Run Activity RETI - GUI

File > Import > Long Title (RETI)…
[Select file containing long case title]
Run Line Mode Activity RETI - CLI
ACTIVITY?
>>RETI
None
The long title data input activity RETI reads a data file containing up to 16 lines of alphanumeric data
and places them into the long title. The previous content of the long title is overwritten.
The RETI API routine requires as input the name of a data file containing the lines to be placed into
the long title.
Records read for activity RETI are placed into the long title array in the exact format in which they
are entered. If any input record contains more than 72 characters, those beyond column 72 are
ignored. If a record contains fewer than 72 characters, the corresponding title line is blank filled.
Activity RETI accepts data records until either 16 records have been entered or a data record is
entered containing the characters /E in columns one and two. In this case, the remaining lines of
the long title are blank filled and activity RETI ends.
If the data file contains more than 16 lines, only the first 16 are recognized. If the data file contains
fewer than 16 lines and the last line does not contain the characters /E or /e in columns one and
two, the following message is displayed at the Progress device:
OUT OF FILE DATA--SWITCH TO TERMINAL INPUT MODE
Then those title lines for which no data was read are blank filled and activity RETI ends.
®
PSS E GUI Users Guide, Section 6.9.1, Importing a Long Title
PSS®E Command Line Interface (CLI) Users Guide, Section 3.10.1, Importing a Long Title
PSS®E Application Program Interface (API), Section 1.271, RETI
5-114
Program Operation Manual Managing Case Titles
5.34.2 Changing the Long Title

Activity CHTI
Run Activity CHTI - GUI

File > Case titles, short & long (CHTI)…
[Case Titles]
Run Line Mode Activity CHTI - CLI
ACTIVITY?
>>CHTI
ENTER LINE NUMBER (CARRIAGE RETURN FOR LINE 1, 0 TO EXIT):
>>
None
The long title data change activity CHTI enables the user to modify the contents of individual lines
of the 16-line long title without having to reread the entire set of lines with activity RETI.
Line mode activity CHTI is similar to activity CHNG, involving a prompt and response conversational
dialog.
The LongTitleData API routine is the functional equivalent of activity CHTI.
Both interfaces provide the following capabilities:
• Editing the text of one or more title lines while leaving the others unchanged.
• Entering the entire long title manually without prior preparation of a Long Title File.
• Adding additional long title lines if only the first few title lines had previously been
specified.
®
PSS E GUI Users Guide, Section 6.9.2, Changing the Case Title and the Long Title
Section 3.10.2, Changing the Long Title
PSS®E Application Program Interface (API), Section 2.27, LONG_TITLE_DATA
5-115
Counting System Components in the Working Case Program Operation Manual
5.34.3 Editing the Two-Line Case Title or the Long Title

Activity EDTR
Run Line Mode Activity EDTR - CLI

ACTIVITY?
>>EDTR
EDITOR OPTIONS ARE:

None
Activity EDTR is a title editing tool available only in line mode. It provides for changing part of a title
line without having to enter the entire line.
®
Section 3.10.3, Editing the Two-Line Case Title or the Long Title
5.35 Counting System Components in the Working Case

Activity SIZE
Run Activity SIZE - GUI

File > File Information (SIZE/SHOW/BUSN)…
[File Information]
OPTION: List the number of system components
Run Line Mode Activity SIZE - CLI
ACTIVITY?
>>SIZE
None
The case size summary activity SIZE tabulates the number of components in the working case,
along with the maximum number permitted at the current size level of PSS®E working memory.
The SIZE API routine prints its summary at the Report device (refer to Section 4.4, Virtual Output
Devices), and requires no additional inputs.
5-116
Program Operation Manual Counting System Components in the Working Case
The following network elements are included in the report of activity SIZE:
• Buses, including generator buses and star • Two-winding transformers (both those that
point buses of three-winding transformers. were entered as two-winding transformers and
• Plants. those that are members of three-winding
transformers).
• Synchronous machines, including wind
machines. • Three-winding transformers.
• Wind machines. • Branches treated as zero impedance lines.
• Machine ownership specifications. • Branch ownership specifications.
• Fixed shunts. • Multi-section line groupings.
• Switched shunts. • Branches designated as line sections in multi-

section line groupings.
• Loads.
• Zero sequence mutual couplings.
• Induction machines.
• Two-terminal dc transmission lines.
• Areas.
• Multi-terminal dc transmission lines.
• Interarea transfers.
• Voltage source converter (VSC) dc lines.
• Owners zones.s
• FACTS devices.
• AC branches, including two-winding
transformers (both those that were entered as • GNE devices.
two-winding transformers and those that are
members of three-winding transformers) and
zero impedance lines.
An example of the output of activity SIZE is shown in Figure 5-46.
5-117
Counting System Components in the Working Case Program Operation Manual
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS®E FRI, APR 08 2011 9:40

PSS(R)E PROGRAM APPLICATION GUIDE EXAMPLE
BASE CASE INCLUDING SEQUENCE DATA
BUSES PLANTS MACHINES WIND MACHINES MACHINE OWNERS

TOTAL 23 6 6 0 14
MAXIMUM 1000 300 360 20 720
S H U N T S INDUCTION
FIXED SWITCHED LOADS MACHINES
TOTAL 5 0 8 0
MAXIMUM 1000 126 2000 20
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS®E FRI, APR 08 2011 9:40

BUSES PLANTS MACHINES WIND MACHINES MACHINE OWNERS

TOTAL 23 6 6 0 14
MAXIMUM 1000 300 360 20 720
S H U N T S INDUCTION
FIXED SWITCHED LOADS MACHINES
TOTAL 5 0 8 0
MAXIMUM 1000 126 2000 20
T R A N S F O R M E R S
BRANCHES TWO-WINDING THREE-WINDING ZERO IMPEDANCE BRANCH OWNERS
MUTUALS
TOTAL 34 11 0 0 35 6
MAXIMUM 2500 400 100 500 5000 500
MULTI-SECTION LINE
GROUPINGS SECTIONS AREAS ZONES OWNERS
TRANSFERS
TOTAL 2 4 3 4 7 4
MAXIMUM 100 250 100 999 999 300
2-TERM. DC N-TERM. DC VSC DC FACTS DEVICES GNE DEVICES

TOTAL 0 0 0 0 0
MAXIMUM 20 5 10 20 10
2-TERM. DC N-TERM. DC VSC DC FACTS DEVICES GNE DEVICES

TOTAL 0 0 0 0 0
MAXIMUM 20 5 10 20 10
Figure 5-46. Example Output of Activity SIZE
®
PSS E GUI Users Guide, Section 8.2.1, System Components
Section 6.2.1, System Components
5-118
Program Operation Manual Listing Unused Bus Numbers
5.36 Listing Unused Bus Numbers

Activity BUSN
Run Activity BUSN - GUI

File > File information (SIZE/SHOW/BUSN)…
[File Information]
OPTION: List unused bus numbers in a range
Run Line Mode Activity BUSN - CLI
ACTIVITY?
>>BUSN
>>
AB
The unused bus number summary activity BUSN tabulates those numbers, from within a user spec-
ified bus number range, which are not assigned to buses in the working case.
The inputs to the BUSN API routine define the desired bus number range (starting and ending bus
numbers).
Activity BUSN lists those numbers in the designated range that are not assigned to a bus in the
working case. It lists single numbers and ranges of numbers (e.g., 1208 THROUGH 1219), as
appropriate. It then reports the number of numbers used and the number of numbers available from
within the designated range. The report of activity BUSN is directed to the Report device.
An example of the output of activity BUSN using the default range is shown in Figure 5-47. The
default range is the complete set of valid bus numbers available in PSS®E.
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSSE TUE, FEB 03 2009 11:49

UNUSED BUS NUMBERS BETWEEN 1 AND 999997
1 THROUGH 100
103 THROUGH 150
155 THROUGH 200
207 THROUGH 210
212 THROUGH 3000
3009 THROUGH 3010
3012 THROUGH 3017
3019 THROUGH 999997
23 NUMBERS USED AND 999974 NUMBERS AVAILABLE BETWEEN 1 AND 999997
Figure 5-47. Example Output of Activity BUSN
5-119
Listing Unused Bus Numbers Program Operation Manual
®
PSS E GUI Users Guide, Section 8.2.3, Unused Bus Numbers
Section 6.2.3, Unused Bus Numbers
5-120
Program Operation Manual Displaying Power Flow Data
5.37 Displaying Power Flow Data

Activity LIST
Run Activity LIST - GUI

Power Flow > List Data…
[List Data]
OPTION: Powerflow
Run Line Mode Activity LIST - CLI
ACTIVITY?
>>LIST
AB
The data listing activity LIST tabulates the power flow working case in a form suitable for problem
data documentation. The report generated by activity LIST is separated into several categories of
data.
The LIST API routine includes the following among its inputs:
• A designation of the power flow data category to be tabulated.
• A designation of the units to be used to display ac voltages:
- The units (per unit or kV) indicated by the voltage output program option setting
(see Saved Case Specific Option Settings).
- The alternate units.
5.37.1 Operation of Activity LIST

The user specifies either that the entire working case is to be processed, or that data items for
equipment in a designated bus subsystem are to be tabulated.
If output for a bus subsystem is being produced, only equipment in the designated subsystem is
included in the report except for the following data categories: the case summary; area data; inter-
area transfer data; owner data; and zone data. Any subsystem filtering applied to a data category
is described in the data category descriptions given in Section 5.37.2, Listing Format.
Ac voltages are normally tabulated in the units indicated by the voltage output program option
setting (either per unit or kV). An input of the LIST API routine provides for the tabulation of ac volt-
ages using the other units. If voltages are to be listed in kV but the base voltage at the bus has not
been specified, its voltage is listed in per unit.
The report of activity LIST is directed to the Report device.
5-121
Displaying Power Flow Data Program Operation Manual
The following data categories are available in activity LIST:
• case summary • induction machine miscellaneous data

• all data (single entry branch) • load data
• all data (double entry branch) • multi-section line grouping data
• area interchange data • owner data
• bus data • plant data
• branch data (single entry)* • switched shunt data
• branch data (double entry)† • synchronous machine data
• dc line data • 2-winding transformer impedance data
• FACTS device sending end data • 2-winding transformer winding data
• FACTS device terminal end data • 2-winding transformer control data
• fixed shunt data • 3-winding transformer impedance data
• GNE device data • 3-winding transformer winding data
• impedance correction data • 3-winding transformer control data
• inter-area transfer data • 3-winding transformer general data
• line shunt data • zone data
• induction machine circuit data
* Each branch appears once in the listing: with the lower ordered bus (number or name)
listed as the from bus.
† Each branch is listed in both directions.
If all data categories are to be tabulated, branch-related sections may be in either single or double
entry format (refer to Branch Data). This format selection applies to the following data categories:
non-transformer branch data; line shunt data; the three categories of two-winding transformer data;
and multi-section line grouping data.
5.37.2 Listing Format

Most of the data items tabulated by activity LIST correspond to data entered in activities READ,
TREA, RDCH, CHNG, and the [Spreadsheet]. Refer to Section 5.2.1 Power Flow Raw Data File
Contents for detailed descriptions of these quantities.
The following paragraphs describe those data items printed that do not correspond to data previ-
ously described. Unless otherwise stated, data in the various categories are tabulated in ascending
bus number order when the numbers output option is in effect and in alphabetical order when the
names output option is in effect.
Case Summary
The case summary consists of three pages. The first page tabulates various system totals and solu-
tion parameters. The BUSES summary items are interpreted as follows:
TOTAL Total number of buses in the case, including star point buses of three-winding
transformers.
PQ<>0. Total number of Type 1 buses with non-zero load.
PQ=0. Total number of Type 1 buses with no load, including star point buses of in-service
three-winding transformers.
5-122
PE/E Total number of Type 2 buses that are not at a reactive power limit.
PE/Q Total number of Type 2 buses that are at a reactive power limit (each of these
buses has its type code set to -2 by the power flow solution activities).
SWING Total number of Type 3 buses.
OTHER Total number of buses having other type codes, including star point buses of out-of-
service three-winding transformers; these are usually Type 4 (i.e., disconnected)
buses and/or those buses identified as boundary buses by activities READ and
EXTR.
The BRANCHES summary tabulates ac branches. Its data items are interpreted as follows:
TOTAL Total number of ac branches in the case; includes two-winding transformers (both
those that were specified as two-winding transformers and those that are members
of three-winding transformers), branches treated as zero impedance lines, and
branches that are members of multi-section line groupings.
RXB Total number of non-transformer branches with charging (i.e., transmission lines);
excludes zero impedance lines.
RX Total number of non-transformer branches with no charging (e.g., series capacitors,
equivalent branches); excludes zero impedance lines.
RXT Total number of two-winding transformer branches; includes those at nominal ratio
and those that are members of three-winding transformers.
RX=0. Total number of branches treated as zero impedance lines.
IN Total number of in-service branches.
OUT Total number of out-of-service branches.
The number of multi-section line groupings and the number of ac branches that are members of
multi-section line groupings are tabulated separately. The total numbers of three-winding trans-
formers, dc transmission lines, FACTS devices, and GNE devices are tabulated separately. Totals
by service status of three-winding transformers, multi-section line groupings, dc lines, FACTS
devices, and GNE devices are not tabulated. The number of loads, plants, synchronous machines,
wind machines, fixed shunts, switched shunts, induction generators, and induction motors is
reported, as are the number of areas, zones, and owners that have been defined, and the number
of inter-area transactions.
System totals of generation, load, and so on are tabulated. The quantity shown as SHUNTS is the
sum of fixed bus shunts, switched shunts, line connected shunts, magnetizing admittance of trans-
formers, and the shunt elements of FACTS devices. Losses are the sum of I2R and I2X losses for
in-service ac branches plus dc line and FACTS device losses, and do not include charging and line
shunt contributions or contributions from GNE devices. The loss and swing bus power totals are
meaningful only if the working case represents a solved system condition. The highest and lowest
pu bus voltages are listed along with the largest individual bus and total system mismatch. Up to
twelve swing buses are tabulated in ascending bus number order; if more than twelve Type 3 buses
exist in the case, only twelve of these are listed.
The second page of the case summary tabulates those buses in the working case with the largest
mismatches. At least one, and up to 25, buses are listed, but not more than the number that can fit
on one page. The list is terminated at a largest mismatch of 0.005 MVA.
5-123
The third page of the case summary lists rating set information. The column labeled "# NON-ZERO
RATINGS" lists the number of ac branches for which the value in the corresponding rating set is
non-zero.
The case summary always applies to the complete system, even if activity LIST is reporting
for a bus subsystem.
5-124
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS(R)E TUE, DEC 10 2013 10:57
PSS(R)E PROGRAM APPLICATION GUIDE EXAMPLE SYSTEM SUMMARY
---------------------BUSES---------------------- -----GENERATION----- ----SHUNTS----- -IND MACHS- FACTS GNE

TOTAL PQ<>0. PQ=0. PE/E PE/Q SWING OTHER LOADS PLANTS MACHNS WIND FIXED SWITCHED GENS MOTORS DEVS DEVS
PSS®E 34.2
23 7 10 3 2 1 0 8 6 6 0 5 0 0 0 0 0
------------------AC BRANCHES------------------- 3WIND MULTI-SECTION ---DC LINES-- AREA X----- SWING BUSES -----X
TOTAL RXB RX RXT RX=0. IN OUT XFORM LINES SECTNS 2TRM MTRM VSC AREAS ZONES OWNRS TRANS 3011 MINE_G 13.800
34 22 1 11 0 34 0 0 2 4 0 0 0 3 4 7 4
----GENERATION---- INDUCTION GNE
TOTAL SYNCHR INDUCTN MOTORS PQLOAD I LOAD Y LOAD SHUNTS DEVICES CHARGING LOSSES SWING
MW 3258.7 0.0 0.0 3200.0 0.0 0.0 0.0 0.0 0.0 58.7 258.7
MVAR 964.2 0.0 0.0 1950.0 0.0 0.0 -291.5 0.0 1810.1 1115.7 104.0
TOTAL MISMATCH = 0.00 MVA X------- AT BUS --------X THRSHZ PQBRAK BLOWUP SBASE MXTPSS
MAX. MISMATCH = 0.00 MVA 201 HYDRO 500.00 0.000100 0.700 5.00 100.00 99
HIGH VOLTAGE = 1.04043 PU 211 HYDRO_G 20.000 ADJTHR ACCTAP TAPLIM SWVBND MXSWIM
LOW VOLTAGE = 0.93892 PU 154 DOWNTN 230.00 0.0050 1.0000 0.0500 100.0 10
X------ SOLV AND MSLV ------X X----------------- NEWTON ------------------X X----- TYSL -----X
ACCP ACCQ ACCM TOL ITER ACCN TOLN VCTOLQ VCTOLV ITER DVLIM NDVFCT ACCTY TOL ITER
1.600 1.600 1.000 0.00010 100 1.00 0.1000 0.1000 0.000010 20 0.9900 0.9900 1.000 0.000010 20
-------------------------------------------------------------------------------

PSS(R)E PROGRAM APPLICATION GUIDE EXAMPLE WORST
5-125
BASE CASE INCLUDING SEQUENCE DATA MISMATCHES
BUS# X-- NAME --X BASKV MW MVAR MVA
201 HYDRO 500.00 0.00 0.00 0.00
-------------------------------------------------------------------------------

PSS(R)E PROGRAM APPLICATION GUIDE EXAMPLE RATING SET
BASE CASE INCLUDING SEQUENCE DATA UTILIZATION
RATING SET -NAME- X---------DESCRIPTION----------X # NON-ZERO RATINGS
1 RATE1 RATING SET 1 24
Figure 5-48 shows the case summary for the savnw.sav Saved Case File.

Figure 5-48. Case Summary for the savnw.sav Saved Case File
Displaying Power Flow Data
Power Flow Data Entry, Modification, and Display Activities
Bus Data
A bus type code of -2 indicates a Type 2 bus for which generation is at a reactive power limit. This
is set by the various power flow solution activities.
The number of loads independently modeled at the bus is tabulated in the column labeled LOADS.
Similarly, the number of fixed and switched shunts modeled at the bus is tabulated in the columns
labeled FIXED and SWITCHED, respectively.
When reporting for a bus subsystem, the bus data tabulation is restricted to subsystem buses.
Load Data
Data for loads is tabulated in the load data category. Loads are listed in ascending bus order
(numeric or alphabetic), and loads at each bus are in ascending load identifier order.
Loads tabulated are at nominal values (i.e., at 1.0 pu voltage). The nominal constant MVA load
component tabulated is not adjusted by any load multiplier associated with an Optimal Power Flow
adjustable bus load table; the load multiplier is tabulated in the column labeled PSI. Constant admit-
tance loads do not include any shunt elements modeled at the bus (refer to Fixed Bus Shunt Data
and Switched Shunt Data).
The column labeled SCALE reflects the setting of the load scaling flag, and the column labeled
INTRPT reflects the setting of the interruptible load flag (refer to Load Data).
When reporting for a bus subsystem, the bus and/or base voltage selection criteria, if enabled,
determine those buses whose connected loads are candidates for reporting; otherwise, all buses
are candidate buses. The area, owner, and/or zone selection criterion, if enabled, determine which
loads at candidate buses are to be reported; otherwise, all loads at candidate buses are reported.
Plant Data
Buses that have plant data associated with them (refer to Plant and Machine Sequence Numbers)
are tabulated in the plant data listing. This tabulation includes plants that are out-of-service (i.e., with
a type code of 1 or 4). The number of machines independently modeled at the plant is tabulated in
the column labeled MCNS.
Any plant that regulates the voltage at a remote bus has the remote bus listed at the right-hand side
of the report. Any plant regulating its own terminal voltage has no entry in the REMOTE BUS field.
When reporting for a bus subsystem, the plant data tabulation is restricted to subsystem buses.
Generator Unit Data

Data for conventional (synchronous) machines is tabulated in the generator unit data category.
Machines are listed in ascending bus order (numeric or alphabetic), and machines in each plant are
in ascending machine identifier order.
For each machine, the bus type code, machine identifier and machine status flag are listed in the
columns labelled CD, ID, and ST, respectively. Recall that the actual status of a machine is deter-
mined both by its status flag and the bus type code (refer to Section 5.9.1, Equipment Status
Changes). For machines that are not designated as wind machines, the columns labelled WMOD
and WPF are blank.
5-126
When reporting for a bus subsystem, the bus, area, zone, and/or base voltage selection criteria, if
enabled, determine those buses whose connected machines are candidates for reporting; other-
wise, all buses are candidate buses. The owner selection criteria, if enabled, determines which
machines at candidate buses are to be reported; otherwise, all machines at candidate buses are
reported.
Induction Machine Data

Data for induction machines is tabulated in the induction machine circuit data listing and in the
induction machine miscellaneous data listing. Machines are listed in ascending bus order (numeric
or alphabetic), and machines at the same bus are in ascending machine identifier order. In both of
these listings, the machine identifier and machine status flag are listed in the columns labelled ID
and ST, respectively.
In the induction machine circuit data listings, when the machine design code is zero, CUSTOM is
printed in the column labelled DESIGN, and the remaining data in the listing corresponds to the
circuit and saturation data specified by the user. When one of the NEMA or IEC designs had been
specified (a machine design code of one through 5 was specified), the design description (e.g.,
"NEMA B") is printed in the DESIGN column, and the circuit and saturation data values listed corre-
spond to the pre-programmed values for that machine design.
In the induction machine miscellaneous data listings, an M (for mechanical) or E (for electrical) indi-
cates the machine base power code and is printed following the machine base power. Similarly, an
M or E follows the power setpoint and indicates the scheduled power code. In addition to the induc-
tion machine input data (refer to Induction Machine Data), solution results are listed. These include
the complex power flowing into the machine from the network, and the machine slip.
determine those buses whose connected induction machines are candidates for reporting; other-
wise, all buses are candidate buses. The area, owner, and/or zone selection criterion, if enabled,
determine which induction machines at candidate buses are to be reported; otherwise, all induction
machines at candidate buses are reported.

Data for fixed bus shunts is tabulated in the fixed shunt data category. Shunts are listed in ascending
bus order (numeric or alphabetic), and shunts at each bus are in ascending shunt identifier order.
Shunt data tabulated are at nominal values (i.e., at 1.0 pu voltage), and do not include any constant
admittance load modeled at the bus (refer to Load Data).
When reporting for a bus subsystem, the fixed bus shunt data tabulation is restricted to subsystem
buses.
Switched Shunt Data

Data for switched shunts is tabulated in the switched shunt data category. The value listed as
SHUNT is the admittance presently switched on at the bus.
Any switched shunt that regulates the voltage at a remote bus or the reactive power output of
another voltage controlling device has the controlled bus listed in the REMOTE BUS columns at the
right-hand side of the report; those regulating the reactive power output of a VSC dc line converter
or of the shunt element of a FACTS device also have the device name listed. Switched shunts regu-
lating their own terminal voltage have no entry in these fields.
5-127
When reporting for a bus subsystem, the switched shunt data tabulation is restricted to subsystem
buses.
Branch Data
Data for non-transformer ac branches is tabulated in the branch data category. Branches are
ordered in ascending numerical or alphabetical order by from bus, and, for each from bus, in
ascending order by to bus. Parallel circuits between any pair of buses are tabulated in ascending
circuit identifier order.
The branch data listing may be in either single or double entry format. In single entry format, each
branch that is tabulated appears once in the listing: with the lower ordered bus (number or name)
listed as the from bus. In double entry format, each branch is listed in both directions.
An asterisk (  ) follows the number, name and base voltage of the bus designated as the metered
end.
The column labeled ZI contains a Z if the branch is treated as a zero impedance line; for other
branches, the ZI column is blank. The column labeled ST is the status flag of the branch, with 0
indicating out-of-service, and 1 indicating in-service. Columns for rating sets that are unused (i.e.,
all elements of the rating set are 0.0) are omitted from the report. The remaining data items in this
report category correspond to data items specified in branch data input records (refer to Non-Trans-
former Branch Data).
enabled, determine those buses whose connected branches are candidates for reporting; other-
branches at candidate buses are to be reported; otherwise, all non-transformer branches at candi-
date buses, including branches to non-candidate buses (i.e., ties), are reported.
Line Shunt Data

Data for line connected shunts on non-transformer ac branches is tabulated in the line shunt data
category. This report tabulates branches with a non-zero line connected shunt at either end;
branches with line shunt values of (0.0 + j 0.0) at both ends are omitted from the report.
The line shunt tabulation is ordered in the same manner as is branch data report (refer to Branch
Data). Branches are tabulated in single entry format as in the branch data category except when
full listing (double entry branch) is specified.
Branch status is tabulated in the column labeled ST.
date buses with a non-zero line shunt at either end, including branches to non-candidate buses (i.e.,
ties), are reported.
Two-Winding Transformer Data

Data for two-winding transformers is tabulated in the two-winding transformer impedance data
listing, in the two-winding transformer winding data listing, and in the two-winding transformer
control data listing. The majority of data items in these report categories correspond to data items
specified in the two-winding transformer data input block (refer to Transformer Data).
5-128
The two-winding transformer tabulations are ordered in the same manner as is branch data report
(refer to Branch Data). Transformer branches are tabulated in single entry format as in the branch
data category except when full listing (double entry branch) is specified.
In the transformer impedance and control data listings, the column labeled W1 contains an F if the
bus listed as the from bus is the bus to which Winding 1 of the transformer is connected, or a T if
the to bus is the bus to which Winding 1 is connected.
In the transformer impedance data listing, the column labeled ST is the status flag of the trans-
former, with 0 indicating out-of-service, and 1 indicating in-service. The column labeled MT contains
an F if the bus listed as the from bus is the metered end, or a T if the to bus is the metered end. For
any transformer with an impedance correction table assigned to it, both specified (i.e., nominal) and
corrected (i.e., as modified by application of the transformer impedance correction table) imped-
ances are tabulated.
In the winding data listing, columns for rating sets that are unused (i.e., all elements of the rating
set are 0.0) are omitted from the report.
In the transformer control data listing, the controlled bus number is preceded by a minus sign if it is
on the Winding 1 side of the transformer.
enabled, determine those buses whose connected two-winding transformers are candidates for
reporting; otherwise, all buses are candidate buses. The owner selection criteria, if enabled, deter-
mines which transformers at candidate buses are to be reported; otherwise, all two-winding
transformer branches at candidate buses, including transformers to non-candidate buses (i.e., ties),
are reported.
Three-Winding Transformer Data

Data for three-winding transformers is tabulated in the three-winding transformer general data
listing, in the three-winding transformer impedance data listing, in the three-winding transformer
winding data listing, and in the three-winding transformer tap and control data listing. The majority
of data items in these report categories correspond to data items specified in the three-winding
transformer data input block (refer to Transformer Data).
The three-winding transformer tabulations are ordered in ascending numerical or alphabetical order
by Winding 1 bus, and, for each Winding 1 bus, in ascending order by Winding 2 bus, and for each
Winding 1, Winding 2 bus combination, in ascending order by Winding 3 bus. Transformers
connecting the same three buses are tabulated in ascending circuit identifier order. Single entry
format is always used.
In the general and impedance data listings, the column labeled ST is the status flag of the three-
winding transformer, with values of 0 through 4 as defined in Transformer Data.
The winding data and the tap and control data listings are comprised of three lines of data for each
three-winding transformer: one for each of the two-winding transformers in the star model used to
model a three-winding transformer.
In the impedance data listing, measured impedances are listed in the units indicated by CZ. For any
transformer with an impedance correction table assigned to one or more of its windings, both spec-
ified (i.e., nominal) and corrected (i.e., as modified by application of the transformer impedance
correction table) measured impedances are tabulated.
5-129
In the winding data listing, the winding bus identifiers of the two metered windings are followed by
an asterisk (  ). The column labeled ST is the status flag of the two-winding transformer, as derived
from the status flag of the three-winding transformer, with 0 indicating out-of-service, and 1 indi-
cating in-service. The winding impedances are derived from the values entered as measured
impedances, and are listed in per unit on system MVA base and winding voltage base. For any
winding with an impedance correction table assigned to it, both nominal (i.e., as derived from the
measured impedances) and corrected (i.e., as modified by application of the transformer imped-
ance correction table) impedances are tabulated. Columns for rating sets that are unused (i.e., all
elements of the rating set are 0.0) are omitted from the report.
In the control data listing, the controlled bus number is preceded by a minus sign if it is on the same
side of the transformer as the bus connected to the controlling winding.
enabled, determine those buses whose connected three-winding transformers are candidates for
mines which transformers at candidate buses are to be reported; otherwise, all three-winding
are reported.
Transformer Impedance Correction Table Data

Each transformer impedance correction table in the working case is tabulated in ascending table
number order. Each table is followed by a listing of those transformers assigned to the table, their
winding off-nominal turns ratio or phase shift angle as appropriate, and their winding actual and
nominal impedances. Transformers are listed in single entry format except when full listing (double
entry branch) is specified.
enabled, determine those buses whose connected transformers are candidates for reporting; other-
transformers at candidate buses are to be reported; otherwise, all transformers at candidate buses
that are assigned to the table, including transformers to non-candidate buses (i.e., ties), are
reported.
Multi-Section Line Grouping Data

Data for multi-section line groupings, along with the ac branches that are their members, is tabu-
lated in the multi-section line grouping data listing. The multi-section line groupings are tabulated in
single entry format as in the branch data category (refer to Branch Data) except when full listing
(double entry branch) is specified.
An asterisk (  ) follows the identifiers of the bus designated as the metered end.
The branches comprising each grouping are listed in series order starting at the bus listed as the
from bus.
enabled, determine those endpoint buses whose connected multi-section lines are candidates for
reporting; otherwise, all buses are candidate buses. The owner selection criteria, if enabled, is
applied to each member of the multi-section lines at candidate buses and determines which multi-
section lines are to be reported; otherwise, all multi-section lines at candidate buses, including
those to non-candidate endpoint buses (i.e., ties), are reported.
5-130
DC Line Data
Data for dc lines is tabulated in the dc line data listing. The dc line listing has two-terminal lines in
dc line name alphabetical order listed first, followed by multi-terminal lines in dc line name alpha-
betical order, followed by VSC dc lines in dc line name alphabetical order.
In addition to the dc line input data (refer to Two-Terminal DC Transmission Line Data, Voltage
Source Converter (VSC) DC Transmission Line Data and Multi-Terminal DC Transmission Line
Data), solution results are listed. For each converter of a two-terminal or multi-terminal line, the
alpha or gamma angle is printed along with the apparent ac system complex load and the tap
setting.
For each two-terminal line, the dc line current (DCAMPS) and the compounded dc line voltage
(VCOMP) are printed on the first line of the output block, and the dc voltage at each end of the line
is printed with the converter data. The Winding 1 tap ratio (RATIO) of an ac transformer that is
controlling a dc line quantity is shown following the ac transformer identifiers in the output block of
the appropriate dc line.
For each multi-terminal line, the voltage at each dc bus and the current on the dc side of each
converter transformer is printed. For each dc link in the line, the metered end dc bus is listed in the
column labeled MET.
For each VSC dc line, the dc line current (DCAMPS) is printed. For each converter, the apparent
ac system complex generation, the ac current in amps (ACAMPS), and the voltage on the dc side
of the converter are listed.
When reporting for a bus subsystem, the dc line data tabulation is restricted to those dc lines that
are connected to at least one subsystem bus.
Area Data
Data for areas that are defined is listed in the area data listing. The tabulation is in ascending area
number order.
If an area has an area slack bus designated for it, its number, name, base voltage, and active power
output are tabulated in the listing. This is followed by the plant active power limits, which are taken
as the sums of these limits for the in-service machines at the plant. If the total power output is
outside of these limits, an asterisk (  ) is printed following the generator power.
For each area that is listed, the tabulation includes the number of buses, loads, induction machines,
and dc buses assigned to the area.
The final line tabulates the summation of the listed desired interchanges.
When reporting for a bus subsystem for which area is one of the subsystem selection criteria, the
area tabulation is restricted to those areas specified.
Interarea Transfer Data

Data defining transfers between pairs of areas are listed in the interarea transfer data listing. Inter-
area transfers are ordered in ascending order by from area number, and, for each from area, in
ascending order by to area number. Multiple transfers between any pair of areas are tabulated in
ascending interarea transfer identifier order. Interarea transfers are listed in double entry format,
with each interarea transfer listed in both directions.
5-131
For each from area block, the line reporting the last transfer includes the algebraic sum of all trans-
fers involving the from area, as well as the area’s desired net interchange (refer to Area Interchange
Data and Area Data).
When reporting for a bus subsystem for which area is one of the subsystem selection criteria, the
interarea transfer tabulation is restricted to the from area blocks of those areas specified.
Zone Data
Data for zones that are defined is listed in the zone data listing. The tabulation is in ascending zone
number order.
For each zone that is listed, the tabulation includes the zone name along with the number of buses,
loads, induction machines, and dc buses assigned to the zone.
When reporting for a bus subsystem for which zone is one of the subsystem selection criteria, the
zone tabulation is restricted to those zones specified.
Owner Data
Data for owners that are defined is listed in the owner data listing. The tabulation is in ascending
owner number order.
For each owner that is listed, the tabulation includes the owner name along with the number of
buses, loads, synchronous machines, induction machines, branches, dc buses, FACTS devices,
VSC dc lines, and GNE devices assigned to the owner.
When reporting for a bus subsystem for which owner is one of the subsystem selection criteria, the
owner tabulation is restricted to those owners specified.
FACTS Device Data

Data for FACTS devices is tabulated in the FACTS device sending end data listing and in the
FACTS device terminal end data listing. FACTS devices are ordered in ascending FACTS device
name alphabetical order.
enabled, determine those buses whose connected FACTS devices are candidates for reporting;
otherwise, all buses are candidate buses. The owner selection criteria, if enabled, determines which
FACTS devices at candidate buses are to be reported; otherwise, all FACTS devices at candidate
buses, including those with a series element connected to a non-candidate bus (i.e., ties), are
reported.
GNE Device Data

Data for GNE devices is tabulated in the GNE device data listing. GNE devices are ordered in
ascending GNE device name alphabetical order.
enabled, determine those buses whose connected GNE devices are candidates for reporting;
otherwise, all buses are candidate buses. The owner selection criteria, if enabled, determines which
GNE devices at candidate buses are to be reported; otherwise, all GNE devices at candidate buses,
including those with a series element connected to a non-candidate bus (i.e., ties), are reported.
5-132
Program Operation Manual Listing Components of a Bus
PSS®E GUI Users Guide, Section 8.1, Working Case Data Reporting

Section 6.1, Working Case Data Reporting
Section 1.119, LIST
5.38 Listing Components of a Bus

Activity EXAM
Run Activity EXAM - GUI

[List Data]
OPTION: Examine Powerflow / sequence data
Run Line Mode Activity EXAM - CLI
ACTIVITY?
>>EXAM
>>
AB
The data examination activity EXAM produces a tabulation of power flow data organized by bus.
For each bus tabulated, its bus data is followed by the data associated with each network element
that is connected to the bus.
The EXAM API routine includes the following among its inputs:
5.38.1 Operation of Activity EXAM

The report of activity EXAM is directed to the Report device.

The blocks of output for buses are ordered as described in Section 4.9, Subsystem Reporting. The
data for each equipment category is tabulated in a format similar to that of activity LIST (refer to
Section 5.37.2 Listing Format).
5-133
Listing Buses in Alphabetical Order Program Operation Manual
In the non-transformer branch data tabulation, the column labeled MET contains an F if the bus
being reported is the metered end or a T if the bus listed as the to bus is the metered end. Any
branch treated as a zero impedance line has a Z printed in the column labeled ZI. The column
labeled ST is the branch status. Transformers are omitted from the branch data tabulation.
Two-winding transformer data is printed in three blocks. The column labeled W1 contains an F if the
bus being reported is the bus to which Winding 1 of the transformer is connected, or a T if the bus
listed as the to bus is the Winding 1 bus. The column labeled MT contains an F if the bus being
reported is the metered end, or a T if the bus listed as the to bus is the metered end. The column
labeled ST is the transformer status. Transformer impedances, admittances, and winding data are
printed in the units specified by CZ, CM, and CW, respectively. The column labeled CN is the trans-
former’s automatic adjustment control mode.
Three-winding transformer data is printed in four blocks. The column labeled ST in the first and
second blocks is the three-winding transformer status (0 through 4; refer to Non-Transformer
Branch Data). The column labeled ST in the third block shows the status of the three two-winding
transformers comprising the three-winding transformer. The two winding buses in the third block
where identifiers are followed by an asterisk (  ) are the two metered end buses, and the other bus
is the non-metered bus. Except for winding impedances, which are derived from the measured
impedances and are tabulated in per unit on system MVA base and winding voltage base, trans-
former impedances, admittances, and winding data are printed in the units specified by CZ, CM,
and CW, respectively. The column labeled CN is the transformer’s automatic adjustment control
mode.
The adjustable branch reactance device data tabulation includes the to bus and circuit identifier, the
branch reactance multiplier magnitude, the nominal branch reactance, and the device status.
®
PSS E GUI Users Guide, Section 8.1.3, Listing Buses and their Connected Equipment
Section 6.1.4, Listing Components of a Bus
Section 1.78, EXAM
5.39 Listing Buses in Alphabetical Order

Activity ALPH
Run Activity ALPH - GUI

[List Data]
OPTION: Bus names
Run Line Mode Activity ALPH - CLI
ACTIVITY?
>>ALPH
5-134
Program Operation Manual Listing Buses using Partial Bus Name

AB
The bus alphabetic listing activity ALPH prints an alphabetically sorted table of all buses in a spec-
ified subsystem of the working case.
The ALPH API routine includes the following among its inputs:
The user specifies either that the entire working case is to be processed, or that buses in a desig-
nated bus subsystem are to be tabulated.
The report of activity ALPH is directed to the Report device.
The report of activity ALPH lists the extended bus names and bus numbers of subsystem buses.
Buses are listed in alphabetical order by extended bus name, and are grouped as described in
Section 4.9, Subsystem Reporting.
®
PSS E GUI Users Guide, Section 8.1.2, Listing Buses in Alphabetical Order
Section 6.1.2, Listing Buses in Alphabetical Order
Section 1.26, ALPH
5.40 Listing Buses using Partial Bus Name

Activity FIND
Run Line Mode Activity FIND - CLI

ACTIVITY?
>>FIND
ENTER DESIRED BUS NAME:
AB
The bus name to number translation activity FIND enables the user to determine the number of a
bus with a specified extended bus name. In addition, through the use of a string matching character,
activity FIND produces a listing of possible matching names even if the exact spelling of the bus
name and/or its base voltage is not known.
The FIND API routine includes the following among its inputs:
• The bus name component of the extended bus name.

• The base voltage component of the extended bus name.
5-135
Listing Buses using Partial Bus Name Program Operation Manual
The bus name input string consists of up to twelve alphanumeric characters, plus embedded aster-
isks (  ), which are interpreted as wildcard string matching characters. Each  represents any
number of characters, including zero, which may be embedded between other substrings specified
in name, and up to seven of them may be included between other alphanumeric characters.
Any buses for which the name and base voltage contain the specified substrings are listed at the
Report device in ascending bus number or name order, according to the bus output option currently
in effect (refer to Saved Case Specific Option Settings and activity OPTN).
The following examples illustrate the response of activity FIND to various input values, with the first
column indicating the input for the bus name component, and the second the input for the base
voltage component:
AB All buses of any base voltage whose name begins with "AB".
AB 230 All 230-kV buses whose name begins with "AB".
AB 115 All 115-kV buses whose name contains the string "AB" anywhere in its twelve-
character name. Thus the listing produced would include 115-kV buses
"ABCD" and "XYZABC", but not "AXB" or "XAYB".
ABC All buses of any base voltage whose name begins with "A" and in addition con-
tains the string "BC". Thus the listing produced would include the buses
"ABCXYZ" and "AXYZBC", but not the buses "XABC", "BCA", or "ABXC".
13.8 All 13.8-kV buses.
13 All buses with a base voltage equal to or greater than 13-kV and less than
14-kV.
13.0 All buses with a base voltage of 13.0-kV.
0 All buses for which a base voltage was not specified.
 All buses.
Exit activity FIND.
Activity FIND is not available from the GUI drop-down menus. Rather, the bus filtering capability of
the bus subsystem selector and the Find function of the [Spreadsheet] provide equivalent capability.
PSS®E GUI Users Guide:
Section 2.3.3, Using the Subsystem Menu
Section 2.2.1, Menu Options
Section 6.1.3, Listing Buses Matching a Partial Extended Bus Name
Section 1.84, FIND
5-136
Program Operation Manual Listing Bus Shunts
5.41 Listing Bus Shunts

Activity SHNT
Run Activity SHNT - GUI

[List Data]
OPTION: Bus shunts
Run Line Mode Activity SHNT - CLI
ACTIVITY?
>>SHNT
AB
The bus shunt summary activity SHNT tabulates fixed and/or switched bus shunts contained in the
working case.
The SHNT API routine includes the following among its inputs:
• A designation of the types of bus shunts to be reported:
- All bus shunts
- Only fixed shunts
- Only switched shunts
The user specifies either that the entire working case is to be processed, or that shunts connected
to buses in a designated bus subsystem are to be tabulated.
The report of activity SHNT is directed to the Report device.
In the report of activity SHNT, buses are ordered as described in Section 4.9, Subsystem Reporting.
When multiple shunts are present at a bus, fixed shunts at the bus are listed first in ascending shunt
identifier order, followed by the switched shunt if one is present.
For each shunt tabulated by activity SHNT, the bus number, name, base voltage, and bus type code
are printed, along with the shunt’s service status and the nominal values (i.e., at one per unit
voltage) of the shunt’s admittance. The present bus voltage magnitude is printed along with an iden-
tifier indicating whether the shunt is a fixed or switched shunt. For fixed bus shunts, the shunt
identifier is also printed. For switched shunts, the switched shunt control mode and switched shunt
adjustment method are printed along with the minimum (i.e., all reactors switched on) and maximum
(i.e., all capacitors switched on) susceptance values of the switched shunt. If a switched shunt
reactor block is out of sequence (i.e., a reactor block is detected after the first capacitor block), the
calculated maximum value is followed by an asterisk (  ).
5-137
Listing Outaged Equipment Program Operation Manual
®
PSS E GUI Users Guide, Section 8.1.7, Listing Bus Shunts
Section 6.1.8, Listing Bus Shunts
Section 1.296, SHNT
See also:
Switched Shunt Data
5.42 Listing Outaged Equipment

Activity OUTS
Run Activity OUTS - GUI

[List Data]
OPTION: Outaged equipment
Run Line Mode Activity OUTS - CLI
ACTIVITY?
>>OUTS
AB
The outaged equipment reporting activity OUTS tabulates those components in the working case
that are removed from service.
The OUTS API routine includes the following among its inputs:
The user specifies either that the entire working case is to be processed, or that outaged equipment
in a designated bus subsystem is to be tabulated.
The report of activity OUTS is directed to the Report device.
The following outaged equipment is listed by activity OUTS:
• Out-of-service non-transformer branches and two-winding transformers

• Out-of-service three-winding transformers
• Disconnected and isolated buses
• Out-of-service plants
• Out-of-service synchronous machines at in-service plants
5-138
Program Operation Manual Listing Outaged Equipment
• Out-of-service induction machines at in-service buses.

• Out-of-service loads at in-service buses
• Out-of-service fixed shunts at in-service buses
• Blocked dc transmission lines
• Out-of-service converters at in-service VSC dc lines
• Out-of-service FACTS devices.
• Out-of-service GNE devices.
When a subsystem is being processed and ownership is included among the selection criteria,
branch, synchronous machine, load, FACTS device, VSC dc line, and GNE device ownership rather
than bus ownership is used in determining which branches, machines, induction machines, loads,
FACTS devices, VSC dc lines, and GNE devices are contained in the specified subsystem; any
other selection criteria apply to the buses to which the equipment item is connected.
Out-of-service branches are listed in single entry format (refer to Branch Data) and are ordered in
ascending numerical (using the numbers output option) or alphabetical (using the names option)
order by from bus, and, for each from bus, in ascending order by to bus and circuit identifier. When
the multi-section line reporting option is enabled (refer to Section 3.3.3 Program Run-Time Option
Settings and activity OPTN), out-of-service multi-section line groupings (from bus, to bus, identifier)
rather than their individual line sections are listed in the category of out-of-service ac branches.
Out-of-service three-winding transformers are listed in alphabetical order by transformer name. If

only one winding of a three-winding transformer is out-of-service (i.e., the status value of the three-
winding transformer is 2 through 4; refer to Transformer Data), the out-of-service winding is noted
at the end of the output line.
The classification of isolated buses includes both those buses for which the type code is 4, and
those that are not connected to any other bus by an in-service ac branch but where the type code
is not 4. Any bus included in the latter group is designated by an asterisk (  ) following its bus iden-
tifiers, and, unless it is a Type 3 bus connected to a dc line, results in an improperly specified
network, which usually causes the power flow solution activities to fail to converge. When the multi-
section line reporting option is enabled, Type 4 buses that are dummy buses of a multi-section line
grouping (refer to Multi-Section Line Grouping Data) are omitted from the isolated bus report.
The category of disconnected plants includes those buses that have plant data assigned to them
but for which their bus type code is 1 or 4.
Buses listed in the isolated bus, disconnected plant, out-of-service synchronous machine, out-of-
service induction machine, and out-of-service load sections of the report are in ascending numerical
or alphabetical order, as appropriate.
Each out-of-service synchronous machine, out-of-service load, and out-of-service fixed shunt has
its identifier printed following the bus identifiers. If more than one synchronous machine, induction
machine, load, or fixed shunt is out-of-service at the same bus, they are listed in alphabetical order
by synchronous machine, induction machine, load, or fixed shunt identifier, as appropriate.
Two-terminal dc lines, multi-terminal dc lines, and VSC dc lines are listed in dc line name alphabet-
ical order. FACTS devices are listed in FACTS device name alphabetical order, and GNE devices
are listed in GNE device name alphabetical order.
5-139
Listing Sequence Data Program Operation Manual
When a subsystem is being processed and bus, area, zone, and/or owner are included among the
selection criteria, the output of activity OUTS is grouped as described in Section 4.9, Subsystem
Reporting.
PSS®E GUI Users Guide, Section 8.1.6, Outaged Equipment
Section 6.1.7, Listing Outaged Equipment
Section 1.188, OUTS
5.43 Listing Sequence Data

Activity SQLI
Run Activity SQLI - GUI

[List Data]
OPTION: Sequence data
Run Line Mode Activity SQLI - CLI
ACTIVITY?
>>SQLI

AB
The sequence data listing activity SQLI tabulates the sequence data arrays in the working case in
a form suitable for problem data documentation. The report generated by activity SQLI is separated
into several categories of data.
The SQLI API routine includes the following among its inputs:
• A designation of the sequence data category to be tabulated.
5.43.1 Operation of Activity SQLI

If output for a bus subsystem is being produced, only equipment in the designated subsystem is
included in the report. Any subsystem filtering applied to a data category is described in the data
category descriptions given in Section 5.43.2, Listing Format.
5-140
Program Operation Manual Listing Sequence Data
The report of activity SQLI is directed to the Report device.
The following data categories are available in activity SQLI:
• All data • Line shunt data

• Load data • Two-winding transformer positive sequence data
• Synchronous machine data • Two-winding transformer zero sequence data
• Induction machine data • Three-winding transformer general data
• Fixed bus shunt data • Three-winding transformer positive sequence data
• Switched shunt data • Three-widing transformer zero sequence data
• Non-transformer branch date • Zero sequence mutual data

Most of the data items tabulated by activity SQLI correspond to data entered in activities RESQ,
TRSQ, READ, TREA, RDCH, and/or MCRE. Refer to Sections 5.2.1, 5.4.1, and 5.5.1 for detailed
descriptions of these quantities.
The following paragraphs describe the data tabulated in the various output categories by activity
SQLI. Unless otherwise stated, data in these categories are tabulated in ascending bus number
order when the numbers output option is in effect and in alphabetical order when the names output
option is in effect.
Load Data
Data for loads is tabulated in the load data category. Loads are listed in ascending bus order
(numeric or alphabetic), and loads at each bus are in ascending load identifier order. The bus type
code and load status are tabulated. Loads tabulated are at nominal values (i.e., in MW and Mvar at
1.0 per unit voltage).
In reporting positive sequence loads, the nominal constant MVA load componentis not adjusted by
any load multiplier associated with an Optimal Power Flow adjustable bus load table; the load multi-
plier is tabulated in the column labeled PSI. Constant admittance loads do not include any shunt
elements modeled at the bus (refer to Fixed Bus Shunt Data and Switched Shunt Data).
Zero sequence and exceptional negative sequence shunt loads, as described in Load Sequence
Data, are listed along with the zero sequence grounding flag.
determine those buses whose connected loads are candidates for reporting; otherwise, all buses
are candidate buses. The area, owner, and/or zone selection criterion, if enabled, determine which
loads at candidate buses are to be reported; otherwise, all loads at candidate buses are reported.
Generator Data
Data for conventional (synchronous) machines is tabulated in the generator unit data category.
Machines are listed in ascending bus order (numeric or alphabetic), and machines in each plant are
The data listed includes the machine identifier, the bus type code, the machine status flag, and the
generator impedance data described in Generator Sequence Data, along with the values of
MBASE, XTRAN, and GENTAP (refer to Generator Data and Section 12.2.3, Generator Step-Up
Transformers). Recall that the actual status of a machine is determined both by its status flag and
5-141
the bus type code (refer to Section 5.9.1 Equipment Status Changes).
enabled, determine those buses whose connected machines are candidates for reporting; other-
machines at candidate buses are to be reported; otherwise, all machines at candidate buses are
reported.

Data for induction machines is tabulated in the induction machine data listing. Machines are listed
in ascending bus order (numeric or alphabetic), and machines at the same bus are in ascending
machine identifier order.
The data listed includes the machine identifier, the bus type code, and the machine status flag.
Recall that the actual status of a machine is determined both by its status flag and the bus type code
(refer to Section 5.9.1 Equipment Status Changes). The machine impedance data described in
Induction Machine Sequence Data is listed, along with the vaules of the machine’s base power and
rated voltage (refer to Induction Machine Data). An M (for mechanical) or E (for electrical) indicates
the machine base power code and is printed following the machine base power.
determine those buses whose connected induction machines are candidates for reporting; other-
wise, all buses are candidate buses. The area, owner, and/or zone selection criterion, if enabled,
determine which induction machines at candidate buses are to be reported; otherwise, all induction
machines at candidate buses are reported.
Fixed Shunt Data

Data for fixed bus shunts is tabulated in the fixed shunt data category. Shunts are listed in ascending
bus order (numeric or alphabetic), and shunts at each bus are in ascending shunt identifier order.
The data listed includes the shunt identifier, the bus type code, the shunt status flag, the positive
sequence fixed shunt admittance, and the zero sequence fixed shunt admittance. Shunt admit-
tances tabulated are at nominal values (i.e., MW and Mvar at 1.0 per unit voltage).
When reporting for a bus subsystem, the fixed bus shunt data tabulation is restricted to subsystem
buses.
Switched Shunt Data

Data for switched shunts are tabulated in the switched shunt data listing. The data printed for each
switched shunt includes the admittance currently switched on along with the switched shunt blocks
present at the bus. Output for each switched shunt consists of two lines of data, with positive
sequence values printed on the first line and zero sequence values on the second line. All admit-
tances printed are at nominal values (i.e., at 1.0 per unit voltage.
When reporting for a bus subsystem, the switched shunt data tabulation is restricted to subsystem
buses.
Non-Transformer Branch Data

Data for non-transformer ac branches is tabulated in the branch data category. Branches are
ordered in ascending numerical or alphabetical order by from bus, and, for each from bus, in
ascending order by to bus and circuit identifier.
5-142
Program Operation Manual Listing Sequence Data
The non-transformer branch data listing is in single entry format. Each non-transformer ac series
branch appears once in the listing: with the lower ordered bus (number or name) listed as the from
bus.
For a branch treated as a zero impedance line, a Z is printed in the column labeled ZI. For branches
that are not treated as zero impedance lines, this column is left blank.
The column labeled ST is the status flag of the branch, with zero indicating out-of-service and one
indicating in-service.
If a branch is mutually coupled to other branches in the zero sequence network, the mutually
coupled branches are listed following the branch data line. Mutuals are listed one per line in single
entry format. The from bus, to bus and circuit identifier of the coupled branches are printed along
with the mutual impedance. Note that the value printed as the mutual impedance may be the nega-
tive of the value initially entered. Careful inspection of the from and to bus ordering for the branches
involved will show that the tabulation has reversed the bus ordering for one of the pair of lines, and
consequently changed the sign of the complex mutual impedance.
date buses, including branches to non-candidate buses (i.e., ties), are reported.
Line Shunt Data

Data for line connected shunts on non-transformer ac branches is tabulated in the line shunt data
category. This report tabulates branches with one or more non-zero line connected shunts in the
positive and/or zero sequence networks; branches for which line shunt values are all (0.0 + j 0.0)
are omitted from the report.
The line shunt data listing is in single entry format. Each non-transformer ac series branch with a
non-zero line shunt admittance appears once in the listing: with the lower ordered bus (number or
name) listed as the from bus. Branches are ordered in ascending numerical or alphabetical order
by from bus, and, for each from bus, in ascending order by to bus and circuit identifier.
date buses with any non-zero line shunt component, including branches to non-candidate buses
(i.e., ties), are reported.
Two-Winding Transformer Data

Data for two-winding transformers is tabulated in the two-winding transformer positive sequence
data listing, and in the two-winding transformer zero sequence data listing. Transformer branches
are ordered in ascending numerical or alphabetical order by from bus, and, for each from bus, in
ascending order by to bus and circuit identifier.
The two-winding transformer data listings are in single entry format. Each two-winding transformer
appears once in the listings: with the lower ordered bus (number or name) listed as the from bus.
5-143
In the positive sequence data listing, the column labeled ST is the status flag of the transformer,
with zero indicating out-of-service and 1 indicating in-service. If the from bus is the bus to which
Winding 1 of the transformer is connected, the column labeled W1 contains an F; otherwise, this
column contains a T.
enabled, determine those buses whose connected two-winding transformers are candidates for
mines which transformers at candidate buses are to be reported; otherwise, all two-winding
are reported.
Three-Winding Transformer Data

Data for three-winding transformers is tabulated in the three-winding transformer general data
listing, in the three-winding transformer positive sequence data listing, and in the three-winding
transformer zero sequence data listing. The three-winding transformer data listing is in single entry
format. Each three-winding transformer appears once in the listing, with transformers ordered
alphabetically by transformer name.
In the general data listing, the first column labeled ST is the status flag of the transformer, with
values of 0 through 4 as defined in Transformer Data. The remaining columns labeled ST contains
the status flags of the three windings, as derived from the status flag of the three-winding trans-
former, with zero indicating out-of-service and 1 indicating in-service. The magnetizing admittance
is listed in the units indicted by CM.
In the positive sequence and zero sequence data listings, the column labeled ST is the status flag
of the three-winding transformer, with values of 0 through 4 as defined in Transformer Data.
In the positive sequence data listing, measured impedances are listed in the units indicated by CZ,
and tap settings (i.e., WINDVn) are listed in the units indicated by CW.
In the zero sequence data listing, nominal impedances are listed in the units indicated by CZ0, and
grounding and neutral impedances are listed in the units indicated by CZG.
enabled, determine those buses whose connected three-winding transformers are candidates for
mines which transformers at candidate buses are to be reported; otherwise, all three-winding
are reported.
Mutual Impedance Data

Data for zero sequence mutual couplings is tabulated in the mutual impedance data listing. The data
printed for each mutual coupling consists of the from bus, to bus, and circuit identifier of the coupled
branches, the mutual impedance and the geographic B factors (refer to Zero Sequence Mutual
Impedance Data). As in the case of the mutual portion of the branch data listing described in Non-
Transformer Branch Data, the sign of a branch’s mutual impedance may be the negative of the
value initially entered. Similarly, one or both sets of its B factors may be modified to express the
location of the mutual relative to the bus listed as the from bus in the data listing.
Zero sequence mutuals are listed in single entry format.
5-144
Program Operation Manual Listing Sequence Data for a Bus
When reporting for a bus subsystem, a mutual coupling is reported if either of the two branches
satisfy the subsystem selection criteria. The bus, area, zone, and/or base voltage selection criteria,
if enabled, determine those buses whose connected branches are candidates for reporting; other-
branches involved in mutuals at candidate buses satisfy the subsystem selection criteria; otherwise,
all branches involved in mutuals at candidate buses, including branches to non-candidate buses
(i.e., ties), satisfy the subsystem selection criteria.
PSS®E GUI Users Guide, Section 8.1.4, Listing Sequence Data
Section 6.1.5, Sequence Data
Section 1.309, SQLI
5.44 Listing Sequence Data for a Bus

Activity SQEX
Run Activity SQEX - GUI

[List Data]
OPTION: Examine Powerflow / sequence data > Sequence data
Run Line Mode Activity SQEX - CLI
ACTIVITY?
>>SQEX

AB
The sequence data examination activity SQEX produces a tabulation of fault analysis data orga-
nized by bus. For each bus tabulated, its bus data is followed by the data associated with each
network element that is connected to the bus for which sequence data is applicable.
The SQEX API routine includes the following among its inputs:
5.44.1 Operation of Activity SQEX

The report of activity SQEX is directed to the Report device.
5-145
Listing Sequence Data for a Bus Program Operation Manual

The blocks of output for buses are ordered as described in Section 4.9, Subsystem Reporting. The
output block for each bus tabulated includes bus, load, fixed shunt, switched shunt, synchronous
machine, and induction machine quantities along with data for each transmission line, transformer,
dc line, and FACTS device connected to the bus. The data for each equipment category is tabulated
in a format similar to that of activity SQLI (refer to Section 5.43.2 Listing Format).
In the non-transformer branch data tabulation, any branch treated as a zero impedance line has a
 printed in the column labeled ZI at the end of the line; for other branches, this column is left blank.
In the two-winding transformer positive sequence data tabulation, the column labeled W1 contains
an F if the bus being reported is the bus to which Winding 1 of the transformer is connected or a T
if the bus listed as the to bus is the Winding 1 bus. All transformer impedances, admittances, and
tap ratios are printed in the units indicated by the various input/output units codes(i.e., CZ, CM, CW,
CZ and CZG).
5-146
Program Operation Manual Creating a Saved Case File
For dc lines and FACTS devices, the control mode is printed along with the pu powers as seen by
the ac system. For two-terminal dc lines, multi-terminal dc lines, and FACTS devices, the powers
are printed as flowing from the ac system into the device at each of the ac buses to which it is
connected; for VSC dc lines, the powers are printed as flowing into the ac system.
PSS®E GUI Users Guide, Section 8.1.5, Listing Sequence Data for Buses and their Connected
Equipment
Section 6.1.6, Listing Sequence Data for Buses and their Connected Equipment
Section 1.307, SQEX
5.45 Creating a Saved Case File

Activity SAVE
Run Activity SAVE - GUI

File > Save
[Save Network Data]
Case Data Tab
Run Line Mode Activity SAVE - CLI
ACTIVITY?
>>SAVE
>>
None
The case saving activity SAVE stores the working case into a user-specified Saved Case File in a
compressed format.
The SAVE API routine requires as an input the name of the Saved Case File to be used.
If an asterisk (  is specified as the name of the Saved Case File, the last Saved Case File
accessed by either activity SAVE or activity CASE in the current execution of PSS®E is used.
Refer to Section 2.4.2, Specifying Filenames for the file specification conventions and to Section
2.6, Files Created By PSS®E for the file overwriting conventions used by activity SAVE.
Along with the working case, several of the PSS®E run-time option settings that are active at the
time activity SAVE is selected are preserved in the Saved Case File (refer to Saved Case Specific
Option Settings).
5-147
Bus Renumbering Program Operation Manual
®
PSS E GUI Users Guide, Section 10.1, Creating a Saved Case File
Section 7.1, Creating a Saved Case File
Section 1.279, SAVE
See also:
Section 5.1, Retrieving a Power Flow Saved Case File
5.46 Bus Renumbering

Activity BSNM
Run Activity BSNM - GUI

Power Flow > Renumber Buses > By Bus Number…
By Bus Name…
By Packing…
By Subsystem…
[Renumber Buses by Bus Number]
[Renumber Buses by Bus Name]
[Renumber Buses by Bus Packing]
[Renumber Buses by Subsystem]
Run Line Mode Activity BSNM - CLI
ACTIVITY?
>>BSNM
None
The bus renumbering activity BSNM enables the user to change the bus numbers of specified
network buses in the working case and retain a tabulation, normally in file form, of the bus number
changes made.
The BSNM API routine includes the following among its inputs:
• A flag indicating the method to be used to renumber buses and/or the processing
phase to be performed during this call of the BSNM API routine.
• A designation of the subsystem in which bus numbers are to modified if the renum-
bering method is subsystem renumbering; refer to Section 4.8, Subsystem Selection.
• Three integer data items; their interpretation and usage is dependent on the value
specified for the method flag during this call of the BSNM API routine.
• A character data item that specifies an extended bus name if the renumbering method
is Bus Name to Bus Number Translation.
5-148
Program Operation Manual Bus Renumbering
• A character data item that specifies a translation input file if the renumbering method is
a translation method (Bus Number to Bus Number Translation or Bus Name to Bus
Number Translation) with input taken from a file.
• A code indicating the disposition of the Output Tabulation of bus number changes
made.
• The name of the Bus Renumbering Translation File for recording the bus number
changes made; used if a data file is selected for the output tabulation.
5.46.1 Renumbering Methods

Several bus renumbering methods are available in activity BSNM. The appropriate method to use
in a given bus renumbering task is usually dictated by the scope and purpose of the renumbering
task.
The following paragraphs describe the use of the various bus renumbering methods.
All Buses Without Area Blocking

In this method, activity BSNM renumbers all buses in the working case. The user specifies a starting
bus number, and the bus numbers in the working case are resequenced by increments of one,
starting at the specified bus number. The new bus number sequence corresponds to the original
bus number sequence when the numbers output option is in effect, or to bus name alphabetical
order when the names output option is in effect (see Saved Case Specific Option Settings).
All Buses With Area Blocking

In this method, activity BSNM renumbers all buses in the working case. The user specifies a bus
number range for each area that has at least one bus assigned to it. For each area, the bus numbers
in the working case are resequenced by increments of one, starting at the area’s specified starting
bus number. Within each area, the new bus number sequence corresponds to either the original
bus number sequence or bus name sequence of area buses, depending on the bus output option
in effect (see Saved Case Specific Option Settings).
When specifying an area’s bus number range, the following conditions must be satisfied:
• The starting bus number must be greater than zero.

• The ending bus number must not exceed 999,997.
• The ending bus number must be greater than the starting bus number.
• The bus number range must be large enough to accommodate all of the buses
assigned to the area.
No overlap of bus number ranges is allowed.
Subsystem
In this method, activity BSNM renumbers all buses in a specified bus subsystem. Two subsystem
renumbering methods are available: the Bus Number Range Method, and the Bus Number Offset
Method.
Bus Number Range Method

In this method, activity BSNM reassigns bus numbers of the specified subsystem so that they all
fall within a designated range. The user specifies the starting and ending bus numbers for the range
into which the subsystem is to be renumbered.
5-149
When specifying the bus number range, the following conditions must be satisfied:

• The bus number range must be large enough to accommodate all of the buses in the
subsystem.
If any violations are detected, an appropriate message is printed and no bus number changes are
made for the specified subsystem. Otherwise, the subsystem buses are renumbered. Any buses
with numbers already in the specified range are left unchanged.
Bus Number Offset Method

In this method, activity BSNM reassigns bus numbers of the specified subsystem by adding a
constant, either positive or negative, to the bus numbers of all buses in the specified subsystem. If,
for any bus, the resulting bus number is invalid or already assigned to another bus, an appropriate
message is printed and no bus number changes are made for the specified subsystem. Otherwise,
the subsystem buses are renumbered.
Bus Number to Bus Number Translation

In this method, activity BSNM changes the number of a specified bus to a designated new bus
number. The bus that is to have its number changed is designated by its present bus number.
A bus number pair may be specified as an input to the BSNM API routine. Alternatively, a Bus
Renumbering Translation File containing bus number pairs may be specified to the BSNM API
routine; each record of the file must be in the form:
current bus number new bus number
In either case, when specifying an old number, new number pair, the following conditions must be
satisfied:
• The first bus specified must be in the working case.

• The new bus number must be a valid bus number (i.e., between 1 and 999,997).
• The new bus number must not already be assigned to a bus in the working case.
If any violations are detected in processing a bus number pair, an appropriate message is printed
and the corresponding bus number change is not implemented. Otherwise, the bus number change
is made. Activity BSNM then processes the next bus number pair.
Bus Name to Bus Number Translation

In this method, activity BSNM changes the number of a specified bus to a designated new bus
number. The bus that is to have its number changed is designated by its extended bus name.
A bus name, bus number pair may be specified as an input to the BSNM API routine. Alternatively,
a translation input file containing bus name, number pairs may be specified to the BSNM API
routine; each record of the file must be in the form:
'extended bus name' new bus number
In either case, when specifying an bus name, new number pair, the following conditions must be
satisfied:
5-150
Program Operation Manual Bus Renumbering
• The first bus specified must be in the working case.

• The new bus number must be a valid bus number (i.e., between 1 and 999,997).
• The new bus number must not already be assigned to a bus in the working case.
If any violations are detected in processing a bus name, number pair, an appropriate message is
printed and the corresponding bus number change is not implemented. Otherwise, the bus number
change is made. Activity BSNM then processes the next bus name, number pair.
Bus Number Packing

In this method, activity BSNM changes the numbers of buses in a specified bus number range so
that all bus numbers in the range are packed into the low end of the range.
When specifying the bus number range, the following conditions must be satisfied:

If any violations are detected, an appropriate message is printed and no bus number changes are
made for the specified range. Otherwise, the bus numbers falling within the specified range are
packed sequentially beginning with the starting bus number. Thus, the new bus number sequence
corresponds to the original bus number sequence, with gaps in bus number usage eliminated.
5.46.2 Output Tabulation

Activity BSNM provides for a tabulation documenting those buses that have been assigned new bus
numbers. This tabulation consists of a series of records in the following format:
old bus number new bus number / bus name and base voltage
The following options are available for the handling of this output tabulation:
• Write these records to a Bus Renumbering Translation File.

• Write these records to the Report device.
• Suppress the writing of these records.
Writing these records to a Bus Renumbering Translation File is useful for the situation where
several power flow Saved Cases of substantially identical network topology but, for example,
different loading levels are to be renumbered. This may be accomplished by directing the output of
activity BSNM to a file for the first of the group of cases. That file may then be used as input in
subsequent executions of activity BSNM for the remaining cases using the Bus Number to Bus
Number Translation renumbering method. This Bus Renumbering Translation File is also directly
usable by activity RNFI.
Following the completion of processing, the following message is printed at the Progress device
by activity BSNM:
n BUS NUMBER CHANGES MADE FOR SPECIFIED SUBSYSTEM
If enabled, the tabulation of the bus number changes in Bus Renumbering Translation File format
is written just before leaving activity BSNM. Thus, assuming Bus Number to Bus Number Transla-
tion, a series of changes such as:
5-151
change bus 101 to bus 154

then change bus 154 to bus 101
would be reported as two changes in the Progress output, but the output tabulation would show no
bus number translations because the effect of the second change was to cancel out the first
change.
5.46.3 Examples of Activity BSNM

Suppose that Bus Number Packing is performed on the range starting at 101 and ending at 160 for
the savnw.sav Saved Case File. The original and resulting new bus numbers are shown in Figure 5-
49. It can be seen that the original bus range from 101 to 154 has been packed to a range from 101
to 106.
Figure 5-49. Packing Bus Numbers
Figure 5-50 shows the message at the Progress device indicating how many buses have been
modified, along with the tabulation of bus number changes at the Report device. The latter tabula-
tion could have been sent to a specified output file.
Figure 5-50. Progress Output Indicating Number of Buses Modified
Figure 5-51 shows the Progress and Report device output resulting from bus renumbering using
the All Buses With Area Blocking method on the savnw.sav Saved Case File. Each of the three
areas in the case is given a new bus number range.
5-152
Program Operation Manual Saving the Working Case in an IEEE Common Format File
Figure 5-51. Result of Block Renumbering by Areas
®
PSS E GUI Users Guide, Section 7.16, Renumbering Buses
Section 4.21.1, Saving Renumbered Bus Data to a File
Section 1.45, BSNM
5.47 Saving the Working Case in an IEEE Common Format File

Activity RWCM
Run Activity RWCM - GUI

File > Save…
[Save Network Data]
IEEE Format Power Flow Data Tab
Run Line Mode Activity RWCM - CLI
ACTIVITY?
>>RWCM
5-153
Saving the Working Case in an IEEE Common Format File Program Operation Manual

AB
The IEEE Common Format output activity RWCM writes the working case as a file in IEEE common
tape format data records. This format is described in "Common Format for Exchange of Solved
Load Flow Data," IEEE Transactions on Power Apparatus and Systems, Vol. PAS-92,
November/December 1973, pp. 1916-1925.
The RWCM API routine includes the following among its inputs:
• A code indicating the handling of dc lines, FACTS devices, and GNE devices in the
IEEE Common Format data records.
• A code indicating the disposition of the IEEE Common Format data records.
• The name of the file to which the IEEE Common Format data records are to be written;
used if a data file is selected as the destination for the records written by activity
RWCM.
2.6, Files Created By PSS®E for the file overwriting conventions used by activity RWCM.
If any unblocked dc lines, out-of-service FACTS devices, or out-of-service GNE devices are present
in the working case, the user must specify whether to ignore dc lines, FACTS devices, and GNE
devices, or add their apparent ac powers to the loads. If dc lines, FACTS devices, and GNE devices
are ignored, their representation should be described in the transmittal letter to the party receiving
the data file. If power is added to loads, all unblocked dc lines, in-service FACTS devices, and in-
service GNE devices are accounted for in the common format data records by treating the powers
flowing into them at their ac network buses as complex bus loads.
If more than 9,999 buses are present in the working case, or any buses have bus numbers greater
than 9999, an appropriate message is printed at the Alert device and activity RWCM is terminated.
Buses with a type code of 4 or greater and out-of-service branches are not included in the output
file. Any buses in the working case residing in an area for which the number is greater than 99 are
assigned area number 99 in the output file.
For any bus with a switched shunt element, the switched shunt admittance is added to the fixed bus
shunt. Line connected shunts are added to the bus shunt of the appropriate buses. In-service
constant current load is added to the constant power load and in-service constant admittance load
is added to the bus shunt. Powers flowing into in-service induction machines are added to the
constant power load.
Branch circuit identifiers may be modified in the output file built by activity RWCM. Circuit numbers
are assigned for all circuits between pairs of buses such that they are numbered starting with circuit
number 1 and assigned sequential circuit numbers up to 9. If more than 9 parallel circuits exist
between any pair of buses, appropriate alarm messages are printed and circuits 10, 11, and so on
are assigned and reported. Note that the leading digit is placed in a field that is defined to be blank
in the IEEE format, so that other programs reading the data file might have difficulty. It is suggested
that parallel circuits be combined so that no more than nine circuits exist between any pair of buses.
For each three-winding transformer contained in the working case, activity RWCM assigns an avail-
able four digit bus number to the star point bus, and produces a corresponding bus record. Three
5-154
Program Operation Manual Saving Machine Impedance Data
two-winding transformer branch records are also produced, one for each winding of the three-
winding transformer.
Section 10.2, Saving the Working Case in an IEEE Common Format File
Section 7.2, Saving the Working Case in an IEEE Common Format File
Section 1.274, RWCM
5.48 Saving Machine Impedance Data

Activity RWMA
Run Activity RWMA - GUI

File > Save…
[Save Network Data]
Machine Impedance Data Tab
Run Line Mode Activity RWMA - CLI
ACTIVITY?
>>RWMA
AB
The machine impedance data output activity RWMA writes out machine parametric data from the
working case in the form of a Machine Impedance Data File (refer to Section 5.4.1 Machine Imped-
ance Data File Contents). That is, when directed to a file, the output of activity RWMA is in a format
suitable for input to activity MCRE. A data file of the form written by activity RWMA is also required
by the IEEE stability data output program, CMDYRE (refer to Additional Resources for PSS®E,
CMDYRE).
The RWMA API routine includes the following among its inputs:
• A designation of the subsystem from which the machine parametric data is to be

written; refer to Section 4.8, Subsystem Selection.
• A code indicating whether to include or exclude data records for out-of-service
machines.
• A code indicating the option to use in calculating active power split fractions.
• A code indicating the option to use in calculating reactive power split fractions.
• A code indicating the disposition of the machine impedance data records.
5-155
Saving Machine Impedance Data Program Operation Manual
• The name of the Machine Impedance Data File to which the machine impedance data
records are to be written; used if a data file is selected as the destination for the records
written by activity RWMA.
5.48.1 Operation of Activity RWMA

The user specifies either that the entire working case is to be processed, or that machine imped-
ance data in a designated bus subsystem are to be processed.
When a bus subsystem is being processed and ownership is included among the selection criteria,
the owners to which machines (rather than buses) are assigned are used in defining the subsystem
of machines to be processed. The bus, area, zone, and/or base voltage selection criteria, if enabled,
determine those buses whose connected machines are candidates for processing; otherwise, all
buses are candidate buses. All machines at candidate buses that are wholly or partly owned by any
of the owners specified are processed (refer to Generator Data).
Activity RWMA provides options for calculating the power split fractions FP and FQ (refer to
Section 5.4.1 Machine Impedance Data File Contents):
• for calculating P fractions:

- PGEN (default)
- MBASE
- PMAX
• for calculating Q fractions:
- QGEN (default)
- MBASE
- QMAX
Details on the calculation of the active and reactive power split fractions are provided in Split
Fractions.
2.6, Files Created By PSS®E for the file overwriting conventions used by activity RWMA.
Data records are produced in ascending bus number order by activity RWMA. The extended bus
name (name plus base voltage) is included at the end of each data record. While these are ignored
by activity MCRE, they are required by the auxiliary program CMDYRE.

The inclusion or omission of out-of-service machines and the proper selection of the quantities used
to derive the power split fractions is dependent upon the application at hand.
Transfer Machine Data to Another Case

One use of the Machine Impedance Data File is to introduce generator impedance data, as required
for switching studies, fault analysis, and dynamic simulation work, into a power flow case in which
the plant modeling terminates at the plant bus. This is handled by activity MCRE, which also
provides for the introduction of multiple machine representation at a plant and the splitting of total
plant power output and power limits among its machines. The Machine Impedance Data File as built
by activity RWMA may be used to transfer this level of plant modeling from one power flow case to
5-156
Program Operation Manual Saving Machine Impedance Data
another that models essentially the same system but in which the details of the individual machines
have not as yet been introduced. Refer to Section 5.4.3 Application Notes for additional application
notes on the use of the Machine Impedance Data File by activity MCRE.
When transferring machine data from one case to another, it is usually appropriate to include out-
of-service machines and to use either generator powers or machine bases to form the active power
split fractions. In setting the reactive power split fractions, either the machine base or QMAX should
be selected rather than the machine reactive power. This avoids a potential problem if, for example,
in a multimachine plant with differently sized units, the lower reactive power limits are all zero and
all machines are at their low var limits. The reactive power split fractions would then be set equal
for these machines, and, when subsequently read by activity MCRE, reactive power limits would be
set incorrectly.
Stability Data in IEEE Format

A Machine Impedance Data File, along with its corresponding Dynamics Data File (refer to Section
15.1.1, Dynamics Model Raw Data File Contents), is required by the auxiliary program CMDYRE to
construct a stability data file in IEEE format. This format is described in "Procedures for the
Exchange of Power Plant and Load Data for Synchronous Stability Studies", IEEE Transactions on
Power Apparatus and Systems, Vol. PAS-100, No. 7 July 1981, pp. 3229-3245.
When the file created by activity RWMA is to be used as input to the auxiliary program CMDYRE,
it is usually appropriate to include only in-service machines and to use generator powers to calcu-
late the power split fractions.
Machine Status Considerations

In determining machine status, both the bus type code and the machine status flag are considered.
A machine is treated as in-service if its status flag is 1 and the bus type code is 2 or 3.
Split Fractions
The split fractions of a machine are calculated as the ratio of the selected machine quantity to the
sum of those quantities of all in-service machines being processed at the bus. If this denominator
is zero and records for out-of-service machines are being included, the denominator is taken as the
sum of the appropriate quantity of all machines being processed at the bus. If it is still zero, the split
fraction is set to the reciprocal of the number of in-service machines being processed at the bus; if
all machines being processed at the bus are out-of-service, the split fraction is set to the reciprocal
of the number of such machines being processed at the bus.
Using this approach, then, the sum of the split fractions of the in-service machines being processed
at a bus, exclusive of numerical round off, is normally unity. The only situation in which this is
violated is in the case where out-of-service machines are included, both in-service and out-of-
service machines are present and being processed at a bus, and the sum of the split fraction quan-
tity is zero for the in-service machines and non-zero for the out-of-service machines.
When generator reactive powers are used in determining the reactive power split fractions, the
working case must be solved to an acceptable mismatch level.
5-157
Creating a Power Flow Raw Data File Program Operation Manual
®
PSS E GUI Users Guide, Section 10.3, Saving Machine Impedance Data
Section 7.3, Saving Machine Impedance Data
Section 1.275, RWMA
5.49 Creating a Power Flow Raw Data File

Activity RAWD
Run Activity RAWD - GUI

File > Save…
[Save Network Data]
Power Flow Raw Data Tab
Run Line Mode Activity RAWD - CLI
ACTIVITY?
>>RAWD
AB
The Raw Data File output activity RAWD writes the working case in the form of a Power Flow Raw
Data File (refer to Section 5.2.1 Power Flow Raw Data File Contents). That is, when directed to a
file, the data records written by activity RAWD are in a format suitable for input to activity READ.
The RAWD_2 API routine includes the following among its inputs:
• A designation of the subsystem for which the power flow data records are to be written;
• A code indicating whether to include or exclude data records for out-of-service buses
(i.e., Type 4 buses).
branches.
• A code indicating whether to include or exclude data records for equipment within the
specified subsystem.
• A code indicating whether to include or exclude data records for tie branches from the
• A code indicating the option to be used for including load data records.
• A code indicating the use of either bus numbers or extended bus names as bus
identifiers.
• A code indicating the intended use of the Power Flow Raw Data file.
5-158
Program Operation Manual Creating a Power Flow Raw Data File
• A code indicating the disposition of the power flow data records: either to a file or to the
Progress device.
• The name of the Power Flow Raw Data File to which the data records are to be written;
used if a data file is selected as the destination for the records written by activity RAWD.
5-159
Creating a Power Flow Raw Data File Program Operation Manual
5.49.1 Operation of Activity RAWD

The user specifies either that the entire working case is to be processed, or that data records for a
designated bus subsystem are to be written.
When a bus subsystem of the working case is specified for processing by activity RAWD, the user
has the ability to select as output for that subsystem one of the following:
• All buses in the specified subsystem, all branches having all of its buses in the specified
subsystem, and all bus connected equipment connected to buses in the specified sub-
system. Branches include non-transformer branches, transformers, dc lines, and
FACTS and GNE devices with a series element. Bus connected equipment include
fixed shunts, machines, switched shunts, and FACTS and GNE devices without a
series element. When area, owner and/or zone are among the subsystem selection cri-
teria, options for the handling of loads is described next; otherwise, loads are handled
in the same manner as other bus connected equipment.
• All branches having one, but not all, of its buses in the specified subsystem.
• All buses in the specified subsystem, all branches having at least one of its buses in
the specified subsystem, and all bus connected equipment connected to buses in the
When a bus subsystem of the working case is specified for processing by activity RAWD, and area,
owner and/or zone are among the subsystem selection criteria, one of the following options is
selected for the handling of loads:
• Include load records for all loads at subsystem buses.

• Include load records for subsystem loads at all buses. In this case, the area, owner
and/or zone assignments, as appropriate, of a load is used in determining if its load
record is output; the area, owner and/or zone assignments of the bus to which the load
is connected are not considered. When this option is selected, records for loads that
are connected to buses outside of the subsystem may be included in the output of
activity RAWD, and records for some loads connected to subsystem buses may be
omitted.
• Include load records for all loads at subsystem buses and for subsystem loads at non-
subsystem buses.
When the entire working case is being processed and the option to include records for subsystem
tie branches is specified, activity RAWD produces an output tabulation consisting only of branches
between areas. Thus, no bus, load, fixed shunt, generator, switched shunt, area, zone, owner, or
interarea transfer data is output, and the only branch, transformer, transformer impedance correc-
tion table, dc line, FACTS device, and GNE device data included in the output is for branches with
terminals connected to buses in different areas.
The intended use of the Power Flow Raw Data File that is being written governs the appropriate
form of the Case Identification Data records at the beginning of the file. One of the following
intended uses must be selected:
• By activity READ with initialization of the working case (i.e., with IC = 0 on the first data
record).
• By activity READ to add data to the working case (i.e., with IC = 1 on the first data
record).
• By activity RDCH (i.e., with the case identification data records omitted).
5-160
Program Operation Manual Creating a Power Flow Raw Data File
2.6, Files Created By PSS®E for the file overwriting conventions used by activity RAWD.

Each data category of the output of activity RAWD is tabulated in ascending bus number (or bus
name if the NAME bus identifier option is enabled) order, except for:
• dc line data, which is reported in ascending dc line name order for two-terminal, multi-
terminal, and VSC dc lines.
• transformer impedance correction table data, which is reported in table number order.
• area interchange data and area transactions data, which are reported in ascending
area number order.
• zone data, which is reported in ascending zone number order.
• owner data, which is reported in ascending owner number order.
• FACTS device data, which is reported in ascending FACTS device name order.
• GNE device data, which is reported in ascending GNE device name order.
While switched shunt data is, for the most part, reported in ascending bus number or name order,
those switched shunts that control the admittance setting of other switched shunts are grouped at
the end of the switched shunt data records.
If a branch data record is reported for a branch that is a member of a multi-section line grouping,
then that multi-section line has a multi-section line grouping data record included in the output
tabulation.
A transformer impedance correction table data record is included in the output of activity RAWD for
any table referenced in the transformer data record block of at least one transformer where data is
included in the output of activity RAWD.
When the data records for the entire working case are being written, an area interchange data
record is included in the output of activity RAWD for all areas that satisfy the following:
• at least one bus, load, induction machine, or dc bus record for equipment assigned to
the area is written
and
• the area does not have default area interchange data assigned to it (refer to Area Inter-
change Data).
When a subsystem of the working case is processed, an area interchange data record is written for
all areas that satisfy the following:
• at least one bus or load record for equipment assigned to the area is written
and
• the area does not have default area interchange data assigned to it.
Similarly, a zone data record is written for any zone for which:
• at least one bus, load, or dc bus record for equipment assigned to the zone is written
5-161
Creating a Sequence Data File Program Operation Manual
and
• the zone has a non-blank zone name (refer to Zone Data).
When the entire working case is processed, an owner data record is written for any owner for which:
• at least one bus, load, synchronous machine, induction machine, branch, dc bus,
FACTS device, VSC dc line, or GNE device record is written
and
• the owner has a non-blank owner name (refer to Owner Data).
When a subsystem of the working case is processed, an owner data record is written for any owner
for which:
• at least one bus, load, machine, branch, dc bus, or VSC dc line record is written
and
• the owner has a non-blank owner name.
When the data records for the entire working case are being written, an interarea transfer data
record is included in the output of activity RAWD for any transaction for which at least one bus, load,
induction machine, or dc bus record from each of the two areas is written. When a subsystem of the
working case is processed, an interarea transfer data record is written for any transaction for which
at least one bus, load, or dc bus record from each of the two areas is written.
While a PSS®E Saved Case File is the preferred mechanism for preserving and archiving network
data, a PSS®E Power Flow Raw Data File facilitates the merging of network data with another
power flow case (see Merging Cases).
Activity RAWD may be used to set up a Power Flow Raw Data File for use by activity READ in the
data processing phases of advanced network equivalent construction (refer to Section 5.2.5
Reading Power Flow Raw Data Files Created by Previous Releases of PSS®E). When used in this
mode, disconnected buses and out-of-service branches should normally not be included in the
output file created by activity RAWD.
®
PSS E GUI Users Guide, Section 10.4, Creating a Power Flow Raw Data File
5.50 Creating a Sequence Data File

Activity RWSQ
Run Activity RWSQ - GUI

File > Save…
[Save Network Data]
Sequence Data Tab
Run Line Mode Activity RWSQ - CLI
5-162
Program Operation Manual Creating a Sequence Data File
ACTIVITY?
>>RWSQ
>>
AB
The Sequence Data File output activity RWSQ writes the sequence data contained in the working
case in the form of a Sequence Data File (refer to Section 5.5.1 Sequence Data File Contents). That
is, when directed to a file, the output of activity RWSQ is in a format suitable for input to activity
RESQ.
The RWSQ_2 API routine includes the following among its inputs:
• A designation of the subsystem for which the sequence data records are to be written;
• A code indicating whether to include or exclude data records for out-of-service buses
(i.e., Type 4 buses).
branches.
• A code indicating whether to include or exclude data records for equipment within the
• A code indicating whether to include or exclude data records for tie branches from the
• A code indicating the intended use of the Sequence Data File.
• A code indicating the disposition of the sequence data records: either to a file or to the
Progress device.
• The name of the Sequence Data File to which the data records are to be written; used
if a data file is selected as the destination for the records written by activity RWSQ.
5-163
Creating a Sequence Data File Program Operation Manual
5.50.1 Operation of Activity RWSQ

The user specifies either that the entire working case is to be processed, or that data records for a
designated bus subsystem are to be written.
When a bus subsystem of the working case is specified for processing by activity RWSQ, the user
has the ability to select as output for that subsystem one of the following:
• All buses in the specified subsystem, all branches having all of its buses in the specified
subsystem, and all bus connected equipment connected to buses in the specified
subsystem.
• All branches having one, but not all, of its buses in the specified subsystem.
• All buses in the specified subsystem, all branches having at least one of its buses in
the specified subsystem, and all bus connected equipment connected to buses in the
When the entire working case is being processed and the option to include records for subsystem
tie branches is specified, activity RWSQ produces an output tabulation consisting only of branches
between areas. Thus, no generator, load, switched shunt, fixed shunt, and induction machine data
is output, and the only branch, mutual impedance, and transformer data included in the output is for
branches with terminals connected to buses in different areas.
2.6, Files Created By PSS®E for the file overwriting conventions used by activity RWSQ.

The Sequence Data File written by activity RWSQ always has the IC value on the first data record
set to the value specified as an input to the RWSQ_2 API routine. When using such a Sequence
Data File, it is the responsibility of the user to ensure that this flag is set to the appropriate value for
the application at hand. This data value may be changed with a text editor.
Each data category of the output of activity RWSQ is tabulated in ascending bus number order.
Transformer records are written with the winding 1 bus as the "from" bus.

Section 10.5, Creating a Sequence Data File
Section 7.5, Creating a Sequence Data File
Section 1.278, RWSQ_2
5-164
Program Operation Manual Creating a Transactions Raw Data File
5.51 Creating a Transactions Raw Data File

Activity RWMM
Run Activity RWMM - GUI

File > Save…
[Save Network Data]
Transaction Data Tab
Run Line Mode Activity RWMM - CLI
ACTIVITY?
>>RWMM
>>
AB
The Transactions Raw Data File output activity RWMM writes the transactions data contained in
working memory in the form of a Transactions Raw Data File (refer to Section 5.6.1, Transactions
Raw Data File Contents). That is, when directed to a file, the data records written by activity RWMM
are in a format suitable for input to activity REMM.
The RWMM API routine includes the following among its inputs:
• A code indicating the disposition of the transactions data records: either to a file or to
the Progress device.
• The name of the Transactions Raw Data File to which the data records are to be
written; used if a data file is selected as the destination for the records written by activity
RWMM.
5.51.1 Operation of Activity RWMM

Activity RWMM produces data records for all transaction data contained in working memory.

The data records written by activity RWMM include the initial record specifying the current state of
the participation factor flag, IPF. In line mode, it is the responsibility of the user to ensure that this
record is removed when the file is to be used as input to activity REMM run with the suffix CH.
Section 1.276, RWMM
5-165
This page intentionally left blank.
5-166
5-167
Creating a Transactions Raw Data File Program Operation Manual
5-168
5-169
5-170
5-171
5-172
5-173
5-174
5-175
5-176
5-177
5-178
5-179
5-180
5-181
5-182
5-183
5-184
5-185
5-186
5-187
5-188
Chapter 6
Power Flow Solution
Activity Descriptions
Chapter 6 - Power Flow Solution Activity Descriptions
6.1 About Power Flow Calculations

The most common power system network simulation is the power flow calculation, described in the
following question:
Given the load power consumption at all buses of the electric power system and
the generator power production at each power plant, what is the power flow in each
line and transformer of the interconnecting network?
Calculated answers to this question are the basic means by which the power system is engineered
to serve its load. The power system must operate without overloading transmission lines or trans-
formers, stay within acceptable voltage limits at all buses, and maintain generator reactive power
outputs between acceptable limits.
The power flow problem pertains to balanced steady-state operation of the power system. Because
it considers balanced operation in which all negative- and zero-sequence voltages are zero, the
power flow calculation deals with the positive-sequence model of all system components.
The following are the basic known input data for power flow calculations:
• Transmission line impedances and charging admittances.

• Transformer impedances and tap ratios.
• Admittances of shunt-connected devices such as static capacitors and reactors.
• Load-power consumption at each bus of the system.
• Real-power output of each generator or generating plant.
• Either voltage magnitude at each generator bus or reactive power output of each gen-
erating plant.
• Maximum and minimum reactive power output capability of each generating plant.
The quantities to be determined are
• The magnitude of the voltage at every bus where this is not specified in the input data.
• The phase of the voltage at every bus, except swing buses.
• The reactive power output of each plant for which it is not specified.
6-1
Power Flow Solution Activity Descriptions PSS®E 34.2
Power Flow Solution Methods Program Operation Manual
• The real power, reactive power, and current flow in each transmission line and
transformer.
The power flow calculation is a network solution problem. The network of transmission lines and
transformers is described by the linear algebraic equation:
In = YnnVn (6.1)
where:
In = Vector of positive-sequence currents flowing into the network at its nodes

(buses).
Vn = Vector of positive-sequence voltages at the network nodes (buses).
Ynn = Network admittance matrix.
If either In or Vn is known, the power flow calculation is straightforward. In practice, neither In nor
Vn is known and the task of the power flow program is to devise successive trials of both In and Vn
such that they satisfy both Equation 6.1 and all the load and generation conditions specified in the
problem data. After Vn has been determined, all individual transmission line and transformer flows
can be obtained directly from the individual component equations.
This chapter contains operational descriptions of the PSS®E power flow solution activities. Those
network solution activities used in linear network analysis, equivalent construction, switching
studies, and fault analysis are described in subsequent chapters. Interface references are provided,
with links to the PSS®E GUI Users Guide and the PSS®E Command Line Interface (CLI) Users
Guide, where appropriate.
6.2 Power Flow Solution Methods

PSS®E includes five power flow solution activities, each of which operates on the bus voltage esti-
mates in the working case to attempt to bring them to a solution of Kirchhoff’s laws. Each activity
makes successive adjustments to the bus voltages in accordance with a different iterative scheme.
The iterative schemes are listed in Table 6-1 Available Iteration Schemes in PSS®E along with the
activity names familiar to users of previous versions of PSS®E.
Table 6-1. Available Iteration Schemes in PSS®E
Iterative Scheme Activity Name

Gauss-Seidel SOLV
Modified Gauss-Seidel handles series capacitors MSLV
Full Newton-Raphson FNSL
Decoupled Newton-Raphson NSOL
Fixed-Slope Decoupled Newton-Raphson FDNS
Because power flow convergence properties are dependent upon network and load attributes, each
of the five iteration methods has its own strengths and weaknesses. The most significant strengths
and weaknesses are summarized in Table 6-6 Power Flow Solution Activities—Selection Guide.
6-2
PSS®E 34.2 Power Flow Solution Activity Descriptions
Program Operation Manual Power Flow Solution Methods
Any of these five methods can fail to converge on the solution of some problems. It is rare, however,
to find a problem that has a solution, but the voltage solution vector cannot be found by the appli-
cation of one or more of the five methods. There are many problems that are difficult or impossible
to solve with a single iterative method but which can be solved readily by the successive application
of more than one method.
A general guide to the selection of an iterative method follows:
• The Gauss-Seidel methods are generally tolerant of power system operating condi-
tions involving poor voltage distributions and difficulties with generator reactive power
allocation, but do not converge well in situations where real power transfers are close
to the limits of the system.
• The Newton-Raphson methods are generally tolerant of power system situations in
which there are difficulties in transferring real power, but are prone to failure if there are
difficulties in the allocation of generator reactive power output or if the solution has a
particularly bad voltage magnitude profile.
• The Gauss-Seidel methods are quite tolerant of poor starting voltage estimates, but
converge slowly as the voltage estimate gets close to the true solution.
• The Newton-Raphson methods are prone to failure if given a poor starting voltage esti-
mate, but are usually superior to the Gauss-Seidel methods after the voltage solution
has been brought close to the true solution.
Experimentation is needed to determine the optimum combination of iterative methods for each
particular power system model.
Experience suggests the following as the most advantageous approach to new power flow cases
where the specific characteristics have yet to be learned:
• Initialize all voltages to either unity amplitude, or to scheduled amplitude if given, and
initialize all phase angles to zero. (This step is referred to as a flat start.)
• Execute Gauss-Seidel iterations until the adjustments to the voltage estimates
decrease to, say, 0.01 or 0.005 per unit in both real and imaginary parts.
• Switch to Newton-Raphson iterations until either the problem is converged, or the reac-
tive power output estimates for generators show signs of failure to converge.
• Switch back to Gauss-Seidel iterations if the Newton-Raphson method does not settle
down to a smooth convergence within 8 to 10 iterations.
Experience with each specific problem will suggest modifications to this procedure. In particular, the
initial Gauss-Seidel iterations and flat-start steps will be bypassed when the result of a previous
solution is known to be a close estimate of the expected new solution.
In many power flow cases, the solution can be expedited by using two (or even more) iteration activ-
ities in succession in order to take advantage of the complementary strengths of the various iterative
schemes. For example, if the starting voltage estimate is known to be poor, it is often advantageous
to execute several Gauss-Seidel iterations and to switch over to the Newton-Raphson iterations
after the voltage estimate has been brought into rough approximation to the true solution.
A simple approach is to allow a Gauss-Seidel solution to complete its maximum iterations and then
select a Newton method and continue the solution from the same convergence point. (The starting
voltage estimate for the Newton solution would be the last voltage vector estimated in the preceding
6-3
execution of the Gauss solution.) At any time the solution can be changed back to a Gauss-Seidel
solution or a different Newton method.
If the iterations are slow, it is possible to use the AB interrupt to cancel whichever solution method
is in progress and, subsequently, select a different solution method to continue.
6.2.1 Using Acceleration Factors and Solution Tolerances

The power flow solution activities use the acceleration factors listed in Table 6-2 Power Flow Itera-
tion Acceleration Factors and the convergence tolerance values listed in Table 6-3 Power Flow
Convergence Tolerances. The power flow working case contains an iteration limit used by the
Gauss-Seidel solutions (ITMX), and another (ITMXN) used by the Newton-Raphson solutions. The
default values of these iteration limits are 100 and 20 iterations, respectively.
Table 6-2. Power Flow Iteration Acceleration Factors
Iteration Type Name Default Value Applied To

ACCP 1.6 Real part of voltage change
Gauss-Seidel
ACCQ 1.6 Imaginary part of voltage change
ACCM 1.0 Complex voltage change at Type 1 buses

Modified Gauss-Seidel ACCP 1.6 Real part of voltage change at Type 2 buses
ACCQ 1.6 Imaginary part of voltage change at Type 2 buses
Newton-Raphson ACCN 1.0 Magnitude of voltage change at Type 2 buses only
Table 6-3. Power Flow Convergence Tolerances
Name Used By Default Value Applied To

Gauss-Seidel
TOL 0.0001 per unit Voltage magnitude change convergence tolerance
solutions
Newton-Raphson
TOLN 0.1 MW and Mvar Mismatch convergence tolerance
solutions
Newton-Raphson Controlled bus reactive power mismatch
VCTOLQ 0.1 MW and Mvar
solutions convergence tolerance
Newton-Raphson
VCTOLV 0.00001 per unit Controlled bus voltage error convergence tolerance
solutions
Each of these solution parameters is set to a default value based on general experience each time
PSS®E is started up. The user should be prepared to tune these solution parameters. The conver-
gence properties of the Gauss-Seidel solutions are particularly dependent upon the acceleration of
the voltage adjustment process.
These solution parameters can be changed using the data changing activity CHNG or the [Solution
Parameters] dialog. They are all saved and retrieved with the power flow case.
6-4
6.2.2 Automatic Power Flow Solution Adjustments

Automatic adjustment options may be used in power flow solutions to allow maneuvering of the
system to meet specified voltage, branch flow, and area net interchange schedules. Automatic
adjustments can be enabled or disabled when setting program run-time options (see Section 3.3.3
Program Run-Time Option Settings).
The automatic adjustments available are specified in Table 6-4 Available Automatic Adjustments.
In addition to the options listed in the table, the user has the option to start the power flow solution
from a flat start.
When enabled, an adjustment option is applied throughout the entire power flow case. However, it
is important to recognize that the adjustment of any individual tap-changing transformer, phase
shifter, or area net interchange can be suppressed by editing its adjustment parameters in such a
way that no adjustment can occur. Those parameters are accessible in the spreadsheet.
Table 6-4. Available Automatic Adjustments
Type of Adjustment Normal Default Available In
Adjustment of transformer turns ratio in steps to hold voltage GAUSS

Disabled
at a designated bus in specified band. NEWTON
Direct adjustment of transformer turns ratio to hold voltage at
a designated bus in specified band or to hold reactive power Disabled NEWTON
through transformer within a specified band.
Adjustment of area swing bus generator powers to hold area GAUSS

Disabled
net interchange within a specified band. NEWTON
Adjustment of transformer phase shift to hold real power
Disabled NEWTON
through transformer within a specified band.
Adjustment of converter transformers of dc transmission GAUSS
terminals to place rectifier delay angle and inverter margin Enabled
angle within specified ranges. NEWTON
Adjustment of switched shunt admittances to hold voltage at GAUSS

the bus as close to specified voltage as permitted by induc- Enabled
tance/capacitor module size. NEWTON
Adjusting Transformer Off-Nominal Tap Ratio

Depending on the solution technique chosen, transformer tap ratio adjustments can be made to
control either voltage at a specified bus, a compensated voltage based on the transformer loading
or to control Mvar flow at the tapped side of the transformer (see Table 6-5 Transformer Tap Adjust-
ment Options). Compensated voltage is often used on radial circuits when the user wishes to
remotely regulate a voltage but does not wish to install any communication links. Note that by
controlling voltage using the Newton solution activities, the user may choose one of two adjustment
techniques: discrete or direct tap adjustment. The Mvar control can be performed using direct tap
adjustment only in Newton solutions.
With all solution activities, the request to adjust taps ratio automatically will not be honored until the
voltage change is less than the adjustment threshold (ADJTR), a solution parameter with a default
value of 0.005 per unit. With discrete tap adjustment, tap ratio will then be adjusted to a maximum
of value of tap limit (TAPLIM), a solution parameter with a default value of 0.05 per unit, until toler-
6-5
ance is reached. With direct tap adjustment controlling voltage, tap ratio will be adjusted, as if the
taps are continuous, from the iteration when tolerance is first reached through subsequent iterations
until the tolerance is again reached. At that time, unless the tap ratio is zero, all taps will be set to
the nearest step, locked, and additional iterations made to bring mismatch down to tolerance once
again. Similarly, with direct tap adjustment controlling Mvar, adjustment will not be made until toler-
ance is reached and controlling logic is identical thereafter to that of direct tap adjustment controlling
voltage.
The solution parameters ADJTR and TAPLIM can be changed using the data changing activity
CHNG or the [Solution Parameters] dialog.
Table 6-5. Transformer Tap Adjustment Options
Availability of Availability of Voltage Availability of Mvar

Voltage Control Control Via Direct Tap Control Via Direct Tap
Method Adjustment Adjustment Adjustment
Gauss-Seidel Yes No No*
Modified Gauss-Seidel Yes No No*
Full Newton-Raphson Yes Yes Yes
Decoupled
Yes Yes Yes
Newton-Raphson
Fixed-slope, decoupled
Yes Yes Yes
Newton-Raphson
* Tap is assumed fixed.
Adjusting Transformer Voltage Control

Voltage control by transformer turns ratio adjustments, as described above, will only be made on
transformers having the following conditions: a nonzero regulated bus number, IREG; and a value
of 1 for the transformer enable flag, RF. The tap ratio of each transformer is adjusted to hold a
voltage magnitude between the limits VMIN to VMAX. The voltage magnitude to be controlled is
calculated as follows:
Vc = VIREG - Itransformer (CR + jCX)

where:
CR + jCX = Compensating impedances entered by the user.

Itransformer = Current in the transformer calculated on the IREG side of the transformer.
The recommended method for suppressing ratio adjustment is to set the transformer control flag to
zero. Ratio adjustment may also be suppressed by setting IREG to 0.
The tap-step ratio should be properly coordinated with the acceptable voltage band (VMAX-VMIN)
because the discrete steps of available tap ratio are recognized. The default tap-step ratio is
0.00625 per unit (0.625%). The band between VMAX and VMIN should normally be twice the
transformer tap-step. A band of 2% is recommended for the normal case of 0.625% tap ratio steps.
A value of 0 for tap-step should only be used to indicate continuously adjustable taps to the direct
tap adjustment algorithm.
6-6
Adjusting Transformer Mvar

The tap ratio is adjusted to hold the Mvar on the tap side of the transformer between the limits VMIN-
VMAX. As mentioned previously for voltage-controlling transformers, the user should coordinate
tap-step and available range for Mvar-controlling transformers.
Adjusting Transformer Phase Shift Angle

The phase-shift angle of each phase shifter is adjusted, as necessary, to keep the real power flow
through the phase shifter between the limits VMAX and VMIN.
Phase-shift adjustment is continuous and all adjustable phase shifters are adjusted simultaneously
whenever the regulated real power flow of at least one of them falls outside its scheduled band. An
unduly narrow band can cause non convergence of the power flow solution. A reasonable band is
 5 MW of the target flow.
Adjusting Transformer Direct Current (DC) Converter Taps

The control logic adjusts the converter transformer tap positions to attempt to hold the bridge firing
angles above minimum values and below maximum. The minimum values of the firing angles, min
and min, are firm limits; the bridges will not be operated in power flow solutions with firing angles
below these values. The maximum values of the firing angles, max and max, are objectives, but not
firm limits; the converters may be operated in power flow solutions with firing angles above these limits
if the converter transformer tap positions are at the ends of their ranges or if the desired angle ranges
are narrow relative to the tap steps.
Converter taps are adjusted only until the corresponding bridge firing angles are between their
specified maximum and minimum values; taps are not adjusted to minimize firing angles when they
fall between their corresponding maxima and minima. Accordingly, the ranges of the bridge firing
should be treated as the optimum bands for the various converters, with recognition that operation
at a firing angle above the specified maximum value may be necessary for some combinations of
scheduled dc power, dc voltage, and ac system conditions.
The ac solution options can be modified such that the adjustment of converter transformer ratios
are disabled. This disabling applies to all dc transmission lines. Selective locking of dc converter
transformer taps requires that their adjustment not be disabled via the ac solution options. The tap
ratio of any individual converter transformer can be locked by using the program’s data editing func-
tions to set the dc converter tap limits and tap ratio equal to the desired value.
Adjusting Net Interchange

Each area of the power system may have one of its generators designated as an area-slack
machine. Net interchange adjustment is implemented by manipulating the real power output of all
area slack machines except those in areas containing system swing (Type 3) buses. Area slack
machine adjustment may be suppressed for any individual area by setting the area slack bus
number in the area interchange data category to 0. Area slack adjustment is continuous, but takes
place only if the area net interchange falls outside the band for at least one area: (Scheduled inter-
change  Interchange tolerance). An unduly small interchange tolerance can cause non
convergence of the power flow solution.
The net interchange tolerance should be related to system interchange capability and system
impedances. A typical tolerance for a large electric utility with capability for a 500 MW net inter-
change might be 10 MW, while an industrial plant with a maximum net interchange capability of 15
MW might be assigned a tolerance of 0.5 MW. The tolerance should be set in relation to interchange
capability and remain fixed as the interchange schedule is varied.
6-7
Adjusting Switched Shunt Admittance

Automatically switched shunt devices are normally adjusted according to the rules given in
Section 6.3.15 Switched Shunt Devices. When this adjustment option is enabled, either all adjust-
able switched shunts (i.e., the switched shunt is in-service and its control mode, MODSW, is not 0)
are subject to adjustment, or only continuous mode switched shunts (i.e., MODSW is 1) are subject
to adjustment. This adjustment is normally enabled in all power flow solutions. It can be suppressed,
regardless of the values of MODSW in the Solution Options. Selective locking of automatically
switched shunt devices must be handled by leaving the adjustment feature enabled in the power
flow solution and setting MODSW to 0 at buses where locking is required.
6-8
Table 6-6. Power Flow Solution Activities—Selection Guide
6-9
Iteration
Method/
Old Activity
name Advantages Disadvantages Use When Do Not Use When Convergence Monitor
Intolerant of data errors.
Cannot start from poor
voltage estimates.
Power Flow Solution Methods
Newton-
Rapid convergence Cannot handle network with
Raphson
on well-conditioned low X/R ratio branches (e.g., Network contains branches
method with Poor voltage esti-
cases. equivalents). with low X/R ratios.
real and reac- mate and network
No indication of cause of As for Full Newton-Raphson.
tive power Small bus contains negative Overloading has produced
Power Flow Solution Activity Descriptions
equations mismatches can be problem when failing to reactive branch. reactive power problems.
decoupled achieved. converge.
(NSOL) Can give problems
converging cases where
6-10
reactive power limits are
restrictive.
As mismatches are reduced,
Newton- rate of improvement may be
Raphson allowed.
method with Rapid convergence
real and reac- on well-conditioned
tive power cases. No indication of cause of Overloading has produced
problem when failing to As for Full Newton-Raphson.
equations Small bus reactive power problems.
decoupled converge.
mismatches can be
using a fixed achieved. Can give problems
Jacobian matrix converging cases where
(FDNS) reactive power limits are
restrictive.
PSS®E 34.2
Iteration
PSS®E 34.2
Method/
Old Activity
name Advantages Disadvantages Use When Do Not Use When Convergence Monitor
Cannot start from poor
voltage estimates.
Newton-
Rapid convergence Cannot handle network with
Raphson
on well-conditioned low X/R ratio branches (e.g., Network contains branches
method with Poor voltage esti-
cases. equivalents). with low X/R ratios.
real and reac- mate and network
No indication of cause of As for Full Newton-Raphson.
tive power Small bus contains negative Overloading has produced
equations mismatches can be problem when failing to reactive branch. reactive power problems.
decoupled achieved. converge.
(NSOL) Can give problems
converging cases where
6-11
reactive power limits are
restrictive.
As mismatches are reduced,
Newton- rate of improvement may be
Raphson allowed.
method with Rapid convergence
real and reac- on well-conditioned
tive power cases. No indication of cause of Overloading has produced
problem when failing to As for Full Newton-Raphson.
equations Small bus reactive power problems.
decoupled converge.
mismatches can be
using a fixed achieved. Can give problems
Jacobian matrix converging cases where
(FDNS) reactive power limits are
restrictive.
Power Flow Solution Methods
Applying Gauss-Seidel Power Flow Solution Program Operation Manual
6.3 Applying Gauss-Seidel Power Flow Solution

Activity SOLV
Run Activity SOLV - GUI

Power Flow > Solution > Solve (NSOL/FNSL/FDNS/SOLV/MSLV)…
[Loadflow solutions]
Gauss Tab OPTION: Gauss-Seidel
Run Line Mode Activity SOLV - CLI
ACTIVITY?
>>SOLV
AB, NC, NM, DC, FD,MO
6.3.1 About Power Flow Iterative Solution Algorithms

The power flow problem is nonlinear and requires an iterative trial and error process for its solution.
One simple but effective iterative scheme follows:
1. Make an initial estimate of the voltage at each bus.
2. Build an estimated current inflow vector, In, at each bus from a boundary condition such as:
Pk + jQk = vkik* (6.2)
where:
Pk + jQk = Net load and generation demand at bus k.
vk = Present estimate of voltage at bus k.
3. Use Equation 6.1 to obtain a new estimate of the bus voltage vector, vn.
4. Return to Step 2 and repeat the cycle until it converges on an unchanging estimate of vn.
While this scheme is useful in some specific situations (to be discussed later), it does not work well
for the general power flow calculation where the terminal voltage magnitude, rather than reactive
power output, is specified for many generators.
6-12
Program Operation Manual Applying Gauss-Seidel Power Flow Solution
6.3.2 About Power Flow Boundary Conditions

Steps 2 and 3 of the iterative scheme in Section 6.3.2 About Power Flow Boundary Conditions refer
to two aspects of the power flow solution calculation. The solution of the power flow problem is a
set of bus (or node) voltages that simultaneously satisfy the network condition, In = Ynnvn, derived
from Kirchhoff’s laws, and the boundary conditions derived from load and generator characteristics,
such as Pk + jQk = vkik*.
The network condition (Equation 6.1) is linear and can be solved without iteration if either the
voltage vector, vn, or the current vector, In, is specified. The solution is a direct calculation if vn is
specified, and requires a standard computer procedure for solving linear simultaneous equations if
In is given.
The boundary conditions may be specified quite arbitrarily, depending upon the loads that electricity
users choose to connect to the network, and are usually nonlinear. It is the nonlinearity of the
boundary conditions that forces the use of an iterative procedure for power flow solution. It must be
noted though, that while the network condition can be handled in a non iterative, closed-form
manner, it is often advantageous to use an iterative method to solve both the network condition and
the boundary conditions.
In the commonly used power flow iteration procedures:
• Gauss-Seidel methods solve both network and boundary conditions by iteration.

• Newton-Raphson methods solve the network condition by closed-form calculation,
while using iteration to solve the boundary conditions.
6-13
6.3.3 Boundary Conditions of Constant MVA Loads

The most common load boundary condition is a specification of load real and/or reactive power
consumption
Real (vkik*) = -Pk (6.3)
Imag (vkik*) = -Qk (6.4)
This characteristic is not realistic for voltages below approximately 0.8 per unit. All PSS®E power
flow voltage solutions, in both power flow and dynamic simulation, therefore, modify Equation 6.3
and Equation 6.4 to make Pk and Qk functions of the magnitude of the bus voltage as shown in
Figure 6-1.
Figure 6-1. Constant MVA Load Characteristic (Top) and Resultant Form of
Current/Voltage Curve (Bottom)
The constant power characteristic holds the load power constant as long as the bus voltage
exceeds the value specified by the solution parameter PQBRAK, and assumes an elliptical current-
voltage characteristic of the corresponding load current for voltages below this threshold.
The user may modify the value of PQBRAK using the data changing activity CHNG or the [Solution
Parameters] dialog.
6-14
Figure 6-2. Constant Power Load Characteristic
6-15
6.3.4 Boundary Conditions of Constant Current Loads

Load may be specified as a given active or reactive component of current such that:
Real (vkik* )
= - Ipk
|vk|
(6.5)
Imag (vkik* )
= - Iqk
|vk|
(6.6)
Again, because this characteristic is unrealistic for voltages below about 0.5 per unit, all PSS®E
power flow solutions modify (Equation 6.5 and Equation 6.6) to make Ipk and Iqk functions of the
magnitude of vk, as shown in Figure 6-3.
Figure 6-3. Constant Current Load Characteristic (Top) and Resultant Form
of Load MVA/Voltage Curve (Bottom)
6-16
6.3.5 Boundary Conditions of Constant Impedance Loads

Finally, load may be specified by given real and reactive parts of shunt admittance such that
ik Pk - jQk Pk - jQk Pk Qk
= Gk + jBk = = = -j
vk vkvk* |vk|2 |vk|2 |vk|2
(6.7)
Note that Equation 6.7 is not treated as a boundary condition in the solution process; it can be more
convenient to incorporate this type of load as a bus shunt branch unless there is a need, at some
time, to convert this load to another type.
6.3.6 Boundary Conditions of Composite Loads

All PSS®E network solutions allow the load at each bus to be a composite of arbitrary amounts of
load with each of the characteristics described in the previous subsections. The composite charac-
teristic becomes the boundary condition used in iterative power flow solutions.
The normal practice is to specify the load at each bus initially as a compendium of constant MVA
and constant admittance loads. Subsequently the data can be adjusted to comprise the required
amounts of each characteristic. This course gives compatibility with external power flow data
formats such as the IEEE Common Format. Conversion and construction of load data is facilitated
by activity CONL.
6.3.7 Boundary Conditions of the Swing Bus

Every power flow simulation case must have at least one bus designated as a swing bus. The corre-
sponding boundary condition is:
vk(complex) = constant (6.8)
The net real and reactive power inflow to a swing bus are free variables and follow from the power
flow solution, rather than being boundary conditions imposed upon it.
Power flow solution cases must have at least one swing bus in every separate section (island) of
the network. An ac island is defined as the set of all in-service buses such that each bus in the island
may be reached from every other bus in the island through the in-service ac network. If a working
case contains more than one island, any island is either electrically disjoint from all other islands,
or connected to one or more islands by one or more asynchronous ties (e.g., dc lines).
To be a valid power flow case, each ac island in the working case must contain at least one Type 3
(swing) bus. Furthermore, the buses connected by each in-service branch must be in-service (i.e.,
none of them may be Type 4 buses). No swing bus is needed in fault analysis, switching, and
dynamic simulation calculations, although swing buses may be used in these simulations.
When enabled, the solution connectivity checking option checks for the presence of swingless
islands at the start of each power flow solution (activity OPTN).
The user can check that every subsystem of a power system power flow case includes a swing bus
using activity TREE.
6-17
6.3.8 Boundary Conditions of Standard Generators

The standard generator arrangement used throughout PSS®E is shown in Figure 6-4. The gener-
ator is assumed to be connected to bus k by a step-up transformer where per unit impedance is Zt,
(Rt + TXt), on generator MVAbase. The transformer impedance may be set to zero to model a gener-
ator connected directly to the bus such that bus k is the generator terminal bus.
Bus k
•
t :1 Z
g t
Generator Step-up Generator

High-Voltage Transformer
Bus
Figure 6-4. Standard PSS®E Generator Configuration
The standard generator boundary condition is a specification of real power output at the high
voltage bus, bus k, and of voltage magnitude at some designated bus, not necessarily bus k.
Real (vkik*) = Pk (6.9)
V1 = Vsched (6.10)
This characteristic is subject to the following reactive power output limitations:
Qmn k  Imag(vkik*)  Qmx k (6.11)
which overrides the voltage schedule condition (Equation 6.10).
It is important to recognize that the maximum and minimum reactive power limits assigned to bus k
apply to generator reactive power output measured at the high-voltage bus and not at the generator
terminals. Determination of Qmin k and Qmax k must, therefore, recognize the reactive power loss
in the step-up transformer reactance. A reasonable assumption for assigning reactive power limits
to bus k, in this situation, is to subtract a reactive loss corresponding to full load current (1.0 pu)
from the generator terminal reactive power limits.
Because Zt has a per-unit value with respect to generator MVA base and Qmin k, Qmax k are in
megavars,
Qlimit k = Qlimit g - Xt × MBASE (6.12)
for lagging generator terminal power factor, and
Qlimit k = Qlimit g + Xt × MBASE (6.13)
6-18
for leading generator terminal power factor, where:
Xt = Step-up transformer reactance in per unit on generator base.

Qlimit g = Limiting reactive power in Mvar at generator terminals.
Qlimit k = Qmin k or Qmax k.
6.3.9 Boundary Conditions of Multiple Identical Generators

Multiple, identical generators and generator step-up transformer units may be represented by the
standard model, as shown in Figure 6-4, by specifying the generator MVA base to be the total MVA
rating of all connected generators and specifying Zt as the impedance of a single step-up trans-
former on its own single generator rating. This representation is illustrated in Figure 6-5.
Unit 1 R MVA
t :1 Z
t
Unit 2 R MVA
t :1 Z
t
Unit n R MVA
t :1 Z
t
nR
Z MVA
t :1 t
Figure 6-5. Identical Generators at Bus
Lumping several identical generators may, for example, be used where startup and shutdown of
individual units in a plant are scheduled to meet increasing and decreasing plant loading. This is
achieved by adjusting Pgen, Qmax k, Qmin k, and MBASEk. No adjustment of Zt or of the network
branch data is necessary.
Use of this lump approach to handle multiple units implies that real and reactive power output are
distributed uniformly between them. If loadings of multiple units are not identical, they must be
treated as different generators even though their impedances and other characteristics are iden-
tical. This offers the advantage of having to change only unit status flags to account for a change in
the number of operating units at the plant.
6.3.10 Boundary Conditions of Multiple Non-Identical Generators

A plant having several different generators connected to its high voltage bus cannot be represented
by a single generator model. Correct representation of such plants requires the use of multiple, indi-
vidual generator models at the plant bus.
6-19
6.3.11 Operation of Activity SOLV

The power flow solution activity SOLV uses a Gauss-Seidel iterative algorithm to solve for the bus
voltages needed to satisfy the bus boundary conditions contained in the working case.
A quick note of value is that the Gauss-Seidel solution cannot handle negative series reac-
tances (series capacitors) but the Newton and Modified Gauss-Seidel can.
Activity SOLV first does a quick check for valid network topology. In this check, it looks at all series
elements (ac branches, dc lines, and FACTS devices with a series element) connected to each bus,
and reports the following errors:
• any type 4 (out-of-service) bus with one or more in-service series elements connected
to it.
• any in-service bus with no in-service series elements connected to it.
If any topological errors are detected, activity SOLV terminates without attempting its power flow
solution calculation.
If the power flow solution network connectivity checking option is enabled (refer to Section 3.3.3
Program Run-Time Option Settings), activity SOLV checks that each non-Type 4 bus is connected
back to a Type 3 (swing) bus through the in-service ac network. If any violations are detected, an
appropriate message is printed and activity SOLV is terminated.
When the Flat start solution option is selected, all bus voltages are set to a magnitude of 1.0 at a
phase angle of 0.0 degrees. Then, at each type 3 (system swing) bus, the voltage magnitude is set
to the scheduled voltage specified in the plant data for the bus; any bus which is connected to a
type 3 bus by an in-service zero impedance line has its complex voltage set to that of the swing bus
to which it is connected.
When the Flat start solution option is not selected, the present voltage profile is used as the starting
point for the power flow solution. This is the usual case when changes and/or additions have been
imposed on a “solved” power flow case.
However, when buses are added to a solved case with default values applied for voltage magnitude
(1.0) and phase angle (0.0), and they are connected to one or more buses whose “solved” voltage
values differ substantially from the default values, extremely large mismatches are possible on the
first and subsequent iterations. It is possible that these differences are so large that they are “too
far away from” the solved voltage profile for the case and the solution attempt can “blow up”.
To attempt to overcome such solution failure, activity SOLV looks for “flat” buses (i.e., in-service
buses with default voltage and phase angle values), and “boundary” buses (i.e., in-service buses
with voltage and/or phase angle values that differ from the default values). Prior to the first iteration,
it adjusts complex voltages at “flat” buses as follows:
1. For one “flat” bus radially connected to one “boundary” bus, the complex voltage at the “flat”
bus is set to that of the “boundary” bus. If a transformer connects the two buses, the tap
settings and phase shift angle of the transformer are considered in setting the voltage at the
“flat” bus.
2. For one “flat” bus connected to two or more “boundary” buses, voltages as calculated in 1.
are determined for each of the “boundary” buses, and the complex voltage at the “flat” bus
is set to the average of these voltages.
6-20
3. For an arbitrary sub-network of two through ten “flat” buses connected to a single “boundary”
bus, the following procedure is used:
a. The number of “flat” buses in this sub-network connected directly to the “boundary”
bus is determined.
b. If more than one “flat” bus in this sub-network is connected to the “boundary” bus,
the complex voltages of all buses in the “flat” sub-network are set to the complex
voltage of the “boundary” bus, and processing of the sub-network is terminated.
c. If exactly one “flat” bus in this sub-network is connected to the “boundary” bus, the
voltage at the “flat” bus is set as in 1. above. This former “flat” bus is removed from
the sub-network, and becomes the “boundary” bus of the reduced sub-network. If
any “flat” buses remain in the reduced sub-network, go back to step a. and repeat
for the reduced sub-network.
4. For all other sub-networks of “flat” buses connected to multiple “boundary” buses, the volt-
ages are left at their “flat” values.
At the completion of each iteration, activity SOLV prints a convergence monitor, which tabulates:
1. The iteration number.
2. The largest voltage magnitude change as a multiple of the convergence tolerance.
3. The number, name and base voltage of the bus experiencing the largest voltage change;
alternatively, if the bus is the star point bus of a three-winding transformer, the transformer
name followed by  BUS is printed.
4. The real part of the largest voltage change.
5. The imaginary part of the largest voltage change.
At the end of activity SOLV, the largest bus mismatch is tabulated, along with the system total MVA
mismatch and a summary of swing (Type 3) bus power outputs. An asterisk (  ) following a plant’s
active or reactive power output in the swing bus summary indicates that the power output is beyond
its limits.
If area interchange adjustment was enabled, each area that has at least one in-service tie element
connected to it and which has an area swing assigned to it, but fails to meet is net interchange spec-
ification, is logged.
If the case has not converged, the user can modify the solution parameters (refer to Section 6.3.19
Characteristics of Activity SOLV) and solution type, if warranted, and re-run the solution. If the solu-
tion had diverged (blown up), the Flat start control option should be used to establish a feasible
starting point for the next solution.
Activity SOLV responds to the following interrupt control codes:
AB Abandon activity SOLV following completion of the next iteration.

NC Suppress the convergence monitor.
NM Suppress any automatic adjustment monitors.
6-21
DC Tabulate the conditions for each in-service dc line after each iteration. The data
printed for each noncapacitor commutated two-terminal dc line includes the dc line
name followed by two lines including the following quantities:
IPR IPI ALPHA GAMMA VDCR VDCI TAPR TAPI DCCUR PACR QACR PACI
QACI
The information printed for each capacitor commutated two-terminal dc line includes
the dc line name, followed by an iteration report of the Newton solution performed for
one or more operating modes, followed by:
ALPHA_R MU_R VDC_R(kV) TAP_R PAC_R QAC_R DC_CURRENT
GAMA_I MU_I VDC_I(kV) TAP_I PAC_I QAC_I ALPHA_I
For multi-terminal lines, the dc line name is followed by conditions at each converter
bus:
bus # ANGLE TAP VDC DCCUR PAC QAC

For VSC dc lines with both converters in-service, the dc line name is followed by line
and converter bus conditions as follows:
dc voltages at the power and voltage controlling converters and dc current

if a limit violation is relieved at this iteration, the converter bus at which it occurs, the
present ac injections at that bus, and the reduced values are tabulated, followed by
the new dc voltages and the dc current
dc power, converter losses, and ac power at the power controlling converter

dc line losses
dc power, converter losses, and ac power at the voltage controlling converter
For VSC dc lines with only one converter in-service, the dc line name is followed by
the dc power, converter losses, and ac power at the in-service converter.
FD Tabulate the conditions for each in-service FACTS device after each iteration. The
data printed for each FACTS device includes conditions at the sending and terminal
buses, series voltage and current in polar coordinates, series voltage with respect to
both series current and sending end voltage in rectangular coordinates, and an indi-
cation of those quantities currently at a limit.
MO Tabulate the conditions for each in-service induction machine after each iteration.
The data printed for each induction machine includes the bus number and machine
identifier, the voltage magnitude at the bus, the voltage error in the induction machine
iteration, slip, mechanical torque, mechanical power, the magnitude of the voltage
across the mutual reactance, the mutual inductance saturation multiplier ALFAXM,
the magnitude of armature current, the armature reactance saturation multiplier
ALFAXA, the partial derivative of mechanical output power with respect to slip, the
partial derivative of mechanical output power with respect to terminal voltage, the
partial derivative of mechanical load with respect to slip, and the apparent active and
reactive power flowing into the induction machine at the ac bus.
6-22
6.3.12 Generation
During the solution, generator buses are treated as follows:
1. Those generators that regulate their own voltage hold their scheduled voltage as long as
their reactive power limits are not violated.
2. Those generators that regulate the voltage of a remote type 1 or 2 bus have their reactive
power output adjusted as required to hold the desired voltage at the remote bus as long as
their reactive power limits are not violated.
3. Those generators that are swing buses (i.e., with a type code of 3) are held at constant
voltage and phase angle. Their active and reactive power outputs are set as required prior
to leaving activity SOLV. The plant active power is shared among the machines at the plant
in proportion to the magnitudes of their active power settings at the time activity SOLV was
initiated; if all machines have an active power setting of 0.0 at the time activity SOLV is
selected, the plant active power is shared in proportion to the MBASEs of the machines at
the plant. For such buses with both generators and synchronous condensers, only the
generators share the swing bus active power output.
4. At the end of activity SOLV, generator plant reactive powers (and active powers for Type 3
buses) are apportioned among the machines at the plant; reactive powers are split so as to
achieve identical power factors at all machines in a plant, except that machine reactive
power limits are honored.
6.3.13 Load
Busbar load data is entered into PSS®E in activities READ, TREA, and RDCH (refer to Load Data)
on the basis of the following power flow load characteristics for both the active and reactive compo-
nents of load: constant MVA, constant current, and constant admittance.
Loads may be apportioned among these three characteristics by activities CONL and RCNL.
The constant power characteristic holds the load power constant as long as the bus voltage
exceeds the value specified by the solution parameter PQBRAK, and assumes an elliptical current-
voltage characteristic of the corresponding load current for voltages below this threshold. Figure 6-
6 depicts this characteristic for PQBRAK values of 0.6, 0.7, and 0.8 pu. The user may modify the
value of PQBRAK with the data changing activity CHNG or the [Solution Parameters] dialog.
The constant current characteristic holds the load current constant as long as the bus voltage
exceeds 0.5 pu, and assumes an elliptical current-voltage characteristic as shown in Figure 6-7 for
voltages below 0.5 pu.
6-23
1.1
1.0
0.0
0.0 0.6 0.7 0.8 1.0 1.1
Voltage
Figure 6-6. Constant Power Load Characteristic

1.1
Current
1.0
Power
0.5
0.0
0.0 0.5 1.0 1.1

Voltage
Figure 6-7. Constant Current Load Characteristic
6-24
6.3.14 Induction Machines

Buses for which data for one or more induction machines has been specified in activities READ,
Section Activity, TREA, or RDCH (refer to Induction Machine Data) are handled according to the
following rules:
1. In-service induction machines at type 1, 2 and 3 buses are modeled during power flow
solutions.
2. On an iteration in which a solution for a machine cannot be achieved due to load terminal
voltage, the state of the induction machine is changed as follows:
• If the machine is a motor (i.e., PSET is positive), the machine is treated as "stalled"; it
is represented by its locked rotor impedance. In calculating the locked rotor impedance,
it is assumed that Xa is fully saturated and that saturation of Xm is negligible
• If the machine is a generator (i.e., PSET is negative), the machine is treated as
"tripped".
3. At each power flow iteration, a complete solution of each in-service machine is performed.
Thus, solutions for machines that were placed in the "stalled" and "tripped" states during the
previous iteration are again attempted.
4. For each induction machine, the solution keeps count of the number of iterations in which a
machine is placed in the "stalled" or "tripped" state. If, during a single power flow solution, a
machine experiences more than MXSWIM switchings from the "running" state to the
"stalled" or "tripped" state, it remains in the "stalled" or "tripped" state for the remainder of
the current power flow solution.
6.3.15 Switched Shunt Devices

Buses for which switched shunt data has been specified in activities READ, TREA, or RDCH (refer
to Switched Shunt Data) are handled according to the following rules:
1. Automatically switched shunts are permitted only at type 1 and 2 buses. At type 3 (swing)
buses, switched shunts are treated as locked at the value specified as BINIT in activities
READ, TREA, or RDCH (refer to Switched Shunt Data), or as subsequently modified with
activity CHNG or the [Spreadsheet].
2. For those switched shunts designated as locked (i.e., MODSW = 0 or the bus is a type 3
bus), the specified admittance is held constant during the solution.
3. Those switched shunts controlling local or remote bus voltage to a voltage setpoint
(i.e., VSWHI = VSWLO) are handled as follows:
a. Those switched shunts designated as continuous (i.e., MODSW = 2) hold their

scheduled voltage as long as the admittance limits are not violated. The high admit-
tance limit is the admittance when all reactor blocks are switched off and all
capacitor blocks are switched on; the low limit represents all reactor blocks
switched on and all capacitor blocks are switched off. (Note that for reactors, BL<0
and for shunt capacitors, BC>0).
b. Switched shunt devices designated as operating in discrete mode (i.e.,
MODSW = 1) are initially treated as the continuously operating devices described
above. When the network solution convergence tolerance is reached, the dis-
6-25
cretely operating shunts are set to the nearest discrete step. The network solution
iteration then continues with the switched shunts held constant.
4. Switched shunts controlling local or remote bus voltage to a voltage band (i.e.,
VSWHI > VSWLO) must be designated as operating in discrete mode. Such devices are
moved in single steps between network solution iterations (refer to Switched Shunt
Adjustment).
5. Continuous mode control to a voltage band is not allowed. Such devices generate an alarm
and are treated as controlling to a voltage setpoint (taken as the midpoint of the specified
voltage band) in continuous mode as described in (3a) above.
6. Those switched shunts controlling other voltage controlling devices check the reactive
power output of the controlled device against the more restrictive limits described in
Switched Shunt Data. If the reactive power is outside of these limits, the switched shunt
admittance is raised or lowered so as to bring the reactive output of the controlled device
toward the nearer of the more restrictive limits. Assuming the input order adjustment method
in the example in Switched Shunt Data, if the output of the controlled voltage controlling
device exceeds 25 Mvar, the reactive output of the switched shunt will be increased: if the
switched shunt has inductors switched on, one step of inductors will be switched off; other-
wise one step of capacitors will be switched on.
An adjustment monitor is printed at the Progress tab any time a stepwise adjustment as in (4) and
(6) above, or the setting to the nearest discrete step as in (3b) above, occurs.
When activity SOLV is run on a system that had previously been solved by one of the PSS®E
network solution activities, the presence of discretely operating switched shunts as described in
(3b) above may result in more than one network solution iteration being required. Although the
network was expected to be in balance, significant voltage changes may initially be imposed as
these devices are (temporarily) switched to the continuous mode. This may be overcome by locking
the discrete mode switched shunts at their present settings (refer to Section 6.3.20 Automatic
Adjustments and Switched Shunt Adjustment).
6.3.16 FACTS Devices

PSS®E’s FACTS device model (refer to FACTS Device Data and Figure 5-15) contains a shunt
element that is connected between the sending bus and ground, and a series element connected
between the sending and terminal buses. A unified power flow controller (UPFC) has both the series
and shunt elements active, and allows for the exchange of active power between the two elements
(i.e., TRMX is positive). A static series synchronous condenser (SSSC) is modeled by setting both
the maximum shunt current limit (SHMX) and the maximum bridge active power transfer limit
(TRMX) to zero (i.e., the shunt element is disabled). An interline power flow controller (IPFC) is
modeled with a pair of series FACTS devices; the shunt current limits (SHMX) of both devices are
set to zero, TRMX of the master device is set to the maximum active power transfer between the
two devices, and TRMX of the slave device is set to zero. A static synchronous condenser
(STATCON) or static compensator (STATCOM) is modeled by a FACTS device for which the
terminal bus is specified as zero (i.e., no series element is present).
For an in-service FACTS device to be modeled during power flow solutions, it must satisfy the
following conditions:
1. The sending bus must be either a type 1 or type 2 bus.
2. The sending bus must not be connected by a zero impedance line to type 3 bus.
6-26
3. If it is specified, the terminal bus must be a Type 1 bus with exactly one in-service ac branch
connected to it; this branch must not be a zero impedance line and it must not be in parallel
with the FACTS device.
4. If it is specified, the terminal bus must not have a switched shunt connected to it.
5. If it is specified, the terminal bus must not be a converter bus of a dc line.
6. A bus that is specified as the terminal bus of an in-service FACTS device may have no other
in-service FACTS device connected to it. However, multiple FACTS device sending ends on
the same bus are permitted.
7. A bus that is specified as the terminal bus of an in-service FACTS device may not have its
voltage controlled by any remote generating plant, switched shunt, or VSC dc line converter.
The FACTS device model is called at the start of each iteration to set the boundary conditions to be
imposed upon the ac network at the sending and terminal buses during that iteration.
The shunt element at the sending bus is used to hold the voltage magnitude at either the sending
bus or the specified remote bus to VSET, subject to the sending shunt current limit SHMX. This is
handled in power flow solutions in a manner similar to that of synchronous condensers and contin-
uous switched shunts. In terms of the boundary conditions they impose at the buses to which they
are connected, these three devices differ only in their representation of limits: synchronous
condensers have Mvar limits; switched shunts have admittance limits; and the shunt elements of
FACTS devices have current limits. Current in the shunt-connected bridge is determined by both
the shunt Mvar output and the amount of active power transferred between the shunt and the series
elements. If the current limit is violated, sending end voltage control is abandoned and the magni-
tude of the shunt Mvar output is reduced.
The series element may be set to operate in one of eight modes as described in the following
sections.
Normal Mode
The normal operating mode of the series element is enabled by setting the control mode of the
FACTS device to 1 (refer to FACTS Device Data). In unconstrained operation, the series element
is used to maintain the desired active (PDES) and reactive (QDES) power flow between the sending
and terminal buses. If the series current limit (IMX) is violated, the magnitude of the desired reactive
power flow is reduced; if reducing the desired reactive power flow to zero still results in a series
current limit violation, the magnitude of the desired active power flow is reduced as required. With
desired power setpoints established (either as specified or as reduced due to a series current limit
violation), the bus boundary conditions, which are to be presented to the power flow solution, are
determined.
Limits on three quantities may prohibit the series element from maintaining power flow at the estab-
lished active and/or reactive power setpoints: the series voltage magnitude (maximum of VSMX);
the terminal bus voltage magnitude (maximum of VTMX and minimum of VTMN); and the magni-
tude of the active power transfer between the shunt and series-connected bridges (maximum of
TRMX). These limits result in seven possible states of the model:
6-27
1. Series voltage, terminal bus voltage, and bridge active power transfer are all within their
limits and are therefore treated as dependent variables. Active and reactive power flows
meet their established setpoints.
2. Series voltage is held at VSMX; terminal bus voltage and bridge active power transfer are
both dependent variables. If possible, active power flow is maintained at its established
setpoint and reactive power flow control is abandoned; otherwise, active power flow control
is abandoned and the model attempts to hold reactive power flow at its established setpoint.
3. Terminal bus voltage magnitude is held at either VTMX or VTMN; series voltage and bridge
active power transfer are both dependent variables. Reactive power flow control is aban-
doned and active power flow is maintained at its established setpoint.
4. Bridge active power transfer is held at either TRMX or -TRMX; series voltage and terminal
bus voltage are both dependent variables. Reactive power flow control is abandoned and
active power flow is maintained at its established setpoint.
5. Series voltage is held at VSMX and terminal bus voltage magnitude is held at either VTMX
or VTMN; bridge active power transfer is a dependent variable. Both active and reactive
power flow control are abandoned.
6. Series voltage is held at VSMX and bridge active power transfer is held at either TRMX or -
TRMX; terminal bus voltage is a dependent variable. Both active and reactive power flow
control are abandoned.
7. Terminal bus voltage magnitude is held at either VTMX or VTMN and bridge active power
transfer is held at either TRMX or -TRMX; series voltage is a dependent variable. Both active
and reactive power flow control are abandoned.
Generally, the model remains in its current state until network convergence is achieved. Then model
quantities are checked to determine if a change in model state is required (i.e., if a limited quantity
can be made a dependent variable, or if a dependent variable violates its limit). If a change of model
state is applied, the power flow solution continues until convergence is again achieved, and then
the model is again tested for a change of state.
The PSS®E FACTS model will not attempt to solve for the state in which all three of the above quan-
tities are simultaneously held at a limit. Such a state defines an over-constrained problem. In such
a system condition, the FACTS model will usually cycle among model states (5) through (7) above.
It is the user’s responsibility to decide which of the three limits is to be relaxed, and then make the
appropriate data change.
Bypassed Mode
The bypassed operating mode of the series element is enabled by setting the control mode of the
FACTS device to 2 (refer to FACTS Device Data). In this mode, the series element is solved to a
series voltage magnitude of zero. No limits are enforced other than SHMX, the maximum shunt
current at the sending bus. The solution is identical to that which would be obtained by replacing
the series element with a zero impedance line.
6-28
Constant Series Impedance Mode

The constant series impedance operating mode of the series element is enabled by setting the
control mode of the FACTS device to 3 (refer to FACTS Device Data). In this mode, the series
element is modeled with a fixed series impedance specified on system base. No limits are enforced
other than SHMX, the maximum shunt current at the sending bus.
Constant Series Voltage Mode

The constant series voltage operating mode of the series element is enabled by setting the control
mode of the FACTS device to 4 (refer to FACTS Device Data). In this mode, the series element is
solved to a specified complex series voltage expressed relative to the value indicated by VSREF
(i.e., relative to either sending end voltage or series current). No limits are enforced other than
SHMX, the maximum shunt current at the sending bus.
IPFC Master and Slave Modes

An Interline Power Flow Controller (IPFC) may be modeled using two series FACTS devices. One
device of this pair must be assigned as the IPFC master device by setting its FACTS device control
mode to 5 or 7; the other must be assigned as its companion IPFC slave device by setting its control
mode to 6 or 8 and specifying the name of the master device in its MNAME (refer to FACTS Device
Data).
In the IPFC model, both devices have a series element but no shunt element. The master device is
solved in the same manner as a series device in Normal Mode when the control mode is 5 or in
Constant Series Voltage Mode when the control mode is 7, except that the active power transfer is
exchanged with the series element of the slave device. The slave device is always solved with its
bridge active power transfer fixed as dictated by the master device; that is, when its control mode
is 6, it is always in one of solution states 4, 6, or 7. When its control mode is 8, the specified value
of series voltage is modified to reflect the active power exchange dictated by the master.
In control mode 8 when VSREF is 1 (i.e., desired series voltage is specified relative to series
current), the specified Vd is replaced with that calculated from the active power exchange deter-
mined by the master and the series current of the slave. In control mode 8 when VSREF is 0 (i.e.,
desired series voltage is specified relative to sending bus voltage), the specified Vd and Vq are first
transformed to the series current axis, and the resulting Vd is then replaced with that calculated
from the active power exchange determined by the master and the series current of the slave.
Therefore, both devices typically have SHMX set to zero, and VSET of both devices is ignored.
TRMX of the master device is the maximum active power exchange between the two devices, and
TRMX of the slave device is set to zero. QDES of the slave device is ignored.
All Modes
It is possible for the power flow iteration to continue even though its voltage change or mismatch
tolerance has been achieved. This can occur in several model states described above when the
limited quantity is too far away from the limit being held.
The solution of the series FACTS device in all of the above model states except the constant series
impedance mode includes the temporary insertion into the network of ac series and shunt elements
and a corresponding Norton current injection at the sending and terminal buses of the FACTS
device. This technique can improve the convergence properties of the power flow solution. The
insertion of these dummy elements is handled automatically by the FACTS model using the reac-
tance specified as LINX. If the convergence monitor indicates an underaccelerated convergence,
increasing LINX (which decreases its effect) may be helpful. When the shunt element is at a current
6-29
limit, and therefore the sending end voltage magnitude is changing from one iteration to the next,
slow network convergence may be observed with several of the model states described above.
Manually adjusting LINX can improve the convergence characteristics.
6.3.17 DC Lines
The two-terminal dc line (refer to Two-Terminal DC Transmission Line Data), multi-terminal dc line
(refer to Multi-Terminal DC Transmission Line Data), and voltage source converter (VSC) dc line
(refer to Voltage Source Converter (VSC) DC Transmission Line Data) models are called at the start
of each iteration to set the active and reactive powers flowing from the ac network into the dc line
at each converter bus during that iteration. If a dc line is blocked by its model, an appropriate
message is printed at the Progress tab (refer to Section 4.4 Virtual Output Devices).
Capacitor Commutated DC Lines

At each power flow solution iteration, capacitor commutated two-terminal dc lines require an itera-
tive Newton solution to compute the active and reactive power boundary conditions. If this Newton
solution fails to converge, an appropriate message is printed at the Progress tab.
VSC dc Lines
Whenever converter limits are checked by the VSC dc line model, the following procedure is used:
1. Convert the current limit IMAX to MVA using the present ac voltage and the base voltage of
the converter bus. If IMAX is positive, but the base voltage at the converter bus is zero,
unlimited current loading is permitted.
2. Use IMAX converted to MVA or SMAX, whichever is smaller, as the converter limit.
3. If in power factor mode, limits are checked during each power flow iteration as follows:
a. Get the MVAR corresponding to the desired MW.

b. If |P + jQ| exceeds the limit from 2, reduce the magnitude of P and/or Q using PWF.
4. If in ac voltage control mode, limits are checked whenever convergence of the power flow
iteration is achieved as follows:
a. Get the MVAR from the last iteration.

b. If |P + jQ| exceeds the limit from 2, reduce the magnitude of P and/or the appro-
priate Q limit using PWF.
c. If, on any iteration during which limits are checked, both converters are controlling
voltage and both are loaded beyond a limit, only the converter with the larger over-
load has its loading reduced so that it is at its limit.
d. Whenever a limit violation is detected and relieved are described above, the con-
vergence flag is reset and the power flow solution continues.
5. Whenever a converter has its active power order reduced due to a limit violation, the active
power order at the other converter is reduced accordingly.
6-30
Power orders and/or reactive power limits are reduced such that the following two equations are
simultaneously satisfied:
(Pi + P)2 + (Qi + Q)2 = SMAX2
P P (1.0 - PWF)
= i x
Q Qi PWF
Thus, if PWF is 0.0, only active power is reduced; if PWF is 1.0, only reactive power is reduced;
otherwise, the above equations are applied.
One of two solution strategies is used for solving the conditions at a VSC dc line at each iteration.
The following approach is used when the following three conditions are satisfied: both converters
are in ac voltage control mode; limits are being checked on this iteration; and both converters are
overloaded.
1. At the converter where the amount of overload is greater, relieve the overload as described
above.
2. Solve for the dc current using the specified dc voltage at the voltage controlling converter,
the active power order and the converter loss coefficients at the converter where the over-
loading was relieved, and the dc line resistance.
3. Calculate the active power order at the other converter.
In all other situations, the following solution approach is used:
1. At the power controlling converter, check limits as described above.
2. Solve for the dc current using the specified dc voltage at the voltage controlling converter,
the active power order and the converter loss coefficients at the power controlling converter,
and the dc line resistance.
3. Calculate the active power order at the voltage controlling converter.
4. Check limits at the voltage controlling converter as described above.
5. If a limit is violated at the voltage controlling converter, calculate a new power order for the
power controlling converter and repeat steps 1 and 2.
When activity SOLV is run on a system that had previously been solved by one of the PSS®E
network solution activities, the presence of VSC converters that control ac voltage and which are at
an MVA or current limit usually results in more than one network solution iteration being required.
Although the network should have been in balance, significant voltage changes may initially be
imposed as these devices are solved with limits ignored until convergence is achieved.
6-31
6.3.18 AC Voltage Control

The discussions of the various types of equipment above and in Section 5.2.1 Power Flow Raw
Data File Contents indicate that the power flow model may include several types of ac voltage
controlling equipment. Each such device can be included in one of the following categories:
1. Swing bus.
2. Setpoint mode voltage control device.
3. Band mode voltage control device.
The following paragraphs discuss each of these types of ac voltage control.
Swing Bus
A power flow case may be considered as being composed of one or more ac islands. An ac island
is defined as the set of all in-service buses such that each bus in the island may be reached from
every other bus in the island through the in-service ac network. If a working case contains more
than one island, any island is either electrically disjoint from all other islands, or connected to one
or more islands by one or more asynchronous ties (e.g., dc lines).
To be a valid power flow case, each ac island in the working case must contain at least one Type 3
(swing) bus. Furthermore, the buses connected by each in-service branch must be in-service (i.e.,
none of them may be Type 4 buses). When enabled, the solution connectivity checking option (refer
to Saved Case Specific Option Settings) checks for the presence of swingless islands at the start
of each power flow solution. Furthermore, activity TREE may be used to check for the presence of
swingless islands, as well as to disconnect any or all such islands and to check for the presence of
in-service ac branches connected to Type 4 buses.
During power flow solutions, the voltage magnitude and phase angle at each Type 3 bus are held
constant. The voltage magnitude is held to the value specified by VS in the Type 3 bus generator
data (refer to Generator Data), and the phase angle is held to the value specified by VA in the Type
3 bus data (refer to Bus Data) or to zero degrees if a flat start is specified. At the completion of each
power flow solution, the active and reactive power generation at each Type 3 bus are set such that
the mismatch at the bus is zero. Each Type 3 bus must have at least one in-service machine
connected to it.
While more than one Type 3 bus may be present in an island, this is generally not recommended.
It is the user’s responsibility to coordinate their phase angle settings when multiple swing buses are
present in an island. Furthermore, care must be taken in the use of the flat start option of the power
flow solution activities, which always sets the phase angles of all buses, including type 3 buses, to
zero degrees.
6-32
Setpoint Voltage Control

Those devices that provide for voltage control to a setpoint have their reactive power output or
consumption set during each power flow iteration such that the voltage magnitude at the controlled
bus is held at its scheduled value as long as the device’s reactive power limits are not violated.
These devices provide for either local bus voltage control or voltage control of a remote type 1 or 2
bus.
The following setpoint mode voltage controlling devices may be modeled in PSS®E:
• An in-service generating plant at a type 2 bus may control either local bus voltage or
the voltage at a remote bus. Refer to Generator Data and Section 6.3.12 Generation.
• A switched shunt for which MODSW is 1 or 2 at a type 1 or 2 bus may control either
local bus voltage or the voltage at a remote bus to a voltage setpoint (refer to Switched
Shunt Data). Such switched shunts for which MODSW = 1 (i.e., discrete control) are
initially treated as continuous, then moved to the nearest step and locked, as described
in (3b) of Section 6.3.15 Switched Shunt Devices.
• A voltage controlling converter of a VSC dc line at a type 1 or 2 bus may control either
local bus voltage or the voltage at a remote bus. To be a voltage controlling converter,
the VSC dc line must be in-service (MDC = 1), the converter must be in-service
(TYPE = 1 or 2), and the ac control mode must be set for voltage control (MODE = 1).
Refer to Voltage Source Converter (VSC) DC Transmission Line Data and VSC dc
Lines.
• The shunt element at the sending end of an in-service FACTS device at a type 1 or 2
bus may control either local bus voltage or the voltage at a remote bus. Refer to FACTS
Device Data and Section 6.3.16 FACTS Devices.
When multiple voltage controlling devices control the same bus voltage, the reactive power require-
ments are shared among the controlling devices in proportion to their RMPCTs, subject to each
device’s reactive power, current or admittance limits, as appropriate. The Mvar output of each device
controlling the voltage at bus I is set to the product of the total Mvar required at all devices controlling
the voltage at bus I times a fraction; the numerator of this fraction is RMPCT of the device and the
denominator is the sum of the RMPCTs of all the devices controlling the voltage at bus I. It is the
responsibility of the user to ensure that voltage control specifications for all the setpoint mode
devices controlling the same bus voltage are identical, and that the RMPCT values are such that
the desired reactive power sharing is obtained.
When multiple setpoint mode voltage controlling devices are present at a bus, they should normally
all be specified with the same voltage control objective. Similarly, when multiple setpoint mode
voltage controlling devices are present among a group of buses connected together by zero imped-
ance lines, the same voltage control objective should be specified for all of them. (Recall that buses
connected together by zero impedance lines are treated as the same bus during power flow solu-
tions; refer to Zero Impedance Lines.)
When one or more devices are controlling the voltage at a remote bus, any setpoint mode voltage
controlling devices at the controlled bus should be specified so as to control local bus voltage.
6-33
Other than generation at the bus itself, setpoint mode voltage controlling devices at type 3 buses
and at buses connected to type 3 buses through zero impedance lines may not be used for voltage
control purposes. Such devices are handled as follows by the power flow solution activities:
• A zero impedance line connected generating plant is held at its present active and reac-
tive power output.
• A local or zero impedance line connected switched shunt controlling to a voltage set-
point is locked at its present admittance.
• A local or zero impedance line connected VSC dc line is blocked.
• A local or zero impedance line connected FACTS device is blocked.
Activity CNTB may be used to check for suspect or erroneous voltage control specifications.
Band Mode Voltage Control

Those devices that control voltage at a bus to a voltage band or the reactive power output of another
voltage controlling device are termed band mode voltage controlling devices. Their settings are
adjusted between (rather than during) power flow iterations.
The following band mode voltage controlling devices may be modeled in PSS®E:
• A switched shunt for which MODSW is 1 at a type 1 or 2 bus may control either local
bus voltage or the voltage at a remote bus to a voltage band (refer to Switched Shunt
Data and Section 6.3.15 Switched Shunt Devices).
• A switched shunt for which MODSW is 3 at a type 1 or 2 bus may control the reactive
power output of a generating plant to fall within a reduced reactive power limit band
(refer to Switched Shunt Data and Section 6.3.15 Switched Shunt Devices).
power output of a voltage controlling VSC dc line converter to fall within a reduced reac-
tive power limit band (refer to Switched Shunt Data and Section 6.3.15 Switched Shunt
Devices).
• A switched shunt for which MODSW is 5 at a type 1 or 2 bus may control the admittance
setting of a remote switched shunt to fall within a reduced reactive admittance limit
band (refer to Switched Shunt Data and Section 6.3.15 Switched Shunt Devices).
power output of the shunt element of FACTS device to fall within a reduced reactive
current limit band (refer to Switched Shunt Data and Section 6.3.15 Switched Shunt
Devices).
• A transformer may have its Winding 1 turns ratio adjusted to hold the voltage at a des-
ignated bus within a specified band (refer to Transformer Data and Voltage Control).
• The terminal end of an in-service FACTS device at a type 1 or 2 bus may deviate from
its desired power setpoints to keep the voltage at the terminal bus within a specified
band. Refer to FACTS Device Data and Section 6.3.16 FACTS Devices.
6-34
6.3.19 Characteristics of Activity SOLV

The Gauss-Seidel and the Modified Gauss-Seidel have much of their operation and characteristics
in common. This section will summarize the aspects of the Gauss-Seidel method. Refer to
Section 6.4 Applying Modified Gauss-Seidel Power Flow Solution to review differences with the
Modified method.
The Gauss-Seidel solution method has five available solution control parameters:
• ACCP - Acceleration factor for the real part of the voltage adjustment.
• ACCQ - Acceleration factor for the imaginary part of the voltage adjustment.
• TOL - Convergence tolerance in pu.
• ITMX - Default limit on number of iterations. (= 100)
• BLOWUP - Largest voltage change threshold.
The acceleration factor ACCM is used only for the Modified Gauss-Seidel method.
The nodal iterative solution method of activity SOLV uses separate acceleration factors (ACCP and
ACCQ) for the real and imaginary parts of the voltage adjustment. Both of these factors have default
values of 1.6, but ACCP need not be equal to ACCQ. The guide to the tuning of the acceleration
factors should be:
• If the voltage change on successive iterations is oscillating in magnitude and/or sign,

decrease acceleration.
• If the voltage change on successive iterations is decreasing smoothly, convergence
may be improved by increasing acceleration (see Figure 6-8).
The acceleration factors should never be set greater than two, and the optimum seldom exceeds
about 1.8. Although the acceleration must be tuned to the system for optimum performance, devi-
ations from the optimum values do not have a dramatic effect on the number of iterations required.
The normal tolerance value for the Gauss-Seidel solution is 0.0001 per unit. This tolerance is
applied to the largest voltage change in each iteration and convergence is assumed when |V| is
less than this tolerance. The tolerance may be increased as far as 0.0005 per unit if only approxi-
mate power flows are needed. Reducing the tolerance as low as 0.00001 per unit is permissible to
achieve reduced node mismatches, but such a small tolerance is not recommended because the
convergence of the Gauss-Seidel method becomes very slow as the voltage changes fall below
about 0.0001 per unit.
6-35
Largest
|DV|
Under accelerated
ACCN Factor Should
be Increased
Over accelerated
ACCN Factor Should
be Decreased
Optimum
Acceleration
Iteration Number
Figure 6-8. Dependence of Power Flow Convergence on Acceleration Factors
At the completion of each iteration, the largest voltage change is checked against a blowup toler-
ance, which has a default value of 5.0 pu. If the largest change exceeds this tolerance, an
appropriate message is printed and activity SOLV is terminated.
The General solution parameters are independent of the type of iterative solution. In addition to the
BLOWUP parameter, previously described, they are:
• PQBRAK – This is the voltage level below which the load characteristic will change
from constant MVA to an elliptical current-voltage characteristic. (see Section 6.3.3
Boundary Conditions of Constant MVA Loads).
• THRSHZ – This is the threshold reactance for branches below which they will be
treated as zero impedance lines. (see Zero Impedance Lines)
• ADJTHR – When tap adjustment is enabled for the Gauss-Seidel and the Full Newton-
Raphson solutions, those transformers controlling voltage are checked for adjustment
whenever the largest voltage magnitude change in per unit on the previous iteration is
less than the automatic adjustment threshold tolerance, ADJTHR. When using the
decoupled and fixed slope decoupled Newton-Raphson solutions, this adjustment
check occurs following any P-angle half iteration in which the largest voltage phase
angle change in radians is less than ADJTHR.
• ACCTAP – This is a tap movement deceleration factor. The voltage error, for a voltage
controlling transformer is multiplied by ACCTAP. If ACCTAP is set less than its default
value of 1.0, the apparent voltage error is reduced and the number of tap changes
occurring during the iterative process is reduced.
• TAPLIM – The solution parameter TAPLIM, which has a default value of 0.05, defines
the maximum ratio change that may be applied to a transformer during any adjustment
6-36
calculation. If the tap STEP of a transformer exceeds TAPLIM and the controlled
voltage is outside of its voltage band, the ratio is changed by one tap STEP.
• SWVBND - The solution parameter SWVBND specifies the percentage of switched
shunts controlling to a voltage band, and for which the voltage at the controlled bus is
outside of the specified band, that can be adjusted on any single adjustment cycle.
• MXTPSS - The solution parameter MXTPSS specifies the maximum number of power
flow iterations during which the adjustment of transformer tap ratios and/or the adjust-
ment of switched shunts that control to a voltage band or that control the reactive power
output of another voltage controlling device may occur.
• MXSWIM - The solution parameter MXSWIM specifies the maximum number of power
flow iterations during which an induction machine may be switched from the "running"
state to the "stalled" or "tripped" state. Any machine for which this limit is reached
remains in the "stalled" or "tripped" state for the remainder of the power flow solution.
Reducing ACCTAP and/or TAPLIM below their default values may be beneficial on systems
with a high concentration of Load Tap Changers or where the voltage profile is extremely
sensitive to tap settings.
Activity SOLV has a default limit of 100 iterations and a voltage convergence tolerance of 0.0001
pu. This tolerance applies to the largest voltage change each iteration, and convergence is
assumed when the magnitude of the largest bus voltage change is less than this tolerance.
Reducing the tolerance as low as 0.00001 pu is permissible to achieve reduced node mismatches,
but such a small tolerance is not recommended for activity SOLV because the convergence of the
Gauss-Seidel method becomes very slow as the voltage changes fall below about 0.0001 pu.
The user may modify any of these solution parameters with the data changing activity CHNG or the
[Solution Parameters] dialog.
The following rules and convergence characteristics apply to activity SOLV:
1. The presence of negative reactance branches in a network usually causes activity SOLV to
diverge.
2. The presence of very low impedance branches (e.g., jumpers with an impedance of j0.0001)
that are not being treated as zero impedance lines (refer to Zero Impedance Lines) often
results in slow convergence as the voltage adjustments get small, and in mismatches at the
buses involved.
3. The number of iterations required to reach the convergence tolerance increases as the
system size increases.
4. Activity SOLV may be used if the initial voltage estimate is poor.
5. Activity SOLV is tolerant of reactive power problems.
6. Activity SOLV is tolerant of data errors and insoluble conditions in local areas of the network.
It is generally well converged everywhere except in the problem areas.
7. When it diverges, it usually fails gently.
6.3.20 Automatic Adjustments

Activity SOLV provides for the following solution options:
6-37
Applying Modified Gauss-Seidel Power Flow Solution Program Operation Manual
1. Adjustment of transformer off-nominal turns ratio to hold the voltage at a designated bus
within a specified band.
2. Adjustment of area swing bus generator powers to hold area net interchange within a spec-
ified band.
3. Flat start.
4. Adjustment of the turns ratios of converter transformers at dc transmission terminals and of

ac network transformers controlling dc line quantities.
5. Adjustment of switched shunt devices. When this adjustment option is disabled, discretely
operating switched shunts are moved to their nearest step, if necessary, and all switched
shunts, including continuously operating devices, are held constant. When this adjustment
option is enabled, either all adjustable switched shunts may be adjusted, or continuous
mode switched shunts are subject to adjustment and discrete mode switched shunts are
locked.
6. Ignoring generator reactive power limits at Type 2 buses with unequal var limits.
PSS®E program option settings exist for adjustments (1), (2), (4), and (5) above. Activity OPTN may
be used to establish the default setting for each of these adjustment options (refer to Section 3.3.3
Program Run-Time Option Settings). Then, on each entry into activity SOLV, these option settings
determine which of the adjustment options are activated.
The default responses corresponding to the adjustments for which a PSS®E option setting exists
are the current values of these option settings; the default responses for the flat start and var limits
items are zeros.
For transformer ratio adjustment, (#1 above), the adjustment is enabled if the corresponding option
setting is either 1 (stepping) or 2 (direct). Refer to Voltage Control.
For further discussion of solution options, refer to Section 6.5.2 Automatic Adjustments.
®
PSS E GUI Users Guide, Section 11.2.5, Gauss-Seidel Power Flow Solution
Section 9.1, Running Gauss-Seidel Power Flow Solution
6.4 Applying Modified Gauss-Seidel Power Flow Solution

Activity MSLV
Run Activity MSLV - GUI

Gauss Tab OPTION: Modified Gauss-Seidel
Run Line Mode Activity MSLV - CLI
6-38
Program Operation Manual Applying Modified Gauss-Seidel Power Flow Solution
ACTIVITY?
>>MSLV
AB, NC, NM, DC, FD,MO
The power flow solution activity MSLV uses a modified Gauss-Seidel iterative algorithm to solve for
the bus voltages needed to satisfy the bus boundary conditions contained in the working case. A
secondary adjustment applied based on each primary voltage change enables negative reactance
branches to be represented between Type 1 buses.
Activity MSLV handles the network topology check, the network connectivity checking option, flat
start solution, selection and application of automatic adjustments, generator, load, switched shunt,
FACTS device, and dc line boundary conditions, the blowup check, and interrupt codes in the same
way as activity SOLV. The solution convergence monitor, FACTS device monitor, dc transmission
line monitors, induction machine monitor, largest mismatch tabulation, swing bus summary, and
area interchange violation summary are identical to those of activity SOLV. Refer to SOLV, particu-
larly the sections regarding Generation, Load, Switched Shunt Devices, FACTS Devices, DC Lines,
AC Voltage Control, and Automatic Adjustments.
Unlike the Gauss-Seidel solution method, the Modified Gauss-Seidel iterative algorithm employs a
secondary adjustment based on each primary voltage change to enable negative reactance
branches to be represented between Type 1 buses. Activity MSLV applies the standard Gauss-
Seidel voltage adjustment formula at Type 2 buses and a modified formula at Type 1 buses. This
allows it to handle series capacitors connecting Type 1 buses. (MSLV usually cannot handle nega-
tive reactance branches connected to Type 2 or 3 buses.)
Activity MSLV uses the same acceleration factors, ACCP and ACCQ, at Type 2 buses as does
activity SOLV. At Type 1 buses, it uses a separate acceleration factor, ACCM, which has a default
value of unity. The principles for setting ACCM are the same as outlined in Section 6.3.19 Charac-
teristics of Activity SOLV for setting ACCP and ACCQ. The convergence of activity MSLV is,
however, much more sensitive to the value of ACCM than activity SOLV is to the values of ACCP
and ACCQ.
Changing ACCP and ACCQ by 0.05 usually has very little effect on the convergence of SOLV and
MSLV, but the same change in ACCM may cause a major change in the convergence properties of
MSLV. Typical values for ACCM range from about 1.2 for well-behaved systems without series
capacitors down to slightly below unity in difficult cases with series capacitors.
The parameters designating the maximum number of iterations, the convergence tolerance, and
the blowup threshold are shared with activity SOLV. The user may modify any of the solution param-
eters with the data changing activity CHNG or the [Solution Parameters] dialog.
The following rules and convergence characteristics apply to activity MSLV:
1. The presence of negative reactance branches connected to Type 2 or 3 buses usually

causes activity MSLV to diverge.
2. Series capacitors may be represented between Type 1 buses, as long as the level of
compensation does not exceed about 80%.
which are not being treated as zero impedance lines (refer to Zero Impedance Lines) often
6-39
Applying Fully-Coupled Newton-Raphson Power Flow Solution Program Operation Manual
results in slow convergence as the voltage adjustments get small, and in mismatches at the
buses involved.
4. The number of iterations required to reach the convergence tolerance increases as the
system size increases.
5. Activity MSLV may be used if the initial voltage estimate is poor.
6. Activity MSLV is tolerant of reactive power problems.
7. Activity MSLV is tolerant of data errors and insoluble conditions in local areas of the network.
It is generally well converged everywhere except in the problem areas.
8. The rate of convergence is very sensitive to the tuning of the acceleration factor ACCM.
Modest deviation from the optimum value may result in poor convergence characteristics.
9. Activity MSLV takes somewhat more time per iteration than does activity SOLV, but gener-
ally requires fewer iterations.
PSS®E GUI Users Guide, Section 11.2.6, Modified Gauss-Seidel Power Flow Solution
Section 9.2, Running Modified Gauss-Seidel Power Flow Solution
6.5 Applying Fully-Coupled Newton-Raphson Power Flow

Solution
Activity FNSL
Run Activity FNSL - GUI

Newton Tab OPTION: Full Newton-Raphson
Run Line Mode Activity FNSL - CLI
ACTIVITY?
>>FNSL
ENTER ITERATION NUMBER FOR VAR LIMITS
0 FOR IMMEDIATELY, -1 TO IGNORE COMPLETELY:
>>
AB, NC, NM, DC, FD, MO,NV
The power flow solution activity FNSL uses a fully coupled Newton-Raphson iterative algorithm to
solve for the bus voltages needed to satisfy the bus boundary conditions contained in the working
case.
Differences from the Gauss method are as follows:
6-40
Program Operation Manual Applying Fully-Coupled Newton-Raphson Power Flow Solution
• Tap and phase adjustment options are broken out to be independent.

• Imposition of VAR limits has more options.
• A non-divergent solution is available only for the full Newton and the fixed slope decou-
pled Newton solutions.
Activity FNSL requires the prior execution of activity ORDR. If the need for a new bus ordering is
detected, activity ORDR is automatically executed before beginning the voltage change calculation.
The user specifies the number of iterations for which generator reactive power limits are applied. In
normal (default) mode, reactive power limits are ignored until the largest reactive power mismatch
has been reduced to a preset multiple of the mismatch convergence tolerance, TOLN. Set at 0,
reactive power limits are recognized on the first mismatch calculation, preceding the first iteration.
A positive number < n > causes reactive power limits to be applied either on iteration number < n >
or when the largest reactive power mismatch is within a preset multiple of the tolerance, whichever
occurs first.
The var limit logic of activity FNSL contains code to prevent the phenomenon of a setpoint mode
voltage controlling device oscillating on and off a limit from one iteration to the next, or between high
and low limit from one iteration to the next. This is accomplished by going back to check the reactive
power requirement and voltage magnitude on the previous iteration. Consequently, because the
logic presumes the existence of a previous iteration for the conditions in the working case, the
immediate application of generator reactive power limits (i.e., a response of zero) should be spec-
ified only when continuing the solution of the system in the working case (i.e., following SOLV,
MSLV, FNSL, NSOL, or FDNS).
The application of generator reactive power limits on the first iteration following a network change
may cause setpoint mode voltage controlling devices to be spuriously placed on a limit (e.g., a
generator’s reactive power set at the low limit but voltage magnitude less than scheduled voltage).
Activity FNSL prints a summary of any such voltage controlling devices at the Progress tab prior to
returning control back to the PSS®E interface (refer to Section 6.5.1 Characteristics of Activity
FNSL).
The reactive power component limits of voltage controlling switched shunts, VSC converters, and
shunt elements of FACTS devices are always recognized.
Activity FNSL handles the netowrk topology check, the network connectivity checking option, flat
start solution, and load, generator, switched shunt, FACTS device, and dc line boundary conditions
in the same way as does activity SOLV. In addition to the interrupt control codes recognized by
activity SOLV, the NV interrupt control code may be used to suppress the incorrect var limit tabula-
tion printed at the termination of activity FNSL. The FACTS device monitor, dc transmission line
monitors, induction machine monitor, largest mismatch tabulation, swing bus summary, and area
interchange violation summary are identical to those of activity SOLV. Refer to SOLV, particularly
the sections regarding Generation, Load, Switched Shunt Devices, FACTS Devices, DC Lines, and,
AC Voltage Control.
During each iteration, activity FNSL prints a convergence monitor, which tabulates:
1. The iteration number.
2. The largest active power mismatch in per unit and the bus at which it occurs (refer to #1 in
the convergence criteria described in Section 6.5.1 Characteristics of Activity FNSL).
6-41
3. The largest reactive power mismatch in per unit from among those buses with a PQ
boundary condition and the bus at which it occurs (refer to #2 in the convergence criteria
described in Section 6.5.1 Characteristics of Activity FNSL).
4. The largest reactive power mismatch in per unit from among those buses with a PV
boundary condition and the bus at which it occurs (refer to #3 in the convergence criteria
described in Section 6.5.1 Characteristics of Activity FNSL). This line is included only if this
value exceeds the reactive power mismatch in 3. above.
5. The largest voltage magnitude change in per unit and the bus at which it occurs.
6. The largest phase angle change in radians and the bus at which it occurs.
Buses are identified in the convergence monitor by their bus numbers, except for the star point
buses of three-winding transformers which are identified by their transformer names.
Figure 6-9. Newton-Raphson Convergence Monitor (Fully Coupled)
6.5.1 Characteristics of Activity FNSL

The Newton-Raphson solution method has seven available solution control parameters. The user
may modify any of these solution parameters using the data changing activity CHNG or the [Solution
Parameters] dialog. The available solution parameters are:
• ACCN - the acceleration factor

• TOLN - the largest mismatch in MW and Mvar
• ITMXN - the maximum number of iterations
• DVLIM - the largest change in bus voltage
• NDVFCT - the non-divergent improvement factor
• VCTOLQ - the controlled bus Q mismatch convergence tolerance
• VCTOLV - the controlled bus voltage error convergence tolerance
The Newton solutions apply an acceleration factor ACCN to the voltage adjustments made at
voltage-controlled buses. This factoring overcomes stability problems that can arise when the
Newton method encounters reactive power limits. The normal value of this acceleration factor is
6-42
unity, but in extremely difficult cases it can be advantageous to set its value as low as 0.1. It will
never be advantageous to set this acceleration factor greater than unity.
Activity FNSL scales down the voltage magnitude and voltage angle change vectors if the most
negative element of the vmag / vmag vector is less than or equal to -1.0. A more restrictive limit
on the size of the largest voltage magnitude change that may be applied on any single iteration is
provided by the solution parameter DVLIM; the element of the vmag / vmag vector with the largest
magnitude is checked against DVLIM, and, if it exceeds DVLIM, the change vectors are uniformly
scaled down such that the largest voltage magnitude change applied is of magnitude DVLIM. The
default value of DVLIM is 0.99; reducing it to as low as 0.05 may improve convergence properties
in difficult cases.
At the completion of the first iteration, the largest vmag / vmag change is checked against a
blowup tolerance, BLOWUP, which has a default value of 5.0 pu; on subsequent iterations, the
largest phase angle change as well as the largest voltage magnitude change are checked. The
unscaled change vectors are used in the blowup check; i.e., the blown up condition is determined
before any scaling down of the change vectors, as described in the preceding paragraph, is applied.
If the largest change exceeds the blowup tolerance, an appropriate message is printed and activity
FNSL is terminated. The blowup check is bypassed if the non-divergent Newton power flow solution
option is enabled (refer to Section 6.5.3 Non-Divergent Solution Option).
Convergence is assumed when the following conditions are simultaneously satisfied:
1. The largest active power mismatch at each Type 1 and 2 bus must be less than the
mismatch convergence tolerance, TOLN.
2. The largest reactive power mismatch at those buses at which a PQ boundary condition is
applied must be less than the mismatch convergence tolerance, TOLN. This test applies to
the following categories of Type 1 and 2 buses:
a. Voltage at the bus is not subject to control to a setpoint.

b. Voltage at the bus is subject to control to a setpoint (refer to Setpoint Voltage Con-
trol), but all of the devices participating in the control of bus voltage to its setpoint
are at a reactive power limit.
3. The largest reactive power mismatch at those buses at which a PV boundary condition is
applied must be less than the larger of the controlled bus reactive power mismatch conver-
gence tolerance, VCTOLQ, and TOLN. This test applies to each Type 1 and 2 bus where
voltage is subject to control to a setpoint, and for which at least one of the devices partici-
pating in the control of bus voltage to its setpoint is not at a reactive power limit. While this
test is applied to all such buses, the reactive power mismatch will normally be zero (or very
close to zero) at such buses which have local devices participating in the control of bus
voltage to its setpoint, and at least one of these local devices is not at a reactive power limit.
4. The largest difference between actual and scheduled voltage magnitude in per unit at each
Type 1 and 2 bus where voltage is subject to control to a setpoint, and for which at least one
of the devices participating in the control of bus voltage to its setpoint is not at a reactive
power limit, must be less than the controlled bus voltage error convergence tolerance,
VCTOLV.
The Newton solution might not be able to reduce mismatch to the 0.001 per-unit value because of
the inherent computer precision limit.
6-43
Consider a branch with impedance of 0.0001 per unit and voltages close to unity at both ends. The
maximum imprecision in calculation of power flow through the branch is approximately:
V
P = 2 -------- = 0.0025 per unit
Z
Because the bus mismatch imprecision is the sum of the imprecisions in flows into connected
branches, a power flow case including such low-impedance branches is unlikely to reach the default
tolerance of 0.001 per unit.
The default mismatch tolerances (TOLN and VCTOLQ) are 0.1 MW and Mvar (0.001 pu on 100
MVA base), but tolerances as large as 1 MW and Mvar can give acceptable power flow solutions
for many purposes. The default Newton power flow solution mismatch tolerance program option
setting (refer to User Specified Option Settings) is the value assigned to these tolerances when a
new case is read into PSS®E with activity READ. VCTOLQ may be set to a value larger than TOLN
for cases with challenging remote voltage control specifications.
Activity FNSL has a default limit of 20 iterations (ITMXN). The default value of VCTOLV is 0.00001.
The user may modify any of these solution parameters with the data changing activity CHNG or the
[Solution Parameters] dialog.
Branch impedances as low as 0.0001 per unit do not occur frequently, but can arise in star-equiva-
lents of three-winding transformers and are sometimes used to represent jumpers between bus
sections. When these low-impedance branches exist in a power flow case, it is often advisable to
raise the zero-impedance branch threshold to represent these branches as zero-impedance lines
and then remove the low-impedance branches by joining the terminal buses of the branch together.
(This topological manipulation is described in Section 5.16 Joining Buses). An alternative is to
increase the tolerance to 0.0025 or 0.005 per unit.
A tolerance of 0.005 per unit on a 100-MVA system base represents a power flow solution impreci-
sion of 0.5 MW, which is more than acceptable for the great majority of power flow cases.
Activity FNSL continues its iterations until one of the following occurs:
1. The bus mismatch and controlled bus voltage criteria described above are satisfied, and all
FACTS devices are satisfactorily solved.
2. The iteration limit is exceeded.
3. The non-divergent solution option is disabled and the blown-up condition is detected.
4. The non-divergent solution option is enabled and applying the current iteration’s change
vectors does not significantly reduce the system mismatch level.
5. The user interrupts the solution.
6. A diagonal element of the Jacobian matrix is near zero, indicating a singular matrix.
Prior to terminating, activity FNSL checks for setpoint mode voltage controlled buses with boundary
condition inconsistencies.
First, any setpoint mode voltage controlled bus for which at least one of its controlling devices is not
at a reactive power limit, but where voltage differs from its designated setpoint by more than the
smaller of VCTOLV and 0.00001, is tabulated. For buses where the difference exceeds VCTOLV,
6-44
the voltage is followed by an asterisk (  ). Such buses may be present when ACCN is less than
unity and further iterations are needed to step the bus voltage magnitude to within these tolerances
of its desired value. Such buses may also be present when, on the last mismatch calculation before
the solution is terminated, a voltage controlled bus switches from reactive power limited (a PQ
boundary condition) to voltage controlled (a PV boundary condition).
Then, any setpoint mode voltage controlled bus where controlling devices are all at a reactive power
limit, but where voltage magnitude is on the wrong side of its voltage setpoint by more than the
smaller of VCTOLV and 0.00001, is tabulated (i.e., controlling devices are at their high reactive
power limits and the voltage magnitude is greater than the setpoint, or the controlling devices are
at their low reactive power limits and the voltage is less than the setpoint). For buses where the
difference exceeds VCTOLV, the voltage is followed by an asterisk (  ).
Following each report, the number of violations detected is tabulated. The list of buses that are in
violation may be suppressed as a user option; the total number of violations is still tabulated.
The following rules and convergence characteristics apply to activity FNSL:
1. Activity FNSL converges in a very few iterations on well-conditioned cases, achieving very
small bus mismatches.
2. Negative reactance branches are permitted in the network.
that are not being treated as zero impedance lines (refer to ORDR) may result in the inability
of FNSL to reach the default convergence tolerances. Even with such a network, FNSL is
usually capable of reducing the largest bus mismatch to less than 0.2 MVA.
4. The number of iterations required to reach the convergence tolerances is generally insensi-
tive to system size.
5. Activity FNSL may diverge if the initial voltage estimate is poor.
6. Reactive power problems may cause poor convergence characteristics.
7. Applying generator reactive power limits too early may cause FNSL to diverge.
8. Activity FNSL is intolerant of data errors and insoluble conditions in local areas of the
network.
9. When it diverges, it often fails catastrophically, giving no indication of where the problems
are.
10. Activity FNSL requires the optimal ordering of network nodes. If it detects that a new
ordering is required, a message is printed, activity ORDR is automatically executed, and
activity FNSL continues.
11. The time per iteration with FNSL is longer than that required for the other power flow solution
activities, but fewer iterations are usually needed.
Convergence Testing Used in Prior Releases

The convergence testing described in the preceding section was implemented in PSS®E-30.3. This
section describes the convergence criteria used in earlier releases of PSS®E, and defines settings
6-45
of the two solution parameters introduced at PSS®E-30.3 (VCTOLQ and VCTOLV) that will result
in matching the convergence criteria used in earlier releases.
For a Newton-Raphson based power flow solution calculation to be considered converged in

PSS®E-30.0 through PSS®E-30.2.2, the following conditions must have all been satisfied:
2. The largest reactive power mismatch at each Type 1 and 2 bus must be less than the
power limit, must be less than 0.00001.
To match the convergence criterion of PSS®E-30.0 through PSS®E-30.2.2, set:
VCTOLQ = TOLN
VCTOLV = 0.00001
PSS®E-29.0 through PSS®E-29.5.1, the following conditions must have both been satisfied:
2. The largest reactive power mismatch at each Type 1 and 2 bus must be less than the
To match the convergence criterion of PSS®E-29.0 through PSS®E-29.5.1, set:
VCTOLQ = TOLN
VCTOLV = a large number (e.g., 10.0)
PSS®E-28 and earlier releases, the following conditions must have all been satisfied:
2. The largest reactive power mismatch at the following categories of Type 1 and 2 buses must
be less than the mismatch convergence tolerance, TOLN:
a. Voltage at the bus is not subject to control to a setpoint.

b. Voltage at the bus is subject to control to a setpoint (refer to Setpoint Voltage Con-
trol), but all of the devices participating in the control of bus voltage to its setpoint
are at a reactive power limit.
power limit, must be less than TOLN/SBASE.
6-46
To match the convergence criterion of PSS®E-28 and earlier releases, set:
VCTOLQ = a large number (e.g., 1000.0)

VCTOLV = TOLN/SBASE
6.5.2 Automatic Adjustments

Activity FNSL provides for the following solution options:
1. Adjustment of transformer turns ratio to hold the voltage at a designated bus within a spec-
ified band, or to hold reactive power flow through the transformer within a specified band.
2. Adjustment of area swing bus generator powers to hold area net interchange within a spec-
ified band.
3. Adjustment of transformer phase shift angle to hold the active power flow through the phase
shifter within a specified band.
4. Flat start.
5. Adjustment of the turns ratios of converter transformers at dc transmission terminals and of

ac network transformers controlling dc line quantities.
6. Adjustment of switched shunt devices. When this adjustment option is disabled, discretely
operating switched shunts are moved to their nearest step, if necessary, and all switched
shunts, including continuously operating devices, are held constant. When this adjustment
option is enabled, either all adjustable switched shunts may be adjusted, or continuous
mode switched shunts are subject to adjustment and discrete mode switched shunts are
locked.
7. A non-divergent solution option (refer to Section 6.5.3 Non-Divergent Solution Option).
PSS®E program option settings exist for adjustments (1), (2), (3), (5), (6) and (7) above. Activity
OPTN may be used to establish the default setting for each of these adjustment options (refer to
Section 3.3.3 Program Run-Time Option Settings). Then, on each entry into activity FNSL, these
option settings determine which of the adjustment options are activated.
The following paragraphs discuss the optional automatic adjustments in more detail. The user is
referred to Section 5.2.1 Power Flow Raw Data File Contents for additional details on the signifi-
cance of the control parameters mentioned below.
Automatic Transformer Adjustments

Any two-winding ac transformer represented in the PSS®E working case may be treated as either:
a fixed tap transformer; a tap changing transformer where Winding 1 turns ratio may be adjusted to
control the voltage at a designated bus; a tap changing transformer where Winding 1 turns ratio may
be adjusted to control reactive power flow through the transformer; a tap changing transformer
where Winding 1 turns ratio may be adjusted to control a dc line quantity; or a regulating phase
shifter where Winding 1 phase shift angle may be adjusted to control active power flow through the
transformer.
Similarly, any winding of a three-winding ac transformer represented in the PSS®E working case
may be treated as either: a fixed tap transformer winding; a tap changing transformer winding where
turns ratio may be adjusted to control the voltage at a designated bus; a tap changing transformer
winding where turns ratio may be adjusted to control reactive power flow through the transformer
6-47
winding; or a regulating phase shifter winding where phase shift angle may be adjusted to control
active power flow through the transformer winding.
The data values specified for the transformer automatic adjustment control mode and for the two-
terminal dc line ac controlling transformer parameters determine which of the above applies for any
transformer (refer to Transformer Data and Two-Terminal DC Transmission Line Data).
An adjustment monitor is printed at the Progress tab any time an adjustment occurs.
Voltage Control
To be a candidate for automatic tap ratio adjustment as a voltage controlling transformer, an
in-service transformer winding must meet the following conditions:
1. Its automatic adjustment control mode, CODn of Transformer Data, must be set to one.
2. Its specified controlled bus number (CONTn of Transformer Data) must be non-zero, and
bus CONTn must have a bus type code of 1 or 2.
3. RMAn and RMIn of Transformer Data define the tap ratio limits of the transformer, and
RMAn must be greater than RMIn.
4. VMAn and VMIn of Transformer Data define the desired voltage limits at the controlled bus,
and VMAn must be greater than VMIn.
5. NTPn of Transformer Data defines the number of tap positions, and must be greater than
one.
6. CRn + jCXn of Transformer Data defines the load drop compensating impedance.
When tap adjustment and reactive power limit application are both enabled during a power flow
solution activity, tap adjustment is suppressed until after a voltage magnitude correction with reac-
tive power limits honored has been calculated.
When tap adjustment is enabled in activities SOLV, MSLV, FNSL, INLF, ACCC, PV Analysis, or QV
Analysis using FNSL, those transformers controlling voltage are checked for adjustment whenever
the largest voltage magnitude change in per unit on the previous iteration is less than the automatic
adjustment threshold tolerance, ADJTHR; in activities FDNS, NSOL, ACCC, PV analysis, or QV
analysis using FDNS, this adjustment check occurs following any P-angle half iteration in which the
largest voltage phase angle change in radians is less than ADJTHR.
The controlled voltage is calculated as the voltage at the controlled bus less a compensating voltage
that is a function of the transformer’s loading:
VC = VCONTn - Itransformer × (CRn + jCXn)

Transformer current is calculated at the controlling winding side bus of the transformer if VCONTn
of Transformer Data is either the controlling winding side bus or a negative number; otherwise,
current on the Winding 2 side (for a two-winding transformer) or the star bus side (for a three-
winding transformer winding) is used. In either case, the current direction reference is always from
the uncontrolled side to the controlled side of the transformer. Clearly, load drop compensation by
a transformer may be suppressed by setting its CRn and CXn to zero, in which case
VC = VCONTn.
The tap adjustment step increment is calculated as:
6-48
RMAn - RMIn
STEP =
NTPn - 1
A discrete or stepping method of tap adjustment is used by activities SOLV and MSLV; this
approach may also be specified in activities FNSL, NSOL, FDNS, INLF, ACCC, PV Analysis, and
QV Analysis by specifying one as the tap adjustment code when selecting adjustment options. In
addition to the data requirements listed above, the quantity (VMAn - VMIn) should be at least
1.5  STEP.
In this method, each transformer is checked independently outside of the main power flow iteration.
If the controlled voltage is outside of its specified band (i.e., if the relationship shown in the following
expression is violated), the tap ratio is moved at least one step.
VMIn  VC  VMAn
The tap ratio may be given a change consisting of multiple steps if the controlled voltage is outside
of the voltage band by at least two times STEP. A tap movement deceleration factor, ACCTAP, is
applied to the voltage error. Setting ACCTAP below its default value of unity reduces the one-to-one
tap movement applied in response to a given voltage error.
The solution parameter TAPLIM, which has a default value of 0.05, defines the maximum ratio
change that may be applied to a transformer during any adjustment calculation; if the STEP of a
transformer exceeds TAPLIM and the controlled voltage is outside of its voltage band, the ratio is
changed by one STEP.
Reducing ACCTAP and/or TAPLIM below their default values may be beneficial on systems with a
high concentration of LTCs or where voltage profile is extremely sensitive to tap settings.
Activities FNSL, NSOL, FDNS, INLF, ACCC, PV Analysis, and QV Analysis also provide for a direct
Newton-based method of tap adjustment, which is enabled by specifying 2 as the tap adjustment
code when selecting adjustment options. In this method, if any tap ratios need to be adjusted, a
simultaneous adjustment is made of all voltage controlling transformers as well as of all Mvar
controlling transformers (refer to Mvar Control) and of all bus voltage magnitudes. Upon conver-
gence of the main power flow iteration, tap ratios of controlling transformers are moved to their
nearest step and the solution refined with tap ratios locked at those positions.
The tap movement deceleration factor, ACCTAP, used in the stepping method described above is
also used in the direct method. It reduces the elements of the voltage error vector used in the
Newton-based direct method. The maximum ratio change solution parameter, TAPLIM, is not used
in the direct method.
In the direct method, compensated limits rather than compensated voltages are used to handle load
drop compensation. The inequality shown above for the discrete method may be expressed in
terms of the voltage magnitude at the controlled bus as follows:
VMIn  (VCONTn - V)  VMAn

Adding V to each term above, the relationship may then be written in terms of compensated limits:
(VMIn + V)  VCONTn  (VMAn + V)

It is possible for the direct method to fail as a result of an overconstrained situation. This is most
likely to occur in radial or tightly looped portions of the network containing several voltage controlling
transformers attempting to control the voltage at multiple buses. Should this occur, tap ratios are
6-49
moved to their nearest step and the solution continues with subsequent adjustment of voltage
controlling transformers handled by the discrete method described above.
Mvar Control
To be a candidate for automatic tap ratio adjustment as a Mvar flow controlling transformer, an
in-service transformer winding must meet the following conditions:
1. It automatic adjustment control mode, CODn of Transformer Data, must be set to 2.
2. RMAn and RMIn of Transformer Data define the tap ratio limits of the transformer, and
3. VMAn and VMIn of Transformer Data define the desired Mvar flow limits through the trans-
former, and VMAn must be greater than VMIn. Flow is calculated at the controlling winding
side bus of the transformer and is positive when power is flowing from the controlling winding
side bus into the transformer. When specifying VMAn and VMIn, remember that -100 is
greater than -110!
4. NTPn of Transformer Data defines the number of tap positions, and must be greater than
one.
5. The controlled bus number (CONTn) and compensating impedance (CRn and CXn) of
Transformer Data are ignored.
When tap adjustment and reactive power limit application are both enabled during a power flow
solution activity, tap adjustment is suppressed until after a voltage magnitude correction with reac-
tive power limits honored has been calculated.
When tap adjustment is enabled in activities FNSL, INLF, ACCC, PV Analysis, or QV Analysis using
FNSL, those transformers controlling reactive power flow are checked for adjustment whenever the
largest voltage magnitude change in per unit on the previous iteration is less than the automatic
adjustment threshold tolerance, ADJTHR; in activities FDNS, NSOL, ACCC, PV analysis, or QV
analysis using FDNS, this adjustment check occurs following any P-angle half iteration in which the
largest voltage phase angle change in radians is less than ADJTHR. Mvar flow control is not avail-
able in activities SOLV and MSLV.
Adjustment of Mvar controlling transformers is enabled by entering either 1 or 2 as the tap adjust-
ment code when selecting adjustment options. The direct method described in Voltage Control is
used for this adjustment; ACCTAP and TAPLIM are not used in Mvar control.
DC Line Control
To be a candidate for automatic tap ratio adjustment as a dc line quantity controlling transformer,
an in-service two-winding transformer must meet the following conditions:
1. Its automatic adjustment control mode, COD1 of Transformer Data, must be set to four.
2. IFR, ITR, and IDR (or IFI, ITI, and IDI, as appropriate) of one (and only one) two-terminal dc
line converter must specify the transformer branch (refer to Two-Terminal DC Transmission
Line Data).
3. TMXR and TMNR (or TMXI and TMNI, as appropriate) of Two-Terminal DC Transmission
Line Data define the tap ratio limits of the transformer.
6-50
4. STPR (or STPI as appropriate) of Two-Terminal DC Transmission Line Data defines the tap
ratio step increment, and it must be greater than zero.
5. The remaining ac tap adjustment data of Transformer Data is ignored.
Adjustment of ac transformers that control dc line quantities is enabled only when dc tap adjustment
is enabled.
When dc tap adjustment is enabled in activities SOLV, MSLV, FNSL, INLF, ACCC, PV Analysis, or
QV Analysis using FNSL, those ac transformers controlling dc line quantities may be adjusted
whenever the largest voltage magnitude change in per unit on the previous iteration is less than the
automatic threshold tolerance, ADJTHR; in activities FDNS, NSOL, ACCC, PV analysis, or QV
analysis using FDNS, adjustment is allowed following any P-angle half iteration in which the largest
voltage phase angle change in radians is less than ADJTHR.
This adjustment calculation follows the same methodology as is used in the stepping method of tap
adjustment for ac voltage control described in Voltage Control. The tap movement deceleration
factor, ACCTAP, and the maximum ratio change solution parameter, TAPLIM, are applied.
Phase Shift Angle Adjustment

To be a candidate for automatic phase shift angle adjustment as a MW flow controlling phase shifter,
an in-service transformer winding must meet the following conditions:
1. Its automatic adjustment control mode, CODn of Transformer Data, must be set to 3 (for
symmetrical phase shift adjustment) or 5 (for unsymmetrical phase shift adjustment).
2. RMAn and RMIn of Transformer Data define the phase shift angle limits in degrees, and
3. VMAn and VMIn of Transformer Data define the desired MW flow limits through the phase
shifter, and VMAn must be greater than VMIn. Flow is calculated at the controlling winding
side bus of the transformer and is positive when power is flowing from the controlling winding
side bus into the transformer. When specifying VMAn and VMIn, remember that -100 MW is
greater than -110 MW!
4. CNXAn of Transformer Data defines the winding connection angle in degrees. A non-zero
value of the winding connection angle is required when the control mode, CODn, is 5. When
the control mode is 3, CNXAn is ignored.
5. The controlled bus number (CONTn), number of tap positions (NTPn), and compensating
impedance (CRn and CXn) of Transformer Data are ignored.
When phase shift angle adjustment is enabled in activities FNSL, INLF, ACCC, PV Analysis, or QV
Analysis using FNSL, those phase shifters controlling active power flow are checked for adjustment
whenever the largest voltage phase angle change in radians on the previous iteration is less than
the automatic adjustment threshold tolerance, ADJTHR; in activities FDNS, NSOL, ACCC, PV anal-
ysis, or QV analysis using FDNS, this adjustment check occurs following any QV half iteration in
which the largest voltage magnitude change in per unit is less than ADJTHR. MW flow control is not
available in activities SOLV and MSLV. An adjustment monitor is printed on the Progress tab any
time an adjustment occurs.
The phase shift adjustment utilizes a direct method. If any phase shift angles need to be adjusted,
a simultaneous adjustment is made of all regulating phase shifters as well as of all bus voltage
6-51
phase angles. ACCTAP and TAPLIM are not used in MW control by phase shifters. The algorithm
is normally able to handle the case of parallel phase shifters with similar flow constraints and angle
limits, and the presence of phase shifters on area interchange boundaries (see below).
When the phase shift adjustment calculation detects a singular matrix, an alarm is printed and the
power flow solution continues with further phase shift adjustment disabled.
In symmetrical phase shift adjustment (i.e., CODn is 3), the adjustable winding’s off-nominal turns
ratio is not changed as a result of a change in phase shift angle. In the unsymmetrical phase shift
adjustment (i.e., CODn is 5), the adjustable winding’s off-nominal turns ratio is changed as a func-
tion of the phase shift angle and the winding connection angle.
Area Interchange Control

Each bus in the PSS®E working case may be designated as residing in an interchange area, for
purposes of both interchange control and selective output and other processing. When the inter-
change control option is enabled during a power flow solution, each interchange area for which an
area slack bus is specified has the active power output of its area slack bus modified such that the
desired net interchange for the area falls within a desired band.
The area interchange control code as specified in activity OPTN, or as overridden at the start of the
network solution (refer to Sections 6.3.20 and 6.5.2), establishes the net interchange definition to
be used by the area interchange control calculation. When a value of 1 is specified, an area’s net
interchange is defined as the sum of the flows on all of its tie lines; a tie line is a branch (ac line, dc
line, series FACTS device or series GNE device) connected to a bus residing in the area where the
other end is connected to a bus that is not in the area. Tie flows are calculated at the metered end
as power flowing out of the area. When the area interchange control code is 2, a load where area
assignment differs from that of the bus to which it is connected is considered a tie branch for net
interchange calculation purposes; that is, an area’s net interchange includes tie line flows as well
as contributions from loads connected to area buses that are assigned to areas other than the bus’
area, and from loads assigned to the area that are connected to buses assigned to other areas.
In specifying area interchange control data, the following rules apply:
1. The area slack generator must be a Type 2 or 3 bus residing in the area.
2. Any area containing a system swing bus (Type 3) may not have some other generator bus
designated as the area slack bus.
3. Any area for which no bus is specified as an area swing is not controlled; it is not mandatory
for all areas to be under control.
4. The desired interchange is specified as a positive number for export and a negative number
for import.
5. The desired interchanges specified with area interchange data (refer to Area Interchange
Data), not the sums of each area’s interarea transfers (refer to Interarea Transfer Data), are
used as targets by the area interchange control algorithm.
6. The specification of PDES of Area Interchange Data must be consistent with the definition
of area interchange implied by the area interchange control code (see above).
7. The tolerance band should be at least 2 or 3 MW; 5 or 10 MW are more typical values.
6-52
When area interchange control is enabled in activity FNSL, ACCC, PV Analysis, or QV Analysis
using FNSL, area interchange is checked whenever the largest voltage phase angle change in
radians on the previous iteration is less than the automatic adjustment threshold tolerance,
ADJTHR; in activities FDNS, NSOL, ACCC, PV analysis, or QV analysis using FDNS, this adjust-
ment check occurs following any QV half iteration in which the voltage magnitude change in per unit
is less than ADJTHR. In activities SOLV and MSLV, the check is made when the largest voltage
magnitude change in per unit is less than 0.001 and ADJTHR, but no more frequently than every
10 iterations. An adjustment monitor is printed at the Progress tab any time an adjustment occurs.
An asterisk (  ) following a slack bus old or new active power setting indicates that the power output
is beyond its limits.
When the multi-section line reporting option is enabled (refer to Section 3.3.3 Program Run-Time
Option Settings and activity OPTN), the area assignments of the dummy buses of each multi-
section line grouping and the metered ends of the individual members of each multi-section line
grouping are ignored. Instead, a multi-section line grouping is treated as a tie branch if and only if
its endpoint buses are in different areas, with tie flow evaluated at the metered end of the multi-
section line grouping.
When the multi-section line reporting option is disabled, the area assignments of dummy buses as
well as the metered end of each member of a multi-section line grouping are recognized; the multi-
section line grouping definitions and their metered end information are ignored.
Whenever the area interchange control option is enabled during a power flow solution activity, a
warning message is printed at the start of the solution, and again at the completion of the solution,
if the sum of the desired interchanges is not zero. At the termination of the solution, an area inter-
change violation summary tabulates any area that has at least one in-service tie element connected
to it and which has an area swing assigned to it, but which fails to meet is net interchange
specification.
Switched Shunt Adjustment

The significance of switched shunt data and the treatment of switched shunts during power flow
solutions are described in Switched Shunt Data and Section 6.3.15 Switched Shunt Devices,
respectively.
When switched shunt adjustment is enabled, adjustments of switched shunts that control to a
voltage setpoint (refer to rule (3) of Section 6.3.15 Switched Shunt Devices) occur during each iter-
ation of the power flow solution activities as described in Setpoint Voltage Control. Switched shunts
that control to a voltage band (refer to rule (4) of Section 6.3.15 Switched Shunt Devices) are
adjusted between network solution iterations. Similarly, switched shunts that control the reactive
power output of another voltage controlling device are adjusted between power flow iterations.
In adjusting switched shunts that control to a voltage band, the presence of a large number of such
switched shunts among a fairly small number of buses can result in some of them oscillating from
one adjustment cycle to the next. The solution parameter SWVBND specifies the percentage of
switched shunts controlling to a voltage band and for which the voltage at the controlled bus is
outside of the specified band that can be adjusted on any single adjustment cycle. Reducing
SWVBND, thereby decreasing the number of switched shunts that are adjusted on any adjustment
cycle, may be helpful in overcoming such oscillations.
When adjustment of discrete mode switched shunts is enabled in activities SOLV, MSLV, FNSL,
INLF, ACCC, PV Analysis, or QV Analysis using FNSL, such switched shunts are checked for
adjustment whenever the largest voltage magnitude change in per unit on the previous iteration is
less than the automatic adjustment threshold tolerance, ADJTHR; in activities FDNS, NSOL,
6-53
ACCC, PV analysis, or QV analysis using FDNS, this adjustment check occurs following any
P-angle half iteration in which the largest voltage phase angle change in radians is less than
ADJTHR.
Oscillating Tap Ratio and/or Switched Shunt Adjustments

Using the solution parameter SWVBND to overcome oscillations in the adjustment of switched
shunt settings was discussed in the preceding section. This method addresses the situation where
there are a fairly large number of voltage band controlling switched shunts distributed within a rela-
tively small portion of the system.
Another type of oscillation that may occur when either or both of tap ratio adjustment and discrete
(i.e., band mode) switched shunt adjustment are enabled involves one or both of:
• very narrow control ranges (i.e., voltage bands) relative to the size of the tap ratio
and/or switched shunt steps;
• interaction among multiple devices controlling the same quantity or "nearby" quantities.
The solution parameter MXTPSS specifies the maximum number of power flow iterations on which
tap ratio adjustments and/or discrete switched shunt adjustments may occur. Once that limit is
reached, tap ratio and discrete switched shunt adjustments are suppressed for the remainder of the
power flow solution. In this case, summaries reporting violations are printed at the end of the
solution.
Automatic Adjustment Solution Parameters

The automatic adjustment threshold tolerance, ADJTHR, the tap movement declaration factor,
ACCTAP, the maximum ratio change solution parameter, TAPLIM, the voltage band controlling
switched shunt percentage, SWVBND, and the maximum number of times tap ratois and/or band
mode switched shunts may be adjusted, MXTPSS, may be modified with the data changing activity
CHNG or the [Solution Parameters] dialog. They are carried along with the working case as it is saved
and retrieved with activities SAVE and CASE, respectively.
When a new case is read into PSS®E with activity READ, the solution parameters are set to their
default values: ADJTHR to 0.005, ACCTAP to 1.0, TAPLIM to 0.05, SWVBND to 100.0, and
MXTPSS to 99.
6.5.3 Non-Divergent Solution Option

When applying the Newton-Raphson algorithm or any of its variants to the power flow problem, one
of the following results is usually observed:
• Mismatches for all buses are within tolerance (convergence).

• Increasing mismatches, and usually increasing voltage and angle changes, are
observed on successive iterations (divergence). A divergent solution is often charac-
terized by unrealistically small or large voltage magnitudes and by very large bus
mismatches; it may be characterized by a Jacobian matrix that is singular or nearly so.
• Mismatch tolerances are not met, but the solution is neither converging nor diverging
(non-convergence). This condition could be caused by convergence tolerances that
are beyond the precision limits of the combination of host computer and network
impedances; it could also result from control ranges that are too narrow relative to the
adjustment step (e.g., desired voltage range used by a voltage controlling transformer
relative to the tap step), which results in oscillation of the controlling parameter from
6-54
one adjustment cycle to the next (e.g., tap ratio increasing, then decreasing, then
increasing, and so on), or by multiple controlling devices in conflict with each other.
The non-divergent Newton power flow solution option attempts to terminate the iterative procedure
before divergent iterations have driven the voltage vector to a state where large mismatches and
unrealistic voltages are present. The resulting voltage vector, although not sufficiently accurate to
provide a converged power flow solution, often provides a relatively good indication of the state of
the network. In particular, voltage collapse situations can be identified by localized areas of bus
mismatches and low voltages, with the remainder of the network converged.
The non-divergent solution option may be applied in activities FNSL, FDNS, and the ACCC (refer
to Sections 6.5.2 and 3.3.3 and activity OPTN).
Non-Divergent Solution Methodology

The application of the Newton method to the power flow problem calculates a pair of change
vectors:  for voltage phase angles, and vmag / vmagold for bus voltage magnitudes. In its usual
application, the bus voltages are updated using equations which may be written in the form:
new = old + (ACCFAC * )

vmagnew = vmagold * [1.0 + ACCFAC * (vmag / vmagold)]
where ACCFAC is equal to 1.0.
In the non-divergent solution scheme, ACCFAC is set to 1.0 at the start of each Newton iteration. If
the mismatches that result from the new voltage and angle vectors indicate divergence, the value
of ACCFAC is halved, new and vmagnew recalculated, and mismatches recalculated. This process
is repeated until either:
• the indication of divergence is eliminated. In this case, activity FNSL advances to its
next iteration.
• ACCFAC has been reduced to a near zero value without eliminating the indication of
divergence. In this case, activity FNSL is terminated.
The divergence metric used in this inner loop voltage correction is the sum of squares of the MVA
mismatches, expressed in per unit, at all in-service buses in the working case (SUMSQM). The non-
divergent algorithm infers the elimination of divergence when the SUMSQM resulting from the appli-
cation of a set of voltage magnitude and phase angle corrections is less than the SUMSQM at the
start of the iteration multiplied by the improvement factor NDVFCT. That is, a new set of voltages is
accepted if:
SUMSQMnew < NDVFCT * SUMSQMold

The non-divergent improvement factor, NDVFCT, which has a default value of 0.99, should never
be greater than 1.0 nor less than or equal to 0.0. With values very close to 1.0, activity FNSL
accepts small reductions in SUMSQM and goes on to the next Newton iteration. As NDVFCT is
reduced, activity FNSL requires larger reductions in SUMSQM before inferring the elimination of
divergence. The setting of NDVFCT is a trade-off between execution time and a possible incre-
mental improvement in total system mismatch level. The user may modify NDVFCT with the data
changing activity CHNG or the [Solution Parameters] dialog.
Up to ten inner loop mismatch calculations are performed, and if SUMSQM has not improved suffi-
ciently by the last attempt (with ACCFAC approximately 0.00195), activity FNSL is terminated. The
voltage vector is set to either its value at the completion of the prior Newton iteration, or to value
6-55
corresponding to the last inner loop mismatch calculation, whichever has the smaller value of
SUMSQM.
Convergence Monitor
When the non-divergent solution option is enabled, the standard FNSL convergence monitor (refer
to FNSL) is augmented by two additional columns containing SUMSQM and ACCFAC. In addition,
each inner loop mismatch calculation is reported. Figure 6-10 shows the convergence monitors for
the attempted FNSL solutions of a difficult case, first with the non-divergent solution option disabled,
and then with the non-divergent solution option enabled. DVLIM and NDVFCT are both 0.99.
When the non-divergent solution option is enabled (see Figure 6-10b), the main Newton iteration
mismatch lines are identified in the ITER column as whole numbers, just as they are when the non-
divergent solution option is disabled (see Figure 6-10a); the inner loop mismatch lines are identified
with the corresponding main iteration number, followed by a decimal point, followed by the inner
loop iteration number.
In Figure 6-10b, for the first six iterations, the full change vector reduced SUMSQM and hence was
applied. The mismatch line labeled 6 indicates the mismatches resulting from the application of the
voltage and angle changes listed on the preceding line. At this point, a new pair of change vectors
are calculated, and the mismatch line labeled 6.1 indicates the resulting mismatch if the full changes
are applied (i.e., ACCFAC is 1.0). The resulting SUMSQM exceeds that of line 6, so ACCFAC is
halved and the process repeated. Finally, at line 6.4, with ACCFAC at 0.125, a reduction of
SUMSQM is achieved. The following line shows the largest voltage and angle changes actually
applied (i.e., after being multiplied by ACCFAC).
In Figure 6-10b, for most of the voltage magnitude and phase angle corrections applied, the
mismatch lines immediately preceding and following a voltage correction line are identical. While
this is often the case, it need not be. Lines 2.1 and 3 differ in the largest reactive power mismatch;
this is the iteration on which reactive power limits are first applied. Post-voltage correction mismatch
values may also be affected by bus boundary condition modifications imposed for dc lines, FACTS
devices, and GNE devices.
Recall that when the solution is terminated by the non-divergent solution option, it is not converged;
it has merely been halted in an attempt to capture useful information on the state of the system
before the solution blows up catastrophically. Therefore, in addition to mismatch tolerance not being
met, specified setpoints and bands of various equipment item parameters may not be satisfied for
all controlled equipment in the case.
6-56
ITER DELTAP BUS DELTAQ BUS DELTA/V/ BUS DELTAANG BUS

0 5.6995( 151 ) 1.2217( 151 ) 0.07177( 3008 ) 0.14024( 101 )
1 0.5073( 201 ) 0.6370( 205 ) 0.00591( 206 ) 0.00490( 201 )
2 0.0028( 152 ) 0.4046( 206 ) 0.00379( 206 ) 0.00034( 206 )
3 0.0001( 205 ) 2.4734( 3008 ) 0.03639( 3008 ) 0.00266( 206 )
4 0.0065( 154 ) 1.6332( 205 ) 0.03136( 205 ) 0.00779( 101 )
5 0.0253( 205 ) 0.8006( 201 ) 0.08905( 205 ) 0.03293( 101 )
6 0.2468( 205 ) 0.0599( 205 ) 0.17461( 205 ) 0.06537( 101 )
7 0.9226( 205 ) 0.2194( 205 ) 0.13294( 154 ) 0.04131( 101 )
8 0.3062( 205 ) 0.0904( 154 ) 0.13959( 205 ) 0.04873( 101 )
9 0.5686( 205 ) 0.1260( 205 ) 0.08090( 154 ) 0.03244( 101 )
10 0.2733( 205 ) 0.0589( 205 ) 0.82297( 205 ) 0.30216( 101 )
11 7.0235( 206 ) 7.6130( 102 ) 0.99000( 152 ) 4.91214( 206 )
BLOWN UP AFTER 12 ITERATIONS
LARGEST MISMATCH: 495.60 MW 1025.72 MVAR 1139.18 MVA AT BUS 205 [SUB230 230.00]
SYSTEM TOTAL ABSOLUTE MISMATCH: 7280.84 MVA
SWING BUS SUMMARY:

BUS# X-- NAME --X BASKV PGEN PMAX PMIN QGEN QMAX QMIN
3001 MINE -1500.9 9999.0 -9999.0 2959.5* 600.0 -100.0
a. Non-Divergent Solution Option Disabled
Figure 6-10. Activity FNSL Convergence Monitor
6-57
ITER DELTAP BUS DELTAQ BUS DELTA/V/ BUS DELTAANG BUS SUMSQM ACCFAC
0 5.6995( 151 ) 1.2217( 151 ) 66.093 1.00000
0.1 0.5073( 201 ) 0.6370( 205 ) 1.6272 1.00000
0.07177( 3008 ) 0.14024( 101 )
1 0.5073( 201 ) 0.6370( 205 ) 1.6272 1.00000
1.1 0.0028( 152 ) 0.4046( 206 ) 0.32739 1.00000
0.00591( 206 ) 0.00490( 201 )
2 0.0028( 152 ) 0.4046( 206 ) 0.32739 1.00000
2.1 0.0001( 205 ) 0.0388( 206 ) 0.30034E-02 1.00000
0.00379( 206 ) 0.00034( 206 )
3 0.0001( 205 ) 2.4734( 3008 ) 6.1208 1.00000
3.1 0.0065( 154 ) 1.6332( 205 ) 2.7156 1.00000
0.03639( 3008 ) 0.00266( 206 )
4 0.0065( 154 ) 1.6332( 205 ) 2.7156 1.00000
4.1 0.0253( 205 ) 0.8006( 201 ) 0.64587 1.00000
0.03136( 205 ) 0.00779( 101 )
5 0.0253( 205 ) 0.8006( 201 ) 0.64587 1.00000
5.1 0.2468( 205 ) 0.0599( 205 ) 0.15622 1.00000
0.08905( 205 ) 0.03293( 101 )
6 0.2468( 205 ) 0.0599( 205 ) 0.15622 1.00000
6.1 0.9226( 205 ) 0.2194( 205 ) 2.1249 1.00000
6.2 0.3679( 205 ) 0.0859( 205 ) 0.33685 0.50000
6.3 0.2479( 205 ) 0.0591( 205 ) 0.15538 0.25000
6.4 0.2319( 205 ) 0.0560( 205 ) 0.13730 0.12500
0.02183( 205 ) 0.00817( 101 )
7 0.2319( 205 ) 0.0560( 205 ) 0.13730 1.00000
7.1 7.9710( 206 ) 9.5520( 102 ) 357.47 1.00000
7.2 3.6765( 206 ) 3.8054( 102 ) 60.676 0.50000
7.3 1.5493( 205 ) 0.9314( 102 ) 8.2484 0.25000
7.4 0.6542( 205 ) 0.1560( 205 ) 1.0698 0.12500
7.5 0.3362( 205 ) 0.0800( 205 ) 0.28423 0.06250
7.6 0.2556( 205 ) 0.0613( 205 ) 0.16584 0.03125
7.7 0.2364( 205 ) 0.0570( 205 ) 0.14249 0.01563
7.8 0.2323( 205 ) 0.0560( 205 ) 0.13773 0.00781
7.9 0.2316( 205 ) 0.0559( 205 ) 0.13698 0.00391
7.10 0.2316( 205 ) 0.0559( 205 ) 0.13701 0.00195
0.00193( 205 ) 0.00071( 101 )
TERMINATED AFTER 8 ITERATIONS--NON-DIVERGENT OPTION COULD NOT REDUCE MISMATCH
SWING BUS SUMMARY:
3001 MINE 270.5 9999.0 -9999.0 427.0 600.0 -100.0
b. Non-Divergent Solution Option Enabled
Figure 6-10 (Cont). Activity FNSL Convergence Monitor
6-58
Program Operation Manual Applying Decoupled Newton-Raphson Power Flow Solution
®
PSS E GUI Users Guide, Section 11.2.2, Fully-Coupled Newton-Raphson Power Flow Solution
Section 9.3, Running Fully-Coupled Newton-Raphson Power Flow Solution
6.6 Applying Decoupled Newton-Raphson Power Flow Solution

Activity NSOL
Run Activity NSOL - GUI

Newton Tab OPTION: Decoupled Newton-Raphson
Run Line Mode Activity NSOL - CLI
ACTIVITY?
>>NSOL
>>
AB, NC, NM, DC, FD, MO, NV
The power flow solution activity NSOL uses a decoupled Newton-Raphson iterative algorithm to
solve for the bus voltages needed to satisfy the bus boundary conditions contained in the working
case.
Activity NSOL handles the network topology check, the network connectivity checking option, flat
start solution, treatment of generator reactive power limits, load, generator, switched shunt, FACTS
device, and dc line boundary conditions, the blowup check, scaling of the voltage magnitude
change vector, acceleration, convergence criteria, and interrupt control codes in the same way as
activity FNSL. The selection and application of automatic adjustments is identical to that of activity
FNSL except that the non-divergent solution option is not available in activity NSOL. The FACTS
device monitor, dc transmission line monitors, induction machine monitor, largest mismatch tabula-
tion, swing bus summary, and area interchange violation summary are identical to those of activity
FNSL.
The solution convergence monitor is similar to that of activity FNSL. Each iteration is identified in
the ITER column with its main iteration number, followed by a decimal point, followed by either a
zero (for the angle correction calculation) or a five (for the voltage magnitude correction calculation);
see Figure 6-11.
6-59
Applying Decoupled Newton-Raphson Power Flow Solution Program Operation Manual
Figure 6-11. Decoupled Newton-Raphson Convergence Monitor
The solution parameters designating the maximum number of iterations, acceleration, convergence
tolerances, and maximum voltage magnitude change are shared with activity FNSL, while the
blowup threshold and constant power voltage breakpoint (refer to Section 6.3.13 Load) are shared
among all power flow solution activities. The user may modify any of the above solution parameters
with the data changing activity CHNG or the [Solution Parameters] dialog.
Activity NSOL uses an iterative scheme in which the active power-angle calculation is decoupled
from the reactive power-voltage adjustment. It is basically a Newton calculation in which each iter-
ation consists of a pair of half iterations; first, with the voltage magnitudes held constant and new
voltage phase angles determined, then with the phase angles fixed and new voltage magnitudes
calculated.
The rules and characteristics governing the use of activity NSOL are similar to those of activity
FNSL. In addition to those rules enumerated in Section 6.5.1 Characteristics of Activity FNSL, the
following apply:
1. Activity NSOL converges well if fairly uniform X/R ratios are present throughout the network.
2. When the network contains branches with resistance close to or greater than the reactance,
the iteration usually reaches some mismatch level and then begins to diverge, usually
slowly.
3. As the mismatches are reduced, the rate of improvement on successive iterations is slowed.
4. The time per half iteration with activity NSOL is roughly 1/4 of the time per FNSL iteration.
6-60
Program Operation Manual Applying Fixed Slope Decoupled Newton-Raphson Power Flow Solu-
Figure 6-12 is an example of the use of activity NSOL specified to initiate the solution from a flat
start voltage profile.
ACTIVITY? NSOL,FS NSOL from

flat start
ITER DELTAP BUS DELTAQ BUS DELTA/V/ BUS DELTAANG BUS

0.0 12.0000( 205 ) 7.1856( 152 ) 0.00000( ) 0.30269( 101 )
0.5 0.1299( 152 ) 6.9528( 154 ) 0.05212( 3002 ) 0.00000( )
1.0 0.8079( 201 ) 0.5285( 206 ) 0.00000( ) 0.02701( 101 ) Angle correction #1
1.5 0.0011( 204 ) 0.5197( 206 ) 0.00479( 206 ) 0.00000( )
2.0 0.0384( 206 ) 0.0773( 205 ) 0.00000( ) 0.00055( 101 )
Voltage correction #1
2.5 0.0000( 205 ) 2.0215( 3008 ) 0.03085( 3008 ) 0.00000( ) Angle correction #2
3.0 0.1801( 3008 ) 1.7660( 205 ) 0.00000( ) 0.00246( 101 ) Voltage correction #2
3.5 0.0001( 204 ) 1.7825( 205 ) 0.03084( 205 ) 0.00000( )
4.0 0.5470( 205 ) 0.0599( 205 ) 0.00000( ) 0.00752( 101 )
4.5 0.0001( 152 ) 0.1052( 205 ) 0.01141( 205 ) 0.00000( ) var limits first applied
5.0 0.2468( 205 ) 0.0021( 205 ) 0.00000( ) 0.00310( 101 ) here; note increased
5.5 0.0000( 205 ) 0.0306( 154 ) 0.00449( 154 ) 0.00000( )
6.0 0.0987( 205 ) 0.0003( 154 ) 0.00000( ) 0.00124( 101 ) var mismatch
6.5 0.0000( 205 ) 0.0120( 204 ) 0.00179( 205 ) 0.00000( )
7.0 0.0394( 205 ) 0.0000( 154 ) 0.00000( ) 0.00049( 101 )
7.5 0.0000( 152 ) 0.0048( 204 ) 0.00071( 205 ) 0.00000( )
8.0 0.0158( 205 ) 0.0000( 154 ) 0.00000( ) 0.00020( 101 )
8.5 0.0000( 102 ) 0.0019( 204 ) 0.00029( 205 ) 0.00000( )
9.0 0.0063( 205 ) 0.0000( 154 ) 0.00000( ) 0.00008( 101 )
9.5 0.0000( 102 ) 0.0008( 204 ) 0.00011( 205 ) 0.00000( ) Note slow rate of
10.0 0.0025( 205 ) 0.0000( 154 ) 0.00000( ) 0.00003( 101 )
10.5 0.0000( 102 ) 0.0003( 204 ) 0.00005( 205 ) 0.00000( ) convergence as
11.0 0.0010( 205 ) 0.0000( 154 ) 0.00000( ) 0.00001( 101 ) we get close
11.5 0.0000( 102 ) 0.0001( 204 ) 0.00002( 205 ) 0.00000( )
12.0 0.0004( 205 ) 0.0000( 154 )
REACHED TOLERANCE IN 12 ITERATIONS
SWING BUS SUMMARY:

3001 MINE 248.9 9999.0 -9999.0 187.2 600.0 -100.0
ACTIVITY?
Figure 6-12. NSOL Example
®
PSS E GUI Users Guide, Section 11.2.1, Decoupled Newton-Raphson Power Flow Solution
Section 9.4, Running Decoupled Newton-Raphson Power Flow Solution
6.7 Applying Fixed Slope Decoupled Newton-Raphson Power

Flow Solution
Activity FDNS
Run Activity FDNS - GUI

Newton Tab OPTION: Fixed slope decoupled Newton-Raphson
Run Line Mode Activity FDNS - CLI
6-61
Applying Fixed Slope Decoupled Newton-Raphson Power Flow Solution Program Operation Man-
ACTIVITY?
>>FDNS
>>
AB, NC, NM, DC, FD, MO,NV
The power flow solution activity FDNS uses a fixed-slope decoupled Newton-Raphson iterative
algorithm to solve for the bus voltages needed to satisfy the bus boundary conditions contained in
the working case.
Activity FDNS handles the network topology check, the network connectivity checking option, flat
start solution, treatment of generator reactive power limits, load, generator, switched shunt, FACTS
device, and dc line boundary conditions, selection and application of automatic adjustments, the
blowup check, the scaling of the voltage magnitude change vector, acceleration, convergence
criteria, and the non-divergent solution option, and interrupt control codes in the same way as
activity FNSL. The FACTS device monitor, dc transmission line monitors, induction machine
monitor, largest mismatch tabulation, swing bus summary, and area interchange violation summary
are identical to those of activity FNSL. Refer to Sections 6.5.1 and 6.5.2 for details.
Activity FDNS is terminated if the voltage magnitude at a bus is driven to very nearly 0.0.
The solution convergence monitor is similar to that of activity FNSL. Each iteration is identified in
the ITER column with its main iteration number, followed by a decimal point, followed by either a
zero (for the angle correction calculation) or a five (for the voltage magnitude correction calculation).
When the non-divergent solution option is enabled, the inner loop mismatch lines are identified as
described above, followed by a second decimal point, followed by the inner loop iteration number.
Activity FDNS uses an iterative scheme in which the active power-angle calculation is decoupled
from the reactive power-voltage adjustment. It is basically a Newton calculation in which each iter-
ation consists of a pair of half iterations; first with the voltage magnitudes held constant and new
voltage phase angles determined, then with the phase angles fixed and new voltage magnitudes
calculated.
Activity FDNS uses an approximation of the Jacobian matrix that is insensitive to bus voltages. Thus
the matrix used in the active power-angle solution remains fixed throughout the solution, while the
matrix used for the reactive power-voltage calculation changes only as voltage controlled buses
switch between voltage regulating (PV) and reactive power limited (PQ) boundary conditions.
The rules and characteristics governing the use of activity FDNS are similar to those of activity
FNSL. In addition to those rules enumerated in Section 6.5.1 Characteristics of Activity FNSL, the
following apply:
6-62
Program Operation Manual Applying Fixed Slope Decoupled Newton-Raphson Power Flow Solu-
1. Activity FDNS is much less sensitive to a poor initial voltage estimate than is activity FNSL.
2. As the mismatches are reduced, the rate of improvement on successive iterations may be
slowed.
3. The time per half iteration with activity FDNS is roughly 1/5 of the time per FNSL iteration.
The start-up time is longer, as the fixed matrices are calculated.
Figure 6-13 shows the convergence monitor of activity FDNS with the non-divergent solution option
enabled. The network condition at the beginning of this example is as it was following the comple-
tion of the FNSL solution shown in Figure 6-10b.
ITER DELTAP BUS DELTAQ BUS DELTA/V/ BUS DELTAANG BUS SUMSQM ACCFAC
0.0 0.2316( 205 ) 0.0559( 205 ) 0.13701 1.00000
0.0.1 0.0301( 205 ) 0.0794( 154 ) 0.19026E-01 1.00000
0.00000( ) 0.00413( 154 )
0.5 0.0301( 205 ) 0.0794( 154 ) 0.19026E-01 1.00000
0.5.1 0.2790( 205 ) 0.0765( 154 ) 0.21856 1.00000
0.5.2 0.1549( 205 ) 0.0777( 154 ) 0.76493E-01 0.50000
0.5.3 0.0926( 205 ) 0.0785( 154 ) 0.37107E-01 0.25000
0.5.4 0.0614( 205 ) 0.0789( 154 ) 0.25393E-01 0.12500
0.5.5 0.0458( 205 ) 0.0792( 154 ) 0.21540E-01 0.06250
0.5.6 0.0380( 205 ) 0.0793( 154 ) 0.20115E-01 0.03125
0.5.7 0.0341( 205 ) 0.0793( 154 ) 0.19528E-01 0.01562
0.5.8 0.0321( 205 ) 0.0794( 154 ) 0.19267E-01 0.00781
0.5.9 0.0311( 205 ) 0.0794( 154 ) 0.19143E-01 0.00391
0.5.10 0.0306( 205 ) 0.0794( 154 ) 0.19084E-01 0.00195
0.5.11 0.0301( 205 ) 0.0794( 154 ) 0.19026E-01 0.00000
0.00000( 205 ) 0.00000( )
TERMINATED AFTER 0 ITERATIONS--NON-DIVERGENT OPTION COULD NOT REDUCE MISMATCH
LARGEST MISMATCH: 2.35 MW 7.94 MVAR 8.28 MVA AT BUS 154 [DOWNTN 230.00]
SWING BUS SUMMARY:

3001 MINE 277.4 9999.0 -9999.0 427.1 600.0 -100.0
Figure 6-13. Activity FDNS Convergence Monitor: Non-Divergent Solution Option Enabled
An optimized FDNS solution method is provided in activities that are related to contingency anal-
ysis: ac contingency analysis, multi-level contingency analysis, PV analysis and QV analysis. It is
a special form of the fixed slope decoupled Newton-Raphson power flow solution method for use in
contingency analysis where a set of contingencies is imposed on a base case in turn, and the FDNS
solution method is called repeatedly to solve a full ac power flow solution for each contingency. The
only difference between the optimized FDNS and the standard FDNS is that, in the former, two tech-
niques are applied to avoid some calculations of the matrices during a power flow solution for a
contingency.
• the matrix used in the active power-angle solution (B matrix) of the base case is saved
and then used in power flow solution for a contingency; the changes in the network due
to the contingency are reflected with an additional angle correction vector.
• the matrix used in the reactive power-voltage solution (B matrix) remains fixed when
either no bus types switch or bus types switch only from voltage regulating (PV) to reac-
tive power limited (PQ) boundary conditions; the bus type changes are reflected with
an additional voltage corrective vector.
The first technique (using the B matrix of the base case and the additional angle correction vector
reflecting a contingency) produces the identical voltage angles that would be obtained using the
B matrix of the contingency case at each iteration during the power flow solution for the contin-
gency. If only bus types switches from PV to PQ occur during an iteration, the B matrix from the
6-63
Applying Newton-Raphson Power Flow Solution with Inertial / Governor Dispatch Program Opera-
last iteration is used to calculate voltages at the iteration; then the voltages are modified with the
voltage correction vector reflecting bus type switches.
When the tap setting adjustment is enabled in a contingency analysis, minor discrepancies of volt-
ages between the optimized FDNS and the standard FDNS may be found. That is because there
are slight differences in the two methods in the handling of the tap settings in the B matrix.
When the optimized FDNS is enabled in contingency analysis, some matrix calculations are
avoided. Therefore, it typically takes less time to run the contingency calculations than it does when
the standard FDSection 11.2.3, Fixed Slope Decoupled Newton-Raphson Power Flow SolutionNS solution
is used.
Section 11.2.3, Fixed Slope Decoupled Newton-Raphson Power Flow Solution
Section 9.5, Running Fixed Slope Decoupled Newton-Raphson Power Flow Solution
6.8 Applying Newton-Raphson Power Flow Solution with Inertial

/ Governor Dispatch
Activity INLF
Run Activity INLF - GUI

Power Flow > Solution > N-R solution with inertial governor dispatch (INLF)…
[N-R Solution with Inertial / Governor Redispatch]
Run Line Mode Activity INLF - CLI
ACTIVITY?
>>INLF
ENTER 0 FOR INERTIAL SOLUTION
1 FOR GOVERNOR RESPONSE SOLUTION:
>>
AB, NC, NM, DC, FD, MO, NV
The Gauss-Seidel and Newton-Raphson power flow solutions take advantage of the swing bus to
absorb all changes in system losses, changes in load and generation dispatch. These assumed
steady-state solutions do not account for power flow conditions immediately following a disturbance
or system change that modifies the power balance, such as:
• Sudden loss of load, which would be redistributed in the transient period immediately
following the disturbance among generators
• Sudden loss of generation, which would be redistributed among all other generators
• System break-up into islands each with its own frequency deviation.
6-64
Program Operation ManualApplying Newton-Raphson Power Flow Solution with Inertial / Governor
An Inertial Power Flow solution represents the effects of governor action and other effects that
might stress the system. Following the loss of generation, addition of significant demand or the split-
ting of a network, conditions can be such that there is a demand resource unbalance. The result is
a change in frequency and an adjustment of generator output. Generator output will be controlled
initially by machine inertia and fast acting controls, such as excitation and voltage regulators. As
time extends beyond the disturbance, the generator governors will have more influence.
PSS®E provides two power flow solutions with inertia/governor re-dispatch to enable the user to
examine system conditions and to obtain a revised generator dispatch for the conditions in which
machine inertia plays the major role in modifying generator output and in which governors play a
more significant role.
The Inertial Power Flow solution gives a quick approximation to system effects in the first 0.5
seconds following a disturbance, during which governor effects are minimal. Generator powers are
principally influenced by machine inertias
The Governor Response solution represents the system several seconds after an event when
governors and exciters have brought the system back to steady-state. The new generator powers
are determined by governor droop and load damping characteristics.
The inertial and governor response power flow solution activity INLF uses a Newton-Raphson iter-
ative algorithm to solve for the bus voltages needed to satisfy the bus boundary conditions
contained in the working case. The working case is assumed to have appropriate data changes
corresponding to some event imposed upon the solved pre-event power flow case; activity INLF
then solves the network for conditions existing either at about half a second following the event (an
inertial power flow) or at several seconds after the event (a governor response power flow).
Activity INLF can accommodate switching operations that result in islanding and/or load and gener-
ation power unbalances. Swing bus generation changes are redispatched among in-service
generator buses, according to either machine inertial (for an inertial power flow) or governor droop
and damping (for a governor response power flow) characteristics. Data required for the generation
dispatch is specified in an Inertia and Governor Response Data file (refer to Section 6.8.1 Inertia
and Governor Response Data File Contents). Island average frequencies are estimated and
network parameters are made frequency sensitive.
Because INLF permanently changes basic data in the working case to include frequency-depen-
dent effects, it is strongly recommended that a Saved Case file of the working case be made with
activity SAVE prior to using activity INLF.
6.8.1 Inertia and Governor Response Data File Contents

The input stream to activity INLF consists of a series of records in the following format:
I, ID, H, PMAX, PMIN, R, D
where:
I Bus number. Bus I must be present in the working case with a plant sequence
is allowed.
H Machine inertia; entered in pu on MBASE base. H = 4.0 by default.
6-65
PMAX Maximum machine active power output; entered in pu on MBASE base. Default
PMAX and PMIN for this machine are set as described in Section 6.8.4 Governor
Response Power Flow Solution.
PMIN Minimum machine active power output; entered in pu on MBASE base. If PMAX
was set to the default value, the value specified for PMIN is ignored, and PMAX and
PMIN for this machine are set as described in Section 6.8.4 Governor Response
Power Flow Solution; otherwise, PMIN = 0.0 by default.
R Governor permanent droop; entered in pu on MBASE base. R = 0.05 by default.
D Turbine damping factor; entered in pu on MBASE base. D = 0.0 by default.
Data records may be entered in any order. Input is terminated with a record specifying an I value of
zero.
Any machine for which PMAX = PMIN in the Inertia and Governor Response Data file is treated as
non-dispatchable by activity INLF. Its active power remains at its initial value from the working case
when its island’s swing bus generation change is dispatched among the in-service machines in the
island.
In the inertial power flow, except for the use of PMAX and PMIN to categorize machines as either
dispatchable or non-dispatchable, only H is used. In the governor response power flow, R, D,
PMAX, and PMIN are used.
6.8.2 Operation of Activity INLF

Activity INLF separates the working case into islands. It generates an alarm and terminates if more
than ten energized islands are detected. Otherwise, it reports the number of islands detected.
Activity INLF allows the user to select the automatic adjustment options to be enabled. As in the
standard power flow solution activities, the default response to the selection request reflects the
current automatic adjustment option settings; refer to Sections 3.3.3 and 6.5.2 and activity OPTN.
Regardless of the selections made, area interchange control is always disabled in activity INLF.
The user must specify the Unit Inertia and Governor Data file containing data records of the form
defined in Inertia and Governor Response Data File Contents. If no file is specified, the default data
described below is used for all machines. If the file does not exist or some other file system error
occurs, an appropriate message is printed. Refer to Section 2.4.1 File Usage for the file specifica-
tion conventions used by activity INLF.
In reading the input file, gross data errors (e.g., H = 0.0) generate an alarm and the corresponding
record is ignored. Data inconsistencies (e.g., PMAX less than initial machine power) generate an
alarm and are fixed and used.
Finally, the user must specify the number of the iteration during which generator reactive power
limits are to be first applied (refer to activity FNSL). When the inertial power flow calculation had
been specified, the default is -1; otherwise, 99 is the default (i.e., the same default used in activities
FDNS, FNSL, and NSOL).
Activity INLF checks each island for a swing bus. One (and only one) swing bus must be specified
in each island, and, if no swing bus exists in an island, activity INLF assigns the self-regulating
generator bus with the largest inertial or governor response, as appropriate, as the island swing.
Activity INLF generates an alarm and terminates if:
• Any island contains more than one Type 3 bus
6-66
• A Type 3 bus has no dispatchable in-service machines

• An island without a Type 3 bus contains no dispatchable self-regulating generator
buses
• An island contains no dispatchable machines.
Activity INLF functions in a manner similar to activity FNSL. Activity INLF provides for the redispatch
of generator powers to allow proper load sharing in a power unbalance condition. This occurs when-
ever the largest angle change in radians during an iteration is less than the automatic adjustment
threshold tolerance, ADJTHR, and any island swing bus power has changed by more than the
mismatch convergence tolerance since the last dispatch. The largest swing bus power change is
tabulated prior to each dispatch calculation.
Island average frequency estimates are updated during the dispatch calculation; they are set to the
average of the dispatchable machine frequencies. All bus and line shunts, admittance loads, line
charging capacitances and line impedances are modified to reflect their dependency on frequency.
Prior to terminating, activity INLF tabulates the frequency estimate and swing bus of each island.
Sections 6.8.3 and 6.8.4 contain details specific to the inertial and governor response power flow
solutions respectively.
Where applicable, activity INLF handles the network topology check, treatment of generator reac-
tive power limits, load, generator, switched shunt, FACTS device, VSC dc lines, and dc line
boundary conditions, the blowup check, scaling of the voltage magnitude change vector, accelera-
tion, and interrupt control codes in the same way as activity FNSL. The selection and application of
automatic adjustments is identical to that of activity FNSL except that the area interchange control
and the non-divergent solution options are not available in activity INLF. The basic solution conver-
gence monitor, FACTS device monitor, dc transmission line monitors, induction machine monitor,
largest mismatch tabulation, and swing bus summary are identical to those of activity FNSL. Refer
to Section 6.5.2 Automatic Adjustments for details.
6.8.3 Inertial Power Flow Solution

The inertial power flow solution is intended to indicate system conditions that would exist half a
second after the initiation of an event on a steady-state system condition. In this time frame, it is
assumed that generator overcurrent protection and governor effects are minimal, and that changes
in generator powers are influenced principally by machine inertias.
In this solution, generator scheduled voltages at those generator buses that are initially at a reactive
power limit are set to their pre-disturbance (i.e., initial working case) voltages. The default to the var
limits selection is to ignore reactive power limits. By default, tap adjustment and phase shift angle
adjustment are disabled, dc converter taps are locked, and switched shunts are active. These
settings may be overridden by the user. Area interchange control and the non-divergent solution
option are always disabled.
For machines for which no data record is successfully read (e.g., if no data file is specified, or if it
does not contain data records for all in-service machines), a machine inertia constant of 4.0 on
6-67
machine base (i.e., on MBASE base), is used. Clearly, the proper specification of MBASE for any
machine using default data is essential.
Speed deviation and frequency in per unit of each machine are estimated according to the
equations:
Pt - Pe dn
= 2H
1+n dt (6.14)
dn
n = 0.5
dt (6.15)
f=1+n (6.16)
where:
Pt = Turbine power; assumed equal to the initial machine electrical power.

Pe = Machine electrical power.
H = Machine inertia.
n = Machine speed deviation.
f = Machine terminal frequency.
Equation 6.15 assumes that the rate of change of frequency is linear over the half second time
frame.
6.8.4 Governor Response Power Flow Solution

The governor response power flow solution is intended to indicate system conditions that would
exist at least several seconds after the initiation of an event on a steady-state system condition. In
this time frame, it is assumed that voltage regulator and turbine governor effects are influential in
bringing the system to a new steady-state condition, and that changes in generator powers are
determined by governor droop and damping characteristics.
In this solution, generator scheduled voltages are unchanged except as described below, and the
default to the var limit selection is to honor generator reactive power limits. By default, tap adjust-
ment by the stepping method (refer to Voltage Control) and phase shift angle adjustment are
enabled, dc taps are unlocked, and switched shunts are active. These settings may be overridden
by the user. Area interchange control and the non-divergent solution option are always disabled.
A generator bus that is specified as an island swing by activity INLF and that was initially at a reac-
tive power limit generates an alarm, and its scheduled voltage is set to its pre-disturbance (i.e., initial
working case) voltage.
For machines for which no data record is successfully read (e.g., if no data file is specified, or if it
does not contain data records for all in-service machines), the following default data, on machine
base (i.e., on MBASE base), is used: R = 0.05 and D = 0.0. The user may specify one of the
following methods of assigning default data for PMAX and PMIN:
• Set them to 1.0 and 0.0 respectively for any machine for which no data record is suc-
cessfully read, and to the active power limits contained in the working case (refer to
6-68
Generator Data) for any machine for which a data file record was successfully read but
PMAX was set to the default value (Pre Rev-29 approach).
• Set them to 1.0 and 0.0 respectively (0.0 to 1.0 for both types).
• Set them to the working case active power limits (working case values for both types).
Clearly, the proper specification of MBASE for any machine using default data is essential.
6-69
Speed deviation and frequency in per unit of each machine are estimated according to the
equations:
Pt - Pe
n =
D + (1/R) (6.17)
f=1+n (6.18)
where D and R are as defined in Section 6.8.1 Inertia and Governor Response Data File Contents,
and Pt, Pe, n, and f are as defined in Section 6.8.3 Inertial Power Flow Solution.
If, during the solution, the total generation requirement in an island drives all generators in the island
to their high or low power output limits, an appropriate message is printed and activity INLF is
terminated.
6.8.5 Example of a Generator Contingency Analysis Solution

An example Inertial solution can be run using the savnw.sav power flow case found in the
C:\Program Files\PTI\PSSE33\EXAMPLE directory.
The test will be to trip the machine at bus 101 in the power flow. That unit is generating 750 MW.
The inertial data file to be used assumes the following information contained in Table 6-7 Inertial
Power Flow Solution Data File.
Table 6-7. Inertial Power Flow Solution Data File
I ID H PMAX PMIN R D
101 1 4 0.9 0 0.05 0
102 1 4 0.9 0 0.05 0
206 1 4 0.9 0 0.05 0
211 1 5 0.85 0 0.05 0
3011 1 4 0.9 0 0.05 0
3018 1 4 0.9 0 0.05 0
Running the Inertial and Governor power flow solutions will result in a summary of network condi-
tions and a convergence monitor at the Progress tab (see Figure 6-14).
6-70
Inertial Response
Governor Response
Figure 6-14. Progress Reports for Inertial and Governor Power Flow
Solutions
It can be seen in Figure 6-14 that the frequency in the inertial response, shortly after the disturbance
has fallen to 59.287 Hz while following governor action it has recovered to 59.478 Hz. Furthermore,
following governor action the swing bus has an increased power generation at 809 MW.
To further examine the solution it is useful to look at the redispatches. In Figure 6-15 the dispatches
are shown for the Base case, the situation subject to inertial redispatch and the situation subject to
governor action.
Inertial redispatch is not controlled by governor action. The amount of power from each unit is a
function of its inertia and it can be seen that some units are producing power above PMAX. This will
slow down the units. Following governor action, machine powers have been reduced to levels at or
within their maximum capabilities.
6-71
Base Case
Inertial
Governor
Figure 6-15. Initial Dispatch Compared to Inertial and Governor Power Flow
Redispatch Levels

The rules and characteristics governing the use of activity INLF are similar to those of activity FNSL
(refer to Section 6.5.1 Characteristics of Activity FNSL).
It may often be appropriate to precede activity INLF with activity CONL to convert the load boundary
conditions from the typical constant MVA characteristic used in conventional power flow calcula-
tions to a representation suitable for network conditions involving abnormally low or high voltages
(refer to Sections 6.3.13 and activity CONL).
All frequency-sensitive data items (refer to Section 6.8.2 Operation of Activity INLF) are modified in
the working case at the completion of activity INLF. Therefore, the standard power flow reporting
activities such as POUT, AREA, and SUBS implicitly calculate results at off-nominal frequencies,
even though island frequencies are not preserved. As a result of this, and the possible modification
of generator scheduled voltages described above, it is strongly recommended that activity SAVE
6-72
Program Operation Manual Overview: Contingency Analysis
be used with care following any execution of activity INLF. In particular, the user should not over-
write the Saved Case file containing the pre-event network solution, or any milestone Saved Case
file preserved prior to selecting activity INLF.
The generator power redispatch and frequency calculation use the machine powers as specified at
the time activity INLF is selected. This, coupled with the changes to data in the working case
described above, renders the following activity sequence invalid:
• FNSL (to solve the pre-event condition)

• CHNG (to set up the event)
• INLF (solution; not converged)
• INLF (to continue solution)
Activity INLF may require more iterations than activity FNSL, particularly when the system, or an
island thereof, is under severe stress. The iteration limit ITMXN may be increased via activity CHNG
or the [Solution Parameters] dialog.
Should activity INLF fail to converge in an islanding situation, inspection of solution results may indi-
cate that all islands except one are solved. Such a solution may be adequate for the application at
hand. Note that in an islanding case, those islands that are not of particular interest may be discon-
nected with activity TREE. This should be done after implementing the data changes required to
model the event being studied, and before selecting activity INLF.
Just as in a conventional power flow solution, selection of a swing bus for each island can have an
effect on the solution convergence properties for that island. Proper selection of island swing buses
requires an understanding of the system. The user may find it helpful to make several attempts at
solution for a particularly troublesome island, each with a different island swing bus.
It is good practice to save the working case in a Saved Case file before selecting activity INLF. This
is useful for the situation in which activity INLF fails to converge. The Saved Case may be restored,
changes made (e.g., different load characteristics, different island swing buses, or other techniques
described above) and a new solution attempted without having to respecify the data changes
required to model the event under study.
Note again that the data items described in Section 6.8.1 Inertia and Governor Response Data File
Contents are specified on machine base.
Section 11.2.4, Newton-Raphson Power Flow Solution with Inertial / Governor Dispatch
Section 9.6, Running Newton-Raphson Power Flow Solution with Inertial / Governor Dispatch
6.9 Overview: Contingency Analysis

Contingency analysis covers a variety of analytical investigations performed by both system plan-
ners and operators. The system planner’s objective is to identify the network elements that will be
required to maintain system operation within planning criteria. The general requirement is to identify
capital investments and operating costs for long term future developments.The system operator’s
objective is to identify the manner in which the system must be operated to maintain system security
6-73
Overview: Contingency Analysis Program Operation Manual
both in the near term (days, weeks, months) with existing network elements or the medium term
(one to three years) during which a limited amount of equipment could be installed.
The basic approach to contingency analysis is to:
• Establish generation/demand base case scenarios that are to be tested.

• Identify variations of generation and demand for the base cases for the time period of
development or operation.
• Identify the tests (contingencies) to be performed for both steady-state and dynamic
analysis and the system conditions that are acceptable or required prior to and during
such contingencies. The tests and required post-contingency conditions are generally
described by Reliability Criteria.
• Perform the tests.
6.9.1 Reliability Testing Criteria for Contingency Analysis

Criteria describe tests to be performed and required conditions prior to and during the test condi-
tions. While there may be variations in criteria between electric power utilities, regions and
countries, there is significant commonality.
Typical steady-state tests can include:
• Base case with all elements in service.

• Single contingencies (N-1). Loss of any transmission line or transformer or generator.
These are often termed probable or credible contingencies.
• Double contingencies (N-2). Simultaneous loss of two single-circuit transmission lines,
a double-circuit line or dc bipole. Variations on these contingencies exist worldwide
specifically with respect to the definition of double circuit and the option of non-simul-
taneity of loss (N-1-1). These too are credible or probable contingencies.
• Less probable contingences and/or extreme contingencies can include loss of entire
substations or multiple generators.
Typical dynamic testing will include the same family of contingencies and are augmented by repre-
sentation of the severity of the initiating disturbance, which results in the loss of system elements
(three-phase and single-phase faults with normal or delayed clearing times for example).
Acceptable system conditions prior to and subsequent to the contingencies depend on the severity
of the contingency and include:
• Voltages within defined normal or emergency limits.

• Changes in voltage within defined limits.
• Branch loadings within normal or emergency loading limits.
• Maintenance or loss of limited amounts of load.
• Maintenance of system integrity or breakdown into viable sections.
• Maintenance of transient and dynamic stability.
Such criteria are deterministic in the sense that the scenario being tested must comply with the
acceptable system conditions or is considered to have failed the test. A failure implies the need for
6-74
additional system elements (for planning) or an adjustment of precontingency test conditions (for
operations).
An overview of deterministic reliability tests is summarized in Table 6-8 Deterministic Reliability

Tests.
6-75
6-76
PSS®E 34.2
Overview of Deterministic Reliability Tests

Test Conditions Analysis Acceptable Conditions
Normal Steady-State conditions Steady-State Power Flow System within normal loading and voltage limits
System within emergency loading and voltage limits
Single Contingencies (Credible - Steady-State Power Flow immediately after outage and within normal limits after
more probable) system adjustments
Dynamic Analysis Transiently and dynamically stable
6-77
Reliability Test Criteria for
System within emergency loading and voltage limits
Transmission Expansion Double Contingencies (Credible Steady-State Power Flow
after system adjustment.
- more probable)
Dynamic Analysis Transiently and dynamically stable
Less Probable Contingencies Steady-State Analysis No voltage collapse or overload cascading

Supplementary Tests Dynamic Analysis Transiently and dynamically stable
Table 6-8. Deterministic Reliability Tests
Extreme Contingencies Steady-State and Avoidance of widespread load interruptions, uncon-

Supplementary Tests Dynamic Analysis trolled cascading and black-outs
Overview: Contingency Analysis
6.9.2 Applying Deterministic Criteria

This type of study comprises the outage of system elements and an examination of voltage and
loading conditions both prior to and subsequent to the outage (contingency).
Generally, for the normal condition (base case with all elements in service) the user is establishing
acceptable normal conditions of voltage and loading of lines, transformers and generators. Under
these conditions the user will normally solve the power flow with control options activated for trans-
former taps, switched shunts and other devices. Under contingency conditions, depending on the
criteria in use, the user will often block control actions as a function of how equipment in the user’s
system operates.
The basic process is one of:
• Disconnecting a system element.

• Solving the new power flow.
• Examining system conditions using PSS®E reporting facilities.
The user’s response to the results of contingency cases will depend on the study objectives.
A limited system analysis can be performed merely by manually performing the steps outlined in
the basic process. A more detailed analysis, specifically of a large system can involve the simulation
and examination of thousands of contingencies. For this, PSS®E provides procedures for automatic
testing and reporting: AC Contingency Analysis and Multi-level AC Contingency Analysis. These
procedures are described in this chapter.
Applying Transmission Transfer Limit Analysis

For economic or market requirements, the user will often need to identify the maximum level of
power that can be transferred across a network; often from identified sending and receiving areas
or systems. Limits are usually identified for both normal and contingency conditions.
As power transfers are increased across a network, limits will be reached when the thermal loading
of network elements is exceeded or when voltages fall outside acceptable levels; usually during
contingencies. The procedures for identifying transfer limits, available in PSS®E, are described in
Chapter 13 and Section 6.17, Performing PV/QV Analyses.
Applying Voltage Stability Analysis

This type of analysis is similar to transfer limit analysis but is specifically concerned with situations
where voltage control becomes the major factor in determining the power transfer capabilities of a
network. Voltage stability is a phenomenon concerning the eventual collapse of voltage as system
loading is increased and/or power transfers are increased.
Widely accepted measures of a networks vulnerability to voltage instability or collapse are:
• Power - Voltage curves (PV) that identify voltage levels in a system as power transfers
increase.
• Reactive - Voltage curves (QV) that identify reactive margins versus system voltage
levels.
Both PV and QV curves show limiting operating conditions in a network for both normal and contin-
gency conditions. The procedures for analyzing these conditions with PSS®E are described in
Section 6.17 Performing PV/QV Analyses.
6-78
6.9.3 Applying Probabilistic Reliability Criteria

The behavior of power systems is probabilistic. Loads are always uncertain. The events that cause
the outages my vary, but are always in the form of unplanned events such as lightning strikes, falling
tree limbs, human errors, and so on; these events are thus of a random nature. The weakness of
deterministic reliability analysis is that it does not reflect the probabilistic nature of power system
behavior, but treats every contingency tested equally significant. In deterministic reliability analysis,
every contingency being tested must comply with the acceptable system conditions or is considered
to have failed the test. A failure implies the need for additional system elements (for planning) or an
adjustment of precontingency test conditions (for operations). It is impossible to have zero risk of
system failures in power systems because contingencies are uncontrollable. tn many cases, a deci-
sion must be made to accept a risk as long as it can be technically and financially justified, in other
words keeping risk of system failures within a acceptable range. on the other hand, customers have
the rights to know how often, for how long these outages cause discontinuity of load supply. Prob-
abilistic reliability assessment (see Section 6.15 Calculating Probabilistic Reliability) is provided to
answer these questions. The module uses contingency enumeration technology and consists of a
calculation part, which evaluates each contingency and models predefined tripping and corrective
action sequences, and an analysis part, which conducts a detailed analysis on the basis of the eval-
uated contingency sequences to calculated following probabilistic indices:
• Probabilistic indices of flow overloads

• Probabilistic indices of voltage violations
• Expected unserved energy
• Interrupted power
The basic procedure to perform probabilistic reliability study is:
• perform a contingency analysis following the procedure for contingency analysis dis-
cussed in the above section
• prepare outage statistics data
• perform probabilistic reliability assessment
6.9.4 About Generation Dispatch

Contingency events such as generator outages, the separation of the network into islands and the
shedding of load may lead to imbalances in the power resources and demand for interconnected
ac systems. An individual dispatch mode can be specified for a contingency causing the imbalance.
A DISPATCH keyword should be employed in the contingency specification record that specifies
the contingency, and the record be followed by a group of participating bus specification records
that defines a dispatch group in the Contingency Description Data file (see Section 8.1.4 Contin-
gency Description Data File Contents), so that the change in the boundary condition is allocated
among participating generators selected in the dispatch group.
AC Contingency Analysis also provides an option to perform a common generation dispatch to

handle imbalances for all contingency events. When neither individual dispatch mode nor common
dispatch mode is specified, these imbalances are totally absorbed by the swing bus in the island;
any island without the swing bus is shut down. If both modes are enabled, the common dispatch
acts after generation dispatch is done with the individual dispatch mode for a contingency event.
The common generation dispatch is enabled by selection of one of four dispatch modes and a
dispatch subsystem. Imbalances are then apportioned among machines in the dispatch subsystem
in specified participation factors. For islands without the swing bus, the bus with largest generation
6-79
capacity is designated as the island swing bus. When there is insufficient capacity available from
the reserves, load is shed. Reactive power loads are shed in proportion to active power loads to
retain the power factor at affected buses. The following describes the computation procedures.
1. Identify all islands in the network using a tree searching technique.
2. For each island, assure that a swing bus exists. If there is no existing swing bus, the bus
with the largest generation capacity in the island is chosen as the swing bus. If no such bus
can be found, the entire island is shut down and all load shed.
3. Sum the present generator output and generation requirement to find if there is a MW imbal-
ance. The generation requirement in the island is given by the total of all bus loads, active
power bus shunts, and active power losses, including dc lines.
4. If generation deficiency, DEF, exists, it is met by increasing the present generation of partic-
ipating machines in the island by an amount proportional to the given participation factors.
If DEF still exists after the active power reserves of participating machines are exhausted,
all on-line machines in the island are participating in the generation dispatch to meet gener-
ation deficiency in the specified dispatch mode.
PGENi1 = PGENi0 + pi × DEF
where:
PGENi0 is the present dispatch of unit i,
PGENi1 is the new dispatch of unit i, and

pi is the participating factor of unit i.
5. Load shedding will take place if the sum of the maximum generation of all on-line machines
is insufficient to cover the generation requirements. In such cases, load at all buses is shed
proportionately until a load/generation balance is attained. Bus shunts and bus losses will
not be shed.
PLOADi0
PLOADi1 = PLOADi0 + x DEF
 (PLOADi0)
where:
PLOADi0 is the present load at bus i,
PLOADi1 is the new load at bus i.

6. Similarly, if generation excess, EXC, exists, it is corrected by reducing the dispatch of partic-
ipating machines in this island proportional to their given participation factors. If generation
excess still exists after all on-line machines have been reduced to their minimum generation
limits, the island will be shut down, and all load shed.
PGENi1 = PGENi0 + pi × EXC
where pi is the participating factor of unit i.
6-80
Steps 3 through 6 in the above list are repeated for each island in the network until a load/generation
balance is attained.
6.9.5 Tripping Simulation and Corrective Action Analysis

A complete contingency analysis for a contingency event includes a power flow solution on the
working base case with the contingency imposed, following sequences including a tripping simula-
tion and a corrective action analysis.
The tripping simulation is discussed in section 6.12.7 and is used to simulate protection relay oper-
ations, system adjustments by operators following a contingency event and a system cascading
failure.
A power flow solution may have any number of operating limit violations, and these problems can
be alleviated by corrective actions. The ac corrective action analysis is formulated as an optimal
power flow problem with the objective of minimizing load curtailment, MW generation re-dispatch,
transformer phase angle adjustment, off-line generator active power dispatch, tap setting adjust-
ment and switched shunt controls. It includes a standard ac power flow solution with local automatic
adjustments, power system network linearization, and a linear programming solution to relieve the
overload and voltage limit violations. Contingency analysis may start with corrective action analysis
enabled to automatically specify corrective actions for each contingency. Corrective action analysis
may be also used to only clean up the current working case. The Corrective Action Analysis is
discussed in Section 6.11 AC Corrective Actions.
Recognizing that thermal ratings and voltage limits in a power system may sometimes be treated
as soft limits, the algorithm relaxes the hard limits on the constraints in case of infeasibility, and
returns a solution with some minor violations. Hence, incorporation of the soft limits reduces the like-
lihood of infeasible solutions, which is particularly useful during contingency analysis when a large
number of corrective action solutions may need to be performed automatically.
6.9.6 Substation Reliability Assessment Analysis

Substations are junction points of power transfer between generation and transmission systems, or
transmission and distribution systems. Substations are a critical part of power systems and play an
important role in reliability analysis of power systems. Reliability of a substation is measured in
terms of the frequency and duration of substation related outage events leading to system not
meeting performance criteria. The reliability results could be used for:
• comparing substation/network configuration alternatives

• evaluating the sensitivity of substation performance to outage statistics
• evaluating the sensitivity of substation performance to equipment rating
• evaluating the sensitivity of substation performance to load level
• determining the impact of equipment maintenance on reliability.
Substation reliability assessment analysis uses state enumeration method, similar to probabilistic
reliability assessment, and is discussed in Section 6.16 Calculating Substation Reliability.
6-81
Performing AC Contingency Analysis Program Operation Manual
6.10 Performing AC Contingency Analysis

Activity ACCC
(Section 1.5, ACCC_PARALLEL_2 and Section 1.18, ACCC_WITH_DSP_3)
Run Activity ACCC - GUI

Power Flow, Contingency, Reliability, PV/QV Analysis, AC contingency solution (ACCC)…
[AC Contingency Solution]
Run Line Mode Activity ACCC - CLI
ACTIVITY?
>>ACCC
ENTER AC CONTINGENCY SOLUTION OUTPUT FILENAME:
>>
AB, CM, NM, DC, FD, MO
The AC Contingency Solution functions calculate full ac power flow solutions for a specified set of
contingency cases. Results are stored in a binary file, the Contingency Solution Output file. This file
is subsequently processed to produce reports of non-converged contingencies, violations, loadings,
and available capacity. An optional ZIP Archive Output File may be produced during the contin-
gency calculation. This file may be subsequently accessed to place any of the contingency case
solutions into the working case.
Two APIs can be used to perform the AC Contingency solutions: ACCC_WITH_DSP_3 and
ACCC_PARALLEL_2. The former is implemented for single-processor systems where the function
evaluates each contingency case in the set sequentially. The latter is implemented for multiple-
processor systems. If more than one contingency processor is selected in the Program Settings
dialog (see OPTN), ACCC_PARALLEL_2 will be invoked when running ACCC via graphical user
interface. The set are divided into as many subsets as number of contingency processor;
ACCC_PARALLEL_2 uses each processor to process one subset simultaneously.
This network contingency calculation function calculates full ac power flow solutions for the user’s
specified set of contingency cases, monitors voltage and loading conditions and stores the results
in a binary file. Subsequently, this file can be processed to produce a variety of reports of voltage
and loading violations, loadings and available capacity. This feature is a powerful approach for
testing large systems with many possible contingencies where the user wishes to monitor specific
branches, interfaces or network areas for problems.
One role of the ac contingency calculation is that of a screening tool for which the purpose is to
focus attention on those contingency cases that deserve closer study. Such a case may be brought
into the working case from an Incremental Saved Case File (an .isv file) contained in the ZIP Archive
Output File created during the contingency calculation (see Section 6.10.13, ZIP Archive Output
File).
A useful feature is the ability to produce reports in a format appropriate for import to a spreadsheet
program.
To perform ac contingency analysis there are several steps:
6-82
Program Operation Manual Performing AC Contingency Analysis
1. Produce the Distribution Factor Data file from the *.sub, *.mon, *.con files (activity DFAX).
2. Produce the Contingency Solution Output file using the Distribution Factor Data file.
3. Produce the selected report using the Contingency Solution Output file.
The process and file path are shown in Figure 6-16. Remember that the *.con file can be partially
constructed using the Ranking process (refer to Section 8.3.1 Contingency Ranking Methodology).
Figure 6-16. File Path and Process for AC Contingency Analysis
6.10.1 AC Contingency Solution Options

The following input data is specified to both of these functions (Table 6-9 AC Contingency Solution
Options).
6-83
Table 6-9. AC Contingency Solution Options
Option Description
The desired solution options to be applied during power flow calculations for
obtaining post-contingency states (see Section 6.2 Power Flow Solution
Methods)
Tap adjustment:
• Lock taps
• Stepping
• Direct
Solution options Area interchange control:

• Disabled
• Tie lines only
• Tie lines and loads
Switched shunt adjustments:
• Lock all
• Enable all
• Enable continuous, disable discrete
Non-divergent Flag to enable or disable option in the power flow solution of each contingency
solution case.
Adjust phase Flag to enable or disable option in the power flow solution of each contingency
shift case.
Flag to enable or disable option in the power flow solution of each contingency
Adjust dc taps
case.
Induction motor When an induction motor fails to solve due to low terminal bus voltage, flag to
treatment treat it as, "stalled," or, "tripped".
Either:
• Treat a contingency as non-coveveraged if any induction machines are
Induction
placed in the, "stalled," or, "tripped," states.
machine failure
• Treat a contingency case as solved if it converged, even if induction
machines were placed in the, "stalled," or, "tripped," states.
Select the desired power flow solution engine to be used in obtaining postcontin-
gency states (see Section 6.2 Power Flow Solution Methods).
• Fixed slope decoupled Newton-Raphson (FDNS)*
• Full Newton-Raphson (FNSL)
Solution Engine
* The optimized fixed slope decoupled Newton-Raphson method is
used when ACCC is initiated via the graphical user interface.
The user may choose either the regular or the optimized fixed slope
decoupled Newton-Raphson method when initiating ACCC from
an automation file.
6-84
Table 6-9. AC Contingency Solution Options (Cont.)
Option Description
Tolerance used to check for the largest initial active or reactive power mismatch.
Mismatch If exceeded, the process is terminated. This value is also used as the conver-
tolerance gence tolerance in the power flow solution of each contingency case (see
Section 6.2 Power Flow Solution Methods).
Dispatch Mode Dispatch codes for generation dispatch calculations in ACCC analysis.
Participating machines are connected to dispatch subsystem buses and have
positive active power generation. Each machine's participation factor is its
reserve (PT-PG or PG-PB) with positive values. If a Unit Inertia and Governor
Data file is specified, machine active power limits are taken from it; otherwise,
Subsystem the machine active power limits in the working case are used. In generation
machines dispatch analysis, generator active power limits are adjusted by the following
(Reserve) rules. If PT had been set to the default value, the larger value of PG (its
existing MW output) and machine power base (MVA base) will be used as PT; If
PT of a machine is less than its PG, the PT is set equal to the PG. If PB of a
machine had been set to the default value, it is set to zero; if PB of a machine
is less than its PG, the PB is set equal to the PG.
positive active power generation. Each machine's participation factor is its
Subsystem maximum active power generation with positive values. If a Unit Inertia and
machines Governor Data file is specified, maximum machine active power limits are taken
(Pmax) from it; otherwise, the maximum machine active power limits in the working case
are used. PT is adjusted by the rules discussed in Dispatch Mode of Machine
Reserve.
Subsystem
positive active power generation. Each machine's participation factor is its inertia
machines
constant. For machines for which no data record is successfully read, an inertia
(Inertia)
constant of 4.0 on machine base is used.
Subsystem Participating machines are connected to dispatch subsystem buses and have
machines positive active power generation. Each machine's participation factor is its
(Governor governor permanent droop. For machines for which no data record is success-
droop) fully read, a droop constant of 0.05 on machine base is used.
Select the subsystem for the generation dispatch. The subsystem is predefined
in a subsystem description file. All subsystem buses with one or more in-service
machines where active power generation is positive are participating in the
Dispatch system
generation dispatch. If several islands exist in the system, participating
machines for each island are connected to dispatch subsystem buses in the
island.
(*.dfx) a required file to be build by activity DFAX that corresponds to the
network condition contained in the working case (refer to Section 8.1.7 Appli-
cation Notes) and to the desired linear network analysis data files (refer to
Section 8.1.1 Linear Network Analysis Data Files). The bus input option
Distribution
(refer to Section 3.3.3 Program Run-Time Option Settings and activity
Factor Data File
OPTN) must have the same setting that was in effect when activity DFAX filled
the specified Distribution Factor Data file. Refer to Section 2.4.1 File Usage
for the file specification conventions used by the AC Contingency Solution
function.
6-85
Table 6-9. AC Contingency Solution Options (Cont.)
Option Description
Contingency
(*.acc) a required file designated by the user as the destination for the results of
Solution Output
the contingency calculations.
File
( *.thr) an optional file, created by the user, that contains data records of the
following form:
IBUS, JBUS
Load Throw-
over Data File where IBUS and JBUS are bus numbers. If branch outage contingency events
isolate bus IBUS, the user can elect to move the load to bus JBUS. Bus IBUS
and/or JBUS may be a dummy bus of a multi section line grouping. Data records
may be entered in any order. Input is terminated with a record specifying an
IBUS value of zero.
(*.inl) a required file if the generation dispatch is enabled and either the inertial or
Unit Inertia and governor droop dispatch method is selected. If the PMAX or reserve method is
Governor Data selected, the specification of this file is optional. If a file is specified, machine
File active power limits are taken from it; otherwise, the machine active power limits
in the working case are used.
ZIP Archive
Flag to enable or disable the writing of a ZIP Archive Output File.
option
ZIP Archive (*.zip) an optional file designated by the user as the destination for data used to
Output File place contingency case solutions into the working case.
6-86
6.10.2 Running AC Contingency Analysis

The network contingency calculation function calculates full ac power flow solutions for a specified
set of contingency cases. Results are stored in a binary file. This file is subsequently processed to
produce reports of violations, loadings and available capacity.
Invoking the specified AC Contingency Solution function generates an alarm and terminates if
generators are converted (refer to CONG). It checks that each non-Type 4 bus is connected back
to a Type 3 (swing) bus through the in-service ac network, and an in-service line is connected to an
out-of-service bus. If any violations are detected, an appropriate message is printed and the func-
tion is terminated. If the largest initial active or reactive power mismatch exceeds the specified
mismatch tolerance input data item, the function is terminated. This tolerance is also used as the
mismatch convergence tolerance in the power flow solution of each contingency case.
The AC Contingency Solution function sets up PSS®E working memory and temporary scratch files
in preparation for the contingency case power flow solutions. This function uses either the same
fixed slope decoupled Newton-Raphson iterative power flow solution algorithm as does activity
FDNS, or the full Newton-Raphson method of activity FNSL; the same set-up steps are performed
here.
The contingency label and contingency events of each contingency case are logged at the Prog-
ress tab (refer to ORDR) as the solution function encounters it. A message identifies any network
conditions that fail to converge or which are skipped.
The AC Contingency Solution function responds to the following interrupt control codes:
AB Abandon the function following completion of the next iteration.

CM Print the convergence and automatic adjustment monitors.
NM Suppress any automatic adjustment monitors (only used with CM interrupt control
code).
DC Tabulate conditions for each dc line after each iteration (see Section 6.3.11 Opera-
tion of Activity SOLV).
FD Tabulate conditions for each FACTS device after each iteration (see Section 6.3.11
Operation of Activity SOLV).
MO Tabulate conditions for induction machines after each iteration (see Section 6.3.11
PSS®E GUI Users Guide, Section 11.3, Running AC Contingency Analysis
Section 9.7, Running AC Contingency Analysis
6.10.3 AC Contingency Output

The AC Contingency Solution functions calculate contingency solution results (loadings on moni-
tored branches and interfaces, and bus voltage magnitudes) and place them into the specified
Contingency Solution Output file. These results may then be tabulated using any or all of three
output processing functions.
6-87
• The AC Contingency Single Run Report function (refer to Section 6.10.9 AC Contin-
gency Single Run Report) may be used to produce a variety of tabular and spreadsheet
format output reports of results from a single Contingency Solution Output file.
• The AC Contingency Multiple Run Report function (refer to Section 6.10.11 AC Contin-
gency Multiple Run Report) may be used to produce a variety of tabular reports of
results from up to nine Contingency Solution Output files.
• The auxiliary program AcccBrwsGrid, which is documented in its Help files, allows
spreadsheet-like manipulations of the results from a single Contingency Solution
Output file.
For branches, loadings printed are MVA loadings. For each monitored non-transformer branch, the
percent loading is either the percent current or the percent MVA loading, according to the non-trans-
former branch percent loading units program option setting (refer to Section 3.3.3 Program Run-
Time Option Settings and activity OPTN).
For monitored transformers, the percent loading is either the percent current or the percent MVA
loading, according to the transformer percent loading units program option setting.
When percent current is used for non-transformer branches or two-winding transformers, both the
MVA loading and percent current loading are taken from the end of the branch with the larger
current loading. If the current loadings at each end are identical, both the MVA loading and the
percent current loading are taken from the end of the branch with the larger MVA loading.
When percent MVA is used for non-transformer branches or two-winding transformers, both the
MVA loading and percent MVA loading are taken from the end of the branch with the larger MVA
loading. If the MVA loadings at each end are identical, both the MVA loading and the percent MVA
loading are taken from the end of the branch listed as the from bus.
For monitored three-winding transformer windings, both the MVA loading and percent loading are
calculated at the winding bus.
The flow across an interface is taken as the sum of the MW flows of its members. For three-winding
transformer windings, the MW loading is calculated at the winding bus as power flowing into the
transformer. For other members, the MW flow is calculated at its metered end in the from bus (i.e.,
the first bus specified in entering the branch; refer to Monitored Element Data File Contents) toward
the to bus direction. The percent loading for each interface is its percent MW loading based on its
MW loading and its interface MW rating from the selected rating set.
The user selects those subsystems where bus voltages are to be monitored, the types of voltage
check (voltage band or deviation from base case values), and threshold values by specifying
records in the Monitored Element Data file (refer to Voltage Monitoring Records). In the AC Contin-
gency Single Run Report function and the AC Contingency Multiple Run Report function, voltage
violations reports are presented in groups corresponding to the MONITOR VOLTAGE data records
specified in the Monitored Element Data file. One (or two if the second r value on the MONITOR
VOLTAGE record is specified) reports are generated for each MONITOR VOLTAGE record to be
processed. Report blocks are printed in the order in which the MONITOR VOLTAGE data records
are contained in the Monitored Element Data file.
Each voltage range record results in a tabulation of those buses from the set of buses defined on
the data record where voltage is below the low voltage threshold (i.e., the first r value on the data
record), followed by the list of buses where voltage is above the high voltage threshold (i.e., the
second r value on the data record).
6-88
Each voltage deviation record results in a tabulation of those buses from the set of buses specified
on the data record where voltage drop from their base case values exceeds the voltage drop
threshold (i.e., the first r value on the data record), followed by the list of buses where voltage rise
exceeds the voltage rise threshold (i.e., the second r value on the data record).
6.10.4 AC Contingency Post Processor

The AcccBrwsGrid program is used to perform spreadsheet-like manipulations on the results
contained in a Contingency Solution Output file. It executes outside of PSS®E, and is initiated by
selecting the ACCC Post Processor (AcccBrwsGrid) entry from the PSS®E Windows® start menu.
Refer to Additional Resources for PSS®E, Section 1.2.1 ACCC Post Processor.
6.10.5 AC Contingency Result Retrieval Routines

A family of retrieval routines is provided to extract the results in contingency analysis output files
and return arrays in FORTRAN format. These return values can then be used to create customized
reported. These routines can be called from Python files (see Section 17.1 Python Modules for
Result Retrieval).

The AC Contingency Solution function uses the same network solution calculations as do activities
FNSL and FDNS. It uses as its mismatch convergence tolerance the mismatch tolerance data item,
which is one of the user inputs to the API, rather than the Newton mismatch tolerance solution
parameter contained in the working case. All other network solution parameters are the same as
those used by activities FNSL and FDNS.
As in the power flow solution activities, FACTS devices and VSC dc lines that are zero impedance
line connected to a Type 3 bus in the base case are blocked (refer to Setpoint Voltage Control).
Even if, in a contingency case, zero impedance line outages result in such devices no longer being
zero impedance line connected to a Type 3 bus, they remain blocked in the contingency case.
One role of the AC Contingency Solution function is that of a screening tool for which the purpose
is to focus attention on those contingency cases that deserve closer study. In this mode, it may be
appropriate to use looser convergence tolerances than are used in other power flow solution
applications.
If any line outage contingency cases form one or more swingless islands, such islands are discon-
nected for the solution of that contingency case. Any dc line having at least one converter station
bus in such an island is blocked for that contingency case solution. Similarly, any FACTS device or
GNE device having at least one of its buses in such an island is removed from service for that
contingency case solution. Any such dc line, FACTS device, or GNE device that is a tie branch
between a swingless island and the remaining system generates an alarm.
If the DISPATCH option is included on a SET, CHANGE, INCREASE, DECREASE, ADD or

REMOVE record, the opposite change in the active power boundary condition is distributed among
the Type 2 and 3 buses specified. Note that only Type 2 and 3 buses are allowed to participate in
picking up the active power boundary condition change imposed by the contingency event. Any
other buses specified as participating generate an alarm and are omitted from the power dispatch
calculation. If only non-Type 2 or 3 buses are specified, the system swing bus(es) pick up all of the
active power change.
The AC Contingency Solution function detects the specification of duplicate single- and double-line
outage contingencies and calculates the contingency case solution only for the first specification of
6-89
such a contingency. Any contingency cases involving bus boundary condition contingency events
or more than two-line outage contingency events are not checked for duplication.
It is required that the working case be solved to an acceptable mismatch tolerance prior to executing
the AC Contingency Solution function.
Load Contingencies
When the SET, CHANGE, INCREASE, DECREASE or MOVE contingency commands operate on
LOAD, they operate on the total nominal (i.e., not voltage adjusted) load of the in-service loads
connected to the specified bus. For each load at the bus, its pre-contingent nominal load is the sum
of the nominal constant power, constant current and constant admittance load components; the
effect of any load multiplier associated with an Optimal Power Flow adjustable bus load table is
applied to the constant power component in calculating the total nominal load.
When these contingency commands employ the MW keyword, only those in-service loads at the
specified bus where pre-contingent nominal active power load is positive are modified in these
contingency events.
For the MOVE contingency command, in-service connected load with positive nominal active power
must exist at the FROM bus, and at least one in-service load, regardless of its nominal active power
specification, must be present at the TO bus. Except for the destination bus in the MOVE contin-
gency command, the total active power change is assigned to individual loads at the bus in
proportion to their individual total nominal active power loads. For each participating load at the bus,
its reactive power is modified such that the reactive power to active power ratio remains constant;
the relative proportions of constant power, constant current and constant admittance load compo-
nents also remain constant.
When these contingency commands employ the PERCENT keyword, active and reactive power
components of all three load characteristics of all in-service loads at the bus are both adjusted by
the specified percentage of their pre-contingent nominal load. Thus, the reactive power to active
power ratio remains constant, and the relative proportions of constant power, constant current and
constant admittance load components remain constant. For the MOVE contingency command, in-
service load must be present at both the FROM and TO buses.
In the MOVE contingency command, all nominal active and reactive power load that is removed
from the FROM bus is transferred to the TO bus. Each such load component retains its original load
characteristic (constant power, constant current or constant admittance).
Shunt Contingencies
SHUNT, they operate on the nominal (i.e., at 1.0 pu voltage) shunt admittance of the in-service fixed
shunts connected to the bus; any switched shunt connected to the bus is not affected by these
commands.
When these contingency commands employ the MW keyword and the initial conductance (i.e., the
active power component) of shunt admittance is non-zero, the shunt susceptance (i.e., its reactive
power component) is modified such that the susceptance to conductance ratio remains constant.
When these contingency commands employ the MW keyword and the initial conductance of shunt
admittance is zero, the specified change is applied to the conductance but the susceptance is
unchanged.
6-90
When these contingency commands employ the MVAR keyword, the specified change is applied to
the susceptance, but the conductance is unchanged.
When these contingency commands employ the PERCENT keyword, the conductance and suscep-
tance components of all in-service fixed shunts at the bus are both adjusted by the specified
percentage of their pre-contingent nominal values. Thus, the conductance to susceptance ratio
remains constant.
Generation Contingencies
GENERATION, the specified buses must have one or more in-service machines connected to them.
These contingency commands operate on the total active power output of the in-service machines
connected to the specified bus(es); reactive power limits are not modified.
When these contingency commands employ the MW keyword, the total plant active power is modi-
fied accordingly.
When the SET contingency command employs the PERCENT keyword, the total plant active power
is set to the specified percentage of its original power. When the CHANGE, INCREASE,
DECREASE or MOVE contingency commands employ the PERCENT keyword, the plant active
power is modified by the specified percentage of the magnitude of its initial setting.
6.10.7 Implementing Generation Dispatch Algorithm in Contingency

Analysis
Run Activity AC Contingency Solution with Generation Dispatch - GUI

Power Flow > Solution > Implement generation dispatch…
[Implement Generation Dispatch]
For each contingency, automatic contingency analysis imposes the contingency, implements gener-
ation re-dispatch if generation dispatch mode is enabled (see Section 6.9.4, About Generation
Dispatch), and solves ac power flow solution sequentially. To know how system operation condition
is changed by a contingency, such as bus disconnection, line open/close and changes in bus
boundary condition, and how the imbalances caused by the contingency is apportioned by means
of generation dispatch algorithms, the Implement Generation Dispatch feature is used to impose a
contingency and/or implement generation dispatch, and activity DIFF can then be used to check the
changes made by Implement Generation Dispatch to working case. The modified case can then be
solved by power flow solution.
Processing options include:
Study case: Select to impose a contingency from the contingency list specified in Contin-
gency Description Data file (*.con) or to use working case
Dispatch Mode and Dispatch system: Specify generation dispatch mode and dispatch
subsystem. If Dispatch mode is disabled, buses that are not connected to a swing bus will
be disconnected and imbalances are absorbed by the swing bus in the island.
There are three input files:
6-91
Distribution Factor Data File: a required file that contains contingency descriptions and
subsystem specifications.
Load Throwover Data File: an optional file that contains load throwover data.
Unit Inertia and Governor Data File: an optional file, that contains generator inertia and
governor response data.
6.10.8 Appending Data to a Contingency Solution Output File
Run Append to AC Contingency Solution Output File - GUI

Power Flow > Reports > Append to AC Contingency solution output file…
[Append to AC Contingency Solution Output File]
The Append ACCC function (the APPEND_ACCC API) is used to output system conditions of a
contingency case solution, as contained in a designated Saved Case file, in the form of a Contin-
gency Solution Output file. This is useful for the situation in which the specification and/or solution
of a contingency case exceeds the capability of the AC Contingency Solution function, but the user
wishes to have the contingency case reported along with, and in the same format as, the contin-
gency cases calculated by the AC Contingency Solution function. The user specifies the following
data items:
1. An append output option flag indicating either that the results for the contingency case spec-
ified in 4. below are to be appended to the existing Contingency Solution Output file
specified in 5. below, or that a new Contingency Solution Output file is to be written
containing results for both the base case specified in 3. below and the contingency case
specified in 4. below.
2. The name of the Distribution Factor Data file to be used. This file specifies the network
elements to be monitored. When appending results to an existing Contingency Solution
Output file from a previous execution of the AC Contingency Solution function, the Distribu-
tion Factor Data file must be the same one specified to the AC Contingency Solution
function.
3. The name of the Saved Case file containing the pre-contingency power flow case. The
Saved Case in this Saved Case file must be the same case that was present as the PSS®E
working case when the Distribution Factor Data file specified in 2. above was constructed
with activity DFAX. It must also be the Saved Case from which the contingency case was
formed and where the solution is contained in the Saved Case file specified in 4. below.
4. The name of the Saved Case file containing the contingency case solution where the results
are to be placed in the Contingency Solution Output file specified in 5. below. The contin-
gency case must have been formed by imposing status, boundary condition, and/or other
data changes in the pre-contingency case specified in 3. above, and then solved using one
or more of the power flow solution activities.
5. The name of the Contingency Solution Output file into which the results of the contingency
case specified in 4. above are to be placed. When the append output option flag in 1. above
indicates that the contingency case results are to be appended to an existing Contingency
Solution Output file, the name of that file must be specified here, and it must be compatible
with the Distribution Factor Data file specified in 2. above. This function is able to append to
Contingency Solution Output files created by PSS®E-30.0 and later releases of PSS®E.
6-92
6. A contingency label of up to 32 characters used to identify the contingency.
7. The number of text lines to be used to describe the contingency. At least one, and no more
than 16, such lines may be supplied.
8. Text lines of up to 120 characters each of which are used to describe the contingency. The
number of text lines specified must be identical to the value specified in 7. above.
In imposing data changes to the base case to define the contingency case, equipment status,
boundary condition, and other data changes to the base case may be specified. However, funda-
mental topological changes are not allowed. For example, buses or branches may not be added
to, or removed from, the case. Furthermore, the use of activities such as SPLT, JOIN, and LTAP is
prohibited, as is the use of activity MOVE to re-route a branch, and similar functions.
When results for multiple contingency case solutions are to be appended to the same Contingency
Solution Output file, the same Distribution Factor Data file and pre-contingency Saved Case file
must be specified for each of the Append ACCC functions.
6.10.9 AC Contingency Single Run Report
Run Activity AC Contingency Report - GUI

Power Flow > Reports > AC Contingency reports…
[AC Contingency Reports]
AB
The AC Contingency Single Run Report function (the ACCC_SINGLE_RUN_REPORT_3 API) is

able to process Contingency Solution Output files created by PSS®E-30.0 and later releases of
PSS®E.
The following input data is specified to this function:
Table 6-10. AC Contingency Single Run Report Options
Option Description
Base case rating defines line loading limits used in determining overloads in
base case. Default is set in program options (see activity OPTN).
Base case voltage limit defines voltage limits used in determining bus voltage
Base case rating and limit violations in base case. The voltage limits apply to buses specified by
voltage limit: monitor voltage limit records. When processing a Contingency Solution Output
File created by N-1-1 contingency solution (see activity Section 6.14, N-1-1
Contingency Solution), the base case rating and voltage limits are used for
both base case and primary N-1 contingency case.
Contingency case rating define line loading limits used in determining overloads
in contingency case. Default is set in program options (see activity OPTN).
Contingency case rating Contingency case voltage limit defines voltage limits used in determining bus
and voltage limit voltage limit violations in base case. When processing a Contingency Solution
Output File created by N-1-1 contingency solution, the contingency case rating
and voltage limits are used for secondary N-1 contingency case only.
6-93
Table 6-10. AC Contingency Single Run Report Options (Cont.)
Option Description
Reports that can be imported into a spreadsheet program:
• Spreadsheet overload report
• Spreadsheet loading table
• Available capacity table
Report format
• Non-converged network conditions
Reports that are available only for visual inspection:
• .Non-spreadsheet overload report
• Non-spreadsheet loading table
• Non-spreadsheet corrective actions report: a report of overloads and
voltage violations in each network condition where corrective actions are
specified to alleviate the violations, overloads and voltage violations in
corresponding post-corrective action network condition, as well as
specified corrective actions (see Section 6.13.10 Corrective Actions
Options)
Exclude interfaces from
Enable or disable (default) exclusion of interface loadings from all reports.
the report
The user selects those subsystems where bus voltages are to be monitored, the
types of voltage check (voltage band or deviation from base case values), and
threshold values by specifying records in the Monitored Element Data file (see
Section 8.1.3 Monitored Element Data File Contents). In the dialog,
however, is the facility to specify the Minimum contingency case voltage change
for range violations.
If enabled (default), buses where out-of-limits voltages in contingency cases
differ from their base case voltages by less than this minimum change parameter
Perform voltage limit are omitted from any voltage range checking reports. Also, a network condition
check is included in the report if the following conditions are satisfied:
• The number of buses in the largest disconnected island is greater than or
equal to the threshold.
• The number of violations of all three voltage violation categories is greater
than or equal to each respective threshold.
When voltage limit checking is disabled a network condition is included in the
report if the number of buses in the largest disconnected island is greater than or
equal to the threshold.
Exclude elements with
Enable or disable (default) exclusion of monitored branches and interfaces that
base case loading viola-
show loading violations in the base case from being checked and reported in
tions from contingency
overload reports of contingency cases.
reports
Exclude elements with Enable or disable (default) exclusion of monitored buses that show voltage
base case voltage viola- range violations in the base case from the corresponding check in contingency
tions from contingency case reports. This flag applies only to the voltage range violation checks of the
reports overload reports.
6-94
Option Description
Enable or disable (default) exclusion of cases with no overloads from the non-
spreadsheet overload report or the non-spreadsheet corrective actions report.
Exclude cases with no This flag may be used to limit the number of records appearing in these reports.
overloads from non- When disabled, reports identify all converged network conditions; it may indicate
spreadsheet overload that some network conditions have no monitored element loading violations.
When enabled, reports will identify all network conditions and it may indicate that
some network conditions have no overloaded monitored elements.
If enabled, post-tripping network conditions are processed in the same way as
Report post-tripping simu-
contingency netowrk conditions. If disabled, post-tripping network conditions are
lation solutions
excluded from reports (see Section 6.13.7 About Tripping Sequence).
Enable or disable reporting load. Curtailments in contingency network
Report loss of loads
conditions.
Number of low voltage
Filter limiting the converged network conditions included in a report. (default = 0)
range violations
Number of high voltage
range violations
Number of voltage devia-
tion violations
Number of buses in the
largest disconnected Filter limiting the converged network conditions included in a report. (default = 0)
island
Filter limiting the total number of records (monitored elements) that may appear
Maximum elements in in the table, and the cutoff threshold for available capacity table parameter
available capacity table excludes any monitored element where available capacity exceeds this
threshold. (default = 6000)
Percent of flow rating Filter used in determining overloads (default = 100.00)
Minimum contingency Overloaded branches in contingency cases where the contingency case flows
case flow change for differ from their base case flows by less than this parameter are omitted from the
overload report overload report. (default = 0.000)
Minimum contingency For voltage violation reports, those buses where out-of-limits voltages in contin-
case voltage change for gency cases differ from their base case voltages by less than this value are
range violations omitted from any voltage range checking reports. (default = 0.00)
Minimum contingency Increase from the base case value. This suppresses the checking and reporting
case percent loading of monitored elements where contingency case loading does not increase above
increase for overload its base case loading by at least a specified percentage of its base case rating.
reports (default = 0.00)
Cutoff threshold for avail- Any monitored element where available capacity exceeds this value is excluded
able capacity table from the table.
Bus mismatch converged tolerance in MW or Mvar used to treat contingency
Bus mismatch tolerance
cases that have small mismatches but failed to achieve convergence as
(MVA)
converged. (default = 0.50)
Total system MVA mismatch converged tolerance used to treat contingency
System mismatch toler-
cases that have small mismatches but failed to achieve convergence as
ance (MVA)
converged. (default = 5.00)
6-95
Option Description
Contingency Solution
Name of the Contingency Solution Output file (*.acc) to be processed.
Output file
Results for all system conditions that were successfully solved in the AC Contingency Solution func-
tion are included in all but the non-converged network conditions report. In addition, the user may
elect to consider as converged those contingency cases that are close to solution; i.e., those contin-
gency cases that satisfy all of the following conditions are to be treated as converged:
• the AC Contingency Solution function was terminated either due to the maximum iter-
ation limit being exceeded or by the non-divergent option (refer to activity FNSL)
• the largest bus MW and Mvar mismatch magnitudes are less than the specified bus
mismatch converged tolerance data item
• the total system MVA mismatch is less than the specified system mismatch converged
tolerance data item.
The non-converged network conditions report identifies those network conditions that failed to
achieve convergence and which are not treated as converged based on their termination condition
and mismatch level as described above. Thus, the non-converged network conditions report
includes those contingency cases for which the solution was terminated under any of the following
conditions:
• The BLOWN UP condition.

• The ITERATION LIMIT EXCEEDED or TERMINATED BY NON-DIVERGENT OPTION
condition with bus and/or system mismatches exceeding the corresponding mismatch
tolerances described above.
• The TERMINATED BY CONSOLE INTERRUPT condition.
• The SINGULAR JACOBIAN OR 0.0 VOLTAGE condition.
• The converged with stalled or tripped induction machines condition.
Such network conditions are identified in the non-Spreadsheet overload report and the non-
converged network conditions report, and excluded from all other reports.
The converged network conditions included in a report may be limited by filter criteria. Only those
contingencies that satisfy the filter criteria are reported. The following filter criteria are user
assigned; the first two apply to all network conditions, while the last two apply only to contingency
cases:
• Number of low voltage range violations.

• Number of high voltage range violations.
• Number of voltage deviation violations.
• Number of buses in the largest disconnected island.
When voltage limit checking is enabled, a network condition is included in the report if the following
two conditions are satisfied:
6-96
1. For contingency cases, the number of buses in the largest disconnected island is greater
than or equal to the threshold.
2. The number of violations of the first two (for bases cases) or all three (for contingency cases)
voltage violation categories is greater than or equal to each respective threshold.
When voltage limit checking is disabled, a contingency case is included in the report if the number
of buses in the largest disconnected island is greater than or equal to the threshold.
Clearly, specifying a zero for any of the filtering criteria disables filtering according to that criteria.
6.10.10 Single Run Report Formats

In each report format, the first page includes a summary of the linear network analysis data files
used in the AC Contingency Solution function along with the percent loading units (MVA or current)
for transformers and non-transformer branches, which are based on the percent loading units
program option settings at the time the AC Contingency Solution function was executed. If the
Contingency Solution Output file was written by PSS®E-30.3 or later, the solution options used
during the contingency case power flow solutions is tabulated.
When, during the construction of the Distribution Factor Data file (refer to DFAX), the multi-section
line reporting option is enabled (refer to Section 3.3.3 Program Run-Time Option Settings and
activity OPTN), all members of each monitored multi-section line are checked for overloading. For
each such line section reported, both the branch itself and the multi-section line of which it is a
member are identified in the overload report.
The specified percent of flow rating does not affect the values printed as monitored element ratings
in all report formats.
If a line outage contingency forms an island with no Type 3 (swing) bus, the swingless island is
disconnected during the solution of the contingency case. In the overload reports, any monitored
branch that is located in the swingless island, as well as any interface that includes such a branch
as a member, is omitted. In the loading table, such monitored elements have zero reported as their
flows. Any bus in a swingless island is omitted from the voltage report.
The reports are directed to the currently selected output destination (refer to Section 4.4 Virtual
Output Devices).
Overload Report
Each converged network condition that satisfies the filter criteria described above (refer to
Section 6.10.1 AC Contingency Solution Options) is included in the overload report. Loadings on
monitored branches and interfaces are calculated as described in Section 6.10.3 AC Contingency
Output. A branch or interface is reported if the following conditions are satisfied:
• Its rating from the selected rating set is non-zero.

• Its loading exceeds the specified percentage of the selected rating.
• For contingency cases, the difference in loading between the base and the contingency
case exceeds the minimum contingency case flow change tolerance input data item.
For monitored branches in the overload reports, an asterisk (  ) is printed between the bus number
and name of the bus at the end of the branch at which the loading and percent loading are taken.
6-97
In the non-spreadsheet overload report, for each monitored element printed, the pre-contingency
and post-contingency loadings, the rating and the post-contingency percent loading are listed. In
the spreadsheet overload report, for each monitored element printed, the post-contingency loading,
the rating and the post-contingency percent loading are listed.
When the voltage limit checks are enabled in the non-spreadsheet format, the overloaded moni-
tored element report for each system condition is followed by its voltage violation report. The voltage
violations report is presented as described in Section 6.10.3 AC Contingency Output; the report is
limited to only those buses with voltage violations. For each bus printed, both its contingency case
and base case values are printed. Any report block for which no violations are detected is omitted
from the report.
When the voltage limit checks are enabled in the spreadsheet format, the overloaded monitored
element report for all system conditions is followed by the voltage violation report for all system
conditions. The voltage violations report is presented in groups corresponding to the voltage moni-
toring data records specified in the Monitored Element Data file.
For contingency cases, if the voltage change at a bus from its value in the base case is less than
the minimum contingency case voltage change input data item, the bus is omitted from the report.
In the spreadsheet format, a final table identifies event descriptions for each network condition for
which any flow or voltage was tabulated.
An example spreadsheet overload report is shown, partially in Figure 6-18a and 6-18b overleaf.
The report shows initially the rating set and percentage used for checking overloads, followed by
the files used to perform the contingency analysis.
The overload report lists the monitored elements that suffer overloads and the name of the contin-
gency causing the overload. To the right of that listing is the branch Rating, the post-contingency
Flow and the post-contingency flow’s percentage of rating. It should be noted that the first branch
listed, which is from bus 153 to bus 154 has a rating of 350 MVA, an post-contingency flow of 343.2
MVA and a percentage loading of 117%. While the MVA flow is apparently less than the branch
rating, it must be remembered that the rating is based on branch current capacity and 100% voltage.
Ratings are assumed to have been entered as:
MVArated = 3 × Ebase × Irated × 10-6

where:
Ebase = the base voltage in volts of the bus to which the terminal of the branch
is connected.
Irated = the rated phase current in amps.
For this contingency, the MVA flow shown is concurrent with a voltage of 0.832 pu. This corre-
sponding level of current is 17% higher than the branches current capacity.
The monitored interface listed as suffering an overload is identified in the jdmsavnw.mon file, indi-
cating that the interface comprises the three branches shown (see Figure 6-17).
6-98
Figure 6-17. Sample Monitored Interface Description
Following the overloaded element list, the report shows buses where voltage falls outside the spec-
ified range that has an upper threshold of 1.50 pu (a value of 1.05 is more adequate) and a lower
threshold of 0.93 pu. The contingency initiating the voltage reduction is indicated by the bus
number. Note that the list of buses outside the range is limited for only two in Figure 6-18. Finally,
following the listing of the overloaded elements and buses outside Range, the report presents a
legend indicating for each contingency name, the details of the disturbance.
In the non-spreadsheet overload report, for each monitored element printed, the pre-contingency
and post-contingency loadings, the rating and the post-contingency percent loading are listed.
Loading Table
Each converged network condition that satisfies the filter criteria described above (refer to
Section 6.10.1 AC Contingency Solution Options) is included in the loading table. Loadings on
monitored branches and interfaces are calculated as described in Section 6.10.3 AC Contingency
Output. For each monitored element, the selected rating, loading and percent loading are reported.
In the non-spreadsheet format, results are reported in tabular form with four contingency cases per
table. Each group of contingency cases contains a page summarizing the contingency cases being
reported. For each contingency, the contingency label and the events defining the contingency are
listed. The summary page is followed by the loading table. For each monitored element, this table
lists its rating, loading, and percentage loading in the base case network solution, and the loading
and percentage loading for each of the contingency cases reported. Any percentage loading above
the specified percentage threshold is followed by an asterisk (  ). When the multi-section line
reporting option is enabled, all members of each monitored multi-section line are reported.
In the spreadsheet format, the monitored flow results are reported in a table that include the
following fields: the monitored element description, the network condition label, the element’s rating,
the element’s flow, and the element’s percent loading. An asterisk (  ) is printed between the bus
number and name of the bus at the end of the branch at which the loading and percent loading are
taken. A subsequent table identifies event descriptions for each network condition label.
Single branches are listed first, either in the order in which they were specified in the Monitored
Element Data file, or in ascending numerical or alphabetical order, according to the option selected
during the execution of activity DFAX (refer to Section 8.1.6 Operation of Activity DFAX). When
interface loadings are included in the report, the branch loadings are followed by the loading on
interfaces in the order in which they were specified.
When the voltage limit checks are enabled, each loading table is followed by the voltage violations
report.
In the non-spreadsheet format, the voltage violations report is presented as described in

Section 6.10.3 AC Contingency Output; the report is limited to only those buses with voltage viola-
6-99
Figure 6-18. Overload Report from AC Contingency Analysis

b.)
a.)
6-100
tions. For each bus printed, both its contingency case and base case values are printed. Any report
block for which no violations are detected is omitted from the report.
In the spreadsheet format, the voltage violations report includes all buses identified by the moni-
toring data records.
In the spreadsheet format, a final table identifies event descriptions for the converged network
conditions tabulated in the report.
Figure 6-19 shows a partial sample of a loading report obtained using the savnw.sav power flow
case.
Figure 6-19. Sample Loading Report
It can be seen in the report that there are eleven monitored elements, two of which are defined inter-
faces. Their ratings, flow and percentage loadings are listed for the base case and subsequently for
each contingency for which a converged case was obtained.
Available Capacity
The available capacity report provides a worst case summary over all converged system conditions
that satisfy the filter criteria. In this report, each monitored element with a non-zero rating in the
specified rating set is printed no more than once: for the system condition (base case or contin-
gency case) in which its available capacity index is smallest.
Two input data items may be specified to control the contents of the available capacity table: the
maximum number of elements in the available capacity table data item may be used to restrict the
table to the < n > monitored elements with the smallest available capacity indices; the cutoff
threshold for the available capacity table data item may be used to restrict the table to those moni-
tored elements where available capacity indices are less than the specified cutoff threshold.
For each monitored element reported, this table lists: its rating; its base case loading; its worst case
loading, percentage loading, available capacity index, and the system condition (the contingency
case label or BASE CASE) in which the worst case loading occurs. The report indicates the number
of other system conditions in which the monitored element has the same available capacity index
as in the tabulated worst case, and the impact on the monitored element.
Base case (the column headed BASE) and worst case (MAXIMUM) loadings are MVA loadings for
branches and MW loadings for interfaces. Element loadings in the corresponding system condition
are tabulated in the column headed IMPACT. For branches, the IMPACTs are either MVA loadings
or current loadings expressed as MVA, according to the transformer and non-transformer branch
percent loading units program option settings; for interfaces, the IMPACTS are MW loadings. Worst
case percentage loadings are also calculated according to the transformer and non-transformer
branch percent loading units program option settings as described in Section 6.10.3 AC Contin-
gency Output. An available capacity index (the column labeled AVAILABLE) is listed for each
tabulated monitored element. The available capacity index is the difference between the RATING
and the IMPACT.
In the available capacity report, monitored elements are printed in order of increasing available
capacity index. Clearly, elements with negative indices are overloaded in the worst case system
condition.
6-101
This report is terminated with descriptions of those contingency cases that were identified as worst
case system conditions for one or more monitored elements. This contingency case summary lists
contingency cases in the order in which they were calculated.
Figure 6-20 shows the capacity report for the savnw.sav power flow case. It can be seen that the
Interface West suffers the greatest capacity deficiency, followed by the branches from bus 154 to
buses 153 and 203. Other listed branches and interface show, for the contingencies tested (and
converged) an available capacity for increased flow.
6-102
6-103
Figure 6-20. Sample Capacity Report from the savnw.sav Power Flow Case
6-104
Non-converged Network Conditions

The non-converged network conditions report identifies each network condition that fails to meet
the convergence criteria as described above (refer to Section 6.10.9 AC Contingency Single Run
Report). The report format is suitable for import into a spreadsheet program.
The user specified values of bus mismatch converged tolerance and system mismatch converged
tolerance are identified following the report title. A table of non-converged networks is presented
that identifies: the contingency label, the largest bus mismatch magnitude, the system mismatch
magnitude, and the termination condition from the AC Contingency Solution function. A subsequent
table identifies event descriptions for each contingency label.
For the savnw.sav power flow case, Figure 6-21 shows the Report. It can be seen that five contin-
gencies have failed to converge. The user, at this point has the option of re-testing the ac
contingencies using the non-divergent power flow solution with this automated approach or to
examine each contingency heuristically using a variety of solution methods and solution controls.
Often the problem is a lack of voltage support.
6-105
6-106
Figure 6-21. Non-Converged Network Report Example
6-107
Corrective Action Report

To have corrective action reports, contingency analysis output file must be produced by multiple-
level contingency analysis initiated with perform corrective actions (see Section 6.13 Performing
Multi-Level AC Contingency Solution).
Each network condition, which causes violations and for which corrective actions are specified to
relieve the violations, is included in the non-spread sheet corrective action report, if it satisfies the
filter criteria. After each network condition is solved, flow overloads and bus voltage violations are
identified by the operating limits specified prior to multiple level contingency analysis instead of the
rating setting and percent of rating specified in single run ACCC report.
The corrective actions results also depend on running mode specified prior to multiple contingency
analysis. The running mode is specified according to selections of three options in contingency
analysis: perform multiple contingency analysis, perform tripping simulation (see Section 6.13.7
About Tripping Sequence) and perform corrective actions (see Section 6.13.10 Corrective Actions
Options). When contingency analysis is initiated with perform tripping simulation, flows and volt-
ages in post-tripping network conditions are checked against limits, corrective actions are then
specified to alleviate flows and voltages violations if any.
To reproduce the complete sequences that had been simulated, and present corrective actions and
violations that had been identified and activated corrective actions during contingency analysis,
some options in AC Contingency Single Run report are not allowed to select, but set by programs
when the report option is a corrective action report as follows:
• Enabled:
- Perform voltage limit check
- Report post-tripping simulation solutions
• Not enabled:
- Exclude interfaces from report
- Exclude elements with base case loading violations from contingency reports
- Exclude elements with base case voltage range violations from contingency
reports
- Exclude cases with no overloads from non-spreadsheet overload report
• Taken from the rating set specified prior to contingency analysis:
- Base case rating
- Contingency rating
- Percent of flow rating
In the summary page, input files and options used in contingency analysis are presented. For each
network condition that satisfies conditions, post-contingency solution is reported first, then followed
by post-tripping solution and post-corrective action solution. Each solution is presented in the
format similar to non-spread sheet overload report format. For each monitored element printed, the
pre-contingency loading, one of post-contingency, post-tripping and post-corrective action loading,
the rating and the corresponding percent loading are listed. For each bus printed, voltage in one of
post-contingency, post-tripping and post-corrective action solutions, base case voltage are printed.
Violations in solutions are followed by correctives actions specified for the network condition.
Corrective actions are grouped by control types: generator active power dispatch, load shedding,
6-108
phase shift angle adjustment, off-line generator active power dispatch, tap setting adjustment and
switched shunt control. In each division, the initial value and the change of a control are reported in
its unit. Generator active power dispatch, load shedding and off-line generator active power control
are in MW; phase shifter angle adjustment is in degree, tap setting adjustment is in pu, and switched
shunt control is in MVAR.
Figure 6-22 shows a partial sample of a corrective action report. In the sample, contingency 1_5
causes an interface flow overloading and two bus voltage violations. In post-corrective action solu-
tion, the loading of the interface is decreased to 100.2 percent of rating A and two bus voltage
violations still exist. The corrective actions involved are generation re-dispatch of five generators,
load shedding at four buses and one phase shift angle adjustment.
6-109
6-110
Figure 6-22. Sample Corrective Action Report
6-111
6.10.11 AC Contingency Multiple Run Report
Run AC Contingency Multiple Run Report - GUI

Power Flow > Reports > Multiple AC Contingency run report…
[Multiple AC Contingency Run Report]
AB
The AC Contingency Multiple Run Report function (the ACCC_MULTIPLE_RUN_REPORT API) is

used to report the results of up to twenty-two executions of the AC Contingency Solution function.
This report function is able process Contingency Solution Output files created by PSS®E-30.0 and
later releases of PSS®E.
The following input data is specified to this function (Table 6-11 AC Contingency Multiple Run
Report Options):
Table 6-11. AC Contingency Multiple Run Report Options
Option Description
Flag to enable (default) or disable the printing of the Monitored Element
Monitored elements summary
Summary Report.
Flag to enable (default) or disable the printing of the Missing Monitored
Missing monitored elements
Elements Report.
Missing monitored voltage Flag to enable (default) or disable the printing of the Missing Monitored
buses Voltage Buses Report
Flag to enable (default) or disable the printing of the Missing Contingencies
Missing contingencies
Report
Flag to enable (default) or disable the printing of the Non-converged Contin-
Non-converged contingencies
gencies Report
Options for the Contingency Summary Report and the Contingency
Legend. Control options are:
• No: contingency summary and legend reports disabled
• Complete master legend report only
Contingency legend
• Reduced contingency legend with each table in which contingencies
are referenced
• Both master legend report and a reduced contingency legend with
each table in which contingencies are referenced (default)
Options for the Loading Violations Report. Control options are:
• No: loading violation reports disabled
Loading violations • Base case and worst case contingency violations only (default)
• Base case and all contingency violations
• Base case, worst case contingency, and all contingency violations
6-112
Table 6-11. AC Contingency Multiple Run Report Options (Cont.)
Option Description
Options for the Voltage Violations Report. Control options are:
• No: voltage violation reports disabled
Voltage violations • Base case and worst case contingency violations only
• Base case and all contingency violations
• Base case, worst case contingency, and all contingency violations
Selection of one of the following to be used as a column heading to identify
the run being reported in the column:
Column headings
• AC Contingency report filenames (default)
• Saved case filenames as contained in the ac report files
Rating set to be used in determining base case monitored element loading
violations (default set by activity OPTN)
Base case rating set and • Rate A, B, C
voltage limit Voltage limit to be used in determining bus voltage limit violations in base
case
Normal, Emergency
Rating set to be used in determining contingency case monitored element
loading violations (default set by activity OPTN)
Contingency case rating set • Rate A, B, C
and voltage limit Voltage limit to be used in determining bus voltage limit violations in contin-
gency case
Normal, Emergency
Include interface loading Flag to enable or disable (default) violation checking and reporting of inter-
violations face loading violations.
Exclude elements with base
case loading violations from Flag to enable or disable (default) exclusion of base case loading violations
contingency reports
Exclude elements with base
case voltage range violations Flag to enable or disable (default) exclusion of voltage range violations
from contingency reports
Percent of flow rating for Percent of flow rating for reporting an element in the loading violation
reporting reports (default = 100.00)
Percent of flow rating for
This value must be at least as large as Percent of flow rating for reporting
counting in worst case contin-
(default = 100.00)
gency violation reports
Minimum contingency case Loading change from a monitored element’s base case loading to enable
flow change for reporting and the checking of its loading in the contingency case loading violation reports.
counting (default = 0.0, to check all monitored elements)
Change from a monitored element’s base case loading to enable the
Minimum contingency case % checking of its loading in the contingency case loading violation reports; the
loading increase for overload base case rating set is used in calculating these percent loadings. (default =
0.0, to check all monitored elements)
6-113
Table 6-11. AC Contingency Multiple Run Report Options (Cont.)
Option Description
Minimum contingency case Change from a monitored bus’ base case voltage magnitude to enable the
voltage for reporting in voltage checking of its voltage in the contingency case voltage range violation
range violation reports. (default = 0.0, to check all buses designated for range checking)
Bus mismatch converged Used to treat contingency cases that have small mismatches but failed to
tolerance (MVA) achieve convergence as converged
System mismatch converged Used to treat contingency cases that have small mismatches but failed to
tolerance (MVA) achieve convergence as converged.
Names of the Contingency Solution Output file (*.acc) to be processed; at
Contingency Solution Output least one is required; up to 22 may be specified. This report function is able
files process Contingency Solution Output files created by PSS®E-30.0 through
the current release.
The AC Contingency Multiple Run Report function is designed to work best for the situation in which
different base cases of essentially the same system (e.g., different seasons, loading levels, and/or
years), with the same setting of the transformer percent loading units program option setting, and
with the same setting of the non-transformer branch percent loading units program option setting
are each presented to the AC Contingency Solution function with its Distribution Factor Data file
based on the same set of linear network analysis data files (refer to Section 8.1.1 Linear Network
Analysis Data Files). Typically, each base case is brought into PSS®E, activity DFAX is executed,
and the AC Contingency Solution function executed; results of each case may then optionally be
individually examined using the Single Run Output Report function (refer to Section 6.10.9 AC
Contingency Single Run Report). After all base cases have been processed, the AC Contingency
Multiple Run Report function may be used to obtain combined reports for up to twenty-two such
runs.
The AC Contingency Multiple Run Report function constructs a master monitored element list
containing all branches and interfaces that are monitored in at least one of the Contingency Solution
Output files being processed. An element’s rating corresponding to an Contingency Solution Output
file is taken from the appropriate rating set as contained in the file.
The AC Contingency Multiple Run Report function constructs a master monitored voltage bus list
containing all buses where voltages are monitored in at least one of the Contingency Solution
Output files being processed.
The set of voltage range and deviation checks to be performed is taken from the first Contingency
Solution Output file specified. That is, the voltage checks performed by the AC Contingency Multiple
Run Report function correspond to the MONITOR VOLTAGE records (refer to Voltage Monitoring
Records) contained in the Distribution Factor Data file used in the AC Contingency Solution run
corresponding to the first Contingency Solution Output file specified (recall that these MONITOR
VOLTAGE records are taken from the Monitored Element Data file specified at the time Distribution
Factor Data file is constructed). Each voltage check is performed on the buses specified for it in the
first run, as well as for any additional buses specified in other runs containing the identical
MONITOR VOLTAGE record. Any voltage check not present in the first Contingency Solution
Output file but in one of the other files is omitted from the voltage violation reports.
The AC Contingency Multiple Run Report function constructs a master contingency list containing
all contingencies for which the results are contained in at least one of the Contingency Solution
6-114
Output files being processed. The process of matching up contingencies from the various runs
depends upon the method by which the contingency was specified.
A contingency case where the contingency label contains SINGLE (or DOUBLE) as its first six char-
acters, and which is comprised of one (or two) contingency events, is assumed to have been
generated as a result of one of the automatic contingency specification data records (refer to Auto-
matic Contingency Specification) in the Contingency Description Data file. Such contingencies are
matched up among the various output files by comparing the text description(s) of the event(s)
comprising the contingency. The sixth (or fifth and sixth) character of the contingency label (i.e., E
or LE) of such contingencies is replaced by one or two digits(1 through 22) indicating the Contin-
gency Solution Output file in which it is first encountered.
Similarly, a contingency case where the contingency label contains OVRLOD, VLTAGE, ISLAND,
or UNIT as its first six characters, and which is comprised of a single contingency event, is assumed
to have been generated by activity RANK. Such contingencies are matched up using the same
approach as described above.
All other contingency cases are assumed to have been specified in the Contingency Description
Data file using the contingency case block structure (refer to Contingency Case Block Structure).
Such contingency cases are matched up among the various output files according to their contin-
gency labels. Clearly, for this process to be effective, unique contingency labels must be specified
in each Contingency Description Data file; further, if multiple Contingency Description Data files are
used, contingency label usage among these files must be coordinated.
Results for all system conditions that were successfully solved in the AC Contingency Solution func-
tion are included in all but the Non-converged Contingencies report. In addition, the user may elect
to consider as converged those contingency cases that are close to solution; i.e., those contingency
cases that satisfy all of the following conditions are to be treated as converged:
• the AC Contingency Solution function was terminated either due to the maximum iter-
ation limit being exceeded or by the non-divergent option (refer to FNSL)
• the largest bus MW and Mvar mismatch magnitudes are less than the specified bus
mismatch converged tolerance data item
• the total system MVA mismatch is less than the specified system mismatch converged
tolerance data item.
6.10.12 Multiple Run Output Report Formats

The output of the AC Contingency Multiple Run Report function consists of several reports. The first
report is always printed; the remaining reports are included or omitted based upon the values spec-
ified for the various report flag input data items.
Many of the reports present results for the runs being tabulated in column format, where columns
correspond to the NFILES Contingency Solution Output files being processed. The column heading
corresponding to each Contingency Solution Output file is either the name of the Contingency Solu-
tion Output file or the name of the Saved Case file as contained in the Contingency Solution Output
file, according to the value of the column headings code input data item.
When, during the construction of the Distribution Factor Data file (refer to DFAX), the multi-section
line reporting option is enabled (refer to Section 3.3.3 Program Run-Time Option Settings and
activity OPTN), all members of each monitored multi-section line are included as monitored
elements. For each such line section reported in the Loading Violations reports, only the branch
6-115
itself is identified; both the branch itself and the multi-section line of which it is a member are iden-
tified in the Monitored Element Summary report.
If a line outage contingency forms an island with no Type 3 (swing) bus, the swingless island is
disconnected during the solution of the contingency case. In the loading violations reports, any
monitored branch that is located in the swingless island, as well as any interface that includes such
a branch as a member, is omitted. Any bus in a swingless island is omitted from the voltage viola-
tions reports.
The percent loading values tabulated for each Contingency Solution Output file reflect the settings
of the non-transformer branch percent loading units option setting and the transformer percent
loading units program setting that existed in the working case at the time the Contingency Solution
Output file was constructed. These settings are listed for each Contingency Solution Output file
being processed in the AC Contingency Solution Output files report. However, the title boxes of the
base case loading violation report, the contingency case all loading violations report, and the contin-
gency case worst case loading violations report all include a line indicating the percent loading units
for transformers and non-transformer branches as contained in the last Contingency Solution
Output file specified.
The reports are directed to the currently selected output destination (refer to Section 4.4 Virtual
Output Devices).
Contingency Solution Output Files Report

The Contingency Solution Output files report is always included in the output of the AC Contingency
Multiple Run Report function. This report lists the following for each Contingency Solution Output
file specified:
• the name of the Contingency Solution Output file.

• the name of the most recently accessed Saved Case file at the time that the AC Con-
tingency Solution function was executed.
• the two line case title of the working case at the time that the AC Contingency Solution
function was executed.
• the name of the Distribution Factor Data file specified to the AC Contingency Solution
function.
• the name of the Subsystem Description Data file specified to, and used by, activity
DFAX in constructing the Distribution Factor Data file.
• the name of the Monitored Element Data file specified to, and used by, activity DFAX
in constructing the Distribution Factor Data file.
• the name of the Contingency Description Data file specified to, and used by, activity
DFAX in constructing the Distribution Factor Data file.
• the percent loading units (MVA or current) for transformers and non-transformer
branches, which are based on the percent loading units program option settings at the
time the AC Contingency Solution function was executed.
• if the Contingency Solution Output file was written by PSS®E-30.3 or later, the solution
options used during the contingency case power flow solutions.
Monitored Element Summary Report

The Monitored Element Summary report lists the following for each monitored element:
6-116
• the description of the branch or interface as obtained from the Contingency Solution
Output file in which it is first encountered.
• the element’s rating(s) from the appropriate rating set(s) as obtained from the Contin-
gency Solution Output file in which it is present, the element’s rating - Contingency
Solution Output file pair is blank when the element is not present in the corresponding
Contingency Solution Output file; neither of the percent of rating input values affects
the value printed as the element’s rating(s).
• if a branch is a member of a multi-section line in the Contingency Solution Output file
in which it is first encountered, the multi-section line description as obtained from that
Contingency Solution Output file.
Missing Monitored Elements Report

The Missing Monitored Elements report lists members of the master monitored element list that are
specified as monitored elements in some, but not all, of the Contingency Solution Output files being
processed.
Missing Monitored Voltage Buses Report

The Missing Monitored Voltage Buses report lists members of the master monitored voltage bus list
that are specified as monitored voltage buses in some, but not all, of the Contingency Solution
Output files being processed. It also tabulates MONITOR VOLTAGE records specified in any of the
Contingency Solution Output files being processed that are not present in the first Contingency
Solution Output file; the voltage range and deviation checks corresponding to such records are not
performed by the AC Contingency Multiple Run Report function.
Contingency Summary Report

The Contingency Summary report lists members of the master contingency list. For each contin-
gency, the report tabulates the contingency label used to identify the contingency in the AC
Contingency Multiple Run Report function and the events comprising the contingency. This report
is included in the output of the AC Contingency Multiple Run Report function if the value specified
for the contingency legend flag data item is 1 or 3.
Missing Contingencies Report

The Missing Contingencies report lists members of the master contingency list that are specified as
contingencies in some, but not all, of the Contingency Solution Output files being processed.
A contingency legend follows this report if the value specified for the contingency legend flag data
item is 2 or 3. For each contingency listed in the report, the contingency legend tabulates the contin-
gency label used to identify the contingency in the AC Contingency Multiple Run Report function
and the events comprising the contingency.
Non-converged Contingencies Report

The Non-converged Contingencies report lists members of the master contingency list that failed to
meet the convergence criteria as described above (refer to Section 6.10.11 AC Contingency
Multiple Run Report), along with the network solution termination condition from the AC Contin-
gency Solution function. The user specified values of the bus mismatch converged tolerance and
the system mismatch converged tolerance are listed at the beginning of the report.
6-117
Base Case Loading Violations Report

The Base Case Loading Violations report lists members of the master monitored element list where
loading exceeds the specified reporting percentage of the selected rating in the base case of one
or more of the Contingency Solution Output files. This report is included in the output of the AC
Contingency Multiple Run Report function if the value specified for the loading violations report flag
data item is 1, 2 or 3.
For each violation, the report tabulates MVA loadings for branches and MW loadings for interfaces.
Percentage loadings are calculated as described in Section 6.10.3 AC Contingency Output,
according to the transformer and non-transformer branch percent loading units program option
settings. Interface violations are included in the report only if a value of 1 is specified for the interface
option flag data item.
Contingency Case All Loading Violations Report

The Contingency Case All Loading Violations report lists members of the master monitored element
list where loading exceeds the specified reporting percentage of the selected rating in a contingency
case of one or more of the Contingency Solution Output files. This report is included in the output
of the AC Contingency Multiple Run Report function if the value specified for the loading violations
report flag data item is 2 or 3.
For each violation, the report tabulates the label of the contingency causing the loading violation. It
lists MVA loadings for branches and active power loadings for interfaces. Percentage loadings are
calculated as described in Section 6.10.3 AC Contingency Output, according to the transformer and
non-transformer branch percent loading units program option settings.
If a value of 1 is specified for the exclude base case loading violations from contingency case
reports flag, a violation is included in the table only if the element was not in violation in the base
case. If the minimum contingency case loading change data item is positive, a violation is included
in the table only if the element’s loading in the contingency case differs from its corresponding base
case loading by the specified value. If the minimum contingency case percent loading increase data
item is positive, a violation is included in the table only if the element’s loading in the contingency
case, expressed as its percent loading relative to the its base case rating, exceeds its corre-
sponding base case loading by the specified value. Interface violations are included in the report
only if a value of 1 is specified for the interface option flag data item.
Contingency Case Worst Case Loading Violations Report

The Contingency Case Worst Case Loading Violations report lists members of the master moni-
tored element list where loading exceeds the specified recording percentage of the selected rating
in a contingency case of one or more of the Contingency Solution Output files. This report is
included in the output of the AC Contingency Multiple Run Report function if the value specified for
the loading violations report flag data item is 1 or 3.
6-118
This report can be considered a compressed form of the Contingency Case All Loading Violations
report (refer to Contingency Case All Loading Violations Report). Each row of the report lists a moni-
tored element along with the label of the contingency that causes the most severe contingency case
loading violation of that element in one or more of the Contingency Solution Output files. For each
monitored element - Contingency Solution Output file pair (i.e., for each cell in the table) having a
non-blank entry, this report lists the most severe loading violation of the element from among all
contingencies in the Contingency Solution Output file. Thus, while there could be several rows for
the same monitored element in the table, each will be paired with a different contingency label and
each column of the table will have a non-blank cell in at most one of these rows for the same moni-
tored element.
For each violation reported, the report tabulates MVA loadings for branches and active power load-
ings for interfaces. Percentage loadings are calculated as described in Section 6.10.3 AC
Contingency Output, according to the transformer and non-transformer branch percent loading
units program option settings. It also lists a count of the number of contingency cases in this Contin-
gency Solution Output file, including the contingency case listed, in which the loading on the
element exceeds the specified percentage of flow rating for counting violations.
If a value of 1 is specified for the exclude base case loading violations from contingency case
reports flag, a violation is included in the table only if the element was not in violation in the base
case. If the minimum contingency case loading change data item is positive, a violation is included
in the table only if the element’s loading in the worst case contingency case differs from its corre-
sponding base case loading by the specified value. If the minimum contingency case percent
loading increase data item is positive, a violation is included in the table only if the element’s loading
in the worst case contingency case, expressed as its percent loading relative to the its base case
rating, exceeds its corresponding base case loading by the specified value. Interface violations are
included in the report only if a value of 1 is specified for the interface option flag data item.
Base Case Voltage Violations Reports

The Base Case Voltage Violations reports list members of the master monitored voltage bus list
where voltage magnitude fails the corresponding range test in the base case of one or more of the
Contingency Solution Output files. This report is included in the output of the AC Contingency
Multiple Run Report function if the value specified for the voltage violations report flag data item is
1, 2 or 3.
The voltage violations report is presented as described in Section 6.10.3 AC Contingency Output.
For each violation, the report tabulates the voltage magnitude in per unit.
Contingency Case All Voltage Violations Reports

The Contingency Case All Voltage Violations reports list members of the master monitored voltage
bus list where voltage magnitude fails the corresponding range or deviation test in a contingency
case of one or more of the Contingency Solution Output files. This report is included in the output
of the AC Contingency Multiple Run Report function if the value specified for the voltage violations
report flag data item is 2 or 3.
6-119
For each violation, the report tabulates the label of the contingency causing the voltage violation
and the voltage magnitude in per unit.
If a value of 1 is specified for the exclude base case voltage range violations from contingency case
reports flag, a voltage range violation is included in the table only if bus voltage was within the corre-
sponding range in the base case. If the minimum contingency case voltage change data item is
positive, a violation is included in a range violation table only if bus voltage magnitude in the contin-
gency case differs from its base case voltage magnitude by the specified value.
Contingency Case Worst Case Voltage Violations Reports

The Contingency Case Worst Case Voltage Violations reports list members of the master monitored
voltage bus list where voltage magnitude fails the corresponding range or deviation test in a contin-
gency case of one or more of the Contingency Solution Output files. This report is included in the
output of the AC Contingency Multiple Run Report function if the value specified for the voltage
violations report flag data item is 1 or 3.
These reports can be considered a compressed form of the Contingency Case All Voltage Viola-
tions reports (refer to Contingency Case All Voltage Violations Reports). Each row of the report lists
a monitored bus along with the label of the contingency that causes the most severe contingency
case voltage range or deviation violation of that bus in one or more of the Contingency Solution
Output files. For each monitored bus - Contingency Solution Output file pair (i.e., for each cell in the
table) having a non-blank entry, this report lists the most severe voltage violation of the bus from
among all contingencies in the Contingency Solution Output file. Thus, while there could be several
rows for the same monitored bus in the table, each will be paired with a different contingency label
and each column of the table will have a non-blank cell in at most one of these rows for the same
bus.
For each violation reported, the report tabulates the voltage magnitude in per unit. It also lists a
count of the number of contingency cases in this Contingency Solution Output file, including the
contingency case listed, in which the bus fails the corresponding range or deviation test.
If a value of 1 is specified for the exclude base case voltage range violations from contingency case
reports flag, a voltage range violation is included in the table only if bus voltage was within the corre-
sponding range in the base case. If the minimum contingency case voltage change data item is
positive, a violation is included in a range violation table only if bus voltage magnitude in the worst
case contingency case differs from its base case voltage magnitude by the specified value.
Section 16.6, Multiple AC Contingency Run Reports
6-120
6.10.13 ZIP Archive Output File

A ZIP Archive Output File may optionally be written during the AC Contingency Analysis, P-V Anal-
ysis, and Q-V Analysis functions.
RunDetails.txt
Most of the files that are preserved in the ZIP Archive Output File are in binary form, and are acces-
sible only to PSS®E functions. There is, however, one source file that may be extracted from the
ZIP Archive Output File and examined by the user. The source file RunDetails.txt contains informa-
tion about the execution of the contingency analysis function that created it. This information
includes:
• the name of the API routine that created the ZIP Archive Output File.
• the time and date of its writing.
• the names of any files that were used as input to the calculation function.
• the names of any files that were written by the calculation function.
• the values of other inputs to the API routine which define various solution and other
options used in the calculation.
Listing System Conditions Represented in a ZIP Archive Output File

The ListContingencySavedCases API routine is used to produce a tabulation at the Report device
of system conditions for which data is stored in the ZIP Archive Output File.
The ListContingencySavedCases API routine includes the following among its inputs:
• the name of the ZIP Archive Output File.

• a label indicating the system condition(s) that are to be tabulated: blank to list all system
conditions; a contingency label to list all system conditions for the specified contin-
gency label; or “Base Case” to list all system conditions for the base case (use “Base
Case” only for ZIP Archive Output Files written by the P-V and Q-V analysis functions).
For each system condition that is tabulated, the contingency label is listed, along with the name of
an Incremental Saved Case File (the .isv file) that contains data pertaining to the solution of the
system condition. For ZIP Archive Output Files written by the P-V Analysis function, the incremental
transfer level that is applied is also listed; for ZIP Archive Output Files written by the Q-V Analysis
function, the voltage at the study bus is also listed.
Bringing Contingency Case Conditions into the Working Case

The GetContingencySavedCase API routine is used to place the working case in the form of a spec-
ified system condition as calculated during a previous run of the AC Contingency Analysis, P-V
Analysis, or Q-V Analysis function. This function retrieves data from a ZIP Archive Output File that
was created during the run of the contingency calculation function.
The GetContingencySavedCase API routine includes the following among its inputs:
• the name of the ZIP Archive Output File.

• the name of an Incremental Saved Case File (.isv file) contained in the ZIP Archive
Output File.
6-121
AC Corrective Actions Program Operation Manual
6.11 AC Corrective Actions
Run AC Corrective Actions - GUI

Power Flow > Solution > AC corrective actions…
[AC Corrective Actions]
AB
Corrective actions are modeled as an optimal power flow problem. The objective function is to mini-
mize the control adjustments needed to remove limit violations in the power system. The constraints
include equality and inequality constraints, namely power flow equations and limits of controls and
operation conditions.
6.11.1 Constraints and Controls

The corrective action algorithm recognizes several types of constraints and controls. Constraints
are operating limits imposed on bus voltages, branch flows, or power transfers over interfaces. The
system problems identified in a contingency analysis are the violations of such constraints. Controls
include generator active powers, phase shifter angles, bus load curtailments, off-line generator
active powers, tap positions and reactive power of switched shunts. The objective of the corrective
action algorithm is to observe all constraints while minimizing the weighted sum of control adjust-
ments within their upper and lower bounds. The priorities of control actions are:
1. Phase shifter angle adjustment
2. Tap setting adjustment
3. Switched shunt reactive power control
4. Generator active power dispatch
5. Off-line generator active power dispatch
6. Load curtailment (if required)
This priority order is maintained by assigning a higher cost to the lower priority controls.
Constraints are the power system operating limits that need to be observed. The corrective action
algorithm allows three types of constraints that are defined in the Distribution Factor Data file:
Table 6-12. AC Corrective Action Constraints
Constraint Description
Branch flow limits are obtained from the designated rating set, adjusted by a
specified multiplying factor. Percent loadings of monitored elements based on
ratings are specified as either Current or MVA percent loadings by percent
Branch flows units program settings (see activity OPTN), and used in determination of over-
loading. Any branch where the rating in the designated rating set is zero is
excluded from the set of constraint; zero impedance lines are also excluded
from the set of constraints in the correction actions solution.
6-122
Program Operation Manual AC Corrective Actions
Table 6-12. AC Corrective Action Constraints (Cont.)
Constraint Description
Interface flow is defined as the sum of MW flow of its members. Each interface
is specified in terms of the from bus, to bus and circuit identifier of each of its
Interface MW
members. Flow is computed at the from bus end of each circuit in the interface.
flows
If an interface consists of one or more zero impedance branches, or its rating
in the designated rating set is zero, it will be excluded from constraints.
High and low voltage limits for each bus are defined in per unit. Voltage limits
can be specified on a system-wide basis, for the study area only, or for indi-
vidual areas, zones and buses. If a bus voltage is monitored by several sets of
upper and lower limits, the maximum of upper limits of all sets is selected as
Bus voltages the upper limit and the minimum of lower limits of all sets is selected as the
lower limit for the bus voltage respectively. Note that voltage deviation limits
are not checked in corrective action calculations. For a generator bus, if the
generator has sufficient reactive power generation to maintain its scheduled
voltage, the generator bus is excluded from the constraint set.
Controls are the actions that can be taken to correct branch loading, bus voltage and interface flow
limit violations in a power system. There are six categories of controls modeled in the corrective
actions computation:
Table 6-13. AC Corrective Action Controls
Control Description
Generator
Generators in the generator control subsystem that have a adjustable range
active power
are available for corrective action analysis.
dispatch
The desired MW flow values in the power flow database for participating phase
shifters are ignored in the corrective action analysis. After a corrective action is
Phase shifter
performed successfully, the upper and lower limits (VMA and VMI) of a phase
angle
shifter specified in corrective actions are reset based on its flow in post-correc-
adjustment
tive solution, while the difference between upper and low limits remains
constant.
Bus active power load can be curtailed as needed to correct system problems.
Load
The reactive power load is adjusted accordingly to maintain a constant power
curtailment
factor of load at the bus.
Off-line generators in the off-line generator control subsystem that have a
Off-line gener- adjustable range are available for corrective action analysis. The reactive
ator active power outputs of the generators remain zeros. After a corrective action is
power dispatch performed successfully, off-line generators specified in corrective actions will
be turn on with the upper and lower limits of reactive power set to zeros.
The transformers in the tap setting adjustment subsystem that are subject to
voltage control mode are available for corrective action analysis. Voltage
controls of participating transformers are ignored in the corrective action anal-
Tap setting
ysis. After a corrective action is performed successfully, the upper and lower
adjustment
limits (VMA and VMI) of a transformer specified in corrective actions are reset
based on bus voltage of the controlled bus in post-corrective solution, while the
difference between upper and low limits remains constant.
6-123
Table 6-13. AC Corrective Action Controls
Control Description
Switched shunt in the switched shunt control subsystem that subject to voltage
control mode are available for corrective action analysis. Voltage controls of
Switched shunt participating switched shunts are ignored in the corrective action analysis.
reactive power After a corrective action is performed successfully, the upper and lower limits
control (VSWHI and VSWLO) of a switched shunt specified in corrective actions are
reset based on bus voltage of the controlled bus in post-corrective solution,
while the difference between upper and low limits remains constant.
6.11.2 Weighting and Penalty Functions

The corrective action algorithm finds an optimal solution by minimizing the weighted sum of the indi-
vidual controls. The weight for each control is given by its weighting function. The corrective actions
are influenced by these weighting functions and the relative effectiveness of the respective controls
in eliminating the system problems.
Two types of weighting functions for controls are used: a linear function for load shedding and V-
curves for other controls such as MW generation and phase shifter angle; Figure 6-23, Figure 6-24
and Figure 6-25 show weighting functions for generator active power dispatch, load curtailment and
phase shifter angle adjustment. Controls in one category have the same weighting function.
Figure 6-23. Active Power Generation Control Default Weighting Function
6-124
Figure 6-24. Load Shedding Control Default Weighting Function
Figure 6-25. Phase Shifter Angle Control Default Weighting Function
Load curtailment should be assigned a much higher weight than generator real power dispatch to
prevent unnecessary load curtailment when generation rescheduling is adequate in relieving the
system problems. Moderate changes of the weights from the default values generally have little
influence on the corrective actions because the sensitivities expressing the effectiveness of indi-
vidual actions tend to dominate. A large weighting factor discourages the control from being
adjusted. Therefore, you can favor certain controls over others by specifying smaller external
weights. However, please note that extremely large or small weights may cause solution problems.
For this reason, it is recommended that weights be limited to the range from 0.1 to 10.
If the limit violations in the power system cannot all be eliminated using the basic control actions, it
may be preferable sometimes to accept certain degree of limit violations instead of applying
6-125
extreme and ineffective control adjustments. This strategy can be represented by applying soft
penalties to the constraints.
The penalties for constraint violations are represented by multi-segment linear functions. The
internal penalties for the first two segments for branch loading and bus voltage constraints are 1000
and 10000, respectively, as shown in Figure 6-26 and Figure 6-27. These penalties cannot be
adjusted.
Figure 6-26. Branch/Interface Flow Overload Penalty Function
Figure 6-27. Bus Voltage Violation Penalty Function
6-126
6.11.3 AC Corrective Action Options

The following options are available in the ac corrective actions menu.
Table 6-14. AC Corrective Action Options
Option Description
Select the desired solution options to be applied during power flow calculations
Solution options with corrective actions (see Section 6.10.1 AC Contingency Solution
Options).
Select the desired number of iterations between execution of the linear program-
ming engine to identify corrective actions and subsequent ac power flow solution
to verify the feasibility of those actions. The specified number of iterations can be
between 1 and 10. Note that, even if a feasible solution appears to have been
found, i.e., the identified corrective actions appear to have been successful, the
Number of ac load
iteration between linear programming computation and ac power flow solution
flows
may continue in an attempt to further optimize the solution if not exceeding the
iteration limit. The user needs to select this parameter carefully, based on expe-
rience. On the other hand, if a solution fails at the nth iteration because the ac
power flow diverges, the user may obtain an approximate solution by specifying
the number of ac power flows as n-1 and repeating the calculations.
This tolerance will be used to check for the largest active or reactive power
mismatch in the power flow case prior to the start of the ac corrective actions
Mismatch
computation. If this tolerance is exceeded, the process is terminated. This value
tolerance
is also used as the convergence tolerance for the ac power flow solution
embedded in ac corrective action analysis.
Constraint options Select branch flow rating set, and limit tolerances for monitored elements.
Specify rating to be used in determination of branch and interface flow over-
Rating loads. The default rating set is established by the program option setting (refer to
Section 3.3.3 Program Run-Time Option Settings and activity OPTN).
Percent of flow Specify percent of rating to be used in determination of branch and interface flow
rating overloads.
Defines voltage limits used in determining bus voltage limit violations. The
Voltage limit voltage limits apply to buses specified by monitor voltage limit records (see
Section 8.1.3, Monitored Element Data File Contents).
Specifies branch overload violation tolerance in percent to adjust branch over-
load limits used in corrective actions. The limits are increased by the tolerance
percent of the specified rating when the tolerance is positive, or reduced when it
Branch overload
is negative. For instance, if the tolerance is 0.1% and the overload limit is 100%
violation tolerance
of rate A, the 100.1% of rating A is used in determining overload violations in
corrective actions. In the above case if the tolerance is -0.1%, the 99.9% of
rating A is used.
Specifies bus voltage violation tolerance in pu to adjust the bus voltage limits
used in corrective actions. The limits are expanded by the tolerance when it is
Bus voltage viola- positive, narrowed when it is negative. For instance, if the tolerance is 0.1 pu
tion tolerance and lower and upper limits on a bus voltage are 0.95 and 1.05 in pu respectively.
The adjusted voltage limits are 0.949 and 1.051 respectively. In the above case
if tolerance is -0.1, the lower and upper limits are 0.951 and 1.049.
Control options Select types of control adjustments and specify weighting factors for each type.
6-127
Table 6-14. AC Corrective Action Options (Cont.)
Option Description
Enable to include active power generation dispatch controls. The adjustable
range is from PT to PB of each participating machine. Generator active power
limits are taken from a Generator Inertia and Governor Response Data file (see
Section 6.8.1 Inertia and Governor Response Data File Contents) if the
file is specified, otherwise the values in base case are used. In corrective action
Enable generator analysis, generator active power limits are adjusted by the following rules. If PT
controls had been set to the default value, the larger value of PG (its existing MW output)
and machine power base (MVA base) will be used as PT; If PT of a machine is
less than its PG, the PT is set equal to the PG. If PB of a machine had been set
to the default value, it is set equal to 0; if PB of a machine is less than its PG, the
PB is set equal to the PG. A machine will be excluded from the controls if its PT
is equal to its PB.
Specify a weighting factor to adjust the cost factor of active power generation
dispatch. The cost of a control adjustment in objective functions is equal to the
amount of adjustment times by a adjusted cost factor. The internal cost factor for
Generator active power generation dispatch defined in the programs is shown in Table 6-
weighting factors 15 Weighting Functions and Factors of Controls; the adjusted cost factor is
equal to the internal factor multiplied by the user defined weighting factor. e.g., if
the weighting factor is set as 1.0, the cost factor for active power generation
dispatch of 100 MW will be 1.0.
Generator control Select the subsystem in which all in-service generators with valid range of
subsystem adjustments will participate in corrective action analysis.
Enable to include load curtailments. The loads with negative MW values will be
Enable load
excluded from the controls. While performing load curtailment, the algorithm
controls
maintains a constant power factor at the buses where load curtailment occurs.
Specify a weighting factor to adjust the cost factor of load curtailment. The
internal cost factor for load curtailments defined in the programs is shown in
Load weighting Table 6-15 Weighting Functions and Factors of Controls; the adjusted cost
factors factor is equal to internal factor multiplied by the the weighting factor. e.g., if the
weighting factor of load curtailments is set as 1.0, the cost factor for load shed-
ding of 100 MW will be 100.0.
Select the subsystem in which all in-service loads will participate in corrective
Load control
action analysis. Loads with negative real power will not be included as candi-
subsystem
dates for load curtailments.
Enable to include phase shifter controls. To be adjustable as a phase shifter,
Enable phase
transformers must be operated subject to MW control mode. The adjustable
shifter controls
range of a participating phase shifter is from Rmax to Rmin.
Specify a weighting factor to adjust the cost factor of phase shifter angle adjust-
ments. The internal cost factor for phase shifter angle adjustments defined in the
programs is shown in Table 6-15 Weighting Functions and Factors of
Phase shifter
Controls; the adjusted cost factor is equal to internal factor multiplied by the
weighting factors
user-defined weighting factor. e.g., if weighting factor of phase shifter angle
adjustment is 1.0, the cost factor of phase shifter angle adjustment of 100
degrees is 3.5.
Phase shifter Select the subsystem in which all in-service phase shifters will participate in
control subsystem corrective actions.
6-128
Table 6-14. AC Corrective Action Options (Cont.)
Option Description
Enable to include off-line generator active power shift. The initial active power
Enable off-line
outputs of participating off-line generators are set to zeros. Their active power
generator controls
ranges are specified in the same way as on-line generators
Specify a weighting factor to adjust the cost factor of active power generation
Off-line generator
dispatch of off-line generators. The internal cost factor defined in the programs is
weighting factor
shown in Table 6-15 Weighting Functions and Factors of Controls.
Off-line generator Select the subsystem in which all out-of-service generators with valid range of
control subsystem adjustments will participate in corrective action analysis.
Enable tap setting
Enable to include tap setting adjustment.
adjustments
Specify a weighting factor to adjust the cost factor of tap setting adjustment. The
Tap setting
internal cost factor defined in the programs is shown in Table 6-15 Weighting
weighting factors
Functions and Factors of Controls.
Tap setting adjust- Select the subsystem in which all in-service transformers designated in voltage
ment subsystem control mode will participate in corrective action analysis.
Enable switched
Enable to include switched shunt reactive power controls.
shunt controls
Specify a weighting factor to adjust the cost factor of switched shunt reactive
Switched shunt
power control. The internal cost factor defined in the programs is shown in Table
weighting factors
6-15 Weighting Functions and Factors of Controls.
Switched shunt Select the subsystem in which all in-service switched shunts designated in
control subsystem voltage control mode will participate in corrective actions.
The Distribution Factor Data file is used to provide monitored elements, bus
voltage limits and control subsystems. When creating a Distribution Factor Data
Input Data File
file for corrective action analysis, a Contingency Description Data file where no
contingencies are specified is allowed.
Table 6-15. Weighting Functions and Factors of Controls
Control Weighing Function Internal Weight

Phase shifter Angle V-Curve 2 per 57.4 degrees (0.035 per degree)
MW Generation V-Curve 1 per 100 MW (0.01 per MW)
Load Curtailment Linear 100 per 100 MW (1.0 per MW)
MW generation of Off-
V-Curve 2 per 100 MW
line generator
Tap setting V-Curve 1 per 0.002 pu
MVAR output of
V-Curve 1 per 100 MVAR
Switched shunt
6-129
6.11.4 Viewing AC Corrective Actions Results.

After ac corrective actions solution is performed successfully, a corrective action analysis report is
produced. In the report, files used in the analysis, and numbers of constraints and controls are
presented first. Flow overloads and bus voltage violations prior to and post corrective action anal-
ysis are reported. Specified corrective actions are presented in the order of generation dispatch,
load shedding, phase shifter angle adjustment, off-line generator active power dispatch, tap setting
adjustment and switched shunt control. For each control adjustment, the initial and new values, as
well as the change are reported. Figure 6-28 shows the results of ac corrective actions applied to
an example system (savnw case). In this run, percent MVA and percent CURRENT units are spec-
ified for monitored transformer and non-transformer branches respectively. 8 branches, 2 interfaces
and 6 bus voltages are selected as constraints from monitored elements, 6 generator buses, 7 load
buses, as well as 1 phase shifter are selected as controls from components in specified subsys-
tems. In the report, the base case is found to have four flow violations above 60% of rating A (as an
illustration) including flow overloading on Interface 'WEST', which is 171% of its normal limit. The
report also shows that, after corrective actions have been applied, flows on two branches are
slightly higher than their limits.
6-130
Figure 6-28. Sample Report from Corrective Action Analysis

The corrective actions solution algorithm does not place a limit on the numbers of controls and
constraints that can be modeled. The computation time of corrective actions solution is approxi-
mately proportional to size of the power system and the number of constraints. Because local
controls are generally more effective in removing violations, it may be preferable to choose the
subsystems in which control actions are allowed to be the same as that in which elements are
monitored.
Operating limit violations caused by incorrect limit settings may have a significant impact on the
optimal solution found. Hence, suspicious limits should be verified and corrected, if necessary, or
even removed from the solution.
6-131
PSCOPF Solution Program Operation Manual
Two methods can be used to exclude controls from the corrective actions solution. One is to set the
upper and lower limits of a control to be identical. In addition, to exclude an on-line generator and
off-line generator from the solution, both the upper and lower limits should be equal to the Pgen.
The second method is to specify a control subsystem that does not include undesirable controls in
a particular application.
Because the optimization engine is based on a linear power flow, the result from the linear program-
ming solution is iterated with a standard ac power flow solution until one of following conditions
occurs:
• all overloads and voltage violations are resolved,

• the adjustable controls are exhausted,
• the number of ac power flow solutions reaches the specified value,
• the difference of the values of objective function between two consecutive iterations is
less than a tolerance when both branch overload violation tolerance and voltage viola-
tion tolerance are greater than 0.
• the ac power flow diverges during the process
When ac corrective actions computation fails because of ac power flow divergence, warning
messages in the progress window indicate at which step the ac power flow diverges. The user may
obtain an approximately optimal solution by specifying the number of ac power flow in ac corrective
actions input menu as one less than the step in the solution failure occurs. Or, if the user finds that
the computation may require more iterations to reach an optimal solution, the desired iteration
number may be increased.
Section 11.4, AC Corrective Actions
6.12 PSCOPF Solution
6.12.1 About PSCOPF analysis

Power flow solution solves a set of non-linear equations, i.e. power balance equations, and adjusts
the system to meet branch flows, bus voltages, and area interchange schedules and determines
the flows on branches and voltages at buses.
In an optimal power flow, the solution is formulated as an optimization problem with an objective
function, a set of constraints to satisfy and a set of controls that can be adjusted (see Section 14.3,
Optimal Power Flow, athough that algorithm is not used in PSCOPF). The settings of controls are
determined to achieve the best solution corresponding to a performance measure defined by the
objective function. The optimal objective is dependent on the application. Some common objectives
are:
• Economic dispatch
• Maximum power transfer
• MW and MVAr loss minimization
• Minimum deviation from a target schedule
6-132
Program Operation Manual PSCOPF Solution
• Minimum control shifts to alleviate violations

These objectives can be set individually or combined to form a composite objective function in an
optimal power flow problem. The controls may be applied to existing devices or new installations.
Some typical controls are:
• Generator MW dispatch;
• Transformer taps;
• Phase shift angles;
• Shunt capacitor
• or reactor addition;
• Series compensation level;
• Load shed.
The constraints may include:
• Power balance equations

• Limits on controls and operation limits
The security constrained optimal power flow is a special class of OPF problems which takes into
consideration the system constraints derived from a base case and a set of predefined contingency
cases. System security is the ability to withstand contingencies, in other words, to remain intact
even after equipment outages or failures. Security plays a crucial role in the planning and operation
of a power system. To ensure a secure system operation condition, system planners and operators
can conduct analyses to identify the necessary adjustments such that there are no limit violations
in the base case (pre-contingency) condition and following any contingency.
There are two principal classes of methods to enhance the system security: preventive and
corrective methods. The preventive method enables the system to be prepared for certain contin-
gencies beforehand. The preventive method can be considered conservative, since it does not take
into account the system’s post-contingency control capabilities. All control variables are optimized
such that no post–contingency adjustments are necessary in order to avoid violations of base case
and post-contingency constraints, and no operator intervention is required following an anticipated
contingency. The corrective method helps identify quick and appropriate responses to the contin-
gencies after their occurrence. In recent system security applications, a mixture of the preventive
and corrective method has also been used.
The Preventive Security Constrained Optimal Power Flow (PSCOPF) function formulates and
solves an optimization problem:
With an objective that minimizes the adjustments of the following types of control:
• On-line and off-line generator MW generation control

• Phase shifter adjustments
• Load controls
• Tap setting adjustments
• Switched shunt adjustments
Subject to the following types of constraints:
6-133
• Power balance equations of base case and contingencies cases

• Limits on controls
• Operation limits under base case and contingency cases
When a huge number of contingency cases are considered, the PSCOPF problem becomes a
large-scale optimization problem. Trying to solve this problem directly for a large power system by
simultaneously imposing all the post-contingency constraints could lead to prohibitive computer
memory requirements and CPU time. Benders decomposition is an appropriate solution method to
the large-scale optimization problems. In Benders method, the initial problem is decomposed to
several sub-problems that can be solved separately and iteratively. In using the Benders decompo-
sition method in the PSCOPF function, the master problem is set up with the base case condition
and the cuts from the contingency cases, and a sub-optimization problem is modeled for each
contingency to ensure the feasibility of the solution.
Master problem for Bender’s cuts

Base Case
Subproblem for
Contingency Case 1
Subproblem for
Contingency Case n
Figure 6-29. Two level structure used in the Bender’s decomposition method
A Successive Linear Programming (SLP) method is used to solve the master problem and each
sub-problem (see Section 6.11, AC Corrective Actions). To keep the number of sub-problems small,
a contingency filtering technique that is based on power flow solutions is applied. The critical
contingencies are identified and put in a set. Only the contingencies in the set are represented as
sub-problems.
The inputs required to perform a PSCOPF consist of a power flow network, the available controls
and the constraints. The controls are selected from the control subsystems, which are pre-defined
in the subsystem description data file (*.sub), and each type of control is assigned a priority, relative
to other control types. The operation constraints are defined in the monitored element data file
(*.mon), and the contingencies are specified in the contingency description data file (*.con). Before
initiating the PSCOPF solution, a dfx file is built using function DFAX to process the three data files
and store the information in a dfx file for use by PSCOPF.
6-134
6.12.2 PSCOPF solution options

The following options are available in the PCSCOPF function. See the API Manual, Section 1.209,
PSCOPF.
Table 6-16. PSCOPF Solution Options
Select solution options for power flow calculations performed to

obtain the base case solution (see 6.2).
• Tap adjustment:
• Lock taps
• Stepping
• Direct
Area interchange control:
• Disabled
• Tie lines only
Base-case Solution options
Lock all
Enable all
Enable continuous, disable discrete
Enable or disable phase shift adjustments.
Enable or disable DC tap adjustments
Induction motor treatment flag applied when an induction motor fails
to solve due to low terminal bus voltage
• stall
• trip
6-135
Select solution options for power flow calculations performed to

obtain the contingency solutions.
Tap adjustment:
• Lock taps
• Stepping
• Direct
• Disabled
• Tie lines only
Contingency-case Solution • Tie lines and loads
options Switched shunt adjustments:
• Lock all
• Enable all
Enable or disable DC tap adjustments
Induction motor treatment flag applied when an induction motor fails
to solve due to low terminal bus voltage
• stall
• trip
Select one engine for both base case and contingency solutions
(see Section 6.2, Power Flow Solution Methods).
• Fixed slope decoupled Newton-Raphson (FDNS) (default)*
• Full Newton-Raphson
Solution Engine
* The optimized fixed slope decoupled Newton-Raphson method is
used when PSCOPF is initiated via the graphical user interface.
The user may choose either the regular or the optimized fixed slope
decoupled Newton-Raphson method when initiating PSCOPF from
an automation file.
Option to enable or disable non-divergent solution in each power
Non-divergent solution
flow solution
Option for generation dispatch to handle system load/generation
imbalance caused by a contingency:
• Subsystem machines (Reserve)
• Subsystem machines (PMAX)
Generation dispatch for
• subsystem machines (Inertia)
contingency case
• subsystem machines (G
• overnor droop)
Dispatch subsystem specifies the subsystem containing the
machines participating in the selected dispatch
6-136
Tolerance used to check for the largest initial active or reactive

power mismatch. If exceeded, the PSCOPF solution is terminated.
Mismatch tolerance (MW) This value is also used as the convergence
tolerance in the power flow solution of the base case and contin-
gency cases (see Section 6.2).
Ignore violations in base case:
flag to ignore the initial violations in the base case, it applies when
initial violations are identified,
• ignore the violations from PSCOPF process
• find the corrective actins to remove the violations; ignore the
violations that can not be removed by corrective actions.
Rating set:
Rating set to be used in determining monitored element loading
violations in contingency solutions
• A
• B
• C
Specify percent of flow rating to be used in determination of branch
and interface flow overloads in contingency solutions.
Branch overload violation tolerance (%):
Constraint Options
Specifies branch overload violation tolerance in percent to adjust
branch overload limits used in PSCOPF. The limits are increased by
the tolerance percent of the specified rating when the tolerance is
positive, or reduced when it is negative. For instance, if the toler-
ance is 0.1% and the overload limit is 100% of rate A, the 100.1% of
rating A is used in determining overload violations in corrective
actions. In the above case if the tolerance is -0.1%, the 99.9% of
rating A is used.
Bus voltage violation tolerance (%):

Specifies bus voltage violation tolerance in pu to adjust the bus
voltage limits used in PSCOPF. The limits are expanded by the
tolerance when it is positive, narrowed when it is negative. For
instance, if the tolerance is 0.1 pu and lower and upper limits on a
bus voltage are 0.95 and 1.05 in pu respectively. The adjusted
voltage limits are 0.949 and 1.051 respectively. In the above case if
tolerance is -0.1, the lower and upper limits are 0.951 and 1.049.
Iteration # of PSCOPF Maximum number of PSCOPF iterations
Cutoff for clean cases Iteration number n of a contingency to be solved in PSCOPF

process. At each iteration of PSCOPF, each contingency that is not
in the set will be solved by a power flow solution and its results will
be checked to determine flow and voltage limit violations and if it
should be included in the set. If a contingency does not cause any
limit violations so it is not included in the set in the n consecutive
iterations of PSCOPF, it will not be tested any more in subsequent
iterations.
6-137
Flag to enable or disable generator active power dispatch (see

Section 6.11, AC Corrective Actions)
Weighting factor for generator active power dispatch
Control subsystem of participating generators
Flag to enable or disable load controls
Weighting factor for load controls
Control subsystem of participating loads
Flag to enable or disable phase shifter controls
Weighting factor for phase shifter controls
Control options Control subsystem of participating phase shifters
Flag to enable or disable off-line generator active power dispatch
Weighting factor for off-line generator controls
Control subsystem of participating off-line generators
Flag to enable or disable tap setting adjustments
Weighting factor for tap setting adjustments
Control subsystem of participating load tap changing transformer
Flag to enable or disable switched shunt controls
Weighting factor for switched shunt controls
Control subsystem of participating switched shunts
(*.dfx) a required file to be build by activity DFAX that corresponds to

the network condition contained in the working case (refer to Section
8.1.7, Application Notes) and to the desired linear network analysis
Distribution Factor Data File data files (refer to Section 8.1.1, Linear Network Analysis Data
Files). The bus input option (refer to Section 3.3.3, Program Run-
Time Option Settings and activity OPTN) must have the same set-
ting that was in effect when activity DFAX filled the specified Distribu-
tion Factor Datafile.
( *.thr) an optional file, created by the user, that contains data
records of the following form:
IBUS, JBUS
where IBUS and JBUS are bus numbers. If branch outage contin-
Load Throwover Data File gency events isolate bus IBUS, the user can elect to move the load
to bus JBUS. Bus IBUS and/or JBUS may be a dummy bus of a
multi section line grouping. Data records may be entered in any
order. Input is terminated with a record specifying an IBUS value of
zero.
(*.inl) a required file if the generation dispatch is enabled and either
the inertial or governor droop dispatch method is selected. If the
PMAX or reserve method is selected, the specification of this file is
Unit Inertia Data File
optional. If a file is specified, machine active power limits are taken
from it; otherwise, the machine active power limits in the working
case are used
6-138
6.12.3 Perform PSCOPF Analysis

To launch the PSCOPF analysis, select Power Flow  Contingency, Reliability, PV/QV  Preven-
tive Security Constrained Optimal Power Flow
START
Initialize the set of critical

contingencies as empty
Perform power flow solutions

of the base case and
contingency cases , identify
the set of sever
contingencies
Yes
Empty set? STOP
PSCOPF
No
Solve the security

Constrained Optimal Power
flow
Figure 6-30. Flow chart of PSCOPF process
The PSCOPF is an iterative process, as shown in Figure 6-30, with each iteration consisting of two
computational components: contingency testing and solution of the combined master problem and
sub-problems. The first part performs power flow solutions of the base case and contingency cases,
identifies the set of critical contingencies and builds the Bender’s cuts that will be used to formulate
the master problem of the security constrained optimal power flow problem. The second part solves
the master problem and finds the optimal settings of the controls. At the end of each iteration, the
base case system is adjusted according to the identified control settings.
The key function in the testing part is to identify a set of critical contingencies at each iteration of
the PSCOPF. The set consists of contingencies that cause flow and/or voltage limit violations, but
cannot be represented by any other contingencies in the set. The power flow results from each
contingency solution are checked against the corresponding performance criteria to identify the limit
violations. For example, under contingency A, the line x-y is overloaded by 5 percent of its rating;
under contingency B, the same line is overloaded by 10 percent. In theory, if preventive strategies
can be found to adjust the system under base case condition so that the line x-y does not violate its
rating limit following contingency B, then the line will operate within its limit following contingency A
6-139
too. If the overload of line x-y is the only violation under both contingencies A and B, B is the domi-
nant contingency and will be added into the set, while A is considered a non-dominant contingency.
However, in many situations, multiple violations may be found in a contingency solution. In that
case, the solution of the contingency being tested is compared against the solutions of every other
contingency already included in the set. If any contingency in the set causes the same violations,
more specifically, the number of violations is identical, the same monitored elements are over-
loaded and the same buses have same low voltage or high voltage problems. The solution of the
contingency in the set is further compared to the contingency being tested, if the violations in the
contingency in the set are more severe than the ones in the contingency being tested, the contin-
gency being tested is not a dominant contingency; otherwise it is a dominant case and included in
the set. This method of selection can reduce the number of cuts significantly and therefore speed
up the calculations in the second part.
6-140
START
Select i th contingency case, i from 1 to the

number of contingencies
Solve the i th
contingency
No
Meet contingency
performance criteria?
No Yes
Skip the
Converged?
contingency
Yes
Put it into the set of

critical contingencies
No
Finish all
contingencies?
Yes
End of computational
part I
Figure 6-31. Chart for testing of contingencies and selection of cut set
6-141
The testing part consists of several steps:
1. Set up the base case, contingency definitions, monitored elements, etc. to prepare for
contingency analysis, initialize the set of severe contingencies to be empty.
2. Perform a power flow solution under base case condition; the solution results are checked
against base case performance criteria to identify flow and/or voltage limit violations, if any.
3. Select a contingency, impose it on the base case condition and calculate the power flow
solution with contingency-case power flow solution options.
4. Check results from the contingency solution against contingency case performance criteria
to identify flow and/or voltage limit violations, if any. If violations are found and the contin-
gency is considered to be dominant, add the contingency to the set of critical contingencies.
5. Return to step 3 to test the next contingency. Stop when all contingences have either been
tested or included in the set.
Figure 6-32 shows a sample progress output of contingency testing in an iteration of PSCOPF.
Figure 6-32. Sample of progress outputs of PSCOPF
At each iteration of PSCOPF, every contingency not already in the set will be tested, the results
checked to identify possible overloads and/or voltage violations and a decision made whether the
contingency should be included in the critical set of not. If no violations are found in the contingency
power flow solution, or if the contingency is classified as non-critical in several consecutive itera-
tions of PSCOPF, it is safe to say that any system control adjustments made in subsequent
iterations of PSCOPF will have relatively small impact on this contingency. Therefore, this contin-
gency will be excluded from further testing in subsequent iterations. The number of consecutive
iterations for making this decision to exclude the contingency is specified in the input option: cutoff
for clean cases.
The second calculation part is to solve the master problem and determine the system adjustments,
feed the adjustments back to each sub-problem and update the Bender’s cuts corresponding to the
6-142
new system condition. These steps are conducted iteratively until the process arrives at the best
solution that satisfies all the constraints. There are several steps in this part:
Generate the
Bender’s cuts
Prepare controls
and constraints
Build the master

problem
Solve the master problem

with Successive Linear
Programming
Adjust the system
Perform a power flow

calculation for a
contingency in the set and
identify the violations in the
solution
Yes Update the

Violations? Bender’s cuts for
the contingency
No
Finish all
contingencies in
the set
Yes
Bender’s cuts
updated?
No
End of computational
part II
Figure 6-33. The process to determine the control adjustments
6-143
1. Create the Bender cuts for each violation in each contingency in the set.
2. Process controls and constrains, together with Bender cuts to build the master optimization
problem.
3. Solve the master optimization problem with Successive Linear Programming.
4. Apply the adjustments determined from the Successive Linear Programming algorithm to
the base case system, and perform an AC power flow solution. This solution is used as the
initial condition for the following calculations.
5. Impose one contingency case and perform a power flow solution with the contingency case
solution options. If automatic system adjustments are enabled, they are determined by the
power flow solution to meet their respective specified bus voltage, branch flow or are inter-
change schedules.
6. Check the results from the contingency solution to identify thermal and/or voltage limit viola-
tions, if any. If violations are found, the cuts with respect to the violations are updated
7. If all contingencies in the set have been tested, proceed to the next step; otherwise go to the
step 5.
8. If any cuts have been updated in step 6, go to step 1. Otherwise, stop the process.
6-144
Figure 6-34 is an example of progress output of solving the master problem to determine the adjust-
ments in one iteration of PSCOPF.
Figure 6-34. Sample of progress outputs of PSCOPF
6.12.4 Application notes

Invoking the PSCOPF will trigger an alarm and termination of the solution if generators are
converted (refer to CONG). The solution then checks to make sure that each non-Type 4 bus is
connected back to a Type 3 (swing) bus through the in-service ac network. If any isolated bus is
found, an appropriate warning message is displayed and the solution is terminated. If the largest
initial active or reactive power mismatch exceeds the specified mismatch tolerance (an input item),
the solution is terminated. This tolerance is also used as the bus mismatch convergence tolerance
in the power flow solution of each contingency case.
The PSCOPF Solution function responds to the following interrupt control codes:

NM Suppress any automatic adjustment monitors (only used with CM interrupt control code).
Tabulate conditions for each dc line after each iteration (see Section 6.3.11, Operation of
DC
Activity SOLV).
Tabulate conditions for each FACTS device after each iteration (see Section 6.3.11, Operation
FD
of Activity SOLV).
6-145
When the set of critical contingencies is empty in either one of the two calculation parts, the
PSCOPF solution is considered converged and will terminate. If the system condition represented
in the working case after a converged PSCOPF solution is then used as the base case for an AC
contingency analysis with the identical contingency files (*.sub, *.mon, and *.con) and identical
power flow options, there should be no limit violations in the contingency solutions.
PSCOPF may be terminated abnormally under one of following conditions;
• The base case solution does not converge in either one of the calculation parts.
• The Linear Programming solution does not converge.
• The maximum iteration limit is reached.
• Termination initiated by the program user.
Discrete controls of switched shunt and tap setting adjustments are treated as continuous control
variables at the beginning of the PSCOPF solution if they are enabled. After the PSCOPF has
reasonably converged, the control settings are moved to their respective nearest discrete steps and
will remain constant in the remaining iterations of PSCOPF.
PSCOPF solution will update the power flow in the working case with the computed bus voltage
magnitudes and angles, and the values of any control variables that have been adjusted, such as
generator outputs, loads, phase shifter angels, tap settings, and switched shunt outputs.
Active constraints are limiting constraints which cannot be satisfied in the final solution of PSCOPF.
Constraints can be limiting because not enough applicable controls have been specified. For
example, if a transmission line along a radial network is overloaded and the loads along the network
are not allowed to be adjusted, there is no practical way to eliminate the overload. Another reason
is the application of soft penalties to the constraints. Mathematically, because the ineffective
controls always involve large adjustments and introduce large penalties to the objective function,
the PSCOPF will balance the cost of infeasibility (limit violations) against the costs of the adjust-
ments to determine the optimal solution. Hence, if the limit violations in a power system cannot all be
eliminated using the basic control actions, it may be preferable sometimes to accept certain degree of limit
violations instead of applying extreme and ineffective control adjustments.
6-146
Program Operation Manual Performing Multi-Level AC Contingency Solution
Besides the progress output, PSCOPF also produces a report upon completion of execution. The report
summarizes the adjustments made to mitigate the violations in the base case, the list of active constraints, and
the adjustments made by PSCOPF process to ensure system security.
Active constraints
6.13 Performing Multi-Level AC Contingency Solution

Activity Multi-Level AC Contingency Solution
Run Activity Multi-Level AC Contingency Solution - GUI

Power Flow > Solution > Multi-Level AC contingency solution…
[Multi-Level AC Contingency Solution]
AB
Multiple level AC contingency analysis provides a comprehensively featured function for testing
deterministic reliability as discussed in Section 6.9.2 Applying Deterministic Criteria. It features
easy configuration, built-in contingency ranking function to automatically select contingencies, trip-
ping simulation of post-contingency conditions and corrective action analysis to relieve flow
overloads and voltage violations caused by a contingency. The procedure of evaluating a single
contingency with multiple level contingency analysis is shown in Figure 6-35.
6-147
Performing Multi-Level AC Contingency Solution Program Operation Manual
Figure 6-35. Outline of Evaluation Procedure Using AC Power Flows for a

Single Contingency
Multiple level AC contingency analysis calculates full AC power flow solutions for the user specified
and automatically selected single or multiple contingencies, monitors voltage and loading condi-
tions and stores the results in a binary file. It will accept a user-specified list of contingencies to be
included in a contingency study as defined in a Contingency Description Data file (see Contingency
Description Data File Contents). Each of these specified contingencies may consist of a combina-
tion of generation and transmission outages. In addition, contingencies may be selected by built-in
automatic contingency rankers. Two such rankers, for branch overload and voltage collapse contin-
gencies (see Section 8.3.1 Contingency Ranking Methodology), are integrated during multiple level
contingency analysis. There is full flexibility in defining contingency subsystem; i.e., you can define
in which portion of the system you will allow contingencies automatically selected by rankers. A
contingency sub-system may comprise of specific equipment, a combination of control areas or
zones, or the whole database (see Section 6.10.1 AC Contingency Solution Options).
The multiple contingency solution function performs deterministic reliability assessment for up to
three levels, namely N-1, N-2 and N-3 criterion. User specified and automatically selected contin-
gencies are evaluated individually and in combination with each other as overlapping outages up
to the specified evaluation level. When used in conjunction with the automatic contingency ranker,
a stopping criterion (non-failure cutoff) is applied at each level. This provides the opportunity for
6-148
enormous savings in computational evaluation of contingencies. Furthermore, PSS®E has built-in

logic that identifies if a given set of outages has already been evaluated as a contingency, thus
ensuring that an automatic contingency analysis run is comprised only of unique contingencies.
Multiple-level ac contingency analysis models special relay actuation schemes designed to trip or
reconnect a generator or a circuit, and shed or transfer load in response to specified low voltage,
line flow, interface flow, generator output, or line and generator service status. During contingency
analysis, switching will be automatically performed and new power flow solutions obtained when-
ever trip/reconnect relaying sequences are triggered. The tripping simulation can simulate
cascading outages from contingencies.
Multiple-level ac contingency analysis performs corrective action analysis to eliminate flow over-
loads and voltage violations caused by a contingency with the objective of minimizing control
adjustments such as re-dispatch of generations, curtailment of loads and adjustment of phase-
shifting transformers. This can help translate system related reliability measures, such as the loca-
tion and magnitude of branch overloads and bus voltage violations, to customer-impact indices in
terms of the potential amount of service interruptions, which are critical indices in probabilistic reli-
ability assessment.
6.13.1 Terms Used in Multiple-Level Contingency Analysis

Multiple level contingency analysis can perform both simple and complex contingency analysis.
Certain terms used in the implementation and documentation are specific to multiple contingency
analysis use and may not necessarily reflect those of local electric power analysis practice. Some
key definitions of terms applied to multiple contingency analysis are identified as following:
Contingency element: A major component in the network where operation status or set-
points can be changed, e.g., one transmission circuit outage, one machine out-of-service,
one transmission circuit re-closing, a change in load or generation at a bus.
Contingency event: The contingency of one or more elements originating from a single
cause, e.g., each contingency case defined with a block structure in a contingency descrip-
tion file is considered as one contingency event.
Contingency: A contingency condition simulated by PSS®E made up of one or more con-
tingency events.
Level: The number of contingency events within a contingency studied by PSS®E. Level
may also be viewed as the number of independent causes studied in a contingency; e.g.,
N-1, N-2 and N-3.
Contingency events include:
• Single contingency elements, e.g., one transmission circuit outage, and
• Multiple contingency elements, e.g., a combination of circuits and, or machines
out-of-service at the same time.
Examples of the latter include outages of multiple circuits terminating at the same bus caused by
bus failures and outages of two circuits on the same right-of-way caused by ROW failure.
When multiple events are combined within a contingency, they are assumed to be occurring simul-
taneously but originating from independent causes, i.e., one event does not trigger the others.
Multiple level contingency analysis is deigned to model up to three events per contingency.
6-149
6.13.2 Power Flow Control Options

Table 6-17. Multi-Level AC Contingency Solution Power Flow Control Options
Option Description
The desired solution options to be applied during power flow calculations for obtaining
post-contingency states (see Section 6.2 Power Flow Solution Methods)
Tap adjustment:
• Lock taps (default)
• Stepping
• Direct
Solution options
• Disabled (default)
• Tie lines only
• Lock all
• Enable all (default)
Non-divergent Flag to enable or disable (default) option in the power flow solution of each contingency
solution case.
Adjust phase Flag to enable or disable (default) option in the power flow solution of each contingency
shift case.
Flag to enable (default) or disable option in the power flow solution of each contingency
Adjust dc taps
case.
Select the desired power flow solution engine to be used in obtaining post-contingency
states (see Section 6.2 Power Flow Solution Methods).
Solution Engine • Fixed slope decoupled Newton-Raphson (FDNS) (default)
• Optimized fixed slope decoupled Newton-Raphson (FDNS)
Dispatch codes for generation dispatch calculations in contingency
Dispatch mode
analysis (see Table 6-10 AC Contingency Single Run Report Options)
Dispatch system Select the subsystem for the generation dispatch.
Tolerance used to check for the largest initial active or reactive power mismatch. If
Mismatch
exceeded, the process is terminated. This value is also used as the convergence toler-
tolerance
ance in power flow solution (see Section 6.2 Power Flow Solution Methods).
(*.dfx) a required file to be build by activity DFAX that corresponds to the network condi-
tion contained in the working case (refer to Section 8.1.7 Application Notes) and to the
desired linear network analysis data files (refer to Section 8.1.1 Linear Network Anal-
Distribution ysis Data Files). The bus input option (refer to Section 3.3.3 Program Run-Time
Factor Data File Option Settings and activity OPTN) must have the same setting that was in effect when
activity DFAX filled the specified Distribution Factor Data file. Refer to Section 2.4.1 File
Usage for the file specification conventions used by the AC Contingency Solution
function.
6-150
Table 6-17. Multi-Level AC Contingency Solution Power Flow Control Options (Cont.)
Option Description
Contingency
(*.acc) a required file designated by the user as the destination for the results of the
Solution Output
contingency calculations.
File
( *.thr) an optional file, created by the user, that contains data records of the following
form:
IBUS, JBUS
Load Throw-
over Data File where IBUS and JBUS are bus numbers. If branch outage contingency events isolate bus
IBUS, the user can elect to move the load to bus JBUS. Bus IBUS and/or JBUS may be a
dummy bus of a multi section line grouping. Data records may be entered in any order.
Input is terminated with a record specifying an IBUS value of zero.
(*.inl) a required file if the generation dispatch is enabled and either the inertial or
Unit Inertia and
governor droop dispatch method is selected. If the PMAX or reserve method is selected,
Governor Data
the specification of this file is optional. If a file is specified, machine active power limits are
File
taken from it; otherwise, the machine active power limits in the working case are used.
6.13.3 Multiple Contingency Analysis Options

Table 6-18. Multi-Level AC Contingency Solution Multiple Contingency Analysis Options
Option Description
When disabled, all other options in this dialog are disabled.
When enabled, the next-level contingencies (e.g. secondary contingencies of a primary
Multiple contin- contingency) of each non-failure contingency (see Section 6.13.4 Classification of
gency analysis Contingency Analysis Results) are to be evaluated.
When enabled with failure cutoff disabled, the next-level contingencies of each failure and
non-failure contingency will be evaluated.
Max level of
Level of multiple contingency analysis, up to third level. This option enables the contin-
contingency
gency combination selections at less or equal levels.
analysis
Contingency groups included in the primary contingency list (see Section 6.13.5 About
Contingency List). There are three groups of contingencies to choose, namely S, U and
B. S represents user specified outages, U and B are machine outages and branch outages
First level of
respectively. When the ranked contingencies are included in the primary list, the ranking
analysis
solution is performed on the base power flow case using a linearized network model. The
number of ranked contingencies of each group included in the list is determined by the
min, max, cutoff values of the ranker.
Contingency groups included in the secondary contingency list for each primary contin-
gency. Nine N-2 contingency combinations are represented with a matrix. Each row
represents one type of first-level contingencies from which the secondary contingency list
is generated based on existing system condition after solving. The name of contingency
Second level of
type is dictated by the letter at the beginning of each row; three elements of a row repre-
analysis
sent the same categories (S, U, B) in secondary contingency list. When an element is
selected, the corresponding N-2 contingency will be evaluated. If one group of contingen-
cies is not specified in primary contingency list, its secondary list is empty and the
corresponding row will be disabled.
6-151
Option Description
Contingency groups included in the tertiary contingency list for each first-level and
second-level contingency. There are 27 N-3 contingency combinations for the tertiary
contingency; each combination is comprised of one of each of three contingency event
types for each level. These combinations are represented with three matrices; each of
them has nine elements. Each matrix represents one group of first-level contingency
cases and is dictated by the letter at the first column; each row of a matrix represents one
Third level of type of second-level contingencies and is indicated by the letter at the second column.
analysis Three elements of a row of a matrix represent categories S, U and B in tertiary contin-
gency list. The tertiary contingency list is built based on existing system condition after
solving first and second level contingencies. Similarly, tertiary contingency list may exist if
and only if its corresponding first and second level contingencies have been tested. That is
if one group of contingency is not included in primary list, all following lists are empty and
the corresponding matrix is disabled; if one group of contingency is not tested at level 2,
the corresponding row is disabled and the tertiary list is empty.
Select contingency rankers and specify the number of each group of contingencies to be
Ranking options included in the list (for contingency ranking, see Section 8.3.1 Contingency Ranking
Methodology).
These define the loading limits to be used in calculating overload performance indices. By
default, contingency case rating is rating set program option setting and percent of rating
Contingency
is 100 percent. They are also used to determine flow overloads in post-contingency solu-
case rating and
tions and classify the post-contingency solutions into either failure or non-failure groups,
percent of rating
and if Perform corrective actions option is enabled, then corrective actions are specified to
remove the flow overloads.
If enabled, ratings of monitored branches are converted to estimated MW ratings based
Convert to MW
upon each monitored line's reactive power loading at the metered end in the base case ac
rating
solution.
Contingency
Subsystem where contingencies will be automatically selected by rankers.
subsystem
If enabled, include in the contingency list only branches from within the designated
Include subsystem. If disabled, both subsystem branches and ties from the subsystem to other
subsystem ties buses in the working case are included. The group of branches that may be outaged is
defined according to subsystem selection options.
Reactance threshold; all branches from the contingency list (based on the user’s
Small reac-
subsystem selection) where magnitude of reactance is less than or equal to this threshold
tance threshold
have their performance indices explicitly calculated.
Four control parameters.
• Enable: Include single branch outage that causes overloading in the contingency
list.
• Min.: The minimum of single branch outages from the overload ranking to be tested
Line overload in the list.
• Max.: The maximum of single branch outages from the overload ranking to be
tested in the list.
• Cutoff: The number of consecutive single branch outages from the overload
ranking that are non-failure
6-152
Option Description
• Enable: Include single machine outages from branch overload ranking in the
contingency list.
• Min.: The minimum of single machine outages from the overload ranking to be
Machine
tested in the list.
overload
• Max.: The maximum of single machine outages from the overload ranking to be
tested in the list.
• Cutoff: The number of consecutive single machine outages from the overload
ranking that are non-failure.
• Enable: Include single branch outage that causes voltage collapse in the
contingency list.
• Min.: The minimum of single branch outages from the voltage collapse ranking to
Voltage
be tested in the list.
depression
• Max.: The maximum of single branch outages from the voltage collapse ranking to
be tested in the list.
• Cutoff: The number of consecutive single branch outages from the voltage collapse
ranking that are non-failure.
Two control parameters.
Islanding • Enable: Include single branch contingencies that result in the formation of an island
ranking of one or more buses, without a swing bus, in the contingency list.
• MW threshold: The minimum of active power flow on such branches.
6.13.4 Classification of Contingency Analysis Results

There are two cutoffs to control the level of multiple contingency analysis and number of contingen-
cies to be evaluated at each level during analysis: failure cutoff and non-failure cutoff.
The failure cutoff is enabled by selecting Enable for multiple contingency analysis option, the next-
level contingencies of a failure contingency that results in operating limit violations will be skipped.
It is most likely that under a failure contingency condition any next-level contingencies will result in
operating limit violations too, so there is no need to apply more contingencies to failure cases.
Enabling failure cutoff can reduce the set of tested contingencies and concentrate studies on more
probable contingencies. To evaluate complete multiple event contingencies for the specified level,
the failure cutoff must be disabled by selecting Enable with failure cutoff disabled for Perform
multiple contingency analysis option. After completion of a contingency analysis, only non-failure
cases could be used as base cases for next-level contingency analysis. The failure cutoff is applied
to both user specified contingencies and ranked contingencies. For example, multiple level contin-
gency analysis is initiated with level 2 and failure cutoff enabled, user specified contingencies for N-
1 and combinations SS and SB for N-2 (SS consists of two different user specified contingencies in
the user specified contingency list, and SB consists of a user specified contingency and a ranked
single branch outage), if all user specified contingencies are failure cases based on the failure
criteria in Table 6-20 Types of Problems Qualifying a Category I Contingency as a Failure, namely
all N-1 cases are failure cases, all N-2 contingencies are skipped.
6-153
The non-failure cutoff is specified by cutoff numbers within each ranker. If the number of consecu-
tive non-failure contingencies from the ranker is more than the cutoff, it is assumed that the rest
contingencies from the same ranker will not lead to violations and be skipped. This section
discusses internal the failure criteria to classify a contingency solution.
At the completion of a contingency evaluation, the contingency may be classified according to solu-
tion characteristics of the last power flow solution performed on the contingency. This classification
is shown in Table 6-19 Classification of Contingency Evaluation Based on Power Flow Solution.
Table 6-19. Classification of Contingency Evaluation Based on Power Flow Solution

Category I Converged and maximum bus mismatch within tolerance
Category II Voltage Collapse solution stopped by non-divergent power flow
Category III Not Converged
Category I contingencies are those for which power flow solutions have a maximum bus mismatch
less than the mismatch tolerance. Category I contingencies are further classified into: failures and
non-failures. A Category I contingency is classified as a failure if the contingency results in problems
listed in Table 6-20 Types of Problems Qualifying a Category I Contingency as a Failure or if specific
events occur during the contingency. The classifications are applied only to internal programs. The
failure status of the contingency is used only as stopping criteria for failure and non-failure cutoff
algorithms. You can make your failure criteria more stringent in order to obtain a reduced set of
tested contingencies; however only monitored flows and voltages specified in monitored element
data file of tested contingencies are saved in results files and can be post-processed to generate
the different reports. In order to test more contingencies, you have to repeat contingency analysis
with new selections of failure criteria (see Section 6.13.6 Wind Chime Algorithm for Multiple Level
Contingency Analysis). The failure status of a contingency is not stored in result files.
Table 6-20. Types of Problems Qualifying a Category I Contingency as a Failure

Problem Description Default Criteria
Circuit or interface loading above a Specified rating multiplied by a percent factor
OVERLOAD specified multiplier of a specified rating from GUI, by default, 100 percent of rating set
(A, B or C). program option setting is used.
HIGH VOLTAGE Bus voltage above the high voltage limit. Upper limit defined in monitored element file.
LOW VOLTAGE Bus voltage below the low voltage limit. Lower limit defined in monitored element file.
Bus voltage change (absolute value)
VOLTAGE between pre- and post-contingency
Variation defined in monitored element file
DEVIATION conditions exceeds the Deviation
criterion
The detected overloaded branches are different with those in post-processed report files
where the different ratings of loading may be applied.
An islanding event occurs when a contingency causes a physical separation of a bus or group of
buses from the base case network. The outage of a radial branch will automatically result in
islanding of a radial bus. If the contingency is a multiple element outage, it may cause multiple
islands. When dispatch mode and dispatch subsystem are specified, contingency analysis will
process islanding events via generation redispatch (see Section 6.9.4 About Generation Dispatch),
6-154
otherwise those islands without a swing bus will be shut down. The islanding problem has been
removed from the failure criteria since PSS®E-30.3.
The types of events (as differentiated from troubles) occurring during contingency evaluation that
would qualify a contingency as a failure, include:
• TRIPPING – A contingency where at least one trip specification is actuated (see

Section 6.13.7 About Tripping Sequence).
Power flow cases with solutions that are classified as either voltage collapse (Category II) or not
converged (Category III) are excluded from tests of failure.
6.13.5 About Contingency List

Multiple contingency analysis functions work with a contingency event list, also referred to as a
contingency list. The list provides a sequence for evaluating contingencies. However, the true
power of this list lies in the fact that not all contingencies included in it are evaluated by multiple
contingency analyses.
It is useful to think of the contingency list as further divided into contingency groups. Contingency
groups are shown in Table 6-21 Groups within Contingency List. The graphic equivalent of this table
is shown in Figure 6-36.
Table 6-21. Groups within Contingency List

Group Contents
S Specified contingencies.
U Outages of single machines, ranked according to impact on thermal loading of branches.
B1 Outages of single branches that result in separation (islanding) of the network.
B2 Outage of single branches ranked according to impact on thermal loading of branches.
B3 Outage of single branches ranked according to impact on voltage collapse.
In group S, the contingencies are taken directly from a dfax file that is generated with a Contingency
Description Data file (see Contingency Description Data File Contents). These can be viewed as
must-test contingencies; i.e., no matter how system conditions change, it is important to the reli-
ability assessment to consider these contingencies. The Contingency Description Data file may be:
• Created by the user based on previous operating or planning experience with a system,
reliability criteria guidelines or some other arbitrary method. The file is thus one that is
created outside of PSS®E, with a text editor.
• Produced by pre-screening contingencies using activity RANK.
Groups U, B1, B2 and B3 are comprised of ranked contingencies from the contingency subsystem,
each group is based on different methods of ranking.
Things to note about the contingency list and its groups:
• Within each ranked group, there is internal ordering from most severe to least severe
contingencies.
• Contingencies are evaluated according to the sequence of groups.
6-155
• If a contingency has been evaluated in an earlier group, the same contingency in a later
group will be skipped.
Each contingency evaluation constitutes a Power Flow solution resulting in a post-contingency
system state. Conditions in the post-contingency state are then checked against the specified
failure criteria.
Ranked contingencies are tested one by one in sequence until an unbroken series of N non-failure
contingencies. The stopping criterion (non-failure cutoff) of N contingencies in a row is applied here.
The evaluation of a ranked contingency group is complete when all contingencies are exhausted or
the stopping criterion is met.
Groups B1, B2 and B3 may be comprised of the same contingencies, albeit with different ranking.
Some of these contingencies may also be included in group S.
Figure 6-36. Contingency List
6.13.6 Wind Chime Algorithm for Multiple Level Contingency Analysis

If a one-level contingency analysis is specified, all must-test events (group S) are evaluated first.
Ranked individual machine outages (group U) follow the group S. These ranked machine outages
will be tested one by one until an unbroken sequence of N contingencies without any system prob-
lems has been detected or the maximum of contingencies of group U has been tested. When the
testing of machine outages is complete, either because the list has been exhausted, or because the
6-156
stopping criterion has been met, the branch outage events causing system separations (group B1)
are evaluated. A simple screening algorithm that searches for continuity can also automatically
select these events. The final two groups of events in the list are the ranked branch outages from
overload (group B2) and voltage collapse ranking (group B3). These are tested in a similar fashion
as the ranked machine outages, in which the individual branch outages are tested one by one and
the list is truncated after the corresponding stopping criterion is met. Groups B1, B2 and B3 may be
comprised of the same contingencies, albeit with different ranking. Some of these contingencies
may also be included in group S.
The multiple contingency solution procedure is given by the example of a two-level contingency
analysis. If a two-level contingency analysis is to be performed, a newly ordered event list is built
after solving each first-level contingency Power Flow. These secondary ordered event lists may
contain the same categories of outage events as those in the first-level list, with the exclusion of the
initial outage event. New rankings are determined based on the system conditions existing after
each first-level contingency using a linearized network model. This approach is called Wind Chime
approach.
Figure 6-37 illustrates the Wind Chime approach for a two-level contingency run using a contin-
gency level of 2; some other options specified for this run are Enabled with failure cutoff disabled
for Perform multiple contingency analysis option, B for the first level and BB for the second level
analysis, as well as only single branch outages from overload ranking with non-failure cutoff of 2.
Figure 6-37. Wind Chime Approach for 2 Level
6-157
In Figure 6-37, the initial first-level contingency is a non-failure. That is, it does not have any criteria
violations in Table 6-20 Types of Problems Qualifying a Category I Contingency as a Failure and
trigger any failure events. A number of second-level contingencies are then run until two consecu-
tive second-level contingencies are non-failures. The next first-level contingency is evaluated and
is classified as a failure case; because failure cutoff is disabled, it is followed by second-level contin-
gencies until two consecutive second-level contingencies are non-failures. This procedure
continues until the top two second-level contingencies are non-failures for two consecutive first
level contingencies.
This process can be duplicated for any level of automatic contingency analysis. If third-level contin-
gencies are requested, a ranking is done for each second-level contingency and the tertiary
contingencies are run until the maximum is reached or the cutoff criterion is satisfied.
The contingency evaluation functions contain logic to efficiently check whether a contingency
consisting of a combination of branches and machines has already been tested. In this way, any
particular branch or machine outage combination, whether it originates from one multiple element
event or from two or more single element events, will be tested only once. Also, elements that are
ranked higher in the primary event list than the present primary contingency will not be included in
the present and subsequent secondary ranking lists. This assumes that all two level events asso-
ciated with those primary events would have been evaluated, either explicitly by power flow
solutions or implicitly by ranking list truncation. The ranking algorithm also takes into account the
outages of identical machines located at the same bus. Because the impact of these outages on
the system will be identical, it is necessary to test only one of such machine outages per contin-
gency level.
The program can still test multiple levels of machines of the same size.
6.13.7 About Tripping Sequence

A contingency analysis may be followed by tripping simulations during multiple level contingency
analysis. Tripping sequences are simulations of events ensuing from automatic monitoring equip-
ment such as relays, and automatic circuit breaking and making equipment such as circuit breakers
and switches. These sequences are important in order for multiple contingency analysis to obtain
the right post-contingency state. Examples of tripping sequences are:
• Transfer of load to another bus on loss of power on a transmission branch.

• Switching of lines following outage or overload of another.
• Tripping of transmission circuits following extreme overloads.
Tripping sequences may also be used to model other automatic actions such as remedial action
schemes (RAS), special protection schemes (SPS) and operating guides.
6.13.8 Tripping Simulation Options

Table 6-22. Multi-Level Contingency Solution Tripping Simulation Options
Option Description
Perform tripping
Enable or disable (default) tripping simulation for post-contingencies states.
simulation
6-158
Table 6-22. Multi-Level Contingency Solution Tripping Simulation Options (Cont.)
Option Description
After a contingency power flow solution, tripping conditions that trigger tripping
sequences are checked in the order in which tripping events are specified in
Number of trip
Tripping Element Data file (Section 6.13.9 Tripping Element Data File
events per load
Contents). There may be more than one instance of tripping sequences that are
flow
activated. This option sets the number of trip events that are activated prior to
the next power flow solution.
When a new power flow solution is performed following activation of one or more
tripping sequences, the trip triggers are reset and all the remaining trip
Number of load sequences are checked for the new power flow solution. If one or more
flows per remaining tipping sequences satisfy conditions, a new power flow is performed
contingency with activation of these tripping sequences up to Number of trip events per load
flow. This process continues till the number of power flows following a contin-
gency power flow reaches the number of power flows per contingency.
Tripping
If multiple level contingency analysis is initiated with tripping simulation, this file,
Element Data
created by the user, is required. It contains tripping data.
File
6-159
6.13.9 Tripping Element Data File Contents

The tripping events are defined via the tripping data file (see Section 6.13.9 Tripping Element Data
File Contents for conventions in tripping data file). Each specification block structure is comprised
of a trip descriptor and one of each of two categories of data records - monitored equipment, trip
equipment. The former includes circuit/transformer/interface flows, generator output, bus voltage,
the operating status of monitored elements. The latter includes circuit/transformer/unit outages,
load shedding, bus outage, and circuit re-closing. The tripping event is defined in a block structure
as follows:
TRIPPING label
(monitored element)
(trip element)
End
The 12-character contingency label is used to identify each tripping event.
Monitored Equipment
The monitored elements include buses, lines, transformers, interfaces and machines. In a block
structure of tripping condition definition, there may be several individual conditions up to 10; each
condition has its monitored element specification and tripping rating. If the value of logical OR of
these conditions is TRUE, tripping actions defined within this block are triggered.
Voltage Monitoring Records

The following data record defines a voltage band with a single bus where voltage is to be checked
against the band:
[MONITOR] VOLTAGE RANGE BUS bsid TR r [r]
where the first r value is the lower bound of the per unit voltage band and the optional second r
value is the upper bound. If the upper bound is omitted, the upper end of the band is not checked.
Token TR is key word for trip rating.
Flow Monitoring Records

The data record format defines a non-transformer branch or two-winding transformer for monitoring.
T h e r v a l u e i s t h e t r i p p i n g r a t i n g i n s p e c i f i e d u n i t w i t h o n e o f t o k e n M W / M VA /
MVAR/AMPS/PERCENT. The monitored flow direction is dictated by FROM bus to TO bus specifi-
cations. If the trip rating is a positive number, trip will occur if the monitored flow exceeds this
number, if it is a negative number, trip will occur if the monitored flow is below the absolute value of
this number. A trip rating of 0 means that tripping should take place if the monitored element is out
of service.
[MONITOR]|BRANCH| FROM BUS bsid TO BUS bsid [|CIRCUIT| ckid] TR r |MW |

|LINE | |CKT | |MVA |
|MVAR |
|AMPS |
|PERCENT| OF |A|
|B|
|C|
6-160
To specify one winding of a three-winding transformer for monitoring, the bus to which the winding
is connected must be the first bus specified in the following data record:
[MONITOR]|BRANCH| FROM BUS bsid TO BUS bsid TO BUS bsid [|CIRCUIT | ckid] TR r|MW |
|LINE | |CKT | |MVA |
|MVAR |
|AMPS |
|PERCENT| OF |A|
|B|
|C|
When flow monitoring records employ keyword PERCENT, one of rating sets A/B/C must be spec-
ified. Percent loadings of monitored elements based on ratings are specified as either Current or
MVA percent loadings by percent units program settings (see activity OPTN).
Unit Monitoring Record

The data record defines a single machine for monitoring:
[MONITOR]|UNIT | mcid AT BUS bsid TR r |MW |

|MACHINE| |MVA|
|MVAR |
|AMPS |
Interface Monitoring Record

[MONITOR] INTERFACE label TR r |MW/MVA/ MVAR/AMPS|
(branch specification record, see below)
.
.
(branch specification record, see below)
END
where r is trip rating for the monitored interface, if the sum of MW/MVA/ MVAR/AMPS flows at the
from bus end of specified branches is greater than r, trip actions occur. A rating of zero will disable
the monitored interface flow condition. The branch specification record may specify individual two-
winding or non-transformer branches or individual three-winding transformers.
For specifying a two-winding or non-transformer branch the following data specification record is
used:
|BRANCH| FROM BUS bsid TO BUS bsid [|CIRCUIT| ckid]

|LINE | |CKT |
For specifying a three-winding transformer the following data specification record is used:
|BRANCH| FROM BUS bsid TO BUS bsid TO BUS bsid [|CIRCUIT| ckid]
|LINE | |CKT |
6-161
Join block structure

A join block structure specifies the monitoring condition through the logical ANDING of two or more
of the monitoring records described above. A join group has the following block structure:
JOIN
(monitoring record)
.
.
(monitoring record)
END
where each monitoring specification data record is one of the simple record types described above
(flow monitoring record, unit monitoring record, interface monitoring record, etc) . The logical value
of a join block is .TURE. if all monitoring records within the block are .TURE. A tripping block can
have one or more join blocks; the join blocks and simple monitoring records within a tripping block
are used to determine the value of the block’s tripping condition via logical OR.
Trip Equipment
Up to 32 tripping actions may be specified in a tripping event definition block structure. If any one
of tripping conditions is satisfied, all given tripping actions might be enforced to post-contingency
cases. The tripping actions are defined using following data records.
The outaging of an in-service non-transformer branch or two-winding transformer is specified with

the following record:
|DISCONNECT||BRANCH| FROM BUS bsid TO BUS bsid [|CIRCUIT| ckid]

|OPEN ||LINE | |CKT |
|TRIP |
An out-of-service non-transformer branch or two-winding transformer may be placed in-service with

a record of the form:
CLOSE |BRANCH| FROM BUS bsid TO BUS bsid [|CIRCUIT| ckid]

|LINE | |CKT |
The outaging of a three-winding transformer is specified with the following record:
|DISCONNECT||BRANCH| FROM BUS bsid TO BUS bsid TO BUS bsid [|CIRCUIT| ] ckid
|OPEN ||LINE | |CKT |
|TRIP |
An out-of-service three-winding transformer may be placed in-service with a record of the form:
CLOSE |BRANCH| FROM BUS bsid TO BUS bsid TO BUS bsid [|CIRCUIT| ckid]
|LINE | |CKT |
The next four record types allow the user to specify contingency events in which the load and gener-
ation boundary conditions may be changed at a selected bus. When changing generation, the bus
must have in-service generation connected to it and it may not be a swing bus.
6-162
The first data record of this type uses the following data record to set the load or generation at a bus
either to a designated value or to a specified percentage of its initial value:
SET BUS bsid |GENERATION| TO r |MW |

|LOAD | |PERCENT|
|SHUNT |
The number r specified must not be a negative number when the PERCENT keyword is used.
The second data record of this type uses the following data record to change the load or generation
at a bus either by a designated amount or by a specified percentage of its initial value:
|CHANGE| BUS bsid |GENERATION| BY r |MW |

|ALTER | |LOAD | |PERCENT|
|MODIFY| |SHUNT |
The third and fourth data records of this type are similar to the CHANGE record, except the direction
of the change is defined by the first keyword, and r must be a positive number:
|INCREASE| BUS bsid |GENERATION| BY r |MW |

|RAISE | |LOAD | |PERCENT|
|SHUNT |
|DECREASE| BUS bsid |GENERATION| BY r |MW |

|REDUCE | |LOAD | |PERCENT|
|SHUNT |
To transfer load or generation from one bus to another, the following data record is used:
MOVE r |MW | |GENERATION| FROM BUS bsid TO BUS bsid

|PERCENT| |LOAD |
|SHUNT |
See Contingency Description Data File Contents for details.
An in-service machine may be removed from service using the following data record:
REMOVE |MACHINE| mcid FROM BUS bsid

|UNIT |
Similarly, an out-of-service machine may be placed in-service with a record of the form:
ADD |MACHINE| mcid TO BUS bsid

|UNIT |
Automatic Single Tripping Record

A series of single branch tripping events is specified with a record of the form:
6-163
SINGLE LINE IN | AREA i | TR r PERCENT OF |A|

| ZONE i | |B|
| OWNER i | |C|
| KV r |
| SYSTEM label |
| SYBSSYTEM label|
In each tripping event, a single branch within a given subsystem is monitored. For non-transformer
branches and two-winding transformers, a branch is tripped when flow at either one of its two bus
ends exceeds the tripping rating. For three-winding transformers, a three-winding transformer is
outaged when the flow at any one of its three winding buses exceeds the tripping rating.
6-164
A breaker is a branch where the circuit ID’s first character is @, a switch has a  as the first char-
acter of its circuit ID. A series of single breaker and switch tripping events is specified with a record
of the form:
SINGLE BREAKER IN | AREA i | TR r PERCENT OF |A|

| ZONE i | |B|
| OWNER i | |C|
| KV r |
| SYSTEM label |
| SYBSSYTEM label|
6.13.10 Corrective Actions Options

When multiple level contingency analysis is initiated with corrective action analysis, if there are
operating limit violations in post-contingency solutions, or in post-tripping contingency solutions if
tripping simulation is enabled and tripping events are activated following a contingency, corrective
actions will be specified to relieve these violations.
Table 6-23. Multi-Level Contingency Solution Corrective Actions Options
Option Description
Perform Correc- Enable (default) to perform corrective action analysis; disable to disable all corrective
tive Actions actions options.
The desired number of iterations between execution of the linear programming engine to
identify corrective actions and subsequent ac power flow solution to verify the feasibility of
those actions. The specified number of iterations can be between 1 and 10.
Number of AC
load flows Note that, even if a feasible solution appears to have been found, i.e., the identified
corrective actions appear to have been successful, the iteration between linear program-
ming computation and AC power flow solution may continue in an attempt to further
optimize the solution if not exceeding the iteration limit.
Specifies branch overload violation tolerance in percent to adjust branch overload limits
used in corrective actions. The limits are increased by the tolerance percent of the speci-
Branch over-
fied rating when the tolerance is positive, or reduced when it is negative. For instance, if
load violation
the tolerance is 0.1% and the overload limit is 100% of rate A, the 100.1% of rating A is
tolerance
used in determining overload violations in corrective actions. In the above case if the toler-
ance is -0.1%, the 99.9% of rating A is used.
Specifies bus voltage violation tolerance in pu to adjust the bus voltage limits used in
corrective actions. The limits are expanded by the tolerance when it is positive, narrowed
Bus voltage
when it is negative. For instance, if the tolerance is 0.1 pu and lower and upper limits on a
violation
bus voltage are 0.95 and 1.05 in pu respectively. The adjusted voltage limits are 0.949 and
tolerance
1.051 respectively. In the above case if tolerance is -0.1, the lower and upper limits are
0.951 and 1.049.
Control options Types of control adjustments and weighting factors for each type
Enable (default) to include active power generation dispatch controls. The adjustable
range is from PT to PB of each participating machine. Generator active power limits are
Enable gener-
taken from a Unit Inertia and Governor Data file (see Section 6.8.1 Inertia and
ator controls
Governor Response Data File Contents) if the file is specified, otherwise the values in
base case are used.
6-165
Table 6-23. Multi-Level Contingency Solution Corrective Actions Options (Cont.)
Option Description
In corrective action analysis, generator active power limits are adjusted by the following
rules.
• If PT had been set to the default value, the larger value of PG (its existing MW
output) and machine power base (MVA base) will be used as PT.
• If PT of a machine is less than its PG, the PT is set equal to the PG.
• If PB of a machine had been set to the default value, it is set equal to 0.
• If PB of a machine is less than its PG, the PB is set equal to the PG.
• A machine will be excluded from the controls if its PT is equal to its PB.
Specify a weighting factor to adjust the cost factor of active power generation dispatch.
The cost of a control adjustment in objective functions is equal to the amount of adjust-
Weighting factor
ment times by a adjusted cost factor. The internal cost factor for active power generation
of active power
dispatch defined in the programs is shown in Table 6-15 Weighting Functions and
generation
Factors of Controls; the adjusted cost factor is equal to the internal factor multiplied by
dispatch
the user defined weighting factor. e.g., if the weighting factor is set as 1.0, the cost factor
for active power generation dispatch of 100 MW will be 1.0.
Generator
Select the subsystem in which all in-service generators with valid range of adjustments will
control
participate in corrective action analysis.
subsystem
Enable to include load shedding controls (default = disabled). The loads with negative MW
Enable load
values will be excluded from the controls. While performing load curtailment, the algorithm
controls
maintains a constant power factor at the buses where load curtailment occurs.
Specify a weighting factor to adjust the cost factor of load curtailment. The internal cost
Weighting factor factor for load curtailments defined in the programs is shown in Table 6-15 Weighting
of load Functions and Factors of Controls; the adjusted cost factor is equal to internal factor
curtailment multiplied by the weighting factor. e.g., if the weighting factor of load curtailments is set as
1.0, the cost factor for load shedding of 100 MW will be 100.0.
Select the subsystem in which all in-service loads will participate in corrective action anal-
Load control
ysis. Loads with negative active power will not be included as candidates for load
subsystem
curtailments.
Enable (default) to include phase shifter controls. To be adjustable as a phase shifter,
Enable phase
transformers must be operated subject to MW control mode. The adjustable range of a
shifter controls
participating phase shifter is from Rmax to Rmin.
Specify a weighting factor to adjust the cost factor of phase shifter angle adjustments. The
Weighting factor internal cost factor for phase shifter angle adjustments defined in the programs is shown in
of phase shifter Table 6-15 Weighting Functions and Factors of Controls; the adjusted cost factor is
angle equal to internal factor multiplied by the user-defined weighting factor. e.g., if weighting
adjustment factor of phase shifter angle adjustment is 1.0, the cost factor of phase shifter angle
adjustment of 100 degrees is 3.5.
Phase shifter
Select the subsystem in which all in-service phase shifters will participate in corrective
Control
actions.
subsystem
Enable off-line Enable to include off-line generator active power shift. The initial active power outputs of
generator participating off-line generators are set to zeros. Their active power ranges are specified in
controls the same way as on-line generators
6-166
Table 6-23. Multi-Level Contingency Solution Corrective Actions Options (Cont.)
Option Description
Weighting factor Specify a weighting factor to adjust the cost factor of active power generation dispatch of
of off-line off-line generators. The internal cost factor defined in the programs is shown in Table 6-
generator 15 Weighting Functions and Factors of Controls.
Off-line gener-
Select the subsystem in which all out-of-service generators with valid range of adjust-
ator control
ments will participate in corrective action analysis.
subsystem
Enable tap
setting Enable to include tap setting adjustment.
adjustments
Specify a weighting factor to adjust the cost factor of tap setting adjustment. The internal
Weighting factor
cost factor defined in the programs is shown in Table 6-15 Weighting Functions and
of tap setting
Factors of Controls.
Tap setting
Select the subsystem in which all in-service transformers designated in voltage control
adjustment
mode will participate in corrective action analysis.
subsystem
Enable switched
Enable to include switched shunt reactive power controls.
shunt controls
Weighting factor Specify a weighting factor to adjust the cost factor of switched shunt reactive power
of switched control. The internal cost factor defined in the programs is shown in Table 6-15
shunt Weighting Functions and Factors of Controls.
Switched shunt
Select the subsystem in which all in-service switched shunts designated in voltage control
control
mode will participate in corrective actions.
subsystem
6-167
6.13.11 Operation of Multiple Contingency Analysis Activity

Table 6-24. Running Modes for Multiple Contingency Analysis
Disabled Enabled Action

Multiple Contingency Power Flow Control
Analysis Options and required file- Only user specified contingencies defined in contin-
Tripping Simulation names have been gency description file are tested.
Corrective Actions* specified.
Power Flow Control AC contingency analysis will be performed to all user

Multiple Contingency specified contingencies with tripping simulations. All
Tripping Simulation
Analysis converged post-contingency states will be checked
Options and required file- against the tripping conditions. If tripping actions are
Corrective Actions* names have been activated, the post-tripping condition at the last stage
specified. of tripping simulation will be saved in the output file.
Contingency analysis with tripping simulation is
Power Flow Control performed. Each post-contingency condition will be
Multiple Contingency checked against the tripping conditions. If tripping
Analysis actions are activated, post-tripping condition at the
Corrective Actions* Tripping Simulation last stage of tripping simulation will be saved in the
Options and required file- output file. Tripping events activated following a
names have been contingency will qualify the case as failure, so that its
specified. next-level contingencies are skipped if failure cutoff
is enabled.
* Corrective action analysis can be enabled or disabled for any running mode.
Running mode refers to a combination of selections of three options in multiple-level contingency

analysis: perform multiple-level contingency analysis, perform tripping simulation and perform
corrective action. Running mode determines which sequences following a contingency are simu-
lated, the solutions with respect to one of the options can be found in ACCC output files only if the
option is enabled in a mode.
The contingency label and contingency events of each contingency case are logged at the Prog-
ress tab as the solution process encounters it. A message identifies any network conditions that fail
to converge or which are skipped. The duplicate contingencies at secondary and tertiary levels will
not be presented in the Progress tab.
6.13.12 Contingency Analysis Results

The multiple level AC Contingency Solution function calculates post-contingency, post-tripping and
post-corrective actions contingency solution results (loadings on monitored branches and inter-
faces, and bus voltage magnitudes) and places them into the specified Contingency Solution
Output file. These results may then be tabulated using any or all of three output processing func-
tions: the AC Contingency Single Run Report function; the AC Contingency Multiple Run Report
function; the auxiliary program AcccBrwsGrid (see Section 6.10.3 AC Contingency Output).
6-168
Program Operation Manual N-1-1 Contingency Solution

The multiple level AC contingency solution can automatically generate and test single, double, or
multiple contingencies. The labels of the single contingencies generated by a contingency ranker
in the multiple level AC contingency solution contain the name of the contingency ranker and an
identifier. For branch outage the identifier is from bus, to bus and the branch circuit ID, e.g.
OVRLOD 219-220(1); for machine outage it is generator bus number and machine ID, e.g. UNIT
221(1). The other rankers for single branch contingencies are VLTAGE and ISLAND.
The label of a double and multiple contingency contains a sequence number for each single contin-
gency which is combined to form the double or multiple contingency; and these numbers are
separated by an underscore. As discussed in preceding sections, the function works with a contin-
gency list, the sequence number of a single contingency indicates its position in the corresponding
contingency list. The label of a double contingency contains two numbers; the first number indicates
the position of the primary contingency in the first level list and the second indicates the position of
the secondary contingency at the second level list. These numbers are followed by the labels of the
primary and secondary contingencies. A multiple contingency contains three numbers and the last
one indicates the position of the tertiary contingency in the third level contingency list.
Example:
A double contingency 4_10(N1OVRLOD 1:N1OVRLOD 3) consists of two contingency events,

‘N1OVRLOD 1’ and ‘N1OVRLOD 3’, the number 4 in the label indicates the primary contingency
‘N1OVRLOD 1’ is the fourth contingency in the first level contingency list, the ‘N1OVRLOD 3’ is the
tenth contingency in the second level contingency list.
Post-tripping solutions at the last stage of tripping simulation for each contingency that triggers trip-
ping events are saved into output files in the same format as contingency cases. The label of a post-
tripping solution is generated by the programs, and is comprised of the first ten letters of the label
of the contingency activating tripping actions and ended with /T, which identifies the case as a post-
tripping case. Normally contingency legends for a tripping solution will include tripping labels,
description of the monitored element that triggers the tripping activities, and description of tripping
activities, due to limited space to save the legends, when the number of tripping activities and moni-
tored elements in a tripping solution is more than 32, only tripping labels are saved as contingency
legends.
The post-corrective action solution and activated corrective actions are stored into output files if the
Perform corrective actions option is enabled.
There is no limit on the number of contingencies that can be tested in a contingency analysis, while
the size of a contingency analysis output file is limited by Operating system. When the contingency
analysis file reaches its size limit, contingency analysis is terminated and the rest of contingencies
are ignored.
6.14 N-1-1 Contingency Solution
6.14.1 About N-1-1 AC contingency analysis

A simultaneous double contingency, e.g. the outage of two single transmission lines, can be simu-
lated with the proceeding functions, ACCC or Multiple-level Contingency Analysis. A double
contingency can also occur sequentially, in the form of loss of one system component, possibly
followed by some automatic or operator initiated system adjustments, then followed by another loss
of a system component. This type of outages is sometimes known as an N-1-1 contingency.
6-169
N-1-1 Contingency Solution Program Operation Manual
Some definitions of terms applied to the N-1-1 contingency solution documents are identified as
follows:
• Base Case: the original base case.

• Primary Contingency: the N-1 Contingency, in the pair of N-1 contingencies, which
occurs first.
• Secondary Contingency: the N-1 contingency that occurs after the primary contingency
and system adjustments.
• Performance criteria which define system stability, thermal and voltage limits under pri-
mary and secondary contingencies
• System security: A system is secure if, following any one of the credible contingencies,
all components remain within performance criteria without the need for additional
system control adjustments.
• Secure control: A process to determine appropriate system adjustments to ensure
system security and is implemented by the Security Constrained Optimal Power Flow
(SCOPF).
• System Adjustments: Actions made by regulating the controlling devices, such as
phase angle regulators.
The N-1-1 contingencies are credible disturbances that may occur in a power system and are
required to be tested, according to many reliability standards. Figure 6-38 shows the evaluation
process for a pair of N-1 contingencies. The N-1-1 contingency solution performs an AC power flow
to solve the primary contingency, applies the appropriate system adjustments to return the system
to an acceptable state, in accordance with the program user's preference, and then runs another
AC power flow to solve the secondary contingency.
Solve a primary
contingency
Implement system
adjustments
Solve a secondary
contingency
Figure 6-38. Flow chart to test a pair of N-1 contingencies
The process is repeated until all pairs of N-1 contingencies are tested. The results are stored in a
binary file (*.acc), which can subsequently be processed to produce a variety of flow and voltage
limit violation reports. To perform an N-1-1 contingency solution, there are several steps:
6-170
1. Produce the Distribution Factor Data file from the *.sub, *.mon and *.con files (using activity
DFAX). The primary contingencies are specified in the contingency description data file
(*.con)
2. Specify another contingency description data file containing definitions of the secondary
contingencies.
3. Specify the sets of automatic control options used to conduct power flow solutions for the
primary and secondary contingencies, respectively.
4. Specify the control mode for system adjustments between each primary and secondary
contingency pair.
5. Perform the N-1-1 Contingency Solution and produce a Contingency Solution Output file.
6. Produce the selected AC Contingency Report(s) using the Contingency Solution Output file.
A challenge in testing N-1-1 contingencies is to determine the appropriate settings of system adjust-
ments following the primary contingency. There are many different types of control adjustments at
different locations in the power system. Furthermore, different reliability standards may have
different goals and strategies for implementing the system adjustments. The N-1-1 Contingency
Solution function in PSSE can be performed with any one of three control modes: (1) Local control
mode, (2) Corrective action mode and (3) Preventive Security constrained optimal power flow
(PSCOPF) mode. Under each mode, several types of controls are available to adjust system to
meet the specified goals.
The following table lists the three control modes to implement the system adjustments.
Table 6-25.
Adjustment mode Available adjustments Implementation Report

• Tap adjustments
Each adjustment is
• Switched shunt adjustments
made to achieve its
• Phase shift adjustments local objective, i.e., to The adjustments
Local control mode • DC tap adjustments control a specific bus are not available
voltage, power flow or for reporting.
• Area interchange control
area interchange
• Induction machine response to schedule.s
low voltage
• On-line generator MW controls
Adjustments are made
• Load controls by a corrective action The adjustments
• Phase shifter controls analysis algorithm to made can be
Corrective action
maintain the power reported using the
mode • Off-line generator MW controls system within defined AC Contingency
• Tap setting adjustments criteria after each Report function.
• Switched shunt controls contingency
6-171
Table 6-25.
• On-line generator MW controls

Adjustments are made
• Load controls The adjustments
by a preventive secu-
Preventive Security • Off-line generator MW controls can be reported
rity constrained optimal
constrained optimal with AC contin-
• Phase shift controls power flow algorithm to
power flow mode gency single run
ensure a secured
• Tap setting adjustments report.
system state
• Switched shunt controls
The primary contingency is solved by a full AC power flow solution. When automatic adjustment
options are enabled, the power flow solution will adjust the controls with the aim of meeting pre-
defined branch flow, bus voltage and area interchange schedules. For instance, when tap adjust-
ment is enabled, the transformer turns ratio is adjusted to control the voltage at a pre-specified bus.
The desired voltage is the control objective of the transformer. The control is local, since the impacts
of the turns ratio adjustment on voltages at other buses or on branch flows are not considered.
Therefore, adjustments are made by the power flow solution to achieve their respective local
objectives.
A solution under a primary contingency is deemed infeasible if the system condition does not
comply with steady state performance criteria, because of thermal limit and/or bus voltage viola-
tions. If control devices are available, the system problems may be resolved by performing a
corrective action analysis, which is formulated as an optimization problem with the objective of
removing the violations while minimizing the system adjustments, subject to operational constraints.
Even though the operation strategies determined by the corrective actions analysis can mitigate the
system problems after a primary contingency, the system may still not be in a secure state, which
means that the system may not be within acceptable criteria if a secondary contingency occurs,
unless more corrective actions are taken. To ensure a secure system operation condition, a preven-
tive security constrained optimal power flow can be performed. The control adjustments determined
by PSCOPF are meant to ensure a feasible and secure solution, that is, no limit violations after the
primary contingency and no limit violations if any one from a list of predefined secondary contingen-
cies occurs.
Therefore, the tool for conducting N-1-1 studies should be powerful and yet flexible enough to allow
one to analyze the different scenarios described above. The N-1-1 contingency solution in PSSE
has the following features:
• Automatically set up to assess pairs of N-1 contingencies.

• Determine the system state after each primary contingency under one of three adjust-
ment modes described above: local control, corrective action, and preventive security
constrained optimal power flow.
• Produce a variety of reports to document any thermal and voltage limit violations after
each primary contingency and each pair of N-1 contingencies, as well as the system
adjustments determined by corrective action or by PSCOPF.
N-1-1 contingency solution options

Two N-1-1 contingency solution functions are described:
6-172
• N11_ACCC, the function for performing N-1-1 contingency analysis in the local control
mode.
• N11_ACCC_PSCOPF, the function for performing N-1-1 contingency analysis in either
the corrective action mode or the preventive security constrained optimal power flow
mode.
Select solution options for power flow calculations performed

to obtain the post-primary contingency solutions (see
Section 6.2, Power Flow Solution Methods).
Tap adjustment:
• Lock taps
• Stepping
• Direct
• Disabled
• Tie lines only
Primary Contingency-case Solution options • Tie lines and loads
• Lock all
• Enable all
Enable or disable dc tap adjustments
Induction motor treatment flag applied when an induction
motor fails to solve due to low terminal bus voltage
• stall
• trip
6-173
Select solution options for power flow calculations performed

to obtain the post-secondary contingency solutions.
Tap adjustment:
• Lock taps
• Stepping
• Direct
• Disabled
• Tie lines only
Secondary Ccontingency- case Ssolution • Tie lines and loads
options
• Lock all
• Enable all
Enable or disable dc tap adjustments
Induction motor treatment flag applied when an induction
motor fails to solve due to low terminal bus voltage:
• stall
• trip
Solution Engine Select one solution engine for both primary and secondary
contingency solutions (see Section 6.2, Power Flow
Solution Methods).
• Fixed slope decoupled Newton-Raphson (FDNS)
(default)*
• Full Newton-Raphson
* The optimized fixed slope decoupled Newton-Raphhyson
method is used when N-1-1 contingency solution is initiated
via the graphical user interface. The user may choose either
the regular or the optimized fixed slope decoupled Newton-
Raphson method when initiating N-1-1 contingency analysis
from an automation file.
Non-divergent solution Option to enable or disable non-divergent solution in each

power flow solution
Dispatch mode Option for generation dispatch to handle system

load/generation imbalance caused by a contingency (see
Section 6.9.4, About Generation Dispatch).
• Subsystem machines (Reserve)
• Subsystem machines (PMAX)
• subsystem machines (Inertia)
• subsystem machines (Governor droop)
Dispatch system specifies the subsystem containing the
machines participating in the selected dispatch
6-174
Tolerance used to check for the largest initial active or

reactive power mismatch. If exceeded, the N-1-1
contingnecy solution process is terminated.
Mismatch tolerance (MW) This value is also used as the convergence
tolerance in the power flow solution of each primary and
secondary contingency (see Section 6.2, Power Flow
Solution Methods).
Flag to skip the secondary contingencies. It applies when a
primary contingency causes thermal or voltage limit
Skip the Secondary contingencies if the
violations,
corresponding Primary contingency has
• Skip the analyses of all the secondary contingencies
violations
associated with the primary contingency
• Continue to assess the secondary contingencies.
Select the control mode to implement the system

adjustments:
• Local mode, automatic adjustments are made during
the power flow solution
System adjustment mode
• Corrective action mode, system adjustments are
determined by corrective actions analysis.
• Security constrained OPF mode, preventive system
adjustments are determined by PSCOPF analysis
Rating set to be used in determining monitored element
loading violations in primary contingency solutions
• A
• B
• C
Rating set to be used in determining monitored element
loading violations in secondary contingency solutions
• A
Constrained Options
• B
• C
Specify percent of flow rating to be used in determination of
branch and interface flow overloads in primary and
secondary contingency solutions.
Branch overload violation tolerance (%) and Bus voltage
violation tolerance (%) are used only in the corrective action
mode or the PSCOPF mode (see next table).
(*.dfx) a required file to be build by activity DFAX that corre-
sponds to the network condition contained in the working case
(refer to Section 8.1.7, Application Notes) and to the desired
linear network analysis data files (refer to Section 8.1.1, Linear
Distribution Factor Data File Network Analysis Data Files). The bus input option (refer
toSection 3.3.3, Program Run-Time Option Settings and
activity OPTN) must have the same setting that was in effect
when activity DFAX filled the specified Distribution Factor Data
file.
6-175
(*.con) an optional file containing the secondary contingency

definitions. When not specified, a secondary contingency is
Contingency Description Data File for
selected from the contingency description data file that is
secondary contingency
used to build the dfax. When specified, a secondary contin-
gency is selected this contingency description data file.
( *.thr) an optional file, created by the user, that contains

data records of the following form:
IBUS, JBUS
where IBUS and JBUS are bus numbers. If branch outage
Load Throwover Data File
contingency events isolate bus IBUS, the user can elect to
move the load to bus JBUS. Bus IBUS and/or JBUS may be
a dummy bus of a multi section line grouping. Data records
may be entered in any order. Input is terminated with a
record specifying an IBUS value of zero.
(*.inl) a required file if the generation dispatch is enabled and
either the inertial or governor droop dispatch method is
selected. If the PMAX or reserve method is selected, the
Unit Inertia Data File
specification of this file is optional. If a file is specified,
machine active power limits are taken from it; otherwise, the
machine active power limits in the working case are used
(*.acc) a required file designated by the user as the destina-
Output file (results)
tion for the results of the contingency calculations
The following options are used only when the system adjustment mode is set as Corrective action
or Security constrained OPF.
Maximum number of PSCOPF iterations when the system

Iteration # of PSCOPF
adjustment mode is Security constrained OPF
Iteration number of a secondary contingency to be solved in
PSCOPF process. At each iteration of PSCOPF, each
secondary contingency will be solved by a power flow solu-
tion, its results will be checked to determine flow and
Cutoff of clean cases
voltage limit violations. If a secondary contingency does not
cause any limit violations in several consecutive iterations
of PSCOPF, it will not be tested any more in subsequent
iterations.
6-176
Flag to enable or disable generator active power dispatch

(see AC Corrective Actions)
Weighting factor for generator active power dispatch
Control subsystem of participating generators
Flag to enable or disable load controls

Weighting factor for load controls
Control subsystem of participating loads
Flag to enable or disable phase shifter controls

Weighting factor for phase shifter control
Control subsystem of participating phase shifters
Control options
Flag to enable or disable off-line generator active power
dispatch
Weighting factor for off-line generator controls
Control subsystem of participating off-line generators
Flag to enable or disable tap setting adjustments

Weighting factor for tap setting adjustments
Control subsystem of participating transformers with tap
setting adjustment capability
Flag to enable or disable switched shunt controls

Weighting factor for switched shunt controls
Control subsystem of participating switched shunts
Branch overload violation tolerance (%):
The tolerance used in the linear programming algorithm to
determine if a flow rating violation has been resolved. E.g.,
if the tolerance is specified as 0.1% and the percent of flow
rating is specified as 100%, the algorithm will ensure that
the flow is within 100.1% of rating.
Constrained options (for Corrective action Bus voltage violation tolerance (%):
mode or Security constrained OPF mode only)
The tolerance used in the linear programming algorithm to

determine if a bus voltage violation has been resolved. The
tolerance is applied to both upper and lower voltage limits.
E.g., if the tolerance is specified as 0.1%, and the lower and
upper bus voltage limits are 0.95 and 1.05 in pu, respec-
tively, the algorithm will ensure that the bus voltage is
between 0.949 and 1.051 pu.
6.14.2 Perform N-1-1 Contingency Analysis

To launch the N-1-1 contingency analysis, select Power Flow  Contingency, Reliability, PV/QV
 N-1-1 Analysis
6-177
Running in the Local Control Mode

The process to perform N-1-1 contingency analysis is determined by the selection of system adjust-
ment control mode. When the local control mode is specified, the flow chart of the process is shown
in Figure 6-39
Base case
Implement a primary
contingency
Solve the power flow

solution with automatic
system adjustments
Check the results

against performance
criteria
Yes Yes Stop the process for the

Thermal or voltage Skip the secondary
pair of N-1
violations ? contingencies?
contingencies
No No
Impose and solve a

Figure 6-39. Flow chart of evaluation process under local control mode for a pair of N-1
contingencies
The process consists of several steps:
1. Set up the base case, contingency definitions for primary and secondary contingencies,
monitored elements, etc. to prepare for contingency analysis.
2. Impose a primary contingency and calculate the power flow solution with the primary-contin-
gency-case power flow solution options. When automatic system adjustments are enabled,
they are implemented by the power flow solution to meet their own respective specified bus
voltage, branch flow or area interchange schedules.
6-178
3. If the option to skip secondary contingencies if the corresponding Primary contingency has
violations is turned on, the results from the primary contingency solution are checked
against performance criteria to identify possible flow and voltage limit violations. If violations
are detected, the secondary contingencies that are associated with the primary contingency
will not be tested. Otherwise proceed to the next step.
4. Impose a secondary contingency and solve it with secondary contingency-case solution

options. When automatic system adjustments are enabled, they are implemented by the
power flow solution to meet their own respective specified bus voltage, branch flow or area
interchange schedules in the post-contingency state.
Figure 6-40 is an example of the progress output from an N-1-1 contingency solution in local control
mode.
Figure 6-40. Progress output from N-1-1 contingency analysis in local control mode
6.14.3 Running in the Corrective Action Mode

When the system adjustment mode is corrective action, the procedure becomes more extensive.
Both power flow solution adjustments and corrective actions controls may be involved in the
process. Available controls for corrective actions are specified via the control options definitions: the
flag to enable or disable a control adjustment type, the weighting factor, and the control subsystem
to identify participating control elements. The corrective action has a higher priority in making the
control adjustments. For example, if tap setting adjustments is selected as a corrective actions
control and tap adjustment is also enabled as a contingency case solution option, the local objective
of each transformer is ignored and its tap is adjusted, as necessary, to resolve violations anywhere
in the system.
6-179
The flow chart of the evaluation process under corrective action mode is shown in Figure 6-41.
Base case
Implement a
primary
contingency
Check the solution

against primary
contingency-case
performance criteria
Yes Run corrective actions

Violations? analysis to mitigate the
operation limit violations
No
Impose and solve

a secondary
contingency
Check the solution

against secondary
contingency-case

Violations? analysis to mitigate the
operation limit violations
No
Finish the pair of

N-1 contingencies
Figure 6-41. Flow chart of evaluation process under corrective action mode for a pair of N-1
contingencies
6-180
The process consists of several steps:
2. Impose a primary contingency and calculate the power flow solution with the primary contin-
gency-case solution options. When automatic system adjustments are enabled, they are
implemented by the power flow solution to meet their own respective specified bus voltage,
branch flow or are interchange schedules.
3. The results from the primary contingency solution are checked against system performance
criteria to identify possible thermal and voltage limit violations. If overloads and/or voltage
limit violations are found, a corrective action analysis is performed to determine adjustments
suitable for eliminating the violations.
4. If the option of skip the secondary contingencies if the corresponding Primary contingency
has violations is turned on and the limit violations identified in the previous step cannot be
eliminated completely by the corrective actions, the secondary contingencies that are asso-
ciated with the primary contingency will not be tested and the process of evaluation of the
pairs of N-1 contingencies will be terminated. Otherwise proceed to the next step.
5. Apply the control adjustments determined from the corrective action analysis on the system
with the primary contingency and perform an AC power flow solution again. This solution is
used as the initial condition for the analysis of the secondary contingencies.
6. Impose one secondary contingency and calculate the power flow solution with the
secondary contingency-case solution options. When automatic system adjustment options
are enabled, they are implemented by the power flow solution to meet their own respective
specified bus voltage, branch flow or are interchange schedules.
7. The results from the secondary contingency solution are checked against system perfor-
mance criteria to identify possible thermal and voltage limit violations. If violations are found,
a corrective action analysis is performed to determine the adjustments suitable for elimi-
nating the violations.
The is an example of the progress output from an N-1-1 contingency solution in corrective action
control mode. Following the solution of primary contingency "N1VORLOD 1", a corrective action
6-181
analysis is performed and adjustments are made to remove the violations found. Similarly, following
the solution of a secondary contingency, corrective action analysis is performed.
Figure 6-42. Exampe of progress output from an N-1-1 contingency solution corrective
action control mode
6.14.4 Running in the Security Constrained OPF Mode

When the system adjustment mode is PSCOPF, the power flow solution adjustments, corrective
actions as well PSCOPF are all involved in the process. Available controls for corrective actions and
PSCOPF are specified via the control options definitions: the flag to enable or disable a control
adjustment type, the weighting factor, and the control subsystem to identify participating control
elements. The PSCOPF and corrective action have higher priority in making the system adjust-
ments, compared with the local adjustments defined in the power flow solution options. The flow
chart of the evaluation process under the security constrained OPF mode is shown in Figure 6-43
6-182
Base case
Implement a primary
contingency
Solve the power flow

solution with automatic
system adjustments
Check the security of

the primary contingency
solution
Run Security
No Constrained Optimal
Secure?
Power Flow to ensure
the system security
Yes
Impose and solve a

Check results against

secondary contingency-case

Thermal or voltage
analysis to mitigate the
violations ?
violations
No
Stop
Figure 6-43. Flow chart of evaluation process with PSCOPF mode for a pair of N-1
contingencies
6-183
There are several steps in the N-1-1 contingency solution using the PSCOPF mode:
2. Impose a primary contingency and calculate the power flow solution with the primary-contin-
gency-case solution options. When automatic system adjustments are enabled, they are
implemented by the power flow solution to meet their own respective specified bus voltage,
branch flow or area interchange schedules.
3. The results from the primary contingency solution are checked against system performance
criteria to identify possible thermal and voltage limit violations. If overloads and/or voltage
limit violations are found, a corrective action analysis is performed to determine adjustments
suitable for eliminating the violations.
4. If the option of skip the secondary contingencies if the corresponding Primary contingency
has violations is is turned on and the limit violations identified in the previous step cannot be
eliminated completely by the corrective actions, the secondary contingencies that are asso-
ciated with the primary contingency will not be tested and the process of evaluation of the
pair of N-1 contingencies will be terminated. Otherwise proceed to the next step.
5. Apply the control adjustments determined from the corrective action analysis on the system
with the primary contingency and perform an AC power flow solution again. This solution is
used as the initial condition for the analysis of the secondary contingencies prior to the
preventive security constrained optimal power flow.
6. Perform a preventive security constrained optimal power flow with the solution in step 5 as
the base case and the secondary contingencies as contingency constraints. Determine the
system adjustments necessary to ensure system security of the post-primary contingency
case.
7. Apply the system adjustments determined from the preventive security constrained optimal
power flow analysis as well as from the corrective actions analysis in step 3, on the system
with the primary contingency and perform an AC power flow solution again. This solution will
be used as the initial condition for the analysis of the secondary contingencies.
8. Impose one secondary contingency case and perform a power flow solution with secondary
contingency-case solution options. If automatic local system adjustments are enabled, they
are implemented by the power flow solution to meet their respective specified bus voltage,
branch flow or are interchange schedules.
9. The results in the secondary contingency solution are checked against system performance
criteria to determine if there are thermal and voltage limit violations. If any violations are
found, a corrective action analysis is automatically performed to determine the system
adjustments necessary to eliminate the violations.
This is an example of the progress output from an N-1-1 contingency solution in PSCOPF mode.
Following the solution of primary contingency "N1VORLOD 1", the corrective action analysis is
performed and the adjustments are made to remove the violations in the solution. Subsequently,
PSCOPF starts to perform a secure control.
6-184
Figure 6-44. Progress output from an N-1-1 contingency solution in PSCOPF mode
In each mode, the initial system condition, or base case condition, for secondary contingencies is
different. The following table summarizes the base case condition for secondary contingencies
under each mode.
Adjustment mode Initial system condition for the secondary contingencies

Local control The power flow solution after a primary contingency
Corrective action The power flow solution after the primary contingency is imposed and
the system is adjusted by adjustments made by corrective actins.
PSCOPF The power flow solution after the primary contingency is imposed and
the system is adjusted by adjustments made by PSCOPF
The AC Contingency Solution function responds to the following interrupt control codes:

NM Suppress any automatic adjustment monitors (only used with CM interrupt control
code).
6-185
DC Tabulate conditions for each dc line after each iteration (see Section 6.3.11,
FD Tabulate conditions for each FACTS device after each iteration (see Section 6.3.11,
Operation of Activity SOLVs).
The N-1-1 Contingency Solution functions calculate contingency solution results (loadings on moni-
tored branches and interfaces, and bus voltage magnitudes) and place them into the specified
Contingency Solution Output file. These results may then be tabulated using the AC Contingency
Single Run Report function (Section 6.10.9, AC Contingency Single Run Report). In the reports
created by AC Contingency Single Run Report function, the contingency labels of the pair of N-1
contingencies are present together. The Figure shows a sample of non-converged network report.
Figure 6-45. Sample of non-converged network report
In using AC Contingency Single Run Report function to produce one of the report formats: spread-
sheet or non-spreadsheet overload report, spreadsheet or non-spreadsheet loading report,
available capacity report, Base case rating is used to calculate the loading percent of monitored
elements in base case and primary contingency solutions; contingency case rating is used to calcu-
late loading percent of monitored elements in secondary contingency solutions. Figure 6-46 shows
a sample of spreadsheet overload report.
Base case rating
Figure 6-46. Sample of spreadsheet overload report
If a N-1-1 contingency solution is started with either corrective action or PSCOPF mode, a correc-
tive action report can be produced to tabulate the flows and voltages in the solutions before and
after adjustments, as well as adjustments. If corrective action mode is selected prior to N-1-1 contin-
gency solution, the results of adjustments are corrective actions specified in step 3 and step 7 of N-
1-1 analysis procedure with corrective action mode following each primary and secondary contin-
gency solution respectively. In using PSCOPF mode, the results of adjustments following each
primary contingency solution are the total adjustments made by corrective action and PSCOPF,
step 3 to step 7 in N-1-1 analysis procedure with PSCOPF mode; the results following each
secondary contingency solution are corrective actions. Figure 6-47 shows a sample of corrective
action report.
6-186
Program Operation Manual Calculating Probabilistic Reliability
Figure 6-47. Sample of corrective action report
6.15 Calculating Probabilistic Reliability
Run Probabilistic Reliability Assessment - GUI

Power Flow > Reliability > Reliability Assessment…
[Probabilistic Reliability Assessment]
AB
The applications of probabilistic methods can provide points of view from transmission planners and
operators, focusing on the frequency and duration of system problems, or from customers focusing
on the impact of unreliability on load curtailments. Typically probabilistic reliability assessment is
applied to:
• Calculation of reliability indices;

• Weak points analysis, i.e. components most affected by outages;
• Comparisons between different operating conditions, network structure as well as plan-
ning alternatives.;
• Analysis of effectiveness of corrective actions
The transition from deterministic contingency analysis to probabilistic assessment for system prob-
lems is an easy one. Probabilistic reliability analysis is provided via an additional post-processing
function to calculate probabilistic indices for local and system problems with given outage statistics
6-187
Calculating Probabilistic Reliability Program Operation Manual
for each contingency. The reliability assessment package as shown in Figure 6-48 consists of a
calculation part, which evaluates each contingency and models predefined tripping and corrective
action sequences, and an analysis part, which conducts a detailed analysis on the basis of the eval-
uated contingency sequences.
The results are referred to as probabilistic indices. They are composite probabilities of problems
given in terms of frequency and duration indices, and determined by probabilities of transitions from
'success' operating conditions to 'failure' operating conditions. Generally, outage statistics are given
in terms of frequencies and duration to reflect the probability that a transmission element will be
forced out-of-service, and to calculate transition probabilities.
The procedure of performing probabilistic reliability analysis consists of three steps (Figure 6-48):
• Perform contingency analysis. The contingency screening results (.acc output files) are
required to computed reliability indices.
• Set up options, specify input files, and perform reliability assessment. If deterministic
reliability indices are computed, Outage Statistics Data file is not required.
• Analyze the results
Perform contingency
analysis
Outagestatistic
Outage Statistics Data
data *.acc
Calculate and report

probability indices
Figure 6-48. Process of Probabilistic Reliability Assessment
6-188
6.15.1 Probabilistic Reliability Assessment

Table 6-26. Probabilistic Reliability Assessment Options
Option Description
The user selects from among the following reports:
• system problem summary
• system loss of load
• bus loss of load
• branch flow overloading
• bus voltage violations
• contingency summary for
Report format • system problem probabilistic indices

• system load curtailment probabilistic indices
• bus load curtailment probabilistic indices
• branch flow overloading probabilistic indices
• bus voltage violation probabilistic indices
• contingency summary with probabilistic indices
When no probabilistic data is available or the studies are limited in deterministic
reliability area, the users can produce the first six reports for deterministic reli-
ability analysis, and each contingency will have identical statistic data.
Probabilistic reliability analysis can be performed in one of three modes, subject
to the corresponding running mode specified during contingency analysis.
• post-contingency mode: Select the post-contingency solutions as the
states in the determination of system and component problems
• post-tripping mode: Select the solutions after tripping events as the
states for calculations of probabilistic indices. If contingency analysis has
been initiated without tripping simulation, post-tripping solution of a
Output mode contingency is identical to its post-contingency solution.
• post-corrective action mode: Select the solutions after corrective action
analysis for probabilistic reliability analysis. If contingency analysis has
been initiated without corrective actions; post-corrective action solution of
a contingency is identical to its post-contingency solution if tripping
simulation enabled in contingency analysis, or to its post-contingency
solution if tripping simulation disabled. In this mode a contingency and
complete sequences following it are taken account into probabilistic
reliability assessment.
Branch rating set Branch rating set and loading percentage: define branch loading limits used in
Loading percentage determining overloads.
Defines voltage limits used in determining bus voltage limit violations. The
Voltage limit voltage limits apply to buses specified by monitor voltage limit records (see
Section 8.1.3 Monitored Element Data File Contents).
6-189
Table 6-26. Probabilistic Reliability Assessment Options (Cont.)
Option Description
Define the study subsystem where the probability indices are calculated. There
is a Entire system subsystem set by the programs, when selected, analysis is
performed within entire system. Probabilistic Indices can also be obtained for a
specific subsystem predefined in Subsystem Description Data file (see
Section 8.1.2 Subsystem Description Data File Contents). When a
Subsystem
subsystem is designated, only monitored elements in the subsystem are
checked against failure criteria to determine whether a contingency solution has
problems. For bus voltages being checked, buses must be part of that
subsystem; for line flows being checked, both of ends of a line must be in the
subsystem.
Enable (default) or disable to include interfaces. Interfaces are not part of any
Include interfaces subsystems. If enabled, the impacts of interfaces on probability indices of the
specified subsystem will be accumulated.
Enable (default) or disable to include the impacts of tie lines on probability
Include ties
indices of the specified subsystem.
Enable (default) or disable to exclude contingencies from probabilistic reliability
Probability and analysis for which probability and frequency are less than these threshold
frequency cutoffs values. A contingency may be of low probability or frequency that the risk to the
system is low, and evaluation is superfluous.
Distribution Factor (*.dfx) Required file, used when performing contingency analysis (see activity
Data File DFAX ).
(*.acc) Required file, created with the current base case and Distribution Factor
Data file. It is recommended that the file been generated by multiple level contin-
Contingency Solu-
gency analysis function (see Section 6.13 Performing Multi-Level AC
tion Output File
Contingency Solution), When this file is generated by simple ACCC, analysis
is limited to deterministic reliability assessment.
Required file; the Reliability Outage Statistics file (*.prb) contains outage statis-
Outage Statistics
tics of user specified contingencies and individual components (see
Data File
Section 6.15.2 Outage Statistics Data File Contents).
Output outage
Enable or disable (default) output of outage statistics to a file.
statistics
Required when Output outage statistics option is selected. The file is used to
Output Outage convert generic statistics to specific statistics for individual components.The
Statistics Data File resulting file can be edited and modified for future use. It has the same format as
Outage Statistics Data file.
6.15.2 Outage Statistics Data File Contents

The Outage Statistics Data file is used to specify frequencies and durations for individual element
outages and user specified contingencies. Outage statistics for individual elements, including non-
transformer branches, transformers and machines, must be specified. They are also used to calcu-
late outage statistics of multiple independent element contingencies for which statistics are not
specified. Statistics for user specified outages can be defined in Outage Statistics Data file or in the
Contingency Description Data file; when both files contain statistics for a user specified contingency,
values are taken from Outage Statistics Data file. When no statistics data is entered for a multiple
element contingency, the contingency is treated as a multiple independent element outage and its
statistics are calculated on the basis of outage statistics of each single element within it. If a user
6-190
specified contingency contains one or more FACTs device outages, closing events, or boundary
condition change events, its statistics are set to zeros if not specified. Contingencies generated
automatically by the multiple level contingency analysis are treated as independent multiple
element contingencies, their outage statistics are thus calculated. The following examples illustrate
how to specify outage statistics.
Example 1: There is no need to specify outage statistics of contingencies created by global

command 'DOUBLE', each double branch contingency is treated as a multiple independent outage
and its outage statistics are calculated from frequency and duration of two branches within it.
Example 2: Contingency A has branch B outage. Statistics for contingency A can be specified in the
Outage Statistics Data file or in the Contingency Description Data file. Otherwise its statistics are
equal to the statistics for the outage of branch B. If no invalid outage statistics data record is read
for branch B in Outage Statistics Data file, outage statistics of contingency A are zero.
Example 3: Contingency A has branches B and C outages. Statistics for contingency A can be spec-
ified in the Outage Statistics Data file or in the Contingency Description Data file. If no statistics are
specified for contingency A, its statistics are equal to frequency and duration of the multiple inde-
pendent outaging of branches A and B. If no invalid outage statistics data records are read for either
branch B or C, outage statistics of contingency A are zero.
Example 4: Contingency A has branch B and FACTs device C outages. Statistics for contingency A
can be specified in the Outage Statistics Data file or in the Contingency Description Data file. If no
statistics are specified for contingency A, its statistics are zeros.
6-191
Please refer to input data files for AC Contingency Analysis (in Section 6.10.1 AC Contingency
Solution Options) for notational conventions used in the outage statistics data file. Frequency value
is designated in occurrence per year and duration value is in hour. Generally, there are two types
of data records: generic outage statistics data record to specify outage statistics for a set of
elements, and specific outage data record for a single element. The following data record defines a
set of non-transformer branches that have the same outage statistics:
|LINES | |IN | |AREA i | xm bm ft dt fmt dmt

|BRANCHES| |FROM | |ZONE i |
|OWNER i |
|KV r |
|SYSTEM label|
|SUBSYSTEM label|
Where: xm is branch reactance (ohm/mile), bm is branch charging susceptance (S./mile), ft is

outage frequency for terminal caused single circuit outages, dt is repair time for terminal caused
single circuit outages, fmt is outage frequency for single circuit outages per mile, and dmt is outage
durations for single circuit outages. In using system or subsystem keywords, the label must corre-
spond to a subsystem label specified in a previously accessed Subsystem Description Data file. In
using IN keyword, both bus ends of a non-transformer branch must be associated with a specified
subsystem to be included. In using FROM keyword, either end of a non-transformer branch is asso-
ciated with a specified subsystem to be included. The frequency F and duration D of a single line
outage are calculated as:
F = len*fmt+ft
D = (mft*dmt*len+ft*dt)/F
Where len is the length of a branch. When length of a branch is not specified in working case, it is
estimated by its reactance in the form of len=X/xm. For example, if the branch from bus i to bus j is
10 miles and statistics of the branch are ft=0.01, dt=10, fmt=0.02, dmt=20, then F and D of this
single branch outage are:
F = (10*0.02+0.01)=0.21 (Occurrences/year)
D = (0.02*20*10+10*0.01)/0.21=19.5 (hour)
The following data record defines outage statistics of breakers or switches within a subsystem:
|BREAKERS| |IN | |AREA i | f d [fu du fm dm]
|SWITCHES| |FROM| |ZONE i |
|OWNER i |
|KV r |
|SYSTEM label|
|SUBSYSTEM label|
In using keyword BREAKERS, the record specifies outage statistics of breakers. The breaker is a
special branch with the first character of @ in circuit ID. Where f and d are frequency and duration
of a breaker fault, optional fu and du are frequency and duration of a breaker unscheduled main-
tenance outage, optional fm and dm are frequency and duration of a breaker maintenance outage
respectively. A record employs SWITCHES keyword to specify outage statistics of switches. A switch
is a special branch with the first character of  in circuit ID. The designated values are used as
outage statistics with respect to each mode. In Probabilistic Reliability Assessment analysis, a
6-192
component has only two states: in-service or out-of-service. The probability of a component being
out-of-service is the sum of probabilities of three failure modes. When the specification data record
is read by Probabilistic Reliability Assessment function, frequency and duration of a breaker or
switch being out-of-service are calculated as follows:
F=f+fu+fm
D=(f*d+fu*du+fm*dm)/F
In Substation Reliability Assessment analysis, each component can have three failure modes: fault,
unscheduled maintenance and scheduled maintenance outages. When the record is read by
Substation Reliability Assessment function, each pair of frequency and duration values is taken for
the corresponding fault or outage mode. By default, the four optional values are set to zeros.
The following data record defines statistic data of transformers within a subsystem.
TRANSFORMERS |IN | |AREA i | f d

|FROM| |ZONE i |
|OWNER i |
|KV r |
|SYSTEM label|
|SUBSYSTEM label|
Where: f is outage frequency for transformer on site outages, d is outage duration for transformer
on site outages. In using IN keyword, for a three-winding transformer to be included, all of its in-
service windings must be connected to subsystem buses. In using FROM keyword, for a three
winding transformer to be included, one of its in-service windings must be connected to a
subsystem bus.
The following data record defines generic statistic data for a set of machines.
|UNITS | min_size max_size IN |AREA i | f d

|MACHINES | |ZONE i |
|OWNER i |
|KV r |
|SYSTEM label|
|SUBSYSTEM label|
Where: min_size and max_size are minimum and maximum size of generators in the set, the
MBASE of generators are checked against the limits. f is frequency of unit outage, d is duration of
unit outage.
The following data record defines generic statistic data for buses within a subsystem.
|BUSES | IN |AREA i | f d [fu du fm dm]

|ZONE i |
|OWNER i |
|KV r |
|SYSTEM label|
|SUBSYSTEM label|
6-193
The Probabilistic Reliability Assessment and Substation Reliability Assessment functions read the
record and match outage statistics of the buses with single bus outage events defined in a Contin-
gency Description Data file. These outages are either single bus outages specified by an automatic
single bus outage command SINGLE BUS... or contingency cases labeled as BUS plus the bus
number. The probability of the contingencies is the sum of probabilities of three modes. Specially in
Substation Reliability Assessment analysis, the record also specifies frequency and duration of
three failure modes of single bus outages generated by the function.
The following records define statistic data for a specific user specified contingency:
CONTINGENCY label f d
Where: f and d are frequency and duration of user specified outages respectively. As discussed
before, statistics of user specified contingencies can be specified in either a Contingency Descrip-
tion Data file or an Outage Statistics Data file in above format, if both files have statistics for the
same user specified contingencies, the designated values in Outage Statistics Data file will be
applied.
The following data record defines statistic data for a non-transformer branch or two-winding
transformer.
|LINE | FROM BUS bsid TO BUS bsid |CKT | cktid f d [fu du fm dm]
|BRANCH| |CIRCUIT|
The following data record defines statistic data for a breaker or switch.
|BREAKER| FROM BUS bsid TO BUS bsid |CKT | cktid f d [fu du fm dm]
|SWITCH | |CIRCUIT|
Where: f is frequency of a breaker outage, d is duration of a breaker outage.
Similarly the following data record defines statistic data for a three-winding transformer:
|LINE | FORM BUS bsid TO BUS bsid TO BUS bsid |CKT | cktid f d
[fu du fm dm]
|BRANCH| |CIRCUIT|
The following data record defines statistic data for a machine
|UNIT | macid AT BUS bsid p d

|MACHINE|
Where p is probability of machine outage, d is duration of machine outage.
The following data record defines statistic data for a bus.
BUS bsid f d [fu du fm dm]
When the multi-section reporting option is enabled, the frequency and probability of a multi section
line is equal to the sum of frequencies and probabilities of all its members.
6-194
6.15.3 Analyzing Probabilistic Assessment Results

For each monitored non-transformer branch, the percent loading is either the percent current or the
percent MVA loading, according to the non-transformer branch percent loading units program
option setting (see Section 3.3.3 Program Run-Time Option Settings and activity OPTN) specified
when performing contingency analysis to create Contingency Solution Output files. For monitored
transformers, the percent loading is either the percent current or the percent MVA loading,
according to the transformer percent loading units program option setting.
Three output modes are available when reporting results: post-contingency, post-tripping simula-
tion, and post-corrective actions. Each output mode corresponds to one stage in the evaluation of
a contingency. When performing multiple level contingency analysis (see Section 6.13 Performing
Multi-Level AC Contingency Solution), a running mode is specified according to selections of
options of perform multiple contingency analysis, perform tripping simulations and perform correc-
tive actions. The running mode determines how many stages in a contingency analysis are
involved. e.g. if all three options are selected, a contingency and its following sequences: tripping
events and corrective actions are simulated and then each contingency may have one power flow
solution with respect to each option stored in the Contingency Solution Output file, the solution after
a contingency being imposed, the one after simulating tripping events triggered by the contingency,
and the last one is after applying corrective actions that are specified to relieve violations in the
second solution. In other words, a contingency analysis consists of three stages. By specifying
output mode option, users have access to power flow solutions at each stage. If power flow solu-
tions for an output mode do not exist in the output files, power flow solutions at previous stage will
be used for the output mode. e.g., tripping simulation option is disabled prior to contingency anal-
ysis, therefore there are no post-tripping solutions in result files. If output mode is set as post-
tripping, reliability results in post-tripping mode are identical to those in post-contingency mode.
When calculating probabilistic load curtailment indices, results may be quite different in different
output modes, because load curtailments may be caused by contingencies, tripping events, gener-
ation dispatch and corrective actions.
In order to better understand the output, several examples are developed with the savnw.sav power
flow case. The .sub, .mon, and .con files for contingency analysis and an example outage statistics
data file .prb for reliability assessment are provided in the example directory. Contingency analysis
is performed by multiple level contingency analysis function with simulations of tripping and correc-
tive actions sequences.
System Probabilistic Index Summary

Figure 6-49 shows the system reliability indices summary report in post-contingency output mode.
The frequency, average duration and probability for each type of problems are calculated. Impact
indices of overloads and bus voltage violations with respect to voltage limits 'AREA 2 BUSES WITH
VOLTAGE LESS THAN 0.940 (pu)' and 'AREA 2 BUSES WITH VOLTAGE GREATER THAN 1.060
(pu)' are also given. For each type of problems, the number of contingencies causing the problem,
the worst violation as well as the contingency causing the worst violation are reported. The study
subsystem is 'Entire system', study system total indices are reported at the end. The results in post-
corrective actions mode are shown in Figure 6-50. The load curtailments are found in the post-
corrective actions solutions, while voltage violations and overloads are alleviated by corrective
actions. From a system point of view, reliability indices, frequency, average duration and probability,
are almost the same in the two stages. Furthermore, the results in post-contingency mode provides
reliability indices for system problems, and the results in post-corrective actions mode provide
impacts of system problems on electricity customers.
6-195
FREQ. DURATION PROB. IMPACT NO. OF WORST WORST
<-- F A I L U R E C R I T E R I A --> (OC/Y) (HOURS) (H/Y) CONT. VIOL.
AREA 2 BUSES WITH VOLTAGE LESS THAN 0.940 (PU) 11.9176 10.0 119.1 1.53 13 0.875 17_17
ZONE 5 BUSES WITH VOLTAGE DROP BEYOND 0.060 (PU) 0.3369 10.0 3.4 0.18 2 0.084 14_20
AREA 2 BUSES WITH VOLTAGE GREATER THAN 1.060 (PU) 8.9740 10.0 89.6 0.27 10 1.106 17_17
OVERLOAD (%) 0.4113 9.1 3.7 3.68 6 211.905 14_20
NOT CONVERGE 0.0511 5.0 0.3 6
ENTIRE SYSTEM TOTAL 12.3048 10.0 122.7 20
Figure 6-49. System Reliability Indices Summary in Post-Contingency Mode

Calculating Probabilistic Reliability
6-196
FREQ. DURATION PROB. IMPACT NO. OF WORST
<-- F A I L U R E C R I T E R I A --> (OC/Y) (HOURS) (H/Y) CONT. VIOL.
AREA 2 BUSES WITH VOLTAGE LESS THAN 0.940 (PU) 1.7018 9.9 16.8 0.29 5
AREA 2 BUSES WITH VOLTAGE GREATER THAN 1.060 (PU) 1.7198 9.8 16.9 0.07 7
ZONE 5 BUSES WITH VOLTAGE RISE BEYOND 0.055 (PU) 0.0043 5.0 0.0 0.00 2
OVERLOAD (%) 0.3361 10.0 3.4 2.49 1
LOSS OF LOAD (MW) 10.5780 10.0 105.8 14026.67 11
NOT CONVERGE 0.0511 5.0 0.3 6
ENTIRE SYSTEM TOTAL 12.3048 10.0 122.7 20
Figure 6-49. System Reliability Indices Summary in Post-Corrective Action Mode

PSS®E 34.2
System Loss of Load Report

The cumulative system loss of load summary provides detailed indices of loss of load for outages
in which one or more buses are separated from the remainder of the network, or load shedding is
performed at certain buses. The cumulative loss of load index represents the amount, frequency
and energy of load lost as given in increments, and accumulated. Incremental step size is 10 MW;
for load curtailment in excess of 1000 MW, it is grouped as one set.
Figure 6-50 shows system loss of load report in post-corrective actions mode. System load curtail-
ments results are dependent on the options used in the multiple level contingency analysis. The
sum of frequency, average duration and probability causing the corresponding amount of load
curtailments are reported. The interrupted power I.P. and Expected Unserved Energy E.U.E. are
provided. Note for E.U.E, the duration is one year (8760 hours). The study subsystem is specified
as 'ENTIRE SYSTEM'
<-- LOAD CURTAILMENTS --> FREQ. DURATION PROB. I.P. E.U.E NO. OF WORST CONT.
<----- (MW) -----> (OC/Y) (HOUR) (H/Y) (MW/Y) (MWH/Y) CONT.
80.0 -- 90.0 3.6272 10.0 36.4 290.17 2911.76 2 OVRLOD 14
160.0 -- 170.0 6.8657 10.0 68.9 1098.51 11029.22 2 OVRLOD 17
ENTIRE SYSTEM 10.4928 10.0 105.3 1388.68 13940.98 4
Figure 6-50. System Load Curtailment Probabilistic Indices
Branch Flow Overloading Indices

Figure 6-51 shows the branch flow overload deterministic reliability results, where no outage statis-
tics are required and all contingencies are assumed to have equal statistics. The following items are
calculated: average overload and maximum loading of the overloaded circuit, the number of contin-
gencies that result in overload of this circuit, and the contingency causing maximum overload.
Figure 6-53 shows overload probabilistic indices for each circuit and for the study subsystem.
Specifically, the sum of frequency, average duration and probability of all contingencies resulting in
a circuit overload are reported. The system overload impact index is equal to the sum of overload
impact indices of all circuits. As we can see, the total number of contingencies that result in overload
problem in Figure 6-51 is much bigger than that in Figure 6-53; this is because some contingencies
with overload problems had zero statistics or statistics less than cutoff values.
<----- O V E R L O A D E D L I N E S -----> AVG.OVRLOD MAX.LOADING NO. OF WORST CONT.

<------F R O M ------> <------ T O ----->CKT (%) (%) CONT.
ENTIRE SYSTEM 49
203 EAST230 230.00 154 DOWNTN 230.00 92.55 244.85 11 5_9
205 SUB230 230.00 154 DOWNTN 230.00 9.01 120.68 8 15_22
INTERFACE WEST 193.29 296.76 35 1_12
Figure 6-51. Branch Flow Overloading Probabilistic Indices
6-197
Calculating Probabilistic Reliability
<------ O V E R L O A D E D L I N E S -------> FREQ. DURATION PROB. IMPACT MAX VIO. NO. OF WORST CONT.
<------ F R O M ------> <------ T O ---- -->CKT (OC/Y) (HOUR) (H/Y) (PU) (%) CONT.
ENTIRE SYSTEM 0.4113 9.1 3.7 3.68 0.00 6
203 EAST230 230.00 154 DOWNTN 230.00 0.3518 9.8 3.4 3.62 211.90 3 14_20
6-198
205 SUB230 230.00 154 DOWNTN 230.00 0.0744 5.0 0.4 0.06 120.68 4 15_22
Figure 6-52. Branch Flow Overloading Probabilistic Indices

PSS®E 34.2

The probabilistic reliability assessment requires a Contingency Solution Output file and a Distribu-
tion Factor Data file. It is required that the working case contain the same network representation
(i.e., the same Saved Case) on which the contingency analysis calculation was based, and that the
same Distribution Factor Data file that was used in contingency analysis be specified; otherwise,
the probabilistic assessment function will terminate. When the base case remains unchanged, but
the Monitored Element Data file and/or the Contingency Description Data file (and therefore the Dis-
tribution Factor Data file) are changed, the contingency analysis must be performed again before
selecting the reliability assessment function. When adding new subsystems in the Subsystem
Description Data file (see Section 8.1.2 Subsystem Description Data File Contents) without any
changes in the Monitored Element Data file and the Contingency Description Data file, only the Dis-
tribution Factor Data file needs to be rebuilt, the reliability assessment can be performed with the
newly created DFAX file without redoing contingency analysis.
A Contingency Solution Output file created by N-1-1 contingency solution can not be used for reli-
ability assessment studies. A contingency solution output file created by activity ACCC in PSS®E
32 and previous versions can not be used to compute probabilistic reliability indices. When such a
file is used, an error message is prompted and the process is terminated.
Contingencies with frequencies and probabilities of zeros have no impact on probability indices.
When a user specified contingency does not have statistics specified, it is treated as a multiple inde-
pendent outage and its statistic data is determined on the basis of the individual outages of which
it consists. In case any one among them has unknown or zero frequency or duration, its statistics
will be zeros. For contingencies consisting of closing outages, FACTs device outages and boundary
condition changes (specified by keywords SET/CHANGE/INCREASE/ DECREASE /MOVE),
because statistics of these outages cannot be defined in outage statistic data file, statistics of such
contingencies then cannot be calculated must be given explicitly in outage statistics data file or in
Contingency Description Data file, otherwise their statistics are zeros.
The multiple level contingency analysis function can simulate a contingency and event sequences
following the contingency. For a contingency, there may be three solutions: post-contingency, post-
tripping, and post-corrective actions solutions. It is important to properly select the stage at which
the reliability assessment will be performed. When analysis is performed on solutions at the stage
that does not exist in a Contingency Solution Output file, the solutions at previous stage will be used.
Reliability measures can be obtained as a function of the severity of problems without repeating the
contingency analysis. For example, PSS®E can be used to compute failure indices for 10%, 20%,
and more severe levels of overloads. Such computations can be done entirely within activity
RELIND by adjusting the overload failure criterion and obtaining the reliability index output corre-
sponding to each overload rating. The procedure to change voltage limits is to edit voltage monitor
records in Monitored Element Data file (only the values of limits can be changed), and then recreate
the Distribution Factor Data file. The reliability assessment can then be performed with newly
created DFAX file without redoing contingency analysis. However, when other changes are made
to Monitored Element Data file and Contingency Description Data file, the whole procedure must be
gone through to perform probabilistic reliability assessment.
Reliability calculations can be obtained for different outage statistics without repeating the contin-
gency analysis. This can be done by preparing two or more sets of outage statistics, and simply
repeating the reliability calculations in RELIND after each set of outage data has been read into the
program. This feature is useful for studying the impact of severe weather conditions and to deter-
mine the sensitivity of results to specific outages and to uncertainties in outage statistics.
6-199
Calculating Substation Reliability Program Operation Manual
If there are violations in the base case with specified failure criteria, all other states will result in
system problems on the basis of the second assumption of the algorithm in PSS®E, and then the
probability of system problems should be equal to 1; in other words, system problems always exist.
In this case, PSS®E will neglect the probability of the base case, and add up probabilities of all out-
ages with system problems to calculate probabilistic indices. However, the double counting problem
is more prominent because it is most likely that tested outages have system problems if the base
case has problems.
When probabilistic indices are used to compare the relative performance of the system under dif-
ferent operating conditions or with different system configurations, a contingency analysis must be
performed for each initial system condition (base case). The different operating conditions can be
simulated by means of load or dispatch adjustments, or by outages of specific network elements in
the pre-disturbance condition. Different system configurations can be represented using appro-
priate system adjustment activities within PSS®E, such as activity CHNG.
Section 11.9, Running Probabilistic Reliability Assessment
6.16 Calculating Substation Reliability

Run Substation Reliability Assessment - GUI
Power Flow > Reliability > Substation reliability assessment…
[Substation Reliability Assessment]
AB
6.16.1 Substation Reliability Assessment
Overview
Station reliability evaluations can augment substation design principles to enable quantitative eval-
uation and comparison of alternative substation configurations. In general, substation reliability
studies are organized into seven steps as follows:
1. Define the system extent and list of components to be included. The study system may
include substation and incoming and outgoing lines/feeders.
2. Gather failure, repair, and maintenance data for each component within the study system.
3. Specify performance criteria for system failure and select the indices to be calculated.
4. Determine models and modeling assumptions.
5. Develop the reliability models mathematically.
6. Perform component failure effects and system analysis of enumerated states.
7. Compute reliability indices.
6-200
Program Operation Manual Calculating Substation Reliability
Run Options:
Table 6-27. Substation Reliability Assessment Options
Option Description
Allows user to select from among the following reports:
• Substation component report
Report format • Contingency report
• Bus load curtailment report
• Substation load curtailment report
Branch rating set
Specify branch loading limits used in determining the branch MW power transfer
and Flow rating
capacity. A branch does not have any transfer capacity if its loading limit is 0.
percentage
Specify contingency frequency cutoff value in occurrences per year. Contingencies with
Frequency cutoff frequencies of occurrence lower than the cutoff will be excluded from substation reli-
ability assessment.
Specify the loads to serve. The desired loads are curtailed when the sum of desired
loads is greater than the transfer capacity of a substation. The desired load at a sink
bus is the percent of the total MW power load at the bus. If a load consists of constant I
Peak load
and constant Y components, its active power load is calculated at unity voltage. When
percentage
the bus is connected to a tie, which has one end connected to the bus and another end
connected to a bus outside the substation system, the capacity of the tie is included
into the total load at the bus.
Specify the elapsed time (in hours) for switching operation(s) to isolate
Switching time: the faulted component(s) and re-close breakers to limit the impact of a fault; the
elapsed time is the duration for the fault at post-fault state. The same switching time is
assumed for all faults in a study.
Specify the stuck breaker failure rate (in hours per year). The rate will be used to calcu-
Stuck breaker late the frequency and probability of a circuit breaker failing to operate following a
failure rate substation component fault.
Include system ties

Specify whether the ties connected to the source or sink buses should be considered
to source/sink
as part of the substation system (see definitions of source and sink below).
systems
Specify the extent of the substation to be considered in the study. Substation reliability
Substation system assessment processes each failure mode of each component within the substation
system only.
Specify the source system. The power transfer is from the source system to the sink
system. A substation can have up to 60 source buses. Each source bus is assumed to
be connected to an infinite system with unlimited active power generation. All source
buses must reside within the substation system. A source tie (an incoming line) is a
Source system
branch connecting a source bus with the outside network. When the Include system
ties to source/sink systems option is enabled, both ends of the tie are treated as part of
the substation, the source bus is replaced by the bus at the other end of the tie and the
ties are moved one bus out.
6-201
Table 6-27. Substation Reliability Assessment Options
Option Description
Specify the sink system. A sink subsystem includes buses where loads are to be
served. A substation can have up to 60 sink buses. All sink buses must reside within
the substation system. A sink tie (an outgoing line) is a branch connecting a sink bus
with the outside network. When the Include system ties to source/sink systems option
Sink system is enabled, both ends of the tie are treated as part of the substation, the bus at the
other end of the tie is included in the sink system, and the ties are moved one bus out.
The equivalent load at a sink bus is the sum of the active power loads at the bus plus
the MVA ratings (according to selected rating set and percentage multiplier) of all ties
connected to the sink bus.
Input Files
Substation reliability assessment requires a Distribution Factor Data file and an Outage Statistics
Data file.
6.16.2 Modeling the Substation

A power flow case may contain one more substations. Substation reliability assessment solution
can process only one substation at a time; the extent of the substation is defined by a system in a
Subsystem Description Data file. The outside substation in the power flow case is shut down during
solutions; therefore the external system has no impacts on the results. Distribution Factor Data file
setup activity (DFAX) reads the Subsystem Description Data file, together with a Monitored Element
Data file (The file could be empty by having only one END command since none of the contents are
used), as well as a Contingency Description Data file which defines common mode faults, and
reflects their contents in a Distribution Factor Data file in preparation for substation reliability
assessment.
Only in-service buses in the substation system are included in the studies. There are some buses
in a substation which are off-line under normal condition and turned on for the emergency. In order
to properly simulate switching operations following a fault on those buses, they must be assigned
to in-service status. A substation may include several islands, which are isolated by normally-
opened breakers; each island must have at lease one swing bus (bus type code 3). Since substa-
tion reliability assessment does not perform conventional power flow solutions, the choice of the
swing bus has no impact on the results. Besides buses, Components considered in a solution are
breakers, switches, branches and three-winding transformers. For a three-winding to be included,
all its in-service windings must be connected to substation buses.
For instance, a substation has a main and transfer bus configuration. There is a normally-opened
tie breaker between the main and transfer bus, and all branches are connected to the main bus
under normal condition; the transfer bus will be isolated under normal condition. when there is a
fault at the main bus, all branches will be redirected to the transfer bus and the load supply can be
restored. In order to simulate the switching operations in substation reliability assessment solution,
the transfer bus must be set in-service and if it is the only bus in an island, it must be set to the swing
bus.
The breakers and switches within the substation system are modeled as special non-transformer
branches with unique first characters in the circuit IDs: @ to designate a breaker and  to designate
a switch. Though not compulsory, the modeling of breakers and switches as zero impedance lines
(each with resistance of zero and reactance less than the zero impedance line threshold) is highly
recommended.
6-202
Breakers and switches can operate in either normally-open or normally-closed mode. The two
modes are represented by the ON and OFF statuses, respectively, of the branch.
Each breaker is assumed to have two switches, one on each side, to isolate the breaker for repair
and maintenance. These implicit switches are added automatically during substation reliability
assessment. Switches for isolating other substation components must be explicitly modeled by the
user.
6.16.3 Failure Modes

Substation reliability assessment analysis performs failure modes and effects analyses of arbitrary
bus-breaker configurations and measures the impact of substation equipment failures upon the
resulting power transfer capability of the substation. It can evaluate four modes of equipment fail-
ures as follows:
• Fault: Requires operation of circuit breakers to clear the fault and isolate the faulted
component.
• Common Mode Fault: A common mode fault refers to simultaneous outages of mul-
tiple components due to a common cause. It requires operation of circuit breakers to
clear the fault and isolate the faulted components. A common mode fault is specified in
the Contingency Description Data file.
• Unscheduled Maintenance Outage: Unplanned or uncontrolled removal or transfer to
the open circuit state of the affected component. Component is removed immediately,
no system fault occurs.
• Scheduled Maintenance Outage: Controlled or planned removal for inspection, over-
haul, test, etc. Time of removal is controllable to accommodate maintenance crews,
seasonal or weather considerations, load levels, or outage of other components.
Representation of fault events (single component faults and common mode faults) includes the
option of substation re-configuration following breaker opening to minimize the impact of the
component outages. Faults are represented with a three-state model, as shown in the state transi-
tion diagram in Section 6-53 Three-State Component Fault Model.  is the failure rate, µSW is
switching rate, and µ is repair rate.
Figure 6-53. Three-State Component Fault Model
6-203
For a fault event, the sequence of switching and assessment is modeled as follows:
1. Identify the fault.
2. Operate breakers to clear the fault.
3. Assess the effect on the substation; this is the post-fault state.
4. Operate switch(es) to isolate the faulted component and, if appropriate, re-close breakers
to minimize the extent of the fault effect. The post-fault state persists until switching is
completed; the time to switching completion is labeled S.
5. Assess the effect on the substation. This is the post-switching state, which persists until
component repair or replacement is completed; the time to repair completion is labeled R.
6. Reconfigure the system with the restored component.
The time line in Figure 6-54 illustrates the steps in a fault simulation:
Figure 6-54. Time Line Illustrating the Steps in a Fault Simulation
Any effect of switching operations during system re-configuration in step 6 is not considered in the
reliability assessment. Note further that the outage duration is counted from the time of fault or
outage initiation. The model for component repair is based on the following premises:
1. Component outage duration is far longer than the switching time, S;
2. Repair time, R, starts upon completion of switching.
For a single-component or common mode fault, the substation capability is evaluated at two stages:
• Post-fault stage consists of steps 1 to 4 in Figure 6-54, corresponding to the period fol-
lowing the fault until re-configuration can be effected by switching, and
• Post-switching stage which consists of steps 5 and 6 corresponding to the period fol-
lowing switching operation until repair is completed.
Each stage is culminated by a check on network connectivity. Equipment that is electrically
connected is identified by processing circuit breaker status and disconnect switch positions. Thus,
equipment that is isolated and the degree of service lost can be determined. Power transfer capa-
bility of the substation is assessed by means of a transportation network flow algorithm (maximum
flow-minimum cut). The frequency (in occurrences per year), duration (in hours), and the probability
(in hours per year) of finding the system in that condition are also computed.
For an unscheduled maintenance or a scheduled outage event, a model with two states, up and
down (repair) states, as shown in Figure 6-55, is used.
6-204
Figure 6-55. Two-State Model for Scheduled and Unscheduled Outage
The sequence of switching and assessment for unscheduled maintenance or scheduled mainte-
nance is modeled as follows:
1. Perform switching to remove the component for maintenance, time to switching completion
is S.
2. Assess the effect on the substation. Post-switching state persists until component mainte-
nance is completed, duration is R.
Outage statistics of substation components are specified in the Outage Statistics Data file in the
form of frequency of occurrence and duration; by default they are zeros. The statistics data for
scheduled and unscheduled maintenance outages is optional and used only in substation reliability
study. The duration of an outage mode is repair time only and does not include switching time. In
order to include failures of the implicit switches in the substation reliability assessment, the user
should specify the outage statistics for the switches using a generic input command (see description
in Section 6.15.2 Outage Statistics Data File Contents). An example of an Outage Statistics Data
file is shown in Figure 6-56. The record to specify the outage statistics data for switches specifies
both explicit and implicit switches.
Figure 6-56. Example of Outage Statistics Data File
Performing the Assessment

The reliability of a substation is assessed by checking the effects of fault and outage of each compo-
nent within the substation. For each possible failure location and failure mode, the Substation
Reliability Assessment (SRA) function in PSS®E simulates the operation of the automatic devices
(breakers) to isolate the faulted component and the manual switches to minimize the equipment
isolated. The process for SRA evaluation of a component failure is illustrated in Figure 6-57. In this
manner, SRA methodically looks at each component failure in the substation system and evaluates
post-fault and post-switching connectivity and loss of service.
6-205
Figure 6-57. Process to Assess a Failure Mode of a Component in SRA
SRA generates a list of outage events; the list contains common mode faults and all in-service
substation components. Events in the list are then evaluated with the proceeding process
sequentially.
Common mode faults must be defined in the Contingency Description Data file. They are also
referred to as user specified outages. For each user specified outage, only the common mode fault
6-206
is considered in SRA. Unscheduled and scheduled maintenance outages are not considered. SRA
honors only these contingencies where a DISCONNECT/OPEN/TRIP keyword is present. In an
event description record, for a breaker or switch, a DISCONNECT/OPEN/TRIP keyword indicates
that the breaker or switch is taken out-of-service; for other components, it indicates a fault on the
component, which should be isolated by breakers.
For each substation component, three failure modes may be considered: fault, unscheduled main-
tenance, as well as scheduled maintenance. The substation components include transformers,
incoming and outgoing lines or feeders, breakers, switches, and bus sections. Switches include
implicit ones (on both sides of each breaker) introduced by SRA and those explicitly modeled by
the user.
Out-of-service components in the power flow model are excluded from the outage event list, except
normally open switching devices (breakers and switches). The normally opened switching devices
cannot be modeled as a primary failure event (or contingency), however, they may be automatically
selected by SRA as a secondary contingency following a single-component fault or a common
mode fault, since these devices can be closed in the post-switching stage to restore service inter-
rupted by a primary fault.
SRA can evaluate up to two levels of contingencies. A contingency in SRA refers to a common
mode fault or a single component failure in one of three failure modes. A contingency event in the
event list is selected as a primary contingency and evaluated. After evaluation of the primary contin-
gency, a two-level contingency is generated by combining the primary contingency with another
component failure or common mode fault. Some two-level contingences may not exist in real world,
for instance a primary contingency is a fault on a single component followed by a scheduled main-
tenance on another component. The state transient diagram for some two-level contingencies and
the calculations of their frequency and probability are discussed in the PSS®E Program Application
Guide, Section 10.1.3, Probabilistic Indices.
A fault is modeled with two stages (post-fault and post-switching). If a primary contingency is a fault
or common mode fault, its secondary contingency can occur during either stage of the primary fault.
SRA also considers breakers failing to operate. Following each fault, all breakers that have been
tripped to clear the fault are cataloged. The possibility of each of these breakers failing to operate
correctly is investigated as a new contingency.
Analyzing Results
SRA provides several reports from the substation reliability assessment:
• Substation Component Report

• Contingency Summary Report
• Bus Load Curtailment Report
• Substation Load Curtailment Report
Substation Component Report

This report lists by data category the substation components included in the study and the corre-
sponding frequency and duration of each component failure mode. The column headed
ATTRIBUTE in breaker and switch table indicates the status of a breaker or a switch: NORM-
CLOSE for normally close and NORM-OPEN for normally open. An  leading the attribute string
indicates that the component is an implicit switch. A sample of substation component report is
shown in Figure 6-59.
6-207
Figure 6-58. Sample Substation Component Report
6-208
Reactive power is neglected in the substation reliability assessment. The active power load curtail-
ment due to a failure event is equal to the total desired load minus the amount of power that can be
transferred from the source system to the sink system. The total load is the sum of the equivalent
loads at the sink buses. The equivalent load at a sink bus is the sum of the MW loads at the bus
plus the MVA ratings (according to the selected rating set and percentage) of all branches
connected between the sink bus and the system outside the substation. Calculation of the
maximum transfer capability is based on a transportation network flow algorithm which takes into
account only branch capacities (branch MVA ratings) and ignores branch impedances and bus
voltages.
The computed interrupted power (I.P.) and expected unserved energy (E.U.E.) are included in the
Bus Load Curtailment Report and the Substation Load Curtailment Report shown below. Expected
unserved energy indices are normalized for the entire year.
Contingency Summary Report

A sample report shown in Figure 6-60 contains the contingency events and the computed reliability
results at the post-fault and the post-switching stages. The columns headed by PRIMARY and MD
show the primary contingency labels and the corresponding failure modes. Each failure mode is
identified by one letter: U for unscheduled outage, F for single-component fault, S for scheduled
maintenance and C for common mode fault. Similarly, the columns headed by SECONDARY and
MD contain the secondary contingency labels and the corresponding failure modes.
There are two stages for a single-component fault or a common mode fault: post-fault and post-
switching. The secondary fault may occur in either stage of the primary fault. A failure mode of “F”
indicates that the secondary fault occurs during the post-fault stage of the primary fault, while a
failure mode PF indicates that the secondary fault occurs during the post-switching stage of the
primary fault. Similarly, failure modes C and PC indicates, respectively, whether the secondary fault
occurs during the post-fault or post-switching states of a common mode primary fault.
If a failure event involves a stuck breaker, the label of the breaker that fails to open is shown in the
STUCK BREAKER column.
This summary report only displays those contingency events that result in load curtailment during
either the post-fault or fault-switching stage. The amount of load curtailed in MW, the frequency in
occurrences/year and the probability in hours/year are shown for each stage.
6-209
6-210
Figure 6-59. Sample Contingency Summary Report
6-211
As discussed above, SRA adds two implicit switches for each breaker. The faults and outages can
occur on both implicit and explicit switches. An  in the contingency event label for a switch, such
as SWITCH5 in the sample report, indicates that the switch is an implicit one.
The bottom of the summary report provides descriptions of the contingencies, as shown in Figure
6-61. For scheduled maintenance and unscheduled maintenance failures, an OPEN keyword in the
event description record indicates that the component is taken out of service. For single-component
faults, it indicates that a fault is applied on the component which requires operations of breakers
and switches to isolate the fault component(s). For an implicit switch fault, the contingency descrip-
tion identifies the breaker branch for which the switch is added, with the from bus corresponding to
the side with the faulted switch.
6-212
6-213
Figure 6-60. Sample Descriptions of the Contingencies in the Summary Report
6-214
Program Operation Manual Performing PV/QV Analyses
Bus Load Curtailment Report

This report lists, for each bus in the sink subsystem, the total load in MW, the total frequency and
probability of contingency events that result in load curtailment at the bus, the interrupted power
(I.P.) in MW per year and the expected unserved energy (E.U.E.) in MWHR per year in the post-
fault and post-switching stages. A sample report is shown in Figure 6-62.
Substation Load Curtailment Report

This report is divided into post-fault and post-switching stages. Within each stage, the failure events
that resulted in similar amounts of load curtailments are grouped together. For each group, the
report lists the corresponding failure event labels, the load curtailment in MW, the frequency in
occurrences per year and the probability in hours per year. Also shown for each group are the
frequency, the probability, the interrupted power (I.P.) and the expected unserved energy (E.U.E.).
Part of a substation load curtailment report is shown in Figure 6-61.
Figure 6-61. Sample of Substation Load Curtailment Report
Section 11.10, Running Substation Reliability Assessment
6.17 Performing PV/QV Analyses

The PV/QV analyses that are described in this chapter are designed for studies of low voltage sta-
bility, which could be analyzed as a steady-state problem. They are power flow based analyses
used to assess voltage variations with active and reactive power change. Two methods are used to
determine the loading limits imposed by voltage stability under the steady-state conditions.
The PV/QV analyses do not provide solutions to specific problem but function as tools that can be
directed by the user to perform analyses in the solution of problems associated with the steady-
state voltage stability of power systems.
6.18 PV Analysis
Run Activity PV Analysis - GUI

Power Flow > Solution > PV analysis…
[PV Analysis]
6-215
PV Analysis Program Operation Manual

AB,CM,NM,DC,FD,MO
Table 6-28. PV Analysis Options
Option Description
Select solution options for the series of power flow calculations performed to
obtain the PV curves for the base case transfer solutions (see Section 6.2
Power Flow Solution Methods).
Tap adjustment:
• Lock taps
• Stepping
• Direct
• Disabled
• Tie lines only
Base-case
Solution options • Tie lines and loads
Switched shunt adjustment:
• Lock all
• Enable all
Enable or disable phase shift adjustment.
Enable or disable dc tap adjustment.
Induction motor treatment flag when it fails to solve due to low terminal voltage:
• set to the "stalled" state
• set to the "tripped" state
6-216
Program Operation Manual PV Analysis
Table 6-28. PV Analysis Options (Cont.)
Option Description
The contingency-case solution options allow for a different set of automatic
adjustments of the contingency case solutions than those used in the base case
transfer increment solutions (see Section 6.2 Power Flow Solution
Methods).
Tap adjustment:
• Lock taps
• Stepping
• Direct
• Disabled
Contingency-case Solu- • Tie lines only
tion options • Tie lines and loads
Switched shunt adjustment:
• Lock all
• Enable all
Induction motor treatment flag when it fails to solve due to low terminal voltage:
If this option is enabled, the PV_ENGINE_6 API routine is used to calculate the
analysis; PV_ENGINE_6 must be used if the base case and contingency case
solution options are not identical, if a negative minimum transfer increment is
Apply contingencies to specified, if a specified power factor is to be used when increasing load using
base case transfer solu- transfer methods 2, 3 and 4 (rather than retaining the original load power
tions (GUI option to select factors), or if a re-dispatch is to be performed to satisfy island power unbalances
the API routine to use) resulting from the application of contingencies.
If these options are disabled, the PV_ENGINE_1A API routine is used to calcu-
late the analysis.
Select the solution engines for the series of power flow calculations and
contingency studies to obtain the PV curves (see Section 6.2 Power
Flow Solution Methods).
Solution Engine • Fixed slope decoupled Newton-Raphson (FDNS)
Non-divergent solution Flag to enable or disable option in each power flow solution.
6-217
Option Description
Select the var limit codes for the following cases:
• Base case transfer increment solutions
• Contingency case power flow solutions
Var Limit Codes The var limit codes indicate when, during the power flow solutions, plant reactive
power limits are to be honored. They can be set as follows:
• Apply immediately on the first iteration
• Initially ignore, then apply when bus mismatches have been reduced to a
pre-set multiple of the convergence tolerance
Dispatch codes for study and opposing dispatch calculations in PV analysis.
DFAX generation: Participating buses and their participation factors are taken
from the DFAX file. Only subsystem buses with one or more in-service machines
with positive active power generation are participating buses.
If a PARTICIPATE block is specified for the subsystem in the Subsystem
Description Data file, the participation factors specified in the file are used;
Transfer Dispatch participating buses for which no participation factor was specified are excluded.
Methods If no PARTICIPATE block is specified, it uses the MBASEs of the participating
machines.
DFAX load: Participating buses and their participation factors are taken from the
DFAX file. Only subsystem buses with one or more in-service loads with positive
constant MVA load active power are participating buses. Participation factors
specified in the subsystem’s PARTICIPATE block are used; participating buses
for which no participation factor was specified are excluded.
6-218
Option Description
DFAX generation or load: Participating buses and their participation factors are
taken from the DFAX file. Only subsystem buses with either one or more in-
service machines where active power generation is positive, or one or more in-
service loads where constant MVA load active power is positive, are participating
buses. Participating buses and participation factors are handled as described in
DFAX generation and DFAX load.
If both generation and load meeting the above criteria are present at a bus, the
generation is dispatched if the bus is in the study subsystem, and the load is
dispatched, if the bus is in the opposing subsystem.
Subsystem load: Participating buses are subsystem buses with one or more in-
service loads where constant MVA load active power is positive; each bus'
participation factor is the total of its positive active power constant MVA load.
Subsystem machines (MW): Participating buses are subsystem buses with one
or more in-service machines where active power generation is positive; each
Transfer Dispatch bus' participation factor is the total of the active power generation of its machines
Methods (continued) with positive active power generation.
Subsystem machines (MBASE): Participating buses are subsystem buses with
one or more in-service machines where active power generation is positive;
each bus' participation factor is the total of the MBASEs of its machines with
positive active power generation.
Subsystem machines (Reserve): Participating buses are subsystem buses with
one or more in-service machines where active power generation is positive;
each bus' participation factor is the total of the reserve (PT-PG) of its machines
with positive values of both active power generation and reserve.
Subsystem machines (ECDI w/o Unit Commitment): Participating buses are
subsystem buses with one or more in-service machines specified in the
Economic Dispatch Data file; machines participate in the transfer based on an
equal incremental cost dispatch as implemented by activity ECDI. No machine
status changes are implemented.
Subsystem machines (ECDI w/ Unit Commitment): Participating buses are
subsystem buses with one or more in-service machines specified in the
Economic Dispatch Data file; machines participate in the transfer based on an
equal incremental cost dispatch as implemented by activity ECDI. If necessary,
machines are placed into service or removed from service.
Power factor used in dispatch methods 2, 3 and 4 for load increases. Specify a
Power factor for load
power factor < 0.0 to retain the original power factor at each load that is changed
increases
(default).
Generation limits flag for Select one of the following, if appropriate:

transfer dispatch methods • No limits (default)
using generation • Honor machine active power limits
Positive load flag for Select one of the following, if appropriate:

transfer dispatch methods • No limits (default)
using loads • Enforce non-negative active power constant MVA loads
6-219
Option Description
If exceeded, the process is terminated. This value is also used as the conver-
Mismatch tolerance
gence tolerance in the power flow solution of each contingency and transfer
increment case (see Section 6.2 Power Flow Solution Methods).
Initial transfer increment Starting transfer increment value. This value will be the initial transfer increment
(MW) step size in MW between the two defined subsystems.
Min monitored bus voltage
Minimum voltage value for termination of calculation. If the low voltage check is
in pu for terminating anal-
enabled, calculations for the current system condition will stop if any monitored
ysis for this system
voltage is less than this value.
condition
Largest acceptable difference in transfer level between a transfer level for which
Transfer increment toler-
a solution is found and a higher transfer level which fails to achieve
ance (MW)
convergence.
Maximum incremental
Maximum transfer in MW between the two specified subsystems.
transfer (MW)
Minimum incremental
Minimum transfer in MW between the two specified subsystems.
transfer (MW)
Branch overload threshold
Threshold in determining branch overloads.
(%)
Line loading limit used in determining overloads. If the branch loading check is
Rating set enabled, calculations will stop if any monitored branches are overloaded beyond
this limit.
Flag to enable a low voltage limit check for monitored voltages. If enabled, the
calculations for the current system condition will stop if any low voltage violations
are detected. This flag may be set as follows:
0 to disable the low voltage check.
1 to enable the low voltage check using the value specified as the minimum
monitored bus voltage.
Low voltage limit check
2 to enable the low voltage check using the normal lower limit for base and
contingency case solutions.
3 to enable the low voltage check using the normal lower limit for base case
solutions, and the emergency lower limit for contingency case solutions.
4 to enable the low voltage check using the emergency lower limit for base and
contingency case solutions.
If enabled, the calculations for the current system condition will stop if any moni-
Enable the branch loading
tored branches are overloaded beyond the limit specified by overload threshold
check
and rating set.
Subsystem selection Subsystem names of the "source" and "sink" subsystems.
Enables the option to re-dispatch to satisfy island power unbalances resulting
Dispatch mode from the application of contingencies. See Table 6-9 AC Contingency Solu-
tion Options.
6-220
Option Description
Name of the the subsystem for the generation dispatch. All subsystem buses
with one or more in-service machines where active power generation is positive
Dispatch subsystem are participating in the generation dispatch. If several islands exist in the system,
participating machines for each island are connected to dispatch subsystem
buses in the island.
Name of a Distribution Factor Data File (*.dfx) previously built by activity DFAX
that corresponds to the network condition contained in the working case (refer to
Section 8.1.7 Application Notes) and to the desired linear network analysis
data files (refer to Section 8.1.1 Linear Network Analysis Data Files). The
Distribution Factor Data
bus input option (refer to Section 3.3.3 Program Run-Time Option Settings
File
and activity OPTN) must have the same setting that was in effect when activity
DFAX filled the specified Distribution Factor Data file. Refer to Section 2.4.1
File Usage for the file specification conventions used by the AC Contingency
Solution function.
Name of an optional Load Throwover Data File ( *.thr) that contains data records
of the following form:
IBUS, JBUS
Load Throwover Data File where IBUS and JBUS are bus numbers. If branch outage contingency events
IBUS value of zero.
Name of an Economic Dispatch Data File ( *.ecd) that contains machine
Economic Dispatch File dispatch data records for use if one of the ECDI-based transfer methods is spec-
ified as the transfer dispatch method for the "source" and/or "sink" subsystems.
Name of the Inertia and Governor Response Data File (*.inl). This file is required
if the generation dispatch is enabled and either the inertial or governor droop
Unit Inertia and Governor dispatch method is selected. If the PMAX or reserve method is selected, the
Data File specification of this file is optional. If a file is specified, machine active power
limits are taken from it; otherwise, the machine active power limits in the working
case are used.
Name of the P-V Results File (*.pv) into which the results of the P-V calculation
will be stored. The results file is preserved so that you may view the P-V calcula-
tion results at a later time by simply selecting the P-V Results File rather than re-
running the P-V calculations.
Flag to enable or disable the writing of a ZIP Archive Output File. If enabled,
ZIP Archive option each system condition may be preserved either at its largest solved incremental
transfer level, or at all of its solved incremental transfer levels.
(*.zip) an optional file designated by the user as the destination for data used to
ZIP Archive Output File
place contingency case solutions into the working case.
Two P_V analysis API routines are available. In the PV_ENGINE_1A API routine, the same set of
automatic adjustments is applied in base case and contingency case power flow solutions. The
basic solution flow is:
• Apply the contingency to the base case solution at the initial transfer level (i.e., at 0.0
incremental transfer) and solve the power flow.
6-221
• In the solved contingency case at the initial transfer level, increment the transfer to
transfer level 1 and solve.
• From the solved contingency case at transfer level 1, increment the transfer to transfer
level 2 and solve.
• ...
The PV_ENGINE_6 API routine allows a different set of automatic adjustments to be applied in
contingency case power flow solutions. The basic solution flow for contingency cases is:
• Apply the contingency to the base case solution at the initial transfer level (i.e., at 0.0
incremental transfer) and solve the power flow.
• Apply the contingency to the base case solution at transfer level 1 and solve it.
• Apply the contingency to the base case solution at transfer level 2 and solve it.
• ...
PV_ENGINE_6 must be used in any of the following conditions:
• A different set of automatic adjustments is specified for the base case and contingency
case solutions.
• A negative minimum incremental transfer is specified.
• A power unbalance dispatch mode is specified.
• A power factor is specified for use in incrementing the transfer by load increases.
• The ZIP Archive option is specified as either 1 or 2.
Either PV_ENGINE_6 or PV_ENGINE_1A may be used if all of the following conditions are
satisfied:
• The same set of automatic adjustments is specified for the base case and contingency
case solutions.
• 0.0 is specified for the minimum incremental transfer.
• 0 is specified for the dispatch mode.
• 0.0 is specified for the power factor for load increases.
• 0 is specified for the ZIP Archive option.
The results window for PV analysis will be displayed after calculations are initiated.
Select the type of graph you wish to plot and select the items of interest from the following:
Bus voltages: Plots bus voltages against incremental power transfer of selected base
case or contingencies.
Generator MW: Plots generator MW output against incremental power transfer of selected
base case or contingencies.
Branch MVA Flow: Plots branch MVA against incremental power transfer of selected base
case or contingencies.
Interface MW Flow: Plots interface MW against incremental power transfer of selected
base case or contingencies.
6-222
Bus voltage against interface flow: Plots the selected bus voltage against interface flow.
Items in the list may be selected individually or as a continuous set. The results are plotted as a
graph. Graph axis parameters are fully adjustable. Scale values are adjustable for both vertical and
horizontal axes. Additional options are available for printing clarity.
6.18.1 Retrieving Results from a Previous PV Analysis
Run Activity PV Analysis, Previous Results Retrieved - GUI

Power Flow > Solution > PV analysis using previous results…
[PV Parameters]
Select a previously saved PV results file (*.pv). Parameters used for the selected PV analysis will
be shown. These values are for reference only and are not editable.
6.18.2 Implementing a Specific PV Transfer
Run Activity PV Transfer - GUI

Power Flow > Solution > Implement PV transfer…
[Implement PV Transfer]
It is often important to study the performance of the power system at or near the transfer limit that
had been determined by a PV analysis study. The implement PV transfer function may be used to
implement a transfer between designated source and sink systems using the same transfer dis-
patch methods that are available in the PV analysis function.
To impose a designated transfer:
1. Open the Saved Case file containing the power flow case on which the transfer is to be
imposed. Normally, the same Saved Case file on which an earlier PV analysis calculation
had been performed is specified.
2. Open the [Implement PV Transfer] dialog, which will contain default settings.
3. Specify the same Distribution Factor Data file, source and sink systems, and transfer
dispatch method data as was specified in the earlier PV analysis calculation.
4. Specify the desired transfer increment.
5. Launch the transfer.
The implement PV transfer function then changes the generation or load, as appropriate, at those
subsystem buses participating in the transfer.
Details on the transfer may be examined using activity DIFF.
6-223
QV Analysis Program Operation Manual
Section 11.7, PV Analysis
6.19 QV Analysis
Run Activity QV Analysis - GUI

Power Flow > Solution > QV analysis…
[QV Analysis]
AB,CM,NM,DC,FD,MO
Table 6-29. QV Analysis Options
Option Description
Bus number for analysis. Filters may be applied to the bus selector for name
Bus number
mask, number range, base voltage, and bus type.
Select solution options for the series of power flow calculations performed to
obtain the QV curves (see Section 6.2 Power Flow Solution Methods).
Tap adjustment:
• Lock taps
• Stepping
• Direct
• Disabled
• Tie lines only
Solution options • Tie lines and loads
• Lock all
• Enable all
Induction motor treatment flag when it fails to solve due to low terminal
voltage:
Non-divergent solution Flag to enable or disable option in each power flow solution.
6-224
Program Operation Manual QV Analysis
Table 6-29. QV Analysis Options (Cont.)
Option Description
Select the solution engines for the series of power flow calculations and
contingency studies to obtain the PV curves (see Section 6.2 Power
Flow Solution Methods).
Solution Engine • Fixed slope decoupled Newton-Raphson (FDNS)
Select the var limit code for the following cases:
• VHI power flow solution
• Subsequent voltage decrement cases
Var Limit Codes The var limit codes can be set for as follows:
• Apply immediately on the first iteration
• Initially ignore, then apply when bus mismatches have been reduced to a
pre-set multiple of the convergence tolerance
Enables the option to re-dispatch to satisfy island power unbalances resulting
Dispatch mode from the application of contingencies. See Table 6-9 AC Contingency Solu-
tion Options.
Mismatch tolerance (MW If exceeded, the process is terminated. This value is also used as the conver-
and Mvar) gence tolerance in the power flow solution of each contingency case (see
Section 6.2 Power Flow Solution Methods).
Initial (maximum) per unit
voltage setpoint at study Maximum voltage of study bus
bus (VHI)
Minimum per unit voltage
setpoint at study bus Minimum voltage of study bus
(VLO)
Per unit voltage setpoint
decrement (positive) at Voltage increment size from VLO to VHI.
study bus (DLTAV)
Name of the subsystem for the generation dispatch. All subsystem buses with
one or more in-service machines where active power generation is positive are
Dispatch subsystem participating in the generation dispatch. If several islands exist in the system,
participating machines for each island are connected to dispatch subsystem
buses in the island.
Name of a Distribution Factor Data File (*.dfx) previously built by activity DFAX
that corresponds to the network condition contained in the working case (refer to
Section 8.1.7 Application Notes) and to the desired linear network analysis
data files (refer to Section 8.1.1 Linear Network Analysis Data Files). The
bus input option (refer to Section 3.3.3 Program Run-Time Option Settings
File
and activity OPTN) must have the same setting that was in effect when activity
DFAX filled the specified Distribution Factor Data file. Refer to Section 2.4.1
File Usage for the file specification conventions used by the AC Contingency
Solution function.
6-225
QV Analysis Program Operation Manual
Table 6-29. QV Analysis Options (Cont.)
Option Description
Name of an optional Load Throwover Data File ( *.thr) that contains data records
of the following form:
IBUS, JBUS
Load Throwover Data File where IBUS and JBUS are bus numbers. If branch outage contingency events
IBUS value of zero.
Name of the Inertia and Governor Response Data File (*.inl). This file is required
if the generation dispatch is enabled and either the inertial or governor droop
Unit Inertia and Governor dispatch method is selected. If the PMAX or reserve method is selected, the
Data File specification of this file is optional. If a file is specified, machine active power
limits are taken from it; otherwise, the machine active power limits in the working
case are used.
Name of the Q-V Results File (*.qv) into which the results of the Q-V calculation
will be stored. The results file is preserved so that you may view the Q-V calcula-
tion results at a later time by simply selecting the Q-V Results File rather than re-
running the Q-V calculations.
Flag to enable or disable the writing of a ZIP Archive Output File. If
ZIP Archive option enabled, each system condition may be preserved either at its lowest
solved study bus voltage level, or at all solved study bus voltage levels.
(*.zip) an optional file designated by the user as the destination for data
ZIP Archive Output File
used to place contingency case solutions into the working case.
The results window for QV analysis will be displayed after calculations are initiated. Select the base
case and/or contingencies. Items in the list may be selected individually or as a continuous set.
The results are plotted as a graph. Graph axis parameters are fully adjustable. Scale values are
adjustable for both vertical and horizontal axes. Additional options are available for printing clarity.
6.19.1 Retrieving Results from a Previous QV Analysis
Run Activity QV Analysis, Previous Results Retrieved - GUI

Power Flow > Solution > QV analysis using previous results…
[QV Parameters]
Select a previously saved QV results file (*.qv). Parameters used for the selected QV analysis will
be shown. These values are for reference only and are not editable.
Section 11.8, QV Analysis
6-226
Program Operation Manual Basic Engineering Guide to PV and QV Curves Applications
6.20 Basic Engineering Guide to PV and QV Curves Applications
6.20.1 Objective
The objective of a PV and QV curves is to determine the ability of a power system to maintain
voltage stability at all the buses in the system under normal and abnormal steady-state operating
conditions. They are useful, for example:
• To show the voltage collapse point of the buses in the power system network.
• To study the maximum transfer of power between buses before voltage collapse point.
• To size the reactive power compensation devices required at relevant buses to prevent
voltage collapse.
• To study the influence of generator, loads and reactive power compensation devices
on the network.
The PV and QV curves are obtained through a series of ac power flow solutions. The PV curve is
a representation of voltage change as a result of increased power transfer between two systems,
and the QV curve is a representation of reactive power demand by a bus or buses as voltage level
changes.
6.20.2 PV Analysis (PV Curves) Applications

PV curves are parametric study involving a series of ac power flows that monitor the changes in one
set of power flow variables with respect to another in a systematic fashion. This approach is a pow-
erful method for determining transfer limits that account for voltage and reactive flow effects. As
power transfer is increased, voltage decreases at some buses on or near the transfer path. The
transfer capacity where voltage reaches the low voltage criterion is the low voltage transfer limit.
Transfer can continue to increase until the solution identifies a condition of voltage collapse; this is
the voltage collapse transfer limit.
This can be demonstrated using a simple two terminals network as in Figure 6-62. From reference
P. Kundur, Power System Stability and Control, McGraw-Hill 1994, the power flow relationship
between the source and the load can be summarized by Equation 6.19 and Equation 6.20.
Figure 6-62. Two Terminals Simple Network
ZLD Es 2
PR = VR I COS =
F ZLN COS
(6.19)
6-227
Basic Engineering Guide to PV and QV Curves Applications Program Operation Manual
1 ZLD
VR = Es
 F’ ZLN (6.20)
where:
2
ZLD ZLD
ZLN cos( - )
F = 1+ +2
ZLN
The loading of the network can be increased by decreasing the value if ZLD. This is done with Es,
load power factor and line parameters fixed. From Equation 6.19, as ZLD is decreased gradually
the load power, PR, increases, hence the power transmitted will increase. As the value of ZLD
approaches ZLN the value of PR starts to decrease gradually due to F. However, from Equation 6.20
as ZLD decreases the receiving voltage VR decreases gradually.
The plot of the relationship between voltage at the receiving end, VR, and the load power, PR, as
the power transfer is increased due to increase loading, gives the PV curves similar in characteristic
to the curve shown in Figure 6-63.
PV curves are typically used for the knee curve analysis. It is as named because of its distinctive
shape at the point of voltage collapse as the power transfer increases, as shown in Figure 6-63.
Depending on the transfer path, different buses have different knee point. The buses closer to the
transfer path will normally exhibit a more discernible knee point.
Figure 6-63. PV Curves Voltage and Incremental Power Transfer

Characteristics
Voltage instability occurs at the knee point of the PV curve where the voltage drops rapidly with an
increase in the transfer power flow. The power flow solution will not converge beyond this limit, indi-
cating voltage instability. Operation at or near the stability limit is impractical and a satisfactory
operating condition must be ensured to prevent voltage collapse.
In PSS®E, the PV curves are generated by selecting two subsystems where the power transfer
between the subsystems is incremented in a defined step size for a series of ac power flow calcu-
lations while the bus voltages, generator outputs and the branch flows of the system are monitored.
When the bus voltages are plotted as a function of the incremental power transfer the PV curves
are obtained. One of the subsystems in the study must be defined as the study (source) system and
6-228
another as the opposing (sink) system. The power flows from the study subsystem to the opposing
subsystem.
Figure 6-64 shows the PV curves of a bus 203 in an example network under normal and various
contingency conditions. The maximum transfer limit for this bus in base case is approximately 750
MW. The maximum transfer limit decreases under contingency conditions. The response shown is
expected because under network contingencies the loading of the line will increase. These curves
can be used to set transfers or local generation dispatch so that the system will not fall below the
knee point following a disturbance (i.e., loss of lines).
The PV curves for different buses under the same network conditions (base case or contingency)
can also be plotted in the results window as shown in Figure 6-65. The plots of three different buses
in base case indicate that the knee point is below the 90% of the nominal voltage and the transfer
limit is approximately 750 MW. However, this transfer limit is not reasonable as voltages below 90%
will cause motors in the system to stall. The transfer limit should be set for voltages in the vicinity of
95% of the nominal voltage.
The distribution of generations between the generators in the system as a result of the power
transfer can be observed by analyzing their relationship as shown in Figure 6-66.
6-229

Characteristics for Bus 203 under Different Network Conditions
6-230

Characteristics for Different Buses in Base Case
6-231
Figure 6-66. Generator Output Versus Power Transfer Curves
6.20.3 QV Analysis (QV Curves) Applications

In the PV curve analysis we have demonstrated the effect of active power flow on voltage instability.
However, if we revisit Equation 6.19 and Equation 6.20, we see that the power factor of the load
has a significant impact on the overall equations. This is to be expected because the voltage drop
in the line is a function of both active and reactive power transfer. Hence, the QV curves may also
be used to assess voltage stability of the system.
QV curves are used to determine the reactive power injection required at a bus in order to vary the
bus voltage to the required value. The curve is obtained through a series of ac power flow calcula-
tions. Starting with the specified maximum per unit voltage setpoint at the study bus, the reactive
power injections can be computed for a series of power flows as the voltage setpoint is decreased
in steps, until the power flow demonstrates convergence difficulties as the system approaches the
voltage collapse point.
6-232
Figure 6-67 is a typical of the QV curves that will be generated for a system that is stable at mod-
erate loading and unstable at higher loadings.
Figure 6-67. QV Curves for a Range of System Loading
The bottom of the QV curve, where the change of reactive power, Q, with respect to voltage, V (or
derivative dQ/dV) is equal to zero, represents the voltage stability limit. Because all reactive power
compensator devices are designed to operate satisfactorily when an increase in Q is accompanied
by an increase in V, the operation on the right side of the QV curve is stable, whereas the operation
on the left side is unstable. Also, voltage on the left side may be so low that the protective devices
may be activated.
The bottom of the QV curves, in addition to identifying the stability limit, defines the minimum reac-
tive power requirement for the stable operation. Hence, the QV curve can be used to examine the
type and size of compensation needed to provide voltage stability. This can be performed by super-
imposing the QV characteristic curves of the compensator devices on that of the system. For
instance the capacitor characteristic can be drawn over the system's QV curves as shown in Figure
6-68.
6-233
Figure 6-68. QV Curves and Characteristics of a Capacitor Bank Required at

Stable Operating Point
Figure 6-69 shows the QV curves for a range of capacitor banks with different rating super-imposed
on the system's QV curves under different loading conditions. From the plot we can determine that
capacitor rating of 300 Mvar is required to maintain 1 pu voltage at loading of 1300 MW, 450 Mvar
at 1500 MW and so on.
For the case of very high loading at 1900 MW, even though the capacitor bank rating of 950 Mvar
can maintain a voltage of 1 pu, point B is not a stable operating point. If there is a drop in voltage
from point B to B', the ability of the capacitor to supply reactive power is decreased more than the
drop in requirement of the system. This will result in continuous drop in voltage. Alternatively, if the
voltage is increased above point B, the capacitor will supply more reactive power than the increase
in requirement of the system. This will result in continuous rise in voltage.
Hence, the criterion for stable operating point when using a reactive power compensator is as
follow:
System dQ/dV > Compensator dQcomp/dV

where:
dQ/dV is the change of the system's reactive power, Q, with respect to voltage, V.
dQcomp/dV is the change of the compensator's reactive power output, Qcomp, with
respect to voltage, V.
For the case of light loading at 1300 MW with capacitor rating of 300 Mvar, point A is a stable oper-
ating point. If the voltage is increased from point A to A', the capacitor will supply less reactive power
than the increase in system's demand, hence reducing the voltage to 1 pu. Alternatively, if the
voltage is decreased from point A towards the bottom of the QV curve, the capacitor will supply
more reactive power than the system's demand, hence returning the voltage to 1 pu.
6-234
Figure 6-69. Compensator Operations and Size on Voltage Stability using QV

Curves
In PSS®E, the QV curves are generated by artificially introducing a synchronous condenser, with
high reactive power limits, at a bus to make this a PV bus. As the scheduled voltage set point (bus
voltage) of the PV bus is varied in steps for a series of ac power flow calculations, the reactive power
output from the condenser is monitored. When the reactive power is plotted as a function of the bus
voltage a QV curves are obtained.
QV curves are commonly used to identify voltage stability issues and reactive power margin for spe-
cific locations in the power system under various loading and contingency conditions. The QV
curves are also used as a method to size shunt reactive compensation at any particular bus to main-
tain the required scheduled voltage.
Figure 6-70 shows QV curves for bus 203 in an example network. From the curves we can deter-
mine the reactive power required to hold the desired scheduled voltage in the base case and under
various contingencies. In this example, the reactive power required is approximately 110 Mvar to
hold the scheduled voltage at bus 203 at 1.0 pu in the base case.
6-235
Figure 6-71 show the QV curves of bus 103 in base case under higher loading conditions. It is observed that the demand for reactive power to
Figure 6-70. QV Curves under Various Contingencies for Bus 103
hold the scheduled voltage at 1.0 pu increases with loading.

6-236
There are no functions in PSS®E QV Analysis that allow super-imposing of compensator QV char-
acteristics over that of the system. However, this can be performed using IPLAN or Python
programming tools.
6-237
Figure 6-71. QV Curve in Base Case with Increase in Load on Bus 103
6-238
The shape of the QV curves can also be used to determine the load characteristic, and study the
effect of load tap changer (LTC) transformer on the system. Figure 6-72 shows the QV curve on bus
108 of the example system. The load on the bus 108 is of constant current type controlled by a LTC
transformer. It is observed that the QV curves are slightly shaped like an 'S'. The S-shape charac-
teristics are due to the load type in the system and the action of the LTC transformer as illustrated
in Figure 6-73.
6-239
Figure 6-72. S-Shaped QV Curve on Bus 108
6-240
Program Operation Manual Sensitivity Analysis
Figure 6-73. QV Curves for Different Load Type with Consideration of LTC
6.21 Sensitivity Analysis

The sensitivity analysis is a method to systematically study the impacts of changes in system
operation conditions such as MW and MVar power injections, and phase angles of phase shifters
on changes in branch flows and bus voltages. The function calculates sensitivity factors to assess
the impacts, and is used in following applications:
• Determine the loading contribution of a branch due to the generation and load
injections
• Provide operation strategies to mitigate the thermal or voltage limits violations
• Determine the dispatch mode to maximize power transfer from one area to another
The sensitivity analysis can use a linearized or "DC" network model as used in the dc analogy
network solution method of activity DCLF (see Section 8.4, Applying the DC Linearized Network
Solution). In DC power flow model, the bus voltage magnitudes remain constant, and reactive
power flows are neglected. Therefore, the sensitivity analysis for bus voltages and branch flows
which include MVar components are not available with DC power flow model. The sensitivity
factors are determined by DC power flow network topology.
The sensitivity analysis can also use an AC power flow network model. In the AC network model
the sensitivity factors are the first-order partial derivatives of the AC power flow equations at some
state which is represented by a set of voltage angles and magnitudes of a converged power flow
solution. For example, sensitivity factors of a branch flow to MW power injection at a generator bus
is defined as:
fij
V f 
 ij
it can be re-written as  V  pgenk   pgenk with the composite function derivative method.
6-241
Sensitivity Analysis Program Operation Manual
f ij
pgenk
Where
f ij is the branch flow on branch form bus i to bus j, pgenk is the MW power injection at
bus k, V is the vector of voltage magnitudes and  is the vector of bus voltage angles. The AC
power flow network model is a full representation of power systems, therefore sensitivity factors of
bus voltage magnitudes and branch flows including MVar components can be calculated. The
sensitivity factors calculated in this manner are determined by both the network topology and the
current system operation condition.
When calculating sensitivity factors to MW change at a bus, an opposing system to which the
sensitivity factors are referenced is required. The opposing system determines how the change is
to be apportioned among buses with given participation factors to maintain the balance between
generation source and demand. The sensitivity factors to MW change at a bus is calculated in the
form of:
SFi  SFi '   SF

j 1, n
j
'
Where SFi is the sensitivity factor at bus i, SFj is the sensitivity factor at bus j, wj is the participation
factor of bus j,SFi is the sensitivity factor at bus i which is referenced to the buses from 1 to n. If an
opposing system is a bus, the form is simplified to SFi =SFi -SFi
6.21.1 Options of Sensitivity Analysis

The following options are available in the sensitivity analysis function menu (Table 6-30 Sensitivity
Analysis Options).
Table 6-30. Sensitivity Analysis Options
Define the power flow network model which sensitivity

analysis is based on, select one of the following:
Network model
• DC network model
• AC network model
With AC network model, the largest MW and MVar

Initial condition MW mismatch tolerance mismatches must be less than the mismatch tolerance
to continue sensitivity analysis.
Sensitivity factor cutoff Report sensitivity factors greater than the cutoff value
Select a single branch via branch type and branch
identification selections or branches in a subsystem
for sensitivity analysis.
Factors for branch flows Branch type specifies which type of branches the
selector is to look for. Branch identification consisting
of from bus, to bus and branch circuit ID is specified
by the selector.
6-242
Specify the type of a branch flow for which the sensi-

Flow type
tivity factors are calculated. Select one of the following
(when DC network is used, only the branch MW flow is
valid for sensitivity analysis):
• MW flow
• MVar flow
• MVA flow
• Amps flow
Factors for bus voltages Select a single bus or buses in a subsystem for sensi-
tivity analysis if AC network model is enabled.
Factors for interface flow Select the interface on which sensitivity factors of MW
flow are calculated.
Select a subsystem containing devices to which the
sensitivity factors are calculated from a list of pre-
defined subsystems.
Flag to enable or disable calculation of sensitivity
factors to MW injections at buses for branch flows,
and MW and MVar injections for bus voltages.
Flag to Enable or disable calculation of sensitivity
factors to MW injections at generator buses.
Select devices to which sensitivity factors are
factors to MW injections at load buses for branch
calculated
flows, and to MW and MVar injections at load buses
for bus voltages.
factors to phase shifters.
factors to tap changing transformers in AC network
model only.
factors to switched shunts in AC network model only.
Define the direction of the transfer and opposing
subsystem.
They are required if one of bus, generator and load
device flags is selected. The transfer could be either
from the device to which sensitivity factors are calcu-
lated to the opposing subsystem or the other way
Transfer options around, select one of the following:
• From device. The transfer is from a device (bus,
generator bus or load bus) to the opposing
system.
• To device. The transfer is from the opposing
system to a device.
6-243
Select to which the sensitivity factors are referenced

from one of the following:
Opposing system for MW dispatch • Slack bus
• Single bus
• System
Select a subsystem and a dispatch mode from seven
modes if the opposing subsystem type is a subsystem:
• Buses & participating factors from DFAX file for
buses with positive MW machines
buses with positive MW constant MVA load
buses with either positive MW machines or
positive MW constant MVA load
Subsystem and dispatch mode for opposing system
• Subsystem buses with positive MW constant
MVA load in proportion to their MW load
• Subsystem buses with positive MW machines in
proportion to their MW output
proportion to their MBASE
proportion to their r
• eserves (Pmaxmc-Pgenmc)
A required file built by DFAX provides subsystem and
Distribution factor data file
interface definitions.
6.21.2 Sensitivity analysis output

The sensitivity analysis will generate a report containing sensitivity factors. Figure 6-74 shows a
sample of the report. The network model selection (DC network or AC network) is present at the
top of the report, followed by the opposing system selection if any. The sensitivity factors are then
listed in different tables, one table for each flow or voltage to each device type.
In the sample, the sensitivity factors of MW flow on the branch from bus 151 to bus 152 to
generation injections, loads, as well as the phase shifter from bus 202 to bus 203 are listed
respectively. The direction of MW flow is from bus 151 to bus 152. The value of the factor of MW
flow to the generation injection at bus 101 is 0.2933, which indicates the line will have an
increased MW flow of 0.2933 per unit in the direction from bus 151 to bus 152 when the generation
at bus 101 increases by 1 per unit and correspondingly generation at system swing bus decreases
by 1 per unit. For the phase shifter, angle is represented in radians. The line will have a decreased
MW flow of 0.1912 per unit in the direction from bus 151 to bus 152 when the phase shifter angle
increases one radian or 57.3 degrees.
6-244
Figure 6-74. Sample of sensitivity analysis report
The API has been provided to calculate and return sensitivity factors of branch flows to active power
injections of generators and loads in a subsystem in Fortran arrays, the arrays can then be exported
to a Excel file. The API can be called from Python files (refer to the Section 9.1.4,
SENSITIVITY_FLOW_TO_MW in the API Guide).
6-245
6-246
Chapter 7
Geomagnetically Induced
Currents
Chapter 7 - Geomagnetically Induced Currents
7.1 GIC Analysis

Activity GIC
Run Activity GIC - GUI

Power Flow > GIC Analysis
Requirements / Prerequisites
Validly specified power flow case
GIC data file (See Section 7.2, GIC Data File Contents)
AB
Activity GIC is to calculate Geomagnetically Induced Currents (GIC) in electric power system
network as a result of Geomagnetic Disturbance (GMD). The flow of GIC in transformers causes
their half-cycle saturation. This results in increased harmonics, reactive power consumption and
increase in transformer hot-spot temperature. After calculating GIC flows, activity GIC calculates
transformer reactive power losses.
Activity GIC can be run on entire power flow network or specified sub system.
7-1
Geomagnetically Induced Currents PSS®E 34.2
GIC Analysis Program Operation Manual
The user specifies one or all of the following options for the correct execution of activity GIC.
Specification Description
Three different GMD events are modeled for calculating GICs flowing in power system
network.
• Uniform Electric Field
The GMD event effect on power system is specified by uniform geoelectric field (E) in
V/km and its direction (?) in degrees.
• Benchmark GMD Event Electric Field
The benchmark GMD event effect on power system is specified by uniform geoelectric
field (E) of 8 V/km and its direction (?) in degrees.
The substation location data is provided in terms of geographical coordinates.
However, NERC TPL-007-1 provides alpha scaling factors in terms of geomagnetic
coordinates. Therefore, GIC activity "Benchmark Year" option is used to convert
substation geographical coordinates to geomagnetic coordinates.
GMD Event
The substation earth model is provided either from activity option argument or in
substation record of GIC data file. This substation earth model name is used to get
beta scaling factors as per NERC TPL-007-1.
• Non-Uniform Electric Field
Following data is provided to define the electrojet source current characteristics.
• Electrojet Current Amplitude (million Amps)
• Electrojet Current Density Cauchy Distribution half-width (km)
• Electrojet Period of Variation (minutes)
• Electrojet Height of Current (km)
• Latitude of Electrojet Center (degrees)
7-2
PSS®E 34.2 Geomagnetically Induced Currents
Program Operation Manual GIC Analysis
Select Standard earth conductivity model or enter User defined earth conductivity
model.
Standard Earth Conductivity Models
Following one dimensional earth conductivity models defined by United States
Geological Survey (USGS) are added as standard earth conductivity models.
Name Description Name Description
AK1A Adirondack AK1B Adirondack
Mountains-1A Mountains-1B
AP1 Appalachian AP2 Northern Appala-
Plateaus chian Plateaus
BR1 Northewest Basin CL1 Colorado Plateau
and Range
CO1 Columbia Plateau CP1 Coastal Plain
Earth Conductivity (South Carolina)
Models
CP2 Coastal Plain CS1 Cascade-Sierra
(Georgia) Mountains
IP1 Interior Plains IP2 Interior Plains
(North Dakota)
IP3 Interior Plains IP4 Interior Plains
(Michigan) (Great Plains)
NE1 New England PB1 Pacific Border
(Willamette
Valley)
PB2 Pacific Border PT1 Piedmont
(Puget Lowlands)
SL1 St. Lawrence SU1 Superior Upland
Lowlands
7-3
GIC Analysis Program Operation Manual
Following one dimensional earth conductivity models defined by Natural
Resources Canada are added as standard earth conductivity models.
Name Description
BC British Columbia (BC)
PRARIES Alberta (AB), Saskatchewan (SK),
Manitoba (MB)
SHIELD Ontario (ON), Quebec (QC)
ATLANTIC Atlantic Canada
User Defined Earth Conductivity Models
User defined earth conductivity models can be specified in GIC data file.
Application Notes
The name of the earth conductivity model should be unique. Activity GIC
searches earth conductivity model in "standard" models first then in "user"
models. So if any User earth model has same name as "standard" earth
model, it will not get used.
GIC analysis can be performed either for entire power flow network or for a
subsystem.
Two subsystem can be defined - Study subsystem and Local Hotspot subsystem.
Local hotspot subsystem must be subset of study subsystem as shown below.
GIC Subsystem
In reality during GMD event, the flow of GICs will not be restricted only to subsystem,
but GICs will flow in the entire network. So in order to consider the effect of GIC flows
in neighboring network on the transformers in subsystem under study, the "Intertie
Levels" can be specified. The "Intertie Levels" option is used as below:
• Intertie Level = 0, consider buses in subsystem only
• Intertie Level = 1, consider buses in subsystem + buses 1 level up from
subsystem tie buses.
• Intertie Level = 2, consider buses in subsystem + buses 2 level up from
subsystem tie buses.
• Intertie Level >0, consider buses in subsystem + buses specified number of
levels up from subsystem tie buses
Application Notes
Local Hotspot subsystem is used only for uniform and benchmark event calculations.
7-4
Program Operation Manual GIC Analysis
• GIC Data Input File (.gic extension)
The additional data that is required for GIC calculations is provided in this file. See
Section 7.2, GIC Data File Contents. Activity GIC will not run without providing
GIC data file.
Depending on the size of the power flow network studied, this data could be large.
- Using "Create GIC File" button required GIC data file template could be
created and saved.
- Using "Edit GIC File" button GIC data from GIC data file provided could be
edited and saved to same or new file.
• GIC Case Data Output File
The result of GIC calculations is increased reactive power losses in transformers.
These losses can be applied to power flow base case either as:
- Saved Case - A new Saved Case will be created with transformer Q
GIC Files losses added to it as Constant Current loads and saved to file specified
here. The program working memory will be changed to open this new
Saved Case.
- RDCH - An RDCH file with transformer Q losses as Constant Current
loads will be created.
• GIC to Base Case RDCH Output File
An RDCH file with "out-of-service" status for transformer Q losses loads will be
created.
• GIC Resistive Network Output Raw File
Power flow base case network is converted to resistive network for GIC calculations.
This will be complete power raw file. Note that, there will be many more buses added
to base case when creating this network to facilitate transformer winding and substa-
tion ground connections.
The "output" files specified here will be created only if their names are provided.
GIC calculations are based on power flow networks DC resistance and DC resistance
values specified in GIC data files. If some of these resistance values are not specified,
these default values will be used to determine resistance.
• Substation grounding DC resistance
Every substation in GIC study must have a grounding resistance. This resistance in
ohms is provided in GIC data file. However, if this is not specified in GIC data records,
this R value will be used.
• Non-transformer branch X/R ratio
Activity GIC uses branch resistance specified in power flow data as branch DC resis-
GIC Global Data tance. For those branches whose R value is not specified, this branch X/R is used to
Defaults determine branch resistance value.
However, for accurate GIC calculations, branch DC resistance with its skin effect
accounted should be used. If this information is available, using PSSE automation
files change branch resistance accordingly before performing GIC analysis.
• Transformer X/R ratio
Activity GIC uses transformer winding DC resistance specified in GIC data file. If
these resistance values are not specified, it calculates winding resistance values from
resistance values specified in power flow data. In this case, for those transformers
whose resistance value is not specified, this X/R is used to determine their resistance
value. Again, for accurate GIC calculations provide transformer winding DC resistance
in GIC data file
7-5
GIC Data File Contents Program Operation Manual
These options allow creating "text report" as desired. The output can be limited to
certain top (maximum value) numbers or all possible values. The quantities that can
be selectively added to text report are:
• Induced Branch Voltage
GIC Report Output • Bus Voltages
Options
• Branch GIC Flows
• Transformer GIC Flows
• Substation GIC Flows
• Transformer Losses
7.2 GIC Data File Contents

The geomagnetic induced currents can flow through transformer winding and substation ground
paths. For power flow calculations and substation ground paths data is not required. So this data is
not available in power flow data. This additional data is provided in GIC data file (extension .gic).
The accuracy of GIC calculations will depend on the data provided in GIC data file.
Depending on the size of the power flow network studied, this data could be large. It is recom-
mended to create a GIC data template with one of the following ways and edit/modify that.
• Using activity GIC GUI, GIC data file from Excel GIC data templates
- Power Flow > GIC Analysis > Excel template for GIC data file
- Power Flow > GIC Analysis > Create GIC data file from Excel template
• Python module "gicdata" (See PSS®E Application Program Interface (API) manual)
• Using activity GIC GUI button "Create GIC File"
There are three record groups, each group contains a particular type of required data.
The GIC data file record structure is shown below:
7-6
Program Operation Manual GIC Data File Contents
GIC Data File Identification Data
Substation Data
Bus Substation Data
Transformer Data
Branch Data
User Earth Model Data
Switched Shunt Data
Two-Terminal DC Data
VSC DC Data
Multi-Terminal DC Data
FACTS Device Data
Load Data
Q Record
Q Record Generally, specifying a data record with a Q in column 1 indicates the

end of the GIC data file. The end of data input indicator is permitted
anywhere except the ’GIC Data File Version’ record.
7-7
7.2.1 GIC Data File Identification Data

This record contains only one data item which is specified as:
GICFILEVRSN=vernum
where:
GICFILEVRSN is the keyword to specify GIC data file version number.

vernum is an integer value specifying GIC data file version number. No default
allowed.
Allowed, GICFILEVRSN=4
Note: The first release of GIC data file did not have this record and are treated as file version 1.
7.2.2 Substation Data

I, NAME, UNIT, LATITUDE, LONGITUDE, RG, EARTHMDL, RGFLAG
where:
I Substation Number (1 through 999997). No default allowed.

NAME Alphanumeric identifier assigned to substation I. NAME may be up to
40 characters and may contain any combination of blanks, uppercase
letters, numbers, and special characters, but the first character must
not be a minus sign. NAME must be enclosed in single or double
quotes if it contains any blanks or special characters. NAME is 40
blanks by default.
UNIT Unit for geophysical location (longitude and longitude) data.
= 0 for degrees
At this time, only allowed unit value is degrees.
UNIT = 0 by default.
LATITUDE Substation latitude, positive for North and negative for South. No
default allowed.
When UNIT is 1, latitude is specified in degrees.
LONGITUDE Substation longitude, positive for East and negative for West. No
default allowed.
When UNIT is 1, longitude is specified in degrees.
RG Substation grounding DC resistance in ohms
If RG<=0.0 or RG>=99.0, it is assumed that substation is ungrounded.
RG = 0.1 ohm by default
EARTHMDL Name of the Earth Model. It may be up to 32 characters.
• When specified, this Earth Model will be used n determining the
Benchmark GMD event earth model scaling factor (beta) and Non-
uniform GMD event calculations.
• When it is not specified, the Earth Model specified in the GIC API is
used.
EARTHMDL = ’’ by default.
7-8
RGFLAG Method used to specify RG value. It may be up to 40 characters.

This is used for information only. Possible methods include ’Assumed’,
’Measured’, ’Calculated’ or any similar brief comment.
RGFLAG = ’Assumed’ by default.
7.2.3 Bus Substation Data

BUSNUM, SUBNUM
The bus specified by "BUSNUM" must exist in power flow data.
where:
BUSNUM Bus Number. It must be present in power flow network data. No default allowed.
SUBNUM Substation Number (1 through 999997). This is a substation number to which bus
"BUSNUM" belongs to. No default allowed.
"SUBNUM" must be previously defined in "Substation Data" record group.
The following restrictions apply when assigning bus and its substation:
• Generally, two buses connected by a transmission line (non-transformer branch) reside
in two different substations. An exception to this would be short lines between two
buses of the same substation. Those short branches are treated as zero length
branches with no GMD induced voltage in them.
• Two buses connected by a two winding transformer must be in same substation.
• Three buses connected by a three winding transformer must be in same substation.
• Two buses connected by zero impedance line must have same substation number.
7.2.4 Transformer Data

I, J, K, CKT, WRI, WRJ, WRK, GICBDI, GICBGJ, GICBDK, VECGRP, CORE, KFACTOR,
GRDWRI, GRDWRJ, GRDWRK, TMODEL
The transformer specified by buses "I, J, K, CKT" must exist in power flow data. Also the winding
bus order must be same as in power flow data.
Note 1: For two and three winding auto transformers WRI, WRJ and WRK could represent per
phase dc resistances of series winding (Rs) or common winding (Rc).
For example, as shown in figure below:
• Bus I is series winding bus, WRI=Rs

• Bus J is common winding bus, WRJ=Rc
7-9
S – Series winding, C – Common winding

Rs – Series winding dc resistance, ohms/ phase
Rc – Common winding dc resistance, ohms/ phase
kV Ibus > kV Jbus
Bus I
kV Ibus
S Rs
Bus J
kV Jbus
C Rc
Two winding auto transformer circuit
Note 2: The figure below shows generic Phase Angle Regulator (PAR) connections where series
winding has split tap. It is represented as the T model in the GIC calculation DC network. The series
winding is connected between Bus I and Bus J. In the GIC data file:
• WRI is dc winding resistance of series winding section connected to Bus I.

• WRJ is dc winding resistance of series winding section connected to Bus J.
• WRK is dc winding resistance of common winding.
It is imperative that WRI, WRJ, and WRK values are calculated and specified in the GIC data file
for correct modeling of such a transformer.
split series unit

Bus I Bus J
kV Ibus WRI WRJ kV Jbus
IS IL
WRK
IE
exciting
unit
(a) AC Connections (b) GIC Equivalent DC Circuit T Model
Symmetric Phase Shifting Transformer
7-10
Parameters in the above two figures:
I The bus number of the bus to which Winding 1 is connected. It must

be same Winding 1 bus for the same transformer power flow data. No
default allowed.
J The bus number of the bus to which Winding 2 is connected. It must
be same Winding 2 bus for the same transformer power flow data. No
default allowed.
K The bus number of the bus to which Winding 3 is connected. It must
be same Winding 3 bus for the same transformer power flow data.
K = 0 for two winding transformers
No default allowed for three winding transformers
CKT One- or two-character non-blank alphanumeric circuit identifier
WRI DC resistance of Winding 1 in ohms/phase.
WRI = 0.0 by default
When WRI is not specified, power flow data resistance is used to
determine WRI.
WRJ DC resistance of Winding 2 in ohms/phase.
WRJ = 0.0 by default
When WRJ is not specified, power flow data resistance is used to
determine WRJ.
WRK DC resistance of Winding 3 in ohms/phase.
WRK = 0.0 for two winding transformers
For three winding transformers, when WRK is not specified, power
flow data resistance is used to determine WRK.
WRK = 0.0 by default
GICBDI GIC blocking device in neutral of Winding 1
= 0, no GIC blocking device present
= 1, GIC blocking device present
For an auto-transformer, if either GICBDI=1 or GICBDJ=1, that auto-
transformer is treated as it has GIC blocking device present.
GICBDI = 0 by default
GICBDJ GIC blocking device in neutral of Winding 2
For an auto-transformer, if either GICBDI=1 or GICBDJ=1, that auto-
transformer is treated as it has GIC blocking device present.
GICBDJ = 0 by default
GICBDK GIC blocking device in neutral of Winding 3
GICBDK = 0 for two winding transformers
GICBDK = 0 by default
7-11
VECGRP Alphanumeric identifier specifying vector group based on transformer

winding connections and phase angles. VECGRP is 12 blanks by
default.
If vector group is specified in power flow data that data will be used
and it is not needed to be specified here. As far as GIC calculations
are concerned, winding grounding connection information is used; its
clock angles are not used.
Refer to POM sections ’Two Winding Transformer Vector Groups’ and
’Three Winding Transformer Vector Groups’ for allowed vector groups.
• When the bus number orders in the GIC data file record are different
from the bus number orders in the power flow RAW data file, the bus
number orders in the power flow RAW data file is used to assign winding
configuration as per vector group specified.
• For auto transformers, bus with lower base bus voltage is treated as
common winding bus.
• For three winding auto transformers, windings on bus I and bus J form
auto transformer.
CORE Number of cores in transformer core design. This information is used
to calculate transformer reactive power loss from GIC flowing its
winding.
= -1 for three phase shell form
= 0 for unknown core design
= 1 for single core design
= 3 for three phase 3-legged core form
= 5 for three phase 5-legged core form
CORE = 0 by default
KFACTOR A factor to calculate transformer reactive power loss from GIC flowing
its winding (MVAR/AMP). KFACTOR = 0.0 by default
GRDWRI Winding 1 grounding DC resistance in ohms
GRDWRI = 0.0 by default (no grounding resistance, solidly grounded)
GRDWRJ Winding 2 grounding DC resistance in ohms
GRDWRJ = 0.0 by default (no grounding resistance, solidly grounded)
GRDWRK Winding 3 grounding DC resistance in ohms
GRDWRK = 0.0 by default (no grounding resistance, solidly grounded)
TMODEL Transformer Model in GIC DC Network
= 0, two/three/auto transformer model as defined by its vector group
= 1, transformer as T model in DC network (see Note 2)
TMODEL = 0 by default
7.2.5 Fixed Bus Shunt Data

I, ID, R, RG
Only in service fixed bus shunts provided on this data record are modeled in the GIC DC network.
7-12
where:
I Bus number of the bus to which fixed shunt is connected. It must be

present in power flow network data. No default allowed.
ID One- or two-character non-blank alphanumeric fixed bus shunt
identifier
R DC resistance in ohms/phase. It must be > 0. No default allowed.
Fixed bus shunt records with R=0 will be ignored.
RG Grounding DC resistance in ohms
RG = 0.0 by default (no grounding resistance, solidly grounded)
7.2.6 Branch Data

I, J, CKT, RBRN, INDVP, INDVQ, RlnshI, RlnshJ
Only in-service ranches are modeled in the GICDC network.
I Branch from bus number. No default allowed.

J Branch to bus number. No default allowed.
CKT One- or two-character non-blank alphanumeric branch circuit identifier.
RBRN Branch DC resistance in ohms/phase.
RBRN = 0.0 by default.
If RBRN is not specified or RBRN = 0.0, the power flow data branch resistance is
used as is.
INDVP Real part of total branch GMD-induced electric field in volts.
See notes below on how to specify this value.
INDVQ Imaginary part of total branch GMD-induced electric field in volts.
See notes below on how to specify this value.
RlnshI DC resistance on ohms/phase of the line shunt at the bus I end of the branch. It must
be > 0. No default allowed. If RlnhsI = 0 or is not specified, there is no ground path
for this line shunt.
RlnshJ DC resistance on ohms/phase of the line shunt at the bus J end of the branch. It
must be > 0. No default allowed. If RlnhsJ = 0 or is not specified, there is no ground
path for this line shunt.
Note 1: Total branch FGMD-induced electric field is INDUCEDV = INDVP + j INDVQ volts.
Branch INDUCEDV is determined as below:

• If INDUCEDV is not specified, GIC activity calculates it according to the specified
options.
• If INDUCEDV is specified, it is used as the GMD-induced voltage on that branch.
• If INDUCEDV is specified as INDVP = 0.0 and INDVQ = 0.0, then that branch is treated
as part of the GICDC network but does not have GMD-induced voltage, like ’under-
ground cable’.
7-13
For uniform field modeling INDUCEDV has a real value, but for non-uniform field modeling
it is a complex value.
The voltage has positive polarity at branch To Bus (J bus).
Note 2: When:
• Branch INDVP + j INDVQ is specified, it is used as is. There are no other scaling factors
applied to this voltage.
• INDVP + j INDVQ is specified for all branches, the specified GMD event option is
ignored during GIC calculations.
• INDVP + j INDVQ is specified for few branches, the induced Efield for the remaining
branches in study subsystem is calculated using the GMD event option specified.
7.2.7 User Earth Model Data

The User Earth Model Data Activity in GIC models the US and Canadian Earth Models (see Earth
Conductivity Models chapter). If any other Earth Model is required, use this data to define such an
Earth Model (See the PAG v.1, Chapter 12, GIC Calculations). A total of 50 Earth Models are
allowed, and each Earth Model can have up to 25 layers. The thickness of the last layer is infinity,
which is specified as any value less than 0.0. (for example, -999.0). A thickness value less than 0.0
is also used as the end of Earth Model data.
NAME, BETAFTR, DESC,

RESISTIVITY1, THICKNESS1,
RESISTIVITY2, THICKNESS2,
.
.
.
RESISTIVITY25, THICKNESS25
NAME The non-blank alphanumberic identifier assigned to this Earth Model.

Each Earth Model mist have a unique NAME. The NAME may have up
to 12 characters.This name should be different from the standard US
and Canada Earth Models defined in (cf. Earth Conductivity Models
and PAG volume 1 chapter 12 GIC Calculations). No default allowed.
BETAFTR Earth Model scaling factor used when calculating branch induced
electric field for Benchmark GMD event. BETAFTR = 1 by default.
DESC Description of the Earth Model. DESC may have up to 72 characters.
It is used for information purposes only. DESC is empty by default
RESISTIVITY1 Layer 1 resistivity in ohm-m. No default allowed.
THICKNESS1 Layer 1 thickness in km. No default allowed.
RESISTIVITYn nth layer resistivity in ohm/m.No default allowed. Up to 25 layers are
allowed.
THICKNESSn nth layer thickness in km. No default allowed. Up to 25 layers are
allowed. The thickness of the last layer is infinity, specified as any
value less than zero (for example, -999.0).
7.2.8 Switched Shunt Data

I, R, RG
7-14
Only in-service switched shunts provided on this data record are modeled in the GIC network.
where:
I Bus number of the bus to which the load is connected. It must be

present in power flow network data. No default allowed.
R DC resistance in ohms/phase. If must be > 0. No default allowed.
Switched shunt records with R = 0 will be ignored.
RG Grounding DC resistance in ohms. RG = 0.0 by default (no grounding
resistance, solidly grounded).
7.2.9 Two-Terminal DC Data

NAME, I, ID, R, RG
The rectifier and inverter converter stations are connected to AC network through converter trans-
formers. If these converter transformers are not explicitly modeled in the power flow, then use this
data record to specify GIC DC network data for them.
Provide DC resistance data of grounded wirings of converter transforms.
The status (blocked or in-service) of two-terminal DC lines from power flow data is not considered.
The DC data provided on this data record are modeled in the GIC DC network. Up to 10 GIC DC
network elements are allowed per DC line.
where:
NAME The non-blank alphanumeric identifier assigned to this DC line. It must

be present in the power flow network data. No default allowed. NAME
may be up to 12 characters.
I Bus number of the rectifier (IPR) or inverter (IPI) AC bus. It must be
present in the power flow network data. No default allowed.
ID One- or two-character non-blank alphanumeric identifier. There could
be more than one ground path at rectifier or inverter AC bus. This ID is
used to specify which ground path. This is specific to GIC data and
does not exist in power flow data. No default allowed.
R DC resistance in ohms/phase of grounded winding of converter trans-
formers. It must be > 0. No default allowed. R = 0 or unspecified
means there is no ground path.
7-15
AC AC
Pole 1
Bus 1 Bus 2
AC Bus 1: Implicit converter transformer model
AC Bus 2: Explicit converter transformer Model
T1
AC Bus
T2
R(T1) R(T2) R(T3) R(T4)
3*RG(T1) 3*RG(T2) 3*RG(T3) 3*RG(T4)

T3
Substation Bus
Rsub
T4
Pole 2
Converter transformer grounded windings
Typical HVDC Converter station representation in GIC DC network
7.2.10 VSC DC Data

NAME, I, ID, R, RG
The VSV converters are connected to the AC network through converter transformers. If these
converter transformers are not explicitly modeled in the power flow, then use this data record to
specify GIC DC network data for them.
Provide DC resistance data of grounded windings of converter transformers.
The status (in-service or out-of-service) of VSC DC lines from power flow data is not considered.
The DC data provided in this data record is modeled in the GIC DC network. Up to 10 GIC DC
network elements are allowed per VSV DC line.
where:
NAME The non-blank alphanumeric identifier assigned to this VSC DC line. It

must be present in the power flow network data. No default allowed.
NAME may be up to 12 characters.
I Converter AC bus number (IBUS). It must be present in the power flow
network data. No default allowed.
be more than one ground path at AC bus. This ID is used to specify
which ground path. This is specific to GIC data and does not exist in
power flow data. No default allowed.
7-16

7.2.11 Multi-Terminal DC Data

NAME, I, ID, R, RG
The multi-terminal converters are connected to the AC network through converter transformers. If
these converter transformers are not explicitly modeled in the power flow, then use this data record
to specify GIC DC network data for them.
The status (blocked or in-service) of multi-terminal DC lines from power flow data is not considered.
where:
NAME The non-blank alphanumeric identifier assigned to this multi-terminal

DC line. It must be present in the power flow network data. No default
allowed. NAME may be up to 12 characters.
I Converter AC bus number (IB). It must be present in the power flow
network data. No default allowed.
7.2.12 FACTS Device Data

NAME, I, ID, R, RG
The FACTS device converters are connected to the AC network through converter transformers. If
these converter transformers are not explicitly modeled in the power flow, then use this data record
to specify GIC DC network data for them.
The status (in-service or out-of-service) of FACTS devices from power flow data is not considered.
7-17
NAME The non-blank alphanumeric identifier assigned to this FACTS device.

It must be present in the power flow network data. No default allowed.
NAME may be up to 12 characters.
I FACTS device sending end bus number (IBUS). It must be present in
the power flow network data. No default allowed.
7.2.13 Load Data

I, ID, R, RG
Only in-service loads provided on this data record are modeled in the GIC DC network.
where:
I Bus number of the bus to which the load is connected. It must be

present in the power flow network data. No default allowed.
ID One- or two-character non-blank alphanumeric identifier.
formers. It must be > 0. No default allowed. Load records with R = 0
will be ignored.
7-18
Chapter 8
Linear Network Analysis
Chapter 8 - Linear Network Analysis
8.1 Building the Distribution Factor Data File

Activity DFAX
Run Activity DFAX - GUI

Power Flow > Linear Network > Build distribution factor data file (DFAX)…
[Build Distribution Factor Data File]
Run Line Mode Activity DFAX - CLI
ACTIVITY?
>>DFAX
ENTER FILENAME FOR STORING DISTRIBUTION FACTORS

None
The Distribution Factor File setup activity DFAX reads a set of Linear Network Analysis Data Files
(refer to Section 8.1.1 Linear Network Analysis Data Files) and reflects their contents in a Distribu-
tion Factor Data File in preparation for any of activities OTDF, DCCC, TLTG, POLY, SPIL, IMPC,
LLRF, and ACCC. Activity DFAX also calculates line outage distribution factors and preserves them
in the Distribution Factor Data File.
Subsystems of the working case are specified in a Subsystem Description Data File, monitored
elements are specified in a Monitored Element Data File, and contingencies are specified in a
Contingency Description Data File.
The Distribution Factor File setup activity reads a set of Linear Network Analysis Data Files and
reflects their contents in a Distribution Factor Data File in preparation for performing automatic ac
contingency analysis as well as a variety of other analyses including dc contingency testing, gener-
ator contingency analysis and transfer limit identification.
8-1
Linear Network Analysis PSS®E 34.2
Building the Distribution Factor Data File Program Operation Manual
Input for the process of creating the Distribution Factor file is contained in three data files:
• Subsystem Description Data file; relevant subsystems of the working case are speci-
fied in this *.sub file.
• Monitored Element Data file; network elements to be monitored for problems are
specified in this *.mon file.
• Contingency Description Data file; contingencies to be tested are specified in this
*.con file.
8.1.1 Linear Network Analysis Data Files

This section contains details on the formats of the data input files used by activity DFAX. File Nota-
tional Conventions defines the notational conventions used in the data record descriptions defined
below. Special Data Records describes those records that are common to all of the Linear Network
Analysis Data Files. Section 8.1.2 Subsystem Description Data File Contents gives the record
formats used in the Subsystem Description Data File, Monitored Element Data File Contents
describes the Monitored Element Data File, and Contingency Description Data File Contents
defines the Contingency Description Data File.
File Notational Conventions

In describing the input file syntax, the following notational conventions are used:
CAPITALS Keyword that must be specified exactly as shown. No keyword abbreviations are
allowed.
[…] Items enclosed in square brackets are optional keywords and/or values.
|A| or A|B Specify one from the list separated by, or enclosed in, the vertical bars.
|B|
bsid Bus identifier; this data value must be a bus number when the numbers input option
is in effect, and an extended bus name (twelve character name plus bus base
voltage) when the names input option is in effect (refer to Section 3.3.3 Program
Run-Time Option Settings and activity OPTN). If an extended bus name contains
blanks or special characters, it must be enclosed in single quotes.
ckid One- or two-character circuit identifier.
mcid One- or two-character machine identifier.
devid FACTS device or dc line name; up to twelve characters. If a device name contains
blanks or special characters, it must be enclosed in single quotes.
i An integer value.
r A floating point value; the decimal point is optional when specifying a whole number
(e.g., 10, 10., and 10.0 all specify the floating point number ten).
file A filename.
label A 12-character label identifier. If a label contains blanks or special characters, it
must be enclosed in single quotes.
Keywords and data values must be separated by one or more blanks.
8-2
PSS®E 34.2 Linear Network Analysis
Program Operation Manual Building the Distribution Factor Data File
Special Data Records

The following record types are allowed in each of the Linear Network Analysis Data Files:
TRACE Enable or disable input tracing. When enabled, each line read from the input file is
written to the Progress tab or the user’s designated output file; refer to Section 4.4
Virtual Output Devices. Tracing is initially disabled.
ECHO file Write each input line to the designated file; if the filename specification contains any
blanks or slashes ( / ), it must be enclosed in single quotes. Echoing of input records
is useful when data records are being entered interactively and the same set of
input records will be used in subsequent executions of activity DFAX. The file spec-
ified here is completely independent of any file specified to the PSS®E activity
ECHO (refer to Section 16.12, Running a Response File and Section 16.13,
Recording User Actions). Refer to Section 2.4.1 File Usage for the file specification
conventions used by activity DFAX.
COM Comment line that is ignored during input processing. Any meaningful comments
may be placed on a comment line following the COM keyword.
END End of block structure or end of data input, as appropriate.
In addition, blank lines may be included anywhere in the file. These are ignored during the input file
processing.
8.1.2 Subsystem Description Data File Contents

Subsystems of the working case are defined via the Subsystem Description Data File. While format
details differ, the subsystem definition provided is functionally identical to the specification of
subsystems via the bus subsystem selector dialog and the optional suffixes of many PSS®E
reporting and processing activities (refer to Section 4.8 Subsystem Selection).
The portion of the working case to be contained in each subsystem being defined is specified in the
following block structure:
SUBSYSTEM|SYSTEM [label]
(subsystem specification data record)
.
.
END
The subsystem specification data records allowed are as described below.
The optional subsystem labels are used on several record types in the Monitored Element and
Contingency Description Data Files; they are also printed in the line mode dialog of activity TLTG,
SPIL, and POLY, which summarizes the subsystems defined and allows the user to select the study
and opposing systems. If no label is specified on a SUBSYSTEM record, the label UNNAMED n is
assigned to the subsystem, where < n > is a unique integer. Up to 100 subsystems may be specified
in a Subsystem Description Data File, and each subsystem must be defined within a single
SUBSYSTEM block structure.
Buses can be selected to be in included in a SUBSYSTEM or SYSTEM using a series of criteria;

that is selecting by BUS, AREA, ZONE, OWNER and KV. Furthermore, buses can be selected on
an individual basis or in groups.
8-3
Selecting buses by number requires data records of the following form:
BUS bsid
BUSES bsid bsid
The BUSES record is valid only when the numbers input option is in effect (refer to Section 3.3.3
Program Run-Time Option Settings and activity OPTN), and assigns the designated buses, as well
as all buses where bus numbers fall between the two bus numbers specified, to the subsystem
being defined. For example, the data record BUSES 15 77 may be used to select all buses with
numbers from 16 to 76, inclusive.
All buses in selected areas may be assigned to a subsystem with data records in the following
format:
AREA i
AREAS i i
where i is an area number. The AREAS record type assigns all buses in a range of area numbers
to the subsystem being defined. For example, the data record AREAS 5 7 may be used to assign
all buses in areas five, six, and seven to the subsystem.
Similarly, all buses in selected zones and owners may be assigned to a subsystem with data
records of the following form:
ZONE i
ZONES i i
OWNER i
OWNERS i i
Buses at designated voltage levels may be assigned to a subsystem with records of the following
form, where, as above, the KVRANGE record defines a range of voltage levels:
KV r
KVRANGE r r
Note that, in specifying ranges of bus numbers, areas, zones, owners, and voltage levels, the
second value specified must not be preceded with a minus sign. The second number specified
must be greater than the first.
In addition, a join group block structure provides for the specification of a group of buses through
the logical anding of two or more of the five selection criteria described above. A join group has the
following block structure:
JOIN [label]
.
.
END
where each subsystem specification data record is one of the simple record types (BUS, AREA,
ZONE, OWNER, KV, or the corresponding range of records) described above. The optional JOIN
group label is for the user’s convenience and is neither used by activity DFAX nor preserved in the
Distribution Factor Data File.
8-4
Each join group block structure must appear within the subsystem block structure described above.
Both join group block structures and the simple record types may be included within a subsystem
block structure.
The following example defines the subsystem MY COMPANY, which consists of all buses in Area 5,
along with all buses in Area 6, which are in Zones 8 through 10:
SUBSYSTEM 'MY COMPANY'

AREA 5
JOIN 'GROUP 1'
AREA 6
ZONES 8 10
END
END
A single bus or a set of buses can be excluded from a subsystem with the SKIP commands as
described below. The commands must follow the simple subsystem specification records and/or
join group block structures; in other words they must be the last records or only appear before the
participation block within the subsystem specification block.
A single bus may be excluded from a subsystem with the data record in the form of:
SKIP BUS busid

A set of buses may be excluded form a subsystem with the following data records:
SKIP BUS WITH [IN-SERVICE] |LOAD | |LESS | r |MW |

|GENERATION | |GREATER | |MVAR|
|GENUPLIMIT | |MVA |
|GENLOWLIMIT |
|SHUNT |
When the optional IN-SERVICE keyword is present, only in-service components are considered in
summation, otherwise both in-service and out-of-service components are counted. The 'r' value is
the threshold in the specified unit with one of keywords MW, MVAR and MVA. In using the LESS
keyword, a bus is skipped from a subsystem if the corresponding data quantity of the bus is less
than the 'r' value. In using the GREATER keyword, a bus is skipped from a subsystem if its data
quantity is greater than the 'r' value.
At each bus that is assigned to the subsystem, in using LOAD keyword the total nominal load of
loads is compared against the 'r' value. When the GENERATION keyword is used, the total gener-
ation of the machines is compared against the 'r' value. In using GENUPLIMIT or GENLOWLIMIT
keyword, the corresponding total upper or lower limit of machines is considered in the summation.
When the SHUNT keyword is present, the total nominal output of bus fixed shunts is used for
comparing against the 'r' value.
The following data record can be used to exclude buses from a subsystem by comparing the current
nominal reactive power output from the switched shunt at the buses against the 'r' value.
SKIP BUS WITH [IN-SERVICE] SWSHUNT |LESS | r MWAR

|GREATER |
The following data record can be used to exclude buses by comparing the total active power
settings of induction machines at the buses against the 'r' value.
8-5
SKIP BUS WITH [IN-SERVICE] INDUCMACHINE |LESS | r MWAR

|GREATER |
Activities TLTG, SPIL, and POLY and the PV Analysis calculation modify the generation/load profile
within designated subsystems to determine transfer capability. The participation block structure
allows the user to specify those buses that are to participate in the generation/load shift, along with
their participation factors that determine how the change in subsystem power injection is to be
shared among the designated buses. To establish the participating buses and their participation
factors, the PARTICIPATE block structure is used.
The form of the participation block structure is:
PARTICIPATE
BUS bsid r
.
.
BUS bsid r
END
Each participation block structure must appear within the subsystem block structure described
above, and must follow the simple record types and/or join group block structures defining the
SUBSYSTEM; that is, it must be the last data record block in the SUBSYSTEM specification.
Each bus specified must be present in the subsystem being processed. Any bus that violates this
requirement or which is disconnected (i.e., its type code is four or greater) generates an alarm and
is excluded from the group of participating buses.
The r values are non-zero participation factors that are normally expressed in percent or per unit
of the total subsystem generation shift. While individual r values may be negative, the sum of the
r values within a participate block structure must be positive.
8.1.3 Monitored Element Data File Contents

This file identifies those elements, or groups of elements that are to be monitored for flow violations
and those buses that are to be monitored for voltage violations.
Flow Monitoring Records

Each monitored element may consist of either a single branch or a group of branches (an interface),
where the flow on an interface is taken as the sum of the flows on the branches comprising the
interface.
Up to 1,000 interfaces are allowed, and the total of single branches plus branches contained in all
interfaces may not exceed the number of branches for which PSS® E is dimensioned. Only
in-service branches are added to the monitored element list.
To specify a single branch for monitoring, the following data record may be used:
[MONITOR] |BRANCH| FROM BUS bsid TO BUS bsid

|LINE |
|CIRCUIT| ckid
|CKT | ]
To specify one winding of a three-winding transformer for monitoring, the bus to which the winding
is connected must be the first bus specified in the following data record:
8-6
[MONITOR] |BRANCH| FROM BUS bsid TO BUS bsid TO BUS bsid |CIRCUIT| ckid
|LINE | |CKT | ]
If the optional circuit identifier keyword and data value are omitted, a circuit identifier of '1' is
assumed.
As a convenience to save typing, the following block structure may be used to designate a series
of single branches for monitoring where, as above, the default circuit identifier is '1'. Three-winding
transformers cannot be specified using this block structure.
[MONITOR] BRANCHES|LINES|BREAKERS
bsid bsid [ckid]
.
.
bsid bsid [ckid]
END
In specifying a branch with the above records, if it is already in the monitored element list in the
specified direction, an appropriate message is printed and the record is ignored. If a branch is
included in the monitored element list in both directions, flows (and distribution factors) for the two
entries are printed in activities OTDF, DCCC, TLTG, SPIL, IMPC, and POLY with equal magnitude
and opposite sign; in activity ACCC, the same results are shown in both directions.
Option Settings and activity OPTN), in-service multi-section line groupings may be specified with
the above records. If an in-service member of a multi-section line grouping is specified, the multi-
section line (rather than the specified member) is added to the monitored element list in the same
direction as the specified member.
When the multi-section line reporting option is disabled, multi-section line groupings may not be
specified in the above records; in-service members of multi-section line groupings may be desig-
nated and are added as specified to the monitored element list.
The following four record types provide for the addition of a group of branches to the monitored
element list with a single record. When the keyword BRANCHES, LINES, or TIES is used, all
branches in the grouping except breakers and switches are added as monitored elements. In using
the BREAKERS keyword, only breaker and switch branches in the grouping are added as monitored
elements. Any branch that is included in the subset specified by the record, but which is already
included in the monitored element list in either direction, is skipped.
For these record types, when the multi-section line reporting option is enabled, multi-section line
groupings within the specified subset, but not the individual members of such groupings, are added
to the monitored line list. When the multi-section line reporting option is disabled, members of multi-
section line groupings within the specified subset, but not the multi-section line groupings, are
added to the monitored line list.
To place all branches in the monitored element list, the following data record may be used:
[MONITOR] ALL |BRANCHES|

|LINES |
|BREAKERS|
Branches are entered into the monitored element list in single entry form, with the lower ordered
bus (number or name, according to the bus output option currently in effect) as the from bus.
8-7
The following data record may be used to select for monitoring all branches connected to a speci-
fied bus:
[MONITOR] |BRANCHES| FROM BUS bsid

|LINES |
|BREAKERS|
All branches within a specified subsystem may be monitored by entering the data record:
[MONITOR] |BRANCHES| IN |AREA i |[3WLOWVOLTAGE]

|LINES | |ZONE i |
|BREAKERS| |OWNER i |
|KV r |
|SYSTEM label |
|SUBSYSTEM label|
In using the SYSTEM or SUBSYSTEM keywords, the label must correspond to a subsystem label
specified in a previously accessed Subsystem Description Data File (refer to Section 8.1.2
Subsystem Description Data File Contents).
For a three-winding transformer to be included, without the token '3WLOWVOLTAGE' all of its in-
service windings must be connected to subsystem buses; in using the token '3WLOWVOLTAGE',
checking on connection of its low voltage winding to a subsystem bus is disabled if all its three
winding bus voltages are specified as non-zero values. For any such three-winding transformer, all
of its in-service windings connected to subsystem buses are added to the monitored element list.
To place branches that are assigned to a line owner into the monitored element list, the following
data record can be used:
[MONITOR] |LINES | WITH LINE OWNER i

|BRANCHES|
|BREAKERS|
Finally, the following record provides for the monitoring of all ties from a specified subsystem, or all
ties between a pair of subsystems:
[MONITOR] TIES FROM |AREA i | TO |AREA i |

|ZONE i | |ZONE i |
|OWNER i | |OWNER i |
|KV r | |KV r |
|SYSTEM label | |SYSTEM label |
|SUBSYSTEM label | |SUBSYSTEM label |
For a three-winding transformer to be included, at least one of its in-service windings must be
connected to a subsystem bus, and at least one of its in-service windings must be connected to a
bus that is either not in the subsystem or in the to subsystem, as appropriate; for any such three-
winding transformer, all of its in-service windings connected to subsystem buses are added to the
monitored element list.
For a tie branch between a pair of subsystems to be added to the monitored element list, both of
the following must be satisfied:
8-8
1. One bus is in the from subsystem.
2. Another bus is in the to subsystem, and it is not in the from subsystem.
For the case of disjoint subsystems (e.g., TIES FROM AREA 1 TO AREA 2), the selection of tie
branches is clear and unambiguous. However, in the case of overlapping subsystems (e.g., TIES
FROM AREA 1 TO ZONE 5), the user must be aware of the above rules in specifying TIES records.
The possibility exists that, in applying the above criteria, the set of branches included as ties may
not be the same if the from and to subsystems are interchanged. Consider, for example, the
following area and zone assignments:
Bus Area Zone

1 1 10
2 1 5
3 2 5
4 1 5
Furthermore, assume that a branch exists between each pair of buses. The record TIES FROM
AREA 1 TO ZONE 5 would include the branches 1-3, 2-3, and 4-3, but not 1-2, 1-4, or 2-4.
Conversely, the record TIES FROM ZONE 5 TO AREA 1 would include the branches 2-1, 3-1, and
4-1, but not 2-3, 2-4, or 3-4.
Option Settings and activity OPTN), the subsystem assignments of the dummy buses of each multi-
section line grouping are ignored; a multi-section line grouping is treated as a tie branch if and only
if its endpoint buses satisfy items (1) and (2) above. When the multi-section line reporting option is
disabled, the multi-section line grouping definitions are ignored and any member of a multi-section
line grouping satisfying items (1) and (2) above is considered a tie branch.
An INTERFACE is defined using the following block structure:
[MONITOR] INTERFACE label

[
|RATING r [MW] |
|RATINGS r1 r2 ... r12 [MW]|
(branch specification record; see below)
]
.
.
END
where the branch specification records may specify sets of tie lines:
[MONITOR] TIES FROM |AREA i | TO |AREA i |

|ZONE i | |ZONE i |
|OWNER i | |OWNER i |
|KV r | |KV r |
|SUBSYSTEM label| |SUBSYSTEM label|
individual branches:
8-9
MONITOR] |BRANCH| FROM BUS bsid TO BUS bsid |CIRCUIT| ckid

|LINE | |CKT |
individual three-winding transformer windings:
[MONITOR] |BRANCH| FROM BUS bsid TO BUS bsid TO BUS bsid

|LINE | [ |CIRCUIT| ckid
|CKT | ]
or, simply:
bsid bsid [ckid]
The 32-character interface labels are used to identify interfaces in the output reports of those activ-
ities that use the Distribution Factor Data File. As with ac branches, provision is made for up to
twelve interface ratings. Interface ratings that are entered as zero, or omitted, are handled in the
same way as branch ratings of zero in activities DCCC, TLTG, SPIL, POLY, IMPC, and ACCC.
If the optional specification of ratings is omitted, the sum of the appropriate rating set values of each
of the interface members is taken as the interface rating. An interface rating is usually specified as
something other than a thermal limit; for example, contractual or stability considerations may deter-
mine the interface rating to be used.
The SKIP block structure is used to specify individual branches that are to be excluded from the
monitored element list generated as a result of subsequent specification records that are used to
define a group of branches.
SKIP

END
Non-transformer branches and two-winding transformers are specified on branch specification

records using the following record format:
[
bsid TO bsid |CIRCUIT| ckid
|CKT | ]
Three-winding transformers are specified on branch specification records using the following record
format:
[
bsid TO bsid TO bsid |CIRCUIT| ckid
|CKT | ]
The default circuit identifier is '1' if this specification is omitted.
Branches specified in a SKIP block structure apply only to MONITOR ALL, MONITOR LINES and
MONITOR TIES records which define a group of branches and are below it in the Monitored
Element Data File. Multiple SKIP block structures are allowed, and each SKIP block structure
8-10
appends to the list of branches to be omitted from monitoring as a result of subsequent group spec-
ification records.
Voltage Monitoring Records

Buses that are to be monitored for voltage violations by the AC Contingency Solution (refer to
Section 6.10.1 AC Contingency Solution Options) are specified in the Monitored Element Data File.
Two types of voltage violations may be detected.
The following data record defines a voltage band along with a set of buses where voltages are to
be checked against the band.
[MONITOR] VOLTAGE RANGE |ALL BUSES | r [r]

|ALL NODES |
|AREA i |
|ZONE i |
|OWNER i |
|KV r |
|SYSTEM label |
|SUBSYSTEM label |
|BUS bsid |
|SUB suid NODE ndid |
|SUBSTATION suid NODE ndid|
[MONITOR] VOLTAGE RANGE NODES IN |AREA i | r [r]
|ZONE i |
|OWNER i |
|KV r |
|SYSTEM label |
|SUBSYSTEM label |
|BUS bsid |
|SUB suid NODE ndid|
Where the first r value is the lower bound of the per unit voltage band and the optional second r
value is the upper bound. If the upper bound is omitted, the upper end of the band is not checked.
The following data records define a set of buses to be monitored for voltage limit violations.
[MONITOR] VOLTAGE LIMIT |ALL BUSES | r [r]

|ALL NODES |
|AREA i |
|ZONE i |
|OWNER i |
|KV r |
|SYSTEM label |
|SUBSYSTEM label |
|BUS bsid |
[MONITOR] VOLTAGE LIMIT NODES IN |AREA i | r [r]
|ZONE i |
|OWNER i |
|KV r |
8-11
|SYSTEM label |
|SUBSYSTEM label |
|BUS bsid |
When multiple voltage limit records are used in a monitored element data file, buses that have
already been included in the set will be ignored. Bus data includes normal and emergency bus
voltage limits. The designation of the voltage limit to be used is made at result post-processing
stage.
The following data record defines voltage drop and voltage rise deviation thresholds along with a
set of buses where voltage changes in contingency cases from their base case values are to be
checked.
[MONITOR] VOLTAGE DEVIATION |ALL BUSES | r [r]

|ALL NODES |
|AREA i |
|ZONE i |
|OWNER i |
|KV r |
|SYSTEM label |
|SUBSYSTEM label |
|BUS bsid |
[MONITOR] VOLTAGE DEVIATION NODES IN |AREA i | r [r]
|ZONE i |
|OWNER i |
|KV r |
|SYSTEM label |
|SUBSYSTEM label |
|BUS bsid |
Where the first r value is the magnitude of voltage drop in per unit and the optional second r value
is the magnitude of voltage rise. If the voltage rise threshold is omitted, the voltage rise check is
omitted.
8.1.4 Contingency Description Data File Contents

Contingency cases are designated in a Contingency Description Data File. While activity OTDF
allows only single event contingencies, the remaining activities provide for contingency cases
consisting of up to 32 events.
The Contingency Description Data File provides two means by which contingency cases may be
specified. Individual contingency cases consisting of single or multiple events involving bus
boundary condition and/or branch status changes may be specified in a contingency case block
structure (refer to Contingency Case Block Structure). In addition, the selection of a group of single
or double line outage contingency cases may be specified with a single data record (refer to Auto-
matic Contingency Specification).
8-12
Contingency Case Block Structure

In this method, a contingency case is defined in a block structure as follows:
CONTINGENCY label [r r]
(contingency event specification record; below)
.
.
(contingency event specification record; below)
END
The 32-character contingency label is printed in output reports to identify each contingency. The first
r value on the data record represents frequency in occurrence/year and the second r value on the
data record represents duration in hours of the contingency. They are used for probabilistic reliability
assessment. A contingency can contain up to 32 contingency event specification records
The remainder of this section describes the contingency event specification records supported.
The outaging of an in-service non-transformer branch or two-winding transformer is specified with

the following record, where the default circuit identifier is '1' if this specification is omitted:
|DISCONNECT| |BRANCH| FROM BUS bsid TO BUS bsid |CIRCUIT| ckid

|OPEN | |LINE | |CKT |
|TRIP |
Similarly, an out-of-service non-transformer branch or two-winding transformer may be placed in-

service with a record of the form:
CLOSE |BRANCH| FROM BUS bsid TO BUS bsid |CIRCUIT| ckid

|LINE | |CKT |
Option Settings and activity OPTN), multi-section line groupings may be specified with the above
records. If a member of a multi-section line grouping is specified, switching the entire multi-section
line (rather than the specified member) is treated as the contingency event.
When the multi-section line reporting option is disabled, multi-section line groupings may not be
specified in the above records; members of multi-section line groupings may be designated on
OPEN and CLOSE records, and only the specified member is switched.
The outaging of an in-service three-winding transformer is specified with the following record, where
the default circuit identifier is '1' if this specification is omitted:
|DISCONNECT| |BRANCH| FROM BUS bsid TO BUS bsid TO BUS bsid |CIRCUIT| ckid
|OPEN | |LINE | |CKT |
|TRIP|
Similarly, all windings of an out-of-service three-winding transformer may be placed in-service with
a record of the form:
8-13
CLOSE |BRANCH| FROM BUS bsid TO BUS bsid TO BUS bsid |CIRCUIT| ckid
|LINE | |CKT |
The outaging of one winding of a three-winding transformer is specified with the following record,
where the default circuit identifier is 1 if this specification is omitted:
|DISCONNECT| THREEWINDING AT BUS bsid TO BUS bsid TO BUS bsid |CIRCUIT| ckid
|OPEN| |CKT |
|TRIP|
Similarly, one winding of a three-winding transformer may be placed in-service with a record of the
form:
CLOSE THREEWINDING AT BUS bsid TO BUS bsid TO BUS bsid |CIRCUIT| ckid
|CKT |
The winding to be opened or closed is the winding connected to the first bus specified. Prior to
opening one winding of a three-winding transformer, all three windings of the transformer must be
in-service; prior to closing one winding of a three-winding transformer, the other two windings of the
transformer must be in-service.
An in-service FACTS device or dc line may be blocked with a record of the form:
BLOCK |TWOTERMDC | devid

|MULTITERMDC|
|VSCDC |
|FACTS |
where the four tokens in the selection list allow access to two-terminal dc lines, multi-terminal dc
lines, VSC dc lines, and FACTS devices, respectively.
The settings of an in-service two terminal dc line may be specified with a record of the form:
SET TWOTERMDC devid TO r|MW |

|AMPS|
|KV |
When keyword MW is used, the two terminal dc line must be in power control mode and r is the
power demand to be designated. When keyword AMPS is used, the two terminal dc line must be in
current control mode and r is the current demand to be designated. The scheduled compounded
dc voltage is changed to r when keyword KV is employed.
The outaging of all in-service branches connected to a bus may be specified with a record of the
form:
|DISCONNECT|BUS bsid
|OPEN |
|TRIP |
This command is converted to as many OPEN BRANCH commands as are required before it is
passed to the Distribution Factor Data File.
8-14
Option Settings and activity OPTN), each in-service multi-section line connected to the specified
bus is switched out as a unit. If the specified bus is a dummy bus of a multi-section line, this
command is converted to a single OPEN BRANCH command that outages the corresponding multi-
section line.
When the multi-section line reporting option is disabled, only the line section adjacent to the spec-
ified bus is outaged for each multi-section line connected to the bus.
The next four record types allow the user to specify contingency events in which the load and gener-
ation boundary conditions may be changed at a selected bus. Load and shunt are synonymous in
the linearized network model, and specifying either results in identical contingency events. When
changing generation, the bus must have in-service generation connected to it and it may not be a
swing bus.
The following data record is used to set the load or generation at a bus either to a designated value
or to a specified percentage of its initial value:
SET BUS bsid |GENERATION| TO r |MW | [DISPATCH]

|LOAD | |PERCENT|
|SHUNT |
The number r specified must not be a negative number when the PERCENT keyword is used.
When the optional keyword DISPATCH is included at the end of the SET record, the user may
designate how the change in the bus boundary condition is to be apportioned among selected
network buses rather than having it all assigned to the system swing bus(es). In this case, the SET
data record must be followed by records of the form:
BUS bsid r
.
.
BUS bsid r
END
The r values are positive participation factors that are normally expressed in percent or per unit of
the total MW change specified by the contingency event specification record.
When SET commands operate on the bus fixed shunt, an additional keyword MVAR can be used
to change reactive power component of a bus fixed shunt:
SET BUS bsid SHUNT TO r MVAR

The real power component of bus fixed shunts remains constant. DISPATCH keyword is not
allowed to be included in the above command.
The following data record is used to change the load or generation at a bus either by a designated
amount or by a specified percentage of its initial value:
|CHANGE| BUS bsid |GENERATION| BY r |MW | [DISPATCH]

|ALTER | |LOAD | |PERCENT|
|MODIFY| |SHUNT |
When the PERCENT keyword is specified, the magnitude of the initial value of the quantity to be
modified is used to determine the amount of the change; i.e.,
8-15
r x |Porig|
Pnew = Porig +
100.
In changing either by PERCENT or MW, when the quantity to be modified is initially positive and the
change is a reduction (i.e., r is negative), a negative result is treated as an error condition.
The presence of the optional keyword DISPATCH is handled as described above for the SET data
record.
The next two data record types are similar to the CHANGE record, except the direction of the
change is defined by the first keyword, and r must be a positive number:
|INCREASE| BUS bsid |GENERATION| BY r |MW | [DISPATCH]

|RAISE | |LOAD | |PERCENT|
|SHUNT |
|DECREASE| BUS bsid |GENERATION| BY r |MW | [DISPATCH]

|REDUCE | |LOAD | |PERCENT|
|SHUNT |
record.
Similarly, keyword MVAR can be used in CHANGE/INCREASE/DECREASE commands to change

reactive power component of bus fixed shunts, e.g.:
|DECREASE| BUS bsid SHUNT BY r MVAR

|REDUCE |
The following data record is used to transfer load or generation from one bus to another:
MOVE r |MW | |GENERATION| FROM BUS bsid TO BUS bsid

|PERCENT| |LOAD |
|SHUNT |
When transferring MW, the power shift, Psh, is set to r; when the PERCENT keyword is specified,
the power shift is calculated as:
r x |Porig|
Psh =
100.
where Porig is initial load or generation, as appropriate, at the from bus. The power shift is then
subtracted from the original power at the from bus and added to the original power at the to bus.
When the quantity to be modified at the from bus is initially positive, a negative post-shift power at
the from bus is treated as an error condition.
When generation is being transferred, the from bus must have in-service generation. If the to bus
is not a generator bus, an appropriate message is printed and the power shift is treated as negative
load at the to bus. Either of the two buses may be a swing bus.
The keyword MVAR can be used to transfer the reactive power component of bus fixed shunts with
the data record:
8-16
MOVE r MVAR SHUNT FROM BUS bsid TO BUS bsid
An in-service synchronous machine, induction machine, load or fixed bus shunt may be removed
from service using the following data record:
REMOVE |MACHINE | mcid FROM BUS bsid [DISPATCH]

|INDUCMACHINE|
|UNIT |
|LOAD |
|SHUNT |
Similarly, an out-of-service synchronous machine, induction machine, load or fixed bus shunt may
be placed in-service with a record of the form:
ADD |MACHINE | mcid TO BUS bsid [DISPATCH]

|INDUCMACHINE|
|UNIT |
|LOAD |
|SHUNT |
record. The machine status contingency events are not permitted at swing buses.
An in-service switched shunt may be removed form service with the following data record:
REMOVE SWSHUNT FROM BUS busid
Automatic Contingency Specification

Automatic Single and Double Line Outage Contingency Specification
When the keyword BRANCH, LINE, or TIE is used in automatic single and double line outage contin-
gency specification commands, all branches except breakers and switches are included in the
contingencies. When the keyword BREAKER is used, only breaker and switch branches are included
in the contingencies.
The following data record provides for the designation of a series of single line outage contingency
cases:
SINGLE |BRANCH| FROM BUS bsid

|LINE |
|BREAKER|
Each in-service branch connected to the designated bus is outaged, one at a time. Similarly, a
series of double line outage contingency cases may be specified with the data record:
DOUBLE |BRANCH| FROM BUS bsid

|LINE |
|BREAKER|
All branches within a specified subsystem may be outaged, either singly or in pairs, by entering the
data record:
|SINGLE | |BRANCH| IN |AREA i | [3WLOWVOLTAGE]

|DOUBLE | |LINE | |ZONE i |
8-17
|BUSDOUBLE| |BREAKER| |OWNER i |

|PARALLEL | |KV r |
|SYSTEM label |
|SUBSYSTEM label|
Without the token '3WLOWVOLTAGE', for a three-winding transformer to be included, all of its in-
service windings must be connected to subsystem buses. In using the token '3WLOWVOLTAGE',
the three-winding transformer is included if its in-service high and median voltage windings are
connected to subsystem buses.
The DOUBLE, BUSDOUBLE, and PARALLEL contingency specification records all generate
contingency cases consisting of two simultaneous line outages. The DOUBLE record generates all
combinations of double line outage contingencies for all branches where endpoint buses are
contained in the specified subsystem. That is, each branch in the subsystem is outaged in turn with
every other branch in the subsystem. DOUBLE may be viewed as considering independent events
causing simultaneous outages.
The BUSDOUBLE record is more restrictive than the DOUBLE record. For each bus in the specified
subsystem, it generates all combinations of double line outage contingencies for all branches
between that bus and other subsystem buses. BUSDOUBLE may be viewed as considering single
events in substations that affect pairs of branches connected to a substation.
The PARALLEL record is more restrictive than the BUSDOUBLE record. It generates double line
outage contingencies only for parallel branches (i.e., for each contingency case, the two branches
being outaged connect the same pair of subsystem buses). Three-winding transformer contingen-
cies are not generated by the PARALLEL record. PARALLEL may be viewed as considering single
events on rights-of-way that affect pairs of branches on a right-of-way.
In using the SYSTEM or SUBSYSTEM keywords, the label must correspond to a subsystem label
specified in a previously accessed Subsystem Description Data File (refer to Section 8.1.2
Subsystem Description Data File Contents).
Branches that are assigned to a line owner can be outaged, either singly or in pairs by using the
following data record:
|SINGLE | |BRANCH| WITH LINE OWNER i

|DOUBLE | |LINE |
|BUSDOUBLE|
|PARALLEL |
All in-service buses within a specified subsystem may be singly disconnected with the data record:
SINGLE BUS IN |AREA i |

|ZONE i |
|OWNER i |
|KV r |
|SYSTEM label |
|SUBSYSTEM label|
Each single bus outage is converted to as many OPEN BRANCH commands as are required to
open all in-service branches connected to the bus before it is passed to Distribution Factor Data
File.
In-service machines connected to in-service generator buses within a specified subsystem may be
removed from service singly with the data record:
8-18
SINGLE |MACHINE| IN |AREA i |

|UNIT| |ZONE i |
|OWNER i |
|KV r |
|SYSTEM label |
|SUBSYSTEM label|
Only one machine can be outaged for each generator bus. When a generator bus has multiple in-
service machines, the machine with the biggest real power generation is chosen to be outaged.
Finally, the following data record provides for the outaging, either singly or in pairs, of all ties from
a specified subsystem or all ties between a pair of subsystems:
|SINGLE | TIE FROM |AREA i | TO |AREA I |

|DOUBLE | |ZONE i | |ZONE i |
|BUSDOUBLE| |OWNER i | |OWNER i |
|PARALLEL | |KV r | |KV r |
|SUBSYSTEM label| |SUBSYSTEM label|
The selection of tie branches in the case of overlapping subsystems is handled using the same
criteria defined in Monitored Element Data File Contents for the monitoring of ties.
For these record types, when the multi-section line reporting option is enabled, the outaging of a
multi-section line grouping within the specified subset is treated as a contingency event; the entire
multi-section line is outaged. When the multi-section line reporting option is disabled, individual
members of multi-section line groupings within the specified subset (rather than entire multi-section
line groupings) are outaged.
The SKIP block structure is used to specify individual branches that are to be excluded from
outaging in contingencies generated as a result of subsequent SINGLE, DOUBLE, BUSDOUBLE,
and PARALLEL contingency specification records. Each SKIP block structure is specified as
follows:
SKIP
(branch specification record; below)
.
.
(branch specification record; below)
END
Non-transformer branches and two-winding transformers are specified on branch specification
records using the following record format:
bsid TO bsid |CIRCUIT| ckid

|CKT |
Three-winding transformers are specified on branch specification records using the following record
format:
8-19
bsid TO bsid TO bsid |CIRCUIT| ckid

|CKT |
The default circuit identifier is ’1’ if this specification is omitted,
Branches specified in a SKP block structure apply only to SINGLE, DOUBLE, BUSDOUBLE, and
PARALLEL contingency specification records which are below it in the Contingency Description
Data File. Multiple SKIP block structures are allowed, and each SKIP block structure appends to
the list of branches to be omitted from outaging as a result of subsequent automatic contingency
specification records.
When the multi-section line reporting option is enabled and a branch that is a member of a multi-
section line is specified, the multi-section line is excluded from outaging. When the multi-section line
reporting option is disabled and a multi-section line is specified, an error message is printed and the
record is ignored.
8.1.5 NB contingencies
The following commands can be processed only when the PSSE network case contains node
breaker data, otherwise they are ignored by the applications where they are simulated.
The following command will isolate an in-service branch, system switching device or two- winding
transformer by breaker operations.
[
|ISOLATE| |BRANCH | FROM BUS bsid TO BUS bsid |CIRCUIT| ckid [
|LINE | |CKT |
The processing of this and other isolate contingencies consists of:
• Using the full topology network model to systematically follow the circuits outward from
the line to be isolated, and identify and open breakers in order to clear the fault on the
circuit. The operation may result in one or multiple circuits (i.e. branches, transformers,
etc) being opened en route to the opening of a breaker. Once a breaker is successfully
opened, the search along that path terminates. If the process extends along paths
beyond a user specified number of bus levels outward (OPTN) and the line has not
been successfully isolated, then the process will terminate with a message.
• The breakers include those defined as both system switching devices and substation
switching devices. The operations may result in one or more breakers being opened.
• If a stuck breaker status is encountered, the process will continue without opening the
breaker and a message will be displayed. Refer to the Stuck Breaker command below.
• With the successful isolation of the line the following process are completed in order:
- The topology processor will automatically be run to update the bus branch model
based the status of switching devices.
- Once the topology processing is complete, the power flow solution will be run to
solve the new contingency state.
The following command will isolate an in-service three winding transformer by breaker operations:
[
|ISOLATE| |BRANCH | FROM BUS bsid TO BUS bsid TO BUS bsid |CIRCUIT| ckid
[
|LINE | |CKT |
8-20
The following command will isolate one winding of a three-winding transformer by breaker
operations:
[
|ISOLATE| |THREEWINDING | AT BUS bsid TO BUS bsid TO BUS bsid |CIRCUIT| ckid
[
|CKT |
Isolation of all in-service branches connected to a bus may be specified with a record of the form:
[
|ISOLATE| BUS bsid |CIRCUIT| ckid
[
|CKT |
The following command opens an in-service switching device (SWD) in a substation:
[
|DISCONNECT| |SWD | |SUBSTATION| staid FROM NODE nodeid TO NODE nodeid |CIRCUIT| ckid
[
|OPEN | |SWITCH | |SUB | |CKT |
|TRIP | |BREAKER|
The following command closes an out-of-service switching device in a substation:
[
CLOSE |SWD | |SUBSTATION| staid FROM NODE nodeid TO NODE nodeid |CIRCUIT| ckid
[
|SWITCH | |SUB | |CKT |
|BREAKER|
The following command isolates an in-service switching device in a substation by breaker

operations.
|ISOLATE | SWD |SUBSTATION| staid FROM NODE nodeid TO NODE nodeid

|SUB |
The following command will isolate a single end of an in-service branch, system switching device
or two-winding transformer by breaker operations:
[
|DISCONNECT| TERMINAL FROM BUS bsid TO BUS bsid |CIRCUIT| ckid
[
|OPEN | |CKT |
|ISOLATE |
The following command will isolate a single terminal of an in-service three-winding transformer by
breaker operations:
[
|DISCONNECT| TERMINAL FROM BUS bsid TO BUS bsid BUS bsid |CIRCUIT| ckid
[
|OPEN | |CKT |
|ISOLATE |
The following command will isolate a single node of a substation by breaker operations:
ISOLATE |SUBSTATION| staid NODE nodeid
|SUB |
The following command will place a closed breaker in the status of “stuck”. It will fail to open in
subsequent isolation operations in that contingency:
8-21
[
STUCK BREAKER |SUBSTATION| staid FROM NODE nodeid TO NODE node id |CIRCUIT| ckid
[
|SUB | |CKT |
Automatic Contingency Specification

The following record will create contingencies for every in-service branch or transformer connected
to a bus:
|SINGLE| |OPEN TERMINAL | FROM BUS bsid

|DOUBLE| |ISOLATE LINE |
|ISOLATE BRANCH|
The following records will create contingencies for every in-service branch or transformer in a
subsystem:
|SINGLE | |ISOLATE LINE | IN |AREA i | [3WLOWVOLTAGE]

|DOUBLE | |ISOLATE BRANCH| |ZONE i |
|BUSDOUBLE| |OWNER i |
|PARALLEL | |KV r |
|SYSTEM label |
|SUBSYSTEM label|
|SINGLE| |OPEN TERMINAL| IN |AREA i |

|DOUBLE| |ZONE i |
|OWNER i |
|KV r |
|SYSTEM label |
|SUBSYSTEM label|
The following record will create contingencies for every in-service substation switching device
(which can be limited to switches or breakers) in a subsystem:
|SINGLE| |OPEN SWD | IN |AREA i |

|OPEN SWITCH | |ZONE i |
|OPEN BREAKER | |OWNER i |
|CLOSE SWD | |KV r |
|CLOSE SWITCH | |SYSTEM label |
|CLOSE BREAKER| |SUBSYSTEM label|
The following record will create stuck breaker contingencies for a subsystem. For each substation
in the subsystem, for each node in that substation, all combinations of in-service branches or trans-
formers and closed breakers connected to that node will be found. Each combination will generate
a contingency consisting of a stuck breaker record for that breaker and an isolate record for that
branch or transformer.
|SINGLE| |STUCK BREAKER| IN |AREA i |

|ZONE i |
|OWNER i |
|KV r |
|SYSTEM label |
8-22
|SUBSYSTEM label|
8.1.6 Operation of Activity DFAX

Activity DFAX first checks that generators are not converted (refer to CONG) and that each non-
Type 4 bus is connected back to a Type 3 (swing) bus through the in-service ac network. If any viola-
tions are detected, an appropriate message is printed.
The user must specify the filename of the Distribution Factor Data File into which the results of
activity DFAX are saved.
The user defines subsystems of the working case from data records taken from either a designated
Subsystem Description Data File or the dialog input device. Refer to Section 8.1.2 Subsystem
Description Data File Contents for data input formats.
Subsystem definitions are required if the Distribution Factor Data File is to be used by activities
TLTG, SPIL, and/or POLY. Activities OTDF, DCCC, IMPC, LLRF, and ACCC do not require
subsystem definitions unless subsystems are referenced in the Monitored Element Data File and/or
the Contingency Description Data File specified below.
The user constructs a monitored element list from data records taken from either a designated
Monitored Element Data File or the dialog input device, as appropriate. Refer to Monitored Element
Data File Contents for data input formats.
The user may have the branches in the monitored element list sorted in the reports of activities
OTDF, DCCC, POLY, IMPC, LLRF, and AC Contingency Solution.
If the sort option is specified, branches are sorted in ascending numerical or alphabetical order
according to the bus output option currently in effect (refer to Section 3.3.3 Program Run-Time
Option Settings and activity OPTN). Branches are sorted by from bus, and, for each from bus, by
to bus and circuit identifier.
If the sort option is not specified, monitored branches remain in the same order in which they were
specified in the Monitored Element Data File. In either case, interfaces are reported after all moni-
tored branches in the order in which they were specified in the Monitored Element Data File.
Contingencies may be specified from either a designated Contingency Description Data File or the
dialog input device. Refer to Contingency Description Data File Contents for data input formats.
Activity DFAX reads the Contingency Description Data File, updating internal arrays and transfer-
ring the contingency definitions into the Distribution Factor Data File. Any contingency case
specifications in which errors are detected generate an alarm and are skipped.
Line outage distribution factors are used by activity DFAX only for building Distribution Factor Data
Files for specific PSS®E activities, as follows:
• Calculate distribution factors disabled: activities ACCC, IMPC, and LLRF

• Calculate distribution factors enabled: activities OTDF, DCCC, TLTG, SPIL, and POLY
If the distribution factor calculation is specified (default = enabled), activity DFAX continues its
processing. If a new ordering of network buses is required, an appropriate message is printed and
activity ORDR is automatically executed. The base case susceptance matrix is then constructed,
followed by the calculation of vectors of line outage distribution factors corresponding to line outage
contingency events contained in the Contingency Description Data File. Whenever a line outage
8-23
contingency results in the presence of a swingless island, an appropriate message is printed prior
to calculating the corresponding distribution factor vector.
A Distribution Factor Data File containing this additional information is required by activities OTDF,
DCCC, TLTG, SPIL, and POLY; it may also be used by activities IMPC, LLRF, and ACCC.
Refer to Section 2.4.1 File Usage for the file specification conventions used by activity DFAX.

Activity DFAX derives line outage distribution factors from the same linearized network model used
in the dc analogy network solution method of activity DCLF. While injection methods rather than
complete dc power flow solutions are used to calculate line outage distribution factors, the
comments in Section 8.4.4 Application Notes apply here as well. Note, in particular, the approxi-
mate nature of the linearized network model.
Activity DFAX needs to be executed before using activities OTDF, DCCC, TLTG, SPIL, POLY,
IMPC, LLRF, or ACCC. Because the line outage distribution factors and other information stored in
the Distribution Factor Data File are a function of data organization and network topology in the
working case, it follows that it must be re-executed before entering these activities any time one or
more of the following occurs:
• Change of bus type code

• Change of machine, load or branch status
• Change of branch reactance
• Change in the group of branches modeled as zero impedance lines
• Change of metered end of a multi-section line when the multi-section line reporting
option is enabled
• Addition or removal of buses, branches, machines or loads
• Change of any bus attributes by which subsystems, monitored elements, and/or con-
tingencies are specified (e.g., area assignments, base voltages, etc.)
• Change to any of the Linear Network Analysis Data Files
Activity DFAX is sensitive to the multi-section line reporting option (refer to Section 3.3.3 Program
Run-Time Option Settings and activity OPTN). Its setting at the time activity DFAX is selected is
saved in the Distribution Factor Data File and overrides the option setting in subsequent executions
of activities OTDF, DCCC, TLTG, SPIL, POLY, IMPC, LLRF, or ACCC.
Activity DFAX is sensitive to the bus input option (refer to Section 3.3.3 Program Run-Time Option
Settings and activity OPTN). Its setting at the time activity DFAX is selected governs the manner in
which buses must be identified (i.e., either bus numbers or extended bus names) in the Linear
Network Analysis Data Files that are read for activity DFAX. The setting of the bus input option in
subsequent executions of those activities that require a Distribution Factor Data File as input (i.e.,
activities OTDF, DCCC, TLTG, SPIL, POLY, IMPC, LLRF, and AC Contingency Solution) must be
identical to that which existed when activity DFAX was executed.
In defining subsystems, a bus may be assigned to more than one subsystem. Suppose, for
example, that in activity TLTG a study system consisting of all buses in an area is required. Suppose
further that the user wishes to include as monitored elements only those branches in the area at
230 kV and above. This can be accommodated by defining one subsystem to be the entire area and
8-24
Program Operation Manual Calculating Distribution Factors
a second subsystem (using the join group block structure) to contain those buses in the area at or
above 230 kV.
A Distribution Factor Data File specified to one of the analysis functions that utilizes a linear (dc)
network model (e.g., activities such as DCCC, TLTG and LLRF) must specify at least one monitored
branch or one interface. That is, the Monitored Element Data File specified to activity DFAX to
construct such a Distribution Factor Data File must specify at least one monitored branch or one
interface. A Distribution Factor Data File that is to be used only for ac contingency calculations in
which only voltage violations are of interest need not specify any monitored branches or interfaces.
Care should be taken not to include unnecessary END statements in the Linear Network Analysis
Data Files. END statements are used to indicate the termination of block structures as well as the
termination of the data input stream. Improperly placed END statements are often interpreted by
activity DFAX as an end of input data signal. Symptoms of these conditions can occur during the
execution of activities that use such a Distribution Factor Data File; they include monitored elements
that are omitted from output reports and contingency cases that are skipped.
PSS®E GUI Users Guide, Section 13.1, Building the Distribution Factor Data File
Section 10.1, Building the Distribution Factor Data File
8.2 Calculating Distribution Factors

Activity OTDF
Run Activity OTDF - GUI

Power Flow > Linear Network > Calculate and print distribution factors (OTDF)…
[Select Distribution Factor data file to calculate factors for]
Run Line Mode Activity OTDF - CLI
ACTIVITY?
>>OTDF

AB
The distribution factor reporting activity OTDF tabulates distribution factors for single event contin-
gencies using a linearized network model. Distribution factors for line outage contingencies are
retrieved from a Distribution Factor Data File constructed by activity DFAX. Distribution factors for
other types of contingency events are calculated as needed by activity OTDF.
It is possible for the user to print the distribution factors from the linearized network model Distribu-
tion Factor file built as described in Section 8.1 Building the Distribution Factor Data File but only
for single event line outage contingencies. Distribution factors for other types of single contingency
events are calculated as needed.
8-25
Calculating Distribution Factors Program Operation Manual
Because the linearized network model is the basis of the calculation of distribution factors, it is
necessary to recognize that their use provides approximate results useful for estimating conditions
during contingencies.
In both large and small network models, the factors are useful for the user to make quick estimates
of changes in line flows during contingencies that result in:
• Loss of a single line element

• Increase or decrease in generation at a bus
• Increase of decrease of load at a bus
Line closure distribution factors are generally not very useful and are supported only for compati-
bility with other linear analyses. They are equal in magnitude to those of the corresponding line
outage contingency but with the opposite sign.
8.2.1 Operation of Activity OTDF

Activity OTDF first checks that generators are not converted (refer to CONG) and that each non-
Type 4 bus is connected back to a Type 3 (swing) bus through the in-service ac network. If any viola-
tions are detected, an appropriate message is printed and activity OTDF is terminated.
If a new ordering of network buses is required, an appropriate message is printed and activity
ORDR is automatically executed. Next the largest active power mismatch corresponding to the
present ac solution voltage vector in the working case is calculated and printed.
The user must enter the name of a Distribution Factor Data File constructed by activity DFAX that
corresponds to the network condition contained in the working case (refer to Section 8.1.7 Applica-
tion Notes) and to the desired Linear Network Analysis Data Files (refer to Section 8.1.1 Linear
Network Analysis Data Files). The Distribution Factor Data File must specify at least one monitored
branch or interface. The bus input option (refer to Section 3.3.3 Program Run-Time Option Settings
and activity OPTN) must have the same setting that was in effect when activity DFAX filled the
specified file. Refer to Section 2.4.1 File Usage for the file specification conventions used by activity
OTDF.
The Distribution Factor Data File is read, and the base case dc power flow solution is calculated
followed by the processing of the designated contingency cases. Only single event contingencies
are allowed in activity OTDF; changing the status of a three-winding transformer is considered a
multiple event contingency; disconnecting a bus is often a multiple event contingency. Any multiple
event contingencies generate an alarm and are ignored.
Activity OTDF may be terminated by entering the AB interrupt control code.
8.2.2 Output Report Format

Results of activity OTDF are reported in tabular form, with six contingency cases per table. Each
group of contingency cases contains a page summarizing the contingency cases performed. For
each contingency, the contingency label and the data record defining the contingency are listed,
along with the change in power of the affected element (MW shift). For line outage contingencies,
the quantity shown is the base case ac active power flow at the metered end of the line in the from
bus to to bus direction.
The summary page is followed by the distribution factor table. For each monitored element, this
table lists its active power loading in the base case ac network solution as contained in the working
8-26
case when activity OTDF was entered, its loading in the base case dc analogy network solution,
along with the distribution factor for each of the cases reported.
Element Data File or in ascending numerical or alphabetical order, according to the option selected
during the execution of activity DFAX (refer to Section 8.1.6 Operation of Activity DFAX). These are
followed by the interfaces in the order in which they were specified.
If a line outage contingency forms one or more islands with no Type 3 (swing) bus, such islands are
disconnected. Any monitored branch that is located in the swingless island has dashes printed in
place of its distribution factor. Similarly, any interface that includes such a member has its distribu-
tion factor printed as dashes.
A partial report is shown in Figure 8-1, which is curtailed to show only three of the first six contin-
gencies. Note that the reports shows the data files uses and lists each single contingency
considered prior to listing the distribution factors for each of the lines and interfaces monitored, for
each contingency. The files used are the savnw.con/mon/sub files from the PSS®E EXAMPLE
directory.
As an example, It can be seen the if the nuclear plant at bus 101 is tripped, the SHIFT will be 750
MW, (the units output), and the line from Bus 201 to 151 will show a power flow reduction of 310
MW (which is equal to 750 MW x 0.41339). The base case flow is shown as negative value of 564.8
MW at the Bus 201 end. This is the receiving end of the line. Consequently, the 750 MW shift
coupled with a positive distribution factor will result in a reduce flow towards Bus 201. An ac solution
shows the flow reduces to 255.9 MW. The calculation (-564.8 + 310) gives -254.8 MW (error less
than 0.43%).
8-27
Calculating Distribution Factors Program Operation Manual
Figure 8-1. Example Report Listing Distribution Factors

Activity OTDF uses the same linearized network model as is used in the dc analogy network solu-
tion method of activity DCLF. Thus, in utilizing the distribution factors reported by activity OTDF, the
mate nature of the linearized network model used by activity OTDF.
8-28
Activity OTDF detects the specification of duplicate single line outage contingencies and prints the
distribution factor vector only for the first specification of such a contingency. Any contingency cases
involving bus boundary contingency events or line closure contingency events are not checked for
duplication.
It is recommended that the working case be solved to an acceptable mismatch tolerance prior to
launching activity OTDF. Otherwise, while the distribution factors would be valid, the base case line
flows printed would not.
Each column of distribution factors is a set of sensitivity coefficients describing the effect of the
corresponding contingency on the set of monitored elements. A distribution factor is defined as the
ratio of the change in flow on the monitored element in the pre-contingency and post-contingency
dc power flow solutions to the dc power change on the element involved in the contingency:
(MW in contingency case) - (MW in base case)

D.F. =
Power Shift
Distribution factors are usually used to estimate post-contingency line flows when only pre-contin-
gency (base case) conditions are known:
Pnew = Pbase + (D.F. × P)

In using distribution factors, the flow directions of Pbase and P used in the above equation must
be consistent with those assumed when the distribution factors were calculated.
For bus boundary condition contingencies, the distribution factors are expressed relative to a
change in power withdrawn at the bus. Thus, they are identical for increases in generation,
decreases in generation, increases in load and decreases in load. A load increase and a generation
decrease both have a positive P, while a load decrease and a generation increase both have a
negative P in deriving post-contingency monitored line flows with the above formula.
Line outage distribution factors are applied using the above equation with P equal to the flow on
the outaged line before it is opened.
Figure 8-2 is an example that shows the outage of a line carrying 100 MW in the base case. If the
distribution factor for that specific outage is denoted as FIJ for the line from Bus I to Bus L and its
value is equal to 0.05, then the line from Bus I to Bus L will have an increased loading equal to the
100 MW lost from the outaged line multiplied by FIJ, that is 5 MW.
8-29
Estimating Severity Rankings for Single Line Outage Contingencies Program Operation Manual
Figure 8-2. Application of Line Outage Distribution Factor
Line closure distribution factors are generally not very useful and are supported only for compati-
bility with activities DCCC, TLTG, SPIL, POLY, IMPC, and LLRF. They are equal in magnitude to
those of the corresponding line outage contingency but with the opposite sign.
In using distribution factors, the flow directions of Pbase and P used in the above equation must
be consistent with those assumed when the distribution factors were calculated.
A line outage distribution factor calculated by activity DFAX and printed by activity OTDF reflects
the outage of the series reactance element only and not the removal of the branch’s loss estimate
and line shunt components. Furthermore, neither line outage nor line closure distribution factors for
a multi-section line reflect the removal of any generation or load that may be present at its dummy
buses.
®
PSS E GUI Users Guide, Section 13.2, Calculating and Reporting Distribution Factors
PSS®E Command Line Interface (CLI) Guide,
Section 10.2, Calculating Distribution Factors
8.3 Estimating Severity Rankings for Single Line Outage
8-30
Program Operation Manual Estimating Severity Rankings for Single Line Outage Contingencies
Contingencies
Activity RANK
Run Activity RANK - GUI

Power Flow > Linear Network > Single contingency ranking (RANK)…
[Single Line Contingency Ranking]
Run Line Mode Activity RANK - CLI
ACTIVITY?
>>RANK
SOLUTION PARAMETERS ARE:

None
In large systems with many possible contingencies, especially single branch outages, it is often
useful to minimize the computational and subsequent analyses by identifying the most severe
contingencies prior to performing the contingency analysis.
The contingency ranking activity RANK estimates the severity of designated single branch outage
contingencies and builds a Contingency Description Data File (refer to Contingency Description
Data File Contents) with contingencies specified in decreasing order of their estimated severities.
Contingency rankings using two different performance criteria may be calculated by activity RANK.
Activity RANK may also be instructed to include contingencies that create swingless islands.
8.3.1 Contingency Ranking Methodology

The process of ranking contingencies in order of severity involves the following:
1. Establish the criteria to be considered in formulating the ranking (e.g., overloading, voltage
collapse, etc.).
2. For each criteria established in (1), define a scalar mathematical function that has a large
value for contingencies that stress the system relative to that criteria, and a small value for
those that do not; this function is called a performance index. The performance index should
be such that contingencies resulting in system conditions yielding large valued performance
indices are considered more severe than system conditions with smaller performance
indices.
3. Derive an efficient and accurate procedure for calculating these performance indices for a
large number of possible contingencies.
8-31
Activity RANK is able to calculate contingency rankings based on either or both of the following
criteria:
1. An overload criteria measuring branch loadings relative to their ratings.
2. A voltage depression criteria that indicates increased reactive power consumption by esti-
mating increases in reactive losses due to increased line loadings.
In the overload ranker, the performance index, PI, is defined as:
L 2
Pi
PI =  PMAXi
i=1
where:
Pi Is the active power flow on branch i.

PMAXi Is the rating of branch i.
L Is the set of monitored branches contributing to PI.
Clearly, PI has a small value for system conditions with light branch loadings and a large value when
lines exceed their limits. An increase in PI following a contingency indicates that overall loading on
the branches contributing to PI has increased.
The set of monitored branches in the overload ranker is as defined in a Monitored Element Data
File (refer to Monitored Element Data File Contents). This is normally the same set of monitored
elements that are specified to activity DFAX and subsequently, via the Distribution Factor Data File,
to activities such as DCCC and ACCC.
In the voltage ranker, the performance index is defined as:
L
PI =  XiPi2
i=1
where:
Xi Is the reactance of branch i.

Pi Is the active power flow on branch i.
L Is the set of monitored branches contributing to PI.
PI gives an indication of reactive power losses under different system conditions. As line loadings
increase, their I2X losses also increase. This increase in reactive demand generally results in a
depression of system voltages.
The set of monitored branches in the voltage ranker is normally all branches in the working case.
The user may elect to omit those branches for which no rating is specified in a selected rating set.
Having established ranking criteria and defined performance indices to compare the severity of
many contingencies relative to these criteria, we require a procedure for calculating these indices
that is substantially less burdensome than explicitly solving each contingency case. Activity RANK
employs the ranking algorithm described in An Advanced Contingency Selection Algorithm by
8-32
T.A. Mikolinnas and B.F. Wollenberg, IEEE Transactions on Power Apparatus and Systems,
Vol. PAS-100, No. 2, February, 1981, pp. 608-617. This algorithm provides for the evaluation of the
performance indices described above without requiring post-contingency branch flows.
8.3.2 Contingency Ranking Options

When selected, activity RANK first displays its default solution and output control parameters and
gives the user the opportunity to change any of these parameters:
The user may specify any of the following options:
Table 8-1. Contingency Ranking Options
Specification Default Description

If the largest initial active power mismatch exceeds the specified
MW mismatch tolerance 0.5
MW mismatch tolerance, the user may terminate activity RANK.
Reactance threshold; all branches from the contingency list
(based on the user’s subsystem selection, below) where
magnitude of reactance is less than or equal to this threshold
Small reactance threshold 0.0005 have their performance indices explicitly calculated.
Note: The performance index calculation used by activity RANK
(refer to Section 8.3.1 Contingency Ranking Methodology) is
inaccurate for the outaging of branches with small reactances.
If enabled, include in the contingency list only branches from
within the designated subsystem. If disabled, both subsystem
Allow ties from subsystem
Disabled branches and ties from the subsystem to other buses in the
as contingency
working case are included. The group of branches that may be
outaged are defined according to subsystem selection options.
Number < n > of line outages from the overload ranking to be
Number of branch contin- included in the output of activity RANK; a value of zero for this
10
gencies in file solution parameter causes activity RANK to bypass the overload
ranking calculation.
Number < m > of machine outages from the overload ranking to
be included in the output of the ranking process. The overload
ranker is applied to generating machine outages by assuming that
Number of machine contin- the generation deficiency is redispatched among remaining
0
gencies in file machines and that the new dispatches cause changes in branch
loading. The dispatch is always based on reserve. A value of zero
for this solution parameter causes the process to bypass the
machine overload ranking calculation.
activity The contingency case rating set, and the percentage thereof,
Contingency case rating
OPTN define the line loading limits used in determining overloads.
The user specifies the rating; the default rating set is estab-
Percent of rating 100 lished by the program option setting (refer to Section 3.3.3
Program Run-Time Option Settings and activity OPTN).
If enabled, ratings of monitored branches are converted to
Convert ratings to estimate estimated MW ratings based upon each monitored line's
Disabled
MW ratings reactive power loading at the metered end in the base case
ac solution.
8-33
Table 8-1. Contingency Ranking Options (Cont.)

Number < k > of voltage contingencies to be included in the
Number of voltage contin-
5 output of activity RANK; a value of zero for this solution parameter
gencies in file
causes activity RANK to bypass the voltage ranking calculation.
Defines the network branches that are to contribute to the
voltage ranker performance index:
Lines, used in voltage
All • Only branches with non-zero value in the rating set
ranker PI
designated by contingency case rating are used
• All network branches
Include contingencies If enabled, the output of contingencies that result in the for-
creating swingless islands mation of an island of one or more buses that contains no
Disabled Type 3 (swing) bus is enabled as follows: if the active
power flow on such a branch exceeds the MW threshold
tolerance specified in the base case dc power flow, the
contingency is included in the output of activity RANK.
MW threshold to include
100 Such contingencies are omitted from the overload and
island contingencies
voltage ranking calculations.
8.3.3 Operation of Activity RANK

Activity RANK verifies that at least one of the following parameters:
• number of overload contingencies

• number of voltage contingencies
• contingencies that include swingless islands
is greater than zero, that generators are not converted (refer to CONG), that each non-Type 4 bus
is connected back to a Type 3 (swing) bus through the in-service ac network, and that the largest
initial active power mismatch is within the specified MW mismatch tolerance. If any violations are
detected, an appropriate message is printed and activity RANK is terminated.
ORDR is automatically executed.
Activity RANK calculates and prints the largest active power mismatch corresponding to the present
ac solution voltage vector in the working case.
Activity RANK constructs a contingency list that defines those single branch outages that are to be
considered. The user may process the entire working case or specify subsystem data (refer to
Section 4.8 Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. Unless all
buses are specified, activity RANK honors the user specification to either include or omit tie
branches from the specified subsystem in the contingency list.
If the determination of an overload ranking is enabled (i.e., if number of overload contingencies is

greater than zero), the branch ratings to be used are set up according to the specification of contin-
gency case rating, percent of rating, and convert ratings. The appropriate rating set is accessed. If the
convert ratings setting is enabled, these ratings are converted to estimated MW ratings based upon
each branch's reactive power loading at the metered end in the base case ac solution. Finally, the
ratings are modified to reflect the percent of rating specified.
8-34
The user may define subsystems of the working case with input data records taken from either the
designated Subsystem Description Data File or the dialog input device, as appropriate. Refer to
Section 8.1.2 Subsystem Description Data File Contents for data input formats. Subsystem defini-
tions are required only if subsystems are referenced in the Monitored Element Data File specified
below.
The user specifies monitored elements. Activity RANK constructs a monitored branch list, taking
input data records from either the designated Monitored Element Data File or the dialog input device,
as appropriate. Refer to Monitored Element Data File Contents for data input formats. Activity RANK
excludes from the monitored branch list any branch with a zero (or negative) rating in the rating set
specified by contingency case rating; it also ignores any interface definitions.
Note that the above prompts requesting the Subsystem and Monitored Element Description Data
Files occur only if overload ranking is enabled.
The contingency ranking algorithm is unable to handle zero impedance lines as contingent or moni-
tored branches. Consequently, if any zero impedance lines are present in either the contingency
list, the monitored element list for the overload ranker (if overload ranking is enabled), or the moni-
tored element list for the voltage ranker (if voltage ranking is enabled), zero impedance line
modeling is temporarily disabled and a new ordering of network buses is determined with the auto-
matic execution of activity ORDR. The optimal ordering process in PSS®E is used to determine an
ordering of the network buses such that sparsity is maintained as the Jacobian matrix is triangular-
ized for ac network solutions or the system admittance matrix is decomposed into its triangular
factors in activities for linearized network analyses.
The user specifies either the filename where contingency specification records are to be stored or
output of the contingency records to the user's terminal.
Contingency rankings are calculated. If overload ranking is enabled, it is determined and the < n >
contingencies with the largest performance indices produce Contingency Description Data File
records. Similarly, if voltage depression ranking is enabled, it is determined and the < m > contin-
gencies with the largest performance indices produce Contingency Description Data File records.
Finally, if islanding contingency output is enabled, any contingency that results in the formation of
a swingless island and for which base case dc power flow loading exceeds the threshold specified
by MW threshold to include island contingencies, produces Contingency Description Data File records.
The working case is restored to its content at the time activity RANK was selected and activity
RANK is terminated.
Refer to Section 2.4.1 File Usage for the file specification conventions used by activity RANK.
8.3.4 Analyzing AC Contingency Ranking Results

The user supplies the name of an output file (type *.con) to which the contingency specification
records are to be deposited. If no filename is supplied, the results are written to the Progress tab.
If overload ranking is enabled, the < n > contingencies with the largest performance indices
produce Contingency Description Data File records. Similarly, if voltage depression ranking is
enabled, the < m > contingencies with the largest performance indices produce Contingency
Description Data File records. Finally, if islanding contingency output is enabled, any contingency
that results in the formation of a swingless island and for which base case dc power flow loading
exceeds the threshold specified produces Contingency Description Data File records.
8-35
Figure 8-3 shows a subset of the Contingency Description Data file produced by the ranking
process using the savnw.sav power flow case. It can be seen that each contingency included in the
ranked set is identified with either an overload or a voltage label and independently numbered.

Activity RANK derives performance indices and establishes severity rankings using the same
linearized network model used in the dc analogy network solution of activity DCLF. This level of
modeling is well suited for the function performed by activity RANK: the selection of system condi-
tions deserving further study. Contingencies enumerated by the overload ranker may be examined
further with activity DCCC and, if the line loadings warrant, with the ACCC and the other ac power
flow solution activities. Contingencies produced by the voltage ranker are normally analyzed with
the ac power flow solution activities.
The use of a single number to characterize a system condition is convenient for ranking purposes.
It does, however, have its limitations. For example, it is possible for a contingency that results in a
number of heavily loaded lines but no overloaded lines to be ranked equally with a contingency that
produces one or two overloaded lines with other lines being relatively lightly loaded. This is not
necessarily a deficiency; it is quite appropriate to conclude that both of these system conditions
deserve further study.
The performance indices defined above, and hence the severity rankings that are based on them,
are dependent both on (1) network topological and parametric data and (2) the system operating
point (i.e., on pre-contingency branch loadings). The same types of modeling changes that require
a new execution of activity DFAX (refer to Section 8.1.7 Application Notes) are also conditions
under which new rankings should be determined.
Furthermore, boundary condition changes (e.g., changes to loads, machine loadings, etc.), while
not invalidating a Distribution Factor Data File, may affect the contingency rankings. Boundary
condition changes that have only a minor impact on line loadings are not likely to significantly affect
the rankings; changes such as increasing an area's load by ten percent or tripping a large unit and
dispatching its previous power output among other machines in the system are likely to have a signif-
icant effect on line flows that in turn could significantly alter the contingency rankings.
As described in Section 8.3.2 Contingency Ranking Options, the contingency ranking algorithm is
not able to accurately calculate performance indices for branches with small reactances. The small
reactance threshold parameter, which has a default value of 0.0005, is a reactance threshold; for
any branch in the contingency list where reactance magnitude is less than or equal to this threshold,
the standard calculation is bypassed and its performance indices are explicitly calculated. The small
reactance threshold value should always be at least as large as the zero impedance line threshold
tolerance (refer to Section ). Experience to date indicates that the default value is conservative and
for most systems it could safely be reduced. For systems with small impedance lines, the user could
test the adequacy of this threshold by calculating two sets of overload rankings using different
threshold values. If the performance indices for the outaging of small reactance branches are
essentially the same, the smaller threshold value may be used.
When the multi-section reporting option is enabled (refer to Section 3.3.3 Program Run-Time
Option Settings and activity OPTN), the subsystem assignments of the two endpoint buses of each
multi-section line are considered (rather than those of any of its dummy buses) in adding the branch
to the contingency list. If a multi-section line is added to the contingency list, the line section at the
metered end of the multi-section line is considered to be the outaged element. The performance
indices that result are correct unless there is any load or generation present at any of the dummy
buses of the multi-section line.
8-36
Program Operation Manual Applying the DC Linearized Network Solution
For each three-winding transformer in the contingency list, performance indices are calculated for
the outaging of each in-service winding in turn, and the largest of these is taken as the performance
index for the entire transformer.
In constructing the contingency list, parallel lines between the same pair of buses that have identical
impedances, loss estimates, and line shunt and phase shift active power injections (i.e., they are
identical in the linear network model used by activity RANK) are not all included in the contingency
list. Only one from among such a group of lines is needed. Activity RANK does not check for iden-
tical three-winding transformers connecting the same three buses.
If both overload and voltage depression rankings are being determined in the same execution of
activity RANK, the overload rankings are calculated first and any branch that is identified by the
overload ranker is removed from the contingency list prior to calculating the voltage rankings.
The Contingency Description Data File constructed by activity RANK is a standard source file that
may be edited by the user prior to its being submitted to activity DFAX. Bus identifiers are written
as bus numbers when the numbers input option is in effect, and as extended bus names when the
names input option is in effect (refer to Section 3.3.3 Program Run-Time Option Settings and
activity OPTN). That is, when the Contingency Description Data File built by activity RANK is
submitted to activity DFAX along with the same Subsystem Description and Monitored Element
Data Files that were used by activity RANK, the files are compatible with each other and with the
requirements of activity DFAX (refer to Section 8.1.1 Linear Network Analysis Data Files).
Section 13.3, Estimating Severity Rankings for Single Line Outage Contingencies
Section 10.3, Estimating Severity Rankings for Single Line Outage Contingencies
8.4 Applying the DC Linearized Network Solution

Activity DCLF
Run Activity DCLF - GUI

Power Flow > Linear Network > DC network solution and report (DCLF)…
[DC Network Solution and Report]
Run Line Mode Activity DCLF - CLI
ACTIVITY?
>>DCLF
>>
AB
8.4.1 DC Linearized Network Solutions

During the early stages of the planning process, when identifying feasible, alternative expansion
plans, it may be acceptable to use approximate, computationally more efficient, power flow models.
8-37
Applying the DC Linearized Network Solution Program Operation Manual
For example, in the daily operation of a power system, the user may be presented, from an online
system, a model of the expected load, generation, and transmission system for the day. For this
system condition, the user may want to perform a quick analysis of transfer limits for the base case
and several contingencies. Because the results may go back to the online system, a computation-
ally more efficient model is needed. One very widely used approximation is the linearized or dc
power flow, which converts the nonlinear ac problem into a simple, linear circuit analysis problem.
The advantage of this approach is that efficient, non iterative numerical techniques can be used to
compute an approximate power flow solution. Many alternatives or contingencies can be investi-
gated with the same computer effort that would be expended to calculate one ac power flow
solution.
The dc power flow model is useful for rapid calculation of real power flow. It ignores reactive power
flow and changes in voltage magnitudes, and assumes that, for most circuits, Xij > > rij and the angle
between two buses is small. These assumptions result in the power flow from bus i to bus k simpli-
fying to
i - j
Pij =
Xij
(8.1)
where:
i = Angle at bus i.
j = Angle at bus j.
Xij = Reactance between bus i and bus j.
The power injected into a single bus i is just the sum of the power on all circuits into the bus or
n n
i - j
Pi =  Pij =  Xij
j=1 j=1
(8.2)
shown in matrix form as
[P] = [B][] for a system of n buses.

Note that this equation is linear and that the admittance matrix [B] is sparse because there are only
several transmission lines connected to each bus. The solution of this system of equations can be
accomplished efficiently by the numerical technique of triangular factorization. The power injec-
tions, [P], are known, and the phase angles, [], are computed. After the phase-angle solution has
been determined, the real power flows can be computed using Equation 8.1.
8.4.2 Operation of Activity DCLF

The linearized network solution activity DCLF applies the dc analogy network solution algorithm to
the network modeled in the working case. Optionally, the solution method may also be applied to
that network with the status of a specified ac branch changed. The base case and change case
solutions are tabulated in a single report.
Activity DCLF checks that each non-Type 4 bus is connected back to a Type 3 (swing) bus through
the in-service ac network. If any violations are detected, an appropriate message is printed and
activity DCLF is terminated.
8-38
The largest active power mismatch corresponding to the present ac solution voltage vector in the
working case is calculated and printed. The user may specify that activity DCLF terminates if the
largest mismatch is greater than 0.5 MW.
The user specifies which of the 12 branch rating sets are to be used in tabulating line loading
percentages in the output report. The default is the rating set established as the default rating set
program option (refer to Section 3.3.3 Program Run-Time Option Settings and activity OPTN).
For a change case solution calculation, the user must designate either of the following options:
• a branch where status is to be changed for the change case solution

• a 3-winding transformer where status is to be changed for the change case solution
Data requirements for a non-transformer branch or a two-winding transformer both buses and the
circuit ID. A three-winding transformer is designated by specifying the three buses it connects.
If a branch outage separates the system such that an island with no Type 3 (swing) bus remains,
an appropriate message is printed.
Option Settings and activity OPTN), and either an in-service multi-section line grouping or an in-
service member of such a grouping is specified, the entire grouping is switched (refer to Multi-
Section Line Grouping Data and Section 5.9.1 Equipment Status Changes). If the specified multi-
section line grouping or member is initially out-of-service, activity DCLF does not allow it to be
switched. In outaging a multi-section line grouping, the type codes of the interior dummy buses are
automatically changed as required by activity DCLF.
When the multi-section line reporting option is disabled, neither multi-section line groupings nor its
members may be switched by activity DCLF.
If an out-of-service three-winding transformer is specified as the branch where status is to be

changed, activity DCLF does not allow it to be switched.
The user may elect to include or exclude a loss estimate. See Section 8.4.4, Application Notes for
details on the loss estimate used in the dc power flow.
Adjustable phase shifters are those whose control mode is +3 (active power flow control) or +5
(asymmetric active power flow control). The following options are available for their treatment in the
dc power flow:
• Fixed phase shift angles in the base case and the change case.
• Fixed MW in the base case, and fixed phase shift angles in the change case.
• Fixed MW in the base case and the change case.
The user may process the entire working case or specify subsystem data (refer to Section 4.8
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. Output is generated with
buses ordered as described in Section 4.9 Subsystem Reporting. The user is then given the oppor-
tunity to specify an additional group of buses.
The user specifies the voltage vector to incorporate the phase angle vector calculated for either the
base case or change case dc power flow solution from the following options, saving:
8-39
• Original voltages (default)

• Base case dc power flow voltage angle
• Change case dc power flow voltage angle
If the default is accepted, the voltage vector remains the same as it was prior to performing activity
DCLF, and the following message is printed at the Progress device:
ORIGINAL AC VOLTAGES ARE RETAINED

If either the base case or change case voltage angle is specified, activity DCLF sets the voltage at
each bus to its voltage magnitude as contained in the working case at a phase angle corresponding
to its phase angle in the selected dc solution. An appropriate message is printed:
PHASE ANGLES ARE SET TO THOSE OF THE BASE CASE DC LOAD FLOW SOLUTION
or:
PHASE ANGLES ARE SET TO THOSE OF THE CHANGE CASE DC LOAD FLOW SOLUTION
If no change case solution is calculated, the first two options incorporate phase angles as deter-
mined by the base case dc solution.
Finally, if the change case solution option was enabled, the branch or multi-section line grouping
where status was changed for that solution may be either returned to its original status or left with
its modified status.
The user may specify that the changed status of the branch or 3-winding transformer be saved.
Otherwise, the original status is restored. The following example is printed at the Progress tab for
activity DCLF with original voltages retained.
The working case has a largest mismatch of 0.02 MW at bus 205 [SUB230 230.00]
Circuit "1" from 151 [NUCPANT 500.00] to 152 [MID500 500.00] is presently in-service
Status of circuit "1" from 151 [NUCPANT 500.00] to 152 [MID500 500.00] is set to
out-of-service
Output completed
Original ac voltages are retained
Original branch status is restored
Figure 8-3. Output from Activity DCLF
Activity DCLF may be terminated by entering the AB interrupt control code.

The general form of the output report of activity DCLF is similar to that of activity LOUT. Figure 8-3
shows an example of the output of activity DCLF.
The bus information presented includes the number of the area in which the bus is located, the bus
voltage phase angles for the base case and change case dc power flow solutions, generator MW,
and load MW. The value printed as load includes the active power components of all in-service fixed
8-40
bus shunts, all in-service loads, and all in-service induction machines connected to the bus on the
basis of the voltage magnitude at the bus at the time activity DCLF is initiated.
For any induction machine, dc line, or FACTS device that has its ac powers set to zero (e.g., if the
case had just been read with activity section / READ and no ac power flow solution attempted), an
estimate of its power withdrawn from the network is used based upon its scheduled power or
current. Otherwise, regardless of the quality of the ac solution upon entry to activity DCLF, the
powers contained in the working case are used.
The star point buses of three-winding transformers (refer to Transformer Data) are not reported by
activity DCLF.
Output for FACTS devices and dc lines appears on the right side of the bus output block as the first
line or lines of branch data (i.e., before output for ac branches).
For non-transformer branches and for two-winding transformers listed, the number, name, base
voltage, and area of the to bus is printed, along with the circuit identifier; for three-winding trans-
formers, the output line contains the string 3WNDTR in the bus number column, the transformer
name in the bus name column, and the winding number in the base voltage column, followed by the
transformer circuit identifier; if the three-winding transformer to bus reporting option is enabled, two
additional lines, containing the bus numbers, names, and base voltages of the two buses connected
to the from bus by the three-winding transformer, are printed, followed by the number of the area in
which the to bus is located. The active power flowing into the line at the from bus and the corre-
sponding percentage of the selected rating are printed for both the base and change case dc
solutions. The selected line rating and the difference in line flow between the base case and change
case solutions are also tabulated.
If the current execution of activity DCLF included only a base case dc solution, the change case
columns of the report are blank. If a change case solution was calculated, a description of the
change case is included in the banner at the top of each page of output. In addition, in the bus output
block for the from and to buses of the branch where status was changed, the branch output line for
this branch is preceded by the character string --->.
If the change case is a line outage that results in the creation of an island without a swing bus,
change case phase angles and line flows from within the swingless island are not tabulated; dashes
are printed in the output report where these values would normally be shown.
Option Settings and activity OPTN), the interior dummy buses of multi-section line groupings (refer
to Multi-Section Line Grouping Data) are not reported. In reporting branches, the far end to bus
(rather than the closest dummy bus) of each multi-section line connected to the from bus is shown
as its to bus. Multi-section lines are identified with an ampersand ( & ) as the first character of their
line identifiers in the branch circuit identifier column (e.g., &1).
8-41

Activity DCLF provides only approximate power flow solutions. The simplified branch flow equations
on which its algorithm is based inherently result in phase angles and branch flows that are different
from the ac power flow solution, even when the starting point is a fully solved power flow case.
Furthermore, they lead to the assumption that bus voltage magnitudes and line losses remain
constant as a branch is placed in- or out-of-service. It has the advantage, though, that it is substan-
tially faster than a full ac power flow solution. Thus, its proper role is that of a screening tool to
indicate which cases deserve further attention.
The linearized or dc power flow model used by activity DCLF approximates the nonlinear ac power
flow with a simplified non-iterative calculation. In this method, the matrix equation:
[P] = [B] []

expresses net bus power injections as linear functions of bus phase angles.
For any induction machine, dc line, or FACTS device that has its ac powers set to zero (e.g., if the
case had just been read with activity READ and no ac power flow solution attempted), an estimate
of its power withdrawn from the network is used based upon its scheduled power or current. Other-
wise, regardless of the quality of the ac solution upon entry to activity DCLF, the powers contained
in the working case are used.
The line loading percentages tabulated in activity DCLF should be used with caution because reac-
tive power flows are neglected in the dc analogy solution. These percentages are calculated based
only on the MW loading of the line as determined by the dc analogy solution; activities such as
POUT, LOUT and RATE calculate their line loading percentages based upon both the active and
reactive power loading of each branch as determined from a full ac power flow solution.
The active power components of any line connected shunts in the working case are treated in the
same manner that bus shunts are as far is the dc network solution is concerned (refer to
Section 8.4.3 Output Report Format). In the output of activity DCLF, they are reported as part of the
line flow rather than as load at the bus; that is, they are reported in the same manner as for ac solu-
tions. If the change case is a branch outage, its line shunts are removed from the solution along
with the branch. If the change case places a branch in-service, its line shunt components are not
added with the branch.
The mathematics of a standard dc analogy network solution neglects line losses. That is, in applying
such a method, generation and load exactly balance. Activity DCLF, on the other hand, approxi-
mates the effect of line losses on its dc analogy solutions with the following approach for each
branch: From the voltage vector in the working case, it calculates the losses on the branch. Then,
during its network solutions, activity DCLF injects as load the line losses at the sending end of the
branch, as determined from the initial voltage vector.
In the output report, these loss injections are not included in the bus loads tabulated. Rather, their
effect is included in the line flows printed for each branch. Thus, instead of having equal flows with
opposite signs at the two ends of a branch, these flows as tabulated by activity DCLF differ by the
line loss estimate.
The same loss estimate vector is used in both the base case and change case dc analogy solutions.
If the change case is a branch outage, its loss estimate is not removed from the solution along with
the branch; it remains as an invisible load at the sending end bus described above. If the change
case places a branch in-service, no loss estimate is added with the branch.
8-42
Program Operation Manual Calculating Linearized Network Contingency
If the multi-section line reporting option is enabled (refer to Section 3.3.3 Program Run-Time Option
Settings and activity OPTN), the losses from the members of each in-service multi-section line are
calculated as electrical equivalents at its endpoint buses. Thus, if the change case calculation is the
outaging of a multi-section line, all of its losses remain as invisible load.
Similarly, any loss estimate that would normally be injected at the star point bus of a three-winding
transformer are calculated as electrical equivalents at its endpoint buses, and remain as invisible
load if the change case calculation is the outaging of a three-winding transformer.
From the foregoing discussion, then, it is strongly recommended that, when using activity DCLF to
check branch outage cases, the working case be solved to an acceptable mismatch tolerance with
a full ac solution prior to initiating activity DCLF. While it does not require a solved system condition,
the only time an unsolved starting point should be provided is in using activity DCLF as a bootstrap
to obtain an estimate of phase angles for a full ac power flow solution.
PSS®E GUI Users Guide, Section 13.5, Running the DC Linearized Network Solution
Section 10.4, Running the DC Linearized Network Solution
8.5 Calculating Linearized Network Contingency

Activity DCCC
Run Activity DCCC - GUI

Power Flow > Linear Network > DC contingency checking (DCCC)…
[DC Contingency Checking]
Run Line Mode Activity DCCC - CLI
ACTIVITY?
>>DCCC

AB
The previous section on the dc network solution process described the means by which a linearized
base case solution could be obtained along with one change case. Such a change case could be
considered a contingency. The linearized network contingency calculation activity DCCC estimates
the flows on a set of monitored elements for the base case and for a specified set of contingency
cases. Either an overload report or a loading table giving results of each case may be tabulated.
The user specifies solution and output control parameters for the following:
8-43
Calculating Linearized Network Contingency Program Operation Manual
Table 8-2. Linearized Network Contingency Options

MW mismatch exceeds
0.5 MW mismatch tolerance, the user may terminate activity DCCC.
tolerance
The user can modify tolerance in steps of 0.1.
activity The contingency case rating set, and the percentage thereof,
OPTN define the line loading limits used in determining overloads.
Percent of rating 100 lished by the program option setting (refer to Section 3.3.3
Program Run-Time Option Settings and activity OPTN).
If enabled, ratings of monitored branches are converted to
Convert ratings to esti- estimated MW ratings based upon each monitored line’s
disabled
mated MW ratings Mvar loading at the metered end in the base case ac
solution.
The line flow code defines the base flow to be used in deriving
dc base contingency case flow estimates.
Line flow code
case • dc base case
• ac base case
The loss estimate code allows the user to either include or
Loss estimate code include exclude a line loss estimate calculated from the present voltage
vector.
The regulating phase shifter code defines the treatment of these
devices in the base case and contingency case dc power flow
solutions.
Fixed
Regulating phase shifter • Fixed angles in the base case and contingency cases.
phase shift
code
angles • Fixed MW in the base case, fixed angles in the contingency
cases.
• Fixed MW in the base case and contingency cases.
The output code allows the user to select either an overload
Output code Summary
summary report (Summary option) or a loading table (Full option).
Overloaded branches in contingency cases for which contin-
Minimum flow change in gency case flows differ from their base case flows by less than the
1.0
overload report minimum contingency case flow change parameter are omitted
from the summary overload report.
Exclude cases with no
If enabled, those cases for which no overloads are detected are
overloads from overload disabled
omitted from the summary overload report.
report
8-44
Table 8-2. Linearized Network Contingency Options (Cont.)

The user must enter the name of a Distribution Factor Data File
constructed by activity DFAX that corresponds to the network condition
contained in the working case (refer to Section 8.1.7 Application
Notes) and to the desired Linear Network Analysis Data Files (refer to
Section 8.1.1 Linear Network Analysis Data Files). The Distribution
Factor Data File must specify at least one monitored branch or inter-
File
face. The bus input option (refer to Section 3.3.3 Program Run-Time
Option Settings and activity OPTN) must have the same setting that
was in effect when activity DFAX filled the specified file. Refer to
Section 2.4.1 File Usage for the file specification conventions used by
activity DCCC.
8.5.1 Operation of Activity DCCC

Activity DCCC verifies that generators are not converted (refer to CONG) and that each non Type 4
bus is connected back to a Type 3 (swing) bus through the in-service ac network. If any violations
are detected, an appropriate message is printed.
Activity DCCC calculates and prints the largest active power mismatch corresponding to the present
ac solution voltage vector in the working case.
The Distribution Factor Data File is read, and, if the convert ratings option was enabled at the start
of activity DCCC, ratings from the selected rating set of those monitored branches having a non-
zero rating are modified. For each such branch, the reactive power loading is calculated and a MW
rating is determined under the assumption that the reactive power loading is unchanged under
contingency conditions.
Finally, the base case dc power flow solution is calculated followed by the processing of the desig-
nated contingency cases. If a line outage contingency forms an island with no Type 3 (swing) bus,
a singular sub-matrix is formed. Such islands are omitted from the network solution of activity
DCCC.
Activity DCCC may be terminated by entering the AB interrupt control code.
Two different output reports may be produced by activity DCCC: an overload report and a loading
table.
8-45
8.5.2 Overload Report

In the overload report, each network condition (i.e., the base case and each contingency case) is
reported immediately after its calculation. A branch or interface is reported if the following conditions
are satisfied:
• Its rating from the selected rating set is nonzero.

• Its loading estimate exceeds the specified percentage of the selected rating.
• For contingency cases, the difference in loading between the base and contingency
cases exceeds the minimum contingency case flow tolerance.
For each monitored element printed, the pre-contingency and post-contingency MW loadings, the
rating and the post-contingency percent loading are listed. Any monitored branch that is located in
a swingless island, as well as any interface that includes such a branch as a member, is omitted
from the overload report.
For three-winding transformer windings, flow estimates are calculated at the winding bus end as
power flowing into the transformer. For other ac branches, flow estimates are calculated at the
metered end in the from bus to to bus direction. The flow across an interface is taken as the sum of
the flows of its members. For three-winding transformer windings, the flow is calculated at the
winding bus as power flowing into the transformer. For other members, the flow is calculated at its
metered end in the from bus (i.e., the first bus specified in entering the branch; refer to Monitored
Element Data File Contents) to to bus direction.
Element Data File, or in ascending numerical or alphabetical order, according to the option selected
during the execution of activity DFAX (refer to Section 8.1.6 Operation of Activity DFAX). These are
followed by the interfaces in the order in which they were specified.
If the convert ratings option was selected at the start of activity DCCC, the values printed as line
ratings are the estimated MW ratings; otherwise, the ratings as contained in the working case are
printed. In either case, the values printed are not modified by any percentage of rating parameter
specified at the start of activity DCCC.
An example dc contingency check run using the savnw.sav, savnw.sub, savnw.mon and savnw.con
files will produce the Overload/ Summary Report (see Figure 8-4).
It can be seen that four contingencies result in overload conditions. The description of the contin-
gencies are listed at the left hand side of the report. The lines and interfaces that are subjected to
overload conditions during each listed contingency are centered. At the right of the table, under the
Name of the contingency condition, the following are listed:
• Pre-contingency power flow

• Post contingency power flows
• Rating and percent loading based on that rating
8-46
Figure 8-4. Summary Contingency Report from the DC Contingency Checking Process
8-47
8.5.3 Linear Network DC Loading Report

In the loading table, results are reported in tabular form with four contingency cases per table. Each
group of contingency cases contains a page summarizing the contingency cases performed. For
each contingency, the contingency label and the events defining the contingency are listed. The
contingency case summary page is followed by the loading table. For each monitored element, this
table lists its rating, MW loading and percentage loading in the base case network solution, and the
MW and percentage loadings for each of the contingency cases reported. Percentage loadings are
shown as positive numbers. Any percentage loading above the specified percentage threshold is
followed by an asterisk (  ). Any monitored branch that is located in a swingless island, as well as
any interface that includes such a branch as a member, has dashes printed in place of its flow in
the loading table.
An example dc contingency check run using the savnw.sav, savnw.sub, savnw.mon and savnw.con
files will produce the Loading Report partially shown in Figure 8-5.
It should be noted that the cases marked with an asterisk, are summarized on the overload report
typical of which is that shown in Figure 8-4.
Any monitored branch that is located in a swingless island, as well as any interface that includes
such a branch as a member, has dashes printed in place of its flow in the loading table.
8.5.4 Contingency Case Flow Calculations

One of two calculation sequences is used for calculating monitored element flow estimates for each
contingency case. For contingency cases involving no line closure contingency events, no three-
winding transformer outages, and no more than two line outage contingency events, the following
calculations are performed:
1. The contingency case flow estimates are initialized to either the flows given by the base
case dc network solution or the base case ac flows from the working case, according to the
line flow code solution parameter set at the start of activity DCCC (see above).
2. If any bus boundary condition contingency events have been specified as part of the contin-
gency case, the incremental form of the dc power flow equation
[P] = [B] []

is solved for the corresponding phase angle changes, and the resulting incremental line
flows are calculated and added to the contingency case flow estimate vector initialized in
(1).
3. If one (or two) line outage contingency events have been specified as part of the contin-
gency case, the corresponding vector(s) of line outage distribution factors is (are) retrieved
from the Distribution Factor Data File. The contingency case flow estimate vector is updated
using the formula in Section 8.2.3 Application Notes to reflect the first (or only) line outage.
4. If two line outage contingency events have been specified as part of the contingency case,
the vector of distribution factors for the second outage is updated to reflect the prior outage
of the branch processed in (3). The contingency case flow estimate vector is again updated
using the formula in Section 8.2.3 Application Notes to reflect the second line outage.
For contingency cases involving either line closure contingency event(s), three-winding transformer
outages, or more than two line outage contingency events, full dc network solutions are calculated.
If the line flow code solution parameter was set to dc base case at the start of activity DCCC (see
8-48
Program Operation Manual Performing DC Corrective Action Analysis
above), contingency case flows are taken as those from the contingency case dc network solution;
if the line flow code was set to ac base case, the changes in flows between the base case and
contingency case dc network solutions are added to the base case ac flows to establish the contin-
gency case flow estimates.
In applying the first method described above (the distribution factor method) for contingency cases
involving two line outages, if the simultaneous outages create a swingless island that neither of the
two outages individually creates, the distribution factor method is abandoned and the second
method described above, the full dc network solution, is used.
In either of the two calculation methods, whenever a line outage contingency results in the presence
of a swingless island, an appropriate message is printed prior to calculating the contingency case
flow estimates.

Activity DCCC uses the same linearized network model as is used in the dc analogy network solu-
tion method of activity DCLF. Thus, the comments in Section 8.4.4 Application Notes apply here as
well. Note, in particular, the approximate nature of the linearized network model used by activity
DCCC. The proper role of activity DCCC, therefore, should be to focus attention on those system
conditions that deserve more detailed study.
Activity DCCC detects the specification of duplicate single and double line outage contingencies
and calculates the contingency case solution only for the first specification of such a contingency.
Any contingency cases involving bus boundary contingency events, line closure contingency
events, or more than two line outage contingency events are not checked for duplication.
If the convert ratings code is set to one at the start of activity DCCC, any percentage of rating param-
eter is applied after the conversion to estimated MW ratings. Interface ratings are not affected by
the convert ratings solution parameter.
Line loss estimates and line shunts of outaged lines are handled as in activity DCLF (refer to
Section 8.4.4 Application Notes).
It is required that the working case be solved to an acceptable mismatch tolerance prior to entering
activity DCCC.
®
PSS E GUI Users Guide, Section 13.6, Calculating Linearized Network Contingency
Section 10.5, Calculating Linearized Network Contingency
8.6 Performing DC Corrective Action Analysis

Activity DC Corrective Action Analysis
8.6.1 About DC Corrective Action Analysis

The mathematical model is presented in Section 6.11 AC Corrective Actions. The dc corrective
actions algorithm differs from that in the ac corrective actions in that it represents the transmission
system by means of a linear model. Control adjustments are computed using a linear programming
algorithm, for which this objective is to minimize the cost of generation re-dispatch, phase-shifter
angle changes and load shedding. DC corrective actions focus on branch and interface overloads,
8-49
Performing DC Corrective Action Analysis Program Operation Manual
and MW flows are used to determine circuit loadings. Bus voltage constraints are not taken into
account in dc corrective actions. DC corrective actions use the same weighting functions for MW
generation, phase angle, and load curtailment as discussed in ac corrective actions (see
Section 6.11.2 Weighting and Penalty Functions). The penalty functions for soft constraints for
branch flows and interface flows are also the same as those discussed in ac corrective actions.
8.6.2 Operation of DC Corrective Actions

DC corrective actions computation represents the transmission system by means of a linear model,
and is modeled as an optimal power flow problem solved with a linear programming method. It iden-
tifies the necessary adjustments to loads, phase-shifter angles and active power generations to
eliminate branch loading violations.
Table 8-3. DC Corrective Actions Options

Enable to terminate dc corrective action analysis if the largest
Abort if MW mismatch initial active power mismatch exceeds the specified Initial Condi-
disabled
exceeds tolerance tion MW Mismatch Tolerance. If disabled, continue to perform dc
corrective action analysis with out-of-tolerance mismatch.
Initial condition MW
0.50 MW mismatch tolerance, dc corrective action analysis may be
mismatch tolerance
terminated.
Enable to modify generation, load and phase shifter angle to
Modify network data with incorporate adjustments of control components involved in correc-
enabled
corrective action solution tive actions and modify bus voltages to incorporate bus voltage
phase angle vectors calculated from corrective actions.
Select branch flow rating set and limit tolerance for monitored
Constraint options
branches and interfaces.
activity
Rating Define branch rating set and percent of rating. The limits are equal
OPTN
to the specified rating multiplied by percent of flow rating.
Percent of flow rating 100.0%
If enabled, ratings of monitored branches are converted to esti-
Convert ratings to esti-
disabled mated MW ratings based upon each monitored line's MVAR
mated MW ratings
loading at the metered end in the base case ac solution.
Specify branch loading limit tolerance for adjustment of load limits
to be used in linear programming engine. For example, if the toler-
Branch overload violation ance is 0.1% and the selected flow rating is 100% of Rate A, the
0.10%
tolerance linear programming algorithm will consider the solution feasible if
the loading of a branch has been reduced within 100.1% of the
rating.
Select types of control adjustments and specify weighting factors
Control options for each type (see Section 6.11.3 AC Corrective Action
Options).
The Distribution Factor Data File is used to define branch and interface flow
constraints and control subsystems. When creating a Distribution Factor Data
Input Data File
File for dc corrective action, a Contingency Description Data File that specifies
no contingencies is allowed.
8-50
Program Operation Manual Performing DC Corrective Action Analysis
8.6.3 DC Corrective Action Results

After a dc corrective actions solution is performed successfully, the program lists monitored
branches that are overloaded, before and, if any, after the corrective actions solution. In the second
part of the report, initial and new values of the controls, as well as changes in controls are reported
also. Figure 8-5 is the sample result of dc corrective actions applied to an example system. Two
branches and an interface flow overloads in the working case are removed by corrective actions,
which involve the adjustments of the phase shifter between buses 203 and 202, and generation at
two generator buses.
8-51
Performing DC Corrective Action Analysis Program Operation Manual
Figure 8-5. Sample Output of DC Corrective Action Analysis
8-52
Program Operation Manual Calculating Transmission Interchange Limits

The corrective actions solution algorithm does not place a limit on the number of controls and
constraints that can be modeled. The computation time of a corrective actions solution is approxi-
mately proportional to the number of constraints. Because local controls are generally more
effective in removing violations, it may be preferable to choose the subsystem in which control
actions are allowed to be the same as that in which elements are monitored.
Operating limit violations caused by incorrect limit settings may have a significant impact on the
optimal solution found. Hence, suspicious limits should be verified and corrected, if necessary, or
even removed from the solution.
Two methods can be used to excluded controls from the corrective actions solution. One way is to
set the upper and lower limits of a control equal; another is to carefully define the control subsystem
to exclude those controls that are not desired in a particular application.
®
PSS E GUI Users Guide, Section 13.7, Running DC Corrective Action Analysis
Section 10.5, Calculating Linearized Network Contingency
8.7 Calculating Transmission Interchange Limits

Activity TLTG
Run Activity TLTG - GUI

Power Flow > Linear Network > Transmission interchange limits calculation (TLTG)…
[Transmission Interchange Limits Calculation]
Run Line Mode Activity TLTG - CLI
ACTIVITY?
>>TLTG
AB
8.7.1 Overview: Transmission Transfer Limit Analysis

In the day-to-day operation of interconnected networks, bulk power transfer is often constrained by
the ability of transmission elements to withstand thermal effects for various normal and contingency
conditions. More recently this bulk power transfer is often constrained by stability limits. If sufficient
stability analysis has been performed, megawatt limits can be assigned to elements or groups of
elements. Because the transfers of power amount to thousands of megawatts for many hours in
every single day, the determination of the ability of the transmission system to support the power
transfers is a vital consideration to assure that the interconnected network is operated in a secure
and reliable manner.
As shown in Section 8.4.1 DC Linearized Network Solutions a dc technique gives a quick solution.
A common approach used to find a limiting solution is to start with a base case and calculate the
8-53
Calculating Transmission Interchange Limits Program Operation Manual
sensitivity of flow in monitored elements or groups of elements to a variation in interchange. This

technique is often referred to as a distribution factor technique. When the sensitivity of elements is
known, linear projections can be used to estimate permissible interchanges based on thermal limits.
P1, P2 and P3 represents linear line flow functions of the net import. The horizontal line rating inter-
sects P1 imposing a limit or net import restriction. Figure 8-6 graphically shows this technique.
Figure 8-6. Linear Projection Technique Used in Transfer Limit Analysis
8.7.2 Calculating Transmission Transfer Limits

The transmission interchange limit analysis activity TLTG estimates the import or export limits of a
specified subsystem of the working case using a linearized network model. The user designates
this study system in which the total power injection is to be increased (for export limits) or decreased
(for import limits). An opposite change in the total power injection is made in a designated opposing
system. The calculation uses the sensitivity type analysis described in Section 8.7.1 Overview:
Transmission Transfer Limit Analysis.
Power transfer distribution factors relating changes in branch and interface flows to a change in
study system interchange are determined. The maximum study system export or import is then
derived by extrapolation subject to the constraint that no monitored elements exceed a specified
percentage of a selected rating.
This process may then be repeated for a designated set of user specified contingency cases.
The process will perform all the contingencies identified in the contingency description file
processed when building the distribution factor file. Furthermore, the process uses the monitored
list file, which allows the lines to be monitored and interfaced. This feature is important because
these interfaces often define stability limits.
Note that any two subsystems identified in the *.sub file can be used for the transfer analysis.
Furthermore, however, it should be noted that the limits will be found based on only those elements
(lines and interfaces) that are monitored, i.e., included in the *.mon file.
8-54
In Figure 8-7 It can be seen that Areas A and C form the study and opposing system, respectively.
Transfers take place directly and via Area B. It is important therefore to monitor lines within Area B
or interfaces between Area B and the other two areas to ensure that the correct limits are identified.
Figure 8-7. Study System (A) and Opposing System (C). Area B Potentially Limiting
8.7.3 Transmission Transfer Limit Analysis Options

The user specifies solution and output control parameters for the following:
Table 8-4. Transmission Transfer Limit Analysis Options

Largest initial active power mismatch. Note that the user can
modify the tolerance in steps of 0.1.
Abort if MW mismatch Enable or disable termination of activity TLTG if mismatch toler-
enabled
exceeds tolerance ance exceeded.
Base case rating The base case and contingency case rating sets, and the
activity percentage thereof, define the line loading limits used in deter-
OPTN mining overloads.
The user specifies the rating; the default rating set is established
by the program option setting (refer to Section 3.3.3 Program
Percent of rating 100 Run-Time Option Settings and activity OPTN).
disabled mated MW ratings based upon each monitored line’s reactive
mated MW ratings
power loading at the metered end in the base case ac solution.
Line flow code
• ac base case
If set to Regulate (in base case), any regulating phase shifter
where adjustment control mode CODn (refer to Transformer
Data) is set to +3 holds its base case flow in all base case shift
Phase shifter in base case Lock solutions.
If set to Lock, all phase shift angles are locked at their base case
settings.
8-55
Table 8-4. Transmission Transfer Limit Analysis Options (Cont.)

If set to Include, both base case and contingency case flow
constraints are recognized in calculating the pre-contingency
Base case constraints in interchange limits for each contingency case.
Ignore
contingency case
If set to Ignore, only the contingency case loadings are consid-
ered (refer to Section 8.7.8 Application Notes).
Add study system ties to If enabled, automatically include study system tie lines as
disabled
monitored lines monitored elements.
Minimum contingency case Provide the means to ignore those monitored elements
pre-shift flow change 1.0 that, in a contingency case, are not significantly affected by
the contingency. If the magnitude change in pre-shift flow
from the base case value is less than the minimum flow
change threshold and the magnitude change in the power
Minimum contingency case transfer distribution factor from the base case value is less
0.0000
distribution factor change than the distribution factor change threshold, the monitored
element is ignored.
If the value entered is positive, export limits are to be determined;
otherwise, import limits are to be calculated.
The generation shift is apportioned among generator and load
buses in the study system in proportion to the participation factors
specified in the participation block structure of the Subsystem
Description Data File (refer to Section 8.1.2 Subsystem
Description Data File Contents). If no participation block was
entered for the study system, the generation shift is shared
among generator buses in proportion to their plant MBASEs (i.e.,
the sum of the MBASEs of in-service machines with positive
Study system generation active power output at the bus). In this case, there must be at
100
shift least one in-service machine with a positive MBASE in the
subsystem. The opposite generation shift is applied to buses in
the first opposing system, again according to their participation
factors or MBASEs.
Using the incremental form of the dc power flow equation (refer to
activity DCLF) and the power shift vector, phase angle changes
are calculated, followed by incremental line flows for all monitored
lines and interfaces. These are transformed into a vector of base
case power transfer distribution factors, and the interchange limit
is determined by extrapolation such that all monitored elements
satisfy their rating constraints.
Study System: network subsystem in which the total power injec-
tion is to be increased (for export limits) or decreased (for import
Subsystem selection limits). The choices available are those listed in the *.sub type file.
Opposing System: network subsystem in which an opposite
change from that in the Study System is made.
Threshold value, number of monitored elements in the
Maximum import / export 99999
summary report.
Threshold value for summary report. For small distribution
Minimum distribution factor
0.0 factors with levels below this threshold there will be no
magnitude
reporting for the related element.
8-56
Table 8-4. Transmission Transfer Limit Analysis Options (Cont.)

Maximum time report same Threshold value for summary report limiting the number of
5
element times an element is reported in the same report.
Defines the manner in which contingency cases are identified in
the summary report as one of the following:
Contingency descriptions Events • 32-character contingency case label
• events comprising the contingency case
• both contingency label and the contingency events
List study system buses disabled If enabled, list Study System buses in output report.
List opposing system buses disabled If enabled, list Opposing System buses in output report.
List study system tie lines disabled If enabled, list Study System tie lines in output report.
Summary: summary report of all cases considered
Output code Summary Full: monitored element flow table for each case considered
followed by a summary report of all cases considered (refer to
Section 8.8.5 Output Report Format)
Incre- Incremental: incremental transfer capability
Interchange limit output
mental Total: total transfer capability
Limit the flow table for each case reported to the < n > most
Elements in flow tables 60000
restrictive monitored elements.
If enabled, apply the minimum distribution factor magnitude
Apply summary minimum threshold for including monitored elements in the summary
disabled
distribution factor to report report to the monitored element flow table of each case
reported when full output is selected.
Summary report is repeated with interface transfer limits
and distribution factors for a selected interface listed rather
than study system transfer limits and distribution factors.
Optional Interface Output NONE
The interface distribution factors listed on the interface
summary report are measures of the changes in monitored
element flows to a change in base case interface flow.
8.7.4 Operation of Activity TLTG

Activity TLTG checks that generators are not converted (refer to CONG) and that each non-Type 4
are detected, an appropriate message is printed and activity TLTG is terminated.
ORDR is automatically executed. Next, activity TLTG calculates and prints the largest active power
mismatch corresponding to the present ac solution voltage vector in the working case.
The user may specify that activity TLTG be terminated (default) if this largest mismatch is greater
than the MW mismatch tolerance.
8-57
TLTG.
The user must specify the study and opposing systems. If no subsystems are defined, an appro-
priate error message is printed and activity TLTG is terminated. If only one subsystem was
specified, the specified subsystem is taken as the study system while the remainder of the working
case is treated as the opposing system. If two subsystems were specified, the default opposing
system is bypassed.
Activity TLTG ensures that there are no buses that are members of both of the selected subsys-
tems. If any such buses are found, they generate an alarm and activity TLTG is terminated.
working case is calculated and printed.
If the convert ratings option was enabled at the start of activity TLTG, ratings from the selected rating
set(s) of those monitored branches having non-zero rating(s) are modified. For each such branch,
the reactive power loading is calculated and MW rating(s) are determined under the assumption
that the reactive power loading is unchanged under power transfer and contingency conditions.
Using the incremental form of the dc power flow equation (see Section 8.4.1 DC Linearized Network
Solutions) and the power shift vector, phase angle changes are calculated, followed by incremental
line flows for all monitored lines and interfaces. These are transformed into a vector of base case
power transfer distribution factors, and the interchange limit is determined by extrapolation such
that all monitored elements satisfy their rating constraints.
The base case dc network solution is calculated and the solution summarized as in the following
example:
STUDY SYSTEM GENERATION IS 1500.0 MW

OPPOSING SYSTEM GENERATION IS 1748.9 MW
STUDY SYSTEM NET INTERCHANGE IS 282.8 MW
The user may specify a study system generation shift (default = 100). If the value entered is positive,
export limits are to be determined; otherwise, import limits are to be calculated.
The generation shift is apportioned among generator and load buses in the study system in propor-
tion to the participation factors specified in the participation block structure of the Subsystem
Description Data File (refer to Section 8.1.2 Subsystem Description Data File Contents). If no partic-
ipation block was entered for the study system, the generation shift is shared among generator
buses in proportion to their plant MBASEs (i.e., the sum of the MBASEs of in-service machines with
positive active power output at the bus). In this case, there must be at least one in-service machine
with a positive MBASE in the subsystem. The opposite generation shift is applied to buses in the
opposing system, again according to their participation factors or MBASEs. Using the incremental
form of the dc power flow equation (refer to Sections 8.4.4 and 8.5.4) and the power shift vector,
phase angle changes are calculated, followed by incremental line flows for all monitored lines and
interfaces. These are transformed into a vector of base case power transfer distribution factors, and
the interchange limit is determined by extrapolation such that all monitored elements satisfy their
rating constraints.
8-58
The base case solution is then reported, followed by processing of the designated contingency
cases with contingency case flow estimates calculated using the methodology defined in Contin-
gency Case Flow Calculations. Prior to terminating, an ordered summary report from among all the
cases calculated is tabulated (refer to Section 8.7.6 Output Report Format).
The user may specify having the summary report repeated with interface transfer limits and distri-
bution factors for a selected interface listed rather than study system transfer limits and distribution
factors. The interface distribution factors listed on the interface summary report are measures of the
changes in monitored element flows to a change in base case interface flow.
In listing study system buses, opposing system buses, and study system tie lines, the tabulation
may be terminated by entering the AB interrupt control code. In this case, the interrupt is cleared
and processing continues. After the interchange limit calculations have started, activity TLTG may
be terminated by entering the AB interrupt control code.
8.7.5 Analyzing Transfer Limit Results

The results of running an example case will be presented to assist in understanding the report
format. The example will be based on the files available in the PSS®E EXAMPLE directory; those
being:
• savnw.sav – the power flow case

• savnw.sub – subsystem definitions
• savnw.con – contingency description file
• savnw.mon – the monitored element file
To further help clarify the power flow condition, Figure 8-8 shows the inter-area flows and the
Subsystem Description file, savnw.sub. There it can be seen that the subsystem named STUDY
comprises Area 1 of the power flow case and the subsystem named EAST comprises Area 2.
Furthermore, Area 1 has a net export of 131 MW + 148 MW; a total of 279 MW
savnw.sub file Inter-Area Flows in Base Case
Figure 8-8. Subsystem file and Power Flow Condition for Transfer Analysis
8-59

In reporting the base case solution, activity TLTG lists the study system generation, the opposing
system generation, and the study system net interchange corresponding to the network solution
before and after applying the generation shift. This is followed by a tabulation of the pre-shift and
post-shift generation at those study system and opposing system buses participating in the gener-
ation shift. Loadings on monitored elements are then reported, sorted such that the most restrictive
elements are listed first. Either incremental or total pre-contingency transfer limits, as appropriate,
are listed.
For monitored three-winding transformer windings, flow estimates are calculated at the winding bus
end as power flowing into the transformer. For other monitored branches, flow estimates are calcu-
lated at the metered end in the from bus to to bus direction. The flow across an interface is taken
as the sum of the flows of its members. For three-winding transformer windings, the flow is calcu-
lated at the winding bus as power flowing into the transformer. For other members, the flow is
calculated at its metered end in the from bus (i.e., the first bus specified in entering the branch; refer
to Monitored Element Data File Contents) to to bus direction.
Flow estimates are listed for each of three interchange schedules: with the original generation
profile, with the specified generation shift, and at the generation shift corresponding to the transfer
level limit required for the most restrictive monitored element (i.e., the one listed first). Any flow at
or above the selected percentage of the appropriate rating is followed by an asterisk (  ). The
power transfer distribution factor relating the change in flow on the monitored element to a change
in study system net interchange is also tabulated, along with the rating of the monitored element;
for branches, this is not the percentage of the rating used in determining the interchange limit, but
either the value of rating as entered in activities such as READ, TREA, RDCH, CHNG or the [Spread-
sheet], or, if the convert ratings option was selected at the start of activity TLTG, the estimated MW
ratings.
When reporting flows for contingency cases, the events comprising the contingency are listed
followed by flows on the monitored elements sorted as described above. The flow table includes
both the contingency case flows in the same form as the base case report described above, as well
as the base case flows at the transfer level required for the most restrictive monitored element. Note
that if the ignore base case constraints in contingency cases option was specified, only the contin-
gency case constraints are considered in calculating the transfer limit; in this case, base case flows
at the transfer limit may be shown as overloaded because the corresponding constraints are
ignored in the transfer limit calculation.
A summary report tabulates the number of system condition solutions attempted and the number
for which there exists no interchange schedule at which the rating constraint can be satisfied for all
monitored elements (refer to Section 8.7.8 Application Notes). This is followed by a tabulation of
monitored elements for all system conditions that were calculated, in order of increasing incre-
mental or total transfer capability, as appropriate. The limiting element is listed along with its power
transfer distribution factor, its pre-shift contingency case flow, its rating, and a description of the
system condition.
Only those monitored elements satisfying the cutoff threshold solution parameters set at the start
of activity TLTG are included in the summary. After an element has been listed the maximum
number of times < n >, its nth occurrence includes an asterisk (  ) before its description, and further
reporting of the element is suppressed.
This summary report is reprinted for each selected interface with interface transfer limits and distri-
bution factors rather than study system interchange limits and distribution factors tabulated. All
distribution factors on the interface transfer limits summary report describe changes in monitored
8-60
element flow relative to a change in interface flow. The branches that form the interface are listed
on the first page of an interface’s transfer limit summary report.
The final page of the summary report lists those elements that were reported < n > times, sorted by
the number of times they would have been reported.
disconnected. Any monitored branch that is located in the swingless island, as well as any interface
that includes such a branch as a member, has dashes printed where its contingency case results
would normally be printed.
Figure 8-10 shows the report obtained using the example files (savnw.*) from which was built the
dc-contingency.dfx distribution factor file. The filenames are listed in the report as shown.
The pre- and post-shift generation levels and the net interchange are listed for the Study and
Opposing systems. In this example, a shift of 100 MW is assumed. The generators that participate
in both systems to make the + 100 MW shift are listed. They are the nuclear plants at buses 101
and 102 in the Study system and the generators at buses 206 and 211 in the Opposing system.
8-61
For the base case condition, it can be seen that the element that is most restrictive for transfers is
the INTERFACE EAST. This interface comprises 4 branches that tie the Study and Opposing
systems. Consequently, all transfer takes place across these branches. This is why the Distribution
factor has a value of 1.0. This means that 100% of any generation shift will flow on this interface.
The flow in the PRE-SHIFT condition is 130.8 MW on the interface. If a 100 MW shift is imposed,
the POST-SHIFT flow on the interface will increase by 100 MW to 230 MW as shown. The shift can
be increased until the flow on the interface is 350 MW, its thermal limit. this is the LIMIT case.
It can be seen that the flow on the limiting interface can increase by 220 MW (350-131) before
reaching its thermal limit. Consequently, the TOTAL transfer limit will be the pre-shift flow of 278.7
MW plus the possible 220 MW increase. As the report shows, therefore, the transfer limit for the
base case condition is 497.9 MW and is caused by the thermal limit on the INTERFACE EAST.
As the listing shows, the next most restrictive element is the branch from Bus 201 to Bus 151. The
results are showing that, if the INTERFACE EAST thermal limit were removed (by upgrading or
other means), this branch would create the limit; in this case it is 1,330 MW.
How is the 1,330 MW Calculated?

Branch 201 to 151 has a thermal limit of 1,200 MW. The pre-shift flow on the branch is only 558.7
MW. Consequently, the branch has a capacity for an additional flow of 641.3 MW (1200 - 558.3). To
increase the flow on this branch by 641.3 the generation shift would have to be 1,051.6 MW
because the distribution factor for this branch is 0.60981, i.e. only about 60% of the generation shift
will flow on this branch. Given a generation shift of 1,051 MW, on top of the pre-shift inter-area flow
of 278.7 MW, the total transfer limit is 1,330 MW.
Similar calculations can be done to check the other, less restrictive limits shown in the report listing.
Note that the limit imposed by the branch from Bus 205 to Bus 154 is marginally more complicated
to check because the generation shift actually decreases flow on this branch. It is necessary to
consider the flow direction on the branches (to and from) and the sign of the distribution factors.
8.7.7 Transfer Limit Analysis Flows For Contingency Cases

as the base case flows at the transfer level required for the most restrictive monitored element. Note
that if the user so selects (see Section 8.7.3 Transmission Transfer Limit Analysis Options), only the
contingency case constraints are considered in calculating the transfer limit; in this case, base case
flows at the transfer limit may be shown as overloaded because the corresponding constraints are
ignored in the transfer limit calculation.
An curtailed example of the report listing for the contingency cases is shown in Figure 8-9.
monitored elements.
This is followed by a tabulation of monitored elements for all system conditions that were calculated,
in order of increasing incremental or total transfer capability, as appropriate. The limiting element is
listed along with its power transfer distribution factor, its pre-shift contingency case flow, its rating,
and a description of the system condition.
8-62
Only those monitored elements satisfying the cutoff threshold solution parameters set by the user
are included in the summary. After an element has been listed the maximum number of times < n >,
its nth occurrence includes an asterisk (  ) before its description, and further reporting of the
element is suppressed.
If a line outage contingency forms an island with no Type 3 (swing) bus, a singular sub-matrix is
formed. Any monitored branch that is located in the swingless island, as well as any interface that
includes such a branch as a member, has dashes printed where its contingency case results would
normally be printed.
How is the negative transfer limit obtained?

In Figure 8-9 it can be seen that the most severe contingency identifies a negative transfer limit of
-56.5 MW. The contingency is loss of the two units at Buses 101 and 102. In the pre-shift condition,
in which there is a transfer of 278 MW, the branch from Bus 3008 to Bus 154 has a loading of 465
MW but has a thermal capacity of only 440 MW. This loading has to be reduced by 25.4 MW to keep
the branch within its capacity.
The distribution factor is 0.07566. Consequently the transfer has to be reduced by 335 MW (that is
25.4 MW divided by 0.07566) from its current level of 278.7 MW. This, rounding off, is 57 MW less
than the base case (pre-shift) transfer.

Activity TLTG uses the same linearized network model as is used in activity DCLF. Thus, the
mate nature of the linearized network model used by activity TLTG. The proper role of activity TLTG,
therefore, should be to focus attention on those system conditions that deserve more detailed study.
Activity TLTG detects the specification of duplicate single and double line outage contingencies and
calculates the contingency case solution only for the first specification of such a contingency. Any
contingency cases involving bus boundary contingency events, line closure contingency events, or
more than two line outage contingency events are not checked for duplication.
The values shown as monitored element flows are set as described in Section 8.5.4 Contingency
Case Flow Calculations. The user selects the base flow value to be used by setting the line flow
code solution parameter at the start of activity TLTG (see above).
8-63
Typical output for Contingency case. Most restrictive transfer limit is negative due to overload prior to shift during contingency.
Partial Summary Listing showing Contingency Testing results in order of Increasing Transfer Capability
Figure 8-9. Partial Listing of Report for Two Area Transfer Limits for Contingency Cases
8-64
In the contingency case monitored flow tables, transfer limits may be calculated using either of the
following approaches:
1. Both pre-contingency and post-contingency flows must satisfy their appropriate rating
constraints (i.e., both the base case and the contingency case must have no overloads).
2. Only post-contingency constraints need be satisfied.
The user selects the method to be used by setting include/ignore base case constraints in contingency
case at the start of activity TLTG. The setting of this parameter has no effect on the summary report
of activity TLTG; for contingency cases, the transfer capability shown is always the one at which the
monitored element is at its limit in the contingency case. Thus, the setting of this parameter is mean-
ingful only if the full output option is specified.
When the user has specified apply summary minimum distribution factor to report and minimum distribu-
tion factor magnitude is greater than zero, monitored elements with distribution factor magnitudes
below the threshold are ignored in calculating the corresponding monitored element flow table as
well as being omitted from the summary report.
If the convert ratings code is set to one at the start of activity TLTG, any percentage of rating param-
the convert ratings solution parameter.
activity TLTG.
It is entirely possible that, for a given system condition, there is no interchange schedule at which
the linearized network model results in all monitored elements satisfying their rating constraints.
This could occur, for example, if the pre-shift solution had two overloaded branches, and one
required an increase in interchange to relieve its overload while the other required a decrease in
interchange.
Minimum pre-shift flow change and minimum distribution factor change values may be used to
exclude from consideration those monitored elements in a contingency case that are not greatly
affected by the contingency. This could result in a situation in which none of the remaining moni-
tored elements have non-zero ratings. Such insoluble conditions are described in the output block
for that condition when full output is selected; when the summary report is chosen, such cases are
identified.
When specifying a rating percentage of other than 100%, note that interface ratings are also scaled
by the specified percentage in checking their flows to determine maximum interchange.
PSS®E GUI Users Guide, Section 13.7, Running DC Corrective Action Analysis
Section 10.6, Calculating Transmission Interchange Limits
8-65
Calculating Sequential Participation Interchange Limits Program Operation Manual
8.8 Calculating Sequential Participation Interchange Limits

Activity SPIL
Run Activity SPIL - GUI

Power Flow > Linear Network > Sequential participation interchange limit (SPIL)…
[Sequential Participation Interchange Limit]
Run Line Mode Activity SPIL - CLI
ACTIVITY?
>>SPIL

AB
The sequential participation transmission interchange limit analysis activity SPIL estimates the
import or export limits of a specified subsystem of the working case using a linearized network
model. The user designates this study system in which the total power injection is to be increased
(for export limits) or decreased (for import limits). An opposite change in the total power injection is
made in a designated opposing system.
It is clear that this analysis is similar to that described in Section 8.7.2 Calculating Transmission
Transfer Limits, the difference here being that the shifts in export or import are defined on the basis
of specific participating elements in the study and opposing systems.
Activity SPIL accesses a Distribution Factor Data File to pick up subsystem, monitored element and
contingency definitions (refer to activity DFAX). It also accesses a Subsystem Participation Data
File in which alternative participation data may be provided for the study and/or opposing systems
(refer to Section 8.8.1 Subsystem Participation Data File Contents).
Power transfer distribution factors relating changes in branch and interface flows to a change in
study system interchange are determined. The maximum study system export or import is then
derived by interpolation and extrapolation subject to the constraint that no monitored elements
exceed a specified percentage of a selected rating.
The process will perform all the contingencies identified in the contingency description file
processed when building the distribution factor file. Furthermore, the process uses the monitored
list file, which allows the lines to be monitored and interfaced. This feature is important because
these interfaces often define stability limits.
Note that any two subsystems identified in the *.sub file can be used for the transfer analysis.
Furthermore, however, it should be noted that the limits will be found based on only those elements
(lines and interfaces) that are monitored, i.e. included in the *.mon file.
8-66
Program Operation Manual Calculating Sequential Participation Interchange Limits
8.8.1 Subsystem Participation Data File Contents

The Subsystem Participation Data File is used to define participation blocks for one or more of the
subsystems that are defined in the Distribution Factor Data File constructed by activity DFAX and
specified to activity SPIL. The subsystems were in turn defined in the Subsystem Description Data
File (refer to Section 8.1.2 Subsystem Description Data File Contents) that was read by activity
DFAX in the process of constructing the Distribution Factor Data File. The participation data defined
in the Subsystem Participation Data File provides for:
• Up to five participation blocks per subsystem.

• For each participation block, the fraction of the maximum permissible power shift (spec-
ified in activity SPIL; refer to Section 8.8.3 Operation of Activity SPIL) to be assigned
to the block.
• For each participation block, the list of buses that are to be included in the block and
their block participation factors.
The Subsystem Participation Data File consists of one or more sets of subsystem data with a line
containing a zero or blanks following the last set of subsystem data. The file format will appear as
shown here:
set of data for a subsystem
set of data for another subsystem
.
.
.
set of data for another subsystem
0 End of participation data

Each set of data for a subsystem contains the subsystem label enclosed in single quotes (refer to
Section 8.1.2 Subsystem Description Data File Contents), followed by data for up to five participa-
tion blocks, followed by line containing a zero:
'label'
data for participation block 1
.
.
.
data for participation block n
0 End of participation data for subsystem 'label'
8-67
The format of records for each participation block is as follows:
BLOCKF
IBUS PF
.
.
.
IBUS PF
0 End of participation block
where:
BLOCKF Is a positive value defining the block participation factor. BLOCKF is typically
expressed in percent or per unit of the maximum permissible power shift that is to
be assigned to the participation block.
IBUS Is the bus number of a bus assigned to subsystem label. A subsystem bus may be a
member of no more than one participation block.
PF Is a non-zero value defining the bus participation factor. PF is typically expressed in
percent or per unit of the power shift assigned to this participation block. While an
individual PF value may be negative, the sum of PF factors within each participation
block must be positive.
Following is an example of a Subsystem Participation Data File for two subsystems, with each
subsystem having two participation blocks.
'SUBSYS A' Start of participation data for subsystem 'SUBSYS A'

.2 Start of participation block 1 for subsystem 'SUBSYS A'
101 1
0 End of participation block 1 for subsystem 'SUBSYS A'
.8 Start of participation block 2 for subsystem 'SUBSYS A'
102 1
0 End of participation block 2 for subsystem 'SUBSYS A'
0 End of participation data for subsystem 'SUBSYS A'
'SUBSYS B' Start of participation data for subsystem 'SUBSYS B'
4 Start of participation block 1 for subsystem 'SUBSYS B'
201 .725
206 1.0
0 End of participation block 1 for subsystem 'SUBSYS B'
6 Start of participation block 2 for subsystem 'SUBSYS B'
211 .3
264 .6
0 End of participation block 2 for subsystem 'SUBSYS B'
0 End of participation data for subsystem 'SUBSYS B'
0 End of participation data
8-68
8.8.2 Interchange Limits Options

Table 8-5. Sequential Participation Interchange Limits Options

Abort if MW mismatch Enable or disable termination of activity SPIL if mismatch toler-
enabled
The user specifies the rating; the default rating set is established
by the program option setting (refer to Section 3.3.3 Program
Percent of rating 100 Run-Time Option Settings and activity OPTN).
mated MW ratings
dc base branch flow estimates.
Line flow code
• ac base case
Phase shifter in base case Lock Data) is set to +3 holds its base case flow in all base case shift
solutions. If set to Lock, all phase shift angles are locked at their
base case settings.
Add study system ties to If enabled, automatically include study system tie lines as
disabled
Minimum contingency case Provide the means to ignore those monitored elements
pre-shift flow change 1.0 that, in a contingency case, are not significantly affected by
the contingency. If the magnitude change in pre-shift flow
from the base case value is less than the minimum flow
change threshold and the magnitude change in the power
Minimum contingency case transfer distribution factor from the base case value is less
0.0000
distribution factor change than the distribution factor change threshold, the monitored
element is ignored.
8-69
Table 8-5. Sequential Participation Interchange Limits Options (Cont.)

Description Data File Contents). If no participation block was
entered for the study system, the generation shift is shared
Study system generation active power output at the bus). In this case, there must be at
100
shift least one in-service machine with a positive MBASE in the
factors or MBASEs.
Subsystem selection limits). The choices available are those listed in the *.sub type file.
Opposing System: network subsystem in which an opposite
Threshold value, number of monitored elements in the
Maximum import / export 99999
summary report.
Threshold value for summary report. For small distribution
0.0 factors with levels below this threshold there will be no
magnitude
reporting for the related element.
Maximum time report same Threshold value for summary report limiting the number of
5
element times an element is reported in the same report.
Defines the manner in which contingency cases are identified in
the summary report as one of the following:
Summary table contin- • 12-character contingency case label
Events
gency descriptions
• events comprising the contingency case
• both contingency label and the contingency events
8-70
Table 8-5. Sequential Participation Interchange Limits Options (Cont.)
Incre- Incremental: incremental transfer capability

Interchange limit output
mental Total: total transfer capability
Limit the flow table for each case reported to the < n > most
Elements in flow tables 60000
restrictive monitored elements.
If enabled, apply the minimum distribution factor magnitude
Apply summary minimum threshold for including monitored elements in the summary
disabled
distribution factor to report report to the monitored element flow table of each case
reported when full output is selected.
Summary report is repeated with interface transfer limits
and distribution factors for a selected interface listed rather
than study system transfer limits and distribution factors.
Optional Interface Output NONE
The interface distribution factors listed on the interface
summary report are measures of the changes in monitored
element flows to a change in base case interface flow.
8.8.3 Operation of Activity SPIL

Activity SPIL checks that generators are not converted (refer to CONG) and that each non-Type 4
are detected, an appropriate message is printed and activity SPIL is terminated.
SPIL.
The user must specify the study and opposing systems. If no subsystems are defined, an appro-
priate error message is printed and activity SPIL is terminated. If only one subsystem was specified,
the specified subsystem is taken as the study system while the remainder of the working case is
treated as the opposing system. If two subsystems were specified, the default opposing system is
bypassed.
Activity SPIL checks to ensure that there are no buses that are members of both of the selected
subsystems. If any such buses are found, they generate an alarm and activity SPIL is terminated.
The user may enter the name of a Subsystem Participation Data File that contains subsystem
sequential participation data as described in Section 8.8.1 Subsystem Participation Data File
Contents. Refer to Section 2.4.1 File Usage for the file specification conventions used by activity
SPIL.
8-71
Data specified in this file must be consistent with the subsystem definitions contained in the Distri-
bution Factor Data File accessed above. For each of the study and opposing systems, if the
designated file contains valid sequential participation data, its data is used rather than the partici-
pation data contained in the Distribution Factor Data File; otherwise, the participation data
contained in the Distribution Factor Data File is used.
If no Subsystem Participation Data File is specified, activity SPIL uses the participation data
contained in the Distribution Factor Data File and produces results identical to those of activity
TLTG.
working case is calculated and printed.
If no subsystems are defined an appropriate error message is printed and the interchange calcula-
tion process is terminated. If only one subsystem is defined, a second subsystem (WORLD) is
assumed containing those buses in the power flow case that are not assigned to the specified
subsystem.
If the convert ratings option was enabled at the start of activity SPIL, ratings from the selected rating
set(s) of those monitored branches having non-zero rating(s) are modified. For each such branch,
the reactive power loading is calculated and MW rating(s) are determined under the assumption
that the reactive power loading is unchanged under power transfer and contingency conditions.
Using the incremental form of the dc power flow equation (see Section 8.4.1 DC Linearized Network
Solutions) and the power shift vector, phase angle changes are calculated, followed by incremental
line flows for all monitored lines and interfaces. These are transformed into a vector of base case
power transfer distribution factors, and the interchange limit is determined by extrapolation such
that all monitored elements satisfy their rating constraints.
The base case dc network solution is then calculated and the solution summarized as in the
following example:

OPPOSING SYSTEM GENERATION IS 1748.9 MW
Description Data File (refer to Section 8.1.2 Subsystem Description Data File Contents) or in a
series of sequential shifts as defined in the Subsystem Participation Data File (refer to Section 8.8.1
Subsystem Participation Data File Contents). If no participation block was entered for the study
system in either file, the generation shift is shared among generator buses in proportion to their
plant MBASEs (i.e., the sum of the MBASEs of in-service machines with positive active power
output at the bus). In this case, there must be at least one in-service machine with a positive MBASE
in the subsystem. Similar opposite generation shifts are applied to buses in the opposing system,
again according to their participation factors or MBASEs. Using the incremental form of the dc
power flow equation (refer to Sections 8.4.4 and 8.5.4) and the generation shift vectors, phase
angle changes are calculated, followed by incremental line flows for all monitored lines and inter-
faces. These are transformed into vectors of base case power transfer distribution factors, and the
interchange limit is determined by extrapolation such that all monitored elements satisfy their rating
constraints.
8-72
The generation shift is apportioned among generator and load buses in the study system in a series
of sequential shifts as defined in the Subsystem Participation Data File described above.
cases with contingency case flow estimates calculated using the methodology defined in Contin-
gency Case Flow Calculations. Prior to terminating, an ordered summary report from among all the
cases calculated is tabulated (refer to Section 8.8.5 Output Report Format).
The user may specify having the summary report repeated with interface transfer limits and distri-
bution factors for a selected interface listed rather than study system transfer limits and distribution
factors. The interface distribution factors listed on the interface summary report are measures of the
changes in monitored element flows to a change in base case interface flow.
In listing study system buses, opposing system buses, and study system tie lines, the tabulation
may be terminated by entering the AB interrupt control code. In this case, the interrupt is cleared
and processing continues. After the interchange limit calculations have started, activity SPIL may
be terminated by entering the AB interrupt control code.
8.8.4 Analyzing Interchange Limit Results

The significant difference between this Sequential Participation Interchange Limit calculation and
the Two-area Transmission Interchange Limit calculation, described in activity TLTG, is that the
generation shift here is established by sequential participation of specific buses each with its own
participation factor.
When multiple participation blocks are specified in the Subsystem Participation Data File for the
study and/or opposing systems, the study system generation shift and the block participation factors
specified in the Subsystem Participation Data File are used to allocate portions of the specified shift
sequentially among the participation blocks. Within each participation block, its allocation is
assigned to the block's participating buses in proportion to their bus participation factors. Thus, the
sensitivity of each monitored element's flow to an incremental change in study system interchange
is defined by a set of power transfer distribution factors that vary according to the current level of
study system interchange.

In reporting the base case solution, activity SPIL lists the study system generation, the opposing
system generation, and the study system net interchange corresponding to the network solution
before and after applying the generation shift. This is followed by a tabulation of the pre-shift and
post-shift generation at those study system and opposing system buses participating in the gener-
ation shift. Loadings on monitored elements are then reported, sorted such that the most restrictive
elements are listed first. Either incremental or total pre-contingency transfer limits, as appropriate,
are listed.
lated at the metered end in the from bus to to bus direction. The flow across an interface is taken
as the sum of the flows of its members. For three-winding transformer windings, the flow is calcu-
lated at the winding bus as power flowing into the transformer. For other members, the flow is
calculated at its metered end in the from bus (i.e., the first bus specified in entering the branch; refer
to Monitored Element Data File Contents) to to bus direction.
Flow estimates are listed for each of three interchange schedules: with the original generation
profile, with the specified generation shift, and at the generation shift corresponding to the transfer
8-73
level limit required for the most restrictive monitored element (i.e., the one listed first). Any flow at
or above the selected percentage of the appropriate rating is followed by an asterisk (  ). The
power transfer distribution factor relating the change in flow on the monitored element to a change
in study system net interchange is also tabulated. When multiple participation blocks were specified
for either the study or opposing system, the power transfer distribution factors printed are those that
apply at the transfer level required for the most restrictive monitored element.
For each monitored element reported, its rating is listed; for branches, this is not the percentage of
the rating used in determining the interchange limit, but either the value of rating as entered in activ-
ities such as READ, TREA, RDCH, CHNG or the [Spreadsheet], or, if the convert ratings option was
selected at the start of activity SPIL, the estimated MW ratings.
as the base case flows at the transfer level required for the most restrictive monitored element. Only
the contingency case constraints are considered in calculating the transfer limit; base case flows at
the transfer limit may be shown as overloaded because the corresponding constraints are ignored
in the transfer limit calculation.
monitored elements (refer to Section 8.8.8 Application Notes). This is followed by a tabulation of
monitored elements for all system conditions that were calculated, in order of increasing incre-
mental or total transfer capability, as appropriate. The limiting element is listed along with its power
transfer distribution factor, its pre-shift contingency case flow, its rating, and a description of the
system condition.
Only those monitored elements satisfying the cutoff threshold solution parameters set at the start
of activity SPIL (refer to Section 8.8.3 Operation of Activity SPIL) are included in the summary. After
an element has been listed the maximum number of times < n >, its nth occurrence includes an
asterisk (  ) before its description, and further reporting of the element is suppressed.
8.8.6 Example Activity SPIL Output

Figure 8-12 shows the report obtained using the example files (savnw.*) from which was built the
dc-contingency.dfx distribution factor file. The example data files used (*.sub, *.mon, *.con) can be
seen listed at the top of the report listing. They are available in the PSS®E EXAMPLE directory.
8-74
As an example, a Subsystem Participation Data file was prepared for the two study areas STUDY
and EAST identified in the savnw.sub file. The file is shown in Figure 8-10 where it can be seen that
generators at Buses 101 and 102, in the STUDY subsystem are identified as participating at 20%
and 80% respectively. In the EAST subsystem, the opposing system, there are two participation
blocks, one of which has a participation of 30% and the other with participation of 70%. Each block
has a participating generator and load bus.
For the purposes of running and example case, a total shift of 100 MW is assumed. In the Report
listing, Figure 8-12, it can be seen that this shifts in the study and opposing systems are apportioned
as defined by the participation block ratios as identified in Figure 8-10.
Figure 8-10. Participation Factors
8-75
Figure 8-11. Sequential Participation Interchange Limit Output for Base Case
8-76
It can be seen that the transfer capabilities and participation factors are different from those shown
in Figure 8-10 where sequential participation factors were not used. There, the power shift is appor-
tioned relative to the MBASE value for the machines in the two participating systems.
8.8.7 Interchange Limits Contingency Cases

as the base case flows at the transfer level required for the most restrictive monitored element. Only
the contingency case constraints are considered in calculating the transfer limit; base case flows at
the transfer limit may be shown as overloaded because the corresponding constraints are ignored
in the transfer limit calculation.
monitored elements. This is followed by a tabulation of monitored elements for all system conditions
that were calculated, in order of increasing incremental or total transfer capability, as appropriate.
The limiting element is listed along with its power transfer distribution factor, its pre-shift contingency
case flow, its rating, and a description of the system condition.
Only those monitored elements satisfying the cutoff threshold solution parameters set by the user
when launching the calculation process are included in the summary. After an element has been
listed the maximum number of times < n >, its nth occurrence includes an asterisk (  ) before its
description, and further reporting of the element is suppressed.
If a line outage contingency forms an island with no Type 3 (swing) bus, a singular sub-matrix is
formed. Any monitored branch that is located in the swingless island, as well as any interface that
includes such a branch as a member, has dashes printed where its contingency case results would
normally be printed.
Reference can be made to Figure 8-9, which shows the report listing for the two-area Transmission
Interchange Limit calculation. The format for this two area calculation, using sequential participation
factors, is the same. The results, however, will show different interchange limits and distribution
factors.

Activity SPIL uses the same linearized network model as is used in activity DCLF. Thus, the
mate nature of the linearized network model used by activity SPIL. The proper role of activity SPIL,
therefore, should be to focus attention on those system conditions that deserve more detailed study.
Activity SPIL detects the specification of duplicate single and double line outage contingencies and
8-77
Case Flow Calculations. The user selects the base flow value to be used by setting the line flow
code solution parameter at the start of activity SPIL (see above).
When multiple participation blocks are specified in the Subsystem Participation Data File for the
study and/or opposing systems (refer to Section 8.8.1 Subsystem Participation Data File Contents),
the study system generation shift specified in the dialog of activity SPIL and the block participation
factors specified in the Subsystem Participation Data File are used to allocate portions of the spec-
ified shift sequentially among the participation blocks. Within each participation block, its allocation
is assigned to the block's participating buses in proportion to their bus participation factors. Thus,
the sensitivity of each monitored element's flow to an incremental change in study system inter-
change is defined by a set of power transfer distribution factors that vary according to the current
level of study system interchange.
Because this transfer limit calculation process uses the linearized network model, note should be
taken of the approximate nature of the solution. The proper role of this analysis, therefore, should
be to focus attention on those system conditions that deserve more detailed study.
The process detects the specification of duplicate single and double line outage contingencies and
In the contingency case monitored flow tables, transfer limits are calculated such that only post-
contingency constraints need be satisfied.
When apply summary minimum distribution factor to report is enabled and minimum distribution factor
magnitude is greater than zero, monitored elements for which all their distribution factor magnitudes
are below the threshold are ignored in calculating the corresponding monitored element flow table
as well as being omitted from the summary report.
If Convert ratings to estimated MW Ratings is enabled at the start of activity SPIL, any percentage
of rating parameter is applied after the conversion to estimated MW ratings. Interface ratings are
not affected by the convert ratings solution parameter.
activity SPIL.
the linearized network model results in all monitored elements satisfying their rating constraints.
This could occur, for example, if the pre-shift solution had two overloaded branches, and one
interchange.
Options for Minimum contingency case pre-shift flow change and minimum contingency case distribution
factor change may be used to exclude from consideration in a contingency case those monitored
elements that are not greatly affected by the contingency. This could result in a situation in which
none of the remaining monitored elements have non-zero ratings. Such insoluble conditions are
8-78
Program Operation Manual Performing Interchange Limit Analysis with Two Opposing Systems
described in the output block for that condition when full output is selected; when the summary
report is chosen, such cases are identified.
Such insoluble conditions are described in the output block for that condition when full output is
selected; when the summary report is chosen, such cases are identified.
PSS®E GUI Users Guide, Section 13.8, Calculating Transmission Interchange Limits
Section 10.7, Calculating Sequential Participation Interchange Limits
8.9 Performing Interchange Limit Analysis with Two Opposing

Systems
Activity POLY
Run Activity POLY - GUI

Power Flow > Linear Network > Interchange limits with two opposing systems (POLY)…
[Interchange Limits with Two Opposing Systems]
AB
The transmission interchange limit analysis activity POLY estimates the import or export limits of a
specified subsystem of the working case using a linearized network model. The user designates
this study system in which the total power injection is to be increased (for export limits) or decreased
(for import limits). Activity POLY differs from activity SPIL in that it considers simultaneous power
injection shifts in two opposing systems in maximizing study system import or export.
Two sets of base case power transfer distribution factors are determined: one set relating changes
in branch and interface flows to a change in study system interchange against the first opposing
system, and another relating changes in flows to a change in study system interchange against the
second opposing system. The maximum study system export or import is then derived by a linear
program subject to the constraint that no monitored elements exceed a specified percentage of a
selected rating.
Results are calculated and then presented in tabular and, optionally, graphical forms. The graphical
output of a previous execution of activity POLY is available via the POLY Results Output File
produced during the execution of activity POLY.
8-79
Performing Interchange Limit Analysis with Two Opposing Systems Program Operation Manual
8.9.1 Interchange Limit Analysis Options

Table 8-6. Interchange Limits Analysis Options for Two Opposing Systems

Abort if MW mismatch Enable or disable termination of activity SPIL if mismatch toler-
enabled
lished by the program option setting (refer to Section 3.3.3
Percent of rating 100 Program Run-Time Option Settings and activity OPTN).
mated MW ratings
Line flow code
• ac base case
Phase shifter in base case Lock Data) is set to +3 holds its base case flow in all base case shift
solutions. If set to Lock, all phase shift angles are locked at their
base case settings.
If set to Include, both base case and contingency case flow
constraints are recognized in calculating the pre-contingency
Base case constraints in
Ignore interchange limits for each contingency case. If set to Ignore, only
contingency case
the contingency case loadings are considered (refer to
Add study system ties to If enabled, automatically include Study System tie lines as
Disabled
Maximum allowed
Places a bound on the permissible generation shift for each
opposing system genera- 10000
tion shift
of the opposing systems.
Defines the minimum distribution factor magnitude

threshold for including monitored elements in the transfer
limit calculation and report. Any monitored element for
0.0 which both of its power transfer distribution factor magni-
magnitude
tudes are below this threshold is ignored during the
processing and reporting of the corresponding system
condition.
8-80
Table 8-6. Interchange Limits Analysis Options for Two Opposing Systems (Cont.)

Study system generation Description Data File Contents). If no participation block was
100 entered for the study system, the generation shift is shared
shift
active power output at the bus). In this case, there must be at
least one in-service machine with a positive MBASE in the
factors or MBASEs.
Study system generation
shift (continued)
limits). The choices available are those listed in the *.sub type file.
Subsystem selection Opposing System 1: network subsystem in which an opposite
Opposing System 2: second network subsystem in which an
opposite change from that in the Study System is made.
Defines the plotting scales if graphical output is specified.
Maximum opposing system Change in interchange in the first opposing system is plotted
1000
 interchange for plotting along the x-axis, and change in interchange in the second
opposing system is plotted along the y-axis.
8-81
Table 8-6. Interchange Limits Analysis Options for Two Opposing Systems (Cont.)

Defines graphical reports for all system conditions:
• None
All system • Only combined cases
Plot code
conditions • All system conditions
A graph is produced for either each optimal solution calculated or
for only the combined cases solution.
Defines constraint line plotting:
• All constraints
• Only feasible region boundary
Only If combined cases specified, all monitored element
Constraint plot code
feasible
constraint lines that fall within the plotting limits specified by
 interchange are plotted. Otherwise, only those constraint
lines that form the border of the feasible region are plotted;
refer to Section 8.9.3 Output Report Format.
Output display:
• Standard output: graphic report reduced to fit on page
Standard • Two pages per case: page 1 = plotted results; page 2 =
Graphic output
output listing of monitored elements corresponding to those
constraint lines that form the border of the feasible
region; refer to Section 8.9.3 Output Report Format.
Output location:
Dialog
Place • Dialog window
window
• Printer
POLY Results file (*.pol): output file to which the information
Output file (results) will be written for current or later plotting of the graphical
display of results.
8.9.2 Operation of Activity POLY

Activity POLY checks that generators are not converted (refer to CONG) and that each non-Type 4
are detected, an appropriate message is printed and activity POLY is terminated.
ORDR is automatically executed. Activity POLY calculates and prints the largest active power
mismatch corresponding to the present ac solution voltage vector in the working case. The user
may specify that activity TLTG be terminated (default) if this largest mismatch is greater than the
MW mismatch tolerance.
8-82
POLY.
The user must specify the study and opposing systems. If fewer than two subsystems are defined,
an appropriate error message is printed and activity POLY is terminated. If either two or three
subsystems were specified, the designated subsystem is taken as the study system while the
remaining two subsystems are treated as the opposing systems. If more than three subsystems
were defined, the user specifies the two opposing systems. Activity POLY verifies that there are no
buses that are members of two or all three of the selected subsystems. If any such buses are found,
they generate an alarm and activity POLY is terminated.
Next, the largest active power mismatch corresponding to the present ac solution voltage vector in
the working case is calculated. If this largest mismatch is greater than the MW mismatch tolerance,
the user is given the option of continuing or terminating: the process.
The program will check to ensure that there are no buses that are members of two or all three of
the selected subsystems. If any such buses are found, they generate an alarm and the process is
terminated.
If the convert ratings option was enabled at the start of activity POLY, ratings from the selected
rating set(s) of those metered branches having non-zero rating(s) are modified. For each such
branch, the reactive power loading is calculated and MW rating(s) are determined under the
assumption that the reactive power loading is unchanged under power transfer and contingency
conditions.
The base case dc network solution is calculated and the solution summarized as in the following
example:

OPPOSING SYSTEM 1 GENERATION IS 1400.0 MW
OPPOSING SYSTEM 2 GENERATION IS 348.9 MW
The user may specify a study system generation shift (default = 100). If the value entered is positive,
export limits are to be determined; otherwise, import limits are to be calculated.
Description Data File (refer to Section 8.1.2 Subsystem Description Data File Contents). If no partic-
ipation block was entered for the study system, the generation shift is shared among generator
buses in proportion to their plant MBASEs (i.e., the sum of the MBASEs of in-service machines with
positive active power output at the bus). In this case, there must be at least one in-service machine
with a positive MBASE in the subsystem. The opposite generation shift is applied to buses in the
first opposing system, again according to their participation factors or MBASEs.
Using the incremental form of the dc power flow equation (refer to activity DCLF) and the power shift
vector, phase angle changes are calculated, followed by incremental line flows for all monitored
lines and interfaces. These are transformed into a vector of base case power transfer distribution
factors, and the interchange limit is determined by extrapolation such that all monitored elements
8-83
A second set of power transfer distribution factors describing the effect on the monitored elements
of an interchange shift between the study system and the second opposing system is calculated.
Based on the two sets of power transfer distribution factors, the study system interchange limit is
determined by a linear programming technique such that all monitored elements satisfy their rating
constraint.
cases, with contingency case flow estimates calculated using the methodology defined in Contin-
gency Case Flow Calculations.
One final optimal solution is calculated for a combined case. This solution calculation includes
constraints for all system conditions (i.e., the base case and all contingency cases) for which an
individual optimum solution was found. This calculation therefore determines the maximum study
system export (or import, as appropriate) schedule such that no monitored element is overloaded
in the base case or under contingency conditions.
The combined case solution is then reported and, prior to terminating, activity POLY summarizes
the calculated interchange limits for the base case, for all contingency cases, and for the combined
case.

In reporting the base case solution, activity POLY lists the generation in the study and opposing
systems and the study system net interchange corresponding to the network solution before
applying any generation shift and in the two generation shift cases. This is followed by a tabulation
of the pre-shift and post-shift generation at those study system and opposing system buses partic-
ipating in the generation shifts.
The generation shifts required to achieve the interchange limit (import or export, as appropriate) are
then listed, along with the limiting lines and/or interfaces and their ratings (see Figure 8.9.4).
lated at the metered end in the from bus to bus direction. The flow across an interface is taken as
the sum of the flows of its members. For three-winding transformer windings, the flow is calculated
at the winding bus as power flowing into the transformer. For other members, the flow is calculated
at its metered end in the from bus (i.e., the first bus specified in entering the branch; refer to Moni-
tored Element Data File Contents) to to bus direction.
Loadings on monitored elements are then reported. The flow estimates are listed for each of four
interchange schedules: with the original generation profile; with the specified generation shift in the
study system and the opposite shift in the first opposing system; with the specified generation shift
in the study system and the opposite shift in the second opposing system; and in the case with
maximum import or export, as appropriate, in which no monitored elements exceed the specified
percentage of the selected rating. Any flow at or above the selected percentage of the appropriate
rating is followed by an asterisk (  ). The power transfer distribution factors relating the change in
flow on the monitored element to a change in study system net interchange with the opposite
change in the two opposing systems in turn are also tabulated, along with the rating of the monitored
element; for branches, this is not the percentage of the rating used in determining the interchange
limit, but either the value of rating as entered in activities such as READ, TREA, RDCH, CHNG or
the [Spreadsheet], or, if the convert ratings option was selected at the start of activity POLY, the esti-
mated MW ratings (see Figure 8.9.4).
8-84
When reporting results for contingency cases, the events comprising the contingency are listed,
followed by the generation shifts required to achieve the transfer limit for the contingency case
being reported, along with the limiting elements. The flow table includes both the contingency case
flows in the same form as the base case report described above, as well as the base case flows at
the transfer limit. Note that if the ignore base case constraints in contingency cases option was
specified, only the contingency case constraints are considered in calculating the transfer limit; in
this case, base case flows at the transfer limit may be shown as overloaded because the corre-
sponding constraints are ignored in the transfer limit calculation.
When reporting results for the combined case, activity POLY tabulates the generation shifts
required to achieve the interchange schedule that results in maximum import (or export, as appro-
priate) while simultaneously avoiding overloading in all system conditions for which individual
optima were found. The limiting elements are listed along with the system condition in which they
are limiting. The combined case flow table includes only those elements that are part of the border
of the feasible region of a successfully solved system condition. Flows are reported in the same
form as the base case report described above, and the system condition to which they apply is
shown at the right side of each output line.
A summary page tabulates the number of optimal solutions attempted, and the number for which
there exists no interchange schedule at which the rating constraint can be satisfied for all monitored
elements. Then, for each case processed, the interchange limit is listed along with the corre-
sponding generation shifts required in the two opposing systems.
8.9.4 Interchange Limit (Two-Opposing Systems) Graphical Output

When the graphical display of results is selected, activity POLY produces a graph for either each
optimal solution calculated or for only the combined case solution (see below). Change in inter-
change in the first opposing system is plotted along the horizontal axis, and change in interchange
in the second opposing system is plotted along the vertical axis. The plotting scales are specified
at the start of activity POLY using the maximum opposing system  interchange for plotting option.
For each monitored element, a pair of straight lines is plotted indicating the set of interchange
schedule changes for which that element is exactly at its rating constraint. Moving to any point on
one side of any limit line brings the loading on the element below its limit; points on the other side
result in a limit violation. On the violation side of the limit line, the background is shaded blue (see
Figure 8-12).
When all monitored elements are so plotted, the region of interchange schedule changes at which
no monitored element violates its rating constraint is shown as the clean portion of the graph. If the
point of maximum transfer (export or import, as appropriate) exists for a given system condition (i.e.,
a clean portion exists on the graph for the system condition), it occurs at the intersection of a pair
of limit lines, and is enclosed in a square. In Figure 8-12 this is where the interchange with the EAST
system is 434 MW and -226 MW with the WEST.
A single-letter code is printed at each end of any limit line that is part of the border of the polygon
forming the clean portion of the graph; a key is printed with the graph indicating the elements repre-
sented by each such annotated constraint line. The two lines for which the intersection occurs at
8-85
the transfer limit are assigned the letter codes A and B; continuing along the border of the polygon,
successively encountered constraint lines are assigned letter codes in alphabetical order.
Plot and graphical output options specified at the start of activity POLY provide for the following
graphical report options:
1. Producing graphical output only for the combined case or for all cases.
2. Including on each plot for which a transfer limit exists either all constraint lines or only those
that form the boundary of the polygon that encloses the feasible region.
3. Including both the graph and the letter code key on the same plot or on separate plots.
Figure 8-12. Graphical Output from Calculation of Interchange Limit with Two Opposing
Systems
8-86

Activity POLY uses the same linearized network model as is used in activity DCLF. Thus, the
mate nature of the linearized network model used by activity POLY. The proper role of activity POLY,
therefore, should be to focus attention on those system and transfer conditions that deserve more
detailed study.
Activity POLY detects the specification of duplicate single- and double-line outage contingencies
and calculates the contingency case solution only for the first specification of such a contingency.
Any contingency cases involving bus boundary contingency events, line closure contingency
events, or more than two-line outage contingency events are not checked for duplication.
Case Flow Calculations. The user selects the base flow to be used by setting the line flow code
option at the start of activity POLY.
Contingency case transfer limits may be calculated using either of the following approaches:
1. Both pre-contingency and post-contingency flows must satisfy their appropriate rating
constraints (i.e., both the base case and the contingency case must have no overloads).
2. Only post-contingency constraints need be satisfied.
The user selects the method to be used by setting include/ignore base case constraints in contingency
case at the start of activity POLY.
When minimum distribution factor magnitude is greater than zero, monitored elements with both of
the distribution factor magnitudes below the threshold are ignored in calculating the transfer limit for
the corresponding system condition.
If the convert ratings code is set to one at the start of activity POLY, any percentage of rating param-
the convert ratings option.
activity POLY.
the linearized network model solution results in all monitored elements satisfying their rating
constraints. This could occur, for example, if the solution had two overloaded branches, and one
interchange. Such insoluble conditions are described in the output block for that condition. When
full output is being produced, the flow column corresponding to the maximum import or export for
that system condition is left blank. Such cases are identified on the summary page and are omitted
from the combined case transfer limit calculation.
The combined case solution is visually equivalent to plotting the graphical output for all successfully
calculated system conditions on the same graph and observing the clean area, if it exists, which all
of these graphs have in common.
8-87
Midwest MW-Mile Calculation Program Operation Manual
Section 13.9, Calculating Sequential Participation Interchange Limits
8.10 Midwest MW-Mile Calculation

Activity MWMI
Run Activity MWMI - GUI

Power Flow>Linear Network>Midwest MW-mile calculation (MWMI)…
[Midwest MW-miles calculation]
Run Line Mode Activity MWMI - CLI
ACTIVITY?
>>MWMI

None
This activity was incorporated into PSS®E for the convenience of customers who use Midwest ISO
(http://www.midwestiso.org/home) planning algorithms. Please contact MISO for current updates,
as PTI does not provide warranty or support for Midwest Independent Transmission System Oper-
ator solutions.
Section 13.11, Running Midwest MW-mile Calculation
8-88
Chapter 9
Network Reduction
Chapter 9 - Network Reduction
9.1 Overview: Equivalent (Reduced) Networks

Activity Overview
PSS®E provides the user with the capability to construct an electrical equivalent of all or a sub-
system of the network in the currently open power flow case. The case must be solved to an
acceptable mismatch level. The output of the construction process is a case with part or all of the
original network model replaced by an equivalent representation.
The primary purpose in constructing equivalents is to represent a portion of a network containing

many buses but having only a few boundary buses by a reduced network containing only the
boundary buses and, perhaps, a few selected buses from within the original subnetwork. Histori-
cally, equivalents have often been used to allow the representation of larger areas of major
interconnected systems in studies using computer programs which, due to restrictions imposed by
the computing hardware, were of limited dimensional capacity. Advances in computer technology,
particularly in the area of memory address capability, have lifted these restrictions to the extent that
network modeling capacity is usually no longer an issue. The primary application of equivalents in
modern engineering computers is to achieve improved computational speed in simulations by
removing buses and branches that are not of specific interest but which do influence system
behavior.
9.1.1 Nomenclature of Equivalents

In discussing the application of equivalents, it is useful to adopt the following terminology:
Study System: A group of buses and branches under detailed study. Within the study system,
all components are represented explicitly.
External System: A group of buses and branches that is connected to and influences a study
system, but which does not need to be represented in detail.
Boundary Buses: Buses from which branches run either into a study system, and one or
more external systems, or into more than one external system.
Source System: A power system representation that contains all components of an external
system as a subset of its own components. It is used to solve for the base conditions within
the external system. The source system does not need to include the study system, but
must recognize flows between the external and study system.
9-1
Network Reduction PSS®E 34.2
Methodology of the Electrical Equivalent Program Operation Manual
Electrical Equivalent: An artificial group of branches and buses that represents the behavior
of the external system as seen from its boundary buses.
Retained Bus: A bus of the external system that is also a bus of the electrical equivalent. A
retained bus is not necessarily a boundary bus, but all boundary buses are retained buses.
Deleted Bus: A bus of the external system that is not a bus of the electrical equivalent, but
where the effect is represented by the equivalent.
Tie Branch: A branch having one end in one system (study or external) and another end in a
different system. Tie branches are connected to boundary buses at each end.
Area: A group of buses designated in power flow input data for interchange control purposes.
An area may, but does not necessarily, coincide with a study or external system.
9.2 Methodology of the Electrical Equivalent

Activity Methodology
An electrical equivalent is constructed by performing a reduction operation on the admittance matrix

of the external system that is to be represented by the equivalent. The admittance matrix equation
of the external system may be written in the partitioned form
I1 Y1Y2 V1
=
I2 Y3Y4 V2
(9.1)
where I1 and V1 are node current and voltage at the nodes to be retained and I2 and V2 are node
current and voltage at the nodes to be deleted.
The desired form of an equivalent is an equation involving only I1 and V1 explicitly, with the I2 and
V2 variables assumed to be linearly dependent upon I1 and V1, and recognized implicitly. The
equivalent is obtained by rearranging the second row of (9.1) as
V2 = Y4-1(I2 - Y3V1) (9.2)
and substituting this into the first row of (9.1) to give
I1 = (Y1 - Y2Y4-1Y3)V1 + Y2Y4-1I2 (9.3)
The first term of (9.3) specifies a set of equivalent branches and static shunt elements connecting
the retained nodes, while the second term specifies a set of equivalent currents that must be
impressed on the retained nodes to reproduce the effect of load currents at the deleted nodes.
These equivalent currents may be translated into equivalent constant real and reactive power loads
at the retained buses. The equivalent obtained by translating the two terms of (9.3) into equivalent
branches, shunts, and loads is exact in the base case for which the current vector, I2, was calcu-
lated. When voltage conditions at the boundary buses are changed, the equivalent gives an
approximation to the change in power flow into the external system. This approximation is good as
long as the changes are small, but may become unreliable when boundary bus voltages and power
flows into the external system (or its equivalent) deviate from the base values by large amounts.
An electrical equivalent is, therefore, correctly applied when it represents an external system in
which the disturbances or switching operations under study produce only minor effects; but equiv-
9-2
PSS®E 34.2 Network Reduction
Program Operation Manual Methodology of the Electrical Equivalent
alents should not be applied to network segments in the close vicinity of the disturbances or
switchings.
9.2.1 Defining Boundaries and Boundary Buses

A boundary cuts a set of tie-lines between areas or otherwise identifiable sections of a network but
passes through no buses. A boundary bus is part of only one area (see Figure 9-1).
An equivalent makes more efficient use of storage when the ratio of branches to buses in the equiv-
alent is reduced. The relative efficiency of different equivalents of a given system is best determined
by trial and error. As a general rule, however, reducing a system into a number of small equivalents
is more efficient than reducing of a large system in one step to produce a single equivalent.
Study Boundary
System
B 550
198 B
T 553 R
302
552 R
13 78 B T 551
B
External
77 B System
T
T Boundary
T
911 B 914 B
Boundary
D R
912 917
External
System
B = Boundary Bus D = Deleted Bus
R = Retained Bus T = Tie Branch
Figure 9-1. Separation of Complete Network into Study System and External
Systems by Boundaries
9-3
Methodology of the Electrical Equivalent Program Operation Manual
Three special bus type codes are used to designate boundary buses at various stages of the equiv-
alent construction processes:
Type 5 As for Type 1 (load bus); boundary bus or a bus that is not to be deleted by the
equivalencing option, retained bus.
Type 6 As for Type 2 (generator bus); boundary bus.
Type 7 As for Type 3 (swing bus); boundary bus.
9-4
Program Operation Manual Building an Electrical Equivalent
It can be seen in Figure 9-1 that the area designated as the Study System there are three buses
(buses 198,78 and 77) that are the terminals of lines incoming from the other two areas and there
are four boundary buses in the external systems. If the external systems bus were to be reduced to
an equivalent network, it is possible that boundary 914 could be eliminated. But it would probably
be important for the user to retain this bus because of its strategic position in the network. Conse-
quently, it would be important to change the code of this bus, or to retain area boundary buses to
avoid having it deleted.
Several analytical processes of PSS®E change the type codes of boundary buses back and forth
between Types 1, 2, 3 and 5, 6, 7, respectively. The user may also change type codes manually by
editing the data in the spreadsheet view.
It is important to note that type codes 5, 6, 7 are valid only during equivalent construction and
system data processing operations. Type codes 5, 6, or 7 must be returned to 1, 2, or 3, respec-
tively, before invoking any optimal ordering, factorization, generator or load conversion, or solution
processing.
9.2.2 Handling DC Lines

In PSS®E, the equivalencing process automatically retains converter buses of unblocked dc trans-
mission lines. Hence, all buses that are affected by dc transmission must become part of a study
system before commencing the construction of an equivalent.
9.2.3 Approaching the Network Equivalent Process

The equivalencing process in PSS®E is designed to develop an electrical equivalent of a power flow
case or a subsystem of it, as described in Section 9.2 Methodology of the Electrical Equivalent,
while allowing the user to control which buses, lines, generators and phase-shifters are retained.
This global approach is supported with other reduction processes, which can be useful in making
selected equivalents of generators, prior to making the global network equivalent, or radial lines.
In addition, PSS®E provides a process for the construction of network equivalents of the positive
and zero sequence networks, and calculates source impedances at equivalent source nodes for all
three sequences in preparation for the unbalanced fault analysis activities of PSS®E.
Furthermore, PSS®E provides a boundary bus balance process that converts the mismatch at
boundary buses to equivalent load and/or generation. It is intended to be used following the removal
of a subsystem from a solved power flow case, with the flows to the deleted subsystem replaced by
load and/or generation at those retained buses that were directly connected to the removed
subsystem.
9.3 Building an Electrical Equivalent

Activity EEQV
Run Activity EEQV - GUI

Power Flow > Equivalence Networks…
[Equivalence Networks]
Build electrical equivalent (EEQV) Tab
9-5
Building an Electrical Equivalent Program Operation Manual
Run Line Mode Activity EEQV - CLI

ACTIVITY?
>>EEQV
USER SPECIFIES SUBSYSTEM TO BE EQUIVALENCED
>>
None
The power flow equivalent construction activity EEQV constructs an electrical equivalent of a
subsystem of the network contained inside the working case.1
The input to activity EEQV (i.e., the working case) must be solved to an acceptable mismatch level.
The output of activity EEQV is a working case with part or all of the original network model replaced
by an equivalent representation.
9.3.1 Overview
The equivalent constructed by activity EEQV is exact in the base case from which it was calculated.
It gives an exact reproduction of the self and transfer impedances of the external system as seen
from its boundary buses. The net total of load, generation, and losses in the equivalent matches this
total in the complete external system if the bus voltages in the working case were a valid power flow
solution. However, the load, generation, and loss totals in the equivalent may not individually match
those of the complete external system.
When voltage conditions at the boundary buses of the study system are changed, the equivalent
gives an approximation to the change in power flow into the external system. This approximation is
good as long as the changes are small, but may become unreliable when boundary bus voltages
and power flows into the external system (or its equivalent) deviate from the base values by large
amounts.
An electrical equivalent is, therefore, correctly applied when it represents an external system in
which disturbances or switching operations under study produce only minor effects. Equivalents
should not be applied to network segments in the close vicinity of the disturbances or switchings.
1 An electrical equivalent of the portion of the working case outside of the specified subsystem may be constructed using
the BAT_XEQV command at the PSS®E Command Prompt.
9-6
9.3.2 Network Equivalence Options

External systems, following the terminology of Section 9.1.1 Nomenclature of Equivalents, are
defined according to the specified subsystem. The user may specify subsystem data (refer to
Section 4.8 Subsystem Selection) by bus subsystem, area, zone, owner, or basekV.
Table 9-1. Network Equivalence Options
Option Description
Retain area boundary
Enable to keep area boundaries intact.
buses
Retain zone boundary
Enable to keep zone boundaries intact.
buses
If any two-winding transformers with a non-zero phase shift
angle are present in the subsystem to be calculated as elec-
trical equivalents, enable to suppress building an electrical
equivalent of phase shifters.
If the user chooses to retain two-winding transformer phase shifters,
activity EEQV forces the retention of the buses involved by changing
their type codes from 1, 2, or 3 to 5, 6, or 7, respectively. Thus, the
Suppress equivalencing of
phase shifter and the buses it connects are all explicitly retained in the
phase shifters
equivalent.
If the user chooses to include two-winding transformer phase shifters
when building the electrical equivalent, activity EEQV resets the
phase shift angle to zero degrees and introduces equivalent MVA load
at the buses connected by the phase shifter such that an electrical
balance is retained. The phase shifter is then treated like any other
transformer.
Enable to suppress building an electrical equivalent of buses where
voltage or reactive power output is controlled by remote generation,
Retain controlled buses
switched shunt, VSC dc line converter, and/or FACTS device shunt
element.
Enable to retain the identity of all non-transformer branches and two-
winding transformers in the working case connecting buses to be
retained in the equivalent.
If this option is enabled, the equivalent may contain an additional
Retain existing branches equivalent branch in parallel with any real branches between any
such pair of buses.
If this option is disabled, the equivalent branch between any such pair
of buses represents the single circuit equivalent of all real branches
between the buses and (possibly) an equivalent branch.
9-7
Table 9-1. Network Equivalence Options (Cont.)
Option Description
This option treats the total equivalent load and shunt at retained
buses such that occurrences of load and shunt that cancel at the bus
(e.g., positive load and negative shunts) are eliminated. The compo-
nent of smaller magnitude is set to zero with the other component set
Net load and shunt to the netted quantity. Active and reactive components at each
retained bus are processed independently.
Disable to allow the equivalent load and shunt components at
retained buses to remain as calculated by the equivalent construction
matrix reduction process
Enable to net small plants at Type 2 buses.
The user sets the positive threshold below which Type 2 buses will
have their generation netted with the bus load and its type code
Minimum generation for changed to one. This does not apply to boundary Type 2 buses or
retaining generator buses area swing buses. Both active and reactive power generation magni-
tudes must be below the threshold. If the threshold specified is zero,
all Type 2 generator buses in the subsystem being calculated as
electrical equivalents are retained.
Any equivalent branch where magnitude of impedance is greater than
Branch threshold tolerance this tolerance is not retained in the equivalent. The default value is
10 per unit.
9.3.3 Operation of Activity EEQV

First, the portion of the working case to be exempted from the equivalencing activity is (temporarily)
removed from the working case, and all radial and two-point Type 1 buses are calculated as elec-
trical equivalents (refer to RDEQ).
The standard output of activity ORDR is tabulated, and the construction of the equivalent is
completed.
If the user specified activity EEQV to net load and shunt at retained buses, it nets the total equiva-
lent load and shunt at retained buses such that occurrences of load and shunt that cancel at the
bus (e.g., positive load and negative shunts) are eliminated. The component of smaller magnitude
is set to zero with the other component set to the netted quantity. Active and reactive components
at each retained bus are processed independently.
If net load and shunt was disabled, the equivalent load and shunt components at retained buses
remain as calculated by the equivalent construction matrix reduction process.
The equivalent and detailed system sections are then combined.
9.3.4 Equivalencing Methodology

The activity of constructing and using an electrical equivalent can be separated into three steps:
1. Isolating an external system in the working case. Activity EEQV temporarily discards from
the working case all other subsystems (study and external) contained in the source system
9-8
except the one to be calculated as electrical equivalents. Boundary and retained buses are
identified and, if desired, selected generators are replaced by negative load.
2. Constructing the electrical equivalent by performing the required matrix reduction operation
on the external system remaining in the working case.
3. Combining system sections together to form a valid system model in the working case. In
this step, detailed representations of selected external systems are replaced with their elec-
trical equivalents.
Activity EEQV constructs electrical equivalents on the following basis:
Table 9-2. Electrical Equivalencing of Buses
Bus Type Code Treatment By Activity EEQV

1 Bus eliminated
2 and 3 Bus retained
Bus ignored in the computation and not included
4
in the equivalent
Bus retained in the equivalent with 4 subtracted
5, 6, and 7
from its bus type code
That is, it constructs an equivalent of a subsystem of the working case with its interior Type 1 buses
eliminated. Activity EEQV automates many of the data handling functions required in preparation
for, and following the execution of, the equivalent construction calculation. It may be used whenever
the entire solved source system is able to be brought into the PSS®E working case.
The equivalent constructed by activity EEQV is present in the working case along with the unequiv-
alenced portions of the system in the same form as an unequivalenced power flow case. There are
normally no operations required to combine system sections.
Activity EEQV processes only the positive sequence network. If sequence data is included in the
working case, the following message is printed upon entering activity EEQV and processing
continues:
WARNING: SEQUENCE DATA WILL NOT BE EQUIVALENCED
Activity EEQV requires that the working case represent a solved system condition.
In constructing the equivalent, all non-boundary Type 1 buses in the designated external system
are eliminated, and all Type 5, 6, and 7 buses are retained as Type 1, 2, and 3 buses, respectively.
Normally, the boundary buses from within the subsystem being calculated as electrical equivalents
are those connected to buses outside of the specified subsystem. However, when the subsystem
to be calculated as an electrical equivalent is specified by bus only, Type 1 and netted Type 2 buses
specified are calculated as electrical equivalents, with the boundary buses being those buses to
which they are connected and that are not among those specified.
When three or more buses are all connected together by zero impedance lines (refer to Section ),
either all may be calculated as electrical equivalents, all may be retained, or one may be retained.
If the bus type codes are such that more than one but not all the buses in such a group of buses
are to be retained, activity EEQV prints an appropriate message and retains all buses in the group.
9-9
Three-winding transformers are handled as follows:
• If all three buses connected by an in-service three-winding transformer are to be

retained, the transformer is explicitly retained.
• If at least one of the three buses connected by an in-service three-winding transformer
is to be calculated as an electrical equivalent, the transformer is calculated as an elec-
trical equivalent.
• Out-of-service three-winding transformers are ignored in constructing the equivalent
and are omitted from the equivalent.
Activity EEQV automatically retains the converter buses of unblocked dc lines, the buses to which
in-service GNE devices are connected, the sending and terminal buses of in-service FACTS
devices, and buses connected to terminal buses of in-service FACTS devices.
At all type 1 buses being eliminated, their in-service constant admittance load, fixed shunt, and
switched shunt are netted before applying the network reduction equations described in Section
9.2, Methodology of the Electrical Equivalent. Similarly, the powers flowing from the bus to any in-
service induction machines are netted with any in-service constant power load and constant current
load at the bus.
For any bus where voltage is being controlled by a remote generator, switched shunt, VSC dc line
converter, or FACTS device shunt element, an alarm is printed if the controlled bus is calculated as
an electrical equivalent while the voltage controlling equipment is retained. The controlling equip-
ment is then set to control local bus voltage and the scheduled voltage setpoint or band is not
changed.
an alarm is printed if the controlled bus is calculated as an electrical equivalent while the controlling
switched shunt bus is retained. The switched shunt’s control mode is not changed.
Equivalent branches introduced by activity EEQV are assigned the circuit identifier 99.
Equivalent loads introduced by activity EEQV are assigned the load identifier 99. If a load with the
identifier 99 already exists at a retained bus, activity EEQV adds any equivalent load to the load
already modeled as load 99; if such a load is associated with an adjustable bus load table for which
the load multiplier is zero, a mismatch is introduced at the corresponding retained bus.
Equivalent bus shunts introduced by activity EEQV are assigned the shunt identifier 99. If a shunt
with the identifier 99 already exists at a retained bus, activity EEQV adds any equivalent shunt
admittance to the fixed shunt already modeled as shunt 99.
9-10
9.3.5 Example: Equivalencing a Power Flow Case

In the savnw.sav power flow case there are three areas; FLAPCO, LIGHTCO and WORLD. The
WORLD area, which will be replaced by its equivalence network has 10 buses, three of which are
load buses and three ties to neighboring areas. As seen in Figure 9-2, the eleven buses are from
bus 3001 to bus 3018. The load buses are 3005, 3007 and 3008. The ties are between buses 3004,
3006 and 3008 to buses 152, 153 and 154 in adjacent areas respectively.
(a) WORLD Buses
(b) WORLD Load Buses
(c) Ties and WORLD Area Lines
Figure 9-2. Components of the WORLD Area in the savnw.sav

Power Flow Case
There are also several two-winding transformers in the WORLD area along with generators at
buses 3011 and 3018. A plot of the area is shown in Figure 9-3.
It is to be expected that the result of creating an equivalent of the WORLD area would be to leave
the two generator buses intact, (unless the threshold for retaining generation is chosen to be greater
that their generation) and leave the boundary buses 3004, 3006 and 3008 intact. This will result in
the removal of 5 of the 10 buses. In this example, area boundary buses are retained and the gen-
eration threshold is 0.00.
9-11
WORLD Area Boundary Buses
Figure 9-3. Pre-Equivalence Power Flow Diagram for the WORLD Area
After building an electrical equivalent of the WORLD area, the raw data appears as shown in
Figure 9-4.
It can be seen that the total load of 500 MW in the WORLD area has been retained but allocated to
the retained buses 3004, 3006, 3008 and 3011 with an identifier of 99. Note that bus 3008 already
had a load of 200 MW with an identifier of 1.
The buses at the boundaries have been maintained but now the number of buses is reduced to five.
There are now 6 new branches with in the WORLD area each with a circuit identifier of 99.
9-12
(a) Remaining World Area buses
(b) Original and New WORLD Area Load buses
(c) Retained Ties and Reduced Area

Lines in WORLD Area
Figure 9-4. Reduced Components of the WORLD Area after Building an

Electrical Equivalent
It should be noted that the slider file (savnw.sld) that was used to create the plotted results in
Figure 9-3 will not suffice for the new power flow with the WORLD area calculated as an electrical
equivalent. Five of the buses have been removed and new branches have been created. The user’s
selected color coding for the diagram properties will indicate that the buses and branches are
unbound, i.e., do not exist in the power flow case. This is because the slider file no longer matches
the network. A new or modified slider file will have to be produced.
Figure 9-5 shows the redrawn slider file presentation with the new branches and loads indicated.
Comparing this diagram with that of Figure 9-3 will clarify the changes in topology due to the
changes brought about by the equivalencing process.
9-13
Boundary buses
Figure 9-5. Redrawn One-Line Diagram to Match Topology after Building an

Electrical Equivalent
9-14
Program Operation Manual Net Generation with Load In a Subsystem

This section summarizes some general points regarding the equivalencing process and some
potential pitfalls to watch for.
The goal in equivalent construction is to generate efficient equivalents. An equivalent may be

regarded as making more efficient use of storage, and therefore improving computational speed of
solution of the network containing the equivalent, when the ratio of branches to buses in the equiv-
alent approaches that of real system (about 1.5). The relative efficiency of different equivalents of
a given system is best determined by trial and error. As a general rule, however, the reduction of a
group of external systems into a number of small equivalents is more efficient than their reduction
in one step to produce a single equivalent.
It is not advisable to net all generation in an external system when constructing an equivalent in
which more than a very few buses are to be retained. Type 2 buses have a generally beneficial
effect on the convergence of power flow iterations and excessive netting of generation removes this
effect from the composite power flow case when the equivalent is finally put to use. It is generally
advisable to retain some major generator and synchronous condenser buses and to net the small
generators that do not contribute strongly to the regulation of system voltage.
When generator netting has taken place in constructing equivalents, it is advisable to check for the
existence of a swing (Type 3) bus in the working case at the completion of the equivalencing calcu-
lation. Activity TREE may be used.
Bus type codes of 5, 6, and 7 are valid only during equivalent construction. All such type codes are
returned to 1, 2, and 3, respectively, by activity EEQV when the equivalencing process is complete.
The values of load and shunt admittance at each retained bus in the equivalent represent both
actual and equivalent quantities at these buses. Changing these values invalidates the equivalent.
Similarly, changing the status of any branches in the equivalent invalidates it.
A power flow working case containing elements introduced via an equivalent is identical in form to
a power flow case containing only real system elements and may be operated on by all PSS®E
activities, including activity EEQV. That is, it is permissible to construct an equivalent of an external
system that contains an equivalent.
®
PSS E GUI Users Guide, Section 14.1.1, Electrical Equivalent
Section 11.1, Building a Network Equivalent
9.4 Net Generation with Load In a Subsystem

Activity GNET
Run Activity GNET - GUI

Net generation with load (NETG/GNET/ImNet) Tab
9-15
Net Generation with Load In a Subsystem Program Operation Manual
Run Line Mode Activity GNET - CLI

ACTIVITY?
>>GNET
USER SPECIFIES THOSE TO BE NETTED
>>
None
The generation netting activity GNET changes the in-service generation to negative MVA load at all
Type 2 and 3 buses within the subsystem specified by the user.
Prior to running a global network equivalence, or when it is required merely to reduce the number
of generators modelled in a power flow case, generators can be removed by netting their output
with the load at a bus. Generators at all type 2 and 3 buses will be replaced with equivalent negative
load with these exceptions:
• Buses that are designated by the user at the start of the activity.
• Buses that are indicated by type codes 6 or 7 to be boundary or retained buses.
When replacing generation with an equivalent load, the power flow solution will remain the same,
i.e. re-solving the case after the netting process will not produce a different solution.
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. What is different from most
of the other subsystem selections is that, for netting generation, the user can choose to identify
those generators that will be netted (see the inside the selected subsystem in the figure) or choose
to identify those generators that will not be netted (see the outside option).
Activity GNET processes all Type 2 and 3 buses specified as inside the selected subsystem as
follows:
1. The type code is set to 1.
2. A new load entry is introduced at the bus.
3. PL of the new load is set to –PG.
4. QL of the new load is set to –QG.
Activity GNET summarizes processing, listing the number of buses netted with their loads.
When activity GNET introduces a load at a bus, the load is assigned the identifier 99. If a load with
the identifier 99 already exists at the bus, an unused two-digit identifier is assigned.
Because activity GNET processes only Type 2 and 3 buses, those generator buses that have been
designated as boundary buses, and hence have type codes of 6 or 7, do not have their generation
netted (refer to Section 5.2.5 Reading Power Flow Raw Data Files Created by Previous Releases
of PSS®E and activity EXTR).
9-16
Program Operation Manual Net Generation with Load In a Subsystem
9.4.1 Example of Net Generation with Load

In the savnw.sav power flow case there are three areas each of which has two generation buses.
Figure 9-6 shows the machine and load data from the spreadsheet. Note that the Load tab data has
been compressed to show the Load P and Q.
If the LIGHTCO Area is selected as the subsystem inside of which all generators will be netted, the
two generators there, on bus 206 and bus 211 will be netted. In the listing of loads, there will be two
new loads each assigned the identifier 99. If a load with the identifier 99 already exists at the bus,
an unused two-digit identifier is assigned. The two new loads are shown in the spreadsheet view in
Figure 9-7.
Prior to terminating the netting process, PSS®E prints a message at the Progress tab, or destina-
tion of the user’s choice, stating:
GENERATION AT nnnnn BUSES NETTED WITH THEIR LOAD

Because activity GNET processes only Type 2 and 3 buses, those generator buses that have been
netted. Furthermore, the netting process is not sensitive to interruption by the user.
Generation
Loads
Figure 9-6. Generation and Load in Power Flow Case savnw.sav
9-17
Net Generation with Load Outside of a Subsystem Program Operation Manual
New loads representing Generation at Bus 206 and Bus 211
Figure 9-7. Result of Netting Generation in the LIGHTCO Area
PSS®E GUI Users Guide, Section 14.1.2, Net Generation with Load
Section 11.1.2, Net Generation with Load at All Non-Boundary Buses
9.5 Net Generation with Load Outside of a Subsystem

Activity NETG
Run Activity NETG - GUI

Run Line Mode Activity NETG - CLI
ACTIVITY?
>>NETG
USER SPECIFIES EXCEPTIONS (I.E., THOSE NOT TO BE NETTED)
>>
None
The generation netting activity NETG changes the in-service generation to negative MVA load at all
Type 2 and 3 buses except those within the subsystem specified by the user.
9-18
Program Operation Manual Convert Induction Machines to Load
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV.
Activity NETG processes all Type 2 and 3 buses except those specified as outside the selected
subsystem as follows:
1. The type code is set to 1.
2. A new load entry is introduced at the bus.
3. PL of the new load is set to –PG.
4. QL of the new load is set to –QG.
Activity GNET summarizes processing, listing the number of buses netted with their loads.
When activity NETG introduces a load at a bus, the load is assigned the identifier 99. If a load with
the identifier 99 already exists at the bus, an unused two-digit identifier is assigned.
Because activity NETG processes only Type 2 and 3 buses, those generator buses that have been
netted (refer to Section 5.2.5 Reading Power Flow Raw Data Files Created by Previous Releases
of PSS®E and activity EXTR).
PSS®E GUI Users Guide, Section 14.1.2, Net Generation with Load
Section 11.1.3, Net Generation with Load at All Buses Except Boundary Buses
9.6 Convert Induction Machines to Load

Activity ImNet
Activity NetIm
Run Activity ImNet - GUI

Run Line Mode Activities ImNet, NetIm - CLI
ACTIVITY?
>>IMNET
ACTIVITY?
>>NETIM
None
9-19
Equivalencing Radial Buses Program Operation Manual
The induction machine netting API routine, ImNet, converts the boundary conditions of in-service
induction machines at Type 1, 2 and 3 buses to MVA load, and changes the status of each machine
processed to out-of-service.
The ImNet API routine includes the following among its inputs:
• A designation of the subsystem in which, or outside of which, induction machines are

to be processed; refer to Section 4.8, Subsystem Selection.
• An option to process induction machines either within, or outside of, the specified
subsystem.
Two line mode activities initiate the ImNet API routine: activity IMNET is used to process induction
machines within a subsystem, and activity NETIM is used to process induction machines outside
of a subsystem.
The ImNet API routine processes the induction machines at a bus as follows:
1. The sum of the powers flowing from the bus to all of the in-service induction machines at the
bus is calculated.
2. A new load is introduced at the bus. The load is assigned the identifier "99". If a load with
the identifier "99" already exists at the bus, an unused two-digit identifier is assigned.
3. The constant MVA load component of the new load is set to the sum of powers calculated
in 1. The constant current and admittance components of the new load are set to zero.
4. The status of each in-service induction machine at the bus is set to out-of-service.
The ImNet API routine summarizes its processing, listing the number of induction machines that
were replaced by load, and the number of buses involved.
When replacing an induction machine with an equivalent load, the power flow solution will remain
the same; i.e., re-solving the case after the netting process will not produce a different solution.
Because the ImNet API routine processes only in-service buses, those induction machine buses
that have been designated as boundary buses, and hence have type codes of 6 or 7, do not have
their induction machines converted to load (refer to Section 5.2.5, Reading Power Flow Raw Data
Files Created by Previous Releases of PSS®E and activity EXTR).
PSS®E Application Program Interface (API), Section 1.107, ImNett
9.7 Equivalencing Radial Buses

Activity EQRD
Run Activity EQRD - GUI

Equivalence radial / 2-point buses (EQRD/RDEQ) Tab
9-20
Program Operation Manual Equivalencing Radial Buses
Run Line Mode Activity EQRD - CLI

ACTIVITY?
>>EQRD
ENTER 1 TO EQUIVALENCE RADIAL BUSES ONLY:
>>
None
The radial bus equivalencing activity EQRD build an electrical equivalent for radial and, optionally,
two-point Type 1 buses, those buses connected to only two other buses. Activity EQRD uses the
same equivalencing algorithm as activity EEQV.
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. As in netting generation,
the user can choose to identify those buses that will or that will not be calculated as an electrical
equivalent. See PSS®E GUI Users Guide, Section 14.1, Building a Network Equivalent; buses that
will be calculated as an electrical equivalent are selected by the Net generation inside the selected
subsystem option and buses that will not be calculated as an electrical equivalent are selected by
the Net generation outside the selected subsystem option in [Equivalence Networks] dialog.
Activity EQRD builds an electrical equivalent for buses inside the specified subsystem of the
working case.
If sequence data is contained in the working case, the zero sequence network is calculated as an
electrical equivalent along with the positive sequence.
The radial equivalent process determines the buses to be calculated as electrical equivalents based
upon their current electrical connections. Suppose, for example, that bus I is a Type 1 bus con-
nected to two other buses by in-service branches and that there is an out-of-service branch from
bus I to a third bus. Assuming that bus I is not in the subsystem to be exempted from the equiva-
lencing process and that the two-point bus equivalencing option was enabled, bus I will be
calculated as an electrical equivalent.
It is neither necessary nor helpful to build an electrical equivalent of radial or two-point buses prior
to building a global electrical equivalent of a network or subsystem.
9-21
Buses that are always retained by the radial/two-point network reduction function are those:
• Connected by three-winding transformers

• With dc line converters connected to them
• With FACTS devices connected to them
• With GNE devices connected to them.
Whenever a two-point bus and its connected branches are calculated as electrical equivalents, the
resulting equivalent branch is assigned the smaller RATEA, RATEB, and RATEC of the connected
branches. If load existed at the two-point bus, the ratings of the equivalent branch should be
checked.
length assigned to the equivalent branch is the sum of the lengths of the equivalent paths. If parallel
branches existed between a retained bus and the equivalenced bus, the length of that path is
assumed to be the length of the longest of the parallel branches.
Equivalent branches, introduced by the radial equivalencing process, are assigned the circuit iden-
tifier 99. Equivalent branches between the same pair of buses have descending circuit identifiers
assigned starting at 99.
Equivalent loads introduced by the radial equivalencing process, are assigned the load identifier 99.
If a load with the identifier 99 already exists at a retained bus, the process adds any equivalent load
to the load already modeled as load 99. If such a load is associated with an adjustable bus load
table for which the load multiplier is zero, a mismatch is introduced at the corresponding retained
bus.
Table 9-3. Radial Bus Equivalencing Options
Limit building an electrical equivalent to only radial buses, otherwise
Equivalence radial buses only both radial buses and those buses connected to only two other buses
are to be eliminated.
Suppress equivalence of Enable to exclude transformer branches from the equivalencing
transformers process.
Suppress equivalence of zero Enable to exempt from a bus electrical equivalent any branches
impedance lines that are treated as zero impedance lines (refer to Section ).
Suppress equivalence of voltage or reactive power output is controlled by remote generation,
controlled buses switched shunts, VSC dc line converter, and/or FACTS device shunt
element.
If sequence data is contained in the working case, and zero sequence
Suppress equivalence of mutual couplings have been specified, any branch (and the buses it
mutually coupled branches connects) involved in a coupling is suppressed, when this option is
enabled.
Suppress equivalence of area
Keeps area boundaries intact when enabled.
boundary buses
9-22
Program Operation Manual Equivalencing Radial Buses
Table 9-3. Radial Bus Equivalencing Options (Cont.)
Suppress equivalence of zone
Keeps zone boundaries intact when enabled.
boundary buses
If the actual positive sequence impedance of any transformer being
calculated as an electrical equivalent differs from its nominal
value (refer to Transformer Impedance Correction Table Data),
the user may apply transformer impedance correction.
Apply transformer impedance If applied, the zero sequence impedance of each such transformer is
correction to zero sequence scaled by the same factor as is its positive sequence impedance.
Otherwise, all zero sequence transformer impedances are left at their
nominal values (i.e., the values entered in activities RESQ, TRSQ,
or SQCH). The same treatment applies to all transformers to be
calculated as electrical equivalents that are not at nominal
impedance.
9.7.1 Operation of Activity EQRD

Activity EQRD summarizes the number of buses removed from the working case. It rebuilds the
data arrays in the working case, compacting them to eliminate gaps created by the deleted equip-
ment. New bus sequence numbers, transformer sequence numbers, and so on are assigned.
At all type 1 buses being eliminated, the powers flowing from the bus to any in-service induction
machines are netted with any in-service load at the bus before the equivalent of the bus is
calculated.
9.7.2 Example: Equivalencing Radial Buses

Using the savnw.sav power flow case, and choosing to build an electrical equivalent for only radial
buses, with all other options suppressed, will result in the removal of one radial bus (bus 3007). The
load on that bus is moved to the neighboring buses 3005 and 3008 (see Figure 9-8).
9-23
Purple color indicates lines and bus no

longer bound to the power flow case. The
color is a user choice.
Two new buses added to buses 3005 and

3008. Existing load has identifier of 1. New
load has identifier 99.
Figure 9-8. Result of Radial Equivalencing Process

Activity EQRD determines the buses to be calculated as electrical equivalents based upon their
current electrical connections. Suppose, for example, that bus I is a Type 1 bus connected to two
other buses by in-service branches and that there is an out-of-service branch from bus I to a third
bus. Assuming that bus I is in the subsystem to be calculated as an electrical equivalent and that
the two-point bus equivalencing option was enabled, bus I is calculated as an electrical equivalent
by activity EQRD.
The use of activity EQRD as a preprocessor to activity EEQV is neither necessary nor helpful.
9-24
Program Operation Manual Equivalencing Radial Buses, with Exception
Buses connected by three-winding transformers are always retained by activity EQRD. The
converter station buses of dc lines are always retained by activity EQRD. Similarly, buses with
FACTS devices or GNE devices connected to them are always retained.
resulting equivalent branch is assigned the smaller RATEA, RATEB and RATEC (refer to Non-
Transformer Branch Data) of the connected branches. If load existed at the two-point bus, the
ratings of the equivalent branch should be checked.
Equivalent branches introduced by activity EQRD are assigned the circuit identifier 99. Equivalent
branches between the same pair of buses have descending circuit identifiers assigned starting at
99.
Equivalent loads introduced by activity EQRD are assigned the load identifier 99. If a load with the
identifier 99 already exists at a retained bus, activity EQRD adds any equivalent load to the load
Equivalent bus shunts introduced by activity EQRD are assigned the shunt identifier 99. If a shunt
with the identifier 99 already exists at a retained bus, activity EQRD adds any equivalent shunt
®
PSS E GUI Users Guide, Section 14.1.3, Radial and 2-Point Buses
Section 11.1.5, Radial and 2-Point Buses
9.8 Equivalencing Radial Buses, with Exception

Activity RDEQ
Run Activity RDEQ - GUI

Equivalence radial / 2-point buses (EQRD/RDEQ) Tab
Run Line Mode Activity RDEQ - CLI
ACTIVITY?
>>RDEQ
ENTER 1 TO EQUIVALENCE RADIAL BUSES ONLY:
>>
None
9-25
Equivalencing Radial Buses, with Exception Program Operation Manual
The radial bus equivalencing activity RDEQ builds an electrical equivalent for radial and, optionally,
two-point Type 1 buses outside the specified subsystem of the working case. Activity RDEQ uses
the same equivalencing algorithm as activity EEQV.
Table 9-4. Radial Bus Equivalencing Options, with Exception
Disable to build an electrical equivalent for both radial buses and those
Equivalence radial buses only
buses connected to only two other buses are to be eliminated
Suppress equivalence of
Enable to suppress building an electrical equivalent of transformers.
transformers
Suppress equivalence of zero Enable to suppress building an electrical equivalent of zero impedance
impedance lines lines (refer to Section )
Suppress equivalence of voltage or reactive power output is controlled by remote generation,
controlled buses switched shunt, VSC dc line converter, and/or FACTS device shunt
element.
If sequence data is contained in the working case, and zero sequence
Suppress equivalence of
mutual couplings have been specified, any branch (and the buses it
mutually coupled branches
connects) involved in a coupling is suppressed, when enabled.
Suppress equivalence of area
Keeps area boundaries intact when enabled.
boundary buses
Suppress equivalence of zone
Keeps zone boundaries intact when enabled.
boundary buses
If the actual positive sequence impedance of any transformer being
calculated as an electrical equivalent differs from its nominal value
(refer to Transformer Impedance Correction Table Data), the user
may apply transformer impedance correction.
Apply transformer impedance If applied, the zero sequence impedance of each such transformer is
correction to zero sequence scaled by the same factor as is its positive sequence impedance.
Otherwise, all zero sequence transformer impedances are left at their
nominal values (i.e., the values entered in activities RESQ, TRSQ, or
SQCH). The same treatment applies to all transformers to be calcu-
lated as electrical equivalents that are not at nominal impedance.
Activity RDEQ summarizes the number of buses removed from the working case. It rebuilds the
data arrays in the working case, compacting them to eliminate gaps created by the deleted equip-
ment. New bus sequence numbers, transformer sequence numbers, and so on are assigned.
At all type 1 buses being eliminated, their in-service constant admittance load, fixed shunt, and
switched shunt are netted before applying the network reduction equations described in Section
9.2, Methodology of the Electrical Equivalent. Similarly, the powers flowing from the bus to any in-
service induction machines are netted with any in-service constant power load and constant current
load at the bus.
9-26
Program Operation Manual Equivalencing Radial Buses, with Exception

Activity RDEQ determines the buses to be calculated as electrical equivalents based upon their
current electrical connections. Suppose, for example, that bus I is a Type 1 bus connected to two
other buses by in-service branches and that there is an out-of-service branch from bus I to a third
bus. Assuming that bus I is not in the subsystem to be exempted from equivalencing and that the
two-point bus equivalencing option was enabled, bus I is calculated as an electrical equivalent by
activity RDEQ.
The use of activity RDEQ as a preprocessor to activity EEQV is neither necessary nor helpful.
Buses connected by three-winding transformers are always retained by activity RDEQ. The
converter station buses of dc lines are always retained by activity RDEQ. Similarly, buses with
FACTS devices or GNE devices connected to them are always retained.
resulting equivalent branch is assigned the smaller RATEA, RATEB, and RATEC (refer to Non-
Transformer Branch Data) of the connected branches. If load existed at the two-point bus, the
ratings of the equivalent branch should be checked.
Equivalent branches introduced by activity RDEQ are assigned the circuit identifier 99. Equivalent
branches between the same pair of buses have descending circuit identifiers assigned starting at
99.
Equivalent loads introduced by activity RDEQ are assigned the load identifier 99. If a load with the
identifier 99 already exists at a retained bus, activity RDEQ adds any equivalent load to the load
Equivalent bus shunts introduced by activity RDEQ are assigned the shunt identifier 99. If a shunt
with the identifier 99 already exists at a retained bus, activity RDEQ adds any equivalent shunt
9-27
Converting Net Boundary Bus Mismatch Program Operation Manual
®
PSS E GUI Users Guide, Section 14.1.3, Radial and 2-Point Buses
Section 11.1.4, Radial Bus and 2-Point Buses, with Exception
9.9 Converting Net Boundary Bus Mismatch

Activity BGEN
Run Activity BGEN - GUI

Net boundary bus mismatches (BGEN) Tab
Run Line Mode Activity BGEN - CLI
ACTIVITY?
>>BGEN
>>
AB
Whenever a subsystem is removed from a solved power flow case, there will be mismatches at
those buses that are boundary buses. The boundary bus balance activity BGEN converts the mis-
match at boundary buses to equivalent load and/or generation. It is intended to be used following
the removal of a subsystem from a solved working case, with the flows to the deleted subsystem
replaced by load and/or generation at those retained buses that were directly connected to the
removed subsystem.
The user specifies the type of boundary condition modifications to be used from the following
options:
Table 9-5. Net Boundary Bus Mismatch Options
Option Description
Model the inflow of power to the retained area as a generator and the
outflow of power as a load. A new machine is introduced at any
Generator for inflow, load for outflow boundary bus at which there was a net inflow of active power from the
(default) removed subsystem into the retained subsystem; at boundary buses
where there was a net outflow of active power, a new load is
introduced.
A new machine is introduced at each boundary bus regardless of the
All equivalent generators
direction of power flow at the boundary.
All equivalent loads Each flow to the deleted subsystem is replaced by a new load.
9-28
Program Operation Manual Building a Three-Sequence Electrical Equivalent
The user may process the entire working case or specify the subsystem for mismatch netting (refer
to Section 4.8 Subsystem Selection) by bus subsystem, area, zone, owner, or basekV.
When a bus has a mismatch in excess of 0.5 MVA, it is assumed to be a boundary bus and a new
load or machine, as selected above, is introduced. Boundary buses are reported in ascending bus
number order or alphabetical order, as described in Section 4.9 Subsystem Reporting.
When activity BGEN introduces a machine at a bus, it assigns the machine identifier 99; if a
machine 99 already exists at the bus, an unused two-digit identifier is used. Similarly, when activity
BGEN introduces a load at a bus, the load is assigned the identifier 99; if a load with the identifier
99 already exists at the bus, an unused two-digit identifier is assigned.
Activity BGEN may be terminated by entering the AB interrupt control code.
®
PSS E GUI Users Guide, Section 14.1.4, Net Boundary Bus Mismatch
Section 11.1.6, Net Boundary Bus Mismatch
9.10 Building a Three-Sequence Electrical Equivalent

Activity SCEQ
Run Activity SCEQ - GUI

Build three sequence equivalent (SCEQ) Tab
Run Line Mode Activity SCEQ - CLI
ACTIVITY?
>>SCEQ
USER SPECIFIES SUBSYSTEM TO BE EQUIVALENCED
>>
None
The three sequence equivalencing activity SCEQ constructs network equivalents of the positive and
zero sequence networks, and calculates source impedances at equivalent source nodes for all
three sequences in preparation for the unbalanced fault analysis activities of PSS®E. The user may
save the equivalents in the form of a Power Flow Raw Data File and a Sequence Data File by spec-
ifying filenames.
9.10.1 Creating Short Circuit Equivalents

While network reduction for fault analysis work could be handled with the standard equivalent han-
dling activities covered in the previous sections, PSS®E provides the user with a superior process
for creating short-circuit equivalents that is designed specifically for fault analysis applications.
9-29
Building a Three-Sequence Electrical Equivalent Program Operation Manual
This process applies all of its operations to all three sequences in parallel, using the same topolog-
ical boundary definitions for each, as shown in Figure 9-9. This process handles all steps of the
equivalencing process automatically so that its single execution, in effect, accomplishes the fol-
lowing functions:
• Separates the external system in the power flow case.

• Builds an equivalent.
• Replaces the detailed external system model with the equivalent.
• Rejoins the study system onto the equivalent.
A single step in the process replaces the full system model in the power flow case with a reduced
model consisting of the detailed study system and an equivalenced external system. The boundary
buses of the external system are retained so that tie branches appear as real system elements in
the reduced system model.
External System
Positive Study
Sequence System
Negative
Sequence
Zero
Sequence
Figure 9-9. Pictorial Image of Power Flow Case with Equivalenced Sequence
Networks
The short-circuit equivalencing process performs a simple network reduction without regard to
loads, transformer phase shift, or pre-event voltages. All generators in the external system are rep-
resented by simple Norton equivalents so that their effective impedances (i.e., Norton shunt
admittances) and positive-sequence source currents can be transferred to the boundary buses by
standard network mathematics. The process operates on a standard fault analysis model but with
FLAT pre-event voltages.
The network reduction is performed by setting up the partitioned admittance matrix of the external
system:
Ib YbbYbn Vb
=
In YnbYnn Vn
(9.4)
where:
b Denotes boundary buses.

n Denotes buses to be deleted.
9-30
Ib, In Contains either zero or generator Norton source current as calculated the generator
conversion process.
The generator internal impedances, Zpos, Zneg, Zzero, where appropriate, are included in the net-
work as shunt elements and are accounted for by the diagonal terms of the admittance matrix. The
positive-sequence source currents are taken as ISORCE = (1./Zpos). The admittance matrix and
equivalent source currents of reduced network are then obtained from the elimination formula:
(Ib - YbnYnn-1In) = (Ybb - YbnYnn-1Ynb)Vb (9.5)
9-31
After calculating these matrix equivalents of the reduced network, the short-circuit equivalencing
process automatically deletes the true data for the external system from the working case and
replaces it with data for the equivalent network. This equivalent network comprises:
• Branches with series impedance but no charging capacitance or shunts, and with cir-
cuit identifier 99.
• Equivalent generators with rating equal to system MVA base and a nonzero positive-
sequence source impedance.
• Negative- and zero-sequence source impedance for each equivalent generator.
• Positive-, negative-, and zero-sequence equivalent shunts.
This equivalent can have an equivalent generator at every boundary bus. As indicated by the left-
hand side of (9.5), the source currents of these generators are the compendium of source current
of any real generators at the boundary bus plus equivalent source currents representing the effect
of generators at deleted buses. The short-circuit equivalencing process replaces all real generators
at each boundary bus with a single equivalent generator and identifies it as such by assigning it
machine number 9. It also assigns the circuit number 99 to all equivalent branches.
All shunt admittances (charging, reactors, capacitors, etc.) arising in the equivalent, except the gen-
erator Norton admittances, are collected together and included in the equivalent as a single shunt
admittance at each boundary bus. These shunts and the generator Norton admittances are always
connected as shunts to ground when the equivalent is used within PSS®E.
The form of the equivalent is illustrated in Figure 9-10. Each sequence equivalent is contained in
the working case as fault analysis data for equivalent branches and generators. Each equivalent is
joined by real tie branches to the study system, which remains in the working case, completely
unaltered.
The generator positive- and negative-sequence source impedances in the power flow case need
not be identical. If they are different, the positive-sequence and negative-sequence reduced admit-
tance matrices will be different. The standard PSS®E negative-sequence model format recognizes
differences between positive and negative sequence only in the generator source impedances,
Zpos and Zneg.
9-32
Real Branches
to Study
System
Bus to be Deleted Boundary

Real System
Buses
ISORCE ISORCE
1 1
-------------- --------------
Z Z
pos pos Real Branches
to Study System
Sequence Networks
Prior to Equivalencing
1 1 1 1
-------------- , ---------------- -------------- , ----------------
Z Z Z Z
neg zero neg zero
ISORCE
Real
Branches
to Study
System
ISORCE
Equivalent Sequence
Equivalent Networks After
Source Circuits Equivalencing
1Z
seq
Equivalent Generator
Source Impedances
Figure 9-10. Form of Sequence Equivalents Built the Short-Circuit

Equivalencing Process
9-33
Hence when the short-circuit equivalencing process encounters a negative-sequence equivalent

branch impedance different from the corresponding positive-sequence value, it ignores it and uses
the positive-sequence value in both sequences. An alarm message is given whenever the positive
and negative-sequence branch impedances differ by more than 5%. This approximation in the
reduction and equivalencing of the negative sequence occurs only when generator Zpos and Zneg
values are different and is rarely a significant influence on the accuracy of the equivalent.
9.10.2 Constructing a Short Circuit Equivalent

Activity SCEQ works on the basis of classical fault analysis assumptions. External systems,
following the terminology of Section 9.1.1 Nomenclature of Equivalents, are defined according to
the specified subsystem; and activity SCEQ handles the data processing functions automatically.
Activity SCEQ requires that the working case be in the following format:
1. The network must reflect classical fault analysis assumptions. That is, a uniform voltage
profile must be specified, no non-zero in-service loads may be present in any of the
sequence networks, and all transformers must be at zero phase shift angle. The set up of
these conditions is automated by activity FLAT with classical fault analysis option.
2. The generator source currents must be determined on the basis of the positive sequence
generator impedances and the flat generator conditions described in (1) above. This initial-
ization is accomplished with activity CONG using one of the fault analysis positive sequence
machine impedances (usually, either transient or subtransient).
If these conditions are not satisfied when activity SCEQ is run, an appropriate alarm message is
printed and activity SCEQ is terminated.
9-34
9.10.3 Short Circuit Equivalent Options

The user identifies the buses or subsystem to be calculated as electrical equivalents by area,
owner, zone, basekV or by individual bus. The equivalencing process generates an alarm and
terminates if either none or all buses are to be retained.
Table 9-6. Short Circuit Equivalent Options
Option Description
If the actual positive sequence impedance of any transformer in the subsystem
to be calculated as an electrical equivalent differs from its nominal value, the
user is free to specify the treatment of the zero sequence impedance of all such
transformers.
Apply impedance
If enabled, the zero sequence impedance of each such transformer is scaled by
correction to zero
the same factor as is its positive sequence impedance.
sequence
If disabled (default), all zero sequence transformers are left at their nominal
values (i.e., the raw data values entered to populate the power flow case). The
same treatment applies to all transformers in the subsystem to be calculated
as an electrical equivalent that are not at nominal impedance.
Branch threshold Any equivalent branch where magnitude of impedance is greater than this toler-
tolerance ance is not retained in the equivalent. The default value is 10 per unit.
Raw data output (*.raw) Optional. The user can save the equivalents in the form of a Power Flow
file Raw Data File.
Sequence data (*.seq) Optional. The user can save the equivalents in the form of a Sequence
output file Data File.
9.10.4 Operation of Activity SCEQ

If sequence data is not contained in the working case (i.e., activity RESQ has not been executed),
an appropriate message is printed, the equivalent is constructed in the normal manner, but only the
positive sequence equivalent is valid.
If an equivalent of the entire working case is constructed, Type 5 and 6 buses are retained as Type
1 and 2 buses, respectively. The user may specify subsystem data (refer to Section 4.8 Subsystem
Selection) by bus subsystem, area, zone, owner, or basekV. Activity SCEQ generates an alarm and
terminates if either none or all buses are to be retained.
The portion of the working case to be exempted from equivalencing is (temporarily) removed from
the working case, and all radial and two-point Type 1 buses are calculated as electrical equivalents
(refer to RDEQ). Then the standard output of activity ORDR is tabulated as the processing of the
positive sequence network commences.
The user may specify branch threshold tolerance (default = 10 pu); any equivalent branch where
magnitude of impedance is greater than this tolerance is not retained in the equivalent.
If the actual positive sequence impedance of any transformer in the subsystem to be calculated as
an electrical equivalent differs from its nominal value (refer to Transformer Impedance Correction
Table Data), the user may apply impedance correction to zero sequence. If applied, the zero sequence
impedance of each such transformer is scaled by the same factor as is its positive sequence imped-
ance. Otherwise, all zero sequence transformers are left at their nominal values (i.e., the values
entered in activities RESQ, TRSQ, or SQCH). The same treatment applies to all transformers in the
9-35
subsystem to be calculated as electrical equivalents that are not at nominal impedance.
The processing of the positive and negative sequence networks is completed, and the zero
sequence calculation commences. The summary output of the optimal ordering function is printed,
the zero sequence network equivalent is constructed, and activity SCEQ combines the equivalent
and detailed system sections.
When three or more buses are all connected together by zero impedance lines (refer to Zero Imped-
ance Lines), either all may be calculated as electrical equivalents, all may be retained, or one may
be retained. If the bus type codes are such that more than one but not all the buses in such a group
of buses are to be retained, activity SCEQ prints an appropriate message and retains all buses in
the group.
9.10.5 Form of the Equivalent

The equivalent constructed by activity SCEQ is present in the working case along with the unequiv-
alenced portions of the system in the form required for fault analysis work under classical
assumptions. There are no operations required to combine system sections.
In constructing the equivalent, all non-boundary Type 1 and 2 buses in the designated external
system are eliminated, and all Type 5 and 6 buses are retained as Type 1 or 2 buses, respectively.
Normally, the boundary buses from within the subsystem being calculated as electrical equivalents
are those that are connected to buses outside of the specified subsystem. However, when the
subsystem to be calculated as an electrical equivalent is specified by bus only, Type 1 and 2 buses
specified are calculated as electrical equivalents, with the boundary buses being those buses to
which they are connected and which are not among those specified.
All boundary buses that represent equivalent sources are set to Type 2 buses with appropriate
Norton source currents and source impedances. Boundary buses with no equivalent source are set
to Type 1. Ground paths other than those resulting from equivalent generator impedances are
included as positive (and hence, negative) sequence shunts and zero sequence shunts.
The topology of the equivalent network is determined from the positive sequence network. As is the
case with the physical system, there may be branches in the positive (and negative) sequence
network for which the zero sequence path is open.
If, in the original data, positive and negative sequence generator impedances are equal, the corre-
sponding sequence source and branch impedances in the equivalent will be identical. For
generators initially characterized by different positive and negative sequence impedances, the
corresponding sequence source and branch impedances will differ in the equivalent. Because the
fault analysis activities of PSS®E assume that the branch impedances are identical in the positive
and negative sequence networks, activity SCEQ gives an approximation of the negative sequence
branch impedances by using those of the equivalent positive sequence network. Activity SCEQ
prints a warning message any time the calculated negative sequence branch impedance differs
from the positive sequence impedance by more than 5% of the positive sequence value.
9-36
9.10.6 Example: Short Circuit Equivalencing of a Power Flow Case

In the savnw.sav power flow case, one of the three Areas (FLAPCO) is subject to a short-circuit
equivalencing. Figure 9-11 shows the 6 buses in the Area. It can be seen that there are two gener-
ators (at buses 101 and 102); one bus (151) with a shunt reactor and one bus (154) with a shunt
capacitor. While there are two loads shown on bus 154, the loads themselves are part of Area
LIGHTCO.
The short-circuit equivalencing removes the two generator buses and original area branches. An
equivalent generator is attached to bus 151. Three new equivalent branches are created linking
buses 151, 152 and 153 (see Figure 9-12). Branch impedances are shown.
FLAPCO Area Buses
Figure 9-11. Pre-Equivalence Power Flow One-Line Diagram Showing the

FLAPCO Area Buses
9-37
Equivalent Generator Equivalent Branches
Figure 9-12. Equivalent FLAPCO Area
9-38

Activity SCEQ requires that the working case reflect classical assumptions. In setting up this condi-
tion, activity CONG using one of the fault analysis machine impedance options must be executed
after the execution of activity FLAT with classical fault analysis option.
Activity SCEQ is not capable of handling the case in which zero sequence mutual couplings span
the boundary of the external system to be calculated as an electrical equivalent and the portion of
the system to be retained in detail. Any such mutual generates an alarm, the mutual is ignored, and
processing continues.
Activity SCEQ is not able to build an equivalent of a subsystem in which a dc line, FACTS device,
or GNE device is present. If any dc lines, FACTS devices, or GNE devices are encountered, an
alarm message is printed but activity SCEQ continues. Upon completion of activity SCEQ, the user
should ensure that any such dc lines, FACTS devices, and GNE devices are blocked before using
the case in any fault analysis calculation.
Activity SCEQ prints an appropriate error message if the number of equivalent source nodes (i.e.,
generators), fixed bus shunts, or branches exceeds the capacity limits of PSS®E.
PSS®E GUI Users Guide, Section 14.2, Building a Three-Sequence Electrical Equivalent
Section 11.2, Building a Three-Sequence Electrical Equivalent
9-39
9-40
Chapter 10
Unbalanced Fault Analysis
Chapter 10 - Unbalanced Fault Analysis
10.1 Overview: Short-Circuit Fault Analysis

Fault analysis in PSS®E is based on a symmetrical component system representation and treated
as a direct extension of the power flow activity group. The positive-sequence system model as
established in power flow work is used directly in fault analysis. The negative- and zero-sequence
system representations for fault analysis work are established simply by appending negative- and
zero-sequence parameter values to the parameter lists describing the system for power flow
purposes. The power flow file always includes provision for negative- and zero-sequence parame-
ters of every system component. This data may be introduced at any time, and after being
introduced, it is saved and retrieved as an integral part of a Saved Case.
PSS®E includes several fault analysis procedures.
• Detailed analysis of complicated multiple unbalanced situations presenting a complete

system solution and overall system-oriented output comparable to that of a power flow.
• Automatic sequencing calculations intended for the more routine work of examining
simple ground faults at a large number of system locations.
• Circuit breaker duty based on ANSI and/or IEC standards
• Circuit breaker Detailed fault analysis
• Positive sequence pi equivalent for representation of transmission line using single
pole operation
Each of these will be discussed in this chapter.
The overriding principle of fault analysis data management in PSS®E is that the modeling detail and
component status information is dictated by the positive-sequence model. Negative- and zero-
sequence data values are held in the power flow file only where their values are different from the
corresponding positive-sequence values. In setting up the negative and zero-sequence networks,
PSS®E assumes the following:
1. All transmission branches (lines and transformers) have the same impedance, charging,
and line-connected shunt characteristics in the negative-sequence as in the positive-
sequence.
2. All transformers have phase shift in the negative-sequence equal and opposite to that in the
positive-sequence.
10-1
Unbalanced Fault Analysis PSS®E 34.2
Appending Sequence Data to the Power Flow Case Program Operation Manual
3. All zero-sequence branches, both transmission branches, line-connected shunts, and bus
connected shunts are assumed to have infinite zero-sequence impedance unless a different
value is specified.
4. All constant MVA and constant current load specified in the positive-sequence data are
converted automatically to constant shunt admittance in the positive-sequence network.
5. All loads are automatically represented by the same shunt admittance in the negative-
sequence as in the positive-sequence unless a different negative-sequence shunt admit-
tance is specified.
6. Loads are open circuits in the zero-sequence unless represented specifically as grounded
with a non-zero by entry of a value of zero sequence shunt admittance.
7. Lines considered zero-impedance branches in the positive-sequence are considered as

zero impedance in the negative- and zero-sequence.
It is evident, then, that neglect of the inherent 30° phase shift of wye-delta transformers results in
the following:
• Calculated sequence and phase currents that are correct in all branches on the fault
side of the transformer.
• Calculated sequence currents that are correct in amplitude but erroneous in phase in
all branches that are removed from the fault by a transformer.
• Erroneous values of phase current in all branches separated from the fault by a wye-
delta transformer.
10.2 Appending Sequence Data to the Power Flow Case

Activity Appending Sequence Data to the Power Flow Case
As described in the previous pages in Section 5.5, Reading Sequence Data, the user is required to
prepare a Sequence Data file (type *.seq) in the data record formats shown and in the required
order of data categories. After the sequence data has been appended to a power flow case, it
accompanies the network as the case is saved and retrieved.
Selecting and opening the file will initiate appending the data. Progress in importing of each data
category will show at the Progress device (see Figure 10-1).
10-2
PSS®E 34.2 Unbalanced Fault Analysis
Program Operation Manual Fault Calculation Modeling Assumptions
Reading IC, version number...
Reading machine impedance data...
Reading load data...
Reading non-transformer branch data...
Reading mutual coupling data...
Reading transformer data...
Reading switched shunt data...
Reading fixed bus shunt data...
Reading induction machine data...
Figure 10-1. Output when Appending Sequence Data
If the change code parameter IC in the first record of the Sequence Data File is set to one and
sequence data had not previously been read for the system in the working case, an alarm is printed
and the data is processed as if IC was set to zero. Remember that a code of zero indicates that the
data is being appended to the positive sequence model sequence for the first time.
As for positive sequence data, the raw Sequence Data File is read in free format with data items
separated by a comma or one or more blanks. Each category of data except the change code is
terminated by a record specifying an I value of zero. Specifying a data record with a Q in column
one is used to indicate that no more data records are to be supplied.
10.3 Fault Calculation Modeling Assumptions
10.3.1 Detailed Fault Calculation Model

The system under study is modeled by three symmetrical component sequence networks based on
the positive-, negative-, and zero-sequence parameters of the three-phase power system elements.
The topology of the system, the positive-sequence parameters of all components (except genera-
tors in some cases), and the pre disturbance system conditions, are all taken from the power flow
Saved Case. Fault analyses may be made with the same level of system modeling as used in a
power flow study. Specifically, fault analyses may do the following:
• Recognize both reactance and resistance and include all actual shunt branches and
line charging in the three sequence networks.
• Recognize both the magnitude ratio and phase shift of all transformers, including the
inherent shift of delta-wye transformers if it is entered in the power flow data.
• Recognize the actual spread of internal voltage magnitude and phase angle of gener-
ators as initialized from a solved power flow case.
• Recognize loads by converting them to equivalent constant shunt admittance.
10-3
Fault Calculation Modeling Assumptions Program Operation Manual
The level of system modeling detail used in a fault analysis calculation is controlled by manipulating
the positive-sequence (or power flow) data in the working case into the required form before
commencing fault analysis work. The detailed, unbalanced fault analyses activities, described in
Section 10.6 Performing Fault Analysis with Multiple Unbalances, usually operate on the assump-
tion that the system is modeled in the highest level of detail. In these activities, although results
corresponding to a simplified modeling basis are obtained if appropriate elements of data have null
values, simplified calculating algorithms are not used. Therefore, no computing time advantage is
gained by simplifying the system model. One advantage to simplifying the model, as described in
Section 9.3.4 Special Conditions for Fault Calculations is to allow comparison of PSS®E results with
those obtained from other software packages which usually use a more simple or classical model.
10.3.2 Detailed Fault Calculation Models for DC Lines and FACTS Devices
If any unblocked dc lines or in-service FACTS devices are present in the working case, the user can
specify their treatment in the fault analysis solution. The options are to:
• Block the device: dc lines and FACTS devices are treated as open circuits (i.e., fully
blocked bridges) in all three sequences, regardless of their actual prefault loadings as
given by the initial condition power flow.
• Represent as load: the apparent ac system complex loads are converted to positive
sequence constant admittance load at the buses at which these quantities are injected
into the ac system during normal power flow work. In the negative and zero sequence
networks, dc lines and series FACTS devices are represented as open circuits. The
equivalent positive-sequence shunt admittance is derived from the values of PAC and
QAC given by the initial condition power flow at each converter ac bus.
Neither of these two representations should be regarded as exact. The first may be regarded as
reasonable for the calculation of fault-current duty on circuit breakers because converter controls
are usually designed to limit their fault currents to values equal to or less than normal load current.
Only one of these options may be selected in any execution of the unbalanced network solutions.
The selected option applies to all dc lines and FACTS devices in the working case. The default
handling of these devices is to block.
10.3.3 Simplified Fault Calculation Model

The multiple unbalanced fault calculation described in SCMU and the automatic sequencing fault
calculations described in ASCC base their calculations on a fully detailed pre-fault initial condition
corresponding to a solved power flow.
Since the use of a simplified model representation is often applicable in the automatic sequencing
fault calculations, enabling the flat conditions option of activity ASCC results in the application of
the following simplifying assumptions:
• A uniform voltage profile of unity magnitude at zero phase angle is assumed.

• Generator and induction machine powers are assumed to be zero.
• Loads are neglected in the positive and negative sequence networks.
• Grounded loads are represented in the zero sequence network.
• Fixed bus shunts and switched shunts are neglected in all three sequence networks.
• Line charging capacitances and line connected shunt elements are neglected in all
three sequence networks.
10-4
Program Operation Manual Detailed Unbalanced Fault Types
• All transformers, including generator step-ups, are assumed to be at nominal ratio, zero
phase shift angle.
• Transformer magnetizing admittances are neglected in the positive and negative
sequence networks.
• The zero sequence ground ties created by grounded transformer windings are
represented.
• Dc lines and FACTS devices are ignored.
When different degrees of simplification than are supplied by the flat conditions option are needed,
they may be imposed on the system model before initiating the fault calculations. Such special
modeling assumptions are usually implemented with activity FLAT (see Section 9.10). When spec-
ifying simplifying assumptions with activity FLAT, note that:
• the simplifying conditions are established in the system model before initiating the fault
calculation;
• the flat conditions option of activity ASCC should not be selected;
• the fault calculations assume the detailed calculation model, but they use network
parameters that have been set to appropriate flat condition values according to the
options specified to activity FLAT.
10.4 Detailed Unbalanced Fault Types

Activity Detailed Unbalanced Fault Types
The multiple, unbalanced network solution allows the user to apply simultaneously, at any bus, on
any phase, any or all of the following unbalances or faults:
10.4.1 Bus Faults

• One or two single-line-to-ground faults (L-G) with specified fault impedances, ZF and
ZG (see Figure 10-2).
• One or two line-to-line (L-L) or double-line-to-ground (L-L-G) faults with specified fault
impedances, ZF and ZG
Three-phase bus faults are simulated with a combination of one L-G fault and one L-L-G fault.
Consequently, if a three-phase bus fault is simulated, there remain one L-G and one L-L-G fault
application available. PSS®E assumes that any three-phase fault is simulated using the second
single-line-to-ground fault and the second double-line-to-ground fault with all fault impedances set
to 0.0+j0.0. Figure 10-2 shows the fault combinations together with the impedances available for
selection. It shows how a double-line-to-ground fault can be converted to a line-to-line fault by
assuming an infinite impedance for the impedance to ground ZG.
10-5
Detailed Unbalanced Fault Types Program Operation Manual
Figure 10-2. Using L-G and L-L-G Fault Combinations
10.4.2 Phase Closed Unbalances

The single and double phase closed unbalances are applicable to represent discrete components
such as series capacitors and jumpers, but are not applicable to transmission lines. The unbalance
simulation places series elements of the specified phase impedance between designated buses in
the selected phases (see Figure 10-3). The unbalances available are:
• Single phase, with specified impedance, closed between a pair of buses.

• Two phases, with equal specified impedance, closed between a pair of buses.
Figure 10-3. Phase Closed Series Unbalances
It should be noted that phase impedances will be placed in parallel with any branch which already
exists, in the power flow case, between the selected buses. If the user wishes to use these models
to represent an unbalance in an existing branch, then that branch must be switched out of services
to avoid duplication (see Section 10.6.5 Phase Closed Unbalances).
10-6
Program Operation Manual Preparing Sequence Network for Unbalanced Network Solution
10.4.3 Line Faults

The inter sequence solution method used in PSS®E for unbalanced fault calculations can apply
faults only at buses. The application of a fault at some point along a line, therefore, requires the
insertion of a dummy bus in the line at the fault location. The fault will be applied at the dummy bus.
The user could introduce a dummy bus and re-organize the line topology to accommodate this type
of fault. This is not necessary. PSS®E provides for the temporary addition of the required dummy
buses and automates the rerouting of branches to the dummy buses and splitting of the zero
sequence mutual couplings on either side of the faulted dummy bus.
The simulation of a fault at any point on a line is designated as the fault slider. The line may be
represented with both ends closed or with one end opened. In either of these two topologies, one
of the following may be applied at any point along the line:
1. The second L-G fault.
2. The second L-L-G fault.
3. A three phase fault utilizing both the second L-G fault and the second L-L-G fault.
The dummy bus, introduced at the fault point is automatically numbered 999999. If one end of the
faulted line is opened and the fault point is not at the line end position, a second dummy bus,
numbered 999998, is introduced at the opened end (see Figure 10-4).
Figure 10-4. Allocation of Dummy Buses for In-Line Slider Faults
10.5 Preparing Sequence Network for Unbalanced Network
10-7
Preparing Sequence Network for Unbalanced Network Solution Program Operation Manual
Solution
Activity SEQD
Run Activity SEQD - GUI

Fault > Setup network for unbalanced solution (SEQD)…
[Setup Network for Unbalanced Solution]
Run Line Mode Activity SEQD - CLI
ACTIVITY?
>>SEQD

AB
The sequence network set up activity SEQD prepares the working case for the unbalanced network
solution activity SCMU or the separate pole circuit breaker duty activity SPCB. This process
involves taking the positive sequence network (i.e., the power flow case) and the various sequence
data arrays defining the negative and zero sequence networks, and setting up the SEQD temporary
file in the form required by activities SCMU and SPCB. Activity SEQD does not modify the contents
of the working case itself.
If sequence data has not been read into the working case via activity RESQ, an appropriate error
message is printed and activity SEQD is terminated.
If any unblocked dc lines or in-service FACTS devices are present in the working case, the user
must specify their treatment:
• Block and ignore

• Convert to constant admittance load
If dc lines and FACTS devices are to be represented as load, the apparent ac system complex loads
are converted to positive sequence constant admittance load at the buses at which these quantities
are injected into the ac system during normal power flow work. In the negative and zero sequence
networks, dc lines and series FACTS devices are represented as open circuits.
Only one of these options may be selected in any execution of SEQD and the unbalanced network
solutions which follow. The selected option applies to all dc lines and FACTS devices in the working
case. The default handling of these devices is to block.
If the actual positive sequence impedance of any transformer in the working case differs from its
nominal value (refer to Transformer Impedance Correction Tables), the user must specify the treat-
ment of the zero sequence impedance of all such transformers.
If transformer correction is applied to the zero sequence, the zero sequence impedance of each
such transformer is scaled by the same factor as is its positive sequence impedance. Otherwise, all
zero sequence transformer impedances are left at their nominal values (i.e., the values entered in
activities RESQ, TRSQ, or SQCH). The same treatment applies to all transformers in the system
that are not at nominal impedance.
10-8
Program Operation Manual Preparing Sequence Network for Unbalanced Network Solution
Activity SEQD performs the following computations on the working case:
1. All positive sequence loads are converted to fixed shunt admittances on the basis of the
voltage at each load bus in the working case. This is functionally equivalent to the use of
activity CONL in switching study work.
2. For loads for which a non-zero negative sequence load has been specified, it is used to
represent the load in the negative sequence. For loads for which the negative sequence
load is zero, the positive sequence value calculated in (1) above is used to represent the
load in the negative se-quence. Refer to Load Sequence Data.
3. All generator and induction machine positive sequence sources are initialized and fixed to
correspond to their generator terminal bus conditions in the working case. This is function-
ally equivalent to the use of activity CONG in switching study work. This step is performed
unless generators have previously been converted; refer to Application Notes.
4. An ordering for the positive and negative sequence networks is determined and the stan-
dard summary of activity ORDR is printed at the Progress device. This is functionally
equivalent to the use of activity ORDR in switching study work.
5. The positive and negative sequence admittance matrices are constructed and factorized. In
switching study work this function is handled by activity FACT.
6. The zero sequence network is ordered and the standard summary is printed.
7. The zero sequence network admittance matrix is constructed and factorized.
If, in the process of building the sequence network admittance matrices, isolated buses are
detected, they generate an alarm. Isolated buses in the positive and negative sequence networks
indicate an improperly specified power flow case. Isolated buses in the zero sequence network,
although they have generated alarms, are permitted and require no special treatment. When the
fault analysis warning option is disabled (refer to Section 3.3.3 Program Run-Time Option Settings
and activity OPTN), the isolated bus tabulations are suppressed. In either case, the total number of
isolated buses in the sequence networks is tabulated.
Following completion of the processing of the zero sequence network, any three-winding trans-
formers with two windings in-service and one winding out-of-service are tabulated (refer to Zero
Sequence Transformer Data). The user should verify that the zero sequence impedances and
connection codes of the two in-service windings result in the proper zero sequence modeling of
such three-winding transformers.
Activity SEQD is called without being specifically selected during the execution of activity ASCC and
during calculation and application of unbalanced bus fault and of branch unbalance.
The isolated bus summaries may be terminated by entering the AB interrupt control code.
10-9
Preparing Sequence Network for Unbalanced Network Solution Program Operation Manual

The processing of activity SEQD assumes that the working case is in the following condition:
1. The bus boundary conditions and transmission network modeling represent a valid pre-fault
condition. The level of detail in network modeling may span the spectrum from classical
short circuit study assumptions through full power flow style representation with the initial
condition being a solved power flow case.
2. The power flow generator data items defining machine bases and step-up transformer
impedances (if the step-up transformer is not explicitly represented as a network branch)
must be included in the working case (refer to Generator Data and Section 12.2.3 Generator
Step-Up Transformers).
3. The sequence data arrays must have been filled with the data describing the negative and
zero sequence networks, along with the three sequence generator impedances for all in-
service machines. Refer to Section 5.5.1 Sequence Data File Contents.
In unbalanced fault analysis work, generators are represented in the positive sequence in exactly
the same way as in power flow cases after execution of activity CONG with generator conversion using
fault analysis positive sequence machine impedance ZPOS (see also Figure 12-4). Generators are
represented in the negative and zero sequences by the impedances ZNEG and ZZERO connected
directly to ground at their terminal buses.
It is often appropriate to model a generator by a different positive sequence impedance in fault anal-
ysis than in switching and dynamic simulation studies. The fault analysis activities handle this
requirement by using a special positive sequence generator characteristic impedance, ZPOS, in
place of the impedance ZSORCE that is associated with the generator in switching and dynamics
applications.
It is quite common, and perfectly valid, to have the generator terminal bus isolated in the zero
sequence network. This is, in fact, the usual case because the majority of generator step-up trans-
formers are delta connected on the generator side and wye connected on the high side. This is the
assumption that is applied in the generator modeling when the step-up transformer is represented
as part of the generator data (i.e., XTRAN is non-zero). Activity SEQD prints an alarm message for
any generator with non-zero values of both XTRAN and ZZERO and uses only XTRAN in setting
up the zero sequence ground tie at the Type 2 (high side) bus.
The usual network initial condition for unbalanced fault work is a complete solved power flow level
model. Through activity FLAT, the user may construct a system model with varying lesser degrees
of detail.
The normal sequencing of activities in preparing for fault analysis work is:
1. Set up the positive sequence network at whatever level of detail is required.
2. Append the required sequence data to the working case with activity RESQ.
3. Use activity SEQD to set up the sequence networks on the basis of the boundary conditions
contained in the working case.
4. Use activity SCMU to apply unbalances and solve the network.
Activity SEQD is normally entered with generators unconverted; activity SEQD then temporarily
converts generators using the generator impedances ZPOS (i.e., it does the equivalent of activity
10-10
Program Operation Manual Performing Fault Analysis with Multiple Unbalances
CONG with generator conversion using fault analysis positive sequence machine impedance ZPOS).
If generators are converted when activity SEQD is selected, the generator conversion calculation
of activity SEQD is bypassed, and the results of the prior execution of activity CONG are used. This
is the case, for example, when an equivalent has been constructed (with activity SCEQ), which
requires the prior execution of activity CONG with ZPOS generator conversion. Similarly, if the char-
acterization of generators using ZSORCE rather than ZPOS was appropriate for a fault analysis
scenario, activity CONG should be executed prior to selecting activity SEQD.
Because activity SEQD builds the sequence network admittance matrices corresponding to the
system in the working case, it follows that it must be re-executed before entering activity SCMU any
time these matrices change, different bus boundary conditions are imposed, or a new system repre-
sentation is brought into the working case. Because activity SEQD prepares the SEQD temporary
file for unbalanced network solutions, it also needs to be re-executed whenever, in the midst of an
unbalanced network study, some other PSS®E activities that utilize these files are executed (e.g.,
activity ANSI), or when PSS®E is terminated and subsequently reentered.
Activity SEQD is sensitive to the fault analysis modeling option setting (refer to Section 3.3.3
Program Run-Time Option Settings and activity OPTN). This setting, at the time activity SEQD is
selected, determines whether subsequent executions of activities SCMU and SCOP use two or
three phase network representations. When activity SEQD is used in preparation for activity SPCB,
this option setting must be set to the normal three phase modeling mode.
Section 15.1, Preparing Sequence Networks for Unbalanced Network Solution
Section 12.1, Preparing Sequence Network for Unbalanced Network Solution
10.6 Performing Fault Analysis with Multiple Unbalances

Activity SCMU
Run Activity SCMU - GUI

Fault > Solve and report network with unbalances (SCMU/SCOP)…
[Multiple Simultaneous Unbalances]
Run Line Mode Activity SCMU - CLI
ACTIVITY?
>>SCMU
ENTER UNBALANCE CODE:

AB
The multiply unbalanced network solution activity SCMU allows the user to apply simultaneously,
at any bus, on any phase, any or all of the following unbalances or faults:
10-11
Performing Fault Analysis with Multiple Unbalances Program Operation Manual
1. Two single-line-to-ground faults (L-G) with specified fault impedances.
2. Two line-to-line (L-L) or double-line-to-ground (L-L-G) faults with specified fault impedances.
3. Single phase, with specified impedance, closed between a pair of buses.
4. Two phases, with equal specified impedance, closed between a pair of buses.
The network is solved in the presence of the specified unbalances and summary output is printed.
Activity SCMU does not modify the contents of the working case or the SEQD temporary file set up
by activity SEQD.
10.6.1 Unbalanced Fault Analysis Options

The user specifies the desired unbalances, selecting the types of unbalances (see Simplified Fault
Calculation Model and Figure 10-5) and specifying faulted buses and phases, and fault imped-
ances. Note that all fault impedances are complex numbers and are entered in per unit. Options are
available for the following unbalances:
• First L-G • Second L-L-G • 3-phase fault

• Second L-G • 1 phase closed • 1 end opened
• First L-L-G • 2 phases closed • In-line slider
ZF ZF L-G,
ZF L-L-G, or
ZG In-Line Fault
3- Fault
L-G Fault L-L-G Fault
L-G,
Two Phases Closed One Phase Closed Open End Fault L-L-G, or
3- Fault
Figure 10-5. Unbalances Modeled in Activity SCMU
10.6.2 Bus Faults

Bus faults are applied simply by instructing activity SCMU to apply the L-G and L-L-G unbalances,
singly or together at the bus, with the appropriate values of the fault impedances ZF and ZG (see
Figure 10-5). For example, a line-to-line fault may be applied by selecting the L-L-G unbalance with
infinite impedance specified for ZG (i.e., the default value). As a second example, a three phase
fault may be applied by selecting the L-G unbalance on phase one (i.e., A) with ZF = 0.0+j0.0
together with the L-L-G unbalance excluding phase one with both ZF and ZG specified as 0.0+j0.0.
Specifying this condition has been automated by including a special unbalance code for a three
phase fault. It automatically applies both the second L-G and second L-L-G faults at the designated
bus, with all fault impedances set to 0.0+j0.0.
10-12
The user must specify the faulted bus. In the case of the L-G unbalance, the user specifies the
faulted phase and the fault impedance; phases one, two and three designate the A, B, and C
phases, respectively. In the case of the L-L-G unbalance, the user specifies the un-faulted phase
and the fault impedances ZF and ZG. Note again that fault impedances (R + jX) are specified and
that both resistance and reactance must be entered. Fault impedances are specified in per unit of
base impedance.
10.6.3 Line Faults

The inter-sequence solution method of activity SCMU can apply faults only at buses. The applica-
tion of a line fault, therefore, requires the insertion of a dummy bus in the line that is to be subjected
to the line fault. The introduction of dummy buses and rerouting of branches may be handled manu-
ally in the working case before executing activity SEQD. However, activity SCMU provides for the
temporary addition of the required dummy buses and automates the rerouting of branches to the
dummy buses and splitting of the zero sequence mutual couplings on either side of the faulted
dummy bus.
In the application of the fault slider, the line may be represented in two ways: with both ends closed
or with one end opened. In either of these two topologies, one of the following may be applied at
any point along the line:
1. The second L-G fault.
2. The second L-L-G fault.
3. A three phase fault utilizing both the second L-G fault and the second L-L-G fault.
In modeling line faults, activity SCMU introduces a dummy bus, numbered 999999, at the fault
point. When one end of the faulted line is opened and the fault point is not at the line end position,
a second dummy bus, numbered 999998, is introduced at the opened end.
To utilize the line faults, the number of buses in the working case must be at least one less (two less
for an in-line fault with one end opened) than the maximum number for which PSS®E is dimen-
sioned. In addition, except for the case of a line end fault at the opened end of a line, the following
conditions must be met:
1. The number of branches in the working case must be less than the maximum number for
which PSS®E is dimensioned.
2. The geographical B factors, BIJ1, BIJ2, BKL1, and BKL2, must have been properly specified
for any zero sequence mutual couplings involving the branch (refer to Zero Sequence
Mutual Impedance Data).
The user specifies the branch on which the fault slider is to be imposed. For the case of one end of
a branch opened, a non-transformer branch, a two-winding transformer, or a three-winding trans-
former may be designated. A non-transformer branch or a two-winding transformer is specified by
keeping the default value or entering a zero as the third bus identifier; a three-winding transformer
is designated by specifying the three buses it connects.
In the case of one end of the branch opened, the user specifies the opened end and, except for a
three-winding transformer, the fault location on the line. The fault location is specified by specifying
the fraction of the line between the closed end and the fault point (A factor); the proper designation
is a number greater than zero and less than or equal to one (one would indicate a line end fault).
For a two-winding transformer, an A factor value of one must be specified.
10-13
For the case of both ends of the branch closed, the user specifies the fault location by entering the
fraction of the line between the from bus as entered above and the fault point; the number entered
must be greater than zero and less than one.
The user specifies the type of fault (refer to Bus Faults).
Only one line fault may be imposed on the network in any given execution of activity SCMU. Other
bus faults and the phase closed unbalances may be simultaneously applied.
For an in-line slider fault with both ends closed, the faulted line may not be a transformer, and it may
not be open in the zero sequence (i.e., its zero sequence impedance must be non-zero). In the case
of one end opened, the fault must be applied at the line end position if the branch is a transformer.
The summary output for either of the line faults is identical in form to that for bus faults. The faulted
dummy bus is listed as bus 999999 with the name DUMMYBUS. For the one end opened case, the
base voltage of the dummy bus is taken to be the same as the opened end bus. For the case of
both ends closed, the base voltage of the dummy bus will be that of one of the two buses involved.
In the case of one end opened with the fault location other than at the opened end, the opened end
dummy bus is listed as bus 999998 with the name STUB END and the base voltage of the original
bus at the opened end of the line.
10.6.4 Branch with One Open End

For the case of one end of a branch opened, a non transformer branch, a two-winding transformer,
or a three-winding transformer may be designated. A non transformer branch or a two-winding
transformer is specified by identifying the two associated buses. A three-winding transformer is
designated by specifying the three buses it connects.
With one end of the branch opened, the user designates the opened end and, except for a three-
winding transformer, the fault location on the branch. For a non-transformer branch, the fault loca-
tion is specified by specifying the fraction of the line between the closed end and the fault point, as
for the slider. The proper designation is a number greater than zero and less than or equal to one
(one would indicate a line end fault). For a two-winding transformer, the value of one must be spec-
ified. For a three-winding transformer, the user can select the open point at any of the three buses
to which the transformer is connected.
In the case of one end opened with the fault location other than at the opened end, the opened end
dummy bus is listed as bus 999998 with the name STUB END and the base voltage of the original
bus at the opened end of the line.
Note that the fault type can be a line-to-ground, a line-to-line-to ground or a 3-phase fault.
10.6.5 Phase Closed Unbalances

The single and double phase closed unbalances of activity SCMU place series elements of the
designated phase impedance between designated buses in the selected phases. The user speci-
fies the pair of buses involved, either the phase to be closed (for the single phase closed unbalance)
or the opened phase (for the double phase closed unbalance), and the phase impedance of the
closed phase(s).
If it is intended to open one or two phases of a branch which already exists, that branch must be
taken out of service in order to be replaced by the unbalance model.
10-14
Following the unbalance specification process, a warning message is printed if there are already
any in-service branches between the designated buses. In this case the new series branch, of
which only one or two phases are closed, is placed in parallel with those branches that are already
present. It is the user’s responsibility to ensure that the working case is in a state such that the appli-
cation of the phase closed unbalance produces the desired overall condition.
The summary output for each of the phase closed unbalances consists of the bus voltage block for
each of the two buses and the branch current block for the unbalance only.
10.6.6 Pre-Calculation Network Setup

The normal sequencing of activities in preparing for fault analysis work is:
1. Set up the positive sequence network at whatever level of detail is required.
2. Append the required sequence data to the power flow case (Section 10.2, Appending
Sequence Data to the Power Flow Case).
3. Select the unbalances to be simulated and start the calculation.
When the calculation is initiated, the first step in the process is the setting up of the sequence
networks. This involves the preparation of the power flow case for the unbalanced network solution
(as well as for the Separate Pole Circuit Breaker simulation discussed in Section 10.13 Calculating
pi-Equivalent, Single Transmission Line Unbalance)
This process involves taking the positive sequence network (i.e., the power flow case) and the
various sequence data arrays defining the negative and zero sequence networks, and setting up
the SEQD temporary file in the necessary form. The following computations are performed:
• All positive sequence loads are converted to fixed shunt admittances on the basis of
the voltage at each load bus in the working case.
• All negative sequence loads, except those for which the user has specified a nonzero
negative sequence load are set equal to the positive sequence values calculated in the
previous step.
• All generator positive sequence sources are initialized and fixed to correspond to their
generator terminal bus conditions in the working case. This is a temporary conversion
of the power flow generator model to a Norton equivalent for the fault calculations (see
Figure 10-6).
• An ordering for the positive and negative sequence networks is determined and
summarized at the Progress device (see Figure 10-7).
• The positive and negative sequence admittance matrices are constructed and
factorized.
• The zero sequence network is ordered and summarized at the Progress device (see
Figure 10-7).
• The zero sequence network admittance matrix is constructed and factorized.
10-15
ZSORCE or ZPOS
Positive Sequence Z tran
1:GTAP
P+ jQ t:1 t -:1
~
E
source
Z
neg
Negative Sequence
Z
tran
1:GTAP
t :1
Z Transf. zero
zero seq. connections
Z
tran
Zero Sequence
1:GTAP
Unbalanced Fault
Power Flow Setup
Augment Positive Sequence model Analysis Setup
and Append Sequence Data
Figure 10-6. Generator Conversion to Norton Equivalent for Fault

Calculations
10-16
Using machine R and X" from fault analysis data
Diagonals = 23 Off-diagonals = 41 Maximum size = 60
Positive sequence network: Diagonals = 23 Off-diagonals = 41
Diagonals = 23 Off-diagonals = 35 Maximum size = 48
Bus 101 [NUC-A 21.600] is isolated in the zero sequence network
Bus 102 [NUC-B 21.600] is isolated in the zero sequence network
Bus 206 [URBGEN 18.000] is isolated in the zero sequence network
Bus 211 [HYDRO_G 20.000] is isolated in the zero sequence network
Bus 3011 [MINE_G 13.800] is isolated in the zero sequence network
Bus 3018 [CATDOG_G 13.800] is isolated in the zero sequence network
6 buses are isolated in the zero sequence network
Zero sequence network: Diagonals = 23 Off-diagonals = 35
Figure 10-7. Summary from Network Ordering Prior to Fault Calculations
With respect to the summary shown in Figure 10-7, it is quite common, and perfectly valid, to have
the generator terminal bus isolated in the zero sequence network. This is, in fact, the usual case
because the majority of generator step-up transformers are delta connected on the generator side
and wye connected on the high side. This is the assumption inherent in the generator modeling
when the step-up transformer is represented as part of the generator data (i.e., XTRAN is nonzero).
An alarm message will be printed for any generator with nonzero values of both XTRAN and
ZZERO. In this case, the value of only XTRAN is used in setting up the zero sequence ground tie
at the Type 2 (high side) bus.
10.6.7 Operation of Activity SCMU

If sequence data has not been read into the working case via activity RESQ, an appropriate error
message is printed and activity SCMU is terminated.
When the sequence network setup option is enabled (refer to Section 3.3.3 Program Run-Time
Option Settings), activity SEQD is automatically executed. Otherwise, activity SCMU assumes the
prior execution of activity SEQD for the network conditions contained in the working case.
After the desired set of unbalances has been specified, the inter-sequence network solution
commences. If any line fault has been specified (refer to Section 10.6.3 Line Faults), the sequence
admittance matrices as constructed by activity SEQD are modified and factorized, and the standard
matrix size information (as in activity FACT) is tabulated. Otherwise, the factorized admittance
matrices built by activity SEQD are used.
This is followed by a tabulation of the system Thevenin impedances as seen at each bus where an
unbalance is to be applied. Each sequence column of this table lists resistive and reactive parts of
10-17
the Thevenin impedances that would be measured by observations made at each bus in turn
without the influence of the prescribed set of unbalances.
Activity SCMU interconnects the three sequence networks to represent the unbalanced condition
and solves for the sequence voltages. Following solution, a summary report is printed for each
unbalance applied. The user is then given the opportunity to get complete output for any bus in the
working case.
Activity SCMU requires that the ordered sequence network admittance matrices and their triangular
factors are present in the SEQD temporary file; i.e., activity SCMU requires successful execution of
activity SEQD. Activity SCMU may be used repeatedly after the successful completion of activity
SEQD to apply different unbalances to a given network configuration. However, any time the
network configuration is changed (for example, via activities TREA, RESQ, CASE, CHNG, SQCH,
or the [Spreadsheet]), re-execution of activity SEQD is required.
The summary report for each unbalance may be terminated by entering the AB interrupt control
code.
10.6.8 Unbalance Condition Summary Report

Following the solution of the unbalanced network, a summary report is printed at the selected output
device for each unbalance that is in effect. Each individual unbalance report consists of a tabulation
of bus voltages and branch currents in terms of both symmetrical component (sequence) and phase
quantities. Voltages and currents are printed in either physical units (kV L-G and amps) or per unit,
and in either rectangular or polar coordinates, according to the fault analysis output options
currently in effect (refer to Section 3.3.3 Program Run-Time Option Settings and activity OPTN). If
the physical units option is enabled and a bus has no base voltage specified for it, its output is
printed in per unit.
The following blocks of output are included:
1. Fault type and bus(es) involved.
2. Bus voltages for the bus at which the unbalance is applied. The first line of each bus voltage
block gives the bus zero, positive and negative sequence voltages as well as three times
the zero sequence voltage, and the second line gives the bus phase voltages. When the per
unit option is enabled, values are in per unit of rated line to ground voltage. The phase volt-
ages are line to neutral values. For the phase closed unbalances, the bus voltage block is
printed for both of the buses involved.
3. For the L-G and L-L-G faults, series branch currents flowing in each branch (including any
generator contributions) connected to the faulted node. All currents are tabulated as flowing
into the faulted node and include the effects of line charging capacitance, line connected
shunt admittances, and transformer magnetizing admittance. When the per unit option is
enabled, currents are expressed in per unit of base phase current. The first line gives
sequence components of current as well as three times the zero sequence current, and the
second line gives the phase currents. For non-transformer branches and for two-winding
transformers, the number and name of the bus at the other end of the branch is printed,
along with the circuit identifier; for three-winding transformers, the output line contains the
winding number, the transformer circuit identifier and the transformer name. For the phase
closed unbalances, the only branch series currents tabulated are those represented by the
unbalance.
10-18
4. For the L-G and L-L-G faults, the algebraic sum of contributions of all elements tabulated in
(3). The format of these currents is the same as for the series branch currents. This is the
total current apparently flowing to ground at the bus, and it includes any load and fixed shunt
connected to the bus, fault current, and the ac side current of any unblocked dc line or
FACTS device.
5. For the L-G and L-L-G faults, a value of contributions equivalent positive sequence admit-
tance, expressed in rectangular form, in both per unit relative to system base values and in
MVA. This quantity is computed from the sum of contributions in (4) and thus includes any
load, fixed shunt and unblocked dc line and FACTS device elements connected to the bus.
Furthermore, this equivalent admittance is valid only in the case of single ground faults. In
the case where there are no dc line or FACTS device effects included in this admittance, and
only this single unbalance was applied, this shunt admittance in MVA, may be entered as a
shunt replacing the load and shunt elements at the bus, to give the correct positive
sequence equivalent representation of this fault in the dynamic simulation activities.
6. For the L-G and L-L-G faults, the current flowing to ground at the bus exclusive of any fault
current. The format of these currents is the same as in (3) and (4) above, and they include
any load and shunt current at the bus as well as the ac side current of any unblocked dc line
or FACTS device. In the zero sequence, only the load and shunt current is output here;
specifically, the zero sequence ground ties created by grounded transformer windings are
not shown here but are included in the branch contribution output of (3) above. Load and
shunt current output is suppressed if the three sequence shunt and load admittances are all
zero.
7. For the L-G and L-L-G faults, when no phase closed unbalances are applied and only one
bus is involved in the ground faults, fault current is calculated and tabulated in a format
similar to (4) above, and positive sequence equivalent fault admittance is listed in a format
similar to (5) above. This admittance in MVA would be added to any in-service shunt at the
bus to represent this fault in the dynamic simulation activities.
Following the summaries for all active unbalances, the user is able to request output for any bus in
the system. Buses are selected one bus at a time and output is written to the selected output device.
Output tabulated includes that specified by (2), (3), (4), and (6) above, with branch currents tabu-
lated as arriving at the selected bus.
Whenever a single ground fault unbalance is solved by activity SCMU, an entry is appended to a
summary file, named SMRYSC, in the user’s directory. This file contains fault descriptive informa-
tion along with the sum of contributions entry described in (4) above. This file is cumulative, and if
it does not exist it is created automatically by activity SCMU. It is never automatically deleted;
activity SCMU always appends to it. The user may delete this file at any time when it is no longer
of use (refer to Section 2.6 Files Created By PSS®E).
10.6.9 Example: Unbalance Condition Summary Report

Following the sequence network set-up, the system Thevenin impedances, as seen at each bus
where an unbalance is to be applied, are reported. Each sequence column of this table lists resistive
and reactive parts of the Thevenin impedances that would be measured by observations made at
each bus in turn without the influence of the prescribed set of unbalances.
An example is shown in Figure 10-8 for a case in which two line-to-ground faults were applied in
the savnw.sav power flow case, with a zero fault impedance, on Buses 151 and 3002.
10-19
UNBALANCES APPLIED:
LINE TO GROUND FAULT AT BUS 151 [NUCPANT 500.00] PHASE 1
L-G Z = (0.0,0.0)
LINE TO GROUND FAULT AT BUS 3002 [E. MINE 500.00] PHASE 1
L-G Z = (0.0,0.0)
SEQUENCE THEVENIN IMPEDANCES AT FAULTED BUSES
BUS# X-- NAME --X BASKV ZERO POSITIVE NEGATIVE
151 NUCPANT 500.00 0.00017 0.00600 0.00409 0.01765 0.00409 0.01765
3002 E. MINE 500.00 0.00063 0.02240 0.00673 0.03855 0.00673 0.03855
Figure 10-8. Sequence Thevenin Impedance for Two Line-to-Ground Faults
The calculation process interconnects the three sequence networks to represent the unbalanced
condition and solves for the sequence voltages. Following solution, a summary report is printed for
each unbalance applied. The user is then given the opportunity to get complete output for any bus
in the working case.
The summary report is printed at the selected output device for each unbalance that is in effect.
Each individual unbalance report consists of a tabulation of bus voltages and branch currents in
terms of both symmetrical component (sequence) and phase quantities. Voltages and currents are
printed in either physical units (kV L-G and amps) or per unit, and in either rectangular or polar coor-
dinates, according to the fault analysis output options currently in effect (refer to activity OPTN). If
the physical units option is enabled and a bus has no base voltage specified for it, its output is
printed in per unit.
The following blocks of output are included:
1. Fault type and bus(es) involved.
2. Bus voltages for the bus at which the unbalance is applied. The first line of each bus voltage
block gives the bus zero, positive and negative sequence voltages as well as three times
the zero sequence voltage, and the second line gives the bus phase voltages. When the per
unit option is enabled, values are in per unit of rated line to ground voltage. The phase volt-
ages are line to neutral values. For the phase closed unbalances, the bus voltage block is
printed for both of the buses involved.
3. For the L-G and L-L-G faults, series branch currents flowing in each branch (including any
generator and induction machine contributions) connected to the faulted node. All currents
are tabulated as flowing into the faulted node and include the effects of line charging capac-
itance and line connected shunt admittances. When the per unit option is enabled, currents
are expressed in per unit of base phase current. The first line gives sequence components
of current as well as three times the zero sequence current, and the second line gives the
phase currents. For non transformer branches and for two-winding transformers, the
10-20
number and name of the to bus is printed, along with the circuit identifier; for three-winding
transformers, the output line contains the winding number, the transformer circuit identifier
and the transformer name. For the phase closed unbalances, the only branch series
currents tabulated are those represented by the unbalance.
4. For the L-G and L-L-G faults, the algebraic sum of contributions of all elements tabulated in
(3). The format of these currents is the same as for the series branch currents. This is the
total current apparently flowing to ground at the bus, and it includes any load connected to
the bus, fault current, and the ac side current of any unblocked dc line or FACTS device.
5. For the L-G and L-L-G faults, a value of contributions equivalent positive sequence admit-
tance is expressed in per unit, rectangular form, relative to system base values. This
quantity is computed from the sum of contributions in (4) and thus includes any load and
unblocked dc line and FACTS device elements connected to the bus. Furthermore, this
equivalent admittance is valid only in the case of single ground faults. In the case where
there are no dc line or FACTS device effects included in this admittance, and only this single
unbalance was applied, this shunt admittance, multiplied by system base MVA, may be
entered as a shunt replacing the load and shunt elements at the bus, to give the correct posi-
tive sequence equivalent representation of this fault in the dynamic simulation activities.
6. For the L-G and L-L-G faults, the current flowing to ground at the bus exclusive of any fault
current. The format of these currents is the same as in (3) and (4) above, and they include
any load and shunt current at the bus as well as the ac side current of any unblocked dc line
or FACTS device. In the zero sequence, only the shunt load is output here; specifically, the
zero sequence ground ties created by grounded transformer windings are not shown here
but are included in the branch contribution output of (3) above. Load and shunt current
output is suppressed if the three sequence shunt and load admittances are all zero.
7. For the L-G and L-L-G faults, when no phase closed unbalances are applied and only one
bus is involved in the ground faults, fault current is calculated and tabulated in a format
similar to (4) above, and positive sequence equivalent fault admittance is listed in a format
similar to (5) above. This admittance, multiplied by system base MVA, would be added to
any shunt at the bus to represent this fault in the dynamic simulation activities.
Whenever a single ground fault unbalance is solved an entry is appended to a summary file, named
SMRYSC, in the user’s directory. This file contains fault descriptive information along with the sum
of contributions entry described in (4) above. This file is cumulative, and if it does not exist it is
created automatically when the unbalanced fault calculations are performed. It is never automati-
cally deleted; results are always appends to it. The user may delete this file at any time when it is
no longer of use.
Figure 10-9 shows the summary report for a single-line-to-ground fault at Bus 151 in the savnw.sav
power flow case, with zero fault impedance.
Note that the output options are polar coordinates and physical quantities; i.e., the voltages are in
kV and the current is in amperes.
Because there is a 600 Mvar shunt connected to bus 151, the Total Contributions include the current
in this shunt.
The total A Phase current is 8420.0 / -67.71 amps. The zero sequence current is 2773.4 /-67.69
amps, These include contributions from the 600 MVAr shunt.
10-21
Because the A Phase current in the 600 Mvar shunt is 99.9 /- 69.33, the actual A Phase fault current
at the bus is less and is 8320.1 /-67.69 amps.
600 Mvar Shunt at bus 151
Sum of Contributions without the 600 Mvar Shunt
Figure 10-9. Summary Output at Bus 151 with L-G Faults at Buses 151 in
Power Flow Case savnw.sav
10.6.10 Unbalanced Fault Analysis Detailed Report

Results summaries are output for each unbalance condition that is in effect. For each fault condi-
tion, conditions at other buses in the system can be reported. This is achieved using the Solution
Output tab in the unbalance dialog. That tab provides access to selection of buses for which
reporting is required and, further, allows the selection of output to be in the following branch
quantities:
• Currents
• Apparent impedances
• Apparent admittances
10-22
This reporting facility recognizes the same fault analysis output options, with quantities printed in
either physical units or per unit, and in either rectangular or polar coordinates as does the summary
report.
The data printed for any selected bus or buses has the same format as for the summary report and
consists of:
1. Sequence and phase voltages at the bus.
2. Series branch quantity for each branch and machine connected to the bus, consisting of
either:
a. Branch series currents leaving the bus, in either per unit or amps. These are in the
reverse direction of the currents shown in the summary report.
b. Branch apparent impedances looking down each branch from the bus, expressed
in either per unit or ohms. These apparent impedances are defined as:
Vseq i Vphase i
Zseq ij = Zphase ij =
Iseq ij Iphase ij
c. where the sequence and phase currents are the total currents flowing into the line
at the bus, including line charging capacitance and line connected shunt current.
Infinite impedance is printed as 9999 per unit or 999999 ohms.
d. Branch apparent admittances looking down each branch from the bus, expressed
in either per unit or mmhos. Apparent admittances are defined as the reciprocal of
apparent impedances. Infinite admittance is printed as 9999 per unit or
99999 mmhos.
3. Sum of branch contributions. When branch currents are being tabulated, the sum of all
contributions flowing into the bus is the total current apparently flowing to ground at the bus
and will be zero unless there is a load or a shunt connected (see Section 10.6.9 Example:
Unbalance Condition Summary Report).
4. When branch currents are being tabulated, the sum of load and shunt current at the bus.
Load and shunt current output is suppressed if the three sequence shunt and load contribu-
tions are all zero.
Note that the direction of current flow in the series branch output is the reverse of that in the
summary output. Rather, it follows the power flow output convention of current leaving the bus.
When output is directed to the user’s terminal, a summary description of each active unbalance is
printed at the top of the first page of output. Otherwise, the unbalance summary is printed on each
page of output.
10.6.11 Observation of Transformer Currents

Grounded wye-delta transformers pose a difficulty in unbalanced fault analysis because they
behave as a shunt path to ground in the zero-sequence, while being series paths in the positive and
negative sequences. There is a distinction between the transformer’s symmetrical component
equivalent circuits and the actual arrangements of its primary, secondary, and neutral leads.
Consider the currents flowing in the leads of a wye-delta transformer as shown in Figure 10-10. The
wye-connected winding allows zero-sequence current to flow into the transformer leads and thence
10-23
to ground via the neutral grounding strap. While the wye-connected winding is certainly a path to
ground, observations at the leads that feed this winding see the zero-sequence current just as if it
were a series current flowing to the bus at the other side. This zero-sequence current in the trans-
former leads must be recognized in calculations of the phase values of the lead currents.
I Primary
p1 Leads
I Secondary
p2
I Leads I
p0 s1
I
s2
Tank
3I p0
– Neutral Lead
3I
p0
Grounding Strap
Figure 10-10. Lead Current Flowing Into and Out of a Wye-Delta Transformer
Consider the calculation of conditions at a bus where the following are connected:
• Transmission lines.
• A grounded wye-winding of a wye-delta transformer.
• A grounded wye-connected shunt reactor.
• A phase-to-ground fault somewhere on the bus side of all circuit breakers.
The bus arrangement is shown in Figure 10-11a. There are three components of zero-sequence
current flowing from the bus to ground: fault current, reactor zero-sequence current, and trans-
former zero-sequence current. A conventional way of representing the bus is shown in Figure 10-
11b. Here, the transformer is represented as a ground tie at the bus in the zero-sequence. The bus
is assigned a shunt admittance equal to the sum of the reactor and transformer admittances. Use
of this representation in system network solutions leads to correct results for bus positive-, negative-
, and zero-sequence voltages. The subsequent calculation of transformer lead currents is erro-
neous, though, because the zero-sequence lead current appears to be zero when it should not be.
The alternative and recommended approach is to represent the transformer via the winding type
code option of PSS®E. When the winding type code approach is used, the implied bus representa-
tion is as shown in Figure 10-11c.
10-24
I
r
Line A
Shunt Reactor
Line B
I
f
I
t
1:t
Transformer
a. Bus with Grounding via Transformer, Shunt Reactor, and Fault
I
fo
I
ro
Z
I
fo
I to B = B
r
I +I
ro to
1:t
1 Z
B = B r + -------------- to
2
Z t
to
b. Bus Setup with Transformer Treated as c. Bus Setup with Transformer Modeled
Bus Ground Path via Winding Type Codes
Figure 10-11. Transformer Zero-Sequence Currents Appearing in Alternative Network

Representations of the Transformer
This results in the same system solution as obtained with the prior approach, but recognizes the
zero-sequence current in the transformer leads. Calculations of transformer lead phase currents
are correct, provided that the 30° phase shift of the transformer is handled properly.
While the winding type codes are normally used in the handling of the majority of transformers, use
of manually determined shunt paths at buses may still be needed in special situations. When the
winding type codes are not used, the following points must be noted:
10-25
• If wye windings of wye-delta transformers are to be represented as bus-connected

shunt admittances to ground, the shunt admittance should be corrected for off-nominal
turns ratio as shown by Figure 10-12.
• When wye-delta transformers are represented by bus-connected shunt admittances,
the phase currents calculated by PSS®E for the leads to the delta-connected winding
are correct, but the phase currents displayed for the wye winding leads are erroneous.
• Because the bus modeling topology shown in Figure 10-11b is correct for bus arrange-
ments other than that shown in Figure 10-11a, PSS®E must assume that all calculated
branch phase currents are valid and leave it for the user to accept or reject the output
values.
t:1 t:1
Positive
Sequence
Z Z
 
Zero
Sequence
1 1
y = --------- y = ---
2 Z
Zt
Figure 10-12. Assignment of Zero-Sequence Shunt Branch for Typical Tapped Delta-Wye
Transformers, Solidly Grounded
10-26
10.6.12 Working with a Two-Wire System

PSS®E includes an option, in the detailed unbalanced fault analysis and the automatic sequencing
fault analysis (Section 10.8 Calculating Automatic Sequencing Fault), to handle certain two- and
one-phase systems. This option was implemented primarily to handle certain European electric
traction systems having a primary transmission system of two phases at 180° displacement feeding
a single-phase catenary system. The basic system connections in this system are shown in
Figure 10-13, but other two- and one-phase systems can be handled by the appropriate setup of
the sequence network models.
132 kV 12 kV
Secondary of
Generator Step-Up Load
Transformer Transformer
Figure 10-13. Two-Phase System Configuration for Railway Application
The two-phase system modelling assumption is established with the Short circuit phase modeling
run-time option (Section 3.3.3 Program Run-Time Option Settings and activity OPTN). This option
allows the selection of two-phase instead of the conventional three-phase mode. Selecting the two-
phase option has the following effects:
• The symmetrical component < a > operator becomes (–1+j0), and the negative
sequence is ignored, giving
i0 1 1 ia
i1 = 1/2 1 -1 ib
• The base voltage is taken to be the line-to-line voltage at base conditions, and the base
current is taken to be the corresponding line current so that
MVAbase
IL base =
VLL base
V2LL base
ZLG base =
2MVAbase
• Line-to-ground voltages in kV are calculated as

VLG = 0.5(VLL base × vpu
Phase currents in amperes are calculated as

Ip = IL base × Ipu
where vpu and Ipu are the per-unit bus voltage and branch current, respectively.
10-27
Using the PSS®E two-phase option is identical to the conventional three-phase mode except for
the following:
• Negative-sequence data may be entered for generators, branches, and loads but it is
ignored in the fault calculations.
• Unbalanced faults may involve only phases 1 and 3. (The excluded phase in an L-L-G
fault must be phase 2.) The three-phase fault selection must not be used.
• The two-phases-closed unbalance should not be used.
10.6.13 Transmission Lines

A two-phase two-conductor transmission line is characterized by positive- and zero-sequence
impedances:
Z1 = Zp - Zm
Z 0 = Zp + Z m
where
Z1 = Positive-sequence impedance.
Z0 = Zero-sequence impedance.
Zp = Self impedance of one phase conductor.
Zm = Mutual impedance between the phase conductors.
Similar expressions hold for the charging capacitances in the positive- and zero-sequences.
10.6.14 Transformers
The positive and zero-sequence characteristics of transformers must be determined from their
internal connections. As an example, consider the transformer connection shown in Figure 10-13.
The behavior of the transformer when positive and zero-sequence currents, respectively, flow in its
primary windings are shown in Figure 10-14. When positive-sequence current flows in the primary
side, the two secondary windings are effectively in parallel and a positive-sequence current flows
in the secondary leads. When a zero-sequence current flows in the primary leads, the direction of
current is reversed in one primary and secondary winding. The two secondary windings now form
a short-circuited loop; a current corresponding to the primary zero-sequence current flows around
this loop, but no zero-sequence current flows in the secondary leads. The behavior of the primary
and secondary currents in this transformer is not affected by the grounding of one secondary lead;
no zero-sequence current can flow into the transformer because the ground is external to it.
10-28
i
1s
i
1p i
1s
--------
2
i
1p i
1s
-------- i 1s
2
a. Positive-Sequence Behavior
0.0
i
0p
i
0s
i 0s
2i i 0p
0p
b. Zero-Sequence Behavior
Figure 10-14. Behavior of Transformer with Secondary Windings Parallel to Single-Phase

Load
The modeling of the load transformer in PSS®E can be handled in a completely standard manner
by the use of connection codes. The positive- and zero-sequence connections, corresponding to
Figures 10-14 and 10-13, are shown in Figure 10-15. They may be specified to PSS®E by connec-
tion codes of 2.
10-29
a. Winding Connections
Winding 1 Winding 2
b. Positive-Sequence Connection
Winding 1 Winding 2
c. Zero-Sequence Connection
Figure 10-15. Sequence Connections Corresponding to Figure 10-14
10-30
10.6.15 Secondary Circuits

The load on the secondary side of the transformer shown in Figure 10-13 must be modeled
according to its physical connections. Straightforward possibilities are shown in Figure 10-16.
Grounding of one phase of a load does not create a zero-sequence path to ground. A ground must
exist inside the load device in order for it to carry a zero-sequence current; such internal ground
connections exist in the center-tapped load (Figure 10-16a) and in the transmission line section
(Figure 10-16d) as a result of its shunt charging capacitances.
10-31
Sequence Circuits
Load Circuit Positive Zero
Z
L
Z Z
L L
Z
L
a. Load Attached From Both Phases to Grounded Neutral
Z Z
L L
-------
2
b. Load Attached Between Phases
Z
Z L
L -------
2
c. Load Attached to Ground
Z Z = Z –Z Z =Z +Z
p 1 p m 0 p m
Z
m B B c1 B B c0
c1 c0
---------- ---------- ---------- ----------
2 2 2 2
d. Mutual Coupling
Figure 10-16. Sequence Circuits for Loads on Two-Phase System
10-32
10.6.16 Faults on a Two-Phase System

Faults on the two phase system may be represented by the standard PSS®E repertoire, except that
the three-phase and single-phase-open faults must not be used. The two phase system consists of
phases a and c. Hence an L-G fault must be on phase a or c, and an L-L-G fault must exclude
phase b.
10.6.17 Examples of Two-Wire Systems

Figure 10-17 shows a small sample system for use in two-phase fault analysis examples. The
system data are summarized in Figures 10-18 and 10-19.
30 MVA
100
j0.333
200
0.015 + j0.15 (0.025) 0.025 + j0.25

(0.04)
300
400
j0.15
j0.15
330
0.05 + j0.5 j4
(5 + j2) MVA 440
550
0.05 + j0.5
(5 + j2) MVA
(15 + j8) MVA
Figure 10-17. Sample System for Two-Phase Example Calculations
10-33
10-34
0, 100.00 / PSS®E-30.0 THU, AUG 05 2004 11:22
PSS®E 34.2
SMALL TWO PHASE EXAMPLE
100,'’GEN-1’ ', 10.0000,3, 0.000, 0.000, 1, 1,1.00000, 0.0000, 1

200,'’HYDRO’ ', 132.0000,1, 0.000, 0.000, 1, 1,0.98277, -4.8404, 1
300,'’WEST’ ', 132.0000,1, 0.000, 0.000, 1, 1,0.97469, -5.9957, 1
330,'’EAST-LO ', 12.0000,1, 0.000, 0.000, 1, 1,0.96723, -7.2034, 1
400,'’EAST’ ', 132.0000,1, 0.000, 0.000, 1, 1,0.97225, -6.5672, 1
440,'’WEST-LO ', 12.0000,1, 0.000, 0.000, 1, 1,0.96527, -7.6463, 1
550,'’MAIN-LO ', 12.0000,1, 0.000, 4.000, 1, 1,0.95002, -9.6922, 1
0 / END OF BUS DATA, BEGIN LOAD DATA
330,'1 ',1, 1, 1, 5.000, 2.000, 0.000, 0.000, 0.000, 0.000, 1

440,'1 ',1, 1, 1, 5.000, 2.000, 0.000, 0.000, 0.000, 0.000, 1
550,'1 ',1, 1, 1, 15.000, 8.000, 0.000, 0.000, 0.000, 0.000, 1
0 / END OF LOAD DATA, BEGIN GENERATOR DATA
100,'3 ', 25.130, 6.283, 20.000, 0.000,1.00000, 200, 30.000, 0.00000, 0.20000, 0.00000, 0.00000,1.00000,1, 1.0, 9999.000, -9999.000,
1,1.0000
0 / END OF GENERATOR DATA, BEGIN BRANCH DATA
200, 300,'1 ', 0.01500, 0.15000, 0.02500, 40.00, 40.00, 40.00, 0.00000, 0.00000, 0.00000, 0.00000,1, 0.00, 1,1.0000
200, 400,'1 ', 0.02500, 0.25000, 0.04000, 40.00, 40.00, 40.00, 0.00000, 0.00000, 0.00000, 0.00000,1, 0.00, 1,1.0000
330, 550,'1 ', 0.05000, 0.50000, 0.00000, 15.00, 15.00, 15.00, 0.00000, 0.00000, 0.00000, 0.00000,1, 0.00, 1,1.0000
440, 550,'1 ', 0.05000, 0.50000, 0.00000, 15.00, 15.00, 15.00, 0.00000, 0.00000, 0.00000, 0.00000,1, 0.00, 1,1.0000
0 / END OF BRANCH DATA, BEGIN TRANSFORMER DATA
200, 100, 0,'1 ',1,1,1, 0.00000, 0.00000,2,' ',1, 1,1.0000
0.00000, 0.33000, 100.00
1.00000, 0.000, 0.000, 35.00, 35.00, 35.00, 1, 200, 1.15000, 0.85000, 1.03000, 1.01000, 49, 0, 0.00000, 0.00000
10-35
1.00000, 0.000
330, 300, 0,'1 ',1,1,1, 0.00000, 0.00000,2,' ',1, 1,1.0000
0.00000, 0.15000, 100.00
1.00000, 0.000, 0.000, 20.00, 20.00, 20.00, 1, 330, 1.15000, 0.85000, 1.00000, 0.98000, 49, 0, 0.00000, 0.00000
1.00000, 0.000
440, 400, 0,'1 ',1,1,1, 0.00000, 0.00000,2,' ',1, 1,1.0000
0.00000, 0.15000, 100.00
1.00000, 0.000, 0.000, 20.00, 20.00, 20.00, 1, 440, 1.15000, 0.85000, 1.00000, 0.98000, 49, 0, 0.00000, 0.00000
1.00000, 0.000
0 / END OF TRANSFORMER DATA, BEGIN AREA DATA
0 / END OF AREA DATA, BEGIN TWO-TERMINAL DC DATA
0 / END OF TWO-TERMINAL DC DATA, BEGIN VSC DC LINE DATA
0 / END OF VSC DC LINE DATA, BEGIN SWITCHED SHUNT DATA
0 / END OF SWITCHED SHUNT DATA, BEGIN IMPEDANCE CORRECTION DATA
0 / END OF IMPEDANCE CORRECTION DATA, BEGIN MULTI-TERMINAL DC DATA
0 / END OF MULTI-TERMINAL DC DATA, BEGIN MULTI-SECTION LINE DATA
0 / END OF MULTI-SECTION LINE DATA, BEGIN ZONE DATA
0 / END OF ZONE DATA, BEGIN INTER-AREA TRANSFER DATA
0 / END OF INTER-AREA TRANSFER DATA, BEGIN OWNER DATA
0 / END OF OWNER DATA, BEGIN FACTS DEVICE DATA
0 / END OF FACTS DEVICE DATA
a. Power Flow Raw Data

Performing Fault Analysis with Multiple Unbalances
Figure 10-18. Raw Data Files for Two-Phase System
0 / PSS®E-30.0 THU, AUG 05 2004 11:24

100,'3 ', 0.00000, 0.20000
0 / END OF POSITIVE SEQ. MACHINE IMPEDANCE DATA, BEGIN NEGATIVE SEQ. MACHINE DATA
100,'3 ', 0.00000, 0.20000
0 / END OF NEGATIVE SEQ. MACHINE IMPEDANCE DATA, BEGIN ZERO SEQ. MACHINE DATA
100,'3 ', 0.00000, 0.00000
0 / END OF ZERO SEQ. MACHINE IMPEDANCE DATA, BEGIN NEGATIVE SEQ. SHUNT DATA
0 / END OF NEGATIVE SEQ. SHUNT DATA, BEGIN ZERO SEQ. SHUNT DATA
0 / END OF ZERO SEQ. SHUNT DATA, BEGIN ZERO SEQ. NON-TRANSFORMER BRANCH DATA
200, 300,'1 ', 0.02000, 0.30000, 0.04000, 0.00000, 0.00000, 0.00000, 0.00000
200, 400,'1 ', 0.04000, 0.45000, 0.06500, 0.00000, 0.00000, 0.00000, 0.00000
330, 550,'1 ', 0.04000, 0.80000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000
440, 550,'1 ', 0.04000, 0.80000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000
0 / END OF ZERO SEQ. NON-TRANSFORMER BRANCH DATA, BEGIN ZERO SEQ. MUTUAL DATA
0 / END OF ZERO SEQ. MUTUAL DATA, BEGIN ZERO SEQ. TRANSFORMER DATA
100, 200, 0,'1 ', 2, 0.00000, 0.00000, 0.00000, 0.33000
Connection codes to
300, 330, 0,'1 ', 3, 0.00000, 0.00000, 0.00000, 0.15000 represent parallel-
400, 440, 0,'1 ', 3, 0.00000, 0.00000, 0.00000, 0.15000 secondary transformer
0 / END OF ZERO SEQ. TRANSFORMER DATA, BEGIN ZERO SEQ. SWITCHED SHUNT DATA connections
0 / END OF ZERO SEQ. SWITCHED SHUNT DATA
b. Sequence Raw Data
Figure 10-18. (Cont.) Raw Data Files for Two-Phase System
10-36
10-37
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS®E THU, AUG 05 2004 11:30
SMALL TWO PHASE EXAMPLE BUS DATA
BUS# X-- NAME --X BASKV CODE LOADS VOLT ANGLE S H U N T AREA ZONE OWNER
100 ’GEN-1’ 10.000 3 0 1.0000 0.0 0.0 0.0 1 1 1
200 ’HYDRO’ 132.00 1 0 0.9828 -4.8 0.0 0.0 1 1 1
300 ’WEST’ 132.00 1 0 0.9747 -6.0 0.0 0.0 1 1 1
330 ’EAST-LO 12.000 1 1 0.9672 -7.2 0.0 0.0 1 1 1
400 ’EAST’ 132.00 1 0 0.9723 -6.6 0.0 0.0 1 1 1
440 ’WEST-LO 12.000 1 1 0.9653 -7.6 0.0 0.0 1 1 1
550 ’MAIN-LO 12.000 1 1 0.9500 -9.7 0.0 4.0 1 1 1
BUS# X-- NAME --X BASKV ID CD ST PSI MVA-LOAD CUR-LOAD Y - LOAD AREA ZONE OWNER
330 ’EAST-LO 12.000 1 1 1 1.000 5.0 2.0 0.0 0.0 0.0 0.0 1 1 1
440 ’WEST-LO 12.000 1 1 1 1.000 5.0 2.0 0.0 0.0 0.0 0.0 1 1 1
550 ’MAIN-LO 12.000 1 1 1 1.000 15.0 8.0 0.0 0.0 0.0 0.0 1 1 1
X----- REMOTE BUS ------X
BUS# X-- NAME --X BASKV COD MCNS PGEN QGEN QMAX QMIN VSCHED VACT. PCT Q BUS# X-- NAME --X BASKV
100 ’GEN-1’ 10.000 3 1 25.1 6.3 20.0 0.0 1.0000 0.9828 1.0 200 ’HYDRO’ 132.00
BUS# X-- NAME --X BASKV CD ID ST PGEN QGEN QMAX QMIN PMAX PMIN OWN FRACT OWN FRACT MBASE Z S O R C E X T R A N GENTAP
100 ’GEN-1’ 10.000 3 3 1 25.1 6.3 20.0 0.0 9999.0-9999.0 1 1.000 30.0 0.0000 0.2000
X------ FROM BUS -------X X------- TO BUS --------X Z S

BUS# X-- NAME --X BASKV BUS# X-- NAME --X BASKV CKT LINE R LINE X CHRGING I T RATEA RATEB RATEC LENGTH OWNR FRACT OWNR FRACT
10-38
200 ’HYDRO’ 132.00* 300 ’WEST’ 132.00 1 0.01500 0.15000 0.02500 1 40.0 40.0 40.0 0.0 1 1.000
200 ’HYDRO’ 132.00* 400 ’EAST’ 132.00 1 0.02500 0.25000 0.04000 1 40.0 40.0 40.0 0.0 1 1.000
330 ’EAST-LO 12.000* 550 ’MAIN-LO 12.000 1 0.05000 0.50000 0.00000 1 15.0 15.0 15.0 0.0 1 1.000
440 ’WEST-LO 12.000* 550 ’MAIN-LO 12.000 1 0.05000 0.50000 0.00000 1 15.0 15.0 15.0 0.0 1 1.000
X------ FROM BUS -------X X------- TO BUS --------X XFRMER S W M C C A C T U A L MAGNETIZING Y N O M I N A L

BUS# X-- NAME --X BASKV BUS# X-- NAME --X BASKV CKT X-- NAME --X T 1 T Z M R 1-2 X 1-2 W1BASE MAG1 MAG2 TBL R 1-2 X 1-2
100 ’GEN-1’ 10.000 200 ’HYDRO’ 132.00 1 1 T T 1 1 0.00000 0.33000 100.0 0.00000 0.00000 0
300 ’WEST’ 132.00 330 ’EAST-LO 12.000 1 1 T T 1 1 0.00000 0.15000 100.0 0.00000 0.00000 0
400 ’EAST’ 132.00 440 ’WEST-LO 12.000 1 1 T T 1 1 0.00000 0.15000 100.0 0.00000 0.00000 0
X------ FROM BUS -------X X------- TO BUS --------X C

BUS# X-- NAME --X BASKV BUS# X-- NAME --X BASKV CKT W WINDV1 NOMV1 ANGLE WINDV2 NOMV2 RATEA RATEB RATEC OWNR FRACT OWNR FRACT
100 ’GEN-1’ 10.000 200 ’HYDRO’ 132.00 1 1 1.00000 0.0000 0.0 1.00000 0.0000 35.0 35.0 35.0 1 1.000
Figure 10-19. Data Listings for Two-Phase System

300 ’WEST’ 132.00 330 ’EAST-LO 12.000 1 1 1.00000 0.0000 0.0 1.00000 0.0000 20.0 20.0 20.0 1 1.000
400 ’EAST’ 132.00 440 ’WEST-LO 12.000 1 1 1.00000 0.0000 0.0 1.00000 0.0000 20.0 20.0 20.0 1 1.000
X------ FROM BUS -------X X------- TO BUS --------X W C X---- CONTROLLED BUS ----X
BUS# X-- NAME --X BASKV BUS# X-- NAME --X BASKV CKT 1 W CN RMAX RMIN VMAX VMIN NTPS BUS# X-- NAME --X BASKV CR CX
100 ’GEN-1’ 10.000 200 ’HYDRO’ 132.00 1 T 1 1 1.15000 0.85000 1.03000 1.01000 49 -200 ’HYDRO’ 132.00
300 ’WEST’ 132.00 330 ’EAST-LO 12.000 1 T 1 1 1.15000 0.85000 1.00000 0.98000 49 -330 ’EAST-LO 12.000
400 ’EAST’ 132.00 440 ’WEST-LO 12.000 1 T 1 1 1.15000 0.85000 1.00000 0.98000 49 -440 ’WEST-LO 12.000
PSS®E 34.2
10-39
BUS# X-- NAME --X BASKV CODE ZERO SEQ SHUNT NEG SEQ SHUNT POS SEQ SHUNT MVA-LOAD CURRENT-LOAD ADMITTANCE-LOAD
100 ’GEN-1’ 10.000 3 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
200 ’HYDRO’ 132.00 1 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
300 ’WEST’ 132.00 1 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
330 ’EAST-LO 12.000 1 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0500 0.0200 0.0000 0.0000 0.0000 0.0000
400 ’EAST’ 132.00 1 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
440 ’WEST-LO 12.000 1 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0500 0.0200 0.0000 0.0000 0.0000 Capacitor
0.0000
550 ’MAIN-LO 12.000 1 0.0000 0.0000 0.0000 0.0000 0.0000 0.0400 0.1500 0.0800 0.0000 0.0000 0.0000 0.0000
bank not
BUS# X-- NAME --X BASKV ID CODE ST ZGEN (ZERO) ZGEN (POSITIVE) ZGEN (NEGATIVE) MBASE X T R A N GENTAP
grounded
100 ’GEN-1’ 10.000 3 3 1 0.00000 0.00000 0.00000 0.20000 0.00000 0.20000 30.0 0.00000 0.00000 1.0000 internally
X------ FROM BUS -------X X------- TO BUS --------X X- POS AND NEG SEQUENCE -X X---- ZERO SEQUENCE -----X
BUS# X-- NAME --X BASKV BUS# X-- NAME --X BASKV CKT ST ZI LINE R LINE X CHARGING LINE R LINE X CHARGING
200 ’HYDRO’ 132.00 300 ’WEST’ 132.00 1 1 0.01500 0.15000 0.02500 0.02000 0.30000 0.04000
10-40
200 ’HYDRO’ 132.00 400 ’EAST’ 132.00 1 1 0.02500 0.25000 0.04000 0.04000 0.45000 0.06500
330 ’EAST-LO 12.000 550 ’MAIN-LO 12.000 1 1 0.05000 0.50000 0.00000 0.04000 0.80000 0.00000
440 ’WEST-LO 12.000 550 ’MAIN-LO 12.000 1 1 0.05000 0.50000 0.00000 0.04000 0.80000 0.00000
X------ FROM BUS -------X X------- TO BUS --------X S W C X-- POS & NEG --X X-------- ZERO SEQUENCE --------X X- WINDING1 -X WINDNG2 MAGNETIZING Y
BUS# X-- NAME --X BASKV BUS# X-- NAME --X BASKV CK T 1 C R X R X RGROUND XGROUND RATIO ANGLE RATIO G B
100 ’GEN-1’ 10.000 200 ’HYDRO’ 132.00 1 1 T 2 0.00000 0.33000 0.00000 0.33000 0.0000 0.0000 1.00000 0.0 1.00000 0.0000 0.0000
300 ’WEST’ 132.00 330 ’EAST-LO 12.000 1 1 T 3 0.00000 0.15000 0.00000 0.15000 0.0000 0.0000 1.00000 0.0 1.00000 0.0000 0.0000
400 ’EAST’ 132.00 440 ’WEST-LO 12.000 1 1 T 3 0.00000 0.15000 0.00000 0.15000 0.0000 0.0000 1.00000 0.0 1.00000 0.0000 0.0000
Connection codes reflect center tapped primary/parallel

secondary transformer arrangements
Figure 10-19. (Cont.) Data Listings for Two-Phase System

PSS®E 34.2
three-phase system solution because it involves only balanced operation and the positive
The initial condition power flow solution is shown in Figure 10-20; this is exactly the same as for a
sequence. The bus voltages in kilovolts are line-to-line values. This solution was made with the
following PSS®E option settings:
• 50 Hz base frequency.
• Two-phase solution mode.
• Polar output of fault analysis results.
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS®E TUE, OCT 08 1991 14:58

SMALL TWO PHASE EXAMPLE RATING
SYSTEM FOR PROGRAM APPLICATION GUIDE SET A
BUS 100 GEN-1 10.0 AREA CKT MW MVAR MVA %I 1.0000PU 0.00 100
GENERATION 1 25.1 5.5R 25.7 86 10.000KV
TO 200 HYDRO 132 1 1 25.1 5.5 25.7 73 1.0313UN
BUS 200 HYDRO 132 AREA CKT MW MVAR MVA %I 1.0162PU -4.83 200
1 134.13KV
TO 100 GEN-1 10.0 1 1 -25.1 -3.3 25.3 71 1.0313LK
TO 300 WEST 132 1 1 13.3 2.5 13.5 33
TO 400 EAST 132 1 1 11.8 0.8 11.9 29
BUS 300 WEST 132 AREA CKT MW MVAR MVA %I 1.0087PU -5.91 300
1 133.15KV
TO 200 HYDRO 132 1 1 -13.3 -4.8 14.1 35
TO 330 EAST-LOD12.0 1 1 13.3 4.8 14.1 70 0.9937UN
BUS 330 EAST-LOD12.0 AREA CKT MW MVAR MVA %I 0.9955PU -7.04 330
1 11.946KV
TO LOAD-PQ 5.0 2.0 5.4
TO 300 WEST 132 1 1 -13.3 -4.5 14.0 70 0.9937LK
TO 550 MAIN-LOD12.0 1 1 8.3 2.5 8.6 58
BUS 400 EAST 132 AREA CKT MW MVAR MVA %I 1.0066PU -6.45 400
1 132.88KV
TO 200 HYDRO 132 1 1 -11.8 -4.5 12.6 31
TO 440 WEST-LOD12.0 1 1 11.8 4.5 12.6 63 0.9937UN
BUS 440 WEST-LOD12.0 AREA CKT MW MVAR MVA %I 0.9938PU -7.45 440
1 11.926KV
TO LOAD-PQ 5.0 2.0 5.4
TO 400 EAST 132 1 1 -11.8 -4.3 12.6 63 0.9937LK
TO 550 MAIN-LOD12.0 1 1 6.8 2.3 7.2 48
BUS 550 MAIN-LOD12.0 AREA CKT MW MVAR MVA %I 0.9795PU -9.39 550
1 11.754KV
TO LOAD-PQ 15.0 8.0 17.0
TO SHUNT 0.0 -3.8 3.8
TO 330 EAST-LOD12.0 1 1 -8.2 -2.1 8.5 58
TO 440 WEST-LOD12.0 1 1 -6.8 -2.0 7.1 48
Figure 10-20. Initial Condition Power Flow Solution for Two-Phase Sample System
Figure 10-20 shows output from activity SCOP corresponding directly to Figure 10-19, with no fault
applied. In this report the negative sequence and b-phase fields have no significance. The a and c
phase voltage fields show sequence and phase voltages on a line-to-ground basis. The current
values are in terms of per unit line current.
10-41
SEQUENCE /V0/ AN(V0) /V+/ AN(V+) /V-/ AN(V-)

PHASE /VA/ AN(VA) /VB/ AN(VB) /VC/ AN(VC)
550 (P.U.) 0.0000 0.00 0.9795 -9.39 0.0000 0.00

MAIN-LOD12.0 0.9795 -9.39 0.0000 0.00 0.9795 170.61
SEQUENCE /I0/ AN(I0) /I+/ AN(I+) /I-/ AN(I-)

PHASE /IA/ AN(IA) /IB/ AN(IB) /IC/ AN(IC)
TO 330 1 0.0000 0.00 0.0867 155.97 0.0000 0.00

EAST-LOD12.0 0.0867 155.97 0.0000 0.00 0.0867 -24.03
TO 440 1 0.0000 0.00 0.0722 154.05 0.0000 0.00

WEST-LOD12.0 0.0722 154.05 0.0000 0.00 0.0722 -25.95
SUM OF 0.0000 0.00 0.1589 -24.90 0.0000 0.00

CONTRIBUTIONS 0.1589 -24.90 0.0000 0.00 0.1589 155.10

330 (P.U.) 0.0000 0.00 0.9955 -7.04 0.0000 0.00

EAST-LOD12.0 0.9955 -7.04 0.0000 0.00 0.9955 172.96

TO 300 1 0.0000 0.00 0.1407 154.13 0.0000 0.00

WEST 132 0.1407 154.13 0.0000 0.00 0.1407 -25.87
TO 550 1 0.0000 0.00 0.0867 -24.03 0.0000 0.00

MAIN-LOD12.0 0.0867 -24.03 0.0000 0.00 0.0867 155.97
SUM OF 0.0000 0.00 0.0541 -28.84 0.0000 0.00

CONTRIBUTIONS 0.0541 -28.84 0.0000 0.00 0.0541 151.16
Figure 10-21. Output from Short-Circuit Solution Reporting Corresponding to Figure 10-19
Comparison of the flow into bus 550 from bus 330 in Figures 10-19 and 10-20 and shows:
Received MVA = 8.5

Receiving voltage = 0.9795 per unit = 11.754 kV (L-L) = 5.877 kV (L-G)
MVA 8.5E6
Phase current, Ip, from Figure 10-19, = = = 723.2 A
MVAbase VLL
100E6 11.754E3
Base phase current = = = 8333.3 A
VLL base 12E3
723.2
Per-unit phase current, from Figure 10-19, = = 0.08605 per unit
8333.3
Per-unit phase current, from Figure 10-20, = 0.0867 per unit
Rerunning the bus based report with the kVA output option in effect shows that bus 550 receives
8496.5 kVA from bus 330. Redoing the above calculations gives the per-unit current as
8.4965E6
= 0.08674 per unit
11.754E3 x 8333.3
All transformers in the system are connected as shown in Figure 10-13 with two low-voltage wind-
ings in parallel. This is reflected in the connection code data in Figures 10-18 and 10-19. The shunt
capacitor bank at bus 550 is connected line-to-line and is not grounded internally. Figure 10-22
shows the output from the unbalance fault calculation for a single L-G fault applied at bus 300.
10-42
As expected, the a-phase bus voltage at the fault is zero, and a current of 1.6417 per unit flows into
the fault, and at the fault I0 = I1 = Voc / (Z0 + Z1).
1.009
I0 = I1 =
0.00127 + j0.11696 + 0.28804 + j1.07742
= 0.1933 - j0.798 = 0.8211-76.4

Figure 10-23 shows the result for an L-G fault at bus 330. Here, because no zero-sequence ground
path exists in the secondary system except for the fault, there is no fault current, and no unbalance
appears in the 132 kV primary system.
The ground connection at one point in the system does not affect the balanced load current at bus
330, and the fault current is zero. The a-phase voltage at bus 330 is zero, as expected. The c-phase
voltage at bus 330 is listed by SCMU as 1.991 per unit. The phase voltages listed by SCMU are
per-unit of phase-to-ground base voltage, and correspond to an a-phase-to-ground voltage of kV.
LINE TO GROUND FAULT AT BUS 300 [WEST 132] PHASE 1

L-G Z = 0.0000E+00 0.0000E+00
SEQUENCE THEVENIN IMPEDANCES AT FAULTED BUSES:
BUS NAME BSKV ZERO POSITIVE NEGATIVE

300 WEST 132 0.00127 0.11696 0.28804 1.07742 0.00000 0.00000
LINE TO GROUND FAULT AT BUS 300 [WEST 132]:

300 (P.U.) 0.0960 -172.91 0.0960 7.09 0.0000 0.00

WEST 132 0.0000 0.00 0.0000 0.00 0.1920 -172.91

FROM 200 1 0.1810 -80.09 0.7558 -80.88 0.0000 0.00 Load currents
HYDRO 132 0.9368 -80.73 0.0000 0.00 0.5749 98.87 flowing in
FROM 330 1 0.6400 -82.91 0.0679 -98.25 0.0000 0.00
c-phase
EAST-LOD12.0 0.7057 -84.37 0.0000 0.00 0.5749 -81.13
a-phase fault current contributions

SUM OF CONTRIBUTIONS INTO BUS 300 [WEST 132]:
300 0.8208 -82.29 0.8208 -82.29 0.0000 0.00

WEST 132 1.6417 -82.29 0.0000 0.00 0.0000 0.00
CONTRIBUTIONS EQUIVALENT POSITIVE SEQUENCE ADMITTANCE 0.0927 -8.5492
I0 = I1 for a-phase
FAULT CURRENT AT BUS 300 [WEST 132]:
fault current
300 0.8208 -82.29 0.8208 -82.29 0.0000 0.00
WEST 132 1.6417 -82.29 0.0000 0.00 0.0000 0.00
Fault current
POSITIVE SEQUENCE EQUIVALENT FAULT ADMITTANCE 0.0927 -8.5492
Figure 10-22. Simple L-G Fault at Bus 300
10-43
UNBALANCES APPLIED:
LINE TO GROUND FAULT AT BUS 330 [EAST-LOD12.0] PHASE 1

L-G Z = 0.0000E+00 0.0000E+00

330 EAST-LOD12.0 ****************** 0.32217 1.14687 0.00000 0.00000
LINE TO GROUND FAULT AT BUS 330 [EAST-LOD12.0]: Zero voltage at point of

ground on system
Voltage on
330 (P.U.) 0.9955 172.96 0.9955 -7.04 0.0000 0.00
EAST-LOD12.0 0.0000 0.00 0.0000 0.00 1.9910 172.96
ungrounded
phase is fully
SEQUENCE /I0/ AN(I0) /I+/ AN(I+) /I-/ AN(I-) offset
FROM 300 1 0.0000 0.00 0.1407 -25.87 0.0000 0.00

WEST 132 0.1407 -25.87 0.0000 0.00 0.1407 154.13
FROM 550 1 0.0000 0.00 0.0867 155.97 0.0000 0.00
MAIN-LOD12.0 0.0867 155.97 0.0000 0.00 0.0867 -24.03
SUM OF CONTRIBUTIONS INTO BUS 330 [EAST-LOD12.0]: Ground does

not affect
330 0.0000 0.00 0.0541 -28.84 0.0000 0.00
EAST-LOD12.0 0.0541 -28.84 0.0000 0.00 0.0541 151.16 balanced load
current;
CONTRIBUTIONS EQUIVALENT POSITIVE SEQUENCE ADMITTANCE 0.0505 -0.0202 compare with
Fault current is zero Figure 10-20
FAULT CURRENT AT BUS 330 [EAST-LOD12.0]:
330 0.0000 0.00 0.0000 0.00 0.0000 0.00

EAST-LOD12.0 0.0000 0.00 0.0000 0.00 0.0000 0.00
POSITIVE SEQUENCE EQUIVALENT FAULT ADMITTANCE 0.0000 0.0000
Figure 10-23. Simple Ground Connection at Bus 330
Figure 10-24 shows the results when the a-phase of the 12-kV system is grounded (by an L-G fault)
at both bus 330 and bus 550. In some cases, the ungrounded zero-sequence network cannot be
handled by PSS ® E because its admittance matrix is singular. This problem is rectified by
connecting a low admittance branch to ground in the zero sequence at an appropriate bus; this
small shunt admittance is insignificant in relation to the admittances of the system branches, but is
adequate to avoid the numerical problems stemming from the singular matrix.
Figure 10-25 shows the phase currents from Figure 10-24 on the 2-line diagram of the secondary
system. Note the following:
• The SUM OF CONTRIBUTIONS shown by the unbalance fault calculation for the a-
phase includes both load and ground current.
Current does flow on the a-phase conductor from bus 330 to 550 even though it is solidly grounded
at both ends, as a result of the mutual coupling between the two phases of the line. No current would
flow in the a-phase conductor if the two phases were of isolated-phase construction and had no
phase-to-phase mutual impedance.
10-44
LINE TO GROUND FAULT AT BUS 330 [EAST-LOD12.0] PHASE 1

L-G Z = 0.0000E+00 0.0000E+00
LINE TO GROUND FAULT AT BUS 550 [MAIN-LOD12.0] PHASE 1

L-G Z = 0.0000E+00 0.0000E+00

330 EAST-LOD12.0 0.00007********* 0.32217 1.14687 0.00000 0.00000
550 MAIN-LOD12.0 0.04007-99.20067 0.42517 1.25624 0.00000 0.00000

330 (P.U.) 1.0066 172.51 1.0066 -7.49 0.0000 0.00

EAST-LOD12.0 0.0000 0.00 0.0000 0.00 2.0132 172.51 Zero voltage at
grounded point
FROM 300 1 0.0000 0.00 0.1517 -23.04 0.0000 0.00
WEST 132 0.1517 -23.04 0.0000 0.00 0.1517 156.96
FROM 550 1 0.0386 -26.93 0.0616 155.92 0.0000 0.00
MAIN-LOD12.0 0.0231 160.69 0.0000 0.00 0.1001 -25.18
Note current flow in a-phase conductor even
though it is grounded at both ends
SUM OF CONTRIBUTIONS INTO BUS 330 [EAST-LOD12.0]:
330 0.0386 -26.93 0.0902 -22.33 0.0000 0.00

EAST-LOD12.0 0.1287 -23.71 0.0000 0.00 0.0518 161.10

Load current
LINE TO GROUND FAULT AT BUS 550 [MAIN-LOD12.0]:

550 (P.U.) 0.9953 170.86 0.9953 -9.14 0.0000 0.00
MAIN-LOD12.0 0.0000 0.00 0.0000 0.00 1.9906 170.86 Zero voltage at
grounded point
FROM 330 1 0.0386 153.07 0.0616 -24.08 0.0000 0.00

EAST-LOD12.0 0.0231 -19.31 0.0000 0.00 0.1001 154.82
FROM 440 1 0.0000 0.00 0.0614 -23.79 0.0000 0.00

WEST-LOD12.0 0.0614 -23.79 0.0000 0.00 0.0614 156.21
SUM OF CONTRIBUTIONS INTO BUS 550 [MAIN-LOD12.0]:

Algebraic sum of load and ground current
550 0.0386 153.07 0.1229 -23.93 0.0000 0.00
MAIN-LOD12.0 0.0844 -22.56 0.0000 0.00 0.1615 155.35 Load
current
Figure 10-24. Secondary System Grounded at Buses 330 and 550
10-45
Bus 330 Bus 550
0.049-j0.0168 0.0906-j0.0426 0.0562-j0.0248
0.147-j0.0674
0.14-j0.594 0.0218-j0.00764 0.0562-j0.0248
0.069-j0.035 0.069-j0.035
Figure 10-25. Current Flows (per unit) from Figure 10-24

PSS®E treats unbalanced fault analysis as a direct extension of its power flow activities. All that is
needed to perform unbalanced fault calculations on a fully detailed, solved power flow case is to
augment the positive sequence power flow data with the corresponding negative and zero
sequence data, and to use fault analysis activities in place of power flow activities. The working
case always includes provision for negative and zero sequence data values corresponding to the
positive sequence parameters of the appropriate system components. This data may be introduced
into the working case at any time and, after being introduced, it is saved and retrieved by activities
SAVE and CASE, respectively, as an integral part of a Saved Case.
The fault analysis activities of PSS®E are capable of working with the transmission network repre-
sented in the same degree of detail as in power flow. Specifically, the fault analysis activities
recognize:
1. Both resistance and reactance, and include all actual shunt branches and line charging in
the three sequence networks.
2. Both the magnitude ratio and phase shift of all transformers, including the inherent shift of
delta-wye transformers if it is specified in the positive sequence transformer data.
3. The actual spread of internal voltage magnitude and phase angle of generators as initialized
from a solved power flow case.
4. Loads by converting them to equivalent constant shunt admittance.
Each fault calculation is a complete solution for the full sequence and phase specification of condi-
tions at every bus. The user may obtain output of voltage at any bus, or current, apparent
impedance or apparent admittance at the entry to any branch (refer to activity SCOP). Multiple
10-46
unbalanced conditions may be applied simultaneously.
After the system positive sequence and fault analysis data have been properly coordinated and
saved, the fault analysis process is a direct parallel of the power flow switching study procedure
outlined in Section 10.6.7 Operation of Activity SCMU. The principal steps in a fault analysis calcu-
lation are:
1. Set up the power flow case for the pre-switching system condition. When a solved case is
to be the initial condition, the working case must be a solved case. Otherwise, the bus
boundary conditions must correspond to the pre-fault condition (refer to activity FLAT). This
provides the basis for the initialization of all generators and the conversion of all loads to
constant admittance.
2. Change branch and generator status as required, or adjust loads and shunts, to produce the
desired post-switching system conditions excluding unbalances. This may require the use
of activities CHNG and SQCH or the [Spreadsheet].
3. Establish all required sequence network admittance matrices for the post-switching condi-
tion with activity SEQD. When the sequence network setup option is disabled (refer to
Section 3.3.3 Program Run-Time Option Settings and activity OPTN), activity SEQD must
be executed by the user before initiating activity SCMU. When the sequence network setup
option is enabled, activity SCMU automatically executes activity SEQD each time it is
executed.
4. Apply all unbalances that are to exist in the post-switching condition and solve the resulting
interconnected sequence networks for the complete set of system voltages. This step is
handled by activity SCMU. Activity SCMU will re-establish the network admittance matrices
for the post-switching condition prior to performing the calculations.
5. Use activity SCOP to obtain output as required.
It is important to note the relationship and sequencing of steps 2 through 4. Steps 2 and 3 represent
the setup of the balanced post-switching system condition. In most cases, step 2 is not needed and
the procedure is to use activity SEQD followed by activity SCMU. When calculating multiple fault
cases from the identical pre-switching system condition when no balanced switchings are required
to get to the post-switching conditions, it is not necessary to execute activity SEQD prior to each
fault calculation. Activity SEQD needs to be executed following any equipment status changes, or
any branch, shunt or load data changes with activities CHNG, SQCH, or the [Spreadsheet].
In applying the unbalances shown in Figure 10-5, the following points should be noted:
1. Both resistance and reactance must be specified for each impedance shown. Impedances
are specified in per unit relative to base impedance.
2. It is not necessary to multiply ground fault impedances by three; this is done automatically
by activity SCMU.
3. The branch on which an in-line unbalance is to be applied must be in-service in the power
flow case before activity SEQD is executed. Activity SCMU opens the branch at one end
automatically if the one end opened option is selected and re-establish the network admit-
tance matrices.
4. Only one in-line unbalance may be applied during any execution of activity SCMU. The loca-
tion of this unbalance is automatically assigned the bus number 999999 by activity SCMU.
10-47
5. For in-line unbalances, the user is required to enter a distance factor, A, specifying the
distance of the fault from the from bus or closed end of the line. The A factor is equal to the
distance from this bus to the unbalance in per unit of the total line length. The user is
cautioned against the use of A factors very close to zero or one because faults very close
to the sending or receiving end of the branch can give very low impedances between the
dummy bus and the closer terminal bus.
6. The single and double phase closed unbalances place new phase branches in parallel with
any that are already present between the specified buses in the working case.
7. The single and double phase closed unbalances are applicable to discrete components
such as series capacitors and jumpers, but are not applicable to transmission lines.
8. All unbalances applied in an execution of activity SCMU remain in effect through subse-
quent executions of activity SCOP. Each execution of activity SEQD or SCMU clears all
previously applied unbalances and deletes the dummy buses 999999 and 999998 from the
system.
The user may create unbalanced conditions other than those that are automated by activity SCMU
by judicious use of dummy buses and low impedance branches. The fault analysis activities are
normally able to handle a branch impedance as low as j0.0001 per unit without difficulty. However,
when introducing jumper branches which are not being treated as zero impedance lines, the user
should examine the impedances of other branches connected to these buses to check for an
extremely wide range of impedances, which could result in numerical precision problems.
In the summary output for ground faults (refer to Section 10.6.8 Unbalance Condition Summary
Report), the sums of the ground currents in (6) and the fault currents in (7) should equal the sum of
contributions tabulated in (4). Differences give an indication of the degree of numerical precision
error present in the fault case solution.
Activity SCMU is sensitive to the fault analysis modeling option setting (refer to Section 3.3.3
Program Run-Time Option Settings and activity OPTN) in effect at the time activity SEQD is
selected (refer to Section 10.5.1 Application Notes). When the two phase system modeling option
is in effect, L-G faults, either at a bus or along a branch, and the single phase closed unbalance
must not be applied to the B phase (i.e., do not enter a 2 in selecting the phase). Similarly, for the
L-L-G faults and the two phase closed unbalance (which are actually balanced conditions), the B
phase must be designated as the excluded phase. A three phase fault must not be applied.
Using the two phase option, negative sequence and B phase quantities are shown in the output
reports as zero.
®
PSS E GUI Users Guide, Section 15.2, Running Fault Analysis under Unbalance Condition
Section 12.2, Running Fault Analysis under Unbalance Condition
10-48
Program Operation Manual Multiple Unbalanced Fault Report
10.7 Multiple Unbalanced Fault Report

Activity SCOP
Run Activity SCOP - GUI

Fault > Solve and report network with unbalances (SCMU/SCOP)…
[Multiple Simultaneous Unbalances]
Solution Output Tab
Run Line Mode Activity SCOP - CLI
ACTIVITY?
>>SCOP

AB
The unbalanced network solution output activity SCOP tabulates the results of activity SCMU. It
allows the user to obtain output of all bus voltages and either branch currents, apparent impedances
or apparent admittances.
The user may process the entire working case or specify a bus subsystem (refer to Section 4.8
The user mus select one of the following branch quantities:
• Currents (default)
• Apparent impedances
• Apparent admittances
Activity SCOP recognizes the fault analysis output options (refer to Section 3.3.3 Program Run-
Time Option Settings), with quantities printed in either physical units or per unit, and in either rect-
angular or polar coordinates. These option settings may be modified with activity OPTN.
The data printed for any bus, i, consists of:
1. Sequence and phase voltages at bus i. This is identical to the bus voltage block described
in Section 10.6.8 Unbalance Condition Summary Report.
2. Series branch quantity for each branch and machine connected to bus i consisting of either:
a. Branch series currents leaving bus i, in either per unit or amps. These are in the
reverse direction of the currents described in Section 10.6.8 Unbalance Condition
Summary Report.
b. Branch apparent impedances looking down each branch from bus i, expressed in
either per unit or ohms. These apparent impedances are defined as:
10-49
Calculating Automatic Sequencing Fault Program Operation Manual
Vseq i Vphase i
Zseq ij = Zphase ij =
Iseq ij Iphase ij
where the sequence and phase currents are the total currents flowing into the line
at bus i, including contributions from line charging capacitance, line connected
shunt admittances, and transformer magnetizing admittance. Infinite impedance is
printed as 9999 per unit or 999999 ohms.
c. Branch apparent admittances looking down each branch from bus i, expressed in
either per unit or mmhos. Apparent admittances are defined as the reciprocal of
apparent impedances. Infinite admittance is printed as 9999 per unit or
99999 mmhos.
3. When branch currents are being tabulated, the sum of all contributions flowing into bus i.
This is the total current apparently flowing to ground at bus i and is identical to the sum of
contributions block described in Section 10.6.8 Unbalance Condition Summary Report.
4. When branch currents are being tabulated, the sum of load and shunt current at bus i. This
is identical to the load and shunt current block described in Section 10.6.8 Unbalance
Condition Summary Report. Load and shunt current output is suppressed if the three
sequence shunt and load contributions are all zero.
Note that the direction of current flow in the series branch output is the reverse of that in the
summary output of activity SCMU; it follows the power flow output convention of current leaving the
bus.
When output is directed to the user’s terminal, a summary description of each active unbalance is
printed at the top of the first page of output produced by activity SCOP. Otherwise, the unbalance
summary is printed on each page of output of activity SCOP.
Activity SCOP may be terminated by entering the AB interrupt control code.
Section 15.3, Running Detailed Fault Analysis under Unbalance Condition
Section 12.3, Running Detailed Fault Analysis under Unbalance Condition
10.8 Calculating Automatic Sequencing Fault

Activity ASCC
There are two APIs which run activity ASCC.
ASCC_1A api
- allows only three phase and line-to-ground fault types
- can only be run from BAT commands and automation files
- generates text output report in original format
ASCC_3 api
10-50
Program Operation Manual Calculating Automatic Sequencing Fault
- in addition to three phase and line-to-ground fault types, allows line-line-to-ground

and line-to-line fault types
- allows to display fault currents on slider diagram
- allows to save fault calculation results into results file
- allows contour plots of maximum fault currents
- can be run from GUI, BAT commands and automation files
- generates text output report in new format
Requirements / Prerequisites, ASCC_1A

Validly specified power flow case with sequence data appended to it.
Reading Sequence Data
Run Line Mode Activity ASCC - CLI
ACTIVITY?
>>ASCC

AB
Requirements / Prerequisites, ASCC_3

Validly specified power flow case.
For unbalanced fault calculations, sequence data appended to saved case.
Run Activity ASCC - GUI
Fault > Automatic sequence fault calculation (ASCC)…
[Automatic Sequence Fault Calculation]
AB
The automatic sequencing short circuit calculation activity ASCC allows the user to apply a series
of single faults at various locations in the working case. Activity ASCC provides for:
1. ASCC_1A api: A pre-fault network condition either as specified in the working case or,
optionally, corresponding to classical flat fault analysis assumptions.
ASCC_3 api: A pre-fault network condition can be:

• as specified in the working case, i.e., from working case power flow solution
• corresponding to classical flat fault analysis assumptions
• linear power flow assumptions, i.e, set synchronous and asynchronous machines real
and reactive power to zero, and set machine bus voltages to specified voltage.
• set faulted bus voltage at specified value.
10-51
2. The specification of the subsystem to be processed according to the standard selection

criteria used throughout PSS®E. Each electrically connected bus in the specified subsystem
becomes the home bus for one or more fault analysis network solutions.
3. ASCC_1A api: The application of only three phase faults or both three phase and single-
line-to-ground faults at each fault location.
ASCC_3 api: If sequence data is not present in the working case, only three phase faults
will be calculated.
4. The application of the faults selected in (3) at each home bus selected in (2).
5. Optionally, (4) again with each branch connected to the home bus in turn removed from
service.
6. Optionally, (4) again with the far end of each branch connected to the home bus in turn
opened, and the faults applied at the line end position.
7. Optionally, (4) again with specified branches in turn removed from service.
8. A selection of output options for each fault applied, ranging from a tabulation of fault currents
through detailed output of conditions at the home bus along with detailed output for all buses
up to < n > levels removed from the home bus.
ASCC_1A api: If sequence data has not been read into the working case via activity RESQ, an
appropriate error message is printed and activity ASCC is terminated.
ASCC_3 api: If sequence data is not present in the working case, only three phase faults will be
calculated.
The user specifies one or all of the following fault calculation options for the correct execution of
activity ASCC.
Table 10-1. Automatic Sequencing Short Circuit Calculation Options
ASCC_1A api only:
Three phase fault: Apply only three phase fault.
Line to ground (L-G) fault: If enabled, both a three phase fault and a phase A to
Faults to apply ground fault are applied at each fault location.
ASCC_3 api only:
Apply selected fault types from three phase, line-to-ground, line-line-to-ground, and
line-to-line faults.
If enabled, the selected fault calculations are repeated at each home bus < n > addi-
tional times: once with each of its < n > connected branches placed out-of-service. In
Line outage cases addition, if any branches have been designated in the Fault Control Data File (refer to
Section 10.8.4 Detailed Bus Output Report) as branches to be outaged for the
current home bus, these fault cases are also calculated.
10-52
If enabled, the selected fault calculations are repeated for each home bus at least < n >
additional times: once (twice for any three-winding transformer which has all its wind-
ings in-service) with each of its < n > connected branches opened at the far end, with
Line end faults
the fault located at the line end position. As in activity SCMU, a dummy bus, numbered
999999, is introduced at the opened end of the branch for each line end fault (refer to
Line Faults).
ASCC_1A api only:
If enabled (default), classical fault analysis conditions are assumed for the network in
the working case.
• Bus voltages are assumed to be one per unit at zero phase angle.
• Constant power, current, and admittance loads are neglected in the
positive and negative sequence networks. Grounded loads are
represented in the zero sequence network.
• Generator and induction machine power outputs are assumed to be zero.
• FACTS devices and dc lines are ignored.
• Transformer phase shift angles are assumed to be zero. Any transformer
impedance, which is a function of phase shift angle, is assumed to be at
nominal value.
• Transformer turns ratios are assumed to be one. This includes generator
Impose flat
step-up transformers, which are modeled as part of the machine
conditions
representation (i.e., the GENTAP). Any transformer impedance, which is
a function of turns ratio, is assumed to be at nominal value.
• Line charging is neglected in all three sequence networks.
• Fixed bus shunts are neglected in all three sequences.
Switched shunts are neglected in all three sequences.
Line shunts and magnetizing admittances are neglected in all three sequences.
• The zero sequence ground ties created by grounded transformer
windings are represented; see Section 5.5.3, Transformers in the Zero
Sequence, and Figures 5-20 and 5-21.
If disabled, the level of network modeling and the bus boundary conditions used by
activity ASCC as the pre-fault network condition are as specified in the working case at
the time activity ASCC is selected. If unblocked dc lines or in-service FACTS devices
are present in the working case, the user specifies their treatment in the fault analysis
solution, either to block or to represent dc lines and FACTS devices as load.
DC lines and FACTS devices can be blocked or represented as load.
Represent dc lines If represented as load, the apparent ac system complex loads are converted to positive
and FACTS sequence constant admittance load at the buses at which these quantities are injected
devices as load into the ac system during normal power flow work. In the negative and zero sequence
networks, dc lines and FACTS devices are represented as open circuits. The selected
option applies to all dc lines and FACTS devices in the working case.
10-53
If the line-to-ground fault option had been selected and the actual positive sequence
impedance of any transformer in the working case differs from its nominal value (refer to
Transformer Impedance Correction Tables), the user may apply transformer
Apply transformer
impedance correction to zero sequence impedance. The zero sequence impedance
impedance correc-
of each such transformer is scaled by the same factor as is its positive
tion to zero
sequence sequence impedance. Otherwise, all zero sequence transformer impedances
are left at their nominal values (i.e., the values entered in activities RESQ,
TRSQ, or SQCH). The same treatment applies to all transformers in the
system that are not at nominal impedance.
Synchronous and ASCC_3 api only:
Asynchronous
machines power When selected synchronous and asynchronous machines real and reactive
output option power poutputs are set to zero.
ASCC_3 api only:

Select either of the following options to set transforer off-nominal tap ratios and
Transformer tap
phase shift angles data.
ratios and phase • Leave tap ratios and phase angles unchanged
shift angles option • Set tap ratios = 1.0 pu and phase angles = 0
• Set tap ratios = 1.0 pu and phase angles unchanged
• Set tap ratios unchanged and phase angles = 0
ASCC_3 api only:
Select either of the following synchronous machine reactances to use in fault
Generator Reac- analysis.
tance option • Subtransient
• Transient
• Synchronous
ASCC_3 api only:
Select either of the following options to set line charging susceptance data.
Line charging
• Leave line charging unchanged
option
• Set line charging to zero in positive and negative sequence
• Set line charging to zero in all sequences
ASCC_3 api only:
Select either of the following options to set fixed shunts, loads, and switched
shunts and transformer magnetisizing
Shunt option
• Leave shunts unchanged
• Set shunts to zero is positive and negative sequence
• Set shunts to zero is all sequences
ASCC_3 api only:
Select either of the following options to set load data.
Load option • Leave loads unchanged
• Set loads to zero s positive and negative sequence
• Set loads to zero is all sequences
10-54
ASCC_3 api only:
Select either of the following options to set pre-fault bus voltages.
Pre-fault Bus
Use the bus voltages as obtained in power flow solution
Voltage option
Set all bus voltages to a specified value
Set faulted bus voltage to a specified value
The user specifies one of the following output options:
ASCC_1A api:
• Full output at home bus and N levels
• Full output at home bus, summary at N levels
• Fault current summary table
Output option
ASCC_3 api:
• Total fault currents
• I”k contributions to N levels away
• Total fault currents and I”k contributions to N levels away
If one of the full output options is selected, the user must indicate the portion of the
working case for which output is to be generated for each fault calculation. The default
entry for the number of levels back for contributions output is 3.
Number of levels If zero is specified, activity ASCC restricts the output to the home bus for each fault. If 1
back for contribu- is specified, output for the home bus is printed followed by the output for all buses
tion output connected to it for each fault case solution.
Generalizing, a response of a positive number < n > results in output for the home bus,
followed by output for all buses connected to it, followed by output for all buses two
buses away from it, and so on up to < n > levels removed from the home bus.
ASCC_1A api only: This defines the form of output for cases involving L-G faults. If the
single-line-to-ground fault and one of the full output at the home bus options have been
selected above, the user may specify one of the following options for unsymmetrical
Unsymmetrical fault reporting:
fault reporting • A phase currents / apparent impedances
• 3 x zero sequence currents / zero sequence apparent impedances
• Both sets of currents / impedances
Optional Fault Control Data file (*.fcd), a file containing data records of the form defined
in Fault Control Data File Contents. Through the use of this file, various faulting and
reporting options may be specified. Refer to Section 10.8.1 Automatic Sequencing
Fault control input
Fault Selection Options for details and Section 2.4.1 File Usage for the file specifi-
file
cation conventions used by activity ASCC. This file provides the user with more
flexibility in selection of faults to be simulated and in the manner in which output is
limited or extended.
Optional Relay Output Data file (*.rel) (see Section 10.8.7 Relay File Output), a file
into which activity ASCC summarizes the faults performed and the short-circuit
current levels in pu. Refer to Section 2.4.1 File Usage for the file specification
Relay file conventions used by activity ASCC. Refer to Section 2.6 Files Created By
PSS®E for the file overwriting conventions used by activity ASCC. The file is
generated as a *.rel type in ASCII format; readily portable to an Excel type.
Bypass the entry to suppress the optional file generation.
10-55
ASCC_3 api only: Optional ASCC Results Output file (*.sc), a file into which
ASCC_2 api saves fault calculation results. This file is a binary file, and can be
Results file
used to reproduce ASCC calculation results in report format and/or on slider
diagram without re-running ASCC_2.
10-56
10.8.1 Automatic Sequencing Fault Selection Options

The term home bus refers to any bus location selected for application of either three phase faults
or both three phase and single-line-to-ground faults. Figure 10-26 shows a three bus system in
which Bus I has been selected for fault application L.
Figure 10-26. Home Bus
Bus I is the home bus and if faults are to be selected only at home buses there will be a maximum
of 2 faults applied at Bus I, if both a three phase and a single-line-to-ground fault are applied. With
only a 3-phase fault applied the number of faults will be limited to one.
Figure 10-27 shows the option where a fault is to be applied at the home bus with all circuits in
service and with each outgoing line out of service in turn. In this situation, for this home bus, there
will be 4 faults if only one fault type is selected. If line outages are performed on a selective basis
instead of selecting all outgoing branches, the number of faults applied will clearly be reduced.
10-57
Figure 10-27. Faults at Home Bus for Each Outgoing Line
Figure 10-28 shows the option where a fault is to be applied at the home bus with all circuits in
service and faults applied at the open end of each outgoing line. In this situation, for this home bus,
there will be 4 faults if only one fault type is selected.
10-58
Figure 10-28. Home Bus and Open Line End Faults
The user can select output options for each fault applied, ranging from a tabulation of fault currents
through detailed output of conditions at the home bus along with detailed output for all buses up to
< n > levels away from the home bus.
Figure 10-29 clarifies the concept of < n > levels away. It can be seen that, given the possibility of
a large combination of home buses, line out cases and line open end cases, coupled with a value
of < n > greater than 1, the possibility arises for a very large output listing or file.
In the diagram, for the home bus shown, there are 3 buses which are 1 level away and 2 buses
which are 2 levels away.
The user should take care in selection of the number of fault and output options.
10-59
Figure 10-29. Clarification of Home Bus and < n > Levels Away
10-60
10.8.2 Fault Control Data File Contents

The Fault Control Data File consists of two groups of records. With the first group of records, buses
may be categorized as not to be faulted. This provides, for example, for the suppression of fault
calculations at dummy buses. In addition, for the purpose of reporting bus conditions for faults at
other buses, each bus may be categorized as being either:
1. Printed and counted in the levels away calculation.
2. Not printed but counted.
3. Not printed and not counted.
This group of records is of the form:
IBUS, FCODE, PCODE

where:
IBUS Bus number. Bus IBUS must be present in the working case. No default is allowed.
FCODE Fault code of either zero (suppress faulting of bus IBUS) or one (allow bus IBUS to
be faulted). FCODE = 1 by default.
PCODE Print control code for conditions at bus IBUS when some other bus is faulted.
PCODE may be specified as either zero (no reporting, and not counted in the
levels away calculation), one (no reporting, but counted in the levels away calcula-
tion), or two (reported and counted). PCODE = 2 by default.
Data records may be entered in any order. This group of records is terminated with a record spec-
ifying an IBUS value of zero.
The hidden star point buses of three-winding transformers are always assumed to have FCODE
and PCODE values of zero. Any other bus for which no data record is read is assigned the default
values given above.
With the second group of records, for any bus to be faulted, the following may be specified:
1. Up to 20 buses where conditions are to be tabulated for all fault cases calculated for this
home bus. These buses are in addition to those printed as a result of the levels away
selection.
2. Up to eight additional branches to be outaged in turn with the home bus faulted. These fault
cases are calculated only if the line out option was selected, and are in addition to the auto-
matic outaging of the branches connected to the home bus. Only non transformer branches
and two-winding transformers may be specified.
Data for each home bus specified here is entered on three consecutive data records as follows:
IBUS
JBUS1, JBUS2, ... JBUS20
I1, J1, CKT1, ... I8, J8, CKT8
where:
IBUS Bus number. Bus IBUS must be present in the working case. No default is allowed.
10-61
JBUSi Bus number of a bus to be reported for home bus IBUS fault calculations. The first
zero value of JBUSi is interpreted as the end of JBUS values for bus IBUS.
JBUSi = 0 by default.
Ii, Ji, CKTi The from bus number, to bus number and branch circuit identifier respectively of a
branch to be outaged with bus IBUS faulted. The first zero value of Ii is interpreted
as the end of branch specifications for bus IBUS. Ii = 0 and CKTi = 1 by default; no
default is allowed for Ji.
Input is terminated with a record specifying an IBUS value of zero.
If any of the data records in the block for bus IBUS contains an error (e.g., bus not found), an appro-
priate message is printed and the entire block for bus IBUS is ignored.
All three records must be entered for each bus block specified. If, for example, one or more output
buses are to be specified for bus IBUS but no additional branches for outage calculations are
required, the third record must still be specified; it may either have a zero as its first bus number or
simply be a blank line.
The buses and branches in the block for bus IBUS are used only if bus IBUS is among the buses
selected for processing as home buses, and an FCODE value of zero was not specified for bus
IBUS.
Bus JBUSi is not reported if it was assigned a PCODE value of zero or one, or if it is not connected
back to the home bus via in-service ac branches.
Outage fault cases are calculated only if the Line outage cases option box is checked in the dialog.
10.8.3 Operation of Activity ASCC

Activity ASCC builds and factorizes the sequence admittance matrices, reporting its progress in the
same manner as does activity SEQD. If sequence data has not been appended to the power flow
case, an appropriate error message is printed and calculation process is terminated.
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. Regardless of the method
of designating home buses, those buses for which an FCODE value of zero was specified in the
Fault Control Input Data File (refer to Section 10.8.2 Fault Control Data File Contents) are skipped
as activity ASCC sequences through fault cases.
The fault calculation of activity ASCC may be terminated by entering the AB interrupt control code.
10-62
10.8.4 Detailed Bus Output Report

In order to better understand the output, several examples will be developed each of which
assumes a fault on Bus 151 in the savnw.sav power flow case. Different fault and output options
will be used. The location of Bus 151 relative to neighboring buses is shown in Figure 10-30 where
it can be seen that there are 4 buses at one level away. They are buses 101, 102, 152 and 201.
Figure 10-30. Location of Bus 151 and Buses One Level Away in savnw.sav
Each page of the detailed bus output report generated by activity ASCC contains a heading block,
which tabulates the current date and time, the two-line case heading, and the home bus number
and name. If the flat conditions option was specified, this is noted; if the line outage or line end
condition is being reported, this is also flagged. If subsystems are being specified by area, zone,
and/or owner, the area, zone, and/or owner, as appropriate, currently being processed are also
identified.
The home bus, the level number, relative to the home bus, of buses where output is printed on the
page, and, if appropriate, a line out or line end identifier are printed on the right side of the banner
block. If line-to-ground faults are being calculated and subsystem selection by area, zone, and/or
owner is enabled, the current area, zone, and/or owner is also printed here. This facilitates the
locating of a desired set of output from within a lengthy report by fanning through the stack of paper.
Voltages, currents and apparent impedances are printed in either physical units (kV L-G, amps and
ohms) or per unit, and in either rectangular or polar coordinates, according to the fault analysis
output options currently in effect (refer to Section 3.3.3 Program Run-Time Option Settings and
10-63
activity OPTN). If the physical units option has been enabled and the bus where base voltage is
required for the calculation of a quantity has no base voltage specified for it, the quantity is printed
in per unit.
For each bus at which conditions are reported (i.e., for each at bus), the following quantities are
tabulated:
1. The bus number, name, base voltage, and area number in which it is located. This is
followed by the positive sequence bus voltage for the three phase fault case. If single line to
ground faults are being calculated, the A phase voltage and the three sequence voltages for
the L-G case are printed.
2. If the bus is the home bus, the sequence Thevenin impedances at the fault point in per unit,
rectangular coordinates. If only three phase faults are being calculated, only the positive
sequence Thevenin impedance is printed.
3. The machine identifier and currents arriving at the bus from all in-service machines at the
bus. For the L-G fault, either zero sequence, A phase, or both quantities are printed,
according to user specification.
4. The from bus number, name, base voltage, area number, and circuit identifier of each non-
transformer branch and two-winding transformer connected to the at bus. The branch quan-
tities tabulated include the current arriving at the at bus from the from bus, the apparent
impedance as seen at the from bus looking down the line toward the at bus (i.e., the V/I ratio
at the from bus), and the ratio of apparent X/R. For the L-G fault, either zero sequence, A
phase, or both quantities are printed, according to the user specification. Branches are
printed in ascending from bus numerical or alphabetical order according to the bus output
option in effect.
5. The winding number, transformer name and circuit identifier of each three-winding trans-
former connected to the at bus. The current arriving at the at bus from the transformer is
tabulated. For the L-G fault, either zero sequence, A phase, or both currents are printed,
according to the user specification. Three-winding transformers are printed in ascending
transformer name order.
6. The current flowing to ground at the bus exclusive of any fault current. These currents, anno-
tated TO SHUNT, include any load and shunt current at the bus as well as the ac side current
of any unblocked dc line or in-service FACTS device. In the zero sequence, only the shunt
load plus fixed and switched shunt is produced here; specifically, the zero sequence ground
ties created by grounded transformer windings are not shown here but are included in the
branch contribution output of (4) and (5) above. For the L-G fault, either zero sequence, A
phase, or both quantities are printed, according to the user specification. Load and shunt
current output is suppressed if the corresponding sequence load and shunt admittances are
all zero.
7. If the bus is the home bus, the fault current.
All buses reported according to the full output option and all home buses reported according to the
full output with summary option are printed as described above.
In reporting remote contributions using the full output with summary option, only machine and
branch quantities are tabulated in a form similar to (3), (4) and (5) above. A branch is only reported
once: at the end which is closer to (i.e., fewer levels away from) the home bus.
10-64
With both full output options printing is suppressed for remote contributions at buses for which a
PCODE value of zero or one was specified in the Fault Control Data File. In addition, upon encoun-
tering a remote bus with a PCODE value of zero, those buses connected to the bus that would
normally be at the next level away are promoted to the current level.
If the fault current summary table option has been specified, one output line is printed for each fault giving
the fault currents. Fault currents are printed in either amps or per unit, and in either rectangular or
polar coordinates, according to the fault analysis output options currently in effect (refer to
Section 3.3.3 Program Run-Time Option Settings and activity OPTN). If the physical units option
has been enabled and the faulted bus has no base voltage specified for it, fault current is printed in
per unit. If line out and/or line end faults are being calculated, for a given home bus, the bus fault is
reported first. Then the line out and/or line end faults involving each branch connected to the home
bus in turn are processed.
10.8.5 Example: Automatic Sequencing, 3-Phase Faults, ASCC API

This case assumes application of only 3-phase faults at bus 151 with full reporting at the home bus
and one level away. Faults are applied with all lines in service, with each outgoing line out of service
in turn and with an open line-end fault on each outgoing line in turn. Output is in rectangular
coordinates.
In Figure 10-31, overleaf, the results for the home bus are listed. It can be seen that although there
is a 600 Mvar shunt connected at bus 151, the total shunt current is zero. This is clearly because
the voltage at this bus (the faulted home but is zero).
Note that the listing has been compressed slightly from the original output listing for the portrait
view.
In Figure 10-32, the results are listed for the 1 Level away. It can be seen that there is a listing for
the four immediate neighbors of bus 151, the home bus. The information on branch flows has the
same format as that of the home bus, at the 0 Level because the full report options was selected
for these buses.
- PSS/E SHORT CIRCUIT OUTPUT THU, FEB 26 2004 11:35 .HOME BUS IS 151.
- PSS/E PROGRAM APPLICATION GUIDE EXAMPLE .NUCPANT 500.0.
- BASE CASE INCLUDING SEQUENCE DATA .
- *** FAULTED BUS IS: 151 [NUCPANT 500.0] *** 0 LEVELS AWAY
AT BUS 151 [NUCPANT 500.00] AREA 1 (PU) U+: 0.0000+J 0.0000
THEV. R, X, X/R: POSITIVE 0.00409 0.01765 4.318
T H R E E P H A S E F A U L T
X--------- FROM --------X AREA CKT I/Z RE(I+) IM(I+) RE(Z+) IM(Z+) APP X/R
101 [NUC-A 21.600] 1 1 PU/PU 9.8734 -11.0030 0.0003 0.0136 45.333
102 [NUC-B 21.600] 1 1 PU/PU 9.8734 -11.0030 0.0003 0.0136 45.333
152 [MID500 500.00] 1 1 PU/PU -0.2319 -6.2545 0.0031 0.0500 16.264
152 [MID500 500.00] 1 2 PU/PU -0.2319 -6.2545 0.0031 0.0500 16.264
201 [HYDRO 500.00] 2 1 PU/PU 3.3729 -16.5469 0.0010 0.0151 14.864
TO SHUNT (P.U.) 0.0000 0.0000
TOTAL FAULT CURRENT (P.U.) 22.6560 -51.0619
Figure 10-31. Report Output at the Home Bus ( 0 level) for a 3-Phase Fault
10-65
In Figure 10-32 it can be seen that the immediate neighbors to bus 151 are the buses 101, 102, 152
and 201. Those buses, at 1 level away, are now the AT buses. The flows shown in the tabulation
are from the from buses towards the respective AT buses.
As an example, it can be seen that the flow shown for bus 101 is the flow from bus 151 to bus 101.
The flow is(-9.8734 11.003). This has the opposite sign from that shown in Figure 10-31 where the
home bus 151 is the AT bus.
Figure 10-33 shows the Fault Current Summary report from the calculation which applies a three
phase fault. It shows the fault current for a fault at Bus 151 with all lines in. It can be seen that the
result is the same as that shown in Figure 10-31. The report then lists the results for a fault at Bus
151 each outgoing line OUT of service and with the fault at the open END.
- PSS/E SHORT CIRCUIT OUTPUT THU, FEB 26 2004 11:35 .HOME BUS IS 151.
- PSS/E PROGRAM APPLICATION GUIDE EXAMPLE .NUCPANT 500.0.
- BASE CASE INCLUDING SEQUENCE DATA .
- *** FAULTED BUS IS: 151 [NUCPANT 500.0] *** 1 LEVELS AWAY
AT BUS 101 [NUC-A 21.600] AREA 1 (PU) U+: 0.1526+J 0.1310
MACHINE 1 PU/ 9.8734 -11.0030
151 [NUCPANT 500.00] 1 1 PU/PU -9.8734 11.0030 0.0000 0.0000 0.000
AT BUS 102 [NUC-B 21.600] AREA 1 (PU) U+: 0.1526+J 0.1310
MACHINE 1 PU/ 9.8734 -11.0030
151 [NUCPANT 500.00] 1 1 PU/PU -9.8734 11.0030 0.0000 0.0000 0.000
AT BUS 152 [MID500 500.00] AREA 1 (PU) U+: 0.2871+J 0.0269
151 [NUCPANT 500.00] 1 1 PU/PU 0.1847 5.7520 0.0000 0.0000 0.000
151 [NUCPANT 500.00] 1 2 PU/PU 0.1847 5.7520 0.0000 0.0000 0.000
153 [MID230 230.00] 1 1 PU/PU -1.2158 -5.5759 -0.0060 0.0542 9.048
151 [EAST500 500.00] 2 1 PU/PU 0.5901 -1.5481 0.1073 0.1860 1.733
3004 [WEST 500.00] 5 1 PU/PU 0.2561 -4.3801 0.0193 0.1146 5.929
AT BUS 201 [HYDRO 500.00] AREA 2 (PU) U+: 0.2516+J 0.0340
151 [NUCPANT 500.00] 1 1 PU/PU -3.3525 16.3960 0.0000 0.0000 0.000
202 [EAST500 500.00] 2 1 PU/PU -2.0353 -2.4222 -0.0750 0.0792 1.056
204 [SUB500 500.00] 2 1 PU/PU -1.6657 -4.1394 -0.0358 0.0893 2.496
211 [HYDRO_G 500.00] 2 1 PU/PU 6.9513 -9.0796 0.0117 0.0405 3.461
TO SHUNT (P.U.) -0.1021 0.7547
Figure 10-32. Current Flows 1 Level Away from Home Bus 151 for Three-Phase Fault
10-66
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS/E THU, FEB 26 2004 11:36

PSS/E PROGRAM APPLICATION GUIDE EXAMPLE SHORT CIRCUIT
BASE CASE INCLUDING SEQUENCE DATA FAULT CURRENTS
| THREE PHASE FAULT

X------ BUS ------X X------ TO BUS ------X CKT RE(I+) IM(I+)
151 [NUCPANT 500.0 P.U. 22.6560 -51.0619
151 [NUCPANT 500.0 101 [NUC-A 21.600] 1 OUT P.U. 12.7826 -40.0589
151 [NUCPANT 500.0 101 [NUC-A 21.600] 1 END P.U. 5.5934 -26.1350
151 [NUCPANT 500.0 102 [NUC-B 21.600] 1 OUT P.U. 12.7826 -40.0589
151 [NUCPANT 500.0 102 [NUC-B 21.600] 1 END P.U. 5.5934 -26.1350
151 [NUCPANT 500.0 152 [MID500 500.00] 1 OUT P.U. 21.9500 -48.2059
151 [NUCPANT 500.0 152 [MID500 500.00] 1 END P.U. 5.0230 -14.4880
151 [NUCPANT 500.0 201 [HYDRO 500.00] 1 OUT P.U. 18.3905 -41.1311
151 [NUCPANT 500.0 201 [HYDRO 500.00] 1 END P.U. 10.0377 -24.6822
Figure 10-33. Fault Summary Report with 3-Phase Fault on Bus 151
10.8.6 Example: Automatic Sequencing, 3-Phase & Single L-G Faults, ASCC
API
This case assumes application of 3-phase faults and single-line-to-ground faults at bus 151 with full
reporting at the home bus. Faults are applied with all lines in service and output in polar coordinates.
The output will be 3 x zero sequence currents and zero sequence apparent impedances.
With the single-line-to-ground faults included, the report format is the same as for only 3-phase
faults. The results now append the zero sequence fault current flows in the branches connected to
the home bus. In addition the negative and zero sequence Thevenin impedances are shown,
together with the A phase and sequence voltages at the faulted bus.
With polar coordinates used, it can be seen that the total fault current is 55.8625 / -66.07 pu,
compared to the rectangular coordinate output which, in Figure 10-31, is 22.656 -51.0619 pu. The
listing for < n > levels away will use the same format shown in Figure 10-32 with, in this case, the
zero sequence (L-G) results appended in the right hand columns.
10-67
10-68
Figure 10-34. Results for Three-Phase and Single Phase fault at bus 151
10-69
10.8.7 Relay File Output

The relay output file optionally generated by the automatic sequence fault calculations activity
contains a single-line summary for each fault calculation performed. Each line commences with a
code indicating the type of fault:
Code Type of Fault

3 Three-phase fault at the home bus
1 Line-to-ground fault at the home bus
30 Three-phase line end fault
10 Line-to-ground line end fault
5 Line-line-to-ground fault at the home bus
7 Line-to-line fault at the home bus
50 Line-line-to-ground line end fault
70 Line-to-line line end fault
The following quantities are tabulated in the indicated column positions of each record
2-3: Fault code

5-10: Home bus number
12-17: from bus number (0 if the branch is a three-winding transformer) for line out or line
end, or blank
19-24: to bus number for line out or line end, or blank
26-27: Circuit identifier for line out or line end, or blank
29-41: Fault current magnitude in per unit
43-55: Ratio of imaginary/real components of fault current
58-75: Extended bus name of home bus
78-95: Extended bus name of from bus (3WND: followed by the three-winding transformer
name if from bus field is 0), or blank
98-115: Extended bus name of to bus, or blank

Activity ASCC is a totally self-contained fault analysis calculation. All that is required prior to
entering activity ASCC is a valid power flow case with sequence data appended to it (i.e., with a
activity RESQ having been executed). Bus voltages and boundary conditions must correspond to
the desired pre-fault network condition, unless the flat conditions option is specified.
Activity ASCC may be preceded by activity FLAT to impose different levels of flattening than is
implemented by the flat conditions option of activity ASCC. For example, the flat option of activity
ASCC retains grounded loads in the zero sequence (refer to Load Sequence Data). To calculate
fault cases with these set to zero, the following procedure may be used:
1. Bring the "unconverted" network into the working case.
2. Use activity FLAT specifying the following options:
10-70
• set classical fault analysis conditions.

• set tap ratios to unity.
• set charging to zero.
• set fixed bus shunts to zero in all sequence networks.
• set switched shunts to zero in all sequence networks.
• set line shunts to zero in all sequence networks.
• set magnetizing admittances to zero in the positive sequence network.
• set loads to zero in all sequence networks.
3. Then run activity ASCC without specifying the flat conditions option.
Although activity ASCC uses the SEQD temporary file (refer to Section 2.2 The PSS®E Working
Case and Temporary Files), the execution of activity SEQD is not required prior to selecting activity
ASCC. Activity ASCC sets up this file in the form required for its fault solution calculation. Note that,
because activity ASCC uses this file, the following activity sequence would not be valid:
1. SEQD
2. SCMU (perhaps several times)
3. ASCC
4. SCMU
Activity SEQD would need to be re-executed following activity ASCC, prior to the second series of
executions of activity SCMU.
Activity ASCC is sensitive to the fault analysis modeling option setting (refer to Section 3.3.3
Program Run-Time Option Settings and activity OPTN). Using the two phase option, negative
sequence Thevenin impedances are shown in the output report as zero.
As with all user specified output files used in PSS®E, the relay output summary file designated
during an execution of activity ASCC does not have data appended to it if the file already exists. If
the contents of a relay output file are to be appended to a previously existing file, a new filename
should be specified during activity ASCC and the two files may be subsequently merged with the
text editor following termination of activity ASCC.
PSS®E GUI Users Guide, Section 15.4, Calculating Automatic Sequencing Fault
Section 12.4, Calculating Automatic Sequencing Fault
10-71
Calculating Fault Currents to ANSI Standards Program Operation Manual
10.9 Calculating Fault Currents to ANSI Standards

Activity ANSI
Run Activity ANSI - GUI

Fault > ANSI fault calculation (ANSI)…
[ANSI Fault Current Calculation]
AB
The ANSI fault current calculation activity ANSI calculates fault currents according to the ANSI stan-
dard C37.5-1979 Guide for Calculation of Fault Currents for Application of AC High-Voltage Circuit
Breakers Rated on a Total Current Basis.
The following input data defining solution and reporting options is specified to the ANSI_2 API
routine:
The positive sequence generator reactance to be used (refer to Generator Sequence Data) Either
subtransient, transient, or synchronous reactance may be used at all in-service synchronous
machines.
• The treatment of the zero sequence impedance of all transformers where actual posi-
tive sequence impedance differs from its nominal value (refer to Transformer
Impedance Correction Tables). The zero sequence impedance of each such trans-
former may either be scaled by the same factor as is its positive sequence impedance,
or all zero sequence transformer impedances may be left at their nominal values (i.e.,
the values entered in activities RESQ, TRSQ, or SQCH). The same treatment applies
to all transformers in the system that are not at nominal impedance.
• Decay factors to be applied. Decay factors may be obtained from either Figures 1 and
2 of the ANSI standard, which include the effects of both ac and dc decay, or from
Figure 3, which includes only the effects of dc decay.
• Resistance scaling factors. For branches and machines with a zero value of resistance,
activity ANSI assigns a non-zero resistance equal to its reactance divided by a scaling
factor. Four such factors (for positive sequence branch impedance, positive sequence
machine impedance, zero sequence branch impedance, and zero sequence machine
impedance) are specified.
• Output option, selected from among the following output report formats:
a. Summary output in report format using only the ANSI X matrices (output fields are
separated by blanks).
b. Summary output in spreadsheet input format using only the ANSI X matrices
(output fields are comma delimited).
c. Detailed output in report format using only the ANSI X matrices.
d. Detailed output in report format using both the ANSI R and ANSI X matrices.
e. Summary output in report format using both the ANSI R and X matrices (output
fields are separated by blanks).
10-72
Program Operation Manual Calculating Fault Currents to ANSI Standards
f. Summary output in spreadsheet input format using both the ANSI R and X matrices
(output fields are comma delimited).
• The breaker rating option. All circuit breakers made before 1964 were tested on a,
"total current," basis. Those made after 1970 were tested on a, "symmetrical current,"
basis. Breakers made between 1964 and 1970 could have been made to conform to
either test method. Activity ANSI can calculate breaker interrupting currents according
to either method.
• Fault specification option. Faulted buses, along with their highest operating voltages
and contact parting times, may be specified either along with the other inputs to the
ANSI_2 API routine, or separately in an ANSI Fault Specification Data File (see below).
If sequence data is not contained in the working case, an appropriate error message is printed and
activity ANSI is terminated.
Activity ANSI performs the following computations on the working case:
1. An ordering for the positive sequence network is determined and the standard summary of
activity ORDR is printed at the Progress tab.
2. The positive sequence decoupled admittance matrices are constructed and factorized.
4. The zero sequence decoupled admittance matrices are constructed and factorized.
5. Fault cases are calculated.
detected, they generate an alarm. The presence of isolated buses in the positive sequence network
indicates an improperly specified power flow case. Isolated buses in the zero sequence network,
although they generated alarms, are permitted and require no special treatment. When the fault
analysis warning option is disabled (refer to Section 3.3.3 Program Run-Time Option Settings and
activity OPTN), the isolated bus tabulations are suppressed. The total number of isolated buses in
the sequence networks is tabulated.
10.9.1 ANSI Fault Specification Data File Contents

If fault specification data is to be taken from an ANSI Fault Specification Data File, the specified file
is opened and processed. Data records must be specified in the following format:
IBUS, VMAX, TIME
where:
IBUS Is the bus number of the bus to be faulted. No default is allowed.

VMAX Is the maximum operating voltage of bus IBUS specified in pu. VMAX = 1.0 by
default.
TIME Is the contact parting time in seconds. TIME = one cycle by default.
Data records may be entered in any order; fault cases are calculated and reported in the same order
in which data records are read. Input is terminated with a record specifying an IBUS value of zero.
10-73
If fault specification data is to be taken from the dialog or the BAT_ANSI command, fault cases are
calculated and reported in the same order in which the data is specified. No defaults for the
maximum operating voltage or the contact parting time are allowed.
10.9.2 Operation of Activity ANSI

If sequence data is not contained in the working case, an appropriate error message is printed and
the calculation process is terminated.
The following computations are performed on the power flow case:
1. An ordering for the positive sequence network is determined and the standard summary
printed at the progress report output device.
2. The positive sequence decoupled admittance matrices are constructed and factorized.
4. The zero sequence decoupled admittance matrices are constructed and factorized.
5. Fault cases are calculated.
detected, they generate an alarm. The presence of isolated buses in the positive sequence network
indicates an improperly specified power flow case. Isolated buses in the zero sequence network,
although they generated alarms, are permitted and require no special treatment.
When the fault analysis warning option is disabled (see Section 3.3.3 Program Run-Time Option
Settings and activity OPTN), the isolated bus tabulations are suppressed. In either case, the total
number of isolated buses in the sequence networks is tabulated.
As each fault case is calculated, its results are tabulated.
10.9.3 ANSI Fault Calculation Output Report

The summary report for each fault case includes the following:
• The bus number, name and base voltage of the faulted bus, along with the maximum
operating voltage and contact parting time input values.
• Three phase fault results, including symmetrical fault MVA, symmetrical fault current in
kA, asymmetrical fault current in kA, the ANSI X/R ratio, and the multiplying factor.
• Line-to-ground fault results, including symmetrical fault current in kA, asymmetrical
fault current in kA, the ANSI X/R ratio, and the multiplying factor.
• Line-to-line-to-ground fault results, including symmetrical phase current in kA, and
three times the zero sequence symmetrical fault current in kA.
• The positive sequence Thevenin impedance as obtained from the decoupled positive
sequence admittance matrices.
• The zero sequence Thevenin impedance as obtained from the decoupled zero
sequence admittance matrices.
An example of a summary report, obtained using the savnw.sav power flow case, with a fault on
Bus 151 (see Figure 10-35a).
10-74
In the detailed output, an output block for each faulted bus is printed. Voltages, currents and
apparent impedances are printed in either physical units (kV L-G, amps and ohms) or per unit, and
in either rectangular or polar coordinates, according to the fault analysis output options currently in
effect (refer to Section 3.3.3 Program Run-Time Option Settings and activity OPTN). If the physical
units option is enabled and the bus where base voltage is required for the calculation of a quantity
has no base voltage specified for it, the quantity is printed in per unit.
For each faulted bus (i.e., at each at bus), the following quantities are tabulated:
1. The bus number, name, base voltage, and area number in which it is located, with the spec-
ified maximum operating voltage listed below the bus identifiers. This is followed by the
positive sequence bus voltage for the three phase fault case, and the A phase voltage and
the three sequence voltages for the L-G case.
2. The positive and zero sequence ANSI Thevenin impedances at the fault point in per unit,
rectangular coordinates (the positive and negative sequences are identical to the ANSI fault
calculation standard).
3. The machine identifier and currents arriving at the bus from all in-service machines at the
bus. For the L-G fault, three times the zero sequence current (3I0) is printed.
4. The from bus number, name, base voltage, area number, and circuit identifier of each non-
transformer branch and two-winding transformer connected to the at bus. The branch quan-
tities tabulated include the current arriving at the at bus from the from bus, the apparent
impedance as seen at the from bus looking down the line toward the at bus (i.e., the V/I ratio
at the from bus), and the ratio of apparent X/R. For the L-G fault, zero sequence quantities
are printed. Branches are printed in ascending from bus numerical or alphabetical order
according to the bus output option in effect.
5. The winding number, transformer name and circuit identifier of each three-winding trans-
former connected to the at bus. The current arriving at the at bus from the transformer is
tabulated. For the L-G fault, zero sequence quantities are printed. Three-winding trans-
formers are printed in ascending transformer name order.
6. The sum of the currents output in (3), (4) and (5) above. These currents are annotated SUM
OF CONTRIBUTIONS.
7. The fault current as calculated from the maximum operating voltage and the ANSI Thevenin
reactance or impedance, as appropriate.
The quantity shown as the sum of contributions will be essentially identical to the quantity shown
as fault current for both three phase and line-to-ground faults when fault currents and contributions
are calculated using only the ANSI X matrices. However, these quantities will normally differ when
the output is calculated using both the ANSI R and ANSI X matrices. This is due to the error intro-
duced by decoupling the complex sequence admittance matrices into pairs of real matrices, using
the real matrices to derive columns of R and X matrices (i.e., the decoupled impedance matrices),
and then coupling the columns back together to get approximations of the complex impedance
matrix columns.
Figure 10-35b shows an example of a detailed report obtained for faults on Bus 151 in the
savnw.sav power flow case.
10-75
Figure 10-35. Summary and Detailed Report of ANSI Fault Calculation
10-76

While the working case may represent the network at any level of detail from classical fault analysis
assumptions through a fully solved power flow model, activity ANSI applies classical fault analysis
conditions. Specifically, voltages, loads, machine loadings, bus and line shunts, line charging,
phase shift angles, dc lines, and FACTS devices in the working case are ignored. Tap ratios and
zero sequence mutual couplings are recognized in constructing the decoupled admittance
matrices. It is quite common, and perfectly valid, to have the generator terminal bus isolated in the
zero sequence network. This is, in fact, the usual case because the majority of generator step-up
transformers are delta connected on the generator side and wye connected on the high side. This
is the assumption inherent in the generator modeling when the step-up transformer is represented
as part of the generator data (i.e., XTRAN is non-zero). Activity ANSI prints an alarm message for
any generator with non-zero values of both XTRAN and ZZERO and uses only XTRAN in setting
up the zero sequence ground tie at the Type 2 (high side) bus.
Any bus which is designated as a bus to be faulted, but which has no base voltage specified for it
in the working case, is logged and omitted from the fault calculations of activity ANSI.
Any non-zero branch or machine impedance where resistance is zero in the working case has an
assumed resistance, equal to its reactance divided by a user-specified scaling factor, used when
the corresponding R decoupled admittance matrix is constructed. Such resistances are always
positive. Zero sequence mutual impedances (RM + jXM of Zero Sequence Mutual Impedance Data)
and zero sequence transformer grounding impedances (RG + jXG of Zero Sequence Transformer
Data) are not subjected to this treatment.
Any non-zero zero sequence branch impedance where reactance is zero in the working case has
an assumed reactance, equal to the zero impedance line threshold tolerance (or to 0.00001 if the
zero impedance line threshold tolerance is 0.0), used when the zero sequence X decoupled admit-
tance matrix is constructed. Such reactances are always positive. Machine impedances, zero
sequence mutual impedances (RM + jXM of Zero Sequence Mutual Impedance Data), and zero
sequence transformer grounding impedances (RG + jXG of Zero Sequence Transformer Data) are
not subjected to this treatment.
Although activity ANSI uses the SEQD temporary file (refer to Section 2.2 The PSS®E Working
Case and Temporary Files), the execution of activity SEQD is not required prior to selecting activity
ANSI. Activity ANSI sets up this file in the form required for its fault solution calculation. Note that,
because activity ANSI uses this file, the following activity sequence would not be valid:
1. SEQD
2. SCMU (perhaps several times)
3. ANSI
4. SCMU
Activity SEQD would need to be re-executed following activity ANSI, prior to the second series of
executions of activity SCMU.
Section 15.5, Calculating Fault Currents to ANSI Standards
10-77
Setting up Classical Fault Analysis Conditions Program Operation Manual
10.10 Setting up Classical Fault Analysis Conditions

Activity FLAT
Run Activity FLAT - GUI

Fault > Setup for special fault calculations (FLAT)…
[Setup for Special Fault Calculations]
Run Line Mode Activity FLAT - CLI
ACTIVITY?
>>FLAT
SELECTED FLAT CHANGES IMPOSED
None
The classical conditions network activity FLAT is used primarily to set up network conditions corre-
sponding to classical fault analysis assumptions.
The first input to the FLAT_2 API routine selects the type of model simplification to be imposed on
the working case:
• change only voltages.

• set classical fault analysis conditions.
• set conditions in preparation for IEC standard 909 calculations.
These three degrees of simplification are discussed in the following sections.
Note that, for all three types of model simplification, the zero sequence ground ties created by
grounded transformer windings are represented; see Section 5.5.3, Transformers in the Zero
Sequence, Section 5.5.5, Two Winding Transformer Zero Sequence Network Diagrams and
Connection Codes, and Section 5.5.6, Three Winding Transformer Zero Sequence Network
Diagrams and Connection Codes.
10.10.1 Change Voltages

This option uses none of the other inputs to the FLAT_2 API routine. Under this option, activity FLAT
sets all bus voltages to one per unit at zero phase angle. This is not identical in function to the flat
start option that may be specified for the network solution activities of PSS®E, which causes swing
(Type 3) bus voltage magnitudes to be set to their scheduled values, and all other bus voltage
magnitudes to unity.
10.10.2 Set Classical Fault Analysis Conditions

Under this option, the following data changes are implemented:
• Bus voltages are set to unity magnitude at zero phase angle.

• Generator and induction machine powers are set to zero.
10-78
Program Operation Manual Setting up Classical Fault Analysis Conditions
• Transformer phase shift angles are set to zero. Any transformer impedance that is a
function of its phase shift angle (refer to Transformer Impedance Correction Table
Data) is set to its nominal value.
• FACTS devices and dc lines are removed from the working case.
• (Note: Using load treatment option, set loads to zero in all sequence for classical
assumptions.)
Further model simplification may be selected by specifying the following additional inputs to the
FLAT_2 API routine:
• Tap ratio treatment option. If this option is enabled, all transformer turns ratios are set
to one. This includes generator step-up transformers, which are modeled as part of the
machine representation (i.e., the GENTAP; refer to Generator Data and Section 12.2.3
Generator Step-Up Transformers). Any transformer impedance which is a function of
turns ratio (refer to Transformer Impedance Correction Table Data) is set at nominal
value.
• Line charging treatment option. If this option is enabled, line charging is set to zero in
all three sequence networks.
• Fixed bus shunt treatment option. One of the following may be specified:
- leave fixed bus shunts unchanged.
- set fixed bus shunts to zero in the positive and negative sequence networks.
- set fixed bus shunts to zero in all three sequence networks.
• Switched shunt treatment option. If this option is enabled, switched shunts are set to
zero in all three sequence networks.
• Line shunt treatment option. One of the following may be specified:
- leave line shunts unchanged.
- set line shunts to zero in the positive and negative sequence networks.
- set line shunts to zero in all three sequence networks.
• Transformer magnetizing admittance treatment option. If this option is enabled, trans-
former magnetizing admittances are set to zero in the positive and negative sequence
networks (they are always zero in the zero sequence network).
• Load treatment option. One of the following may be specified:
- leave loads unchanged.
- set the positive sequence constant power, current and admittance loads to zero;
model (GNEG + j BNEG) in the negative sequence network; for those loads which
are grounded, model (GZERO + j BZERO) in the zero sequence network. Refer to
Load Sequence Data.
set the negative sequence load, (GNEG + j BNEG), to zero; for those loads which
are grounded, model (GZERO + j BZERO) in the zero sequence network.
set the negative sequence load, (GNEG + j BNEG), to zero; set the zero sequence
load, (GZERO + j BZERO), to zero. (Use this option for classical assumptions.)
10-79
Calculating Short Circuit Currents According to IEC 60909 Standard Program Operation Manual
10.10.3 Set IEC 909 Fault Analysis Conditions

Under this option, the following data changes are implemented:
• Bus voltage phase angles are set to zero.

• All synchronous machines with a negative or zero active power have their active and
reactive power outputs set to zero.
• All induction machines with a positive or zero active power (i.e., induction motors) have
their active and reactive powers drawn from the network set to zero.
• Transformer phase shift angles are set to zero. Any transformer impedance that is a
function of its phase shift angle (refer to Transformer Impedance Correction Table
Data) is set to its nominal value.
• FACTS devices and dc lines are removed from the working case.
Further model simplification may be selected by specifying the additional inputs to the FLAT_2 API
routine. In addition to those that may be specified when setting classical fault analysis conditions,
the following additional data inputs to the FLAT_2 API routine are required:
• The voltage magnitude setting. When a positive value is specified, all bus voltage mag-
nitudes are set to the specified value. Otherwise, all bus voltage magnitudes remain at
their present values.
• A machine power factor setting. This setting is used at:
- synchronous machines with a positive value of active power.
- induction machines with a negative value of active power (i.e., at induction
generators).
At any such machine, its active power is unchanged, and its reactive power is set as
follows:
- if the power factor setting is positive, its reactive power is set such that the specified
power factor is maintained.
- otherwise, its reactive power is unchanged.
When the setting of IEC 909 fault analysis conditions is followed by activity BKDY, short circuit
currents in conformance with IEC standard 909 are calculated (see Section 10.12 Calculating
Circuit Breaker Interrupting Duty). Note that loads should normally be set to zero in preparation for
IEC 909 fault current calculations.
PSS®E GUI Users Guide, Section 15.6, Using Classical Fault Analysis Option
Section 12.5, Using Classical Fault Analysis Assumptions
10.11 Calculating Short Circuit Currents According to IEC 60909
10-80
Program Operation Manual Calculating Short Circuit Currents According to IEC 60909 Standard
Standard
Activity IECS
Requirements / Prerequisites
Validly specified power flow case.
For unbalanced fault calculations, sequence data appended to Saved case or
Run Activity IECS - GUI
Fault > IEC 60909 fault calculation (IECS)…
[IEC 60909 Fault Calculation]
None
The activity IECS allows the user to apply shunt faults at various locations in a PSS®E working case
to compute short circuit currents according to the IEC 60909 standard.
Activity IECS calculates following currents (refer to the Program Application Guide, Volume I,
Section 11.10.2 Calculation of Short Circuit Currents for details).
Initial symmetrical short-circuit current (r.m.s) including phase and sequence

I"k
components of fault currents
ip(B) Peak short-circuit current by Method B of IEC standard 60909
ip(C) Peak short-circuit current by Method C of IEC standard 60909
ib(DC) DC component of the asymmetrical breaking current using Method C R/X ratio
ib(SYM) Symmetrical breaking current (r.m.s.)
ib(ASYM) Asymmetrical breaking current (r.m.s.)
Activity IECS includes the following features.
1. The impedances of synchronous generators, network transformers and power station units
are modified with impedance correction factors when calculating short circuit currents with
the equivalent voltage source at the short circuit location according to IEC 60909 standard.
(The model of a synchronous generator with a step-up transformer (GSU) is called a Power
Station Unit in IEC 60909.)
2. The specification of network subsystems to be processed according to PSS®E standard

selection criteria. Each electrically connected bus in the specified subsystem becomes the
home bus for one or more fault analysis network solutions.
3. The specification of three phase faults (3PH), single-line-to-ground (LG) faults, double-line-
to-ground (LLG) faults and line-to-line (LL) faults at each fault location or any combinations
of these faults.
4. The application of the faults selected in (3) at each home bus selected in (2).
10-81
5. A selection of output options for each fault applied, ranging from a tabulation of fault currents
through detailed output of conditions at the home bus along with detailed output for all buses
up to < N > levels away removed from the home bus.
The original values of all data items in the working case are not modified by activity IECS. That is,
at the termination of activity IECS, the working case is identical in content to what it was at the time
activity IECS was initiated.
The following inputs are required.
Table 10-2. Short Circuit Calculation Options for IEC 60909
Fault type selection, select either any combination or all:
• Three phase faults
Faults to apply • Single line to ground fault
• Line-line to ground fault
• Line to line fault
If enabled, the selected fault calculations are repeated at each home bus < n > addi-
tional times: once with each of its < n > connected branches placed out-of-service. In
Line outage
addition, if any branches have been designated in the Fault Control Data File (refer to
cases Section 10.8.4 Detailed Bus Output Report) as branches to be outaged for the
current home bus, these fault cases are also calculated.
If enabled, the selected fault calculations are repeated for each home bus at least < n >
additional times: once (twice for any three-winding transformer which has all its wind-
ings in-service) with each of its < n > connected branches opened at the far end, with
Line end faults
the fault located at the line end position. As in activity SCMU, a dummy bus, numbered
999999, is introduced at the opened end of the branch for each line end fault (refer to
Line Faults).
The possible options are:
Output option • Total fault currents
• I''k contributions to < N > levels away
• Total fault currents and I''k contributions to < N > levels away
The possible options are:
• Fault at Network bus (default)
Fault location
• Fault at LV bus of Power Station Unit
• Fault at Auxiliary Transformer (connected to Power Station Unit) LV bus
Select either of the following options to set fixed shunts, loads and switched shunts
data.
Shunt option • Set shunts to zero is positive sequence
• Leave shunts unchanged
10-82
Table 10-2. Short Circuit Calculation Options for IEC 60909 (Cont.)
Line charging • Set line charging to zero in positive sequence
option • Set line charging to zero in all sequences
• Leave line charging unchanged
When selected transformer off-nominal tap ratios are set to unity,
Transformer taps
When unselected, transformer off-nominal tap ratios are considered
DC lines and FACTS devices can be blocked or represented as load.
Represent dc lines If represented as load, the apparent ac system complex loads are converted to positive
and FACTS sequence constant admittance load at the buses at which these quantities are injected
devices as load into the ac system during normal power flow work. In the negative and zero sequence
networks, dc lines and FACTS devices are represented as open circuits. The selected
option applies to all dc lines and FACTS devices in the working case.
If the line-to-ground fault option had been selected and the actual positive sequence
impedance of any transformer in the working case differs from its nominal value (refer to
Transformer Impedance Correction Tables), the user may apply transformer
Apply transformer
impedance correction to zero sequence impedance. The zero sequence impedance
impedance correc-
of each such transformer is scaled by the same factor as is its positive
tion to zero
sequence sequence impedance. Otherwise, all zero sequence transformer impedances
are left at their nominal values (i.e., the values entered in activities RESQ,
TRSQ, or SQCH). The same treatment applies to all transformers in the
system that are not at nominal impedance.
Select either of the following options to set transformer off-nominal tap ratios
and phase shift angles data.
Transformer tap • Leave tap ratios and phase angles unchanged
ratios and phase
shift angles option
• Set tap ratios = 1.0 pu and phase angles = 0
• Set tap ratios = 1.0 pu and phase angles unchanged
• Set tap ratios unchanged and phase angles = 0
Select either of the following options to set fixed shunts, loads and switched
shunts and transfomrer magnetisizing admittance data.
Shunt option • Leave shunts unchanged

• Set shunts to zero is positive and negative sequence
Line charging • Leave line charging unchanged

option • Set line charging to zero in positive and negative sequence
• Set line charging to zero in all sequences
10-83
Table 10-2. Short Circuit Calculation Options for IEC 60909 (Cont.)
Select either of the following synchronous machine reactances to use in fault
analysis.
Generator Reac- • Subtransient
tance option
• Transient
• Synchronous
If one of the full output options is selected, the user must indicate the portion of the
working case for which output is to be generated for each fault calculation. The default
entry for the number of levels back for contributions output is 3.
Number of levels If zero is specified, activity ASCC restricts the output to the home bus for each fault. If 1
back for contribu- is specified, output for the home bus is printed followed by the output for all buses
tion output connected to it for each fault case solution.
Generalizing, a response of a positive number < n > results in output for the home bus,
followed by output for all buses connected to it, followed by output for all buses two
buses away from it, and so on up to < n > levels removed from the home bus.
Breaker contact parting time in seconds (5.0/Base frequency by default,
Breaker time
increased/decreased in seconds per cycle of Base frequency)
Specify eqivalent voltage source at the fault location as below:
Voltage Factor C • for the calculation of maximum short-circuit currents

option • for the calculation of minimum short-circuit currents
• a particular voltage factor C value
Optional IEC data input file: IEC data filename (*.iec), a file containing data records of
IEC Data file
the form defined in IEC Data File Contents.
Fault control input Optional Fault Control Data file (*.fcd), a file containing data records of the form defined
file in Fault Control Data File Contents.
Optional IEC Results Output file (*.sc), a file into which IECS saves fault calcula-
tion results. This file is a binary file, and can be used to reproduce IECS
Results file
calculation results in report format and/or on slider diagram without re-running
IECS.
10.11.1 IEC Data File Contents

The impedances and admittances of electrical equipment in the working case are modified
according to the correction factors defined in IEC 60909-0, Section 3.
Generators, equivalent generators and asynchronous motors are represented as sources in the
working case. To calculate their impedance correction factors additional data is required. This addi-
tional data is provided in IEC data file (.iec).
Additional data is needed in the following cases.
• If a generator model includes a GSU transformer. It is recommended to represent the

GSU transformer explicitly as a separate power component so as to be able to correctly
modify the generator and transformer impedances as per the IEC 60909 standard.
10-84
• If a generator in the working case is an equivalent generator representation.

• If a generator is a used in the modeling of a synchronous motor.
• If a generator is set with QMIN=QMAX, then it is treated as an asynchronous motor. If
this is the case, then additional data is not necessary.
• If a transformer winding MVA specified in system MVA base and not nameplate winding
MVA.
• If an induction machine base power (MBASE) is specified as mechanical power output
(BCODE=1), then power factor and efficiency are needed to calculate base MVA. If an
induction machine scheduled active power (PSET) is set as real electrical power drawn
by the machine, efficieny is needed to calculate mechanical power output (MW) of the
machine.
There are three groups of records, with each group containing a particular type of data required.
Each record is teminated by specifying a bus number of 0.
GSU, Equivalent Generator and Motor Data

(Induction Motors are specified as part of Generator data category)
Each data record has the following format:
I, ID, MCTYPE, UrG, PG, PFactor, PolePair, GSUType, Ix, Jx, Kx, Ckt, PT
where:
I Machine bus number

ID Machine ID
MCTYPE Machine type
MCTYPE =1, for Generator
MCTYPE =2, for Equivalent generator
MCTYPE =3, for Induction machines specified as part of generator data category
UrG Rated terminal voltage, line-to-line in kV r.m.s. (this need not be the rated bus
voltage)
PG Range of generator voltage regulation in %, e.g., if PG is ±5%, enter PG=5.
PG = (UG -UrG)/UrG, where UG is the scheduled generator terminal voltage
= 0 default
PFactor Generator rated power factor (used only if MCTYPE=1).
This is used in impedance correction factor calculations.
= 1.0 default
PolePair Number of pole pairs if machine is induction machine (used only if the machine is
modeled as induction machine)
Example: If the induction machine has a six pole construction then Polepair=3
GSUType Generator step-up-transformer type
GSUType =0, no GSU, GSU transformer modeled explicitly.
GSUType =1, GSU with OLTC
GSUType =2, GSU without OLTC
10-85
Ix GSU transformer I bus number

Jx GSU transformer J bus number
Kx GSU transformer K bus number
Ckt GSU transformer circuit identifier
PT Tap range of GSU off-load tap-changer transformer in % of transformer winding
rated voltage, e.g., if PT is ±5%, enter PT=5
Transformer Nameplate Winding MVA Data

I, J, K, Ckt, Sbase 1-2, Sbase 2-3, Sbase 3-1
where:
I Winding 1 bus number

J Winding 2 bus number
K Winding 3 bus number ( =0 for two-winding transformer)
Ckt Transformer circuit identifier
Sbase 1-2 Winding 1 to winding 2 Nameplate MVA
Sbase 2-3 Winding 2 to winding 3 Nameplate MVA (not required for two-winding transformer)
Sbase 3-1 Winding 3 to winding 1 Nameplate MVA (not required for two-winding transformer)

(Induction Motors are specified as part of Indcution machine data category)
I, ID, PolePair, PFactor, Efficiency
where:
I Machine bus number

ID Machine ID
PolePair Number of pole pairs
Example: If the induction machine has a six pole construction then Polepair=3
PFactor Induction Machine rated power factor
= 1.0 default
Efficiency Induction Machine percent efficiency.
=100 by default
Example: Efficiency=96.5 for 96.5% efficiency.
Data records for generating units and motors may be entered in any order and using a free format
with blanks or commas separating each data item in each record. These records are terminated
10-86
with a record specifying machine bus number I value of zero. Following is an example of IEC data
for IEC 60909-4, Section 6 network. (Refer PAG for details.)
1 Q1 2
5 Q2 2
6 G3 1 10.5 0.0 0.8
41 G1 1 21.0 0.0 0.85 0 1 4 41 0 T1 12
31 G2 1 10.5 7.5 0.9 0 2 3 31 0 T2
0 / END OF GSU, EQV, GEN, AND INDUCTION MACHINE DATA
0 / END OF TRANSFORMER DATA
7 M1 1 0.88 97.5
7 M2 2 0.89 96.8
7 M3 2 0.89 96.8
0 / END OF INDUCTION MACHINE DATA
10.11.2 Fault Control Data File Contents

The fault control data file contents and format is the same as those used in the fault control data file
of the activity ASCC. The records in this file are treated same way as they are treated in activity
ASCC.
10-87
Calculating Circuit Breaker Interrupting Duty Program Operation Manual

Activity IECS is a totally self-contained fault analysis calculation. All that is required prior to entering
activity IECS is a valid working case with sequence data appended to it if unsymmetrical fault
currents are to be calculated. If the working case does not have sequence data, only three phase
fault currents will be calculated and unsymmetrical faults will be ignored. The fault currents are
calculated with positive sequence equivalent voltage sources and network sequence impedances.
It is not required to solve the power flow because the power flow solution (i.e., initial state of the
network) is not used by the IECS activity when calculating fault currents. When calculating IEC
impedance correction factors, default values used are: Generator power factor = 1.0, Generator
rated terminal voltage (UrG) = Generator bus voltage (UG), Range of generator voltage regulation
(PG) = 0, Tap range of GSU off-load tap-changer transformer (PT) = 0.
In a PSS®E saved case, if most of the transformer data is specified on system MVA base and trans-
former winding MVA is not actual winding MVA, it is required to provide nameplate transformer
winding MVA as a transformer IEC data record.
Section 15.7, Calculating Short Circuit Currents According to IEC 60909 Standard
10.12 Calculating Circuit Breaker Interrupting Duty

Activity BKDY
Run Activity BKDY - GUI

Fault > Circuit breaker interrupting duty (BKDY)…
[Circuit Breaker Interrupting Duty]
Run Line Mode Activity BKDY - CLI
ACTIVITY?
>>BKDY
>>
AB, CM, DC, FD
The circuit breaker duty analysis activity BKDY calculates and reports circuit breaker interrupting
duty for three phase faults at all buses in a specified subsystem of the working case. The working
case is assumed to represent the pre-fault system condition with generators represented as current
sources.
At each bus in the specified subsystem in turn, activity BKDY applies a three phase fault, calculates
two network solutions, giving the initial alternating fault current and the decremented alternating
fault current at the user specified fault duty time. The decremented dc offset and total fault currents
are then derived, and results tabulated.
As an alternative to the standard subsystem selection procedure used throughout PSS®E, fault
locations and corresponding breaker operating times may be specified in a Fault Specification Data
10-88
Program Operation Manual Calculating Circuit Breaker Interrupting Duty
File (refer to Section 10.12.5 Operation of Activity BKDY).
Machine parametric data required by activity BKDY is specified in a Breaker Duty Data File.
The sudden application of a short-circuit fault to a power system produces currents for which tran-
sient form is shown in Figure 10-36. In the case of a three-phase fault (simultaneously applied in
each phase), the total fault current in each phase consists of the following:
1. An alternating component that decays from an initial subtransient value to a final steady-
state value.
2. A decaying unidirectional component for which initial amplitude is equal to the difference
between the initial instantaneous value of the alternating component of fault current and the
instantaneous current in the phase just prior to fault application.
Depending upon the standard (e.g., ANSI Standard C37.5 – 1975 or the International Electrotech-
nical Commission standards) the determination of circuit breaker duty requires the calculation of
either of these values:
• The maximum instantaneous value of current in any phase at the instant, a few milli-
seconds after fault initiation, when the circuit breaker contacts separate
• The root-mean-square (rms) value of current wave consisting of sinusoidal component
of constant amplitude equal to the instantaneous amplitude of the decaying alternating
component at an instant, superimposed on a constant unidirectional component of
amplitude equal to that of the decaying unidirectional component at the same instant.
Figure 10-37 illustrates the two current values of interest. The maximum instantaneous value, as
shown in Figure 10-37a is of interest in connection with the IEC Circuit Breaker standards, while the
rms value shown in Figure 10-37b is used by ANSI C37 standards. In this section, we describe the
calculations made in PSS®E.
10-89
DC
Component
A
Current
B
DC
Component
C
DC
Component
Figure 10-36. Transient Phase Currents in Suddenly Applied Short Circuit
10-90
a. Instantaneous Peak Current
Instant of contact parting
b. Equivalent Root-Mean-Square Current
Figure 10-37. Forms of Expression of Fault Current at Instant of Circuit Breaker Opening
To determine these current amplitudes, the following data must be considered:
• The alternating current component results from decaying machine internal flux linkages
behind constant subtransient impedances of the machines.
• The unidirectional component is, at the instant of fault application, determined by the
value of the alternating component.
10-91
The alternating components can be approximated, with acceptable accuracy for several cycles after
fault application, by expressing the generator flux as:
and the equivalent for the q-axis. For induction motors (Ld = Lq and L'd = L'q), the Ld terms are not
in the above equations.
The calculations for initial fluxes, do and qo, and initial currents, ido and iqo, are based on the
initial conditions in the power flow before fault application. The value of Le at each generator is
calculated by dividing the voltage at each terminal by the current flowing at the terminals at fault
initiation. Because an initial loading on the machine, Le, will never be infinity, this approximation will
result in flux decaying even for very remote machines. The user is responsible for not including data
for machines where flux decay is not wanted.
The initial value of the unidirectional component of fault current is, in the worst case, equal to the
initial amplitude of the alternating component; this corresponds to a fully offset current wave as
shown for Phase A in Figure 10-36. Using full offset is, of course, conservative. The actual
maximum offset depends on the fault point X/R and the point on the wave where the fault occurs.
Thus, the peak is reached after some dc decay has occurred. The decay of the unidirectional
component of fault current is given by:
where a1 + a2 + … + an = 1
and
• The coefficients ki, characterize the decay of the initial unidirectional components
throughout the network.
• The coefficients, ai, express the contribution of each decaying unidirectional current
component to the unidirectional fault current.
10-92
In general, an exact expression of the unidirectional fault current would involve a number of k and
a coefficients equal to the number of branches in the network. Their determination would require a
calculation of the eigenvalues and eigenvectors of the differential equations:
[Lnet ][sLnet ] + [Rnet ][inet ] = 0

where [Rnet + sLnet] is the operational impedance matrix of the complete network. This calculation
is impractical for normal system analysis work, and it is usual to approximate the unidirectional fault
current by:
idc = Iac(0)e-t/Ts
where
Ts = Lthev / Rthev
where Lthev and Rthev are the Thevenin impedance (inductance, resistance) at the point of the fault.
10.12.1 How PSS®E Calculates Circuit Breaker Duty

PSS®E contains a special short-circuit calculation which reports circuit breaker interrupting duty for
three phase faults at all buses in a specified subsystem of the working case. It determines the ampli-
tude of the alternating and unidirectional (dc) components of current flowing in symmetrical faults
and in the branches of the network. The alternating and dc components are calculated as indicated
in the previous section for the instant of fault application and for a specified time after the fault initi-
ation. These component amplitudes are then used to determine the following:
• The maximum instantaneous current that could flow in any phase at the specified time
after fault application, assuming that the fault was initiated at such a time, in relation to
the voltage wave that the specified time after application corresponds to a current peak
(Figure 10-37).
• The rms value of the current at the specified time after fault application (Figure 10-37).
The maximum instantaneous current, Itotal peak, and rms currents, Itotal rms, are determined by
Itotal peak = Idc + Iac
Itotal rms = I2dc + I2rms

where:
Idc = Instantaneous amplitude of unidirectional component.
Iac = Peak amplitude of alternating component.
It is convenient to define an instantaneous rms value of the alternating current component, Irms, by
Iac
Irms =
2
10-93
enabling the total rms current to be written as
Itotal rms = I2dc + I2rms

The breaker duty calculation starts with a power flow case corresponding to system conditions just
before the application of the fault. The values of the initial internal fluxes, do, qo, and initial
currents, ido and iqo, are calculated from the prefault machine currents, terminal voltages, and the
characteristic machine impedances, ZSORCE.
The calculation recognizes that the time constants Tdz, Tdz, Tqz, Tqz governing the decay of
machine internal fluxes and currents are dependent on the relative values of the machine imped-
ances and the impedances of the network between the machines and the fault. The relationships
used to calculate these time constants are shown in Figure 10-38. The Le term is calculated at each
machine in the network by dividing terminal voltage by terminal current at the instant the fault is
applied.
If the fault location is close to major machines, it will present these machines with conditions approx-
imating a short circuit at their terminals, Le = 0. In this case the short-circuit time constants result.
If the fault location is remote from key generators or fault impedances are high, open-circuit time
constants result. The calculation process reads the machine reactances and the open-circuit time
constants from a Breaker Duty File. The subtransient reactances specified in this file must corre-
spond to the reactive parts of the impedances used in the generator conversion function, CONG,
Section 12.1.1, Objectives of a Balanced Switching Study which must precede the selection of
activity BKDY.
Total dc offset current is calculated in two different manners.
For method one, the instantaneous dc offset for each branch is set equal to the magnitude of the
difference between the prefault current on the branch and the instantaneous ac current after the
fault. The total dc offset current is the magnitude of the sum of these differences. Decremented dc
currents and hence total rms and total peak currents for each path are calculated by decaying each
path’s initial dc offset current by the Thevenin impedance at the point of the fault looking out each
path.
Again the total dc offset current is the magnitude of the sum of the decayed currents, which have
been stored and decayed as complex values. The values are listed in the output report on the line
headed with FAULT CURRENT.
For method two, the total instantaneous dc offset current is assumed to be equal to the total instan-
taneous ac current. This instantaneous dc offset current is decremented by the equivalent Thevenin
impedance of all paths from the fault location. The total dc offset, total rms, and total peak current
are listed following the Thevenin impedance and initial voltage on the row beginning with the word
THEVENIN.
10-94
Fault
Z
e
L L
d d
L L
d q
L L
d q
T T
do do
T T
qo qo
L + L L + L
d e q e
T dz = ---------------------- T do T qz = ---------------------- T qo
L +L L +L
d e q e
L + L L + L
d e q e
T dz = ----------------------- T do T qz = ----------------------- T qo
L + L L + L
d e q e
Figure 10-38. Relationships Between Machine Time Constants in Radial System
10.12.2 Breaker Duty Data File Contents

The input stream to activity BKDY consists of two blocks of records. The first block specifies
machine reactances and open-circuit time constants for conventional machines. It consists of a
series of records in the following format:
I, ID, T'do, T"do, T'qo, T"qo, Xd, Xq, X'd, X'q, X"
where:
is allowed.
T'do d axis transient open circuit time constant. No default is allowed.
T" do d axis subtransient open circuit time constant. No default is allowed.
T'qo q axis transient open circuit time constant. T'qo = 0. by default.
T"qo q axis subtransient open circuit time constant. No default is allowed.
Xd d axis synchronous reactance, entered in pu on MBASE base. No default is
allowed.
Xq q axis synchronous reactance, entered in pu on MBASE base. No default is
allowed.
X'd d axis transient reactance, entered in pu on MBASE base. No default is allowed.
10-95
X'q q axis transient reactance, entered in pu on MBASE base. X'q = 0. by default.

X" Subtransient reactance, entered in pu on MBASE base. No default is allowed.
The reactances listed should be saturated values.
Data records may be entered in any order. Input is terminated with a record specifying an I value of
zero.
The second block of records specifies machine reactances and open-circuit time constants for
induction machines. It consists of a series of records in the following format:
I, ID, T'o, T"o, X, X', X"
where:
I Bus number. Bus I must be present in the working case with one or more induction
machines assigned to it. No default is allowed.
ID One- or two-character induction machine identifier used to distinguish among
multiple induction machines at the bus. ID = 1 by default.
T'o Transient open circuit time constant. No default is allowed.
T" o Subtransient open circuit time constant. No default is allowed.
X Synchronous reactance, entered in pu on MBASE base. No default is allowed.
X' Transient reactance, entered in pu on MBASE base. No default is allowed.
X" Subtransient reactance, entered in pu on MBASE base. No default is allowed.
Data records may be entered in any order. Induction machine input is terminated with a record spec-
ifying an I value of zero.
10.12.3 Fault Specification Data File Contents

This file consists of a series of records in the following format:
IBUS, TIME, JBUS, CKT

where:
IBUS Bus number of the bus to be faulted. No default is allowed.

TIME Fault duty time. TIME = the value specified during the interactive dialog by
default.
JBUS Branch to bus number. JBUS = 0 by default.
CKT Branch circuit or multi section line grouping identifier. CKT = '1' by default.
If a nonzero value is specified for JBUS, the branch designated by IBUS, JBUS and CKT must be
present in the working case as an in-service branch or multi section line grouping. The specification
of a branch is used solely for output identification purposes if several fault calculations are
performed at the same bus, each with a different fault duty time.
Data records may be entered in any order; fault cases are calculated and reported in the same order
in which data records are read. Input is terminated with a record specifying an IBUS value of zero.
10-96
10.12.4 Breaker Duty Calculation Options

Table 10-3. Breaker Duty Calculation Options
Option Description
Enable or disable (default) the use of a Fault Specification Data file (see
Section 10.12.3 Fault Specification Data File Contents) as an alternative to
Fault selections
interactive subsystem selection. The user enters the name of a file containing
specified via file
information specifically defining fault locations and corresponding breaker oper-
ating times to be used.
Default fault The time after fault application at which the decremented fault current is to be
duty time calculated.
Number of
levels back for The number of levels away from the faulted bus for which contributions will be
contributions processed. A level of zero will produce contributions at only the faulted bus.
output
Breaker duty (*.bkd) This file contains the machine parametric data required for the calculation
data file (see Section 10.12.2 Breaker Duty Data File Contents).
Fault specifica- (*.bkf) This file identifies fault locations and fault duty times required to be inves-
tion data input tigated (see Section 10.12.2 Breaker Duty Data File Contents). Without this
file file, the user identifies fault locations by Area, Owner, Zone, BasekV or Bus.
10.12.5 Operation of Activity BKDY

Prior to initiating the calculation process, the user should ensure that the power flow case to be used
is converged to an acceptable mismatch level using one or more of the conventional Gauss-Seidel
or Newton-Raphson solution methods.
In addition, the user should ensure that:
• All in-service machines are converted from their power flow representation to a con-
stant Norton current source representation (see Section 12.2 Converting Generators).
• Load boundary conditions are converted from the conventional constant MVA charac-
teristic used in power flow calculations to a representation suitable for network
conditions involving abnormally low voltages.
The user has the option to perform a bus ordering. If not, PSS®E will run a new bus ordering of the
admittance matrix such that its sparsity characteristics are preserved. A new ordering is required
because the generator conversion process introduces a row and column into the admittance matrix
for each former Type 3 (swing) bus.
The short-circuit current calculations employ a triangularized Y matrix network solution which is
designed for those situations where the internal flux linkages of generators are assumed to remain
unchanged as a load or fault is switched onto the system, as a line is opened or closed, or as a load
is removed.This activity is used for balanced short circuit, motor starting, voltage dip, and initial load
rejection over voltage studies; this class of studies is termed switching studies (see Chapter 12).
The Y matrix solution handles load boundary conditions and the blowup check in the same way as
the Gauss-Seidel solution method. The solution convergence monitor, the dc transmission line
monitors for two-terminal and multi-terminal dc lines, and the mismatch summary also are identical
to those of the Gauss-Seidel method.
10-97
No automatic adjustments are allowed, and switched shunt devices and dc converter transformer
tap settings are locked at their pre switching settings. A two-terminal or multi-terminal dc transmis-
sion line is blocked during the remainder of the current execution of this breaker duty calculation if,
on any iteration, the ac voltage at a rectifier converter station bus falls below 50% or is insufficient
to make margin order. Shunt elements of FACTS devices hold their pre switching reactive currents,
and series elements are held at their pre switching series voltages.
For each in-service VSC dc line, the solution starts with each converter holding the active and reac-
tive power at the time the generators were converted to the Norton equivalent. If, on any iteration,
the corresponding current exceeds the converter’s IMAX, the injection is reduced using the power
weighting factor fraction (PWF) just as in the conventional power flow solution activities. Each
converter is treated independently, so that any reduction at one converter does not affect the injec-
tion at the other end of the VSC dc line. The dc transmission line monitor for VSC dc lines includes
the dc line name, followed by the ac power injection at each converter bus.
In reading the Breaker Duty Data File, a machine is treated as a salient pole machine if either T'qo
or X'q are specified as zero; a conventional machine is treated as an induction machine if Xd = Xq
and X'd = X'q; otherwise, a round rotor machine is assumed. For any in-service machine in the
working case for which no data record is read, the same d and q axis currents are used in the two
network solutions performed for each fault case.
Note that the user can convert the generators (activity CONG) prior to entering the circuit breaker
duty calculation. The power flow case with converted generators can be saved using a different file-
name for subsequent or frequent calculation of circuit breaker duties. When performing the
conversion, the user can elect to use the imaginary part of the ZSOURCE (used in stability anal-
yses) or the ZPOS (used in unbalanced fault calculations) machine impedance.
Regardless of the method of designating buses to be faulted, those buses which are dummy buses
of multi section lines are skipped as the calculation sequences through fault cases when the multi
section line reporting option is enabled.
If activity CONG has not been executed, activity BKDY prints an appropriate message and termi-
nates. Otherwise, if activity BKDY detects that a new execution of activity ORDR is required, a
message is printed and activity ORDR is automatically executed.
Activity BKDY uses a network solution similar to that of activity TYSL, and it handles load, dc line,
and FACTS device boundary conditions as well as the blowup check in the same way as activity
TYSL. When enabled, the solution convergence monitor, the dc transmission line monitors, and the
FACTS device monitor are identical to those of activity TYSL. Refer to Sections 12.7 and 6.3.11.
Activity BKDY responds to the following interrupt control codes:
AB Abandon activity BKDY following completion of the next iteration.

CM Print network solution convergence monitor.
DC Tabulate conditions for each dc line after each iteration.
FD Tabulate the conditions for each in-service FACTS device after each iteration.
10.12.6 Circuit Breaker Interrupting Duty Report

At each faulted bus, the current contributions from all machines and branches connected to the bus
are listed, as well as fault current. The Thevenin impedance characterizing the faulted bus as well
as its pre-fault voltage are also printed. Five columns of currents are printed:
10-98
1. Initial complex alternating current assuming no dc offset.
2. Decremented complex alternating current at the specified fault duty time, again assuming
no dc offset.
3. Peak dc offset current magnitude at the fault duty time.
4. Total rms fault current magnitude at the fault duty time.
5. Total peak fault current magnitude at the fault duty time.
The branch decremented peak dc currents in (3) above are calculated assuming that the initial dc
offset current follows from the pre-fault to post-fault instantaneous change in current, and that the
dc offset current decays at a rate dependent upon the X/R ratio of the Thevenin equivalent of the
branch assuming flat conditions. Machine currents are similarly calculated, except that the machine
(plus step-up transformer if XTRAN is non-zero) impedance is used in setting the X/R ratio. The
value printed as FAULT CURRENT is the magnitude of the sum of the decayed change in current
of each of the above components. For reference, the final line for each faulted bus’ output block
shows as peak dc current the total instantaneous fault current decayed according to the faulted bus’
Thevenin impedance as determined from the flat conditions impedance matrix. This line also shows
the Thevenin impedance (in per unit, rectangular coordinates) and pre-fault bus voltage (in per unit,
polar coordinates).
All currents are printed in either amps or per unit, and the complex currents in (1) and (2) above in
either rectangular or polar coordinates, according to the fault analysis output options currently in
effect (refer to Section 3.3.3 Program Run-Time Option Settings and activity OPTN). If the physical
units option is enabled and the bus where base voltage is required for the calculation of the current
has no base voltage specified for it, the current is printed in per unit.
In responding to the output option request, the user may suppress the contributions output
described above and limit the reporting to fault currents.
Similarly, the output report may be extended to provide contributions up to < n > levels away from
the faulted bus. A response of 1 to the output option request causes the output for the faulted bus
to be followed by machine and branch contributions output at all buses connected to it. General-
izing, a response of a positive number < n > results in output for the faulted bus, followed by output
for all buses connected to it, followed by output for all buses two buses away from it, and so on up
to < n > levels removed from the faulted bus. In reporting these remote contributions, only the
currents described in (1) and (2) above are tabulated, and a branch is only reported once: at the
end which is closer to (i.e., fewer levels away from) the faulted bus.
Option Settings and activity OPTN), the far end bus (rather than the closest dummy bus) of each
multi-section line connected to the bus being reported (the at bus) is shown as its connected bus
(its from bus). Multi-section lines are identified with an ampersand ( & ) as the first character of their
line identifiers in the branch circuit identifier column (e.g., &1; refer to Multi-Section Line Grouping
Data). When reporting remote contributions, the dummy buses of multi-section lines are neither
reported nor counted in the levels away calculation; i.e., the far end bus is one level removed from
the at bus.
Contributions from a three-winding transformer are identified by the winding number, the trans-
former name and the circuit identifier.
10-99
10.12.7 Example: Breaker Duty Results Analysis

Figure 10-39 shows a sample output report using polar coordinates and amperes for clarity. The
upper block of output shows decremented values of current based on a contact parting delay time
of zero; hence it describes the intersection of the envelope of the fully offset current wave with the
t = 0+ axis. The ac component of current is stated in rms terms, the ratio of rms value to amplitude
is 1.414, and the initial value of the dc (unidirectional) current component is 1.414  18569.7 =
26261.5 A. Also, with no decay taking place, the total peak current is twice the amplitude of the ac
component.
The center block of output specifies the situation at 25 milliseconds after fault initiation. Here the ac
component of current has decayed to 16239.1 A, while the dc component has decayed more rapidly
to 13996.6 A. The final output block, corresponding to 0.5 seconds with the dc component having
decayed to essentially zero, shows the expected 1.414 relationship between rms and peak fault
current, when expressed in amperes.
10-100
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS®E WED, OCT 09 1991 14:57

PSS®E PROGRAM APPLICATION GUIDE EXAMPLE POLAR
BASE CASE INCLUDING SEQUENCE DATA COORDINATES
FAULT DUTY TIME IS 0.000 SECONDS - ALL BREAKERS
AT 154 [DOWNTN 230] INITIAL RMS DECREMENTED RMS /DECREMENTED CURRENTS/

X----- FROM -----X CKT ALTERNATING CURNT ALTERNATING CURNT PEAK DC TOT RMS TOT PEAK
153 MID230 230 1 1921.4 -72.44 1921.4 -72.44 2124.4 2864.4 4841.6
153 MID230 230 2 1601.1 -72.44 1601.1 -72.44 1759.5 2379.0 4023.9
203 EAST230 230 1 1623.5 -74.96 1623.5 -74.96 1909.8 2506.7 4205.9
205 SUB230 230 1 10775.9 -79.68 10775.9 -79.68 13851.1 17549.2 29090.6
3008 CATDOG 230 1 2685.1 -84.00 2685.1 -84.00 3245.9 4212.5 7043.2
FAULT CURRENT (AMPS) 18569.7 -78.52 18569.7 -78.52 22878.9 29466.6 49140.4
THEVENIN IMPEDANCE: 0.00078 0.01473 V: 0.9211 -7.68 26261.5 32163.6 52523.0
Different
2 because
2 ¥ 18569.7 = 26261.5A  26261.5 
 26261.5  2 + ------------------------------ of load
2 on bus
2 ¥ 16239.1 = 22965.6 18569.7 ¥ 2 + 26261.5
 22965.6  2
 15918.6  2 + ------------------------------
2

153 MID230 230 1 1921.4 -72.44 1699.5 -66.24 1144.2 2048.8 3547.7
153 MID230 230 2 1601.1 -72.44 1416.2 -66.24 947.7 1704.1 2950.6
203 EAST230 230 1 1623.5 -74.96 1439.0 -68.62 1268.5 1918.3 3303.5
205 SUB230 230 1 10775.9 -79.68 9382.5 -71.93 9028.0 13020.7 22296.9
3008 CATDOG 230 1 2685.1 -84.00 2337.7 -79.11 1614.9 2841.2 4920.9
Decaying
total Decaying
each path
independently
22965.6 + 15918.6 = 38884.2

153 MID230 230 1 1921.4 -72.44 1405.5 -51.12 0.0 1405.5 1987.7
153 MID230 230 2 1601.1 -72.44 1171.3 -51.12 0.0 1171.3 1656.4
203 EAST230 230 1 1623.5 -74.96 1192.7 -53.87 0.5 1192.7 1687.3
205 SUB230 230 1 10775.9 -79.68 7513.8 -59.33 2.7 7513.8 10628.8
3008 CATDOG 230 1 2685.1 -84.00 1887.5 -68.18 0.0 1887.5 2669.4
Figure 10-39. Relationship of Outputs to Offset Fault Current Wave (amps)
10-101

Activity BKDY uses the same type of network solution as does activity TYSL. A typical sequencing
of activities is:
1. A standard power flow is converged to an acceptable mismatch level using one or more of
activities SOLV, MSLV, FNSL, NSOL, or FDNS. It is strongly recommended that the solved
power flow case be saved in a Saved Case File with activity SAVE.
2. Activity CONG is executed to convert generator buses from their power flow representation
to the constant Norton current source representation used in activity BKDY. See also
Figure 12-4.
3. Activity CONL is executed to convert the load boundary conditions from the conventional
constant MVA characteristic used in power flow calculations to a representation suitable for
network conditions involving abnormally low voltages (see also Section 6.3.13 Load).
4. Optionally, activity ORDR is executed to determine a bus ordering of the admittance matrix
such that its sparsity characteristics are preserved. A new ordering is required because the
execution of activity CONG introduces a row and column into the admittance matrix for each
former Type 3 (swing) bus. If this step is omitted, activity BKDY will perform the ordering
function.
5. Optionally, this converted and ordered case may be saved with activity SAVE if switching
solutions are also to be calculated from this base condition.
6. Activity BKDY is entered.
To apply a three phase fault at a bus, activity BKDY temporarily introduces a fixed shunt with a large
negative susceptance at the bus. When activity BKDY is initiated, if the fixed bus shunt table is full,
an appropriate message is printed and activity BKDY is terminated.
In reading the Breaker Duty Data File, a machine is treated as a salient pole machine if either T'qo
or X'q are specified as zero; a conventional machine is treated as an induction machine if Xd = Xq
and X'd = X'q; otherwise, a round rotor machine is assumed. For any in-service machine in the
working case for which no data record is read, the same d and q axis currents are used in the two
network solutions performed for each fault case.
The value specified for subtransient reactance for each conventional machine must be identical to
the imaginary part of ZSORCE (refer to Generator Data) when generators have been converted
with activity CONG, or to the imaginary part of ZPOS (refer to Generator Sequence Data) when
generators have been converted with activity CONG with generator conversion using fault analysis
positive sequence machine impedance ZPOS. Similarly, the value specified for subtransient reac-
tance for each induction machine must be identical to the imaginary part of the machine reactance
used in activity CONG.
Regardless of the method of designating buses to be faulted, those buses which are dummy buses
of multi-section lines are skipped as activity BKDY sequences through fault cases when the multi-
section line reporting option is enabled.
10-102
Program Operation Manual Calculating pi-Equivalent, Single Transmission Line Unbalance
®
PSS E GUI Users Guide, Section 15.8, Calculating Circuit Breaker Interrupting Duty
Section 12.6, Calculating Circuit Breaker Interrupting Duty
10.13 Calculating pi-Equivalent, Single Transmission Line

Unbalance
Activity SPCB
Run Activity SPCB - GUI

Fault > Separate pole circuit breaker (SPCB)…
[Separate Pole Circuit Breaker]
Run Line Mode Activity SPCB - CLI
ACTIVITY?
>>SPCB

None
The separate pole circuit breaker activity SPCB calculates the positive sequence pi-equivalent
corresponding to a single transmission line unbalance. This equivalent may subsequently be used
in dynamic simulations to model the branch unbalance.
10.13.1 Calculating pi-Equivalent for Unbalanced Switching

The short-circuit fault current calculations described in previous sections are based on the assump-
tion that the phase self- and mutual-impedances of each branch are balanced. Several situations
exist, especially in dynamics, where the user will want to simulate a situation in which unbalance of
the phase impedances and phase-to-phase coupling is a key effect. PSS®E contains an analytical
process which is designed to calculate positive-sequence pi-equivalents for these cases. The
process constructs positive-sequence equivalents for the following situations:
• One open phase, either grounded or not

• Two open phases
• Mid-line, line-ground, line-line-ground, or three-phase fault
• One breaker open
A series of situations where this activity would be used is shown in Figure 10-40. In this series, a
line-ground fault occurs 40% of the way down the line from bus 151 to bus 152. This is the first
unbalance condition. Next, the single-pole breaker at one end of the line opens the faulted phase
while the breaker at the other end of the line remains closed (stuck) for a period of time. This is the
second unbalanced condition. Finally, the second breaker opens to leave an unbalanced condition
10-103
Calculating pi-Equivalent, Single Transmission Line Unbalance Program Operation Manual
which is with two phases closed on the line section. The user, in a stability study, may then want to
simulate the results of such a sequence of events.
Figure 10-40. Examples of Unbalanced Network Conditions Requiring a PI Equivalent
In order to be able to simulate the three unbalanced conditions, in a stability case, the user would
have to replace the positive sequence branch, in the power flow case, with a positive sequence PI
equivalent for each of the three conditions, in sequence.
Prior to entering activity SPCB, the PSS®E working case and SEQD temporary file must be set up
in the form required by activity SPCB. The procedure is as follows:
1. Solve the working case in the pre-unbalance condition.
2. With activity CHNG or the [spreadsheet], place the transmission line which is to be subjected
to the unbalance out-of-service.
3. Ensure that the fault analysis modeling option setting is placed in the normal three phase
mode.
4. Run activity SEQD.
5. Then run activity SPCB.
10-104
10.13.2 Separate Pole Circuit Breaker Calculation Options

The user identifies the topologies, fault locations and type and grounding impedances to be simu-
lated from among the following options.
Table 10-4. Separate Pole Circuit Breaker Calculation Options
Option Description
Specification of the circuit on which the unbalance will be placed. Activity
SPCB calculates the columns of the three sequence impedance
matrices corresponding to the specified buses. These are tabulated in
sub-matrix form. Any error conditions (e.g., no such branch in the
Out-of-service branch for
working case) generate an alarm.
unbalance
• From bus (number)
• To bus (number
• Circuit ID
Unbalance type One phase open: open at both ends of the branch.
Include a path to ground can also be specified, with fault location and
line-to-ground impedance.
Two phases open: this option has no fault applications.
In-line fault. model assumes both circuit breakers are closed.
The fault can be located at any point on the line and can be a single-line-
to-ground fault, a line-to-line fault or a 3-phase fault; with selectable fault
impedance where appropriate.
One breaker: option to select the open end.
Breaker at from bus (default) or Breaker at to bus
Include a path to ground can also be specified, with fault location and
line-to-ground impedance.
PSS®E prepares the power flow case for the unbalanced network solution in a
Set up network before
manner similar to that used at the initiation of the detailed unbalanced fault anal-
solving with unbalances
ysis described in Section 10.6.6 Pre-Calculation Network Setup.
10.13.3 Transmission Line Unbalances

For the one phase open unbalance, the open phase may be grounded (faulted) or ungrounded. The
user may choose to include a path to ground. If a ground is specified, the user specifies the
grounding (fault) impedance and its location as a fraction of total line length starting at the from bus:
For the two phases open unbalance, no further unbalance specification is necessary.
For the in-line fault, the user may specify a single-line-to-ground fault, double-line-to-ground (or
line-to-line) fault, or three phase fault. For L-G and L-L-G faults, the user specifies the fault imped-
ances in the same manner as in activity SCMU (refer to Bus Faults) and the location of the fault as
a fraction of total line length starting at the from bus.
For the unbalance consisting of one breaker on one phase open, the phase with one end opened
may include a path to ground. Line to ground impedance and fault location are specified as above.
If the user specifies no unbalance, activity SPCB to go through the calculation process with the data
items representing the various unbalances set to default values. This results in no unbalance being
10-105
imposed and should result in a positive sequence pi-equivalent which is equivalent to the positive
sequence branch parameters contained in the working case.
10.13.4 Operation of Activity SPCB

If sequence data has not been read into the working case via activity RESQ, or if activity SEQD had
last been executed with the fault analysis option setting at the two phase option, an appropriate
error message is printed and activity SPCB is terminated.
Activity SPCB calculates the columns of the three sequence impedance matrices corresponding to
the specified buses are calculated in sub-matrix form.
The user describes the unbalance (refer to Transmission Line Unbalances). The positive sequence
pi-equivalent of the branch unbalance is calculated, and the results are printed (refer to
Section 10.13.5 Output of Activity SPCB).
10.13.5 Output of Activity SPCB

For each transmission line unbalance calculated by activity SPCB, the following data is tabulated
at the selected output device:
1. The admittance matrix terms corresponding to the branch with the selected unbalance
present.
2. A summary description of the branch unbalance.
3. The positive sequence pi-equivalent. This is presented in the form of a branch impedance
(R + jX) and the equivalent line connected shunts at each end of the branch.
The pi-equivalent calculated by activity SPCB may be used in dynamic simulations to model the
branch unbalance. It should replace the branch parameters used in modeling the branch without
the presence of the unbalance.
Figure 10-41 shows the output for a single-line-to-ground fault applied on the branch from bus 151
to bus 152 at a point 40% along the line from bus 151. The fault impedance is zero. Figures 10-42a
and 10-42b show diagrammatic view of the pi-equivalent.
10-106
Figure 10-41. Output Report for pi-Equivalent shown in Figure 10-42
10-107
151 152
0.0026 0.0460
B=1.75 B=1.75
Y=0,0 Y=0,0
a) Initial Line Data
151 152
0.00249 0.05390
B=0.0 B=0.0
Y=0.92358, –j6.14228 Y=0.61572, –j3.51151
b) pi-Equivalent for Line-Ground Fault 40% Down Line From Bus 151
Figure 10-42. Diagram of pi-Equivalent and the Branch Power Flow Data

Activity SPCB may apply branch unbalances only to transmission lines modeled in full detail in both
the positive (and hence, negative) and zero sequences. That is, the proper positive and zero
sequence values of branch impedances and line charging (and/or line connected shunts) must be
contained in the working case. Transformers, series capacitors, zero impedance lines (refer to
Section ) or jumpers may not be subjected to branch unbalances in activity SPCB.
The transmission line to which the unbalance is to be applied must be modeled such that:
1. Yi+ or Yj+ are non-zero.
2. Yi0 and Yj0 are non-zero.
3. Yi+ and Yi0 are different.
4. Yj+ and Yj0 and different.
where:
Yi+ Is the quantity (line shunt + one-half of total line charging) at the bus i end
of the branch in the positive sequence.
Yi0 Is the quantity (line shunt + one-half of total line charging) at the bus i end
of the branch in the zero sequence.
Yj+ and Yj0 Are the corresponding quantities at the bus j end of the branch.
10-108
Chapter 11
Power Flow Reports
Chapter 11 - Power Flow Reports
11.1 Analyzing Power Flow Solution Results

Activity Analyzing Power Flow Solution Results
PSS®E can generate a variety of output reports to provide:
• Comprehensive information on the power flow results

• Summaries of conditions in network subsystems
• Checks on system and equipment conditions
This section discusses the available reports, the means by which they are generated and, as appro-
priate, how to interpret the information presented.
Table 11-1 Summary of Available PSS®E Power Flow Reports summarizes the available power
flow reports and subsystems (see Section 4.8, Subsystem Selection) by which they can be limited.
Table 11-1. Summary of Available PSS®E Power Flow Reports
Function Can be Selected by

Power Flow Results
Comprehensive power flow output in tabular or graphical format. Bus subsystem
Multi-terminal dc line solution output All in-service multi-terminal dc
lines are reported
Summary Reports
Summary of system swing bus and area slack bus conditions, and Bus subsystem
subsystem totals.
Summary of area, zone or owner totals of load, generation, net Area, zone or owner
interchange, shunts and losses. subsystem, as appropriate
Summary of tie-line flows between areas. Area subsystem
Summary of tie-line flows between zones. Zone subsystem
Reports on Checking Limit
Summary of branches exceeding specified percentage of selected Bus subsystem
rating.
11-1
Power Flow Reports PSS®E 34.2
Producing a Standard Power Flow Solution Report Program Operation Manual
Table 11-1. Summary of Available PSS®E Power Flow Reports (Cont.)
Function Can be Selected by

Summary of buses with voltage outside specified band. Bus subsystem
Summary of generator terminal loading conditions on either all, or Bus subsystem
only overloaded, generators.
Summary of generator bus loading conditions on either all, or only Bus subsystem
var-limited, generators.
Summary of controlling transformer’s violations Bus subsystem
Generator reactive power capability Bus subsystem
Regulated bus violations and/or conflicts Bus subsystem
Reports on Comparing Power Flow Cases
Report on differences between the working case and a specified Bus subsystem
Saved Case
Report area, zone, owner, or complete system totals for the Area, zone or owner
working case and a specified Saved Case subsystem, as appropriate
Report subsystem tie branch differences between the working Bus subsystem
case and a specified Saved Case
Power flow results can be provided either in a tabular format or in a graphical format using the one-
line slider format.
In the tabular format, power flow output reports may be organized either numerically by ascending
bus number, or alphabetically by bus name. Selection of ordering by numbers or names is made in
the Program Settings (see activity OPTN) where either the Number output option, or the Extended
Name output option may be chosen. Changing between the Number and Extended Name input
options has no effect on the ordering of power flow reports.
All reports, except those selected by the AREA, ZONE and/or OWNER criteria, are made with
buses appearing in pure numeric or alphabetic order. Power flow results reports selected by one or
more of these criteria order the buses numerically or alphabetically within groupings (see Section
4.9, Subsystem Reporting). As an example, if output is selected by AREA, with Areas 2 and 6
selected, the report will list all buses in Area 2 first and then all buses in Area 6.
11.2 Producing a Standard Power Flow Solution Report

Activity POUT
Run Activity POUT - GUI

Power Flow > Reports > Bus based reports…
[Bus Based Reports]
OPTION: Powerflow output / Neither check box
Run Line Mode Activity POUT - CLI
11-2
PSS®E 34.2 Power Flow Reports
Program Operation Manual Producing a Standard Power Flow Solution Report
ACTIVITY?
>>POUT
>>
AB
The power flow output activity POUT prints power flow solution output for the working case. The
data tabulated for each bus printed includes bus voltage and phase angle, generator power output,
constant power, current and admittance loads, bus shunts, and flows into all connected branches,
FACTS devices, and GNE devices. Bus mismatch is printed for any bus for which it exceeds 0.5
MVA or kVA, according to the power output option in effect (refer to Section 3.3.3 Program Run-
Time Option Settings and activity OPTN). For buses where voltage magnitude is less than 10%
(such as faulted buses), the quantity FAULT MVA is printed (refer to Fault MVA).
buses ordered as described in Section 4.9 Subsystem Reporting.
The star point buses of three-winding transformers (refer to Transformer Data) are not reported.
to Multi-Section Line Grouping Data) are not reported.
The output listing of activity POUT may be terminated by entering the AB interrupt control code.
Bus Quantities
The first line of the output block for each bus contains the bus number, name, and base voltage in
the left portion of the line, followed by headings for the remaining lines, the bus voltage (in pu),
phase angle (in degrees), additional headings for the remaining lines, and either the bus number or
the extended bus name again, according to the bus output option currently in effect (refer to
Section 3.3.3 Program Run-Time Option Settings and activity OPTN).
The second line contains the bus voltage in kV if a base voltage was specified for the bus, followed
by headings for the Losses columns, and the numbers and names of the area and zone in which
the bus is located. In addition, if the bus is a generator bus, the line contains the identifier GENER-
ATION at the beginning and the plant active power, reactive power, and MVA output under the
appropriate headings. This is followed by the percent MVA loading of the plant based on total plant
MBASE. The plant reactive power output is followed by a single character flag, where H indicates
that the plant reactive power output is at or beyond the total plant upper reactive power limit, L indi-
cates that it is at or below the total plant lower reactive power limit, and R indicates that it is within
limits. Note that only plant conditions are tabulated in activity POUT. If more than one machine is
modeled at the plant, individual machine conditions may be examined using activities such as LIST,
GEOL, and GCAP (see also Generator Unit Data).
Only plant conditions are tabulated. If more than one machine is modeled at the plant, indi-
vidual machine conditions may be examined using the range checking facilities described in
Section 11.15 Viewing Network Limit Violations.
These lines are followed by any non-zero constant power load, constant current load, constant
admittance load, fixed shunt elements, and switched shunt at the bus, with the appropriate identifier
11-3
at the left of each line. Note that only totals by load characteristic are tabulated in activity POUT. If
more than one load and/or fixed bus shunt is modeled at the bus, individual load and shunt quanti-
ties may be examined using activities such as LIST and EXAM (see also Generator Unit Data and
Fixed Bus Shunt Data).
These lines are following by output for any single terminal GNE devices at the bus. GNE devices
connected to the bus are reported in GNE device name alphabetical order. If the out-of-service
branch reporting program option setting (refer to Section 3.3.3 Program Run-Time Option Settings
and activity OPTN) is disabled, only in-service GNE devices are reported. If this option is enabled,
out-of-service GNE devices at in-service buses are also reported; X is displayed in the various
loading fields.
For each GNE device reported, the following data is printed:
1. An identifier indicating the GNE device type (VAR PQ, VAR I or VAR Y).
2. The identifier GNE; this is printed in the circuit identifier column.
3. The power flowing into the GNE device.
4. The GNE device name.
FACTS Devices
Output for FACTS devices appears in the bus output block immediately following the bus quantities
output described above, and before output for dc lines and ac branches. FACTS devices connected
to the bus are reported in FACTS device name alphabetical order. If the out-of-service branch
reporting program option setting (refer to Section 3.3.3 Program Run-Time Option Settings and
activity OPTN) is disabled, only in-service FACTS devices are reported. If this option is enabled,
out-of-service FACTS devices at in-service buses are also reported; X is displayed in the various
loading and series voltage fields.
For each FACTS device for which the bus being reported is the sending bus of an IPFC master or
slave device, the following data pertaining to the device’s active power transfer to its companion
IPFC device is printed:
1. An identifier indicating the type of the companion IPFC device (IPFC MASTER or IPFC
SLAVE).
2. The identifier IPF; this is printed in the circuit identifier column.
3. The active power flowing to the companion IPFC device. If the bus being reported is the
IPFC master and the active power transfer is being held at its limit, its value is followed by
the tag HI.
4. The FACTS device name.
Except for IPFC devices for which the shunt element is 0.0, for each FACTS device for which the
bus being reported is the sending bus, the following data pertaining to the device’s shunt element
is printed:
11-4
1. An identifier indicating the type of FACTS device shunt element and/or active power transfer
being reported (STATCON SHUNT, SSSC SHUNT, UPFC SHUNT, or IPFC SHUNT).
2. An identifier indicating the type of FACTS device being reported: STA (for a Statcon or
Statcom), SSS (for an SSSC), UPF (for a UPFC) or IPF (for an IPFC); this is printed in the
circuit identifier column.
3. Unless the device being reported is an IPFC, the active power being exchanged between
the shunt and series element. If the active power is being held at its limit, its value is followed
by the tag HI.
4. The reactive power being absorbed by the shunt element.
5. The MVA corresponding to the active and reactive powers in (3) and (4) above, and the
percent loading on the shunt element.
If the FACTS device contains a series element, the following data pertaining to it is printed in the
output blocks of its sending and terminal buses:
1. The number, name, and base voltage of the other endpoint bus (to bus).
2. An identifier indicating the type of FACTS device being reported: SSS (for an SSSC), UPF
(for a UPFC) or IPF (for an IPFC); this is printed in the circuit identifier column.
3. The power flowing into the series element along with its percent loading at the from bus end.
4. The magnitude and phase of the series voltage. If the series voltage magnitude is being held
at its limit (control modes 1, 5 and 6) or if the series voltage magnitude exceeds VSMX
(control modes 2, 3, 4, 7 or 8), its value is followed by the tag HI. Otherwise, the tag RG is
printed.
5. The FACTS device losses calculated as the algebraic sum of the reactive power flowing into
the series device from its endpoint buses.
6. The numbers and names of the area and zone in which the other endpoint bus (to bus) is
located.
Series GNE Devices

Output for multiple terminal GNE devices at the bus appears in the bus output block immediately
following the bus and FACTS device output described above, and before output for dc lines. Series
GNE devices connected to the bus are reported in GNE device name alphabetical order. If the out-
of-service branch reporting program option setting (refer to Section 3.3.3 Program Run-Time Option
Settings and activity OPTN) is disabled, only in-service GNE devices are reported. If this option is
enabled, out-of-service GNE devices at in-service buses are also reported; X is displayed in the
various loading fields.
For each series GNE device reported, the following data is printed:
11-5
1. The number, name, and base voltage of the other endpoint bus (to bus).
4. GNE device losses calculated as the algebraic sum of the powers flowing into the device
from its endpoint buses.
5. The numbers and names of the area and zone in which the other endpoint bus is located.
DC Lines
Output for dc transmission lines appears in the bus output block immediately following the bus,
FACTS device, and series GNE device output described above, and before output for ac branches.
Two-terminal, multi-terminal, and VSC dc lines connected to the bus are reported in dc line name
alphabetical order; the order of printing is:
• Two-terminal lines, in ascending dc line number order

• Multi-terminal lines, in ascending dc line number order
• VSC dc line converters connected to the bus, in alphabetical VSC dc line name order.
If the out-of-service branch reporting program option setting (refer to Section 3.3.3 Program Run-
Time Option Settings and activity OPTN) is disabled, only in-service dc lines are reported. If this
option is enabled, out-of-service dc lines at in-service buses are also reported; an X is displayed in
the various loading fields and other fields indicating dc line conditions.
The power flowing into a dc line is the apparent ac system complex load as seen at the converter
bus. Refer to Sections 6.4.7 and 6.4.9 of the PSS®E Program Application Guide for additional
details on dc line quantities.
The following data is printed in the output block of each two-terminal and multi-terminal dc line
converter bus:
1. For two-terminal lines, the number, name, and base voltage of the other converter terminal
bus (to bus); for multi-terminal lines, the number and name of the dc bus to which the ac
converter bus is connected, with the identifier (DC) in the base voltage column.
2. An identifier indicating the type of dc line being reported: 2D (for two-terminal) or MD (for
multi-terminal), and an identifier indicating the type of converter at the from bus: R (for a
rectifier) or I (for an inverter); this is printed in the circuit identifier column.
3. The ac power flowing into the dc line.
4. The converter transformer off-nominal turns ratio, TAPR (or TAPI), followed by a two-char-
acter tag, which is either HI or LO if the ratio is at its high or low limit, respectively; LK if dc
taps were locked during the last power flow solution activity, or if an ac transformer (rather
than this converter transformer) is controlling a dc line quantity; or RG if the ratio is in regu-
lating range.
11-6
5. The value of converter angle followed by one of the tags RG, HI or LO if the angle is within
its limits, at or above its nominal high limit, or at or below its steady-state low limit,
respectively.
6. DC line losses calculated as the algebraic sum of the powers flowing into the line from its
converter buses.
7. For two-terminal lines, the numbers and names of the area and zone in which the other
converter bus (to bus) is located. For multi-terminal lines, the numbers and names of the
area and zone in which the dc bus to which the ac converter bus is connected is located.
8. The dc line name.
The following data is printed in the output block of each VSC dc line converter bus:
1. The number, name, and base voltage of the other converter terminal bus (to bus).
2. The identifier VSC; this is printed in the circuit identifier column.
3. The ac power flowing into the dc converter.
4. The percent of MVA rating, where the rating is taken as the more restrictive of IMAX
converted to MVA and SMAX (refer to Voltage Source Converter (VSC) DC Transmission
Line Data).
5. DC line losses calculated as the algebraic sum of the powers flowing into the line from its
converter buses.
6. The numbers and names of the area and zone in which the other converter bus is located.
7. The VSC dc line name.
Figure 11-1 contains partial output from activity POUT for a system in which bus 201 is the rectifier
bus of a two-terminal dc line, and bus 161 is the inverter bus. The output is shown with the numbers
output option in effect.
11-7
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS®E WED, JUN 27 2007 16:19
ADDITION OF DC LINE TO BASE CASE DEMO LOAD FLOW RATING %MVA FOR TRANSFORMERS
FOR PSS®E MANUAL SET A % I FOR NON-TRANSFORMER BRANCHES
BUS 201 HYDRO 500.00 CKT MW MVAR MVA % 0.9913PU 2.55 X--- LOSSES ---X X---- AREA -----X X---- ZONE -----X 201
Power Flow Reports
FROM GENERATION 600.0 400.0H 721.1 99 495.65KV MW MVAR 2 LIGHTCO 2

TO SHUNT 0.0 294.8 294.8
TO 161 INVJCT 18.500 2DR 641.8 286.2 702.7 1.0000RG 10.94RG 41.76 568.06 1 FLAPCO 1 "1"
TO 151 NUCPANT 500.00 1 -724.8 -51.1 726.6 61 5.35 80.20 1 FLAPCO 1
TO 202 EAST500 500.00 1 315.1 -142.3 345.8 29 2.06 25.76 2 LIGHTCO 2
TO 204 SUB500 500.00 1 367.9 12.5 368.1 31 4.69 46.92 2 LIGHTCO 2
BUS 161 INVJCT 18.500 CKT MW MVAR MVA % 0.9730PU -1.60 X--- LOSSES ---X X---- AREA -----X X---- ZONE -----X 161
18.000KV MW MVAR 1 FLAPCO 1
TO 201 HYDRO 500.00 2DI -600.0 281.9 662.9 0.9875RG 19.08RG 41.76 568.06 2 LIGHTCO 2 "1"
TO 154 DOWNTN 230.00 1 600.0 78.4 605.1 101 1.0000UN 0.00 48.35 1 FLAPCO 1
TO 162 INVTER 18.500 1 0.0 -360.3 360.3 0.00 13.71 1 FLAPCO 1
Producing a Standard Power Flow Solution Report
11-8
Figure 11-1. Example Output From Activity POUT
PSS®E 34.2
Branch Quantities
Following the output described above, flows for each ac branch connected to the bus are tabulated.
If the out-of-service branch reporting program option setting (refer to Section 3.3.3 Program Run-
Time Option Settings and activity OPTN) is disabled, only in-service branches are reported. If this
option setting is enabled, out-of-service branches at in-service buses are also reported; an X is
displayed in the various loading and losses fields.
Following the output described above, flows for each in-service ac branch connected to the bus are
tabulated.
For non-transformer branches and two-winding transformers, the output line contains the to bus
number, name, and base voltage followed by the branch circuit identifier. For three-winding trans-
formers, the output line contains the string 3WNDTR in the bus number column, the transformer
name in the bus name column, and the winding number in the base voltage column, followed by the
transformer circuit identifier; if the three-winding transformer to bus reporting option is enabled, two
additional lines, containing the bus numbers, names, and base voltages of the two buses connected
to the from bus by the three-winding transformer, are printed.
The active and reactive power flow on the branch is printed as power leaving the from bus (i.e., posi-
tive for outgoing and negative for incoming); MVA flow is also printed.
The percent loading, based on the rating set established as the default rating set program option
setting is then printed (refer to Section 3.3.3 Program Run-Time Option Settings, activity OPTN,
Non-Transformer Branch Data, and Transformer Data). For transformers, either percent current or
percent MVA loading is reported, according to the transformer percent loading units program option
setting. Similarly, for non-transformer branches, either percent current or percent MVA loading is
reported, according to the non-transformer branch percent loading units program option setting.
Branch losses which are printed are taken as I2R and I2X losses and exclude the line charging, line
connected shunt, and magnetizing admittance components. For three-winding transformers, if the
three-winding transformer to bus reporting option is disabled, total losses on all three windings are
printed on the output line for the three-winding transformer; if this option is enabled, losses on each
winding are listed separately on the line identifying the bus to which the winding is connected.
The number and name of the area and zone in which the to bus is located are printed for non-trans-
former branches and for two-winding transformers. For three-winding transformers, if the three-
winding transformer to bus reporting option is enabled, the numbers and names of the areas and
zones of the two buses connected to the from bus by the three-winding transformer are listed on
the lines identifying them.
For transformers, the turns ratio of the winding connected to the from bus is printed following the
percent loading. A two-character tag is printed adjacent to the ratio, which has the following
significance:
HI The from bus is connected to the Winding 1 side of this regulating two-winding
transformer or to a regulating winding of this three-winding transformer, and the
off-nominal turns ratio is at or beyond its high limit.
LO The from bus is connected to the Winding 1 side of this regulating two-winding
transformer or to a regulating winding of this three-winding transformer, and the
off-nominal turns ratio is at or below its low limit.
11-9
RG The from bus is connected to the Winding 1 side of this regulating two-winding
transformer or to a regulating winding of this three-winding transformer, its adjust-
ment control mode is set to +1 or +2, the automatic tap ratio adjustment was
enabled during the last power flow solution activity, and the off-nominal turns ratio is
within its limits.
DC The from bus is the Winding 1 side of this two-winding transformer which is regu-
lating alpha, gamma, or dc voltage of a dc line; its adjustment control mode is set to
+4; dc tap adjustment was enabled during the last power flow solution activity; and
the off-nominal turns ratio is within its limits.
LK The from bus is connected to the Winding 1 side of this two-winding transformer or
to any winding of this three-winding transformer, and either this transformer winding
is not a tap changing transformer winding, its adjustment control mode is set to zero
or negative, or the automatic tap ratio adjustment was disabled during the last
power flow solution activity.
UN The from bus is not the Winding 1 side of this two-winding transformer.
Except for the tags DC and UN, phase shifters are handled in a similar manner. For single section
two-winding transformers with non-zero phase shift angle on the Winding 1 side, no indication of
phase shift is printed in the output block of the Winding 2 side bus.
Option Settings and activity OPTN), the far end to bus (rather than the closest dummy bus) of each
multi-section line connected to the from bus is shown as its to bus. Multi-section lines are identified
with an ampersand ( & ) as the first character of their branch identifiers in the circuit identifier column
(e.g., &1). The sum of the losses on all of the line sections comprising the multi-section line is shown
as losses on the multi-section line. Finally, transformer information is shown only if the line section
adjacent to the from bus is a transformer branch, and the data applies to the winding adjacent to
the from bus.
If any of the non-transformer branches reported have a non-zero line shunt at the from bus end, or
if Winding 1 of any transformer branch connected to the from bus has non-zero magnetizing admit-
tance, and the line shunt reporting option is enabled (refer to Section 3.3.3 Program Run-Time
Option Settings and activity OPTN), the branch output lines are followed by lines reporting powers
corresponding to each of these admittances. Note that, regardless of the setting of this option, the
branch flows reported always include these components.
Figure 11-2 shows a sample of the tabular output. It covers Buses 152 and 153 which are connected
by a 500/230 kV transformer. It can be seen that the tap, at the Bus 152 side is at its high limit (HI)
of 1.05 pu. At bus 153 It can be seen that this is not the winding one side of this two-winding trans-
former (UN).
The figure also shows three non transformer branches from Bus 153. They include circuits #1 and
#2 to Bus 154 (DOWNTN), which are overloaded (at 180% and 150% of rating) and a single circuit
to Bus 3006 (UPTOWN).
11-10
Figure 11-2. Power Flow Output for Branches
Fault MVA
For buses where voltage magnitude is less than 10% (such as faulted buses), the quantity FAULT
MVA is printed. This quantity is intended for use following the solution of a balanced fault with
activity TYSL. It is computed using the fixed bus shunt and the bus voltage; as such, it is normally
the sum of fault MVA and the MVA consumed by the fixed bus shunt, if any, on the bus.
Under three phase fault conditions, the solved voltage magnitude at the faulted bus, and usually at
nearby buses, is very small (e.g., 10-6 pu at the faulted bus). Hence, the voltage correction applied
during the final TYSL iteration may be a large fraction of the solved voltage. Therefore, to ensure
an accurate reporting of FAULT MVA, the acceleration factor applied during the final TYSL iteration
should be 1.0. If the solution requires deceleration to achieve convergence, then, after it converges,
activity TYSL should be repeated one final time with the acceleration factor reset to unity.
®
PSS E GUI Users Guide, Section 16.3.1, Producing a Standard Power Flow Solution Report
Section 13.3.1, Standard Power Flow Solution Report
11-11
Producing a Wide-Format Power Flow Solution Report Program Operation Manual
11.3 Producing a Wide-Format Power Flow Solution Report

Activity LOUT
Run Activity LOUT - GUI

[Bus Based Reports]
OPTION: Powerflow output / Wide format output checked
Run Line Mode Activity LOUT - CLI
ACTIVITY?
>>LOUT
AB
The power flow output activity LOUT prints power flow solution output for the working case. The
loads, bus shunt elements, and flows into all connected branches, FACTS devices, and GNE
devices. Bus mismatch is printed for any bus for which it exceeds 0.5 MVA or kVA, according to the
power output option in effect (refer to Section 3.3.3 Program Run-Time Option Settings and activity
OPTN). For buses where voltage magnitude is less than 10% (such as faulted buses), the quantity
FAULT MVA is printed (refer to Fault MVA).
The output listing of activity LOUT may be terminated by entering the AB interrupt control code.
Activity LOUT formats its report in traditional power flow output style, with bus quantities on the left
side of the page and branch information shown on the right side.
This tabulated output presents the same information about the power flow solution as is seen in the
standard output, with the addition of an option to print the branch currents (in amperes). In addition,
the rating sets in use are printed.
The layout of the information is different from the standard layout. Figure 11-3 shows the wide
format output for the buses shown in Figure 11-1 for the standard output format.
11-12
Program Operation Manual Producing a Wide-Format Power Flow Solution Report
11-13
Figure 11-3. Wide Format Power Flow Output including Branch Currents
11-14
The main difference between the standard and wide format is that, in the former, the data categories
are listed in vertical order while in the wide format they are printed from left to right. Those data cate-
gories are:
• Bus data
• Generators
• Load
• Shunts
• FACTS devices
• GNE devices
• DC lines
• Ac branches
Bus Quantities
The bus identifiers and boundary conditions for each bus reported in activity LOUT are printed on
two lines on the left side of the bus’ output block. The bus identifiers of bus number, name, and base
voltage are listed followed by the number of the area in which the bus is located and the zone
number directly below it on the second line.
The bus voltage (in pu) and phase angle (in degrees) are printed; if the bus base voltage is specified
for the bus, the bus voltage in kV is printed directly below the pu voltage on the second line. The
generation, load, and shunt at the bus are printed, with active power shown on the first line and
reactive power on the second. The plant reactive power output is followed by a single-character
flag, where H indicates that the plant reactive power output is at or beyond the total plant upper
reactive power limit; L indicates that it is at or below the total plant lower reactive power limit; and
R indicates that it is within limits. Note that only plant conditions are tabulated in activity LOUT. If
more than one machine is modeled at the plant, individual machine conditions may be examined
using activities such as LIST, GEOL, and GCAP (see also Generator Unit Data).
The quantities printed as load at the bus are the sum of any constant MVA, current, and admittance
loads at the bus; the shunt is the sum of any fixed and switched shunts. If more than one load and/or
shunt are modeled at the bus, individual load and shunt quantities may be examined using activities
such as LIST and EXAM (see also Generator Unit Data and Fixed Bus Shunt Data).
FACTS Devices
Output for FACTS devices appears on the right side of the bus output block as the first line or lines
of branch data (i.e., before output for GNE devices, dc lines and ac branches). FACTS devices
connected to the bus are reported in FACTS device name alphabetical order. If the out-of-service
branch reporting program option setting (refer to Section 3.3.3 Program Run-Time Option Settings
and activity OPTN) is disabled, only in-service FACTS devices are reported. If this option is
enabled, out-of-service FACTS devices at in-service buses are also reported; an X is displayed in
the various loading and series voltage fields.
11-15
1. An identifier indicating the type of the companion IPFC device (IPFC MASTER or IPFC
SLAVE).
2. The identifier IPF; this is printed in the circuit identifier column.
3. The active power flowing to the companion IPFC device.
4. The FACTS device name printed in the transformer ratio and angle columns.
is printed:
1. An identifier indicating the type of FACTS device shunt element and/or active power transfer
being reported (STATCON SHUNT, SSSC SHUNT, UPFC SHUNT, or IPFC SHUNT).
2. An identifier indicating the type of FACTS device being reported: STA (for a Statcon or
Statcom), SSS (for an SSSC), UPF (for a UPFC) or IPF (for an IPFC); this is printed in the
circuit identifier column.
3. Unless the device being reported is an IPFC, the active power being exchanged between
the shunt and series element.
4. The reactive power being absorbed by the shunt element.
5. The FACTS device name printed in the transformer ratio and angle columns.
6. The rating and percent loading of the shunt element.
1. The number, name, base voltage, and area of the other endpoint bus (to bus).
2. An identifier indicating the type of FACTS device being reported: SSS (for an SSSC), UPF
(for a UPFC) or IPF (for an IPFC); this is printed in the circuit identifier column.
3. The power flowing into the series element at the from bus end.
4. The magnitude and phase of the series voltage. If the series voltage magnitude is being held
at its limit (control modes 1, 5 and 6) or if the series voltage magnitude exceeds VSMX
(control modes 2, 3, 4, 7 or 8), its value is followed by the tag H. Otherwise, the tag R is
printed.
5. The percent current loading and rating.
GNE Devices
Output for GNE devices appears on the right side of the bus output block immediately following any
FACTS device output described above, and before output for dc lines and ac branches. GNE
devices connected to the bus are reported in GNE device name alphabetical order. If the out-of-
service branch reporting program option setting (refer to Section 3.3.3 Program Run-Time Option
enabled, out-of-service GNE devices at in-service buses are also reported; an X is displayed in the
11-16
For each single terminal GNE device reported, the following data is printed:
1. An identifier indicating the GNE device type (VAR PQ, VAR I or VAR Y).
1. The number, name, base voltage, and area of the other endpoint bus (to bus).
DC Lines
Output for dc transmission lines appears on the right side of the bus output block immediately
following any GNE device output described above, and before output for ac branches. Two-
terminal, multi-terminal, and VSC dc lines connected to the bus are reported in dc line name alpha-
betical order, with output for two-terminal lines printed first, followed by output for multi-terminal
lines, followed by output for VSC dc lines. If the out-of-service branch reporting program option
setting (refer to Section 3.3.3 Program Run-Time Option Settings and activity OPTN) is disabled,
only in-service dc lines are reported. If this option is enabled, out-of-service dc lines at in-service
buses are also reported; an X is displayed in the various loading fields and other fields indicating
dc line conditions.
converter bus:
1. For two-terminal lines, the number, name, and base voltage of the other converter terminal
bus (to bus), followed by the number of the area in which it is located; for multi-terminal lines,
the number and name of the dc bus to which the ac converter bus is connected, with the
identifier (DC) in the base voltage column, followed by the number of the area in which the
dc bus to which the ac converter bus is connected is located.
2. An identifier indicating the type of dc line being reported: 2D (for two-terminal) or MD (for
multi-terminal), and an identifier indicating the type of converter at the from bus: R (for a
rectifier) or I (for an inverter); this is printed in the circuit identifier column.
3. The ac power flowing into the dc line.
4. The converter transformer off-nominal turns ratio, followed by a two-character tag, which is
either HI or LO if the ratio is at its high or low limit, respectively; LK if dc taps were locked
during the last power flow solution activity, or if an ac transformer (rather than this converter
transformer) is controlling a dc line quantity; or RG if the ratio is in regulating range.
11-17
5. The value of converter angle followed by one of the tags RG, HI, or LO if the angle is within
its limits, at or above its nominal high limit, or at or below its steady-state low limit,
respectively.
6. The dc line name.
1. The number, name, and base voltage of the other converter terminal bus (to bus), followed
by the number of the area in which it is located.
2. The identifier VSC; this is printed in the circuit identifier column.
3. The ac power flowing into the dc converter.
4. The VSC dc line name printed in the transformer ratio and angle columns.
5. The percent of MVA rating and the rating, where the rating is taken as the more restrictive
of IMAX converted to MVA and SMAX (refer to Voltage Source Converter (VSC) DC Trans-
mission Line Data).
Figure 11-4 contains partial output from activity LOUT for a system in which bus 201 is the rectifier
bus of a two-terminal dc line and bus 161 is the inverter bus. The output is shown with the names
output option in effect. The system condition in this example is identical to that shown in the
example output of activity POUT in Figure 11-1.
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSSE THU, JUN 28 2007 8:31

ADDITION OF DC LINE TO BASE CASE DEMO LOAD FLOW %MVA FOR TRANSFORMERS
FOR PSSE MANUAL % I FOR NON-TRANSFORMER BRANCHES
X------ FROM BUS ------X AREA VOLT GEN LOAD SHUNT X---------TO BUS----------X TRANSFORMER RATING
X--NAME--X BASKV BUS# ZONE PU/KV ANGLE MW/MVAR MW/MVAR MW/MVAR X--NAME--X BASKV BUS# AREA CKT MW MVAR RATIO ANGLE % SET A
HYDRO 500.00 201 2 0.9913 2.5 600.0 0.0 0.0 -------------------------------------------------------------------------

2 495.65 400.0H 0.0 294.8 INVJCT 18.500 161 1 2DR 641.8 286.2 1.000RG 10.9RG "1"
EAST500 500.00 202 2 1 315.1 -142.3 29 1200
NUCPANT 500.00 151 1 1 -724.8 -51.1 61 1200
SUB500 500.00 204 2 1 367.9 12.5 31 1200
INVJCT 18.500 161 1 0.9730 -1.6 0.0 0.0 0.0 -------------------------------------------------------------------------
1 18.000 0.0 0.0 0.0 HYDRO 500.00 201 2 2DI -600.0 281.9 0.987RG 19.1RG "1"
DOWNTN 230.00 154 1 1 600.0 78.4 1.000UN 101 600
INVTER 18.500 162 1 1 0.0 -360.3
Figure 11-4. Example Output From Activity LOUT
Branch Quantities
Following the output described above, flows for each ac branch connected to the bus are tabulated
on the right side of the bus output block. If the out-of-service branch reporting program option
only in-service branches are reported. If this option is enabled, out-of-service branches at in-service
buses are also reported; an X is displayed in the loading fields.
Each branch output line for non-transformer branches and for two-winding transformers contains
the to bus number, name, and base voltage, followed by the number of the area in which the to bus
is located and the branch circuit identifier. For three-winding transformers, the output line contains
the string 3WNDTR in the bus number column, the transformer name in the bus name column, and
the winding number in the base voltage column, followed by the transformer circuit identifier; if the
three-winding transformer to bus reporting option is enabled, two additional lines, containing the bus
numbers, names, and base voltages of the two buses connected to the from bus by the three-
winding transformer, are printed, followed by the number of the area in which the to bus is located.
11-18
tive for outgoing and negative for incoming).
setting (refer to Section 3.3.3 Program Run-Time Option Settings and activity OPTN) and the corre-
sponding rating are printed on the far right-hand side of the line. For transformers, either percent
current or percent MVA loading is reported, according to the transformer percent loading units
program option setting. Similarly, for non-transformer branches, either percent current or percent
MVA loading is reported, according to the non-transformer branch percent loading units program
option setting.
For transformers, the turns ratio of the winding connected to the from bus is printed. A two-character
tag is printed adjacent to the ratio which has the following significance:
HI The from bus is connected to the Winding 1 side of this regulating two-winding trans-
former or to a regulating winding of this three-winding transformer, and the off-nominal
turns ratio is at or beyond its high limit.
LO The from bus is connected to the Winding 1 side of this regulating two-winding trans-
former or to a regulating winding of this three-winding transformer, and the off-nominal
turns ratio is at or below its low limit.
RG The from bus is connected to the Winding 1 side of this regulating two-winding trans-
former or to a regulating winding of this three-winding transformer, its adjustment
control mode is set to +1 or +2, the automatic tap ratio adjustment was enabled during
the last power flow solution activity, and the off-nominal turns ratio is within its limits.
DC The from bus is the Winding 1 side of this two-winding transformer which is regulating
alpha, gamma, or dc voltage of a dc line; its adjustment control mode is set to +4; dc
tap adjustment was enabled during the last power flow solution activity; and the off-
nominal turns ratio is within its limits.
LK The from bus is connected to the Winding 1 side of this two-winding transformer or to
any winding of this three-winding transformer, and either this transformer winding is not
a tap changing transformer winding, its adjustment control mode is to zero or negative,
or the automatic tap ratio adjustment was disabled during the last power flow solution
activity.
with an ampersand ( & ) as the first character of their line identifiers in the branch circuit identifier
column (e.g., &1). Transformer information is shown only if the line section adjacent to the from bus
is a transformer branch, and the data applies to the winding adjacent to the from bus.
11-19
corresponding to each of these admittances. Note that, regardless of the setting of this option, the
branch flows reported always include these components.
11-20
Program Operation Manual Producing a Wide-Format Power Flow Solution Report in Amps
Fault MVA
PSS®E GUI Users Guide, Section 16.3.2, Wide-Format Power Flow Solution Report
Section 13.3.2, Wide-Format Power Flow Solution Report
11.4 Producing a Wide-Format Power Flow Solution Report in

Amps
Activity LAMP
Run Activity LAMP - GUI

[Bus Based Reports]
OPTION: Powerflow output / Wide format output and Output with amps both checked
Run Line Mode Activity LAMP - CLI
ACTIVITY?
>>LAMP
AB
The power flow output activity LAMP prints power flow solution output for the working case. The
loads, bus shunt elements, flows into all connected branches, FACTS devices, and GNE devices,
and branch current loadings in amps. Bus mismatch is printed for any bus for which it exceeds 0.5
MVA or kVA, according to the power output option in effect (refer to Section 3.3.3 Program Run-
Time Option Settings and activity OPTN). For buses where voltage magnitude is less than 10%
(such as faulted buses), the quantity FAULT MVA is printed (refer to Fault MVA).
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. The output report is gener-
ated with specified buses ordered according to the user option, in ascending bus number order
(using the numbers output option) or alphabetical order (using the names output option) (refer to
11-21
Producing a Wide-Format Power Flow Solution Report in Amps Program Operation Manual
Section 4.9 Subsystem Reporting).
The output listing of activity LAMP may be terminated by entering the AB interrupt control code.
Activity LAMP formats its report in traditional power flow output style, with bus quantities on the left
side of the page and branch data shown on the right side.
Bus Quantities
The bus identifiers and boundary conditions for each bus reported in activity LAMP are printed on
two lines on the left side of the bus’ output block. The bus identifiers of bus number, name, and base
voltage are listed followed by the number of the area in which the bus is located and the zone
number directly below it on the second line.
The bus voltage (in pu) and phase angle (in degrees) are printed; if the bus base voltage is specified
for the bus, the bus voltage in kV is printed directly below the pu voltage on the second line. The
generation, load, and shunt at the bus are printed, with active power shown on the first line and
reactive power on the second. The plant reactive power output is followed by a single-character
flag, where H indicates that the plant reactive power output is at or beyond the total plant upper
reactive power limit; L indicates that it is at or below the total plant lower reactive power limit; and
R indicates that it is within limits. Note that only plant conditions are tabulated in activity LAMP. If
more than one machine is modeled at the plant, individual machine conditions may be examined
using activities such as LIST, GEOL, and GCAP (refer to also Generator Unit Data).
The quantities printed as load at the bus are the sum of any constant MVA, current, and admittance
loads at the bus; the shunt is the sum of any fixed and switched shunts. If more than one load and/or
shunt are modeled at the bus, individual load and shunt quantities may be examined using activities
such as LIST and EXAM (refer to Generator Unit Data).
FACTS Devices
Output for FACTS devices appears on the right side of the bus output block as the first line or lines
of branch data (i.e., before output for GNE devices, dc lines, and ac branches). FACTS devices
connected to the bus are reported in FACTS device name alphabetical order. If the out-of-service
branch reporting program option setting is disabled, only in-service FACTS devices are reported. If
this option is enabled, out-of-service FACTS devices at in-service buses are also reported; an X is
displayed in the various loading and series voltage fields (refer to Section 3.3.3 Program Run-Time
Option Settings and activity OPTN).
• An identifier indicating the type of the companion IPFC device (IPFC MASTER or IPFC
SLAVE).
• The identifier IPF; this is printed in the circuit identifier column.
• The active power flowing to the companion IPFC device.
• The FACTS device name printed in the transformer ratio and angle columns.
11-22
is printed:
• An identifier indicating the type of FACTS device shunt element and/or active power
transfer being reported (STATCON SHUNT, SSSC SHUNT, UPFC SHUNT, or IPFC
SHUNT).
• An identifier indicating the type of FACTS device being reported: STA (for a Statcon or
Statcom), SSS (for an SSSC), UPF (for a UPFC) or IPF (for an IPFC); this is printed in
the circuit identifier column.
• Unless the device being reported is an IPFC, the active power being exchanged
between the shunt and series element.
• The reactive power being absorbed by the shunt element.
• The FACTS device name printed in the transformer ratio and angle columns.
• The total shunt current magnitude in amperes if the from bus has its base voltage
specified.
• The rating in amperes and percent loading of the shunt element. If no from bus base
voltage was specified, these columns are left blank.
11-23
• The number, name, base voltage, and area of the other endpoint bus (to bus).
• An identifier indicating the type of FACTS device being reported: SSS (for an SSSC),
UPF (for a UPFC) or IPF (for an IPFC); this is printed in the circuit identifier column.
• The power flowing into the series element at the from bus end.
• The magnitude and phase of the series voltage. If the series voltage magnitude is being
held at its limit (control modes 1, 5 and 6) or if the series voltage magnitude exceeds
VSMX (control modes 2, 3, 4, 7 or 8), its value is followed by the tag H. Otherwise, the
tag R is printed.
• The total current loading magnitude in amperes if the from bus has its base voltage
specified.
• The rating in amperes and percent loading of the series element. If no from bus base
voltage or series current limit was specified, these columns are left blank.
GNE Devices
Output for GNE devices appears on the right side of the bus output block immediately following any
FACTS device output described above, and before output for dc lines and ac branches. GNE
devices connected to the bus are reported in GNE device name alphabetical order. If the out-of-
service branch reporting program option setting (refer to Section 3.3.3 Program Run-Time Option
enabled, out-of-service GNE devices at in-service buses are also reported; an X is displayed in the
For each single terminal GNE device reported, the following data is printed:
• An identifier indicating the GNE device type (VAR PQ, VAR I or VAR Y).
• The identifier GNE; this is printed in the circuit identifier column.
• The power flowing into the GNE device.
• The GNE device name.
specified.
• The number, name, base voltage, and area of the other endpoint bus (to bus).
• The identifier GNE; this is printed in the circuit identifier column.
• The power flowing into the GNE device.
• The GNE device name.
specified.
11-24
DC Lines
Output for dc transmission lines appears on the right side of the bus output block immediately
following any GNE device output described above, and before output for ac branches. Two-
terminal, multi-terminal, and VSC dc lines connected to the bus are reported in dc line name alpha-
betical order, with output for two-terminal lines printed first, followed by output for multi-terminal
lines, followed by output for VSC dc lines. If the out-of-service branch reporting program option
only in-service dc lines are reported. If this option setting is enabled, out-of-service dc lines at in-
service buses are also reported; an X is displayed in the various loading fields and other fields indi-
cating dc line conditions.
converter bus:
• For two-terminal lines, the number, name, and base voltage of the other converter ter-
minal bus (to bus), followed by the number of the area in which it is located; for multi-
terminal lines, the number and name of the dc bus to which the ac converter bus is con-
nected, with the identifier (DC) in the base voltage column, followed by the number of
the area in which the dc bus to which the ac converter bus is connected is located.
• An identifier indicating the type of dc line being reported: 2D (for two-terminal) or MD
(for multi-terminal), and an identifier indicating the type of converter at the from bus: R
(for a rectifier) or I (for an inverter); this is printed in the circuit identifier column.
• The ac power flowing into the dc line.
• The converter transformer off-nominal turns ratio, followed by a two-character tag,
which is either HI or LO if the ratio is at its high or low limit, respectively; LK if dc taps
were locked during the last power flow solution activity, or if an ac transformer (rather
than this converter transformer) is controlling a dc line quantity; or RG if the ratio is in
regulating range.
• The value of converter angle followed by one of the tags RG, HI or LO if the angle is
within its limits, at or above its nominal high limit, or at or below its steady-state low limit,
respectively.
• The ac current magnitude in amperes flowing into the dc line, if the from bus has its
base voltage specified.
• The dc line name.
• The number, name, and base voltage of the other converter terminal bus (to bus), fol-
lowed by the number of the area in which it is located.
• The identifier VSC; this is printed in the circuit identifier column.
• The ac power flowing into the dc converter.
• The VSC dc line name printed in the transformer ratio and angle columns.
• The ac current magnitude in amperes flowing into the dc converter, if the from bus has
its base voltage specified; if no base voltage is specified, this column is left blank.
11-25
• The percent of MVA rating, where the rating is taken as the more restrictive of IMAX
converted to MVA and SMAX (refer to Voltage Source Converter (VSC) DC Transmis-
sion Line Data). If the from bus has its base voltage specified, the rating in amperes is
listed followed by an A; if no base voltage is specified, these columns are left blank.
Figure 11-5 contains partial output from activity LAMP for a system in which bus 201 is the rectifier
bus of a two-terminal dc line and bus 161 is the inverter bus. The output is shown with the numbers
output option in effect. The system condition in this example is identical to that shown in the
example output of activity POUT in Figure 11-1, and of activity LOUT in Figure 11-4.
11-26

PSS®E 34.2
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS(tm)E THU, JUN 28 2007 14:20
ADDITION OF DC LINE TO BASE CASE DEMO LOAD FLOW %MVA FOR TRANSFORMERS
FOR PSS®E MANUAL % I FOR NON-TRANSFORMER BRANCHES
X------ FROM BUS ------X AREA VOLT GEN LOAD SHUNT X--------- TO BUS ----------X TRANSFORMER RATING
BUS# X-- NAME --X BASKV ZONE PU/KV ANGLE MW/MVAR MW/MVAR MW/MVAR BUS# X-- NAME --X BASKV AREA CKT MW MVAR RATIO ANGLE AMPS % SET A
201 HYDRO 500.00 2 0.9913 2.5 600.0 0.0 0.0 -------------------------------------------------------------------------------

2 495.65 400.0H 0.0 294.8 161 INVJCT 18.500 1 2DR 641.8 286.2 1.000RG 10.9RG 818 "1"
151 NUCPANT 500.00 1 1 -724.8 -51.1 846 61 1386A
202 EAST500 500.00 2 1 315.1 -142.3 403 29 1386A
204 SUB500 500.00 2 1 367.9 12.5 429 31 1386A
161 INVJCT 18.500 1 0.9730 -1.6 0.0 0.0 0.0 ------------------------------------------------------------------------------
1 18.000 0.0 0.0 0.0 201 HYDRO 500.00 2 2DI -600.0 281.9 0.987RG 19.1RG 21263 "1"
154 DOWNTN 230.00 1 1 600.0 78.4 1.000UN 19409 101 600M
162 INVTER 18.500 1 1 0.0 -360.3 11556
Figure 11-5. Example Output From Activity LAMP
Producing a Wide-Format Power Flow Solution Report in Amps

11-27
Power Flow Reports

Branch Quantities
Following the output described above, flows for each ac branch connected to the bus are tabulated
on the right side of the bus output block. If the out-of-service branch reporting program option
only in-service branches are also reported. If this option setting is enabled, out-of-service branches
at in-service buses are reported; an X is displayed in the loading fields.
Each branch output line for non-transformer branches and for two-winding transformers contains
the to bus number, name, and base voltage, followed by the number of the area in which the to bus
is located and the branch circuit identifier. For three-winding transformers, the output line contains
the string 3WNDTR in the bus number column, the transformer name in the bus name column, and
the winding number in the base voltage column, followed by the transformer circuit identifier; if the
three-winding transformer to bus reporting option is enabled, two additional lines, containing the bus
numbers, names, and base voltages of the two buses connected to the from bus by the three-
winding transformer, are printed, followed by the number of the area in which the to bus is located.
tive for outgoing and negative for incoming).
If the from bus has its base voltage specified, the current loading at the from bus end of the line is
listed in amperes; if no base voltage is specified, this column is left blank.
setting and the corresponding rating are printed on the far right-hand side of the line. For trans-
formers, either percent current or percent MVA loading is reported, according to the transformer
percent loading units program option setting. Similarly, for non-transformer branches, either percent
current or percent MVA loading is reported, according to the non-transformer branch percent
loading units program option setting. For branches with percent current tabulated, the rating is
reported in amperes followed by an A as long as the corresponding branch rating and the from bus
base voltage are specified; otherwise, the percent loading and rating columns are blank. For
branches with percent MVA tabulated, the rating is printed as is followed by either an M (for MVA)
or K (for kVA), depending upon the PSS®E power output option setting. A rating may have been
entered as either an MVA rating or a current rating expressed as MVA (refer to Case Identification
Data, Generator Data and Non-Transformer Branch Data), but the percent loading calculation
always assumes the units consistent with the appropriate percent loading units program option
setting (refer to Section 3.3.3 Program Run-Time Option Settings and activity OPTN).
For transformers, the turns ratio of the winding connected to the from bus is printed. A two-character
tag is printed adjacent to the ratio which has the following significance:
HI The from bus is connected to the Winding 1 side of this regulating two-winding
transformer or to a regulating winding of this three-winding transformer, and the off-
nominal turns ratio is at or beyond its high limit.
LO The from bus is connected to the Winding 1 side of this regulating two-winding
transformer or to a regulating winding of this three-winding transformer, and the off-
nominal turns ratio is at or below its low limit.
RG The from bus is connected to the Winding 1 side of this regulating two-winding
transformer or to a regulating winding of this three-winding transformer, its adjust-
ment control mode is set to +1 or +2, the automatic tap ratio adjustment was
enabled during the last power flow solution activity, and the off-nominal turns ratio is
within its limits.
11-28
DC The from bus is the Winding 1 side of this two-winding transformer which is regu-
lating alpha, gamma, or dc voltage of a dc line; its adjustment control mode is set to
+4; dc tap adjustment was enabled during the last power flow solution activity; and
the off-nominal turns ratio is within its limits.
LK The from bus is connected to the Winding 1 side of this two-winding transformer or
to any winding of this three-winding transformer, and either this transformer winding
is not a tap changing transformer winding, its adjustment control mode is to zero or
negative, or the automatic tap ratio adjustment was disabled during the last power
flow solution activity.
with an ampersand ( & ) as the first character of their line identifiers in the branch circuit identifier
column (e.g., &1). Transformer information is shown only if the line section adjacent to the from bus
is a transformer branch, and the data applies to the winding adjacent to the from bus.
corresponding to each of these admittances. Current magnitudes in amperes are also printed if the
from bus has a non-zero base voltage specified for it. Note that, regardless of the setting of this
option, the branch flows reported always include these components.
Fault MVA
Section 16.3.3, Wide-Format Power Flow Solution Report with Branch Current Loadings
Section 13.3.3, Producing a Wide Format Power Flow Solution Report with Branch Current Loadings
11-29
Summarizing Subsystem Conditions Program Operation Manual
11.5 Summarizing Subsystem Conditions

Activity SUBS
Run Activity SUBS - GUI

[Bus Based Reports]
Option: Subsystem summary / totals
Run Line Mode Activity SUBS - CLI
ACTIVITY?
>>SUBS
AB
The subsystem reporting activity SUBS summarizes conditions in the working case by tabulating
the following for a specified subsystem:
• Conditions at each system swing (Type 3) bus.

• Conditions at each area slack generator bus.
• The number of components.
• Generation, load, shunt and charging totals.
• Loss, line shunt, and charging totals by voltage level.
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. The area, zone, and/or
owner assignments of buses are used to determine which loads, machines, and branches are to be
processed when subsystem selection by area, zone, and/or owner is enabled. The owner assign-
ments of machines, ac branches, VSC dc lines, FACTS devices, and GNE devices, and the area,
zone, and owner assignments of loads, are not considered.
When processing a subsystem, if the multi-section line reporting option is enabled (refer to
Section 3.3.3 Program Run-Time Option Settings and activity OPTN), the dummy buses of a multi-
section line grouping (and hence the members of the grouping) are treated as part of the specified
subsystem if and only if the nonmetered endpoint bus of the multi-section line grouping is in the
specified subsystem. Therefore, even if such a dummy bus is specifically specified, it is not included
in the subsystem unless the nonmetered endpoint bus is also designated as a member of the
subsystem. When the multi-section line reporting option is disabled, the multi-section line grouping
definitions and their metered end information are ignored.
In calculating branch totals by voltage level, activity SUBS prints an alarm at the dialog output
device whenever it encounters a non-transformer branch in the specified subsystem with different
bus base voltages at the two ends of the line. Such branches are handled as described in Branch
Totals by Voltage Level. If the report of activity SUBS is being directed to the user’s terminal, these
messages are printed between the area slack bus summary and the subsystem component totals.
The tabulation of these error messages may be suppressed by entering the AB interrupt control
code.
11-30
Program Operation Manual Summarizing Subsystem Conditions
Following the two-line case heading, the output report of activity SUBS contains a description of the
subsystem where conditions are being summarized. This is followed by the five categories of data
described in the following paragraphs.
System Swing Bus Summary

Each Type 3 bus in the subsystem being reported is listed, one per line. Swing buses are tabulated
in ascending numerical order when the numbers output option is in effect and in alphabetical order
using the names output option. The bus number, name, and base voltage are printed, along with
the number and name of the interchange area in which it is located and the number and name of
the zone to which it is assigned. The total plant active and reactive power output are printed followed
by the total plant MBASE (i.e., sum of the MBASEs of the in-service machines at the plant).
Area Slack Bus Summary

Those buses which are area slack buses for area interchange control purposes are tabulated one
per line in ascending area number order. The area number and name are printed, followed by the
area slack bus number, name, and base voltage and the number and name of the zone in which it
is located. Total plant active and reactive power output and total plant MBASE are tabulated. When
processing a subsystem, only those area slack buses which are included in the specified subsystem
are reported.
Component Totals
The total number of in-service components in the subsystem is listed in the following categories:
• Buses.
• Plants.
• Machines, including wind machines.
• Fixed shunts.
• Switched shunts.
• Loads.
• AC branches, including transformers.
• Two-winding transformer branches.
• DC lines.
• FACTS devices.
• GNE devices.
The total number of plants is calculated as the number of Type 2 and 3 buses in the subsystem, and
the number of machines is the number of in-service machines at these buses. The total number of
loads is calculated as the number of in-service loads at Type 1, 2, and 3 buses in the subsystem.
The totals of ac branches, transformers, and dc lines include those ties from the specified
subsystem to other subsystems in the working case with a nonmetered end bus is in the specified
subsystem; the total number of FACTS devices are those where the sending bus is in the specified
subsystem; the total number of GNE devices are those where the non-metered bus is in the spec-
ified subsystem (refer to Subsystem Totals and Branch Totals by Voltage Level).
The total number of buses does not include the star point bus of any three-winding transformer
where the nonmetered end bus is in the specified subsystem. Each three-winding transformer
11-31
Summarizing Subsystem Conditions Program Operation Manual
where the nonmetered end bus is in the specified subsystem contributes one to the totals of ac
branches and transformers; the three two-winding transformers comprising each such three-
winding transformer do not contribute to these totals.
When subsystem specification by area, zone, and/or owner is in effect, both the number of loads
and the subsystem load total (refer to Subsystem Totals) indicate the in-service load connected to
Type 1, 2, and 3 buses within the subsystem. These totals include loads assigned to other areas,
zones, or owners (refer to Load Data), but which are attached to subsystem buses, and exclude
loads where area, zone, and/or owner assignments fall within the specified areas, zones, and/or
owners, but which are attached to buses outside of the subsystem.
When subsystem specification by owner is in effect, machine, branch, FACTS device, and GNE
device totals, as well as VSC dc lines contributing to dc line totals, are handled in a similar manner.
Subsystem Totals
Constant MVA, current and admittance load totals, and bus shunt, FACTS device shunt, single
terminal GNE device, line shunt, and charging totals are tabulated, both in terms of nominal values
(i.e., at unity voltage) and actual values (i.e., at the present voltage profile). Generation totals
include swing bus power outputs. Line shunt totals include transformer magnetizing admittance
contributions.
Branch Totals by Voltage Level

Subsystem losses, line shunt, and line charging are tabulated by voltage level with voltage levels
listed in descending order. Line shunt totals include transformer magnetizing admittance contribu-
tions. If any series FACTS devices, GNE devices, or dc lines are in the subsystem being
summarized, their losses are listed first in the report.
Losses on a series FACTS device (i.e., one with a non-zero terminal bus specified; refer to FACTS
Device Data) are defined as the algebraic sum of:
(j QSEND) + (j QTERM)
Similarly, losses on a series GNE device (i.e., one connected to more than one terminal bus) are
defined as the algebraic sum of the powers flowing into the device at each of the buses to which it
is connected.
Losses on a two-terminal dc line are defined as the algebraic sum of:
(PACR + jQACR) + (PACI + jQACI)

Similarly, losses on a voltage source converter (VSC) dc line are calculated as:
- (PACcnv1 + jQACcnv1) - (PACcnv2 + jQACcnv2)

When a designated subsystem is being tabulated and a two-terminal or VSC dc line is a tie branch
to another subsystem, the dc line losses are included in the dc line loss total if the nonmetered end
converter bus is in the subsystem being reported.
For multi-terminal dc lines, losses between an ac converter bus and the dc bus(es) to which it is
connected are included if the ac bus is in the specified subsystem (i.e., metering at the dc bus is
assumed). Losses on a dc link of a multi-terminal line are included in the loss totals when activity
SUBS processes all buses in the working case. When a subsystem of the working case is being
reported, losses on an individual dc link are included in the dc loss totals unless:
11-32
Program Operation Manual Summarizing Subsystem Conditions
• The subsystem is specified by area and the nonmetered end dc bus is not in one of the
specified areas.
• The subsystem is specified by zone and the nonmetered end dc bus is not in one of the
specified zones.
• The subsystem is specified by owner and the nonmetered end dc bus is not assigned
to one of the specified owners.
• The subsystem is specified by base voltage and the low end of the voltage range is
greater than zero.
• The subsystem is specified by bus and at least one converter bus of the multi-terminal
line is not in the designated subsystem.
Similarly, losses through the grounding resistance of the second dc bus of the converters of a multi-
terminal line are included in the loss totals when activity SUBS processes all buses in the working
case. When a subsystem of the working case is being reported, losses through an individual IDC2
ground path are included or omitted using criteria corresponding to that given for dc links above.
The ac branch losses are taken as I2R and I2X losses and exclude the line charging and line
connected shunt components. Transformer losses exclude magnetizing admittance components.
When a designated subsystem is being tabulated, the losses, line shunt, and charging components
on any tie line to another subsystem are included in the branch totals if the nonmetered end bus is
in the subsystem being reported (i.e., subsystem boundaries are at the metered end of each tie
branch). For series FACTS devices, terminal end metering is assumed.
Two- and three-winding transformers have their loss and magnetizing admittance contributions
assigned to the voltage level of the Winding 2 side bus. If the second winding of a three-winding
transformer is out-of-service with the remaining windings in-service (i.e., its status value is 2), its
loss and line shunt contributions are assigned to the voltage level of the Winding 3 side bus.
Non-transformer branches with different base voltages at the two ends of the line generate an
alarm, and their contributions are assigned to the lower of the two base voltages. If a base voltage
is specified at only one end of such a branch, its contributions are assigned to that voltage level.
Be careful not to confuse the roles of the nonmetered end bus and the Winding 2 side bus of trans-
formers. The nonmetered end bus of all branches, including transformers, is used to determine if
the branch is included in the subsystem being reported. If a transformer is in the subsystem, the
voltage level of the Winding 2 side bus determines the voltage level totals to which the transformer
contributes.
PSS®E GUI Users Guide, Section 16.3.4, Summary of Subsystem Conditions
Section 13.3.4, Summary of Subsystem Conditions
11-33
Summarizing Load Reduction Program Operation Manual
11.6 Summarizing Load Reduction

Activity LODR
Run Activity LODR - GUI

[Bus Based Reports]
Option: Load reduction output
AB
The load reduction reporting activity LODR summarizes the reduction in:
• Nominal constant MVA load caused when voltage at a load bus falls below PQBRAK.
• Nominal constant current load caused when voltage at a load bus falls below 0.5 pu.
The LOAD_REDUCTION API routine includes the following among its inputs:
• A designation of the subsystem in which reduced loads are to be reported; refer to Sec-
tion 4.8, Subsystem Selection.
• A subsystem selection option when area, owner and/or zone are included among the
subsystem selection criteria. To determine subsystem loads:
- Use the area, owner and/or zone assignments of the bus to which the load is
connected.
- Use the area, owner and/or zone assignments of the load.
There is no customized question and answer dialog in line mode for activity LODR; in line mode,
activity LODR can be accessed through the BAT_LOAD_REDUCTION command.
11.6.1 Operation of Activity LODR

When voltage at a bus falls below the constant power characteristic threshold PQBRAK, any
constant power load at the bus is reduced as shown in Figure 5-1 so that, at a voltage of 0.0, the
current drawn by the load is 0.0. Similarly, when voltage at a bus falls below 0.5 pu, any constant
current load at the bus is reduced as shown in Figure 5-2 so that, at a voltage of 0.0, the current
drawn by the load is 0.0.
For any subsystem load for which such a reduction is applied, activity LODR tabulates:
• The voltage at the bus.

• If the load has a non-zero constant power component:
- The specified complex constant power load.
- The complex constant power load at the present bus voltage.
- The complex constant power load reduction.
11-34
Program Operation Manual Summarizing Load Reduction
• If the load has a non-zero constant current component:

- The specified complex nominal constant current load.
- The complex nominal constant current load at the present bus voltage.
- The complex nominal constant current load reduction.
Totals of reported quantities are tabulated at the end of each subsystem grouping. An example is
provided in Figure 11-6.

Note that values listed as constant current load are nominal values (i.e., at unity voltage, as shown
in activities such as LIST and in the [Spreadsheet] View). Thus, the values shown as actual constant
current loads are not identical to those reported in the various power flow solution reporting activi-
ties that report loadings in MVA. Clearly, to obtain the MVA corresponding to the reduced current
loadings, multiply the complex value shown as actual nominal constant current load by the voltage
magnitude at the bus.
PQBRAK may be modified using the data changing activity CHNG or the [Solution Parameters]
dialog.
PSS®E GUI Users Guide, Section 16.3.5, Summarizing Load Reduction
PSS®E Application Program Interface (API), Section 1.125, LOAD_REDUCTION
See also:
Constant Power Load Characteristic
Constant Current Load Characteristic
Section 4.8, Subsystem Selection
Section 4.9, Subsystem Reporting
11-35
Summarizing Load Reduction

Power Flow Reports
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSSÆE TUE, FEB 24 2009 9:40
PSS/E PROGRAM APPLICATION GUIDE EXAMPLE
LOAD REDUCTION FOR VOLTAGE < PQBRAK=0.700 (MVA LOAD) & 0.5 (CURRENT LOAD)
I X--------------CONSTANT MVA LOAD--------------X X--------NOMINAL CONSTANT CURRENT LOAD--------X
BUS# X-- NAME --X BASKV D VOLTAGE SCHEDULED ACTUAL REDUCTION SCHEDULED ACTUAL REDUCTION
153 MID230 230.00 1 0.3361 60.0 30.0 30.5 15.2 29.5 14.8 61.1 30.6 56.1 28.1 5.0 2.5
154 DOWNTN 230.00 1 0.0000 180.0 135.0 0.0 0.0 180.0 135.0 195.4 146.6 0.0 0.0 195.4 146.6
154 DOWNTN 230.00 2 0.0000 120.0 105.0 0.0 0.0 120.0 105.0 130.3 114.0 0.0 0.0 130.3 114.0
203 EAST230 230.00 1 0.2492 90.0 45.0 30.0 15.0 60.0 30.0 94.3 47.2 75.6 37.8 18.7 9.4
205 SUB230 230.00 1 0.1373 360.0 210.0 47.2 27.6 312.8 182.4 386.3 225.3 214.8 125.3 171.5 100.1
3005 WEST 230.00 1 0.4198 30.0 15.0 20.2 10.1 9.8 4.9 30.1 15.1 29.5 14.8 0.6 0.3
3007 RURAL 230.00 1 0.3116 60.0 22.5 27.5 10.3 32.5 12.2 62.4 23.4 55.6 20.8 6.8 2.6
3008 CATDOG 230.00 1 0.2262 60.0 22.5 17.3 6.5 42.7 16.0 63.0 23.6 48.0 18.0 15.1 5.7
TOTALS 960.0 585.0 172.7 84.7 787.3 500.3 1023.0 625.7 479.5 244.7 543.5 381.0
Figure 11-6. Example of Load Reduction Report

11-36

PSS®E 34.2
Program Operation Manual Summarizing Area Totals
11.7 Summarizing Area Totals

Activity AREA
Run Activity AREA - GUI

Power Flow > Reports > Area / owner / zone totals…
[Area / Owner / Zone Totals]
OPTION: Report on Areas
Run Line Mode Activity AREA - CLI
ACTIVITY?
>>AREA
AB
The area summary activity AREA provides a tabulation by interchange area of the desired area net
interchange, along with area totals of:
• Generation • Line connected shunt elements, including

• Load magnetizing admittance of transformers
• Induction machine powers • Line charging
• Bus connected shunt elements, including fixed • Net interchange

shunts, switched shunts and shunt elements of • Losses
FACTS devices
The AREA_2 API routine tabulates totals by area. The output block for each area and for system
totals consists of two lines: the first contains active power totals and the second the reactive power
totals.
The AREA_ZONE API routine tabulates totals by area along with subtotals by zone for each
reported area. The output block for each area consists of one line for each zone in the area, followed
by one line of area totals.
In both of these reports, the area number and name is printed for each area block reported.
The user specifies the areas to be reported (refer to Section 4.8 Subsystem Selection). Totals for
the specified areas are printed in ascending area number order, followed by the sums of the totals
of those areas.
Recall that buses, loads and induction machines all have area assignments associated with them
(refer to Bus Data, Load Data and Induction Machine Data). In the AREA_2 API routine, one of three
load and induction machine reporting options may be selected for calculating each area's total load
and induction machine powers:
• Calculate the area totals by summing all in-service loads and induction machines con-
nected to buses that are assigned to the area; the area assignments of the loads and
induction machines are not considered. A single set of totals is tabulated in the induc-
tion generation, induction motor, and load columns labeled AT AREA BUSES.
11-37
Summarizing Area Totals Program Operation Manual
• Calculate the area totals by summing all in-service loads and induction machines that
are assigned to the area; the area assignments of the buses to which they are con-
nected is not considered. A single set of totals is tabulated in the induction generation,
induction motor, and load columns labeled ASSIGNED TO THE AREA.
• Calculate three subtotals of area load and induction machine powers:
- The sums of all in-service loads and induction machine powers for which both the
load or induction machine and the bus to which it is connected are assigned to the
area. These are tabulated in the columns labeled AREA ITEMS AT AREA BUSES.
- The sums of all in-service loads and induction machine powers for which the load
or induction machine is assigned to the area but the bus to which it is connected is
assigned to a different area. These are tabulated in the columns labeled AREA
ITEMS AT NON-AREA BUSES.
- The sums of all in-service loads and induction machines for which the bus to which
it is connected is assigned to the area but the load or induction machine is assigned
to a different area. These are tabulated in the columns labeled NON-AREA ITEMS
AT AREA BUSES.
The output block for COLUMN TOTALS is blank for the three sets of load and induction
machine columns. Rather, load and induction machine totals for the reported areas are
tabulated following this output block. Two complex totals are given for loads, induction
generators, and induction motors:
- TOTAL ASSIGNED TO THESE AREAS, which are the sums of the columns in the
first two sets of totals described above.
- TOTAL CONNECTED TO BUSES IN THESE AREAS, which are the sums of the
columns in the first and third sets of totals described above.
Clearly, if all areas are being reported by the AREA_2 API routine, these two sets of
totals are identical.
In the AREA_ZONE API routine, an individual in-service bus load is included in the load totals of
the area to which the load is assigned; this area need not be the same area in which the bus at
which the load is connected is located. Similarly, an in-service induction machine is included in the
induction machine totals of the area to which it assigned rather than that of the bus to which it is
connected.
Line losses are taken as I2R and I2X losses and exclude the line charging and line connected shunt
components; transformer losses exclude magnetizing admittance components. Series FACTS
device losses are calculated as the algebraic sum of the reactive power flowing into the series
device at its endpoint buses. Multiple terminal GNE device losses are calculated as the algebraic
sum of the powers flowing into the device at its endpoint buses.
Losses on two-terminal dc transmission lines and on branches within multi-terminal dc lines are
assigned to the area of the nonmetered end. For the connections between each multi-terminal dc
line ac converter bus and the dc bus to which it is connected, metering on the dc bus side is
assumed (i.e., losses are assigned to the area of the ac bus). Losses on a voltage source converter
(VSC) dc line are calculated as the algebraic sum of the active and reactive powers flowing into the
line at its endpoint buses. They are assigned to the area of the voltage controlling converter when
both converters are in-service; if only one converter is in-service, losses are assigned to the area
in which it is located. Refer to the PSS®E Program Application Guide for additional details on dc
line quantities.
11-38
An area has positive net interchange when it is selling or exporting power. Two net interchange
totals are tabulated for each area that is reported:
1. The total power flowing into area tie lines.
2. The total power flowing into area tie lines plus contributions from or to loads where the area
assignment of the load differs from that of the bus to which it is connected.
These two values of area net interchange correspond to the two net interchange definitions that
may be specified for use by the area interchange control calculation of the power flow solution
activities.
Line charging, line shunt, net interchange, and loss totals are evaluated on the basis of the metered
end designated for each tie branch; i.e., for each tie branch, these quantities are assigned to the
area of the nonmetered end bus. Transformer magnetizing admittance components are included in
line shunt totals. Tie line flows, and hence interchange, are calculated including the charging, line
connected shunt, and transformer magnetizing admittance components.
grouping are ignored. Instead, any generation, load, induction machine, and bus shunt present at
assigned to the area of the nonmetered endpoint bus of the multi-section line grouping. Similarly,
line charging, line shunt, net interchange and loss contributions are evaluated on the basis of the
metered end designated for each multi-section line grouping which is a tie branch (i.e., its endpoint
buses are located in different areas); for each multi-section tie, these quantities are assigned to the
area of the nonmetered endpoint bus.
A three-winding transformer is considered to be a tie line when the three buses which is connects
are not in the same area. Tie flows are derived from the flows into the transformer at the two
metered ends.
A two-terminal dc transmission line is considered to be a tie line when the converter station buses
are located in different areas. The tie flow is taken as the power flowing into the dc converter from
the ac system at the metered end. For multi-terminal dc lines, if a converter bus and a dc bus to
which it is connected are in different areas, the connection is treated as a tie line and metering on
the dc bus side is assumed. DC links within a multi-terminal dc line are handled in the same manner
as ac branches. A voltage source converter (VSC) dc transmission line is considered to be a tie line
when the converter station buses are located in different areas. The tie flow is taken as the power
flowing into the dc converter from the ac system at the power controlling converter end. Refer to the
PSS®E Program Application Guide for additional details on dc line quantities.
A series FACTS device is considered to be a tie line when the sending and terminal buses are
located in different areas. The tie flow is taken as the power flowing into the series element at the
terminal bus end.
A multiple terminal GNE device is considered to be a tie line when its connected buses are located
in different areas. The tie flow is taken as the power flowing into the device at the metered end.
Activity AREA may be terminated by entering the AB interrupt control code.
11-39
Summarizing Area Totals Program Operation Manual
The savnw.sav power flow case, which is provided in the Example subdirectory of the PSS®E instal-
lation, has three areas. For this power flow case, the Area totals are shown in Figure 11-7. The load
reporting option that provides for three subtotals of area load is used in this example.
A brief examination of the results shows:
• The FLAPCO area is transmitting power to the other two areas although it is exporting
more (278.7 MW) than scheduled (250 MW). This is because the Area Interchange
control was not enabled in the [Loadflow Solutions] window.
• LIGHTCO area is receiving 130.8 MW compared to a desired interchange of 100 MW.
• The FLAPCO area is receiving 684.6 Mvar from the other two areas.
• Total Real Power losses are 58.7 MW
11-40
®
PSS E GUI Users Guide, Section 16.2.1, Area Totals
Section 13.2.1, Area Totals
11-41
PSS®E 34.2
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS®E TUE, MAR 29 2011 15:51

PSS(R)E PROGRAM APPLICATION GUIDE EXAMPLE AREA TOTALS
BASE CASE INCLUDING SEQUENCE DATA IN MW/MVAR
--AREA ITEMS AT-- --AREA ITEMS AT-- --NON-AREA ITEMS-
FROM ----AREA BUSES--- --NON-AREA BUSES- --AT AREA BUSES-- TO -NET INTERCHANGE-
Figure 11-7. Area Total Results

GENE- TO IND TO TO IND TO TO IND TO TO BUS GNE BUS TO LINE FROM TO TO TIE TO TIES D
X-- AREA --X RATION MACHNS LOAD MACHNS LOAD MACHNS LOAD SHUNT DEVICES SHUNT CHARGING LOSSES LINES + LOADS N
1 1500.0 0.0 200.0 0.0 0.0 0.0 1000.0 0.0 0.0 0.0 0.0 21.3 278.7 1278.7
FLAPCO 162.4 0.0 100.0 0.0 0.0 0.0 800.0 349.9 0.0 0.0 841.3 438.3 -684.6 115.4
2 1400.0 0.0 1500.0 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 30.8 -130.8 -1130.8
11-42
LIGHTCO 617.7 0.0 850.0 0.0 800.0 0.0 0.0 -641.4 0.0 0.0 623.0 590.4 441.7 -358.3
5 358.7 0.0 500.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 6.6 -147.9 -147.9
WORLD 184.0 0.0 200.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 345.8 87.0 242.9 242.9
COLUMN 3258.7 0.0 0.0 0.0 0.0 58.7 0.0 0.0
TOTALS 964.2 -291.5 0.0 0.0 1810.1 1115.7 0.0 0.0
X------- INDUCTION MACHINES ------X
X---- LOADS ----X X-- GENERATORS -X X---- MOTORS ---X
MW MVAR MW MVAR MW MVAR
TOTAL ASSIGNED TO THESE AREAS 3200.0 1950.0 0.0 0.0 0.0 0.0
TOTAL CONNECTED TO BUSES IN THESE AREAS 3200.0 1950.0 0.0 0.0 0.0 0.0
Summarizing Area Totals
Power Flow Reports
Program Operation Manual Summarizing Owner Totals
11.8 Summarizing Owner Totals

Activity OWNR
Run Activity OWNR - GUI

OPTION: Report on Owners
Run Line Mode Activity OWNR - CLI
ACTIVITY?
>>OWNR

AB
The owner summary activity OWNR provides a tabulation by owner of the following owner totals:
• Generation.
• Load.
• Induction machine generation.
• Induction motor powers.
• Bus connected shunt elements, including fixed shunts, switched shunts and shunt ele-
ments of FACTS devices.
• Power flow into single terminal GNE devices
• Line connected shunt elements, including magnetizing admittance of transformers.
• Line charging.
• Losses.
The user may process the entire working case or specify subsystem data (refer to Section 4.8 Sub-
system Selection) by bus subsystem, area, zone, owner, or basekV. Totals for the selected owners
are printed in ascending owner number order, followed by the sums of the totals of those owners.
An individual in-service bus load is included in the load totals of the owner to which the load is
assigned; this owner need not be the same owner in which the bus at which the load is connected
is located (refer to Bus Data and Load Data). Similarly, generation, induction machine, ac branch,
VSC dc line, FACTS device, and GNE device quantities are assigned to the designated conven-
tional machine, induction machine, branch, VSC dc line, FACTS device, and GNE device owners,
respectively.
11-43
Summarizing Owner Totals Program Operation Manual
assigned to the owner of the nonmetered end. For the connections between each multi-terminal dc
assumed (i.e., losses are assigned to the owner of the ac bus). Losses on a voltage source
converter (VSC) dc line are calculated as the algebraic sum of the active and reactive powers
flowing into the line at its endpoint buses. Refer to the PSS®E Program Application Guide for addi-
tional details on dc line quantities.
Activity OWNR may be terminated by entering the AB interrupt control code.
The savnw.sav power flow case, has seven Owners. The Report on Owner totals are shown in
Figure 11-8.
11-44
Summarizing Owner Totals
Power Flow Reports
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS®E THU, MAR 31 2011 13:52

PSS(R)E PROGRAM APPLICATION GUIDE EXAMPLE OWNER TOTALS
X----- FROM -----X TO TO
X-- GENERATION --X INDUCTN TO TO BUS BUS GNE TO LINE FROM
X- OWNER --X SYNCHRN INDUCTN MOTORS LOAD SHUNT DEVICES SHUNT CHARGING LOSSES
1 499.9 0.0 0.0 800.0 0.0 0.0 0.0 0.0 26.3
TRAN 1 54.1 0.0 0.0 550.0 349.9 0.0 0.0 1270.8 506.5
Figure 11-8. Owner Totals Results

2 560.0 0.0 0.0 1500.0 0.0 0.0 0.0 0.0 6.2
TRAN 2 247.1 0.0 0.0 850.0 -316.9 0.0 0.0 14.7 264.9
5 124.0 0.0 0.0 500.0 0.0 0.0 0.0 0.0 5.4
11-45
TRAN 5 67.6 0.0 0.0 200.0 0.0 0.0 0.0 57.4 53.4
11 1019.9 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
GEN 1 116.3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
22 899.7 0.0 0.0 0.0 0.0 0.0 0.0 0.0 19.5
GEN 2 394.7 0.0 0.0 0.0 -324.5 0.0 0.0 464.9 257.8
55 155.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.2

GEN 5 84.5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 24.6
100 0.0 0.0 0.0 400.0 0.0 0.0 0.0 0.0 0.9
NO BUSES 0.0 0.0 0.0 350.0 0.0 0.0 0.0 2.3 8.5
PSS®E 34.2
TOTALS 3258.7 0.0 0.0 3200.0 0.0 0.0 0.0 0.0 58.7
964.2 0.0 0.0 1950.0 -291.5 0.0 0.0 1810.1 1115.7
Summarizing Zone Totals Program Operation Manual
• The seven Owners have ownership of all the generators in this network (3258 MW).
This can be compared with the Area totals.
• All the shunts in the network, whether they be FACTS devices, switched shunts or bus
shunts are assigned to three Owners (TRAN 1, TRAN 2 and GEN 2).
• Three Owners (GEN 1, GEN 2 and GEN 5) supply a total of 19,196 MW of generation
but have no ownership of demand.
• Note that there is no Owner interchange control available.
PSS®E GUI Users Guide, Section 16.2.2, Owner Totals
Section 13.2.2, Owner Totals
11.9 Summarizing Zone Totals

Activity ZONE
Run Activity ZONE - GUI

OPTION: Report on Zones
Run Line Mode Activity ZONE - CLI
ACTIVITY?
>>ZONE
AB
The zone summary activity ZONE provides a tabulation by zones of the following zone totals:
• Generation • Line connected shunt elements, including

• Load magnetizing admittance of transformers
• Induction machine powers • Line charging
• Bus connected shunt elements, including fixed • Net interchange

shunts, switched shunts and shunt elements of • Losses
FACTS devices
The ZONE_2 API routine tabulates totals by zone. The output block for each zone and for system
totals consists of two lines: the first contains active power totals and the second the reactive power
totals.
11-46
Program Operation Manual Summarizing Zone Totals
The ZONE_AREA API routine tabulates totals by zone along with subtotals by area for each
reported zone. The output block for each zone consists of one line for each area in the zone,
followed by one line of zone totals.
In both of these reports, the zone number and name is printed for each zone block reported.
The user specifies the zones to be reported (refer to Section 4.8 Subsystem Selection). Totals for
the specified zones are printed in ascending zone number order, followed by the sums of the totals
of those zones.
Recall that buses, loads and induction machines all have zone assignments associated with them
(refer to Bus Data, Load Data and Induction Machine Data). In the ZONE_2 API routine, one of
three load and induction machine reporting options may be selected for calculating each zone's
total load and induction machine powers:
• Calculate the zone totals by summing all in-service loads and induction machines con-
nected to buses that are assigned to the zone; the zone assignments of the loads and
induction machines are not considered. A single set of totals is tabulated in the induc-
tion generation, induction motor, and load columns labeled AT ZONE BUSES.
• Calculate the zone totals by summing all in-service loads and induction machines that
are assigned to the zone; the zone assignments of the buses to which they are con-
nected is not considered. A single set of totals is tabulated in the induction generation,
induction motor, and load columns labeled ASSIGNED TO THE ZONE.
• Calculate three subtotals of zone load and induction machine powers:
- The sums of all in-service loads and induction machine powers for which both the
load or induction machine and the bus to which it is connected are assigned to the
zone. These are tabulated in the columns labeled ZONE ITEMS AT ZONE BUSES.
- The sums of all in-service loads and induction machine powers for which the load
or induction machine is assigned to the zone but the bus to which it is connected
is assigned to a different zone. These are tabulated in the columns labeled ZONE
ITEMS AT NON-ZONE BUSES.
- The sums of all in-service loads and induction machines for which the bus to which
it is connected is assigned to the zone but the load or induction machine is
assigned to a different zone. These are tabulated in the columns labeled NON-
ZONE ITEMS AT ZONE BUSES.
The output block for COLUMN TOTALS is blank for the three sets of load and induction
machine columns. Rather, load and induction machine totals for the reported zones are
tabulated following this output block. Two complex totals are given for loads, induction
generators, and induction motors:
- TOTAL ASSIGNED TO THESE ZONES, which are the sums of the columns in the
first two sets of totals described above.
- TOTAL CONNECTED TO BUSES IN THESE ZONES, which are the sums of the
columns in the first and third sets of totals described above.
Clearly, if all zones are being reported by the ZONE_2 API routine, these two sets of
totals are identical.
In the ZONE_AREA API routine, an individual in-service bus load is included in the load totals of
the zone to which the load is assigned; this zone need not be the same zone in which the bus at
which the load is connected is located. Similarly, an in-service induction machine is included in the
11-47
induction machine totals of the zone to which it assigned rather than that of the bus to which it is
connected.
assigned to the zone of the nonmetered end. For the connections between each multi-terminal dc
assumed (i.e., losses are assigned to the zone of the ac bus). Losses on a voltage source converter
(VSC) dc line are calculated as the algebraic sum of the active and reactive powers flowing into the
line at its endpoint buses. They are assigned to the zone of the voltage controlling converter when
both converters are in-service; if only one converter is in-service, losses are assigned to the zone
in which it is located. Refer to the PSS®E Program Application Guide for additional details on dc
line quantities.
A zone has positive net interchange when it is selling or exporting power. Two net interchange totals
are tabulated for each zone that is reported:
1. The total power flowing into zone tie lines.
2. The total power flowing into zone tie lines plus contributions from or to loads where the zone
assignment of the load differs from that of the bus to which it is connected.
These two values of zone net interchange correspond to the two net interchange definitions that
may be specified for use by the area interchange control calculation of the power flow solution
activities.
Line charging, line shunt, net interchange, and loss totals are evaluated on the basis of the metered
end designated for each tie branch; i.e., for each tie branch, these quantities are assigned to the
zone of the nonmetered end bus. Transformer magnetizing admittance components are included in
line shunt totals. Tie line flows, and hence interchange, are calculated including the charging, line
connected shunt, and transformer magnetizing admittance components.
Option Settings and activity OPTN), the zone assignments of the dummy buses of each multi-
grouping are ignored. Instead, any generation, load, induction machine, and bus shunt present at
assigned to the zone of the nonmetered endpoint bus of the multi-section line grouping. Similarly,
line charging, line shunt, net interchange, and loss contributions are evaluated on the basis of the
metered end designated for each multi-section line grouping that is a tie branch (i.e., its endpoint
buses are located in different zones); for each multi-section tie, these quantities are assigned to the
zone of the nonmetered endpoint bus.
When the multi-section line reporting option is disabled, the zone assignments of dummy buses as
are not in the same zone. Tie flows are derived from the flows into the transformer at the two
metered ends.
11-48
Program Operation Manual Summarizing Zone Totals
are located in different zones. The tie flow is taken as the power flowing into the dc converter from
which it is connected are in different zones, the connection is treated as a tie line and metering on
when the converter station buses are located in different zones. The tie flow is taken as the power
located in different zones. The tie flow is taken as the power flowing into the series element at the
terminal bus end.
A multiple terminal GNE device is considered to be a tie line when its connected buses are located
in different zones. The tie flow is taken as the power flowing into the device at the metered end.
Activity ZONE may be terminated by entering the AB interrupt control code.
The savnw.sav power flow case, has four Zones. The Report on Zone totals is shown in Figure 11-
9. The load reporting option that provides for three subtotals of zone load is used in this example.
• Zone 1 (FIRST) has zero generation but a demand level of 1200 MW. It can be seen
that its net interchange is 1218 MW which serves the load demand and the zone’s
losses of 18 MW. Note that there is no Zone interchange flow control available.
11-49
• Similarly, Zone 2 (SECOND) has 1400 MW of generation but 1500 MW of load. Its net
interchange therefore is seen to be 130 MW which serves the deficit between genera-
tion and demand and the zone’s real power losses of 30.8 MW.
®
PSS E GUI Users Guide, Section 16.2.3, Zone Totals
Section 13.2.3, Zone Totals
11-50
Power Flow Reports
Summarizing Zone Totals
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS®E THU, MAR 31 2011 13:20

PSS(R)E PROGRAM APPLICATION GUIDE EXAMPLE ZONE TOTALS
--ZONE ITEMS AT-- --ZONE ITEMS AT-- --NON-ZONE ITEMS-
Figure 11-9. Zone Totals Results

FROM ----ZONE BUSES--- --NON-ZONE BUSES- --AT ZONE BUSES-- TO -NET INTERCHANGE-
GENE- TO IND TO TO IND TO TO IND TO TO BUS GNE BUS TO LINE FROM TO TO TIE TO TIES
X-- ZONE --X RATION MACHNS LOAD MACHNS LOAD MACHNS LOAD SHUNT DEVICES SHUNT CHARGING LOSSES LINES + LOADS
1 0.0 0.0 1200.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 18.0 -1218.0 -1218.0
FIRST 0.0 0.0 900.0 0.0 0.0 0.0 0.0 349.9 0.0 0.0 841.3 289.6 -698.2 -698.2
2 1400.0 0.0 1500.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 30.8 -130.8 -130.8
11-51
SECOND 617.7 0.0 850.0 0.0 0.0 0.0 0.0 -641.4 0.0 0.0 623.0 590.4 441.7 441.7
5 358.7 0.0 500.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 6.6 -147.9 -147.9
FIFTH 184.0 0.0 200.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 345.8 87.0 242.9 242.9
77 1500.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 3.3 1496.7 1496.7
PLANT 162.4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 148.8 13.6 13.6
COLUMN 3258.7 0.0 0.0 0.0 0.0 58.7 0.0 0.0
TOTALS 964.2 -291.5 0.0 0.0 1810.1 1115.7 0.0 0.0
X------- INDUCTION MACHINES ------X
X---- LOADS ----X X-- GENERATORS -X X---- MOTORS ---X
MW MVAR MW MVAR MW MVAR
TOTAL ASSIGNED TO THESE ZONES 3200.0 1950.0 0.0 0.0 0.0 0.0
TOTAL CONNECTED TO BUSES IN THESE ZONES 3200.0 1950.0 0.0 0.0 0.0 0.0
PSS®E 34.2
Reporting Interchange by Area/Owner/Zone Program Operation Manual
11.10 Reporting Interchange by Area/Owner/Zone

Reporting Interchange by Area/Owner/Zone
Table 11-2 Information Provided in Interchange Reports for Areas and Zones shows the information
provided in the interchange reports on the bases of area and zone.
Table 11-2. Information Provided in Interchange Reports for Areas and Zones
Information Provided Area Zone

Total interchange between Areas (MW, Mvar) Y -
Interchange flows on tie-lines between Areas (MW, Mvar) Y -
Total interchange between Zones (MW, Mvar) - Y
Interchange flows on tie-lines between Zones (MW, Mvar) - Y
There are two types of summary reports: Inter area/zone flow, which provides total flows between
Areas or Zones and Tie line, which provides detailed flows on the tie lines (branches) between the
Areas or Zones.
The output is organized by Area or Zone such that all Areas or all Zones are reported or the report
may be limited to selected Areas or Zones.
It is useful to note that the inter Area / Zone flow report can be compared to the Totals report
described in Section 11.6 Summarizing Load Reduction.
11.11 Summarizing Area-to-Area Interchange

Activity INTA
Run Activity INTA - GUI

Power Flow > Reports > Area / zone based reports…
[Area / Zone Based Reports]
OPTION: Inter area / zone flow; Output for Areas
Run Line Mode Activity INTA - CLI
ACTIVITY?
>>INTA
AB
The area interchange summary activity INTA summarizes tie flows between an interchange area
and all other areas in the working case.
The user may restrict the report to interchange from specified areas (refer to Section 4.8 Subsystem
Selection). Tie flow totals from the specified areas to all other areas are printed in ascending from
area number order.
11-52
Program Operation Manual Summarizing Area-to-Area Interchange
The output of activity INTA is in the form of a matrix (Figure 11-10). The two-line row for each from
area shows active power interchange on the top line and reactive power interchange on the bottom
line. Tie flows, and hence interchange, are evaluated on the basis of the metered end designated
for each tie branch, and are calculated including the charging and line connected shunt compo-
nents. The standard sign convention is used in printing interarea flows: a positive value indicates
power leaving the from area.
Tie line flows, and hence interchange, are evaluated on the basis of the metered end designated
for each tie branch, and are calculated including the charging, line connected shunt, and trans-
former magnetizing admittance components.
metered ends.
terminal bus end.
A multiple terminal GNE device is considered to be a tie line when the buses to which it is connected
are located in different areas. The tie flow is taken as the power flowing into the device at the
metered bus end.
The net interchange definition follows that of the most recently enabled setting of the area inter-
change control code via either activity OPTN or a power flow solution activity: tie lines only, or tie
lines plus loads for which the load and the bus to which it is connected are in different areas (refer
to Area Interchange Control).
The output of activity INTA may be terminated by entering the AB interrupt control code.
The Inter-area summary report for the savnw.sav case is seen in Figure 11-10.
11-53
Summarizing Zone-to-Zone Interchange Program Operation Manual
Figure 11-10. Inter-Area Flows by Area
This simple summary on inter-area flow can be compared with the Area Total report. This report
confirms the previously documented results which show that Area 1 is exporting 131 MW to Area 2
and exporting 148 MW to Area 5. Note that these numbers are rounded in comparison to results
®
PSS E GUI Users Guide, Section 16.1.1, Area-to-Area Interchange
Section 13.1.1, Area-to-Area Interchange
11.12 Summarizing Zone-to-Zone Interchange

Activity INTZ
Run Activity INTZ - GUI

OPTION: Inter area / zone flow; Output for Zones
Run Line Mode Activity INTZ - CLI
ACTIVITY?
>>INTZ
AB
The zone interchange summary activity INTZ summarizes tie flows between each zone and all other
zones in the working case.
The user may restrict the report to interchange from specified zones (refer to Section 4.8
Subsystem Selection). Tie flow totals from the specified zones to all other zones are printed in
ascending from zone number order.
11-54
Program Operation Manual Summarizing Zone-to-Zone Interchange
The output of activity INTZ is in the form of a matrix (Figure 11-11). The two-line row for each from
zone shows active power interchange on the top line and reactive power interchange on the bottom
line. Tie flows, and hence interchange, are evaluated on the basis of the metered end designated
for each tie branch, and are calculated including the charging and line connected shunt compo-
nents. The standard sign convention is used in printing interzone flows: a positive value indicates
power leaving the from zone.
its endpoint buses are in different zones, with tie flow evaluated at the metered end of the multi-
metered ends.
terminal bus end.
are located in different zones. The tie flow is taken as the power flowing into the device at the
metered bus end.
lines plus loads for which the load and the bus to which it is connected are in different zones (refer
The output of activity INTZ may be terminated by entering the AB interrupt control code.
The Inter-zone summary report for the savnw.sav case is seen in Figure 11-11.
11-55
Summarizing Loadings on Ties from Interchange Areas Program Operation Manual
Figure 11-11. Inter-Zone Flows by Zone
This simple summary on inter-zone flow can be compared with the Zone Total report (see Figure 11-
9). This report confirms the previously documented results which show that Zone 1 is importing a
total of 1218 MW from the other three zones.
PSS®E GUI Users Guide, Section 16.1.2, Zone-to-Zone Interchange
Section 13.1.2, Zone-to-Zone Interchange
11.13 Summarizing Loadings on Ties from Interchange Areas

Activity TIES
Run Activity TIES - GUI

OPTION: Tie line; Output for Areas
Run Line Mode Activity TIES - CLI
ACTIVITY?
>>TIES
AB
The tie line summary activity TIES tabulates the flows on all area ties, with tie flows grouped by
area. Interchange between pairs of areas and net interchange from each area are also listed.
11-56
Program Operation Manual Summarizing Loadings on Ties from Interchange Areas
The user may restrict the report to tie flows from specified areas (refer to Section 4.8 Subsystem
Selection). Tie flows from the specified areas to all other areas are printed in ascending from area
number order.
metered ends.
terminal bus end.
are located in different areas. The tie flow is taken as the power flowing into the device at the
metered bus end.
lines plus loads for which the load and the bus to which it is connected are in different areas (refer
In the report, the element listed first for each tie is located in the from area, and the second element
is in the to area. The metered bus of each tie branch is designated with an asterisk (  ). The stan-
dard sign convention is used in printing the tie flows: a positive flow indicates power leaving the from
area.
Activity TIES may be terminated by entering the AB interrupt control code.
11-57
Summarizing Loadings on Ties from Zones Program Operation Manual
A portion of the inter-area tie-line report for the savnw.sav case is seen in Figure 11-12. The report
presents information in order of Area. The figure shows the tie-line flows from Area 1 to Areas 2 and
5. The total flows can be compared with the interchange totals shown in Figure 11-10 (inter-area
flows) and Figure 11-7 (area totals report).
Figure 11-12. Inter-Area Tie Line Report
®
PSS E GUI Users Guide, Section 16.1.3, Loadings on Tie Lines from Interchange Areas
Section 13.1.3, Loadings on Ties from Interchange Areas
11.14 Summarizing Loadings on Ties from Zones

Activity TIEZ
Run Activity TIEZ - GUI

OPTION: Tie line; Output for Zones
Run Line Mode Activity TIEZ - CLI
ACTIVITY?
>>TIEZ
AB
The zone tie line summary activity TIEZ tabulates the flows on all zone ties, with tie flows grouped
by zone. Interchange between pairs of zones and net interchange from each zone are also listed.
11-58
Program Operation Manual Summarizing Loadings on Ties from Zones
The user may restrict the report to tie flows from specified zones. The user specifies the zones to
be reported (refer to Section 4.8 Subsystem Selection). Tie flows from the specified zones to all
other zones are printed in ascending from zone number order.
its endpoint buses are in different zones, with tie flow evaluated at the metered end of the multi-
metered ends.
terminal bus end.
are located in different zones. The tie flow is taken as the power flowing into the device at the
metered bus end.
lines plus loads for which the load and the bus to which it is connected are in different zones (refer
In the report, the element listed first for each tie is located in the from zone, and the second element
is in the to zone. The metered bus of each tie branch is designated with an asterisk (  ). The stan-
dard sign convention is used in printing the tie flows: a positive flow indicates power leaving the from
zone.
Activity TIEZ may be terminated by entering the AB interrupt control code.
11-59
Viewing Network Limit Violations Program Operation Manual
A portion of the inter-zone tie-line report for the savnw.sav case is seen in Figure 11-13. The report
presents information in order of Zone. The figure shows the tie-line flows from Zone 1 to Zones 2,
5 and 77. The total flows can be compared with the interchange totals shown in Figure 11-11 (inter-
zone flows) and Figure 11-9 (zone totals report).
Figure 11-13. Inter-Zone Tie Line Report
®
PSS E GUI Users Guide, Section 16.1.4, Loadings on Tie Lines from Zones
Section 13.1.4, Loadings on Ties from Zones
11.15 Viewing Network Limit Violations

Viewing Network Limit Violations
PSS®E enables the user to develop seven different types of reports which can assist in rapidly iden-
tifying network conditions that are outside of required control limits or to indicate controlling
equipment and possible violations and conflicts associated with those controls. The following
summary reports are available:
• Summary of branches exceeding specified percentage of selected rating

• Summary of buses with voltage outside specified band
• Summary of generator terminal loading conditions on either all, or only overloaded,
generators
• Summary of generator bus loading conditions on either all, or only var-limited,
generators
• Summary of controlling transformers and violations
• Generator reactive power and capability
11-60
Program Operation Manual Producing a Branch Overload Checking Report
• Regulated buses, violations and/or conflicts.
11.16 Producing a Branch Overload Checking Report

Activity RAT3
Run Activity RAT3 - GUI

Power Flow > Reports > Limit checking reports…
[Limit Checking Reports]
OPTION: Branches Tab; List overloaded both trans and non-trans branches, all ratings
Run Line Mode Activity RAT3 - CLI
ACTIVITY?
>>RAT3
>>
AB
The branch overload checking activity RAT3 checks each ac branch current loading against desig-
nated branch ratings. For non-transformer branches, loadings are calculated as either current
loadings or MVA loadings, according to the non-transformer branch percent loading units program
option setting. Similarly, for transformer branches, loadings are calculated as either current loadings
or MVA loadings, according to the transformer percent loading units program option setting. Refer
to Section 3.3.3 Program Run-Time Option Settings and activity OPTN. Branch overloads are
reported based on a selected ratings set: RATE A, RATE B or RATE C.
When percent current loadings are calculated, ratings are assumed to have been entered as:
MVArated =  3 x Ebase x Irated x 10-6

where:
Ebase Is the branch or transformer winding voltage base in volts.

Irated Is the rated phase current in amps.
When percent MVA loadings are calculated, ratings are assumed to have been entered as MVA
ratings.
The user specifies the percentage loading threshold. Any checked branch where loading, including
line charging, line connected shunt, and transformer magnetizing admittance components, exceeds
the specified percentage of rating is reported. The default limit is 100%.
system Selection) by bus subsystem, area, zone, owner, or basekV. Output is generated, with all
branches having at least one endpoint bus in the specified subsystem and at least one non-zero
rating being checked. Then the user is given the opportunity to specify another subsystem.
11-61
Producing a Branch Overload Checking Report Program Operation Manual
When an owner subsystem is specified, branch ownership rather than bus ownership is used in
determining which branches are contained in the specified subsystem; any other selection criteria
apply to the branch’s endpoint buses.
Any branch where the ratings are all zero is not checked for overloading. Any branch where current
loading exceeds the designated percentage of at least one non-zero rating generates an alarm. The
loading is calculated at each end of the line and the number of the bus at the end of the branch with
the higher loading is followed by an asterisk (  ). The branch loading, rating and percentage load-
ings are tabulated for each rating set.
For three-winding transformers, each winding is checked and reported separately. Only those wind-
ings connected to buses in the specified subsystem are processed. For each winding reported, the
bus to which the winding is connected is shown as the from bus, and the winding number and trans-
former name are listed as the to bus.
Activity RAT3 may be terminated with the AB interrupt control code.
The output report of activity RAT3 lists branches in single entry list format ordered by from bus (refer
to Branch Data) and grouped as described in Section 4.9 Subsystem Reporting.
Figure 11-14 shows a subset of the report for the savnw.sav power flow case. It demonstrates the
manner in which the branches are listed in bus number, circuit and Area sequence.
The report shows only one branch is overloaded. It is the 230/18 kV transformer branch from Bus
205 to Bus 206 the loading of which is 108.5% of the RATE A level.
Note that a value for RATE C has been entered with a fictitious value of 1.0 MVA for most branches.
The table therefore shows very high percentage loadings for that RATE.
11-62
Program Operation Manual Producing a Branch Overload Checking Report
11-63
Producing a Branch Overload Checking Report Program Operation Manual
11-64
Program Operation Manual Producing a Transformer Overload Checking Report
Figure 11-14. Report for Branch Loadings, All Ratings
®
PSS E GUI Users Guide, Section 16.4.4, Branch Overloads
Section 13.4.4, Branch Overloads
11.17 Producing a Transformer Overload Checking Report

Activity OLTR
Run Activity OLTR - GUI

OPTION: Branches Tab; List overloaded only transformers
Run Line Mode Activity OLTR - CLI
ACTIVITY?
>>OLTR
AB
The transformer overload checking activity OLTR checks transformer branch loadings against
designated branch ratings. Loadings are calculated as either current loadings or MVA loadings,
according to the transformer percent loading units program option setting. Refer to Section Saved
Case Specific Option Settings and activity OPTN.

where:
Ebase Is the transformer winding voltage base in volts.

ratings.
The user specifies the percentage loading threshold. Any checked transformer branch where
loading, including magnetizing admittance, exceeds the specified percentage of rating is reported.
The default limit is 100%.
The user specifies the rating; the default rating set is established by the program option setting
(refer to Section 3.3.3 Program Run-Time Option Settings and activity OPTN). The report is gener-
ated with branches having a non-zero value for the specified rating being checked.
11-65
Producing a Transformer Overload Checking Report Program Operation Manual
The user specifies the subsystem of the working case for which the overload check is to be made
(refer to Section 4.8 Subsystem Selection). Output is generated with all transformer branches
having at least one endpoint bus in the specified subsystem being checked.
If an owner subsystem has been specified, branch ownership rather than bus ownership is used in
determining which transformers are contained in the specified subsystem; any other selection
criteria apply to the transformer’s endpoint buses.
It should be noted, however, that when subsystem selection is by OWNER, it is branch ownership
rather than bus ownership which is used in determining which transformer branches are contained
in the specified subsystem. Any other selection criteria apply to the transformer’s endpoint buses.
Any transformer where the corresponding rating is zero is not checked for overloading. Any trans-
former branch where loading exceeds the designated percentage of rating generates an alarm. The
loading is calculated at each end of the line and the number of the bus at which the loading is higher
is followed by an asterisk (  ). The branch loading, rating, and percentage loading are tabulated.
Any transformer where the corresponding rating is zero is not checked for overloading. Any trans-
former where loading exceeds the designated percentage of rating generates an alarm. The loading
is calculated at each end of the transformer, and the number of the bus at the end of the transformer
with the higher loading is followed by an asterisk (  ). The transformer loading, rating, and
percentage loading are tabulated.
The output report of activity OLTR lists transformers in single entry list format ordered by from bus
(refer to Branch Data) and grouped as described in Section 4.9 Subsystem Reporting.
Thus, activity OLTR functions in exactly the same manner as does activity RATE, except that non-
transformer branches are omitted from the overload checking.
Activity OLTR may be terminated with the AB interrupt control code.
Figure 11-15 shows a sample output from the savnw.sav case with the transformer overload check
performed on the basis of 80% of RATE A.
The overload report lists transformer branches in single entry list format ordered by from bus. Trans-
formers are also listed by AREA so that all transformers overloaded in AREA 1 are listed first
followed by transformers in AREA 2 and AREA 5. Transformers would also be listed by circuit
number if appropriate. This report shows overloads only in AREAS 2 and 5.
In the table, the right most column shows the percentage loading on 100% of the RATE A level. Only
one transformer loading exceeds the 100% limit. It is the 230/18 kV transformer branch from Bus
205 to Bus 206.
Two other branches are listed which have loadings less than 100% of RATE A but have loadings
exceeding 80%.
11-66
Program Operation Manual Producing a Transmission Line Overload Checking Report
Figure 11-15. Report on Transformer Overloads Based on 80% of RATE A
®
PSS E GUI Users Guide, Section 16.4.6, Transformer Overloads
Section 13.4.6, Transformer Overloads
11.18 Producing a Transmission Line Overload Checking Report

Activity OLTL
Run Activity OLTL - GUI

OPTION: Branches Tab; List overloaded only non-transformer branches
Run Line Mode Activity OLTL - CLI
ACTIVITY?
>>OLTL
AB
The transmission line overload checking activity OLTL checks non-transformer branch loadings
against designated branch ratings. Loadings are calculated as either current loadings or MVA load-
ings, according to the non-transformer branch percent loading units program option setting. Refer
to Section Saved Case Specific Option Settings and activity OPTN.

where:
Ebase Is the base voltage in volts of the bus to which the terminal of the branch is
connected.
11-67
Producing a Transmission Line Overload Checking Report Program Operation Manual
ratings.
The user specifies the percentage loading threshold. Any checked branch where current loading,
including line charging and line connected shunt components, exceeds the specified percentage of
rating is reported. The default limit is 100%.
(refer to Section 4.8 Subsystem Selection). Output is generated with all non-transformer branches
having at least one endpoint bus in the specified subsystem being checked.
determining which branches are contained in the subsystem; any other selection criteria apply to
the branch’s endpoint buses.
Any non-transformer branch where the corresponding rating is zero is not checked for overloading.
Any non-transformer branch where loading exceeds the designated percentage of rating generates
an alarm. The loading is calculated at each end of the branch, and the number of the bus at the end
of the branch with the higher loading is followed by an asterisk (  ). The branch loading, rating, and
percentage loading are tabulated.
The output report of activity OLTL lists branches in single entry list format ordered by from bus (refer
Thus, activity OLTL functions in exactly the same manner as does activity RATE, except that trans-
former branches are omitted from the overload checking.
Activity OLTL may be terminated with the AB interrupt control code.
Figure 11-16 shows a sample output from the savnw.sav case with the transmission line (non-trans-
former branch) overload check performed on the basis of 75% of RATE A.
The overload report lists branches in single entry list format ordered by from bus. As for Branch and
Transformer overloads, branches are also listed by AREA so that all branches overloaded in AREA
1 are listed first followed by branches in AREA 2 and AREA 5. Branches would also be listed by
circuit number if appropriate. This report shows overloads only in AREA 1.
In the table, the right most column shows the percentage loading on 100% of the RATE A level. It
can be seen that no transmission lines have a loading in excess of 100% of RATE A. Three trans-
mission lines are shown to have loadings in excess of 75% of RATE A. One line from Bus 153 to
Bus 154 has two circuits listed in order of circuit number.
11-68
11-69
Producing a Transmission Line Overload Checking Report Program Operation Manual
Figure 11-16. Report on Transmission Line Overloads
11-70
®
PSS E GUI Users Guide, Section 16.4.5, Transmission Line Overloads
Section 13.4.5, Transmission Line Overloads
11-71
Producing a Branch Current Ratings Report Program Operation Manual
11.19 Producing a Branch Current Ratings Report

Activity RATE
Run Activity RATE - GUI

OPTION: Branches Tab; List overloaded both transformer and non-transformer branches
Run Line Mode Activity RATE - CLI
ACTIVITY?
>>RATE
AB
The branch overload checking activity RATE checks ac branch loadings against designated branch
ratings. The user can select from several types of branch loading checks:
• Branch overloads, based on current loading, for transformer and non-transformer

branches
• Transformer overloads, based on MVA loading
• Transmission line (non-transformer branches) overloads based on current loading
• Branch current ratings (A, B and C) and percentage loading at each rating
For overload checking purposes, the user can select which of the three ratings is to be used, with
the default being the rating set established in the program options (activity OPTN). The default
percentage of rating limit is 100%. This limit can be adjusted up or down in 5% steps.
For non-transformer branches, loadings are calculated as either current loadings or MVA loadings,
according to the non-transformer branch percent loading units program option setting. Similarly, for
transformer branches, loadings are calculated as either current loadings or MVA loadings,
according to the transformer percent loading units program option setting. Refer to Section 3.3.3
Program Run-Time Option Settings, activity OPTN, and Case Identification Data.

where:
Ebase Is the base voltage in volts of the bus to which the terminal of the branch is
connected.
ratings.
11-72
Program Operation Manual Producing a Branch Current Ratings Report
Any checked branch where current loading, including line charging, line connected shunt, and
transformer magnetizing admittance components, exceeds the specified percentage of rating is
reported. The default line loading limit is 100%.
(refer to Section 4.8 Subsystem Selection). Output is generated with all branches having at least
one endpoint bus in the specified subsystem being checked.
determining which branches are contained in the subsystem; any other selection criteria apply to
the branch’s endpoint buses.
Any branch where the corresponding rating is zero is not checked for overloading. Any branch
where loading exceeds the designated percentage of rating generates an alarm. The loading is
calculated at each end of the branch, and the number of the bus at the end of the branch with the
higher loading is followed by an asterisk (  ). The branch loading, rating, and percentage loading
are tabulated.
Activity RATE may be terminated with the AB interrupt control code.
The output report of activity RATE lists branches in single entry list format ordered by from bus (refer
Figure 11-17 shows a sample output from the savnw.sav case with a branch overload check
performed on the basis of 80% of RATE A
The overload report lists branches in single entry list format ordered by from bus. It can be seen that
branches are also listed by AREA so that all branches overloaded in AREA 1 are listed first followed
by branches in AREA 2 and AREA 5. Branches would also be listed by circuit number if appropriate.
In the table, the right most column shows the percentage loading on 100% of the RATE A level. Only
one branch loading exceeds the 100% limit; the 230/18 kV transformer branch from Bus 205 to Bus
206. Four other branches are listed which have loadings less than 100% of RATE A but have load-
ings exceeding 80%.
11-73
Producing Out-of-Limits Bus Voltage Reports Program Operation Manual
Figure 11-17. Output Format for Branch Overloads Based on 80% of Rate A
®
PSS E GUI Users Guide, Section 16.4.7, Branch Current Ratings
Section 13.4.7, Branch Current Ratings
11.20 Producing Out-of-Limits Bus Voltage Reports

Two API routines are available for reporting bus voltage violations:
1. Activity VCHK checks bus voltages against a user-specified bus voltage magnitude range.
The same range is applied at all buses that are to be checked.
2. Activity VLIMS checks bus voltages against either normal or emergency voltage limits. Each
bus has its own limits.
11.20.1 Activity VCHK

Activity VCHK
Run Activity VCHK - GUI

Out-of-limit bus voltage Tab
Run Line Mode Activity VCHK - CLI
ACTIVITY?
>>VCHK
AB
The voltage checking activity VCHK tabulates those buses where voltage magnitude is outside of
a specified range.
11-74
Program Operation Manual Producing Out-of-Limits Bus Voltage Reports
The VCHK API routine includes the following among its inputs:
• A designation of the voltage band to be used. The default settings result in a tabulation
of buses where voltage is above 1.05 pu or below 0.95 pu.
The user specifies either that the entire working case is to be processed, or that voltage violations
of buses in a designated bus subsystem are to be tabulated.
The report of activity VCHK is directed to the Report device.
Activity VCHK produces a listing of those buses where voltage magnitude is greater than VMAX,
followed by a listing of buses where voltage is less than VMIN. Both listings are in ascending numer-
ical (using the numbers output option) or alphabetical (using the names output option) bus order;
refer to Section 3.3.3 Program Run-Time Option Settings and activity OPTN.
The star point buses of three-winding transformers are neither checked nor reported by activity
VCHK.
Activity VCHK may be terminated with the AB interrupt control code.
Figure 11-18 shows the report generated for the savnw.sav case using a voltage range from 0.97
pu to 1.01 pu. It can be seen that the bus base voltage is listed together with the actual bus voltages
in pu and kV. There are 13 buses with voltages greater than 1.01 pu and 5 buses with voltages less
than 0.97 pu.
11-75
Producing Out-of-Limits Bus Voltage Reports Program Operation Manual
Figure 11-18. Report for Voltages Out-of-limit
11-76
Program Operation Manual Producing Out-of-Limits Bus Voltage Reports
11.20.2 Activity VLIMS

Activity VLIMS
Run Activity VLIMS - GUI

Out-of-limit bus voltage Tab
Run Line Mode Activity VLIMS - CLI
ACTIVITY?
>>VLIMS
AB
The voltage checking activity VLIMS tabulates those buses where voltage magnitude is outside of
a their normal or emergency voltage limit range.
The VLIMS API routine includes the following among its inputs:
• A designation of the voltage band to be used.
- Normal bus voltage limits
- Emergency bus voltage limits
• A voltage limit threshold that may be used to modify the desitnated voltage limit band.
The threshold must be in the range -0.05 through 0.05.
- 0.0 to report voltages above the upper limit or below the lower limit
- Greater than 0.0 to report voltages beyond, or within the threshold of, a limit
- Less than 0.0 to report voltages outside of a limit by more than the magnitude of
the threshold
The user specifies either that the entire working case is to be processed, or that voltage violations
of buses in a designated bus subsystem are to be tabulated.
The report of activity VLIMS is directed to the Report device.
When checking a bus voltage against the bus’ high voltage limit, the appropriate upper limit (i.e.,
normal or emergency) is modified by subrtacting the specified voltage limit threshold from it. Activity
VLIMS produces a listing of those buses where voltage magnitude is greater than the bus’ modified
limit. The high limit violations report is followed by a listing of buses where voltage is less than a
modified lower limit; the modified lower limit is the appropriate lower limit (i.e., normal or emer-
gency), modified by adding the specified voltage limit threshold to it.
Both listings are in ascending numerical (using the numbers output option) or alphabetical (using
the names output option) bus order; refer to Section 3.3.3 Program Run-Time Option Settings and
11-77
Producing a Machine Reactive Capability Report Program Operation Manual
activity OPTN.
For each bus reported, its bus number and extended bus name are listed, along with its voltage
magnitude and the appropriate limit, both in per unit. The bus voltage limits that are tabulated are
the unmodified limits (i.e., they are not modified by the voltage limit).
The star point buses of three-winding transformers are neither checked nor reported by activity
VLIMS.
Activity VLIMS may be terminated with the AB interrupt control code.
®
PSS E GUI Users Guide, Section 16.4.10, Out-of-limit Bus Voltage
Section 13.4.10, Out-of-Limits Bus Voltage
11.21 Producing a Machine Reactive Capability Report

Activity GCAP
Run Activity GCAP - GUI

Reactive capability Tab
Run Line Mode Activity GCAP - CLI
ACTIVITY?
>>GCAP
AB
The machine capability curve checking activity GCAP reads a data file containing capability curve
data and prints a report of machine loading and limit data. Optionally, machine reactive power limits
in the working case may be updated.
11.21.1 Machine Capability Curve Data File Contents

Any machine to be checked must have its capability curve specified in a Machine Capability Curve
Data File. Each data record in this file has the following format:
I, ID, P1, QT1, QB1, P2, QT2, QB2, ... P20, QT20, QB20
11-78
Program Operation Manual Producing a Machine Reactive Capability Report
where:
is allowed.
ID One- or two character machine identifier used to distinguish among multiple
Pi Generator active power output along the MW axis of the machine’s capability curve,
entered in MW; no default allowed.
QTi Maximum (i.e., overexcited) reactive power limit at Pi MW, entered in Mvar.
QTi = 0.0 by default.
QBi Minimum (i.e., underexcited) reactive power limit at Pi MW, entered in Mvar.
QBi = 0.0 by default.
Up to 20 sets of points on the capability curve may be entered. When the machine is a generator,
the Pi values must be in ascending order with P1 greater than or equal to zero. When the machine
is a motor, the Pi values must be in descending order with P1 less than or equal to zero.
If P1 is non-zero, an additional point is assumed at P = 0.0 with its QT and QB set equal to QT1 and
QB1, respectively.
Data input is terminated with a record specifying a bus number of zero.
In the PSS®E EXAMPLE directory, there is an example capability curve established for the
machines in the savnw.sav power flow case. The data file is savnw.gcp, and the contents of the file
are listed in Figure 11-19. A generic plot of the reactive limits for the machine at bus 206 is shown.
11-79
Figure 11-19. Capability Curve Example for savnw.sav Case
11.21.2 Operation of Activity GCAP

The user enters the name of the appropriate Machine Capability Curve Data File containing data
records of the form defined in Machine Capability Curve Data File Contents. If the file does not exist
or some other file system error occurs, an appropriate message is printed. Refer to Section 2.4.1
File Usage for the file specification conventions used by activity GCAP.
When the input file is successfully opened, activity GCAP processes the data records. If any data
inconsistencies are detected during data input, they generate an alarm and the corresponding
record is ignored. Activity GCAP processes only the valid data records.
When the owner option is specified, each machine wholly or partly owned by any of the owners
specified and for which a data record was successfully read is processed (refer to Branch Data).
The owner assignment of the bus to which the machine is connected is not considered.
The user may update the reactive power limits of all machines reported by activity GCAP.
11-80
The output listing of activity GCAP may be terminated by entering the AB interrupt control code.
The output report of activity GCAP lists the following quantities:
1. Machine active and reactive power loading. If this value is beyond the limits shown in (2), it
is followed by an asterisk (  ).
2. The reactive power limit settings on the capability curve corresponding to the machine’s
active power loading.
3. The maximum active power loading from the capability curve (i.e., Pi from the last point
entered for this machine).
4. The active and reactive power limits as contained in the working case.
Figure 11-20 shows the report generated for the savnw.sav Saved Case. It clearly indicates that the
machine at bus 206 has a reactive power output of 600 MW and a real power output of 800 MW.
Based on its capability curve, the reactive power limit should be 160 Mvar based on the real power
output of 800 MW. This is much less than the assumed limit of 600 Mvar. Examination of the capa-
bility curve plotted in Figure 11-19 confirms a reactive power limit of 160 Mvar with 800 MW
generated.
11-81
11-82
Figure 11-20. Report Output for Reactive Power Checking with Capability Curve
11-83
Producing a Generator Bus Limits Report Program Operation Manual

If the option to update the reactive power limits in the working case was enabled, this updating takes
place after all reporting, just prior to leaving activity GCAP. If activity GCAP is terminated by the
user, this updating takes place for all machines that were reported.
Updating reactive power limits by activity GCAP is not reversible. It is recommended that, prior to
executing activity GCAP with the option to update reactive power limits enabled, the working case
be preserved in a Saved Case File with activity SAVE, and that the new reactive power limit data
be examined before permanently overwriting the original data.
PSS®E GUI Users Guide, Section 16.4.1, Machine Reactive Capability
Section 13.4.1, Machine Reactive Capability
11.22 Producing a Generator Bus Limits Report

Activity GENS
Run Activity GENS - GUI

Generator bus Tab
Run Line Mode Activity GENS - CLI
ACTIVITY?
>>GENS
AB
The generating plant summary activity GENS tabulates the loading and voltage conditions at gener-
ator buses. The user must choose among the following report options:
• VAR limited plants with unequal VAR limits: only plants at a reactive power limit and
where var limits are unequal
• All VAR limited plants: all var-limited plants
• On-line plants: all in-service generator buses
• All plants: both in-service and out-of-service plants.
The user may also specify that voltage output is printed in alternate units rather than in the default
units (refer to Section 3.3.3 Program Run-Time Option Settings and activity OPTN).
11-84
Program Operation Manual Producing a Generator Bus Limits Report
The output listing of activity GENS may be terminated by entering the AB interrupt control code.
The report of activity GENS includes the bus number, name, base voltage, and type code, along
with the number of machines modeled at the plant where status flags are 1, the number of machines
where status flags are zero, the total plant power outputs and reactive power limits, and scheduled
and actual voltages.
If a plant regulates the voltage of a remote bus, the remote bus identifiers are printed and the actual
voltage printed is that at the remote bus; if a plant regulates its own terminal voltage, the remote
bus fields are blank. Total plant MBASE of machines at the bus where status flags are 1, along with
the numbers of the zone and area in which the bus is located, are also printed. Any plant that is
either a system or area swing is identified with an appropriate tag at the end of the output line.
As the last line of each report, subsystem totals of plant power outputs, var limits, and MBASE are
tabulated.
Figure 11-21 shows a report for All plants from the savnw.sav Saved Case.
11-85
From the report it can be seen that:
• Generators at buses 206, 211 and 3018 are regulating voltage at remote buses.
• Generator at buses 206 and 3018 are failing to meet scheduled voltages (VSCHED) at
their remote buses. Their actual voltages (VACTUAL) at the remote buses are below
scheduled because the machines have reached maximum reactive power limits. Under
the TYP column, the machines at buses 206 and 3018 are indicated to be -2; the neg-
ative sign indicates that the machines are at a reactive power limit.
• The system swing bus is 3011 while the swing buses for Areas 1 and 2 are Buses 101
and 206 respectively.
11-86
11-87
Figure 11-21. Generator Bus Report
11-88
®
PSS E GUI Users Guide, Section 16.4.2, Generator Bus Limits
Section 13.4.2, Generator Bus Limits
11-89
Producing a Machine Terminal Limits Report Program Operation Manual
11.23 Producing a Machine Terminal Limits Report

Activity GEOL
Run Activity GEOL - GUI

Machine terminal Tab
Run Line Mode Activity GEOL - CLI
ACTIVITY?
>>GEOL
AB
The machine terminal conditions summary activity GEOL tabulates the loading and voltage condi-
tions at the generator terminals of in-service machines at Type 2 and 3 buses in the working case.
The user specifies whether to restrict the output report to overloaded machines (refer to
Section 11.23.1 Application Notes) or to report conditions for all in-service machines (i.e., at buses
with a type code of plus or minus 2, or 3) are listed.)
If an owner subsystem is specified, each machine wholly or partly owned by any of the owners spec-
ified is processed (refer to Non-Transformer Branch Data). The owner assignment of the bus to
which the machine is connected is not considered.
The output listing of activity GEOL may be terminated by entering the AB interrupt control code.
Data presented includes the bus number, name, and base voltage, along with the machine identifier
and the machine terminal conditions of power output, voltage, current, and power factor. Reactive
power limits and the generator base, MBASE, are also printed, along with the step-up transformer
impedance and off-nominal turns ratio if the transformer is represented as part of the generator
model. The numbers of zone and area in which the bus is located are also printed, and machines
at any plant which is either a system or area swing are identified with an appropriate tag at the end
of the output line. Generators where loading is outside the assumed capability curve have an
asterisk (  ) printed following their current loading.
As the last line of each report, subsystem totals of machine power outputs, reactive power limits,
and MBASE are tabulated.
Figure 11-22 shows the Machine Terminal report selected for All on-line machines in the savnw.sav
power flow case.
It can be seen that machines at buses 206 and 3018 are overloaded based on the calculations
conforming to the assumed capability curve in Figure 11-23.
11-90
Program Operation Manual Producing a Machine Terminal Limits Report
It should be noted that the terminal voltages for those two machines, and the machine at bus 211,
are higher than their scheduled voltages (VSCHED) because these machines are attempting to
control voltage at remote buses rather than at the machine terminals. The Generator Bus report
shows the scheduled voltages and the remote buses (see Figure 11-21).
11-91
11-92
Program Operation Manual Producing a Machine Terminal Limits Report
Figure 11-22. Report Tabulation for Machine Terminal Conditions in savnw.sav File
11-93

Activity GEOL calculates and reports the generator terminal conditions for in-service machines.
When the machine step-up transformer is represented explicitly as a network branch, and hence
the Type 2 bus is the generator terminal bus, activity GEOL simply uses the boundary conditions at
the bus in generating the report (refer to Section 12.2.3 Generator Step-Up Transformers and
Figure 12-4b).
When the step-up transformer is modeled with the generator data (i.e., XTRAN is non-zero), the
generator bus is the high side bus (see Figure 12-4c). In this case, activity GEOL calculates back
through the step-up transformer impedance to determine the conditions that exist at the generator
terminals.
In performing its overload check, activity GEOL assumes a machine capability curve as shown in
Figure 11-23. The radius of the semicircle in the upper half plane, centered at the origin, is taken as:
MBASE
Et
When XTRAN is non-zero, the reactive power limits are modified to reflect these limits at the termi-
nals by taking into account losses through the step-up transformer.
P
------
2
Et
1.6MBASE
Q
------
2
E
t
QMIN -0.3MBASE 0.55MBASE QMAX
Figure 11-23. Assumed Capability Curve of Activity GEOL
When XTRAN is nonzero, the reactive power limits are modified to reflect these limits at the termi-
nals by taking into account losses through the step-up transformer.
The assumed operating region in the capability curve of Figure 11-23 is bounded as follows:
1. On the bottom, by the Q axis.
2. On the top, by the semicircle in the upper half plane.
3. On the left, by the straight line connecting the point QMIN on the Q axis and the point on the
upper half plane circle corresponding to an abscissa of -0.3MBASE. When QMIN is greater
11-94
Program Operation Manual Producing a Regulated Bus Report
than -0.3MBASE, this bound is a line parallel to the P axis through the point QMIN on the
Q axis.
4. On the right, by a circle of radius 1.6MBASE, with center at (0,Qmin) and passing through
the point QMAX on the Q axis and the point on the upper half plane circle corresponding to
an abscissa of 0.55MBASE. When QMAX is less than 0.55MBASE, this bound is a line
parallel to the P axis through the point QMAX on the Q axis.
Any machine where the operating point is such that the quantity:
Pgen + jQgen
(Et )2
is outside this region is considered overloaded. Any machine absorbing active power is checked as
if its active power is in the upper half plane.
For determining overloaded conditions, the value specified as MBASE for each machine must be
the actual MVA base of the generator. The overload check is invalid for any machine for which the
base is something other than this quantity, even if the base conversion has properly been taken into
account in specifying ZSORCE and XTRAN.
When the report is restricted to overloaded machines, only those machines considered overloaded
under the criteria described above are reported. When all on-line machines in the case (or in the
specified subsystem thereof) are being reported, those for which loading is outside the assumed
capability curve have an asterisk (  ) printed following their current loading.
®
PSS E GUI Users Guide, Section 16.4.3, Machine Terminal Limits
Section 13.4.3, Machine Terminal Limits
11.24 Producing a Regulated Bus Report

Activity REGB
Run Activity REGB - GUI

Regulated buses Tab
Run Line Mode Activity REGB - CLI
ACTIVITY?
>>REGB
>>
AB
11-95
Producing a Regulated Bus Report Program Operation Manual
In large databases it is important to have the ability to easily identify which bus voltages are being
regulated and which equipment is controlling the regulation. This helps to avoid situations in which
there are potential regulation conflicts.
The regulated bus reporting activity REGB tabulates those buses where voltages are controlled by
generation, switched shunts, voltage controlling transformers, FACTS devices, and/or VSC dc line
converters. Data presented includes the bus number, name, and base voltage of each regulated
bus along with its present voltage magnitude. For each controlling equipment item, the desired
voltage setpoint or voltage band, as appropriate, is listed along with any deviation between actual
and scheduled voltages.
system Selection) by bus subsystem, area, zone, owner, or basekV. Output for the voltage
controlled buses contained in the specified subsystem is produced with buses ordered as described
in Section 4.9 Subsystem Reporting.
Only in-service voltage controlled buses (i.e., buses where type codes are less than 4) are reported
by activity REGB. The following lists the conditions under which the various voltage controlling
equipment items are reported:
Generation Bus type code is 2 or 3, and at least one in-service machine is present.
Switched shunt Bus type code is less than 4 and the control mode is 1 or 2.
Transformer Branch is in-service and its adjustment control mode is set to +1.
Control mode is non-zero for sending bus end; control mode is 1, 5 or 7 for terminal
FACTS device
bus end.
VSC dc line’s control mode (MDC) is 1, the VSC converter’s ac control mode (MODE)
VSC dc converter
is 1, and the VSC converter’s dc control code (TYPE) is not zero.
For any voltage controlling transformer where load drop compensation impedance (refer to Trans-
former Data) is non-zero, the controlled bus voltage (or, equivalently, the voltage limits) are
compensated as described in Voltage Control. Activity REGB always displays voltage at the
controlled bus. Therefore, limits printed for such transformers are the compensated limits and the
lower limit is preceded by an asterisk (  ). Note that the calculation of these limits requires trans-
former current; hence, they are valid only if the working case represents a solved system condition.
The output listing of activity REGB may be terminated by entering the AB interrupt control code.
A Regulated Bus report from the savnw.sav power flow case is shown in Figure 11-24.
The report shows the following:
• Regulated buses 101, 102 and 3011 are generator terminal buses.
• Bus 154 is a type 1 bus where voltage is regulated by the transformer in the branch
from bus 152 to bus 153. Furthermore the voltage control range of the transformer’s
tap changer is 0.98 to 1.0 pu but the controlled bus voltage is only 0.93892 pu. Conse-
quently, a violation (or error) of -0.04108 pu is indicated.
• Bus 201 is a type 1 bus where voltage is regulated by the remote generator at bus 211.
The scheduled voltage of 1.04 pu has been met.
• Bus 205 is a type 1 bus where voltage is regulated by the remote generator at bus 206
and the transformer tap changer in the transformer branch from the 500 kV bus 204 to
the 230 kV bus 205. The generator is scheduled to control voltage at bus 205 to a level
11-96
of 0.98 pu. The transformer tap changer has a voltage range between 0.98 pu and 1.0
pu and is controlling bus 205. The actual voltage on bus 205 is only 0.949 pu. Conse-
quently, there is a violation indicated of 0.03098 pu.
11-97
Producing a Regulated Bus Report Program Operation Manual
11-98
Figure 11-24. Regulated Bus Report from the Savnw.sav Power Flow Case
11-99
Producing a Controlling Transformer Report Program Operation Manual
®
PSS E GUI Users Guide, Section 16.4.8, Voltage Controlled Buses
Section 13.4.8, Voltage-Controlled Buses
11.25 Producing a Controlling Transformer Report

Activity TLST
Run Activity TLST - GUI

Controlling Transformer Tab
Run Line Mode Activity TLST - CLI
ACTIVITY?
>>TLST
AB
The controlling transformer summary activity TLST tabulates those transformers in the working
case for which off-nominal turns ratio or phase shift angle may be adjusted by the power flow solu-
tion activities.
The user may choose to list all adjustable transformers or restrict the report to those where the
controlled quantity is outside of its specified band. The user may also specify that voltages and
desired voltage bands of voltage controlling transformers are printed in alternate units for voltage
output rather than in the default units (refer to Section 3.3.3 Program Run-Time Option Settings and
activity OPTN).
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. Output is generated, with
all controlling transformers having at least one endpoint bus in the specified subsystem being
processed.
determining which transformers are contained in the specified subsystem; any other selection
criteria apply to the transformer’s endpoint buses.
The output listing of activity TLST may be terminated by entering the AB interrupt control code.
Two-winding transformers are listed in the report with their Winding 1 side bus first and with their
Winding 2 side bus as the to bus. Three-winding transformer windings are listed in the report with
their controlling winding side bus first and with their transformer name and winding number as the
to bus; a three-winding transformer winding is processed if it is an adjustable winding and if the bus
to which it is connected is in the specified subsystem.
11-100
Program Operation Manual Producing a Controlling Transformer Report
Transformers are ordered in ascending numerical (using the numbers output option) or alphabetical
(using the names option) order by controlling winding side bus, and, for each such bus, in ascending
order by to bus field and circuit identifier. When subsystems are specified by area, zone, and/or
owner, the output of activity TLST is grouped as described in Section 4.9 Subsystem Reporting.
The output report for each subsystem grouping is printed in up to four sections.
1. Those transformer windings where tap ratio may be adjusted to control the voltage at a
designated controlled bus are printed. The present controlled voltage and the desired
voltage band are listed, along with the controlled bus, the tap ratio, the ratio limits, and the
number of tap positions. When the load drop compensating impedance is non-zero, the
compensated voltage is printed preceded by an asterisk (  ) (refer to Transformer Data and
Voltage Control); otherwise, the voltage at the controlled bus is reported.
2. A list of any transformer winding where phase shift angle may be adjusted to control the
active power flow through itself. The data tabulated for these includes the present active
power flow through the phase shifter and the desired flow band, the phase shift angle, the
angle limits, the transformer control mode, and the winding connection angle.
3. A list of any transformer winding where ratio may be adjusted to control the reactive power
flow through itself. The present reactive power flow and the desired flow band, the present
tap ratio and its limits, and the number of tap positions are tabulated.
4. A list of those two-winding transformers where ratio may be adjusted to control the firing
angle, extinction angle, or voltage of a dc line. The dc line name, the type of quantity
controlled, its present value and desired band, the present tap ratio and its limits, and the
tap step are tabulated.
Any controlled quantity outside of its desired band is followed by the tag HI or LO as appropriate.
Similarly, if the ratio or phase shift angle of a transformer is at or beyond one of its limits, the appro-
priate identifier is printed.
See Figure 11-25 for an example of a Controlling Transformers report from the savnw.sav power
flow case. Controlled buses at 154 and 205 show voltages below their transformers’ control range
(indicated by LO) and the Phase Shifting transformer controlling power flow shows a flow level
above its control range (indicated by HI).
11-101
Producing a Controlling Transformer Report Program Operation Manual
11-102
PSS®E 34.2
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSSE TUE, AUG 11 2009 11:46

PSS(R)E PROGRAM APPLICATION GUIDE EXAMPLE TRANSFORMER
BASE CASE INCLUDING SEQUENCE DATA SUMMARY
** TRANSFORMERS CONTROLLING VOLTAGE **
X--- ADJUSTABLE SIDE ---X X--------- TO ----------X X--- CONTROLLED BUS ----X
BUS# X-- NAME --X BASKV BUS# X-- NAME --X BASKV CKT VOLT MAX V MIN V BUS# X-- NAME --X BASKV RATIO MAX RAT MIN RAT NTAPOS
152 MID500 500.00 153 MID230 230.00 1 0.93892LO 1.00000 0.98000 154 DOWNTN 230.00 1.01000 1.05000 0.95000 33
204 SUB500 500.00 205 SUB230 230.00 1 0.94902LO 1.00000 0.98000 205 SUB230 230.00 1.00000 1.05000 0.95000 33
-------------------------------------------------------------------------------
11-103
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSSE TUE, AUG 11 2009 11:46
PSS(R)E PROGRAM APPLICATION GUIDE EXAMPLE TRANSFORMER
BASE CASE INCLUDING SEQUENCE DATA SUMMARY
** PHASE SHIFTERS CONTROLLING MW FLOW **
X--- ADJUSTABLE SIDE ---X X--------- TO ----------X MAXIMUM MINIMUM MAXIMUM MINIMUM CONTROL WINDING
BUS# X-- NAME --X BASKV BUS# X-- NAME --X BASKV CKT MW MW MW ANGLE ANGLE ANGLE MODE CNX ANG
202 EAST500 500.00 203 EAST230 230.00 1 592.4HI 555.0 545.0 0.00 30.00 -30.00 3 0.00
Figure 11-25. Controlling Transformers Report for savnw.sav Power Flow Case
Power Flow Reports
Producing a Controlling Transformer Report
Comparing Power Flow Case Totals Program Operation Manual
®
PSS E GUI Users Guide, Section 16.4.9, Controlling Transformers
Section 13.4.9, Controlling Transformers
11.26 Comparing Power Flow Case Totals

Activity CMPR
Run Activity CMPR - GUI

File > Compare
[Compare] Case Totals tab
[Select Powerflow Comparison Options]
Run Line Mode Activity CMPR - CLI
ACTIVITY?
>>CMPR
AB
The case comparison activity CMPR compares the total system values contained in the working
case with those of a designated Saved Case. Either system totals, area totals, zone totals, or owner
totals may be compared. If the Substitute working case after comparison option is selected, then
the currently open case will be replaced by the comparison case after the comparison has been
completed.
One of the two cases to be compared must be present in working memory. When initiated, activity
CMPR requires the user to designate the Saved Case to be compared against the working case.
Refer to Section 2.4.1 File Usage for the file specification conventions used by activity CMPR. Any
errors encountered in accessing the designated Saved Case File are handled as in activity CASE.
The user must specify which of the two cases is to remain as the PSS®E working case.
system Selection) by bus subsystem, area, zone, owner, or basekV. When comparing cases by
area or zone, the user may specify a difference threshold in either engineering units or percent
(default = 0) for the following comparisons:
• generation
• load
• losses
• mismatch
• interchange
The selection of interchange is disabled when totals by owner or the entire case are being
compared. The report for the designated category is printed in ascending area, zone, or owner
number order, for those areas, zones, or owners selected for which difference meets or exceeds
11-104
Program Operation Manual Comparing Power Flow Case Totals
the designated threshold. The report for any category may be terminated by entering the AB inter-
rupt control code, and a new category may then be selected.
Generally, generation, load, loss, and mismatch subsystem totals are accumulated as shown in
Table 11-3 Subsystem Accumulations in Activity CMPR.
11-105
Comparing Power Flow Case Totals Program Operation Manual
Table 11-3. Subsystem Accumulations in Activity CMPR
Area Totals Zone Totals Owner Totals

Generation Bus area Bus zone Machine owners
Load Load area Load zone Load owner
Branch nonmetered Branch nonmetered
Losses Branch owners
end bus area end bus zone
Mismatch Bus area Bus zone Bus owner
Option Settings and activity OPTN), generation and mismatch at multi-section line dummy buses
are assigned to the area, zone, or owner of the multi-section line nonmetered end bus. When totals
by area or zone are being calculated, losses on each multi-section line member are assigned to the
area or zone of the multi-section line nonmetered end bus; for totals by owner, losses are always
assigned to the branch owners.
In calculating area or zone interchange when the multi-section line reporting option is enabled (refer
to Section 3.3.3 Program Run-Time Option Settings and activity OPTN), the area and zone assign-
ments of the dummy buses of each multi-section line grouping and the metered ends of the
individual members of each multi-section line grouping are ignored. Instead, net interchange is
evaluated on the basis of the metered end designated for each multi-section line grouping which is
a tie branch (i.e., its endpoint buses are located in different areas or zones, as appropriate). When
the multi-section line reporting option is disabled, the area or zone assignments of dummy buses
as well as the metered end of each member of a multi-section line grouping are recognized; the
multi-section line grouping definitions and their metered end information are ignored.
In calculating area or zone interchange, a three-winding transformer is considered to be a tie line

when the three buses which is connects are not in the same area or zone, as appropriate. Tie flows
are derived from the flows into the transformer at its two metered ends. In calculating area or zone
interchange, only tie line flows are considered, even if the interchange definition flag is set to its tie
lines plus loads setting (refer to Area Interchange Control).
A typical report produced by the comparison is shown in Figure 11-26. The report compares the
total generation, load, losses and solution mismatches. Differences in the totals for each case as
also presented (under the DELTA columns).
Figure 11-26. Result of the Compare Case Totals
®
PSS E GUI Users Guide, Section 9.1, Comparing Power Flow Case Totals
Section 13.5.1, Power Flow Case Totals
11-106
Program Operation Manual Comparing Power Flow Cases
11.27 Comparing Power Flow Cases

Activity DIFF
Run Activity DIFF - GUI

File > Compare
[Compare] Powerflow Cases tab
[Select Powerflow Comparison Options]
Run Line Mode Activity DIFF - CLI
ACTIVITY?
>>DIFF
AB
The case comparison activity DIFF compares certain parametric data and solution results, as
contained in the working case, with those of a designated Saved Case. Network elements in the
entire case may be subjected to the comparison, or the checks may be restricted to those within a
designated subsystem.
The DIFF API routine includes the following among its initial inputs:
• A designation of the subsystem in which data is to be compared; refer to Section 4.8,

Subsystem Selection.
• The name of a Saved Case File whose data is to be compared to that of the working
case.
• The method to be used for matching up buses in the two cases. To be considered the
same bus, buses must have either:
- the same bus number;
- the same extended bus name; or
- both the same bus number and the same extended bus name.
• The content of the working case at the completion of activity DIFF. The working case
may contain either the case that was present at the time DIFF was initiated, or the des-
ignated Saved Case which was to be compared against the working case may become
the new working case. This is used only if the initialization of activity DIFF fails because
there are no buses to compare.
The DIFF API routine is then called once for each quantity that is to be compared. In these calls,
the following is included among its inputs:
• the type of comparison to be performed.

• for load and rating comparisons, an additional input that further defines the quantities
to be compared.
• for several comparisons, one or more threshold tolerances.
11-107
Comparing Power Flow Cases Program Operation Manual
The DIFF API routine is called one final time to complete the comparision function. In this call, the
following input is specified.
• The content of the working case at the completion of activity DIFF. The working case
may contain either the case that was present at the time DIFF was initiated, or the des-
ignated Saved Case which was compared against the working case may become the
new working case.
In the GUI, the DIFF API routine is accessed from the Powerflow Cases tab of the [Compare] dialog.
In line mode, case comparisons are preformed using activity DIFF.
11.27.1 Operation of Activity DIFF

One of the two cases to be compared must be present in working memory. When initiated, activity
DIFF requires the user to designate the Saved Case to be compared against the working case.
Refer to Section 2.4.1 File Usage for the file specification conventions used by activity DIFF. Any
If buses in the two cases are matched using only their extended bus names, each bus in the spec-
ified subsystem must have a unique extended bus name. Alarms are printed at the Progress device
(refer to Section 4.4 Virtual Output Devices) if there are duplicate extended bus names in the spec-
ified subsystem of either the working case or the designated Saved Case. Any buses that have
generated alarms are treated as being outside of the specified subsystem, and processing
continues using the remaining subsystem buses in the two cases.
A heading page is printed at the selected output device containing the case headings of the working
case and the comparison case.
Activity DIFF constructs a bus comparison list containing buses that exist in both cases with the
same bus number and/or extended bus name, as appropriate, and are in the specified subsystem
in both cases, if subsystem specification was enabled. Star point buses of three-winding trans-
formers are always excluded from the bus comparison list.
Except for star point buses of three winding transformers, any bus from either case that is in the
selected subsystem, but not included in the bus comparison list, generates an alarm. This could
occur, for example, if a bus is contained in the specified subsystem in one case but not in the other.
These messages may be suppressed by entering the AB interrupt control code.
Activity DIFF summarizes the number of buses and branches in the working case and in the
comparison case, the number of buses in the specified subsystem in each case if subsystem spec-
ification was enabled, and the number of buses in the bus comparison list.
It constructs a branch comparison list, which contains all ac branches from either case which
connect buses in the bus comparison list. The number of such branches is then tabulated. Three-
winding transformer windings are included in the branch comparison list if all three buses are
included in the bus comparison list.
Finally, it constructs a multi-section line comparison list, which contains all multi-section line group-
ings from either case for which the endpoint buses are contained in the bus comparison list. The
number of such multi-section line groupings is then tabulated.
The area, zone, and/or owner assignments of buses are used to determine which buses and
branches are to be included in the bus and branch selection lists when subsystem selection by area,
11-108
zone, and/or owner is enabled. The owner assignments of machines and ac branches, and the
area, zone, and owner assignments of loads, are not referenced by activity DIFF.
For several of the data categories that may be compared (see below), the user specifies a threshold
tolerance. If the difference between data items in the two cases is within this tolerance, the item is
omitted from the output report. The user may specify the tolerance threshold in either percent or
engineering units. Comparisons between cases may be specified for the following categories:
Table 11-4. Case Comparison Specifications
Category Additional Specifications

Bus identifiers none
Bus type codes none
Machine status none
Plant MW Comparison Threshold in Percent or Engineering Units
Plant MVAR Comparison Threshold in Percent or Engineering Units
Plant MW or MVAR Comparison Threshold in Percent or Engineering Units
Comparison Threshold in Percent or Engineering Units
Bus load characteristics
• Total nominal load
Loads
• Constant MVA load
• Constant current load
• Constant admittance load
Load status none
Scalable load flags none
Negative sequence loads Comparison Threshold in Percent or Engineering Units
Zero sequence loads Comparison Threshold in Percent or Engineering Units
Fixed bus shunts Comparison Threshold in Percent or Engineering Units
Fixed bus shunt status none
Switched shunts Comparison Threshold in Percent or Engineering Units
Switched shunt status none
Voltage
Voltage threshold
Voltage and angle Voltage threshold
Angle threshold
MBASE & ZSORCE none
MBASE, RPOS and X" none
MBASE, RPOS and X’ none
MBASE, RPOS and Xs none
MBASE & ZNEG none
11-109
Table 11-4. Case Comparison Specifications (Cont.)
Category Additional Specifications

MBASE & ZZERO none
Branch status none
Line R, X, B none
Line shunts none
Ratings to compare:
• All ratings
Line ratings • Rate A
• Rate B
• Rate C
Metered end none
Line lengths none
Ratio threshold
Transformers
Angle threshold
Flows MW or MVAR (from bus) Comparison Threshold in Percent or Engineering Units
Flows MW (from bus) Comparison Threshold in Percent or Engineering Units
Flows MVAR (from bus) Comparison Threshold in Percent or Engineering Units
Flows MW or MVAR (from & to) Comparison Threshold in Percent or Engineering Units
Flows MW (from & to) Comparison Threshold in Percent or Engineering Units
Flows MVAR (from & to) Comparison Threshold in Percent or Engineering Units
Line MW or MVAR losses Comparison Threshold in Percent or Engineering Units
Line MW losses Comparison Threshold in Percent or Engineering Units
Line MVAR losses Comparison Threshold in Percent or Engineering Units
Zero sequence R,X,B none
Zero sequence line shunts none
Connection codes none
Zero sequence mutuals none
Multi-section lines none
Multi-section line metered end none
The selected check is made and exceptions are listed as described in Sections 11.27.2 and 11.27.3.
The report for any category may be terminated by entering the AB interrupt control code, and a new
category may then be selected.
For those categories that allow the user to specify a threshold tolerance, activity DIFF generates an
alarm only for those buses or branches for which the designated data item(s) in the two cases differ
by more than the specified tolerance, whether the difference threshold is specified in percent or in
engineering units. In both cases, the default is zero.
11-110
For categories comparing fault analysis data, this data must be present in both cases.
11.27.2 Bus Related Data Checks

Table 11-5. Case Comparison Specifications, Bus Data Checks
Category Comparison
Bus identifiers, Bus type
codes, Machine status, Plant
MW, Plant MVAR, Plant MW
or MVAR, Loads, Load
status, Scalable load flags, Check various bus related data items of those buses contained in the bus
Negative sequence loads, comparison list. Exceptions are tabulated in ascending bus numerical or
Zero sequence loads, Fixed alphabetical order, according to the bus output option in effect at the time
bus shunts, Fixed bus shunt activity DIFF is selected (refer to Section 3.3.3 Program Run-Time
status, Switched shunts, Option Settings and activity OPTN).
Switched shunt status, For each bus listed, the appropriate data item(s) from both cases are
Voltage, Voltage and angle, printed, along with the bus number and extended bus name as contained
MBASE & ZSORCE, MBASE, in the working case.
RPOS & X", MBASE, RPOS &
X’, MBASE, RPOS & Xs,
MBASE & ZNEG, MBASE &
ZZERO
Plant MW, Plant MVAR, Plant
MW or MVAR, Loads, Negative Differences between the two cases (Saved Case value minus working
sequence loads, Zero case value) are tabulated; differences as a percent of working case values
sequence loads, Fixed bus are also printed.
shunts, Switched shunts
Buses in the bus comparison list with different numbers, names, or base
Bus identifiers
voltages are listed.
Activity DIFF does not report a bus that has a type code of 2 in one case
Bus type codes
and -2 in the other (refer to Bus Data).
If a machine exists in both cases, it is reported only if its actual status, as
implied by the combination of the bus type code and the machine status
flag, is different in the two cases (refer to Section 5.9.1 Equipment
Machine status check Status Changes). When a machine exists in only one of the cases, it is
reported regardless of its implied status. For any machine that is reported,
the bus type code and machine status flag from both of the cases are
listed.
Reoprts those generator buses for which the total plant active power output
differs in the two cases by more than a specified tolerance. If one case
Plant MW contains in-service generation while in the other either no generation is
modeled at the bus or it is out-of-service, the bus is reported only if the in-
service generation exceeds the threshold tolerance.
Similar to Plant MW except that a bus is listed if the reactive gener-
Plant MVAR ator power difference in the two cases exceeds the threshold
tolerance.
Similar to Plant MW, except that a bus is listed if either the active or
Plant MW or MVAR reactive generator power difference in the two cases exceeds the
threshold tolerance.
11-111
Table 11-5. Case Comparison Specifications, Bus Data Checks (Cont.)
Category Comparison
Compares either the total in-service constant MVA, constant current, or
constant admittance load, or the total in-service nominal load, at each bus
in the bus comparison list. If one case contains in-service load while in the
Loads
other either no load elements are modeled at the bus or they are all out-of-
service, the bus is reported only if the in-service load exceeds the
If a load exists in both cases, it is reported only if its actual status, as
implied by the combination of the bus type code and the load status flag, is
Load status different in the two cases. Where a load exists in only one of the cases, it is
reported regardless of its implied status. For any load that is reported, the
bus type code and the load status flag from both cases are listed.
If a load exists in both cases, it is reported only if its scalable load flag is
different in the two cases. Where a load exists in only one of the cases, it is
Scalable load flags
reported. For any load that is reported, the bus type code and the scalable
load flag from both cases are listed.
Compare negative sequence loads (refer to Load Sequence Data),
Negative sequence loads
against a designated threshold tolerance.
Compare zero sequence loads (refer to Load Sequence Data), against a
Zero sequence loads
designated threshold tolerance.
Compares total in-service fixed bus shunts against a designated threshold
tolerance. If one case contains in-service fixed shunt while in the other
Fixed bus shunts either no fixed shunt elements are modeled at the bus or they are all out-of-
service, the bus is reported only if the in-service fixed shunt exceeds the
If a fixed bus shunt exists in both cases, it is reported only if its actual
status, as implied by the combination of the bus type code and the shunt
status flag, is different in the two cases. Where a fixed bus shunt exists in
Fixed bus shunt status
only one of the cases, it is reported regardless of its implied status. For any
fixed bus shunt that is reported, the bus type code and the shunt status flag
from both cases are listed.
If a bus has a switched shunt in only one of the two cases, it is reported if
its magnitude exceeds the tolerance. If the threshold tolerance is specified
Switched shunts
as zero, the bus is reported even if the value of the switched shunt in the
case in which it exists is zero.
If a switched shunt exists in both cases, it is reported only if its actual
status, as implied by the combination of the bus type code and the shunt
status flag, is different in the two cases. Where a switched shunt exists in
Switched shunt status
only one of the cases, it is reported regardless of its implied status. For any
switched shunt that is reported, the bus type code and the shunt status flag
from both cases are listed.
Reports buses where the voltage magnitudes differ by more than a speci-
fied threshold. Differences between the two cases (Saved Case value
Voltage minus working case value) are tabulated. Any bus where the type code is 4
in both cases is skipped. If a bus has a type code of 4 in only one of the two
cases, it is reported.
11-112
Table 11-5. Case Comparison Specifications, Bus Data Checks (Cont.)
Category Comparison
Reports buses for which either the voltage magnitudes differ by more than
a specified tolerance or the phase angle difference exceeds a designated
threshold. Differences between the two cases (Saved Case value minus
Voltage and angle
working case value) are tabulated. Any bus where the type code is 4 in
both cases is skipped. If a bus has a type code of 4 in only one of the two
cases, it is reported.
Compares machines connected to buses in the bus comparison list (refer
to Generator Data and Section 12.2.2 Generator Apparent Imped-
MBASE & ZSORCE ance). If a machine exists in both cases, it is reported if either MBASE or
ZSORCE is different. Where a machine exists in only one of the cases, it is
reported.
Compare machine MBASE, RPOS and subtransient reactance used in
fault analysis work (refer to Generator Sequence Data). This check is
MBASE, RPOS & X"
handled in the same manner as the ZSORCE comparison described
above.
Compare machine MBASE, RPOS and transient reactance used in fault
analysis work (refer to Generator Sequence Data). This check is
MBASE, RPOS & X’
above.
Compare machine MBASE, RPOS and synchronous reactance used in
MBASE, RPOS & Xs
above.
Compare machine MBASE and the negative sequence impedance used in
MBASE & ZNEG
above.
Compare machine MBASE and the zero sequence impedance used in fault
analysis work (refer to Generator Sequence Data). This check is
MBASE & ZZERO
above.
11-113
11.27.3 Branch Related Data Checks

Table 11-6. Case Comparison Specifications, Branch Data Checks
Category Comparison
Branch status, Line R,X,B,
Line shunts, Line ratings,
Metered end, Line lengths,
Transformers, Flows MW or
MVAR (from bus), Flows MW
Check various branch related data items of branches in the branch and
(from bus), Flows MVAR (from
multi-section line comparison lists. Exceptions are tabulated in single entry
bus), Flows MW or MVAR
format (refer to Branch Data), ordered in ascending bus numerical or
(from & to), Flows MW (from &
alphabetical order according to the bus output option in effect at the time
to), Flows MVAR (from & to),
activity DIFF is selected (refer to Section 3.3.3 Program Run-Time
Line MW or MVAR losses, Line
Option Settings). Bus identifiers and ordering from the working case are
MW losses, Line MVAR losses,
used.
Zero sequence, R,X,B, Zero
sequence line shunts, Connec-
tion codes, Zero sequence
mutuals, Multi-section lines,
Multi-section line metered end
If a branch appears in both cases, it is reported if the status flags differ.
Branch status Where a branch exists in only one of the cases, it is reported regardless of
its status.
Checks for different values of line impedance or charging. If a branch
exists in only one of the cases, it is reported. If a branch has the same
value of impedance in the two cases but is treated as a zero impedance
line in only one of the two (i.e., THRSHZ differs in the two cases; refer to
Line R, X, B
Zero Impedance Lines), it is reported. If a branch is treated as a zero
impedance line in both cases, the impedances are considered equal
regardless of their values in the two cases. For three-winding transformer
windings, winding impedances are compared.
If a branch exists in only one of the cases, it is reported only if the line
Line shunts
shunt at either end of the branch is non-zero.
For branches for which the selected rating(s) differ, all three ratings from
Line ratings both cases are tabulated. If a branch exists in only one of the cases, it is
excluded from the report.
Reports branches with opposite metered ends in the two cases. If a branch
Metered end
exists in only one of the cases, it is excluded from the report.
Reports branches where lengths differ in the two cases. If a branch exists
Line lengths
in only one of the cases, it is excluded from the report.
Two-winding transformers and individual windings of three-winding trans-
formers are compared. If a branch exists in both of the cases, it is reported
under any of the following conditions:
• It is a two-winding transformer or a three-winding transformer
Transformers winding in one case, but not in the other.
• It is a two-winding transformer in both cases, but the Winding 1 side
and Winding 2 side relationship is reversed.
• It is a two-winding transformer in both cases and its Winding 1 tap
ratio or phase shift angle, or Winding 2 tap ratio, differs.
11-114
Table 11-6. Case Comparison Specifications, Branch Data Checks (Cont.)
Category Comparison
• If a branch exists in one case and not in the other, it is reported if it is
a transformer.
For two-winding transformers, this report lists the tap ratios of both wind-
Transformers (continued) ings and the Winding 1 phase shift angle from each case, along with an
indication of which bus is the Winding 1 side bus; for three-winding trans-
formers, the winding ratio is listed in the RATIO1 column and the RATIO2
column is left blank. Differences in tap ratios and phase shift angles for
transformers which are present in both cases are also tabulated.
Compares line flows against a designated threshold tolerance. A branch in
the branch comparison list is reported under any of the following
conditions:
• It is in-service in both cases and the active or reactive power flow at
the from bus end in the two cases differs by more than the threshold
tolerance.
• It exists in both cases with different service status and its active or
reactive power flow at the from bus end in the in-service case
Flows MW or MVAR (from bus)
exceeds the threshold.
• It exists in only one of the cases, is in-service, and its active or
reactive power flow at the from bus end exceeds the threshold.
This report tabulates the active and reactive power flowing into the from
bus end of the line in the two cases. Flow differences between the two
cases are printed for each branch reported, both in MW and Mvar and as
percentages of the working case flows. For this comparison, both cases
should be solved to an acceptable mismatch level.
Similar to Flows MW or MVAR (from bus) except that a branch is listed
Flows MW (from bus) if the active power flow difference in the two cases exceeds the
Similar to Flows MW or MVAR (from bus) except that a branch is listed
Flows MVAR (from bus) if the reactive power flow difference in the two cases exceeds the
similar to Flows MW or MVAR (from bus) except the flows at both ends
Flows MW or MVAR (from & of each line are checked against the threshold. For branches
to) reported, from bus end conditions are shown on the first output line
and to bus end conditions on the second.
Similar to Flows MW or MVAR (from & to) except that a branch is listed
Flows MW (from & to) if the active power flow difference at either end in the two cases
exceeds the threshold tolerance.
Similar to Flows MW or MVAR (from & to) except that a branch is listed
Flows MVAR (from & to) if the reactive power flow difference at either end in the two cases
11-115
Category Comparison
Compares line losses that are calculated as I2R and I2X and
exclude the line charging, line connected shunt, and transformer
magnetizing admittance components. A branch in the branch
comparison list is reported under any of the following conditions:
• It is in-service in both cases and the active or reactive power losses
in the two cases differ by more than the threshold tolerance.
Line MW or MVAR losses • It exists in both cases with different service status and its active or
reactive power losses in the in-service case exceeds the threshold.
reactive power losses exceeds the threshold.
For each branch reported, differences in losses between the two cases are
printed, both in MW and Mvar and as percentages of the working case
losses.
Active power losses is similar to Line MW or MVAR losses except that
Line MW losses a branch is listed if the active power loss difference in the two cases
Reactive power losses is similar to Line MW or MVAR losses except
Line MVAR losses that a branch is listed if the reactive power loss difference in the two
cases exceeds the threshold tolerance.
Checks for different values of zero sequence line impedance or charging. If
a branch exists in only one of the cases, it is included in the report. If a
branch has the same value of zero sequence impedance in the two cases
but is treated as a zero impedance line in only one of the two (i.e.,
THRSHZ differs in the two cases; refer to Section ), it is included in the
report. If a branch is treated as a zero impedance line in both cases, the
Zero sequence R,X,B zero sequence impedances are considered equal regardless of their
values in the two cases.
For transformers, the impedances used are those of the "pi" equivalent
representing the transformer’s zero sequence connections. It is calculated
using the transformer’s various series and ground impedances and its
conection code. For three-winding transformers, winding values are
compared.
Checks for different values of zero sequence line shunts. If a branch exists
in only one of the cases, it is reported only if the zero sequence line shunt
at either end of the branch is non-zero.
Zero sequence line shunts For transformers, the admittances used are those of the "pi" equivalent
compared.
11-116
Category Comparison
Checks for different values of the transformer connection code. If a branch
exists in both of the cases, it is reported under any of the following
conditions:
winding in one case, but not in the other.
Connection codes
• It is a two-winding transformer in both cases, and its winding
connection codes differ.
• It is a winding of a three-winding transformer in both cases, and the
connection codes applied at the winding differ.
If a branch exists in one case and not in the other, it is reported if it is a
transformer. This report lists the connection code from each case, along
with an indication of which bus is the Winding 1 side bus.
For mutuals to be checked, the branches coupled must both be members
of the branch comparison list. If a mutual coupling exists in one case but
not in the other, it is reported. If the mutual is in both cases, it is reported if
Zero sequence mutuals its mutual impedance, its geographic B factors, or its polarity is not identical
in the two cases (refer to Zero Sequence Mutual Impedance Data).
The report lists one of the branches along with the mutual data on one line,
followed by a line listing the other branch.
Compares multi-section groupings for multi-section lines in the multi-
section line comparison list (refer to Multi-Section Line Grouping Data).
If a multi-section line grouping exists in one case but not in the other, it is
reported. If a multi-section line grouping exists in both cases, it is reported
under either of the following conditions:
• Any of its dummy buses in either case is not contained in the bus
Multi-section lines comparison list.
• It contains different members in the two cases.
The report lists the endpoint buses and multi-section line identifier, with the
bus identifiers taken from the working case. It also lists the members of the
multi-section line as contained in the working case (using bus identifiers
from the working case) and in the comparison case (using bus identifiers
from the comparison case).
Reports multi-section line groupings with opposite metered ends in the two
Multi-section line metered end cases. If a multi-section line exists in only one of the cases, it is excluded
from the report.
®
PSS E GUI Users Guide, Section 9.2, Comparing Power Flow Cases
Section 13.5.2, Power Flow Cases
11-117
Displaying Power Flow Solution Differences on a Diagram Program Operation Manual
11.28 Displaying Power Flow Solution Differences on a Diagram

Activity GDIF
Run Activity GDIF - GUI

Diagram > Results > Graphical difference data…
Run Line Mode Activity GDIF - CLI
ACTIVITY?
>>GDIF
ENTER COORDINATE FILE NAME, BINARY OPTION (-1 TO EXIT):
>>
AB
The graphical case comparison activity GDIF calculates differences in power flow solution results
and certain power flow boundary condition data contained in the working case with those of a desig-
nated Saved Case. Results are produced in the Diagram View in a form similar to the display of
power flow output.
Prior to initiating activity GDIF, one of the two cases to be compared must be present in the working
case.
If buses in the two cases are matched using only their extended bus names, each bus must have
a unique extended bus name. Alarms are printed at the dialog output device (refer to Section 4.4
Virtual Output Devices) if there are duplicate extended bus names in either the working case or the
designated Saved Case.
A heading page is printed at the Progress tab containing the case headings of the working case
and the comparison case.
GDIF builds a diagram bus list of buses where difference quantities are to be calculated. A bus
comparison list is then constructed. It contains a list of buses for which the following are all true:
1. They are contained in both cases with the same bus number and/or extended bus name, as
appropriate.
2. They are in the diagram bus list.
3. They did not generate an alarm because they had duplicate extended bus names (see
above) in either the working case or the comparison case.
Any bus from the working case which is in the diagram bus list but which is not included in the
comparison case generates an alarm.
Activity GDIF summarizes the number of buses and branches in the working case and in the
comparison case, the number of buses from each case in the diagram bus list, and the number of
buses in the bus comparison list.
11-118
Program Operation Manual Displaying Power Flow Solution Differences on a Diagram
It constructs a branch comparison list that contains all ac branches from either case that connect
buses in the bus comparison list. The number of such branches, three-winding transformers, and
multi-section lines is then tabulated.
Activity GDIF calculates differences in solution results for equipment at all buses in the bus compar-
ison list and for all branches in the branch comparison list. Activity GDIF generates the diagram
showing the case comparison results.
The output of activity GDIF consists of a single one-line diagram showing the differences in solution
results and bus boundary conditions between the working case and the designated Saved Case.
Differences are always calculated as comparison case values minus working case values. At each
bus in the bus comparison list, voltage difference in per unit and phase angle difference in degrees
are shown. All other difference values are shown in MW and Mvar.
The difference fields are left blank for equipment items present in the working case, but not in the
comparison case. Those items present in the comparison case that are not included in the working
case are omitted from the diagram because it is the working case and its diagram definition data
which determine the network elements drawn on the one-line diagram.
Load and shunt differences include voltage sensitivity effects.
Differences in flow into a converter bus of dc line <name> are shown if all of the following conditions
apply:
1. DC line <name> is present in both cases.
2. The converter bus is in the bus compare list.
3. The same converter bus is specified in both cases.
Differences in the sending bus shunt element of FACTS device <name> are shown if all of the
following conditions apply:
1. FACTS device <name> is present in both cases.
2. The sending bus is in the bus compare list.
3. The same sending bus is specified in both cases.
If the above conditions are satisfied and FACTS device <name> has a series element in the working
case, differences in series flow at the sending bus are also shown.
Differences in series flow at the terminal bus are shown if all of the following conditions apply:
1. FACTS device <name> is present and has a series element in both cases.
2. The terminal bus is in the bus compare list.
3. The same terminal bus is specified in both cases.
Activity GDIF lists the name of the Saved Case File against which the working case is being
compared.
11-119
Comparing AC Tie Branches Program Operation Manual
®
Section 13.7.2, Displaying Power Flow Solution on the Diagram
11.29 Comparing AC Tie Branches

Activity DFTI
Run Activity DFTI - GUI

File > Compare…
[Compare]
Tie Lines Tab
AB
The tie line case comparison activity DFTI compares power flow branch data and solution results
contained in the working case with those of a designated Saved Case. Only ac tie branches from
the designated subsystem are subjected to processing and reporting.
Prior to selecting activity DFTI, one of the two cases to be compared must be present in the working
case. The report of activity DFTI is directed to the Progress tab unless an output destination had
been preselected via activity OPEN.
The following input data defining comparison and reporting options is specified to DFTI:
• The subsystem where tie branches are to be compared.

• The name of the Saved Case File for which tie branches from the specified subsystem
are to be compared to those of the working case.
• The method to be used in matching up buses in the two cases.
• Data defining the quantities to be compared and any appropriate comparison options.
• The case to be left in PSS®E working memory at the termination of activity DFTI (i.e.,
the original working case or the specified Saved Case).
Refer to Section 2.4.1 File Usage for the file specification conventions used by activity DFTI. Any
Following the successful pickup of the comparison case, a heading page containing the case head-
ings of the working case and the comparison case is printed at the output device.
Activity DFTI constructs a table of tie point buses in the two cases. Then, for both the working case
and the comparison case, it summarizes the number of buses and branches in the case, the
number of tie point buses in the specified subsystem, and the number of tie point buses outside of
the specified subsystem.
It then matches up tie point buses in the two cases using the method specified by the user (same
bus number, same extended bus name, or both the same bus number and same extended bus
name). If buses in the two cases are matched using only their extended bus names, each tie point
11-120
Program Operation Manual Comparing AC Tie Branches
bus must have a unique extended bus name. Alarms are printed at the dialog output device (refer
to Section 4.4 Virtual Output Devices) if there are duplicate extended bus names of tie point buses
in either the working case or the designated Saved Case. Any tie point buses that generated an
alarm are ignored in the subsequent processing and reporting of activity DFTI.
Tie point bus discrepancies between the two cases are then reported at the output device.
It then constructs a tie branch comparison list, which contains any ac branch from either case which
connects a subsystem tie point bus to a non-subsystem tie point bus. Three-winding transformers
which have at least one winding connected to a subsystem tie point bus and at least one winding
connected to a non-subsystem tie point bus have those windings which are connected to
subsystem tie point buses included in the tie branch comparison list.
The area, zone, and/or owner assignments of buses are used to determine which buses are tie
point buses when subsystem selection by area, zone, and/or owner is enabled. The owner assign-
ments of ac branches are not referenced by activity DFTI.
The user specifies one of the following data types for comparison:
Table 11-7. Case Comparison Specifications, AC Tie Branch Data Checks
ref # Specification Description

If a tie branch appears in both cases, it generates an alarm if the status
1 Branch status flags differ. Where a tie branch exists in only one of the cases, it generates
an alarm regardless of its status.
Check for different values of line impedance or charging.
If a tie branch exists in only one of the cases, it is included in the report.
If a tie branch has the same value of impedance in the two cases but is
treated as a zero impedance line in only one of the two (i.e., THRSHZ
2 Line R,X,B differs in the two cases; refer to Section ), it is included in the report.
If a tie branch is treated as a zero impedance line in both cases, the imped-
ances are considered equal regardless of their values in the two cases.
For three-winding transformer windings, winding impedances are
compared.
If a tie branch exists in only one of the cases, it is included in the tabulation
3 Line shunts
only if the line shunt at either end of the branch is non-zero.
The user specifies the rating sets to be compared (all ratings, RATEA only,
RATEB only, or RATEC only). For tie branches for which the selected
4 Line ratings
rating(s) differ, all three ratings from both cases are tabulated. If a tie
branch exists in only one of the cases, it is excluded from the report.
Report tie branches with opposite metered ends in the two cases. If a tie
5 Metered end
branch exists in only one of the cases, it is excluded from the report.
Report tie branches where lengths differ in the two cases. If a tie branch
6 Line length
exists in only one of the cases, it is excluded from the report.
11-121
Table 11-7. Case Comparison Specifications, AC Tie Branch Data Checks (Cont.)

Two-winding transformers and individual windings of three-winding trans-
formers are compared. If a tie branch exists in both of the cases, it
generates an alarm under any of the following conditions:
• It is a two-winding transformer in both cases, and its Winding 1 tap
7 Transformers ratio or phase shift angle, or Winding 2 tap ratio, differs.
• It is a winding of a three-winding transformer in both cases, and its
winding tap ratio or phase shift angle differs.
If a tie branch exists in one case and not in the other, it generates an
alarm if it is a transformer. For two-winding transformers, this report lists
the tap ratios of both windings and the Winding 1 phase shift angle from
each case, along with an indication of which bus is the Winding 1 side bus;
for three-winding transformers, the winding ratio is listed in the RATIO1
column and the RATIO2 column has a value of 1.0.
Compare line flows against a designated threshold tolerance. A branch in
the tie branch comparison list is included in this report under any of the
following conditions:
• It is in-service in both cases, and the active or reactive power flow at
the from bus end in the two cases differs by more than the threshold
tolerance.
• It exists in both cases with different service status, and its active or
Flows MW or MVAR reactive power flow at the from bus end in the in-service case
8
(from bus) exceeds the threshold.
reactive power flow at the from bus end exceeds the threshold.
This report tabulates the active and reactive power flowing into the from
bus end of the line in the two cases. Flow differences between the two
cases are printed for each branch reported, both in MW and Mvar and as
percentages of the working case flows. For this comparison, both cases
should be solved to an acceptable mismatch level.
Similar to previous specification, except the flows at both ends of each tie
Flows MW or MVAR line are checked against the threshold. For branches reported, from bus
9
(from and to buses) end conditions are shown on the first output line and to bus end conditions
on the second.
11-122
Program Operation Manual Comparing AC Tie Branches

Compare line losses that are calculated as I2R and I2X and exclude the
line charging, line connected shunt, and transformer magnetizing admit-
tance components. A branch in the tie branch comparison list is included in
this report under any of the following conditions:
• It is in-service in both cases, and the active or reactive power losses
in the two cases differ by more than the threshold tolerance.
Line MW or MVAR
10 • It exists in both cases with different service status, and its active or
losses
reactive power losses in the in-service case exceeds the threshold.
reactive power losses exceeds the threshold.
For each branch reported, differences in losses between the two cases are
printed, both in MW and Mvar and as percentages of the working case
losses.
Check for different values of zero sequence line impedance or charging.
If a tie branch exists in only one of the cases, it is included in the report.
If a tie branch has the same value of zero sequence impedance in the two
cases but is treated as a zero impedance line in only one of the two (i.e.,
THRSHZ differs in the two cases; refer to Section ), it is included in the
report.
If a tie branch is treated as a zero impedance line in both cases, the zero
11 Zero sequence R,X,B sequence impedances are considered equal regardless of their values in
the two cases.
For transformers, the impedances used are those of the "pi" equivalent
compared.
Both the working case and the comparison case must contain sequence
data.
If a tie branch exists in only one of the cases, it is included in the tabulation
only if the zero sequence line shunt at either end of the branch is non-zero.
For transformers, the admittances used are those of the "pi" equivalent
Zero sequence line
12 using the transformer’s various series and ground impedances and its
shunts
compared.
Both the working case and the comparison case must contain sequence
data.
11-123

In the transformer connection code check, if a tie branch exists in both of
the cases, it generates an alarm under any of the following conditions:
13 Connection codes • It is a two-winding transformer in both cases, and its winding
connection codes differ.
• It is a winding of a three-winding transformer in both cases, and the
connection codes applied at the winding differ.
If a tie branch exists in one case and not in the other, it generates an
alarm if it is a transformer. This report lists the connection code from each
case, along with an indication of which bus is the Winding 1 side bus.
Similar to flows MW or MVAR (from bus) except that a branch is listed if the
14 Flow MW (from bus) active power flow difference in the two cases exceeds the threshold
tolerance.
Similar to flows MW or MVAR (from bus) except that a branch is listed if the
Flow MVAR (from
15 reactive power flow difference in the two cases exceeds the threshold
bus)
tolerance.
Similar to flows MW or MVAR (from and to buses) except that a branch is
Flow MW (from and to
16 listed if the active power flow difference at either end in the two cases
buses)
Similar to flows MW or MVAR (from and to buses) except that a branch is
Flow MVAR (from and
17 listed if the reactive power flow difference at either end in the two cases
to buses)
Similar to line MW or MVAR losses except that a branch is listed if the
18 Line MW losses active power loss difference in the two cases exceeds the threshold
tolerance.
Similar to line MW or MVAR losses except that a branch is listed if the reac-
19 Line MVAR losses tive power loss difference in the two cases exceeds the threshold
tolerance.
In comparing line flows and losses (Flows MW or MVAR (from bus), Flows MW or MVAR (from and to
buses), and Line MW or MVAR losses), a threshold tolerance is used. If the difference between data
items in the two cases is within this tolerance, the item is omitted from the output report. Tolerances
are allowed to be specified either in engineering units (e.g., MW and Mvar), or as a percentage of
the data item values in the working case.
The selected check is made and exceptions are listed as described.
For categories comparing fault analysis data, this data must be present in both cases. At the
completion of activity DFTI, the user designation of which of the two cases is to be left as the PSS®E
working case is honored.
Exceptions are tabulated in up to three groups, each of which is in single entry format (refer to
Branch Data), ordered in ascending bus numerical or alphabetical order according to the bus output
11-124
Program Operation Manual Generating a Graphical Report
option in effect at the time activity DFTI is selected (refer to Section 3.3.3 Program Run-Time Option
Settings). The first group contains tie branches connecting tie point buses which are present in both
cases. The second group contains those tie branches in the working case with at least one of the
buses it connects not present in the designated Saved Case. The third group contains those tie
branches in the designated Saved Case with at least one of the buses it connects not present in the
working case.
Bus identifiers and ordering from the working case are used in tabulating the first two groups; bus
identifiers and ordering from the designated Saved Case are used in tabulating the third group.
When reporting individual windings of three winding transformers, winding data is tabulated.
Section 9.3, Comparing AC Tie Branches
11.30 Generating a Graphical Report

Activity GRPG
Run Activity GRPG - GUI

Diagram > Generate graphical report…
Graphical Report Data file (*.grp)
GRED Library File (*.sgf)
Graphical Report Definition Data File (*.grb)
Run Line Mode Activity GRPG - CLI
ACTIVITY?
>>GRPG
ENTER INPUT FILE NAME, FILE TYPE OPTION (0=EXIT):
>>
None
The graphic report generating activity GRPG allows the user to generate arbitrary diagrams on a
customer-supported graphics output device from a file.
A dialog requesting selection from among the customer-supported graphics output devices pops
up.
11-125
Generating a Graphical Report Program Operation Manual
Figure 11-27. Plotting Device Popup Dialog
For terminal display, enter the device number for MS-Windows (color) or MS-Windows (BW). To
close the graphic display and return to the [Terminal Read] dialog, use [Enter].
11.30.1 GRPG Commands

GRPG commands are comprised of a verb, followed by zero or more keywords, variables, and/or
comments. In describing the GRPG command syntax, the following notational conventions are
used:
CAPITALS Keyword that must be specified exactly as shown. No keyword abbreviations

are allowed.
lowercase Items shown in lowercase are GRPG variables. The variable < c > is always
enclosed in square brackets and denotes optional comments; other variables
are described along with the appropriate command.
[…] Items enclosed in square brackets are optional keywords and/or variables.
|A| or A|B |B| Specify one from the list separated by, or enclosed in, the vertical bars.
The GRPG commands are organized into seven categories: setup, miscellaneous, drawing, text,
assignment, conditional, and termination. These are described in the following sections.
Setup Commands
The function of these commands is to set the size and orientation of the picture produced by activity
GRPG. Any setup commands must be issued prior to any use of the commands in the drawing, text,
and terminate categories.
SET X|Y COORDINATE PAPER LIMITS TO min AND max
The SET PAPER LIMITS command is used to change the size of the drawing that is
produced. The default limits are 0 to 8 in. for the x-coordinate, and 0 to 10.5 in. for the
11-126
y-coordinate. Separate commands must be issued for X and Y if the paper limits of both are
to be changed. The limits must be specified in inches.
SET PLOT ORIENTATION TO PORTRAIT|LANDSCAPE
The SET PLOT ORIENTATION command is used to rotate the diagram 90 degrees. The
default orientation is PORTRAIT; if LANDSCAPE orientation is specified, the picture is
rotated prior to output.
Use of the following command sets the drawing limits and orientation for the drawing produced by
activity GRPG to those specified in a one-line diagram Drawing Coordinate Data File. Therefore,
the above SET commands should not be used in conjunction with the INCLUDE ONE-LINE
command.
INCLUDE [BINARY] ONE-LINE [c] FROM filename
The INCLUDE ONE-LINE command is used to include one-line diagrams of the form pro-
duced by activity DRAW in the drawing created by activity GRPG. A Graphical Report Def-
inition Data File along with all its INCLUDEd files may contain only one INCLUDE ONE-
LINE command.
11-127
Miscellaneous Commands
The miscellaneous commands may be entered at any time during the execution of activity GRPG.
blank or *
Blank lines and lines that contain an asterisk () in column one are ignored when process-
ing a GRPG input data file. They may be used to enhance the readability of the input file.
COMMENT string
The COMMENT command simply echoes the command to the user’s terminal. It is useful
in monitoring the progress during the execution of longer GRPG data files.
HELP [command]
The HELP command is used to display the syntax of a GRPG command. If a GRPG com-
mand is not entered, a list of GRPG commands is displayed.
INCLUDE filename [c] [OFFSET x,y] [c] [SCALE scale]
The INCLUDE command is used to insert commonly used subdrawings into a Graphical
Report Definition Data File. The optional parameters OFFSET and SCALE may be used to
modify the location and size of the subdrawing being INCLUDEd. By default, the subdraw-
ing is not offset or scaled (i.e., x,y = 0.0,0.0 and scale = 1.0).
The file <filename> must be in the form of Graphical Report Definition Data File; specifi-
cally, it may not be a GRED Library File.
ROTATE PLOT angle [c] AROUND x,y
The ROTATE PLOT command causes subsequent plotting to be rotated the specified
angle around the point <x,y>. The most common use of this command is in conjunction with
the INCLUDE command described above. This command must be included after any
INCLUDE ONE-LINE command.
SET ANGLE TO DEGREES|RADIANS
The SET ANGLE command is used to change the units by which angles are specified in
subsequent GRPG commands. By default, angles are specified in degrees.
SET UNITS TO INCHES|CENTIMETERS
The SET UNITS command is used to change the units by which distances are specified in
subsequent GRPG commands. The default is inches.
DECLARE REAL|STRING &label_l [&label_2 ... &label_10]
The DECLARE command is used to define the names of variables to be used in subse-
quent GRPG commands. All variables (labels) must be declared exactly once before they
are used in other GRPG commands. The form of each label is a 12-character string, the
first of which must be an ampersand ( & ); commas and spaces are not allowed in label
names. Up to 10 variables may be defined in a single DECLARE command. A Graphical
Report Definition Data File along with all its INCLUDEd files may have defined up to 2000
REAL variables and 500 STRING variables of up to 60 characters each. REAL variables
are initialized to zero and STRING variables to a single blank at the time they are
DECLAREd.
11-128
In describing the remainder of GRPG commands, GRPG variables are often referred to as
ampersand labels.
DEFINE MACRO macroname
The DEFINE MACRO command is used to define and name a series of GRPG commands,
which may later be executed with the INVOKE command. A Graphical Report Definition
Data File along with all its INCLUDEd files may define up to 50 macros. Any GRPG com-
mand (except another DEFINE MACRO command) may be used between the DEFINE
MACRO command and its corresponding ENDMACRO command. However, DECLARE
commands should not be contained within any macro that will be INVOKEd more than
once. Macros may be contained in INCLUDE files.
Within a macro, the special strings %n% (where < n > is a single-digit 1 through 9) are used
to represent the values of up to nine arguments specified in the INVOKE command and
evaluated at the time the macro is INVOKEd. An %n% string may be used in any keyword
or variable position except for the command name in any GRPG command within a macro.
ENDMACRO
The ENDMACRO command terminates the definition of a GRPG macro.
Drawing Commands
The drawing commands, along with the text commands, are used to define the desired drawing.
Four of the drawing commands have several forms. The general description of those commands
are as follows.
MOVE Causes an invisible line to be drawn to the specified point.

DRAW Causes one or more lines to be drawn, depending on the command. See the SET
LINE commands in this section for a description of the attributes of the line.
SHADE Causes the figure defined by the command to be filled or toned with the pattern
described by the last SET SHADING PATTERN command.
APPEND Causes one or more lines (or a figure) to be appended to a list of polygons to be
shaded. If the APPEND command causes a move, the current figure is closed (but
not printed) and a new figure is started. All APPEND commands except
APPEND LINE TO, APPEND LINE FOR, and APPEND VECTOR FOR result in a
move. The SHADE ACCUMULATED POLYGONS command causes any appended
figures to be filled.
11-129
The following commands are described using only one verb, but the description applies to all verbs,
with the action taken defined above.
|DRAW |
|MOVE | LINE [FROM x1,y1] TO x2,y2
|APPEND|
This form of the DRAW LINE command causes a line to be drawn from < x1,y1 > to
< x2,y2 >. If the FROM coordinate < x1,y1 > is omitted, the line is drawn from the current
position to < x2,y2 >.
|DRAW |
|MOVE | LINE FOR x,y
|APPEND|
This form of the DRAW LINE command causes a line to be drawn from the current position
< x0,y0 > to < x0+x,y0+y >.
|DRAW |
|MOVE | VECTOR [FROM x,y] FOR len [c] ANGLE ang [c]
|APPEND|
The DRAW VECTOR command causes a line of length < len > and at the angle < ang > to
be drawn from the coordinate < x,y >. If the from coordinate < x,y > is omitted, the line is
drawn from the current position.
|DRAW |
|APPEND| BOX FROM x1,y1 TO x2,y2 [c] [RADIUS rad]
|SHADE |
This form of the DRAW BOX command results in a rectangle being drawn. The rectangle
is defined by the intersections of horizontal and vertical lines through the points < x1,y1 >
and < x2,y2 >. If the optional radius is included, the corners of the box are rounded with the
specified radius < rad >.
|DRAW |
|APPEND| BOX CENTERED AT x,y WITH SIDES xl BY yl [c] [RADIUS rad]
|SHADE |
This form of the DRAW BOX command results in a box being drawn with the center at the
coordinate < x,y >. The lengths of the sides of the box are specified by < xl > and < yl >. If
the optional radius is included, the corners of the box are rounded with the specified radius
< rad >.
|DRAW |
|APPEND| CIRCLE [c] AT x,y [c] RADIUS rad
|SHADE |
The DRAW CIRCLE command results in a circle with the specified radius being drawn with
the center at the coordinate < x,y >.
11-130
|DRAW |
|APPEND| ARC [c] AT x,y [c] RADIUS rad [c] FROM a1 [c] TO a2 [c]
|SHADE |
The DRAW ARC command results in a counterclockwise arc being drawn with the focus
specified by < x,y >, the radius by < rad >, the beginning angle by < a1 > and the ending
angle by < a2 >.
|DRAW | |CLOCKWISE |
|APPEND| |CW | ELLIPSE FROM x1,y1 TO x2,y2
|SHADE | |COUNTERCLOCKWISE|
|CCW |
The DRAW ELLIPSE command results in an ellipse being drawn from the coordinate
< x1,y1 > to the coordinate < x2,y2 >. The direction (or curvature) of the ellipse is deter-
mined by the specification of CLOCKWISE (CW) or COUNTERCLOCKWISE (CCW).
|DRAW |
|APPEND| POLYGON[S] FROM file [c] [OFFSET x,y] [c] [SCALE scale]
|SHADE |
The DRAW POLYGON command causes the contents of the file < file > to be drawn on the
picture. Each line in the file must be blank or must have an x-y pair with the numbers
separated by a comma or one or more blanks. An implied move is performed for the first
x-y coordinate in the file. In addition, a blank line in the file causes a move to the next
x-y coordinate pair.
DRAW GRID FROM x1,y1 TO x2,y2 [c] DELTA xd,yd
The DRAW GRID command results in a grid being drawn with the lower left corner specified
by < x1,y1 > and the upper right corner specified by < x2,y2 >. In the x direction, lines are
drawn spaced at intervals specified by < xd >; in the y direction, lines are drawn spaced at
intervals specified by < yd >.
DRAW LOGO AT x,y WITH SIZE siz [c] [ANGLE ang] [c]
The DRAW LOGO command results in the PTI logo being drawn with the lower left corner
specified by < x,y > at a height of < siz > and at the angle < ang >.
|SCATTER PLOT |
PLOT |STRAIGHT LINES| FROM filename
|SPLINE CURVES |
The PLOT command is used to plot a series of x-y coordinate pairs stored in the file
< filename > on the drawing. Unlike the DRAW POLYGON command, the PLOT command
scales the data before it is included on the diagram. If the SCATTER PLOT option is
selected, the data points are plotted using the symbol designated by the SET PLOT
SYMBOL command at the size and angle designated by the SET SYMBOL command. If
the STRAIGHT LINES option is selected, the data points are connected by straight lines. If
the SPLINE CURVES option is selected, the data points are connected using a curve
approximation algorithm to generate smooth lines between the data points. At least three
data points must be included to approximate a curve. If only two data points are included,
a straight line is drawn between the two points. See the following SET commands for further
information on scaling.
11-131
SET X|Y COORDINATE PLOTTING LIMITS TO min AND max
The SET PLOTTING LIMITS command sets the limits for the portion of the drawing to
which scaled data is mapped. This allows the user to map plotted data into, say, a gridded
area, which was generated by use of the DRAW GRID command. By default, the plotting
limits are the same as the paper limits. This command is normally used in conjunction with
the following command.
SET X|Y COORDINATE DATA LIMITS TO min AND max
The SET DATA LIMITS command sets the limits for data to be plotted via the PLOT com-
mand. As x-y pairs are read from the file, the values are scaled according to where they fall
in the data limit range. Data points outside the data limit range receive no special treatment,
but are plotted outside of the limits set in the SET COORDINATE PLOTTING LIMITS com-
mand. By default, the data limits are the same as the paper limits.
SET PLOT SYMBOL TO number
The SET PLOT SYMBOL command may be used to change the symbol to be drawn by the
PLOT SCATTER PLOT command, where < number > is the number of a symbol from the
font specified in the last SET FONT TYPE command (see Figures 11-28 and 11-29). A
< number > of zero may be specified to use a circle centered around each plotted point; this
is the default if no SET PLOT SYMBOL command is specified. It is recommended that one
of the centered symbols (0 through 14) be specified.
SET SYMBOL [HEIGHT TO size] [c] [ANGLE TO ang] [c]
The SET SYMBOL command may be used to change the height and/or rotational angle of
symbols drawn via the PLOT SCATTER PLOT command. By default, symbols are drawn
with a height of 0.1 in. and rotated zero degrees.
SET LINE TYPE TO type
The SET LINE TYPE command specifies the line pattern to be used when drawing lines to
be of type < type > where < type > is an integer with a range of one to six. A line type of one
is a solid line. Other line patterns are plotting device specific. By default, < type > is one.
SET LINE COLOR TO color
The SET LINE COLOR command specifies the color to be used for subsequent lines and
text to be of color < color >, where < color > is an integer with a range of 1 to 8. On some
devices, however, not all eight colors can be supported. In this case, the value of < color >
is adjusted to a valid color number. The resulting color for each value of < color > is device
dependent. For monochrome plotting devices, the SET LINE COLOR command is ignored.
By default, < color > is one.
SET LINE WIDTH TO width
For monochromatic plotting devices, the SET LINE WIDTH command specifies the line
thickness to be used for subsequent lines. The value of < width > can be 1 through 5. This
command is ignored for plotting devices which support color. By default, < width > is one.
11-132
Figure 11-28. STANDARD Font
11-133
Figure 11-29. LOWERCASE Font
11-134
SET SHADING PATTERN TO pattern
The SET SHADING PATTERN command specifies the shading color or pattern to be used
when filling or toning polygon areas. The value of < pattern > is 1 through 16. The resulting
pattern or color is device dependent. For plotting devices that do not support polygon filling,
shading is simulated by drawing closely spaced lines in the polygonal area.
SET SHADING OUTLINE VISIBLE|INVISIBLE
The SET SHADING OUTLINE command specifies whether the boundary lines of polygons
to be shaded are to be drawn. By default, the boundary lines are not drawn.
CLOSE POLYGON
The CLOSE POLYGON command may be used after an APPEND command to force the
end of a polygon area. This may be needed when it is desired to tone several overlapping
polygon areas with a single shade command.
SHADE ACCUMULATED POLYGON[S]
This form of the SHADE command closes an open polygon, if necessary, and causes one
or more polygons that have been accumulated by the APPEND commands to be toned or
filled. The accumulated polygons are then removed from the list of polygons to be shaded.
FLUSH ACCUMULATED POLYGON[S]
The FLUSH command causes any polygons that have been generated by the APPEND
commands to be removed from the list of polygons to be shaded.
INVOKE MACRO macroname USING P1 [P2 ... P9]
The INVOKE command executes the macro < macroname >, passing up to nine argu-
ments to the macro. The macro < macroname > must have been previously defined using
the DEFINE MACRO and ENDMACRO commands.
If fewer arguments are specified in the INVOKE command than are used within the macro,
the unspecified arguments are evaluated as the string .NULL.. If more arguments are spec-
ified in the INVOKE command than are used within the macro, the extra arguments are
ignored.
Text Commands
The text commands are used to control output of graphic text on the drawing.
JUSTIFY TEXT LEFT|RIGHT|CENTERED
The JUSTIFY TEXT command can be used to modify the reference point for placement of
text specified by the WRITE command. For left justified text, the location specified by the
WRITE command is at the lower left corner of the text string. If the text is to be centered,
the WRITE command specifies the center point of the text. If the text is to be right justified,
then the WRITE command specifies the lower right corner of the text block. The default ref-
erence for text is left justified.
SET FONT TYPE TO STANDARD|LOWERCASE|fontnumber
The SET FONT TYPE command is used to select the character font to be used in subse-
quent WRITE commands. The STANDARD font, or font one (see Figure 11-28), which
11-135
does not contain lowercase characters, is used by default. The LOWERCASE font, or font
two (see Figure 11-29), contains both uppercase and lowercase characters.
The variable < fontnumber > is a positive integer through which the user may select one of
the hardware fonts available on certain PostScript printers. Refer to Guide to Printing and
Plotting for details on setting up the graphics device parameter file.
SET TEXT [HEIGHT TO size] [c] [ANGLE TO ang] [c]
The SET TEXT command may be used to change the height and/or rotational angle of text
drawn via the WRITE command. By default, text is drawn with a height of 0.1 in. and rotated
zero degrees.
SET PRINT FORMAT TO width,decimal
The SET PRINT FORMAT command specifies the format to be used for printing numeric
data in subsequent WRITE commands. The variable < width > specifies the total width of
the numeric field, including the decimal point and any leading spaces. < decimal > specifies
the number of decimal places to be printed following the decimal point. If the value is too
large to fit in < width > digits, < decimal > is reduced to accommodate it. By default,
< width > is 8 and < decimal > is 2.
WRITE item [item2 ... item10] [AT x,y]
The WRITE command builds an output line of up to 132 characters formed by the concat-
enation of the < items > specified. Items may be quoted or unquoted strings of up to 60
characters, reserved keywords enclosed in percent symbols ( % ), symbol codes enclosed
in angled brackets ( < > ), or ampersand labels. Reserved keywords and symbol codes
must be specified as uppercase characters.
If a quoted string is specified as an item, the quotes are removed before it is appended to
the output line. If the string contains any blanks, commas (,), or slashes (/), it must be
enclosed in single quotes. If a quoted string is to contain quotes, each quote within the
string must be specified as two consecutive quotes.
If a reserved keyword of the form %name% is specified as an item, a value designated by
the reserved name is appended to the output line. If the reserved name %DATE% is spec-
ified, a 17-character string containing the current date is used. If the reserved name
%TIME% is specified, a 5-character string containing the current time is used.
If a string of the form <SYMnnn> is specified as an item, the symbol for which the symbol
number is nnn is appended to the output line. Symbol numbers are dependent upon the
character font specified in the last SET FONT TYPE command (see Figures 11-28 and 11-
29).
If an item is an ampersand label (&label), the value of the corresponding GRPG variable is
appended to the output line. If the variable is of type STRING, the output includes any trail-
ing blanks that are a part of the variable’s value. If the variable is of type REAL, the value
is formatted according to the specifications in the last SET PRINT FORMAT command.
If < AT x,y > is specified, that coordinate value is used as a reference point for the output
line. See the JUSTIFY TEXT command above for more information on text reference
points. If < AT x,y > is not specified, the output line is positioned according to the following:
• If text is left justified, the output line is placed at the end of the previous output.
11-136
• If text is centered, the output line is centered 1.3 times text height below the previous
output.
• If text is right justified, the output line is right justified 1.3 times text height below the
previous output.
When in the left justify mode, the string <CR> embedded in the output line causes a
carriage return and line feed to be simulated. The resulting position is 1.3 times the text
height relative to the last position specified by explicitly entering < x,y >. Additional
<CR> strings cause simulation of additional carriage returns and line feeds. The string
<CR> should not be used in the centered or right justify modes.
Assignment Commands
The assignment commands are used to place values into previously DECLAREd GRPG amper-
sand labels (i.e., variables). They provide for access to the PSS®E working case and for arithmetic
operations involving ampersand labels.
|constant|
LET &label_1 = |string |
|&label_2|
This form of the LET command assigns the value from the right side of the equal sign to the
ampersand label on the left side. If &label_1 is of type REAL, the right side must contain
either a numeric constant or another REAL ampersand label. If &label_1 is of type STRING,
the right side must contain either a character string or another STRING ampersand label.
If type conflicts occur, an error message is printed.
LET &label_1 = |constant| oper |constant|
|&label_2| |&label_3|
This form of the LET command assigns the value resulting from the arithmetic computation
on the right side of the equal sign to the ampersand label on the left side. All values must
be of type REAL or an error is reported. The specification of < oper > must be one of the
arithmetic operators +, -, , / or their corresponding keywords PLUS, MINUS, TIMES, or
OVER.
LET &label_1 = THE CABS OF |constant| AND |constant|
This form of the LET command assigns the magnitude of a complex number to the amper-
sand label on the left side of the equal sign. The complex number operated upon is the one
for which real and imaginary components respectively consist of the two values specified
on the right side of the equal sign. All values must be of type REAL or an error is reported.
The following forms of the LET command are used to access data from the PSS®E working case.
Results are stored in ampersand labels, which must have been previously DECLAREd. When a
form of this command returns more than one value (e.g., a complex power), the values are stored
in consecutively DECLAREd REAL ampersand labels, starting at the one specified in the LET com-
mand. In the following forms of the LET command, if the variable on the left side is < &label >, the
command returns a single value; the variable < &label2 > on the left side indicates that two values
are returned by the command. Whenever a bus identifier is required in the LET command (busid),
either the extended bus name enclosed in single quotes or the bus number may be specified.
11-137
LET &label2 = THE CASE TITLE
Returns the two-line case title in the STRING variables &label2 and the next DECLAREd
STRING ampersand label.
LET &label = THE NAME FOR AREA|ZONE n
Returns the name of the specified area or zone in the STRING variable &label.
LET &label2 = THE INTERCHANGE FROM AREA n TO AREA n
LET &label2 = THE INTERCHANGE FROM ZONE n TO ZONE n
Returns the complex interchange between a pair of areas or zones.

LET &label = THE MW |TRANSACTION| FROM AREA n TO AREA n [IDENTIFIER id]
|TRANSFER |
Returns the specified interarea transfer between a pair of areas in MW. If omitted, a transfer
identifier of 1 is assumed.
LET &label2 = THE NET INTERCHANGE FROM AREA|ZONE n
Returns the complex total interchange from a specified area or zone.

LET &label2 = THE GENERATION|LOAD|LOSSES FOR AREA|ZONE n
Returns the complex total generation, load or losses for a specified area or zone.
LET &label2 = THE SYSTEM GENERATION|LOAD|LOSSES
Returns the complex system total generation, load or losses.

LET &label = THE [EXTENDED] NAME FOR BUS busid
Returns the 8-character bus name or the 12-character extended bus name in the STRING
variable &label.
LET &label2 = THE GENERATION AT BUS busid
Returns the complex generation at the specified bus.

LET &label2 = THE LOAD AT BUS busid [LOADID id]
Returns the complex load at the specified bus. If the optional load identifier is omitted, total
bus load is returned; otherwise, the specified load is returned.
LET &label2 = THE ACTUAL|NOMINAL FIXED|SWITCHED SHUNT AT BUS busid
Returns the complex fixed or switched bus shunt either in MW and Mvar or in admittance.
LET &label = THE BASE VOLTAGE FOR BUS busid
Returns the base voltage of a specified bus.

LET &label = THE VOLTAGE AT BUS busid [ IN PU|KV ]
Returns the voltage magnitude at the specified bus in either per unit or kV. If the units spec-
ification is omitted, per unit voltage is returned.
11-138
LET &label = THE ANGLE AT BUS busid
Returns the voltage phase angle at the specified bus in degrees.

LET &label = THE STATUS FOR |BRANCH| FROM BUS busid TO BUS busid [CIRCUIT id]
|LINE |
Returns the service status of the specified branch as either zero for out-of-service or one
for in-service into a REAL ampersand label. If omitted, a circuit identifier of 1 is assumed.
LET &label2 = THE FLOW FOR |BRANCH| FROM BUS busid TO BUS busid [CIRCUIT id]
|LINE |
Returns the complex power flow on the specified branch. If omitted, a circuit identifier of 1
is assumed.
LET &label2 = THE |RECTIFIER| FLOW FOR 2-TERMINAL DC LINE n
|INVERTER |
Returns the complex power flowing into the two-terminal dc line as seen from the appropri-
ate ac converter bus.
LET &label2 = THE CONVERTER FLOW AT BUS busid FOR N-TERMINAL DC LINE n
Returns the complex power flowing into the multi-terminal dc line as seen from the appro-
priate ac converter bus.
LET &label = THE CONTROL MODE FOR |2-TERMINAL| DC LINE n
|N-TERMINAL|
Returns the control mode value MDC for the specified dc line.
Conditional Commands
The conditional commands are used to control output based upon the results of assignment com-
mands. These commands are used to form IF command blocks, which consist of:
• One IF command followed by a series of commands.

• Optionally, one or more ELSEIF commands, each followed by a series of commands.
• Optionally, one ELSE command followed by a series of commands.
• One ENDIF command.
|constant| |constant|
IF |string | oper |string |
The IF command compares a pair of operands to determine if the next series of commands
is to be executed. Both operands must be of the same type. The specification of < oper >
must be one of the logical operators =, <>, >, >=, <, <=, or their corresponding keywords
EQ, NE, GT, GE, LT, or LE.
If the specified expression evaluates to a true condition, the commands in the range of the
IF command are executed. The range consists of those commands between the IF com-
mand and the next ELSEIF, ELSE, or ENDIF command.
11-139
|constant| |constant|
ELSEIF |string | oper |string |
The ELSEIF command must follow an IF or another ELSEIF command. The logical expres-
sion is evaluated only if the IF and all other preceding ELSEIF commands in the IF com-
mand block had evaluated to a false condition. Otherwise, the ELSEIF command behaves
in the same manner as the IF command.
ELSE
The ELSE command must follow an IF or ELSEIF command. The series of commands fol-
lowing an ELSE command are executed only if the IF and all preceding ELSEIF commands
in the IF command block had evaluated to a false condition.
ENDIF
The ENDIF command terminates each IF command block.

There is an unresolved problem with the ELSEIF command. It is recommended
that, until the problem is corrected, instead of using ELSEIF commands, nested IF
command blocks be used as in the following structural example:
IF ... IF ...
a... a...
ELSEIF ELSE
b... IF ...
ELSE b...
c... ELSE
ENDIF c...
ENDIF
ENDIF
Termination Commands
The termination commands are used to terminate the current plot.
ABORT
The ABORT command is used to terminate the execution of GRPG without the generation
of plotting output.
END [c]
The END command is used to terminate all GRPG data files. If the data file currently being
processed is an INCLUDE file, processing of the INCLUDE file terminates and processing
of the original file resumes. Otherwise, the plotting page is terminated and the prompt for
selection of the desired plotting device is displayed.
Only one drawing in such a file may contain SET PAPER LIMITS and SET PLOT
ORIENTATION commands. It is strongly recommended that it be the first one.
START NEW PLOT
The START NEW PLOT command is used to terminate a plotting page. Additional plotting com-
mands may follow and results in another plot being produced. This command, then, is used
between groups of data records specifying multiple drawings in a single data input file.
11-140
Program Operation Manual Viewing Graphical Output of Fault Calculations
®
PSS E GUI Users Guide, Section 3.16, Generating a Graphical Report
Section 13.7.1, Generating a Graphical Report
11.31 Viewing Graphical Output of Fault Calculations

The fault currents calculated by activity ASCC (ASCC_2 api) and activity IECS (IECS_2 api) can be
displayed on slider diagrams.
11.31.1 Display Options
Fault Calculation Results Displayed

The following types of fault currents can be displayed on one slider diagram:
• Total fault currents for all faulted buses and for all fault types considered
• Total fault currents and fault current contributions at home bus
• Total fault currents and fault current contributions across entire network
• Contour diagram of maximum fault currents at each faulted bus considered
Units of Voltage and Currents Displayed

Engineering units are established for a slider diagram using the [Program Settings] dialog. Refer
to Section 20.10, Changing PSS®E Program Settings for the following options:
• Fault currents are displayed in either per unit on a system apparent power and voltage
base or in AMP using the Short circuit output option.
• Fault currents are displayed in either polar or rectangular coordinates using the Short
circuit coordinates option.
• Post-fault bus voltages are displayed in either per unit on a system voltage base or kV
using the Short circuit output option.
Voltage and Currents Displayed

Voltage and current values are displayed on the slider diagram as follows:
• The post-fault bus voltage and total fault current are displayed as bus quantities on the
faulted bus.
• The post-fault bus voltages on all buses except the faulted bus are displayed as bus
quantities.
• The fault currents on each branch, shunts and machines show their contributions to the
total fault current.
Slider Diagram Title

The titles on the slider diagram display the activity name and fault description.
Graphical user interface dialog options

The various options in the graphical user interface dialog (Figure 11-30) are:
11-141
Viewing Graphical Output of Fault Calculations Program Operation Manual
Table 11-8. ASCC Fault Analysis Annotation Options
Option Description
Fault type
• Fault currents (only bus faults): display total fault currents for all calculated
fault types and all faulted buses
This selection does not display total fault currents for the Line Out and
Line End fault options, even when they are calculated.
• Three phase (3PH) faults: display three phase fault currents
• Line to ground (LG) faults: display line-to-ground fault currents
• Line Line to Ground (LLG) faults: display double line-to-ground fault
currents
Select fault to display
• Line to Line (LL) faults: display line-to-line fault currents
Contributions at home bus for bus faults
To display fault contributions at home buses for all faulted buses select
this option in addition to the 3PH, LG, LLG or LL fault type selection.
This selection does not display fault contributions at home buses for the
Line Out and Line End fault options, even when they are calculated.
Faulted bus
To display fault currents for a selected faulted bus specify the faulted bus
in addition to 3PH, LG, LLG or LL fault type selection.
Sequence components of fault current: positive sequence (Ia1), negative
Display quantity sequence (Ia2) and Zero sequence (Ia0) or 3Ia0
Phase components of fault current: Phase A (IA), Phase B (IB), Phase C (IC)
For Line Out (LOUT) fault cases, in addition to selection of fault to display and
Line Out Faults display quantity, specify the branch or three winding transformer that is intention-
ally outaged.
For Line End (LEND) fault cases, in addition to selection of fault to display and
display quantity, specify the branch connected to faulted bus whose far end
(from faulted bus) is being faulted.
When a three winding transformer is connected to the faulted bus, two Line End
faults are calculated at two buses other than the faulted bus. For these two Line
End faults, specify:
Line End Faults
From bus: Line End bus
To bus: Faulted bus
Last bus: Last bus
Note: To Bus is always the faulted bus, but the From Bus is selected depending
on which Line End is faulted.
11-142
Figure 11-30. ASCC Fault Analysis Annotation Dialog
11-143
11.31.2 Example
The slider diagrams in this section show the ASCC_2 fault currents for following faults:
• Case: sample.sav
• 3PH, LG, LLG and LL faults are calculated for faults on buses 152, 3001, 3002, 3004,
3011
• Faults with Line Out as well as Line End
Similarly, activity IECS_2 fault currents can be displayed in the slider diagram.
Total Fault Currents, All Faulted Buses, All Selected Fault Types
The slider diagram below shows total fault currents at faulted buses for 3PH, LG, LLG and LL faults
on buses 152, 3001, 3002, 3004 and 3011.
Figure 11-31. Fault Analysis Annotation Dialog, Total Fault Currents
11-144
Figure 11-32. Slider Diagram, Total Fault Currents
11-145
Total Fault Currents and Fault Current Contributions, Home Bus

The slider diagram below shows total fault currents and fault current contributions at home bus for
a three phase fault on buses 152, 3001, 3002, 3004 and 3011.
Figure 11-33. Fault Analysis Annotation Dialog, Contributions at Home Bus
11-146
Figure 11-34. Slider Diagram, Fault Current Contributions at Home Bus
11-147
Total Fault Currents and Fault Current Contributions, Entire Network

The slider diagram below shows fault currents and post-fault voltages for a three phase fault at bus
3001.
Figure 11-35. Fault Analysis Annotation Dialog, Selected Fault
11-148
Figure 11-36. Slider Diagram, Fault Currents for a Selected Fault
11-149
Total Fault Currents and Fault Current Contributions, Line Outage

3001 with branch 3001-3003-1 out.
Figure 11-37. Fault Analysis Annotation Dialog, Line Outage Fault
11-150
Figure 11-38. Slider Diagram, Line Outage Fault Currents
11-151
Total Fault Currents and Fault Current Contributions, Three Winding Transformer Winding
Outage
3001 with three winding transformer 3001-3002-3011-1, winding connected to faulted bus 3001 out.
Figure 11-39. Fault Analysis Annotation Dialog, Three Winding Transformer Winding Outage
11-152
Figure 11-40. Slider Diagram, Three Winding Transformer Winding Outage Fault Currents
11-153
Line End Fault – 1st Line End Fault
The slider diagram below shows fault currents and post-fault voltages for a three phase fault at the
end of three winding transformer winding: faulted bus 3001, three winding transformer 3001-3002-
3011-1, and fault at the end of winding connected to bus 3002.
Figure 11-41. Fault Analysis Annotation Dialog, Three Winding Transformer,

1st Line End Fault
11-154
Figure 11-42. Slider Diagram, Three Winding Transformer, 1st Line End Fault Currents
11-155
Line End Fault – 2nd Line End Fault
The slider diagram below shows fault currents and post-fault voltages for a three phase fault at the
end of three winding transformer winding: faulted bus 3001, three winding transformer 3001-3002-
3011-1, and fault at the end of winding connected to bus 3011.
Figure 11-43. Fault Analysis Annotation Dialog, Three Winding Transformer,

2nd Line End Fault
11-156
Figure 11-44. Slider Diagram, Three Winding Transformer Winding,

2nd Line End Fault Currents
11-157
Unbalanced Fault Currents

The slider diagram below shows fault currents and post-fault voltages for a line-to-ground (LG) fault
at bus 3004.
The sequence data for shunts (loads, fixed shunts and switched shunts) are entered as negative
and zero sequence shunt data records in sequence data file. The shunt current contributions from
these shunt elements for unbalanced faults are displayed as combined shunt current of all shunts
on one of these shunt elements. For example, in the slider diagram below, combined shunt current
is displayed on loads at bus 152 and at bus 3005.
Figure 11-45. Fault Analysis Annotation Dialog, Unbalanced Fault Currents
11-158
Program Operation Manual Exporting Power Flow Results to Excel
Figure 11-46. Slider Diagram, Selected Fault, Unbalanced Fault Currents
11.32 Exporting Power Flow Results to Excel

Activity Exporting Power Flow Results to Excel
Run Activity Export Results - GUI

Power Flow > Reports > Export ACCC, PV/QV results to Excel…
Start > Programs > PSSExx > Export results to Excel
[Export PSS®E Data/Result to Excel]
Table 11-9. PSS®E to Excel Export Options
Option Description
Report type to export, with data Options.
• ACCC Analysis Results
Data/Results to Export
• PV Solution Results
• QV Solution Results
11-159
Displaying Power Flow Solution on the Diagram Program Operation Manual
Table 11-9. PSS®E to Excel Export Options (Cont.)
Option Description
[Specify pssexcel.accc Options] dialog, with the following options:
• Solution Type
- Contingency
- Corrective Action
ACCC Analysis Results
- Tripping
Options
• Rating
- Rating A, Rating B, or Rating C
• Bus Mismatch (default = 0.5)
• System Mismatch (default = 5.0)
Data/Result File ACCC analysis output file (*.acc) to be exported
Excel Workbook File (*.xls) User-specified filename or Excel default, if no name is specified.
One worksheet for each selected item in this field is created in a speci-
Quantities to Export fied workbook. The name of the worksheet is the name of the quantity to
export.
Excel Sheet Prefix The worksheet name will be prefixed by the specified text.
Enable (default) to overwrite existing worksheets.
Overwrite Worksheets Disable to copy existing worksheets; filenames are automatically
appended with (#), where # is the next sequence number.
Enable (default) to open and display workbook as it is being written to.
Show Workbook
Disable to populate workbook without displaying it.
Split Extended Bus Enable (default) to split extended bus names into three columns - Bus
Names Number, Bus Name and Bus Voltage.
PSS E GUI Users Guide, Section 16.9, Exporting Power Flow Results to Microsoft Excel®
®
11.33 Displaying Power Flow Solution on the Diagram

Activity GOUT
Run Line Mode Activity GOUT - CLI

ACTIVITY?
>>GOUT
Enter 0 to exit
26 for interactive display
30 for default printer
>>
None
11-160
Program Operation Manual Displaying Power Flow Data on the Diagram
The graphical power flow output activity GOUT has been replaced by a similar function in the
Diagram View of the Graphical User Interface (GUI). The PSS®E GUI Users Guide, Chapter 3
describes the Diagram View.
The old line mode dialog of activity GOUT is implemented at the command line input and results in
the execution of the Diagram View’s GOUT function.
The user specifies the bus or branch to be displayed, and the drawing is generated. While the dialog
allows the selection of either a bus display or an expanded branch display, only the bus display is
supported. If the branch display is selected, a bus display of the first bus specified is produced.
PSS®E GUI Users Guide, Section 3.8, Displaying Power Flow Results

Section 13.7.2, Displaying Power Flow Solution on the Diagram
11.34 Displaying Power Flow Data on the Diagram

Activity GEXM
Run Line Mode Activity GEXM - CLI

ACTIVITY?
>>GEXM
Enter 0 to exit
26 for interactive display
30 for default printer
>>
None
The graphical power flow data examination activity GEXM has been replaced by a similar function
in the Diagram View of the Graphical User Interface (GUI). The PSS ®E GUI Users Guide,
Chapter 3 describes the Diagram View.
The old line mode dialog of activity GEXM is implemented at the command line input and results in
the execution of the Diagram View’s GEXM function.
The user specifies the bus or branch to be displayed, and the drawing is generated. While the dialog
allows the selection of either a bus display or an expanded branch display, only the bus display is
supported. If the branch display is selected, a bus display of the first bus specified is produced.

Section 13.7.3, Displaying Power Flow Data on the Diagram
11-161
Displaying Power Flow Data on the Diagram Program Operation Manual
11-162
Chapter 12
Balanced Switching
Chapter 12 - Balanced Switching
12.1 Overview: Balanced Switching

The voltage versus current characteristics of synchronous generators are different in different time
regimes. Power system network solutions must, therefore, be categorized according to the condi-
tions just before and at the instant for which the solution is to apply. The time regimes of significance
in network solutions are illustrated in Figure 12-1.
All power system simulations assume that the system is in the steady state for an extended period
prior to the time, t. It is assumed that the first incident of interest, such as a switching operation,
fault, load change, or control setpoint change, occurs at, t. Power flow calculations apply to the
instant, t– (t minus). The power flow generator boundary conditions, therefore, assume that the
system is in the steady state, or more practically, experiencing the gentle motions of normal undis-
turbed operation. Every power flow calculation establishes the condition of the entire transmission
network, outward from generator terminals to load terminals, for an instant, t–.
12-1
Balanced Switching PSS®E 34.2
Overview: Balanced Switching Program Operation Manual
Generator
Internal
Flux
Linkage
t Time
Network
Variable,
(Voltage
or Current)
t Time
t– t+ Post Disturbance
Conditions Conditions Conditions
(Steady-State) (Switching) (Dynamics of
System)
Figure 12-1. Time Regimes Considered in Power System Simulations
Any switching operation, fault, significant load change or change of control inputs (governor or exci-
tation system reference) starts the system moving. PSS®E simulations assume that high frequency
switching transients in the electric network die away very rapidly in relation to the time durations of
the transients that are of interest. The power frequency phasors representing currents and voltages
throughout the network are assumed to change instantaneously at time t.
The transients of the flux linkages in the rotors of electrical machines are of prime interest and must
be accurately accounted for. Simulations of conditions at, t+ (t plus), and later must, therefore, use
boundary conditions that recognize dynamic, rather than steady-state, behavior of equipment. Both
generator and load characteristics applicable to t+ are different from those applying at t–. Loads are
commonly assumed to have a constant MVA steady-state characteristic in steady-state power flow
solutions applying to t–, but to be better modeled by a mixture of constant current and constant
impedance characteristics at t+ and later.
The instantaneous change caused by a switching is followed by a period when all generator flux
linkages, rotor angular positions, and other power plant quantities vary, as dictated by the differen-
tial equations governing their dynamic behavior.
The power flow database of PSS®E allows the entry of generator and load data pertaining to pre-
disturbance conditions at t–, to switching conditions at t+, and to system dynamic behavior over an
12-2
PSS®E 34.2 Balanced Switching
Program Operation Manual Overview: Balanced Switching
arbitrarily long period after the initiation of the disturbance. The user of PSS®E may then obtain a
solution for any of the three time regimes, steady-state, switching, or dynamic behavior, by exe-
cuting appropriately selected sequences of PSS®E analytical processes.
Switching, or t+, solutions and dynamic simulations require the generator boundary conditions to be
set in accordance with the electromagnetic laws governing rotor flux linkages. Therefore, the power
flow boundary condition in which power output and bus voltage are specified, must be replaced by
a specification of a Thevenin or Norton source where instantaneous value is determined by instan-
taneous values of flux linkages. The generator boundary conditions applying at instants, t– and t+,
are illustrated by Figure 12-2. The t+ boundary condition recognizes that generator rotor flux link-
ages must obey Lenz’s and Maxwell’s laws.
Bus k
P + jQ
k k
e
k
~ ISORCE
t :1 Z
g t
1 E int 
y = --------------
Z -------------------
dyn Z
e dyn
k
b. Norton Generator Equivalent for Switching and Dynamic Simulation Calculations
Figure 12-2. Standard Power Flow Model and Norton Equivalent Used for
Switching and Dynamic Studies
12-3
Overview: Balanced Switching Program Operation Manual
12.1.1 Objectives of a Balanced Switching Study

The objective of a switching study is to calculate the conditions that will exist in the power system
just after a sudden change such as the opening of a transmission line, switching on of a large load,
application of a fault, or tripping of a generator. These calculations are useful, for example:
1.To show the immediate voltage dip caused by switching on of a large motor.
2.To give symmetrical fault duty at a bus.
3.To show the immediate change of flow that will be seen on each tie-line into an area
(before the inertial swing of rotor angles) when one such tie or a generator within the
area is tripped.
4.To show the voltage rise which occurs when a line is opened at one end. This could sepa-
rate a generation plant from the network and result in what is commonly known as load
rejection.
A switching study is a calculation of conditions at time, t+. A switching study is, in effect, the calcu-
lation of the transmission system conditions at the first instant, t = t+, of a dynamic simulation,
separated from the subsequent calculation of conditions at later instants, t > t+. Switching study
results are presented and examined with the same output and limit checking activities as are used
in power flow work studies.
12.1.2 Preparing a Power Flow Case for Balanced Switching

Prior to performing the switching operations, the user must prepare the power flow case. The three
steps are to:
• Ensure the power flow case is solved and contains the required generator dynamic
data
• Convert the generators to a Norton Equivalent (generator boundary condition, activity
CONG)
• Convert the loads to a voltage dependent model (load boundary condition, activity
CONL)
These operations result in a converted power flow case which can be saved in its converted form
for subsequent switching analyses. Note that this converted case should be saved using a different
name because the conversion process is not reversible.
12.1.3 Establishing the Power Flow Base Case for Balanced Switching
The starting point for a switching study is a conventional solved power flow case giving data and
solution corresponding to the pre switching (t–) condition. Conventional procedures are used with
the provision that the dynamic impedance, ZSORCE, must be included in the database for every
generator, and step-up transformer data, XTRAN and GENTAP, must be present for all generators
where the implicit step-up transformer treatment is used.
The generator dynamic impedance and step-up transformer parameters are not needed during
power flow solutions; they may be added to the power flow but a solved power flow case need not
be resolved after any item of generator dynamic impedance or step-up transformer is added or
changed because the dynamic impedance and step-up transformer parameters affect only the
Norton equivalent current sources, ISORCE, that will represent the generators in the post switching
calculation.
12-4
Program Operation Manual Overview: Balanced Switching
12.1.4 Performing a Balanced Switching Study

The sequence of steps required to perform a balanced switching study is shown in Figure 12-3. It
can be seen that the basic preparation is as described as discussed in the previous sections. After
that preparation is complete, the user can perform a variety of switching studies on the converted
power flow case. The method involves:
• Performing the switching action by changing the network as required

• Obtaining a solution and producing the results
The switching of network elements is performed using the processes used by the conventional
power flow facilities. Furthermore, the output of results and network conditions can be performed
using the same output and reporting facilities used for the conventional power flow and getting a
solution.
12-5
Converting Generators Program Operation Manual
Solve Initial Condition Power Flow
Convert Generators
Convert Loads
Make Required
Changes to Initial
Order Network Condition Power Flow
Save the Converted Case t- Model
Perform the Switching Operation
Open <file> to Open <file> to Recover

Recover Converted Factorize and Solve the Network Initial Condition
Power Flow Case Power Flow Case
Output the Results
Perform Another Switching

Operation from the Same
Initial Condition
New Initial Condition Required?
Figure 12-3. Switching Analysis – Sequence of Processes
12.2 Converting Generators

Activity CONG
Run Activity CONG - GUI

Power Flow > Convert Loads and Generators…
[Convert / Reconstruct Loads and Generators]
OPTION: Convert Generators
Run Line Mode Activity CONG - CLI
12-6
Program Operation Manual Converting Generators
ACTIVITY?
>>CONG
None
The generator and induction machine conversion activity CONG initializes the in-service machines
in the working case in preparation for dynamic simulation calculations, network solutions used in
switching studies (activity TYSL), and the three sequence equivalencing activity SCEQ. It also
retains the conditions at each FACTS device and VSC dc line for use in their modeling in switching
studies.
12.2.1 Converting Machines for Balanced Switching

PSS®E uses the same power flow working case for power flow, fault analysis, and dynamic simu-
lation calculations. The representation of a machine as a voltage behind an apparent impedance,
as required for fault analysis and dynamic simulation, is handled by a Norton equivalent for each
machine. The Norton source current is determined from the machine boundary conditions as deter-
mined from the power flow (t–) solution.
For conventional machines, the generator dynamic impedance may be taken to be either the gen-
erator power flow attribute, ZSORCE, or the fault analysis generator attribute, ZPOS. Normal
practice is to set ZSORCE equal to subtransient impedance. In setting ZPOS, either subtransient,
transient or synchronous reactance may be selected, depending upon the requirements of fault
analysis. Those switching studies taking the dynamic impedance to be subtransient machine
impedance, Z, give an accurate calculation of conditions immediately after a switching, while those
switching studies taking the dynamic impedance to be transient machine impedance, Z, give an
approximate calculation of conditions roughly three to five cycles after a switching.
When the power flow impedance ZSORCE is selected as the impedance characterizing conven-
tional machines, IMZPSN, the impedance characterizing induction machines, has a resistance of
Ra, the machine armature resistance, and a reactance X" that is calculated from the equivalent cir-
cuit parameters as
X1 X2
X m X 3 + --------------------
X1 + X2
X = X a + --------------------------------------------------
X1 X2
X m + X 3 + --------------------
X1 + X2
When the fault analysis impedance ZPOS is selected as the impedance characterizing conven-
tional machines, IMZPSN is set using the induction machine locked rotor to rated current ratio,
ILR2IR, if it is specified as a non-zero value with the induction machine sequence data. The mag-
nitude of the impedance is set to the reciprocal if ILR2IR, and the resistance and reactance of
IMZPSN are set according to this impedance magnitude and the resistance to reactance ratio,
RM2XM, specified with the induction machine sequence data. If ILR2IR is zero, IMZPSN is set from
the equivalent circuit parameters as described above for the case of ZSORCE being used to char-
acterize conventional machines.
The initialization of the Norton sources and changeover of boundary conditions is illustrated in
Figure 12-5. The conversion process, which initializes all source currents to correspond to the flux
12-7
linkages behind the dynamic impedance (ZSORCE or ZPOS), sets flags to cause ISORCE to be
held constant in all subsequent solutions, and changes all Type 3 buses to Type 2. The choice of
dynamic impedance is controlled during the conversion process and selected by the user.
12.2.2 Generator Apparent Impedance

The data characterizing the Norton equivalent for each generator consists of the machine MVA
base (MBASE) and the machine impedance (ZSORCE). Values for these data items are entered as
generator data via the PSS®E activities READ, TREA, RDCH, or MCRE, and they may be modified
with the data changing activity CHNG or the [Spreadsheet]. The value specified for ZSORCE may be
the generator transient impedance, subtransient impedance, or any other value of impedance that
may be a meaningful characterization of the generator for the study at hand. In addition, the gener-
ator step-up transformer may be represented as part of the generator model itself or explicitly as a
network branch (refer to Section 12.2.3 Generator Step-Up Transformers). Refer to Generator Data
for additional details on these data parameters. Note that the value of ZSORCE must be specified
on the generator MVA base (i.e., on MBASE base) and that it is a complex number (resistance and
reactance).
The correspondence between the commonly recognized Thevenin equivalent generator represen-
tation and the Norton equivalent used in PSS®E is summarized in Figure 12-4. Note that the
Thevenin internal bus must not be included in the PSS®E power flow case. A generator is modeled
throughout PSS®E by its terminal and/or high side buses only. Furthermore, the fictitious shunt
branches representing generators are automatically separated from real shunt admittance at the
generator buses so that their presence does not affect power flow output reports from PSS®E. Only
the shunt elements representing actual reactors and capacitors are shown under the heading
SHUNT in PSS®E reports.
ZSORCE and MBASE data need not be entered if the working case being constructed is to be used
only for standard power flow solutions. When no data is entered, MBASE and ZSORCE take on
default values equal to the system base MVA and j1.0 pu, respectively.
The report generated by activity GEOL will not be valid for any generators for which MBASE
and ZSORCE are not specified.
12.2.3 Generator Step-Up Transformers

The user may select one of two methods of representing the generator step-up transformer for each
machine.
The traditional method involves representing the step-up transformer as a standard power flow
transformer branch. Both the generator terminal bus and the high side bus are contained in the case
along with a transformer branch between them representing the step-up transformer. The terminal
bus is the Type 2 (or 3) bus and the high side bus has a Type code of 1. This representation is shown
by Figure 12-4b.
The alternative approach is to represent the step-up transformer as part of the generator modeling.
In this method, the high side bus is represented in the power flow case as a Type 2 bus and the
terminal bus is not present. The step-up transformer impedance and off-nominal ratio are repre-
sented by the generator data items XTRAN (i.e., RT + jXT) and GTAP, respectively (refer to
Generator Data). XTRAN is entered on generator base (i.e., on MBASE base) and is a complex
number (resistance and reactance). This representation is shown by Figure 12-4c.
12-8
When XTRAN is non-zero (i.e., the generator bus is the high side bus), the generator boundary
conditions (i.e., voltage setpoint, active power output, and reactive power limits) are as seen at the
high side bus. Generator terminal conditions may be examined with activity GEOL.
When XTRAN is zero, PSS®E assumes that the step-up transformer is represented by an ac
branch and the Type 2 bus is the terminal bus.
12-9
Terminal Bus Fictitious

(Type 2) Internal Bus
Thevenin
ZSORCE Voltage
Source
a. Thevenin Generator Equivalent
High Side Bus Terminal Bus

(Type 1) (Type 2)
Norton
RT + jXT Current
Source
WINDV1:WINDV2
Y = 1. / ZSORCE
b. Norton Generator Equivalent Used in PSS®E (XTRAN = 0.0)
High Side Bus Terminal Bus

(Type 2) (Omitted)
Norton
RT + jXT Current
Source
GTAP:1
Y = 1. / ZSORCE
c. Norton Generator Equivalent Used in PSS®E (XTRAN > 0.0)
Figure 12-4. Relationship Between PSS®E Generator Equivalent and Thevenin Equivalent
12-10
a. Power Flow - ISORCE Follows Network Solution
b. Switching - Network Solution Follows ISORCE
Figure 12-5. Change of Generator Boundary Condition for Switching
12.2.4 Operation of Activity CONG

Activity CONG calculates the Norton source currents for in-service conventional machines at all
Type 2 and 3 buses on the basis of the network conditions at the bus (voltage and power output)
and the values specified for MBASE, ZSORCE, XTRAN, and GTAP (see Figure 12-4). In addition,
12-11
the Type codes of system swing buses are changed from 3 to 2, and of var-limited generator buses
from -2 to 2. Similarly, activity CONG calculates the Norton source currents for in-service induction
machines at all type 1, 2 and 3 buses on the basis of the network conditions at the bus and the data
items describing the equivalent circuit of the machine.
The working case must be solved to an acceptable mismatch level and appropriate values of
MBASE, ZSORCE, XTRAN, and GTAP must have been specified for all in-service generators prior
to executing activity CONG.
When the Use ZPOS option is specified, the positive sequence generator impedances as specified
in sequence data input (ZPOS; refer to Generator Sequence Data) are used in place of ZSORCE
in determining the Norton source currents. If sequence data had not previously been read into the
working case, activity CONG proceeds with the generator conversion using ZSORCE.
Activity CONG is neither reversible nor repeatable. Therefore, it is strongly recommended that the
power flow case be saved prior to executing activity CONG. Furthermore, the only network solution
permitted following activity CONG is activity TYSL.
Activity CONG generates an alarm for any bus with a machine for which an impedance of zero is
detected during the Norton current calculation. When XTRAN is zero, the generator impedance
ZSORCE or ZPOS, as appropriate, must be non-zero; when XTRAN is non-zero, the effective
impedance
GTAP2 (ZG + XTRAN)

must be non-zero, where ZG is ZSORCE or ZPOS, as appropriate. If this restriction is violated, an
appropriate message is printed at the conclusion of activity CONG and the working case is
unchanged. Appropriate data corrections must then be made before executing activity CONG
again.
Activity CONG generates an alarm for any Type 2 or 3 bus that does not have a plant sequence
number assigned to it (i.e., any Type 2 or 3 bus for which no generator data record was entered via
activities READ, TREA, or RDCH). In this case, the bus type code is set to 1, the conversion is not
valid, and the unconverted case must be picked up and the appropriate corrections made before
proceeding with CONG. (Refer to Generator Data and Plant and Machine Sequence Numbers.)
Activity CONG preserves the current magnitude of the shunt element of each in-service FACTS
device, and the series voltage of each in-service series FACTS device for use in activities TYSL and
BKDY. Similarly, it preserves the ac active and reactive power injection at each VSC dc line
converter bus for switching study and circuit breaker duty solutions. Refer to Section 12.7, Solving
the Converted Case for details on the handling of these devices in activities TYSL and BKDY.
®
PSS E GUI Users Guide, Section 17.1.1, Generators
Section 14.1, Converting Generators
12-12
Program Operation Manual Converting Load Characteristics
12.3 Converting Load Characteristics

Activity CONL
Run Activity CONL - GUI

OPTION: Convert / Reconstruct Loads; Convert constant MVA loads
Run Line Mode Activity CONL - CLI
ACTIVITY?
>>CONL
>>
None
The load conversion activity CONL converts the constant MVA load for a specified grouping of
network loads to a specified percentage for constant current or constant admittance load character-
istics of the existing constant MVA load (refer to Load Data and Section 6.3.13 Load).
12.3.1 Modeling Load Characteristics

Normal practice in power flow work is to assume that distribution system tap changers and voltage
regulators have brought customer voltages to nominal values and, hence, that load at the buses
represented in the power flow case may be treated as a constant real and reactive power demand.
It is generally recommended, therefore, that load is treated as constant MVA from one power flow
case to the next.
This is particularly true of conventional planning studies where demand level is a given quantity
which must be maintained under a variety of system normal and abnormal conditions. The
Planner’s job is to identify the lines and equipment required to sustain the defined demand levels;
it is axiomatic that the demand level is a given (constant MVA).
In steady-state and quasi steady-state operation studies, it is reasonable to recognize the loads’
dependence on voltage. Such studies include balanced switching, short-circuit analysis
(Chapter 10) and examination of potential voltage collapse or voltage instability. These are condi-
tions under which voltage excursions can be significant.
Similarly, under dynamic conditions, which would be simulated with the PSS®E dynamic simulator,
treating loads as purely constant MVA at the reference load value is not acceptable because time
delays in distribution voltage-regulating devices prevent them from adjusting customer voltages in
the period of interest. Furthermore, loads have a frequency dependence. For dynamic studies,
therefore, a variety of load models of varying complexity are available. These models recognize, in
more detail, the specific characteristics of loads such as lighting, heating and motor loads. The
PSS®E models available for dynamic simulations are discussed in detail in PSS®E Model Library.
12-13
Converting Load Characteristics Program Operation Manual
12.3.2 Basic Load Characteristics

The network solutions of PSS®E recognize load components with constant MVA, constant current,
and constant admittance characteristics as discussed in Load Data.
The input functions of PSS®E identify the load at each bus and allow the user to indicate the
following components of each load.
PL Real power, constant MVA load.

QL Reactive power, constant MVA load.
IP Real power, constant current load.
IQ Reactive power, constant current load.
YP Real power, constant admittance load.
YQ Reactive power, constant admittance load.
All of these components are specified in MW and Mvar. The MW and Mvar values for the constant
current and constant admittance components are the values that would be consumed by these
loads when the bus voltage is unity per unit. The values of these components can be changed,
using the editing facility in the Spreadsheet View or the load can be taken out of service by changing
its status in the Spreadsheet View.
While it is possible to enter bus loads as combinations of constant MVA, constant current and
constant admittance, it is preferable to enter the total load as constant MVA mainly because the
majority of steady-state analysis will be performed at or close to nominal voltage and the total
demand level is critical to the study at hand. It is a simple exercise to convert system loads from the
constant MVA characteristic to either of the voltage dependent characteristics or a combination of
all three depending on the type of analysis being carried out. It is equally simple to reconvert the
loads to have their original characteristic or any other combination.
12.3.3 Converting Load Characteristics

The conversion process in PSS®E takes constant MVA load and reassigns it all or in part as
constant current or constant admittance load. A fraction of the constant MVA load at each bus are
transferred to each of the other two load characteristics, according to the following rules
aSp
SI = Si +
V
bSp
SY = Sy +
V2
SP = Sp × (1 - a - b)
where:
Sp = Original constant MVA load.

Si = Original constant current load.
Sy = Original constant shunt admittance load.
SP = Final constant MVA load on bus (real, MW, or reactive, Mvar).
12-14
SI = Final nominal constant current load on bus (real, MW, or reactive, Mvar).
SY = Final nominal constant shunt admittance load on bus (real or reactive).
a,b = Load transfer fractions, (a + b) < 1
(Real and reactive load may be allocated by different a and b values.)
v = Magnitude of bus voltage when load conversion is made.
The conversion and re-allocation process is diagrammed in Figure 12-6.
Figure 12-6. Re-allocation of Constant MVA Bus Load
It is useful to note the following points regarding the load conversions:
1. The conversion is performed only on the constant MVA load.
2. Load converted to constant current and constant admittance is added to any existing load
represented by those characteristics.
3. The load is converted on the basis of the actual voltage at the network buses. Prior to
conversion the working case should be solved to an acceptable mismatch level. Following
conversion, the network is still in balance.
4. The split of load among the three characteristics may be different for the active and reactive
components of load.
5. Admittance load is stored separately from the bus shunt.
Furthermore, following conversion, only the new components are accessible for editing.
12-15
Converting Load Characteristics Program Operation Manual
12.3.4 Converting Loads for Balanced Switching

The load boundary condition for switching studies should reflect the relationship between load
voltage and current during sudden changes of voltage. The constant (P,Q) characteristic used in
power flow studies is generally regarded as unsuitable for switching studies. A mixture of constant
current and constant impedance is usually regarded as a more accurate treatment of loads when
the supply voltage is changing rapidly. Load characteristics should be adapted for switching studies
as described in Section 12.1.2 Preparing a Power Flow Case for Balanced Switching.
12.3.5 Operation of Activity CONL

The user may specify the manner of selecting loads to be processed and/or the buses where loads
are to be converted (refer to Section 4.8 Subsystem Selection) by bus subsystem, area, zone,
owner, or basekV. When processed by basekV, activity CONL processes all loads at each bus
where base voltage falls within the specified base voltage band. When processed by area, zone, or
owner, each load assigned to one of the areas, zones, or owners specified is converted (refer to
Load Data). The area, zone, or owner assignments of buses (refer to Bus Data) are not considered
in these subsystem selection modes.
The user specifies the manner in which the existing constant MVA load is to be apportioned for each
grouping of loads to be processed by entering the percentages of the constant current and constant
admittance load characteristics.
Activity CONL prints the number of loads converted out of the total number of loads in the working
case.
12.3.6 Example of Load Conversion

This example describes a case in which 30% of the real part of the constant MVA load is to be
converted to constant current and 20% to constant admittance. For the imaginary component, the
conversion is to 20% constant current and 10% constant admittance.
It can be seen further that the loads to be converted can be selected by the Area, Zone or Owner
number to which the loads are assigned (NOT to the bus assignment to which the loads are
connected). When selected by kV, all loads connected to buses with the selected voltage(s) will be
converted in the loads’ selected Areas, Zones and/or Owners.
Figure 12-7 shows the MVA loads in the savnw.sav power flow case, as initially defined. If the
conversion selections above were chosen, the result would be to re-allocate the loads as shown in
Figure 12-8. The conversion has been done, as can be seen, on all loads.
Note that conversion is done on the basis of the current load bus voltages in the power flow case.
The user should be sure to solve the case to an acceptable tolerance before converting the loads.
12-16
Figure 12-7. Reference Load Values in Savnw.sav Power Flow Case
Figure 12-8. Converted Loads Re-allocations as per Figure 12-7

The portion of the load which is represented as constant MVA load is converted as specified by
activity CONL. Any of that load to be converted to the constant current and admittance character-
istics is added to the load already represented by those characteristics.
It is useful to note the following points regarding the load conversions:
1. Activity CONL converts only the constant MVA load.
2. Load converted to constant current and constant admittance is added to any existing load
represented by those characteristics.
3. The load is converted on the basis of the actual voltage at the network buses. Thus, activity
CONL requires that the working case be solved to an acceptable mismatch level. Following
completion of activity CONL, the network is still in balance.
4. The split of load among the three characteristics may be different for the active and reactive
components of load.
5. The presence of constant MVA and/or constant current reactive power load may require
slight deceleration in activity TYSL and dynamic simulations for optimum performance.
12-17
Reconverting Load Characteristics Program Operation Manual
6. Admittance load is stored separately from the bus shunt.
PSS®E GUI Users Guide, Section 17.1.2, Load Characteristics
Section 14.2, Converting Load Characteristics
12.4 Reconverting Load Characteristics

Activity RCNL
Run Activity RCNL - GUI

OPTION: Convert / Reconstruct Loads; Reconstruct loads…
Run Line Mode Activity RCNL - CLI
ACTIVITY?
>>RCNL
ENTER LOAD RECONSTRUCTION OPTION:
1 FOR PRESENT VOLTAGE 2 OR 3 FOR UNITY VOLTAGE:
>>
None
The load reconstruction and conversion activity RCNL reconstructs the constant MVA load for spec-
ified network loads. It then converts the reconstructed MVA load to a specified mixture of the
constant MVA, constant current, and constant admittance load characteristics (refer to Load Data
and Sections 6.3.13 and 12.3).
12.4.1 Reconverting Load Characteristics

It is possible to reconstruct the constant MVA load from a mixture of the three load characteristics
for selected network loads. Subsequently, it is possible to then convert the reconstructed constant
MVA load to a different specified mixture of the constant MVA, constant current, and constant admit-
tance load characteristics. The reconstruction process as illustrated in Figure 12-9. The process
first collects all load back into a single constant MVA load and then reallocates it into constant MVA,
constant current, and constant admittance components in the same manner as the conversion
process.
12-18
Program Operation Manual Reconverting Load Characteristics
Figure 12-9. Load Collection and Re-allocation
There are two approaches to reconstruction and re-allocation of loads:
• Reconstruct MVA loads based on present bus voltage.

• Reconstruct MVA loads based on unity voltage.
When reconstructing MVA loads based upon present bus voltages, for each bus processed, the
individual MVA loads represented by the three load characteristics are summed. This total load is
then split among the three load characteristics as specified. Using this load reconstruction option,
the network should be solved to an acceptable mismatch level before initiating the reconstruction
process. The network will remain in balance at completion of this process.
This process first collects all load into the constant MVA component by
ST = Sp + vSi + v2Sy
where ST is the total of the three load components and then reallocates it by the formula
aST
SI =
v
bST
SY =
v2
SP = ST(1 - a - b)
The symbols used are defined in Section 12.3.3 Converting Load Characteristics.
12-19
Reconverting Load Characteristics Program Operation Manual
When reconstructing loads based on unity voltage, the three load components are summed
assuming one per unit voltage, (v = 1.0) and this total load is split among the three load character-
istics as specified. The network will normally not be in balance following this process with this load
reconstruction option.
12.4.2 Operation of Activity RCNL

The user specifies the option to be used in reconstructing the MVA load: present voltage or unity
voltage. Refer to Section 12.4.4 Application Notes for details on the load reconstruction options.
The user may specify the buses where loads are to be processed (refer to Section 4.8 Subsystem
Selection) by area, zone, owner, or basekV.
When processed by basekV, activity RCNL processes all loads at each bus where base voltage falls
within the specified base voltage band. When processed by area, zone, or owner, each load
assigned to one of the areas, zones, or owners specified is converted (refer to Load Data). The
area, zone, or owner assignments of buses (refer to Bus Data) are not considered in these
subsystem specifications.
Activity RCNL prints the number of loads reconstructed out of the total number of loads in the
working case.
12.4.3 Example of Load Reconstruction

In this example the option to reconstruct using present voltage has been selected and the re-allo-
cation is to 10% of total load for both real and reactive power for constant current and constant
impedance loads.
Section 12.3.6 Example of Load Conversion shows an example conversion process in which
Figure 12-7 shows the MVA loads in the savnw.sav power flow case, as initially defined. That
conversion example re-allocates the loads with the result shown in Figure 12-8. The conversion
was done on all loads.
With that converted load as a starting point, the reconstruction can be done based on the realloca-
tions shown in Figure 12-9 above. The result is shown in Figure 12-10.
Figure 12-10. Reconstruction of Loads Based on Global 10% Reallocation
12-20
Program Operation Manual Ordering Network Buses for Matrix Manipulation

When reconstructing MVA loads based upon present bus voltages, for each bus processed, the
individual MVA loads represented by the three load characteristics are summed. This total load is
then split among the three load characteristics as specified. Using this load reconstruction option,
the network should be solved to an acceptable mismatch level when activity RCNL is specified, and
it remains in balance following the execution of activity RCNL.
When reconstructing loads based on unity voltage, the three load components are summed
assuming one per unit voltage, and this total load is split among the three load characteristics as
specified. The network will normally not be in balance following the execution of activity RCNL with
this load reconstruction option.
PSS®E GUI Users Guide, Section 17.1.3, Reconverting Load Characteristics
Section 14.3, Reconverting Load Characteristics
12.5 Ordering Network Buses for Matrix Manipulation

Activity ORDR
Run Activity ORDR - GUI

Power Flow > Solution > Order network for matrix operations (ORDR)…
[Order Network]
Run Line Mode Activity ORDR - CLI
ACTIVITY?
>>ORDR
None
The optimal ordering activity ORDR determines an ordering of the network buses such that sparsity
is maintained as the Jacobian matrix is triangularized in activities FNSL, NSOL, FDNS, INLF, and
ACCC, or the system admittance matrix is decomposed into its triangular factors in activities FACT
and BKDY and the linearized network analysis activities DCLF, DFAX, DCCC, OTDF, TLTG, SPIL,
and POLY.
Because it changes at least one bus type code, the generator conversion process (activity CONG)
must be followed by an ordering of the network buses such that sparsity is maintained as the Jaco-
bian matrix is triangularized in a variety of PSS®E analytical processes. The network bus ordering
generally takes place in the background. In the case, however, where the user is specifically setting
up conditions for the switching analysis, it is necessary to convert generators and order the network
as separate activities.
When the Assume all branches are in-service option is specified, activity ORDR ignores the service
status of all branches and assumes all branches connected to Type 1, 2, or 3 buses are in-service.
12-21
Ordering Network Buses for Matrix Manipulation Program Operation Manual
Thus, following the ordering, simple branch status changes do not require an additional execution
of activity ORDR.
When the Ignore out-of-service branches option is specified, activity ORDR recognizes the status
of network branches and ignores out-of-service branches in determining the bus ordering. Thus,
when a branch previously out-of-service is returned to service, activity ORDR should be executed
again. Branch status changes that do not isolate a bus do not require repeated executions of activity
ORDR. However, when a large number of branches have been taken out-of-service, this option may
result in a more efficient matrix storage, thereby decreasing both the time and memory required to
perform calculations using the network matrices.
Activity ORDR must be re-executed whenever any of the following takes place:
1. The addition of a bus or branch to the case.
2. A change to the Type code of a bus from 1 or 2 to 3 or 4, or vice versa. Note that this includes
the execution of those PSS®E activities such as CONG, DSCN, and TREE which have the
ability to modify bus type codes.
3. The removal of a bus from the case (e.g., via activities EXTR or EEQV).
4. If Ignore out-of-service branches was specified for the last execution of ORDR, the returning
to service of a branch which was out-of-service at the time of the previous ordering.
5. A change of an in-service branch from treatment as a zero impedance line to a non-zero

impedance line, or vice versa (refer to Section ).
Activities FNSL, FDNS, NSOL, INLF, ACCC, FACT, BKDY, and the linearized network activities
automatically run activity ORDR if the user has not explicitly done so prior to their selection.
The optimal ordering function is also performed, without being explicitly invoked, during activities
EEQV, SCEQ, SEQD, ASCC, ANSI, when network switching by dynamics models requires it, and
optionally following network data changes in activity ALTR.
Activity ORDR summarizes the results of the ordering by tabulating the following:
1. The number of DIAGONALS (rows) in the matrix.
2. The number of OFF-DIAGONALS corresponding to the number of non-zero super-diagonal

elements in the triangularized or factorized matrix during activities FACT and TYSL, the
linearized network analysis activities, the fault analysis activities, and dynamic simulations.
3. The number MAX SIZE, which represents the largest number of non-zero super-diagonal
elements present in the Jacobian matrix at some stage of the triangularization during activ-
ities FNSL, NSOL, FDNS, INLF, and ACCC.
®
PSS E GUI Users Guide, Section 17.2, Ordering Network Buses for Matrix Manipulation
Section 14.4, Ordering Network Buses for Matrix Manipulation
12-22
Program Operation Manual Factorizing the Network Admittance Matrix
12.6 Factorizing the Network Admittance Matrix

Activity FACT
Run Activity FACT - GUI

Power Flow > Solution > Factorize admittance matrix (FACT)
Run Line Mode Activity FACT - CLI
ACTIVITY?
>>FACT
None
12.6.1 About the Power Flow Network Admittance Matrix

Consider a bus, i, of a power network which connects two transmission lines, two transformers, and
a shunt element (see Figure 12-11).
Bus i is connected only to buses j, k, m, and n. Also note the designation of the tap-changing
side of each transformer.
n •
Transmission Line •j
Tap
Changer
i Transmission Line
• • k
•
m
•
Transformer
Tap Changer
Shunt Reactor and Capacitors
Figure 12-11. Equipment Connected at Bus, i
Each line and transformer may be represented by a per-unit equivalent circuit, with per-unit param-
eters being calculated from spacing, length, and nameplate data with respect to a common system
MVA base. The resulting equivalent circuit surrounding network node, i, which represents bus i in
the equivalent circuit of the whole system, is shown in Figure 12-12.
12-23
Factorizing the Network Admittance Matrix Program Operation Manual
n• tin : 1
•j
Zij
•
Zin B ij
2
•
B ij
i
• 2
•
• Zik
Zi m Ysi
1: tim
B ik
•
B lik 2
m • B ik •k
2
Figure 12-12. Equivalent Circuit for Node i of Transmission Network Model
The total current, ii, flowing into node i when voltages, vi, vj, vk, vm, and vn are applied to the
network are determined by adding up the flow into each leg of Figure 12-12 at its connection to node
i. In the case shown above, the total current, ii, is zero because there is no source or load connected
there. Hence:
ii = viYsi
viBij
+ (vi - vj) / zij +
2
viBik
+ (vi - vk) / zik + + viBlik
2
vi
+ - vm / zimtim
tim
vn
+ vi - / zin
tin
(12.1)
Expansion of Equation 12.1 for the i-th element of In, which is ii, gives:
n
ii =  yihvh
n=1 (12.2)
where
yih are the elements of Ynn
12-24
Program Operation Manual Factorizing the Network Admittance Matrix
and
vh are the elements of the node voltage vector, Vn

The expressions for the elements, yih, in terms of transmission line and transformer parameters can
be found by collecting terms in Equation 12.1 and comparing the result with Equation 12.2. The
construction of the individual elements, yii, of the network admittance matrix from the line and trans-
former data is a key section of all power flow solution procedures of PSS®E.
Examination of Equation 12.1 shows that only the diagonal element, yii, and four off-diagonal
elements, yih, of the i-th row of the admittance matrix are nonzero. That is, a line or transformer from
bus i to bus j contributes nonzero elements only to the i-th and j-th rows of Ynn. Realistic power
systems have between 1.5 and 2 transmission lines or transformers for each node. A transmission
network of 2000 buses might, therefore, be expected to have approximately 4000 branches and,
correspondingly, 8000 nonzero off-diagonal elements in its admittance matrix. This typical bus-to-
branch ratio results in very sparse admittance matrices. In the above example only 8000 out of
(2000) (2000-1), or 0.2% of the off-diagonal elements of Ynn are nonzero.
The great majority of modern power flow calculation programs, including those of PSS®E, take
advantage of this sparsity in their management of computer storage. They also take advantage of
procedures that allow the admittance matrix to be manipulated into triangular factor and partial
inverse forms which have similar sparsity properties, but where the number of nonzero off-diagonal
elements is typically two to three times the number of such elements in the original Ynn matrix.
Presenting a power flow program with a power system network model, for which original Ynn matrix
(or derivatives therefrom) has a number of nonzero elements that exceed the program’s allocated
capacity, results in an error condition that prevents the use of some, but not all, of the available
power flow iteration algorithms.
12.6.2 Operation of Activity FACT

The triangular factorization activity FACT decomposes the network admittance matrix (Y matrix) into
its upper and lower triangular factors for use in the triangularized Y matrix network solution (activity
TYSL) or in the network balance of dynamic simulations. This computation also takes place, without
being specifically invoked, by the following functions:
ASCC ASTR BKDY EEQV IECS

MSTR MRUN SEQD SCMU SCEQ
STRT RUN DYNAMICSMODE
Because activity FACT performs a computation involving the admittance matrix, it follows that it
must be re-executed any time this matrix changes and switching studies or dynamic simulations are
to be run. Thus, in these applications, activity FACT must be rerun any time one or more of the
following occurs:
• Change of load characteristic modeling via activities CONL or RCNL.

• Change of bus type code.
• Change of machine, branch or load status.
• Change of machine impedance parameters.
• Change of branch impedance or charging.
• Change of which branches are modeled as zero impedance lines.
12-25
Factorizing the Network Admittance Matrix Program Operation Manual
• Change of transformer ratio or phase shift angle.

• Change of bus or line connected shunt.
• Change of constant admittance load.
Activity FACT tabulates the number of non-zero diagonal and off-diagonal terms in each factor of
the matrix at the Progress tab.
Activity FACT requires the prior execution of activity CONG, usually activity CONL, and activity
ORDR. Refer also to Section 12.7.5 Application Notes. It prints an appropriate error message and
terminates if generators have not been converted (i.e., activity CONG has not been executed). If
activity FACT detects that a new execution of activity ORDR is required, a message is printed and
activity ORDR is automatically executed prior to the factorization.
12.6.3 Exporting the Power Flow Network Admittance Matrix

All or part of the network admittance ( Y ) matrix, as used in the PSS®E power flow solutions, may
be exported in the form of a source file. To initiate the output Y matrix function, select
File > Export > Network admittance matrix… from the GUI. The user selects the portion of the admit-
tance matrix to be produced from the following options:
• The entire admittance matrix.

• Admittance matrix rows corresponding to buses in the current bus subsystem, either
as currently defined, or as redefined in the [Bus Subsystem Selector].
• A specified set of buses.
Unless the all buses option is selected, all non-zero off-diagonal terms in the rows being processed
are produced by default. If this option is disabled, only off-diagonal terms corresponding to other
rows being processed are produced. The user directs the output to either a named file or to the
Progress tab.
The admittance matrix terms produced are extracted from the admittance constructed by, and used
during, the PSS®E power flow solution functions. As such, they include contributuins for constant
admittance loads, off-nominal tap ratios, phase shifts, and GNE-Y devices, but exclude constant
MVA load, constant current load, generator, switched shunt, dc line, FACTS device, GNE-PQ
device, and GNE-I device contributions. Furthermore, the admittance matrix used during the power
flow solutions excludes rows and columns for swing (i.e., Type 3) buses; this function also excludes
terms from these rows and columns unless generators are converted (i.e., activity CONG is
executed) prior to initiating this function.
Because the admittance matrix is extremely sparse, its terms are produced as a set of matrix terms,
using external bus numbers, as in the following example:
154, 154, 41.9126 , -404.786

154, 3008, -5.49574 , 44.7801
154, 153, -4.47154 , 40.2439
154, 205, -29.4701 , 297.380
154, 203, -2.47525 , 24.7525
12-26
Program Operation Manual Solving the Converted Case
®
PSS E GUI Users Guide, Section 17.3, Factorizing the Network Admittance Matrix
Section 14.5, Factorizing the Network Admittance Matrix
12.7 Solving the Converted Case

Activity TYSL
Run Activity TYSL - GUI

Power Flow > Solution > Solution for switching studies (TYSL)…
[Solution for Switching Studies]
Run Line Mode Activity TYSL - CLI
ACTIVITY?
>>TYSL
AB, NC, DC, FD
The triangularized Y matrix network solution activity TYSL is designed for those situations where
the internal flux linkages of generators are assumed to remain unchanged as a load or fault is
switched onto the system, as a line is opened or closed, or as a load is removed. It determines the
instantaneous change in network voltages as the switching operation takes place. This activity is
used for balanced short circuit, motor starting, voltage dip, and initial load rejection overvoltage
studies; this class of studies is called switching studies.
When the flat start option is specified, all bus voltages are reset to unity magnitude at zero phase
angle. Otherwise, the existing voltage vector in the working case is used as the initial voltage esti-
mate. During the solution, generator buses are not treated as they are in power flow solution
calculations. Rather, the Type 2 bus voltages become free variables just as the voltages at Type 1
buses, and a fixed source current is injected into the network at each generator bus (refer to
Figure 12-4).
Activity TYSL handles load boundary conditions and the blowup check in the same way as activity
SOLV. The solution convergence monitor, the dc transmission line monitors for two-terminal and
multi-terminal dc lines, and the mismatch summary are identical to those of activity SOLV. Refer to
Sections 6.3.11 and 6.3.13.
No automatic adjustments are allowed, and switched shunt devices and dc converter transformer
tap settings are locked at their pre-switching settings. A two-terminal or multi-terminal dc transmis-
sion line is blocked for the remainder of the current execution of activity TYSL if, on any iteration,
the ac voltage at a rectifier converter station bus falls below 50% or is insufficient to make margin
order. Shunt elements of FACTS devices hold their pre-switching reactive currents, and series
elements are held at their pre-switching series voltages.
For each in-service VSC dc line, the solution starts with each converter holding the active and reac-
tive power at the time activity CONG was executed. If, on any iteration, the corresponding current
exceeds the converter’s IMAX, the injection is reduced using the power weighting factor fraction
12-27
Solving the Converted Case Program Operation Manual
(PWF) just as in the conventional power flow solution activities. Each converter is treated indepen-
dently, so that any reduction at one converter does not affect the injection at the other end of the
VSC dc line. The dc transmission line monitor for VSC dc lines includes the dc line name, followed
by the ac power injection at each converter bus.
By default, activity TYSL has a convergence tolerance of 0.00001 on voltage change and a limit of
20 iterations. A deceleration factor, which has a default value of unity, is applied to the voltage
change at each bus. For optimum convergence characteristics, it may be advantageous to reduce
the deceleration factor, especially when a large fraction of the reactive load is represented by the
constant MVA and/or current characteristics. The presence of dc lines may also require some decel-
eration of the solution. The guideline of Section 6.3.19 Characteristics of Activity SOLV should be
used in tuning this parameter. The user may modify any of these solution parameters with the data
changing activity CHNG or the [Solution Parameters] dialog.
Activity TYSL requires that the factors of the network admittance matrix to be present in the admit-
tance matrix temporary file (i.e., it requires the prior execution of activity FACT).
Activity TYSL responds to the following interrupt control codes:
AB Abandon activity TYSL following completion of the next iteration.

NC Suppress the convergence monitor.
DC Tabulate conditions for each dc line after each iteration.
FD Tabulate the conditions for each in-service FACTS device after each iteration.
The following examples show switching cases and provide additional information for the process:
• Voltage rise on a line end

• Motor starting
• Fault application.
12-28
12.7.1 Example: Voltage Rise on Open Line End

The calculation of voltage on the open end of a line is often required to examine the conditions
which could be encountered by line connected reactors; by surge arresters and by breakers. The
latter have limits of voltage across the open break within the equipment. Voltage on the line side
could be high while voltage on the system side could have fallen due to loss of the line’s incoming
power.
This example will open the line from bus 151 to bus 152, circuit 1, at the end terminating on bus
152, in the savnw.sav power flow case. Figure 12-13 shows the power flow diagram for these
buses.
Figure 12-13. Example – Circuits from Bus 151 to Bus 152
One way of performing the breaker operation, is to establish a dummy bus on the circuit from bus
151 to bus 152 which is connected to Bus 152 via a zero impedance line. To open the breaker it
would require taking the zero impedance line out of service (see Figure 12-14). The circuit from bus
151 to the dummy bus 999 will have the same line parameters as the actual circuit from bus 151 to
bus 152 circuit 1. When the zero impedance line between bus 999 and bus 152 is opened, circuit 1
from bus 151 will be connected at bus 151 and hanging open. The post-switching voltage at bus
999 is the line-end voltage of interest together with the voltage at bus 152.
12-29
Figure 12-14. Opening a Line at One End
To avoid having to pre-view the need for dummy buses, activity SPLT can be used. Here the user
would split bus 152 and move circuit 1 to bus 151 to a new bus automatically created by the program
and provided with a unique new number.
Figure 12-15. Producing an Open Line End with Activity SPLT
The diagram will indicate that circuit 1 is open (purple line) but the user has to grow the diagram to
show the new bus and line to 151.
The bus split will introduce a new zero impedance branch between bus 999 and bus 152. The
user will open this zero impedance line to perform the line opening. Furthermore, the new bus;
the new line to bus 151 and the zero impedance branch will be seen in the Tree View and the
Spreadsheet View.
12-30
The sequence of events for this model is:
1. Convert the power flow case (activity CONG) and order the network buses (activity ORDR).
2. Split the bus (activity SPLT) and open the new zero impedance line to create an open ended
line.
3. Factorize the matrix (activity FACT).
4. Perform the Y matrix solution (activity TYSL).
Now the voltages can be examined with a bus based report or by examining the solution shown in
the diagram.
12.7.2 Example: Open Line End Results

It is interesting to look at the bus voltages, in this example, on buses 151, 152 and 9999 for the
power flow condition, for the post switching condition and for a condition obtained by opening the
line in the unconverted power flow case and solving with a conventional solution (e.g., Gauss-
Seidel). This latter case will show conditions after all the voltage regulation devices have had time
to operate to adjust back to set-point voltages (V long-term).
Table 12-1. Results of Line Open End Balanced Switching Calculation
Results of Line Open Operation

Bus Number V pre-switch V post-switch V long-term
151 1.012 1.023 1.015
152 1.017 0.996 0.981
9999 -- 1.112 1.104
It can be seen that immediately after switching the voltage at bus 152 drops because of the sudden
loss of incoming power and the need for greater voltage support. The voltage at bus 151 rises
slightly because, in part, of unconsumed reactive power from the open line. The line end voltage
has increased from its original level of 1.017 pu to 1.112 pu (see Table 12-1 Results of Line Open
End Balanced Switching Calculation).
Following voltage regulator action, the voltage at all buses has been reduced to a new steady-state
level. The voltage at the open end is elevated but reasonable for sustained operation.
12.7.3 Example: Motor Starting

A fairly common switching study requirement is illustrated by Figure 12-16. One of a pair of large
motors is running under load, and the second one is to be started by switching it directly onto the
bus. The extent of the voltage dip produced by switching on the second motor is needed for the
coordination of overcurrent and undervoltage protection.
The example will assume a load at bus 3006, in the savnw.sav power flow case, to consist of two
large motors which, at full load and unity voltage, draw (7.5 + j3.95) MVA each. The starting current
for one motor is given in specification data as 2.72 times rated current at 0.275 power factor. The
calculation in Figure 12-16 shows that this starting duty corresponds to an initial shunt admittance
of (0.0625 j0.218) per unit, relative to a 100-MVA base (I = YV), and nominal voltage.
12-31
7.5 MW 0.89 pf (Running)
7.5 MW 0.89 pf (Starting)
Starting current = 2.72  rated at 0.275 pf

Starting admittance
0.075
= 2.72  ---------------  cos  – j sin  
0.89 s s
= 0.227  0.275 – j0.961 
= 0.0625 – j0.218 7.5 + j3.95 MW
G + jB = 0.0625 - j0.218
Figure 12-16. Motor Starting Example
The switching operation comprises the connection of the starting admittance to the case. As previ-
ously discussed, the user will convert and order the power flow case; then connect the admittance
to bus 3006 then factorize and perform the Y matrix solution. Note that the starting admittance is on
a 100 MVA base. This means that the user should add a shunt of 6.25 -j21.8 MVA which is the MVA
at 1.0 pu voltage. Figure 12-17 shows the bus based report for bus 3006.
Figure 12-17. Bus Based Report Following Motor Starting
It can be seen that the inrush is 85.6 MVA at 0.987 pu voltage. The initial voltage was 0.993 pu,
indicating a voltage dip of only less than 1.0%.
Notice that the load on the bus (the other motor) was converted to 100% constant current for real
power and 100% constant admittance for reactive power.
12-32
12.7.4 Example: Fault Current

Because these examples lie within the realm of balanced switching, the only faults which can be
analyzed are three-phase faults.
In the case of a three-phase fault, the switching operation which is performed before factorization
and solution is the connection of a very large reactive admittance to ground at the fault point. A
value of -j1E9 is adequate. After a solution has been obtained for the instant, t+ output of results is
handled by the standard power flow output formats such as the bus based reports. Such a bus
based report will provide the fault point and branch information (see Figure 12-18).
i v  per unit
i i
MVA P ij + jQ ij = MVA ij
ij
I = ------------------------------- per unit
ij SBASE  V
i
P + jQ = (0. + j0.)
ij ji
MVA = 0.
ji
j
v=0 MVA jk = 0.
Z = (0. + j0.)
f
MVA
kj
= P k + Qkj
V 
k k
MVA
kj
I kj = --------------------------------- per unit
SBASE  V
k
Figure 12-18. Calculation of Branch Currents Flowing into a Bus Faulted

through Zero-Impedance
The format of the bus based report will be unchanged except that it will display the net current
flowing to ground at any bus where voltage is below 0.1 per unit. This current value is expressed in
terms of fault MVA where
FAULT MVA = 3 × (Base Voltage, kV) × (Current, A) × 10-3
12-33
Because the output reports display power flow results, the current flowing in faults and branches
must be calculated from the displays of voltage and complex power or MVA flow. Current in
amperes is obtained from
MVA flow
|Current| = A
3 × (Voltage, kV) × (1 × 10-3)
Per-unit current is obtained from
MVA flow per unit

|Current| =
(System Base MVA) × (Voltage per unit)
The calculation of currents flowing into a bus faulted through a zero impedance is illustrated by
Figure 12-18. Because the voltage at the faulted bus is zero, the MVA flows into it are zero even
though the currents are nonzero. The currents in the branches feeding the fault must be determined
from the MVA flows and voltages at the ends that are away from the fault.
Figure 12-19 shows the output report for a fault on bus 3006, in the savnw.sav power flow case.
Output is for the faulted and two adjacent buses.
pu current contribution = MVA / (SBASE x V) Fault MVA = 3166.4 i.e.
= 326.9 / (100 x 0.3144) = 10.397 pu fault current = 31.66 pu
Figure 12-19. Bus Based Output for Three-phase Balanced Fault on Bus 3006
12-34

Activity TYSL is not a power flow solution; it is unable to handle the power flow style representation
of generator buses (i.e., fixed power and voltage). But, for networks in which generators are repre-
sented by constant internal flux linkages (i.e., following activity CONG), activity TYSL is capable of
producing very small mismatches in only a few iterations. (Note that its default convergence toler-
ance is an order of magnitude smaller than that of activities SOLV and MSLV!). It is much less
sensitive to the values of branch impedances than the other network solution activities.
The use of activity TYSL for switching study network solutions involves operations upon the factor-
ized system admittance matrix. Thus, a typical sequencing of activities is:
1. A standard power flow is converged to an acceptable mismatch level using one or more of
activities SOLV, MSLV, FNSL, NSOL, or FDNS. It is strongly recommended that the solved
power flow case be saved in a Saved Case File with activity SAVE.
2. Activity CONG is executed to convert generator buses from their power flow representation
to the constant Norton current source representation used in activity TYSL. See also
Figure 12-4.
3. Activity CONL is executed to convert the load boundary conditions from the conventional
constant MVA characteristic used in power flow calculations to a representation suitable for
network conditions involving abnormally low or high voltages (refer to Load Data and
Section 6.3.13 Load).
4. Activity ORDR is executed to determine a bus ordering of the admittance matrix such that
its sparsity characteristics are preserved. A new bus ordering is required because the
execution of activity CONG introduces a row and column into the admittance matrix for each
former Type 3 (swing) bus.
5. Optionally, this converted and ordered case may be saved with activity SAVE if several
switching solutions are to be calculated from this base condition.
6. Apply the switching via activity CHNG or the [Solution Parameters] dialog, factorize the corre-
sponding admittance matrix with activity FACT, and balance the network with activity TYSL.
7. The standard power flow output reporting activities (e.g., POUT, VCHK, etc.) are used to
examine the results of the post-switching network solution.
8. Additional switchings may be imposed on the same base condition by retrieving the
converted case saved in step 5 and proceeding to step 6.
Note again that activity TYSL requires that the factorized admittance matrix, representing the
switching operation imposed upon the pre-switching network condition, be present in the admit-
tance matrix temporary file.
®
PSS E GUI Users Guide, Section 17.4, Solving the Converted Case
Section 14.6, Solving the Converted Case
12-35
12-36
Chapter 13
Transmission Pricing and
Open Access
Chapter 13 - Transmission Pricing and Open Access
13.1 Overview: Open Access and Pricing

Activity Open Access and Pricing
The electric utility industry restructuring, prevalent in the United States and many other countries in
the close of the 20th century has generated interest in analytic tools for transaction processing.
Open Access and Pricing Activities (OPA) have been introduced to the power flow processor to aid
in assessing transaction feasibility, and cost allocation. In PSS®E, the transaction feasibility assess-
ment is supported by a transaction impact calculator and a line loading relief calculator. The
transmission cost allocation technique mandated by the Public Utility Commission of Texas for
computing the impact fee component of transmission usage fee is provided in the PSS®E allocation
function. Transmission loss allocation techniques also are provided.
OPA requires a power flow model, which can be employed to produce a valid dc power flow solution,
be imported into PSS®E. This model is then augmented with transaction data. Transaction data
includes transaction event definitions.
A transaction event consists of the following attributes:
• A unique number used for reporting, for defining sequence order, and for referring to
transactions in program dialog.
• An alpha numeric label.
• Service status.
• Priority for grouping and ranking.
• A magnitude value in MW.
• A curtailment value in MW.
• A list of participating network buses.
Buses participate in a transaction as points of power injection into or demand from the power
system network. An in-service transaction of nonzero magnitude will result in power flows on trans-
mission branch elements. Load and generation input values are associated with each participating
bus. A bus participates as a power injection point when its generation value is greater than zero or
its load value is less than zero. A bus participates as a power demand point when its load value is
greater than zero or its generation value is less than zero. The injection or demand magnitude is a
function of the transaction magnitude, the load and generation values, and for some functions, the
transaction curtailment value.
13-1
Transmission Pricing and Open Access PSS®E 34.2
Managing Transaction Data Program Operation Manual
Transmission cost and loss allocation methods are concerned with branch ownership and control
area, respectively. The flow or loss impact of a branch is computed and accumulated by owner or
control area.
13.2 Managing Transaction Data

Activity Transaction Data
Each transaction event the user first assigns a set of transaction attributes and then identifies which
buses will be participating in the transaction event. The transaction attributes are the following:
ID A Transaction event number. ID = 0 by default.

DESCRIPTION Alphanumeric label assigned to the transaction event. The label may be up to
twenty four characters and may contain any combination of blanks, upper-
case letters, numbers and special characters. LABEL is twenty four blanks by
default.
STATUS Transaction event status: 0 for out-of-service, 1 for in-service. STATUS = 0 by
default.
PRIORITY Transaction event priority. This integer value priority number is used to group
transactions into sets. IPR = 0 by default.
MAGNITUDE Transaction event magnitude in MW. MAG = 0.0 by default.
CURTAILMENT Transaction event curtailment magnitude in MW. CURT = 0.0 by default.
For each transaction event the user identifies which will be the participating buses. For each partic-
ipating bus, the following information is required:
I Bus number. I = 0 by default.

LOAD Participating bus load value. LV = 0.0 by default.Can be negative.
GENERATION Participating bus generation value. GV = 0.0 by default.Can be negative.
Table 13-1 Example of Transaction Data for Two Transactions shows an example transaction data
consisting of two transaction events.
Table 13-1. Example of Transaction Data for Two Transactions
Typical Transaction Data

First Transaction
6 UPSTART 1 1 200.0 0.0 Transaction Attributes
3008 1.0000 .0000
Participating Buses
102 .0000 .2667
Second Transaction
5 WORLD 1 1 354.0 0.0 Transaction Attributes
13-2
PSS®E 34.2 Transmission Pricing and Open Access
Program Operation Manual Calculating Transaction Event Impact on Monitored Elements
Table 13-1. Example of Transaction Data for Two Transactions (Cont.)
Typical Transaction Data

3008 .0000 1.0000
3007 1.0000 1.0000
3006 1.0000 1.0000
3005 1.0000 1.0000 Participating Buses
3004 .0000 1.0000
3003 .0000 1.0000
3002 .0000 1.0000
Data is facilitated in the [Transaction Data] dialog. Both attribute and bus data can be modified. Note
that the data is neither saved nor retrieved with the power flow case. It is only temporarily available
for the Transmission Access analyses.
13.2.1 Transmission Access Calculators

PSS®E provides two calculators. They are:
• Calculation of incremental monitored element MW flow impacts due to transaction

events (activity IMPC)
• Calculation of the active power flow on monitored elements as a function of transaction
events. This Line Loading Relief calculation (activity LLRF) is used to: determine the
transfer distribution factors on all monitored elements due to all transaction events;
determine the incremental curtailment of transaction events required to achieve an
incremental flow change on a target monitored element; and determine the incremental
restoration of previously curtailed transaction events needed to achieve an incremental
flow change on a target monitored element.
13.3 Calculating Transaction Event Impact on Monitored

Elements
Activity IMPC
Run Activity IMPC - GUI

Trans Access > Calculators > Impact on monitored elements…
[Impact on Monitored Elements]
Run Line Mode Activity IMPC - CLI
ACTIVITY?
>>IMPC
13-3
Calculating Transaction Event Impact on Monitored Elements Program Operation Manual

AB
Activity IMPC computes and reports the incremental MW flow impact on a set of monitored
elements due to a single transaction event.
The user must enter the name of a Distribution Factor Data File constructed by activity DFAX which
IMPC.
The Distribution Factor Data File defines the monitored element set. It employs the transaction
magnitude, without regard to the curtailment value, to determine the power injections and demands
at participating buses. It employs the linearized solution technique to compute the incremental
element flows. Regulating in-service phase shifting transformers have zero incremental MW flow.
The user may provide the name of an ATC Updates File, which is optional. This file may modify the
monitored interface ratings employed in the report as available transfer capability (ATC). The ATC
Updates File consists of one or more records, each consisting of two fields, a text field which iden-
tifies an interface by twelve character label and a numeric value field which identifies the interface
ATC in MW.
Activity IMPC may be terminated by entering the AB interrupt control code.
The impact calculator produces a report which illustrates the incremental MW flow impacts on each
of the monitored elements, along with the initial available transfer capability (ATC) for the element
and a final ATC which is adjusted for the flow impact due to the transaction. For monitored inter-
faces, a value is provided which illustrates the maximum transaction magnitude that can be
supported by the element’s ATC.
13-4
Program Operation Manual Calculating Transaction Event Impact on Monitored Elements

Both narrow and wide report formats are employed. The column width employed for the output
report depends on the selection of output device. The report begins with an initial page header
followed by four records which identify the source of Distribution Factor and Linear Network Anal-
ysis Data Files.
The remainder of the report is divided into two sections. The first section reports impacts for all
monitored branches contained in the Distribution Factor Data File. The second section reports
impacts for all monitored interfaces. The selected transaction event is identified and followed by a
table of monitored elements. The transaction event identification includes: transaction event
number, transaction event label and transaction magnitude. Each record of the monitored element
table includes: a monitored element description, an initial ATC value in MW, the incremental MW
flow impact on the monitored element due to the transaction event, and a final (adjusted for incre-
mental flow) ATC value in MW. Branch RATEA values are employed as ATC values for monitored
branches. Monitored interface ATC values default to the interface RATEA and may be adjusted by
entries in the ATC Updates File.
For monitored branches the monitored element description consists of: from bus number and name,
to bus number and name, and circuit id. For monitored interfaces the twelve character monitored
element label is employed as the monitored element description.
The monitored interface table includes an additional column of numeric values. These values illus-
trate the transaction magnitude, in MW, which would result in a final ATC value of zero for that
element. This maximum transaction field will take a value only when the initial ATC and incremental
flow values are of the same sign and when the incremental flow value magnitude significantly
exceeds zero.
13.3.2 Example: Transaction Event Impact on Monitored Elements

Using the savnw.sav power flow case and the associated data files (savnw.sub/.mon/.con), all of
which are available in the PSSE/EXAMPLE directory in the user’s installation, an example case is
run using Transaction #6.
The report generated by the impact calculation is shown in Figure 13-1.
13-5
Calculating Line Loading Relief Program Operation Manual
Figure 13-1. Results of Impact Calculation

Activity IMPC uses the same linearized network model as activity DCLF. Thus, the comments in
Section 8.4.4 Application Notes apply here as well. Regulating in-service phase shifting trans-
formers hold constant MW flow.
Section 18.2, Calculating Transaction Event Impact on Monitored Elements
Section 15.1, Calculating Transaction Event Impact on Monitored Elements
13.4 Calculating Line Loading Relief

Activity LLRF
Run Activity LLRF - GUI

Trans Access > Calculators > Line loading relief by transaction adjustment…
[Line Loading Relief by Transaction Adjustment]
Run Line Mode Activity LLRF - CLI
ACTIVITY?
>>LLRF
>>
AB
13-6
Program Operation Manual Calculating Line Loading Relief
Activity LLRF provides a menu of functions related to computing transaction magnitude adjust-
ments which result in feasible monitored element branch MW flows. It performs various analyses
related to identifying the active power flow on monitored elements as a function of transaction
events. LLRF is used to:
• Determine the transfer distribution factors on all monitored elements due to all transac-
tion events
• Determine the incremental curtailment of transaction events required to achieve an
incremental flow change on a target monitored element
• Determine the incremental restoration of previously curtailed transaction events
needed to achieve an incremental flow change on a target monitored element.
Activity LLRF uses a Distribution Factor Data File to define the monitored element set. It employs
the transaction magnitude an the curtailment value to determine the power injections and demands
at participating buses. It employs the linearized solution technique to compute monitored element
distribution factors and the incremental element flows. Regulating in-service phase shifting trans-
formers have zero incremental MW flow. It reflects adjustments in the transaction curtailment value.
The user may specify the desired MW flow increment on a monitored element. This incremental flow
value may, for example, represent the amount by which the element is overloaded. The line loading
relief calculator will report adjustments to transaction magnitudes required to satisfy this incre-
mental flow. These transaction adjustments may be limited to transaction curtailment (i.e.,
increases in transaction curtailment value magnitude not to exceed the transaction magnitude
value) or transaction restoration (i.e., decreases in transaction curtailment value magnitude).
Transactions participate in adjustment as a function of their transaction priority and the applied
adjustment method. Four adjustment methods are available: first in last out, decreasing order by
distribution factor magnitude, pro rata by distribution factor magnitude, and pro rata by the product
of distribution factor with transaction schedule (transaction magnitude less curtailment). Transac-
tions are excluded from adjustment when their distribution factor magnitude is less than a user-
specified tolerance. Individual events are grouped by priority. The curtail transactions function
proceeds to investigate the priorities from lowest to highest priority number until the incremental
flow target is satisfied or all transaction priority groups are exhausted. The restore transactions
function proceeds to investigate the priorities from highest to lowest priority number until the incre-
mental flow target is satisfied or all transaction priority groups are exhausted.
The line loading relief calculator produces reports which illustrate:
• Transaction adjustments which result in a specified incremental flow on a selected

monitored element.
• Distribution factors (i.e., sensitivity of monitored element MW flow to transaction mag-
nitude) for all monitored elements and transaction events).
13.4.1 Operation of Activity LLRF

The user must enter the name of a Distribution Factor Data File constructed by activity DFAX which
13-7
Calculating Line Loading Relief Program Operation Manual
LLRF.
When the distribution factor file is identified, the monitored element list (from a *.mon file) is tabu-
lated in the window.
Table 13-2. Line Loading Relief Calculator Functions
Line Loading
Relief Function Calculation
Curtail Specify the target element from the list of monitored elements and define
or the incremental flow target element adjustment value in MW. The con-
ventions for positive and negative element flow are defined when
Restore
presenting the monitored element list to activity DFAX.
DF Report Activity LLRF produces a report of transfer distribution factors for all
monitored elements due to all transactions events. Out-of-service trans-
action events will have distribution factors of zero.
Distribution If the reset distribution factor tolerance is specified, activity LLRF
factor requires a new value of distribution factor tolerance. This tolerance is
tolerance employed to preclude those transaction events with negligible effect on
the target monitored element from the transaction adjustment functions
The user specifies the association method for adjustment. Four transaction event adjustment
methods are available:
• First in last out (FILO)

• Decreasing order of distribution factor magnitude (DF-ORDER)
• Distribution factor pro rata (DF-PRO RATA)
• Pro rata base on the product of distribution factor with transaction schedule
(DF-SCHED-PRO RATA)
A transaction’s schedule is the transaction magnitude less curtailment. The user may alter the
adjustment method associated with each transaction event priority.
Individual events, where distribution factors exceed a tolerance, are grouped by priority. The curtail
transactions function investigates the priorities from lowest to highest priority number until the incre-
mental flow target is satisfied or all transaction priority groups are exhausted. The restore
transactions function investigates the priorities from highest to lowest priority number until the incre-
mental flow target is satisfied or all transaction priority groups are exhausted.
Having updated the adjustment method associations activity LLRF produces a report of transaction
adjustments and the effect of each on the target monitored element. The transaction event curtail-
ment values are updated by the reported adjustments.
Activity LLRF may be terminated by entering the AB interrupt control code.

Both narrow and wide report formats are employed. The column width employed for the output
reports depends on the selection of output device. All reports begin with an initial page header
13-8
Program Operation Manual Calculating Line Loading Relief
followed by four records which identify the source of the Distribution Factor Data File and the Linear
Network Analysis Data Files.
Curtailing and Restoring Transactions

Following the Distribution Factor Data File and the Linear Network Analysis Data Files summary,
the target element and target adjustment MW value are reported. This is followed by a table which
illustrates for each affected transaction event: the transaction event number, the transaction event
priority, the transaction event label, the initial transaction schedule (transaction event magnitude
less curtailment) in MW, the schedule adjustment in MW (increment used to update the transaction
event curtailment), the final transaction schedule in MW, and the impact of this adjustment on the
target element in MW. A statement which indicates if the adjustment target MW value is satisfied
follows the table.
Distribution Factor Matrix

The distribution factor matrix is reported after the Distribution Factor Data File and the Linear
Network Analysis Data Files summary. Rows of this matrix are the transaction events. These are
identified by transaction event number, transaction priority, and transaction label. Columns of the
matrix are monitored elements. The column headers are limited to twelve characters. For monitored
branches these headers are references to a monitored branch legend. For monitored interfaces the
headers are the interface labels. The matrix presentation is wrapped across multiple records when
the number of columns to be presented exceeds the presentation width.
The distribution factor values of the matrix represent the sensitivity of monitored element MW flow
to transaction event magnitude. A positive value indicates that the monitored element flow will
increase with increasing transaction event magnitude.
The distribution factor matrix is followed by a monitored branch legend which cross references the
column labels employed in the matrix with monitored branches. The branch descriptions include
from bus number and extended name, to bus number and extended name and circuit id.
13-9
Making Allocations Program Operation Manual

Activity LLRF uses the same linearized network model as is used in activity DCLF. Thus, the
comments in Section 8.4.4 Application Notes apply here as well. Regulating in-service phase
shifting transformers hold constant MW flow.
Transaction events may be adjusted by the curtailment or restoration functions when their distribu-
tion factor magnitudes exceed the distribution factor tolerance and are of the correct sign with
respect to the sign of the adjustment MW value (e.g., having opposite sign for curtailment and the
same sign for restoration).
When performing curtailment, the adjustment magnitude limit for each transaction event is equal to
the transaction event magnitude less the initial curtailment magnitude. When performing restoration
the adjustment magnitude limit for each transaction event is equal to the initial transaction event
curtailment magnitude. Adjustments resulting from the curtailment and restoration functions update
the transaction event curtailment magnitude.
®
PSS E GUI Users Guide, Section 18.3, Calculating Line Loading Relief
Section 15.2, Calculating Line Loading Relief
13.5 Making Allocations

Activity ALOC
Run Activity ALOC - GUI

Trans Access > Allocations > Megawatt shift factors…
[Megawatt Shift Factors]
Trans Access > Allocations > Vector Absolute MW-mile
[Vector Absolute MW-mile]
Trans Access > Allocations > Vector Absolute MW-ohm
[Vector Absolute MW-ohm]
Trans Access > Allocations > Vector Sum MW-ohm
[Vector Sum MW-ohm]
Run Line Mode Activity ALOC - CLI
ACTIVITY?
>>ALOC
SELECT THE ALLOCATION TYPE,

None
Activity ALOC performs various analyses related to identifying the MW-mile impact of transaction
events on transmission facility owners. ALOC is used to:
13-10
Program Operation Manual Making Allocations
• Determine the MW-mile impacts of all transaction events on all transmission facility
owners.
• Determine the active power generation on MW-mile shift factors of an individual event
on all transmission facility owners.
• Determine the MW-ohm impacts of all transaction events on all control areas.
• Determine the active power generation on MW-ohm shift factors of a individual event
on all control areas.
• Report the total branch mileage of each transmission facility owner.
Activity ALOC employs the Vector Absolute MW-Mile method as required by the Public Utility
Commission of Texas for computing the impact fee (refer to PUCT Substantive Rule 23.67, Open-
Access Comparable Transmission Service, and PUCT Substantive Rule 23.70, Terms and Condi-
tions of Open-Access Comparable Transmission Service).
The user must specify one of the following reports;
• Vector Absolute Megawatt-mile

• Generation on Megawatt-mile shift factors
• Vector Absolute Megawatt-ohm
• Generation on MW-ohm shift factors (employing the Vector Absolute method)
• Vector Sum Megawatt-ohm
• Branch mileage summary by owner
If specifying Vector Absolute MW-mile, Vector Absolute MW-ohm, Vector MW-ohm, or mileage
summary, the report is produced at the specified output destination.
If specifying Generation on MW-mile shift factors or Generation on MW-ohm shift factors the user
must specify a transaction event. The report for that event is produced at the specified output desti-
nation (refer to Section 4.4 Virtual Output Devices).

Transmission allocation reports and related transaction event worksheets are generated to provide
an accounting basis which illustrates the impact on the transmission system due to transaction
events. The accounting basis may be used to allocate embedded transmission costs or controls
area losses among the various transaction events making use of the transmission networks.
All other reports produced by activity ALOC are formatted for import to a spreadsheet program.
Selections from the Graphical User Interface menu bar result in spreadsheet formatted reports.
Reports formatted for import to a spreadsheet program include an initial record of text fields for use
as column headings in a spreadsheet table. The first field of each subsequent record provides a
row label. All other fields are numeric data.
The Branch Mileage Report contains only the branch mileage summary by owner and is displayed
at the Report tab.
A Vector Absolute MW-Mile (VAMM) method is used to produce the transmission embedded cost
allocation. MW-mile methods are techniques for ascribing the use of the electric power transmission
system among the various beneficiaries. These are accounting practices which rely on engineering
analysis to determine the basis. This basic accounting unit is the product of branch MW flow with
branch length.
13-11
The VAMM method determines the impact for each individual transaction event by perturbing each
bus generation associated with the event against the associated event load. For each perturbation,
the absolute value of change in branch flow (i.e., change from the initial condition power flow model)
is multiplied by the branch length in miles, and this result is accumulated in the event’s MW-Mile
vector, one entry for each branch owner of the power flow model (i.e., each facility owner) as illus-
trated in Equation 13.1.
NAGj NALi
MWMij =   |Pl|Ll
k l (13.1)
where:
MWMij = MW-Mile impact for the ith owner and jth transaction event.
NAGj = Number of jth transaction event associated generators.
NALi = Number of branches owned by the ith owner (transmission facility owner).
P = Incremental MW branch flow due to perturbing MW generation.
L = Branch length in miles.
The union of these vectors for each transaction event forms an aggregate MW-Mile allocation
matrix. This matrix is then employed in a spreadsheet program to allocate each facilities owner’s
cost of service among the transaction events, each transaction event being responsible for costs in
proportion to the ratio of its impact to the total impact on that facilities owner.
The aggregate MW-Mile allocation matrix may be constructed directly by using a procedure which
repeatedly perturbs the participating generation buses for each of the various transaction events,
computing the flow impact and accumulating the impacts into the appropriate matrix positions. The
aggregate matrix may also be constructed as the union of impact vectors, one for each transaction,
where these impact vectors are computed by a transaction event worksheet.
Transaction event worksheets compute an impact vector as a product of generation vector with a
coefficient matrix; a generation on MW-Mile shift factor matrix. An element of this coefficient matrix
is the sensitivity of the MW-mile impact on a facility owner to the generation output of a participating
bus. The matrix elements have units of MW-Mile per MW. The inner summation of Equation 13.1 is
used to compute the elements of the generation on MW-Mile shift factor matrix, where the genera-
tion perturbation magnitude is 1.0 MW. Computing the aggregate MW-Mile allocation matrix in this
manner while more involved, provides for analyzing the impact of various generation dispatch
scenarios with the spreadsheet program. A generation vector can be selected which satisfies the
demand and minimizes the transmission cost.
The reports generated can produce information for allocating control area transmission losses
among the various transaction events. Two loss allocation methods are available, the Vector Abso-
lute MW-Ohm (VAMO) and the Vector Sum MW-Ohm (VSMO). As with the MW-Mile methods,
these MW-Ohm methods are accounting practices which rely on engineering analysis to determine
the basis. This basic accounting unit is the product of branch MW flow with branch per unit
resistance.
The computation required to produce both the VAMO and the VSMO aggregate allocation matrices
is that described in Equation 13.1 modified as follows:
• Branch length is replaced by branch per unit resistance.
13-12
Program Operation Manual Making Allocations
• The inner summation is over branches as part of the control area as opposed to branch
owners.
• For VSMO, only the signed value as opposed to the absolute value of incremental
branch flow is employed.
The generated reports may be directed to produce the aggregate allocation matrix for any of the
VAMM, VAMO, or VSMO methods. It may also be directed to report the generation vector and the
shift factor matrix for both the VAMM and VAMO methods. Furthermore the generated reports can
include the summation of branch mileage for each facility owning area. This mileage report is useful
for checking the integrity of the mileage and joint branch ownership data.
13-13

Activity ALOC uses the same linearized network model as is used in activity DCLF. Thus, the
comments in Section 8.4.4 Application Notes apply here as well. Regulating in-service phase
shifting transformers hold constant angle.
®
PSS E GUI Users Guide, Section 18.4, Making Allocations
Section 15.3, Making Allocations
13-14
Chapter 14
Optimal Power Flow
Chapter 14 - Optimal Power Flow
14.1 Overview
The PSS®E OPF application complements the main PSS®E power flow program. A valid power
flow data model must be present in the current PSS®E power flow working case before any OPF
activities can be successfully executed. The power flow case does not necessarily need to be
solved.
To put the power of the OPF in perspective, it may be easiest to contrast it with the traditional power
flow. With the traditional power flow, a significant amount of time is often spent trying to achieve an
good solution. Multiple iterations are required in which solution executions are performed, results
are analyzed and new estimates of the control values are determined for use in the next solution.
Much time may be spent trying to parametrically determine what values of the controls will provide
a feasible solution. If estimates prove to be unacceptable, as may result in a violation in the oper-
ating criteria, new estimates must be provided and the procedure started again. This can often
prove to be a very costly cycle.
The optimal power flow, on the other hand, provides a completely analytic model, one which auto-
matically changes certain control variables to arrive at the best solution with respect to a stated
quantitative performance measure (i.e. objective function). It efficiently achieves this result by
formulating and solving an optimization problem, defining the goal as a combination of objective
functions and a set of variable constraints to satisfy. After the problem statement is set up, the OPF
often requires much less user intervention than the power flow.
PSS®E OPF formulates and solves the optimization problem within constraints, and automatically
updates any power flow data values affected by the solution. Upon completion of the solution,
results are presented in one or more formatted reports and output files.
Optimal power flow activities are not sensitive to any interrupt control code options.
The following sections provide more detailed information for:
• the optimal power flow analytical model

• how it relates to the standard power flow
• a description for each power flow data model used within the PSS®E OPF
• models employed specifically within the OPF
• OPF algorithm and the solution process.
14-1
Optimal Power Flow PSS®E 34.2
Conventional Power Flow Program Operation Manual
14.2 Conventional Power Flow

The OPF solves an optimization problem with side conditions. To place this problem in context, the
conventional power flow problem is presented first and then contrasted with the optimal power flow
problem.
The conventional power flow problem solves a series of simultaneous nonlinear equations which
ensure that the net complex power injection at every bus is equivalent to the sum of complex power
flows on each connected branch.
N
SGi - SLi =  Sij
j=1
(14.1)
where:
N = Total number of buses,

SGi = Net complex power generation at bus i,
SLi = Net complex load at bus i,
Sij = Complex power flow on branch connecting buses i and j.
Bus power injections and branch power flows are expressed as functions of complex bus voltage.
Through the iterative solution process, a bus voltage vector is determined which satisfies these
equality constraints to within a mismatch tolerance.
One criteria for a desired solution might require that a dependent variable set, such as a group of
bus voltage magnitudes and branch flows, must satisfy maximum and minimum limits. The power
flow model may offer a set of automatic controls for which the values vary independently as func-
tions of local objectives. For example, generator reactive power varies continuously to control the
machine’s terminal bus or some remote bus voltage magnitude. Other controlling equipment may
include transformer tap ratios, transformer phase shift angles, susceptive bus shunts, dc converter
control angles, etc.
It is unlikely that sufficient controlling equipment exists such that an individual control may be
assigned to each dependent variable. In addition, the control variable range is limited and may be
insufficient to satisfy a local objective. This latter condition is especially apparent when local objec-
tives conflict. It is necessary therefore, for the analyst to manually vary either the control values or
their local objectives to attempt to achieve a good solution. By observing the impact of parametric
variations, the analyst develops an intuition of the power system model. This is likely to be a long
and tedious process however.
14.3 Optimal Power Flow

Activity NOPF
The optimal power flow is distinguished from the traditional power flow in that it solves an optimiza-
tion problem consisting of an objective function augmented by equality and inequality constraints.
The optimal power flow algorithms solve a nonlinear problem of the following form:
minimize f(x,y)
subject to: equality constraints, and inequality constraints
14-2
PSS®E 34.2 Optimal Power Flow
Program Operation Manual Optimal Power Flow
where:
• The minimization objective may consist of one or more functions such as fuel cost,
transmission losses, etc.
• The equality constraints constitute such items as the power flow equations presented
in (14.1) which ensure that the net power injection at each bus equals the sum of the
power flows on the connected branches.
• The inequality constraints consist of variables such as the bus voltage magnitudes and
angles or active power output which can be varied between a minimum and maximum
value.
Power system performance quality is implied by satisfying both the global objective and the
constraints. By adjusting control variables, the solution process determines conditions that simulta-
neously satisfy the constraint equations and minimize the objective function. A complete optimal
power flow problem statement thus requires specification of the objective function, the controls, and
the constraints.
14.3.1 Objective Functions

Objective functions are expressions of cost in terms of the power system variables. For example,
the fuel cost incurred to produce power is a function of the active power generation among partici-
pating machines. The OPF automatically adjusts the participating machines’ active power
generation, within capability limits, to reduce the total fuel cost.
Objective functions have both explicit and implicit components. Explicit objective components are
identified by auxiliary modeling data and are generally functions expressed in terms of the optimized
subsystem variable set. Implicit objective functions may be introduced as approximations for
discrete or discontinuous control actions. These implicit objectives are weighted quadratic penalties
applied to the excursion of a variable from an offset: (xj - xj0)2. The scalar weight or cost, , is
assignable.
14.3.2 Constraints and Controls

Reducing participating active power generation to zero will certainly minimize fuel cost, but it does
not provide for the customer power demand. It is necessary therefore, to augment the objective
function with constraint equations, including both equality and inequality constraints. Inequality
constraints define upper and lower bounds on a variable. For the fuel cost dispatch example, these
constraint equations will ensure that the active power generation is sufficient to provide for customer
demand and power system transmission losses.
The complex power flow equations of the conventional power flow problem are always included.
Controls, such as active power generation, generator voltage magnitude, transformer tap ratio,
transformer phase shift angle, etc., may be assigned a fixed value or assigned upper and lower
limits. Certain dependent variables, such as load bus voltage magnitudes and branch flows, are
assigned upper and lower bounds. It is possible however, for the entire constraint set to not be
simultaneously satisfied. This situation results in an infeasible termination.
Unlike the conventional power flow there is no independent local objective associated with each
control. The solution process adjusts each control to find the setting that satisfies all stipulated
constraints, and further minimizes the objective function. The constraints are applied to, and the
objective is written in terms of a variable set. Two variable types exist in the model: control variables
(also referred to as independent or decision variables) and dependent variables (also referred to as
14-3
Conventional Power Flow Models Program Operation Manual
state variables). These are identified through both the conventional power flow model and the auxil-
iary optimal power flow modeling data.
One primary difference between the optimal power flow solution and a standard power flow solution
when applied to a basic power flow case is that the OPF may introduce barrier terms into the objec-
tive function. These barrier terms come from constraints that have hard limits enforced. Bus voltage
constraints for example have, by default, hard limits automatically introduced for every bus in the
system.
14.3.3 Sensitivities
Each variable, both independent and dependent, has a sensitivity associated with it. Sensitivity
values quantify the expected change in the objective in response to a change in the variable. A
negative sensitivity indicates that an increase in the variable’s value will decrease the objective’s
value. The optimal setting for any variable is one which results in a sensitivity of zero. For some
variables, the optimal setting exists outside of the variable’s limits. In this case, the OPF will drive
the variable to the limit and report the sensitivity value. The relative magnitude of the sensitivity
values direct attention to the constraints or fixed controls that have the most influence on the
objective.
®
PSS E GUI Users Guide, Section 19.4, Running the Optimal Power Flow Solution
Section 16.3, Running the Optimal Power Flow Solution
14.4 Conventional Power Flow Models

The OPF model is primarily a conventional power flow model. Complex power flows across trans-
mission branches that connect buses at points of power generation and consumption. The
conventional power flow data is prepared and maintained through the PSS®E power flow data func-
tions and stored and utilized within the PSS®E working case.
The following sections identify the conventional power flow models and details how each one is
utilized and modeled within the optimal power flow. The categories are presented in the same order
as they would appear in the PSS®E Power Flow Raw Data File.
14.4.1 Bus Data

Only in-service buses (not type 4) defined within the power flow working case are recognized in the
OPF model. Any conductive and susceptive shunts that may exist at an in-service bus are
recognized.
Voltage magnitude and bus angle are initialized from the conventional model. Swing (Type 3) bus
angles are fixed at their initial values while all other bus angles are allowed to vary without limit.
Swing bus voltage magnitudes and reactive power generations may vary between the stated upper
and lower limits. For problem statements in which generation is dispatched to minimize fuel cost,
the swing bus active powers vary only when a fuel cost model is applied. For all other problem state-
ments, the swing bus active power may vary without limit.
14-4
Program Operation Manual Conventional Power Flow Models
By default, all bus voltage limits are set to 0.2 per unit Vmin and 2.0 per unit Vmax, with hard lim-
its imposed. These generally wide voltage limits have the potential of contributing to either an infea-
sible solution or an extraneous solution. Setting the limit mode to Reporting may have a similar
impact because it essentially causes the voltage limits to be ignored. It is highly recommended that
the voltage limit ranges on all buses in the OPF problem statement be set to desired values before
commencing the solution.
14.4.2 Load Data

The PSS®E load model is fully recognized by the PSS®E OPF. An auxiliary OPF Adjustable Bus
Load data model may be applied to existing loads. This model may be used to determine an optimal
load multiplier value that is reported, but not directly applied to the current load values.
The data record for defining the auxiliary data is described in Section 14.9.4 Bus Load Data and the
adjustable bus load data model itself is described in Section 14.6.3 Load Adjustment.
14.4.3 Fixed Shunt Data

Fixed Shunt G-Shunt (MW) and B-Shunt (Mvar) values are included directly into the corresponding
bus power injection equations of the OPF solution. Multiple fixed shunts at a bus are treated as a
cumulative value.
Although the OPF adjustable bus shunt data records are independent of the fixed shunt data
records, they do impact the fixed shunt data after an OPF solution in which the objective to minimize
adjustable bus shunts is specified. If a corresponding bus and bus shunt identifier is found within the
fixed shunt data, then the B-Shunt value will be updated with the new OPF solution value added in;
otherwise a new bus shunt will be added to the power flow network data with same identifiers as given
for the adjustable bus shunt record, and the new OPF solution Mvar value specified for B-Shunt.
14.4.4 Generator Data

One or more machines may be associated with a generator bus (type 2) or a swing bus (type 3).
Active power and reactive power generation and reactive power generation limits are initialized from
the conventional power flow data model. Should the lower limit total equal or exceed the upper limit
total at any bus, the bus is implicitly altered to a load bus (type 1). Bus numbers of remotely regu-
lated voltage buses are retained for reporting purposes and optionally for local voltage control of
nonoptimized equipment, although the remote regulation concept is invalid for optimized controls.
The OPF exercises all optimized controls to satisfy all constraints and beyond that to minimize the
objective function. Generator base MVA, source impedance, implicit step-up transformer imped-
ance, and tap ratio data are ignored by PSS®E OPF.
In the conventional power flow, generator control action is discontinuous. Generators regulate a
single bus voltage magnitude. This voltage is considered fixed and the reactive generation varies
until a reactive generation limit is reached, at which point the regulated voltage becomes free to vary
in one direction and the reactive generation is fixed at the limit. If the regulated voltage should return
to the set point, the voltage once again becomes fixed and the reactive generation is free.
Generator bus voltage magnitudes are control variables that are varied by the OPF to optimally
settle on a value that respect limits. The preferred treatment for nonoptimized generators is the
conventional generator model, but this model’s discontinuity severely impedes the reliability of the
OPF solution. The PSS®E OPF does not directly accommodate the discontinuous model, but
approximates it through one of two methods:
14-5
Conventional Power Flow Models Program Operation Manual
1. Through the application of a quadratic penalty on any excursion of the generator voltage
magnitude from its initial value. By default a quadratic penalty with a penalty weight of 100.0
is employed. The penalty weight may be changed through the OPF solution option settings
and a scheduled voltage may be assigned as the penalty offset for locally regulating units; or
2. Through the introduction of an equality constraint (clamp) which restricts the total error in
nonoptimized generator voltage versus reactive generation performance.
These two treatments are mutually exclusive of each other and are globally applied to all nonopti-
mized generators. Both options are further discussed in Section 14.5 Modeling Power Flow
Controls.
14.4.5 Non-Transformer Branch Data

Resistance, reactance, charging, from bus conductive and susceptive shunt, and to bus conductive
and susceptive shunt values are all obtained from the branch data of the standard power flow
branch model.
The PSS®E OPF adheres to the PSS®E convention for zero impedance line modeling. Any branch
where resistance is zero and where reactance is smaller than the threshold value THRSHZ (as set
in the power flow solution parameters), is treated as a zero impedance line.
Branch flow constraints for existing branches in the working case may be introduced through the
OPF branch flow data model, as presented in Section 14.9.15 Branch Flow Constraint Data.
14.4.6 Transformer Adjustment Data

A control variable allocation is made for every transformer defined in the power flow data model, as
identified by a branch with a nonzero tap ratio. The optimization status of the transformer is based
upon whether the branch is located in an area or zone selected for optimization. Branches are
owned by the area and zone associated with the non-metered bus.
Upper and lower limits in the tap ratio or phase shift angle, and tap ratio step size are established
as part of the transformer adjustment data in the power flow model. The regulated bus number and
adjustment enable flag are used by the OPF, but the controlled value limits (voltage, MW or Mvar
flow) are only used to discern the transformer type, tap ratio control or phase angle control, and then
discarded. Regulation status is implied by the data as with PSS ® E, but as discussed in
Sections 14.2 and 14.3, optimized controls are adjusted to accommodate the entire optimization
problem, not simply a local objective.
The PSS®E program accommodates a transformer model for which tap is a complex number in
polar form: the tap ratio is the magnitude and the phase shift is the angle. Only one of these two
components on each transformer is selected as the available control. When the transformer adjust-
ment range (i.e. RMAX - RMIN) exceeds 1.0 then phase shift angle is the control variable, otherwise
the tap ratio is the control variable. In both situations, the alternate component is fixed. Sensitivities
are calculated only for the control variable. Therefore, a transformer that has a fixed phase angle
shift to represent a delta-wye connection is reported within the tap ratio transformer summary report
(Section 14.14.10 Tap Changing Transformers), as opposed to the phase shift angle transformer
summary report (Section 14.14.11 Phase Shifting Transformers).
14.4.7 Area Interchange Data

Area interchange data is only used if the option to Regulate Area Interchange is enabled. In this
situation, a constraint equation is introduced for every area interchange record defined as part of
14-6
Program Operation Manual Conventional Power Flow Models
the power flow data within the working case. Refer to Section 14.6.7 Regulated Area Interchange
for further information on the area interchange constraint.
14.4.8 Two Terminal DC Data

Two terminal dc systems are modeled as equivalent active and reactive power demand. All in-
service two terminal dc systems of the working case are automatically replaced by equivalent bus
loads during the OPF solution. The equivalent load is obtained from the dc bus injection as calcu-
lated by the PSS®E power flow solution activities and stored within the working case. It is therefore
best to perform a power flow solution prior to the OPF solution in order to start with a condition that
has been solved for the dc boundary conditions of interest.
14.4.9 Voltage Source Converter Data

VSC devices are modeled as equivalent load injections, obtained directly from the PSS®E power
flow solution as stored in the working case. It is best to start the OPF solution from a power flow
condition that has already been solved for the boundary conditions of interest.
14.4.10 Transformer Impedance Correction Data

Transformer impedance adjustment as a function of tap position is not accommodated in the
PSS®E OPF. Transformer impedance is initialized to the adjusted impedance and held fixed.
14.4.11 Multi-Terminal DC Line Data

Multi-terminal dc systems are modeled as equivalent active and reactive power demand. All in-
service multi-terminal dc systems within the working case are automatically replaced by equivalent
bus loads. The equivalent dc bus injection is calculated by the PSS®E power flow solution activities
and stored in the working case. It is therefore best to perform a power flow solution prior to the OPF
solution in order to start with a condition that has been solved for the dc boundary conditions of
interest.
14.4.12 FACTS Device Data

FACTS devices are modeled as equivalent active and reactive power demand. During the OPF
solution, all in-service FACTS devices are automatically replaced by equivalent bus loads. The
loads are obtained directly from the equivalent bus injection as calculated by the PSS®E power flow
solution and stored in the working case. It is therefore best to start the OPF solution from a power
flow condition that has already been solved for the boundary conditions of interest.
14.4.13 Induction Generators and Motors

Induction generators and motors are modeled as equivalent active and reactive power demand at
their corresponding buses. During the OPF solution, all induction generators and motors that are
in-service and not tripped are automatically replaced by the equivalent active and reactive bus
loads. The load injections are obtained directly from the equivalent bus injection as calculated by
the PSS®E power flow solution and stored in the working case. It is therefore best to start the OPF
solution from a power flow condition that has already been solved for the boundary conditions of
interest.
14-7
Modeling Power Flow Controls Program Operation Manual
14.4.14 Switched Shunt Data

Bus shunt control variables are identified by both the auxiliary OPF adjustable bus shunt data model
and the switched shunt model in the conventional power flow data. The adjustable bus shunt data
model is presented in Section 14.6.2 Adjustable Bus Shunt.
For switched shunts defined within the power flow, the bus number, control mode, initial value and
switching information for the eight blocks are retained by the program.
By default the switched shunt susceptance is adjusted continuously. Non-regulating switched

shunts and var sites in nonoptimized subsystems are fixed at their initial value (BINIT).
The control mode values of switched shunts that are not fixed are treated as follows:
• Modes 1 and 2: The desired voltage limits and the remote bus number are discarded
in lieu of explicit bus voltage limits applied to buses via the OPF Bus Voltage Attribute
Data Record.
• Mode 3: Reactive generation limits of regulated generators are also restricted by the
specified band.
• Mode 4: Handled the same as modes 1 and 2. Because VSC are handled as equivalent
bus load injections in the OPF solution, no adjustments are made to VSC limits.
• Mode 5: Admittance limits of switched shunts (local or remote) are also restricted by
the specified band.
14.5 Modeling Power Flow Controls

The conventional power flow models pertaining to generator bus voltage magnitudes, transformer
tap ratios, transformer phase shift angles and switched shunts, as presented in Section 14.4
Conventional Power Flow Models, introduce a number of controls into the OPF problem statement.
Within the OPF however, unlike in the standard power flow, it is possible to influence the motion of
these controls.
Controls within both optimized and nonoptimized subsystems (selected areas or zones) of the
power flow may be represented. Most of the control variables introduced through the power flow
model residing in the nonoptimized subsystems are fixed at their initial value, but special treatment
is given to nonoptimized generator bus voltage magnitudes. This is described in further detail below.
14.5.1 Scalar Quadratic Penalties

A weighted quadratic penalty is inherently applied to four power flow controls: generator bus voltage
magnitude, transformer tap ratio, transformer phase shift angle and switched shunt admittance. The
OPF will adjust these controls to achieve a feasible solution and to balance the penalty against the
other selected objective components. This quadratic penalty is all or none; it may not be selectively
applied to certain nonoptimized generator units. Global quadratic penalties take the form,
N
  (xi - xio)2
i=1
where:
N = number of penalized control variables,
14-8
Program Operation Manual Modeling Power Flow Controls
 = scalar quadratic penalty weight,

x = control variable current value (per unit),
xo = control variable penalty offset (per unit).
By default, the nonoptimized generator bus voltage magnitudes are penalized with a default weight
of 100.0 and the quadratic penalty weight for the transformer and switched shunt controls is 0.0.
These values are globally applied to all nonoptimized controls and may be altered by modifying the
Penalty for fixed voltage value and the Quadratic penalty coefficient value, respectively, in the OPF
change parameters interface.
14.5.2 Soft Limit Penalties

Unlike the global quadratic penalty, soft limit penalties, which include a penalty weight (cost) and
offset value, may be selectively applied to specific constraint variables. This includes power flow
bus voltage constraints as well as branch flows and interface flows, both of which are introduced as
part of the OPF models discussed in Section 14.6 OPF Modeling Extensions. By default, soft limit
penalty weights of 1.0 are assigned. These values may be modified and applied to specific vari-
ables, or a common penalty weight may be applied to an entire subsystem by employing the
corresponding OPF subsystem spreadsheet (refer to Section 14.8.4 Optimal Power Flow Spread-
sheet View).
Details of the quadratic and linear soft penalty treatments are further discussed in Soft Limit
Treatment.
14.5.3 Treatment of Transformers and Switched Shunts

For transformers and switched shunts residing in an area or zone selected for optimization, a zero
cost quadratic penalty is automatically applied. This penalty weight value may be altered through
the OPF solution tolerance for the Quadratic Penalty Coefficient.
Transformers and switched shunts not residing within an optimized subsystem, or those where the
setting has been fixed (either in the power flow model or through the Fix setting), will be treated as
nonoptimized. In this situation, these controls are fixed at their current working case values. There
is the possibility however, for bus voltage penalties to also be imposed on the regulated buses,
although this is done independent of whether the transformer or switched shunt is being treated as
a nonoptimized control.
Discrete transformer tap ratio adjustments or switched shunt adjustments are approximated by
initially treating these controls as continuous. If the option to Round Transformer Tap Ratios and/or
Round Switched Shunt Vars is imposed, then after an optimal solution has been achieved with
continuous treatment, the control is fixed to the nearest discrete value and the problem is resolved
from this condition.
14.5.4 Treatment of Local Generator Voltage Controls

Similar penalty treatments exist for generator voltage controls, but vary depending upon whether
the treatment is applied to an optimized or nonoptimized generator. Nonoptimized generators are
those that are not located in an optimized subsystem. If the Treat all Generators as Non-optimized
option is enabled, then all generators in the system are treated as nonoptimized, independent of
whether they are located within a nonoptimized area or zone.
Using the generator and area designations defined in the one-line diagram of Figure 14-1, the far
right-hand column of Table 14-1 Local Generator Voltage Controls indicates which generators
14-9
would result in being treated as nonoptimized based upon the setting of the Treat all generators as
non-optimized option and the subsystem of areas selected for optimization.
3011 101 102
211
3018 206
Area 5 Area 1 Area 2
Figure 14-1. Generator and Area Designations from the savnw.sav Case
Table 14-1. Local Generator Voltage Controls
Treat all generators as non- Areas selected for Resulting nonoptimized

optimized? optimization generators
Yes 1 All generators
Yes 1, 2 and 5 All generators
No 1 211, 206, 3011, 3018
No 1, 2 and 5 No generators
Treatment of Optimized Generators

Generators that are located in an optimized subsystem are treated according to the voltage magni-
tude penalty limits defined at the voltage regulated bus. One of four limits may be applied: reporting
only (no penalties), hard limits, or soft limits with either a linear or quadratic penalty. The hard limits
introduce a barrier term into the objective function. This treatment is discussed in Hard Limit Barrier
Treatment. The soft limits utilize a soft limit penalty weight in conjunction with either a linear or
quadratic curve to penalize the motion of the controls. The higher the cost, the less likely the vari-
able is to violate its limits. Employing the quadratic penalty also imposes a more severe penalty than
will the linear penalty.
Treatment of Non-optimized Generators

The preferred treatment for nonoptimized generators is the local voltage control model employed
by the conventional power flow solution. This however poses problems when modeled in the
optimal power flow. Figure 14-2 illustrates the relationship between the voltage magnitude at the
regulated bus and the regulating reactive power generation employed by the conventional power
flow solution.
14-10
Vregulated
Vscheduled
Qregulating
Figure 14-2. Conventional Power Flow Generator Voltage Regulation
The regulated voltage may be that of a generator bus or a remote non generator bus. The regulating
reactive power supply is the sum of the reactive generation of all the units that regulate the bus.
Note the discontinuity at the upper and lower reactive power generation limits. It is this discontinuity
which confounds modeling this relationship in the OPF, and thus approximations for this treatment
must be employed.
Several different penalty techniques are available for approximating the local control objective at
nonoptimized generators:
• bus voltage magnitude soft limit penalties (linear or quadratic),

• scalar quadratic penalties
• constraint (clamp) equation.
Soft Limit Penalty Techniques: Soft limit penalty techniques are applied on a per bus basis
through the bus voltage magnitude constraints defined at corresponding voltage regulated
buses (see Section 14.9.2 Bus Voltage Constraint Data). The soft limit penalty introduces
an objective function component that penalizes the excursion of the regulated voltage
magnitude from an offset.
There are two soft limit penalty treatments available: linear and quadratic. Both are
discussed in further detail in Soft Limit Treatment. When applied to nonoptimized generator
units, the soft limit penalty treatment supersedes either the scalar quadratic penalty or
clamp treatments discussed in the following text.
Scalar Quadratic Penalty: A second technique for approximating the local control objective
of nonoptimized generators is by means of a scalar quadratic penalty. This quadratic
penalty is all or none; it may not be selectively applied to certain nonoptimized generator
units. Unless the clamp equation is employed (as discussed below), or a penalty limit is
applied to the individual bus voltage constraint, a quadratic penalty is inherently applied to
all nonoptimized generator units. The default penalty weight of 100.0 may be modified prior
14-11
to the OPF solution. Unlike the soft limit penalty weight which may be uniquely defined for
individual bus voltage constraints, this value is applied as a scalar to the entire quadratic
penalty equation. Refer to Section 14.5.1 Scalar Quadratic Penalties for further details.
Clamp Treatment: The final penalty technique available for approximating the local control
objective for nonoptimized generators is by means of a constraint, or clamp, equation. This
equation limits the total deviation from the voltage and reactive power relationship
presented in Figure 14-2. Consider the equation,
N
(Qmax,i - Qi) max(0, (Vs,i - Vi)) + (Qi - Qmin, i) max(0, (Vi - Vs,i))
 (Qmax,i - Qmin,i)

i=1
where:
Q = reactive power generation

V = regulated (local or remote) bus voltage magnitude
Vs = regulated voltage set-point
N = number of nonoptimized generators
 = clamp tolerance,
and note:
(Qmax - Q) max (0, (Vs - V))  0

(Q - Qmin) max (0, (V - Vs))  0
Armature reaction (Efd) is employed in place of reactive generation (Q) when reactive capability
models are introduced for nonoptimized generators. With  = 0.0, the equation is satisfied only when
V = Vs or Q is limited, and the discontinuous performance is accommodated exactly.
The PSS®E OPF interior point solution technique described in Section 14.7.2 Accommodating
Inequality Constraints prevents a solution when  equals 0.0. The consequence of having a nonzero
clamp tolerance is illustrated in Figure 14-3. Clamp constraint limits are applied in an attempt to
reduce the total error in nonoptimized generator performance. The strategy employed in the PSS®E
OPF is to initialize the problem with a relatively large clamp tolerance, and then systematically and
gradually reduce this tolerance to a final tolerance as the solution progresses.
If the voltage set point falls outside of the minimum or maximum voltage range specified for the
regulated voltage bus, the set point voltage will be set to the value of the violated limit.
14-12
Vregulated
Vscheduled
Qregulating
Figure 14-3. Feasible Clamp Region for Non-zero 
14.5.5 Reactive Generation Reserve

A reactive generation reserve objective function component may be included in the opf problem
statement. This objective component will influence the magnitude of reactive power generation held
in reserve. All in-service generators that are members of the optimized subsystem contribute to this
objective. The OPF will adjust the reactive power generation of these generators to achieve a
feasible solution and to balance the cost of this objective component against the other selected
objective components. The reactive generation reserve objective takes the form:
NGEN
  (QMAX,i - QGEN,i)
i=1
where:
NGEN = Number of in-service optimized generators.

 = Objective cost coefficient in cost units/Mvar.
QMAX = Maximum reactive power generation limit in Mvar.
QGEN = Reactive power generation in Mvar.
The reactive generation reserve will tend to be minimized by applying a positive objective cost coef-
ficient. The reactive generation reserve will tend to be maximized by applying a negative objective
cost coefficient. The objective component may be applied by enabling the Minimize Reactive
Generation Reserve option, and the cost coefficient may be assigned using the input field labeled
Reactive generation reserve cost ($/MVAR).
14-13
OPF Modeling Extensions Program Operation Manual
14.6 OPF Modeling Extensions

The following subsections introduce the power system models recognized by the PSS®E OPF
beyond the conventional power flow models introduced in Section 14.4 Conventional Power Flow
Models.
14.6.1 Active Power Generation

Active power generation control variables may be introduced by presenting cost as a function of
active power generation. Individual generator units may be associated with certain active power
controls. The amount of dispatch is adjusted to satisfy the constraints and minimize the total gener-
ation cost component of the objective function. Generators in nonoptimized subsystems that are
associated with an active power dispatch control will participate in the dispatch.
One of three cost curves may be employed to model the control: piece-wise linear, piece-wise
quadratic and polynomial.
14.6.2 Adjustable Bus Shunt

A subset of buses may be identified as susceptive bus shunt adjustment candidates for shunt
compensation. When defined, adjustable bus shunt controls are employed to minimize the total
adjustable bus shunt component of the objective function (refer to Minimize Adjustable Bus Shunts).
The candidate buses for shunt compensation are introduced through the adjustable bus shunt data
records described in Section 14.9.3 Adjustable Bus Shunt Data.
This objective function employs a linear penalty of the following form:
NVARS
F(B) =  |Bi|Ci
i=1
and
BIND, MAXi  Bi  BCAP, MAXi
where:
B = adjustable bus shunt susceptance (per unit)

BCAP,MAX = capacitive limit (per unit)
BIND,MAX = inductive limit (per unit)
C = shunt cost / per unit Mvar
NVARS = number of adjustable shunt candidate buses
The cost, Ci, is assigned to individual adjustable bus shunt controls, in cost units / per unit Mvar.
Multiple shunt device controls may be assigned to the same bus, with each one distinguished by a
different cost for deployment. For example, a relatively low cost may be assigned to a control
representing an existing installation and a high cost to a control representing a potentially new
installation. In this situation the existing installation is ensured of being deployed to its limit before
any portion of the new capacity is applied.
The shunt control is assigned a minimum and maximum var limit and may operate in both an induc-
tive (-B) and capacitive (+B) range. The resulting shunt value is added to the corresponding fixed
14-14
Program Operation Manual OPF Modeling Extensions
shunt in the power flow model. If no corresponding fixed shunt is found, then a new fixed shunt with
the same identifiers as the adjustable bus shunt will be added. If an initial offset (no cost, fixed shunt
component) is desired, it may be included in the power flow model as a fixed shunt prior to the OPF
solution.
14.6.3 Load Adjustment

Any number of predefined loads within the power flow case may be identified as adjustable load
candidates. The constant MVA component of these loads is adjusted by a multiplier to minimize the
total load adjustment component of the objective function. The multiplier may vary continuously
between predefined minimum and maximum limits.
The load adjustment objective function is of the following form:
NSHED
F() =  Ci • MW0i (1 - i)
i=1
MINi  i  MAXi
MVALOADi = i • MVA0i
where:
MVALOAD = MVA bus load (per unit)

MVA0 = initial MVA bus load (per unit)
MW0 = initial active power bus load (per unit)
 = load adjustment factor
MIN = minimum load adjustment factor
MAX = maximum load adjustment factor
C = load shed cost / per unit MW
NSHED = number of load shed candidate buses
Bus load is shed at constant power factor. The cost, Ci, is assigned per candidate load adjustment
group, in cost units / per unit MW. The control is limited between minimum and maximum values
specified as a fraction of initial total load.
14-15
14.6.4 Adjustable Branch Reactance

The adjustable branch reactance model is generally employed to identify the best transmission lines
of a candidate set for which to apply optimal series compensation. The control modifies the branch
reactance by adjusting a reactance multiplier between a minimum and maximum limit in order to
meet the minimal adjustable branch reactance component of the objective. Only non transformer
branches may be considered as candidates for reactance adjustment.
The form of the adjustable branch reactance objective function is as follows:
NCOMP
f(Xc) =  Ci • X0 (1 - i)
i
i=1
and
MIN i  i  MAX i
XCOMP i = i • X0 i
where:
XCOMP = Branch reactance value (per unit)

X0 = initial branch reactance (per unit)
 = reactance adjustment factor
MIN = minimum reactance multiplier
MAX = maximum reactance multiplier
C = compensation cost / per unit ohms
NCOMP = number of compensation candidate branches
The cost, Ci, is assigned per candidate branch, in cost units / per unit ohms. The control may vary
between the minimum and maximum values specified as a fraction of initial compensation.
14.6.5 Generator Reactive Capability

Synchronous generator performance is limited primarily by stator heat transfer, rotor heat transfer,
and a minimum sustainable exciter voltage. These limits are often abstracted into other related vari-
ables depending upon the application. For example, plant operating personnel may be provided
with limits depicted by the reactive power generation (Qgen) versus active power generation (Pgen)
plane illustrated in Figure 14-4. When abstracted in this way, certain assumptions may apply. Any
one set of limiting point locus from the Qgen vs. Pgen representation assumes constant (often unity)
terminal voltage and constant cooling medium consideration (e.g. cold gas inlet temperature, or
hydrogen pressure).
14-16
Qgen
Lag
Pgen
Lead
Figure 14-4. Reactive Capability, Qgen vs. Pgen
The Qgen vs. Pgen limits description is amenable to the conventional power flow problem because
of the simple inequality treatment of reactive power limits, Qmin  Qgen  Qmax, fixed voltage
schedule, and fixed active power generation. Because the OPF is able to dispatch active power
generation and voltage schedule, a more elaborate model that describes the machine’s capability
is appropriate. This is achieved by replacing the generator representation of Pgen and Qgen injec-
tions at the terminal bus, with one of Pgen and Q´gen injections at a point removed from the terminal
bus through direct axis synchronous reactance, as illustrated in Figure 14-5.
Pgen Efd Vterminal

Xd
Is
Q’gen
Qgen
Figure 14-5. Alternate Generator Model (Injection Behind Synchronous Reactance, Xd)
14-17
By ignoring machine saliency and saturation, this model defines both armature reaction (Efd) and
stator current (Is). The Qgen vs. Pgen depiction of generation capability is constructed as a mapping,
at constant terminal voltage magnitude, of voltage invariant limits in the Is vs. Efd plane, as illus-
trated in Figure 14-6.
Is
m
b
Efd
Efd,min Efd,max
Figure 14-6. Is vs. Efd Plane
The machine capability is then fully described by the following inequality limits applied to these
parameters,
Efd,min  Efd  Efd,max

0  Is  Is,max
0  Is  mEfd + b
In addition, all of the limit coordinates: Efd,min, Efd,max, m and b, can be derived from machine
parameters generally provided with the Qgen vs. Pgen capability description, including: machine
MVA rating (MVAr), direct axis synchronous reactance (Xd), rated lagging power factor (pflag), rated
leading power factor (pflead), maximum reactive absorption at zero power factor (Q0pf), and a
choice of maximum stator current (Is,max) reflecting a particular cooling condition (e.g 1.0 per unit
current for H2 pressure of 30 psig). The vector arithmetic required to derive the limits is illustrated
in Figure 14-7.
14-18
Efd,max
Is*Xd
Is = Q0pf / MVAr
Efd,min Is*Xd
V
V
ACOS(pflag)
Is = Is,max E’fd
Is*Xd
m = (E’fd - Efd,min) / (Is,max - Qopf/MVAr)

b = Qopf/MVAr - mEfd,min
Is = Is,max
ACOS(pflead)
Figure 14-7. Vector Arithmetic for Deriving Limits
14-19
14.6.6 Generator Period Reserve

A common practice in power system operation is to commit and dispatch generation such that suffi-
cient excess capacity exists to accommodate some reserve constraint. This may be compounded
with a time dimension, such that the reserve capacity must be fully available within a stated number
of minutes, and the units that participate in supplying the reserve are limited by their active power
generation ramp capability and emergency maximum capacity. A minimum generation cost
dispatch may be significantly impacted by these generation period reserve constraints.
The PSS®E OPF generation period reserve model provides for a reserve in MW, and a time period
in minutes, to be stated. Participating generators associated with each of these constraints are also
defined. A maximum unit capability in MW and an active generation ramp rate in MW per minute is
identified for each participating generator. The sum of participating unit reserves must exceed the
reserve constraint. The amount of reserve contributed by each of the participating units is the lesser
of the unit capability minus its active power dispatch, or its ramp rate times the period. This is exem-
plified in the following equation.
N
 min((Pmax,i - Pgen,i), T • Rampi)  RES
i=1
where:
Pmax,i = maximum unit capacity for the reserve contribution

Pgen,i = unit active power dispatch
Rampi = unit ramp rate
T = reserve period
N = number of reserve constraint participating generators
RES = reserve magnitude
Multiple coincident period reserve constraints are permitted. For example, a problem statement
may include both a 200 MW reserve requirement in 10 minutes and a 700 MW reserve requirement
in 30 minutes. Individual units may participate in multiple constraints. Those units with fixed active
power generation merely act to offset the reserve requirement, otherwise the period reserve
constraints may impact the dispatch of participating units.
14-20
14.6.7 Regulated Area Interchange

The regulated area interchange model provides a convenient means of defining a closed MW inter-
face constraint. Area interchange is measured as the sum of MW flows on tie branches emanating
from the stated area. As such, the tie branches should consist entirely of impedance branches.
This model introduces an interface flow constraint defined by the components described below. It
does not introduce any MW associated controls. While not necessary, it is appropriate to include in
the problem statement those controls for which area tie branch flows are likely to be sufficiently
sensitive (e.g. dispatchable active power generation spanning the controlled area).
The area interchange data model is introduced as part of the standard power flow data model as
defined by the following information:
• Area number
• Bus number of the area slack bus
• Desired net interchange leaving the area (export), in MW
• Interchange tolerance band width, in MW
With the Regulate area interchange option enabled, the optimal power flow transforms the above
information into a constraint equation with the following area interchange limits:
AIntmin = (DesInt - DesTol)

AIntmax = (DesInt + DesTol)
where:
AInt = the minimum and maximum constraint limits placed on the OPF
area interchange constraint equation.
DesInt = the desired interchange.
DesTol = the interchange tolerance band width.
Each new area interchange constraint model implicitly defines an interface consisting of the
following components:
• area tie branches, excluding zero impedance lines;

• flows associated with dc lines, multi-terminal dc lines, FACTs and VSC devices;
• loads, provided that the option to include loads in area interchange calculations has
been enabled (refer to PSS®E GUI Users Guide, Changing Program Settings).
14-21
14.6.8 Linear Constraint Dependency Equation

The linear constraint dependency equations provide the capability to introduce customized
constraint equations into the OPF problem statement. The form of the constraint equation is as
follows:
NTERM
 Ci • Xi - s = 0
i=1
smin  s  smax
where:
C variable term coefficient

x power system variable (voltage, angle, flow, etc.)
s the slack value
smin minimum slack variable value
smax maximum slack variable value
NTERM number of terms within a single equation.
Any number of equations may be introduced into the problem statement. The equations themselves
may consist of one or more variable terms selectable from up to ten different power system variable
types, including:
• voltage magnitude, in pu
• voltage angle, in radians (degrees/57.29578)
• active power generation, in per unit of reactive power based on system base(i.e. 400
MW limit base on a system base of 100 MVA is entered as 4.0)
• reactive power generation, in per unit of reactive power based on system base(i.e. 400
Mvar limit base on a system base of 100 MVA is entered as 4.0)
• transformer tap ratio, entered as the inverse of the tap ratio
• transformer phase shift angle, in radians
• branch flow, in per unit based on system base
• interface flow, in per unit flow value based on system base
• adjustable bus shunt, in per unit Mvar value based on system base
• switched shunt, in per unit Mvar value based on system base
• load adjustment, entered in terms of the load multiplier (i.e. 0.8 for 80% of load or 1.8
for 180% of load
The units of the slack variable are dependent upon the type of variables used within the equation.
Example
Suppose the voltage angles between two generator buses need to be held to within three degrees
of each other. A constraint equation of the following form can be introduced:
14-22
Program Operation Manual Solution Process
(1)*Ang1 + (-1)*Ang2 - slk = 0

and
-3º < slk < 0º, or

-0.052 < slk < 0 radians
14.6.9 Other Dependent Variable Limits

Several power system variables may have limits selectively applied, including those for bus voltage
magnitudes, branch flows and interface flows.
Branch flow limits may be applied to any of MW, Mvar, MVA or current values. The first three limit
values are stated in physical units. Current limits are stated in MVA units at nominal voltage so as
to preclude the need for a valid base kV in the power flow model.
Interface flow limits may be applied to either MW or Mvar constraints, and are stated in physical
units. Interfaces are defined as a collection of branches. The limited flow quantity is the scalar sum
of the individual branch MW or Mvar flows. All flow quantities are measured at the branch metered
point, as identified in the power flow data.
Zero impedance branches may not be branch flow constraint candidates, and may not be included
in interface definitions.
14.7 Solution Process
14.7.1 The Nonlinear Problem

PSS®E OPF solves a nonlinear problem consisting of an objective function and a linear combina-
tion of equality constraints to form a scalar Lagrangian function of the following form.
L (x, ) = f(x) + []t [h(x)] (14.2)
and
h(x) = 0
xMIN  x  xMAX
where:
x = power system variables (control and dependent, column vector),

f(x) = objective function (e.g. active power dispatch cost),
h(x) = equality constraints including bus-power mismatch equations (column vector),
 = Lagrange multiplier variable (column vector).
The Lagrangian function is constructed in terms of both the power system variables and the
Lagrange multipliers, thereby resulting in a dual variable problem. The equality constrained optimal
solution is a Lagrangian stationary point, and is determined by equating the function’s gradient to
zero and solving for x and . This is the Kuhn-Tucker optimality condition1, and the resulting set of
1 Kuhn, H.W. and Tucker, A.W., "Nonlinear Programing", Proceedings of the Second Berkeley Symposium on
Mathematical Statistics and Probability (J. Neyman, ed.), Berkeley, University of California Press, 1951.
14-23
Solution Process Program Operation Manual
simultaneous equations is referred to as the KT formulation. Solving the KT problem produces a set
of optimally defined power system variables (x), along with the objective function sensitivities to
changes in the constraints ().
The OPF formulation is always nonlinear in x because the constraints include the power flow
mismatch equations. The objective function is also likely to be nonlinear in x either through explicitly
selected components, like active power loss, or the implicit introduction of quadratic penalties.
Therefore, an iterative solution technique which will recognize the limits in x is required. A solution
to the nonlinear problem results from solving a series of simpler subproblems, wherein the
inequality constraints are satisfied at every subproblem.
14.7.2 Accommodating Inequality Constraints

Inequality constraints are imposed through implicit objective terms expressed as a function of the
constrained variable. These limits have two types, hard and soft. Hard limits introduce objective
terms that are asymptotic to the variables limits (i.e. barrier terms), while soft limits introduce objec-
tive terms which are defined in the infeasible region and grow in magnitude as the variable value
departs further from its violated limit (i.e. penalty terms).
Limits imposed on the power system control variables, such as transformer tap settings, are consid-
ered extremes in the equipment’s physical range, and thus are always treated as hard limits. This
treatment is in addition to the global quadratic penalty that may optionally be imposed on power flow
control values as they move away from their initial values. As discussed in Section 14.5 Modeling
Power Flow Controls, this quadratic penalty is imposed on all optimized transformers and switched
shunts provided that the quadratic penalty coefficient is greater than zero.
Limits applied to power system dependent variables, including voltage magnitude, branch flows,
and interface flows, represent operating criteria and may receive either hard or soft limit treatment.
Soft Limit Treatment

Two forms of the soft limit penalty are available: quadratic and (two point) linear. These are
discussed in further detail in the following two sections.
Quadratic Penalties: The soft limit quadratic penalty introduces a penalty term of the
following form into the objective function.
2
N (xi,min + xi,max)
 i • xi -
2
i=1
where:
N = number of quadratically penalized control variables

x = control variable current value (per unit)
xmin = control variable minimum (per unit)
xmax = control variable maximum (per unit)
 = vector penalty weight. This value is unique to each control.
A penalty term is introduced any time a variable takes an excursion away from the midpoint
of its two limits. The quadratic growth of the penalty tends to discourage large and presum-
ably infeasible excursions.
14-24
Linear Penalties: The soft limit linear penalty introduces a penalty term of the following form
into the objective function.
N
 i • (max(0, xi - xMAX,i) - min(0, xi - xMIN,i))
i=1
where:
N number of linearly penalized control variables

x control variable current value (per unit)
xMAX control variable maximum value
xMIN control variable minimum value
 vector linear penalty weight
A penalty term is introduced into the objective that is directly proportional to the variable’s
excursion from a violated limit. The penalty is zero for feasible variables. The linear form
provides a relatively larger objective contribution for fairly small excursions in the control
value as compared to the quadratic penalty.
Hard Limit Barrier Treatment

The hard inequality constraints are rigorously enforced at each sub-problem by augmenting the
Lagrangian with objective-like equations in terms of x, xMAX, and xMIN. These equations, called
barrier functions (B(x)), are continuous and asymptotic to the limits, xMAX and xMIN, as depicted in
Figure 14-8.
Logarithmic "barrier" at
xMIN and xMAX
B(x)
x
xMIN xMAX
Figure 14-8. Logarithmic Barrier Function
As shown, the function is not defined for values of x outside of the specified range; thus barriers are
formed in which all of x is corralled within a feasible region. The optimization problem itself is infea-
sible if any equality constraint (e.g. bus-power mismatch) requires that x violate this feasible region.
PSS®E OPF employs a logarithmic barrier function of the form,
14-25
N
B(x) = -(10.)  {log(xi - xMIN,i) + log(xMAX,i - xi)}
i=1 (14.3)
The barrier functions aid the solution process by transforming inequality constraints into objective
terms, eliminating an additional iterative process that would otherwise be required to prevent viola-
tions when solving a subproblem.
The addition of the barrier function transforms the constrained problem into a more easily handled
unconstrained problem. The unconstrained minimum to the combined objective function always
occurs within the feasible region of x, or interior to the limits imposed by xMAX and xMIN. For this
reason, this technique is referred to as the Interior Point Method.
When included in the nonlinear problem formulation of (14.2), the resulting augmented Lagrangian,
as denoted by L´, is as follows.
L´(x, ) = f(x) + B(x) + []t [h(x)] (14.4)
and
h(x) = 0,
where:
B(x) = the barrier equations to satisfy the inequality constraints.

Whereas the original problem statement sought to find the constrained minimum of f(x), the new
formulation ks to find the constrained minimum of the combined objective function, f(x) + B(x). Not
only must the original objective function be decreased but the barrier objective contribution must
also be decreased. This is accomplished by systematically reducing the barrier parameter , as
contained in the equation of (14.3).
Example
An illustration of the effect of augmenting the objective function with the barrier terms is shown in
Figure 14-9. Only the barrier term associated with the upper limit, xMAX = 1.0, is illustrated for
simplicity. The constrained optimal solution to the simple objective f(x), occurs at xMAX. The
constrained optimal solution to the combined objective, f(x) + B(x), occurs at xOPT= 0.8. This value
may be confirmed by setting the combined objective’s first derivative in x equal to zero and solving
for x, the stationary point.
14-26
BARRIER FUNCTION DESCRIPTION

XMAX BARRIER TERMS ONLY, XMAX = 1.0
16:19
POWER
TECHNOLOGIES,
THE COMBINED OBJECTIVE FUNCTION
INC.R
FILE: barrier1
FRI JAN 10, 1992

CHNL# 1: 10.0*(1.0 - [X]) - LOG(1.0-[X]) * 2.0
14.000 -1.000
CHNL# 1: -LOG(1.0-[X]) * 2.0
14.000 -1.000
CHNL# 1: 10.0*(1.0 - [X])
14.000 -1.000
1.0000
0.80000
COMBINED OBJECTIVE
BARRIER TERM
0.60000
X
0.40000
EXPLICIT OBJECTIVE
0.20000
0.0
Figure 14-9. Objective Function with Barrier Term
14-27
Note that f(xMAX) < f(xOPT) + B(xOPT), and xOPT < xMAX. The interior point solution technique
will decrement the barrier objective contribution as it proceeds in order to reduce the objective
discrepancy. Figure 14-10 illustrates the effects of diminishing the barrier.
As the barrier contribution decreases, the combined objective minimum approaches the explicit
objective minimum. In Figure 14-10, the minimum of the combined objective with a barrier coeffi-
cient of 2.0 is at xOPT = 0.8, whereas a barrier coefficient of 1.0 yields an xOPT minimum of 0.9.
Because the combined objective optimum cannot converge exactly to the xMAX limit, some discrep-
ancy between it and the explicit objective optimum must remain. A final barrier coefficient value that
is defined to be rather small should drive the discrepancy to a fairly insignificant value.
14.7.3 Formulating the Equation

Based upon the augmented Lagrangian (L´(x, ) ) formulated in (14.4), the optimum solution to this
nonlinear problem is sought by employing Newton’s second ordered solution method. The standard
Kuhn-Tucker conditions formulate the following equation.
xxL´(x, ) xL´(x, ) x xL´(x, )

 =
xL´(x, ) L´(x, ) L´(x, )
(14.5)
The solution to this equation provides corrections to the dual variables, x and , and solves a
quadratic approximation to the nonlinear system. These variable corrections are driven by the right-
hand side (RHS) of the system of equations.
The RHS is of length N+M where N is the number of power system variables (x) and M is the
number of equality constraint equations (h(x) = 0). The RHS matrix is composed of a lambda
gradient term, -L´(x, ), encompassing the equality constraint residuals, -h(x), as observed in
(14.4). This term encourages the value of x to move in a direction that reduces the mismatch. The
x gradient term of the RHS, -xL´(x, ), encourages x to move in a direction that minimizes the
combined objective function.
The four terms of the square KT matrix on the left side of the equation are themselves matrices.
Because the Lagrangian is linear in , the lower diagonal submatrix is uniquely zero. The off-diag-
onal sub-matricies are merely derivatives of equality constraint equations in terms of the power
system variables, and are the Jacobian (MxN) and its transpose (NxM). The short-hand reference
to the upper diagonal submatrix is the Hessian.
Newton’s second ordered solution method approximates the combined objective function with a
quadratic equation in x. The quadratic equation is constructed for some point x´ such that the
tangent to both the quadratic and the nonlinear expressions are equivalent at x´. Figure 14-11 illus-
trates the quadratic approximation to the combined objective function for a single barrier coefficient,
with a linear explicit objective, and a number of evaluated conditions x´. The values of x´ determined
for each curve are shown in the table provided within the graph. As an example, the value of x for
which the tangent to curve C and the tangent to the combined objective is identical occurs at x´ =
0.7. Additional analysis of this graph is provided by an example in Iterative Solution Strategy.
14-28

16:22
POWER
TECHNOLOGIES,
DIMINISHING BARRIER COEFFICIENT
INC.R
FILE: barrier1
FRI JAN 10, 1992

CHNL# 1: 10.0*(1.0 - [X]) - LOG(1.0-[X])
14.000 -1.000
CHNL# 1: -LOG(1.0-[X])
14.000 -1.000
CHNL# 1: 10.0*(1.0 - [X]) - LOG(1.0-[X]) * 2.0
14.000 -1.000
CHNL# 1: -LOG(1.0-[X]) * 2.0
14.000 -1.000
CHNL# 1: 10.0*(1.0 - [X])
14.000 -1.000
1.0000
BARRIER COEFFICIENT = 1.0
0.80000
BARRIER COEFFICIENT = 2.0
0.60000
X
0.40000
EXPLICIT OBJECTIVE
0.20000
0.0
Figure 14-10. Effects of Reducing the Barrier Coefficient
14-29
Combined nonlinear
objective function
Curves A through E are quadratic

approximations to the objective
Infeasible region
Feasible region
Figure 14-11. Quadratic Approximation to Combined Objective
14-30
Iterative Solution Strategy

The solution to the equation formulated in (14.5) provides corrections to the dual variables, x and
as driven by the right-hand side (RHS) of the system of equations. The solution algorithm is iter-
ative. It constructs a KT problem formulation about some estimated x and , calculates corrections
and updates the variables.The KT problem is formulated using initial estimate of x and and iter-
atively solved to produce corrections in x and .
x´ = xold + x (14.6)
´ = old + x (14.7)
The computed correction, or step x), when added to x´, determines the new minimum of the
quadratic equation. From this point a new quadratic equation is developed and a new step is
computed. As x´ approaches the nonlinear optimum, the minimum of the quadratic equation
converges to the minimum of the nonlinear combined objective. When the quadratic solution esti-
mate is developed for an x´ that is far from the optimum, the computed step may force some
elements of x to violate their limits. Because the combined objective is not defined for infeasible
values of x, it becomes necessary to reduce, or decelerate the correction to x and take a smaller x
step.
Within the OPF iteration log, the step is reported in per unit. A step of 1.0 implies that 100% of the
correction can be added to x' without violating any limits. Otherwise, the reported step is less than
1.0 and the new value indicates by how much the most limiting element of x reduces the correction.
Example
In Figure 14-11, the combined nonlinear objective function for one particular barrier coefficient (in
this case 2.0) is shown by the solid, unlabeled line. Each of the other five lines are different
quadratic approximations to the objective function curve. The values x´ displayed in the table
provided within the graph indicate the value at which the tangent to the objective function and the
tangent to the quadratic approximation is the same. The xOPT values reflect the optimal minimum
of x and in some situations the value of x may need to be corrected so that it achieves a feasible
value as close to xOPT as possible. For this particular example, all values greater than 1.0 are
infeasible.
The quadratic curves in Figure 14-11 exhibit a number of situations that may be encountered by the
program during the solution process. The following scenarios illustrate the necessary corrections in
x and the resulting step size.
For the quadratic approximation exhibited by curve A, the value at which the tangent to
the objective function and the tangent to curve A is identical, occurs at x' =.5. The optimal
value of x for this approximation occurs at xOPT = 2.0. The optimal correction is therefore
Scenario A (2.0 - 0.5), resulting in a x of +1.5. Because an xOPT value larger than 1.0 falls in the
infeasible region, the correction must be truncated to x< +.5 to ensure a feasible result.
This results in a reported step of 0.5/1.5, or 0.33333. All of x is scaled by the most
limiting element.
For curve B, the condition where the tangents are identical occurs at x´=.6 with an optimal
value of x occurring at xOPT = 1.0. In this situation, the optimal value of x lies right on the
Scenario B
border of the feasible region and a full correction of x = 1.0 - 0.6 = 0.4 can be made.
Because 100% of the step can be made, a value of 1.0 is reported for the step.
14-31
Likewise to Scenario B, except that the optimal x is at xOPT = 0.85. This again is present
Scenario C in the feasible region resulting in a full optimal correction of 0.15 and a recorded step of
1.0 (100%).
For this particular approximation the values at for the condition x' and the optimal
Scenario D minimum xOPT both occur at 0.8. In this situation, there is no correction required and a
step size of 1.0 is recorded.
This situation is similar to Scenario C except that the corrected step must be taken back-
Scenario E
wards, thereby resulting in a x of -0.15.
In these examples all calculations are based on the actual values presented in each of the
scenarios. Within the program, the corrections in x and the step size ratio also take into consider-
ation a tolerance value to ensure feasibility. This implies that in situations such as the one
encountered in Scenario B, a slightly smaller step would likely be taken to take into account the
small safety margin around the point of infeasibility. The step size would therefore be a little bit less
than 1.0.
Reduction of the Barrier Terms: The barrier terms contribute to the KT formulation and their
impact is diminished as the solution progresses. It is not necessary to solve to the optimal
condition every time the value of the barrier coefficient is modified. In the PSS®E OPF, the
barrier coefficient is reduced by a factor of 5 at the start of the solution for every iteration
which results in a favorable step larger than 0.5, This allows for the solver to take larger
steps towards the optimal solution. After the solution has made some progress the barrier
coefficient is reduced by a factor of 5 at every iteration. This allows the solver to progress
more quickly towards the optimal solution. The PSS®E OPF starts with a default of 1.0 for
the initial barrier coefficient value and progressively reduces it until the final value of the
barrier co-efficient is reached, as defined by the power flow Convergence Tolerance value.
The exponential decay of the barrier coefficient is illustrated in Figure 14-12.
In some instances, particularly for large or difficult cases, it is suggested to use a larger
positive initial value for the barrier parameter. Values that are too small may prevent the
solver from converging to an optimal solution fast enough, or in some cases, may cause a
failure to solve. Although there is no universal initial value that works for every problem, it
has generally been found that a value on the order of 100 can improve the efficiency and
robustness of the OPF, especially for the large-scale optimization problems. If the optimi-
zation problem you have presented to the PSS®E OPF does not solve with the initial default
value of 1.0, then try values such as 10, 20, 100, or others. As always, there may be some
problems that do better with a smaller initial barrier coefficient value, such as 0.1 or 0.01.
14-32

14:26
POWER
TECHNOLOGIES,
DIMINISHING BARRIER COEFFICIENT
INC.R EXPONENTIAL DECAY
FILE: barrier1
TUE JAN 21, 1992

CHNL# 1: 10.0*(1.0 - [X]) - LOG(1.0-[X]) / 100.
14.000 -1.000
CHNL# 1: 10.0*(1.0 - [X]) - LOG(1.0-[X]) / 10.
14.000 -1.000
CHNL# 1: 10.0*(1.0 - [X]) - LOG(1.0-[X])
14.000 -1.000
CHNL# 1: 10.0*(1.0 - [X])
14.000 -1.000
1.0000
MU=-1
MU=0
0.80000
0.60000
X
0.40000
0.20000
0.0
Figure 14-12. Diminishing the Barrier Coefficient
14-33
The Right-hand Side (RHS): The entries in the RHS of the KT problem are the mismatch
terms. These values drive the variable corrections. When the RHS becomes small, the
correction magnitude will also be small. Therefore, the mismatch magnitude is a good solu-
tion convergence indicator.
The mismatch criteria may be applied to the entire RHS or, by default, to only the lambda
gradient terms (i.e. the bus-power mismatch equations). The latter is a single variable
mismatch criteria that ensures the power flow equations are solved, but does not ensure
convergence in . Generally, iterations beyond those required to meet the single variable
criteria do not appreciably decrease the objective function. In some applications however,
the objective sensitivity information may be a primary concern. For example, the value of 
may be used to obtain cost signals for transmission system access in wheeling power
under third party agreements. In situations such as this, where accurate sensitivities are
desired, the dual variable mismatch criteria should be employed (see Use Dual Variable
Convergence Criteria).
When viewing the OPF iteration log, the single variable power flow mismatch value is
reported under the column labeled Mismatch, whereas the dual variable mismatch is
reported under the column labeled Norm RHS. The solution tolerance is obtained from the
value specified for the Newton tolerance, TOLN, as defined within the standard power flow
solution parameters.
Solution Convergence Criteria

The iterative solution process is considered converged when the following criteria are met:
• the final value of the barrier parameter is obtained,

• the final value of the clamp tolerance is obtained (this value is examined only if the
clamp equation has been employed for nonoptimized generator controls),
• a unit step (Step = 1.0) has resulted in the final iteration, and
• the mismatch is below a user-controlled tolerance.
When all convergence criteria are satisfied, the solution process terminates with an Optimal
Solution Found message. An abnormal termination of the OPF solution will result in an error
message.
Terminated After XX Iterations: If the solution process fails to converge within the maximum
iteration limit, the following error message appears at the bottom of the solution iteration
log:
Error: Terminated after XX iterations--reached iteration limit
This error indicates that the maximum iteration limit value (ITMXN), as displayed to the far
right of the message, has been exceeded. Review the progress of the solution iteration log
and examine the formatted report for any violations or inordinately large sensitivities to
determine whether to proceed with the same problem statement at an increased iteration
limit, or to reexamine and modify the original problem statement.
If it appears that the solution is making some progress, and not diverging, then it is likely
that the maximum iteration limit (ITMXN) simply needs to be increased. This value can be
altered (refer to PSS®E GUI Users Guide, Section 19.3, OPF Parameters or Section 11.1,
Specifying Solution Parameters).
14-34
Blown Up after XX Iterations: If the solution is progressing poorly, then the iterative process
will be terminated with the following error message:
Error: Blown up after XX iterations.
This could occur for a number of reasons, of which the most common are:
- There are many constraints and not enough available controls.
- Constraints overlap and do not provide a feasible solution space.
- The solution started at a point which makes it difficult to find the optimal solution.
In the first two instances, try opening up some of the constraint limits or setting the limit type
to Reporting Only to try to get a sense of which constraints are most critical. It may be
necessary to also introduce more controls.
In the latter situation, changing the Initial Barrier Coefficient value may help to attain a solu-
tion. By default the initial value is 1.0, but for some large-scale problems a larger value
improves the robustness of the solution. Try values such as 10, 20, 100 or 120. There may
also be problems that do better with a small initial value (0.1 or 0.01) as well. Refer to the
Reduction of the Barrier Terms and Section 14.10.3, Tolerance Options for more informa-
tion.
In general, identifying an infeasible problem is often heuristic and takes some experience
before becoming proficient at recognizing which actions need to be taken. There are two
places to look at for additional information: the iteration log and the OPF Report File.
The formatted OPF output report illustrates the objective sensitivities of the constrained
variables. By comparing the relative magnitudes of these sensitivities, the most penalizing
constraints can be identified. Sensitivities are useful even for infeasible terminations in that
they help identify the most effective places where additional control variables may be
needed and/or limits may need to be relaxed.
If, upon examination of the OPF report, nothing appears to be inherently wrong with the
problem statement, the iteration log may provide additional insight into why the solution
may have terminated as infeasible.
An iterate of the solution process is considered to be good when the following criteria is
met:
- The difference between the values of the nonlinear objective function (NL Objec-
tive) in the prior and present iterations is greater than, or equal to, zero. A value
less than zero indicates that the objective function was not significantly reduced in
the prior iteration.
- The ratio of largest mismatch between the present and prior iteration is less than
0.95. A value larger than, or equal to, 0.95 indicates that the mismatch was not sig-
nificantly reduced in the prior iteration.
When one, or both, or the above criteria are not met, the iteration is considered bad and
the iteration number displayed in the solution log is marked with an x. Under certain condi-
tions, the solution process will terminate as infeasible:
- If the value of the barrier is fairly large (greater than 0.011) and the number of suc-
cessive bad iterations equals the Bad iteration coarse limit as specified (refer to
PSS®E GUI Users Guide, Section 19.3, OPF Parameters) OR
14-35
Data Input and Storage Program Operation Manual
- the value of the barrier is small (less than, or equal to, 0.011) and the number of
successive bad iterations equals the Bad iteration fine limit, as specified (refer to
PSS®E GUI Users Guide, Section 19.3, OPF Parameters) OR
- the step size (as displayed under the Step column in the solution log) is below the
minimum barrier step size tolerance.
If the solution is making progress, albeit slow, then it is possible that an increase in the bad
iteration limits will give the solution more time to proceed and an optimal solution will be
found (refer to Bad Iteration Coarse Limit and Bad Iteration Fine Limit).
14.8 Data Input and Storage

The constraint, control and solution options data associated with a given optimal power flow
problem statement can be introduced, stored and retrieved through the use of data files and inter-
active spreadsheets. The principal files and tools used by the optimal power flow activities for data
manipulation and interrogation are as follows.
PSS®E Saved Case File

A binary file that efficiently stores a complete image of everything within the PSS®E
working case, including optimal power flow data and solution settings.
Optimal Power Flow Raw Data File
An ASCII text file containing the optimal power flow control and constraint data records.
Optimal Power Flow Options File, PSSOPF.OPT
A binary file containing the optimal power solution parameter settings. This file may be
used to override default options established at the time the program is initiated.
Optimal Power Flow Spreadsheet View and Data Tables
A set of interactive spreadsheets and tables for viewing and editing optimal power flow
data.
The following sections discuss, in detail, how each of the above files and functions are utilized by
the optimal power flow in the preservation, modification and restoration of optimal power flow data.
14.8.1 PSS®E Saved Case

All data pertaining to the optimal power flow problem statement, including controls, constraints,
objectives and solution parameters are preserved in the PSS®E binary Saved Case File. Each
saved case represents a complete power flow study, including all power flow data and optionally,
any optimal power flow data and solution parameter settings. After all of the information for a study
has been brought into the PSS®E working case and preserved within a PSS®E Saved Case, it
becomes almost unnecessary to refer to any other files.
Existing saved cases may be brought into the working case at any time. When a PSS®E Saved
Case is brought into PSS®E, the complete power flow description, including that of the optimal
power flow problem, will automatically be loaded into the working case. If a saved case is read in
that does NOT contain any OPF data, then the only OPF related data that will be initialized within
the working case will be the default settings of the OPF solution parameters. These values are
either initialized to default values, or to the values stored within the PSSOPF.OPT file, if such a file
exists. Refer to Section 14.8.3 Optimal Power Flow Options File: PSSOPF.OPT for details on the
use of the PSSOPF.OPT file.
14-36
Program Operation Manual Data Input and Storage
Optimal power flow data can easily be added to the working case by reading in data through an OPF
Raw Data File or by entering data via the OPF spreadsheets and data tables. It is not possible to
append data by reading in a second saved case file.
14.8.2 Optimal Power Flow Raw Data File

Activity ROPF
The OPF Raw Data File populates the working case with new or revised optimal power flow data
and stores only optimal power flow data for use in future sessions. It specifically contains data
records for the controls and constraints of an OPF problem statement. It does not contain any infor-
mation related to stated objectives, tolerances or other solution parameters.
The file itself is in ASCII format and contains a series of data records group together by OPF data
category. The data categories must be entered in a particular order, as defined by Figure 14-13. A
single data record containing only a zero indicates that all entries for a particular data category have
been entered. If no data records are to be entered for a particular category, then only a single zero
needs to be placed in the data file. If a record with a single q is encountered during processing, then
the file is closed and the program does not attempt to read any further data records.
®
PSS E GUI Users Guide, Section 19.1, Reading Optimal Power Flow Data
Section 16.1, Reading Optimal Power Flow Data
14.8.3 Optimal Power Flow Options File: PSSOPF.OPT

The Optimal Power Flow Options File provides a means for saving and restoring optimal power flow
solution parameter settings between program sessions. When PSS®E is installed, a set of default
run-time options is established. Upon initiation of the PSS®E program, the default optimal power
flow options may be overridden by the values contained within the PSSOPF.OPT file. Likewise, by
bringing in a PSS®E Saved Case file, the values of the option settings stored within it may override
all previous settings.
In addition to the options described in Section 3.3.3 Program Run-Time Option Settings, there are
a number of option settings specific to the optimal power flow program module. Details of each
option can be found in Section 14.10 Optimal Power Flow Solution Options. The OPF Parameters
specified may be saved to the PSSOPF.OPT options file. The resulting PSSOPF.OPT file is located
in the current working directory. The only information that is not currently stored is that of a
subsystem.
Each time PSS®E is initiated, it will look for the existence of the PSSOPF.OPT file using a particular
directory search sequence, as outlined below.
1. The current working directory. If the file is found, the settings within the file will automat-
ically be applied and further searches in the alternate locations defined in steps 2 and
3 will not be pursued.
2. The user’s home directory. If the file is located here, the settings within the file will auto-
matically be applied and further searches in the alternate location defined in step 3 will
not be pursued.
14-37
Constraint and Control Data Program Operation Manual
3. The program default directory. If the file is located in the PSS®E subdirectory PSSPRM,
then the settings within the file will automatically be applied. If the file is not found, then
no further searches are ensued and the original default values remain unchanged.
14.8.4 Optimal Power Flow Spreadsheet View

General use of the Spreadsheet View is covered in the PSS®E GUI Users Guide, Chapter 2.
The optimal power flow spreadsheet view allows viewing and editing all bus oriented optimal power
flow data records. If optimal power flow data is not present in the working case prior to invoking the
OPF data spreadsheet, then the option to initialize the OPF data is provided.
After being initiated, the OPF spreadsheet view is populated with the default and defined data
values for the optimal power flow data present in the working case. Clicking on the tabs at the
bottom of the spreadsheet allow for navigation between the various bus oriented OPF data records.
By hovering the mouse cursor over a particular tab, the full name of the tab will pop up.
For information on adding records using the OPF spreadsheet and modifying default values refer
to PSS®E GUI Users Guide, Section 19.2, Data Initialization for OPF.
14.8.5 Optimal Power Flow Data Tables

OPF Data Tables allow access to view and edit all table oriented optimal power flow data records.
This includes cost curve tables, period reserve constraints, interface flow constraints, and linear
dependency constraint equations.
14.9 Constraint and Control Data

14.10 Optimal Power Flow Solution Options

Optimal power flow solution parameters may be applied prior to initiation of the OPF solution. These
solution parameters are used to further define the optimal power flow problem statement and may
direct the program to perform additional functions after the solution process has completed.
The five solution parameter groups are as follows:
• Objectives: A list of all available solution objectives. Cost coefficient values are also
listed for those objectives that may have an associated cost applied.
• General: A list of general optimal power flow solution options and additional constraint
equation directives that may be activated during the solution process.
• Tolerances: A list of solution tolerance values and advanced level solution parameters
that may be altered to influence the progress of the solution algorithm.
• Control: A list of options pertaining to the treatment of nonoptimized controls within the
optimal power flow problem statement.
• Reporting: A list of output reporting options. These must be defined prior to solution
initiation.
14-38
Program Operation Manual Optimal Power Flow Solution Options
14.10.1 Objectives
More than one objective may be applied simultaneously to formulate a composite objective function.
The exception is the Minimize fuel cost and Minimize active power loss objectives, of which neither
can solve for their respective goals if the other objective is active. This is covered in more detail in
Minimize Fuel Cost and Minimize Active Power Loss.
Table 14-2. Optimal Power Flow (OPF) Objectives
OPF Objective Description

Directs the OPF to find the minimal amount of active power required to serve losses
and loads.
The system swing bus is automatically considered into the problem statement
although its active power generation is fixed at the initial value and not considered
an available control.
In addition to specifying the Minimize fuel cost objective, three key data elements
are essential to the fuel cost model:
• Generators for dispatch: Each eligible participating generator in the active
power dispatch model must have a Generator Dispatch record defined. The
information within the Generator Dispatch record includes the percentage of
total generation capacity available for dispatch.
• Active power dispatch constraints: Each Generator Dispatch record
references a single Active Power Dispatch Table that defines the minimum
and maximum active power available for dispatch, and references a Cost
Curve Table.
• Generator fuel cost curves: Each Active Power Dispatch Table references
one of three available cost models: piece-wise linear, piece-wise quadratic
Minimize Fuel Cost and polynomial.
When the Minimize fuel cost objective is enabled, the Minimize active power loss objective is automat-
ically disabled. The combination of these two objectives does not formulate a feasible problem
statement. The minimization of active power losses is achieved by holding active power generation
fixed and varying the available reactive power. This is in direct conflict with the fuel cost minimization objec-
tive which relies on the ability to vary active power generation to make up for losses or loads.
Historically employed for minimization of active power losses. In contrast to the
separate minimize active power loss objective, the active power slack objective has
the disadvantage of not being able to distinguish between optimized and non-opti-
mized subsystems.
This objective function adds the change in the active power injection of the retained
slack buses (type 3) to the composite objective. When the active power dispatch is
Minimize Active fixed at every generator except the slack bus, then the minimization of active power
Power Slack losses is mathematically equivalent to the minimization of slack bus active power.
Generation There are no additional data models required to complement this objective function.
Minimize Reactive Adds the reactive power generation of all in-service and regulating generators to
Power Slack the composite objective.
Generation There are no additional data models required to complement this objective function.
14-39
Optimal Power Flow Solution Options Program Operation Manual
Table 14-2. Optimal Power Flow (OPF) Objectives (Cont.)

Attempts to reduce active power losses in the system. It is frequently employed,
either individually or in combination with other objectives. A small reduction in
losses can often produce substantial cost savings.
A global loss objective coefficient may be assigned by entering a cost value directly
into the input field labeled Active power loss cost coefficient ($ / pu MW). A coeffi-
cient value of 1.0 has no effect on the active power loss objective. If multiple
objectives are employed, the relative costs of each objective to one another deter-
Minimize Active mines which objective is treated with a higher priority.
Power Loss There are no additional data models required to complement this objective function.
The Minimize active power loss objective and Minimize fuel cost objective cannot be simultaneously
employed due to the competing goals. The minimization of active power loss is achieved by holding
active power generation fixed and varying the available reactive power which is in direct conflict with
the minimization of fuel cost which relies on the ability to vary active power generation to make up for losses
and serve loads.
Attempts to minimize vars or other voltage related objectives to fine tune the results
and help to eliminate circulating reactive flows and other undesirable phenomena
which may result in the transmission network.
A global loss objective coefficient may be assigned by entering a value directly into
the input field labeled Reactive power loss cost coefficient ($ / pu MVAR). A coeffi-
cient value of 1.0 has no effect on the reactive power loss objective. If multiple
objectives are employed, the relative costs of each objective to one another deter-
Minimize Reactive mines which objective will be treated with the higher priority.
Power Loss There are no additional data models required to complement this objective function.
Determines the minimal amount of series compensation required to relieve flow
constraints. This objective is often used in conjunction with branch flow
(Section 14.9.15 Branch Flow Constraint Data) and interface flow constraints
(Section 14.9.16 Interface Flow Constraint Data).
Minimize Adjustable Candidate branches for series compensation must be defined prior to initiation of
Branch Reactances the OPF solution (Section 14.9.3 Adjustable Bus Shunt Data).
Determines the minimal amount of shunt reactors and capacitors that need be
placed at candidate buses. It may be employed in voltage stability studies or to
assist in the minimization of a composite objective function.
Candidate buses for var adjustment must be defined through Adjustable Bus Shunt
records prior to the OPF solution (Section 14.9.3 Adjustable Bus Shunt Data).
To encourage the deployment of vars, particularly for voltage stability studies, it may
be desirable to fix transformer taps, phase shifters and switched shunts (see Fix
Transformer Tap Ratios).
During the OPF solution, var values may optionally be rounded to the nearest
discrete block step by choosing to Round switched shunt vars (see Round
Switched Shunt Vars).
Minimize Adjustable After the solution process has completed, the new shunt additions will automatically
Bus Shunts be reflected in the power flow bus data of the working case as bus shunts.
14-40
Table 14-2. Optimal Power Flow (OPF) Objectives (Cont.)

Determines the minimal amount of load adjustment to make at candidate buses. It
is most commonly used to study the effects of load shedding to ease voltage
constraint violations due to a severe disturbance on the system. It is possible
however to formulate a problem statement in which the minimization of load addi-
tions, as opposed to load shedding, is the objective.
Candidate buses for load adjustment must be defined through OPF Adjustable Bus
Load records (Section 14.9.4 Bus Load Data) and Adjustable Bus Load Table
records (Section 14.9.5 Adjustable Bus Load Table Data) prior to the solution.
After the OPF solution process, new load adjustment factors will be reflected in the
Minimize Adjustable value Psi, and displayed with the load values in PSS®E output reports (for
Bus Loads example, refer to Section 5.37, Displaying Power Flow Data).
Used in inter-area studies to encourage or curtail flows across a particular interface.
Interface flow limits and participating branches must be defined through the Inter-
face Flow records described in Section 14.9.16 Interface Flow Constraint Data
prior to the solution. In conjunction, the Constrain Interface Flows option, must
be enabled for the interface flow objective and the interface flow constraints to be
recognized during the OPF solution process.
A global interface flow cost coefficient may be assigned by entering a value directly
into the input field labeled Interface flow cost coefficient ($ / pu Flow). A negative
value will attempt to maximize interface flows. A coefficient value of 1.0 has no
effect on the interface flow objective. If multiple objectives are being simultaneously
Minimize Interface employed, the relative cost of the objectives to one another determines which
Flows objectives are be treated with a higher priority during the solution process.
Will influence the reactive generation reserves. It introduces to the combined objec-
tive function a component term proportional to the excursion of reactive power
generation from the maximum reactive power generation limit for each in-service
generator that is a member of the optimized subsystem.
A scalar objective coefficient may be assigned by entering a cost value directly into
the input field labeled Reactive generation reserve cost ($ / MVAR).
When the objective is employed with a negative cost coefficient, the reactive gener-
Minimize Reactive ation reserves will tend to be increased. When a positive cost coefficient is
Generation Reserve employed, the reactive generation reserves will tend to be decreased.
14.10.2 General Options

Table 14-3. Optimal Power Flow (OPF) Parameters - General Options
Option Description
Introduces area interchange constraints into the OPF problem statement for each
area interchange record defined in the standard power flow model. By default, area
Regulate Area interchange constraints are not introduced. For a complete description of the
Interchange model, refer to Section 14.6.7 Regulated Area Interchange.
Introduces defined interface flow constraints (Section 14.9.16 Interface Flow
Constraint Data) and the Minimize interface flows objective, if enabled, into the
OPF problem statement.
Constrain Interface If the Constrain interface flows option is not enabled, the Minimize interface flows
Flows objective and any interface flow constraints will be ignored and not used.
14-41
Table 14-3. Optimal Power Flow (OPF) Parameters - General Options (Cont.)
Option Description
Automatically scales the objective coefficients and derivatives toward a value better
suited to the solution calculation. The variables are scaled to a value that is numer-
ically closer to unity and then rescaled back after the solution process has
Use Automatic completed. In some situations this may improve convergence, without significantly
Scaling altering the solution.
Directs the solution process to continue until the magnitudes of the entire KT
problem right-hand side (both x and ) fall below a specified tolerance. When the
option is disabled, only the bus power mismatch equations (x) are examined. The
use of the dual variable convergence criteria is most useful when accurate sensitiv-
ities are desired. Refer to Section 14.7.3 Formulating the Equation and more
specifically The Right-hand Side (RHS) for further information.
The convergence tolerance is obtained directly from the PSS®E Newton Solution
Use Dual Variable tolerance, TOLN, and may be modified (refer to PSS®E GUI Users Guide, Section
Convergence Criteria 11.1, Specifying Solution Parameters or Section 19.3, OPF Parameters).
Fixes all transformer tap ratios to their current values, thus preventing them from
being employed as controls during the OPF solution process. It is often used to
Fix Transformer Tap encourage the deployment of other controls, such as var adjustment, during the
Ratios OPF solution.
Fixes all transformer phase shift angles at their current values, thus preventing
them from being active during the optimal power flow solution process. This forces
Fix Transformer the possible employment of alternate controls in order to meet the desired
Phase Shift Angles objective.
Fixes all switched shunts at their current values, preventing them from being altered
during the optimal power flow solution process. This action may allow alternate
Fix Switched Shunts controls to be deployed during the solution.
Directs the solution process to round transformer tap ratios to their nearest discrete
tap setting after an initial solution is obtained. It then attempts to pursue a feasible
solution with the tap settings fixed.
Rounding to the nearest tap setting attempts to mimic the discrete nature of trans-
former taps. During the OPF solution, transformer taps are treated as continuous
controls. In some situations a final solution may not result after rounding to a
discrete tap position, although this is unlikely.
When the rounding takes place, upper and lower bus voltage limits may need
to be slightly relaxed to attain a solution. If this should happen, an integer
value will appear to the far right-hand side of the OPF solution iteration log
Round Transformer under an unlabeled column. This value indicates the number of variables for which
Tap Ratios limits needed to be relaxed as a result of rounding.
14-42
Table 14-3. Optimal Power Flow (OPF) Parameters - General Options (Cont.)
Option Description
Directs the OPF solution process to round switched shunt values to their nearest
block setting after an initial solution is obtained and then attempts to continue to a
feasible solution with the switched shunt settings fixed.
This option only applies to switched shunts within the general power flow model. It
does not affect any OPF adjustable bus shunts.
Rounding to the nearest var block attempts to mimic the discrete nature of switched
shunts. During the main OPF solution switched shunt var adjustments are treated
as continuous functions. In some situations the rounding may lead to serious
voltage infeasibilities, particularly if the var block size is rather large. If this should
occur it may be prudent to manually round var settings instead.
When the rounding takes place, upper and lower bus voltage limits may need
to be relaxed to attain a solution. If this should happen, an integer value will
appear to the far right-hand side of the OPF solution iteration log under an
Round Switched unlabeled column. This value indicates the total number of variables for which
Shunt Vars limits needed to be relaxed as a result of rounding.
Temporarily adjusts minimum or maximum bus voltage limits to ensure that the
current voltage is within the specified range.
For example, if the lower and upper voltage limits at a particular bus are set at 0.95
and 1.02 pu respectively, and the initial voltage in the power flow bus data is 0.94,
then the voltage bounds at the bus would temporarily be set to 0.94 and 1.02. Only
the infeasible bound is modified; the actual voltage limits as defined in the corre-
sponding OPF Bus Voltage Attribute data record are not affected.
To permanently change the constraint limits for feasibility, use the Adjust limits
Automatically Adjust option in the Bus Voltage Attribute Spreadsheet. This option may be selectively
Bus Voltages for applied to individual OPF bus voltage constraint records or applied to all buses
Feasibility within a selected subsystem.
Directs the OPF solution process to employ the maximum and minimum emergency
bus voltage limits defined in the OPF Bus Attribute data records instead of the
Impose Emergency normal bus voltage limits. Refer to Bus Voltage Attribute Data Record for further
Bus Voltage Limits information.
Directs the OPF solution process to employ the maximum and minimum emergency
Impose Emergency branch flow limits defined in the Branch Flow Constraint Data Record instead of
Branch Flow Limits the normal branch flow limits.
14-43
14.10.3 Tolerance Options

Table 14-4. Optimal Power Flow (OPF) Parameters - Tolerance Options
Option Description
Indicates, in cost units/pu, the severity for which a variable should be penalized for
an excursion away from its initial value. This penalty is only employed as part of the
quadratic penalty equation applied to transformers and switched shunt controls
residing in optimized subsystems. Nonoptimized transformers and switched shunts
are strictly fixed at their initial working case values.
A separate and unique penalty coefficient may be applied to nonoptimized genera-
tors (Section 14.10.4 Control Options). A full explanation on the treatment of all
power flow controls and the use of the quadratic penalty coefficients is presented in
Section 14.5 Modeling Power Flow Controls.
A hard or soft (linear or quadratic) limit may also be applied to specific constraints
on bus voltages, interface flows or branch flows. When in effect, these treatments
will override the general quadratic penalty treatments for optimized transformers or
switched shunt controls.
By default, the quadratic penalty coefficient is zero for transformer and switched
Quadratic Penalty shunt controls. The quadratic penalty will not be applied unless the quadratic
Coefficient penalty coefficient is assigned a value greater than zero.
The initial value of the barrier function coefficient. At each of the first few iterations
of the solution algorithm, the barrier coefficient value is reduced by a factor of 5
provided the solution algorithm takes a step of at least 0.5. This allows the solver to
take larger steps towards the optimal solution. The progress of the minimization of
the barrier function can be gauged by examining the values of  (mu) printed in the
OPF solution iteration log. After some solution progress has been made, the barrier
coefficient is reduced by a factor of 5 at each iteration, regardless of whether the
step-size is greater than 0.5 or not. This allows the solver to make faster progress
towards the optimal solution.
By default, the initial barrier coefficient is assigned a value of 1.0, which corre-
sponds to a value of 0 for (1.0 = 100). This may be too small for some optimization
problems and may prevent the solver from converging to an optimal solution fast
Initial Barrier enough, or to fail. Initial values on the order of 10 or 100 can improve the efficiency
Coefficient and robustness of the solution for some optimization studies..
Final coefficient value that the barrier function is attempting to attain.
At each iteration of the solution algorithm, the value of the barrier coefficient is
systematically reduced. As long as no infeasible conditions occur, the process will
continue until all of the convergence criteria are met. One of the criteria (as outlined
in Solution Convergence Criteria) is that the final value of the barrier parameter
be less than, or equal to, the final barrier coefficient.
By default, the final barrier coefficient is assigned a value of 0.0001, which corre-
Final Barrier sponds to a value of -4 for (mu). As the iteration log progresses, you should see
Coefficient the value of steadily descend toward this final value.
At each iteration of the nonlinear barrier function, the step length taken by the
barrier function algorithm is compared against this value. If the required step length
is less than the minimum barrier step length tolerance value, then the solution
Minimum Barrier terminates with an infeasible condition.
Step Length The default value for the minimum barrier step length tolerance is 0.00001. It is
Tolerance unlikely that you will encounter a situation where you need to modify this value.
14-44
Table 14-4. Optimal Power Flow (OPF) Parameters - Tolerance Options (Cont.)
Option Description
Specifies the number of bad iterations allowed when the barrier coefficient is
greater than 0.011 (mu greater than -2) before the solution progress is terminated
as being infeasible.
At each iteration of the solution process several criteria are evaluated to assess
whether the solution should continue or be terminated due to infeasibility. In
general, the solution will terminate on an infeasible condition if at least one of the
following conditions are encountered.
• the number of successive bad iterations hits a predefined limit, or
• the solution process is forced to take an algorithmic step that is smaller than
a predefined minimum tolerance.
As used in the context above, a bad iteration is defined as one in which:
• the difference between the nonlinear objective function in the present and
prior iterations is less than zero, or
• the ratio of the largest mismatch value between the current and prior
iterations is greater than, or equal to, 0.95.
By default, the coarse limit on the number of bad iterations is set at 3. If the solution
process appears to be making very small progress, it is possible for this limit to be
exceeded. In situations where the mismatch value is making slow, but steady, prog-
Bad Iteration Coarse ress, and the reduction of the objective is also making some progress, it is
Limit reasonable to try to increase the bad iteration limit.
Specifies the number of bad iterations allowed when the barrier coefficient is less
than, or equal to, 0.011 (mu less than or equal to -2) before the solution progress is
terminated as being infeasible.
By default, the fine limit on the number of bad iterations is set to 10. If the solution
process appears to be making very small progress it is possible for this limit to be
exceeded prematurely. In situations where the mismatch value is making slow, but
Bad Iteration Fine steady, progress, and the reduction of the objective is also making some progress,
Limit it is reasonable to try to increase the iteration limit.
Indicates the maximum number of allowable iterations before the OPF solution
process will end. This value is identical to the Iteration limit (ITMXN) value used for
Maximum Iteration the Newton power flow solution activities. It may also be modified (refer to PSS®E
Limit GUI Users Guide, Section 11.1, Specifying Solution Parameters).
Defines the largest allowable mismatch tolerance in MW and Mvar. For the OPF
solution process to terminate successfully, the largest mismatch must be at, or
below, the convergence tolerance specified.
This value is identical to the largest mismatch in MW and Mvar (TOLN) value used
Convergence in the main power flow Newton solutions. It may also be modified (refer to PSS®E
Tolerance GUI Users Guide, Section 11.1, Specifying Solution Parameters).
14-45
Table 14-4. Optimal Power Flow (OPF) Parameters - Tolerance Options (Cont.)
Option Description
The following options affect the decision process of the solution algorithm and are
strictly provided for highly unique situations. There are no particular instances
which would warrant modifications to any of these values. Short descriptions of
each option are offered below.
Apply Step Size Limit: indicates to the solution algorithm that an alternate
lambda mismatch step size is to be taken. In conjunction with this option, the
Step Length for Barrier Function specified determines the step size to be
taken.
By default, the algorithm automatically determines the appropriate step size to
be taken along the search direction and a full step is always used for the
mismatch.
LaGrange Multiplier Blow-up Tolerance: After the first iteration of the solution
process, a check is performed to ensure that the values of the right hand
side of the equation are not diverging. If the largest lambda value exceeds
the Lagrange multiplier blow-up tolerance, then an asterisk (  ) is placed to
the right of the Normal RHS value in the iteration log output report.
By default the Lagrange multiplier blow-up tolerance is set at 100000.0.
Interior Shift Parameter: indicates by how much a variable should be moved
more interior of the upper and lower limits.
By default, the interior shift value is set at 0.1.
Step Length for Barrier Function: By default, this value is set to 0.99. This
implies that 99% of the largest possible step is taken. If an exact Newton
step can be taken without hitting a bound, then the step size will not be
proportionately reduced.
Minimum Tap Ratio Step: allows the minimum limit of all fixed transformer taps
to be opened up. Any adjustable transformers with a valid tap range are not
affected.
The value specified for the Minimum tap ratio step establishes a minimum
boundary on the tap setting. For example, if the step value is set at 0.02,
then each fixed tap will have a minimum value of (t-0.02), where t is the per
unit value of the fixed tap.
By default, the tap ratios of all fixed transformers are not altered. This option is
only provided for highly unique situations. Often it is much better to explicitly
define transformer tap limits if tap settings are to be altered.
Maximum Tap Ratio Step: allows the maximum limit of all fixed transformer
taps to be opened up. Any adjustable transformers with a valid tap range are
not affected.
The value specified for the Maximum tap ratio step establishes a maximum
boundary on the tap setting. For example, if the step value is set at 0.04,
then each fixed tap will have a maximum value of (t+0.04), where t is the per
unit value of the fixed tap.
Advanced Algo- By default, the tap ratios of all fixed transformers are not altered. This option is
rithmic Decision only provided for highly unique situations. Often it is much better to explicitly
Tolerances define transformer tap limits if tap settings are to be altered.
14-46
14.10.4 Control Options

Table 14-5. Optimal Power Flow (OPF) Parameters - Control Options
Option Description
Treat all Generators Forces all generators in the network to be treated as nonoptimized. This overrides
as Non-optimized whether the generator is in an optimized subsystem or not.
Applies the clamp equation logic to all nonoptimized generators. This overrides the
quadratic penalty treatment, but does not supersede bus voltage constraints that
may be applied at generator buses.
Values for Final clamp tolerance, Initial clamp tolerance and Clamp slack variable
decay factor may be entered directly into the fields provided.
As described in Clamp Treatment, the OPF solution initializes the problem with
the relatively large Initial clamp tolerance, and then systematically and gradually
reduces this tolerance by the Clamp slack variable decay factor until a value less
than or equal to the Final clamp tolerance is attained. Reductions in both the clamp
equation slack variable and the clamp tolerance are taken when a solution step size
of at least  is achieved.
For example, with a default initial clamp tolerance of 1.0 and a decay factor of 0.1,
the clamp tolerance will gradually be reduced by 10 (multiplied by 0.1) at each
healthy step of the solution process, until a final tolerance value of 0.0001 is
attained.
The Scale clamp constraint by reactive generator limits option scales the clamp
equation by the maximum of either 1.0 or the difference between the upper and
Clamp Non-opti- lower generator reactive limits. This is done internal to the solution to potentially
mized Generators improve mathematical calculations and should be transparent.
Use Generator Directs the solution to hold voltage to the generator scheduled voltage instead of
Scheduled Voltage the current voltage.
The Quadratic penalty treatment of nonoptimized generators is the default if the
Clamp non-optimized generators option is not enabled, and bus voltage constraints
on generator buses are not applied. Quadratic terms are introduced into the objec-
tive function to penalize the excursion of regulated voltage magnitudes from their
Penalty for Fixed offsets. The value specified in the Penalty for fixed voltage field indicates the extent
Voltage to which excursions are penalized.
14-47
Solution Results and Reports Program Operation Manual
14.10.5 Reporting Options

Table 14-6. Optimal Power Flow (OPF) Parameters - Reporting Options
Option Description
Preserves all information on the OPF solution progress to a text file. The contents
Produce an Optimi- of the Optimization Log File is presented in Section 14.11.3 OPF Optimization
zation Log File Log.
By default, the Optimization log filename will be given the name DETAIL if an alter-
nate name is not specified. The filename extension is specific to the computer
system PSS®E is being run on.
If the option to Produce an optimization log file is enabled, then the name of
the log file will be preserved between subsequent OPF solution runs within
the same PSS®E session. The specified filename will not however be
preserved within an external data storage file such as a PSS®E Saved Case or the
Raw Data File. Each time a saved case is brought into PSS®E for which the
Produce an optimization log file option is enabled, the log filename will always
Optimization Log File revert to the default name of DETAIL.
appends the optimization log file with detailed information on each variable and a
complete list of the Lagrange multipliers for each constraint equation. This is the
only place for which this information can be obtained; it is not printed as part of the
Print a Detailed normal solution process. By default, a detailed listing will not be produced as part of
Listing the specified optimization log file.
The OPF solution report automatically generated after the OPF solution includes
information on the control variables affected by the solution process. The OPF
output report information allows a subsystem to be defined so that the records
contained within the report will be limited to just the equipment residing within the
defined subsystem. This includes bounded and infeasible reactive power genera-
tion, regulated buses, transformer tap ratios, transformer phase shift angles and
bounded switched shunts.
By default, information for all equipment is presented in the output report.
OPF Output Report A full description of the contents of the OPF Report File can be found in
Information Section 14.14 Optimal Power Flow Solution Report.
14.11 Solution Results and Reports

Several output reports may optionally and automatically be generated after the OPF solution:
OPF Progress Summary Report: All information pertinent to the progress of the optimal
power flow solution is contained within this summary. By default, the output is directed
to the progress device but may optionally be directed to an alternate device such as a
file or printer.
OPF Solution Report File: A detailed report containing a summary of the optimal power flow
problem statement, and the resulting control variable settings and sensitivities is pro-
duced. By default, this report is directed to the report device.
OPF Optimization Log File: An OPF Optimization Log File may optionally be generated. In
addition to the information included in the OPF solution report, the log file also contains
14-48
Program Operation Manual Solution Results and Reports
problem statement statistics, post solution results, and optionally, a detailed listing of
Lagrange multipliers. The option to produce the OPF Optimization Log File file is set by
enabling the Produce optimization log file option on the Reporting tab of
[OPF - Change Parameters].
OPF Diagram Results: OPF sensitivity results for bus voltage magnitude, bus active and
reactive power in-jection, loads, fixed bus shunts and switched shunts can be selec-
tively displayed on the diagram. A contour plot of values may also be produced.
The following subsections describe the contents of each of the above output reports and files in
more detail.
14.11.1 OPF Progress Summary Report

During the optimal power flow solution information pertaining to its progress will automatically be
displayed to the Progress tab of the PSS®E interface. The output may also be directed to another
device such as a printer or file using I/O Control>Direct Progress output (PDEV)....
The contents of the OPF Progress Summary Report are defined in the following sections.
Problem Size Statistics

A table describing the size of the optimal power flow problem statement is the first item printed in
the OPF Progress Summary Report.
Matrix Size Problem Size

----------- -----------------
CM Rows: 73 Angles 28
CM Columns: 118 Voltages 28
Jacobian elements: 559 Xformers 11
KTM elements: 962 MW gens 4
MV gens 6
Bus Shunts 0
Sw. Shunts 0
Load Shed 0
Flows 3
Interfaces 1
S. Compen. 1
R-cap. 5
Res. Units 4
Reserves 1
Area Int. 0
Lin. Dep. 0
Segments 21
The left-hand column, labeled Matrix Size, provides statistics about the formulated KT problem
discussed in Section 14.7 Solution Process. The information is defined by the following:
Rows: The number of equality constraints.

Columns: The number of power system variables.
Jacobian elements: The number of nonzero entries within the Jacobian matrix.
KTM elements: The number of nonzero entries within the KT matrix.
14-49
The right-hand column, labeled Problem Size, contains information on the total number of power
system variables that formulate the columns of the Jacobian matrix. The labels identifying each vari-
able are defined in Table 14-7 Problem Size Label Descriptions.
Table 14-7. Problem Size Label Descriptions
Label Description
The number of power flow bus nodes processed for voltage magnitude and angle infor-
Angles/ mation. Every bus in the network will have a voltage magnitude column and angle
Voltages column introduced in the matrix. Buses connected by zero impedance branches are
treated as a single node.
The number of transformers processed from the power flow data model. Each trans-
Xformers
former branch has one column introduced for either the tap ratio or phase shift angle.
The number of generator units participating in the active power dispatch model. When
MW gens minimizing fuel cost, piece-wise segmented cost curves will introduce a column for each
in-service segment.
MV gens The number of generator units participating in the reactive power dispatch
The number of participating added var devices. Each added var introduces two columns,
Bus Shunts
one for the capacitive segments and one for the inductive segments.
Sw. Shunts The number of participating switched shunts.
Load Shed The number of participating load adjustment variables.
Flows The number of participating branch flow constraints.
Interfaces The number of defined interfaces.
S. Compen. The number of participating branch reactance adjustment variables.
The number of generator units that have a reactive capability model defined. Each reac-
R-cap.
tive capability model introduces four columns.
The number of generating units participating in the generation period reserve
Res. Units
constraints. Each participating unit introduces two columns.
Reserves The number of generation period reserve constraints.
Area Int. The number of interchange regulated areas.
Lin. Dep. The number of linear constraint dependency equations.
The number of segments used to fully represent the variables of certain models (e.g.,
added vars, linear penalties, etc.). Additional columns are employed to accommodate all
Segments
but the first segment. The number indicated is the total number of additional columns
required for these models.
The problem size information is immediately followed by a qualitative statement indicating the initial
conditions of the optimal power flow problem. An example follows:
Note: There were 3 infeasible variables found.

The sum of the violations is 0.2055,
The largest violation is Efd 206 0.1934.
The first line specifies the number of variables for which initial values violate their stated limits.
14-50
The second line specifies the sum of the absolute values of the per unit values for each constraint
violation.
The third line specifies the variable having the largest constraint limit violation, along with the value
in pu. The nomenclature used to identify the variables (i.e., Efd), is defined in Table 14-8 Jacobian
Column Label Descriptions.
Solution Iteration Log

A summary of the nonlinear solution progress is displayed to the progress device and, optionally, to
the OPF Optimization Log File. As discussed in Section 14.7.1 The Nonlinear Problem, the
nonlinear nature of the OPF problem requires that a series of simpler subproblems be solved. At
each iterate of the solution process, one of the subproblems is solved and a row of information is
displayed describing the progress made. This iteration log is the primary means of monitoring the
progress of the solution.
The output is of the following form:
----------------------------------------------------------------------------------------------------
Iter Mu NL Objective Norm RHS Mismatch(PU) Row Equation Nearest Variable Step size NE
---- -- ------------ ---------- ------------------------------ ------------------------------ ---
1 0 2.88120E+01 2.42E+02 6.34E+00 RC-Q 206 Flow 153 u 4.58E-01
2x 0 2.95010E+01 1.18E+02 3.39E+00 RC-Q 206 Trns 204 u 7.33E-01
3 -1 3.03835E+01 2.23E+02 9.16E-01 F-eq 153 1.00E+00
4 -2 3.04181E+01 7.35E+01 8.11E-02 Peqn 204 Volt 3018 u 1.01E-01
5 -2 3.02021E+01 2.23E+02 7.37E-02 Peqn 204 Segm +70 3.61E-01
6 -2 2.98706E+01 1.70E+02 4.72E-02 Peqn 204 1.00E+00
7 -3 2.97907E+01 5.33E+00 6.03E-03 Qeqn 153 Segm +70 1.08E-01 1
. . .
The information contained within each row is defined as follows:
Iter: The current subproblem, or iteration number. An x following the number indicates that the
prior iteration was determined to be bad according to the definition given in Blown Up after
XX Iterations.
Mu: The barrier coefficient exponent, also referred to as the barrier parameter. As discussed
in Initial Barrier Coefficient, the number  is the exponent of 10. A value of -3 signifies a
barrier parameter value of 10-3, or 0.001.
The barrier parameter is the coefficient in the barrier objective function. The smaller the
barrier parameter, the closer the variables (voltages, taps, and others) can approach their
bounds, if that is the direction that they are driven towards. A large barrier parameter of
about 0.01 will keep just about all variables off their bounds and towards the middle. A small
barrier parameter of 0.00001 (or less will allow those variables to get very close to
their limits.
NL Objective: The sum of all the objective components. This value includes all explicitly
defined objectives, as well as any implicit objective terms that may have been introduced
(i.e., terms of the quadratic penalty equation introduced for certain power flow controls
(Section 14.5 Modeling Power Flow Controls) or the barrier terms required for constrained
variables at a hard limit).
Norm RHS: The infinity norm (i.e., the largest element absolute value) of the right-hand side
(RHS) vector in the optimization solution. An asterisk (  ) to the right of the value indicates
that the value exceeded a predefined lambda tolerance. By default the tolerance is set to
105 and should not need to be modified (Advanced Algorithmic Decision Tolerances). If the
14-51
values are becoming increasing larger, the solution is likely to terminate due to infeasibility
problems. This indicates that the problem is most likely over-constrained.
When the dual variable mismatch criteria (Use Dual Variable Convergence Criteria) is
imposed, the values reported for the Norm RHS and the Mismatch must be less than the
tolerance specified by TOLN in the power flow solution parameters.
Mismatch: The infinity norm of the equality constraints or the lambda gradient portion of the
RHS, better known as the familiar power flow mismatch. To arrive at this value, the absolute
values of the MW and Mvar mismatches at each bus are added together. The resulting
value must be less than the tolerance specified by TOLN in the Power Flow Solution
Parameters option. The mismatch value is in per unit on the system MVA base.
Row Equation: Description of the Jacobian row having the largest mismatch value as
displayed under the Mismatch column. The nomenclature employed to identify the entry is
presented in Table 14-9 Jacobian Row Label Descriptions.
Nearest Variable: Description of the most limiting variable, if the value reported under Step
Size is less than 1.0 per unit. The nomenclature used to identify the variables (i.e., Efd), is
defined in Table 14-8 Jacobian Column Label Descriptions. A u placed after the description
indicates that the corresponding variable is constrained by an upper limit.
Step Size: The size of the correction step taken towards the optimal solution point. A 1.0 per
unit step implies that 100% of the correction was added to the power system variables.
NE: The number of negative eigenvalues in the factorization of the KT matrix. It reflects the
number of power system variables that make the KT problem indefinite. The problem
becomes indefinite if the quadratic representation of the problem has negative curvature.
This value may change at each solution iteration, generally increasing for subproblems that
result in a small step size. It may grow quite large, but for problems making good progress,
it should shrink again. If the execution terminates as optimal, but with a nonzero NE value,
then the power balance will be satisfied but the solution may not be a true optimal point.
(You can try increasing the final value of the barrier parameter by an order of 10.)
Unlabeled column: An integer value may appear in an unlabeled column immediately to the
right of the NE column. This number reflects the number of variables for which limits have
been relaxed. This is likely to occur when the discrete treatment of transformer tap ratios
or switched shunts is enabled.
During solution, transformer settings and switched shunts are treated as continuous vari-
ables, provided that they have not been fixed (Fix Transformer Tap Ratios, Fix Transformer
Phase Shift Angles, or Fix Switched Shunts) at their current settings. If the option to Round
Transformer Tap Ratios or Round Switched Shunt Vars is specified, then the resulting
values as obtain after an initial optimal solution is found, are rounded to the nearest discrete
tap or var setting. When this occurs, the program may find that some limits need to be
relaxed. The total number of relaxed limits is reflected in the value displayed in this column.
Solution Termination Message

A termination message will be displayed immediately following the solution progress log. An item-
ized list of the objective functions and their values follows, along with a solution timing report. The
following is one such example:
14-52
Optimal Solution Found.

Minimum Fuel cost objective: 29115.463109
Minimum series var objective: 23.121500
Elapsed time: 0 minutes, 0.2 seconds.

CPU time: 0 minutes, 0.1 seconds.
In the above example, the optimal power flow problem minimized fuel cost and adjustable branch
reactances (series compensation).
Labeling Nomenclature
The following two tables define the labeling conventions used in a number of the solution results
tables.
Jacobian Columns: Within the OPF output reports, the power system variables placed in the
columns of the Jacobian matrix are described with an abbreviated label. The labeling
nomenclature consists of a character string followed by an integer number. The character
labels are defined in Table 14-8 Jacobian Column Label Descriptions. The integer number
appended to the label corresponds to one of two values:
- If the number is prefixed with a +, the number that follows is a sequence number.
For example, the label Intf +3 refers to the third interface defined in the working
case.
- If a number is specified without a + prefix, the value simply refers to the identifica-
tion number describing the power system element. For example, the label Angl 101
refers to the angle at bus 101.
Jacobian Rows: The labeling nomenclature used within the OPF reports to describe the
constraints that make up the rows of the Jacobian matrix consists of a character label
followed by a number. The labels are described in Table 14-9 Jacobian Row Label Descrip-
tions. The numbers refer to one of two values:
- If the number is prefixed with a +, it refers to a sequence number. For example, the
label RTEQ +1 refers to the first generation period reserve constraint defined within
the working case. Sequence numbers are used when the constraint cannot be ref-
erenced back to a power flow bus.
- If the number is not prefixed with a +, the value given is the power flow bus number
for which the constraint equation is defined at. For example, Peqn 101 refers to the
active power constraint equation at bus number 101 in the working case.
14-53
Table 14-8. Jacobian Column Label Descriptions
Label Variable Description

Angl Voltage angle at an explicit network bus
Del Voltage angle at an implicit reactive capability bus
Volt Voltage magnitude at an explicit network bus
Efd Voltage magnitude at an implicit reactive capability bus
Trns Transformer control element: tap ratio or phase angle
Pgen Active power slack variable associated with a fuel cost segment
Pslk Active power slack variable associated with a system slack bus
Qgen Reactive power generator
Cap Capacitive added var component
Shnt Switched shunt
Shed Bus load adjustment component
Flow Constrained branch flow slack variable
Intf Interface flow slack variable
Comp Adjustable branch reactance variable
RC-I Generator stator current slack variable, to limit reactive capability model Imax
RC-Y Generator stator current slack variable, to limit reactive capability model mEfd+b
RTMW Generation period reserve participating unit slack variable
RT Generation period reserve slack variable
LnCs Linear dependency constraint equation variable
AI Regulated area interchange slack variable
Clmp Local generator voltage control clamp equation slack variable
Auxiliary variable segments (e.g., employed for linear type penalties). The number which
Segm
follows the Segm label indicates the column number of the variable.
Table 14-9. Jacobian Row Label Descriptions
Label Constraint Equation Description

Peqn Active power balance at an explicit network node
RC-P Active power balance at an implicit reactive capability node
Qeqn Reactive power balance at an explicit network node
RC-Q Reactive power balance at an implicit reactive capability node
F-eq Branch flow constraint
I-eq Interface flow constraint (or report)
RC-I Generator stator current, to limit reactive capability model Imax
14-54
Table 14-9. Jacobian Row Label Descriptions (Cont.)
Label Constraint Equation Description

RC-Y Generator stator current, to limit reactive capability model mEfd+b
RTMW Generation period reserve participating unit
RTEQ Generation period reserve
LNCS Customized linear dependency
AI Regulated area interchange
CGEN Local generator voltage control clamp
14.11.2 OPF Solution Results Report

An OPF Solution Results Report is automatically produced at the completion of the optimal power
flow solution. It is sent to the report device by default but may be redirected to an alternate device
or file through the I/O Control > Direct report output (OPEN)... menu option.
The OPF Solution Report consists of tables containing summaries of the problem statement control
and constraint variable settings, and their sensitivities to the objective. The report itself is printed in
a format suitable for printing and is necessary for performing post processing and analysis.
It is not possible to send the OPF Report to the Progress View! To avoid potential confusion
that would arise from having output from both the OPF Solution Report and the Solution Iter-
ation Log simultaneously sent to the Progress View and getting mixed together, the OPF Solution
Report information is prevented from being sent to the Progress View. If the device specified by the
I/O Control > Direct report output (OPEN)... menu option is set to the Current progress device, then
the report will automatically be redirected to the report device. This action does not cause the output
of any other activity to be redirected.
14.11.3 OPF Optimization Log

The OPF Optimization Log File is optional and, by default, will not be produced. To produce an Opti-
mization Log File, the Produce optimization log file option must be enabled prior to initiating the
solution. By default the resulting file will be called DETAIL.DAT. An alternate name may be specified
by entering a name directly in the Optimization log input field or selecting from a list of existing files
by clicking [ … ] to the right of the input field. Existing files will be overwritten! Refer to Produce
an Optimization Log File for further information on the use of this dialog.
In addition to the information printed within the standard OPF Progress Summary Report discussed
in Section 14.11.1 OPF Progress Summary Report, the Optimization Log File also includes infor-
mation on problem size statistics and optionally, a detailed listing of the power system variables and
Lagrange multipliers. The following section describe items that are unique to the Optimization Log
File.
14-55
Immediately following the problem size statistics and a report of the initial conditions, a table of KKT
Matrix Factorize statistics is printed. An example of this table is shown below.
KKT Matrix Factorize statistics...

----------------------------------
Symbolic Factors. Opts: 203 Elements: 203 Compres: 0 % Fill-in: 28
Symbolic Factors. Opts: 6441 Elements: 1373 Compres: 1 % Fill-in: 70
Unfactored. Columns: 169 Elements: 806 Density: 2.82
Numeric Factors. 2x2s: 8 Elements: 1413 Compres: 1 % Fill-in: 75
Neg. Eigenvalues: 67 Max front: 17 N-Steps : 82
Immediately following this table is the solution iteration log and termination message, the same
ones as displayed in the Progress View during the solution process. Refer to Solution Iteration Log
and Solution Termination Message for details.
Infeasible Variable Report

Details of any infeasible variables discovered in the problem statement will be printed in a table.
This will take place independent of whether the Print a detailed listing option is enabled or not.
Post Solution Results

If the option to Print a detailed listing is enabled (refer to Produce an Optimization Log File), then a
complete table detailing the final values for all power system variables is produced. The detailed
listing is the only way to obtain this information as it is not displayed in the Progress View during the
solution process.
The table takes the following form:
Column Name F S Value Lower Upper Cost

-------- ------------------ ---- --------- ------------ ------------ ----------
1 Angl 101 3 0.19434 -6.2832 6.2832
2 Angl 102 3 0.19434 -6.2832 6.2832
3 Angl 151 3 0.10051 -6.2832 6.2832
. . .
29 Volt 101 U 1 1.04992 0.9500 1.0500 -1206.06170
30 Volt 102 U 1 1.04992 0.9500 1.0500 -1208.82517
The information presented under each column heading is defined as follows:
Column: The sequence number of the column entry within the Jacobian matrix where the
associated variable is present.
Name: The identifier of the variable associated with the column entry of the Jacobian matrix.
The description of each Name entry is defined in Table 14-8 Jacobian Column Label
Descriptions.
14-56
F: The final status of the variable. This flag may take on one of the following values:
U: The variable is limited by an upper bound;
L: The variable is limited by a lower bound;
F: The variable is fixed at a given value;
-: The lower bound of the variable has been relaxed;
+: The upper bound of the variable has been relaxed;
The variable is infeasible. Variables that are infeasible are always

I: displayed in the Optimization Log, independent of whether the full
detailed listing is produced, or not.
S: The final state of the variable. The state is described by an integer according to the
following table:
Table 14-10. Variable State Values
Variable State, S Variable (x) Condition

0 x = xmin
1 x = xmax
2 xmin x  xmax
3 -  x  +
4 x = x0 (x0  initial condition)
5 xmin  x  +
6 -  x  xmax
7 -  x  +
Value: The final value of the variable. The units associated with the values correspond to the
following:
- Voltage magnitudes are in per unit;
- Voltage angles are in radians;
- Branch flow constraints (MVA and Ampere) are in terms of their magnitudes
squared;
- Transformer tap ratios are inverted.
Lower: The value of the variable’s lower bound. The units of the values are as stated within
the definition for Value.
Upper: The value of the variable’s upper bound. The units of the values are as stated within
the definition for Value.
Cost: The sensitivity of the variable. Whenever a variable reaches an upper or lower bound,
or is fixed, there will be a nonzero entry in this column. The sensitivity values indicate how
much impact it can have on the objective with a small move beyond its boundary limits. All
14-57
Examining OPF Data and Results Program Operation Manual
values are in terms of cost/variable. The number may not be identical to those produced
in the output report due to unit conversions.
Lagrange Multipliers
When the Print a detailed listing option is selected, a table of Lagrange multiplier values is
produced.
The Lagrange multiplier table takes the following form:
Row Name Lagrange Mult.

-------- ------------------ ---------------
1 Peqn 101 -2456.88
2 Peqn 102 -2456.89
3 Peqn 151 -2469.08
4 Peqn 152 -2542.66
5 Peqn 153 -2545.58
. . .
where:
Row: The sequence number of the row entry in the Jacobian matrix for the associated
constraint equation.
Name: The identifier of the constraint equation associated with the row of the Jacobian matrix.
The description of each Name heading is defined in Table 14-9 Jacobian Row Label
Descriptions.
Lagrange Mult: The final value of  as used in the equation described in Section 14.7.1 The
Nonlinear Problem. These values indicate the sensitivity of the objective function to a
change in the constraint.
14.12 Examining OPF Data and Results

Optimal power flow data values may be examined through several different functions, including:
Power Flow > List Data... , OPF button
Produces a tabular report of any or all of the OPF constraint and control data within the
working case.
The OPF Solution Report
A tabular report automatically generated subsequent to the OPF solution process. The
report contains a solution summary and sensitivity tables pertaining to the power sys-
tem variables of the OPF problem statement.
OPF > Data... and OPF > Data tables...
Presents the power flow and optimal power flow data in spreadsheets and data tables
suitable for viewing and editing.
Some of these functions provide additional capabilities for editing the data values displayed.
Each subsection of this chapter covers the above program functions in some detail.
14-58
Program Operation Manual Listing Control and Constraint Data
14.13 Listing Control and Constraint Data

Activity LSTO
OPF data output lists control and constraint data, providing options for a number of customized
reports in addition to the full listing.
Table 14-11. Optimal Power Flow (OPF) Data Output Options
Report Type Description

Produces a tabular report of the total number of records defined within each OPF
data category, along with the maximum number of allowable entries for each
category.
Counts of Bus loads and Generator dispatch units correspond directly to the load
and generator power flow data models and may be obtained through activity SIZE.
Immediately following the tabular listing of data item counts will be a list of the OPF
solution objectives enabled in the working case. If no objectives have been explic-
Case Summary itly specified, the word None will appear after the Desired objectives heading.
All Data A complete report consisting of all the OPF data categories is produced.
All active power dispatch tables within the working case are listed in the active
power dispatch table report, independent of the subsystem selected for output. The
Active Power Dis- data values displayed in the report are defined in Active Power Dispatch Data
patch Tables Record.
All adjustable bus load records referencing an adjustable bus load table number
greater than zero are listed. The values listed under the Tbl heading should corre-
Adjustable Bus spond to an existing adjustable bus load table record. Data values listed in each
Loads adjustable bus load record are defined in Bus Load Data Record.
All adjustable bus load tables within the working case are listed in the report, inde-
pendent of whether a subsystem has been specified. The values listed under the
Load ratio headings, as well as the Cost type and the Cost table headings show
default values. They are displayed for completeness but are not utilized by the
current release of the program.
Adjustable Bus Load The data values displayed in the table correspond to the definitions provided in
Tables Adjustable Bus Load Table Data Record.
All adjustable branch reactance data records within the selected subsystem are
listed in the output report. Branches are listed in ascending bus order (numeric or
alphabetic) with the lower ordered bus listed as the from bus.
The data values listed within each adjustable branch reactance record correspond
Adjustable Branch directly to the definitions provided in Adjustable Branch Reactance Data
Reactance Data Record.
All branch flow constraint records within the defined subsystem are listed in the
output report.
Branches are listed in ascending from bus order (numeric or alphabetic) and then
ascending to bus order, with the lower ordered bus listed as the from bus. Parallel
circuits between any two buses are tabulated in ascending circuit identifier order
and identical circuits are listed in ascending branch flow identifier order.
Branch Flow Con- The data values listed within each branch flow constraint record correspond directly
straint Data to the definitions provided in Branch Flow Constraint Data Record.
14-59
Listing Control and Constraint Data Program Operation Manual
Table 14-11. Optimal Power Flow (OPF) Data Output Options (Cont.)

All bus voltage constraint records for buses within the defined subsystem are
displayed in the output report. Default data is displayed for those buses voltage
constraint records that have not been explicitly modified. Data values displayed
within the bus attribute records are defined in Bus Voltage Attribute Data
Bus Data Record.
All adjustable bus shunt records within the defined subsystem are displayed in the
output report. Multiple bus shunts at the same bus are differentiated by unique
shunt identifiers.
The data values displayed in the table correspond directly to definitions provided in
Adjustable Bus Shunt Data Record. Values listed under Cost type and Cost
table are displayed for completeness but are not utilized by the current release of
Bus Shunt the program.
All generator dispatch records referencing an active power dispatch table number
greater than zero and residing within the selected subsystem for printing are listed
Generator Dispatch in the generator dispatch report. The data values for each generator dispatch
Data record are defined in Generator Dispatch Data Record.
All generation reactive capability data records of machines residing within the
defined subsystem are listed in the output report. Machines are listed in ascending
bus order (numeric or alphabetic) and multiple machines at the same bus are listed
Generation Reactive The data values listed under each heading of the record correspond directly to the
Capability Data definitions provided in Generation Reactive Capability Data Record.
All generation reserve data records for machines residing in the defined subsystem
are listed in the output report. Machines are listed in ascending bus order (numeric
or alphabetic) and multiple machines at the same plant bus are listed in ascending
machine identifier order.
Generation Reserve The values listed under Ramp rate and Capability correspond directly to the defini-
Data tions provided in Generation Reserve Data Record.
All interface flow constraint records contained in the working case are listed in the
report. Interfaces are listed in ascending order based upon the interface flow
identifier.
Each interface flow record may contain one or more participating branches that
define the interface. The participating branches are listed to the far right of the
report on separate lines, in ascending from bus order (numeric or alphabetic) and
then ascending to bus order. Parallel circuits between any pair of buses are tabu-
lated in ascending circuit identifier order.
Interface Flow Con- The data values listed within each interface flow constraint data record are defined
straint Data in Interface Flow Data Input Values.
14-60
Program Operation Manual Listing Control and Constraint Data
Table 14-11. Optimal Power Flow (OPF) Data Output Options (Cont.)

All linear constraint dependency records having one or more participating variable
records are listed in ascending linear constraint identifier order within the report.
Participating variable records are displayed to the far right of the output report with
each participating record listed on a separate line.
Each participating variable record is listed in the order in which it is stored in the
working case. The Type code value indicates the type of variable being listed. The
entries listed under the Participating entry description label identify the variable
record being included in the linear constraint dependency equation. These may
include identifiers such as table numbers, branches (from bus, to bus and circuit
identifier) and machines (bus and generator identifier).
The data values listed within each linear constraint dependency data record,
Linear Constraint including a description of the variable type codes and their corresponding identi-
Dependency Data fiers, are defined in Linear Constraint Dependency Data Record.
All period reserve records having one or more participating generator reserve units
defined are listed in ascending numerical order in the report. There can be at most
fifteen period reserve records listed. If the period reserve record contains more than
one participating generator reserve unit, then subsequent reserve units will be listed
on separate lines immediately following the main period reserve record, in
ascending order (numerical or alphabetical). The data values in each record corre-
spond directly to the generator reserve values defined in Period Reserve Data
Period Reserve Data Input Values.
All piece-wise linear cost tables within the working case are listed in ascending
numerical order in the output report. A main header line is displayed for each linear
cost table record, along with up to three coordinate pairs of data. If a cost table
contains more than three coordinate data points, further data is displayed on subse-
Piece-wise Linear quent lines, without the main header. The data values are defined in Piece-wise
Cost Table Data Linear Cost Table Data Record.
All piece-wise quadratic cost tables within the working case are listed in ascending
numerical order in the report. A main header line is displayed for each quadratic
cost table record, along with up to three coordinate pairs of data. If a cost table
Piece-wise Qua- contains more than three coordinate data points, further data are displayed on
dratic Cost Table subsequent lines, without the main header. The data values are defined in Piece-
Data wise Quadratic Cost Data Record.
All polynomial cost tables within the working case are listed in ascending numerical
Polynomial and order in the report. Each record is displayed on one line of output. The data values
Exponential Cost listed within each polynomial cost table record are defined in Polynomial and
Table Data Exponential Cost Curve Data Record.
®
PSS E GUI Users Guide, Section 19.5, Displaying OPF Data
Section 16.2, Listing Optimal Power Flow Data
14-61
Optimal Power Flow Solution Report Program Operation Manual
14.14 Optimal Power Flow Solution Report

The OPF Solution Report is automatically produced after an OPF solution. By default, output is sent
to the report device but may optionally be redirected to an alternate device through the use of
activity OPEN.
The following sections describe each portion of the OPF Solution Report, in the order in which they
appear in the report.
14.14.1 Solution Termination Summary

A qualitative summary of the power flow problem is output at the top of the report. This information
indicates the initial conditions of the optimal power flow problem statement, as shown below:
Note: There were 4 infeasible variables found.

The sum of the violations is 0.4437,
The largest violation is Efd 206 0.2377.
A complete description of the information presented in this summary can be found in the Solution
Termination Message.
Immediately following the above summary a statement is printed indicating whether an optimal solu-
tion was found or not. Along with this will be an itemized list of each resulting objective function
value.
Optimal Solution Found.

Minimum Fuel cost objective: 29208.031976
Minimum series var objective: 29.271418
If the message states something other than Optimal Solution Found, then the results
presented in the rest of the report will not represent a solved problem! Messages such as
Terminated after XX iterations--reached iteration limit" or "Blown up
after XX iterations" are analyzed in Maximum Iteration Limit Exceeded and
Problem Unable to Solve.
14.14.2 Interface Flows

Each interface flow constraint record in the working case is displayed in the Interface Flow report.
One table is produced for each interface flow constraint specified.
----- Interface Flow -----: AREA 5 TO AREA 1 Continued.
Minimum and Maximum: -160.000 -155.000, Sensitivity: -513.5541 Status: Constrained
From Bus Name kV Area Zone To Bus Name kV Area Zone MW Flow Mvar Flow Mva Flow
--------------------------------------- --------------------------------------- --------- ----------- ----------
3004 WEST 500.00 5 5 152m MID500 500.00 1 1 -79.770 64.503 102.586
3006 UPTOWN 230.00 5 5 153m MID230 230.00 1 1 -49.223 -27.433 56.351
3008 CATDOG 230.00 5 5 154m DOWNTN 230.00 1 1 -26.026 65.054 70.067
---------- ---------- ----------
Totals: -155.019 102.124 185.635
The top line of the report specifies the name of the interface flow constraint being reported.
Immediately following the Minimum and Maximum: field are two values reflecting the minimum and
maximum interface flow limits defined across the interface. Values are expressed in either MW or
Mvar, depending upon the flow condition defined in the data record.
The Sensitivity: field has a value immediately following it if all following conditions are met: a flow
limit has been reached, the OPF Solution Parameter option to Constrain Interface Flows is enabled,
14-62
Program Operation Manual Optimal Power Flow Solution Report
and the interface flow constraint being reported upon does not have a Limit type of Reporting. The
Sensitivity field is left blank if the interface flow constraint limit type is set to Reporting or the
Constrain interface flows option is not selected prior to the solution.
The sensitivity value is expressed in units of cost/per unit MW (on system MVA base) or
cost/per unit Mvar. For every per unit value in which the constrained limit can be relaxed, the cost
will proportionally be reduced by one cost unit.
The Status: field reflects a value of Constrained if the OPF Solution Parameter option to Constrain
Interface Flows is enabled prior to the optimal power flow solution; otherwise the word Uncon-
strained is displayed.
Within each Interface Flow report is a list of participating branches, identified by From Bus and To
Bus number, Name, base kV, Area and Zone.
The MW flow, Mvar flow and MVA flow is reported for each participating branch of the interface. The
total MW, Mvar and MVA flows across all branches in the interface are summed together and given
at the bottom of the report.
14.14.3 Bounded, Infeasible and Opened Voltage Magnitudes

The Bounded, Infeasible and Opened Voltage Magnitudes report displays buses within the selected
subsystem where voltage magnitudes have either violated or reached their voltage limits, or where
limits may have been temporarily adjusted.
Bounded, Infeasible and Opened Voltage Magnitudes:
--------------------------------------------------
Bus # Name kV V-old V-change V-new Vmin Vmax Sensitivity Violation

------- ------------ ------ -------- ------------ --------- ---------- ---------- ----------- ----------
101 NUC-A 21.600 1.0200 -.2175E-03 1.0198 0.9500 1.0200(o) -458.4
102 NUC-B 21.600 1.0200 0.2955E-01 1.0496 0.9500 1.0500 -222.8
154 DOWNTN 230.00 0.9389 0.4382E-02 0.9433 0.9389(o) 1.0500
201 HYDRO 500.00 1.0400 0.9920E-02 1.0499 0.9500 1.0500 -1246.
3018 CATDOG_G 13.800 1.0218 0.2818E-01 1.0499 0.9500 1.0500 -1980.
Violations may occur in situations where discrete controls (transformer taps or switched shunts)
have been employed, soft limits (linear or quadratic) have been assigned to the OPF bus voltage
constraint records, or the OPF solution was not able to attain a feasible state.
Bounded or infeasible buses are identified by bus number (Bus #), Name and base kV.
Under the V-old, V-change and V-new headings are the initial bus voltage, the change in voltage
and the final bus voltage, all in per unit.
The Vmin and Vmax columns list the imposed lower and upper voltage bounds at the bus. These
limits reflect either the Normal or Emergency voltage limits according to the option selected prior to
the OPF solution (Impose Emergency Bus Voltage Limits). All voltage values are presented in per
unit.
A value is displayed in the Sensitivity column if the corresponding bus voltage magnitude has
reached or exceeded a voltage limit, and where sensitivity value is larger than the greater of 0.1 or
10% of the largest voltage magnitude sensitivity reported. The sensitivity value is specified in
cost/per unit voltage.
14-63
Values shown in the Violation column indicate the amount by which the final voltage magnitude
value at the bus exceeds the violated lower or upper voltage limit. This may occur if the Limit Type
of the bus within the OPF Bus Voltage constraint record was set to Reporting.
14.14.4 Bounded and Infeasible Reactive Generation

The Bounded and Infeasible Reactive Generation report displays generators within the selected
subsystem where reactive generation values have reached or violated the upper or lower bound.
Bounded and Infeasible Reactive Generation:

-------------------------------------------
Bus # Name kV ID Variable Description Sensitivity Violation

-------- ------------ ------ -- ------------------------------ ---------- ----------
206 URBGEN 18.000 1 Efd (PU) = 2.2795 -762.
3018 CATDOG_G 13.800 1 Qgen (Mvar) = 109.66 29.7
3018 CATDOG_G 13.800 1 Efd (PU) = 2.4677 741. 0.188
Reactive generation limits (Qmax and Qmin) are introduced through the main power flow generator
model. Additional limits on armature reaction and stator current can be applied using the OPF
generator reactive capability model.
The bus number (Bus #), Name, base kV and machine identifier (ID) describe the reported gener-
ator unit.
The Variable Description column displays the reactive generation value being reported. The labels
may be one of the following:
• Qgen (Mvar) - The reactive power injection in Mvars.
• Efd (pu) - The armature reaction in per unit.
• Is (pu on MVARC) - The stator current value in per unit on generator MVA rating.
The Sensitivity column displays a sensitivity value for generators where reactive generation value
has reached or exceeded a limit, and where sensitivity value is larger than the greater of 0.1 or 10%
of the largest reactive generation related variable sensitivity. Values are shown in cost/per unit
based upon the system MVA.
The Violation column displays the amount by which the reported value has exceeded its limit. Viola-
tions may result in situations where soft limits are applied or reactive capability models have been
employed. In the above report, two violations have occurred at bus 3018, machine identifier 1. The
first violation indicates that the reactive power injection has exceeded the specified limit by 29.7
Mvars. The second violation indicates that the armature reaction limit has been exceeded by 0.188
per unit.
14.14.5 Bounded or Infeasible Line Flows

The Line Flows that are Infeasible or at a Bound report lists branches within the specified
subsystem where flows have reached or violated defined flow limits.
Line Flows that are Infeasible or at a Bound:
---------------------------------------------
From Bus Name kV To Bus Name kV Ckt FlowID Flow Minimum Maximum Violation Sensitivity
--------------------------------------------------------------------------------------------------------------------------
153 MID230 230.00 154 DOWNTN 230.00 1 1 199.905 MVA 0.000 200.000 0.000 -104.858
14-64
The From Bus, To Bus, Ckt Id, base kV and Flow Id identify the reported branch.
The Flow, Minimum and Maximum columns reflect the final flow value, the type and units of the
reported flow value and the imposed lower and upper flow limits. Flow limit values reflect either
Normal or Emergency flow limits according to the option selected for the OPF solution (Impose
Emergency Branch Flow Limits). Physical units are used for the MW, Mvar and MVA flow values
and are indicated by the label next to the Flow value. Current flow values (I) are presented in per
unit on the system MVA base.
The Violation column displays the amount by which the flow value has exceeded its limit.
The Sensitivity column displays the sensitivity value for all flow values that are at a limit. Sensitivities
are reported in the following units for the flow type indicated.
• MW, in cost/per unit MW (on system MVA base)

• Mvar, in cost/per unit Mvar (on system MVA base)
• MVA, in cost/per unit MVA (on system MVA base)
• Current, in cost/per unit amperes (on system MVA base)
14.14.6
The Summary Table of Linear Dependency Constraints reports on all linear dependency constraints
that have been defined, along with each of their corresponding variables.
The first line of the linear dependency constraint record identifies the linear constraint equation
number and name. The final calculated constraint slack value and the defined maximum and
minimum constraint slack values are also displayed.
The remainder of the multiple line record lists each of the participating variables within the linear
dependency constraint equation. Only those variables that are active and in-service at the time of
the solution are reported. The Adjustable Bus MVar and Load Multiplier variables will only be active
if the corresponding objective functions to Minimize adjustable bus shunts and Minimize adjustable
bus loads, respectively, are enabled.
Each of the participating variables display the Coeff data value followed by the calculated value of
the individual variable and the description of the variable. At the end of the each participating vari-
able record is the element corresponding to the description.
14.14.7 Generator Fuel Cost Summary

The Generator Fuel Cost Summary is displayed if the Minimize Fuel Cost objective had been spec-
ified prior to solution in association with defined generator dispatch records and corresponding cost
curves.
Summary Table of Linear Dependency Constraints:
-----------------------------------------------
Constraint Slack
Equation # Name Value Max Min
--------------------- -------- -------- --------
2 NEW ONE 6.00 6.00 -2.00
Participating Variables
Coeff Value Description Element
------ ---------- -------------------------- ------------
14-65
1.0 0.88 Bus Volt Mag (PU) 152 [MID500 500.00]

2.0 19.08 Bus Volt Ang (Degrees) 101 [NUC-A 21.600]
3.0 773.92 Active Power Dispatch (MW) Dispatch table: 2
4.0 -99.96 Reactive Power Generation 102 [NUC-B 21.600] 1
5.0 1.05 Tap Changing Transformer 152 [MID500 500.00] to 153 [MID230 230.00] Ckt 1
6.0 222.78 Branch Flow Constraint (MVA ) 153 [MID230 230.00] to 154 [DOWNTN 230.00] Ckt 1
7.0 -159.78 Interface Flow Constraint (MW ) Flow ID 1: AREA 5 TO AREA 1
8.0 0.04 Adjustable Bus Shunt(MVar) 204 [SUB500 500.00] 1
9.0 0.08 Switched Shunt (MVar) 154 [DOWNTN 230.00]
10.0 0.60 Load Adjust Multiplier Load Table: 2
The id and Type fields identify the active power dispatch constraint table and fuel cost curve type
being employed for the generators identified under the Bus # and ID headings. The Type may be
either Lin, Quad or Poly to respectively indicate a linear, quadratic or polynomial cost curve.
The Fuel $ value indicates the cost of the fuel dispatched, as calculated from the corresponding cost
curve table.
The MW Output value reflects the total active power output from all units participating in the defined
constraint. This includes all the units listed under the Bus # and ID headings for the active power
dispatch constraint Id.
The MW Minimum and MW Maximum columns indicate the minimum and maximum active power
limits defined for the active power dispatch constraint.
Totals for the Fuel and MW value columns are provided at the bottom of the table.
The Bus #, Name, kV, ID, Pgen and Pfrac columns provide information on each generator partici-
pating in the active power dispatch constraint defined. If only one generator participates in a given
active power dispatch constraint, as is shown in the summary report above, then the Pgen value is
the same as the MW Output value, and Pfrac should be 1.0.
14-66
14.14.8 Generation Reserve

A Generation Reserve summary report is displayed for each generator period reserve constraint in
the working case.
Generation Reserve, 200.00 MW in 5.000 minutes.
Bus # Name kV ID MW Reserve MW Maximum

------ -------------------
-- ------------ ------------
206 URBGEN 18.000
1 50.000 50.000
211 HYDRO_G 20.000
1 150.019 500.000
============ ============
Period MW reserve totals: 200.019 550.000, Sensitivity = 0.161E+04
The header line of each Generation Reserve report indicates the active power reserve, in MW, and
the amount of time, in minutes, by which the reserve constraint must be satisfied.
Within each Generation Reserve report is a list of contributing generator reserve units, identified by
the bus number (Bus #), Name, base kV and machine identifier (ID).
The MW Reserve and MW Maximum columns reflects the final reserve and maximum reserve
capabilities, both in units of MW. The final unit reserves and the maximum values for all participating
reserve units are summed together and given at the bottom of each report.
A Sensitivity value is calculated and displayed to the right of the reserve totals if the final reserve
value has reached the reserve limit specified. The sensitivity value reflects the impact that a one
per unit MW change has on the objective (cost/per unit MW, on system MVA base).
14.14.9 Regulated Voltage Buses

A summary record is produced for every voltage regulated bus located within the selected
subsystem. By default, all regulated buses in all areas are printed.
Summary Table for Regulated Voltage Buses:
------------------------------------------
Bus # Name kV Area MW Pmin Pmax Pchange Voltage Vmin V-Sens

Zone Mvar Qmin Qmax Qchange Lambda Vchange Vmax Q-Sens
--------------------------------------------------------------------------------------------------------------
101 NUC-A 21.600 1 750.00 810.00 -2456.884 1.0499 U 0.9500 -1206.0617
77 154.74 -100.00 600.00 73.541 -0.027 0.0299 1.0500 -0.0270
102 NUC-B 21.600 1 750.00 810.00 -2456.887 1.0499 U 0.9500 -1208.8252

77 154.74 -100.00 600.00 73.543 0.017 0.0299 1.0500 0.0168
206 URBGEN 18.000 2 836.40 900.00 36.401-2609.142 1.0136 0.9500

2 428.08 0.00 600.00 -171.919 -102.021 -0.0101 1.0500 -102.0211
The report for each regulated bus includes two lines of output.
The bus number (Bus #), Name and base kV identify the voltage regulated bus. The Area and Zone
numbers of the bus are shown in the upper and lower lines under the Area and Zone heading.
Under the MW and Mvar heading is the final value of the active power, in MW, and the reactive
power, in Mvar. They are shown in the upper and lower lines of the record, respectively.
14-67
An additional character may appear to the right of the reactive power (Mvar) value:
• L indicates that the reactive power is limited by a lower bound (Qmin).

• U indicates that the reactive power is limited by an upper bound (Qmax).
• F indicates that the reactive power is fixed at a particular value.
• + indicates that the reactive power has violated the upper bound (Qmax).
• - indicates that the reactive power has violated the lower bound (Qmin).
Under the Pmin and Qmin heading is the minimum active power limit, in MW, and the minimum
reactive power limit, in Mvar. The values are obtained directly from the power flow generator data
model. A blank field indicates that the magnitude of the defined limit is significantly high.
The Pmin value shown may not be the actual active power limit employed by the OPF. If the
associated bus has a generator with a corresponding OPF generator fuel cost model, then the
Pmin and Pmax limits defined by the fuel cost model will be employed. These limits are shown in
the Generator Fuel Cost Summary (Section 14.14.7 Generator Fuel Cost Summary).
The Pmax and Qmax column displays the maximum active power limit, in MW, and the maximum
reactive power limit, in Mvar.
Under the Pchange and Qchange heading, the value shown in the upper line is the difference
between the final active power value and the initial active power value, in MW. The value shown in
the lower line is the difference between the final reactive power and the initial reactive power value,
in Mvar.
The Lambda column displays the Lagrange multipliers for the active and reactive power injections
at the bus, shown in the upper and lower lines respectively.
The Lambda value for the active power injection is the partial derivative of the objective function
with respect to the active power injection at the regulated bus. It indicates the impact that a one per
unit adjustment in the active power has on the objective function (cost/ per unit MW on system
MVA base). It is most useful for determining the incremental effects of load or generation changes
on the losses or production costs, depending upon the stated objective.
The Lambda value for the reactive power injection is the partial derivative of the objective function
with respect to the reactive power injection at the regulated bus and indicates the impact that a one
per unit adjustment in the reactive power has on the objective function (cost/ per unit Mvar on
system MVA base).
The Voltage and Vchange column displays the final bus voltage magnitude, in per unit, and the
difference between the final voltage value and the initial bus voltage value, also in per unit. Values
are shown in the upper and lower line respectively.
If the final bus voltage magnitude (Voltage) is limited by either an upper or lower bound, or is fixed,
then one of the following characters will appear after the voltage value:
• L indicates that the voltage value is limited by a lower bound (Vmin).

• U indicates that the voltage value is limited by an upper bound (Vmax).
• F indicates that the voltage value is fixed at a particular value.
The Vmin and Vmax column displays the minimum and maximum bus voltage magnitude limits, in
per unit, shown in the upper and lower line respectively. They reflect either the Normal or Emer-
14-68
gency voltage limits defined in the OPF bus voltage attribute data record depending upon the option
selected prior to the OPF solution (Impose Emergency Bus Voltage Limits).
Under the V-Sens heading, a sensitivity value of the voltage to the objective function is displayed in
the upper line if the voltage is at a limit (as indicated by a U or L after the Voltage value), or is fixed
at the current value (as indicated by an F after the Voltage value). The voltage sensitivity value
reflects the impact that a one per unit adjustment in the voltage has on the comprehensive objective
function (cost/per unit voltage magnitude). This is the same value as shown in the Bounded and
Infeasible Voltage Magnitude report (see Section 14.14.3 Bounded, Infeasible and Opened Voltage
Magnitudes).
Under the Q-Sens heading, a sensitivity value of the reactive generation to the object is displayed
in the lower line if the reactive power of the bus is at a limit (as indicated by a U or L after the Mvar
value), or fixed (as indicated by an F after the Mvar value). The reactive sensitivity value reflects the
impact that a one per unit adjustment in the reactive power has on the objective (cost/ per unit
Mvar on system MVA base). This is the same information as shown in the Bounded and Infeasible
Reactive Generation report (see Section 14.14.4 Bounded and Infeasible Reactive Generation).
14.14.10 Tap Changing Transformers

The Summary Table for Tap Changing Transformers reports on all tap ratio varying transformers
within the selected subsystem that have a significant sensitivity value or a change in tap ratio.
Summary Table for Tap Changing Transformers:
--------------------------------------------
From Bus kV Area Zone Voltage Ratio Minimum MW Flow Sensitivity

To Bus kV Area Zone Voltage Change Maximum MV Flow Tap Volt
--------------------------------------------------------------------------------------------------------------
151 NUCPANT 500.00 1 1 1.03227 1.00000 F 0.90000 -748.404 -1133.62749

101 NUC-A 21.600 1 77 1.04992u 1.10000 -82.382 -1206.06170
151 NUCPANT 500.00 1 1 1.03227 1.00000 F 0.90000 -748.404 -1137.12650

102 NUC-B 21.600 1 77 1.04992u 1.10000 -82.384 -1208.82517
152 MID500 500.00 1 1 1.02750 1.01506 0.95000 578.878

153 MID230 230.00 1 1 0.99759 0.00506 ( 2 ) 1.05000 305.148
Each two line transformer record identifies the From Bus, To Bus, base kV, Area and Zone number
of the end buses of the transformer.
The Voltage value reflects the from bus and to bus voltages corresponding to each side of the tap.
A single character displayed to the right of either value indicates whether the voltage is limited by a
lower bound (L), upper bound (u), or has been fixed (f).
The Ratio value reflects the tap ratio, in per unit, and is shown on the upper line of the transformer
record. A single character displayed immediately to the right of this value indicates whether the tap
ratio is limited by a lower bound (L), upper bound (U), or is fixed (F).
A Change value may be displayed under the Ratio value if the final tap ratio, as provided in the top
number, has changed from the initial tap ratio.
To the right of the Change value, in parentheses ( ), is the number of discrete tap steps taken. A
zero per unit change will result in a 0 being printed. If the option to Round Transformer Tap Ratios
had been specified, then the change in tap ratio ought to be an exact multiple of the tap step. The
tap ratio will be annotated with a fixed flag (F) to indicate that tap settings were fixed at their nearest
step during the last phase of the solution process. Tap ratio changes may have occurred during the
first phase of the solution process however, prior to the discretization and display of the fixed flag!
14-69
The Minimum and Maximum tap ratio limits are displayed in the upper and lower line of the trans-
former record respectively. These values are obtained from the transformer information in the power
flow data model of the working case. The minimum and maximum tap ratios of a fixed transformer
are shown as 1.0.
The MW Flow and MV Flow column displays the final MW and Mvar flows on the branch as seen
at the from bus. The MW flow value is shown on the upper line and the Mvar flow value below that.
The Sensitivity Tap column displays a tap ratio sensitivity value if the tap ratio value is either fixed
or at a limit. The value is expressed in units of cost/ per unit tap ratio and is only displayed in the
upper line of the transformer record.
The Sensitivity Voltage column displays a voltage sensitivity value for the from bus and/or to bus if
the voltage magnitude of the corresponding bus is limited by either its upper or lower constraint. The
values are reported in units of cost/ per unit voltage magnitude and are the same values as
displayed in the Bounded and Infeasible Voltage Magnitude report (see Section 14.14.3 Bounded,
Infeasible and Opened Voltage Magnitudes).
Transformer tap records will not be reported if the tap ratio has not changed by more than
0.001 per unit, or if the objective sensitivity of the tap ratio is less than 1.0!
14.14.11 Phase Shifting Transformers

The Summary Table for Phase Shifting Transformers reports on all phase angle varying trans-
formers within the selected subsystem.
Summary Table for Phase Shifting Transformers:

----------------------------------------------
From Bus kV Area Zone Angle Minimum MW Flow Sensitivity

To Bus kV Area Zone Change Maximum MV Flow
--------------------------------------------------------------------------------------
202 EAST500 500.00 2 2 -3.40702 -30.00000 600.000
203 EAST230 230.00 2 2 -3.40702 30.00000 271.184
Each two line phase shifting transformer record identifies the From Bus, To Bus, base kV, Area and
Zone number of each end bus of the transformer.
The Angle value is shown in the upper line of the displayed transformer record and reflects the final
phase shift value, in degrees. A single character displayed immediately to the right of the value indi-
cates whether its limited by a lower bound (L), upper bound (U) or is fixed (F).
A Change value may be displayed under the Angle value if the final phase shift value, as provided
in the top number, has changed from the initial phase angle, in degrees. A Change value will not be
displayed if the difference between the initial and final phase angle is less than or equal to 0.01
degrees.
The Minimum and Maximum phase angle limits, in degrees, are displayed in the upper and lower
line of the phase shifting transformer record respectively. These values are obtained directly from
the transformer information in the power flow data model of the working case. Minimum and
maximum phase angle limit values will not be displayed if the phase shifting transformer is fixed or
if the phase angle is less than or equal to 0.01 degrees
14-70
A MW Flow and MV Flow column displays the final MW and Mvar flows on the transformer as seen
at the from bus.
A Sensitivity value is displayed in the upper line of the phase shifting transformer record if the phase
shifter is fixed or constrained by either its upper or lower limit. The value is expressed in units of
cost/ degrees.
14.14.12 Added Shunts

When the Minimize Adjustable Bus Shunts objective is enabled, all adjustable bus shunts adjusted
during the solution and within the specified subsystem for printing are included in the Summary
Table for Added Shunts.
Summary Table for Added Shunt (Mvar):
-------------------------------------
Bus # Name kV ID Area Zone Initial Final Change Minimum Maximum Cost ($/Mvar) Sensitivity
------- ------------------- -- ----- ----- --------- ---------- ---------- ---------- ---------- ------------- ------------
153 MID230 230.00 1 1 1 0.000 4.217 4.217 -40.000 68.00 1.000
154 DOWNTN 230.00 1 1 1 0.000 68.000 68.000 -40.000 68.00 1.000 -151.0977
------- -------
Total: 0.000 72.217
The bus number (Bus #), Name, base kV, ID, Area and Zone columns provide identification infor-
mation for each adjustable bus shunt control. Multiple adjustable bus shunts defined at a common
bus are listed on separate lines and are uniquely identified by the shunt ID.
The Initial, Final and Change values reflect the initial additional shunt installation (in Mvar), the final
additional shunt value (in Mvar) and the difference between the initial and final values, in Mvars.
The Final value is added to the B-Shunt value of the corresponding fixed shunt within the power
flow data. If no corresponding fixed shunt is found, then a new fixed shunt is added with the given
ID.
The Minimum and Maximum columns display the upper and lower Mvar limits of the adjustable bus
shunt devices.
The Cost value is the cost for each Mvar deployed. The values are obtained directly from the
working case.
A Sensitivity value is reported for each adjustable bus shunt record where the final Mvar value is at
a minimum or maximum Mvar limit. The value is expressed in units of cost/ per unit susceptance
(Mvar).
The Total number of initial Mvars and final Mvars is displayed at the end of the report.
Only adjustable bus shunt controls for which the final shunt value exceeds 0.1 Mvar or the
nominal shunt value has changed by more than 0.1 Mvar will be included in the solution report!
14.14.13 Switched Shunts

All switched shunt devices that have a significant sensitivity value and are located within the spec-
ified subsystem for printing are included in the Bounded Switched Shunt report.
Bounded Switched Shunts:

------------------------
Bus # Name kV Area Zone Final Mvar Minimum Maximum Sensitivity
--------------------------- ----- ----- ------------ ---------- ---------- ------------
154 DOWNTN 230.00 1 1 45.000 U -45.000 45.00 -100.00
14-71
The bus number (Bus #), Name, base kV, Area and Zone columns provide identification information
for each switched shunt.
The Final Mvar column lists the final resulting susceptive value, in Mvar.
The Minimum and Maximum columns display the susceptive limits, as obtained directly from the
power flow switched shunt data model. The values are expressed in units of Mvar at nominal
voltage.
A Sensitivity value is reported for those switched shunts where the final Mvar values are at a
minimum or maximum limit. The value is expressed in units of cost/ per unit susceptance (Mvar).
Only switched shunts where the sensitivity value is larger than the greater of 0.1 or 10% of the
largest switched shunt sensitivity are included in the report!
14.14.14 Load Adjustment

When the Minimize Adjustable Bus Loads objective is enabled, all adjustable bus loads adjusted
during the solution and within the specified subsystem for printing are included in the Summary
Table for MW Load Adjustment.
Summary Table for MW Load Adjustments:

--------------------------------------
Bus # Name kV ID Initial MW Load Mult. Effective MW Maximum MW Minimum MW Sensitivity

------- ------------------- -- ---------- ---------- ------------ ---------- ---------- -----------
154 DOWNTN 230.00 1 600.00 0.400 240.05 600.00 240.00 1.0823
154 DOWNTN 230.00 2 400.00 0.400 160.04 400.00 160.00 1.0823
205 SUB230 230.00 1 1200.00 1.328 1593.57 2400.00 600.00
The bus number (Bus #), Name, base kV level and load identifier (ID) describe the reported bus
load. The ID differentiates between multiple loads at the same bus.
The Initial MW value is the real power load prior to the load adjustment.
The Load Mult. value reflects the resulting multiplier of the original load applied at the conclusion of
the OPF solution.
The Effective MW value reflects the resultant real power load with the final load multiplier applied
to the initial load value.
The Maximum and Minimum active power load limits, in MW, indicate the valid range for MW load
adjustments during the OPF solution as calculated by applying the corresponding maximum and
minimum load multipliers to the current MW load.
A Sensitivity value is reported for those load adjustment controls for which the final load multiplier
is at a minimum or maximum limit. The value is expressed in units of cost/ per unit MW (on
system MVA base).
14-72
14.14.15 Series Compensation

When the Minimize Adjustable Branch Reactances objective is enabled, all adjustable branch reac-
tance records within the specified subsystem for printing are processed for inclusion in the
Summary Table for Series Compensation.
Summary Table for Series Compensation:

--------------------------------------
From Bus Name kV Area Zone Psi Psi Max Voltage MW Flow Sensitivity
To Bus Name kV Area Zone X (PU) Psi Min Voltage MV Flow Cost
-------------------------------------------------------------------------------------
201 HYDRO 500.00 2 2 0.305 1.000 1.043 794.387 -2067.50921
204 SUB500 500.00 2 2 0.00916 0.300 0.989 244.003 30.01278
Each adjustable branch reactance record is identified by the From bus, To Bus, base kV level, Area
and Zone of each end bus of the branch.
The Psi value is shown in the upper line of the displayed branch record and reflects the final value
of the reactance multiplier, .
The X (pu) value, displayed below the Psi value, is the resulting branch reactance value, in per unit.
The Psi Max and Psi Min column displays the maximum and minimum reactance multipliers as
defined in the adjustable branch reactance record.
The MW Flow and MV Flow column displays the final MW and Mvar flow on the branch at the from
bus.
A Sensitivity value is displayed in the upper line of the last column if the final reactance multiplier is
at a minimum or maximum limit. The sensitivity value is expressed in units of cost/ per unit .
A Cost value is reported in the lower line of the last column for situations in which is not equal to
1.0. The cost is in units of cost/per unit .
14.14.16 Regulated Area Interchange

When the option to Regulate Area Interchange is enabled during the OPF solution, a Summary
Table of Area Interchanges is printed for all area interchange constraints, independent of whether
the areas correspond to areas within a printed subsystem or not.
Summary Table of Area Interchange:

----------------------------------
Area # Name MW Value Minimum Maximum Sensitivity

-------- ------------ ---------- ---------- ---------- -----------
1 FLAPCO 284.341 210.000 290.000
2 LIGHTCO -139.979 -140.000 -60.000 492.
5 WORLD -144.362 -160.000 -140.000
The area number (Area #) and Name identify the reported area.
The MW Value indicates the final area interchange value, in MW.
The Minimum and Maximum values are the defined interchange limits, in MW.
A Sensitivity value is reported if the final interchange value is at a minimum or maximum limit. This
value is expressed in units of cost/ per unit MW (on system MVA base).
14-73
14.14.17 Linear Dependency Constraints

The Summary Table of Linear Dependency Constraints reports on all linear dependency constraints
that have been defined, along with each of their corresponding variables.
Summary Table of Linear Dependency Constraints:
-----------------------------------------------
Constraint Slack
Equation # Name Value Max Min
--------------------- -------- -------- --------
2 NEW ONE 6.00 6.00 -2.00
Participating Variables
Coeff Value Description Element
------ ---------- -------------------------- ------------
1.0 0.88 Bus Volt Mag (PU) 152 [MID500 500.00]
2.0 19.08 Bus Volt Ang (Degrees) 101 [NUC-A 21.600]
3.0 773.92 Active Power Dispatch (MW) Dispatch table: 2
4.0 -99.96 Reactive Power Generation 102 [NUC-B 21.600] 1
5.0 1.05 Tap Changing Transformer 152 [MID500 500.00] to 153 [MID230 230.00] Ckt 1
6.0 222.78 Branch Flow Constraint MVA ) 153 [MID230 230.00] to 154 [DOWNTN 230.00] Ckt 1
7.0 -159.78 Interface Flow Constraint MW ) Flow ID 1: AREA 5 TO AREA 1
8.0 0.04 Adjustable Bus Shunt(MVar) 204 [SUB500 500.00] 1
9.0 0.08 Switched Shunt (MVar) 154 [DOWNTN 230.00]
10.0 0.60 Load Adjust Multiplier Load Table: 2
The first line of the linear dependency constraint record identifies the linear constraint equation
number and name. The final calculated constraint slack value and the defined maximum and
minimum constraint slack values are also displayed.
The remainder of the multiple line record lists each of the participating variables within the linear
dependency constraint equation. Only those variables that are active and in-service at the time of
the solution are reported. The Adjustable Bus MVar and Load Multiplier variables will only be active
if the corresponding objective functions to Minimize adjustable bus shunts and Minimize adjustable
bus loads, respectively, are enabled.
Each of the participating variables display the Coeff data value followed by the calculated value of
the individual variable and the description of the variable. At the end of the each participating vari-
able record is the element corresponding to the description.
14-74
Chapter 15
Dynamic Simulation Activity
Descriptions
This chapter contains operational descriptions of the PSS®E dynamic simulation activities. Each
Chapter 15 - Dynamic Simulation Activity Descriptions
section of this chapter documents a single PSS®E activity. Interface references are provided, with
links to the PSS®E GUI Users Guide and the PSS®E Command Line Interface (CLI) Users Guide,
where appropriate.
15.1 Reading Dynamics Model Data

Activity DYRE
Run Activity DYRE - GUI

File>Open…
[Open]
Dynamics Model Raw Data File (*.dyr)
Run Line Mode Activity DYRE - CLI

ACTIVITY?
>>DYRE,ADD
ENTER DYNAMICS DATA SOURCE FILENAME :
>>

None
The dynamics data input activity DYRE reads simulation model data from a Dynamics Model Raw
Data File into the dynamics data arrays in PSS®E working memory.
15.1.1 Dynamics Model Raw Data File Contents

The input stream to activity DYRE consists of a Dynamics Model Raw Data File. This file contains
a group of logical records, each of which defines the location in the network (by bus, machine, load,
dc line, etc.) of a dynamic equipment model from the PSS®E model library, along with the constant
parameters of the model. The PSS®E Model Library contains data sheets for each of the equipment
models in the PSS®E model library.
PSS®E Dynamic models can be broadly classified into the following categories:
15-1
Dynamic Simulation Activity Descriptions PSS®E 34.2
Reading Dynamics Model Data Program Operation Manual
Device models. These are attached to specific equipments in PSS®E power flow (e.g., models of
generators, loads etc.). For any given equipment, there can be only one device model attached to it.
Protection models and models of type “other” attached to specific equipment in PSS®E power flow.
For this group, for any given equipment although there can be more than one model attached, the
restriction is that there can be only one instance of any model attached to that equipment. In other
words for any equipment there can not be more than one instance of the same model attached to it.
Miscellaneous model of type “other”. These are unattached models in the sense that these may or
may not be attached to any specific equipment in PSS®E power flow. For miscellaneous “other”
type, the same model can applied more than once. In other words there can be more than one
instance of the same model. The different models instances are identified by a unique model
instance (MINS)value assigned to each model. The MINS values are assigned by users while
reading the model DYRE record (when the model is being added interactively the MINS value can
be generated by PSS®E or can be input by the user). The rule in applying models of this category
is that no two miscellaneous “other” models can have the same MINS value. If there are two models
with the same MINS value in the same DYR file, then this condition is treated as a duplicate model
and the second model instance is ignored. However if a second model with the same MINS value
is read in via activity “DYR,ADD” (activity to add dynamics model) then the model being added
replaces the one that is already present in the case.
For model categories (a) and (b), each logical record is of the following general format:
BUSID ’model name’ data list /

where:
BUSID Is the bus identifier (number or extended bus name) of the bus at which this
equipment model is to be placed (from bus for a line relay model), a dc line or
FACTS device name (in single quotes), area, zone, or owner number, or zero.
'model name' Is the name by which the model is referenced. The model name is limited to
sixteen characters, and must be enclosed in single quotes.
data list Specifies the constant parameters associated with the model. Generally, these
parameters are specified in the order in which constants are listed on the data
sheets in the blocks labeled ICONs and CONs.
For model category (c), each logical record is of the following general format:
MINS ’model name’ data list /

where:
MINS Model instance value (a whole number greater than zero).
'model name' Is the name by which the model is referenced. The model name is limited to
sixteen characters, and must be enclosed in single quotes.
data list Specifies the constant parameters associated with the model. Generally, these
parameters are specified in the order in which constants are listed on the data
sheets in the blocks labeled ICONs and CONs.
15-2
PSS®E 34.2 Dynamic Simulation Activity Descriptions
Program Operation Manual Reading Dynamics Model Data
Data records for device models, protection models, and models of type “other” that are associated
with plant, wind machine, and induction machine are specified in data records of the form:
BUSID ’model name’ IM data list /

where IM specifies the machine identifier and the other data items are as described above. Data
records for device models, load relay (a.k.a protection) models, and models of type “other” that are
associated with loads are specified in data records of the form:
BUSID ’model name’ IL data list /

where IL specifies the load identifier or a wildcard (*) designating all loads for BUSID. BUSID may
be a bus, area, zone, or owner number.
Data records for relay models associated with branches and 2-winding transformers are specified
in data records of the form:
BUSID ’model name’ BUSID2 ID RS data list /
where:
BUSID2 Is the bus identifier (number or extended bus name) of the to bus.
ID Is the circuit identifier.
RS Is a relay slot, either 1 or 2. Two relays are allowed at each from bus location on a
branch.
Data records for device models and models of “other” type associated with branches and 2-winding
transformers are specified in data records of the form;
BUSID ’model name’ BUSID2 ID data list /
Where, BUSID, BUSID2, and ID are as defined above for line relay models.
Data records for device models, protection models, and models of “other” type associated with 3-
winding transformers are specified in data records of the form;
BUSID ’model name’ BUSID2 BUSID3 ID data list /
Where, BUSID, BUSID2, and ID are as defined above for line relay models, and BUSID3 is the bus
identifier (number or extended bus name) of the third bus.
Auxiliary-signal models can be associated with dc line models (two-terminal dc, multi-terminal dc,
VSC dc) and FACTS device models. Data records for auxiliary-signal models are specified in the
form:
BUSID 'model name' DVTYP SGNDX data list /
15-3
where:
DVTYP Indicates the device type with which the auxiliary-signal is associated, and could be
any of the following:
1 : for two-terminal dc line
2 : for multi-terminal dc line
3 : for VSC dc line
4 : for FACTS device
SGNDX Is the signal injection point number. This is any number 1 through maximum number
of auxiliary-signals that can be associated with the device type under consideration
(refer to Table 3-1 for the maximum number of auxiliary signal injection points, i.e.,
the maximum number of auxiliary-signals that can be attached to each device type).
Data records for device models, protection models, and “other” models associated with dc line (two-
terminal dc, multi-terminal dc, and VSC dc), FACTS models, and switched shunt models are spec-
ified in the form:
BUSID 'model name' data list /

In the case of dc lines and FACTS models, BUSID refers to dc line and FACTS device name spec-
ified in single quotes. In the case of switched shunt models, BUSID refers to bus identifier.
The “Miscellaneous Other” category can be used for those categories of models that are not asso-
ciated with any device or equipment in the power flow. Data records for such models are specified
in the form:
MINS 'model name' data list /

where, MINS is the model instance, and is used to distinguish one “Miscellaneous Other”
model from another “Miscellaneous other” model. The model instance can be any whole
number greater than zero. There cannot be more than one “Miscellaneous Other” model
with the same MINS value.
When specifying a bus, BUSID, BUSID2, and BUSID3 must specify a bus number when the
numbers input option is in effect (refer to Section 3.3.3 Program Run-Time Option Settings and
activity OPTN). Using the names input option specify either a bus number or the extended bus
name enclosed in single quotes. When BUSID, BUSID2 and BUSID3 specify a number, it must be
entered without the quotes.
The model name is limited to sixteen characters, and must always be enclosed in single quotes.
As with the majority of data input records in PSS®E, data is read by activity DYRE in free format
with data items separated by a comma or one or more blanks. Each logical record may occupy
several sequential lines in the data file and must be terminated with a slash. These logical records
may be in any order within the data file.
The following paragraphs discuss details specific to each model type.
Device, Protection, and Other type models associated with machines
Generator Models
Generator models are classified as device models. Each in-service machine in the working case
must have a generator device model data record specified for it. The list of generator device
15-4
models, generator protection models, and generator that activity DYRE recognizes is provided in
Chapter 1, Generator Model Data Sheets of the PSS®E Model Library.
Data records specifying the generator models should have, following the model name, the identifier
of the machine to which the model is being assigned, followed by the ICON data (if applicable) and
CON data in the same order as they appear in the respective model data sheets.
It is to be noted that reactances, H and D are specified on MBASE base as contained in the working
case (refer to Generator Data and Section 11.2.2 Generator Apparent Impedance). In the
GENROE, GENROU, GENSAE, GENSAL, GENDCO and FRECHG models, the value specified for
X'' must be identical to the imaginary part of ZSORCE as contained in the working case. For the
GENCLS and GENTRA models, the imaginary component of ZSORCE must be identical to the
transient reactance, X'. In the CIMTR1, CIMTR2, CIMTR3 and CIMTR4 models, a single cage
induction machine has T'' and X'' set to zero and X' must be identical to the imaginary part of
ZSORCE; a double cage machine has nonzero values for the subtransient data items and X'' must
be identical to the imaginary component of ZSORCE.
Current Compensating Models

Compensating models are classified as device models. Any machine may have a voltage regulator
current compensating model specified for it. These models allow the voltage regulator to sense the
voltage either at a remote bus or at a point separated from the machine terminals by a specified
impedance which must be entered on MBASE base.
Activity DYRE recognizes the compensating models that are listed in Chapter 2, Compensator
Model Data Sheets of the PSS®E Model Library.
Data records specifying the compensating models should have, following the model name, the iden-
tifier of the machine to which the model is being assigned, followed by the ICON data (if applicable)
and CON data in the same order as they appear in the respective model data sheets.
Stabilizer and Excitation Limiter Models

Stabilizer and Excitation Limiter models are classified as device models. Any machine for which an
appropriate generator/exciter model pair has been specified may have a power system stabilizer
model, a minimum excitation limiter model, and/or a maximum excitation limiter model specified for
it. These units are devices that inject supplementary signals into the voltage regulator units. Stabi-
lizer signals are usually derived from either generator speed or generator power in such a way as
to improve the damping of generator rotor angle swings. Minimum and maximum excitation limiters
are relatively slow-acting protective devices which limit field voltage, EFD. The stabilizer model
output, and the minimum and maximum excitation limiter model outputs are accessed as VOTHSG,
VUEL and VOEL inputs respectively by the excitation system model.
The stabilizer and the excitation limiter models that are recognized by activity DYRE are provided
in Chapter 3, Stabilizer Model Data Sheets; Chapter 4, Minimum Excitation Limiter Model Data
Sheets; and Chapter 5, Maximum Excitation Limiter Model Data Sheets of the PSS®E Model
Library.
Data records specifying the stabilizer and excitation limiter models should have, following the model
name, the identifier of the machine to which the model is being assigned, followed by the ICON data
(if applicable) and CON data in the same order as they appear in the respective model data sheets.
In stabilizer models that require a remote bus ICON to be specified, the remote bus ICON must be
specified as zero if a local signal is used.
15-5
Excitation System Models

Excitation system models are classified as device models. Any machine which is modeled by one
of the generator models GENROE, GENROU, GENSAE, GENSAL, GENDCO, GENTRA, CGEN1
or FRECHG may have an excitation system model specified for it.
Activity DYRE recognizes the exciter models that are listed in Chapter 6, Excitation System Model
Data Sheets of the PSS®E Model Library.
Data records specifying the excitation system models should have, following the model name, the
identifier of the machine to which the model is being assigned, followed by the ICON data (if appli-
cable) and CON data in the same order as they appear in the respective model data sheets.
Turbine Governor Models

Turbine governor models are classified as device models. Any machine which is modeled by one
of the generator models GENROE, GENROU, GENSAE, GENSAL, GENDCO, GENTRA, CIMTR1,
CIMTR2, CIMTR3, CIMTR4 or CGEN1 may have a turbine governor model specified for it.
The list of governor models that are recognized by activity DYRE is provided in Chapter 7, Turbine-
Governor Model Data Sheets of the PSS®E Model Library.
For those governor models for which the turbine rating cannot be specified, the turbine governor
data would have to be specified on the base of its generating unit (i.e., on MBASE base).
Data records specifying most of the turbine governor models should have, following the model
name, the identifier of the machine to which the model is being assigned, the ICON data (if appli-
cable), and CON data in the same order as they appear in the respective model data sheets.
For the cross compound models, BUSID and IM specify the high pressure unit. IM is fol-lowed by
the bus and machine identifiers of the low pressure unit. The remaining data items are the ICON
data (if applicable) and CON data in the same order as they appear in the respective model data
sheets.
For the IEEE Type 1 models, IEEEG1, TGOV5 and WSIEG1, BUSID and IM specify the machine
at which the model is to be called. If a cross compound is to be modeled, these specify the high
pressure unit, and IM is followed by the bus and machine identifiers of the low pressure unit; other-
wise two data items of zero must be specified following IM.
Turbine Load Controller Models

Turbine load controller models are classified as device models. Any machine which has a turbine
governor model may have a turbine load controller model specified for it. The function of these
models is to maintain turbine power at a set value by adjusting the turbine-governor reference.
The list of turbine load controller models that are recognized by activity DYRE is provided in
Chapter 8, Turbine Load Controller Model Data Sheets of the PSS®E Model Library.
For those governor models for which the turbine rating cannot be specified, the turbine load
controller data would have to be specified on the base of its generating unit (i.e., on MBASE base).
Data records specifying the turbine load controller models should have, following the model name,
the identifier of the machine to which the model is being assigned, the ICON data (if applicable),
15-6
Machine and Wind machine Protection Models

Any machine (including wind machines) may have a protection model specified for it. Activity DYRE
recognizes the machine protection models that are listed in the Machine protection Model chapter
of the PSS®E Model Library.
Data records specifying the machine protection models should have, following the model name, the
Load Characteristic Models

Load characteristic models are classified as device models. Any load in the working case may have
a load characteristic model data record specified for it.
The list of load characteristic models that are recognized by activity DYRE is provided in Chapter 9,
Load Characteristic Model Data Sheets of the PSS®E Model Library.
Data records specifying each of the above models should have the form:

where:
BUSID Bus number or name for type BL models.

Owner number for type OW models.
Zone number for type ZN models.
Area number for type AR models.
0 for type AL models.
IL Load identifier or  to specify the model for all loads at BUSID.
data list As specified on the model data sheets.
Load Relay (a.k.a, load protection) Models

Any load in the working case may have a load relay model data record specified for it.
The list of load relay models that are recognized by activity DYRE is provided in Chapter 10, Load
Relay Model Data Sheets of the PSS®E Model Library.

where:
BUSID Bus number or name for type BL models.

Owner number for type OW models.
Zone number for type ZN models.
Area number for type AR models.
0 for type AL models.
IL Load identifier or  to specify the model for all loads at BUSID.
15-7
Branch and 2-winding transformer device models

Any branch or a 2-winding transformer in the network may have a device model attached to it. The
device models for branches that are recognized by activity DYRE are provided in the Branch Device
Model chapter of the PSS®E Model Library, while the device models for 2-winding transformer that
are recognized by activity DYRE are provided in the Branch Device Model chapter of the PSS®E
Model Library.
BUSID ’model name’ BUSID2 ID data list /

where:
BUSID Is the branch from bus number or name; this is the end of the line at which the relay
model is placed.
BUSID2 Is the branch to bus number or name.
ID Is the branch circuit identifier.
The relay slot number (RS) must be either 1 or 2. Up to two models per branch per from bus, or four
models per branch, can be accommodated.
Branch Relay and 2-winding transformer protection Models

Any branch in the network may have up to two line relay models at each end. A relay models is
placed at the from bus end of the line, as specified on the model data record. The line relay models
that are recognized by activity DYRE are provided in Chapter 11, Line Relay Model Data Sheets of
the PSS®E Model Library.
BUSID ’model name’ BUSID2 ID RS data list /

where:
model is placed.
RS Is the relay slot number.
The relay slot number (RS) must be either 1 or 2. Up to two models per branch per from bus, or four
models per branch, can be accommodated.
15-8
3-winding transformer device models

Any 3-winding transformer in the network may have a device model attached to it. The device
models for branches that are recognized by activity DYRE are provided in the Model Library.
BUSID 'model name' BUSID2 BUSID3 data list /

where:
model is placed.
BUSID3 Is the 3-winding transformer third bus
Auxiliary-Signal Models
Activity DYRE recognizes the auxiliary-signal models that are provided in Chapter 12, Auxiliary-
Signal Model Data Sheets of the PSS®E Model Library:
With the exception of models RBKELT and SQBAUT, all other auxiliary-signal models can be asso-
ciated with dc line models (2-terminal dc, multi-terminal dc, VSC dc) and FACTS device models.
RBKELT and SQBAUT can be associated only with 2-terminal dc line models.
Data records for auxiliary-signal models are specified in the form:
BUSID 'model name' DVTYP SGNDX data list /

where:
DVTYP Indicates the device type with which the auxiliary-signal is associated, and could be
any of the following:
1 : for two-terminal dc line
2 : for multi-terminal dc line
3 : for VSC dc line
4 : for FACTS device
SGNDX Is the signal injection point number. This is any number 1 through maximum number
of auxiliary-signals that can be associated with the device type under consideration
(refer to Table 3-1 for the maximum number of auxiliary signal injection points, i.e.,
the maximum number of auxiliary-signals that can be attached to each device type).
Each of the above "tableized" auxiliary-signal models calculates the model output and stores it in
the array VAR(L), where L is the starting VAR index for that auxiliary-signal model. Subsequently,
depending on the type of device with which the auxiliary-signal model is associated with, the model
output contained in VAR(L) is then transferred by PSS®E into one of the PSS®E standard arrays,
DC2SIG or DCMSIG or VSCSIG or FCTSIG. The array locations in DC2SIG, DCMSIG, VSCSIG,
and FCTSIG into which VAR(L) is transferred, corresponds to the internal device index, and the
signal index for which the auxiliary-signal model is called.
15-9
DC Line Device Models

DC lines could be one of the following: two-terminal, multi-terminal or VSC dc.
The list of dc two-terminal, multi-terminal, and VSC dc line models recognized by activity DYRE is
provided in Chapter 13, Two-Terminal dc Line Model Data Sheets; Chapter 14, Multi-Terminal dc
Line Model Data Sheets; and Chapter 15, VSC dc Line Model Data Sheets of the PSS®E Model
Library.
Data records for dc line models are specified in the form:

where:
BUSID Is the dc line name (specified in single quotes).
2-Terminal DC Line other Models

The list of dc two-terminal “other” type models recognized by activity DYRE is provided in the
section on 2-terminal dc found in the Other Models chapter of the PSS®E Model Library.
Data records for dc line models are specified in the form:

where:
BUSID Is the dc line name (specified in single quotes).
FACTS Device Model

The list of FACTS device models recognized by activity DYRE is provided in Chapter 16, FACTS
Device Model Data Sheets of the PSS®E Model Library.
Data records for FACTS device models are specified in the form:

where:
BUSID Is the FACTS device name (specified in single quotes).
Wind Generator Models

Each in-service wind-machine in the working case must have a wind generator model data record
specified for it. The list of wind generator models that activity DYRE recognizes is provided in
Chapter 17, Generic Wind Generator Model Data Sheets of the PSS®E Model Library.
Data records specifying the wind-generator models should have, following the model name, the
Wind Electrical Control Models

Any wind machine may have an electrical control model specified for it. These -models control the
active and reactive power to be delivered to the system. The list of wind electrical control models
15-10
recognized by activity DYRE is listed in Chapter 18, Generic Wind Electrical Model Data Sheets of
the PSS®E Model Library.
Data records specifying the wind electrical control models should have, following the model name,
the identifier of the machine to which the model is being assigned, followed by the ICON data (if
applicable) and CON data in the same order as they appear in the respective model data sheets.
Wind Turbine Models

Any wind machine may have a turbine model specified for it. These -models calculate the mechan-
ical power and speed of the wind turbine. The list of wind turbine models recognized by activity
DYRE is listed in Chapter 19, Generic Wind Mechanical Model Data Sheets of the PSS®E Model
Library.
Data records specifying the wind turbine models should have, following the model name, the iden-
Wind Pitch Control Models

Any wind machine may have a pitch control model specified for it. These models control the blade
pitch angle using the rotor speed and torque command input signals.
Activity DYRE recognizes the pitch control models that are listed in Chapter 20, Generic Wind Pitch
Control Model Data Sheets of the PSS®E Model Library.
Data records specifying the pitch control models should have, following the model name, the iden-
Switched Shunt Models

Any device that is modeled as a switched shunt in PSS®E power flow can have a switched shunt
dynamic model specified for it.
The list of switched shunt models that are recognized by activity DYRE is provided in Chapter 22,
Switched Shunt Model Data Sheets of the PSS®E Model Library.
Data records specifying switched models should have, following the model name, the ICON data (if
applicable), and CON data in the same order as they appear in the respective model data sheets.
Miscellaneous “other” Models

The list of miscellaneous “other” models that are recognized by activity DYRE is provided in Miscel-
laneous and other Models chapter of the PSS®E Model Library.
Being unattached models, in principle these models are similar to the CONEC and CONET type
models. However the miscellaneous “other” models unlike the CONEC and CONET type models
will not generate any calls in the CONEC and CONET subroutines.
Data records specifying switched models should have, following the model instance value “MINS”
(which is any unique whole number greater than zero), followed by the model name, the model the
ICON data (if applicable), and CON data in the same order as they appear in the respective model
data sheets.
15-11
CONEC and CONET Models

The PSS®E model library contains a group of models that are presently called in CONEC and/or
CONET. Some of these models are used to model the dynamic characteristics of equipment, while
others pertain to electric network rather than the dynamic characteristics of the equipment. These
models (called CONEC and CONET models) are listed in Chapter 23, CONEC and CONET Model
Data Sheets of the PSS®E Model Library.
The ICON and CON lists contain the constant data values and are specified in the same order as
they appear in the ICON and CON blocks on the model data sheets.
User-Written Models
In addition to processing data records for most of the models contained in the PSS®E model library,
activity DYRE provides for the processing of records specifying data for user-written models (refer
to Chapter 20 for model writing details and Chapter 18 for information on the PSS®E dynamic simu-
lation structure). For such data records to be handled correctly by activity DYRE:
1. The special formats described below must be used.
2. The models must be written so as to be consistent with the calling sequences assumed
(refer to Section 20.4 Model Calling Sequence Rules).
Data records for load characteristic or load relay user-written models must be in the following
format:
BUSID ’USRLOD’ IL ’model name’ IC IT NI NC NS NV NRI data list /

Data records for load “other” type user-written models must be in the following format:
BUSID ’USRLOD’ IL ’model name’ IC IT NI NC NS NV data list /

Data records for branch device and branch “other” user-written models must be in the following
format:
BUSID ’USRBRN’ BUSID2 IL ’model name’ IC IT NI NC NS NV data list /
Data records for 2-winding transformer device and 2-winding transformer “other” user-written
models must be in the following format:
BUSID ’USR2WT’ BUSID2 IL ’model name’ IC IT NI NC NS NV data list /
Data records for line (branch and 2-winding transformer) relay user-written models must be in the
following format:
BUSID ’USRREL’ BUSID2 ID RS ’model name’ IC IT NI NC NS NV NRI data list /

Data records for 3-winding transformer device, and 3-winding transformer “other”, and 3-winding
transformer protection type user-written models must be in the following format:
BUSID ’USR3WT’ BUSID2 BUSID3 IL ’model name’ IC IT NI NC NS NV data list /
Data records for bus connected protection and “other” type user-written models must be in the
following format:
BUSID ’USRBUS’ ’model name’ IC IT NI NC NS NV data list /
15-12
Data records for user-written auxiliary-signal models must be specified in the following format:
BUSID ’USRAUX’ DVTYP SGNDX ’model name’ IC IT NI NC NS NV data list /

Data records for user-written dc line (two-terminal dc, multi-terminal dc and VSC dc) device models,
protection models, and model of type “other” are specified in the form:
BUSID ’USRDCL’ ’model name’ IC IT NI NC NS NV data list /

Data records for user-written FACTS device models, protection models, and model of type “other”
are specified in the form:
BUSID ’USRFCT’ ’model name’ IC IT NI NC NS NV data list /

Data records for user-written switched shunt device models, protection models, and model of type
“other” are specified in the form:
BUSID ’USRSWS’ ’model name’ IC IT NI NC NS NV data list /

Data records for user-written induction machine device, protection and “other” type models must be
in the following format:
BUSID ’USRIMC’ IM ’model name’ IC IT NI NC NS NV data list /
Data records for user-written machine (including wind machine) device, protection and “other” type
models must be in the following format:
BUSID ’USRMDL’ IM ’model name’ IC IT NI NC NS NV data list /
Data records for user-written miscellaneous “other” type models (these are unattached models)
must be in the following format:
MINS ’USRMSC’ ’model name’ IC IT NI NC NS NV data list /
Data records for all other types of user-written models must be in the following format:
BUSID ’USRMDL’ IM ’model name’ IC IT NI NC NS NV data list /
where BUSID, BUSID2, IM, IL, ID, RS, MINS, and < model name > are as described at the
beginning of The dynamics data input activity DYRE reads simulation model data from a Dynamics
Model Raw Data File into the dynamics data arrays in PSS®E working memory., and:
15-13
IC Is the user model type code:

0 = Model called from subroutine CONET and not called from subroutine
CONEC.
1 = Generator model.
2 = Current compensating model.
3 = Stabilizer model.
4 = Excitation system model.
5 = Turbine-governor device model.
7 = Two-terminal dc line model in PSS®E that is not yet in table-driven form (this
is obsolete and should not be used).
8 = Other subroutine CONEC model; place before RETURN statement in
CONEC.
9 = Minimum excitation limiter model.
10 = Maximum excitation limiter model.
11 = Cross-compound turbine-governor model.
12 = Load characteristic model.
13 = Load relay (protection) model.
14 = Line relay (protection) model.
17 = Auxiliary signal model.
18 = Two-terminal dc line model.
19 = Multi-terminal dc line model.
20 = VSC (Voltage Source Converter) dc line model.
15-14
21 = FACTS device model.

23 = Turbine load controller model.
24 = Switched Shunt model.
25 = Induction machine model
101 = Renewable generator model.
102 = Renewable electrical control model.
103 = Renewable turbine (mechanical) model.
104 = Renewable pitch control model.
105 = Renewable aerodynamic model.
106 = Renewable gust model.
107 = Renewable auxiliary control model.
108 = Renewable torque control model.
301 = Branch device model
302 = 2-Winding transformer device model
403 = 3-Winding transformer protection model
404 = Bus protection model (i.e., protection model attached to bus)
405 = Machine (including wind machine) protection model
406 = 2-Terminal dc line protection model
407 = N-Terminal dc line protection model
408 = VSC dc line protection model
409 = FACTS device protection model
410 = Switched shunt protection model
413 = Induction machine protection model
501 = Branch “other” model
502 = 2-Winding transformer “other” model
503 = 3-Winding transformer “other” model
504 = Bus “other” model (i.e., “other” type model attached to bus)
505 = Machine (including wind machine) “other” type model
506 = 2-Terminal dc line “other” model
507 = N-Terminal dc line “other” model
508 = VSC dc line “other” model
509 = FACTS device “other” model
510 = Switched shunt “other” model
15-15
511 = Load “other” model

512 = Miscellaneous “other” model (the model instance, MINS value, is required only
for this category of models)
513 = Induction Machine “other” model
IT For user models that are called from CONEC and/or CONET (i.e., when IC is 0, 7, or
8), IT could be 0, 1 or 2:
0 = not a current injection or metering model
1 = current injection model, place before IFLAG test in subroutine CONET
2 = metering model, place after IFLAG test in subroutine CONET
For user models with IC values of 1 through 5, or 9 through 14, 23, 17 through 21, or
101 through 107, the IT value depends on the value of IC. When IC is 1 through 5, 9
through 11, 23, 17 through 21, or 101 through 107, IT could be 0 (not a current injec-
tion model) or 1 (current injection model). When IC is either 12 or 13 (i.e., user written
load characteristic or load relay model), IT represents the subsystem type for the
load-related model and could be any value 1 through 5:
1 = Bus-type
2 = Owner-type
3 = Zone-type
4 = Area-type
5 = All-type
When IC is 14 (line relay user model), then IT indicates whether the relay is a super-
visory relay:
0 = Not supervisory
1 = Supervisory
When IC is 24, IT could be 1 or 2:
1 = current injection model
2 = metering model
When IC is 25, IT should be 1 (indicating it is a current injecting type model)
When IC is 301 through 303, IT could be any value 0 through 2
When IC is 403 through 410, or when IC is 413, IT should be 2
When IC is 501 through 513, IT could be any value 0 through 2
NI Is the number of ICONs used by the model (NI < 500).
NC Is the number of CONs used by the model (NC < 1000).
NS Is the number of STATEs used by the model.
NV Is the number of VARs used by the model.
NRI Is the number of additional (reserved) ICONs used by the model.
data list Specifies NI ICONs, followed by NC CONs.
In specifying ICONs, character ICONs (e.g., circuit identifiers) may be specified; they must be
enclosed in single quotes.
The 'model name' is limited to sixteen characters. This string is employed as a subroutine name
15-16
within the connection subroutines generated by activity DYRE (refer to For CONET models which
are not coordinated call models (i.e., IC is zero and IT is either one or two), BUSID and IM are both
specified as zero.) so it must conform to FORTRAN conventions for a subroutine name.
The following paragraphs discuss details specific to various model types. The CALL statements for
these models are generated as defined in Section 20.4 Model Calling Sequence Rules.
Machine Related Models

For plant-related model records (i.e., IC values of one through five and nine through eleven), BUSID
and IM designate the bus and machine identifiers respectively. Except as described below, all
machine related models must have a zero specified for IT.
For user-written cross-compound governor model records (i.e., IC values of eleven), BUSID and IM
specify the high-pressure unit. NV is followed by the bus and machine identifiers of the low pressure
unit. The remaining data items are the model constants (NI ICONs followed by NC CONs).
Machine-related user-written models are called at those phases of the dynamic simulation calcula-
tion concerned with the handling of differential equations. Certain generator models such as static
var systems also involve a voltage sensitive current injection during the network balance. For such
models:
1. IC and IT must be specified as one.
2. The model must contain a supplementary ENTRY point with the first character of the model
(SUBROUTINE) name changed to a T.
3. The model is called at its principal entry point for simulation calculations involving the differ-
ential equations, and at its supplementary entry point during the current injection calculation
of the network solution.
The implementation of this type of modeling requirement is referred to as a coordinated call model.
Load-Related Models
Load-related model records have an IC value of 12 or 13 and must have an IT value of 1 through 5.
The value of IT determines the type of subsystem for which the model applies, determines the
nature of BUSID and imposes constraints on the user 'model name' for the data record:
Table 15-1. Load-Related Model Subsystem Types

IT TYPE BUSID Model Name IL
1 Bus Bus Number ’xxxxBL’ Load ID or 
2 Owner Owner Number ’xxxxOW’ Load ID or 
3 Zone Zone Number ’xxxxZN’ Load ID or 
4 Area Area Number ’xxxxAR’ Load ID or 
5 All ’xxxxAL’ Load ID or 
15-17
The model name must be sixteen characters with the last two characters specifying the model type
(e.g., BL for Bus type model). IL may be specified as a specific load identifier for which the model
is to be applied, or a wildcard (*) indicating that the model is to be applied to all loads in BUSID.
All load-characteristic-user-written models must be set up as coordinated call models. Each load-
characteristic model will result in a subroutine call to 'model name' and a call to a supplementary
entry point with the first character of 'model name' changed to a T. For example, the model which
employs a 'model name' of MYLDBL will result in a calls to MYLDBL and TYLDBL. The 'model
name' should preclude an initial character of T to ensure that each subroutine reference is unique.
The NRI field of the user-written model data record identifies the number of reserved ICONs
employed by the model. A single data record for a load-related model may generate multiple
instances of the model’s application. The ICON and CON data presented on the data record will be
common to all application instances and will be stored in the data arrays only once. Any VAR,
STATE and reserved ICON requirements will apply to each instance. An allocation of the required
VARs, STATEs and reserved ICONs will be made in the data arrays for each application instance.
Line Relay Models

Line relay model records have an IC value of 14. The IT value must be 1 to indicate that it is a relay
acting in a supervisory role, or 0 if it is not a supervisory relay.
The BUSID value indicates the branch from bus where the relay is located and BUSID2 indicates
the branch to bus. ID is the branch circuit identifier. Two relays are allowed at each from bus. The
user must enter a 1 or 2 for the relay slot (RS).
Line relay user-written models are called from subroutine USRREL.
Auxiliary Signal Models

Auxiliary-signal user-model records have an IC value of 17. The IT value must be zero to indicate
that it is not a current injection model.
Auxiliary-signal models can be associated with dc line models (two-terminal dc, multi-terminal dc,
VSC dc) and FACTS device models. The BUSID in the dynamic data record is the device name in
single quotes with which the auxiliary-signal is associated. DVTYP indicates the type of the device
with which the auxiliary-signal is associated (1 for 2-terminal dc line, 2 for multi-terminal dc line, 3
for VSC dc line, 4 for FACTS device). SGNDX is the auxiliary-signal index. This is any number 1
through maximum number of auxiliary-signals that can be associated with the device type under
consideration (refer to Table 3-1 for the maximum number of auxiliary-signals that can be attached
to each device type).
The user-written auxiliary-signal model should calculate the model output and store it in VAR(L),
where L is the starting VAR index for that auxiliary-signal model. Subsequently, depending on the
type of device with which the auxiliary-signal model is associated, the model output contained in
VAR(L) is then transferred by PSS®E into one of the PSS®E standard arrays, DC2SIG or DCMSIG
or VSCSIG or FCTSIG. The array locations in DC2SIG, DCMSIG, VSCSIG, and FCTSIG into which
VAR(L) is transferred, corresponds to the internal device index and the signal index for which the
auxiliary-signal model is called.
15-18
DC Line Models
DC line user-model records have an IC value of 18 for two-terminal dc lines, 19 for multi-terminal
dc lines, and 20 for VSC dc lines. The IT value must be 1 to indicate that it is a current injection
model. The BUSID is the dc-line line name in single quotes.
All dc line user-written models must be set up as coordinated call models. Each dc line model will
result in a subroutine call to 'model name' and a call to a supplementary entry point with the first
character of the 'model name' changed to a T. The model is called at its principal entry point for
simulation calculations involving the differential equations, and its supplementary entry point during
the current injection calculation of the network.
FACTS Device Models

FACTS device user-model records have an IC value of 21. The IT value must be 1 to indicate that
it is a current injection model. The BUSID indicates the FACTS device name in single quotes.
All FACTS device user-written models must be set up as coordinated call models. Each FACTS
device model will result in a subroutine call to 'model name' and a call to a supplementary entry point
with the first character of the 'model name' changed to a T. The model is called at its principal entry
point for simulation calculations involving the differential equations, and its supplementary entry
point during the current injection calculation of the network.
Wind Machine Related Models

For wind machine model records (i.e., IC values of 101 through 107), BUSID and IM designate the
bus and machine identifiers respectively. Except for the wind generator models, all other wind
machine related models must have a zero specified for IT.
Wind machine related user-written models are called at those phases of the dynamic simulation
calculation concerned with the handling of differential equations. Wind generator models also
involve a voltage sensitive current injection during the network balance. For such models:
1. IC and IT must be specified as one.
2. The model must contain a supplementary ENTRY point with the first character of the model
(SUB-ROUTINE) name changed to a T.
3. The model is called at its principal entry point for simulation calculations involving the differ-
ential equations, and at its supplementary entry point during the current injection calculation
of the network solution.

Switched shunt user-model records have an IC value of 24. The IT value could be 1 (for current
injecting models), or could be 2 (metering model that turns shunts ON/OFF).
The BUSID indicates the bus at which the switched shunt is connected.
User-written switched shunt model with IT=1 (current injecting type), will be set up as a coordinated
call model. Such switched shunt models will result in a subroutine call to 'model name' and a call to
a supplementary entry point with the first character of the 'model name' changed to a T. The model
is called at its principal entry point for simulation calculations involving the differential equations, and
its supplementary entry point during the current injection calculation of the network.
15-19
User written switched shunt models with IT=2 are called after the dynamic simulation network solu-
tion is converged.
CONEC Models
Those CONEC models with an IC value of eight may be implemented either as simple CONEC
models (IT is specified as zero) or as coordinated call model pairs (IT is specified as one). In the
latter case, model calls are generated in both subroutines CONEC and CONET, with the first char-
acter of the model name changed to a T in the CONET model call.
CONET Models
For CONET models which are not coordinated call models (i.e., IC is zero and IT is either one or
two), BUSID and IM are both specified as zero.
15.1.2 Operation of Activity DYRE

In order to conduct the time domain simulation it is necessary to associate (connect) dynamic equip-
ment and other models with power flow network equipment (i.e. buses, machines, loads, etc.). The
dynamic models are resolved either in the PSS®E simulation model library or by user supplied user-
written model code. A programmatic association is made for those models which are resolved in
the PSS®E simulation model library and which represent generator plant related equipment, load
characteristics, load relays, branch relays, auxiliary signals, dc lines, FACTS device, switched
shunt, and some monitoring functions, and for user supplied models of plant related equipment,
load characteristics, load relays, branch relays, auxiliary signals, dc lines, FACTS device, switched
shunt, and induction machine models.
Activity DYRE performs these major functions as it reads through the Dynamics Model Raw Data
File:
1. It assigns storage locations in the various dynamics data storage arrays for each of the
models referenced (refer to Section 18.1.2 Data Structure).
2. It initializes the constant parameters in these data arrays for each model referenced in the
data file.
3. It creates tables of pointers for programmatic associations of dynamic models with network
equipment where appropriate.
4. If required, it constructs the connection subroutines (refer to Section 18.4 The Dynamic
Model).
Activity DYRE requires that the network corresponding to the dynamics data being read is present
in the working case. It further requires that the in-service machines in the working case contain the
proper specification of the machine attributes MBASE, ZSORCE, XTRAN and GENTAP (refer to
Generator Data), and that they be represented as current sources (i.e., with activity section /
CONG having been executed.
The user specifies the Dynamics Model Raw Data File which contains data records in the form
given in The dynamics data input activity DYRE reads simulation model data from a Dynamics
Model Raw Data File into the dynamics data arrays in PSS®E working memory..
The user also specifies the files into which activity DYRE is to place the connection subroutines.
Refer to Section 2.6 Files Created By PSS®E for the file overwriting conventions used by activity
DYRE. If the user does not provide filenames for either CONEC or CONET files, an image of the
15-20
corresponding subroutine’s CALL statements is written to the user’s terminal rather than to a file.
After the required files are read into the working case, activity DYRE provides the following
information:
NEXT AVAILABLE ADDRESSES ARE:
CON STATE VAR ICON
nnn nnn nnn nnn
The values < nnn > indicate the next available locations in the corresponding dynamics data
arrays. When PSS®E is started up, these indices are set to one and are subsequently updated by
activities DYRE, CHAN, and CHSB. They may be changed by the user via activity ALTR using the
category of solution parameter changes. These indices are preserved with dynamics working
memory as it is saved and retrieved with activities SNAP and RSTR respectively.
When constructing a new dynamics setup, the normal entry is 1 for each of the starting indices.
When activity DYRE is used in its add models mode (refer to Section 15.1.3, Adding Models), the
usual procedure is to let activity DYRE assign locations in the dynamics data arrays for the models
being added beginning at the next unused slots.
Activity DYRE generates an alarm for any model data record for which either too many, or not
enough, data items have been specified. Upon completing its pass through the Dynamics Model
Raw Data File, activity DYRE builds the connection subroutines and deposits values in locations in
the dynamics data constant arrays.
As it completes each of the model types described above, a summary of the storage locations
allocated in the various data storage arrays is printed. A single similar summary is printed for the
model types described in CONEC and CONET Models. These are followed by a summary of the
number of model references read from the Dynamics Model Raw Data File. These tabulations are
printed at the Progress tab.
Activity DYRE then prints a final summary of the storage locations used. This is printed at the
Progress tab; it is also printed at the dialog output device if these two output destinations are
different. The next available indices are updated to reflect these dynamics data array allocations.
Activity DYRE summarizes the status of the connection subroutines generated by printing at the
dialog output device, one of the messages as explained below.
If the case has user models for which compilation is required, and if no model calls were generated
in the connection routines CONEC and CONET, the message generated at the dialog output
device would be:
COMPILE USER MODELS, & CREATE USER DLL
If there are user models in the case, and if model calls were generated only in CONEC, the
message generated at the dialog output device would be:
COMPILE CONEC, USER MODELS, & CREATE USER DLL

If there are user models in the case, and if model calls were generated only in CONET, the message
generated at the dialog output device would be:
COMPILE CONET, USER MODELS, & CREATE USER DLL

If there are user models in the case, and if model calls were generated both in CONEC and in
CONET, the message generated at the dialog output device would be:
COMPILE CONEC, CONET, AND USER MODELS, & CREATE USER DLL
15-21
If the case does not have any user models for which compilation is required, the following message
is generated at the dialog output device:
NO USER WRITTEN MODELS IN CASE. COMPILATION NOT REQUIRED
If the user specifies filename for a Compile File, unnecessary if CONEC and CONET filenames
were not read into the working case, activity DYRE creates a file which, when executed at
operating system level, compiles the connection subroutines just constructed. The use of this
feature is strongly encouraged because it guarantees the correct specification of compiler option
settings in compiling these subroutines. A response of zero to the above instruction suppresses
the generation of the compiling file.
Those data items identified as BUSID in the data record formats described in The dynamics data
input activity DYRE reads simulation model data from a Dynamics Model Raw Data File into the
dynamics data arrays in PSS®E working memory. must specify bus numbers when the numbers
input option is in effect. Using the names input option specify either a bus number or an extended
bus name enclosed in single quotes. In specifying ICONs in the data list portion of data records,
any ICON in which a bus is to be specified must contain a bus number regardless of the bus input
option setting.
Refer to Section 2.4.1 File Usage for the file specification conventions used by activity DYRE.
15.1.3 Adding Models

Activity DYRE may be operated in an add models mode. The usual procedure in adding models to
an existing (or partially completed) system model is as follows:
1. Initiate PSS®E.
2. Use activity
3. to restore RSTRthe Snapshot containing the dynamics data of the existing system model.
4. Pick up the network model corresponding to the Snapshot accessed in (2).
5. Run activity DYRE,ADD or navigate File > Open > Files of type: Add Dynamics Model Data
(*.dyr) from the GUI menu.
6. Take a Snapshot with activity
7. Exit PSS®E with activity section / STOP.
8. If there are model calls in the connection routines CONEC and/or CONET, merge the model
calls generated in (4) with the original versions of these connection subroutines.
Compile the resulting subroutines and link the connection subroutines into PSS®E in the standard
manner (refer to Sections 4.10 and 18.4.4).
If no additional model calls are generated in the connection subroutine additions files, steps 6
through 8 are not required (see below).
After specifying the appropriate Dynamics Model Raw Data File to activity DYRE in (4) above, the
user enters the names of the files into which activity DYRE is to place any new connection subrou-
tine model calls.
15-22
The user should not specify the pair of files containing the versions of these subroutines corre-
sponding to the existing system model; activity DYRE does not append to the specified files but
overwrites the previous contents of existing files. Refer to Section 2.4.1 File Usage for the file
specification conventions used by activity DYRE.
The normal response to the request for starting data array indices (refer to For CONET models
which are not coordinated call models (i.e., IC is zero and IT is either one or two), BUSID and IM
are both specified as zero.) is the default, after which activity DYRE uses the next available loca-
tions as contained in the Snapshot restored in (2) above.
In the add models mode, activity DYRE summarizes the status of the connection subroutines by
printing one of the following messages as explained below.
If the DYRE addition has user models for which compilation is required, and if no model calls were
generated in the connection routines CONEC and CONET, the message generated at the dialog
output device would be:
CONEC & CONET (IF PRESENT) ARE UNCHANGED. COMPILE USER MODELS, AND
CONEC & CONET (IF PRESENT), & CREATE DLL
If the DYRE addition generates user model calls only in CONEC, the message generated at the
dialog output device would be:
EDIT NEW CALLS INTO CONEC. CONET (IF PRESENT) IS UNCHANGED. THEN
COMPILE CONEC, USER MODELS, AND CONET (IF PRESENT), & CREATE USER DLL
If the DYRE addition generates user model calls only in CONET, the message generated at the
dialog output device would be:
EDIT NEW CALLS INTO CONET. CONEC (IF PRESENT) IS UNCHANGED. THEN
COMPILE CONET, USER MODELS, AND CONEC (IF PRESENT), & CREATE USER DLL
If the DYRE addition generates user model calls in CONEC as well as CONET, the message gener-
ated at the dialog output device would be:
EDIT NEW CALLS INTO CONEC & CONET. THEN COMPILE CONEC, CONET, AND
USER MODELS, & CREATE USER DLL
If the DYRE addition does not have any user model for which compilation is required, the following
message is generated at the dialog output device:
CONEC & CONET (IF PRESENT) ARE UNCHANGED

The generation of a new compiling file is suppressed in the add models mode. In (7) above, the
usual approach is to store the merged versions of the connection subroutines with their original file-
names rather than with the filenames specified to activity DYRE in (4) above. In this case, the
original compiling file may be used. If filenames other than the original filenames are used in (7)
above, the original compiling file may be modified as appropriate with the text editor.
In the add models mode, the CONEC and CONET subroutine additions files constructed are not in
FORTRAN subroutine form. Rather, they consist of only the CALL statements and are set up to be
conveniently merged, via the text editor, with the original versions of these two subroutines.
When replacing a model called from internal tables (e.g., changing the excitation system model
from a SEXS to an IEEET1), activity DYRE removes references to the old model from the dynamics
model connection tables before adding the new model reference to these data tables. A message
15-23
is printed at the Progress tab each time a model reference is deleted. When replacing a model
called from subroutine CONEC or CONET, the user must remove the old model call from the
connection subroutines when merging the original versions of these subroutines with the newly
generated model subroutine calls.
15.1.4 Subsystem Models

Load characteristic and load relay models may be introduced by subsystem. Subsystems can be
designated as: bus, owner, zone, area, or all. The presentation of a single data record for a
subsystem model can generate multiple instances of the model’s application. For example,
presenting a bus specific model with a wildcard element identifier (e.g., a load-related model with
IL='*') generates an instance of the model for each load connected to the bus. Similarly, presenting
an area specific subsystem model with a specific identifier (e.g., a load-related model with IL='1')
generates as many instances of the model as there are loads within the area which are assigned
that identifier.
Precedence is an issue unique to subsystem models. The data presentation for subsystem models
may involve intersection among the subsystems. The data may contain a presentation for both a
bus-specific model and an area-specific model, and the bus associated with the first model may be
part of the area associated with the second. Therefore a precedence order is provided to accom-
modate subsystem models. The decreasing order of precedence for resolving conflicts is from the
most specific to most general subsystem: bus, owner, zone, area, and all. A model applied to a bus
takes precedence over all conflicting models applied to any other subsystem in which the bus is
located. A model applied to an owner takes precedence over any conflicting model applied to a
zone, area, or all buses.
A precedence order is provided to accommodate conflicts in element identifier as well. A data

record which introduces a subsystem model with a specific element identifier will take precedence
over a subsystem model with a wildcard ('*') identifier.
Models employing programmatic association with network elements may be bypassed. This
includes all models except those connected to the network by subroutine calls within the CONEC
and/or CONET subroutines. When the model is bypassed, its function is excluded from the time
domain simulation without extracting its reference or data from the simulation model. The model
may be restored to an active state through program dialog.
A subsystem model can be bypassed at both the subsystem instance and the element instance.
When a model is bypassed at the subsystem instance the model’s function is excluded for each
element to which the subsystem model applies. When the subsystem model is bypassed at the
element instance, the model’s function is excluded for only that element, and the function will be
invoked for all other active elements to which the subsystem model applies.
A bypassed model remains connected to the element. The bypassed model is not superseded by
another active model which could potentially replace it due to precedence. However, if the model is
removed, the next subsystem model in the precedence order automatically connects to the
element. For example, if a Bus Subsystem model with a specific identifier (e.g.'1') were to be
bypassed, another Bus Subsystem model at the same bus with a wildcard (*) identifier does not
replace it. If the element specific model were removed, then the wildcard model applies.

The processing of activity DYRE results in three related but separate sets of data needed in formu-
lating the dynamic system model:
15-24
1. Dynamics working memory with its constant data arrays initialized to the model constants
obtained from the data file.
2. A data file containing the FORTRAN subroutine CONEC.
3. A data file containing the FORTRAN subroutine CONET.
After an error-free execution of activity DYRE is completed, and prior to terminating PSS®E, it is
strongly recommended that dynamics working memory be preserved in the form of a Snapshot by
using activity SNAP.
When specifying data for the compensating models (refer to Current Compensating Models), the
user should carefully note the significance of the sign of their data values (refer to the data sheets
in Chapter 2, Compensator Model Data Sheets of the PSS®E Model Library). With a negative reac-
tance, the COMP model queries from the terminal bus into the machine to determine the
compensated voltage, while with a positive reactance, it queries into the network. The IEEEVC
model uses the opposite sign convention.
The 1968 IEEE Type 1 and 2 exciter models, IEEET1 and IEEET2, use the same model subroutine
which distinguishes between these two excitation systems on the basis of the value specified for
the second feedback time constant. A zero for this constant is used to designate the Type 1 model,
and a nonzero value is interpreted as the second feedback time constant of the Type 2 model.
Activity DYRE examines the value specified for this data item, and if appropriate, converts a Type
1 reference to a Type 2 or vice versa. The 1979 IEEE Type 1 and 2 models, IEEEX1 and IEEEX2,
are handled in the same manner.
In the summary tabulating the number of references of each PSS®E model, the IEEE Type 1
governor models, IEEEG1, TGOV5 and WSIEG1, may each be shown twice. The first listing shows
its number of uses as a cross compound turbine governor model, and its second gives the number
of occurrences with a single machine.
Models CIROS1 and SLNOS1 have an ICON that must be modified if these models are used in a
supervisory mode. These should be set to the number of the appropriate permissive flag ICON of
the supervised relay model. This can be done through the model edit feature in the Dynamics
Models Spreadsheet; refer to PSS®E GUI Users Guide, Section 2.5, Dynamics Spreadsheet.
15.1.6 Error Messages

As it processes the Dynamics Model Raw Data File, activity DYRE generates an alarm for errors
resulting from the conditions listed below. In alarming a data record, the error message block often
includes the first physical line of the offending data record.
1. A model name is encountered which is not recognized. The following error message is
generated:
UNDEFINED MODEL aaaaaa

Activity DYRE ignores the data record and processing continues. In reading Dynamics
Model Raw Data Files prepared for, or generated by, release nineteen or earlier of
PSS®E, data records for the models STAB2 and GAST2 generate an alarm as unde-
fined. These models were replaced by the models STAB2A and GAST2A at PSS®E-
20. For additional details refer to the PSS®E-20 release notes in PSS®E Compatibility
Reference.
15-25
2. Too many models of a given type (e.g., two generator models specified for a machine). One
of the following error messages is generated:
DUPLICATE MODEL TYPE: aaaaaa AT BUS nnnn MACHINE n

DUPLICATE MODEL TYPE: aaaaaa AT BUS nnnn LOAD n
DUPLICATE MODEL TYPE: aaaaaa AT AREA nnnn LOAD n
DUPLICATE MODEL TYPE: aaaaaa AT ZONE nnnn LOAD n
DUPLICATE MODEL TYPE: aaaaaa AT OWNER nnnn LOAD n
DUPLICATE MODEL TYPE: aaaaaa FROM BUS nnnn TO BUS nnnn SLOT i
DUPLICATE MODEL TYPE: aaaaaa FOR ALL-TYPE LOAD aa
DUPLICATE MODEL TYPE: aaaaaa WITH SAME SIGNAL INDEX nn
ASSOCIATED WITH 2-TERM DC LINE name
ASSOCIATED WITH MULTI-TERM DC LINE name
ASSOCIATED WITH VSC DC LINE name
ASSOCIATED WITH FACTS DEVICE name
DUPLICATE MODEL TYPE: aaaaaa FOR 2-TERMINAL DC LINE nn
DUPLICATE MODEL TYPE: aaaaaa FOR MULTI-TERMINAL DC LINE name
DUPLICATE MODEL TYPE: aaaaaa FOR VSC DC LINE name
DUPLICATE MODEL TYPE: aaaaaa FOR FACTS DEVICE name
Activity DYRE ignores the data record that generated an alarm (i.e., it uses the data
record previously read) and processing continues.
3. Error in decoding a data record. The standard data input error message is printed followed
by:
RECORD IGNORED
This message is the first physical line of the offending record. In addition to typograph-
ical errors, this error is encountered when the numbers input option is in effect and a
BUSID field on a data record specifies an extended bus name.
4. Error in the specification of the low pressure unit on a data record specifying the cross
compound governor model CRCMGV, IEEEG1, TGOV5 or WSIEG1, the second machine
of a FRECHG or COMPCC model, or the low pressure unit of a user-written cross-
compound governor model. The following error message is printed, the record is ignored,
and processing continues:
aaaaaa BUS nnnn MACHINE n NOT FOUND

5. Either the bus or designated machine is not in the working case.
6. Too many bus and network oriented models. The following error message is printed, the
record is ignored, and processing continues:
TOO MANY MISCELLANEOUS MODELS

7. Activity DYRE can process a total number of the models listed in
8. of up to the maximum number of machines for which PSS®E is dimeCONEC and CONET
Modelsnsioned. Too few data items on a record. The following error message is printed
15-26
followed by a line indicating that either the record is ignored or that zeros are assumed for
the missing data items:
WARNING: INCOMPLETE DATA RECORD FOR MODEL aaaaaa

9. Too many data items on a record. The following error message is printed followed by the first
physical line of the data record, and processing continues:
EXCESS DATA IGNORED ON RECORD

10. The bus specified on a bus oriented model data record is not in the working case. The
following error message is printed, the record is ignored, and processing continues:
BUS nnnn NOT FOUND

11. Auxiliary-signal models SQBAUT and RBKELT can be used only with two-terminal dc line
models. One of the following error message is printed, the record is ignored, and processing
continues:
AUX. SIGNAL MODEL SQBAUT CAN BE USED ONLY WITH 2-TERM DC LINES
AUX. SIGNAL MODEL RBKELT CAN BE USED ONLY WITH 2-TERM DC LINES
12. The device type (DVTYP) in the auxiliary-signal data record is invalid. This error message
could be due to the following reason:
- DVTYP is a value other than 1 through 4.

The following error message is printed, the record is ignored, and processing contin-
ues:
INVALID DEVICE TYPE
13. The signal index (SGNDX) in the auxiliary-signal data record is invalid. This error occurs if
the SGNDX value specified is less than or equal to zero, or if it is greater than the maximum
number of auxiliary signals that can be associated with the device type.
The following error message is printed, the record is ignored, and processing contin-
ues:
INVALID AUX. SIGNAL INDEX FOR THE DEVICE
14. An invalid two-terminal dc line name is specified either in the data record for a two-terminal
dc line model, or in the auxiliary-signal data record that is associated with a two-terminal dc
line. The following error message is printed, the record is ignored, and processing
continues:
INVALID 2-TERMINAL DC LINE

15. An invalid multi-terminal dc line name is specified either in the data record for a multi-
terminal dc line model, or in the auxiliary-signal data record that is associated with a multi-
terminal dc line. The following error message is printed, the record is ignored, and
processing continues:
INVALID MULTI-TERMINAL DC LINE

16. An invalid VSC dc line name is specified either in the data record for a VSC dc line model,
or in the auxiliary-signal data record that is associated with a VSC dc line. The following error
message is printed, the record is ignored, and processing continues:
15-27
INVALID VSC DC LINE NAME

17. An invalid FACTS device is specified either in the data record for a FACTS device model, or
in the auxiliary-signal data record that is associated with a FACTS device. The following
error message is printed, the record is ignored, and processing continues:
INVALID FACTS DEVICE

18. An invalid user model type code (IC) is specified for a user-written model. The following error
message is printed, the record is ignored, and processing continues:
INVALID USER MODEL TYPE CODE: nnn

19. An invalid user model network code (IT) is specified for a user-written model. The following
error message is printed, the record is ignored, and processing continues:
INVALID USER MODEL NETWORK CODE: nnn

20. An invalid combination of model type and network codes is specified for a user-written
model. The following error message is printed, the record is ignored, and processing
continues:
INVALID USER MODEL TYPE/NETWORK CODE COMBINATION

21. Less than zero or more than five hundred array locations in the CON, STATE or VAR array,
or less than zero or more than two hundred array locations in the ICON array, specified for
a user-written model. The following error message is printed, the record is ignored, and
INVALID NUMBER OF ARRAY LOCATIONS: nnn

22. The same user-written model is given different characteristics (IC through NV or NRI) on two
user model data records. The following error message is printed, the record is ignored, and
INCONSISTENT MODEL DEFINITIONS FOR SAME USER MODEL

23. More than 100 user-written model names have been defined for plant-related, load charac-
teristic, load relay, branch relay, auxiliary signal, dc line, and FACTS device -models. The
following error message is printed, the record is ignored, and processing continues:
TOO MANY USER MODEL DEFINITIONS

The Remove unused user models function available from the Dynamics>Model mainte-
nance… menu entry for Plant model, Load model, Line relay model, Aux Signal model,
DC line model, FACTS model, switched, and wind model may be used to eliminate
unused user model definitions. Refer to PSS®E GUI Users Guide, Section 20.9, Mod-
ifying Dynamics Model Pointer Tables.
24. In reading the ICONs for a user-written model, a number with a decimal point was entered.
The following error message is printed, the record is ignored, and processing continues:
REAL ENTERED WHERE INTEGER OR CHARACTER EXPECTED: X.XXXX

25. In the add models mode, the number of entries needed in the table driven machine model
connection tables exceeds the number of machines for which PSS®E is dimensioned. The
following error message is printed and activity DYRE is terminated:
15-28
MACHINE MODEL CONNECTION TABLES FULL--USE DYCH TO PACK TABLES

The Remove unconnected models and Pack models functions of the Dynamics>Model
maintenance… menu entry for Plant model may be used to eliminate slots in these
tables for machines not in the working case. Refer to PSS®E GUI Users Guide, Section
20.9, Modifying Dynamics Model Pointer Tables.
26. In the add models mode, the number of entries needed in the table driven load model
connection tables exceeds the number of table entries for which PSS®E is dimensioned.
The following error message is printed and activity DYRE is terminated:
LOAD MODEL CONNECTION TABLES FULL--USE PACK LOAD MODELS FUNCTION

maintenance… menu entry for Load model may be used to eliminate slots in these
tables for loads not in the working case. Refer to PSS®E GUI Users Guide, Section
27. In the add models mode, the number of entries needed in the table driven line relay model
connection tables exceeds the number of table entries for which PSS®E is dimensioned.
The following error message is printed and activity DYRE is terminated:
LINE RELAY CONNECTION TABLES FULL--USE PACK LINE RELAY MODELS

FUNCTION
maintenance… menu entry for Line relay model may be used to eliminate slots in these
tables for branches not in the working case. Refer to PSS®E GUI Users Guide, Section
28. In the add models mode, the number of entries in the auxiliary-signal connection tables
exceeds the number of table entries for which PSS®E is dimensioned. The following error
message is printed and activity DYRE is terminated:
AUX. SIGNAL CONNECTION TABLES FULL-USE PACK AUX. SIGNAL MODEL

29. In the add models mode, the number of entries in the dc line connection tables exceeds the
number of table entries for which PSS®E is dimensioned. Depending on the dc line type
(two-terminal or multi-terminal or VSC), one of the following error messages is printed and
activity DYRE is terminated:
TWO-TERMINAL DC LINE MODEL CONNECTION TABLES FULL-USE PACK DC

LINE MODEL
MULTI-TERMINAL DC LINE MODEL CONNECTION TABLES FULL-USE PACK DC
LINE MODEL
VSC DC LINE MODEL CONNECTION TABLES FULL-USE PACK DC LINE MODEL
30. In the add models mode, the number of entries in the FACTS device connection tables
exceeds the number of table entries for which PSS®E is dimensioned. The following error
message is printed and activity DYRE is terminated:
FACTS DEVICE MODEL CONNECTION TABLES FULL-USE PACK FACTS DEVICE

MODEL
31. One of the data storage arrays has no more available locations. The following message is
printed and activity DYRE is terminated:
15-29
DYRE TERMINATED--SYSTEM MODEL REQUIRES TOO MANY aaaaaa

32. The same machine was specified for both machines in a two machine model. The following
-message is printed, the record is ignored, and processing continues:
DIFFERENT MACHINES MUST BE SPECIFIED IN TWO MACHINE MODEL

33. Too many load models of a given subsystem type (BUS, OWNER, ZONE, AREA or ALL-
TYPE) were specified. The following -message is printed, the record is ignored, and
xxxxx LOAD MODEL TABLE OVERFLOW

34. Mismatch between the network code (IT) and the two character suffix of a user load model
name:
LOAD MODEL SUBSYSTEM CODE AND MODEL NAME INCONSISTENT

35. An invalid relay slot (RS) was specified. The following error message is printed, followed by
the first physical line of the data record, and processing continues:
INVALID RELAY SLOT: aaaaa CKT id FROM BUS nnnn TO BUS nnnn SLOT i
36. An obsolete system-wide model, for which the function is now handled via solution options,
is specified. The following error message is printed and processing continues:
MODEL aaaaa IGNORED--USE SIMULATION OPTIONS TO INVOKE

37. An obsolete monitoring model, for which the function is now enabled via activity
, is specified. One of the following error messages is printed and processing coCHSBntinues:
MODEL aaaaa IGNORED--USE ACTIVITY CHSB
MODEL TOTA FOR AREA NUMBER nnn IGNORED--USE ACTIVITY CHSB
MODEL TOTZ FOR ZONE NUMBER nnn IGNORED--USE ACTIVITY CHSB
38. In converting an old branch relay model to its new table-driven replacement, two branch
relay models are already present on the line in the same direction. The following error
message is printed and processing continues:
MODEL aaaaa FROM BUS nnn TO BUS nnn CKT aa IGNORED--BOTH RELAY
SLOTS TAKEN
The user should reconcile any error messages before completing the setup of the dynamic model
of the system under study.
PSS®E GUI Users Guide, Section 20.1, Reading Dynamics Model Data
Section 17.1, Reading Dynamics Model Data
15-30
Program Operation Manual Assigning Simulation Variables to Output Channels
15.2 Assigning Simulation Variables to Output Channels

Activity CHAN
Run Activity CHAN - GUI

Dynamics>Define simulation output (CHAN)
[Assign Channels for Bus Quantities]
[Assign Channels for Line Quantities]
[Assign Channels for Load Quantities]
[Assign Channels for Machine Quantities]
[Assign Channels for Misc. Quantities]
Run Line Mode Activity CHAN - CLI
ACTIVITY?
>>CHAN

None
The output channel selection activity CHAN enables the user to select simulation variables which
are to be monitored during dynamic simulation runs. These quantities may be tabulated and/or
placed into a Channel Output File at regular intervals during a simulation run (refer to activity RUN).
The simulation results, as contained in the Channel Output File, are able to be processed by the
PSS®E plot package following completion of the simulation. Up to six channels can be defined for
interactive plotting during the simulation run.
15.2.1 Operation of Activity CHAN

The user identifies quantities to be placed into output channels and activity CHAN places their
memory addresses and alphanumeric identifiers into the PSS®E dynamics data arrays IPRINT and
IDENT respectively.
Activity CHAN displays the next available location pointers for Channel, VAR, and ICON for the
corresponding dynamics data arrays (refer to For CONET models which are not coordinated call
models (i.e., IC is zero and IT is either one or two), BUSID and IM are both specified as zero. and
activity SNAP). In a simulation, output channels are assigned sequentially starting with channel
one. If there are < n > quantities being monitored, they normally occupy output channels one
through < n >. Activity CHAN assigns locations in these arrays at their next available positions.
The user specifies the type of data to be placed in output channels, the element to be monitored,
and an optional thirty-two character identifier to be assigned to the output channel. The user also
specifies the bus number, machine identifier, and an alphanumeric channel identifier which, if
supplied, must be enclosed in single quotes. If no identifier is specified, activity CHAN supplies a
default identifier. summarizes each category of data with the default identifier assigned by activity
CHAN.
Table 15-2. Activity CHAN Summary
15-31
Assigning Simulation Variables to Output Channels Program Operation Manual
Quantity Units Selected By Default Identifier*

ANGLE: rotor angle degrees Bus, machine id ANGL xx
PELEC: electrical power pu on system base Bus, machine id POWR xx
QELEC: reactive power pu on system base Bus, machine id VARS xx
ETERM: terminal voltage pu Bus, machine id ETRM xx
EFD: field voltage pu Bus, machine id EFD xx
PMECH: mechanical power pu on machine base Bus, machine id PMEC xx
SPEED: speed deviation pu Bus, machine id SPD xx
XADIFD: field current pu Bus, machine id IFD xx
ECOMP: compensated voltage pu Bus, machine id ECMP xx
VOTHSG: stabilizer signal pu Bus, machine id AUX xx
VREF: regulator reference pu Bus, machine id VREF xx
VUEL: minimum excitation limiter
pu Bus, machine id VUEL xx
signal
VOEL: maximum excitation limiter
pu Bus, machine id VOEL xx
signal
BSFREQ: frequency deviation pu Bus FREQ yy
Bus voltage pu Bus VOLT yy
Bus voltage and angle pu and degrees Bus VOLT yy and ANGL yy
from bus, to bus, circuit

Branch flow (P) MW POWR zz
identifier, third bus

Branch flow (P and Q) MW and Mvar POWR zz and VARS zz

Branch flow (MVA) MVA MVA zz

Apparent R and X pu and pu APPR zz and APPX zz
VAR Varies VAR number VAR nn

STATE Varies STATE number STATE nn
Machine terminal current(1) pu Bus, machine id ITRM xx
Machine apparent impedance(1) pu and pu Bus, machine id APPR xx and APPX xx
PLOAD: active power load pu Bus, load id PLOD vv

QLOAD: reactive power load pu Bus, load id QLOD vv
Governor reference pu Bus, machine id GREF xx
Turbine Load Controller referencepu Bus, machine id LCRF xx
15-32
Wind velocity pu Bus, wind machine id WVEL xx

Wind turbine speed pu Bus, wind machine id WTSP xx
Wind Pitch degree Bus, wind machine id WPCH xx
Wind aerodynamic torque pu Bus, wind machine id WAET xx
Wind rotor voltage pu Bus, wind machine id WRTV xx
Wind rotor current pu Bus, wind machine id WRTI xx
Wind real power command from
pu Bus, wind machine id WPCM xx
electrical control
WInd reactive power command
pu Bus, wind machine id WQCM xx
from electrical control
Wind Auxiliary control output pu Bus, wind machine id WAUX xx
PMECH subsystem
PELEC subsystem
SUBSYSTEM TOTALS(2) MVA Subsystem number PACCL subsystem
PLOAD subsystem
PE-PL subsystem
*Notes:
xx Contains the bus number, the extended bus name, and the machine identifier
yy Contains the bus number and the extended bus name.
zz Contains the from bus number, to bus number or, for a three-winding transformer, the
string 3W: followed by the transformer name, and the circuit identifier.
nn Is the VAR or STATE index.
vv Contains the bus number, load identifier, and the extended bus name
(1) Valid for synchronous machine models only.
(2) From activity CHSB, SUBS.
When selecting branches for monitoring, up to three buses may be specified. Nontransformer
branches and two-winding transformers are specified by making no entry in the third bus field. For
three-winding transformers, all three buses must be specified. Branch quantities are calculated at
the end of the branch corresponding to the first bus specified. Note that the following categories
generate two output channel assignments for each element selected for monitoring:
• Voltage & Angle

• Flow (P&Q)
• Relay2 (R & X)
• Machine apparent impedance
Activity CHAN summarizes the next available positions in the pertinent arrays as a result of its
current execution. The value of the solution parameter NCHAN, which indicates the highest
numbered channel being monitored during simulations (refer to activity ALTR and Section 18.6
Simulation Outputs), is set to NCHAN-1.
When activity CHAN is being used to change the channel assignments assigned to a subset of
previously generated assignments, the value printed for < NCHAN > is the larger of the original
next available channel and that which would be set as a result of the current execution of activity
15-33
CHAN. Consider, for example, the situation in which fifty output channels have been assigned and
are being monitored and the user wishes to change the quantity associated with channel ten.
Activity CHAN would be entered, a starting channel number of ten would be specified rather than
the default of fifty-one, and the appropriate channel assignment made. < NCHAN > would be fifty-
one, and hence NCHAN would retain its previous value of fifty.

As shown in the following data of activity CHAN’s output category selector designate quantities
associated with plant equipment models.
• Angle • Ecomp • Wind turbine speed

• Pelec • Vothsg • Wind pitch
• Qelec • Vref • Wind aerodynamic torque
• Eterm • Vuel • Wind rotor voltage
• EFD • Voel • Wind rotor current
• Pmech • Gref • Wind real power command from electrical control
• Speed • Lcref • Wind reactive power command from electrical control
• Xadifd • Wind velocity • Wind auxiliary control output
Pload and Qload designate the active and reactive load quantities associated with each load in the
network. In the PSS®E dynamics data structure, there are dedicated arrays containing each of
these quantities for each machine and load in the working case. These data items are automatically
calculated by the various equipment models used to model each machine and its controls and by
the various load characteristic models applied to loads in the network (refer to For CONET models
which are not coordinated call models (i.e., IC is zero and IT is either one or two), BUSID and IM
are both specified as zero. and 18.4.1). Activity CHAN simply sets up the appropriate address
pointers in the dynamics data array IPRINT so that the channel output routine picks up the proper
values.
Similarly, bus frequency deviation is stored in a dedicated array for each bus in the working case
and activity CHAN sets up the appropriate pointer. VARs and STATEs (categories nineteen and
twenty) are handled in the same way.
However, the following categories specify data items that are not readily accessible from the stan-
dard dynamics data arrays.
• Voltage • Flow (MVA)

• Voltage and Angle • Relay2 (R&X)
• Flow (P) • Machine terminal current
• Flow (P&Q) • Machine apparent impedance
For these quantities to be available as output channel variables, they must be calculated and placed
into a data array which can be accessed by the channel output routine. This function is performed
by a group of network monitoring models which calculate certain network quantities and place them
into specified locations in the VAR array.
15-34
Thus, when activity CHAN is programmed to place bus voltages, branch flows, branch apparent
impedances, machine currents and machine apparent impedances into output channels, it takes
the following steps:
1. It allocates positions in the ICON array and sets these elements to the values required to
designate the bus, branch or machine to be monitored.
2. It allocates positions in the VAR array which are to contain the monitored quantities.
3. It generates entries in the CHAN monitoring model tables for the appropriate model call
(VOLMAG, FLOW1, FLOW3, RELAY2, RELAY3, GENTMC or GENTMZ).
4. As with the other data categories, it establishes the appropriate IPRINT and IDENT array
entries.
During dynamic simulations, model calls corresponding to the model references contained in the
CHAN monitoring model tables are issued each time step at the completion of the network balance.
Thus, after being selected by activity CHAN, these network quantities are automatically calculated
during dynamic simulation runs and placed into output channels.
As activity CHAN assigns each selected simulation quantity to an output channel, it makes a corre-
sponding entry in a set of channel descriptor arrays. These arrays describe the type of quantity
assigned to the channel, and its location in the network in terms of external bus numbers and
machine, load and circuit identifiers (or in a dynamics data array in the case of categories nineteen
and twenty). These arrays are also used in describing the content of each channel in activities ALTR
and DLST.
This information is also used to reconcile differences in the PSS®E internal numbering scheme
which may exist when a Saved Case is retrieved for which internal storage of network quantities
differs from that which was contained in the working case during the execution of activity CHAN.
This reconciliation occurs at the execution of activities RSTR, SRRS, and section / RTRN whenever
both network and dynamics data have been read into PSS®E working memory. It also occurs
following network data changes via activity ALTR, and at the completion of the power flow data
edits.
When the value specified as the starting channel index exceeds the next available channel value
contained in dynamics working memory, the channels in this gap have their IPRINT, IDENT and
channel descriptor array entries set so as to leave the channel unused. Dynamic simulation quan-
tities may be assigned to such channels in subsequent executions of activity CHAN as described
earlier.
As in activity DYRE (refer to Section 15.1.3, Adding Models), the user should take care to take a
Snapshot following successful execution of activity CHAN and prior to terminating PSS®E. If a
Snapshot is not taken, the newly established IPRINT, IDENT, ICON and channel descriptor array
entries are not preserved and activity CHAN will need to be re-executed.
The user must exercise caution in specifying the starting VAR and ICON indices in response to the
input request issued by activity CHAN. In particular, the location indices specified and successive
locations in the respective arrays must not be used by other models. For simulation execution effi-
ciency, it is desirable that the locations specified be the next available slots in the respective data
arrays. Thus, the normal specification of these indices is to enter the default response.
As can be seen in the use of activity CHAN, as well as in the requirements of activities SNAP and
DYRE, it is strongly recommended that the next available position indices maintained within each
15-35
Snapshot be used whenever possible. PSS®E is able to perform the bookkeeping required for the
storage allocations assigned by activities DYRE, CHAN and CHSB. It is the user’s responsibility to
update these indices, with activity ALTR, whenever models or user written code utilizing additional
dynamics data array elements are manually added to the connection subroutines.

During its implementation, activity CHAN generates an alarm for errors resulting from the following
conditions:
1. A bus, machine, load or branch specified by the user is not in the working case. An appro-
priate error message is printed and the user re-specifies the equipment identifier(s).
2. In allocating an output channel, the preceding channel selection used the highest numbered
output channel for which PSS®E is currently dimensioned. The following error message is
printed and activity CHAN is terminated:
ALL CHANNELS USED

3. In selecting for output a quantity requiring a network monitoring model call, there are not
enough ICONs remaining to accommodate those required by the model call. The following
message is printed:
nnnn IS END OF ICON ARRAY

enough VARs remaining to accommodate those required by the model call. The following
message is printed:
nnnn IS END OF VAR ARRAY

5. In selecting for output a quantity requiring a network monitoring model call, the table accom-
modating the CHAN monitoring model references is full. The following message is printed:
nnnn MONITORING MODELS SPECIFIED--POINTER TABLE FULL

6. In placing a VAR or STATE in an output channel, a VAR or STATE number greater than the
largest for which PSS®E is currently dimensioned is specified. The following message is
printed:
nnnn IS END OF aaaaa ARRAY
PSS®E GUI Users Guide, Section 20.5.1, Simulation Variables
Section 17.2.1, Simulation Variables
15-36
Program Operation Manual Saving Dynamics Working Memory in a Binary File
15.3 Saving Dynamics Working Memory in a Binary File

Activity SNAP
Run Activity SNAP - GUI

File>Save…
[Save Dynamics Data]
Snapshot Data Tab
Run Line Mode Activity SNAP - CLI

ACTIVITY?
>>SNAP
ENTER SNAPSHOT FILENAME:
>>

None
The snapshot activity SNAP preserves the contents of dynamics working memory in a user speci-
fied Snapshot File. PSS®E optionally runs activity SNAP on completion of activity STRT.
The user specifies the name of the file in which the Snapshot is to be saved. If an asterisk (  ) is
specified as the name of the Snapshot file, the last Snapshot File accessed by either activity SNAP
or activity RSTR during the current session of PSS®E is used. Refer to Section 2.4.1 File Usage for
the file specification conventions and to Section 2.6 Files Created By PSS®E for the file overwriting
conventions used by activity SNAP.
When activity SNAP is run, output quantities are displayed for CONs, STATEs, VARs, ICONs, and
Channels. The user specifies the number of elements in the data arrays and the number of output
channels (refer to activity CHAN and Section 18.6 Simulation Outputs) to be written to the Snapshot
File. The displayed values reflect the next available position indices as maintained by activities
DYRE, CHAN, and CHSB (refer to For CONET models which are not coordinated call models (i.e.,
IC is zero and IT is either one or two), BUSID and IM are both specified as zero. and activities CHAN
and CHSB). When specifying other than the default values (i.e., the indices displayed), the number
specified for each of the above quantities should be at least as large as the number of elements in
use in the corresponding data arrays.
The contents of dynamics working memory are then written to the file, along with the current date
and time. The following message is printed at the user’s terminal and activity SNAP is terminated:
SNAPSHOT STORED IN FILE <filename> AT TIME = X.XXX

Activity SNAP records only the data arrays associated with the modeling of dynamic equipment; it
does not record any other data arrays describing the electric network as contained in the working
case. The user must, therefore, take careful note of the network model as contained in the working
case at the time the Snapshot is taken. It is generally advisable to use activity section / SAVE to
create a power flow Saved Case File corresponding exactly to each Snapshot.
15-37
Restoring Dynamics Working Memory from a Binary Snapshot File Program Operation Manual
A Snapshot in conjunction with the corresponding power flow Saved Case completely specifies the
instantaneous condition of the system at the time of their creation. It is strongly recommended that
the user always preserve and retrieve Snapshots and Saved Cases in coordinated pairs, making
careful note of which power flow Saved Case is associated with which Snapshot. The utilization of
some meaningful file naming convention can be very useful in this regard.
The most common application of Snapshots is to save a valid setup so that future runs from the
same network condition can be started without the need of re-executing activities DYRE, CHAN,
and so on (refer to Section 18.4 The Dynamic Model). The network condition associated with these
starting condition Snapshots is normally a converted base case power flow which is already saved.
Thus, all that is needed to be able to reestablish the network data arrays is to note the name of the
appropriate power flow Saved Case File. A Snapshot may also be taken within activity STRT for this
purpose of saving valid checked out initial conditions.
Another possible application is to preserve a dynamic simulation run for future running to an
extended value of TIME (refer to Restarting From a Snapshot). In this case, the network model is
likely to be significantly different from the base case, and it is necessary that the present condition
of the working case be saved immediately following execution of activity SNAP. When taking a mid-
run Snapshot, it is recommended that the user preserve the initial condition Snapshot by specifying
a different filename for the mid-run Snapshot.
Taking a Snapshot has no effect on the simulation and the user may proceed to any activity imme-
diately after completion of activity SNAP.
In specifying the number of elements to be saved in the Snapshot, the usual procedure is to respond
with the default (i.e., a carriage return). The next available position indices are maintained by activ-
ities DYRE, CHAN, and CHSB to record the utilization of storage for the model references
generated by these activities. These pointers are preserved with the Snapshot and are used to set
the default responses for activities SNAP, DYRE, CHAN, and CHSB.
For those applications in which models are manually added to a dynamics setup or user written
code in the connection subroutines utilizes additional locations in the dynamics data arrays, it is
strongly recommended that the user manually update these next available pointers via activity
ALTR. Subsequent executions of activities SNAP, CHAN, CHSB, and DYRE may then use, via the
default response, the pointers maintained with the Snapshot without the user having to remember
and enter these values.
The user is permitted to record portions of the dynamics data arrays beyond those currently in use
by overriding the default response. However, the practice of preserving large portions of these
arrays which are unused by the simulation is discouraged. Large amounts of disk space is unnec-
essarily used and the time required to write the Snapshot and subsequently restore it with activity
RSTR is increased.
PSS®E GUI Users Guide, Section 20.6, Saving Dynamics Working Memory in a Binary FIle
Section 17.3, Saving Dynamics Working Memory in a Binary File
15.4 Restoring Dynamics Working Memory from a Binary Snap-
15-38
Program Operation Manual Restoring Dynamics Working Memory from a Binary Snapshot File
shot File
Activity RSTR
Run Activity RSTR - GUI

File>Open…
[Open]
Dynamics Snapshot Data File (*.snp)
Run Line Mode Activity RSTR - CLI

ACTIVITY?
>>RSTR
ENTER SNAPSHOT FILENAME:
>>

None
The snapshot retrieval activity RSTR restores the dynamics data arrays contained in the specified
Snapshot File into dynamics working memory. The contents of working memory are overwritten
while the contents of the specified Snapshot File are unchanged.
The user specifies the name of the file in which the Snapshot is located. If an asterisk (  ) is spec-
ified as the name of the Snapshot file, the last Snapshot File accessed by either activity RSTR or
activity SNAP during the current session of PSS ®E is read into the working case. Refer to
Section 2.4.1 File Usage for the file specification conventions used by activity RSTR.
If the specified file is not in a Snapshot File format recognized by this release of PSS®E, an error
message is printed.
If the Snapshot exceeds the capacity limits of the size level of PSS®E currently installed in the
system, an error message is printed.
Generally, activity RSTR is able to access Snapshot Files filled by activity SNAP of the current and
previous releases of PSS®E. However, a Snapshot File written by the current version of PSS®E is
normally not able to be read by earlier releases of the program.
In restoring the output channel specification data, activity RSTR automatically updates the channel
addresses if the Snapshot was taken in a version of PSS®E of different dimensional capacity than
the one currently installed on the system.
In retrieving Snapshots created by PSS®E-16 through PSS®E-19, activity RSTR checks for the use
of the models STAB2 and GAST2; at PSS®E-20, these models were replaced by the models
STAB2A and GAST2A respectively. Activity RSTR deletes all references to the old models. The
replacement models, which have different storage requirements than their obsolete counterparts,
must be introduced into the simulation setup with activity DYRE. Upon encountering a reference to
either of these models, activity RSTR allows the user to specify a file into which it will place data
records for the new models; this file may subsequently be used as input (refer to Section 15.1.3,
Adding Models).
Following the reading of the dynamics data from the Snapshot File, if network data is contained in
the working case, the dynamics model table array pointers and output channel addresses are
15-39
Restoring Dynamics Working Memory from a Binary Snapshot File Program Operation Manual
updated to reflect the internal bus, machine, load, branch, and VSC dc line numbering of the
working case. The dynamic model table array pointers are also updated for two-terminal dc line,
multi-terminal dc line, and FACTS device to reflect if the corresponding device is present in the
working case.
Finally, the case heading read from the file is printed at the user’s terminal, along with the time and
date at which the Snapshot was written, and the number of elements in the dynamics data arrays
that were restored.
15.4.1 Restarting From a Snapshot

Because a Snapshot in conjunction with the corresponding power flow Saved Case completely
specifies the instantaneous condition of the system at the time they were written, a simulation run
may be restarted from a Snapshot and continued just as if it had never been halted.
As pointed out in Application Notes, network data is not saved with the dynamics data arrays in the
Snapshot File. Thus, to continue a simulation from mid-run Snapshot and Saved Case Files, it is
necessary to retrieve both the appropriate Snapshot and its corresponding power flow Saved
Case. The procedure is illustrated by example.
Consider a simulation run that has been stopped for intermediate examination, with the mid-run
Snapshot in the file temp.snp, the corresponding network in the Saved Case File temp.cnv, and
with the output of the simulation up to the snapshot TIME in the file case1.out. To continue the run,
the restart sequence of PSS®E activities is:
1. Enter PSS®E.
2. Restore the dynamics data with the activity command rstr,temp.snp.
3. Pick up the electrical network using the command case:
case,temp.cnv
4. Proceed with the simulation as if it were not interrupted (activities
or if, before continuing with the simulation, changes are to be made to ALTR the system condition
as restored into memory).
The name of the simulation output file, case1.out in this example, is retained in the Snapshot along
with a file position pointer for the output file. Thus, when restarting from an intermediate point Snap-
shot, the output from the continuation of the run is appended onto the output contained in the output
file, and so the output file should not be changed. It should not have been used for any other
purpose (except for examination with the channel output file processing program) after the simula-
tion was halted and the Snapshot taken.
When the Snapshot contains an initial condition (i.e., it was written in activity STRT), the user does
not need to re-execute activity STRT. However, the user should check, with activity ALTR, that the
simulation output file, as specified in the Snapshot, is the desired output file. If not, an output file
may be established by specifying the appropriate filename in activity ALTR. In this situation, it is still
advisable to execute activity STRT before proceeding with the simulation because this allows for:
15-40
Program Operation ManualRestoring Dynamics Working Memory from a Snapshot File Created in
1. A cross check of dynamics and network data to ensure proper correspondence of the Snap-
shot and Saved Case Files.
2. Specifying a new simulation output file and having it initialized with the output channel head-
ings without having to go through activity ALTR.

If implementing the supplemental file for STAB2A / GAST2A models optionally constructed by
activity RSTR, note that GAST2A requires one more data item than did GAST2. The user should
edit the data file to add the value of TC to each GAST2A data record. The STAB2A data records
may be used without change.
Section 20.2, Restoring Dynamics Working Memory from a Binary Snapshot File
Section 17.4, Restoring Dynamics Working Memory from a Binary Snapshot File
15.5 Restoring Dynamics Working Memory from a Snapshot File

Created in PSS®E-26 or Earlier
Activity SRRS
Run Activity SRRS - GUI

File>Open…
[Open]
Dynamics Snapshot Raw Data File (*.srs)
Run Line Mode Activity SRRS - CLI

ACTIVITY?
>>SRRS
ENTER SOURCE FORM SNAPSHOT FILENAME:
>>

None
The Dynamics Snapshot Raw Data File retrieval activity SRRS restores the dynamics data arrays
contained in the specified Dynamics Snapshot Raw Data File into dynamics working memory. The
contents of working memory are overwritten while the contents of the specified Snapshot File are
unchanged. Source snapshots could only be created prior to PSS®E-27.
15-41
®
Restoring Dynamics Working Memory from a Snapshot File Created in PSS E-26 or Earlier Pro-
The user specifies the name of the file in which the Snapshot is located. If no file is specified, or a
file system error condition is encountered in opening the designated file, or the specified file is not
in Source Form Snapshot File format, an appropriate error message is displayed.
If the number of CONs, ICONs or output channels contained in the Snapshot File exceeds the
capacity limits of the size level of PSS®E currently installed in the system, an appropriate error
message is displayed along with sizing information, and activity SRRS is terminated. Similarly, if
any of the next available position pointers specified in the Snapshot File exceed the capacity limits
of the size level of PSS®E currently installed, an appropriate error message is displayed.
In retrieving Source Form Snapshots created by PSS®E-16 through PSS®E-19, activity SRRS
checks for the use of the models STAB2 and GAST2; at PSS®E-20, these models were replaced
by the models STAB2A and GAST2A respectively. Activity SRRS deletes all references to the old
models. The replacement models, which have different storage requirements than their obsolete
counterparts, must be introduced into the simulation setup with activity DYRE. Upon encountering
a reference to either of these models, activity SRRS allows the user to specify a file into which it will
place data records for the new models; this file may subsequently be used as input (refer to Adding
Models).
Following the reading of the dynamics data from the Snapshot File, the case heading as read in
from the file is printed at the user’s terminal, along with the time and date at which the Snapshot
was written, and the number of elements in the dynamics data arrays which were restored.
Prior to terminating, activity SRRS gives the user the option of generating a file for the compiling of
the connection subroutines, CONEC and CONET. (These were presumably obtained from the
same party as the Source Form Snapshot which was just read by activity SRRS.)
When a filename is specified, activity SRRS creates a file which, when executed at operating
system level, compiles the CONEC and/or CONET subroutines which are contained in the files
specified. The use of this feature is strongly encouraged because it guarantees the correct specifi-
cation of compiler option settings in compiling these subroutines.
Refer to Section 2.4.1 File Usage for the file specification conventions used by activity SRRS.

The file specified in invoking activity SRRS must be in the format of a Source Form Snapshot File;
that is, it must have been written by activity SRSN, which was available prior to PSS®E-27.
Activity SRRS requires that the network corresponding to the Source Form Snapshot File to be read
be present in the working case at the time activity SRRS is selected.
In restoring the output channel specification data, activity SRRS automatically updates the channel
addresses if the Snapshot was taken in a version of PSS®E of different dimensional capacity than
the one currently installed on the system.
If implementing the supplemental file for STAB2A / GAST2A models optionally constructed by
activity RSTR, note that GAST2A requires one more data item than did GAST2. The user should
edit the data file to add the value of TC to each GAST2A data record. The STAB2A data records
may be used without change.
A change in the Source Form Snapshot File data defining the system variables assigned to output
channels occurred between releases eight and nine of PSS®E. Therefore, when one of the parties
is using release eight of PSS®E while the other is running release nine or above, it is strongly
15-42
Program Operation Manual Modifying Data in Dynamics Working Memory
recommended that the output of activity DMPC be included in the transmittal of dynamic simulation
setups. This Response File may then be used to override the output channels specified in the
Source Form Snapshot File after it has been restored.
Section 20.3, Restoring Dynamics Working Memory from a Binary Snapshot File Created in PSS®E-26
or Earlier
®
Section 17.5, Restoring Dynamics Working Memory from a Snapshot File Created in PSS®E-26 or
Earlier
15.6 Modifying Data in Dynamics Working Memory

Activity ALTR
Run Activity ALTR - GUI

Dynamics [spreadsheet]
Run Line Mode Activity ALTR - CLI

ACTIVITY?
>>ALTR
ENTER CHANGE CODE:

None
The dynamics data change activity ALTR allows the user to examine and make changes to the
values of data items contained in dynamics data working memory. When using line mode, it also
provides for the specification of network data changes through an automatic link to the power flow
activities section / CASE, section / CHNG, section / ORDR, and section / FACT; using the GUI, a
new Saved Case may be picked up, but access to activity CHNG is not provided.
PSS®E GUI Users Guide, Section 20.8, Modifying Data in Dynamics Working Memory
Section 17.6, Modifying Data in Dynamics Working Memory
15-43
Modifying Dynamics Model Pointer Tables Program Operation Manual
15.7 Modifying Dynamics Model Pointer Tables

Activity DYCH
Run Activity DYCH - GUI

Dynamics>Model maintenance…
[Model Maintenance]
Run Line Mode Activity DYCH - CLI

ACTIVITY?
>>DYCH

None
The table driven data table maintenance activity DYCH allows the user to interrogate and modify
the data array entries used in associating plant related equipment models with machines repre-
sented in the working case.
Activity DYCH first displays table utilization, the number of current entries and the maximum allow-
able number of entries, for the following dynamic tables:
Table 15-3. Dynamic Tables

Table Description
Each entry is associated with a specific machine. Normally, there are as many entries
in this table as there are machines in the working case. However, when the working
case differs topologically from that which was present when the simulation model data
Model Connection
was read into PSS®E, this may not be the case. For dynamic simulation calculations,
Table
each in-service machine in the power flow must have a model connection table entry.
The model connection table entry for a machine contains pointers to the array alloca-
tion table entries assigned to that machine.
Each entry is associated with a single model reference. It defines the specific model
being used along with the starting indices in the dynamics data storage arrays
Array Allocation Table assigned to that model call (refer to Section 18.1.2 Data Structure). Normally, there
are as many entries in this table as there are plant-related model references in the
simulation setup.
One entry appears for each user-written model 'model name' that was defined during
User Model Definition the construction of the dynamic simulation setup (refer to User-Written Models), and
Table which is called from internal PSS®E tables. User-written models which are called from
CONEC or CONET do not have entries in the user model definition table.
Contains an entry for each network monitoring model reference generated through
Activity CHAN Moni- activities CHAN
toring Model Table andCHSB
.
A function selector provides access to the tables. Some selections may be limited to specific
models: load, plant, wind, relay, auxiliary signal, FACTS device, dc line, or switched shunt models.
15-44
Program Operation Manual Modifying Dynamics Model Pointer Tables
The user may select from the following options, one at a time:
• List unconnected models

• Remove unconnected models
• Pack models
• List user models
• Remove unused user models
• Consistency check (plant and wind models only)
The following sections describe each of the above functions.
15.7.1 List Unconnected Models

The unconnected model listing function lists those model connection table entries for which the
corresponding machine is not contained in the working case as in the following example:
PLANT RELATED MODELS WITH NO MACHINE IN LOAD FLOW:

MACH GEN. COMP. STAB. MINEXL MAXEXL EXC. GOV. TLC
1 GENROU -- -- -- -- IEEET1 *TGOV1 ---
15.7.2 Remove Unconnected Models

The unconnected model removal function marks as unused those model connection table entries
for which the corresponding machine is not contained in the working case. The corresponding array
allocation table entries are also marked as unused. Each model reference removed from the model
tables is reported at the Progress tab.
15.7.3 Pack Tables

The table packing function removes gaps (i.e., entries which are marked as unused) from the model
connection table and the array allocation table. If either of these tables are packed, messages are
printed at the Progress tab as in the following example:
PLANT MODEL TABLES UPDATED:

OLD NEW MAXIMUM
CONNECTIONS FROM MACHINES TO MODELS: 6 5 33050
POINTERS FROM MODELS TO DATA: 17 13 66100
15.7.4 List User Models

The list user model definitions function prints the user model definition table which reflects the
definition information specified to DYRE on the USRMDL data records of plant-related user-written
models (refer to User-Written Models). The data printed for each model definition includes its
name, the type of model, the number of locations required in the data storage arrays for each
reference of the model, and the number of references of the model (i.e., the number of machines
at which it is called). The report also indicates if a model is a coordinated call model (e.g., an SVS)
or a two machine model (i.e., a cross-compound governor model).
15.7.5 Remove Unused User Models

The unused model definition removal function deletes from the user model definition table any
model definitions which are no longer referenced from the array allocation table. Vacated slots are
15-45
available to activity DYRE, ADD for new model definitions.
15.7.6 Consistency Check

The consistency checking function loops through all machines in the working case and generates
an alarm for any invalid model combinations. This report is in ascending bus number order when
the numbers output option is in effect, and in alphabetical bus name order using the names option.
For any alarm messages printed by activity DYCH for a given machine, a heading line identifies the
bus and machine being processed. The following conditions generate an alarm:
1. No generator model specified for a machine. The following error message is printed:
NO GENERATOR MODEL. MACHINE STATUS IS IN (or OUT)

The remaining model combination checks in (2) through (12) below are bypassed. In
executing dynamic simulation calculations, all in-service machines must have an active
generator model assigned to them.
2. The generator model reference is bypassed (refer to Section 15.7.8, Change Model Status).
The following message is printed:
GENERATOR MODEL BYPASSED. MACHINE STATUS IS IN (or OUT)

The remaining model combination checks in (3) through (12) below are bypassed. In
executing dynamic simulation calculations, all in-service machines must have an active
generator model assigned to them.
3. At a machine with active generator and exciter models (i.e., neither model is bypassed; refer
to Change Model Status), the generator model does not allow an excitation system model.
The following error message is printed:
EXCITER MODEL NOT ALLOWED WITH GENERATOR MODEL name

An excitation system is not permitted in combination with the classical generator model
GENCLS, with the static shunt compensator models CSVGN1, CSVGN3, CSVGN4,
CSVGN5 and CSVGN6, with the induction machine models CIMTR1, CIMTR2,
CIMTR3 and CIMTR4, with the DSMES model CDSMS1, or with CBEST, CSMEST
and CSTATT models.
4. At a machine with active generator and stabilizer models, the generator model does not
allow a stabilizer model. The following error message is printed:
STABILIZER MODEL NOT ALLOWED WITH GENERATOR MODEL name

A stabilizer model is not permitted in conjunction with the classical generator model
GENCLS, with the induction machine models CIMTR1, CIMTR2, CIMTR3 and
CIMTR4, with the DSMES model CDSMS1, or with CBEST, CSMEST and CSTATT
models.
5. At a machine with active generator and stabilizer models, a power sensitive stabilizer model
is used in combination with a static var system model. The following error -message is
printed:
STABILIZER MODEL name NOT ALLOWED WITH SVS MODEL name

The stabilizer models STAB2A, STAB3, STAB4, STABNI, IVOST, PTIST1 and PTIST3
are not permitted as supplementary signal models for the static shunt compensator
15-46
models CSVGN1, CSVGN3, CSVGN4, CSVGN5 and CSVGN6; the STAB1, IEEEST,
IEE2ST, PSS2A, ST2CUT and STBSVC models or user-written stabilizer models may
be used.
6. At a machine with active generator and stabilizer models, the generator model is not a static
var system model and either there is no excitation system referenced or the exciter model
is bypassed (refer to ). The following error message is printed:
STABILIZER MODEL REQUIRES EXCITATION SYSTEM MODEL

7. At a machine with active generator, stabilizer and exciter models, the generator model is not
a static var system model and the excitation system model does not allow a supplementary
signal. The following error message is printed:
STABILIZER MODEL NOT ALLOWED WITH EXCITER MODEL name

A stabilizer model is not permitted in conjunction with the IEEET4, IEEET5, IEET5A,
IEEEX4 and EXELI excitation system models.
8. At a machine with active generator and excitation limiter models, the generator model does
not allow an excitation limiter model. The following error message is printed:
EXCITATION LIMITER MODEL NOT ALLOWED WITH GENERATOR MODEL name

An excitation limiter model is not permitted in conjunction with the classical generator
model GENCLS, with the static shunt compensator models CSVGN1, CSVGN3,
CSVGN4, CS-VGN5 and CSVGN6, with the induction machine models CIMTR1,
CIMTR2, CIMTR3 and CIMTR4, with the DSMES model CDSMS1, or with CBEST,
CSMEST and CSTATT models.
9. At a machine with active generator and excitation limiter models, either there is no excitation
system referenced or the exciter model is bypassed (refer to Section 15.7.8, Change Model
Status). The following error message is printed:
EXCITATION LIMITER MODEL REQUIRES EXCITATION SYSTEM MODEL

10. At a machine with active generator, excitation limiter and exciter models, the excitation
system model does not allow a supplementary signal. The following error message is
printed:
EXCITATION LIMITER MODEL NOT ALLOWED WITH EXCITER MODEL name

An excitation limiter model is not permitted in conjunction with the IEEET4, IEEET5,
IEET5A, IEEEX4 and EXELI excitation system models.
11. At a machine with active generator and turbine-governor models, the generator model does
not allow a governor model. The following error message is printed:
GOVERNOR MODEL NOT ALLOWED WITH GENERATOR MODEL name

A turbine governor model is not permitted in conjunction with the classical generator
model GENCLS, the static shunt compensator models CSVGN1, CSVGN3, CSVGN4,
CSVGN5 and CSVGN6, the salient pole frequency changer model FRECHG, with the
DSMES model CDSMS1, or with CBEST, CSMEST and CSTATT models.
12. At a machine with active generator and turbine-governor models, the torsional shaft model
SHAF25 is used in combination with a generator model other than GENDCO. The following
error message is printed:
15-47
SHAF25 MODEL REQUIRES GENDCO GENERATOR MODEL

13. One machine of an active two-machine PSS®E Library model is not in the working case.
The following error message is printed:
MODEL name--OTHER MACHINE NOT IN CASE: MACHINE i BUS nnn

The following sections describe functions available in line mode only.
15.7.7 List Plant Models

The list model references function tabulates the plant related model references for all machines at
selected buses. Activity DYCH instructs the user to select the bus for which output is desired. Buses
are entered one at a time and the report is printed following the user specification of the bus. Then
the request for a bus selection is repeated. A response of zero to the bus selection request termi-
nates the listing function of activity DYCH.
The report of the listing function is as shown in the following example:
PLANT RELATED MODELS AT BUS 101 [NUC-A 21.600]:

MACH GEN. COMP. STAB. MINEXL MAXEXL EXC. GOV. TLC
1 GENROU -- -- -- -- IEEET1 *TGOV1 ---
For any model reference which is bypassed (refer to Section 15.7.8, Change Model Status), the
model name is preceded by an asterisk (  ).
15.7.8 Change Model Status

The model status modification function allows individual models to be characterized as either
active or bypassed. Activity DYCH instructs the user to select the bus where plant related models
are to be listed and, possibly, have their status changed. Buses are entered one at a time and
activity DYCH cycles through the machines connected to the bus in ascending machine identifier
order.
First, the model names are listed as described in Section 15.7.7, List Plant Models. Then the
consistency checks given in Section 15.7.6, Consistency Check are performed and any error or
warning messages are printed. Finally, the user may toggle the status of any of the models at the
machine as in the following example:
MODEL CODES FOR MACHINE 1 AT BUS 101 [NUC-A 21.600] ARE:
1 FOR GENROU
6 FOR IEEET1
7 FOR *TGOV1
ENTER CODE OF MODEL TO BE SWITCHED (0 FOR NO MORE):
Following the entry of a valid model code, the model status is changed followed by the printing of a
new model name listing and code menu. This process is repeated until a zero or carriage return is
entered in response to the above request. The consistency checks are then again performed, and
the next machine at the selected bus is processed.
After all machines at the bus have been processed, the request for a bus selection is repeated. A
response of zero to the bus selection request terminates the status changing function of activity
DYCH.
15-48
15.7.9 Remove Plant Models

The model removal function allows individual models at a machine to be removed from the model
connection table entry for the machine, and the corresponding array allocation table entry to be
marked as unused. Activity DYCH instructs the user to select the bus where plant related models
are to be listed and, possibly, removed. Buses are entered one at a time and activity DYCH cycles
through the machines connected to the bus in ascending machine identifier order.
First, the model names are listed as described in Section 15.7.7, List Plant Models. Then the
consistency checks given in Section 15.7.6, Consistency Check are performed and any error or
warning messages are printed. Finally, the user may remove the pointer to any of the models at
the machine as in the following example:
MODEL CODES FOR MACHINE 1 AT BUS 101 [NUC-A 21.600] ARE:
1 FOR GENROU
6 FOR IEEET1
7 FOR *TGOV1
ENTER CODE OF MODEL TO BE REMOVED (0 FOR NO MORE):
Following the entry of a valid model code, the appropriate model pointer is removed from the
model connection table and a confirming message is printed at the Progress tab. This is followed
by the printing of an updated model name listing and code menu. This process is repeated until a
zero or carriage return is entered in response to the above request. The consistency checks are
then again performed, and the next machine at the selected bus is processed.
After all machines at the bus have been processed, the request for a bus selection is repeated. A
response of zero to the bus selection request terminates the model removal function of activity
DYCH.
Note that the blocks of storage locations in the data storage arrays that were allocated to a model
which is removed are available to the user. They are not, however, automatically reused by
activities DYRE, ADD, CHAN, or CHSB.
15.7.10 List CHAN Models

The activity CHAN model listing function lists those monitoring model references which were
generated as a result of the execution of activities CHAN and CHSB (refer to Section 15.2.2,
Application Notes When activity CHAN is being used to change the channel assignments assigned
to a subset of previously generated assignments, the value printed for < NCHAN > is the larger of
the original next available channel and that which would be set as a result of the current execution
of activity CHAN. Consider, for example, the situation in which fifty output channels have been
assigned and are being monitored and the user wishes to change the quantity associated with
channel ten. Activity CHAN would be entered, a starting channel number of ten would be specified
rather than the default of fifty-one, and the appropriate channel assignment made. < NCHAN >
would be fifty-one, and hence NCHAN would retain its previous value of fifty. and Section 15.25.2,
Application Notes). This tabulation includes the model name, the type of quantity calculated by the
model, the bus, machine, branch or subsystem at which it is called, and the starting ICON and
VAR indices used.
When this function is selected, the user is instructed to:
SELECT CHAN MODELS TO LIST:
0 = ALL
1 = THOSE MONITORING EQUIPMENT IN POWER FLOW
15-49
Linking to Power Flow Activities from Dynamic Simulation Program Operation Manual
2 = THOSE AT EQUIPMENT NOT FOUND IN POWER FLOW

ENTER SELECTION CODE:
If a two is entered, only models for which the corresponding bus, branch or machine is not contained
in the working case are listed. If a one is entered, only models for which the monitored element
exists in the working case are listed. If a zero is entered, all CHAN model calls are tabulated.
15.7.11 Remove Unused CHAN Models

The unused activity CHAN model removal function deletes network monitoring references for
which the monitored element is not contained in the working case. Each deleted model reference
is listed using the same format as in the CHAN model listing function (refer to List CHAN Models).
The CHAN monitoring model table is then packed so as to remove gaps in the numeric sequence.
Note that, while deleted CHAN model table entries are available to subsequent executions of
activities CHAN and CHSB, the ICON, VAR and output channel entries which are released are not
automatically made available for reuse.
PSS®E GUI Users Guide, Section 20.9, Modifying Dynamics Model Pointer Tables
Section 17.7, Modifying Dynamics Model Pointer Tables
15.8 Linking to Power Flow Activities from Dynamic Simulation

Activity LOFL
Run Line Mode Activity LOFL - CLI

ACTIVITY?
>>LOFL

None
Note: Starting with PSS®E-31, mode switching is not apparent to the user and is retained only for
backwards compatibility.
The power flow link activity LOFL allows the user to execute any power flow activity after having
been operating in dynamics mode.
Activity LOFL is used primarily to:
1. Set up the working case to correspond to the starting condition for a dynamic simulation run.
The activity sequence to be used to set up the initial condition power flow case is:
a. Link to Power Flow Activities from Dynamic Simulation (LOFL)

b. Retrieve a Power Flow Saved Case File (CASE) <file>
15-50
Program Operation Manual Linking to Power Flow Activities from Dynamic Simulation
c. Return to Dynamic Simulation (RTRN)

where <file> is the name of the Saved Case File containing the initial condition converted
power flow case (refer to Section 18.3 The Network Model).
2. Allow examination of the network conditions existing at any instant during the system distur-
bance being simulated. When run during a state-space or extended term dynamic
simulation calculation, activity LOFL sets the plant and machine power output arrays in the
working case to correspond to those contained in the dynamics data arrays PELEC and
QELEC. Thus, the machine powers at that point in the simulation will be recognized in any
power flow reporting activities which are executed while the power flow linkage is in effect.
When examining network conditions during a dynamics run, any of the power flow reporting
activities may be used. However, these activities, in particular activities such as section /
POUT and section / LOUT, do not have a knowledge of any load-related models or other
non-plant boundary condition models that might be active in the simulation; they only recog-
nize the standard power flow load characteristics (refer to Section 6.3.13 Load). Thus, if -
network frequency dependence, algebraic load models such as IEELAR, or equipment
such as saturable reactors are being modeled, mismatches will occur at the buses involved.
These mismatches represent the power variation due to these models at the present instant
of the simulation.
When examining network conditions during a dynamics run, the user should exercise
caution in executing any power flow activity which modifies the working case unless a
system disturbance or re-initialization of the dynamic simulation is intended. Reporting
activities may be executed without risk of disturbing the dynamic simulation; all other activ-
ities, particularly activities section / CASE, section / CHNG, and all other activities which
affect the content of the working case, should be used with great care during a simulation
run.
While the power flow linkage is in effect, dynamics working memory is preserved.
Activity LOFL itself is not sensitive to any interrupt control code options. However, any power flow
activity run while the power flow linkage is in effect is sensitive to the same interrupt control code to
which it responds in normal power flow work.
®
Section 20.2.2, Linking to Power Flow Activities from Dynamic Simulation
15-51
Initializing Models for State-Space Simulation Program Operation Manual
15.9 Initializing Models for State-Space Simulation

Activity STRT
Run Activity STRT - GUI

Dynamics>Simulation>Perform simulation (STRT/RUN)…
[Perform Dynamic Simulation]
Run Line Mode Activity STRT - CLI

ACTIVITY?
>>STRT
ENTER CHANNEL OUTPUT FILENAME:
>>

AB, CM, NC, MO
The state-space dynamic simulation initialization activity STRT calculates the initial values of all
variables for each equipment model as a function of the model’s constant data and the boundary
condition at the bus in the working case at which it is referenced. Thus, for a valid execution of
activity STRT, dynamics data must be present in dynamics data working memory and the converted
network must be represented in the working case. The normal activity sequence which precedes
activity STRT is:
1. Restore Dynamics Working Memory from a Binary Snapshot File (RSTR) <file1>
2. Retrieve a Power Flow Saved Case File (CASE) <file2>
where <file1> is the Snapshot File containing the appropriate dynamics model data and output
channel specifications, and < file2 > is the Saved Case File containing the converted power flow
case.
When run, activity STRT generates an alarm and terminates if generators are not converted. It then
ensures that the machine power arrays in the power flow working case are set to their original initial
condition values (they may have been changed by a prior execution of activity STRT or MSTR).
Activity STRT completes its setup phase by checking for the presence of the factorized network
admittance matrix. If necessary, activity FACT (or activities section / ORDR and section / FACT) is
executed.
Activity STRT initializes the dynamic simulation by first doing a network solution and then, based
on the bus boundary conditions, initializing the state variables (STATEs) and algebraic variables
(VARs) of each equipment model. If, in setting up for the initial network solution, any CIMTR5,
CIMWSC, CIM5xx, CIMWxx, CLODxx, or IEELxx model removes constant admittance load from
the load at which it is called, an appropriate message is printed and the network admittance matrix
is automatically refactorized prior to commencing the network solution.
Any machine which is online in the working case but which does not have a generator model
assigned to it generates an alarm with a message of the form:
NO ACTIVE GENERATOR MODEL CALL FOR MACHINE i AT BUS nnnn
15-52
Program Operation Manual Initializing Models for State-Space Simulation
The source current (ISORCE) of any such machine is set to zero. The presence of any such
machines renders the initial condition invalid, and activity RUN will not allow itself to be executed
following such an initialization.
Similarly, any two-terminal, multi-terminal, or VSC dc line, any FACTS device, or any switched shunt
device that is under continuous control which is in-service in the working case but which does not
have a dynamic table model assigned to it generates an alarm with one of the following error
messages:
NO ACTIVE TABLE MODEL CALL FOR TWO-TERMINAL DC LINE "name"

PLEASE ENSURE THAT THIS EQUIPMENT HAS A MODEL CALL IN CONEC
NO ACTIVE TABLE MODEL CALL FOR MULTI-TERMINAL DC LINE "name"
NO ACTIVE TABLE MODEL CALL FOR VSC DC LINE "name"
NO ACTIVE TABLE MODEL CALL FOR FACTS DEVICE "name"
NO ACTIVE TABLE MODEL CALL FOR SWITCHED SHUNT AT BUS "bus name"
During the model initialization process, any model variable which is initialized beyond its prescribed
limits (e.g., the voltage regulator output, STATE(K+1), of the IEEE type one excitation system
model, IEEET1) is alarmed with a message of the form:
name AT BUS nnnn MACHINE i INITIALIZED OUT OF LIMITS

where < name > is the model name (e.g., IEEET1), < nnnn > is the bus number, and < i > is the
machine identifier of the model containing the out-of-limits variable. The user should resolve any
such error conditions before running a simulation.
Activity STRT then prints, at the progress report output device, the case heading followed by the
message:
INITIAL CONDITION LOAD FLOW USED n ITERATIONS

A value of < n > greater than one usually (but not always) indicates some sort of modeling error.
Similarly, any two-terminal, multi-terminal, or VSC dc line, any FACTS device, or any switched shunt
device that is under continuous control which is in-service in the working case but which does not
have a dynamic table model assigned to it generates an alarm. The presence of any such dc line,
FACTS or switched shunt device could indicate one of the following:
• A table model was assigned to the dc line, FACTS device or the switched shunt, but
the model was later removed. When this condition is detected during activity STRT,
activity RUN will not allow itself to be executed for dc lines and FACTS devices. In the
case of switched shunts, RUN will still be allowed, because the simulation will use the
power flow value of shunt in the admittance matrix.
• No table model was ever assigned to the dc line, FACTS, or the switched shunt device,
or that the model assigned is a CONEC and CONET called model. When this condition
is detected during activity STRT, activity RUN
will allow itself to be executed.
15-53
limits (e.g., the voltage regulator output, STATE(K+1), of the IEEE Type 1 excitation system model,
IEEET1) generates an alarm. The user should resolve any such error conditions before running a
simulation. The presence of such error alarms renders the initial condition invalid in the sense that
the system is not in a steady state; that is, if activity STRT were to be followed by activity RUN with
no disturbances imposed, there would be movement as the out-of-limits quantities are brought back
to their appropriate limits. The exception is the condition where the bus boundary conditions are
such that the variable in question is initialized exactly at its limit. Such a situation may occur, for
example, when a generator is fully loaded and its turbine mechanical power initializes precisely at
its ceiling.
Activity STRT then prints, at the Progress tab, the case heading followed by the number of itera-
tions used to calculate the initial power flow. A value greater than one usually (but not always)
indicates some sort of modeling error. This is especially true if the converted power flow network
was solved with activity TYSL prior to the execution of activity STRT. (The network solution method
used in the dynamic simulation is identical to that used by activity TYSL, and the default conver-
gence tolerance is an order of magnitude smaller in section / TYSL.)
The most common causes of this type of error are:
1. No dynamics model corresponding to an in-service dc line or FACTS device in the working

case.
2. Forgetting to compile the connection subroutines following a change to these subroutines,

or forgetting to relink following a recompilation of one of these subroutines.
The types of errors described above and all other initialization errors and warnings should be
resolved before executing simulations.
Activity STRT summarizes the conditions at each online machine by tabulating the following
quantities:
• Terminal voltage (ETERM).

• Exciter output voltage (EFD).
• Active and reactive power output (PELEC and QELEC).
• Power factor.
• Machine angle in degrees (ANGLE).
• d and q axis currents on machine base.
This report is in ascending bus number order when the numbers output option is in effect, and in
alphabetical bus name order using the names option. Note that for wind machines, because the
quantity EFD is not of any relevance, this is set to zero.
Following the calculation of the system initial condition, a dummy step calculation is made and the
time derivatives (DSTATEs) of all STATE variables are checked for a steady state. Any STATE for
which the time derivative is nonzero generates an alarm (nonzero as used here is interpreted as
significantly different from zero in relation to the value of the STATE). For any such STATE variable,
its index is printed along with the values of its time derivative and the STATE variable itself. For
STATEs that generated an alarm that are assigned to plant-related or wind-machine related models,
the model and machine are also identified. For STATEs that generated an alarm that are assigned
to load-related models, the model and load are also identified. For STATEs that generated an alarm
that are assigned to auxiliary-signal models, the model and the name of the device (the two-
terminal, multi-terminal or VSC dc line or the FACTS device) with which the auxiliary-signal is asso-
15-54
Program Operation Manual Initializing Models for State-Space Simulation
ciated are identified. For STATEs that generated an alarm that are assigned to dc line models, the
model and dc line are identified. For STATEs that generated an alarm that are assigned to FACTS
device models, the model and FACTS device are identified. For STATEs that generated an alarm
that are assigned to dc line models, the model and dc line are identified. For STATEs that generated
an alarm that are assigned to switched shunt models, the model and switched shunt device are
identified.
In each case, the ac bus is also identified. In the case of machines, loads, and switched shunts, this
will be the ac bus at which the machine, load or the switched shunt are connected; for two-terminal
dc lines, VSC dc lines, as well as for auxiliary signals attached to these devices, this is the rectifier
ac bus; for multi-terminal dc lines and for auxiliary signals attached to multi-terminal dc lines, this
will be the ac bus associated with converter number one; for FACTS devices and for auxiliary
signals attached to FACTS devices this will be the sending end ac bus.
If no nonzero STATEs are found, activity STRT outputs a message. The absence of suspect initial
conditions generally (though not always) indicates a valid steady state. Conversely, the presence
of initial condition alarms usually indicates some error in setup.
The same types of procedural errors which cause the initial network solution to use more than one
iteration may also result in nonsteady STATEs. In addition, the following situations may cause these
errors:
1. Model variables initialized out of limits. When this occurs, the STATE variable downstream
of the limit violation may also show some perturbation.
2. STATE variables characterized by a high gain and a short time constant. This often occurs
in the voltage regulator transfer function (e.g., a gain of four hundred and a time constant of
0.05 seconds). This can usually be accepted if the value of the derivative is small relative to
the value of the STATE (say, two or three percent).
3. Improperly specified data (e.g., zero time constants where they are not allowed, unrealistic
limits, etc.).
The user specifies the name of the Channel Output File to be used in the subsequent dynamic simu-
lation run. If no filename is specified in response to the above instruction, the writing of the output
channel variable values to a file is suppressed during the simulation run.
The user must specify a Dynamics Snapshot Data File to preserve the initial system condition, as
contained in the dynamics data arrays. If no filename is specified, activity STRT is terminated. If a
Snapshot File name is specified, a Snapshot is taken prior to terminating activity STRT.
Refer to Section 2.4.1 File Usage for the file specification conventions used by activity STRT.
The default time step in PSS®E is half a cycle (i.e., 0.008333 of a second when base frequency is
sixty cycles and 0.01 of a second for fifty cycle systems). Activity STRT sets the value of simulation
TIME to minus two time steps. This provides for a period of simulation under steady-state conditions
prior to initiating a disturbance.
The user may specify that the network solution convergence monitor be automatically printed. This
is particularly useful when PSS®E is being executed as a batch job.
15-55
Activity STRT responds to the following interrupt control codes:
(1) Suppress machine initial conditions summary.

AB (2) Suppress suspect initial conditions summary.
Suppress network convergence monitor when the CM suffix was specified in selecting activity
NC
STRT.
The format of the network convergence monitor is the same as that of activities section / TYSL and
section / SOLV.
In the induction motor model CMOTOR and the complex load models CLOAD and CLODxx, a local
iteration is used to solve for the equivalent load drawn by the model at each iteration of the network
solution.
The CMOTOR convergence monitor tabulates the bus number at which the model is being called,
the local iteration number, and the ratio of the change in motor slip to its convergence tolerance of
0.00001.
The CLOAD and CLODxx convergence monitor tabulates the bus number at which the model is
being called, the local iteration number, the voltage magnitude at the low side bus, the change in
voltage magnitude, and the complex voltage at the low side bus. Preceding each such local iteration
monitor line, the inner loop convergence monitors of the large and small motors (listed as motors
one and two respectively) are printed. These contain the motor number, the inner loop iteration
number, the motor slip, and the ratio of the change in slip to its convergence tolerance of one-tenth
of the network solution convergence tolerance.
PSS®E GUI Users Guide, Section 21.3, Running State-Space Simulation
Section 18.1, Initializing Models for State-Space Simulation
15-56
Program Operation Manual Performing State-Space Simulation in Time Steps
15.10 Performing State-Space Simulation in Time Steps

Activity RUN
Run Activity RUN - GUI

Dynamics>Simulation>Perform simulation (STRT/RUN)…
[Perform Dynamic Simulation]
Run Line Mode Activity RUN - CLI

ACTIVITY?
>>RUN
AT TIME = 0.017 ENTER TPAUSE, NPRT, NPLT, CRTPLT:
>>

AB, CM, NC, MO, CH, TI
The state-space time simulation activity RUN sequences through time solving the system’s
differential equations and the electrical network at each time step. When run, activity RUN
generates an alarm and terminates if activity STRT had not previously been successfully executed
or if generators are not converted.
The user specifies the following simulation options:
Run to n.nnnn secs : the value of simulated TIME at which the simulation activity is to
be terminated.
TPAUSE
Activity RUN steps through time simulating the system, starting at the present value of simula-
tion TIME, until TIME > TPAUSE.
Print every <n> time steps: integer value defining the interval, in units of the number of
simulation time steps, between the recording of output channel values. This setting is
recorded and becomes the initial value the next time RUN is run.
NPRT The values of the first NCHAN output channel variables are written to the Progress tab every
NPRT time steps. They are printed for the present value of TIME, every NPRT time steps
thereafter, and for TIME = TPAUSE. If NPRT is entered as zero, the tabulation of output
channel values is bypassed.
Write every < n > time steps: integer value defining the interval, in units of the number of
simulation time steps, between the recording of output channel values. This setting is
NPLT The values of the first NCHAN output channel variables are written to the Channel Output File
every NPLT time steps. They are written to the file for the present value of TIME, every NPLT
time steps thereafter, and for TIME = TPAUSE. If NPLT is entered as zero (or one), channel
values are written to the output file at the completion of each time step. NPLT has significance
only if a channel output file has been specified either in activities STRT or ALTR.
15-57
Performing State-Space Simulation in Time Steps Program Operation Manual
Plot every <n> time steps: integer value defining the interval, in units of the number of
CRTPLT simulation time steps, between the recording of output channel values. This setting is
If the value specified for TPAUSE is less than the current value of simulation TIME, activity RUN is
terminated.
If a Channel Output File has been opened (in the most recent execution of activity STRT or subse-
quently via ALTR), the filename is displayed in a message.
Activity RUN then checks for islands which contain no in-service machines, generates an alarm for
buses in such islands, and disconnects them. Activity RUN completes its setup phase by checking
for the presence of the factorized network admittance matrix. If necessary, activity FACT (or activi-
ties ORDR and FACT) is executed.
The simulation starts at the present value of simulation TIME.
Activity RUN responds to the following interrupt control codes:
Force a pause by setting TPAUSE to the current value of simulation TIME. This overrides the
value of TPAUSE which was specified at the time activity RUN was run. In addition, if PSS®E
AB
is operating in its Response File mode, all active Response Files are closed and subsequent
user commands are taken from the user’s terminal.
NC
RUN.
MO Print the induction motor local iteration convergence monitor.
Print the output channel values at each time step. The value of NPRT which was entered at the
time activity RUN was run is overridden while this option is in effect. When this option is
CH
cleared, the original value of NPRT is restored and the next printing of channels occurs NPRT
time steps from the TIME of the clearing of the option.
TI Print the value of simulation TIME at the user’s terminal.
The form of the network convergence monitor is identical to that of activities STRT, TYSL, and
15-58
Program Operation Manual Performing State-Space Simulation in Time Steps
SOLV. The induction motor convergence monitor is identical to that of activity STRT.

When setting up a new system model, it is good practice, after a clean run of activity STRT is
obtained, to execute activity RUN for some period of simulation TIME without applying any distur-
bances. This can often reveal time constants which are too small in relation to the simulation time
step, DELT, or other modeling errors. Another useful test is to initiate some system movement with
a minor disturbance and execute the simulation until a new steady state is reached. This might be,
for example, the shedding of a small amount of load, the tripping of a small unit, or the tripping of a
lightly loaded branch.
Activity STRT sets the output control variables NPRT and NPLT to one, and CRTPLT to zero.
On the first subsequent execution of activity RUN, these values are the defaults for these variables.
On following executions of activity RUN, these variables default to the values specified on the
previous execution of activity RUN.
Whenever the value of simulation TIME reaches the time specified for TPAUSE, the time derivative
and network solution calculations are performed with a flag set to inform the simulation that this is
a t calculation. For any of the channel output options which are active, the appropriate output is
generated regardless of whether the present time step is a print or plot time step as determined by
the variables NPRT, and NPLT. When activity RUN is reentered, with perhaps some switching oper-
ation having been specified, the time step is repeated as a t+ calculation. Appropriate channel
output is performed at the completion of the time step as determined by the new specification of the
output control variables. This applies both for the case in which activity RUN has advanced TIME
to the value specified for TPAUSE and when interrupted by the user.
There are several PSS®E models which activate automatic switchings (e.g., blocking or unblocking
of a dc line by a dc line model, branch tripping by a relay model, load shedding, generator tripping,
and so on). When one of these switchings takes place, a dual time step calculation is performed as
described above. If a Channel Output File is active, the output channel values are written to it for
both the pre- and post-switching time step calculations made at the switching TIME; similarly, CRT
plotting takes place for both the pre- and post-switching time step calculations.
Both upon entering activity RUN and before performing the t+ time step calculation following auto-
matic switchings, activity RUN checks for islands which contain no in-service machines, generates
an alarm for buses in such islands, and disconnects them. It then calculates a new sparsity-
preserving ordering (activity section / ORDR) and rebuilds the factorized admittance matrix (activity
section / FACT).
It is not permissible to change the simulation time step, DELT, during a state-space simulation run.
Output channels may however be added during the course of a simulation run.
If the user forces a pause in the simulation, care must be taken when PSS®E is being executed
from a command file with PSS®E commands and responses taken from a Response File. As
described above, activity RUN closes any active PSS®E Response Files. The source of subse-
quent PSS®E dialog varies among the different PSS®E host computers.
If the network solution fails to reach its tolerance in the prescribed number of iterations, an alarm is
printed and the simulation continues as though convergence had been achieved. Refer to
Section 18.7 Running a Simulation for additional details.
15-59
Initializing Excitation System Models Program Operation Manual
PSS®E GUI Users Guide, Section 21.3, Running State-Space Simulation
Section 18.2, Running State-Space Simulation in Time Steps
15.11 Initializing Excitation System Models

Activity ESTR
Run Activity ESTR - GUI

Dynamics>Simulation>Perform exciter simulation (ESTR/ERUN)…
[Perform Exciter Simulation Test]
Run Line Mode Activity ESTR - CLI

ACTIVITY?
>>ESTR
ENTER 0 FOR RESPONSE RATIO TEST
1 FOR OPEN CIRCUIT SETPOINT STEP TEST:
>>

AB
The excitation system performance initialization activity ESTR initializes the dynamic models in
preparation for excitation system performance checking. Activity ESTR is used in conjunction with
activity ERUN to verify excitation system data by simulating the step response of excitation
systems in isolation. (Section 18.5 Model Verification contains details on the use of this pair of
activities.)
Activities ESTR and ERUN, then, are special versions of activity STRT and RUN respectively
which are used in verifying excitation system data. As such, their operating characteristics are
similar to those of activities STRT and RUN.
The user may specify a single bus for processing. Activity ESTR (and the subsequent execution of
activity ERUN) then tests the excitation system response of all machines at the specified bus
having a connected excitation system model. Otherwise, all machines with connected exciter
models are tested.
Following the initialization calculation, activity ESTR prints the case heading followed by the
number of iterations used to calculate the initial power flow. This is followed by the machine initial
conditions summary for all machines being tested in a form identical to that of activity STRT.
The user must specify the name of the Channel Output File to be used in the subsequent exciter
test simulation. If no filename is specified in response to the above instruction, the writing of the
output channel variable values to a file is suppressed during the simulation.
Activity ESTR overrides the user specified set of main output channel assignments (refer to
Section 18.6.1 Output Channel Selection) with a set of channels suitable for excitation system
15-60
Program Operation Manual Initializing Excitation System Models
testing and sets all CRT plot channel selections (refer to Section 18.6.3 CRT Plot Channels) to
zero. Therefore, activity ESTR does not enable the user to take an optional Snapshot as does
activity STRT. In fact, the user should never overwrite the main simulation Snapshot File following
execution of activity ESTR because its execution destroys the user specified output channel
assignments.
When using line mode, two separate step response tests may be simulated: a response ratio test,
and an open circuit test with a step of the voltage regulator setpoint.
Activity ESTR may be terminated by entering the AB interrupt control code.
15.11.1 Response Ratio Test

In this test, activity ESTR initializes each generator to rated MVA (i.e., to MBASE as contained in
the power flow generator data) at a user specified power factor (default = 0.95, lagging). The user
may also specify those machines which are to be initialized at another power factor (e.g.,
synchronous condensers).
Activity ESTR initializes all machines to rated MVA at their specified power factor. Because the
machine initialization to rated MVA is based on the value specified as MBASE for each machine,
the initialization, and subsequent simulation with activity ERUN, is not valid for any machines
where data is specified on a base other than its actual MVA base. As pointed out several times
throughout this manual, it is therefore strongly recommended that the PSS®E user adopt the
practice of specifying machine data parameters on actual machine MVA base.
The user selected output channels are overridden, and the exciter output voltage, EFD, for each of
the < n > online machines being tested are placed in channels one through < n >. Channel
assignments are made in ascending bus number order and identifiers are assigned as listed in .
Following activity ESTR, the user should check the value of EFD for each machine before
proceeding to activity ERUN. This value of full load excitation should be compared with that
obtained from generator test data for rated load or from the generator data verification program,
VCV (see Additional Resources for PSS®E, VCV). An unacceptable value of full load EFD most
often indicates an erroneous specification of the saturation data for the main generator. All
generator data, in particular SE(1.2), should be checked before proceeding.
15.11.2 Open Circuit Step Response Test

In this test, activity ESTR initializes each generator to unity terminal voltage on open circuit. The
user selected output channels are overridden, and the exciter output voltage, EFD, and machine
terminal voltage, ETERM, for each of the < n > online machines being tested are placed in
channels 1 through 2n. Channel assignments are made in ascending bus number order with EFDs
in odd numbered channels and ETERMs in even numbered channels. The identifiers assigned by
activity ESTR are as listed in .
The initial value of EFD for each unit will be slightly greater than the air gap line value of unity due
to saturation in the main generator. An initial open circuit value of EFD exceeding about 1.2 pu is a
fair indication that the saturation curve specified for the generator is erroneous.
PSS®E GUI Users Guide, Section 21.4, Running Exciter Simulation
Section 18.5, Initializing Excitation System Models
15-61
Performing Exciter Simulation in Time Steps Program Operation Manual
15.12 Performing Exciter Simulation in Time Steps

Activity ERUN
Run Activity ERUN - GUI

Dynamics>Simulation>Perform exciter simulation (ESTR/ERUN)…
[Perform Exciter Simulation Test]
Run Line Mode Activity ERUN - CLI

ACTIVITY?
>>ERUN
AT TIME = 0.000 ENTER TPAUSE, NPRT, NPLT, CRTPLT
>>

AB, CH, TI
The excitation system performance checking activity ERUN simulates the step response of
excitation systems in isolation. Activity ERUN performs the test selected in the previous execution
of activity ESTR; the selection of activity ERUN must, therefore, be preceded by activity ESTR.
The user specifies the simulation options TPAUSE, NPRT, NPLT, CRTPLT as in activity RUN. Re-
entering these parameters is necessary because the required activity ESTR has overridden
channel assignments. Recall that activity ESTR overrides the user selected output channel
assignments with channel values appropriate for the excitation system response tests and that it
sets CRT plot channel selections to zero. Thus, if the terminal plot option is to be selected in
activity ERUN (i.e., CRTPLT is to be specified as nonzero), the user must reestablish the CRT plot
channels and scales to correspond to the desired quantities (refer to Section 18.6 Simulation
Outputs). This must be done after execution of activity ESTR.
If the value specified for TPAUSE is less than the current value of simulation TIME, activity ERUN
is terminated.
If a Channel Output File has been opened (in the most recent execution of activity ESTR or
subsequently via activity ALTR), the filename is displayed in a message.
Activity ERUN responds to the following interrupt control codes:
value of TPAUSE which was specified at the time activity ERUN was run. In addition, if PSS®E
AB
time activity ERUN was run is overridden while this option is in effect. When this option is
CH
15-62
Program Operation Manual Performing Exciter Simulation in Time Steps
15.12.1 Response Ratio Test

Activity ERUN automatically raises the voltage regulator reference settings by a large amount at
TIME equals zero seconds. This will drive all excitation systems being tested to their ceilings as -
rapidly as possible.
At TIME = 0.5 seconds, activity ERUN tabulates at the Progress tab the values of full load
excitation and of Response Ratio for all machines being tested. The tabulation is in ascending bus
number or alphabetical order, depending on the output option currently in effect. Although
response ratio is printed for all machines, its main significance is for rotating machine exciters.
SCR bridge type exciters, such as that modeled by SCRX, will generally exhibit very high
response ratios because of their ability to reach ceiling output practically instantaneously.
This test should be carried out until at least two seconds to allow all rotating exciters to reach their
ceilings.
Using activities ESTR and ERUN to perform this simulation yields three major items of information
on each generator-exciter combination:
1. Full load excitation; note that this quantity is determined exclusively as a function of the
generator model data parameters, particularly its saturation curve.
2. The ceiling value of EFD; note that EFDs are expressed in per unit of excitation voltage for
rated open circuit generator voltage on the air gap line, not in per unit of rated load excitation
or any other value of excitation voltage.
3. The excitation system response ratio.
15.12.2 Open Circuit Step Response Test

The response ratio test discussed in Response Ratio Test provides information on the modeling of
rotating exciters but gives no information on the correctness of the voltage regulator gains and
time constants. These data are checked for correctness by ensuring that the excitation system
gives stable and effective control of generator terminal voltage when the generator is operating at
rated speed on open circuit (e.g., just before synchronizing). The open circuit response test is
intended to check this aspect of excitation system performance.
In this test, a simple step change of about five percent is applied to the voltage regulator
references and the resulting responses of field voltage and generator terminal voltage are
observed. At TIME equals zero seconds, the activity ERUN applies the user-specified Vref pu step
change (typically 0.02 to 0.1) to all voltage regulator setpoints. The step magnitude should not
exceed about ten percent (0.1 pu) because the object of this test is to reveal small disturbance
behavior.
This simulation should normally be carried out until at least five seconds; it may have to be
extended to as long as ten seconds if any slow responding exciters have not reached their steady
state.
The values of excitation system parameters should be such that a well damped but not overly
sluggish response is obtained. The response to a setpoint step of about 0.05 pu should normally
show a slight overshoot but be well damped with no persistent oscillations.
CRT plotting must not be enabled until after the voltage reference step has been specified at
TIME equals zero seconds.
15-63
Performing Exciter Simulation in Time Steps Program Operation Manual

The procedure in simulating the excitation system response tests follows that used in running
conventional state-space dynamic simulations. Instead of using activities STRT and RUN after the
data has been brought into memory, activities ESTR and ERUN are used.
The response tests calculate the excitation system response of either all generating units in the
system with connected excitation system models, or all machines at a bus (designated during
activity ESTR initialization of a single bus) with connected exciter models. Because machines are
operating in isolation, no network solution is required in the simulation. Furthermore, only the
generator and excitation system models are active in these simulations; all other models perform
no calculations. Therefore, these simulations require substantially less computer time than
complete system simulations.
The typical sequencing of PSS®E activities in preparing for these simulations is as follows:
1. Restore Dynamics Working Memory from a Binary Snapshot File () <file1>
2. Retrieve a Power Flow Saved Case File (section / CASE) <file2>
where <file1> is the name of the appropriate dynamics data Snapshot File and <file2> is the name
of the corresponding converted power flow Saved Case File. Generators in the working case must
be converted (i.e., activity section / CONG must have been executed). Because the network is not
involved in these simulations, the load characteristic is immaterial and the execution of activity
section / FACT is not required.
Following execution of activity ESTR, activity ERUN should have its first TPAUSE specified as
zero, because the perturbation of the voltage regulator references occurs at that TIME. Activity
ERUN should then be reentered, specifying the desired duration of the simulation.
Note again that because activity ESTR replaces the user’s output channel assignments with other
quantities, activity SNAP should not be executed following activity ESTR.
The comments given in The form of the network convergence monitor is identical to that of
activities STRT, TYSL, and SOLV. The induction motor convergence monitor is identical to that of
activity STRT. for activity RUN regarding the defaults for the output control variables, the repeat
time step calculation at each simulation pause, changing of the simulation time step, adding output
channels, and interrupting the simulation when running from a command file also apply to activity
ERUN.
PSS®E GUI Users Guide, Section 21.4, Running Exciter Simulation
Section 18.6, Running Exciter Simulation in Time Steps
15-64
Program Operation Manual Initializing Turbine Governor Models
15.13 Initializing Turbine Governor Models

Activity GSTR
Run Activity GSTR - GUI

Dynamics>Simulation>Perform governor response simulation (GSTR/GRUN)…
[Perform Governor Response Simulation]
Run Line Mode Activity GSTR - CLI

ACTIVITY?
>>GSTR
ENTER INITIAL LOADING, STEP (P.U.):
>>

AB
The governor performance initialization activity GSTR initializes the dynamic models in
preparation for governor performance checking. Activity GSTR is used in conjunction with activity
GRUN to verify turbine governor data by simulating the response of individual units in isolation.
(Section 18.5 Model Verification contains details on the use of this pair of activities.)
The principal purpose of the governor response test is to ensure that the governor gain and time
constant parameters correspond to a correctly tuned, well damped response. This test simulates
the response of the governing loops of units in isolation to a step change in load. The load active
power is held constant and the reactive load is adjusted to maintain unity terminal voltage. This
test, then, indicates the damping due to the turbine and governor loop only.
Activities GSTR and GRUN are special versions of activities STRT and RUN, respectively which
are used in verifying governor data. As such, their dialog and operating characteristics are similar
to those of activities STRT and RUN.
If the user has specified processing a single bus, activity GSTR (and the subsequent execution of
activity GRUN) then tests the governor response of all machines at the specified bus having a
connected governor model. Otherwise, all machines with connected governor models are tested.
The user specifies initial machine loading in per unit of machine base, MBASE, and the load step
change to be applied at TIME equals zero by activity GRUN. Because the machine initialization to
a specified fraction of rated MVA is based on the value specified as MBASE for each machine, this
test assumes that generator parameters are entered on actual machine base. The governor droop
is to be specified on turbine base if the turbine governor model has the provision to specify the
turbine rating; otherwise the governor droop has to be specified on the machine base.
Activity GSTR prints the case heading followed by the number of iterations used to calculate the
initial power flow. This is followed by the machine initial conditions summary for all machines being
tested in a form identical to that of activity STRT.
The user specifies the Channel Output File to be used in the subsequent governor test simulation.
If no filename is specified in response to the above instruction, the writing of the output channel
variable values to a file is suppressed during the simulation.
Activity GSTR overrides the user specified set of output channel assignments (refer to
Section 18.6.1 Output Channel Selection), and the machine speed deviation, SPEED, and turbine
mechanical power, PMECH, for each of the < n > online machines being tested are placed in
channels 1 through 2n. Channel assignments are made in ascending bus number order with
15-65
Performing Governor Response Simulation in Time Steps Program Operation Manual
SPEEDs in odd numbered channels and PMECHs in even numbered channels; the identifiers
assigned by activity GSTR are as listed in Table 14-2. Activity GSTR also sets all CRT channel
selections (refer to Section 18.6.3 CRT Plot Channels) to zero. Therefore, activity GSTR does not
enable the user to take an optional snapshot as does activity STRT. In fact, the user should never
overwrite the main simulation Snapshot File following execution of activity GSTR because its
execution destroys the user specified output channel assignments.
The machine initial conditions summary of activity GSTR may be terminated with the AB interrupt
control code.

The testing of cross-compound governor models requires that both generator models be active.
PSS®E GUI Users Guide, Section 21.5, Running Governor Response Simulation Test
Section 18.7, Initializing Turbine Governor Models
15.14 Performing Governor Response Simulation in Time Steps

Activity GRUN
Run Activity GRUN - GUI

Dynamics>Simulation>Perform governor response simulation (GSTR/GRUN)…
[Perform Governor Response Simulation]
Run Line Mode Activity GRUN - CLI

ACTIVITY?
>>GRUN
>>

AB, CH, TI
The governor performance checking activity GRUN simulates the response of the governing loops
of units in isolation to a step change in load. Activity GRUN uses the step specified in the previous
execution of activity GSTR; the selection of activity GRUN must, therefore, be preceded by activity
GSTR.
The user specifies the simulation options TPAUSE, NPRT, NPLT, CRTPLT as in activity RUN. Re-
entering these parameters is necessary because the required activity GSTR has overridden
channel assignments. Recall that activity GSTR overrides the user selected output channel
assignments with channel values appropriate for the governor response test and that it sets CRT
plot channel selections to zero. Thus, if the terminal plot option is to be selected in activity GRUN
15-66
Program Operation Manual Performing Governor Response Simulation in Time Steps
(i.e., CRTPLT is to be specified as nonzero), the user must reestablish the CRT plot channels and
scales to correspond to the desired quantities (refer to Section 18.6 Simulation Outputs). This
must be done after execution of activity GSTR.
If the value specified for TPAUSE is less than the current value of simulation TIME, activity GRUN
is terminated.
If a Channel Output File has been opened (in the most recent execution of activity GSTR or
subsequently via activity ALTR), the filename is displayed in a message.
Activity GRUN responds to the following interrupt control codes:
value of TPAUSE which was specified at the time activity GRUN was run. In addition, if PSS®E
AB
time activity GRUN was run is overridden while this option is in effect. When this option is
CH
Activity GRUN automatically applies the load increment (typically 0.05 to 0.1) specified in activity
GSTR to each unit at TIME equals zero seconds.
This simulation should normally be carried out until at least ten seconds; the simulation may have
to be extended to as long as twenty seconds if hydro units are present.

Using activities GSTR and GRUN to perform this simulation reveals the transient variation of
turbine power and machine speed. All governing units should have a well damped response.
Hydro governors will generally exhibit a somewhat greater overshoot than steam turbine
governors, but should still be well damped, showing no persistent oscillations. A small negative
change in hydro turbine power before it follows a positive change in load power is normal and does
not indicate incorrect governor tuning.
The procedure in simulating the governor response test follows that used in running conventional
state-space dynamic simulations. Instead of using activities STRT and RUN after the data has
been brought into memory, activity GSTR and GRUN are used.
The response test calculates the governor response of either all generating units in the system
with connected governor models, or all machines at a bus (designated during activity GSTR
initialization of a single bus) with connected governor models. Because machines are operating in
isolation, no network solution is required in the simulation. Furthermore, only the generator and
turbine-governor models are active in these simulations; all other models perform no calculations.
Therefore, these simulations require substantially less computer time than complete system
simulations.
The typical sequencing of PSS®E activities in preparing for these simulations is as follows:
15-67
Building a State Variable Matrix for Linear Dynamic Analysis (LSYSAN)Program Operation Manu-
of the corresponding converted power flow Saved Case File. Generators in the working case must
be converted (i.e., activity section / CONG must have been executed). Because the network is not
involved in these simulations, the load characteristic is immaterial and the execution of activity
section / FACT is not required.
Following execution of activity GSTR, activity GRUN should have its first TPAUSE specified as
zero, because the load increment is applied at that TIME. Activity GRUN should then be reentered,
specifying the desired duration of the simulation.
Note again that because activity GSTR replaces the user’s output channel assignments with other
quantities, activity SNAP should not be executed following activity GSTR.
The comments given in The form of the network convergence monitor is identical to that of
activities STRT, TYSL, and SOLV. The induction motor convergence monitor is identical to that of
activity STRT. for activity RUN regarding the defaults for the output control variables, the repeat
time step calculation at each simulation pause, changing of the simulation time step, adding output
channels, and interrupting the simulation when running from a command file also apply to activity
GRUN.
PSS®E GUI Users Guide, Section 21.5, Running Governor Response Simulation Test
Section 18.8, Running Governor Response Simulation in Time Steps
15.15 Building a State Variable Matrix for Linear Dynamic Anal-

ysis (LSYSAN)
Activity ASTR
Run Activity ASTR - GUI

Dynamics>Build matrices for LSYSAN program (ASTR)…
[Build Matrices for LSYSAN]
Run Line Mode Activity ASTR - CLI

ACTIVITY?
>>ASTR
ENTER LARGEST DERIVATIVE CHANGE ALLOWED (DEFAULT IS 0.01):
>>

AB, CM, NC, MO
Activity
The state variable matrix construction activity ASTR calculates the initial values of all variables for
each equipment model as a function of the model’s constant data and the boundary condition at the
bus in the working case at which it is referenced. It then infers the state variable system matrices
15-68
Program Operation ManualBuilding a State Variable Matrix for Linear Dynamic Analysis (LSYSAN)
and processes them into a form suitable for input into the Linear Dynamic Analysis program,
LSYSAN.
For a valid execution of activity ASTR, dynamics data must be present in dynamics data working
memory and the converted network must be represented in the working case. The normal activity
sequence which precedes activity ASTR is:
where <file1> is the Snapshot File containing the appropriate dynamics model data and output
channel specifications, and <file2> is the Saved Case File containing the converted power flow
case.
When run, activity ASTR generates an alarm and terminates if generators are not converted. It
then ensures that the machine power arrays in the power flow working case are set to their original
initial condition values (they may have been changed by a prior execution of activity STRT or
MSTR). Activity ASTR completes its setup phase by checking for the presence of the factorized
network admittance matrix. If necessary, activity FACT (or activities section / ORDR and section /
FACT) is executed.
Activity ASTR does a network solution and then, based on the bus boundary conditions, initializes
the state variables (STATEs) and algebraic variables (VARs) of each equipment model. If, in
setting up for the initial network solution, any CIMTR5, CIMWSC, CIM5xx, CLODxx, or IEELxx
model removes constant admittance load from the load at which it is called, an appropriate
message is printed and the network admittance matrix is automatically refactorized prior to
commencing the network solution.
Similarly, any two-terminal, multi-terminal, VSC dc line, FACTS device, or switched shunt device in
continuous control mode, which is in-service in the working case but which does not have a dynamic
table model assigned to it generates an alarm with one of the following error messages:

The presence of any such dc line, FACTS device or switched shunt could indicate one of the
following:
15-69
• a table model was assigned to the dc line, FACTS device, or the switched shunt, but
the model was later removed by selecting Remove Model form the popup menu that
appears by right-clicking on model name in the Dynamics Models Spreadsheet; refer
to PSS®E GUI Users Guide, Section 2.6, Models Spreadsheet.
• no table model was ever assigned to the dc line, FACTS device or the switched shunt,
or that the model assigned is a CONEC and CONET called model.
The presence of any dc line or FACTS device for which there is no dynamic model renders the initial
condition invalid.
limits (e.g., the voltage regulator output, STATE(K+1), of the IEEE Type 1 excitation system model,
IEEET1) generates an alarm with a message of the form:
such error conditions before using the matrices constructed by activity ASTR. The presence of
such error alarms renders the initial condition invalid in the sense that the system is not in a steady
state. The exception is the condition where the bus boundary conditions are such that the variable
in question is initialized exactly at its limit. Such a situation may occur, for example, when a
generator is fully loaded and its turbine mechanical power initializes precisely at its ceiling.
Activity ASTR then prints case heading followed by the number of iterations used to calculate the
initial power flow. A value of < n > greater than one usually (but not always) indicates some sort of
modeling error. This is especially true if the converted power flow network was solved with activity
TYSL prior to the execution of activity ASTR. (The network solution method used here is identical
to that used by activity TYSL, and the default convergence tolerance is an order of magnitude
smaller in section / TYSL.)
The most common causes of this type of error are the same as for activity STRT.
Activity ASTR then summarizes the conditions at each online machine by tabulating the following
quantities:
• Power factor.
Following the calculation of the system initial condition, the time derivatives (DSTATEs) of all
STATE variables are calculated and then checked for a steady state. The user specifies the
largest derivative change to be allowed. Any STATE for which the time derivative exceeds the
specified threshold generates an alarm; its index is printed along with the values of its time
derivative and the STATE variable itself. For STATEs that have generated an alarm that are
assigned to plant-related models, the model and machine are also identified. For STATEs that
have generated an alarm that are assigned to load-related models, the model and load are also
identified. For STATEs that have generated an alarm that are assigned to auxiliary-signal models,
15-70
Program Operation ManualBuilding a State Variable Matrix for Linear Dynamic Analysis (LSYSAN)
the model and the name of the device (the two-terminal, multi-terminal or VSC dc line or the
FACTS device) with which the auxiliary-signal is associated are identified. For STATEs that have
generated an alarm that are assigned to dc line models, the model and dc line are identified. For
STATEs that have generated an alarm that are assigned to FACTS device models, the model and
FACTS device are identified. For STATEs that have generated an alarm that are assigned to
switched shunt models, the model and switched shunt device are identified. In each case, the ac
bus is also identified. In each case, the ac bus is also identified. In the case of machines, loads,
and switched shunts, this will be the ac bus at which the machine, load or the switched shunt.
In the case of machines and loads, this will be the ac bus at which the machine and load are
connected; for two-terminal dc lines, VSC dc lines, as well as for auxiliary signals attached to
these devices, this is the rectifier ac bus; for multi-terminal dc lines and for auxiliary signals
attached to multi-terminal dc lines, this will be the ac bus associated with converter number one;
for FACTS devices and for auxiliary signals attached to FACTS devices this will be the sending
end ac bus. If any such STATE variables are detected, activity ASTR is terminated. As in activity
STRT, the presence of nonsteady STATEs may be caused by a variety of factors (e.g., procedural
errors, incorrect model data, numerical precision).
The user must specify the name of the Matrix Output File into which the system matrices and
related information are to be written. If no filename is specified in response to the above
instruction, activity ASTR is terminated. Refer to Section 2.4.1 File Usage for the file specification
conventions used by activity ASTR.
The user specifies those STATE variables to be included in the linear system matrices, either as
single STATEs or range of STATEs to be included in the matrices.
The user specifies the perturbation factor (default = 0.01).
The LSYSAN program provides for up to fifty elements in the system output vector and related
matrices. Activity ASTR treats the output channel selections in dynamics working memory (refer to
activity CHAN and Section 18.6 Simulation Outputs) as potential output quantities. If no output
channel selections have been introduced into the simulation setup, an appropriate message is
printed and the H and F matrices are not constructed. Otherwise, the user may specify those
output channels to be included as linear system outputs, either as single channels or range of
channels to be included as linear system outputs. If no specification is made, the first < nn > (or
fifty, whichever is smaller) output channels are used.
Activity ASTR then perturbs each of the selected STATE variables in turn, calculates time
derivatives, constructs the corresponding columns of the A and H matrices (refer to Application
Notes), and writes them to the matrix output file.
The user specifies input variables to be perturbed. The LSYSAN program provides for up to twenty
input variables. Input quantities for the designated machine and a perturbation factor by which the
initial condition value of the selected quantity is modified may be any of the following:
• EFD
• Pmech
• Vothsg
• Vref
• VAR (L)
The VAR index may be specified.
The user may specify a thirty-two character identifier to be included in the matrix output file. If no
identifier is specified, activity ASTR assigns an identifier as listed in . The corresponding columns
of the B and F matrices are calculated and written to the matrix output file.
15-71

Activity ASTR responds to the following interrupt control codes:

NC
ASTR.
The format of the network convergence monitor is the same as that of activity STRT.

Activity ASTR converts the system model into its state-space form represented by the following
equations:
x = Ax + Bu
v = Hx + Fu
where x is the state variable vector, u is the vector of input variables, v is the output variable vector,
and A, B, H and F are the real matrices describing the small perturbation behavior of the system.
While zero time constants for certain transfer function blocks such as voltage transducers may be
appropriate for dynamic simulation runs, any such state variable included in the system matrices
described above will result in its row in the A matrix having every term zero. The analysis in the
LSYSAN program prohibits this condition; LSYSAN automatically removes the corresponding row
and column from the A matrix, the corresponding column from the H matrix, and the corresponding
row from the B matrix. Alternatively, the user may exclude such STATEs from the specification of
those STATEs to be included in the linear system. Note that several PSS®E models treat small
(relative to the simulation time step, DELT) time constants as if they were zero; therefore, the
comments above apply to such STATEs as well.
If the user wishes to include such STATEs in the linear system model, then, prior to using activity
ASTR, those time constants which are zero must be set to appropriate small values and the simu-
lation time step DELT must be set such that all time constants included in the linear system are at
least five times DELT. DELT may be set to as small a value as necessary with no execution time
penalty or change in results because no actual time simulation takes place during or following
activity ASTR. DELT is only used by the equipment models to determine which transfer function
blocks are to be treated algebraically; the models perform the same calculations that they do in
normal time simulations.
In designating those inputs to be perturbed, only variables which are external inputs into the system
model may be selected. For example, an EFD may be perturbed only if there is no excitation system
model for the machine; similarly, a machine’s PMECH may not be perturbed if its governor is -
modeled.
The mathematical basis of the calculations performed in activity ASTR and by the LSYSAN program
require that the matrices constructed be based on a system model initialized in equilibrium. Any
15-72
Program Operation Manual Listing Dynamics Model Data
out-of-limits or non steady-state variable errors should be checked before using these matrices in
LSYSAN; care should be exercised in increasing the derivative threshold tolerance simply to force
activity ASTR to run to completion.
The matrix output file constructed by activity ASTR is a binary file in the form required by the
LSYSAN activity BCAS.
Section 21.9, Building a State Variable Matrix for Linear Dynamic Analysis (LSYSAN)
Section 18.9, Building a State Variable Matrix for Linear Dynamic Analysis (LSYSAN)
15.16 Listing Dynamics Model Data

Activity DOCU
Run Activity DOCU - GUI

Dynamics>List>Models and data (DOCU)…
[List Dynamics Model Data]
Run Line Mode Activity DOCU - CLI

ACTIVITY?
>>DOCU

AB
The model documenting activity DOCU produces a tabulation of the data associated with equip-
ment models referenced in the user’s simulation setup. The tabulation for each model includes a
listing of the locations in the various dynamics data arrays used by the model, and a listing of the
values of the constant data parameters used by the model.
The user must specify one of the following modes of operation:
• Reporting mode
• Data checking mode
In reporting mode, all model references being processed are tabulated. In data checking mode,
activity DOCU compares the data of each model reference being processed to typical parameter
ranges and performs certain relational checks (e.g., generator subtransient reactance greater than
leakage reactance). For any model for which the data is found to be suspect, the data item(s) in
question are tabulated followed by the standard model data tabulation for that model.
15-73
Listing Dynamics Model Data Program Operation Manual
The user specifies the model type to be listed or processed:
• CONEC models: restricted to models called from subroutine CONEC

• CONET models: restricted to models called from subroutine CONET
• CHAN models: restricted to activity
and monitoring models (refer to CHAN and CHSB). The monitoring models are lWhen activity
CHAN is being used to change the channel assignments assigned to a subset of previously
generated assignments, the value printed for < NCHAN > is the larger of the original next available
channel and that which would be set as a result of the current execution of activity CHAN.
Consider, for example, the situation in which fifty output channels have been assigned and are
being monitored and the user wishes to change the quantity associated with channel ten. Activity
CHAN would be entered, a starting channel number of ten would be specified rather than the
default of fifty-one, and the appropriate channel assignment made. < NCHAN > would be fifty-one,
and hence NCHAN would retain its previous value of fifty.istedApplication Notes in the order in
which the output channel assignments were made.
• Models by subsystem
• Miscellaneous other models
If all buses in a models by subsystem list are processed, activity DOCU displays all models refer-
enced in the simulation setup in the following order:
1. plant-related equipment models
2. load-related models
3. line relay models
4. auxiliary signal models in the following order:
a. two-terminal dc line auxiliary signal models

b. multi-terminal dc line auxiliary signal models
c. VSC dc line auxiliary signal models
d. FACTS device auxiliary signal models
5. dc line models in the following order:
a. two-terminal dc line models

b. multi-terminal dc line models
c. VSC dc line models
6. FACTS device models
7. all miscellaneous other models and models called from subroutines CONEC and CONET
The various dynamic simulation options are also displayed.
Plant-related and load-related models are tabulated in ascending bus numerical (using the numbers
output option) or alphabetical (using the names option) order; multiple elements (machines or
loads) at the same bus are printed in ascending identifier order. Plant- and load-related models for
15-74
Program Operation Manual Listing Dynamics Model Data
a given network element are listed together in the report in the same order in which they are called
during a dynamic simulation calculation. For machines, this order is: generator, compensator, stabi-
lizer, minimum excitation limiter, maximum excitation limiter, excitation system, and governor. For
loads, the model order is load characteristic followed by load relay.
Line relay models are also tabulated in ascending bus numerical or alphabetical order. Models on
branches connected to a given bus are listed in ascending order of the other bus; line relay models
on parallel circuits are printed in ascending circuit identifier order.
Auxiliary-signal models are tabulated in ascending bus numerical or alphabetical order. At any bus,
the auxiliary-signal models are listed in the following order: auxiliary models associated with two-
terminal dc lines followed by auxiliary models associated with multi-terminal dc lines followed by
auxiliary models associated with VSC dc lines followed by auxiliary models associated with FACTS
devices.
DC line models are tabulated in ascending bus numerical or alphabetical order. At any bus, dc line
models are listed in the following order: two-terminal dc line models followed by multi-terminal dc
line models followed by VSC dc line models.
FACTS devices, and switched shunt models are also tabulated in ascending bus numerical or
alphabetical order.
Wind machine models (i.e., wind related models attached to machines designated as wind
machines in power flow) are tabulated in ascending bus numerical (using the numbers output
option) or alphabetical (using the names option) order; multiple machines at the same bus are
printed in ascending identifier order. Wind machine related models for a given network element are
listed in the following order: generator, electrical control, mechanical model, pitch control, aerody-
namic model, gust model, and auxiliary control.
The CONEC models are tabulated in the order in which they are called; then the CONET models
are tabulated in the order they are called.
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. In any of the subsystem
selection modes the user may specify any of the following types of models:
15-75
Listing Dynamics Model Data Program Operation Manual
• All models • VSC dc line models

• All plant models • FACTS device models
• Generator models • CONEC models
• Compensator models • CONET models
• Stabilizer models • CHAN models
• Minimum excitation limiter models • Turbine load controller models
• Maximum excitation limiter models • Switched shunt models
• Excitation system models • Wind models
• Turbine governor models • Wind generator models
• Load characteristic models • Wind electrical control models
• Load relay models • Wind mechanical models
• Line relay models • Wind pitch models
• Auxiliary signal models • Wind aerodynamic models
• 2-terminal dc line models • Wind gust models
• N-terminal dc line models • Wind auxiliary control models
Output for the appropriate grouping of buses is produced with buses ordered as described in
Section 4.9 Subsystem Reporting.

The data checking mode of activity DOCU is intended to identify gross data errors such as
misplaced decimal points, improper relationships between parameters and so on. It provides an
initial editing of the complete set of model data, restricting the output to models for which the values
of parameters are outside of a representative range of values.
Being reported in the data checking mode of activity DOCU does not indicate that parameter values
are necessarily wrong; it simply indicates that they deserve to be checked. Conversely, the absence
of warning messages from this screening by activity DOCU does not indicate that all data is valid.
Most power system parameters can fall within reasonable normal value ranges and still be totally
invalid. For this reason, the checking of parameter ranges is not an adequate form of data verifica-
tion; it is only a rough initial check for typing and stenographic errors. The checking of parameter
ranges must be followed by performance checks to verify that the parameter values specified for
the dynamic equipment models actually represent realistic system performance. Model perfor-
mance verification is described in Section 18.5 Model Verification.
When generator data is expressed on a base other than the actual machine base (i.e., when
MBASE is not actual machine base), the data checking mode of activity DOCU may generate
alarms for data items which are perfectly reasonable. This is due to the assumption in the models
that data is expressed on actual machine base. Quantities such as machine inertias and turbine
governor limits are most likely to generate an alarm for such machines. It is therefore strongly
recommended that generator data be expressed on actual generator base.
15-76
Program Operation Manual Listing Dynamics Data Arrays
PSS®E GUI Users Guide, Section 20.12.1, Model Data
Section 17.11.1, Listing Dynamics Model Data
15.17 Listing Dynamics Data Arrays

Activity DLST
Run Activity DLST - GUI

Dynamics>List>Dynamics data (DLST)…
[List Dynamics Data Common]
Run Line Mode Activity DLST - CLI

ACTIVITY?
>>DLST
>>

AB
The dynamics data array listing activity DLST provides a tabulation of user selected portions of any
or all of the following categories of data:
• CON array
• VAR array
• STATE array
• ICON array
• Main output channel selections
• CRT plot channel selections
The user specifies the desired starting and ending indices for each of these arrays. A null
response for the range of data values of any category of data causes that category to be skipped.
STATEs and VARs are generally meaningful only during and following dynamic simulation
calculations. These arrays are initialized during the initialization of the simulation (i.e., during
activities STRT, MSTR, ESTR, or GSTR), and not during activity DYRE. When performing
extended term simulations with activities MSTR and MRUN, the STATE array is used for different
purposes than it is during state-space simulations. The value displayed for a STATE by activity
DLST is unrelated to the STATE index displayed.
For output channel data, the listing consists of the output channel number, the channel address
(IPRINT), the current value of the variable assigned to the channel, the channel identifier, a
description of the type of quantity assigned to the channel (refer to activity CHAN and ), and its
15-77
Creating a Dynamics Model Raw Data File Program Operation Manual
location in the network or dynamics data arrays.

For CRT plot channel data, the listing consists of the CRT plot channel number, the number of the
main output channel assigned to this CRT plot channel, the current value of the variable assigned
to the channel, the plotting limits (CMIN and CMAX), the channel identifier, a description of the
type of quantity assigned to the channel (refer to activity CHAN and ), and its location in the
network or dynamics data arrays.
PSS®E GUI Users Guide, Section 20.12.2, Data Arrays
Section 17.11.2, Listing Dynamics Data Arrays
15.18 Creating a Dynamics Model Raw Data File

Activity DYDA
Run Activity DYDA - GUI

File>Save…
[Save / Show Dynamics Data]
Dynamics Model Data Tab
Run Line Mode Activity DYDA - CLI

ACTIVITY?
>>DYDA
>>

AB
The dynamics data output activity DYDA processes dynamics model data into the form of a
Dynamics Model Raw Data File (refer to The dynamics data input activity DYRE reads simulation
model data from a Dynamics Model Raw Data File into the dynamics data arrays in PSS®E
working memory.) suitable for input to activity DYRE. It may be viewed as the logical inverse of
activity DYRE.
The user may process the entire dynamics simulation setup or specify model specification records
for those models called from subroutines CONEC or CONET. Data is written in the following order:
1. Data records for plant-related models contained in the model connection tables are written
in ascending numerical or alphabetical bus order, according to the bus output option
currently in effect.
2. Data records for load-related models contained in the model connection tables are written
in order of decreasing precedence. Bus oriented load-related models are presented in
ascending numerical or alphabetical bus order, according to the bus output option currently
15-78
Program Operation Manual Creating a Dynamics Model Raw Data File
in effect. Load-related models pertaining to other subsystems are presented in subsystem

numeric order.
3. Line relay models are written in ascending numerical or alphabetical from bus order
according to the bus output option in effect; when multiple line relay models are present at
the same from bus, they are written in ascending to bus and circuit identifier order.
4. Auxiliary signal models are written in ascending numerical or alphabetical bus order,
according to the bus output option currently in effect. At any bus, the auxiliary-signal models
are written in the following order: auxiliary models associated with two-terminal dc lines
followed by auxiliary models associated with multi-terminal dc lines followed by auxiliary
models associated with VSC dc lines followed by auxiliary models associated with FACTS
devices.
5. The dc line models are written in ascending numerical or alphabetical bus order, according
to the bus output option currently in effect. At any bus, dc line models are written in the
following order: two-terminal dc line models followed by multi-terminal dc line models
followed by VSC dc line models.
6. FACTS devices, and switched shunt models are written in ascending numerical or alphabet-
ical bus order, according to the bus output option currently in effect.
7. Wind machine model (i.e., wind related models attached to machines designated as wind
machines in power flow) data records contained in the model connection tables are written
out in ascending numerical or alphabetical bus order, according to the bus output option
currently in effect.
8. Data records for the remaining simulation models are written in the same order in which the
equipment models are referenced in subroutines CONEC and CONET.
In any of the subsystem selection modes the user may specify any of the following types of models:
• All models • VSC dc line models

• All plant models • FACTS device models
• Generator models • CONEC models
• Compensator models • CONET models
• Stabilizer models • Turbine load controller models
• Minimum excitation limiter models • Switched shunt models
• Maximum excitation limiter models • Wind models
• Excitation system models • Wind generator models
• Turbine governor models • Wind electrical control models
• Load characteristic models • Wind mechanical models
• Load relay models • Wind pitch models
• Line relay models • Wind aerodynamic models
• Auxiliary signal models • Wind gust models
• 2-terminal dc line models • Wind auxiliary control models
• N-terminal dc line models
15-79
Creating a Dynamics Model Raw Data File Program Operation Manual
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. Output for the appropriate
grouping of buses is produced with buses ordered as described in Section 4.9 Subsystem
Reporting.
Activity DYDA produces model specification records for any subsystem load-related model
connected to a load which is a member of selected subsystem. This means that, for example, an
Owner type subsystem model is produced when processing a subsystem consisting only of zones
if the Owner type subsystem model is connected to a load which is a member of the selected zones.

Prior to initiating activity DYDA, the following requirements must be met:
1. Dynamics data must be present in working memory (i.e., the appropriate Snapshot File must
be restored into memory with activity ).
2. The corresponding electrical network must be present in the power flow working case as a
converted case.
3. The associated connection subroutines (if present) must be linked into the PSS®E program
structure (i.e., the createusrdll command to create the user dll must have been executed;
refer to Additional Resources for PSS®E, Createusrdll).
Thus, assuming that the connection subroutines have been linked as described in Section 4.10
Loading the Connection Subroutines, the following activity sequence normally precedes activity
DYDA:
of the corresponding converted power flow Saved Case File.
Data records for plant-related models, load-related models, line relay models, dc line models,
FACTS device models, and auxiliary signal models which are bypassed (i.e., off) are omitted from
the output of activity DYDA. Similarly, data records for such models which are unconnected (i.e.,
the network element to which they are connected is not present in the power flow working case) are
excluded.
In subsystem selection mode in the graphical user interface, when specifying subsystems and
model types, the user should be careful not to write data records for any model more than once.
When writing two machine models (e.g., FRECHG, COMPCC, CRCMGV), a special convention is
used by activity DYDA. The model is assumed to be associated with the first machine of the two for
which it is applied.
When writing auxiliary-signal models, dc line models, and FACTS device models, the following
convention is used: for two-terminal dc lines, and for auxiliary-signal models associated with two-
terminal dc lines, DYDA assumes that the model is associated with the rectifier bus; for multi-
terminal dc lines and auxiliary-signal models combined with multi-terminal dc lines, DYDA assumes
15-80
Program Operation Manual Creating a Dynamics Model Raw Data File
that the model is associated with the ac bus of the first converter; for VSC dc lines, and for auxiliary-
signed models combined with VSC dc lines, DYDA assumes that the model is associated with the
first converter; for FACTS devices and auxiliary-signal models combined with FACTS devices,
DYDA assumes that the model is associated with the sending end ac bus.
In subsystem selection mode, a similar convention is used in processing line relay, CONEC, and/or
CONET models following specification of all models, line relay models, CONEC models, or CONET
models. For line relay models and for those CONEC and CONET models that refer to more than
one bus, activity DYDA assumes that the model is associated with the first bus that defines the
equipment being modeled (e.g., for DISTR1, the from bus of the branch).
GUI only: The [Save / Show Dynamics Data] dialog available from the File > Save menu entry
when dynamics data is present in the working case provides an additional control beyond those
available using line mode. This control is the Load model output toggle which includes two condi-
tions: All subsystem models and Selected subsystem models. The toggle is available when bus
selection is limited to one bus subsystem or individually specified buses.
The All subsystem models selection is equivalent to the line mode behavior of activity DYDA.
Selecting the Selected subsystem models condition may further limit the reported model specifica-
tion records of subsystem load-related models.
Under either condition the output includes model specification records for Bus type subsystem
models connected to any element which is a member of the selected subsystem. When subject to
the Selected subsystem models condition, the output excludes all non-Bus type subsystem models
for which the subsystem type is not part of the subsystem selection criteria. For example, if the
selected subsystem consists only of zones, then the reported model specification records excludes
all Owner, Area and All type subsystem models, and includes Zone type subsystem models which
are connected to elements in the selected zones.
PSS®E GUI Users Guide, Section 20.10, Creating a Dynamics Model Raw Data File
Section 17.9, Creating a Dynamics Model Raw Data File
15-81
Dumping Dynamic Simulation Output Channels into a Response File Program Operation Manual
15.19 Dumping Dynamic Simulation Output Channels into a

Response File
Activity DMPC
Run Activity DMPC - GUI

File>Save…
Dump Output Channels Tab
Run Line Mode Activity DMPC - CLI

ACTIVITY?
>>DMPC
ENTER 0 TO SKIP CHANNELS CONTAINING STATES AND VARS
1 TO INCLUDE ALL CHANNELS:
>>

None
The output channel dumping activity DMPC writes the simulation output channel selections as
contained in dynamics working memory in the form of a PSS®E Response File suitable for
directing activities CHAN and/or CHSB. Thus, activity DMPC may be viewed as the logical inverse
of the channel selection activities. The normal application of this file is to automate the transfer of
output channel specifications from an existing simulation setup to a new Snapshot which models
essentially the same system.
The user specifies either:
• A filename. If an error occurs in opening the file, an appropriate error message is
printed and the request for the output device is repeated. Refer to Section 2.4.1 File
Usage for the file specification conventions used by activity DMPC.
• Output of records to the user’s terminal.
The user specifies one of the following conditions:
• Skip channels containing VARs and STATEs: all channels containing STATEs, as well
as those containing VARs not associated with activity CHAN and CHSB monitoring
models (refer to When activity CHAN is being used to change the channel assignments
assigned to a subset of previously generated assignments, the value printed for
< NCHAN > is the larger of the original next available channel and that which would be
set as a result of the current execution of activity CHAN. Consider, for example, the sit-
uation in which fifty output channels have been assigned and are being monitored and
the user wishes to change the quantity associated with channel ten. Activity CHAN
would be entered, a starting channel number of ten would be specified rather than the
default of fifty-one, and the appropriate channel assignment made. < NCHAN > would
be fifty-one, and hence NCHAN would retain its previous value of fifty.
,Application Notes , andList CHAN Models ), are omitted from the set of responses produced by
activity DMPC.
• Include all channels: responses for all channels are generated.
15-82
Program Operation Manual Creating Dynamic Data Records for Use by Other Activities
Activity DMPC writes to the selected output destination the dialog required to specify channels one
through NCHAN (refer to ALTR and RUN) via activities CHAN and/or CHSB.
Activity DMPC generates an alarm at the Progress tab any channel for which the channel genera-
tion dialog is not written. Output channels are skipped under the following conditions:
1. An invalid channel address is assigned to the channel (refer to Section 18.6.1 Output
Channel Selection).
2. The channel quantity is a VAR not associated with a CHAN monitoring model or a STATE,
and the option to include these was not enabled.
In the Response File built by activity DMPC, a blank line is included as the response for the
starting channel, VAR and ICON request by activities CHAN and CHSB. Thus, the next available
locations in these arrays at the time the Response File is executed will be used.
Section 20.13, Dumping Dynamic Simulation Output Channels into a Response File
Section 17.12, Dumping Dynamic Simulation Output Channels into a Response File
15.20 Creating Dynamic Data Records for Use by Other Activities

Activity RWDY
Run Activity RWDY - GUI

File>Save…
Machine Parametric Source Data Tab
Run Line Mode Activity RWDY - CLI

ACTIVITY?
>>RWDY
>>

AB
The auxiliary dynamics data output activity RWDY writes machine parametric data from dynamics
working memory in the form of either an Inertia and Governor Response Data File (refer to
Section 6.8.1 Inertia and Governor Response Data File Contents) for input to activity section / INLF,
or a Breaker Duty Data File (refer to Section 9.12.2 Breaker Duty Data File Contents) for input to
activity section / BKDY. Activity RWDY may also be used to produce line relay data and branch
impedances in the form required by the PSSPLT activity RELY.
15-83
Creating Dynamic Data Records for Use by Other Activities Program Operation Manual
The user must specify one of the following file types to be generated:
• Breaker Duty Data File

• Unit Inertia and Governor Data File
• Relay Characteristic Data File
If the user specifies the Unit Inertia and Governor Data File, the following options are also available:
• Suppress machine power limits: When output is used by activity INLF the machine
active power limits from the working case are used rather than those from the turbine
governor models.
• Specify treatment of machines without governor models by activity INLF:
- Use INLF defaults (default = working case limits) OR
- Treat machine as non-dispatchable
If working case limits are specified, PMAX and PMIN are set to default values for such machines
so that activity INLF will assign active power limits as described in Section 6.8.4 Governor
Response Power Flow Solution. If working case limits are to be treated as non-dispatchable, PMAX
and PMIN are both reported as zero so that activity section / INLF will treat such machines as fixed
MW output machines and will exclude them from participating in any swing bus power change
dispatches.
The appropriate output tabulation is then produced and activity RWDY is terminated.

When a Breaker Duty Data File is being written by activity RWDY, a data record is produced for each
machine in the working case which is modeled by one of the following generator models: GENROU,
GENROE, GENSAL, GENSAE, GENDCO, FRECHG, CIMTR1, CIMTR2, CIMTR3 or CIMTR4.
Machines modeled by other machine models are omitted from the Breaker Duty Data File.
When an Inertia and Governor Response Data File is being written by activity RWDY, a data record
is produced for each machine in the working case which is modeled by one of the following gener-
ator models: GENROU, GENROE, GENSAL, GENSAE, GENCLS, GENDCO, GENTRA, CGEN1,
FRECHG, CIMTR1, CIMTR2, CIMTR3 or CIMTR4. Machines modeled as a static var system, by
the CDSMS1, CSMEST, CBEST and CSTATT model, or by a user-written model are omitted from
the Inertia and Governor Response Data File. If the machine has a governor model other than the
SHAF25 model or a user-written model, governor response data is included in its data record; other-
wise, only the machine inertia is written and the remaining data items will take on default values
when the data file is read by activity section / INLF.
When a Relay Characteristic Data File is being written by activity RWDY, a data record is produced
for each occurrence in the simulation setup of any of the following line relay models for which the
branch is in the working case: CIROS1, SLNOS1, DISTR1, RXR1, SLLP1, and SLYPN1. A data
record is also generated for each RELAY2 and RELAY3 monitoring model reference generated by
activities CHAN and CHSB for which the monitored branch is in the working case. The 16-character
identifier fields are set by activity RWDY so as to identify the branch at which the model is applied.
For the line relay models, each identifier is set to the two bus numbers, the circuit identifier, and the
relay slot number, all separated by dashes (e.g., 7533-248-1-1). For the RELAY2 monitoring model,
each identifier is set to the two bus numbers and the circuit identifier, all separated by dashes (e.g.,
7533-248-1). For the RELAY3 model, each identifier is set to the number of the bus to which the
monitored winding is attached, the three-winding transformer name, and the circuit identifier, all
15-84
Program Operation Manual Listing Dynamics Model Storage Locations
separated by dashes (e.g., 7533-TRNSFRMR-1); the relay type field is set to RELAY2. These iden-
tifiers may be changed by the user to conform with the naming conventions and to assure
uniqueness.
Section 20.11, Creating Dynamic Data Records for Use by Other Activities
Section 17.10, Creating Dynamic Data Records for Use by Other Activities
15.21 Listing Dynamics Model Storage Locations

Activity MLST
Run Activity MLST - GUI

Dynamics>List>Model storage locations…
[List Model Storage Locations]
Run Line Mode Activity MLST - CLI

ACTIVITY?
>>MLST
>>

AB
The model listing activity MLST produces a tabulation of plant-related equipment models refer-
enced in the user’s simulation setup. The tabulation for each model includes a listing of the locations
in the various dynamics data arrays used by the model, and a flag for models which are bypassed
(refer to Section 15.7.8, Change Model Status).
The user may restrict the tabulation to active models, bypassed models, or both (refer to Section
15.7.8, Change Model Status).
In any of the subsystem selection modes the user may specify any of the following types of models:
• All machine models • Maximum excitation limiter models

• Generator models • Excitation system models
• Compensator models • Turbine governor models
• Stabilizer models • Turbine load controller models
• Minimum excitation limiter models
15-85
Initializing Models for Extended Term Simulation Program Operation Manual
Subsystem Selection) by bus subsystem, area, zone, owner, or basekV. Output for the appropriate
grouping of buses is produced with buses ordered as described in Section 4.9 Subsystem
Reporting. Then the user is given the opportunity to specify another subsystem.
If an owner subsystem is specified, the owners to which machines (rather than buses) are assigned
are used in defining the subsystem of machines to be processed. If a machine has multiple owners
(refer to Generator Data), its output is included in the block for each of its owners which is contained
in the specified subsystem.
For each model listed by activity MLST, the locations in the CON, STATE, VAR and ICON arrays
allocated to that model reference are printed. For any model which is bypassed (refer to
Section 14.7.8 Change Model Status), the model name is preceded by an asterisk (  ).
PSS®E GUI Users Guide, Section 20.12.3, Model Storage Locations
Section 17.11.3, Listing Dynamics Model Storage Locations
15.22 Initializing Models for Extended Term Simulation

Activity MSTR
Run Activity MSTR - GUI

Dynamics>Simulation>Perform extended term simulation (MSTR/MRUN)…
[Perform Extended Term Dynamic Simulation]
Run Line Mode Activity MSTR - CLI

ACTIVITY?
>>MSTR
ENTER CHANNEL OUTPUT FILENAME:
>>

AB, CM, NC, MO
The extended term dynamic simulation initialization activity MSTR initializes the dynamic models in
preparation for extended term simulation calculations. Activity MSTR is used in conjunction with
activity MRUN in performing these simulations. Refer to Section 18.10 Extended Term Simulations
of this manual, and the PSS®E Program Application Guide for additional details on extended term
simulations.
Activities MSTR and MRUN are special versions of the state-space simulation activities STRT and
RUN respectively which are used to perform extended term simulations. As such, their dialog and
operating characteristics are similar to those of activities STRT and RUN.
15-86
Program Operation Manual Initializing Models for Extended Term Simulation
Working memory requirements for activity MSTR are identical to those of activity STRT. The normal
activity sequence which precedes activity MSTR is:
1. Restore Dynamics Working Memory from a Binary Snapshot File (RSTR) < file1 >
2. Retrieve a Power Flow Saved Case File (CASE) < file2 >
where < file1 > is the Snapshot File containing the appropriate dynamics model data and output
channel specifications, and < file2 > is the Saved Case File containing the ordered converted power
flow case.
When initiated, activity MSTR first checks that:
1. The simulation time step is less than the intermediate time step mode threshold.
2. The long time step mode threshold is greater than the intermediate time step mode
threshold.
If either of these requirements is violated, an appropriate error message is printed and activity
MSTR is terminated.
Activity MSTR generates an alarm and terminates if generators are not converted. It then ensures
that the machine power arrays in the power flow working case are set to their original initial condition
values (they may have been changed by a prior execution of activity STRT or MSTR). Activity
MSTR completes its setup phase by checking for the presence of the factorized network admittance
matrix. If necessary, activity FACT (or activities section / ORDR and section / FACT) is executed.
Activity MSTR initializes the dynamic simulation by first doing a network solution and then, based
on the bus boundary conditions, initializing the Z-form integration cells (STOREs) and algebraic
variables (VARs) of each equipment model. If, in setting up for the initial network solution, any
CIMTR5, CIMWSC, CIM5xx, CIMWxx, or IEELxx model removes constant admittance load from the
load at which it is called, an appropriate message is printed and the network admittance matrix is
automatically refactorized prior to commencing the network solution.
The source current (ISORCE) of any such machine is set to zero. The presence of any such
machines renders the initial condition invalid, and activity MRUN will not allow itself to be executed
following such an initialization.
Similarly, any two-terminal, multi-terminal, VSC dc line, FACTS device, or any switched shunt
device that is in the continuous control mode, which is in-service in the working case but which
does not have a dynamic table model assigned to it generates an alarm with one of the following
error messages:
15-87

The presence of any such dc line, FACTS or switched shunt device could indicate one of the
following:
• A table model waswas ever assigned to the dc line, FACTS, or the switched shunt
device, or the model assigned is a CONEC and CONET called model. When this con-
dition is detected during activity MSTR, activity MRUN will allow itself to be executed.
limits (e.g., the voltage regulator output of the IEEE Type 1 excitation system model, IEEET1)
generates an alarm with a message of the form:
such error conditions before running a simulation. The presence of such error alarms renders the
initial condition invalid in the sense that the system is not in a steady state; that is, if activity MSTR
were to be followed by activity MRUN with no disturbances imposed, there would be movement as
the out-of-limits quantities are brought back to their appropriate limits. The exception is the
condition where the bus boundary conditions are such that the variable in question is initialized
exactly at its limit. Such a situation may occur, for example, when a generator is fully loaded and
its turbine mechanical power initializes precisely at its ceiling.
Activity MSTR then prints, at the Progress tab, the case heading followed by the message:
INITIAL CONDITION LOAD FLOW USED n ITERATIONS
A value of < n > greater than one usually (but not always) indicates some sort of modeling error.
This is especially true if the converted power flow network was solved with activity TYSL prior to
the execution of activity MSTR. (The network solution method used in the dynamic simulation is
identical to that used by activity TYSL, and the default convergence tolerance is an order of
magnitude smaller in section / TYSL.) The most common causes of this type of error are the same
as for activity STRT. The types of errors described above and all other initialization errors and
warnings should be resolved before executing simulations (refer to Application Notes).
Activity MSTR then summarizes the conditions at each online machine by tabulating the following
quantities:
• Power factor.
15-88
Program Operation Manual Initializing Models for Extended Term Simulation
The user specifies the Channel Output File to be used in the subsequent dynamic simulation run.
If no filename is specified in response to the above instruction, the writing of the output channel vari-
able values to a file is suppressed during the simulation run. Refer to Section 2.4.1 File Usage for
the file specification conventions used by activity MSTR.
The default time step in PSS®E is half a cycle (i.e., 0.008333 of a second when base frequency is
sixty cycles and 0.01 of a second for fifty cycle systems). Activity MSTR sets the value of simulation
TIME to minus two time steps. This provides for a period of simulation under steady-state conditions
prior to initiating a disturbance.
Activity MSTR responds to the following interrupt control codes:

NC
MSTR.
The format of the network convergence monitor is the same as that of activities section / TYSL,
section / SOLV, and STRT.
In the induction machine models CIMTR5, CIMWSC, CIM5xx, CIMWxx, CIMTR3, and CIMTR4, a
local iteration is used in extended term simulations to solve for the equivalent load drawn by the
model at each iteration of the network solution. The induction machine convergence monitor
tabulates the load or machine to which the model is connected, the local iteration number,
electrical torque (VAR(L+2)), and the real and imaginary components of the complex machine
internal voltage.

While a faithful system model is critical to all simulations, it is especially so in extended term simu-
lations because of their duration. As with state-space simulations, it is strongly recommended that
the system model data be validated using the techniques given in Sections 18.5.1 and 18.5.2.
Furthermore, because a steady-state check such as that performed during activity STRT is not
performed by activity MSTR, it is recommended that the initial condition operating point be checked
using techniques similar to those described in Section 18.5.3 Simulation Initialization. This involves
the following steps:
1. Using activity STRT to achieve a clean initialization.
2. Running a no disturbance state-space simulation of several seconds duration with activity

RUN.
15-89
3. Running a standard state-space simulation of at least ten seconds.
When these test simulation runs look reasonable, they should be repeated using the extended
term simulation activities MSTR and MRUN in place of activities STRT and RUN. The simulation
time step should not be changed during these first runs, and results should be essentially identical
to their state-space counterparts.
In any simulation setups containing user-written models which utilize STATEs, such models must
be modified to allow them to be used in extended term simulations. Refer to the PSS®E Program
Application Guide for details.
Most models supplied with PSS®E have been enhanced to allow their use in extended term
simulations. Several models, however, have not been so modified and any simulation setups
containing any of them may not be used in extended term simulations. Such models are listed
here, grouped as their data sheets appear in the PSS®E Model Library.
Table 15-4. PSS®E Models Unavailable for Extended Term

SimulationPOM_DynSim.fm
Generator and Compensator Models
CBEST CGEN1 CIMTR1 CIMTR2 CSMEST
CSTATT FRECHG GENDCO GENTRA
Stabilizer and Excitation Limiter Models

IVOST STABNI PSS3B UEL2 UEL1
PSS4B
Excitation System Models

BUDCZT EMAC1T EXNEBB EXNI IVOEX
REXSYS REXSY1 URHIDT AC7B AC8B
DC4B ST6B ST5B ST7B DC3A
Governor and Turbine Load Controller Models

HYGOV2 HYGOVM HYGOVT IVOGO SHAF25
TGOV4 TURCZT
Load Characteristic and Relay Models

CLODxx
Auxuliary Signal Models

RBKELT
DC Line Models
CDC1T CDCABT MTDC2T VSCDCT CDC7T
Generic Wind Models

WT3G1 WT3E1 WT3T1 WT3P1 WT1G1
WT2G1 WT3G2 WT4G1 WT2E1 WT4E1
WT12T1 WT12A1 WT4G2 WT4E2
15-90
Program Operation Manual Performing Extended Term Simulation in Time Steps

CHSVCT ABBSVC1
CONEC and CONET Models

CASEA1 CDC1 CDCAB1 CDCRL CDCVUP
CEELRI CHESVC CMDWAS DCPOW MTDC02
RBKELR
Activity MSTR generates an alarm for the use of any of the models listed above and sets a flag
such that activity MRUN will not allow itself to be executed. However, it is not able to detect the
presence of user-written models for which the code has not been modified for use in extended
term simulations. Moreover, it is likely that such models will result in other models behaving
incorrectly. The test simulation runs recommended at the beginning of this section are likely to
reveal this situation.
PSS®E GUI Users Guide, Section 21.6, Running Extended Term Dynamic Simulation
Section 18.3, Initializing Models for Extended Term Simulation
15.23 Performing Extended Term Simulation in Time Steps

Activity MRUN
Run Activity MRUN - GUI

Dynamics>Simulation>Perform extended term simulation (MSTR/MRUN)…
[Perform Extended Term Dynamic Simulation]
Run Line Mode Activity MRUN - CLI

ACTIVITY?
>>MRUN
>>

AB, CM, NC, MO, CH, TI
The extended term time simulation activity MRUN sequences through time solving the system’s
differential equations and the electrical network at each time step.
Activity MRUN requires the prior successful execution of activity MSTR. It also requires that the long
time step mode threshold be greater than the intermediate time step mode threshold, and that
15-91
Performing Extended Term Simulation in Time Steps Program Operation Manual
generators be converted. If any of these requirements is violated, an appropriate error message is

printed and activity MRUN is terminated.
The user specifies the four simulation options described in activity section / RUN. If the value spec-
ified for TPAUSE is less than the current value of simulation TIME, activity MRUN is terminated.
If a Channel Output File has been opened (in the most recent execution of activity MSTR or subse-
quently via activity ALTR), its filename is printed.
If the simulation time step has changed since the last execution of MRUN, both the old and new
time steps are listed along with simulation mode to be used (refer to Section 18.10 Extended Term
Simulations).
Activity MRUN checks for islands which contain no in-service machines, generates an alarm for
buses in such islands, and disconnects them.
If activity MRUN is operating in the uniform island frequency mode, the number of energized islands
in the system is determined and each non-Type 4 bus is assigned to an island. Up to ten such
islands are permitted.
Activity MRUN completes its setup phase by checking for the presence of the factorized network
admittance matrix. If necessary, activity FACT (or activities section / ORDR and section / FACT) is
executed.
Activity MRUN responds to the following interrupt control codes:
value of TPAUSE which was specified at the time activity MRUN was run. In addition, if PSS®E
AB
NC
MRUN.
MO Print the induction motor local iteration convergence monitor.
time activity MRUN was run is overridden while this option is in effect. When this option is
CH
The form of the network convergence monitor is identical to that of activities STRT, RUN, MSTR,
section / TYSL, and section / SOLV in the small and intermediate time step modes. In the large
time step (uniform island frequency) mode, each convergence monitor line is extended to include:
15-92
Program Operation Manual Performing Extended Term Simulation in Time Steps
• The magnitude of the largest machine angle change as a multiple of the island fre-
quency convergence tolerance.
• The number of the bus with the machine experiencing the largest angle change.
• The largest machine angle change.
The form of the induction machine convergence monitor is identical to that of activity MSTR.

As discussed in Application Notes, before executing extended term simulations with a system
model, state-space simulations should be performed. A steady-state run of several seconds and a
reference standard simulation of at least ten seconds are recommend. After any suspect modeling
has been resolved, this pair of simulations should be repeated in extended term mode using the
same time step as was used in the state-space simulations.
Activity MSTR sets the output control variables NPRT and NPLT to one, and CRTPLT to zero. On
the first subsequent execution of activity MRUN, these values are the defaults for these variables.
On following executions of activity MRUN, these variables reset to its default values, those values
specified on the previous execution of activity MRUN.
Whenever the value of simulation TIME reaches the time specified for TPAUSE, the transfer func-
tion output and network solution calculations are performed with a flag set to inform the simulation
that this is a t- calculation; the Z-form integration array elements (STOREs) are not updated.For any
of the channel output options which are active, the appropriate output is generated regardless of
whether the present time step is a print or plot time step as determined by the variables NPRT, NPLT
and CRTPLT. When activity MRUN is reentered, with perhaps some switching operation having
been specified, the time step is repeated as a t + calculation. Appropriate channel output is
performed at the completion of the time step as determined by the new specification of the output
control variables. This applies both for the case in which activity MRUN has advanced TIME to the
value specified for TPAUSE and when interrupted by the user.
It is permissible to change the simulation time step, DELT, during an extended term simulation run
(refer to Section 18.10 Extended Term Simulations). Time step increases should be implemented
only after the higher frequency oscillations have been reduced; decreasing the time step is
permitted at any point in the simulation. It is strongly recommended that all disturbances and major
switchings be modeled only in the small time step mode.
Care must be taken in modifying the time step thresholds during extended term simulations. It is not
valid to change the time step thresholds such that a new simulation mode results for the simulation
time step in use before the threshold change. For example, t- values of:
• DELT = 0.07.
• DLTBKW = 0.05.
• DLTEXT = 0.1.
would have resulted in machines being modeled in the intermediate time step mode. Changing
DLTBKW to 0.06 or DLTEXT to 0.09 would be valid; changing DLTBKW to 0.08 or DLTEXT to 0.07
would not.
A typical extended term simulation might start with the default time step of half a cycle and would
initially be performed just as a state-space simulation would, except that activity MSTR and MRUN
are used in place of activities STRT and RUN. After the higher frequency effects have more or less
subsided, the simulation time step is increased so that running time is reduced. If another distur-
15-93
Performing Extended Term Simulation in Time Steps Program Operation Manual
bance or switching is to be applied, it is prudent to reduce the simulation time step so that the higher
frequency effects may again be modeled and observed; otherwise, dynamic instabilities may be
completely masked out.
When changing the simulation time step, particularly into and out of the long time step (uniform
island frequency) mode, bumps may occur on plotting simulation results at time coordinates where
modeling assumptions were changed. Usually, these are minor and any oscillations introduced die
out relatively quickly.
Longer time steps may require more network solution iterations than the default maximum allowed
and/or some deceleration of the network solution. These parameters may be changed with activity
ALTR. In the long time step mode, note that two acceleration factors and tolerances are involved
(refer to Section 18.10 Extended Term Simulations). Acceleration factors should be tuned using the
guide given in Section 6.3.18 Characteristics of Activity SOLV.
There are several PSS®E models which activate automatic switchings (e.g., blocking or unblocking
of a dc line by a dc line model, branch tripping by a relay model, load shedding, generator tripping,
and so on). When one of these switchings takes place, a dual time step calculation is performed as
described above. If a Channel Output File is active, the output channel values are written to it for
both the pre and postswitching time step calculations made at the switching TIME; similarly, CRT
plotting takes place for both the pre- and post-switching time step calculations.
As described above, it is appropriate that switchings be implemented in small time step mode; this
is not so critical for load shedding and capacitor or reactor switching. In simulations where relays
are being modeled, it is recommended that Snapshots and Saved Cases be preserved periodically
during the simulation. Because relay action cannot always be anticipated, this allows the user to
back up and repeat part of the simulation with a smaller simulation time step without having to rerun
the entire simulation.
Both upon entering activity MRUN and before performing the t+ time step calculation following auto-
matic switchings, activity MRUN checks for islands which contain no in-service machines,
generates an alarm for buses in such islands, and disconnects them. It then calculates a new spar-
sity-preserving ordering (activity section / ORDR) and rebuilds the factorized admittance matrix
(activity section / FACT).
If an automatic line switching occurs in uniform island frequency mode which causes changes in
the island assignments of buses (e.g., if a new island is defined), results are unpredictable. Estab-
lishing the relationship of buses to islands occurs only upon entry into activity MRUN and not
following automatic switchings.
If the network solution fails to reach its tolerance in the prescribed number of iterations, an alarm is
printed and the simulation continues as though convergence had been achieved. Refer to
Section 18.7 Running a Simulation for additional details.
The computer time per simulation time step is much longer in extended term simulations than it is
in state-space simulations. However, extended term simulations can achieve significant execution
time advantages over state-space simulations when there are significant periods of simulated time
where a much larger simulation time step is appropriate.
15-94
Program Operation Manual Changing Dynamics Model Constants
PSS®E GUI Users Guide, Section 21.6, Running Extended Term Dynamic Simulation
Section 18.4, Running Extended Term Simulation in Time Steps
15.24 Changing Dynamics Model Constants

Activity CCON
Run Line Mode Activity CCON - CLI

ACTIVITY?
>>READ
ENTER BUS NUMBER, MACHINE ID (0 TO EXIT):
>>

None
The dynamics data modification activity CCON allows the user to display and modify the constant
data values being used by plant-related models contained in the simulation setup.
Activity CCON uses the CRT terminal lines per page option setting to group data items into pages.
When a model is selected, any CONs which it uses are processed first, followed by its ICONs. If the
model uses both CONs and ICONs, the ICON display always starts on a new page.
The user specifies the bus and machine identifier of the machine where plant-related model data is
to be examined. The user specifies a model for any equipment being modeled at the machine. The
constant data associated with the selected model is displayed.
The user may change the value of any of the displayed data items by entering its code as shown
on the display along with the new value. The data display is repeated with the new data value.
The user continues with data changes as prompted by the dialog. Except for a response of -1 when
the -1 FOR ICONS response is valid, any negative response is treated the same as a response of
zero.

When changing the ICON values of a model, the user may specify either integer or character
constants. Character ICON values must be entered as one or two alphanumeric characters
enclosed in single quotes (e.g., ’H’).
When activity CCON builds the display for a selected model, information on the number of CONs
and ICONs it utilizes is taken from the internal tables describing the standard PSS®E models or
from the user model definition table. Similarly, the starting CON and ICON array indices used by the
model are obtained from the array allocation table (refer to activity DYCH).
The descriptive information on each data item is read from a binary file named MODELS (on most
systems, this file has the extension RWF). When initiated, activity CCON searches the current
15-95
Assigning Subsystem Simulation Data to Output Channels Program Operation Manual
directory for this file. If the file is not found locally, activity CCON follows the directory search
sequence described in Section 2.1 Directories and Files Overview.
As supplied with PSS®E, the MODELS file is located in the PSS®E master directory and contains
descriptive data for plant-related models distributed with PSS®E; it does not, of course, contain
information on any other user-written models which may be included in your simulation setup. When
using this MODELS file, CONs of user-written models for which the descriptive information is not
contained in the file are described as J, J+1, J+2, and so on, and ICONs are described as M, M+1,
and so on.
With the auxiliary program DBUILD, users may construct customized MODELS files which include
descriptive information on their user-written models. With such a customized MODELS file in the
user’s current or home directory, activity CCON automatically accesses the user’s copy rather than
the MODELS file as supplied on the PSS®E installation tape. Details on the operation of DBUILD
may be found in Additional Resources for PSS®E, section / DBUILD.
Section 17.8, Changing Dynamics Model Constants
15.25 Assigning Subsystem Simulation Data to Output Channels

Activity CHSB
Run Activity CHSB - GUI

Dynamics>Define simulation output by subsystem (CHSB)
[Select Channels by Subsystem]
Run Line Mode Activity CHSB - CLI

ACTIVITY?
>>CHSB

None
The output channel selection activity CHSB enables the user to select either simulation variables
which are to be monitored during dynamic simulation runs on a subsystem basis, or certain
machine angle-related quantities. These quantities may be tabulated, placed into a Channel
Output File and/or plotted at the terminal at regular intervals during a simulation run (refer to
activity RUN). The simulation results, as contained in the Channel Output File, are able to be
processed by the plotting package provided with PSS®E.
15-96
Program Operation Manual Assigning Subsystem Simulation Data to Output Channels
15.25.1 Operation of Activity CHSB

The user identifies quantities to be placed into output channels and activity CHSB places their
memory addresses and alphanumeric identifiers into the PSS®E dynamics data arrays IPRINT and
IDENT respectively.
The user may specify starting indices for the output channel and associated VAR and ICON or keep
the default settings, which are the next available location pointers for the corresponding dynamics
data arrays (refer to Section 15.1.2, Operation of Activity DYRE and activity SNAP). In a simulation,
output channels are assigned sequentially starting with channel one. By default, activity CHSB
assigns locations in these arrays at their next available positions.
Machine, Bus, Load, and Branch Quantities

• Angle • Bus frequency deviation • Active power command from
• Pelec • Voltage wind control
• Qelec • Voltage & Angle • Wind turbine speed
• Eterm • Mach Iterm • Wind pitch
• EFD • Machine Apparent • Wind aerodynamic torque
• Pmech Impedance • Wind rotor voltage
• Speed • Vuel • Wind rotor current
• Xadifd • Voel • Wind real power command

• Pload from electrical control
• Ecomp
• Qload • Wind reactive power
• Vothsg command from electrical
• Vref • Gref control
• Lcref • Wind auxiliary control output
Machine, Bus, Load, and Branch Quantities

Tie Line Quantities
• Flow (P) • Flow (MVA) • Relay2 (R&X)
• Flow (P&Q)
The user specifies any of the following quantities for monitoring:
In addition, the user may specify the inclusion of out-of-service equipment. Otherwise, output chan-
nels are generated only for in-service machines, loads, buses or branches, as appropriate. The
default is in-service equipment only.
For load and generating-plant quantities, activity CHSB processes all elements in the selected
subsystem. For bus quantities, activity CHSB processes all buses in the specified subsystem. For
branch quantities, activity CHSB processes all branches where endpoint buses are in the specified
subsystem. Output channels are generated, and then the user may select another type of quantity,
service status option, and, if appropriate, subsystem.
Note that categories Voltage & Angle, Flow (P&Q), Relay2 (R&X), and Machine Apparent Impedance
generate two output channel assignments for each element selected for monitoring.
15-97
When processing branches between areas or zones, the user must specify ties from either areas
or zones, as appropriate, using the methodology given in Section 4.8 Subsystem Selection. The
selected branch quantity or quantities for all tie branches from each specified area or zone are
placed into output channels.
Subsystem power totals may be specified by area, zone, owner, or all buses. This produces
summations by subsystem of: machine electrical power, machine mechanical power, accelerating
power, and load demand.
If machine angle statistics are specified, the following quantities are selected for monitoring:
• Average angle • Smallest angle

• Largest angle • Bus with smallest angle
• Bus with largest angle • Angle spread
Activity CHSB supplies a channel identifier for each output channel that is generated. These
identifiers are the same format as the default identifiers generated by activity CHAN (refer to Table
15-2 Activity CHAN Summary).
Following the completion of the channel selection process, activity CHSB summarizes the next
available positions in the pertinent arrays as a result of its current execution.
The value of the solution parameter NCHAN indicates the highest numbered channel being
monitored during simulations (refer to activity ALTR and Section 18.6 Simulation Outputs), is set to
NCHAN-1.
When activity CHSB is being used to change the channel assignments of a subset of previously
generated output channels, the value printed for < NCHAN > is the larger of the original next
available channel and that which would be set as a result of the current execution of activity
CHSB.

As shown in , values for Angle, Pelec, Qelec, Eterm, EFD, Pmech, Speed, Xadifd, Ecomp, Vothsg,
Vref, Vuel, and Voel of activity CHSB’s output category selector designate quantities associated
with generating plant equipment models.
Values for Pload and Qload designate the active and reactive load quantities associated with each
load in the network. In the PSS®E dynamics data structure, there are dedicated arrays containing
each of these quantities for each machine and load in the working case. These data items are auto-
matically calculated by the various equipment models used to model each machine and its controls
and by the various load characteristic models applied to loads in the network (refer to Section
15.1.2, Operation of Activity DYRE and Section 19.4.1, Subroutines TBLCNC and CONEC). Activity
CHSB simply sets up the appropriate address pointers in the dynamics data array IPRINT so that
the channel output routine picks up the proper values.
Similarly, bus frequency deviation is stored in a dedicated array for each bus in the working case,
and activity CHSB sets up the appropriate pointer.
15-98
However, values for Voltage, Voltage & Angle, Flow (P), Flow (P&Q), Flow (MVA), Relay2 (R&X),
Mach Iterm, and Machine Apparent Impedance, as well as totals by subsystem, specify data items
that are not readily accessible from the standard dynamics data arrays. For these quantities to be
available as output channel variables, they must be calculated and placed into a data array which
can be accessed by the channel output routine. This function is performed by a group of network
monitoring models which calculate certain network quantities and place them into specified loca-
tions in the VAR array.
Thus, when activity CHSB is programmed to place bus voltages, branch flows, branch apparent
impedances, machine currents, machine apparent impedances and subsystem powers into output
channels, it takes the following steps:
1. It allocates positions in the ICON array and sets these elements to the values required to
designate the bus, branch, machine, or subsystem to be monitored.
2. It allocates positions in the VAR array which are to contain the monitored -quantities.
3. It generates entries in the CHAN monitoring model tables for the appropriate model call
(VOLMAG, FLOW1, FLOW3, RELAY2, RELAY3, GENTMC, GENTMZ, PTOTOW, PTOTZN,
PTOTAR, or PTOTAL).
4. As with the other data categories, it establishes the appropriate IPRINT and IDENT array
entries.
During dynamic simulations, model calls corresponding to the model references contained in the
CHAN monitoring model tables are issued each time step at the completion of the network balance.
Thus, after being selected by activity CHSB, these network quantities are automatically calculated
during dynamic simulation runs and placed into output channels.
VARs and STATEs are not valid options in activity CHSB. In order to assign VARs and STATEs to
output channels activity CHAN must be used.
As activity CHSB assigns each selected simulation quantity to an output channel, it makes a corre-
sponding entry in a set of channel descriptor arrays. These arrays describe the type of quantity
assigned to the channel, and its location in the network in terms of external bus numbers, machine
and circuit identifiers, and so on. These arrays are also used in describing the content of each
channel in activities ALTR and DLST.
This information is also used to reconcile differences in the PSS®E internal numbering scheme
which may exist when a Saved Case is retrieved for which the internal storage of network quantities
differs from that which was contained in the working case during the execution of activity CHSB.
This reconciliation occurs at the execution of activities RSTRRSTR, SRRS, and RTRN (see also
Application Notes) whenever both network and dynamics data have been read into PSS®E working
memory.
When the value specified as the starting channel index exceeds the next available channel value
contained in dynamics working memory, the channels in this gap have their IPRINT, IDENT and
channel descriptor array entries set so as to leave the channel unused. Dynamic simulation quan-
tities may be assigned to such channels in subsequent executions of activity CHAN or CHSB using
the approach given at the end of Section 15.2.1, Operation of Activity CHAN and Section 15.25.1,
Operation of Activity CHSB.
As in activity DYRE (refer to Section 15.1.3, Adding Models), the user should take care to take a
Snapshot following successful execution of activity CHSB and prior to terminating PSS®E. If a
15-99
Snapshot is not taken, the newly established IPRINT, IDENT, ICON and channel descriptor array
entries are not preserved and activity CHSB will need to be re-executed.
The user must exercise caution in specifying the starting VAR and ICON indices in response to the
input request issued by activity CHSB. In particular, the location indices specified and successive
locations in the respective arrays must not be used by other models. For simulation execution effi-
ciency, it is desirable that the locations specified be the next available slots in the respective data
arrays. Thus, the normal specification of these indices is to enter the default response.
As can be seen in the use of activity CHSB, as well as in the requirements of activity CHAN, SNAP,
and DYRE, it is strongly recommended that the next available position indices maintained within
each Snapshot be used whenever possible. PSS®E is able to perform the bookkeeping required
for the storage allocations assigned by activities DYRE, CHAN, and CHSB. It is the user’s respon-
sibility to update these indices, with activity ALTR, whenever models or user written code utilizing
additional dynamics data array elements are manually added to the connection subroutines.

During its dialog, activity CHSB generates an alarm for errors resulting from the following condi-
tions:
1. In allocating an output channel, the preceding channel selection used the highest numbered
output channel for which PSS®E is currently dimensioned. The following error message is
printed and activity CHSB is terminated:
ALL CHANNELS USED

enough ICONs remaining to accommodate those required by the model call. The following
message is printed:
nnnn IS END OF ICON ARRAY

enough VARs remaining to accommodate those required by the model call. The following
message is printed:
nnnn IS END OF VAR ARRAY

4. In selecting for output a quantity requiring a network monitoring model call, the table accom-
modating the CHAN
monitoring model references is full. The following message is printed:

nnnn MONITORING MODELS SPECIFIED--POINTER TABLE FULL
5. In selecting angle statistics, the following message is printed if the function was previously
selected:
ANGLE STATISTICS STARTING AT VAR nnnn ALREADY IN CHANNELS
®
Section 17.2.2, Subsystem Simulation Data
15-100
15-101
15-102
Chapter 16
Program Automation
Chapter 16 - Program Automation
16.1 What is Program Automation?

Program automation in PSS®E provides the mechanism to control PSS®E execution other than by
direct user interaction. This is the ability to define a set of operations for PSS®E to perform in a file
of some kind (explained in the following sections) and to tell PSS®E to use the instructions in that
file as a single command. We will call these files Automation Files. There are two primary ways to
use Automation Files:
• As a program extension. In this case the user, in the course of using the program inter-
actively, can decide to select an existing Automation File as the next instruction to the
program.
• For un-attended execution. This is commonly called batch execution. In this case the
entirety of the user’s interaction would be the specification of the source of the instruc-
tions for it to execute (although there may be other options specified at the same time).
Although there are a few minor exceptions, for the most part the specification of the instructions, i.e.
the contents of the Automation File, is the same in both cases.
The following sections will concentrate on the first alternative. Near the end of the chapter is a
section on batch execution. There is also a section on entering single commands; while not a
program automation method it uses the commands defined here and is best understood in this
context.
16.2 Controlling PSS®E Execution Using the API

Activity Application Program Interface
An Application Program Interface (API) is a set of callable routines for building software applica-
tions. PSS®E has a supported, documented API available for use with PSS®E. The API is the
primary and recommended method for accessing PSS®E functionality for automation. The PSS®E
API is described in PSS®E Application Program Interface (API). That manual includes descriptions
of the syntax for using each API routine in each automation method in which it is supported. Not
every API routine is supported in every automation method.
In most cases the API manual will also describe the syntax for calling an equivalent Fortran
subroutine.
16-1
Program Automation PSS®E 34.2
Automation Methods in PSS®E Program Operation Manual
Siemens PTI will support users who make use of the API through the automation methods
described here, such as batch commands and Python programs, only. No support is provided
for Fortran or, say, C applications developed by users of PSS®E.
16.3 Automation Methods in PSS®E

Activity Automation Methods
There are six automation processors in PSS®E:
• An embedded Python interpreter (refer to Section 16.4 Python Programs)

• The Batch (or BAT_) Command interpreter (Section 16.5 Batch Commands)
• The Line Mode Interpreter (LMI) (Section 16.11 Line Mode Commands)
• The PSS®E Engineering Basic (PSEB) macro processor (Section 16.14 Building a
Response File, Power Flow Calculation)
• The PSS®E Simulation Run Assembler (PSAS) macro processor (Section 16.15
Building a Response File, Dynamic Simulation)
• The IPLAN simulator (Section 16.16 Launching an IPLAN Program File)
Only five file types are available in the GUI, because line mode commands and batch commands
can be intermingled in the same file, so the Response File file type (*.idv) is used for either (or both).
Some general observations are appropriate at this point:
• Python and IPLAN are both programming languages, i.e. they can be used to write any
kind of a program, not just control PSS®E (although IPLAN’s features are fairly limited,
relatively speaking).
• IPLAN programs must be compiled (they do not need to be linked). The compiler
(called IPLAN) is a Siemens PTI product and supplied with PSS®E. The source files
are of file type *.ipl. The result (*.irf) are not object code files in the normal sense, but
a unique format.
• Python programs are interpreted (one command at a time is executed - no compilation
is necessary); although Python does support optional byte-compilation.
• PSEB and PSAS commands can also be embedded in Response Files, albeit in a par-
ticular context.
• Python programs can use existing IPLAN programs and Response Files. The other
automation methods can all interact with each other.
• Response Files, PSAS, and PSEB Command Files are free-format data files.
16.4 Python Programs

Python is an OSI certified, freely available, object-oriented, interpreted programming language. Its
syntax and usage are well-documented on the web and in numerous publications, so we will
concentrate here solely on its interaction with PSS®E.
A Python installer is included in the PSS®E program installation package for your convenience. The
language can also be downloaded from the official Python site at http://www.wxpython.org/. Python
language documentation, extension modules, book recommendations, and user forums are also
available directly from this site. Siemens PTI recommends the following textbooks for reference:
16-2
PSS®E 34.2 Program Automation
Program Operation Manual Python Programs
• Learning Python - Lutz and Ascher

• Python Essential Reference - Beazley
• Programming Python - Lutz
• Python in a Nutshell - Martelli
• Python Cookbook - Martelli and Ascher
• Python Programming on Win32 - Hammond and Robinson
Siemens PTI supports the use of Python programs within PSS®E, however, the language
itself is not supported nor maintained by Siemens PTI staff.
The PSS®E installation package will also install the following freely available third-party extension
modules:
• wxPython (http://www.wxpython.org//)
• win32all (Python Extensions for Windows) (http://sourceforge.net/projects/pywin32/)
Python files can be in source form (*.py, *.pyw) or byte-compiled (*.pyc). Python Files can be used
in PSS®E in any of the following ways:
• From Run Program Automation File… (see Section 16.3 Automation Methods in
PSS®E)
• At program startup by using the -pyfile option (see Section 16.9 Unattended Execution
of PSS®E)
16.4.1 PSS®E Extension Modules For Python

One of Python’s greatest strengths is its ability to be easily extended. These extensions can be
written in Python or in system languages (C/C++, Fortran, etc.). Libraries and legacy code can be
therefore be made accessible in Python. It is also an excellent transition language in that it can
communicate with other programs and processes (e.g. Microsoft® Excel). Extensions are accom-
plished through the creation and use of packages that Python calls modules.
Many extension modules are currently available on the Internet for download including: numeric
processing and optimization, graphic and data visualization (plotting), database connectivity, graph-
ical user interface programming, XML and text processing, network programming and connections
to Microsoft® Excel and Microsoft® Access.
Your PSS®E installation will include the following Python extension modules, documented in
PSS®E Application Program Interface, that can be imported into user programs inside or outside of
the PSS®E GUI:
• excelpy - provides Python functions to interface with Excel; these functions can be
used to create, populate and format Excel workbooks from Python.
• pssarrays - provides Python functions to retrieve PSS®E solution results
• pssexcel - provides Python functions to export PSS®E data or solution results to
Microsoft® Excel spreadsheets.
• pssplot - provides access to the PSS®Plot API
• psspy - provides access to the PSS®E API
16-3
Python Programs Program Operation Manual
Your PSS®E installation will also include the following Python extension modules which can also be
imported into user programs inside or outside of the PSS®E GUI:
• bsntools - a set of simple bus name manipulation tools

• caspy - provides access to the Saved Case Data Extraction routines (USRCAS)
• dyntools - tools for processing channel output files
• excelexport - provides a graphical user interface to PSSEXCEL for exporting PSS®E
results into Excel® spreadsheets.
• gicdata - help to create GIC data file applicable to a specific PSSE Power Flow Net-
work Case for an entire network or just desired study subsystem.
• plot2word - provides a graphical user interface to WORDPY for inserting plot/picture
files into a Microsoft® Word document.
• pssgrpg - provides functions intended to be used to supply valves to report nodes on
I-line diagrams
• redirect - some tools to connect I/O streams between PSS®E and Python
• sliderPy - provides functions to directly manipulate diagram elements
• wordpy - provides Python functions to interface with Microsoft® Word; these functions
can be used to create, populate, and format a Microsoft® Word document from Python.
This is especially useful to insert plot files (*.eps, *.wmf, *.png, etc.) created by
PSSPLT/PSSPLOT or any picture file into a Word document.
These modules are fully supported as part of the PSS®E program product. There are other Python
modules and programs that are supplied with PSS®E that either support the above modules or are
used by other program features. Modules that are designed as standalone programs are also
supplied. In addition you will find several *.py files supplied in the Example directory for you to use
and modify as you see fit.
Each of the modules above provides built-in documentation which can be accessed via the Python
help command. In the case of psspy, however, the result will be too voluminous to be useful. A
summary is available by entering:
help(psspy.psspyc)
Help is also available for individual API routines, e.g:
help(psspy.pout)
Some features of the psspy module that are not part of the API itself are documented in the doc
string for psspy. Enter:
print psspy.__doc__
16-4
Program Operation Manual Python Programs
16.4.2 The Embedded Interpreter Environment

PSS®E contains an embedded Python interpreter. This is what allows PSS®E to execute Python
files and commands. When the PSS®E GUI is started, it initializes the Python interpreter and
executes a few initial commands. Those commands are:
import sys
sys.path.append(pathname)
import os
import psspy
_i=psspy.getdefaultint()
_f=psspy.getdefaultreal()
_s=psspy.getdefaultchar()
import redirect
redirect.py2psse()
import pssplot
import excelpy
import gicdata
import sliderPy
(where pathname is a variable containing a value retrieved from the registry; you will generally not
need to be concerned with this)
When the PSS®E Command Prompt program is started, it initializes Python in a similar way, but
does not include the pssplot, excelpy, and sliderPy modules as they require the GUI execute
correctly.
The os and sys modules are supplied with Python and contain commonly used functions for
accessing operating system features. The other modules are defined above. The use of the _i, _f,
and _s variables is explained in the section about default values in Python Files, below, and in the
PSS®E Application Program Interface (API). The redirect.py2psse() function causes Python’s stdin
(standard input) to use the function userin from the psspy module (psspy.userin) and Python’s
stdout (standard output) and stderr (standard error) to be redirected to PSS®E’s progress device.
Note in particular that none of the modules are imported into the local name space. That means, for
example, that to use a PSS®E API routine defined in the API manual as, say:
ierr = abc()
You would need to reference it as:
ierr = psspy.abc()
This is in keeping with standard practice for the Python community.
A Python program is shown below that performs the following:
16-5
Python Programs Program Operation Manual
1. Read a PSS®E Saved Case file, savnw.sav, into working memory.
2. Solve the power flow.
3. Loop through the buses and print the bus number and area to the Report tab.
psspy.case('savnw.sav')
psspy.fnsl((0,0,0,1,1,0,99,0))
psspy.inibus(0)
while 1:
ierr,busnum,busname = psspy.nxtbus()
if ierr!=0: break
ierr,busarea = psspy.busint(busnum,'AREA')
psspy.report('%s %s' % (busnum,busarea))
One idiosyncrasy of the current embedded interpreter is that results are not automatically echoed
to the terminal as they are in the stand-alone Python interpreter. To view the values of expressions
you must use the print command.
16.4.3 The External Interpreter Environment

Python programs that access PSS®E functions can be used without starting the PSS®E GUI.
Python is installed with its own command line interpreter, its own integrated Development Environ-
ment (IDE) - called IDLE -, and programs can be written to create their own GUIs. Any of these can
use the PSS®E supplied extension modules shown above.
In order to use the PSS®E supplied extension modules in this way, you must first make sure that
the Python import path can find all the modules by name, and that the windows load path can find
any required DLLs. The following example initializes PSS®E in the Python command line
interpreter:
>>> import psse34
>>> import psspy
>>> import redirect
>>> _i=psspy.getdefaultint()
>>> _f=psspy.getdefaultreal()
>>> _s=psspy.getdefaultchar()
>>> redirect.psse2py()
>>> psspy.psseinit(80000)
This example assumes a starting bus size of 80000. Other values could have been chosen. It omits
python built-in modules os and sys, which you can certainly use if you need to. It also omits other
PSSE supplied modules. Other than gicdata, the other modules imported in the GUI only work with
the GUI.The other commands are typically used. The only absolutely critical statements are the
import psse34, import psspy and the call to psseinit.
16-6
Program Operation Manual Batch Commands
The import of pssplot is omitted in the example above because its functions depend on the PSS®E
GUI and cannot be used in this mode. There are some graphics functions in psspy for which this is
true as well.
16.4.4 The Embedded Interpreter Version

For PSS®E versions 31, 32, and 33 the standard interpreter supplied for python has incompatible
with the PSS®E GUI. As a result we have supplied a rebuilt copy of the interpreter that is installed
with PSS®E. When you run the GUI, you are using this rebuilt interpreter. When you use the
external interpreter, you are running the native installed version.
For most uses you will see no issues. However, certain third party modules (which ones is very diffi-
cult to predict) will not load in the GUI for the same incompatibility reasons.
Starting with release 33.4.0, a new command line switch has been supplied to allow you to run any
of several versions of Python with PSS®E, including the native interpreter for 2.7, the version that
we supply a rebuilt copy of. Through some internal conversions that we have developed, most of
the original problems have been avoided. If you specify no command line switch then you will still
get the rebuilt interpreter. The shortcut in the Start Menu will specify -pyver 27.
16.4.5 Finding user-created modules

If you wish to write your own modules for import into PSS®E or your scripts, you have a the following
choices.
1. The startup directory should be on the import path. Files located there should be found.
2. The PYTHONPATH environment variable is added to the front of the import path. PSS®E
will add it's paths in the PSSE install tree ahead of those in PYTHONPATH. You may place
multiple paths here - separate them with a semi-colon.
3. When you are running a script, an empty string (indicating the current directory) should be
temporarily added to the front of the install path.
4. The import path list is accessible and can be modified. It is sys.path. Care will need to be
exercised when changing this.
5. You can add your module in the site-packages directory of your Python installation.
6. You can add a path configuration file to the site-packages directory of your Python
installation.
There are actually several other methods, but they require changes either to the registry or the
Python installation itself.
16.5 Batch Commands

Activity Batch Commands
Batch commands are free-format forms of inputs to the PSS®E API. What this means is best illus-
trated by an example.
Let’s say there is a PSS®E API routine called abcd. It takes an integer argument (IVAL), a two-
element integer array (IDATA) and returns a floating-point value and an integer return code. The
batch command syntax for this hypothetical API routine would be:
16-7
Recording Program Operation Manual
BAT_ABCD IVAL IDATA(1) IDATA(2)

In other words, three integers after the command name that correspond to the arguments IVAL, the
first element of IDATA and the second element of IDATA, respectively. The returned values are not
represented. Furthermore, if the function of the API routine was only to return those values, then
there will not be a batch command syntax defined for it. The reason for this is that the batch
commands are not a language; there are no variables or logic controls. A batch command is really
data to the batch command interpreter, which then calls the indicated API routine with the input
values defined after the command name.
The format of the batch commands is the same as the standard free-format rules used for all
PSS®E data files. The following additional rules apply to batch commands, though:
• The command name itself is case insensitive, i.e. it doesn’t matter whether you use
upper case or lower case letters, or mix them (the documentation will always define
them as all upper case).
• The commands may be continued on multiple lines. The interpreter keeps reading data
until all the arguments that it needs for a given API routine are satisfied.
• There is a special token, a semi-colon, that can be used to tell the interpreter that it
should return all remaining inputs to default settings for that particular API routine. It
must be a separate token, not part of the previous value. In our example above,
BAT_ABCD 1 34 ;
will reset the third value to the default value, but
BAT_ABCD 1 34;
will return a syntax error because 34; is not a valid integer.
Batch commands can be used in Response Files or entered as Command Line input.
16.6 Recording
Activity Recording
The PSS®E interface is capable of recording PSS®E API commands. Recorded API commands
can be in the form of either Python statements or batch commands (Response File) depending on
a specified user option. The easiest way to record a Python script (*.py, for Python statements) or
a Response File (*.idv, for batch commands) for later execution is to use the I/O Control>Start
Recording… option. Selecting this option will start the recorder. The entry of subsequent selections
of PSS®E commands will record the API routines used to an automation file for later use until the
I/O Control>Stop Recording option is selected.
As an example, suppose you wanted to print power flow results to the Report View for buses 101,
201, 205, 154, and 3001. To record these interactions:
1. Select I/O Control>Start Recording… and select the type of file you wish to record: Python
File (*.py) or Response File (*.idv).
2. Specify, say, busout.idv or busout.py as the filename depending on your selection of file type
in Step 1, and open it.
3. Select File>Open, select savnw.sav, and open it.
16-8
Program Operation Manual Argument Passing
4. Select Power Flow>Solution>Solve. The power flow solutions dialog is displayed. Solve it
and then close it.
5. Select Power Flow>Reports>Bus based reports…. The bus based reports dialog is displayed.
Enter buses 101, 201, 205, 143, 3001 in the text box provided. Select Go and then close it.
6. Select I/O Control>Stop Recording.
Using a text editor, open the file busout.idv (Figure 16-1) or busout.py (Figure 16-2) and you will see
the following:
@! File:"C:\Program Files\PTI\PSSE31\EXAMPLE\busout.idv", generated on TUE, AUG 17 2004 15:41

BAT_CASE,'C:\Program Files\PTI\PSSE31\EXAMPLE\savnw.sav'
BAT_FDNS,0,0,0,1,1,0,99,0
BAT_BSYS,1,0,0.0,0.0,0,5,101,201,205,154,3001,0,0
BAT_POUT,1,0
Figure 16-1. Response File Recorded by PSS®E
# File:"C:\Program Files\PTI\PSSE31\EXAMPLE\busout.py", generated on WED, AUG 18 2004 15:13

psspy.case(r"""C:\Program Files\PTI\PSSE31\EXAMPLE\savnw.sav""")
psspy.fdns([0,0,0,1,1,0,99,0])
psspy.bsys(1,0,[0.0,0.0],0,[],5,[101,201,205,154,3001],0,[],0,[])
psspy.pout(1,0)
Figure 16-2. Python File Recorded by PSS®E
16.7 Argument Passing

Activity Argument Passing
Arguments can be passed to a response file by using the Arguments button located on the
[Select Program Automation File to Run] dialog.
Arguments can be passed to the following types of automation files:
• Python files
• Response files
• IPLAN files
but how they are handled by each varies. Note that the dialog permits specifying arguments for
PSAS and PSEB files, but those languages have no facility for retrieving the argument values.
16.7.1 Arguments in Python Files

The list argv in the module sys can be used to access the program arguments. Consider the
following Python program named arg0.py:
import sys
print sys.argv
When run using the Python interpreter from a Command Prompt the input is assumed to be space
delimited and is parsed into separate values, e.g.:
Enter:
python arg0.py a list of words
16-9
Argument Passing Program Operation Manual
and the following is displayed:
['arg0.py', 'a', 'list', 'of', 'words']

From within PSS®E the input string is entered as a single argument. If the file arg0.py is selected
(say, in the root directory of the C drive) and the string a list of words is entered in the argument
string dialog box, the following will be displayed at the Progress tab:
Executing Python file:C:\LocalDocs\dev\testing\arg0.py

['C:\\arg0.py', 'a list of words']
16.7.2 Arguments in Response Files

The argument string is parsed according to the standard PSS®E free-format input rules for strings.
Arguments in the Response File are then replaced by simple string substitution. If an argument
contains a blank, comma, or slash, the argument must be enclosed in single quotes; otherwise the
quotes are optional.
A Response File that is receiving arguments has the appropriate argument, less any surrounding
quotes, substituted by the input processor before the dialog input line is passed to PSS®E itself.
Arguments replace argument designator strings, which are of the form %n%, where < n > is one of
the numbers 1 through 15. Any recording of input lines contains the argument values in place of the
argument designator strings. A Response File may pass an argument that it receives to another
Response File, which it, in turn, initiates. It is usually good practice to place such argument desig-
nators in quotes so that a single argument that contains blanks and/or commas not be interpreted
by the designated Response File as multiple arguments.
An example of an argument would be %1%, which could appear anywhere in the file. In this case
%1% would be replaced by the first value parsed from the argument string. Likewise %5% would
be replaced by the fifth value parsed from the argument string.
Response Files require that all arguments receive values. When a Response File references an
argument that was not passed to it at the time it was initiated, an error condition occurs A useful
technique is to document all arguments referenced in a Response File using the TEXT command
at the beginning of the Response File. This approach will help detect missing argument errors
before any lengthy computations specified in the Response File are performed.
The following are examples of specifying arguments to a response file that can be entered in the
command line:
@INPUT , filename , 'argument 1' , 'argument 2' ... 'argument 15'

or:
@CHAIN , filename , 'argument 1' , 'argument 2' ... 'argument 15'
16.7.3 Arguments in IPLAN Files

The entire argument string is placed in a buffer. The IPLAN command ARGUMENT can then be
used to parse the string in any way - and repeatedly - using the standard PSS®E free-format input
rules. Refer to Section 3.27 Program Arguments of the IPLAN Program Manual.
16-10
Program Operation Manual Default Values
16.8 Default Values

Activity Default Values
Many of the statements in automation files specify data for which defaults exist. The idea of a default
value is one that is simply not specified. Typically this means that either some function or action
associated with that value is ignored, or a specific documented value is used; that specific value
might be a fixed value - say, zero - or the current value of some quantity in the network case or a
program setting.
While it is possible in some programming languages for a value to be missing, the general case is
that in order to indicate this situation a special value is used. When input values are omitted in auto-
mation files such special values are substituted for them. The various API routines check for the
special values and take appropriate default actions when they are encountered.
Currently spaces and false are used for filenames and logical values when they are omitted. The
special values for integers, real numbers (floats), and characters (strings) are returned from the API
routines GETDEFAULTINT, GETDEFAULTREAL, and GETDEFAULTCHAR. No assumptions
should be made that these precise values will be identical from one release of the PSS®E to
another. If it is necessary to acquire these values, always run the API routine to get the current
values.
Default values can be specified in references to API routines in Python Files. Data items can be
omitted in Response Files. The concept of default values does not apply to IPLAN programs in
general, but there are some functions that take optional arguments, and because PUSH statements
can contain anything that could be in a Response File, any comments about Response Files will
apply there. All data values are required in PSEB and PSAS files, unless the syntax specifically indi-
cates otherwise.
16.8.1 Defaults in Python Functions

The Python language provides an easy mechanism for permitting optional arguments to functions.
However it requires that each function be coded in such a way as to permit this. Not every one is.
All the functions in the psspy module are coded in this way. For other modules delivered with
PSS®E please check the help facility.
16.8.2 Defaults and Keywords in Module psspy

All arguments to functions defined in module psspy may be omitted and default values will be
supplied. All arguments to functions defined in module psspy may be specified by keyword.
In addition psspy contains a unique feature for specifying values for specific elements in an input
list. This is best illustrated by example. Let’s say a function mysub takes a single argument, opt,
which is a 2-element list of integers, then the following are equivalent:
mysub([_i,1])
mysub(opt=[_i,1])
mysub(opt2=1)
mysub(opt=None,opt2=1)
mysub(opt=[_i,42],opt2=1)
mysub(opt2=1,opt=[_i,352])
mysub(opt1=_i,opt2=1)
where _i is a variable equal to the default integer value.
16-11
Unattended Execution of PSS®E Program Operation Manual
What this means is that all the functions in psspy recognize special keywords formed by concate-
nating any input list name and the string representation all the possible index values (starting at 1)
and will use them to override just that specific element of the list.
16.8.3 Defaults in Recorded Python Files

When recording is enabled and the Python format is chosen, values for all arguments are specified.
Where default values are recorded, actual values are used except for the following:
• in place of default integer values, the variable _i is used.

• in place of default float values, the variable _f is used.
• in place of default string values (not filenames) the variable _s is used.
This will work directly inside of the PSS®E GUI because those variable are automatically assigned
the appropriate values at program startup. This is why the statements
_i=psspy.getdefaultint()
_f=psspy.getdefaultreal()
_s=psspy.getdefaultchar()
are recommended in Section 16.4.3 The External Interpreter Environment.
16.8.4 Defaults in Response Files

Because Response Files are simply free-format data files, an input value can be omitted by two
commas either together or separated by only spaces.
For batch commands there is a special token, a semi-colon, that can be used to tell the interpreter
that it should return all remaining inputs to the default settings (see Section 16.5 Batch Commands).
Files containing recorded batch commands will use consecutive commas for default values speci-
fied to the API routine.
16.9 Unattended Execution of PSS®E

Activity Unattended Execution of PSS®E
In some cases, it may be desirable to run PSS®E in batch mode, that is, without any user interface.
PSS®E provides command line options that can be used for this purpose. In Section 16.9.1 Start-
up Commands provides a list of all the available command line options; these four specifically
pertain to this purpose:
-rspfile -pyfile -argstr -embed
• note that the initial - is part of the command

• -rspfile, -pyfile, and -argstr all expect to be followed by a string
• -pyfile will be ignored if -rspfile is specified
• -argstr and -embed will be ignored if neither -rspfile nor -pyfile are specified
• the command line is blank delimited; if the string specified to -rspfile, -pyfile, or -argstr
contains a blank then the string must be quoted
16-12
Program Operation Manual Unattended Execution of PSS®E
• if the same option is specified more than once, only the last one will be used
• notwithstanding the previous point, the order of the options is unimportant
• the string value for the -argstr option is the argument string (see Section 16.7 Argument
Passing)
Provision is made for specifying only Response Files or Python Files. Both of those file types can
use other types of Automation Files so, indirectly at least, any type can be used.
The -embed option has the effect of suppressing the display of the PSS®E GUI. If the Automation
File terminates without stopping the execution of PSS®E the GUI will be displayed at that time.
The following are a few points to be aware of when preparing to run PSS®E in an unattended mode:
• PSS®E does not read input from stdin or write to stdout, so pipes cannot be used for
batch execution of PSS®E.
• Be aware of the nature of the operating system tool you are using to start PSS®E. In
Microsoft® Windows, for example, non-console application programs, such as PSS®E,
are executed asynchronously. This means that should you have a batch file that starts
PSS®E it will not wait for the program to stop before continuing on the next statement
in the batch file.
• When running in batch mode (i.e. with a startup automation file specified that stops the
program) the Progress tab and Report tab output should be re-directed to a printer or
file, otherwise output will be sent to windows that would be closed when the program
stops.
16-13
Running a Python Program Program Operation Manual
Here are some examples of starting PSS®E from a Command Prompt:
psse33 -rspfile busout.idv

psse33 -pyfile busout.py
psse33 -pyfile busout.py -embed
psse33 -embed -pyfile "study number 2.py" -argstr 101
Appendix D - Command Line Options contains a complete list of all the command line options that
are available.
16.10 Running a Python Program
Run Python Program - GUI

I/O Control>Start recording…
[Select Program Automation File to Record]
Python file (*.py)
None
Python programs run in this manner execute in the embedded interpreter environment as described
in Section 16.4.2, The Embedded Interpreter Environment. All code runs in that local namespace
and can therefore be impacted by previous Python programs, or affect subsequent Python
programs. Specifically, local variables retain their bindings (values) for the entirety of the execution
of PSS®E. Use Modules, Classes, or functional programming techniques to create independent
namespaces.
Python’s interaction with PSS®E is strictly through the API. PSS®E functions can be executed, and
data can be retrieved from PSS®E’s working memory. API routines are provided to run Response
Files and IPLAN programs from within a Python program, so the other automation methods are inte-
grated with Python in this way, and functionality that was developed using this other methods, which
all predate Python’s introduction into PSS®E, is preserved and can be used with minimal rework.
16.11 Line Mode Commands

The line mode was the primary method of controlling PSS®E through rev 29 (and the only method
through rev 18). It was highly efficient, very thorough, but completely procedural. It was essentially
a question-and-answer session with a program that began with the question:
Activity?
The appropriate response to this question was any of about 170-180 (in the last few releases) activ-
ities that comprised the primary functions that PSS®E could perform. Each activity name was four
characters long; most could be abbreviated. Some activities could accept optional suffixes which
modified their behavior somewhat. Almost all would then ask a series of questions, unique to each
activity, to which the user would respond to operate the program. Many of those activity names are
preserved today in API routines that perform similar functions.
16-14
Program Operation Manual Line Mode Commands
Line mode commands can be used to automate PSS®E through Response Files (*.idv), so called
because they contain responses to the questions that the command line of PSS®E asks.
The modern GUI has replaced this previously common method of operation, but there is a wealth
of existing Response Files containing line mode commands used to automate PSS®E. Therefore
PSS®E currently contains a feature called the Line Mode Interpreter (LMI) - a new program written
to imitate the traditional line mode of PSS®E, but that actually uses the PSS®E API. In a way it is
a translator from line mode to batch commands. It is not a perfect imitation, and those differences
are captured in PSS®E Command Line Interface (CLI) Users Guide, Appendix A.
It is worth noting that, although the line mode now comprises a subset of the full functionality of
PSS®E, for those functions it can perform, and for those users who are thoroughly familiar with the
command line (and are good typists), the program can still be operated more quickly from the
keyboard than is physically possible with a point-and-click interface (i.e., a mouse). So while
command line capabilities are not likely to be enhanced in the future, its current operation is consid-
ered to be an important feature of the program.
16.11.1 Mixing Line Mode and Batch Commands

Response files can contain both line mode and batch commands. The batch commands can be
thought of as additional activities of the line mode. They are not, and they are handled very differ-
ently; but for purposes of understanding how they may be combined in the same file, that image
provides the guidelines that need to be followed.
The format of the line mode commands also conforms to the PSS®E standard free-format rules
16.11.2 Immediate Commands

The line mode has been augmented over the years with a set of Immediate (@) Commands, so
called because their actions occur without the involvement of any of the API routines in PSS®E.
They are functions of a utility library (a Siemens PTI product) that is used by PSS®E but separately
maintained. Immediate Commands can also be mixed with line mode and batch commands. Unlike
batch commands, however, they can be used anywhere, even in the middle of a series of responses
to a particular activity using the command line. The following list is provided for convenience:
@CHAIN filename - Open the specified file as a chained response file.

@INPUT filename - Open the specified file as a nested response file.
@PAUSE - Temporarily suspend response file operation.
@CONTINUE - Resume PAUSEd response file operation.
@END - Close the current response file.
@SYSTEM command - Issue a designated operating system specific command
@RELEASE - display the PSS®E release number and date, along with similar information
about selected subsystems.
@DONGLE - display time used statistics for time lock users
@! - Ignore the entire line.
The last one, @!, will work from any input file. The others are only recognized from terminal input,
such as a Response File.
16-15
Running a Response File Program Operation Manual
16.11.3 Version
The LMI provides an additional feature that the original line mode did not - the ability to change
versions. As releases of PSS®E come out, sometimes changes are necessary in the sequence of
line mode commands. The creates maintenance work for existing Response Files. The LMI
provides a command, VERSION, which displays or sets the version of the line mode language
being processed. Introduced at rev 31 of PSS®E, it recognizes versions from rev 30 and newer, for
example:
VERSION 30 - sets the version to rev 30

VERSION 31 - sets the version to rev 31
etc.
VERSION - displays the current version
16.12 Running a Response File

IDEV
Run Response File - GUI

I/O Control>Run Program Automation file…
[Select Program Automation File to Run]
Response file (*.idv)
Run Line Mode Activity IDEV - CLI
ACTIVITY?
>>IDEV <filename>
Immediate Commands - CLI

@ input filename
OR
@ chain filename
Python Command
psspy.runrspnsfile <filename>
None
Executing activity IDEV in Line Mode should be considered an obsolete capability which is retained
for backward compatibility purposes. Activity IDEV itself is not sensitive to any interrupt control code
options. While one or more Response Files are active, the CL interrupt control code may be used
to close all open Response Files.

The Response File must contain PSS®E Batch Commands and/or an exact image of the Line Mode
user responses which would normally be entered by the user from the Command Line and/or Imme-
diate Commands. Therefore, the manual creation of a Response File, which is done with the text
editor, requires an intimate familiarity with these commands, particularly for dialog intensive Line
16-16
Program Operation Manual Recording User Actions
Mode activities such as CHNG and ALTR.
®
PSS E GUI Users Guide, Section 23.2.1, Response File
Section 19.2, Assigning Interactive Input to a Response File
16.13 Recording User Actions

Activity ECHO
Run Line Mode Activity ECHO - CLI

ACTIVITY?
>>ECHO

None
The dialog echoing activity ECHO enables the writing of all subsequent user dialog input to a desig-
nated file, which may subsequently be used as a Operation of activity ECHO.
Users of PSS®E’s traditional command line interface will be familiar with the activity ECHO. It
performs a function similar in effect to the recording function in the current program. It is a very
different thing, however, and a remnant of it remains.
ECHO copies terminal input to a file. Because all PSS®E input in a console application either came
from a terminal or a device that imitated the terminal, that meant all (interactive) input. This capa-
bility is retained in the PSSECMD console application.
The current recording function is a feature of the API routines. When they are called, if recording is
enabled, they record a copy of their input in the designated format in the designated file; it doesn’t
matter how the call occurred - by menu selection, through line mode, from an automation file, etc.
The ECHO function still exists in the GUI, and it still does the same thing, i.e. copies all terminal
input to a file. The difference is that there is very little terminal input. The API routine userin, the
IPLAN function INPUT (and INPUTLN), and the @pause immediate command all attempt to read
from the terminal, which is handled in via a pop-up window. So data entered there will show up in
an ECHO file.
Related to this is the traditional command line activity IDEV, meaning Input DEVice. IDEV was used
to replace the terminal with a file so that subsequent READs from the terminal would find the
responses in the file (hence the name Response File). IDEV never executed the commands in a
Response File, although that appeared to be the situation. The implementation of IDEV in the GUI
does what most people would expect, therefore; it causes the commands in the Response File to
be interpreted by the LMI. This means, however, that IDEV no longer runs the way it used to, i.e.
replaces terminal input with a file. That function is now performed by the API routine
SET_INPUT_DEV. The outcome of that API is opening a file to respond to input requests from the
16-17
Recording User Actions Program Operation Manual
terminal (except @pause which will still force an actual terminal read, handled via a pop-up
window).
When activity ECHO is initiated, if a file for capturing responses had previously been opened with
an earlier execution of activity ECHO, it is closed.
16-18
Program Operation Manual Building a Response File, Power Flow Calculation

With a console application like PSSECMD the file built as a result of activity ECHO can be used as
a PSS®E Response File with @INPUT or @CHAIN or IDEV command to exactly reproduce a
sequence of PSS®E activity commands and responses to instructions. Files written by activity
ECHO are source files which may be modified with the text editor (e.g., to specify different faulted
buses, switched branches, Saved Case and Snapshot File names, and so on) to tailor the original
set of user responses to the application at hand.
Activity ECHO copies to the designated file those user inputs that are entered into PSS®E as part
of the interactive dialog. In addition, whenever a PSS®E bulk data input activity is reading data from
the dialog input device (rather than from a bulk data input file), these data records are also recorded
in the file. This applies to activities such as READ, TREA, RESQ, TRSQ, MCRE, and PSAS.
®
Section 19.3, Recording User Actions
16.14 Building a Response File, Power Flow Calculation

Activity PSEB
Run Activity PSEB - GUI

I/O Control>Run program Automation file…
PSEB Command file (*.pse)
Run Line Mode Activity PSEB - CLI
ACTIVITY?
>>PSEB
>>
None
The power flow run assembler activity PSEB allows the user to specify routine power flow runs in
an English-like language. Input to activity PSEB is taken either from a PSEB Command File or from
the dialog input device. This can be in-stream in a Response File, typed into the command line in
the GUI, or entered at the console in PSSECMD. The output from activity PSEB is in the form of a
PSS®E Response File.
16.14.1 PSS®E PSEB Macro Language

PSEB (PSS®E Engineering Basic) is a built-in macro language that supports PSS®E Power Flow
operations through the use of English-like command macros. PSEB commands are created within
a text file using a text editor. Each record is in the form of a command starting with a verb from a
previously defined vocabulary. The PSEB commands are documented below and in the PSEB
User’s Ready Reference.
16-19
Building a Response File, Power Flow Calculation Program Operation Manual
PSEB commands do not interact with PSS®E directly. The PSEB macro processor is really a trans-
lator from the PSEB language to a Response File, which may contain a mixture of command line
and batch commands. The PSEB command line command normally automatically performs the
commands in the Response File after the translation. When used with the suffix CHECK (i.e. PSEB,
CHECK) only the translation is performed. When using the PSEB API routine only the translation is
performed.
Each PSEB command begins with a verb from the vocabulary recognized by activity PSEB. Some
commands require additional keywords (e.g., BUS, BRANCH), numeric quantities (e.g., bus
number, load MW), and/or character identifiers (e.g., bus name, circuit identifier) in specific fields of
the command format. Some commands provide for the optional specification of keywords, numeric,
and/or character quantities; these are shown in the command syntax enclosed in braces ([ ]).
Where one of several keywords may be specified, they are shown in the command format enclosed
in vertical bars (| |). One of the keywords listed must be entered in the field.
Each keyword or data value must be followed by one or more blanks. For clarity, a comma or equal
sign may be used in place of, or in addition to, a blank space. For example, the following two PSEB
commands are equivalent:
OPEN TIE FROM BUS 153 TO BUS 154 CKT 2

OPEN TIE, FROM BUS = 153, TO BUS = 154, CKT = 2
Any field labeled bus id designates that a bus identifier is to be entered. When the numbers input
option is in effect, the bus number must be specified; using the names input option, the extended
bus name enclosed in single quotes is required.
Any field labeled dc id designates that a two-terminal dc line name is to be entered. If the name
contains any blanks or special characters, it must be enclosed in single quotes.
I and R indicate that integer and real (i.e., it may include a decimal point) numeric values respec-
tively are to be specified.
Many PSEB commands provide for the insertion of optional descriptive text in designated fields,
indicated by [n] in the command syntax. For example, the following two PSEB commands translate
into the same PSS®E dialog:
RECOVER FROM SAVNW.SAV

RECOVER saved case FROM SAVNW.SAV
A dollar sign ( $ ) at the end of a PSEB command line is used to continue the command on the
following line. At least one space must precede the dollar sign. As many physical lines as required
may be used to specify a single PSEB command as long as all lines except the last one are termi-
nated with a dollar sign. This multiline capability may be used with all PSEB commands except the
USE command (see below). In addition, each PSS®E activity command and response to an instruc-
tion entered in passthru mode (see below) must be entered on a single line.
16.14.2 PSEB Commands

The detailed syntax of each PSEB command is given below and also on the PSS®E Engineering
Basic PSEB User’s Ready Reference sheet. Keywords shown in uppercase letters must be entered
as shown in either upper or lowercase characters.
HOLD [n] IN (saved-case-filename) [NOW]
16-20
The HOLD command is used to preserve the power flow working case in the designated
Saved Case File; refer to Section 5.45 Creating a Saved Case File. When the HOLD
command includes the optional keyword NOW, activity SAVE is immediately executed. In
this case, the PSS®E responses for activity SAVE are not written to the Response File
being constructed by activity PSEB.
When the HOLD command does not include the optional keyword NOW, the appropriate
entries in the Response File are made to save the working case during the subsequent
execution of the Response File.
RECOVER [n] FROM (saved-case-filename)
The RECOVER command is used to access the designated Saved Case File; refer to
Section 5.1 Retrieving a Power Flow Saved Case File. Activity CASE is executed immedi-
ately and the PSS®E responses for activity CASE are written to the Response File being
constructed by activity PSEB. Note that the RECOVER command overwrites the working
case. The HOLD command with the NOW option may be used before the RECOVER
command to save the working case.
16-21
|MW |
|MWP |
|MWI |
|ALTER | |MWY | [ |MW | ]
|CHANGE| |MVAR | LOAD [n] BUS (bus id) [LOAD (id)] TO (R) [ |MVAR| ]
|MVARQ|
|MVARI|
|MVARY|
This form of the ALTER command is used to change a specified component of a designated
load at a designated bus to a specified value. If the optional load identifier tokens are
omitted, a load identifier of 1 is assumed. The second token specified indicates the compo-
nent of load as follows:
MW, MWP Active power component, constant power characteristic.

MWI Active power component, constant current characteristic.
MWY Active power component, constant admittance characteristic.
MVAR, MVARQ Reactive power component, constant power characteristic.
MVARI Reactive power component, constant current characteristic.
MVARY Reactive power component, constant admittance characteristic; R is
negative for an inductive load.
The value specified is always in MW or Mvar at unity voltage. Refer to Load Data.
SHED LOAD [n] BUS (bus id)
The SHED command is used to set all loads at the specified bus out-of-service. Refer to
Load Data.
|MW |
|ALTER | |MWG | [|MW |]
|CHANGE| |MVAR | SHUNT [n] BUS (bus id) [SHUNT (id)] TO (R) [|MVAR|]
|MVARB|
This form of the ALTER command is used to change a specified component of a specified
fixed shunt at a designated bus to a specified value. If the optional shunt identifier tokens
are omitted, a shunt identifier of 1 is assumed. The second token specified selects either
the active (MW or MWG) or reactive (MVAR or MVARB) component of bus shunt. Values
entered are in MW or Mvar at unity voltage. The reactive component is specified as a nega-
tive quantity for an inductive load. Refer to Fixed Bus Shunt Data.
|ALTER |
|CHANGE| BUS (bus id) CODE TO (I)
This form of the ALTER command is used to change the bus type code of a designated bus.
Refer to Bus Data.
16-22
|ALTER | |R| [|CKT | ]

|CHANGE| |X| TO (R) [n] FROM [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT| (id)]
|B|
This form of the ALTER command is used to change the per unit resistance, reactance or
charging of a designated non-transformer branch or two-winding transformer to a specified
value. If the optional circuit identifier tokens are omitted, a circuit identifier of 1 is assumed.
Refer to Non-Transformer Branch Data.
DROP PLANT [n] BUS (bus id)
This form of the DROP command is used to disconnect all generation at a specified bus.
The bus type code is set to one; refer to Bus Data and Section 5.9.1 Equipment Status
Changes.
RECONNECT PLANT [n] BUS (bus id)
This form of the RECONNECT command is used to reconnect generation at a specified

bus. The bus type code is set to two; machine status flags are not changed. Refer to Bus
Data, Generator Data, and Section 5.9.1 Equipment Status Changes.
|UNIT |
DROP |GENERATOR| (id) [n] BUS (bus id)
|MACHINE |
|LOAD |
|SHUNT |
This form of the DROP command is used to disconnect a specified machine, load, or fixed
shunt at a designated bus. The machine, load, or shunt status flag is set to zero; refer to
Load Data, Fixed Bus Shunt Data, Generator Data, and Section 5.9.1 Equipment Status
Changes.
|UNIT |
RECONNECT |GENERATOR| (id) [n] BUS (bus id)
|MACHINE |
|LOAD |
|SHUNT |
This form of the RECONNECT command is used to reconnect a specified machine, load,
or fixed shunt at a designated bus. The machine, load, or shunt status flag is set to 1; the
bus type code is not changed. Refer to Bus Data, Load Data, Fixed Bus Shunt Data, Gener-
ator Data, and Section 5.9.1 Equipment Status Changes.
DISCONNECT BUS (bus id)
This form of the DISCONNECT command is used to electrically disconnect a bus and all
equipment connected to it. This command results in the use of activities DSCN and ORDR.
|DISCONNECT| |LINE | [|CKT | ]
|TRIP | |TIE |[n] FROM [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT| (id)]
|OPEN | |BRANCH|
This form of the DISCONNECT command is used to remove a specified branch from
service. If the optional circuit identifier tokens are omitted, a circuit identifier of 1 is
assumed. The branch status flag is set to zero; refer to Non-Transformer Branch Data and
Section 5.9.1 Equipment Status Changes.
16-23
|RECONNECT| |LINE | [|CKT | ]

|CLOSE | |TIE | [n] FROM [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT|(id)]
|RECLOSE | |BRANCH|
This form of the RECONNECT command is used to return a specified branch to service. If
the optional circuit identifier tokens are omitted, a circuit identifier of 1 is assumed. The
branch status flag is set to 1; refer to Non-Transformer Branch Data and Section 5.9.1
Equipment Status Changes.
|DISCONNECT| [|CKT | ]
|TRIP |THREEWINDING [n] FROM [n] BUS (bus id) TO [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT| (id)]
|OPEN |
This form of the DISCONNECT command is used to remove all windings of a specified
three-winding transformer from service. If the optional circuit identifier tokens are omitted,
a circuit identifier of 1 is assumed. The transformer status flag is set to zero; refer to Trans-
former Data and Section 5.9.1 Equipment Status Changes.
|TRIP |THREEWINDING [n] AT [n] BUS (bus id) TO [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT| (id)]
|OPEN |
This form of the DISCONNECT command is used to remove the winding connected to the
bus specified as the AT bus of a specified three-winding transformer from service. If the
optional circuit identifier tokens are omitted, a circuit identifier of 1 is assumed. The trans-
former status flag is set to 2, 3 or 4; refer to Transformer Data and Section 5.9.1 Equipment
Status Changes.
|RECONNECT| [|CKT | ]
|CLOSE |THREEWINDING [n] FROM [n] BUS (bus id) TO [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT| (id)]
|RECLOSE |
This form of the RECONNECT command is used to return all windings of a specified three-
winding transformer to service. If the optional circuit identifier tokens are omitted, a circuit
identifier of 1 is assumed. The transformer status flag is set to 1; refer to Transformer Data
and Section 5.9.1 Equipment Status Changes.
BLOCK DCLINE (dc id)
The BLOCK command is used to block a specified two-terminal dc line. The control mode
is set to zero; refer to Two-Terminal DC Transmission Line Data.
UNBLOCK DCLINE (dc id)
The UNBLOCK command is used to unblock a specified two-terminal dc line. The control
mode is set to 1 (i.e., the UNBLOCK command assumes power control mode). Refer to
Two-Terminal DC Transmission Line Data.
|SETPOINT|
SET DCLINE (dc id) |SCHEDULE| TO (R)
This form of the SET command is used to change the current or power demand
(SETPOINT) or scheduled dc voltage (SCHEDULE) on a specified two-terminal dc line to
a designated value; refer to Two-Terminal DC Transmission Line Data.
SET LOADFLOW TITLE LINE |1| TO ‘(title)’
|2|
This form of the SET command is used to change the designated line of the two-line case
heading to a specified string. The title may be up to 60 characters and must be enclosed in
single quotes; refer to Case Identification Data.
16-24
|BUS |
NET GENERATION [n] |BUSES| (bus id) [(bus id)...[(bus id)]]
This form of the NET command is used to net the generation with the load at specified
buses; refer to activity GNET. Up to 25 buses may be specified in each use of this
command.
NET GENERATION [n] FOR BUSES (I) THRU (I)
This form of the NET command is used to net the generation with the load at all buses within
a specified bus number range; refer to activity GNET. This command is valid only when the
bus input option is in its numbers setting.
SET SOLUTION OPTION[S] TO DEFAULT
This form of the SET command is used to instruct activity PSEB that subsequent SOLVE
commands (see below) are to execute power flow solutions with the present power flow
solution adjustment option settings honored. Refer to Sections 3.3.3 and 6.3.20 and activity
OPTN.
SET SOLUTION OPTION[S] TO [|DISCRETE-TAP|],[|AREA-LOCKED|],[FLAT-START],[|DC-LOCKED|],[|SHUNT-LOCKED|],[|PHASE-SHIFT |]
[|DIRECT-TAP |] [|AREA-INTCHG|] [|DC-ADJUST|] [|SHUNT-ADJUST|] [|PSHFT-LOCKED|]
[|TAP-LOCKED |] [|TIES+LOADS |] [|SHN-ADJ-CONT|]
This form of the SET command is used to enable and/or disable the power flow adjustments
to be used on subsequent power flow solutions initiated with the SOLVE command (see
below). For any adjustment option not specified, the present program option setting is
honored. Refer to Sections 3.3.3 and 6.3.20 and activity OPTN.
|FNSL|
|FDNS| [ |AFTER (I) [ITERATION[S]]|]
SOLVE [n] USING |NSOL| [WITH VAR LIMITS [n] |IMMEDIATE[LY] |]
|SOLV| [ |IGNORED |]
|MSLV|
|INLF|
The SOLVE command is used to execute one of the power flow solution activities. Solution
options as established by the last SET SOLUTION OPTIONS command are honored; if no
SET SOLUTION OPTIONS command was specified, the current solution adjustment option
settings are honored. Refer to activities SOLV, MSLV, FNSL, NSOL, FDNS, INLF, and
OPTN and Section 3.3.3 Program Run-Time Option Settings.
|PSS |
|PASS |
|PASSTHRU|
The PASSTHRU command is used to inform activity PSEB that subsequent command
input is in the form of BAT_ records (refer to PSS®E Application Program Interface (API))
and/or PSS®E activity commands and responses to questions rather than in the form of
PSEB commands. While passthru mode is in effect, each input to activity PSEB is simply
appended without modification to the Response File being built. If input to activity PSEB is
being taken from the user’s terminal, the prompt PASSTHRU: is issued while this mode is
in effect. Passthru mode is terminated and PSEB command mode reinstated by entering
the command FIN (see below). @INPUT and @CHAIN commands must not be specified
while passthru mode is in effect; the IDEV activity command may be specified.
16-25
FIN
Terminate passthru mode (see above) and reinstate PSEB command mode.
|USE |
|COPY| (response-file-filename) [arg1 ... [arg9]]
|IDEV|
The USE command allows the user to include the BAT_ records (refer to PSS®E Applica-
tion Program Interface (API)) and/or PSS®E line mode commands and responses to
instructions which are contained in a Response File within the PSEB commands which
define a PSS®E calculation sequence. The USE filename command is converted to an
@INPUT filename command and inserted into the Response File being constructed by
activity PSEB. Note that entries in the designated file must be in the form of BAT_ records
and/or activity commands and responses to questions rather than in the form of PSEB
commands.
The designated file may contain @INPUT commands but must not contain any @CHAIN
commands or IDEV activity commands. The designated file must be terminated with an
@END command; it must not be terminated with an IDEV activity command or a FIN PSEB
command.
EXECUTE (iplan-program-filename)
The EXECUTE command allows the user to include the execution of an IPLAN program
within the PSEB commands which define a calculation sequence. The EXECUTE filename
PSEB command is converted to an EXEC filename activity command (refer to activity
EXEC) and inserted into the Response File being constructed by activity PSEB.
WATCH [OFF]
The WATCH command is used to enable or disable the echoing of responses generated
from PSEB commands to the dialog output device (normally the user’s terminal). Response
echoing is disabled upon entering activity PSEB; the PSEB command WATCH enables
response echoing and WATCH,OFF disables it.
CHECK
The CHECK command instructs activity PSEB to bypass the automatic execution of the
Response File that it constructs.
END
The END command terminates PSEB command input. Unless it is otherwise suppressed,
the Response File constructed by activity PSEB is automatically executed.
ABORT
The ABORT command terminates activity PSEB and bypasses the automatic execution of
the Response File that it has constructed.
HELP
This form of the HELP command displays the list of PSEB commands at the dialog output
device (refer to Section 4.4 Virtual Output Devices).
16-26
Program Operation Manual Building a Response File, Dynamic Simulation
HELP,command
This form of the HELP command displays the syntax format of the specified PSEB
command at the dialog output device (refer to Section 4.4 Virtual Output Devices).
®
PSS E GUI Users Guide, Section 23.3.3, PSEB Command File, Power Flow Calculation
Section 19.4, Building a Response File, Power Flow Calculation
16.15 Building a Response File, Dynamic Simulation

Activity PSAS
Run Activity PSAS - GUI

PSAS Command file (*.psa)
Run Line Mode Activity PSAS - CLI
ACTIVITY?
>>PSAS
>>
None
The simulation run assembler activity PSAS allows the user to specify dynamic simulation runs in
an English-like language. Input to activity PSAS is taken either from a PSAS Command File or from
the dialog input device. This can be in-stream in a Response File, typed into the command line in
the GUI, or entered at the console in PSSECMD. The output from activity PSAS is in the form of a
PSS®E Response File.
16.15.1 PSS®E PSAS Macro Language

PSAS (Simulation Run Assembler) is a built-in macro language that supports PSS®E Dynamics
simulations through the use of English-like command macros. PSAS commands are created within
a text file using a text editor. Each record is in the form of a command starting with a verb from a
previously defined vocabulary. The PSAS commands are documented below and in the PSAS
User’s Ready Reference.
PSAS commands do not interact with PSS®E directly. The PSAS macro processor is really a trans-
lator from the PSAS language to a Response File, which may contain a mixture of command line
and batch commands. The PSAS command line command normally automatically performs the
commands in the Response File after the translation. When used with the suffix CHECK (i.e. PSAS,
CHECK) only the translation is performed. When using the PSAS API routine only the translation is
performed.
16-27
Building a Response File, Dynamic Simulation Program Operation Manual
16.15.2 PSAS Commands

Each PSAS command begins with a verb from the vocabulary recognized by activity PSAS. Some
commands require additional keywords (e.g., BUS, VAR), numeric quantities (e.g., bus number,
VAR index), and/or character identifiers (e.g., dc line name, circuit identifier) in specific fields of the
command format. Some commands provide for the optional specification of keywords, numeric
and/or character quantities; these are shown in the command syntax enclosed in braces ([ ]).
Where one of several keywords may be specified, they are shown in the command format enclosed
in bars (| |). One of the keywords listed must be entered in the field.
Each keyword or data value must be followed by one or more blanks. For clarity, a comma or equal
sign may be used in place of a blank space. For example, the following two PSAS commands are
equivalent:
START OUTPUT SAVNW.PLT

START, OUTPUT=SAVNW.PLT
Any field labeled bus id designates that a bus identifier is to be entered. When the numbers input
option is in effect, the bus number must be specified; using the names input option, the extended
bus name enclosed in single quotes is required.
Any field labeled dc id designates that a two-terminal dc line name is to be entered. If the name
contains any blanks or special characters, it must be enclosed in single quotes.
I and R indicate that integer and real (i.e., it may include a decimal point) numeric values respec-
tively are to be specified. C indicates that a one or two character alphanumeric value is to be
specified.
Many PSAS commands provide for the insertion of optional descriptive text in designated fields,
indicated by [n] in the command syntax. For example, the following two PSAS commands translate
into the same PSS®E dialog:
RECOVER FROM SAVNW.SNP AND SAVNW.SAV

RECOVER snapshot and saved case FROM SAVNW.SNP AND SAVNW.SAV
A dollar sign ( $ ) at the end of a PSAS command line is used to continue the command on the
following line. At least one space must precede the dollar sign. As many physical lines as required
may be used to specify a single PSAS command as long as all lines except the last one are termi-
nated with a dollar sign. This multiline capability may be used with all PSAS commands except the
USE command (see below). In addition, each PSS®E activity command and response to an instruc-
tion entered in passthru mode (see below) must be entered on a single line.
The detailed syntax of each PSAS command is given below and also on the PSS®E Simulation Run
Assembler PSAS User’s Ready Reference sheet. Keywords shown in uppercase letters must be
entered as shown in either upper or lowercase characters.
[|NOW |]
HOLD[n]IN(snapshot-filename)AND(saved-case-filename) [|SIZE[S](I1)(I2)(I3)(I4)(I5)|]
The HOLD command is used to preserve dynamics working memory and the power flow
working case in Snapshot and Saved Case Files respectively (refer to activities SNAP and
SAVE). When the HOLD command includes the optional keyword NOW, activity SNAP and
SAVE are immediately executed and the user specifies the number of dynamic simulation
array elements to save in the same manner as when activity SNAP is specifically invoked.
16-28
In this case, the PSS®E responses for activity SNAP and SAVE are not written to the
Response File being constructed by activity PSAS.
When the HOLD command does not include the optional keyword NOW, the appropriate
entries in the Response File are made to take a Snapshot and save the working case during
the subsequent execution of the Response File. In this case, the user may optionally
specify the keyword SIZES followed by the number of CONs, STATEs, VARs, ICONs and
output channels to be preserved. If this keyword and its data are omitted, a blank response
is generated in the Response File and, when the Response File is subsequently executed,
activity SNAP preserves up to the next available positions in the respective dynamics data
arrays.
RECOVER[n] FROM (snapshot-filename) AND (saved-case-filename) [NOFACT] [NOTYSL] [NORETURN]
The RECOVER command is used to access the designated Snapshot and Saved Case
Files (refer to activities RSTR and CASE). Activities RSTR and CASE are executed imme-
diately and the PSS®E responses for activities RSTR, LOFL, and CASE are written to the
Response File being constructed by activity PSAS. The activity commands FACT, TYSL,
and RTRN are included in the Response File unless they are suppressed with one or more
of the optional tokens NOFACT, NOTYSL and NORETURN. If NOFACT is specified,
NOTYSL is assumed. If NORETURN is specified, NOFACT and NOTYSL are also
assumed, and the next PSAS command must be either CONVERT, USE or PASS; the
CONVERT command (see below) generates the RTRN activity command but in passthru
mode (see below), the RTRN activity command must be specified before terminating
passthru mode.
The RECOVER command overwrites dynamics working memory and the power flow
working case. The HOLD command with the NOW option may be used before the
RECOVER command to preserve these two sets of data.
|INITIALIZE| OUTPUT |(filename)| [SNAPSHOT |(filename)|]
|START | |NONE | [ |NONE |]
This form of the START command is used to initialize the dynamic model in preparation for
state-space simulations. The STRT activity command is generated with user specified
channel output and Snapshot filename responses. The reserved token NONE may be used
to indicate that the corresponding filename is not to be specified.
|INITIALIZE| EXTENDED [n] OUTPUT |(filename)| [n]
|START | |NONE |
This form of the START command is used to initialize the dynamic model in preparation for
extended term simulations. The MSTR activity command is generated with a user specified
channel output filename response. The reserved token NONE may be used to indicate no
channel output file is to be specified.
|TO | |CYCLE[S] |
RUN [n] |FOR| (R) |SECOND[S]| [PRINT (I)] [PLOT (I)] [CRTPLT (I)]
The RUN command is used to perform dynamic simulation calculations with activity RUN
or MRUN. If the RUN command is preceded by the START command (see above), the form
of the START command determines whether activities RUN or MRUN is to be used. Other-
wise, state-space simulations are assumed and activity RUN is used. The real value indi-
cates the duration of the simulation calculation and may be specified in either seconds or
cycles. It is the value of simulation time (i.e., TPAUSE) when the token TO precedes it and
an incremental value of time when the token FOR precedes it. The optional integer tokens
16-29
and their corresponding keywords allow the user to specify channel printing and plotting
intervals (refer to Section 15.10 Performing State-Space Simulation in Time Steps). By
default, PRINT=20, PLOT=5 and CRTPLT=0.
|OFF|
CONVERGENCE MONITOR |ON |
The CONVERGENCE MONITOR command is used to enable or disable the printing of the
network solution convergence monitor during the execution of the PSS®E activity calls
generated by subsequent START and RUN commands (see above). By default, the
convergence monitor is suppressed.
16-30
APPLY FAULT [n] BUS (bus id) [n]
This form of the APPLY FAULT command is used to apply a solidly grounded three-phase
fault at the designated bus. The Response File being constructed by activity PSAS includes
responses to use activity ALTR to change the fixed shunt at the bus to j(-2.109); refer to
Bus Data, activity ALTR and Section 21.7.2 Applying Disturbances.
|Y | |MVA |
APPLY FAULT [n] BUS (bus id) [n] |ADMITTANCE| (R1) (R2) |MHO[S]| [BASEKV (R)]
This form of the APPLY FAULT command is used to apply a fault with a specified fault
admittance, (R1) + j(R2), at a designated bus. The Response File being constructed by
activity PSAS includes responses to use activity ALTR to change the fixed shunt at the bus.
(R2) should be entered as a negative number. Refer to Bus Data, activity ALTR and
Section 21.7.2 Applying Disturbances.
If the MVA token is specified, the active and reactive components of fixed shunt at the bus
are set to the values specified as (R1) and (R2) respectively; i.e., the fault admittance is
specified in the same MVA units as is bus shunt.
If the MHO or MHOS token is specified, (R1) and (R2) are entered in mhos and activity
PSAS converts them to the MVA units used for specifying bus shunts. If the optional base
voltage tokens are specified, the base voltage specified on the PSAS command is used in
the conversion calculation; otherwise, the base voltage contained in the working case for
the designated bus is used. In either case, a positive base voltage value is required.
|Z |
APPLY FAULT [n] BUS (bus id) [n] |IMPEDANCE| (R1) (R2) OHM[S] [BASEKV (R)]
This form of the APPLY FAULT command is used to apply a fault with a specified fault impedance,
(R1) + j(R2), at a designated bus. The Response File being constructed by activity PSAS includes
responses to use activity ALTR to change the fixed shunt at the bus. (R2) should be entered as a
positive number and (R1) and (R2) are specified in ohms. Activity PSAS converts them to the MVA
units used for specifying bus shunts. If the optional base voltage tokens are specified, the base
voltage specified on the PSAS command is used in the conversion calculation; otherwise, the base
voltage contained in the working case for the designated bus is used. In either case, a positive base
voltage value is
|L-G |
SCMU |L-L | FAULT [n] BUS (bus id) [n] [ZL-G (R1) (R2)] [n]
|L-L-G|
[ZL-L (R3) (R4)] [n] [CONVERTDC] [n] [APPLYZCOREC]
The SCMU FAULT command is used to calculate and apply a single line-to-ground, line-
to-line, or line-to-line-to-ground fault at a designated bus. For the L-G and L-L-G faults, (R1)
and (R2) may optionally specify the complex line-to-ground fault impedance to be used;
similarly, for the L-L and L-L-G faults, (R3) and (R4) may optionally specify the complex
line-to-line fault impedance to be used. These impedances are specified in per unit. For any
of these impedance values that are not specified, 0.0 is assumed.
If the optional token CONVERTDC is specified, dc lines and FACTS device boundary
conditions are converted to constant admittance load for the fault calculation. Otherwise,
they are neglected.
If the optional token APPLYZCOREC is specified, for those transformers which include a
transformer impedance adjustment table, the same correction factor is applied to the zero
16-31
sequence impedance as is applied to the positive sequence impedance. Otherwise, trans-

former zero sequence nominal impedances are used.
|L-G |
|L-L |
|L-L-G | [|CKT | ]
SPCB |3PHASE| FAULT (R1) [n] FROM [n] BUS (bsid) TO [n] BUS (bsid) [n] [|CIRCUIT| (id)]
[n] [ZL-G (R2) (R3)] [n] [ZL-L (R4) (R5)] [n] [CONVERTDC] [n] [APPLYZCOREC]
This form of the SPCB FAULT command is used to calculate and apply a ground fault at a
designated point along a transmission line. (R1) specifies the fault location as the fraction
of the line from the FROM bus; the default value of 0.5 applies the fault at the midpoint of
the line.
For the L-G and L-L-G faults, (R2) and (R3) may optionally specify the complex line-to-
ground fault impedance to be used; similarly, for the L-L and L-L-G faults, (R4) and (R5)
may optionally specify the complex line-to-line fault impedance to be used. These imped-
ances are specified in per unit. For any of these impedance values that are not specified,
0.0 is assumed.
they are neglected.
[|CKT | ]
SPCB 2PHASE OPEN [n] FROM [n] BUS (bsid) TO [n] BUS (bsid) [n] [|CIRCUIT| (id)]
[n] [CONVERTDC] [n] [APPLYZCOREC]
This form of the SPCB FAULT command is used to calculate and apply a transmission line
unbalance with two of its three phases open.
they are neglected.
[|CKT | ]
SPCB 1PHASE OPEN [n] FROM [n] BUS (bsid) TO [n] BUS (bsid) [n] [|CIRCUIT| (id)]
[n] [PATH (R1) [ [n] [ZL-G (R2) (R3)] ] [n] [CONVERTDC] [n] [APPLYZCOREC]
unbalance with one of its three phases open.
This branch unbalance may optionally include a ground fault at a designated point of the
open phase by specifying the optional token PATH, along with (R1) which specifies the fault
location as the fraction of the line from the FROM bus; the default value of 0.5 applies the
16-32
fault at the midpoint of the open phase. (R2) and(R3) may optionally specify the complex
line-to-ground fault impedance in per unit to be used. For any of these impedance values
that are not specified, 0.0 is assumed.
they are neglected.
[|CKT | ]
SPCB BREAKER OPEN [n] AT [n] BUS (bsid) TO [n] BUS (bsid) [n] [|CIRCUIT| (id)]
[n] [PATH (R1) [ [n] [ZL-G (R2) (R3)] ] [n] [CONVERTDC] [n] [APPLYZCOREC]
unbalance with the breaker of one phase open. The breaker at the AT bus is assumed to
be the open breaker.
This branch unbalance may optionally include a ground fault at a designated point of the
open phase by specifying the optional token PATH, along with (R1) which specifies the fault
location as the fraction of the line from the FROM bus; the default value of 0.5 applies the
fault at the midpoint of the open phase. (R2) and(R3) may optionally specify the complex
line-to-ground fault impedance in per unit to be used. For any of these impedance values
that are not specified, 0.0 is assumed.
they are neglected.
CLEAR FAULT [n] [BUS (bus id)]
CLEAR BUS [FAULT] [n] [BUS (bus id)]
These forms of the CLEAR command are used to clear bus faults which were previously
applied with the APPLY FAULT command (see above). The Response File being con-
structed by activity PSAS includes responses to use activity ALTR to change the fixed bus
shunt at the bus back to its original value.
Activity PSAS remembers the faulted bus and the fixed bus shunt which was replaced with
the fault admittance for up to ten bus faults. If the optional bus identification tokens are
omitted, activity PSAS clears the last bus fault which was applied and which has not already
been cleared.
16-33
|LINE | [|CKT | ]
APPLY FAULT [n]|TIE |[n] FROM [n] BUS (bus id) TO [n] BUS (bus id) [n][|CIRCUIT|(id)] [n]
|BRANCH|
This form of the APPLY FAULT command is used to apply a solidly grounded three-phase
fault at the from bus end of a designated non-transformer branch. The Response File being
constructed by activity PSAS includes responses to use activity ALTR to change the line
shunt at the from bus end of the branch to j(-2.107). If the optional circuit identifier tokens
are omitted, a circuit identifier of 1 is assumed. Refer to Bus Data, activity ALTR and
Section 21.7.2 Applying Disturbances.
|LINE | [|CKT | ]
APPLY FAULT [n] |TIE | [n] FROM [n] BUS (bus id) TO [n] BUS (bus id) [n] [|CIRCUIT| (id)] [n]
|BRANCH|
|Y | |MVA |
|ADMITTANCE| (R1) (R2) |MHO[S]| [BASEKV (R)]
admittance, (R1) + j(R2), at the from bus end of a designated non-transformer branch. The
Response File being constructed by activity PSAS includes responses to use activity ALTR
to change the line shunt at the from bus end of the branch. (R2) should be entered as a
negative number. If the optional circuit identifier tokens are omitted, a circuit identifier of 1
is assumed. Refer to Non-Transformer Branch Data, activity ALTR and Section 21.7.2
Applying Disturbances.
If the MVA token is specified, the values specified as (R1) and (R2) are divided by the
system base MVA and the active and reactive components respectively of the line shunt at
the from bus end of the branch are set to these values. The fault admittance is therefore
specified on the record is in the same MVA units as is bus shunt (refer to Bus Data).
If the MHO or MHOS token is specified, (R1) and (R2) are entered in mhos and activity
PSAS converts them to the per unit values used for specifying line shunts. If the optional
base voltage tokens are specified, the base voltage specified on the PSAS command is
used in the conversion calculation; otherwise, the base voltage contained in the working
case for the designated from bus is used. In either case, a positive base voltage value is
required.
|LINE | [|CKT | ]
APPLY FAULT [n] |TIE | [n] FROM [n] BUS (bus id) TO [n] BUS (bus id) [n] [|CIRCUIT| (id)] [n]
|BRANCH|
|Z |
|IMPEDANCE| (R1) (R2) OHM[S] [BASEKV (R)]
impedance, (R1) + j(R2), at the from bus end of a designated non-transformer branch. The
Response File being constructed by activity PSAS includes responses to use activity ALTR
to change the line shunt at the from bus end of the branch. (R2) should be entered as a
positive number and (R1) and (R2) are specified in ohms. Activity PSAS converts them to
the per unit values used for specifying line shunts. If the optional base voltage tokens are
specified, the base voltage specified on the PSAS command is used in the conversion cal-
culation; otherwise, the base voltage contained in the working case for the designated from
bus is used. In either case, a positive base voltage value is required. If the optional circuit
identifier tokens are omitted, a circuit identifier of 1 is assumed. Refer to Non-Transformer
Branch Data, activity ALTR and Section 21.7.2 Applying Disturbances.
16-34
|LINE |
CLEAR |TIE | FAULT [n]
|BRANCH|
This form of the CLEAR command is used to clear the last line fault which was previously
applied with the APPLY FAULT command (see above). The Response File being
constructed by activity PSAS includes responses to use activity ALTR to change the appro-
priate line shunt on the faulted branch back to its original value.
Activity PSAS remembers the faulted branch and the from and to bus orientation specified
on the last APPLY FAULT command. Note that only the last line fault command is remem-
bered by activity PSAS.
CONVERT [n] MW TO (R) (R) [MVAR TO (R) (R)]
The CONVERT command is used to convert the constant MVA load at all buses in the
working case to a specified mix of the constant MVA, constant current and constant admit-
tance load characteristics. The (R) values are specified as percents where the first value of
each pair is the percentage of load to be converted to the constant current characteristic
and the second is the percentage to be converted to constant admittance. If the optional
Mvar tokens are omitted, the same split of load is used for the active and reactive power.
The Response File being constructed by activity PSAS includes responses to use activity
CONL to convert the load as specified in the CONVERT command, followed by the activity
commands CONG, ORDR, FACT, TYSL, and RTRN.
The CONVERT command must be used immediately following a RECOVER command on
which the optional token NORETURN is specified.
|MWP |
|MWI |
|ALTER | |MWY | [ |MW | ]
|CHANGE| |MVARQ| LOAD [n] BUS (bus id) [LOAD (id)] TO (R) [ |MVAR| ]
|MVARI|
|MVARY|
This form of the ALTER command is used to change a specified component of a designated
load at a designated bus to a specified value. If the optional load identifier tokens are
omitted, a load identifier of 1 is assumed. The second token specified indicates the compo-
nent of load as follows:
MWP Active power component, constant power characteristic.

MWI Active power component, constant current characteristic.
MWY Active power component, constant admittance characteristic.
MVARQ Reactive power component, constant power characteristic.
MVARI Reactive power component, constant current characteristic.
MVARY Reactive power component, constant admittance characteristic; R is nega-
tive for an inductive load.
The value specified is always in MW or Mvar at unity voltage. Refer to Load Data.
16-35
SHED LOAD [n] BUS (bus id)
The SHED command is used to set all loads to out-of-service at the specified bus. Refer to
Load Data.
|ALTER | |MWG | |LOAD | [|MW |]
|CHANGE| |MVARB| |SHUNT| [n] BUS (bus id) [SHUNT (id)] TO (R) [|MVAR|]
This form of the ALTER command is used to change a specified component of a specified
fixed shunt at a designated bus to a specified value. If the optional shunt identifier tokens
are omitted, a shunt identifier of 1 is assumed. The second token specified selects either
the active (MWG) or reactive (MVARB) component of bus shunt. Values entered are in MW
or Mvar at unity voltage. The reactive component is specified as a negative quantity for an
inductive load. Refer to Fixed Bus Shunt Data.
|ALTER |
|CHANGE| BUS (bus id) CODE TO (I)
This form of the ALTER command is used to change the bus type code of a designated bus.
Refer to Bus Data.
|ALTER | |R| [|CKT | ]
|CHANGE| |X| TO (R) [n] FROM [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT| (id)]
|B|
This form of the ALTER command is used to change the per unit resistance, reactance or
charging of a designated non-transformer branch or two-winding transformer to a specified
value. If the optional circuit identifier tokens are omitted, a circuit identifier of 1 is assumed.
Refer to Bus Data.
DROP PLANT [n] BUS (bus id)
This form of the DROP command is used to disconnect all generation at a specified bus.
The bus type code is set to one; refer to Bus Data and Section 5.9.1 Equipment Status
Changes.
RECONNECT PLANT [n] BUS (bus id)
This form of the RECONNECT command is used to reconnect generation at a specified

bus. The bus type code is set to two; machine status flags are not changed. Refer to Bus
Data, Generator Data, and Section 5.9.1 Equipment Status Changes.
|UNIT |
DROP |GENERATOR| (id) [n] BUS (bus id)
|MACHINE |
|LOAD |
|SHUNT |
This form of the DROP command is used to disconnect a specified machine, load, or fixed
shunt at a designated bus. The machine, load, or shunt status flag is set to zero; refer to
Bus Data, Fixed Bus Shunt Data, and Section 5.9.1 Equipment Status Changes.
16-36
|UNIT |
RECONNECT |GENERATOR| (id) [n] BUS (bus id)
|MACHINE |
|LOAD |
|SHUNT |
This form of the RECONNECT command is used to reconnect a specified machine, load,
or fixed shunt at a designated bus. The machine, load, or shunt status flag is set to one; the
bus type code is not changed. Refer to Bus Data, Load Data, Fixed Bus Shunt Data, Gener-
ator Data, and Section 5.9.1 Equipment Status Changes.
DISCONNECT BUS (bus id)
This form of the DISCONNECT command is used to electrically disconnect a bus and all
equipment connected to it. This command results in the use of activities DSCN and ORDR.
|DISCONNECT| |LINE | [|CKT | ]
|TRIP | |TIE | [n] FROM [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT| (id)]
|OPEN | |BRANCH|
This form of the DISCONNECT command is used to remove a specified branch from ser-
vice. If the optional circuit identifier tokens are omitted, a circuit identifier of 1 is assumed.
The branch status flag is set to zero; refer to Non-Transformer Branch Data and
Section 5.9.1 Equipment Status Changes.
|RECONNECT| |LINE | [|CKT | ]

|CLOSE | |TIE | [n] FROM [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT|(id)]
|RECLOSE | |BRANCH|
This form of the RECONNECT command is used to return a specified branch to service. If
the optional circuit identifier tokens are omitted, a circuit identifier of 1 is assumed. The
branch status flag is set to one; refer to Non-Transformer Branch Data and Section 5.9.1
Equipment Status Changes.
|TRIP |THREEWINDING [n] FROM [n] BUS (bsid) TO [n] BUS (bsid) TO [n] BUS (bsid) [|CIRCUIT| (id)]
|OPEN |
This form of the DISCONNECT command is used to remove all windings of a specified
three-winding transformer from service. If the optional circuit identifier tokens are omitted,
a circuit identifier of 1 is assumed. The transformer status flag is set to zero; refer to Trans-
former Data and Section 5.9.1 Equipment Status Changes.
|TRIP |THREEWINDING [n] AT [n] BUS (bsid) TO [n] BUS (bsid) TO [n] BUS (bsid) [|CIRCUIT| (id)]
|OPEN |
This form of the DISCONNECT command is used to remove the winding connected to the
bus specified as the AT bus of a specified three-winding transformer from service. If the
optional circuit identifier tokens are omitted, a circuit identifier of 1 is assumed. The trans-
former status flag is set to 2, 3 or 4; refer to Transformer Data and Section 5.9.1 Equipment
Status Changes.
|RECONNECT| [|CKT | ]
|CLOSE |THREEWINDING [n] FROM [n] BUS (bsid) TO [n] BUS (bsid) TO [n] BUS (bsid) [|CIRCUIT| (id)]
|RECLOSE |
This form of the RECONNECT command is used to return all windings of a specified three-
winding transformer to service. If the optional circuit identifier tokens are omitted, a circuit
identifier of 1 is assumed. The transformer status flag is set to one; refer to Transformer
16-37
Data and Section 5.9.1 Equipment Status Changes.
BLOCK DCLINE (dc id)
The BLOCK command is used to block a specified two-terminal dc line. The control mode
is set to zero; refer to Two-Terminal DC Transmission Line Data.
UNBLOCK DCLINE (dc id)
The UNBLOCK command is used to unblock a specified two-terminal dc line. The control
mode is set to one (i.e., the UNBLOCK command assumes power control mode). Refer to
Two-Terminal DC Transmission Line Data.
|POWER |
|CURRENT |
SET [n] DCLINE (dc id) |SETPOINT| TO (R)
|SCHEDULE|
|VOLTAGE |
This form of the SET command is used to change the current or power demand (POWER,
CURRENT, SETPOINT) or scheduled dc voltage (SCHEDULE, VOLTAGE) on a specified
two-terminal dc line to a designated value; refer to Two-Terminal DC Transmission Line
Data.
|VAR|
SET [n] |CON| (I) TO (R)
This form of the SET command is used to change a specified VAR or CON to a designated
value. Refer to activity ALTR and 21.1.2.
|(C)|
SET [n] ICON (I) TO |(I)|
This form of the SET command is used to change a specified ICON to a designated integer
or character value. Refer to activity ALTR and 21.1.2.
|VAR[S]|
SET [n] |CON[S]| (I1) THRU (I2) TO (R1) ... (Rm)
This form of the SET command is used to change up to twenty-five consecutive VARs or
CONs to designated values. Refer to activity ALTR and 21.1.2.
|(C1)| |(Cm)|
SET [n] ICON[S] (I1) THRU (I2) TO |(I1)| ... |(Im)|
This form of the SET command is used to change up to twenty-five consecutive ICONs to
designated integer and/or character values. Refer to activity ALTR and 21.1.2.
[|CYCLE[S] |]
SET [n] STEP TO (R) (n) [|SECOND[S]|] [n]
This form of the SET command is used to change the simulation time step, DELT, to a des-
ignated value. The new time step may be specified in either seconds or cycles. When nei-
ther of the optional tokens is specified, SECONDS is assumed.
16-38
NEXT [CHANNEL[S] (I)] [VAR[S] (I)] [ICON[S] (I)]
The NEXT command is used in conjunction with PLACE commands to form the dialog
required by activity CHAN to assign simulation variables to PSS®E output channels. It is
used in setting the responses for the starting channel, VAR and ICON indices to be used
by activity CHAN. If a NEXT command is not entered, or if the CHANNEL, VAR and/or
ICON keywords and values are omitted from the NEXT command, a corresponding default
response is generated in the Response File. When the Response File is subsequently
executed, activity CHAN will use the next available location pointers as contained in
dynamics data memory.
PLACE quantity [n] BUS (bus id) [MACHINE (id)] IN CHANNEL[S]
[WITH IDENTIFIER[S] (ident) [AND (ident)]]
This form of the PLACE command is used to assign a single machine quantity (two quan-
tities in the case of MACHAPPIMP) to an output channel. < quantity > may be specified as
one of the following machine related tokens:
ANGLE PELEC QELEC ETERM ECOMP EFD PMECH

VREF SPEED XADIFD VOTHSG VUEL VOEL
MACHAPPIMP MACHITERM
If the optional machine identifier tokens are omitted, channels for all machines at the bus
are generated. The user may either specify the channel identifier(s) to be assigned to the
output channel(s) or let activity CHAN assign them. Refer to Table 15-2 Activity CHAN
Summary and 21-1, activity ALTR, and Section 21.6.1 Output Channel Selection.
|BSFREQ |
|VOLTAGE |
PLACE |VOLT&ANG| [n] BUS (bus id) IN CHANNEL[S]
[WITH IDENTIFIER[S] (ident) [AND (ident)]]
This form of the PLACE command is used to assign a single bus quantity (two quantities in
the case of VOLT&ANG) to an output channel. The user may either specify the channel
identifier(s) to be assigned to the output channel(s) or let activity CHAN assign them. Refer
to Table 15-2 Activity CHAN Summary and 21-1, activity ALTR, and Section 21.6.1 Output
Channel Selection.
|PLOAD|
PLACE |QLOAD| [n] BUS (bus id) [LOAD (id)] IN CHANNEL[S]
[WITH IDENTIFIER (ident)]
This form of the PLACE command is used to assign a single load quantity to an output
channel. If the optional load identifier token is omitted, channels for all loads at the bus are
generated. The user may either specify the channel identifier to be assigned to the output
channel(s) or let activity CHAN assign it. Refer to Table 15-2 Activity CHAN Summary and
21-1, activity ALTR, and Section 21.6.1 Output Channel Selection.
PLACE quantity [n] BUSES (I1) THRU (I2) IN CHANNEL[S]
This form of the PLACE command is used to assign a specified machine, bus, or load
related quantity to output channels for all machines, buses, or loads within a designated
bus number range. < quantity > is specified as in the three BUS forms of the PLACE
command given above. Refer to Table 15-2 Activity CHAN Summary and 21-1, activity
16-39
ALTR, and Section 21.6.1 Output Channel Selection.

|FLOWP | [|CKT | ]
PLACE |FLOWPQ | [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT| (id)]
|FLOWMVA|
|RELAY2 |
IN CHANNEL[S] [WITH IDENTIFIER[S] (ident) [AND (ident)]]
This form of the PLACE command is used to assign one or two branch related quantities
to output channels for a designated branch. If the optional circuit identifier tokens are
omitted, a circuit identifier of 1 is assumed. The second token specified indicates quantities
to be monitored as follows:
FLOWP One channel containing the active power flow on the branch.
FLOWPQ Two channels containing the active and reactive power flow on the branch.
FLOWMVA One channel containing the MVA flow on the branch.
RELAY2 Two channels containing the apparent impedance on the branch as n by
the RELAY2 model.
The user may either specify the channel identifier(s) to be assigned to the output channel(s)
or let activity CHAN assign them. Refer to Table 15-2 Activity CHAN Summary and 21-1,
activity ALTR, and Section 21.6.1 Output Channel Selection.
|3WNDFLOWP |
|3WNDFLOWPQ |
|3WNDFLOWMVA| [|CKT | ]
PLACE |3WNDRELAY3 | [n] BUS (bus id) TO [n] BUS (bus id) TO [n] BUS (bus id) [|CIRCUIT| (id)]
IN CHANNEL[S] [WITH IDENTIFIER[S] (ident) [AND (ident)]]
This form of the PLACE command is used to assign one or two branch related quantities
to output channels for the three-winding transformer winding connected to the first bus
specified. If the optional circuit identifier tokens are omitted, a circuit identifier of 1 is
assumed. The second token specified indicates quantities to be monitored as follows:
3WNDFLOWP One channel containing the active power flow into the winding.
3WNDFLOWPQ Two channels containing the active and reactive power flow into the
winding.
3WNDFLOWMVA One channel containing the MVA flow on the winding.
3WNDRELAY3 Two channels containing the apparent impedance on the winding
as n by the RELAY3 model.
The user may either specify the channel identifier(s) to be assigned to the output channel(s)
or let activity CHAN assign them. Refer to Table 15-2 Activity CHAN Summary and 21-1,
activity ALTR, and Section 21.6.1 Output Channel Selection.
|VAR[S] |
PLACE |STATE[S]| (I1) [THRU (I2)] IN CHANNEL[S]
This form of the PLACE command is used to assign one or more consecutive VARs or
STATEs to output channels. Refer to Table 15-2 Activity CHAN Summary and 21-1, activity
ALTR, and Section 21.6.1 Output Channel Selection.
16-40
|PSS |
|PASS |
|PASSTHRU|
The PASSTHRU command is used to inform activity PSAS that subsequent command
input is in the form of BAT_ records (refer to PSS®E Application Program Interface (API))
and/or PSS®E activity commands and responses to questions rather than in the form of
PSAS commands. While passthru mode is in effect, each input to activity PSAS is simply
appended to the Response File being built without modification. If input to activity PSAS is
being taken from the user’s terminal, the prompt PASSTHRU: is issued while this mode is
in effect. Passthru mode is terminated and PSAS command mode reinstated by entering
the command FIN (see below). @INPUT and @CHAIN commands must not be specified
while passthru mode is in effect; the IDEV activity command may be specified.
FIN
Terminate passthru mode (see above) and reinstate PSAS command mode.
|USE |
|COPY| (response-file-filename) [arg1 ... [arg9]]
|IDEV|
The USE command allows the user to include the BAT_ records (refer to PSS®E Applica-
tion Program Interface (API)) and/or PSS®E line mode commands and responses to
instructions which are contained in a Response File within the PSAS commands which
define a PSS®E calculation sequence. The USE filename command is converted to an
@INPUT filename command and inserted into the Response File being constructed by
activity PSAS. Note that entries in the designated file must be in the form of BAT_ records
and/or activity commands and responses to questions rather than in the form of PSAS
commands.
The designated file may contain @INPUT commands but must not contain any @CHAIN
commands or IDEV activity commands. The designated file must be terminated with an
@END command; it must not be terminated with an IDEV activity command or a FIN PSEB
command.
EXECUTE (iplan-program-filename)
The EXECUTE command allows the user to include the execution of an IPLAN program
within the PSAS commands which define a calculation sequence. The EXECUTE filename
PSAS command is converted to an EXEC filename activity command (refer to activity
EXEC) and inserted into the Response File being constructed by activity PSAS.
WATCH [OFF]
The WATCH command is used to enable or disable the echoing of responses generated
from PSAS commands to the dialog output device (normally the user’s terminal). Response
echoing is disabled upon entering activity PSAS; the PSAS command WATCH enables
response echoing and WATCH,OFF disables it.
16-41
CHECK
The CHECK command instructs activity PSAS to bypass the automatic execution of the
Response File which it constructs (refer to Section 16.15.3 Operation of Activity PSAS).
END
The END command terminates PSAS command input. Unless it is otherwise suppressed
(refer to Section 16.15.3 Operation of Activity PSAS), the Response File constructed by
activity PSAS is automatically executed.
ABORT
The ABORT command terminates activity PSAS and bypasses the automatic execution of
the Response File which it has constructed.
HELP
This form of the HELP command displays the list of PSAS commands at the dialog output
device (refer to Section 4.4 Virtual Output Devices).
HELP,command
This form of the HELP command displays the syntax format of the specified PSAS
command at the dialog output device (refer to Section 4.4 Virtual Output Devices).
16.15.3 Operation of Activity PSAS

The user specifies either:
• The name of the appropriate PSAS Command File (refer to Section 2.4.1 File Usage).
If the specified file does not exist or some other file system related error occurs, an
appropriate error message is printed and the request for the input device is repeated.
• Data input from the user’s terminal. This applies to both interactive and Response File
operation of PSS®E.
The user specifies an output filename. Refer to Section 2.4.1 File Usage for the file specification
conventions used by activity PSAS. If a file system error occurs while opening the specified file, an
appropriate error message is printed. If no filename is specified, activity PSAS writes its output into
a file for which the name is of the form PSASnnn.IDV, where < nnn > is a number which is set such
that the resulting filename is a new file in the user’s directory.
When terminal input had been specified, activity PSAS issues the prompt PSAS: each time it is
ready to accept a new PSAS command. PSAS command input is terminated by entering either the
END or ABORT command.
When input is taken from a PSAS Command File, no prompts are issued. If the input file is not termi-
nated with either the END or ABORT command, the following message is printed:
OUT OF FILE DATA--SWITCH TO TERMINAL INPUT MODE

Additional PSAS command input records may then be entered from the user’s terminal.
If an error occurs in processing an input record, an appropriate error message is printed, the
offending record is ignored, and processing continues.
16-42
Upon entry of either the END or ABORT command, activity PSAS is terminated and, except as
described below, an @INPUT command is automatically issued to execute the Response File
constructed by activity PSAS. If PSS®E is already being operated in Response File mode (i.e.,
activity PSAS was initiated from a Response File), any remaining commands contained in the orig-
inal Response File are executed following the execution of the Response File created by activity
PSAS.
The execution of the PSAS Response File is bypassed if any one of the following has occurred:
1. Command line only: Activity PSAS was invoked with the suffix CHECK.
2. The PSAS command CHECK was entered during PSAS command input.
3. Command line only: PSAS command input was terminated with the command ABORT
rather than END.
4. Any errors were encountered during the processing of PSAS command input. In this case,
if PSS®E is being operated in its Response File mode, all active Response Files are closed
and further user inputs to PSS®E are taken from the user’s terminal.
When automatic Response File execution is bypassed, activity PSAS prints the message:
YOUR RESPONSE FILE IS filename

where < filename > is the name of the PSS®E Response File corresponding to the run described
by the PSAS commands which were specified.
While activity PSAS may be used with an ECHO file enable, care must be exercised if the automatic
execution of the Response File built by activity PSAS occurs. In this case, the ECHO file will contain
the commands used to execute activity PSAS as well as the Response File commands generated
by activity PSAS. That is, if subsequently executed as a PSS®E Response File, the ECHO file will
perform the sequence defined by the PSAS commands twice.

When using the SET command to assign values to VARs, CONs and/or ICONs, the corresponding
Response File dialog is not generated until either:
1. A START, RUN, HOLD, PASS, USE, EXECUTE, END, or ABORT command, or one of their
synonyms, is entered; or
2. Two hundred data items have been specified in SET commands.
This minimizes the number of entries into activity ALTR.
In a similar manner, the Response File dialog for PLACE commands is not generated until either:
1. A NEXT, START, RUN, HOLD, PASS, USE, EXECUTE, END, or ABORT command, or one
of their synonyms, is entered; or
2. Two hundred simulation variables have been specified in PLACE commands.
This minimizes the number of entries into activity CHAN.
16-43
Launching an IPLAN Program File Program Operation Manual
The generation of the Response File entries corresponding to previously specified PLACE
commands cancels the parameters established by any previous NEXT command.
®
PSS E GUI Users Guide, Section 23.3.4, PSAS Command File, Dynamic Simulation
Section 19.5, Building a Response File, Dynamic Simulation
16.16 Launching an IPLAN Program File

Activity EXEC
Run an IPLAN Program - GUI

IPLAN File (*.irf)
Run Line Mode Activity EXEC - CLI
ACTIVITY?
>>EXEC,filename
>>
Python Command
psspy.runiplanfile <filename>
None
The programmable PSS®E execution activity EXEC retrieves an IPLAN executable program and
starts its execution. The IPLAN program must have been compiled by the IPLAN compiler from its
source form into an IPLAN Executable Program File, and the name of the IPLAN Executable
Program File must be specified.
Activity EXEC itself is not sensitive to any interrupt control code options. However, PSS®E activities
executed under control of an IPLAN program respond to interrupt control codes in their normal
fashion. In addition, the IP interrupt control code may be used to terminate execution of an active
IPLAN program.
16.16.1 IPLAN Programs

IPLAN is high-level programming language designed to be utilized as an enhancement to existing
application programs such as PSS®E, but which can also be used as a stand-alone product. IPLAN
is a Siemens PTI proprietary programming language that requires compilation in order to be
executed in PSS®E. The compiled IPLAN program in binary format is used as input to the IPLAN
simulator which is built into PSS®E. Programs written in IPLAN are created by the user with a stan-
dard text editor and compiled using the IPLAN compiler program supplied with PSS®E.
16-44
Program Operation Manual Launching an IPLAN Program File
Compiled IPLAN Files can be used in PSS®E in any of the following ways:
• from I/O Control >Run Program Automation File… (see Section 16.3 Automation
Methods in PSS®E)
• via line mode activity EXEC (see Section 16.11 Line Mode Commands)
• via the EXECUTE command in PSAS and PSEB (see Sections 16.14.1 and 16.15.1)
• via the runiplanfile function in the Python extension module psspy (see Section 16.4.1
PSS®E Extension Modules For Python)
For specific detailed information and instructions on how to use the IPLAN language, please refer
to the IPLAN Program Manual.
16.16.2 Interaction With PSS®E

The IPLAN compiler and simulator recognize the Single Element Data Retrieval routines from the
PSS®E API. They are used in IPLAN CALL statements. This means that IPLAN programs can
assign various values from the PSS®E network case to variables and act on them.
IPLAN cannot modify PSS®E directly, or call other routines in the PSS®E API directly. However, via
the PUSH (and PUSHX, QPUSH, QPUSHX) command(s) it can do anything that can be done in a
Response File. That includes, say, @input, which will open a Response File; in that case, the
commands in that response file will not take effect immediately unless other steps are taken. This
is explained in detail in the IPLAN Program Manual.
One of the commands in line mode is EXEC, which is used to load an IPLAN program. If an IPLAN
program invokes EXEC through a PUSH statement or by causing a Response File containing EXEC
to run, that program will replace the current one in the IPLAN simulator. IPLAN programs do not
nest.
16.16.3 The IPLAN Stand-Alone Simulator

The IPLAN compiler can call the IPLAN simulator directly. When used in this mode PUSH
commands are just displayed at the terminal, and fetch routines return default values (non-zero
return codes where appropriate, else zeros and blanks).
16.16.4 Operation of Activity EXEC

If no file is specified, or if a file system error condition is encountered in opening the designated file,
an error message is printed and activity EXEC is terminated.
Activity EXEC first searches the current directory for the IPLAN program file. If it is not found there,
activity EXEC follows the directory search sequence described in Section 2.1 Directories and Files
Overview and looks to the user’s home directory and the PSS®E master directory PROGRAMS for
the file. If the file is not found, an appropriate message is printed and activity EXEC is terminated.
Refer to Section 2.4.1 File Usage for the file specification conventions used in specifying filenames
to activity EXEC.
If the IPLAN program in the above example requires run-time arguments, it may be initiated with
either of the activity commands:
exec,job1, argument_list
exec,job1, -arg
16-45
Launching an IPLAN Program File Program Operation Manual
When the token -arg is specified, activity EXEC instructs the user to specify the argument list which
is to be passed to the IPLAN program.
After the IPLAN program is loaded into PSS®E’s working memory, activity EXEC is terminated and
execution of PSS®E continues. PSS®E’s next request for input (i.e., for the user’s specification of
the next function or activity to be performed) triggers the execution of the IPLAN program. When
the PSS®E GUI is being used, a read from the dialog input device is forced after the IPLAN program
is loaded. While an IPLAN program is controlling the execution of PSS®E, input to PSS®E is
normally taken from the IPLAN program rather than from the PSS®E dialog input device. On the
other hand, input to the IPLAN program to satisfy any IPLAN INPUT and INPUTLN statements is
always taken from the dialog input device. When the PSS®E GUI is being used, a General Input
Window is created containing whatever prompts are awaiting display and taking the request input.
PSS®E continues to accept input from the IPLAN program until either an IPLAN PAUSE, PAUSE
UNTIL, or PAUSE READ statement is executed; or the IPLAN program is terminated. At this time,
PSS®E looks to the dialog input device for its input, or control returns to the GUI.
The input conventions described above apply regardless of whether interactive operation is active,
the execution of the IPLAN program is initiated from a Response File, or the IPLAN program
PUSHes an @INPUT or @CHAIN command or an IDEV,filename activity command. IPLAN
Program Manual gives some examples describing the interaction of Response Files and IPLAN
programs when both are active simultaneously.
While the redirection of input to PSS®E provided by activity EXEC is similar in concept to the use
of Response Files, an IPLAN program is much more flexible than a Response File; it may receive
information from PSS®E and make decisions based upon PSS®E execution results.
For details on the IPLAN programming language, the IPLAN language interface to the PSS®E
working case and dynamics data, and the IPLAN compiler, refer to the IPLAN Program Manual.
®
PSS E GUI Users Guide, Section 23.3.2, IPLAN Program File
Section 19.7, Launching an IPLAN Program File
16-46
Chapter 17
Result Retrieval
Chapter 17 - Result Retrieval
17.1 Python Modules for Result Retrieval

Activity Python Lists
PSS®E result retrieval APIs (Chapter 9, PSS®E Application Program Interface (API)) are used to
retrieve PSS®E activity results into Python lists. Such lists then can be used to make customized
reports or for further processing using Python scripts. This chapter describes how to invoke these
APIs from PSS®E Python automation files or the PSS®E CLI (command line input), and write
simple Python scripts using these APIs to further process the results. The Python modules available
for such a use are:
• PSSARRAYS module returns data and results from PSS®E activities to Python lists.
• PSSEXCEL module creates and populates Excel spreadsheets with data and results
from PSS®E activities. This module is an example of how to use Python lists returned
by PSSARRAYS for further processing. This modules uses the PSSARRAYS module
to retrieve PSS®E activity data and results and the EXCELPY module to write the data
and results to Excel spreadsheets.
• EXCELPY is an auxiliary module that provides Python functions to create and populate
Excel spreadsheets.
Following sections describe just a few functions and give sample Python commands/code to illus-
trate how to use Python functions available in these modules. These Python commands can be
executed from either PSS®E program automation files or the PSS®E CLI.
17-1
Result Retrieval PSS®E 34.2
pssarrays.accc_summary Program Operation Manual
17.2 pssarrays.accc_summary
Activity pssarrays.accc_summary
17.2.1 CLI
import pssarrays 1
2
smry = pssarrays.accc_summary(r"savnw.acc")
or
smry = pssarrays.accc_summary(accfile=r"savnw.acc")
or
smry = pssarrays.accc_summary(accfile=r"c:\filepath\savnw.acc")
print smry.ierr 3
0
print smry.acccsize.nmline
11
print smry.file.acc
C:\Program Files\PTI\PSSE31 Alpha 2\EXAMPLE\savnw.acc
print smry.melement
(' 201 HYDRO 500.00 151 NUCPANT 500.00 1', ' 202
EAST500 500.00 152 MID500 500.00 1', ' 203 EAST230
230.00 154 DOWNTN 230.00 1', ' 205 SUB230 230.00 154
DOWNTN 230.00 1', ' 3001 MINE 230.00 3002 E. MINE
500.00 1', ' 3004 WEST 500.00 152 MID500 500.00 1', '
3004 WEST 500.00 3005 WEST 230.00 1', ' 3005 WEST
230.00 3008 CATDOG 230.00 1', ' 3006 UPTOWN 230.00 153
MID230 230.00 1', ' 3008 CATDOG 230.00 154 DOWNTN
230.00 1', ' 3008 CATDOG 230.00 3018 CATDOG_G 13.800 1', '
INTERFACE WEST', ' INTERFACE EAST')
print smry.mvbuslabel
(' 3001 MINE 230.00', ' 201 HYDRO 500.00', ' 202
EAST500 500.00', ' 203 EAST230 230.00', ' 204 SUB500
500.00', ' 205 SUB230 230.00', ' 206 URBGEN 18.000', '
211 HYDRO_G 20.000', ' 3001 MINE 230.00', ' 3002 E. MINE
500.00', ' 3003 S. MINE 230.00', ' 3004 WEST 500.00', '
3005 WEST 230.00', ' 3006 UPTOWN 230.00', ' 3007 RURAL
230.00', ' 3008 CATDOG 230.00', ' 3011 MINE_G 13.800', '
3018 CATDOG_G 13.800')
By importing the pssarrays module, the functions defined inside this module are made avail-
1 able outside of the module.
The accc_summary function can be called in any of the following ways:

2
• Contingency Solution Output file is available in the working folder.
17-2
PSS®E 34.2 Result Retrieval
Program Operation Manual pssarrays.accc_summary
• Contingency Solution Output file is available in the working folder, accc_summary func-
tion called with keyword argument accfile.
smry = pssarrays.accc_summary(accfile=r"savnw.acc")
• Contingency Solution Output file is not available in the working folder, then its location
needs to be specified.
smry = pssarrays.accc_summary(accfile=r"c:\filepath\savnw.acc")
Note: The accfile name is specified in r"…" format, to make the filename a Python raw
string. It suppresses escapes sequences, viz., \n for newline character, \t for tab etc.
ACCC summary results are returned in the Python list smry. The various values available
3 in this list are accessed by their names as an attribute of the returned list. The API docu-
mentation provide the list of values available in the returned list.
The following Python commands print some of these values.

• Value ierr gives the error condition.
print smry.ierr
• Value acccsize.nmline gives the number of monitored elements (branches +
interfaces).
• Value file.acc gives the .acc input filename.
print smry.file.acc
• Value smry.melement gives the monitored element labels.
print smry.melement
• Value smry.mvbuslabel gives the monitored bus labels.
17.2.2 Automation File

The examples above can be combined into one Python file, as shown below, and run as a PSS®E
automation file to report on the basic data contained within an ACCC output file. Any Python code
can be added to this code to further process the returned values.
import pssarrays
print smry.ierr
print smry.file.acc
print smry.melement
17-3
pssarrays.accc_solution Program Operation Manual
17.3 pssarrays.accc_solution
Activity pssarrays.accc_solution
The following Python code example shows how to get ACCC analysis results and write them to a
report.
import pssarrays
reptfile = 'accc_output.txt'
reptnam = open(reptfile,'w')
smry = pssarrays.accc_summary(accfile=r'savnw.acc')
rate = smry.rating.a
stype = 'con'
for lbl in smry.colabel:

soln = pssarrays.accc_solution(accfile=r'savnw.acc',
colabel=lbl,stype=stype,busmsm=0.5,sysmsm=5.0)
if soln == None: continue # contingency solution not found,
# move to next
if soln.ierr !=0: continue # return any non-zero ierr
reptnam.write("CONTINGENCY EVENTS\n")
# (1) contingency events summary

cnvflag = soln.cnvflag
cnvcond = soln.cnvcond
island = ("%d" % soln.island).center(7)
mvaworst = soln.mvaworst
mvatotal = soln.mvatotal
for jj in range(len( soln.codesc)):
desc = soln.codesc[jj]
if jj == 0:
reptnam.write("%(lbl)s %(desc)s %(cnvflag)s \
%(cnvcond)s %(island)s %(mvaworst)11.4f \
%(mvatotal)11.4f\n" % vars())
else:
tmp = 12*' '
reptnam.write("%(tmp)s %(desc)s\n" % vars())
if not cnvflag:
reptnam.write("\n================================\n")
continue # consider solution for converged cases only
# (2) flows
txtstr = ''
17-4
Program Operation Manual pssarrays.accc_solution
for jj in range(smry.acccsize.nmline+smry.acccsize.ninter):
mvaflow = "%9.2f" % soln.mvaflow[jj]
if jj < smry.acccsize.nmline:
ampflow = "%9.2f" % soln.ampflow[jj]
pctflow = abs( soln.ampflow[jj])
else:
ampflow = 9*' '
pctflow = abs( soln.mvaflow[jj])
if rate[jj]:
pctflow = "%6.2f" % (pctflow*100.0/rate[jj])
else:
pctflow = 6*' '
txtstr += " %(mvaflow)s %(ampflow)s %(pctflow)s " %vars()

if txtstr:
reptnam.write("\nMONITORED ELEMENT FLOWS\n")
reptnam.write("%(lbl)-12s%(txtstr)s\n" % vars())
# (3) voltages
if smry.acccsize.nmvbus:
reptnam.write("\nMONITORED BUS VOLTAGES\n")
txtstr = ''
for eachv in soln.volts:
txtstr += " %8.5f" % eachv
if txtstr:
reptnam.write("%(lbl)-12s%(txtstr)s\n" % vars())
# (4) loads shed

if len( soln.lshedbus):
reptnam.write("\nLOADS SHED\n")
for jj in range(len(soln.lshedbus)):
if stype in ['caction','corrective action','cor']:
reptnam.write("%25s %10.2f %10.2f %12s\n" % \
(soln.lshedbus[jj], soln.loadshed[0][jj],
soln.loadshed[1][jj], lbl))
else:
reptnam.write("%25s %10.2f %12s\n" % \
(soln.lshedbus[jj], soln.loadshed[jj], lbl))
# (5) generator dispatch

if stype in ['caction','corrective action','cor'] and \
len( soln.gdispbus):
17-5
pssarrays.accc_violations_report Program Operation Manual
reptnam.write("\nGENERATOR DISPATCH\n")
for jj in range(len( soln.gdispbus)):
(soln.gdispbus[jj], soln.gendisp[0][jj],
soln.gendisp[1][jj], lbl))
# (6) phase shifter

if stype in ['caction','corrective action','cor'] and \
len( soln.phsftr):
reptnam.write("\nPHASE SHIFTER ANGLE\n")
for jj in range(len( soln.phsftr)):
(soln.phsftr[jj], soln.phsftrang[0][jj],
soln.phsftrang[1][jj],lbl))
reptnam.write("\n================================\n")
reptnam.close()
print "ACCC Solution saved in file %s." % reptfile
17.4 pssarrays.accc_violations_report
This function creates the following reports:
• monitored element flow violations (percent flow greater than flow limit). The flow limit is
specified as an argument of this function.
• monitored bus voltage violations (bus voltage <minimum voltage bound or >maximum
voltage bound). The voltage bound values are taken from monitored element data file
(.mon).
• loads shed
• generator dispatch
• phase shifter angle adjustments
The following command, executed from either line mode or a Python automation file, produces
ACCC violations reports for corrective action solution and reports on monitored branches where
loading is above 95%.
ierr = pssarrays.accc_violations_report( accfile=r"savnw.acc",

stype="cor", busmsm=0.5,sysmsm=5,rating=’a’,
flowlimit=95,rptfile=r"savnw_violations.txt")
17.5 pssexcel.accc
Activity pssexcel.accc
Using the pssarrays module, ACCC analysis results are retrieved from an *.acc input file and then,
using the excelpy module, these results are written to Excel Spreadsheets.
17-6
Program Operation Manual pssexcel.accc
The Python commands below create a ’savnw_acc.xls’ file and the following worksheets populated
with ACCC Corrective Action solution data from the "savnw.acc" file for contingencies ’base case’
and ’trip1nuclear’. If a colabel value is not provided, all contingencies are considered. Also the
extended bus names of monitored branches and buses are split into three Excel spread columns
(namesplit=True). The argument show=True displays the workbook when it is being populated.
• test Summary
• test Contingency Events
• test Branch Flow
• test Interface Flow
• test Bus Voltage
• Test Load Shed
• test Generator Dispatch
• test Phase Shifter Angle
import pssexcel
pssexcel.accc(accfile = r"savnw.acc",
string = ['b','e','g','i','l','p','s','v'],
colabel = ['base case', 'trip1nuclear'],
stype = 'con',
busmsm = 0.5,
sysmsm = 5.0,
rating = 'a',
namesplit = True,
xlsfile = r'savnw_acc.xls',
sheet = 'test',
overwritesheet = True,
show = True,
ratecon = ’b’,
baseflowvio = True,
basevoltvio = True,
flowlimit = 100.0,
flowchange = 0.0,
voltchange = 0.0,
)
In the command above, accfile and string are the only mandatory arguments. The worksheets
to create are defined by the string argument.
17-7
pssexcel.pv Program Operation Manual
17.6 pssexcel.pv
Activity pssexcel.pv
Using the pssarrays module, PV solution results are retrieved from a *.pv input file and then, using
the excelpy module, these results are written to Excel Spreadsheets.
The Python commands below create a ’savnw_pv.xls’ file and the following worksheets populated
with PV solution results from the "savnw.pv" file for contingencies ’base case’ and ’trip1nuclear’. If
a colabel value is not provided, all contingencies are considered. Also the extended bus names
of monitored branches and buses are split into three Excel spread columns (namesplit=True).
The argument show=True displays the workbook when it is being populated.
• testpv Summary
• testpv Bus Voltage
• testpv Mismatch
• testpv Generator Dispatch
• testpv Bus Load
• testpv Branch Flow
• testpv Interface Flow
import pssexcel
pssexcel.pv(pvfile = r"savnw.pv",
string = ['s','m','v','g','l','b','i'],
namesplit = True,
xlsfile = r'savnw_pv.xls',
sheet = 'testpv',
show = True
)
In the command above, pvfile and string are the only mandatory arguments. The worksheets
to create are defined by the string argument.
17.7 excelpy Examples

Activity excelpy Examples
17.7.1 Export QV Solution to Excel Spreadsheet

The following Python code writes QV solution summary and bus voltage results from "savnw.qv" file
to the Excel spreadsheet ’testqv.xls’.
• Using the pssexcel.qv function

import pssexcel
pssexcel.qv(qvfile = r"savnw.qv",
string = ['s','v'],
17-8
Program Operation Manual excelpy Examples

namesplit = False,
xlsfile = r'testqv.xls',
sheet = '',
show = True
)
• Using the pssarrays and excelpy modules
The following example illustrates how the pssarrays and excelpy modules can be used to
export PSS®E activity data and results to Excel spreadsheets.
import excelpy
import pssarrays
qvfile = r"savnw.qv"
colabel = ['base case', 'trip1nuclear']
xlsfile = 'testqv.xls'
# create Excel workbook, with sheet 'qvsummary'

qvxls = excelpy.workbook(xlsfile=xlsfile, sheet='qvsummary',
overwritesheet=True)
qvxls.show() # show workbook
qvxls.font_sheet() # set default font for 'qvsummary' worksheet
# add other sheets as required

qvxls.worksheet_add_end(sheet='qvvolts',overwritesheet=True)
qvxls.font_sheet() # set default font for ''qvvolts' worksheet
# Get Summary and validate contingency labels provided

smry = pssarrays.qv_summary(qvfile)
# populate qvsummary worksheet

qvxls.set_active_sheet('qvsummary')
row, col = 1, 1
qvxls.set_cell((row,col),"QV SOLUTION RESULTS",fontStyle="bold",
fontSize=14, fontColor="blue")
tmplst=[
smry.casetitle.line1,
smry.casetitle.line2,
'QV output file = %s' % smry.file.qv,
'Saved Case file = %s' % smry.file.sav,
17-9
excelpy Examples Program Operation Manual
'DFAX file = %s' % smry.file.dfx,

'Subsystem file = %s' % smry.file.sub,
'Monitored Element file = %s' % smry.file.mon,
'Contingency Description file = %s' % smry.file.con,
' ', # blank row
'Number of Contingencies+Base Case = %d' % smry.qvsize.ncase,
'Number of Monitored Generators(Plants)= %d' %
smry.qvsize.nmgnbus,
'Number of Voltage Monitored Buses = %d' % smry.qvsize.nmvbus,
'Number of Voltage Monitored Records = %d' % smry.qvsize.nmvrec,
'Number of max.volt. setpoint changes = %d' % smry.qvsize.nmxvstp,
]
if smry.file.thr:
tmplst.insert(4,'Load throwover file = %s' % smry.file.thr)
row += 2
bottomRow,rightCol = qvxls.set_range(row,col,tmplst,transpose=True)
qvxls.font_color((row,col,row+1,col),'brown')
row = bottomRow+2
qvxls.set_cell((row,col),"QV Contingencies",fontStyle="Bold",
fontSize=12, fontColor="red")
conlst = [['CON#', 'LABEL', 'Min Vstp', 'Max Vstp', 'Min MVAR',

'Max MVAR', 'Max Mismatch', 'DESCRIPTION']]
for i in range(smry.qvsize.ncase):
if i==0:
srnum = ' '
else:
srnum = str(i)
nam = smry.colabel[i]
minvstp = smry.minvstp[i]
maxvstp = smry.maxvstp[i]
minmvar = smry.minmvar[i]
maxmvar = smry.maxmvar[i]
maxmsm = smry.maxmsm[i]
for j in range(len(smry.codesc[i])):
dsc = smry.codesc[i][j]
if j==0:
conlst.append([srnum,nam,minvstp,maxvstp,minmvar,
maxmvar,maxmsm,dsc])
17-10
else:
conlst.append(['' ,'' ,'' ,'' ,'' ,'' ,'' ,dsc])
row += 1
bottomRow,rightCol = qvxls.set_range(row,col,conlst)
qvxls.font_color((row,col,row,rightCol), "dgreen")
qvxls.font((row,col+2,bottomRow,col+3),numberFormat='0.00')
qvxls.font((row,col+4,bottomRow,col+6),numberFormat='0.000')
qvxls.align((row,col),'right')
qvxls.font((row,col,row,rightCol),fontStyle=('Bold',))
qvxls.autofit_columns((row,col+1,row,rightCol))
# done qvsummary worksheet
# populate qvvolts worksheet

mvbuslabel = list(smry.mvbuslabel)
mvbuslabel.insert(0,'VOLTAGE SETPOINT->')
qvxls.set_active_sheet('qvvolts')
row, col = 1, 1
for lbl in colabel:

soln = pssarrays.qv_solution(qvfile,lbl)
if soln==None: continue # contingency solution not found
if soln.ierr !=0: continue # solution with error
contitle = 'CONTINGENCY: ' + lbl.strip()
# assemble data in columns: 1st=MW Transfer, rest=bus voltages

tmplst = [ mvbuslabel ]
for i in range(len(soln.vsetpoint)):
t = list(soln.volts[i])
t.insert(0,soln.vsetpoint[i])
tmplst.append(t)
col = 1
qvxls.set_cell((row,col+1),contitle,fontStyle='bold',
fontSize=12,fontColor="dgreen")
row += 1
bottomRow,rightCol =
qvxls.set_range(row,col,tmplst,transpose=True)
qvxls.font((row,col,row,rightCol),fontColor="red",fontStyle='bold')
17-11
qvxls.font((row,col+1,bottomRow,rightCol),numberFormat="0.000")
qvxls.align((row,col,row,rightCol),'h_center')
qvxls.align((row,col),'right')
qvxls.font((row+1,col,bottomRow,col),fontColor="blue",
fontStyle='bold')
row = bottomRow + 2 # one blank row
# format qvvolts worksheet

qvxls.autofit_columns((1,1))
# Save the workbook and close the Excel application

xlsfile = qvxls.save(xlsfile)
print "\n Excel workbook saved to file %(xlsfile)s.\n" % vars()
17.7.2 Write Data to Excel Spreadsheet

Following example code shows how to use excelpy functions and methods to create, populate and
format Excel workbook from Python.
import excelpy
testxls = excelpy.workbook(r"test.xls","TestExcelPy")
testxls.show()
testxls.font_sheet()
testdata=[
['CON#', 'LABEL', 'Max MW', 'DESCRIPTION'],
[' ', 'BASE CASE', 756.25, 'BASE CASE '],
['1', 'TRIP1NUCLEAR', 1000.0, 'REMOVE UNIT 1'],
['2', 'TRIP2NUCLEAR', 0.0, 'REMOVE UNIT 1'],
['', '', '', 'REMOVE UNIT 2'],
['3', 'ADDLARGELOAD', 0.0, 'INCREASE LOAD'],
['4', 'LOSEWESTGEN', 625.0, 'REMOVE UNIT 3'],
['5', 'LOSEWESTBIGT', 312.5, 'TRIP LINE 1 '],
]
row=1
col=1
testxls.set_cell(value="How to use EXCELPY module?",
address=(row,col),fontName="Arial",fontSize=12,
fontColor='red',fontStyle=('Bold','italic'))
row = row+2 #add one blank row

bottomRow, rightCol =
17-12
testxls.set_range(row,col,testdata,transpose=False)
testxls.font((row,1,row,rightCol),fontStyle='bold',fontColor='blue')
testxls.align((row,1,row,rightCol),alignv='h_center')
testxls.align((row,1,bottomRow,2),alignv='h_center')
testxls.autofit_columns((row,2,row,rightCol))
testxls.font((row,3,bottomRow,3),numberFormat='0.000')
xlsfile = testxls.save(xlsfile)
print "Excel workbook saved to ’%s’ file.\n"% xlsfile
17-13
17-14
Chapter 18
Implementing the Powerflow
Customization Interface (PCI)
Chapter 18 - Implementing the Powerflow Customization Interface (PCI)
The PCI is implemented by creating a Python module. This module must have the name pssuserpf.
See Section 16.4.5, Finding user-created modules about where this file may be located and found
by PSS®E.
18.1 Contents of pssuserpf

Normally you will create the pssuserpf module by creating a file named pssuserpf.py. The following
general comments apply:
• The function names shown in the sections below are specific; only these exact names
will be called via the PCI.
• It is not necessary to define all of these functions.
• Those that you do define must specify exactly the number of arguments shown above.
The names of the arguments are not important, but those names will be used in other
parts of the documentation.
• Functions described below that return a value must return a value of the type shown.
Values should not be returned by functions described below that do not return values.
• You may define other functions than these, if you wish, along with other constants and
variables.
In the following, the pssuserpf functions are shown in their simplest form, i.e. taking no action, other
than returning the default value if needed.
18.1.1 on_case
def on_case(casename):
pass
It is called for CASE, just before the saved case file is closed.
The argument contains the filename of the saved case file, in the form that it was given, e.g. if, in
python, you entered psspy.case('myfile.sav') then casename would contain 'myfile.sav'; if you
entered psspy.case(r'd:\stuff\afile') then casename will contain r'd:\stuff\afile'. When running inter-
actively through the PSSE GUI, full file paths are supplied.
It does not return a value.
18-1
Implementing the Powerflow Customization Interface (PCI) PSS®E 34.2
Contents of pssuserpf Program Operation Manual
18.1.2 pre_accc
def pre_accc(opts,sub,mon,con):
pass
It is called for ACCC, ACCC_WITH_DSP, and MACCC after edit checking of arguments and before
normal processing starts. Before this routine is called, the Distribution Factor File is opened to
retrieve the input filenames.
The arguments are a list containing the first 7 options (OPTACC), the Subsystem Description file-
name, the Monitored Element Description filename, and the Contingency Description filename.
Note that the filenames are in the form that they were entered, e.g. if, in python, you entered
'myfile.con’ for the Contingency Description filename, then that will be the value of the argument
'con'. When running interactively through the PSSE GUI, full file paths are supplied.
18.1.3 post_accc
def post_accc():
pass
It is called immediately before the termination of the activity.
There are no arguments.
18.1.4 pre_solution
def pre_solution():
pass
It is called for FDNS, FNSL, RUNLASTSOLUTION (if the last solution was fdns or fnsl), and GIC (if
the option to Solve Power Flow is set to 'fdns' or fnsl') after edit checking of arguments and before
normal processing starts. If the Connectivity Check option is on, the connectivity check is performed
before this call.
18.1.5 post_solution
def post_solution(errcode,solved):
pass
It is called for FDNS, FNSL, RUNLASTSOLUTION (if the last solution was fdns or fnsl), and GIC (if
the option to Solve Power Flow is set to 'fdns' or fnsl') after the solution is completed (but before
interrupt options are cleared).
The arguments contain the values of the return code FDNS or FNSL and the value of the conver-
gence flag at that time.
18-2
PSS®E 34.2 Implementing the Powerflow Customization Interface (PCI)
Program Operation Manual Contents of pssuserpf
18.1.6 pre_ca_solution
def pre_ca_solution(conlabel):
pass
It is called for ACCC, ACCC_WITH_DSP, and MACCC after the contingency has been applied but
before any processing of that contingency has begun.
The argument contains the label of the current contingency.
18.1.7 post_ca_soln_eval
def post_ca_soln_eval(conlabel,solved):
return True
It is called for ACCC, ACCC_WITH_DSP, and MACCC after each solution for the contingency has
been completed but before the restoration of the base case, provided that the limit for the number
of contingency iterations has not been reached. There is a maximum number of 20 contingency iter-
ations allowed per contingency.
The arguments contain the label of the current contingency and the value of the convergence flag
at that time.
It returns a logical value. Return False to request that post_ca_soln_adj be called to make changes
to the contingency case, and then rerun the contingency with those changes. Return True to
continue with normal termination of the current contingency.
For MACCC implementation is not complete in this release. The call to post_ca_soln_eval will take
place, but the contingency will not be repeated.
18.1.8 post_ca_soln_adj
def post_ca_soln_adj(conlabel,solved):
pass
It is called for ACCC, ACCC_WITH_DSP, and MACCC if post_ca_soln_eval returns False.
The arguments contain the label of the current contingency and the value of the convergence flag
at that time.
18.1.9 pre_iteration
def pre_iteration():
pass
It is called during initialization of a solution iteration for FDNS, FNSL, and any of the other functions
that utilize those solutions (e.g. ACCC, MACCC, GIC, etc.).
18-3
Importing pssuserpf and Progress information Program Operation Manual
18.1.10 post_iteration
def post_iteration():
return True
It is called during evaluation of the solution results for FDNS, FNSL, and any of the other functions
that utilize those solutions (e.g. ACCC, MACCC, GIC, etc.).
It returns a logical value. Return False to request another iteration. Return True to allow the solution
to determine whether another iteration is needed.
18.2 Importing pssuserpf and Progress information

The pssuserpf module is not loaded until the first time an attempt is made to call one of the functions
that it can define.
The pssuserpf module is not required, therefore there is no message if it fails to load. A message
is written to the Progress output device if the pssuserpf module is loaded successfully.
The first time each of the functions that can be defined in pssuserpf for the PCI is called, a message
is written to the Progress output device.
You can import pssuserpf at the command line in PSS®E. If you suspect an import failure - say, a
syntax error in your module - this will cause a traceback to printed to the Progress output device.
Importing the module in this way makes it available to the command input environment; it does not
make the module available to the PCI. However, even if the module is successfully imported into
both the PCI and the command input environment, only one copy of the module will be in memory.
Only one attempt will be made to load the pssuserpf module through the PCI.
Once the pssuserpf module has been successfully loaded, you can use the Python reload
command from the PSS®E command line to replace it, subject to the usual restrictions on this
ability. See Python's documentation of the reload command.
If you are not sure that the pssuserpf module (or any other python module) that is loaded is the
correct one (say you have multiple projects that you are working on and different modules defined
for each) you can use the showLoadedModules function in psspy to display all the loaded Python
modules and the file that they were loaded from. Enter:
psspy.showLoadeModules()
from the PSSE command line.
18.3 Use of the psspy module in pssuserpf

You can import psspy and use the functions defined there, with some limitations and considerations.
18-4
PSS®E 34.2 Implementing the Powerflow Customization Interface (PCI)
Program Operation Manual Using other PSS®E modules from pssuserpf
Certain of the pssuserpf functions are considered "outer" functions, others are "inner" functions. The
"outer" functions are: on_case, pre_accc, post_accc, pre_solution, post_solution, . The others are
"inner" functions.
"Outer" functions can use any of the functions defined in the module psspy, except for those that
conflict with the current API function in use (e.g. on_case cannot call CASE or READ).
"Inner" functions can only use those functions defined in the module psspy that do not change the
state of the program, i.e. those that strictly retrieve data.
18.4 Using other PSS®E modules from pssuserpf
18.4.1 pfcontrol
It is critical to the intended purpose of the PCI that certain values are modifiable from the "inner"
functions, but the PSS®E API functions in the psspy module to do so are not available to be called.
You can import pfcontrol and use the functions defined there to modify the case during solutions or
contingencies. There is an important difference in the impact of changes that are made in the
different "inner" functions:
pre_iteration, post_iteration - changes made here are permanent. This is consistent with the expec-
tation that the network case at the end of the solution represents a solved case.
pre_ca_solution, post_ca_soln_adj - changes made here affect the contingency case only. This is
consistent with the expectation that the network case at the end of the contingency analysis is
unchanged. These changes are reflected in the incremental saved case saved for that contingency.
post_ca_soln_eval - changes cannot be made from this function
Not all the functions in pfcontrol can be used in all of the "inner" functions. The pfcontrol functions
cannot be used in the "outer" functions.
18.4.2 ppsppe
The read function in the module ppsppe was designed for reading parameters into a pssuserpf
module.
18.4.3 others
In general other modules that are available through the interface to PSS®E that you are using can
also be used in pssuserpf. pssarrays will not be able to access the acc file being written in the
contingency analysis functions.
18-5
Using other PSS®E modules from pssuserpf Program Operation Manual
18-6
Chapter 19
Using the Remedial Action
Scheme API
The Python-based RAS API allows the user to define arbitrarily complex remedial action schemes
Chapter 19 - Using the Remedial Action Scheme API
(also known as system adjustments, operating procedures or mitigation procedures) that can be
simulated within the PSS®E ACCC activity. The API is based on the PCI (Powerflow Control Inter-
face) described in the previous section. In order to use the RAS API, a custom RAS definition
module and pssuserpf module have to be included in the working directory (or Python Path) as
shown below.
The contents of these files are described in the following sections.
19.1 Minimal Contents of the User-defined pssuserpf.py Module

for RAS Simulation
The following code shows the minimum content required in the pssuserpf.py file in order to simulate
RAS behavior using the PCI-based system. Note that additional code may be added to this file
based on other uses of the pssuserpf.py interface (such as custom control models or reports). Note
also, that the "import ras" line of code in the below file contents must in general import the actual
19-1
Using the Remedial Action Scheme API PSS®E 34.2
Contents of the User-defined ras.py File Program Operation Manual
RAS definition file. For example, if the RAS definitions were included in a module "myras.py", then
the import statement should read "import myras".
19.2 Contents of the User-defined ras.py File

Below are the contents of an example RAS definition file.
19-2
PSS®E 34.2 Using the Remedial Action Scheme API
Program Operation Manual Explanation of the Typical RAS Definition
19.3 Explanation of the Typical RAS Definition

The construction of an example RAS is described below, and consists of three major parts: the
condition definition, the action definition, and the RAS definition.
1. Define the Condition
a. The condition function does not have to be called "condition", but whatever name
you choose, you need to use the same name in the RAS definition function (see
item 8 below).
b. You cannot include arguments in the condition function definition (the parentheses
must be empty).
2. Define the Condition Description (optional)
a. This optional description string will be used by PSS®E in RAS reports to allow your
custom description to be including in the log and report messages.
b. You can use single quotes, but you must use triple quotes if the description spans
multiple lines (based on Python multi-line string rules)
3. Define True/False Conditional Statement(s)
a. This is where you put statements that result in True or False

b. You can make logical combinations of True/False expressions by assigning each
Boolean expression to a variable (as shown in this example).
4. Return the Result of the Condition Function
a. You must include a return statement as the last line of the condition function that
returns True (RAS triggered) or False (RAS not triggered). For compound expres-
sions, you can return a Boolean expression using a combinations of Boolean
variables using "or", "and" and parentheses to define the order of nested
operations.
5. Define the Action
a. The action function does not have to be called "action", but whatever name you
choose, you need to use the same name in the RAS definition function (see item 8
below).
b. You cannot have arguments in the action function definition (the parentheses must
be empty).
19-3
Python Operators Program Operation Manual
6. Define the Action Description (optional)
a. This optional description string will be used by PSS®E in RAS reports

b. You can use single quotes, but you must use triple quotes if the description spans
multiple lines (based on Python multi-line string rules)
7. Define Action Statements
a. This is where you put statements that perform adjustments to the system as
desired.
b. You can use functions from PTI-provided pssras, psspy, or pfcontrol modules. Note
that you can only make adjustments with the functions in pssras or pfcontrol mod-
ules, as data-changing functions in psspy will have unexpected results.
8. Define the RAS
a. Finally, the RAS definition is created by calling the define_ras function, passing in
the desired name of the RAS, along with the names of the condition and action
functions defined in the previous steps.
19.4 Python Operators

For your reference, the following table contains a subset of the math, assignment, comparison and
logical operators in the Python language. These will be useful is defining conditional expressions
based on systems conditions determined in the Condition Function.
Math + ‐ * / % **
Assignment = += ‐= *= /= %= **=
Comparison == != >= <= > <
Logical and or not
19.5 Available RAS Getter Functions

The below functions are useful in assessing system conditions that trigger RAS actions. Note that
functions that return float values must be used in combination with comparison operators in order
to provide boolean (True/False) results needed to trigger a RAS action.
Function Argument(s) Return Value(s)
bus_get_typecode(ibus) ibus: Bus Number (int) Bus Typecode (int)
bus_is_disconnected(ibus) ibus: Bus Number (int) True/False
ibus: Bus Number (int)

branch_status(ibus, jbus, ckt) jbus: To Bus Number (int) True/False
ckt: Circuit ID (int or string)
19-4
Program Operation Manual Available RAS Getter Functions

branch_is_open(ibus, jbus, ckt) jbus: To Bus Number (int) True/False

branch_is_closed(ibus, jbus, ckt) jbus: To Bus Number (int) True/False
subnum: Sub Number (int)

inode: From Node Num (int)
breaker_status(subnum, inode, jnode, ckt) True/False
jnode: To Node Num (int)
ckt: SWD ID (int or string)

fixed_shunt_status(ibus, shntid) True/False
shntid: Shunt ID (int or string)

fixed_shunt_mvar(ibus, shntid) MVAR (float)
shntid: Shunt ID (int or string)
sw_shunt_status(ibus) ibus: Bus Number (int) True/False
sw_shunt_qinit(ibus) ibus: Bus Number (int) MVAR (float)
sw_shunt_vmax(ibus) ibus: Bus Number (int) Vpu (float)
sw_shunt_vmin(ibus) ibus: Bus Number (int) Vpu (float)

load_status(ibus, loadid) True/False
loadid: Load ID (int or string)

branch_mw(ibus, jbus, ckt) jbus: To Bus Number (int) MW (float)
19-5
Available RAS Getter Functions Program Operation Manual

branch_mvar(ibus, jbus, ckt) jbus: To Bus Number (int) MVAR (float)

branch_amps(ibus, jbus, ckt) jbus: To Bus Number (int) Amps (pu) (float)

branch_mva(ibus, jbus, ckt) jbus: To Bus Number (int) MVA (float)
jbus: To Bus Number (int)
branch_loading(ibus, jbus, ckt, rating=1,
ckt: Circuit ID (int or string) Loading (pu) (float)
amps=False)
rating: Rating to use (1-12)
amps: Return equiv. amp loading
bus_voltage(ibus) ibus: Bus Number (int) Vpu (float)
bus_kv(ibus) ibus: Bus Number (int) kV (actual) (float)
bus_kvbase(ibus) ibus: Bus Number (int) kV (base) (float)

bus_angle(ibus, degrees=False) angle (float)
degrees: True/False
bus_vrange_normal(ibus) ibus: Bus Number (int) (v1, v2) (float, float)
bus_vrange_emergency(ibus) ibus: Bus Number (int) (v1, v2) (float, float)
area: Area Number (int)

area_load_mw(area,
bus_assignment: Use Bus Assig- MW (float)
bus_assignment=True)
ment (True/False)
area: Area Number (int)
area_load_mvar(area,
bus_assignment: Use Bus Assig- MVAR (float)
bus_assignment=True)
ment (True/False)
area_gen_mw(area) area: Area Number (int) Total MW (float)
area_gen_mvar(area) area: Area Number (int) Total MVAR (float)
area_loss_mw(area) area: Area Number (int) Total MW (float)
19-6
Program Operation Manual Available RAS Getter Functions
area_loss_mvar(area) area: Area Number (int) Total MVAR (float)
area_interchange_mw(area) area: Area Number (int) Net MW (float)
area_interchange_mvar(area) area: Area Number (int) Net MVAR (float)
name: DC Line Name (string)

dc_line_current(name, ibus) Amps (pu) (float)
dc_line_setpoint(name, ibus) Setpoint (float)
dc_converter_mw(name, ibus) MW (float)
dc_converter_mvar(name, ibus) MVAR (float)
dc_converter_mva(name, ibus) MVA (float)
dc_converter_amps(name, ibus) Amps (pu) (float)
dc_converter_kv(name, ibus) kV (float)
dc_converter_angled(name, ibus) Angle (degree) (float)
dc_line_control_mode(name) name: DC Line Name (string) Control Mode (int)
dc_nterm_firing_angle_status(name) name: DC Line Name (string) True/False
dc_nterm_tap_status(name) name: DC Line Name (string) True/False
plant_mw(ibus) ibus: Bus Number (int) Total MW (float)
plant_mvar(ibus) ibus: Bus Number (int) Total MVAR (float)
plant_mva(ibus) ibus: Bus Number (int) Total MVA (float)

machine_pgen(ibus, machid) MW (float)
machid: Mach ID (int or string)
machine_pmax(ibus, machid) MW (float)
machine_pmin(ibus, machid) MW (float)
machine_qgen(ibus, machid) MVAR (float)
19-7
Available Setter Functions Program Operation Manual

machine_qmax(ibus, machid) MVAR (float)
machine_qmin(ibus, machid) MVAR (float)
machine_mva(ibus, machid) MVA (float)
machine_mbase(ibus, machid) MW (base) (float)
machine_status(ibus, machid) True/False
load_mw(ibus, loadid, actual=False) MW (float)
load_mvar(ibus, loadid, actual=False) MVAR (float)
load_mva(ibus, loadid, actual=False) MVA (float)
19.6 Available Setter Functions

These functions can be used to define system adjustments required in a RAS action definition.
Action Function Argument(s)

trip_unit(ibus, machid)

open_branch(ibus, jbus, ckt) jbus: To Bus Number (int)
close_branch(ibus, jbus, ckt) jbus: To Bus Number (int)
disconnect_bus(ibus) ibus: Bus Number (int)

jbus: To Bus Number (int)
set_branch_status(ibus, jbus, ckt, status)
status: True/False
19-8
Program Operation Manual Available Setter Functions

subnum: Sub Number (int)
inode: From Node Num (int)
set_breaker_status(subnum, inode, jnode, ckt,
jnode: To Node Num (int)
status)
ckt: SWD ID (int or string)
status: True/False

set_fixed_shunt_status(ibus, shntid, status) shntid: Shunt ID (int or string)
status: True/False

set_fixed_shunt_mvar(ibus, shntid, mvar) shntid: Shunt ID (int or string)
mvar: Nominal MVAR

set_sw_shunt_status(ibus, status)
status: True/False

set_sw_shunt_qinit(ibus, qinit)
qinit: Nominal Q Init MVAR

set_sw_shunt_vmax(ibus, vmax)
vmax: Vpu Max

set_sw_shunt_vmin(ibus, vmin)
vmin: Vpu Min

set_load_status(ibus, loadid, status) loadid: Load ID (int or string)
status: True/False

set_machine_status(ibus, machid, status) machid: Mach ID (int or string)
status: True/False
19-9
Settings and other Utility Functions Program Operation Manual

set_machine_mw(ibus, machid, mw) machid: Mach ID (int or string)
mw: Machine MW (pgen)

set_machine_qmin(ibus, machid, mvar) machid: Mach ID (int or string)
mvar: Machine MVAR Min (Qmin)

set_machine_qmax(ibus, machid, mvar) machid: Mach ID (int or string)
mvar: Machine MVAR Max (Qmax)

set_scheduled_voltage(ibus, machid, vpu) machid: Mach ID (int or string)
vpu: Vpu Setpoint

set_vcsdc_mw(name, cnvbus, mw) cnvbus: Converter Bus (int)
mw: MW to set

set_vcsdc_qmin(name, cnvbus, mvar) cnvbus: Converter Bus (int)
mvar: MVAR Min to Set

set_vcsdc_qmax(name, cnvbus, mvar) cnvbus: Converter Bus (int)
mvar: MVAR Max to Set
19.7 Settings and other Utility Functions

These functions provide access to settings and other utility operations.
Function Description
set_max_ras_iterations(n) Set the max number of RAS iterations (system adjustment
iterations)
19-10
Program Operation Manual Settings and other Utility Functions
enable_ras_PSSE_report(enable=Tru Enable verbose RAS reporting.
e, to_progress=False) enabled: If True, verbose reporting will be sent to the PSS®E
report stream during the set up and operation of the RAS
system in contingency analysis. If False, no reporting will be
provided.
to_progress: If True, reporting will be sent to the defined
progress output device. If False, reporting will be sent to
the defined report output device.
enable_ras_csv_report(file- Enable a csv output report for programmatic post-processing.

path=None, ena-ble=True) filepath: csv filepath to which the report messages will be sent.
enabled: If True, verbose reporting will be sent to the PSS®E
provided.
enable_ras_logging(file- Enable verbose RAS reporting.

path="raslog.txt", enable=True, over- filepath: Log filepath to which the log messages will be sent.
write=True) enabled: If True, verbose reporting will be sent to the PSS®E
provided.
overwrite: If True, and existing file will be overwritten with each
run of the contingency engine.
report(text, newline=True, time- Send a message to the PSS®E report stream. Has no effect if
REPORT flag is False. To enable reporting, call the function
stamp=False)
enable_ras_reporting() in your RAS definition script.
text: The text to send to the report.
newline: (optional, default=True) add a newline at the end of
the message.
timestamp: (optional, default=False) add a timestamp at the
beginning of the message.
log(text, newline=True, time- Send a message to the log file. Has no effect if LOG flag is
False. To enable logging and to define the log file path, call the
stamp=True)
function enable_ras_logging(path) in your RAS definition
script.
text: The text to send to the log.
newline: (optional, default=True) add a newline at the end of
the message.
timestamp: (optional, default=False) add a timestamp at the
beginning of the message.
csv_report(contingency, iteration, Write a row to the CSV report.

ras_name, notes="") contingency: Label of current contingency
iteration: System adjustment iteration limit
ras_name: Name of triggered RAS scheme
report_and_log(text, newline=True,
Automatically sends a message to report and log streams (see
report_timestamp=False, report and log functions for argument detail)
log_timestamp=True)
19-11
Settings and other Utility Functions Program Operation Manual
clear_log() Clears the log file (makes the file empty).
ras_summaries(*ras_names) Provides a string containing summaries of RAS definitions.

ras_names: (optional) arg list of RAS definitions to include in
the summary. If empty, all define schemes will be included.
enable_ras(name) Enable (arm) a RAS.

name: RAS name (case-sensitive)
disable_ras(name) Disable (disarm) a RAS.

set_ras_enabled(name, enabled)
Enable (arm) or disable (disarm) a RAS.
enabled: True (arm) or False (disarm)
clear_all_ras() Un-define all defined RAS schemes.
define_ras(name, condition, action, Defines a RAS.

enabled=True, report=None, name: The user-defined name of the scheme.
condition: The name of a defined function that will be called
description=None) each ras iteration to determine if this ras is triggered. This func-
tion should return True for triggered or False otherwise.
action: The name of the function that will be called if this ras is
triggered.
enabled: (optional) True for enabled (armed) or False for
disabled (disarmed).
report: (optional) a function that returns a string for custom
reporting.
description: (optional) detailed description of the RAS.
returns: The Scheme object created.
19-12
Chapter 20
Miscellaneous Activity
Descriptions
This chapter contains operational descriptions of those PSS®E activities related to file and output
Chapter 20 - Miscellaneous Activity Descriptions
device management and other miscellaneous functions used in performing engineering studies in
PSS®E. Each section of this chapter documents a single PSS®E activity. Interface references are
provided, with links to the PSS®E GUI Users Guide and the PSS®E Command Line Interface (CLI)
Users Guide, where appropriate.
20.1 Terminating PSS®E

Activity STOP
Run Activity STOP - GUI
Run Line Mode Activity STOP - CLI

ACTIVITY?
>>STOP

None
The PSS®E termination activity STOP is the normal exit from PSS®E. When selected, activity
STOP closes any Response Files which are active (see Sections 2.3.4 and 16.12) and any output
files that are open, such as redirected virtual output devices (see Section 4.4 Virtual Output
Devices). It then returns the user to operating system level.
Activity STOP does not affect the status of any command files or session logging files which might
have been opened outside of PSS®E.
If the working case represents a system condition that may be needed in the future, the user should
ensure that it is preserved in a Saved Case File prior to selecting activity STOP. A similar argument
applies to preserving dynamics working memory in a Snapshot File.
20-1
Miscellaneous Activity Descriptions PSS®E 34.2
Applying a User-Written Activity Program Operation Manual
®
Section 2.2, Terminating PSS®E
20.2 Applying a User-Written Activity

Activity USER
Run Line Mode Activity USER - CLI

ACTIVITY?
>>USER

None
The PSS®E interface provides for the incorporation of a user-written activity into PSS®E.
Activity USER is not sensitive to any interrupt control code options.
Additional Resources for PSS®E, Section 2.3.1, Dynamics User Model DLLs
Section 2.4, Running a User-Written Activity
20.3 Displaying Help Information

Activity HELP
Run Activity HELP - GUI
Run Line Mode Activity HELP - CLI

ACTIVITY?
>>HELP

None
The line mode activity HELP prints brief summary documentation at the Progress device.
For Future PSS®E Release: The GUI Help function is entirely different. It provides information on
using the GUI dialogs.
20-2
PSS®E 34.2 Miscellaneous Activity Descriptions
Program Operation Manual Selecting Prompt Output Destination
20.4 Selecting Prompt Output Destination

Activity ODEV
Direct Prompt Output - GUI

I/O Control>Direct Prompt output…
[Prompt Output Destination Selector]
Run Line Mode Activity ODEV - CLI
ACTIVITY?
>>ODEV

None
Selecting the prompt output destination controls where output identified in PSS®E as prompt, or
dialog, information is sent. The PSS®E GUI default behavior (prompt window) is to display accu-
mulated prompts in the general input window that is generated for terminal input requests. Prompts
are messages that request input from the PSS®E user. The GUI itself does not generate any such
output, but they can be created in automation files.
Prompts generated by using the command line in the GUI are an exception to the above default
behavior. Those prompts are forced to the Progress device and appear immediately. When using
a console application, such as PSSECMD, redirecting the prompts will affect all the conversational
dialog. Care should be taken in this case as the user may not be able the see the questions being
asked.
The line mode activity ODEV instructs the user to select the device to be used for these tabulations
and presents a menu of choices. Specifying either zero or one to the device selection request
assigns report output to the user’s terminal, or the prompt window in the PSS®E GUI. ODEV will
redirect alert output as well as prompt output. Using ODEV is effectively the same as redirecting
both prompt and alert output.
The destination specified for prompts may be the same file or printer that is used for any or all the
other virtual output devices. Output may be directed to the Progress or Report device, in which
case prompt output will be handled as part of that output.
When a printer is specified for the prompt device, the output is normally not printed until either
prompt output is reassigned elsewhere or PSS ® E is terminated. The PSS ® E GUI and the
prompt_output API routine provide a print immediate option that will send the output to the printer
at the end of every activity.
20-3
Selecting Alert Output Destination Program Operation Manual
®
PSS E GUI Users Guide, Section 24.1.3, Alerts and Prompts Destination
Section 20.1.4, Specifying Alert and Prompt Destination
See also: Section 4.4, Virtual Output Devices
20.5 Selecting Alert Output Destination

Activity ODEV
Direct Alert Output - GUI

I/O Control>Direct Alert output…
[Alert Output Destination Selector]
Run Line Mode Activity ODEV - CLI
ACTIVITY?
>>ODEV

None
Selecting the alert output destination controls where output identified in PSS®E as alert information
is sent. The PSS®E GUI default behavior (alert box) is to display alert information in a MessageBox,
and a copy of that message in both the Progress window and the Alerts/Warnings window. Alerts
are messages that inform the PSS®E user of an error in program execution. This should be under-
stood to mean situations where the program was unable to perform the assigned task, and
specifically not situations where results might or might not meet some standard, such as a solution
failing to converge.
Alerts generated by using the command line in the GUI and during Automation File execution are
exceptions to the above default behavior. Those alerts are forced to the Progress device and
appear immediately.
The line mode activity ODEV will redirect alert output as well as prompt output. Using ODEV is
effectively the same as redirecting both prompt and alert output.
The destination specified for alerts may be the same file or printer that is used for any or all the other
virtual output devices. Output may be directed to the Progress or Report device, in which case
alert output will be handled as part of that output.
When a printer is specified for the alert device, the output is normally not printed until either alert
output is reassigned elsewhere or PSS®E is terminated. The PSS®E GUI and the alert_output API
routine provide a print immediate option that will send the output to the printer at the end of every
activity.
20-4
Program Operation Manual Selecting Progress Output Destination
®
PSS E GUI Users Guide, Section 24.1.3, Alerts and Prompts Destination
Section 20.1.4, Specifying Alert and Prompt Destination
20.6 Selecting Progress Output Destination

Activity PDEV
Direct Progress Output - GUI

I/O Control>Direct Progress output (PDEV)…
[Progress Output Destination Selector]
Run Line Mode Activity PDEV - CLI
ACTIVITY?
>>PDEV

None
Selecting the progress output destination controls where output identified in PSS®E as progress
information is sent. The PSS®E GUI default behavior (Progress window) is to display progress
information in the Progress tab of the output bar. Progress output are messages that inform the
PSS®E user of intermediate results, confirmation of instructions, supplemental information, and
usage history. These include such tabulations as the network solution convergence monitors, the
machine initial conditions summary of activities STRT, ESTR, and GSTR, and the output channel
tabulations of activities RUN, ERUN, and GRUN.
The line mode activity PDEV instructs the user to select the device to be used for these tabulations
assigns progress output to the user’s terminal, or the Progress window in the PSS®E GUI.
The destination specified for progress may be the same file or printer that is used for any or all the
other virtual output devices. Output may be directed to the Report device, in which case progress
output will be handled as part of that output.
When a printer is specified for the progress device, the output is normally not printed until either
progress output is reassigned elsewhere or PSS®E is terminated. The PSS®E GUI and the
progress_output API routine provide a print immediate option that will send the output to the printer
at the end of every activity.
20-5
Selecting Report Output Destination Program Operation Manual
®
PSS E GUI Users Guide, Section 24.1.2, Progress Destination
Section 20.1.3, Specifying Progress Report Destination
20.7 Selecting Report Output Destination

Activity OPEN
Direct Report Output - GUI

I/O Control>Direct Report output (OPEN)…
[Report Output Destination Selector]
Run Line Mode Activity OPEN - CLI
ACTIVITY?
>>OPEN

None
Selecting the report output destination controls where output identified in PSS®E as report informa-
tion is sent. The PSS®E GUI default behavior (Report window) is to display report information in
the Report tab (or tabs) of the output bar. Report output are the results of calculations or analysis
that are specifically requested by the PSS®E user.
The line mode activity OPEN instructs the user to select the device to be used for these tabulations
assigns report output to the user’s terminal, or the Report window in the PSS®E GUI.
The destination specified for reports may be the same file or printer that is used for any or all the
other virtual output devices. Output may be directed to the progress device, in which case report
output will be handled as part of that output.
When a printer is specified for the report device, the output is normally not printed until either report
output is reassigned elsewhere or PSS®E is terminated. The PSS®E GUI and the report_output
API routine provide a print immediate option that will send the output to the printer at the end of
every activity.
Selecting report output destination has a secondary effect in the line mode. Until the first time that
report output is explicitly directed by the user, line mode activities that produce report output
produce a menu requesting where the report output for that one activity should be directed. Once
report output has been explicitly designated by the user (via the GUI, the line mode OPEN activity,
or the API routine report_output) this mode of operation is terminated. It can be restored by using
the line mode activity CLOS (see Section 20.8 Closing Report Destination).
20-6
Program Operation Manual Closing Report Destination
®
PSS E GUI Users Guide, Section 24.1.1, Global Report Destination
Section 20.1.1, Specifying Global Report Destination
20.8 Closing Report Destination

Activity CLOS
Run Line Mode Activity CLOS - CLI

ACTIVITY?
>>CLOS

None
The report output device closing activity CLOS terminates output to the previously OPENed selec-
tion (see Section 20.7 Selecting Report Output Destination), and returns to the operating mode in
which each reporting activity initiated using the line mode (see Section 4.2.2, Command Line Inter-
face) requests the user to select the destination for its report. As a result, the report output
destination is set back to the default, or standard, behavior.
®
Section 20.1.2, Closing Report Destination
20.9 Setting the Path for Use with & Filenames

Activity PATH
Run Activity PATH - GUI

I/O Control>Set path for use with "&" filenames (PATH)…
[Define PATH by selecting any file in the desired directory]
Run Line Mode Activity PATH - CLI
ACTIVITY?
>>PATH
ENTER PATHNAME PREFIX FOR USE WITH '&' FILE NAMES
>>
None
20-7
Changing PSS®E Program Settings Program Operation Manual
The directory path specification activity PATH allows the user to specify a directory name. Then,
whenever a simple filename preceded by an ampersand (e.g., &myfile) is specified to a PSS®E file
accessing activity, the file is opened in the directory specified to activity PATH rather than in the
user’s current directory. Refer to Section 2.4.2 Specifying Filenames.
®
PSS E GUI Users Guide, Section 24.2, Setting the Path for Use with & Filenames
Section 20.1.5, Setting the Path for Use with & Filenames
20.10 Changing PSS®E Program Settings

Activity OPTN
Run Activity OPTN - GUI

Misc>Change program settings (OPTN) …
[Program Settings]
Run Line Mode Activity OPTN - CLI
ACTIVITY?
>>OPTN
PRESENT OPTION SETTINGS ARE:

None
The PSS®E option setting activity OPTN enables the user to override most of the default option
settings as established when PSS®E is installed on the system (refer to Section 3.3.3 Program
Run-Time Option Settings). It also provides for saving the current option settings in a PSS®E
Options File for access on subsequent entries into PSS®E.
When saved, activity OPTN preserves the current settings of most PSS®E options in a PSS®E
Options File (see Sections 20.10.1, 2.3.7, and 3.3.3).
When invoked in line mode, activity OPTN displays the current settings of all options which may be
modified. The user may re-specify any option. Following such a change, the option menu is again
displayed with any new setting shown.
PSS®E options are listed in Table 3-2 Saved Case Specific PSS®E Program Option Settings, 3-3,
and Table 3-4 Installation Dependent Option Settings.

Whenever PSS®E is started up, the default option settings as established when PSS®E is installed
on the system are in effect. These are overridden by the settings contained in a PSS®E Options
File if one is found in the user’s current or home directory or in the PSS®E master directory PSSLIB;
PSS®E follows the directory search sequence described in Section 2.1 Directories and Files Over-
view when looking for the PSS®E Options File.
20-8
Program Operation Manual Returning Activity Selection to Dynamic Simulation
Most PSS®E option settings are stored with the working case when it is saved with activity SAVE.
When a power flow case is retrieved with activity CASE, the option settings contained in it override
those then set in working memory. Any time activity CASE changes an option setting, an appro-
priate message is printed.
Number of contingency processor defines the number of processors in using for AC contingency
analysis solutions. The option is computer system dependent, and its maximum is the number of
processors of a computer up to 24 (1 by default).
®
PSS E GUI Users Guide, Introduction, Changing Program Settings
Section 2.1, Changing Program Settings
20.11 Returning Activity Selection to Dynamic Simulation

Activity RTRN
Run Line Mode Activity RTRN - CLI

ACTIVITY?
>>RTRN

None
Note: Starting with PSS®E-31, mode switching is not apparent to the user and need not be done
explicitly. It is retained only for backwards compatibility.
The return to dynamics activity RTRN allows the user to execute any dynamics activity after having
been operating in power flow mode.
Activity RTRN coordinates dynamics model data and network data by performing the following
steps:
1. It coordinates the power flow machine electrical power arrays and the dynamic simulation
machine electrical power arrays.
2. It sets up a translation array (NUMTRM) indexed by internal machine sequence number and
pointing to the associated network bus. Out-of-service machines have their corresponding
NUMTRM entries set to a negative number.
3. It sets up a translation array (NUMLOD) indexed by internal load sequence number and
pointing to the associated network bus. Out-of-service loads have their corresponding
NUMLOD entries set to a negative number.
4. It sets up a translation array (RINCNX) indexed by internal double entry branch index and
pointing to the associated branch relay model connection table entry.
20-9
Editing the Case Heading or Long Title Program Operation Manual
5. It updates internal pointer arrays used in associating dynamic simulation models with the
machine and load indexing contained in the power flow working case.
6. It updates output channel addresses to reflect any changes in the internal sequence
numbering of buses, machines, and loads in the working case.
7. It builds translation arrays DC2CNX, DCMCNX, VSCCNX, and FCTCNX for two-terminal dc
lines, multi-terminal dc lines, VSC dc lines, and FACTS devices, respectively. These arrays
are indexed by the internal device index in the power flow working case and point to the
dynamic model associated with the corresponding two-terminal dc line, multi-terminal dc
line, VSC dc line, or FACTS device, as appropriate.
8. It sets up a translation array (AUXLOC) indexed by internal auxiliary signal model number
and pointing to the internal device index of the two-terminal dc line, multi-terminal dc line,
VSC dc line, or FACTS device associated with the auxiliary signal model.
9. It sets up a translation array (SWSCNX) indexed by internal switched shunt sequence

number and pointing to the dynamic model associated with the switched shunt.
Section 20.2.1, Returning Analytical Output to Dynamic Simulation
20.12 Editing the Case Heading or Long Title

Activity EDTR
Run Line Mode Activity EDTR - CLI

ACTIVITY?
>>EDTR
EDITOR OPTIONS ARE:

None
The title editing activity EDTR allows the user to perform editing operations on the two line case
heading and on the sixteen line long title. It is accessible only as a command line activity. In the GUI
the Case Titles dialog (activity CHTI) provides convenient editing ability. See also activity CHNG.
When either the two line case heading or the sixteen line long title is selected, the user specifies a
valid line number and appropriate editing commands.
The general form of each editing command is XnA where:
X Is a single letter editing command as described below.

Is a number in the range of 1 through 32000 (default is 1) which specifies the number of times that
the command is to be executed. Alternatively, n may be specified as an asterisk (  ), indicating that
n
the given command is to be executed as many times (perhaps zero times) as possible for the
displayed line.
20-10
Program Operation Manual Editing the Case Heading or Long Title
A Are the argument(s), if any, required for a given command.
As an example, consider the command C2/WX/YZ/, where C specifies the change command, 2
specifies that the change is to be performed twice, and /WX/YZ/ is the argument to the change
command. This command searches the displayed title line for the first two occurrences of WX and
replaces them with YZ.
The / characters used in this example are delimiters and are used to separate the two strings
required by the change command. Valid delimiters are: . / $ % ! : ' " and &. Any one of these delim-
iters may be used as long as it does not occur in either of the specified strings. (The starting, middle,
and ending delimiter characters must, of course, all be the same.)
Several edit commands can be strung together in a single editing command input line. Prior to
executing each editing command input line, an internal edit pointer is initialized to point to column
one of the line being edited. As each edit command of the command input line is executed, this
pointer moves toward the right end of line being edited. In other words, the editing proceeds from
left to right, with each new editing command in the command input line starting where the previous
one ended. For example, the command C/AB/CD/C/WX/TY/ would cause the first occurrence of AB
to be replaced with CD and the first occurrence of WX after the original AB to be replaced with TY.
Whenever an error condition is encountered in performing the operations specified in an editing

command input line, an appropriate error message is printed and the line is unchanged.
The editing commands are:
The change (or substitute) command. This command searches for one or more occurrences of a
given string and substitutes a second string for the original string. The format of this command is
one of the following:
Cn/string1/string2/
C or S Sn/string1/string2/
where n and the / delimiters have been described above. Here, string1 is the original string and
string2 is the string to be substituted. Note that string2 can be the null string ( // ), so that the
change command can be used to delete one or more occurrences of a given string. Normally, n is
not specified and only the first occurrence of string1 is changed.
The find command. This command moves the edit pointer to the position in the line being edited
where a specific string is located. The format of this command is:
Fn/string/
F
where n and the / delimiters have been described above. This command moves the edit pointer to
the first character of the nth occurrence (or last occurrence if an asterisk was specified) of string.
Normally, n is not specified, so the find command moves the edit pointer to the first character of the
first occurrence of string.
The move command. This command moves the edit pointer a specified number of character posi-
tions to the right. The format of this command is:
M Mn
here n indicates the number of columns to move the edit pointer (relative to its current location). An
asterisk is not allowed for n in this command.
20-11
Editing the Case Heading or Long Title Program Operation Manual
The delete command. Starting at the current position, this command deletes a specified number of
characters. The format of this command is:
D
Dn
where n indicates the number of characters to be deleted.
The insert command. This command inserts a given string of characters into the title line, starting
just before the current position. The format of this command is:
I/string/
I
where the / delimiters have been described above and string is the string of characters to be
inserted. The edit pointer is positioned to the first location following the inserted string. Characters
that are pushed past the end of the title line by the insert command are lost, and no error message
is generated.
The overlay command. Starting at the current location, this command overlays (replaces) charac-
ters in the title line. The format of this command is one of the following:
O/string/ or R/string/
O or R
where the / delimiters have been described above and string is the string of characters that are to
overlay (replace) characters in the displayed title line. The edit pointer is positioned to the first loca-
tion following string.
The append command. This command appends a specified string to the title line, starting immedi-
ately after the last non-blank character in the line. The format of this command is:
A A/string/
where the / delimiters have been described above and string is the string of characters that is to be
appended. The edit pointer is positioned to the first location following the appended string.
Following are several examples of using the editing commands.
Example 1: Simple C(hange) commands.
Assume that a title line originally contains ABCADEF. The edit command C/B/XY/ changes
it to AXYCADEF, while the command C2/A/MN/ results in a line of MNBCMNDEF. Note that
the second change command could have been written as C*:A:MN:, where an asterisk is
used instead of an explicit count and a different delimiter is being used.
Two (or more) change commands can be specified as one EDTR command. For example,
assume that the title line originally contains ABCABCABC and that the edit command
C/B/X/C/A/Q/ is given. The resulting line is AXCQBCABC. Note that the first A was not
changed, because the second C(hange) command started where the first C(hange)
command left off (and not at the beginning of the line).
Example 2: The F(ind), I(nsert), and D(elete) commands.
Assume that a title line originally contains ABCDEF. The edit command F/C/I/NEW/ results
in the title line containing ABNEWCDEF. Note that the string NEW is inserted directly
before the character that was located with the F(ind) command. Starting with the same orig-
inal line, the edit command F/C/D2I/NEW/ results in the title line containing ABNEWEF,
where the D(elete) command has removed the original CD characters.
Example 3: The O(verlay), A(ppend), and M(ove) commands.
Assume once more that the line originally contains ABCDEF. The edit command
F/C/O/xxx/A/stuff/ results in a line containing ABxxxFstuff. Starting with the original line, the
20-12
Program Operation Manual Listing Directory Contents
edit command M3O/bigstuff/ results in the title line ABCbigstuff. Note that this command
would have failed if there were not enough room in the title line to hold the additional char-
acters.
®
Section 3.10.3, Editing the Two-Line Case Title or the Long Title
20.13 Listing Directory Contents

Activity CATA
Run Line Mode Activity CATA - CLI

ACTIVITY?
>>CATA

None
The directory listing activity CATA tabulates an alphabetical listing of the names of files contained
in the current directory.
The names of all files in the current directory which appropriately contain a specified character
string as a part of their name are listed, including imbedded asterisks (  ) which are treated as wild
characters matching zero, one or more characters.
®
Section 6.2.6, Directory Contents
20.14 Listing Saved Case or Snapshot Files

Activity SHOW
Run Activity SHOW - GUI

File>File information (SIZE/SHOW/BUSN)…
[File Information]
OPTION: List Save case and Snapshot files
Run Line Mode Activity SHOW - CLI
ACTIVITY?
>>SHOW
>>
20-13
Displaying Timing Statistics Program Operation Manual

None
The Saved Case and Snapshot File summary activity SHOW lists the case headings of Saved Case
and Snapshot Files contained in the current directory. This list is printed to the Progress device
(see Section 4.4 Virtual Output Devices). Separate lists of Saved Case or Snapshot Files may be
specified.
Each file listed is followed by the report of activity SIZE if the file is a Saved Case File, or a tabulation
of the number of dynamics data array elements stored in the file if it is a Snapshot File. In addition,
on some host computers activity SHOW allows the specification of pathnames as well as simple
filenames. The actual implementation of activity SHOW differs among the various host computers
of PSS®E.
®
PSS E GUI Users Guide, Section 6.2, Listing Saved Case Filenames
Section 20.7, Listing Snapshot Filenames
Section 6.2.2, Saved Case or Snapshot Filenames
20.15 Displaying Timing Statistics

Activity TIME
Run Activity TIME - GUI

Misc>Reset timing statistics to zero (TIME,INIT)
Misc>Display timing statistics (TIME)
Run Line Mode Activity TIME - CLI
ACTIVITY?
>>TIME, INIT
DAY, MMM DD YYYY H:M - TIMER INITIALIZED

None
The timing statistics activity TIME allows the user to obtain execution time statistics during a PSS®E
work session.
On subsequent executions of activity TIME it prints a summary of elapsed time, in seconds, since
the previous execution of activity TIME, and cumulative times from the point at which the timers
were last initialized. It also prints two additional system dependent timing statistics, at least one of
which indicates CPU utilization. This tabulation, which is printed to the Progress device, is of the
form:
20-14
Program Operation Manual Inserting Comments into the Progress Output
FRI, MAY 23 2003 15:21 ELAPSE heading2 heading3

SINCE LAST "TIME" XX.XXX XX.XXX XX.XXX
CUMULATIVE XX.XXX XX.XXX XX.XXX
®
PSS E GUI Users Guide, Overview, Displaying and Resetting Timing Statistics
Section 6.2.5, Timing Statistics
20.16 Inserting Comments into the Progress Output

Activity TEXT
Run Activity TEXT - GUI

Misc>Insert text into the Progress stream (TEXT)
[Insert Text into the Progress Stream]
Run Line Mode Activity TEXT - CLI
ACTIVITY?
>>TEXT,<message>

None
The null activity TEXT doesn’t manipulate power flow data. However, it does provide a mechanism
by which the user may insert descriptive comments in a Response File at any point at which the
next activity to be executed is specified. In addition, it enables the user to insert comments in the
Progress output of the PSS®E interface and into a recording file, if one is being used.
®
PSS E GUI Users Guide, Section 23.5, Inserting Comments into the Progress Output
Section 19.6, Inserting Comments into the Progress Output
20-15
Inserting Comments into the Progress Output Program Operation Manual
20-16
Chapter 21
Dynamic Simulation Setup
and Procedures
The user of PSS®E is able to run dynamic simulations when, after opening PSS®E, the user selects
Chapter 21 - Dynamic Simulation Setup and Procedures
the dynamics tab. This will give user access to various dynamic simulation activities. The individual
dynamic simulation activities are described in detail in Chapter 15 of this manual. The purpose of
this section is to describe the sequencing of these activities in constructing a valid system model,
and the use of this model in simulation calculations.
21.1 Simulation Overview

The objective in performing a dynamic simulation of a physical system is to determine the response
of the system to prescribed stimuli. The process of dynamic simulation is quite straightforward
conceptually.
At an instant in time T, it is known "where you are". From "where you are" and the differential equa-
tions describing the behavior of the system, it can be determined "where you’re going". Then "go
there", advance time to T+t (where t is the time step or integration step), and run it again.
Stated in slightly more formal terms, the behavior of a system is described by a set of differential
equations. At every time step of the simulation, the time derivative of each state variable in the
system is calculated, with the constant and variable parameters, which describe the condition of the
system at that time instant in detail, as initial conditions. From the present value of each state vari-
able and its rate of change (i.e., its time derivative), the state variable values at the next time step
are determined. Simulation time is advanced and the process is repeated.
21.1.1 Program Structure

The user of the dynamic simulation section of PSS ®E requires a working knowledge of the
dynamics modeling structure. The principal steps of dynamic simulation as applied to electric power
systems are shown in Figure 21-1. The dynamic simulation procedure outlined above is compli-
cated by the presence of the electrical network which is described by a large set of simultaneous
algebraic equations.
21-1
Dynamic Simulation Setup and Procedures PSS®E 34.2
Simulation Overview Program Operation Manual
Data Assimilation
Initialization
Network Solution
Time Derivative Calculation
Optionally Apply
Disturbances
Output
Numerical Integration
Advance Time
Figure 21-1. Dynamic Simulation Basic Logic Flow
21-2
PSS®E 34.2 Dynamic Simulation Setup and Procedures
Program Operation Manual Simulation Overview
The activities which initialize a dynamic simulation (activity STRT) and calculate the instantaneous
state of the system at each time step (activity RUN) contain the basic elements of a general purpose
dynamic simulation calculation (e.g., numerical integration, time stepping, output). The following
calculation phases are required to extend this dynamic simulation control structure to that required
for the simulation of electric power systems:
1. The solution of the electric network given the machine internal flux linkages and the load
boundary conditions.
2. The calculation of the time derivative of each state variable used in modeling equipment,
given the present values of all state variables and of all generator stator currents. This phase
includes calculating the values of all algebraic variables needed in the course of obtaining
numerical values of the state variable time derivatives.
3. The modeling of equipment in which there is an algebraic relationship between the voltage
at a bus and the current drawn by, or key variable n by, the device. These include such
devices as induction motors, relays, meters and certain loads.
The requirement given in (1) above is handled by the subroutine SITER which is supplied as a part
of PSS®E. The equipment modeling requirements of (2) and (3) above are satisfied through the use
of specialized equipment model subroutines, each of which contains the coded equations for
modeling one specific type of equipment. The PSS®E Model Library contains a large number of
such models. In addition, PSS®E is structured such that users may develop and use their own
model subroutines whenever there is no standard library model which accurately models a given
item of equipment (see Chapter 23).
After equipment models for the system under study are selected, the user must supply the intelli-
gence connecting these models to the machines, buses, dc lines, and other equipment in the
electric network. This information is imbedded within ten subroutines:
TBLCNC Is supplied as a part of PSS®E and is responsible for the requirements given in (2)
above for machines, their control systems, loads, auxiliary signal models, FACTS
devices, and dc lines. This subroutine utilizes a set of tables which associate
models and their data with machines, loads, FACTS device, dc lines, and switched
shunt in the working case.
CONEC Is responsible for the state variable requirements given in (2) above for all equip-
ment in the network that are not in the table-driven form.
TBLCNT Is supplied as part of PSS®E and is responsible for the requirements given in (3)
above for machines, loads, load relays, line relays, FACTS devices, dc lines, and
switched shunt. This subroutine utilizes a set of tables that associate their data with
machines, loads, line relays, FACTS devices, dc lines, and switched shunt in the
working case.
CONET Is responsible for the modeling of the network-related equipment described in (3)
above for all equipment in the network that are not in the table-driven form.
USRXXX Is responsible for calling user-written plant and wind related models. Calls to
USRXXX are initiated from TBLCNC and TBLCNT. Staring PSS®E version 31, the
presence of this subroutines is not mandatory. If the USRXXX subroutine is not
present, PSS®E has the provision to call user written plant and wind related models
directly from TBLCNC and TBLCNT.
21-3
USRLOD Is responsible for calling user-written load-related models. Calls to USRLOD are
initiated from TBLCNC and TBLCNT. Staring PSS®E version 31, the presence of
this subroutines is not mandatory. If the USRLOD subroutine is not present, PSS®E
has the provision to call user written load-related models directly from TBLCNC and
TBLCNT.
USRREL Is responsible for calling user-written line relay models. Calls to USRREL are initi-
ated from TBLCNT. Staring PSS®E version 31, the presence of this subroutines is
not mandatory. If the USRREL subroutine is not present, PSS®E has the provision
to call user written line relay models directly from TBLCNT.
USRAUX Is responsible for calling user-written auxiliary signal models that could be associ-
ated with dc line and FACTS device models. Calls to USRAUX are initiated from
TBLCNC. Staring PSS®E version 31, the presence of this subroutines is not
mandatory. If the USRAUX subroutine is not present, PSS®E has the provision to
call user written auxiliary signal models directly from TBLCNC.
USRFCT Is responsible for calling user-written FACTS device models. Calls to USRFCT are
initiated from TBLCNC and TBLCNT. Staring PSS®E version 31, the presence of
this subroutines is not mandatory. If the USRFCT subroutine is not present, PSS®E
has the provision to call user written FACTS device models directly from TBLCNC
and TBLCNT.
USRDCL Is responsible for calling user-written dc line models. Calls to USRDCL are initiated
from TBLCNC and TBLCNT. Staring PSS®E version 31, the presence of this
subroutines is not mandatory. If the USRDCL subroutine is not present, PSS®E has
the provision to call user written dc line models directly from TBLCNC and TBLCNT.
It is the user’s responsibility to supply the subroutines CONEC and CONET if there are user model
calls in these two subroutines. While subroutines CONEC and CONET bear modeling responsibility,
often they contain no user-written code at all, but are simply a sequence of FORTRAN CALL state-
ments connecting models from the PSS®E Model Library to network components. Presence of
USRXXX, USRLOD, USRREL, USRAUX, USRFCT, and USRDCL subroutines as explained above
is not mandatory.
21.1.2 Data Structure

The types of data involved in dynamic simulation calculations may be separated into four
categories:
• Constants are parameters that do not vary during the simulation.

• State variables are quantities for which the instantaneous values are determined by
differential equations.
• Algebraic variables are quantities for which the values at any instant can be deter-
mined if all state variables and constants are known.
• Input variables are quantities for which the values at any instant are specified by logic
outside of the dynamic simulation.
The PSS®E dynamic simulation data structure contains a group of named arrays, related to buses,
machines and loads, that comprise quantities that are frequently needed as input and output in
setting up and displaying the results of dynamic simulations. These include arrays such as VOLT,
BSFREQ, MBASE, PELEC, EFD, TPLOAD etc. PSS®E supplied dynamic models as well as user-
written models gain access to these quantities through the bus, machine, load, and branch
numbering sequences.
21-4
In addition, there are four large general purpose storage arrays:
CON Contains constants.

STATE Contains state variables.
VAR Contains algebraic variables.
ICON Contains integer quantities which may be either constants or algebraic variables.
Corresponding to each ICON is an entry in the CHRICN array which may contain
character quantities.
These four general purpose arrays are treated as large storage bins. Each reference to a model
from the PSS®E Model Library and to a user-written model may be assigned a small contiguous
block of locations in one or more of these arrays. The block of consecutive storage locations in
these arrays is allocated for each model type (i.e., plant-related model, load related model etc.) on
a first come, first served basis.
The filling of the model connection tables used by PSS®E supplied as well as user defined models,
then, requires enumeration of the CONs, STATEs, VARs and/or ICONs used for each model refer-
ence. The number of locations that would be allocated in each of these arrays for all PSS ®E
supplied models is shown in data sheets; refer to PSS®E Model Library.
Although the user must understand this process, the bookkeeping chore of assigning blocks of
storage locations for each model reference is handled by the PSS®E activities DYRE, CHAN, and
CHSB, and by the Add/Edit constants Add/Replace functions. These activities also construct the
model connection tables and the connection subroutines (CONEC and CONET), and transfer the
constant parameters associated with each model call into the CON and ICON blocks assigned to
the model.
Table 21-1 Dynamic Simulation Arrays tabulates the principal arrays used in the dynamic simulation
section of PSS®E.
Table 21-1. Dynamic Simulation Arrays
Array Contents Indexed By

Constants:
CON General constants (real) CON number
ICON General constants (integer) ICON number
General constants (character) (maximum 12
CHRICN ICON number
characters)
MBASE Machine base MVA Machine index
ZSORCE Machine impedance (complex) Machine index
XTRAN Step-up transformer impedance (complex) Machine index
GENTAP Step-up transformer tap ratio Machine index
State Variables:
STATE General state variable array (state-space) STATE number
21-5
Table 21-1. Dynamic Simulation Arrays (Cont.)
Algebraic Variables:
VAR General algebraic variable array VAR number
VOLT Bus pu voltages (complex) Bus sequence number
BSFREQ Bus pu frequency deviations Bus sequence number
ANGLE Machine relative rotor angle (degrees) Machine index
PELEC Machine electrical power (pu on SBASE) Machine index
QELEC Machine reactive power (pu on SBASE) Machine index
ETERM Machine terminal voltage (pu) Machine index
EFD Generator main field voltage (pu) Machine index
PMECH Turbine mechanical power (pu on MBASE) Machine index
SPEED Machine speed deviation from nominal (pu) Machine index
XADIFD Machine field current (pu) Machine index
ECOMP Voltage regulator compensated voltage (pu) Machine index
VOTHSG Stabilizer output signal (pu) Machine index
VUEL Minimum excitation limiter output signal (pu) Machine index
VOEL Maximum excitation limiter output signal (pu) Machine index
TPLOAD Effective MW load (pu on SBASE) Load index
TQLOAD Effective Mvar load (pu on SBASE) Load index
auxiliary signal index and 2-terminal dc
DC2SIG Auxiliary-signal input for 2-terminal dc line models
line index
Auxiliary-signal input for multi-terminal dc line auxiliary signal index and multi-terminal
DCMSIG
models dc line index
VSCSIG Auxiliary-signal input for VSC dc line models Auxiliary signal index and VSC index
Auxiliary signal index and FACTS
FCTSIG Auxiliary-signal input for FACTS device models
device index
VRFDBK AVR rate feedback output Machine Index
VFEOUT AVR VFE signal Machine index
WVLCTY * Wind velocity, m/s Wind machine index
WTRBSP * Wind turbine rotor speed deviation (pu) Wind machine index
WPITCH * Pitch angle (degree) Wind machine index
WAEROT * aerodynamic torque (pu on MBASE) Wind machine index
WROTRV * Rotor voltage (pu on MBASE) Wind machine index
WROTRI * Rotor current (pu on MBASE) Wind machine index
Active power command from wind control (pu on
WPCMND * Wind machine index
MBASE)
Reactive power command from wind control (pu on
WQCMND * Wind machine index
MBASE)
21-6
WAUXSG * Output of wind auxiliary control (pu on MBASE) Wind machine index
WROTVD * Rotor voltage d-component (pu on MBASE) Wind machine index
WROTVQ * Rotor voltage q-component (pu on MBASE) Wind machine index
WROTID * Rotor current d-component (pu on MBASE) Wind machine index
WROTIQ * Rotor current q-component (pu on MBASE) Wind machine index
Active current command from wind control (pu on
WIPCMD * Wind machine index
MBASE)
Reactive current command from wind control (pu on
WIQCMD * Wind machine index
MBASE)
q-axis voltage command from wind control (pu on
WEQCMD * MBASE) Wind machine index
Input Variables:
VREF Voltage regulator voltage setpoint (pu) Machine index
GREF Turbine governor reference Machine index
LCREF Turbine Load Control reference Machine index
SWSREF Switched shunt reference Switched shunt index
Internal Arrays:
DSTATE General state variable time derivatives (state-space) STATE number
STORE General state variable integrator memory STATE number
2 * STATE number - 1
STORMT General memory (extended term)
and 2 * STATE number
CURNT Network solution current injection (complex) Bus sequence number
BSFMEM Memory for frequency calculation Bus sequence number
STRTIN Starting array indices for plant-related models Array allocation table index
NUMTRM Pointer to bus sequence number Machine index
NUMBUS External bus number Bus sequence number
MACHID Machine identifier Machine index
0 if the machine is not a wind machine, else contains
WNDNUM Machine index
the wind machine index
WSTRTIN Starting array indices for wind-related models Wind array allocation table index
Starting shared data array indices for load-related
LDSTRT Load array allocation table index 1
models
Starting private data array indices for load-related
LDSTR2 Load array allocation table index 2
models
NUMLOD Pointer to bus sequence number Load index
LOADID Load identifier Load index
RLSTRT Starting array indices for line relay models Line relay array allocation table index
21-7
Linkage to Power Flow Program Operation Manual
RINCNX Branch relay model connection table index Double entry branch index
INTICN Integer memory array ICON number
Auxiliary-signal array allocation table
STRTAU Starting array indices for auxiliary-signal models
index
STRTFC Starting array indices for FACTS device models FACTS device connection index
STRT2D Starting array indices for two-terminal dc line models two-terminal dc line connection index
Starting array indices for multi-terminal dc line
STRTMD multi-terminal dc line connection index
models
STRTVS Starting array indices for VSC dc line models VSC dc line connection index
FCTCNX FACTS device connection table index FACTS device index
DC2CNX Two-terminal dc line connection table index Two-terminal dc line index
DCMCNX Multi-terminal dc line connection table index Multi-terminal dc line index
VSCCNX VSC dc line connection table index VSC dc line index
STRTSS Starting array indices for switched shunt models Switched shunt connection index
Starting array indices for CCT type models (the
family of models that are called CCT type models
are as follows: branch device and other models, 2-
winding transformer device and other models, 3-
winding transformer device, protection and other
models, bus protection and other models, machine
STRTCCT protection and other models, 2-terminal dc line pro- CCT array allocation index
taction and other models, n-terminal dc line protec-
tion and other models, VSC dc line protection and
other models, FACTS device protection and other
models, switched shunt protection and other mod-
els, induction machine protection and other models,
and miscellaneous other models)
* Can be used only for wind machine models (i.e., models for machines that are designated as wind
machines in power flow).
21.2 Linkage to Power Flow

PSS®E allows the user to execute power flow activities (i.e., those activities described in Chapter 6)
at any point during a dynamic simulation run. This is accomplished by selecting the network tab on
the PSS®E GUI.
The interface elements for the Dynamics study elements of PSS®E are contained directly within the
application. Switching between the two modes of analysis, steady-state and stability, is done auto-
matically, there is no need to worry about the mode of operation.
Moving from the dynamics to the power flow window has the effect of transferring the generator
power outputs, PELEC and QELEC of Table 21-1 Dynamic Simulation Arrays, into the plant and
machine output arrays in the working case, and making the power flow related menu items
accessible.
21-8
Program Operation Manual The Network Model
The return back to the dynamic simulation window is accomplished by selecting the dynamics tab
on the PSS®E GUI. Moving from the power flow to dynamics window has the effect of setting up
the translation arrays NUMTRM, NUMLOD, RINCNX, FCTCNX, DC2CNX, DCMCNX, VSCCNX
etc. (see Table 21-1 Dynamic Simulation Arrays), updating the plant-related, load-related, line relay
model, FACTS device, VSC (Voltage Source Converter) dc line connection tables etc., (see
Sections 21.1.1 and 21.4), updating the output channel addresses (see Section 21.6 Simulation
Outputs), and transferring control back to dynamic simulation activity selection.
The principal applications of the power flow linkage are to:
1. Set up the power flow working case and to establish the admittance matrix temporary file (if
the factored matrix is not constructed prior to running the dynamic simulation, PSS®E will
run the factorization).
2. Allow examination of the network conditions existing at any instant of a simulation.
The required sequencing of PSS®E activities in these two applications are given in Sections 21.3
and 21.7.2, respectively.
Care must be taken while the power flow linkage is in effect not to modify the power flow working
case unless a system disturbance or reinitialization of the dynamic simulation is intended. The
power flow output reporting activities and activity SAVE may be used freely without risk of disturbing
the simulation. Activities such as CASE, CHNG, DSCN, and SCAL should be used with care in the
midst of a simulation run. Additional comments are given in Section 21.7.2 Applying Disturbances.
21.3 The Network Model

Every dynamic simulation is based upon a power flow Saved Case that provides it with the required
transmission network data, load data, machine positive sequence characteristic data (i.e., MBASE,
ZSORCE, XTRAN and GENTAP), and the initial network condition from which the dynamic models
are initialized. Thus, the dynamics data structure with its corresponding connection subroutines
described in Section 21.1.2 Data Structure is augmented by the power flow working case to form a
system model of the form required for dynamic simulations.
The power flow Saved Case must be present in the working case and be converted from its stan-
dard power flow form to the form required for dynamic simulations. In power flow, most generators
are represented by specifying their desired bus voltage magnitudes and active power outputs; their
voltage phase angles and reactive power outputs, within specified limits, are free variables which
are determined by the power flow solution activities. In dynamics, generators are represented by
their Norton equivalents as current sources. This conversion of machines from their power flow
model to their Norton equivalent is handled by activity CONG. The determination of the initial source
current (ISORCE) by activity CONG is based upon the machine power outputs and bus voltages,
along with the impedance data in the working case characterizing each machine. Activity CONG
converts all power flow Type 3 (swing) buses to Type 2.
The constant MVA load representation used in conventional power flow solutions is usually not an
acceptable load characteristic for dynamic simulations. The basic conversion of loads from their
constant MVA representation to an arbitrary combination of constant MVA, current and admittance
is handled by activity CONL. The modeling of loads beyond this level is handled by applying models
from the library of load characteristic models.
It is then recommended that activities FACT and TYSL be executed to fine tune the solution, and
that the converted case be preserved in a Saved Case File. The file specified to activity SAVE
21-9
The Dynamic Model Program Operation Manual
should not be the same one from which the original (unconverted) case was picked up because
the use of activity CONG renders the working case and its Saved Case image invalid for the stan-
dard power flow solution activities, and activity CONG is not reversible.
To summarize, then, the following sequence should be followed in setting up the converted network
model for use in dynamic simulations:
1. Pick up a standard power flow case with activity CASE.
2. Using the power flow solution activities, solve the working case to an acceptable mismatch
level. The bus boundary conditions should represent the desired initial network condition
from which the dynamic simulation is to be initialized.
3. Ensure that the machine characteristic data MBASE, ZSORCE, XTRAN and GENTAP are
properly entered for all machines in the working case (see Generator Data and activities
MCRE and CONL).
4. Preserve the unconverted initial network condition in a power flow Saved Case File with
activity SAVE.
5. Execute activities CONG and CONL.
6. Optionally, execute activities FACT and TYSL. Although not essential, this step is
recommended.
7. Save the converted case in a Saved Case File other than the one specified in (4).
After the converted Saved Case is created, it can then be accessed each time it is needed in
constructing the dynamics model as described in Section 21.4 The Dynamic Model and in
executing dynamic simulation calculations as described in Section 21.7 Running a Simulation.
21.4 The Dynamic Model

From the preceding paragraphs of this section, then, the system model for dynamic simulation
calculations in PSS®E is comprised of:
1. The power flow working case, giving a positive sequence representation of the electric
network. A standard power flow case must be augmented by the machine impedance char-
acteristic data MBASE, ZSORCE, XTRAN and GENTAP, and the load and generator
representations must be converted from their power flow modeling to that required by the
dynamic simulation activities. Refer to Sections 21.3 and 6.3.13, Generator Data, and activ-
ities MCRE, CONG, and CONL.
2. Dynamics data working memory which includes: (1) the constants associated with equip-
ment models from the PSS®E Model Library and user-written models which are to be used
in modeling the system; and (2) the model connection table arrays defining the model
connection and data array entries associated with plant-related, load-related, line relay,
auxiliary signal, FACTS devices, dc line, and switched shunt models. Refer to
Sections 21.1.1 and 21.1.2.
3. A set of connection subroutines, CONEC and CONET, which link together equipment
models and their data with network elements.
21-10
Program Operation Manual The Dynamic Model
The remainder of this section describes the development of the second and third items listed above,
and the incorporation of the connection subroutines into the PSS®E program structure.
21.4.1 Subroutines TBLCNC and CONEC

As described in Section 21.1.1 Program Structure, subroutines TBLCNC and CONEC have the
principal responsibility of processing those equipment models involving state variables and differ-
ential equations. The majority of such models are those used in the modeling of generating plant
equipment (generators, power system stabilizers, compensators, excitation limiters, excitation
systems, and turbine governors), some types of load characteristic models, auxiliary signal models,
FACTS device models, dc line models, and switched shunt models, and are called through subrou-
tine TBLCNC.
The form of each model reference in these subroutines is that of a FORTRAN CALL statement
referencing the model name and an argument list. The arguments generally specify the location of
the model in the network and the starting locations in the general purpose storage arrays CON,
STATE, VAR and/or ICON of the block of storage locations reserved for that model reference.
Although implemented differently, plant-related models, load characteristic models, auxiliary signal
models, FACTS device models, dc line models, and switched shunt models called through subrou-
tine TBLCNC receive the same information via their argument lists whenever they are called; see
Section 23.5 Writing the Basic Model for details.
21-11
The Dynamic Model Program Operation Manual
The construction of the model connection tables for subroutine TBLCNC and of subroutine CONEC,
then, involves the following steps:
1. A model must be selected from the PSS®E Model Library for each piece of equipment to be
represented in the simulation, and the appropriate constant parameters required must be
recorded.
2. Storage locations in the general purpose storage arrays must be assigned and numeric
values must be determined for all subroutine arguments for each model selected in (1).
3. A model connection table entry must be made for each TBLCNC model reference.
4. The subroutine CONEC model calls must be collected into the form of FORTRAN
subroutines.
5. Each model’s constant parameters must be placed into its CON and/or ICON locations
assigned in (2).
Although steps 2, 4 and 5 above could be done manually by the user, this process would be both
time consuming and error prone. Rather, the PSS®E activity DYRE is normally used to accomplish
the bookkeeping and data handling functions in 2 through 5. The use of activity DYRE is further
discussed in Section 21.4.3 Data Assimilation.
21.4.2 Subroutines TBLCNT and CONET

Subroutines TBLCNT and CONET contain two general types of models:
1. Those for which there is an algebraic relationship between the voltage at a bus and the
current drawn by the device being modeled, and other models which inject a current at each
iteration of the network solution.
2. Those for which input or output is a quantity determined solely by network quantities, such
as relays and monitoring models.
The construction of these subroutines involves the same type of approach as in the construction of
subroutines TBLCNC and CONEC described in the previous section. The majority of CONET
models are processed by activity DYRE as described in the following section.
There is a group of models (e.g., static VAR system models, and certain load characteristic models)
which involve both state variables and network current injections. Such models are handled by a
coordinated model pair in which there is a call in subroutine TBLCNC or CONEC to process the
differential equation part of the modeling, and a call in subroutine TBLCNT or CONET to handle the
network current injection. For example, when the series reactor model CRANI is called from subrou-
tine CONEC, its CONET counterpart, TRANI, must be called from subroutine CONET with the same
set of arguments.
21.4.3 Data Assimilation

Activity DYRE reads data records from a Dynamics Data Input File, and in its processing performs
the following functions:
1. It assigns storage locations in the general purpose arrays for each model reference.
2. It places the constant parameters associated with each model reference into the assigned
locations in the CON and/or ICON arrays.
21-12
Program Operation Manual The Dynamic Model
3. It builds the model connection table arrays for plant-related, load-related, line relay, FACTS
device, dc line, and switched shunt models.
4. It builds the CONEC and CONET subroutines containing the model calls with their appro-
priate argument lists for each remaining model.
The user should first create a Dynamics Data Input File of the form described in Section 15.1.1
Dynamics Model Raw Data File Contents. One record should be entered for each PSS®E Model
Library reference and each user-written model reference used in modeling the system.
The following points should be noted in constructing this file:
1. Each record must have the model name enclosed in single quotes and must be terminated
with a slash.
2. A record may occupy more than one physical line in the file as long as only the final line of
the record is ended with the slash.
3. Data records may appear in any order.
4. Any equipment which is modeled by a coordinated call model pair (e.g., CDC4T / TDC4T
and CSVGN1/TSVGN1) should have only one record entered for it with the TBLCNC or
CONEC model name specified.
After a Dynamics Data Input File has been created, the following procedure is used:
1. Initiate PSS®E.
2. Retrieve the converted power flow Saved Case representing the network to be modeled.
3. Read dynamics data file, and preserve the dynamics working memory in a snapshot file.
Preserve dynamics working memory in a Snapshot File and terminate PSS®E.
4. Incorporate the connection subroutines into the PSS®E program structure as described in
Section 21.4.4 Program Set-Up.
Error messages tabulated during the execution of activity DYRE are displayed at the Progress tab.
Any such messages should be resolved prior to proceeding with further. This may involve an editing
operation on the data input file to correct typographical errors or to add data records to the file, and
a subsequent re-execution of activity DYRE.
The progress report output of activity DYRE and the consistency check may be preserved in hard
copy form and retained with the user’s study notes. This may be done either via activity PDEV, the
computer system’s session logging facility, or a cut and paste operation from the Progress tab of
the PSS®E interface.
Those models which are not automatically processed by activity DYRE (see Section 15.1.5 Appli-
cation Notes) are either set up by activity CHAN (see Section 15.2.2, Application Notes and Section
21.6, Simulation Outputs), they may be treated as User-Written Models by activity DYRE, or their
calls may be manually entered into the connection subroutines by the user (see Section 21.9
Advanced Uses of CONEC and CONET).
21-13
Model Verification Program Operation Manual
21.4.4 Program Set-Up

Prior to compiling the connection subroutines, the user may add any desired control logic to them;
this is discussed in more detail in Section 21.9 Advanced Uses of CONEC and CONET. There is
however a situation in which the connection subroutines as generated by activity DYRE require
statement insertion by the user. It occurs when dc lines are being modeled (using one of the
following models that are still not in the table-driven form: CDCRL, CASEA1, CDCVUP, CEELRI,
CMDWS2, CMFORD, CHIGAT, CMDWAS) and one or more of the dc line supplementary signal
models are being used. The insertion involves placing the auxiliary signal into the Other signals
VAR, VAR(L), of the dc line model. The procedure is illustrated by example.
Suppose dc line 1 is sensitive to a supplementary signal which is formed by summing the outputs
of a pair of PAUX1T models. Suppose the supplementary signal model PAUX1T model stores the
model output in VAR(9) and VAR(20). Note that because PAUX1T is a table-driven model, activity
DYRE does not generate PAUX1T model calls in CONEC. Suppose the dc line is modeled using
the dc line model CMFORDT. Because CMFORD model is still not in the table-driven form, activity
DYRE will generate CMFORD model call in subroutine CONEC. A portion of subroutine CONEC as
constructed by activity DYRE appears as follows:
CALL CMFORD ( 1, 206, 73, 31, 3)

C
RETURN
Referring to the CMFORD data sheets (see PSS®E Model Library, Chapter 23), the fifth argument
in the CMFORD calling sequence is the index of the first VAR used by it, and this VAR contains the
supplementary signal used as input to the model.
Thus, immediately preceding the call of the CMFORD model, the following statement must be
inserted:
VAR(3) = VAR(9) + VAR(20)
If extended term simulations are to be performed (see Section 21.10 Extended Term Simulations),
the supplementary signal model output and the setting of the dc line model’s Other signals VAR
must be brought over into subroutine CONET as well. Using the above example, the following code
fragment results when the above code is inserted before the TMFORD model call in subroutine
CONET corresponding to the CMFORD call in subroutine CONEC:
IF (MIDTRM)
. VAR(3) = VAR(9) + VAR(20)
...FIN
C
CALL TMFORD ( 1, 206, 73, 31, 3)
With valid connection subroutines prepared, the user must compile them and link the resulting
object code with the rest of PSS®E. This procedure is described in Section 4.10 Loading the
Connection Subroutines.
21.5 Model Verification

Having gone through the process of collecting data and feeding it through activity DYRE into
PSS®E dynamics working memory, prior to executing simulation runs the user must ensure himself
that the system model thus constructed faithfully models the physical power system. A model setup
with unchecked and unreliable data usually produces inaccurate results in system simulations.
21-14
Program Operation Manual Model Verification
There are thousands of data parameters from a wide variety of sources used in a large scale system
simulation study. The checking of each of these for accuracy is no easy task. PSS®E provides for
three levels of model verification:
1. Data parameters are checked for reasonableness. This detects many simple errors such as
transcription errors.
2. The performance of generating units are tested in hypothetical isolated operating conditions
where the effects of excitation and governor action are not masked by the electrical synchro-
nization effect, but are clearly and unambiguously visible.
3. The initialization of the simulation at the predisturbance network operating condition is

checked for model variables initialized outside of prescribed limits and for steady-state
operation.
The following paragraphs discuss these levels of data verification in greater detail.
21.5.1 Parameter Range Checking

Activity DOCU provides documentation of the dynamic simulation setup. For each model, it tabu-
lates the equivalent of a filled in model data sheet. This consists of a listing of the constant data read
from the Dynamics Data Input File along with a statement of the locations assigned in the general
purpose storage arrays by activity DYRE.
However, critical examination of this report for a large system is difficult because of its volume. It is
unlikely that an engineer studying this report would find all errors and it is therefore not a practical
way of locating errors.
Through its interactive dialog, activity DOCU may be operated in a mode which provides an initial
editing of the report and restricts it to those models for which the values of one or more constant
parameters are suspect. Parameters are checked against typical ranges of values. In addition,
certain relational checks between parameters are made (e.g., machine leakage reactance must be
less than subtransient reactance). The suspect parameters are tabulated followed by the standard
model output block.
It must be noted that being flagged by activity DOCU in its data checking mode does not indicate
that parameter values are necessarily wrong; it simply indicates that they deserve to be checked.
Conversely, the absence of warning messages from activity DOCU in this mode does not indicate
that all data is valid. Most power system parameters can fall within reasonable typical value ranges
and still be totally invalid.
Thus, the data checking mode of activity DOCU is intended to detect gross errors such as
misplaced decimal points and as such provides only a rough initial screening for typing and steno-
graphic errors.
As a final point, the preprogrammed typical parameter ranges are set on the assumption that plant
equipment data is specified on actual machine base MVA. The practice of specifying all machine
data on a common base (say, 100 MVA) is discouraged because this often results in the spurious
flagging of generator and governor models in the data checking mode of activity DOCU, thus
partially defeating its report editing intent. It is strongly recommended, then, that the machine quan-
tity MBASE in the power flow, on which machine model data is specified, be set to the actual
machine base MVA for each machine, and that model parameters be specified accordingly.
21-15
21.5.2 Performance Verification

The proper criterion for judging the correctness of generator, excitation system, and turbine
governor data is not that all parameter values lie within typical ranges, but rather that the parameter
values modeling each item of equipment correspond to correct performance of the unit under test
conditions. Therefore, after data has been checked for gross errors using the reasonable data
check option of activity DOCU, the user should verify that the sets of parameter values in the system
model lead to:
1. Correct steady-state values of all quantities that are normally measured or documented in
normal operation of a generating unit.
2. Correct reproduction of dynamic response tests that may be performed on generating units
and their control systems in isolation.
The following paragraphs describe the tools available to the PSS®E user for assessing the correct-
ness of a system model.
Generator Reactances and Saturation Data

The PSS®E machine models require the specification of unsaturated synchronous machine reac-
tances together with two points on the machine’s open circuit saturation curve.
Generator saturation data is often among the least checked of the constant parameters describing
a power system. The correct specification of the saturation data is necessary in order for the gener-
ator field voltage, EFD, to take on its correct value at all loadings. The correct initial value of EFD is
of major importance in any simulation run in which the excitation system ceiling is a significant
parameter (e.g., in virtually all transient stability runs). Any error in the initial value of EFD in such
simulations produces a corresponding error in the maneuvering range available to raise the field
flux linkages while the exciter is at ceiling during and following a fault. Because this field forcing
effort is known to be a key factor in determining transient stability limits, a correct initial value of EFD
is just as important as correct specification of excitation ceiling.
The best form of verification of generator reactances and saturation data is the machine V-curves
which plot generator terminal current versus excitation voltage, EFD, over its whole operating
range. These curves are commonly provided by generator manufacturers along with open circuit
saturation curves as standard design documentation.
The PSS®E auxiliary program VCV produces such a plot for a specified set of machine reactances
and saturation data. It also tabulates the steady-state excitation voltage corresponding to a given
loading. The use of program VCV is described in Additional Resources for PSS®E, VCV.
21-16
Exciter Response Ratio Test

The data describing the rotating exciter may be checked by simulating an exciter response ratio
test. In this test, the exciter is set up to run at the output voltage and current corresponding to rated
main generator operating point. The voltage regulator setpoint is then raised suddenly by a large
amount to drive the exciter to its ceiling as rapidly as possible.
The procedure for carrying out this test is as follows:
1. Initiate PSS®E.
2. Restore the Snapshot containing the dynamics data of the system being modeled
(activity RSTR).
3. Retrieve the corresponding converted power flow Saved Case. Note that the generators
must be converted. However, there is no need to factorize the matrices (i.e., activity FACT
is not required) because the transmission network is ignored in this test, with all machines
operating in isolation.
4. From the menu, select the option to perform exciter response ratio simulation. After initial-
izing, run the response ratio simulation to zero seconds (specifying TPAUSE equal to 0).
Then continue the simulation to TPAUSE set at 2 seconds.
The response ratio test is executed simultaneously on either all units in the system or all machines
at a designated bus. Any user-specified output channels (see Section 21.6 Simulation Outputs) are
overridden and the exciter outputs, EFD, of all online machines being tested are placed in output
channels.
Activity ESTR overrides the initial generator loadings as contained in the working case and initial-
izes each unit to rated MVA at a user-specified power factor. Following completion of activity ESTR,
it is advisable to check the value of EFD for each machine to ensure that it is as determined by
program VCV or from generator test data for rated load. An unacceptable value of full load excitation
usually indicates an erroneous specification of the generator saturation data; all generator data, in
particular SE(1.2), should be checked before proceeding.
Activity ERUN reveals both the ceiling value of EFD and the excitation system response ratio for
each unit. The user should examine these values and adjust the excitation loop data if they do not
correspond to the known ceiling and response ratio.
Because the machine initialization to rated MVA is based on the value specified as MBASE for each
machine, the response ratio test is valid only for those machines where data is specified on their
actual MVA base. For operational and additional application details, refer to activities ESTR and
ERUN.
Excitation System Open Circuit Step Response Test

The response ratio test described above provides information on the modeling of exciters but gives
no indication of the correctness of the voltage regulator gains and time constants. These are
checked by ensuring that the excitation system gives stable and effective control of generator
terminal voltage when the machine is operating at rated speed on open circuit (e.g., just before
synchronizing).
This aspect of excitation system performance is readily tested by applying a simple step change of
about five percent to the voltage regulator reference and observing the resulting responses of field
21-17
voltage (EFD) and generator terminal voltage (ETERM). The values of excitation system parame-
ters should be such that a well damped but not overly sluggish response is obtained.
1. Initiate PSS®E.
(activity RSTR).
4. From the menu, select the option to perform exciter simulation test. After initializing, run the
open circuit simulation to zero seconds (specifying TPAUSE equal to 0). Then continue the
simulation to TPAUSE set at 2 seconds.
The open circuit response test is executed simultaneously on either all units in the system or all
machines at a designated bus. Any user-specified output channels (see Section 21.6 Simulation
Outputs) are overridden and the exciter outputs, EFD, and machine terminal voltages, ETERM, of
all online machines being tested are placed in output channels.
Activity ESTR overrides the initial generator loadings as contained in the working case and initial-
izes each unit to the rated terminal voltage on open circuit. Following completion of activity ESTR,
the initial value of EFD for each unit should be slightly greater than the air gap line value of unity
due to saturation in the main generator. An initial open circuit value of EFD exceeding about 1.2 pu
is a fair indication that the generator saturation data is erroneous.
The response to a setpoint step of about 0.05 pu should normally show a slight overshoot but be
well damped with no persistent oscillations. For operational and additional application details, refer
to activities ESTR and ERUN.
Governor Response Test

The principal purpose of the governor response test is to ensure that the governor gain and time
constant parameters correspond to a correctly tuned well damped response. In this test, each
machine is initialized to a given load and the response of the governors to a step change in the load
is measured. The load electrical power is held constant after the step so that the response indicates
the damping due to the turbine and governor loop only.
1. Initiate PSS®E.
(activity RSTR).
21-18
4. From the menu, select the option to perform governor response simulation. After initializing,
run the simulation to zero seconds (specifying TPAUSE equal to 0). Then continue the simu-
lation to TPAUSE set at 2 seconds.
The governor test is executed simultaneously on either all units in the system or all machines at a
designated bus. Any user-specified output channels (see Section 21.6 Simulation Outputs) are
overridden and the speed deviations, SPEED, and turbine mechanical powers, PMECH, of all
online machines being tested are placed in output channels.
It is recommended that the governors be initialized to about 0.8 pu load and that the load step be
approximately 0.1 pu. Note that the damping of hydro governing loops is usually decreased with
increasing load and hence, unless the objective is to compare the calculated response with a test
result taken at a low load level, governor response tests should normally be made near full load.
Activity GSTR overrides the initial generator loadings as contained in the working case and initial-
izes each unit to a specified loading at unity power factor. This test reveals the transient variation
of turbine power. All units should have a well damped response. Hydro governors will generally
show a somewhat greater overshoot than steam turbine governors but should still be well damped,
showing no persistent oscillations. Note that a small negative change in hydro turbine power before
it follows a positive change of load power is normal and does not indicate incorrect governor tuning.
Because the machine initialization is based on the value specified as MBASE for each machine, the
governor response test is valid only for those machines where data is specified on their actual MVA
base. For operational and additional application details, refer to activities GSTR and GRUN.
Application Notes
The response tests described in Exciter Response Ratio Test, Excitation System Open Circuit Step
Response Test, and Governor Response Test are special PSS®E simulations of standard test
conditions. Steady-state and transient results are observed and compared with either actual test
results or with typical unit performance. Because the form of the test result needed for satisfactory
performance of the unit is well understood in practice, these simulations assist in detecting those
situations where parameter values appear to be reasonable but are actually incorrect.
These response tests are able to calculate the response of all generating units in the system simul-
taneously. Because machines are operating in isolation, no network solution is required in the
simulation. Furthermore, only the generator and their excitation system or governor models perform
any calculations in these simulations; all other models are inactive. Thus, these simulations require
substantially less computer time than complete system simulations.
In the second and subsequent passes through one of the above response tests, even further execu-
tion time advantages can be realized. Suppose, for example, that on previous response test
simulations all units except the single machine at bus 201 have shown satisfactory performance.
One additional test is to be run with modified data for this machine and only this machine is of
interest, and hence the excitation open circuit test need be performed for this machine only.
The response test subsequently performed simulates only the response of the machines at bus
201, and the channel output file written during the simulation contains only the variables of interest.
Note again that activities ESTR and GSTR override any output channel selections previously made
by the user (see Section 21.6 Simulation Outputs). Thus, following execution of either of these
activities, Snapshot Files containing these channel specifications should not be overwritten with
activity SNAP if the channel selections are to be preserved.
21-19
21.5.3 Simulation Initialization

The verification procedures heretofore described are used to assess the correctness of the equip-
ment model parameters comprising the system model. However, a dynamic simulation model must
be correct with respect to both its equipment parameters and its initial condition operating point.
The checking of the initial condition operating point should begin before setting up the converted
network for use in the dynamic simulation activities (see Section 21.3 The Network Model). Most
importantly, machine terminal conditions should be examined to check for acceptable voltage,
loading and power factor, and to ensure that machine loadings are within turbine governor limits.
Activity GEOL is useful for this check. Other operating point checks that can be made include: a
cross check of the operating point of dc transmission lines with the dynamics data parameters spec-
ified for the dc line model, particularly the voltage dependent current limit; acceptably small
mismatches from the power flow solution; and the selection of load characteristics in establishing
the converted case.
These checks can only verify operating point variables outward from the generator terminals. The
checking of the initial condition with respect to variables within the equipment dynamic models is
assisted by the dynamic simulation initialization activity STRT.
Beginning with the generator terminal conditions as contained in the working case, activity STRT
works backward through all dynamic simulation models to determine the initial condition values of
all state, algebraic, and input variables along with those of several of PSS®E’s internal arrays (refer
to Table 21-1 Dynamic Simulation Arrays). These quantities represent the conditions inside the
generators, excitation systems and other equipment modeled by the PSS®E Model Library subrou-
tines that comprise the system model.
Activity STRT also performs a number of data consistency and operating limit checks. This
checking is handled in conjunction with this backward initialization process. Each equipment model
checks all variables to which limits are applied to ensure that the calculated initial value of the vari-
able falls between the limits. Limit violations generate an alarm and the calculated values are
overridden by the appropriate limits.
All limit violations should be resolved before proceeding with dynamic simulation runs. This may
involve either simply correcting an erroneously specified limit, redoing of power flow work to modify
the initial condition operating point, or tracking down some other parameter in error in the model.
It is possible for the initial condition operating point to be such that a variable is initialized exactly at
one of its limits. Such a situation may occur, for example, if a machine is fully loaded and its turbine
mechanical power initializes precisely at its ceiling. This condition, although it has generated an
alarm, is acceptable.
A network solution is used during the initialization process and the number of iterations it requires
is tabulated by activity STRT. In the vast majority of cases, particularly if the network solution in the
converted power flow case was refined with activity TYSL as suggested in Section 21.3 The
Network Model, only one iteration should be required. When more than one iteration is needed, this
usually indicates a serious modeling error (e.g., omitting the dc line model for a dc line represented
in the working case) which must be resolved.
A useful aid in tracking down the cause of this type of error is to execute activity STRT with the
network solution convergence monitor turned on (i.e., select activity STRT,CM; activity STRT). The
bus experiencing the largest voltage change on the first iteration is a good starting point for
detecting the cause of the problem.
21-20
Program Operation Manual Simulation Outputs
Any limit violation errors and the causes of excessive iteration during the initial condition network
solution should be reconciled first. These errors usually result in a number of steady-state violation
errors (i.e., nonzero time derivatives) described next which are eliminated upon correction of these
first two categories of errors.
Upon completing the calculation of the system initial condition, activity STRT performs a test calcu-
lation of the time derivatives of all state variables using the same calculation sequence that is used
during dynamic simulation runs. In the absence of limit violations, the network solution should
converge in one iteration and all time derivatives should be close to zero. (Some will not be exactly
zero due to the precision and rounding errors inherent in the computer’s finite word length). Any
state variable for which the time derivative differs significantly from zero in relation to the value of
the state variable itself generates an alarm. The STATE number and the values of the state variable
and its derivative are printed. For any plant-related, load-related, dc line, FACTS, and switched
shunt models with a state variable included in the tabulation, the name and location of the model
are also listed. For other models, individual STATEs may be correlated with specific model calls by
examining the output of activity DOCU,CN and DOCU,CT.
These steady-state violation errors should be checked out before the system model is accepted as
a valid starting point for dynamic simulations. Perseverance in tracking down the causes of these
errors is essential if good quality simulation results are to be obtained; they are often symptoms of
errors or incompatibilities in the power flow and dynamic simulation data on which the system model
is based.
It is possible for a state variable to generate an alarm because of the precision limitations of the
computer referred to above rather than due to a modeling error. Such STATEs are usually charac-
terized by a high gain and a short time constant. The voltage regulator output, STATE(K+1), of the
IEEET1 model, for example, often possesses these characteristics. Usually, these errors may be
accepted if the time derivative, DSTATE, is less than about five or six percent of the value of the
STATE.
In these cases, and, in fact, for all simulation setups, a simulation run with no disturbance applied
is often a useful mechanism for revealing previously undetected data errors and/or numerical inte-
gration instability (i.e., a time step too large in relation to the shortest time constant in the process).
Such a simulation should remain completely steady with no deviation from the initial condition
regardless of the number of integration steps taken.
Another useful test run involves initiating some movement in the system with a minor perturbation.
This could be the tripping of a small machine, the shedding of a small amount of load, or the tripping
of a noncritical transmission line. Such a simulation should require only two or three network solu-
tion iterations per time step following the disturbance and should approach a new steady state fairly
quickly. There should be no undamped or persistent oscillations.
In both the steady-state and minor disturbance simulations, observing the network solution conver-
gence monitor as described above often gives a good indication of any problems. For operational
and additional application details, refer to activity STRT.
21.6 Simulation Outputs

PSS®E contains no standard set of simulation variables that are recorded to document the results
of a simulation run. Rather, any power system variable that can be represented by an element of
the following dynamics data arrays may be selected as an output of a dynamic simulation run (refer
21-21
Simulation Outputs Program Operation Manual
to Table 21-1 Dynamic Simulation Arrays):
ANGLE PELEC QELEC ETERM EFD PMECH

SPEED XADIFD ECOMP VOTHSG VREF VUEL
VOEL VAR STATE BSFREQ TPLOAD TQLOAD
GREF LCREF WVLCTY WTRBSP WPITCH WAEROT
WROTRV WROTRI WPCMND WQCMND WAUXSG
This is accomplished by assigning the desired value to an output channel. PSS®E places the set
of output channel values into a Channel Output File at specified regular intervals during the simu-
lation run. This file, then, records a comprehensive history of the event being simulated.
21.6.1 Output Channel Selection

The assignment of simulation variables to output channels is handled by the PSS ® E
activities CHAN and CHSB. As each output channel variable is assigned, an entry is made in the
following output channel control arrays:
IPRINT Contains the addresses of the output variables in the dynamic simulation array
space of PSS®E.
IDENT Contains the thirty-two character alphanumeric channel identifiers assigned to each
output channel.
CHNTYP Contains coded descriptions of the type of quantity assigned to each output
channel.
CHNBUS Contains descriptions of the physical location of each output channel quantity.
These arrays are preserved with the dynamics data Snapshot as it is saved and retrieved with
activities SNAP and RSTR, respectively.
The arrays IPRINT and IDENT are used during activity STRT and RUN in the process of filling the
Channel Output File. Each variable address is formed by summing the appropriate array base
address and an offset. The array base addresses are installation dependent; they are a function of
the capacity limits for which PSS®E is dimensioned. (They are displayed in activity ALTR when
output channel data changes are selected.) The offset for VARs and STATEs is simply the VAR or
STATE number; for the remaining quantities, the offset is determined by the internal numbering
scheme of machines, buses and loads in the power flow working case.
When activity CHAN is used to assign a simulation variable to an output channel, the channel iden-
tifier may be specified by the user. If no identifier is entered, activity CHAN supplies a default
identifier (see Table 15-2 Activity CHAN Summary). Activity CHSB always supplies channel
identifiers.
The arrays CHNTYP and CHNBUS are used in describing the quantity assigned to an output
channel in activities DLST and ALTR. They are also used by activities RSTR, SRRS, and RTRN for
recomputing the channel address, IPRINTs, for the situation where the internal numbering of buses,
machines and loads in the working case differs from that contained in the working case at the time
activities CHAN and /or CHSB were executed.
Several of the network quantities available in the menu of activities CHAN and CHSB are not
directly available from any of the arrays listed at the beginning of Section 21.6 Simulation Outputs.
To calculate and place such variables into output channels, activities CHAN and CHSB generate
appropriate references to PSS®E monitoring models which place their results into VARs during the
21-22
Program Operation Manual Simulation Outputs
simulation. These model call references are located in the model connection table arrays, and the
corresponding models are called automatically at each time step of the dynamic simulation. Refer
to Section 15.2.2, Application Notes and Section 15.25.2, Application Notes.
Activities CHAN and CHSB are used to establish the set of output channels for which values are to
be recorded during the simulation. They may also be used to append additional output channel
selections to those previously specified, and to modify the simulation variable assignment of indi-
vidual output channels.
Although activity ALTR may be used to add or change output channel assignments, this is not
recommended because this process involves the determination of the channel addresses in
dynamics memory by the user. This, in turn, requires the knowledge of the internal numbering of
buses, machines and loads in the working case to determine the offset to be used in forming the
channel address. Because activities CHAN and CHSB automatically handle the look-up of these
numbers, their use, rather than through the line model activity ALTR, reduces the risk of error in
specifying output channels.
Two separate index pointers used in the processing of output channels are maintained. The variable
NXTCHN points to the next available channel number and is used in setting up the default channel
number responses in subsequent executions of activities SNAP, CHAN and CHSB. The variable
NCHAN, which is normally equal to NXTCHN-1, is sensed by activities STRT and RUN and defines
the number of output channels to be monitored during dynamic simulation runs. NCHAN may be
set to any nonnegative number less than NXTCHN by the user. Both of these pointer variables may
be changed either using the GUI or by running the line model activity ALTR. For operational and
additional application details, refer to activities CHAN and CHSB, respectively.
21.6.2 Channel Output File

Other than as described in Section 21.7 Running a Simulation, the PSS®E simulation activities do
not plot the set of output channels during the execution of the simulation run. Rather, the values of
the system model variables assigned to output channels are deposited into a Channel Output File
at regular intervals during the simulation.
The Channel Output File is specified in response to an instruction during activity STRT.
Activity STRT creates a file with the specified name (if it does not already exist) and initializes it by
writing the case heading and the channel identifiers at the beginning of the file. Values of simulation
TIME and the variables designated as output channels are written into successive records of the
file by activity RUN. This occurs every NPLT time steps, where NPLT is specified by the user
following the selection of activity RUN.
The user may specify (or change) the Channel Output File to be used during a simulation run. This
ability is useful in the following situations:
1. The user inadvertently bypasses the specification of a Channel Output File during
activity STRT. A file may be specified prior to entering activity RUN.
2. Following activity STRT and before commencing execution of the simulation with
activity RUN, additional simulation variables are to be added to the set of output channels
previously assigned. These are added with activity CHAN or CHSB, a Channel Output File
is specified, and activity RUN is then entered.
3. The Snapshot and power flow Saved Case used as the initial condition operating point for
the simulation were preserved immediately following a previous execution of activity STRT,
and activity STRT is not to be used again to initialize this simulation. Working memory is set
21-23
Running a Simulation Program Operation Manual
up in the standard manner (activities RSTR, LOFL, CASE, FACT, and RTRN), a Channel
Output File is specified either using the GUI or with activity ALTR, and activity RUN is
entered.
Unless some specific purpose is to be served, the user should not normally change the Channel
Output File used in a simulation in the middle of a run.
The Channel Output File is a binary file of variable length records. The results of a simulation run,
as recorded in the Channel Output File, may be plotted and/or tabulated upon completion of the
simulation calculation. The processing of this file is handled by PSS®E plot package as well as the
by the auxiliary program PSSPLT.
21.7 Running a Simulation

A dynamic simulation study involves two general phases: the setup and check out of the system
model, and the execution of simulation runs using the system model. The setup phase, as
described in the preceding sections, is the more critical and involves the greater amount of work.
However, after a valid system model is constructed, an extensive series of simulation runs can be
made with relatively little incremental effort.
21.7.1 Initialization
As described previously, the process of setting up working memory in preparation for a dynamic
simulation calculation requires the following steps:
1. Ensure that the CONEC, and CONET subroutines have been compiled and linked into the
PSS®E program structure as described in Section 4.10 Loading the Connection
Subroutines.
2. Start up PSS®E.
3. Open the power flow case and the dynamics snapshot files.
The above sequence of activities assumes that the Saved Case and the Snapshot files are present,
and that the Snapshot File contains the desired output channel assignments for the simulation run.
Whenever network data is present in the working case and dynamics data is present in PSS®E
working memory, when moving between the power flow and dynamics data spreadsheets, PSS®E
takes care to update the dynamics model connection table array pointers and output channel
addresses to reflect changes in the internal bus, machine, load, and branch numbering of the
working case. These steps correctly set up these arrays in preparation for the dynamic simulation
initialization activity, STRT which initializes all simulation models comprising the system model.
The user may preserve the initial conditions of the dynamic models by taking a Snapshot. The
attainment of a clean STRT is a key point in a simulation study and such a Snapshot often provides
a useful reference in analyzing simulation results. Although such a Snapshot may be used as the
initial condition for future simulations with the same initial condition without repeating activity STRT,
the inclusion of activity STRT in each simulation run is strongly recommended because it provides
for:
1. A cross check for compatibility of the Snapshot and power flow Saved Case; and
2. The specification of a new Channel Output File; one common mistake in using such a Snap-
shot and omitting activity STRT in subsequent simulations occurs when neglecting to
21-24
Program Operation Manual Running a Simulation
change the Channel Output File, thus unintentionally overwriting the results of a previous
simulation.
The execution of activity STRT contributes only a small fraction of the total job time in a system
simulation; including activity STRT in each simulation to provide the checks described above is well
worth the investment. For operational and additional application details, refer to activity STRT and
Section 21.5.3 Simulation Initialization.
21-25
Running a Simulation Program Operation Manual
21.7.2 Applying Disturbances

The process of making dynamic simulation runs involves executing activity RUN. Activity RUN
starts from the present value of simulation TIME, and calculates the state of the system, advancing
TIME until it reaches the value specified as TPAUSE. TPAUSE is designated upon entering
activity RUN.
Activity STRT initializes the value of simulation TIME to minus two time steps. This provides for a
period of steady-state simulation prior to initiating any disturbance. This serves as a further check
on the formulation of the system model and the initial condition operating point, and produces a
corresponding flat segment at the beginning of plots generated by the Output Channel File
processing program, PSSPLT, executed following the completion of the simulation.
Thus, following an error-free execution of activity STRT, activity RUN should be selected with its
first TPAUSE set for TIME equals zero seconds. Some PSS®E users have adopted the practice of
routinely including a longer period of steady-state running in each simulation, typically to TIME
equal to 0.05 or 0.1 seconds.
System disturbances and switchings may be specified via activity ALTR, via the power flow data
editing spreadsheet, or via the functions accessible from the Disturbance menu entry in the
Dynamics spreadsheet view.
If activity ALTR is used, ALTR first allows the user to modify dynamics data (such as CON and ICON
values) and then gives the option of applying network changes. Network switching changes such
as fault application, fault clearance, and branch tripping may be applied either to the current working
case or to a new set of network data that is retrieved from a converted power flow Saved Case. A
reply of 1 (yes) to the question PICK UP NEW SAVE CASE? enables the user to specify the name
of a Saved Case File which is then brought into the working case. In this situation, the bus voltages
contained in working memory are preserved rather than being replaced by the voltages from the
Saved Case File.
The new Saved Case feature is useful in undoing the application of a fault or other disturbance by
returning directly to the predisturbance network data. It may also be used to establish an often used
complicated switching operation by imposing the switchings on the original converted case before-
hand and saving the resulting network in a Saved Case File. However, this application should be
used with great care in any simulations in which relays are active and hence machines, branches,
or loads may have been automatically tripped.
Furthermore, several PSS®E load characteristic models modify the load data arrays in the working
case during the execution of activity STRT. This, in turn, requires that any such Saved Case be
established following the execution of activity STRT when any of these types of simulation models
are being used. Therefore, the new Saved Case feature of activity ALTR should be used with
caution during a simulation run.
Activity CHNG is automatically entered and network switching operations may be applied in the
standard manner. Prior to running simulation, PSS®E will automatically run activity FACT (to set up
the admittance matrix temporary file) if needed. If FACT detects that a new ordering calculation is
required, activity ORDR is also automatically executed.
Three phase faults are applied in PSS®E by placing a large shunt susceptance at the faulted bus.
The typical value recommended is B = -2.E9 Mvar. This is usually large enough to drive the voltage
at the faulted bus to zero yet avoid floating point arithmetic underflow. Unbalanced bus faults are
simulated by adding the positive sequence equivalent fault admittance, as tabulated by activity
SCMU, to the bus shunt (see Section 10.6.8 Unbalance Condition Summary Report). Transmission
21-26
Program Operation Manual Running a Simulation
line unbalances are simulated by replacing the branch impedance, charging and line shunts of the
branch experiencing the unbalance with those tabulated by activity SPCB (see Section 10.13.5
Output of Activity SPCB).
The network data changes required to impose disturbances or switchings may also be implemented
by going to the network spreadsheet, and either making the appropriate changes on the spread-
sheet itself, or selecting the appropriate power flow activities. In either of these cases, PSS®E will
automatically run activity FACT if needed.
While the power flow linkage is in effect, power flow reporting activities such as POUT and GENS
may be executed to examine network conditions at that instant of the simulation. Note that, while
the power flow activities do recognize the basic load characteristics as implemented by
activity CONL, they do not have a knowledge of other boundary condition modeling as implemented
by load characteristic models. Thus, network modeling in a simulation such as loads modeled
beyond the level provided by the basic load characteristics or frequency sensitivity of loads and
network parameters shows as mismatches in power flow output reports. Any dc lines are correctly
reported.
During simulations, particularly while a fault is applied or the system voltages are generally
depressed, the network solution may fail to converge within the prescribed number of iterations. It
is also possible for convergence failure to result from the system reaching an unrealistic state of
stress which relay action in the physical system, which is unmodeled in the simulation, would not
allow.
Any convergence failure is reported with an appropriate message, including the final convergence
monitor line in the same form as is used in activities SOLV, MSLV, and TYSL. The simulation then
continues as if convergence had been achieved.
Convergence failure can often be corrected by decreasing the acceleration factor used and
increasing the number of iterations permitted during the network solution with activity ALTR. It is
advisable to observe the convergence monitor when the iteration is failing to converge and following
a change in acceleration.
21.7.3 Snapshots
Dynamic simulation working memory may be preserved in the form of a Snapshot which is placed
into a Snapshot File by activity SNAP. Among other data items, a Snapshot contains both the
constant parameters associated with the dynamic equipment models and those arrays which
specify the instantaneous condition of the equipment models. It does not, however, contain any
information pertaining to the electric network. As in power flow and fault analysis applications,
network data (i.e., the working case) is preserved in a Saved Case File.
Thus, a system dynamic model is completely specified by the combination of a Snapshot and its
corresponding power flow Saved Case. It is strongly recommended, particularly for the novice user
of PSS®E, that in the dynamic simulation portions of PSS®E Snapshots and Saved Cases be saved
and retrieved in coordinated pairs.
Note that although the Saved Case does not contain the elements of the factorized admittance
matrix, PSS®E will automatically execute activity FACT and generate the factored admittance
matrix, if needed, before a dynamic simulation is performed.
21-27
Procedural Summary Program Operation Manual

It is permissible in PSS®E to stop a simulation run and examine in detail the results to date, and
then restart the run from that point just as if it had not been interrupted. This is accomplished by first
recording the instantaneous state of the system in Snapshot and Saved Case form. PSS®E may
then be terminated and the Channel Output File of the simulation examined with the plot package
provided with PSS®E. The user should however be careful not to overwrite the original Snapshot
and Saved Case Files on which future simulations may be based.
To continue such an interrupted simulation, PSS®E is started up again, the Snapshot and Saved
Case files (which were preserved when the simulation was halted) are read, and the simulation is
then continued.
This preserving of mid-run conditions in a Snapshot and Saved Case is also useful for the case in
which alternative switching options at, say, three seconds into a simulation are to be compared. The
identical first part of the run need not be repeated.
In these applications, the user does need to exercise care with regard to the run’s Channel Output
File. The name of this file and its position pointer are preserved with the Snapshot. In either of the
above applications, care must be taken not to delete this file or otherwise modify its contents.
In the case of the comparison simulations described above, the user often wishes to retain the
Channel Output File for both of the simulations for future plotting. Upon completion of the first simu-
lation run, the Channel Output File containing its results should be copied into another file for
retention. The second of the comparison runs may then be commenced with its results placed into
the original Channel Output File.
Care must be taken with regards to power flow Saved Cases for any simulation setups using load
characteristic models. During the execution of activity STRT, these models modify the load arrays
contained in working memory. Therefore, the pre-STRT converted Saved Case should not be
overwritten by activity SAVE following execution of activity STRT. With such a system model,
successive STRTs are permitted because the pre-STRT load arrays are returned to their original
working case values prior to the simulation initialization calculations.
21.8 Procedural Summary

This section describes those procedures which are used frequently in the dynamic simulation
portion of PSS®E. Many of the operations are described in detail elsewhere in this manual and are
reviewed here for reference.
21.8.1 The Executable Run File

If the dynamic case has user models, the user dll (usually the dsusr.dll) has to be created. The user
dll will contain references to the user models and to any connection routines that may have been
generated as a result of running activity DYRE.
To create the user dll, the create usrdll program can be used. The create usrdll is GUI driven method
that allows users to compile the model source code and create the dll. An alternative way to create
the user dll is to use the CLOAD4 command which is run via the DOS prompt.
Any time a system model change is implemented by a change to either of the connection subroutine
files, the new versions must be compiled and the user dll file must be rebuilt by again running the
create usrdll tool or by running the CLOAD4 command. See Additional Resources for PSS®E,
Createusrdll.
21-28
Program Operation Manual Procedural Summary
21.8.2 The Converted Saved Case

The dynamic simulation activities require that the network in the working case be converted from its
power flow representation to the form required for dynamic simulations. The converted case may
initially be set up by:
1. Picking up the appropriate power flow case which must be solved to an acceptable
mismatch level. The solved unconverted case should be preserved in a Saved Case File.
2. Ensuring that the machine characteristic data MBASE, ZSORCE, XTRAN and GENTAP are
correctly specified for all in-service machines. These machine attributes are a part of the
power flow data that is kept with the Saved Case.
3. Converting the generator representation by executing activity CONG.
4. Converting the load representation by executing activity CONL. Selective load conversion
is accommodated by specifying the appropriate bus subsystem, area, zone, owner, or
basekV when invoking activity CONL.
5. Calculating the triangular factors of the system admittance matrix and storing them in the
admittance matrix temporary file by executing activity FACT.
6. Refining the voltage solution by executing activity TYSL.
7. Preserving the converted power flow case in a Saved Case File by executing activity SAVE.
This should not be the same Saved Case File in which the unconverted (i.e., power flow
style) Saved Case is located.
This procedure need be done only once for each initial condition operating point.
Note that the results of the conversion process of steps 3 and 4, and the refined network solution
of step 6 are reflected in the Saved Case of step 7. The triangular factors determined in step 5,
however, are located in the admittance matrix temporary file and are not in the Saved Case File.
21.8.3 Initial Model Setup

In constructing a new system model from source data, the following steps are used:
1. Set up the converted Saved Case as described in Section 21.8.2 The Converted Saved
Case.
2. Using the model data sheets for reference, prepare a Dynamics Data Input File in the form
given in Section 15.1.1 Dynamics Model Raw Data File Contents.
3. Initiate PSS®E
4. Retrieve the converted Saved Case with activity CASE.
5. Execute activity DYRE as described in Section 15.1.2 Operation of Activity DYRE. Specify
the filenames into which the CONEC and CONET subroutines are to be placed, making sure
not to overwrite existing files which the user wishes to retain. Specify starting addresses of
one for each of the general purpose storage arrays. Specify a filename to be used as a
compiling file.
21-29
6. Use the consistency check for plant models via GUI (available from Dynamics > Model main-
tenance…> Consistency Check) to check for modeling inconsistencies as described in
Section 15.7.6 Consistency Check. Resolve any error messages printed by activity DYRE
and the consistency check. If necessary, edit the Dynamics Data Input File as required and
repeat steps 3 through 6.
7. Preserve dynamics working memory in a Snapshot File by executing activity SNAP.
8. Exit PSS®E with activity STOP.
9. If any supplementary signal models are being used with one of the dc line models that is not
in the table-driven form, modify subroutines CONEC and CONET as detailed in
Section 21.4.4 Program Set-Up. Then compile the connection subroutines, and create the
user dll.
10. Verify any unchecked data using the procedures given in Section 21.5.2 Performance Veri-
fication. Correct erroneous data, and update the Snapshot created in (7) with activity SNAP.
21.8.4 Retrieving System Model Data

The converted network may be accessed, along with the Snapshot containing the system model
dynamics data, during subsequent dynamic simulation runs with the following steps:
1. Start up PSS®E.
2. Open the converted network.
3. Open the Snapshot file.
4. Run the simulation. It may be noted that if setting up the factored matrix (i.e., running activity
FACT) is not done by user, PSS®E will take care of doing this before running activities like
ASTR, STRT, RUN, MSTR, and MRUN. Setting up of the factored matrix is not required if
only activities such as DYRE, CHAN, DOCU, and MLST are to be executed.
21-30
Program Operation Manual Procedural Summary
21.8.5 Selecting Output Channels

To add the user’s selection of those system model variables to be monitored during simulation runs
to the dynamics data contained in the Snapshot, the following steps may be used:
1. Retrieve the system model data into working memory by the procedure given in
Section 21.8.4 Retrieving System Model Data.
2. Select activity CHAN and/or CHSB to designate those variables which are to be placed into
output channels. Specify the default starting addresses in the VAR, ICON, and output
channel arrays. See also Section 21.6 Simulation Outputs.
3. Preserve dynamics working memory, which now contains the output channel specification
arrays, by executing activity SNAP. The Snapshot File specified would normally be the
same one referenced in Step 7 of Section 21.8.3 Initial Model Setup and Step 3 of
21.8.6 Running a Simulation

With the system model constructed, the procedure used in executing dynamic simulation runs is as
follows:
1. Retrieve the system model data into working memory by the procedure given in
2. Initialize the dynamic models to correspond to the initial condition operating point with
activity STRT. Specify the name of the Channel Output File in response to the prompt from
activity STRT. Any error conditions should be reconciled before continuing with the simula-
tion (see also Section 21.5.3 Simulation Initialization).
3. Simulate a period of steady-state operation with activity RUN, specifying a TPAUSE of zero
(or 0.05 or 0.1) seconds.
4. Apply a disturbance or switching.
5. Execute activity RUN, specifying as TPAUSE the next switching time.
6. Repeat steps 4 and 5 for each switching operation.
7. Optionally, preserve the end of run system conditions by taking a Snapshot and Saved
Case.
21.8.7 Modifying the Network Model

A change in the initial condition operating point for a simulation run is handled by executing power
flow activities on the base case network condition from which the original converted Saved Case of
Section 21.8.2 The Converted Saved Case was constructed. Because this involves power flow
solutions, the unconverted case must be used. One procedure is as follows:
1. Initiate PSS®E, and retrieve the appropriate unconverted power flow Saved Case.
2. Set up and solve the power flow to represent the modified system condition, saving the
resulting network condition in a new Saved Case File with activity SAVE.
21-31
3. Set up and preserve the converted Saved Case as in Section 21.8.2 The Converted Saved
Case.
4. Retrieve the dynamic snapshot file.
5. If desired, add output channels. Then execute dynamic simulations as described in

Section 21.8.6 Running a Simulation.
This approach assumes that there are no dynamic modeling changes required to model the new
initial condition operating point. Changes to the dynamic model are described in the following
section.
21.8.8 Modifying the Dynamic Modeling

The majority of dynamic modeling changes fall into one of the following two categories:
1. A change to the constant parameters of a model for which the reference already exists.
2. The addition of a new model reference to an existing dynamics setup.
The first type of modeling change is straightforward and requires no modification of the model
connection table arrays or the connection subroutines. Working memory is setup as described in
Section 21.8.4 Retrieving System Model Data, and the appropriate data changes are entered on
the Dynamics spreadsheet, or with activities CCON, ALTR, or PSAS. Dynamics working memory,
with the modified data items, is then preserved with activity SNAP, either overwriting the original
Snapshot or in a new Snapshot File as appropriate.
The second type of modeling change requires the modification of the intelligence connecting
specific models to network elements: the model connection tables in the case of plant-related, load-
related, line relay models, auxiliary-signal models, FACTS device models, dc line models, switched
shunt models or the connection subroutines for models related to other network elements (see
Section 21.1.1 Program Structure). Furthermore, it may involve either adding a model for an equip-
ment item which was previously not modeled (e.g., adding a governor to a machine) or replacing
one model with another (e.g., changing an IEEET1 model to an SCRX).
The majority of plant-related, load-related, line relay, auxiliary-signal, FACTS, dc line, and switched
shunt models may be introduced into the dynamic simulation setup using the appropriate spread-
sheet in the Dynamics or Models tab.
All other models must be introduced via activity DYRE (plant-related, load-related, line relay, auxil-
iary-signal, FACTS, and dc line models may also be introduced in this manner). One way to do this
is to edit the original Dynamics Data Input File (or its current version as output by activity DYDA),
and reconstruct the entire dynamics setup. Alternatively, activity DYRE may be used in an add
models mode (see Section 15.1.3 Adding Models); the following approach may be used:
1. Prepare a Dynamics Data Input File in the form shown in Section 15.1.1 Dynamics Model
Raw Data File Contents. Only data records for the new models should be included.
2. Initiate PSS®E, and retrieve the data for the current system model into working memory as
described in Section 21.8.4 Retrieving System Model Data (step 4 may be omitted).
3. Run activity DYRE,ADD, specifying the file created in (1), and files into which the connection
subroutine calls are to be placed. They should not be the same files containing the CONEC
21-32
Program Operation Manual Advanced Uses of CONEC and CONET
and CONET subroutines for the current version of the system model. Specify the default
next available locations in the dynamics data general purpose storage arrays.
4. Preserve dynamics working memory as updated in (3) by executing activity SNAP.
If the changes in modeling included new model calls in subroutines CONEC, or CONET, the
following additional steps are required:
5. Terminate PSS®E.
6. Merge the CONEC and CONET model calls as generated in the above execution of
activity DYRE with the versions of these subroutines containing the rest of the system model
calls. If models are being replaced, the user must either delete or comment out the model
calls which were replaced so that the resulting connection subroutine contains the new call
and not the old reference.
7. Compile and link to create the user dll.
21.8.9 A Comment
The experienced user of the dynamic simulation activities of PSS®E will find that many of the proce-
dures described above, several of which may be required in a given application, may be combined
into a single operating procedure. This is perfectly valid and encouraged, but requires that the user
gain an understanding of, and be comfortable with:
1. The prerequisites of the various PSS®E activities involved.
2. The proper sequencing of these activities required for a given application.
3. The contents of working memory in the context of the recent sequencing of PSS®E
activities.
4. The relationship among the various files involved in the data handling and simulation phases
referenced above.
21.9 Advanced Uses of CONEC and CONET

As described in Section 21.4 The Dynamic Model, the connection subroutines CONEC and CONET
are a vital component of the system model. They are, however, simply FORTRAN subroutines and
the experienced
PSS®E user may add any desired code to them to handle a wide variety of simulation control and
modeling requirements.
This section describes some typical examples of user-written code in these subroutines. It is not
intended to be an all-encompassing treatment on the subject, but rather to suggest approaches that
might be used to meet specific requirements.
21.9.1 Manual Model Addition

The process of manually adding models to the connection subroutines involves filling out a model
sheet for each model to be added, incorporating the model CALL statement into the connection
subroutine(s), and entering the model’s constant data parameters into the PSS®E dynamics data
general purpose storage arrays. The procedure is illustrated by example.
21-33
Advanced Uses of CONEC and CONET Program Operation Manual
Suppose that in a simulation setup, the user wishes to place the branch flow exclusive of line
connected shunt elements for circuit 1 from bus 100 to bus 110 into output channels. The model
FLOW2 may be used to calculate these quantities and place them into VARs. The VARs may then
be assigned to output channels. The following procedure may be used:
1. Enter the constant parameters for the FLOW2 model on its data sheet in the Value column
of the ICON block (see Figure 21-2).
2. Start up PSS®E, restore the Snapshot containing the original simulation data and, using the
dialog for solution parameter changes (available from the GUI menu Dynamics>Simula-
tion>Solution Parameters…), note the next available locations in the ICON and VAR arrays
(FLOW2 does not use any CONs or STATEs). Assume that these are listed as 101 and 601
respectively.
3. Assign storage locations in the ICON and VAR arrays for the FLOW2 model. For the ICON
array, we assign locations starting at 101 (the next available location), and ending at 103
(i.e., I+2 from the data sheet). Similarly, in the VAR array, we assign locations 601 and 602
which will hold the MW and Mvar flow; the MVA flow is not needed so L will be set to zero.
The model call can now be written from the completely filled in model data sheet as:
CALL FLOW2 ( 101, 601, 602 0 )

At this point, the next available ICON and VAR indices are 104 and 603, respectively.
4. Modify the CONET subroutine by adding the FLOW2 model call listed in (3). Compile the
revised CONET subroutine and link it to create the user dll.
5. Initiate PSS®E and retrieve the original system model data as detailed in Section 21.8.4
Retrieving System Model Data.
6. From the GUI menu Dynamics>Simulation>Solution Parameters…, or using the solution

parameter changes of activity ALTR, update the next available location pointers for the
ICON and VAR arrays to correspond to the values determined at the end of step 3.
7. Referring to Figure 21-2, set the constant parameters for the new model by setting the ICON
values in the dynamics data spreadsheet for ICON, or with activity ALTR, or by executing an
appropriate Response File generated by the PSS®E simulation run assembler activity,
PSAS.
8. Using activity CHAN, assign VARs 601 and 602 to the next available output channels.
9. Preserve the modified dynamics data in Snapshot form with activity SNAP.
Models called from subroutines CONEC and CONET may be added either via activity DYRE,ADD
or using the approach described above. Refer to Section 21.1.1, Program Structure, Section 21.4.1,
Subroutines TBLCNC and CONEC, and Section 15.1.3, Adding Models. See also User-Written
Models.
The first use of any user-written plant-related, wind related, load-related, line relay, auxiliary signal,
FACTS device, dc line, and switched shunt models in a simulation setup must be added to it by
modifying the model connection table arrays through activity DYRE,ADD. Instances of plant-
related, wind related, load-related, line relay, auxiliary signal, FACTS device, dc line, and switched
shunt models contained in the PSS®E Model Library, or of user-written plant-related, wind related,
load related, line relay, auxiliary signal, FACTS device, dc line, and switched shunt models already
21-34
in use in the simulation setup, may be introduced either via activity DYRE,ADD or by using the
appropriate Dynamics spreadsheets.
21-35
FLOW2
Branch Flow Model
CALL FLOW2 (I,N,M,L) from CONET

This model ICONs starting with #_______ I.
It stores the real component of flow
#_______ N,
in VAR
the imaginary component in VAR #_______ M,
and the VA flow in VAR #_______ L
Flow is calculated out of the bus number contained in ICON(I).
N, M, and/or L may be zero to bypass storing of the respective
quantity
VARs # Description
N 601 MW
M 602 Mvar
L 0 MVA
ICONs # Value Description

I 101 100 from bus number
I+1 102 110 to bus number
I+2 103 1 Circuit identifier*
* Enter circuit identifier of -1 to sum flows of all parallel

circuits between the two buses.
Note: Flows do not include the line shunt components.

Model call must be manually inserted into subroutine
CONET after the IFLAG test and data must be entered.
Figure 21-2. Branch Flow Model
21-36
21.9.2 Accessing Machine and Load Data

There are a number of arrays in the PSS®E data structure containing machine variables. These are
identified in Table 21-1 Dynamic Simulation Arrays as being indexed by machine index. The
machine index for a given machine is an internal sequence number assigned by PSS®E to the
machine as it is introduced into the power flow case with activities READ, TREA, RDCH, or MCRE
(see Plant and Machine Sequence Numbers) or the machine data spreadsheet.
PSS®E includes the subroutine GENCHK which may be called by the user in subroutine CONEC
to determine the machine index of a given machine. Its calling sequence is:
CALL GENCHK (IBUS, 'I', K, 'string')
where:
IBUS Is the number of the bus.

I Is the machine identifier of the machine for which the index is to be found.
K Is returned as the machine index, or zero if the machine is not found.
string Is text which is included in any error message printed whenever GENCHK cannot
find the specified machine.
Suppose, for example, the user wished to calculate the accelerating power (ignoring stator losses)
in MW of machine one at bus 100 and place it in a VAR for monitoring during a series of simulation
runs. This could be accomplished as follows:
1. Start up PSS®E, restore the Snapshot containing the simulation data and, using the GUI
menu Dynamics>Simulation>Solution parameters…, note the next available location in the
VAR array. In this example, assume it is 714. The coding to be added to subroutine CONEC
will place the calculated quantity in this VAR. Change the next available VAR pointer to 715,
and then, with activity CHAN, assign VAR 714 to an output channel. Preserve these
changes by taking a Snapshot and terminate PSS®E.
2. Edit the source code of subroutine CONEC to include the following FORTRAN statements
just before the RETURN statement:
IF (MODE.NE.2) RETURN
CALL GENCHK ( 100, '1', II, 'IN CONEC' )
IF (II.EQ.0) RETURN
VAR(714) = PMECH(II)*MBASE(II) - PELEC(II)*SBASE
These calculations need be done only in MODE two, hence the logical IF statement. Note
that the PMECH array elements are in pu on machine base, and that the PELEC array
elements are in pu on system base. Thus, the calculated quantity is expressed in MW.
3. Compile the modified CONEC subroutine and create the user dll.
Table 21-1 Dynamic Simulation Arrays also identifies several arrays as being indexed by load index.
The load index for a given load is an internal sequence number assigned by PSS®E to the load.
PSS®E includes the subroutine LODCHK, which may be called by the user in subroutine CONET
to determine the load index of a given load. Its calling sequence is:
CALL LODCHK (IBUS, ’I’, K)
21-37
where:
IBUS Is the number of the bus.

I Is the load identifier of the load for which the index is to be found.
K Is the returned load index, or zero if the load is not found.
21.9.3 Getting Bus Sequence Numbers

PSS®E includes the subroutine BSSEQN which may be called by the user in subroutine CONEC
or CONET to determine the bus sequence number of a given bus. Its calling sequence is:
CALL BSSEQN (IBUS, I, *alt )
where:
IBUS Is the number of the bus for which the bus sequence number is to be found.
I Is returned as the bus sequence number; it is unchanged if the bus is not found.
alt Is the FORTRAN statement label to which BSSEQN returns if the bus is not found.
Suppose, for example, the user wished to convert the pu bus frequency deviation at a given bus to
bus frequency in Hertz. This involves a determination of the bus sequence number (see Bus
Sequence Numbers) corresponding to a given bus. The FLECS code fragment shown in Figure 21-
3, inserted before the RETURN statement in subroutine CONEC, determines the bus sequence
number of the bus for which the external number is contained in ICON 101, and stores the corre-
sponding bus frequency in VAR 401.
IF (MODE.GT.2) RETURN
C
WHEN (MODE.EQ.1 .OR. KPAUSE.EQ.2)
. IBUS=ICON(101)
. IS=0
. CALL BSSEQN( IBUS, IS, *10 )
10 . INTICN(101)=IS
...FIN
ELSE IS=INTICN(101)
C
WHEN (IS.EQ.0) VAR(401)=0.
ELSE
VAR(401)=60.*(1.+BSFREQ(IS))
Figure 21-3. Bus Frequency Example
This fragment of code takes advantage of the following points concerning the PSS®E data structure
and the logic sequence of activity RUN to execute efficiently:
1. It only needs to be executed when the value of the control variable MODE is one (initializa-
tion) or two (time derivative calculation following the network solution).
2. The array INTICN is indexed in the same manner as the array ICON and is available to the
PSS®E model writer (or, in this case, the CONEC twiddler) as a memory location. Its content
is preserved from one entry of subroutine CONEC to the next and in Snapshots.
21-38
3. The bus sequence number remains unchanged for a given execution of activity RUN. The
range of the WHEN block of the WHEN/ELSE construction looks up the bus sequence
number, IS, only during activity STRT (when MODE is one) and on the first time step deriv-
ative calculation following a pause (when KPAUSE is two). It stores it in INTICN 101 for use
during subsequent time steps.
This code provides for the case in which ICON 101 contains an invalid bus number or specifies a
bus not contained in the power flow working case; VAR 401 is set to zero in these cases. The user
may augment this logic to print an appropriate error message in this situation, writing to the logical
unit specified by the variable LPDEV.
An obvious extension of the coding in Figure 21-3 is to repeat the calculation for a group of buses.
Figure 21-4 shows this logic expanded to calculate the bus frequencies of the buses designated in
ICONs 101 through 105 and store them in VARs 401 through 405.
IF (MODE.GT.2) RETURN
C
IF (MODE.EQ.1 .OR. KPAUSE.EQ.2)
C .
. DO (INDXIC=101,105)
. . IBUS=ICON(INDXIC)
. . IS=0
. . CALL BSSEQN( IBUS, IS, *10 )
10 . . INTICN(INDXIC)=IS
. ...FIN
C .
...FIN
C
INDXVR=401
C
DO (INDXIC=101,105)
. IS=INTICN(INDXIC)
C .
. WHEN (IS.EQ.0) VAR(INDXVR)=0.
. ELSE VAR(INDXVR)=60.*(1.+BSFREQ(IS))
C .
. INDXVR=INDXVR+1
...FIN
Figure 21-4. Multiple Bus Frequency Example
21-39
Extended Term Simulations Program Operation Manual
21.9.4 Run Termination

Often in a simulation, it is desired to terminate the run based upon some system condition such as
a convergence failure of the network solution or the machine angle spread exceeding some
threshold. This is particularly useful for simulations executed in batch mode.
This example shows an approach for stopping a simulation upon convergence failure, with the
conditions at the point of termination preserved in Snapshot and Saved Case Files.
First, with the text editor create a Response File named stop.idv containing the following PSS®E
activity commands and responses:
snap,temp.snp
save,temp.sav
stop
Note: The blank line following the selection of activity SNAP activates the default response
for the number of elements to save field in activity SNAP. This sequence of commands
assumes that, if either of the files temp.snp or temp.sav already exists, PSS®E is being
operated in its file overwrite mode (see Section 3.3.3 Program Run-Time Option Settings).
Then, in subroutine CONET, insert the following statement after any relay and monitoring model
calls and immediately before statement label 9000:
IF (ITER.GT.ITMXDS) CALL UPAUSE('stop.idv')
The effect of this statement is to force a pause upon detection of convergence failure. Subsequent
dialog input is then taken from the Response File stop.idv, which causes a Snapshot and power flow
Saved Case to be written to the files temp.snp and temp.sav, respectively, and PSS®E to be
terminated.
The UPAUSE run termination routine (supplied with PSS®E) may be called from CONET as in the
above example; it may also be called from CONEC when the value of the variable MODE is three
(see Section 23.3 Model Requirements).
21.10 Extended Term Simulations

A class of dynamic simulation calculations termed extended term simulations is characterized by:
1. Simulation times ranging from many seconds to several minutes.
2. The need to model additional effects not normally considered in stability runs of several
seconds.
3. Significant periods of simulated time during which the higher frequency effects associated
with system disturbances have subsided.
While such simulations could be performed with the state-space simulation activities STRT and
RUN, this is usually not done because:
1. The user would need to develop code to model phenomena such as boiler effects, tap
changer and phase shifter action, and maximum excitation limiters.
2. Computer time requirements would be excessive.
21-40
Program Operation Manual Extended Term Simulations
3. The accumulation of round off errors after many thousands of time steps using explicit inte-
gration techniques may cause the simulation to drift.
The extended term simulation option of PSS®E provides a simulation calculation more suitable for
simulations of up to several minutes. It includes:
1. The augmentation of most equipment models containing state variables to include an

implicit integration algorithm for use in performing extended term simulations in addition to
the explicit integration technique used in state-space simulations.
2. The ability to change the simulation time step during the simulation.
3. Several additions to the PSS®E model library.
Synchronous machine models operate in one of three modes during extended term simulations:
1. A small time step mode, in which all state variables are handled in the same manner.
2. An intermediate time step or midterm dynamics mode in which the higher frequency modes
of the synchronous machine models GENROU, GENROE, GENSAL, GENSAE and
GENCLS have some extra damping.
3. A large time step or uniform island frequency mode in which, for each electrical island in the
system, an average frequency is determined and all machines in the island take on the
island frequency as their SPEEDs.
Two solution parameters are used to determine which of these three modes is being used: an inter-
mediate mode time step threshold (DLTBKW) and an island frequency time step threshold
(DLTEXT). The simulation time step (DELT) is compared to these threshold values and the simula-
tion mode is set to:
• Small time step mode if DELT < DLTBKW.

• Intermediate time step mode if DLTBKW < DELT < DLTEXT.
• Large time step mode if DELT > DLTEXT.
Default values of the time step thresholds are established when PSS®E is started up; they are set
as follows:
• DLTBKW = 3 cycles.
• DLTEXT = 7 cycles.
In the island frequency mode, a separate acceleration factor and convergence tolerance is applied
to the average island frequency calculation during the network solution. When PSS®E is started up,
these parameters are set to 1.0 and 0.0005 respectively. In this mode, the network solution iteration
continues until both the largest voltage change is below its convergence tolerance and the largest
machine angle change is below the island frequency mode convergence tolerance.
The time step thresholds, acceleration factor and convergence tolerance may be changed using
Dynamics>Simulation>Solution Parameters… in the GUI, or with activity ALTR and are preserved
with the Snapshot when it is saved with activity SNAP. Care must be taken in changing the time
step thresholds during an extended term simulation (see Section 15.23.1 Application Notes).
21-41
Creating and Viewing the Results of Dynamic Simulations Program Operation Manual
The state-space simulation activities utilize the following arrays in their second order explicit inte-
gration calculations:
STATE Contains the values of the state variables.

DSTATE Contains their time derivatives.
STORE Contains the integrator memory.
The extended term simulation activities use the Z-form expression of the trapezoidal integration
algorithm, an implicit integration algorithm (see the PSS®E Program Application Guide). The same
STORE array described above is used in extended term simulations; the STATE and DSTATE
arrays are not used in extended term simulations. In their place, the array STORMT, dimensioned
twice as large as the STATE array, is used.
Referring to the model data sheets, for each STATE allocated to a model reference, the following
entries in the above arrays are reserved:
State-Space Extended Term

STATE(K) STORE(K)
STORE(K) STORMT(2*K-1)
DSTATE(K) STORMT(2*K)
where K is the STATE number.
In PSS®E’s address space, the STORMT array occupies the same locations as the STATE and
DSTATE arrays. In state-space simulations, models do not reference their STORMT array
elements, and in extended term simulations, they do not reference their STATE and DSTATE array
elements.
Clearly, in extended term simulations, STATE values placed in output channels or tabulated with
activity DLST are not useful.
21.11 Creating and Viewing the Results of Dynamic Simulations

The channels captured during the Dynamic Simulation can be viewed and plotted directly from
within PSS®E. Multiple channel output files can be open simultaneously and the channels from
these multiple channel files combined on a single plot. Currently, the plotting functionality is only a
subset of the plotting capabilities found in PSS™PLT. In future releases, the full functionality of
PSS®PLT will be incorporated into PSS®E. Therefore, PSS®PLT is still installed and can be used
in the same manner as in previous releases of PSS®E.
21.11.1 General Workflow to View Dynamic Results

The results of Dynamic Simulations are the plot channels of various PSS®E quantities that are
selected prior to performing the Dynamic Simulation. The plot channels captured during any
Dynamic Simulation are contained in a plot channel output file which is in a binary form. The plotting
functions contained within PSS®E can be used to read these binary channel files and display the
plots.
In order to view the plots, a Plot Book has to be created. The Plot Book is configured like an Excel
Worksheet with multiple Plot Pages each capable of displaying several Plots. A Plot in turn can con-
21-42
Program Operation Manual Creating and Viewing the Results of Dynamic Simulations
tain several channels/curves/traces. A Plot Book by default will contain on Page with one Plot on
that Page.
After a Plot Book is created, a channel output file has to be opened. The channel output file will
appear in the Tree View, which, when expanded, will display all the channel outputs that were
selected prior to the Dynamic Simulation run.
Any channel output quantity can be viewed by dragging and dropping into the Plot Page.
21.11.2 Recording
Many of the interactions involved in creating and customizing the Plot Book are recordable and can
be played back through the use of Automation files. In future releases, most of the Plot Book inter-
actions will be recordable and available for playback.
®
PSS E GUI Users Guide, Section 23.1, Reproducing User Actions
21-43
This page intentionally left blank.
21-44
Chapter 22
Example Data Files
Chapter 22 - Example Data Files
22.1 SAVNW Case Data Input Files

SAVNW case comprises a simple power system network. It shows how to build a case in PSS®E
and the kind of data input required to study power flow, fault analysis and dynamic behavior of
power system network. A PSS®E File Planning Sheet is shown on next page.
These example files are available in the Example folder in the PSS®E product installation folder:
\\Program Files\PTI\PSSE33\EXAMPLE
22.2 Sample Case Data Input Files

Sample Case shows the capabilities of PSS®E in modelling of various power system components.
It depicts all the power system components that can be modelled in PSS®E, however it does not
represent a realistic power system configuration and therefore may not provide the most accurate
results as other analysis features available in PSS®E.
22-1
Example Data Files PSS®E 34.2
Sample Case Data Input Files Program Operation Manual
PSS®E File Planning Sheet
Name of Study:_SAVN W Case Directory Name:

\\Program Files\PTI\PSSE33\EXAMPLE
Filename Description
1. Power Flow Raw Data Files (input data, source)
a. __savnw.raw_____________________ _PSS®E savnw case_________________________
b. ______________________________ ________________________________________
2. Diagram Data Files (input data, source and/or binary)
a. __savnw.sld______________________ _O neline diagram .__________________________
b. ______________________________ ________________________________________
3. Dynamics Data Files (input data, source)
a. __savnw.dyr_____________________ _G EN RO U ,G EN SAL,TG O V1,H YG O V,IEEET1,__
b. ______________________________ _SCRX,SEXS____________________________
4. Power Flow Saved Case Files (saved case, binary)
a. __savnw.sav______________________ ________________________________________
b. __savcnv.sav_____________________ _Allloadsconverted to 100% C onstantIand B.______
c. ______________________________ _Allgeneratorsconverted using ZSO U RCE._________
d. ______________________________ ________________________________________
5. Simulation Snapshot Files (snapshot, binary)
a. __savnw.snp______________________ ________________________________________
b. ______________________________ ________________________________________
6. Sequence Data Files (input data, source)
a. __savnw.seq______________________ ________________________________________
b. ______________________________ ________________________________________
7. Optimal Power Flow Data Files (input data, source)
a. ______________________________ ________________________________________
b. ______________________________ ________________________________________
8. Other Auxiliary Files (input data, source)
a. __savnw.bkd_____________________ _G enerated using RW D Y.____________________
b. ______________________________ ________________________________________
c. ______________________________ ________________________________________
d. ______________________________ ________________________________________
9. Linear Network Analysis Data Files (input data, source)
a. __savnw.sub______________________ _ACC C files______________________________
b. __savnw.m on_____________________ ________________________________________
c. __savnw.con______________________ ________________________________________
d. ______________________________ ________________________________________
10. Channel Output Files (output, binary)
a. __savnw.out_____________________ ________________________________________
b. ______________________________ ________________________________________
11. CONEC and CONET Subroutine Files (FORTRAN, source)
a. __conec.flx______________________ ________________________________________
b. __conet.flx______________________ ________________________________________
22-2
Chapter 23
Model Writing
This chapter gives an introduction to the fundamentals of writing equipment models for use in the
Chapter 23 - Model Writing
dynamic simulation of PSS®E.
23.1 Background
The objective of dynamic simulations is to accurately simulate the response of a physical system to
some event. This, in turn, requires that each component affecting the response be faithfully
modeled over the time frame of interest. In PSS®E terms, this means that, for each equipment
being represented, a model which implements the differential equations describing the dynamic
behavior of the equipment must be supplied.
The PSS®E Model Library contains a wide variety of equipment models which satisfy this require-
ment for the vast majority of generating plant equipment. However, situations may arise in which
there is no library model which corresponds to the differential equations needed to model a given
piece of equipment. To handle this situation, engineers historically have tried to modify the data
characterizing the equipment to fit the block diagram of an existing model. Rather than resorting to
this approach, the PSS ® E user is encouraged to write a model that accurately models the
equipment.
The purpose of this section is to describe the basic approach to writing PSS®E models at the level
needed to get something working. It is not the all-encompassing treatment on the subject needed
to make the user a PSS®E model writing expert; that would require a book by itself. However, it
should allow the user to develop models for excitation systems, stabilizers, excitation limiters,
turbine governors and dc line supplementary signals which are not contained in the Model Library.
Models of other system components generally have a direct impact on the network balance portion
of the dynamic simulation calculation. This, in turn, requires a much more intimate familiarity with
the internal design of PSS®E than is necessary for these basic modeling functions. Section 23.9
Writing a Basic Load Model outlines the basic requirements of load-related models.
While the discussion here is limited to the categories of models listed above, the principles given in
this section apply to all types of PSS®E simulation models.
23.2 Prerequisites
Section 21.1 Simulation Overview gives an overview of the dynamic simulation process and the
dynamic simulation data structure as implemented in PSS ®E. It is recommended that all of
Chapter 18, particularly Section 18.1, be reviewed before continuing. Chapter 12 of the PSS®E
Program Application Guide also contains useful background material.
23-1
Model Writing PSS®E 34.2
Model Requirements Program Operation Manual
The remainder of this section assumes that the user:
1. Knows the physics of the equipment to be modeled or has been given the block diagram
and/or the differential and algebraic equations describing the equipment.
2. Has sufficient calculus and block diagram algebra background to transform the equations to
the form required of a PSS®E model.
3. Is familiar with the PSS®E data arrays given in Table 21-1 Dynamic Simulation Arrays.
4. Knows the FORTRAN programming language.
Before attempting to write any model, the user should first ensure that the modeling requirements
cannot be met by a standard library model; perhaps setting a gain to one or a time constant to zero
in an existing model reduces it to the required form.
23.3 Model Requirements

Having concluded that a new model is required, the user must gain an understanding of the require-
ments of PSS®E models. Each model must make different types of computations at different stages
in the dynamic simulation process.
A set of scalar variables which are present in PSS®E COMMON memory are used to communicate
between several of the PSS®E dynamic simulation activities and equipment models. The PSS®E
activities which invoke equipment models set seven flags before calling these modules. These flags
are the variables MODE, KPAUSE, MSTATE, MIDTRM, ITER, IFLAG and IBDOCU. Activities
STRT, RUN, MSTR and MRUN sense the variable KTRIP which must be set by any equipment
models that implement network data changes which affect the network admittance matrix.
At the most basic model writing level, the MODE flag is the most critical of these variables. In state-
space simulations the significance of MODE is as follows:
MODE=1 The model must initialize all of its state variables and algebraic variables. Prior to
the first network solution iteration (i.e., when the variable ITER is zero), load charac-
teristic models which are not coordinated call models (see Section 21.4.2
Subroutines TBLCNT and CONET) must set the initial values of any variables
needed in the current injection calculations of subsequent model calls issued during
network solution iterations.
MODE=2 The model must make all computations needed to place time derivatives into the
DSTATE array; each stabilizer model must compute the present value of its output
signal and place it in the appropriate entry in the VOTHSG array; each minimum
excitation limiter model must compute the present value of its output signal and
place it in the appropriate entry in the VUEL array; each maximum excitation limiter
model must compute the present value of its output signal and place it in the appro-
priate entry in the VOEL array.
23-2
PSS®E 34.2 Model Writing
Program Operation Manual Model Requirements
MODE=3 Each stabilizer model must compute the present value of its output signal and place
it in the appropriate entry in the VOTHSG array; each minimum excitation limiter
model must compute the present value of its output signal and place it in the appro-
priate entry in the VUEL array; each maximum excitation limiter model must
compute the present value of its output signal and place it in the appropriate entry in
the VOEL array; an excitation system model must compute the present value of
excitation system output voltage and place it in the EFD array; a turbine governor
model must compute the present value of turbine mechanical power and place it in
the PMECH array; other models written by users normally have no requirements in
MODE three.
MODE=4 The model must update the PSS®E variable NINTEG indicating the highest
numbered STATE being used. Load characteristic models which are coordinated
call models (see Section 21.4.2 Subroutines TBLCNT and CONET) must set the
initial values of any variables needed in the current injection calculations of subse-
quent model calls issued during network solution iterations. Other user-written
models normally have no other duties in MODE four.
MODE=5 The model is being called by activity DOCU in its reporting mode and must write out
the model data report.
MODE=6 The model is being called by activity DYDA and must write out the appropriate data
record.
MODE=7 The model is being called by activity DOCU in its data checking mode and must
perform appropriate model constant data checks; if any data exceptions are
detected they must be reported followed by the normal DOCU report.
MODE=8 The model is being called to return descriptions of each CON and ICON data input
value used by the model.
The variable KPAUSE is meaningful in MODEs one through four and indicates the type of time step
calculation being performed by activities RUN, MRUN, ERUN, or GRUN:
KPAUSE=0 Models are being called to make their normal time step calculations.
_
KPAUSE=1 Models are being called for the value of simulation TIME equal to TPAUSE , just
prior to a pause. Any models which perform local integrations or accumulations,
or which update local transport delay tables, should bypass these calculations.
KPAUSE=2 Models are being called at the first time step following a pause (i.e., for the same
value of simulation TIME as on the last time step calculation).
Most user-written models need not be sensitive to the variable KPAUSE.
The variable MSTATE is meaningful in MODEs one through four and indicates the type of simulation
being performed by activities STRT/RUN, MSTR/MRUN, ESTR/ERUN, GSTR/GRUN or ASTR:
MSTATE=0 Standard state-space dynamic simulation via activities STRT and RUN, or
activity ASTR.
MSTATE=1 Excitation system response ratio test via activities ESTR and ERUN. Models
other than generator and excitation system models are not called.
MSTATE=2 Excitation system open circuit step response test via activities ESTR and ERUN.
Models other than generator and excitation system models are not called.
MSTATE=3 Governor response test via activities GSTR and GRUN. Models other than
generator and turbine governor models are not called.
23-3
Model Requirements Program Operation Manual
MSTATE=4 Extended term dynamic simulation via activities MSTR and MRUN.
MSTATE=5 Dynamics data is present but no initialization activity has been successfully
executed.
The LOGICAL variable MIDTRM is meaningful in MODEs one through four and indicates whether
state-space or extended term simulations are being performed:
MIDTRM=.FALSE. State-space simulation.

MIDTRM=.TRUE. Extended term simulation.
The variable ITER is meaningful only in MODEs one and three during the network solution calcula-
tion, and it indicates the number of iterations completed during the network solution for the present
value of simulation time. It is usually sensed in MODE one by load characteristic models which are
not implemented as coordinated call models (see Section 21.4.2 Subroutines TBLCNT and
CONET) and which have initialization requirements which must be performed prior to any network
solution iterations (i.e., when ITER is zero).
23-4
Program Operation Manual Model Requirements
The variable IFLAG is meaningful only in MODEs one and three during the network solution calcu-
lation and is usually sensed by models called from subroutines TBLCNT and CONET. These
subroutines are called once each iteration, and once more following convergence of the network
solution. IFLAG indicates the status of the network solution calculation:
IFLAG=.FALSE. The network solution has not achieved convergence.

IFLAG=.TRUE. The network solution has converged or reached its maximum number of
iterations.
The variable IBDOCU is meaningful only in MODEs five through seven and indicates the mode of
operation of activities DOCU or DYDA:
IBDOCU=0 Process all models called.

IBDOCU>0 External bus number; only process models called at bus IBDOCU. Only
models called from subroutines CONEC or CONET need to sense IBDOCU.
The variable KTRIP, as well as the variable KPAUSE (see above), must be set by any equipment
model, or by user logic in CONEC or CONET, which imposes network switchings or other data
changes that require a dual time step calculation (i.e., one time step calculation before the switching
at TIME = t-, and another after the switching at TIME = t+). This may only be done when KPAUSE
is not 2. The model library subroutines which trip buses (i.e., BSDSCN), machines (i.e., GENTRP),
loads (e.g., LDSHxx), and branches (e.g., LINTRP) set KPAUSE and KTRIP as required, so that
user code needs to be concerned with setting these variables only when it changes PSS®E network
data array values directly. To force a dual time step calculation, KPAUSE must be set to 1 and
KTRIP to the appropriate non-zero value:
KTRIP=0 No dual time step calculation required.

KTRIP=1 In activities RUN and MRUN one or more data changes requiring a dual time step
calculation were implemented, but none of these affect the network admittance
matrix.
KTRIP=-1 In activities STRT and MSTR, one or more load models changed the value of the
constant admittance component of a load. In activities RUN and MRUN, one or
more data changes affecting the admittance matrix have been implemented; no
zero impedance line switchings were implemented.
KTRIP=-3 In activities RUN and MRUN, one or more data changes affecting the admittance
matrix have been implemented; at least one zero impedance line switching was
implemented.
When KTRIP of 1 (or -1) is required in RUN and MRUN, care must be taken to ensure that some
other model has not already set KTRIP to -1 (or -3). Therefore, the statement for setting KTRIP is
one of the following:
IF (KTRIP.EQ.0) KTRIP=1
IF (KTRIP.GE.0) KTRIP=-1
KTRIP=-3
23-5
Model Calling Sequence Rules Program Operation Manual
23.4 Model Calling Sequence Rules

When activity DYRE is used to introduce user-written models into a simulation setup, the corre-
sponding records in the Dynamics Data Input File are required to be in the format of the special
USRMDL, USRLOD, USRREL, USRAUX, USRFCT, and USRDCL records described in User-
Written Models. In addition, these models must be written so as to be compatible with the calling
sequences assumed when these models are called from subroutines TBLCNC, TBLCNT, CONEC
or CONET (see Section 21.1.1 Program Structure).
The SUBROUTINE statements for plant-related models must be of the form:
SUBROUTINE modelname (MC, ISLOT)
where:
MC Is the internal PSS®E machine array index for the machine at which the model is
being called.
ISLOT Is the internal PSS®E array allocation table index for this model call.
Using the notation of User-Written Models, at the completion of activity DYRE, the array allocation
table entries for each plant-related model reference are set as follows:
STRTIN(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
STRTIN(2,ISLOT) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
STRTIN(3,ISLOT) Contains the index of the first of NV VARs used by the model, or zero if
NV is zero.
STRTIN(4,ISLOT) Contains the index of the first of NI ICONs used by the model, or zero if NI
is zero.
The SUBROUTINE statements for load-related models must be of the form:
SUBROUTINE modelname (LD, ISLOT, ISLOT2)
where:
LD Is the internal PSS®E load array index for the load at which the model is being
called.
ISLOT Is the internal PSS®E array allocation table index for the shared data for this
model call.
ISLOT2 Is the internal PSS®E array allocation table index for the private data for this
model call.
table entries for each load-related model reference are set as follows:
LDSTRT(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
LDSTRT(2,ISLOT) Contains the index of the first of NI shared ICONs used by the model, or
zero if NI is zero.
23-6
Program Operation Manual Model Calling Sequence Rules
LDSTR2(1,ISLOT2) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
LDSTR2(2,ISLOT2) Contains the index of the first of NV VARs used by the model, or zero if
NV is zero.
LDSTR2(3,ISLOT2) Contains the index of the first of NRI reserved (i.e., private) ICONs used
by the model, or zero if NRI is zero.
The SUBROUTINE statements for line relay models must be of the form:
SUBROUTINE modelname (KM, RS, ISLOT)
where:
KM Is the internal PSS®E double entry line array index for the line at which the
model is being called.
RS Is the relay slot (1 or 2) as specified on the USRREL data record.
table entries for each line relay model reference are set as follows:
RLSTRT(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
RLSTRT(2,ISLOT) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
RLSTRT(3,ISLOT) Contains the index of the first of NV VARs used by the model, or zero if
NV is zero.
RLSTRT(4,ISLOT) Contains the index of the first of NI ICONs used by the model, or zero if NI
is zero.
The SUBROUTINE statements for auxiliary-signal models must be of the form:
SUBROUTINE modelname (IDVX, IDVT, ISGX, ISLOT)
where:
IDVX Is the device index (the device number in case of two-terminal dc line, multi-
terminal dc line and FACTS device, and the internal PSS®E array index in the
case of VSC dc line).
IDVT Is the device type with which the auxiliary-signal is associated:
1: for two-terminal dc line
2: for multi-terminal dc line
3: for VSC dc line
4: for FACTS device
23-7
ISGX Is the signal injection point number (or the auxiliary-signal index). This is any
number 1 through maximum number of auxiliary-signals that can be associated
with the device type under consideration (see Table 3-1 Standard Maximum
PSS®E Program Capacities for the maximum number of auxiliary-signals that
can be attached to each device type).
table entries for each auxiliary-signal model reference are set as follows:
STRTAU(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
STRTAU(2,ISLOT) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
STRTAU(3,ISLOT) Contains the index of the first of NV VARs used by the model, or zero if
NV is zero
STRTAU(4,ISLOT) Contains the index of the first of NI ICONs used by the model, or zero if NI
is zero.
The auxiliary-signal model output has to be calculated and stored in the first VAR location VAR(L)
where L is the starting VAR index for that auxiliary-signal model (i.e., L=STRTAU(3,ISLOT)). Subse-
quently, depending on the type of device with which the auxiliary-signal model is associated with,
the model output contained in VAR(L) is then transferred by PSS®E into one of the PSS®E standard
arrays, DC2SIG or DCMSIG or VSCSIG or FCTSIG. The array locations in DC2SIG, DCMSIG,
VSCSIG, and FCTSIG into which VAR(L) is transferred, corresponds to the device number (internal
VSC device index for VSC dc lines) and the signal index (i.e., the signal injection point number) for
which the auxiliary-signal model is called.
The SUBROUTINE statements for FACTS device models must be of the form:
SUBROUTINE modelname (IDVX, ISLOT)
where:
IDVX Is the device index.

table entries for each FACTS device model reference are set as follows:
STRTFC(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
STRTFC(2,ISLOT) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
STRTFC(3,ISLOT) Contains the index of the first of NV VARs used by the model, or zero if
NV is zero.
STRTFC(4,ISLOT) Contains the index of the first of NI ICONs used by the model, or zero if NI
is zero.
23-8
Program Operation Manual Model Calling Sequence Rules
The SUBROUTINE statements for dc line models (for all those dc line models that are called from
internal PSS®E tables) must be of the form:
SUBROUTINE modelname (IDVX, ISLOT)
where:
IDVX Is the device index.

table entries for each two-terminal dc line, multi-terminal dc line, and VSC dc line model reference
are set as follows.
Two-terminal dc line allocation tables:
STRT2D(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
STRT2D(2,ISLOT) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
STRT2D(3,ISLOT) Contains the index of the first of NV VARs used by the model, or zero if
NV is zero.
STRT2D(4,ISLOT) Contains the index of the first of NI ICONs used by the model, or zero if NI
is zero.
Multi-terminal dc line allocation tables:
STRTMD(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
STRTMD(2,ISLOT) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
STRTMD(3,ISLOT) Contains the index of the first of NV VARs used by the model, or zero if
NV is zero.
STRTMD(4,ISLOT) Contains the index of the first of NI ICONs used by the model, or zero if NI
is zero.
VSC dc line allocation tables:
STRTVS(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
STRTVS(2,ISLOT) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
STRTVS(3,ISLOT) Contains the index of the first of NV VARs used by the model, or zero if
NV is zero.
STRTVS(4,ISLOT) Contains the index of the first of NI ICONs used by the model, or zero if NI
is zero.
The SUBROUTINE statements for switched shunt models must be of the form:
SUBROUTINE modelname (IB, ISLOT)
23-9
where:
IB Is the internal bus sequence number.

table entries for each switched shunted device model reference are set as follows:
STRTSS(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
STRTSS(2,ISLOT) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
STRTSS(3,ISLOT) Contains the index of the first of NV VARs used by the model, or zero if
NV is zero.
STRTSS(4,ISLOT) Contains the index of the first of NI ICONs used by the model, or zero if NI
is zero.
The SUBROUTINE statements for induction machine models must be of the form:
SUBROUTINE modelname (IMC, ISLOT)
where:
IMC Is the internal PSS®E induction machine array index for the machine at
which the model is being called.
table entries for each induction machine model reference are set as follows:
STRTIM(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
STRTIM(2,ISLOT) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
STRTIM(3,ISLOT) Contains the index of the first of NV VARs used by the model, or zero if NV
is zero.
STRTIM(4,ISLOT) Contains the index of the first of NI ICONs used by the model, or zero if NI
is zero.
The SUBROUTINE statements for all the following models (collectively called the CCT models) -
the branch device and other models, two-winding transformer device and other models, three-
winding transformer device, protection and other models, bus protection and other models,
machine protection and other models, dc line (2-terminal, n-terminal and VSC dc) protection and
other models, FACTS device protection and other models, switched shunt protection and other
models, induction machine protection and other models, and the miscellaneous other models must
be of the form:
SUBROUTINE modelname (KM, ISLOT)
23-10
Program Operation Manual Writing the Basic Model
where:
KM For all CCT type models except the miscellaneous other model, KM is the
in-ternal PSS®E device of that device to which the CCT model is
attached.
In the case of miscellaneous other models, KM is the model instance of the miscellaneous other
model
table entries for CCT models are set as follows.
STRTCCT(1,ISLOT) Contains the index of the first of NC CONs used by the model, or zero if
NC is zero.
STRTCCT(2,ISLOT) Contains the index of the first of NS STATEs used by the model, or zero if
NS is zero.
STRTCCT(3,ISLOT) Contains the index of the first of NV VARs used by the model, or zero if NV
is zero.
STRTCCT(4,ISLOT) Contains the index of the first of NI ICONs used by the model, or zero if NI
is zero.
The CALL statements for the two-terminal dc line models that are not yet in a table-driven form (i.e.,
not called from internal PSS®E tables - CDCRL, CASEA1, CDCVUP, CEELRIT, CMDWS2T,
CMFORDT, CHIGATT, and CMDWAST), are generated as:
CALL modelname (IDC, I, J, K, L)
where IDC is the dc line number, and, again using the notation of User-Written Models:
I Is the index of the first of NI ICONs used by the model, or zero if NI is zero.
J Is the index of the first of NC CONs used by the model, or zero if NC is zero.
K Is the index of the first of NS STATEs used by the model, or zero if NS is zero.
L Is the index of the first of NV VARs used by the model, or zero if NV is zero.
For all other model categories (i.e., those that are not in any of the following categories: plant
related, load related, line-relay models, auxiliary-signal models, dc line models, and FACTS device
models), the CALL statements are generated as:
CALL modelname (I, J, K, L)
where I, J, K and L are as described above.
23.5 Writing the Basic Model

The steps in writing a PSS®E model are:
23-11
Writing the Basic Model Program Operation Manual
1. Determine the block diagram and/or the differential and algebraic equations of the equip-
ment to be modeled.
2. Identify the state variables associated with the model and determine a procedure for
computing their time derivatives.
3. Identify those quantities needed as inputs to the model.
4. Allocate locations in the CON, STATE, VAR and/or ICON arrays as required.
5. Write the model subroutine in FORTRAN or FLECS.
This procedure is best illustrated by an example. Consider the simple excitation system shown in
Figure 23-1. (Note that this example is for illustrative purposes only. In fact, this model is not likely
to be suitable for modeling any excitation system.)
Vref
+
1 – K E
EC  Efd
1 + sTr Esensed Verror 1 + sTe
0
+
Other Signals
Vothsg
Figure 23-1. Simple Excitation System
The first transfer function block of this model involves one state variable which is shown as Esensed,
the voltage transducer output. This transfer function gives the equation:
1
Esensed = × EC
1 + sTr
Cross multiplying and rearranging gives the required expression for the time derivative as:
dEsensed EC - Esensed
sEsensed = =
dt Tr
Similarly, for the second transfer function, the exciter:
K
E = × Verror
1 + sTe
23-12
resulting in:
dE K x V error - E
sE = =
dt Te
The limit block is a simple clip (windup limit) prohibiting a negative exciter output voltage. Note that,
because this is an excitation system model, the model output, Efd, must be placed in the EFD array
for use by the generator model.
We may now allocate memory locations in the various dynamics data arrays (refer to Table 21-1
Dynamic Simulation Arrays).
Model inputs:
ECOMP(I) Ec, the compensated voltage input

VOTHSG(I) Vothsg, a possible supplementary input signal from a stabilizer model
Model outputs:
EFD(I) Efd, the excitation system output voltage
Other model variables:
CON(J) = Tr VREF(I) = Vref

CON(J+1) = K STATE(K) = Esensed
CON(J+2) = Te STATE(K+1) = E
Verror may be treated as a local variable in our model subroutine because its value need not be
preserved from one time step to the next. The model writer could elect to assign such a quantity to
a VAR if it is desired to place it in an output channel.
Thus, our model requires three CONs (J through J+2), two STATEs (K and K+1), and no VARs or
ICONs. The index I shown above is the machine array index assigned to the machine at which the
model is to be called.
Following the model calling conventions of PSS®E plant-related models (see Section 23.4 Model
Calling Sequence Rules), the CALL statement for this model will be:
CALL DEMOEX ( I, ISLOT )
23-13
The model subroutine may now be written. In MODEs one through four, the bus sequence number
must be determined. If the machine is off-line, or the generator model at the machine is either a
static VAR system, an induction machine, a DSMES, CSMES battery energy storage CBES, or a
static condenser CSTATT, (none of which allow excitation systems), the model does no further
calculations. The starting array indices in the CON and STATE arrays for use in this model call are
determined. The coding is:
C
C BUS SEQUENCE NUMBER NEGATIVE IF MACHINE
C IS OFF-LINE, SVS OR INDUCTION MACHINE
C
IB=NUMTRM(I)
IF (IB.LE.0) RETURN
C
C GET STARTING 'CON' AND 'STATE' INDICES
C
J=STRTIN(1,ISLOT)
K=STRTIN(2,ISLOT)
In the above code fragment, I is the machine array index and IB is the bus sequence number at
which machine I is connected (see Bus Sequence Numbers and Plant and Machine Sequence
Numbers).
In MODE one, the model must initialize its STATEs, along with its entry in the VREF array. (The
values of EFD and ECOMP are initialized by the generator model prior to entering an excitation
system model, and VOTHSG is initialized by activity STRT before any stabilizer models are called.)
This initialization is done on the basis of known model input and output values, and the assumption
that time derivatives of all STATE variables are zero:
STATE(K)=ECOMP(I)
STATE(K+1)=EFD(I)
VREF(I)=ECOMP(I) + EFD(I)/CON(J+1)
It is advisable to alarm if the STATE variable E is initialized outside of its permissible range. The
quantities written out are the external identifiers (bus number and machine identifier) which are
indexed by variables which were described above:
IF (EFD(I).LT.0.) WRITE(LPDEV,307) NUMBUS(IB),MACHID(I)

307 FORMAT(' DEMOEX AT BUS',I6,' MACHINE ',A,
* ' INITIALIZED OUT OF LIMITS')
In MODE two, the model must calculate the values of the time derivatives as derived above:
DSTATE(K)=(ECOMP(I)-STATE(K))/CON(J)
VERROR=VREF(I)+VOTHSG(I)-STATE(K)
DSTATE(K+1)=(CON(J+1)*VERROR-STATE(K+1))/CON(J+2)
In MODE three, the model must transfer the STATE variable E into the EFD array with the appro-
priate clipping:
EFD(I)=MAX(STATE(K+1),0.)
23-14
In MODE four, the model must update NINTEG if the highest numbered STATE which it uses is
greater than the present value of NINTEG:
NINTEG=MAX(NINTEG,K+1)
MODE's five through six handle the model's responsibilities during activities DOCU and DYDA. In
activities DOCU and DYDA, all model output should be written to the FORTRAN unit number
contained in the variable IPRT. In MODE eight, definitions of CON and ICON input values are placed
in the arrays CON_DSCRPT and ICON_DSCRPT, respectively.
The complete basic model subroutine may now be assembled from the above code fragments as
shown in Figure 23-3. This code references the FLECS procedure shown in Figure 23-5, which has
to be inserted just before the END statement of Figure 23-3.
The following points on this model coding should be noted.
1. The file specified in the INCLUDE statement provides access to the main PSS®E data
arrays and COMMON variables. This syntax can be used for model source codes written in
FLECS as well as pure FORTRAN.
The ’I’ of the INCLUDE is in Column 7 for both FLECS and FORTRAN models.
2. The code in Figure 23-3 contains declaration of FORTRAN intrinsic functions, EXTERNAL
subprogram declarations, and type declaration for local variables.
3. This model has not as yet been coded for use in extended term simulations (see
Section 23.9 Writing a Basic Load Model). When MIDTRM is.TRUE., activity MSTR is being
executed; the model calls BADMID which prints an appropriate message and sets a flag
which does not allow activity MRUN to be executed. The model then RETURNs.
The three arguments of subroutine BADMID are the machine array index, the bus
sequence number, and the model name enclosed in single quotes. It is used in plant-
related models which have not been written for use in extended term simulations.
A similar subroutine, BADMDL, is used in load-related models which have not been
expanded for use in extended term simulations. Its three arguments are the load array
index, the bus sequence number, and the model name enclosed in single quotes.
Finally, a subroutine, BADMD2, is used in all other models which have not been expanded
for use in extended term simulations. It has a single argument: the model name enclosed
in single quotes.
4. Any error or progress report messages written in MODEs one through four should be written
to the FORTRAN unit number specified by the variable LPDEV.
5. When this model is used at a machine, the output signal of any excitation limiter model
called at the machine is ignored. Some excitation system models use the sum:
6. VOTHSG(I) + VUEL(I) + VOEL(I)
7. as their single supplementary signal input.
8. ISLOT is undefined in MODE eight. Hence the code for MODE eight appears before the use
of ISLOT.
23-15
SUBROUTINE DEMOEX(I,ISLOT)
C
INCLUDE ’COMON4.INS’
C
INTEGER I,ISLOT
C
C I = MACHINE ARRAY INDEX
C ISLOT = ARRAY ALLOCATION TABLE INDEX
C J = STRTIN(1,ISLOT) [ USES CON(J) THROUGH CON(J+2)
]
C K = STRTIN(2,ISLOT) [ USES STATE(K) AND STATE(K+1)
]
C
INTRINSIC MAX, ABS
EXTERNAL BADMID, DOCUHD
C
INTEGER IB, J, K, IBUS, JJ
REAL VERROR
LOGICAL NEW
CHARACTER IM*2
C
IF (MODE.EQ.8)
. CON_DSCRPT(1)='Tr'
. CON_DSCRPT(2)='K'
. CON_DSCRPT(3)='Te'
. RETURN
...FIN
C
C GET STARTING 'CON' AND 'STATE' INDICES
C
J=STRTIN(1,ISLOT)
K=STRTIN(2,ISLOT)
C
IF (MODE .GT. 4) GO TO 1000
C
C BUS SEQUENCE NUMBER NEGATIVE IF MACHINE
C IS OFF-LINE, SVS OR INDUCTION MACHINE
C
IB=NUMTRM(I)
IF (IB.LE.0) RETURN
C
IF (MIDTRM) GO TO 900
GO TO (100,200,300,400), MODE
C
C MODE = 1 - INITIALIZE
C
Figure 23-2. Basic DEMOEX Model Routine (Part 1)
23-16
100 STATE(K)=ECOMP(I)
STATE(K+1)=EFD(I)
VREF(I)=ECOMP(I) + EFD(I)/CON(J+1)
IF (EFD(I).LT.0.) WRITE(LPDEV,307) NUMBUS(IB),MACHID(I)
RETURN
C
C MODE = 2 - CALCULATE DERIVATIVES
C
200 DSTATE(K)=(ECOMP(I)-STATE(K))/CON(J)
VERROR=VREF(I)+VOTHSG(I)-STATE(K)
DSTATE(K+1)=(CON(J+1)*VERROR-STATE(K+1))/CON(J+2)
RETURN
C
C MODE = 3 - SET EFD
C
300 EFD(I)=MAX(STATE(K+1),0.)
RETURN
C
C MODE = 4 - SET NINTEG
C
400 NINTEG=MAX(NINTEG,K+1)
RETURN
C
C MODE > 4
C
1000 IM=MACHID(I)
IB=ABS(NUMTRM(I))
IBUS=NUMBUS(IB)
C
IF (MODE.EQ.6) GO TO 2000
C
C MODE = 5 OR 7--ACTIVITY DOCU
C
IF (MODE.EQ.5)
. CALL DOCUHD(*1900)
. GO TO 1100
...FIN
C
C DATA CHECKING CODE
C
NEW=.FALSE.
C
UNLESS (CON(J).GT.2.*DELT .AND. CON(J).LT.0.2)
. PRINT-HEADING
. WRITE(IPRT,107) CON(J)
...FIN
C
UNLESS (NEW) RETURN
C
C DATA TABULATION CODE
23-17
Model Writing Notes Program Operation Manual
C
1100 JJ=J+2
WRITE(IPRT,17) IBUS,IM,J,JJ,K,K+1
WRITE(IPRT,27) (CON(K),K=J,JJ)
1900 RETURN
C
C MODE = 6--ACTIVITY DYDA
C
2000 WRITE(IPRT,507) IBUS,IM,(CON(K),K=J,J+2)
RETURN
C
900 CALL BADMID(I, IB, 'DEMOEX')
C
17 FORMAT(//6X,'** DEMOEX ** BUS MACH C O N S S T A T E S'/
* I23,3X,A2,3X,2(I7,'-',I6))
27 FORMAT(/21X,'TR K TE'/F24.3,F8.1,F8.3)
37 FORMAT(' DEMOEX AT BUS' I7,' MACHINE ',A,
* ' INITIALIZED OUT OF LIMITS')
97 FORMAT(//' BUS',I7,' MACHINE ',A,':')
107 FORMAT(' TR=',F10.4)
507 FORMAT(I7,' ''DEMOEX''',2X,A,1X,3G13.5,'/')
END
TO PRINT-HEADING
C .
. UNLESS (NEW)
. . NEW=.TRUE.
. . CALL DOCUHD(*1900)
. . WRITE(IPRT,97) IBUS,IM
. ...FIN
C .
...FIN
Figure 23-5. FLECS Procedure
23.6 Model Writing Notes

To incorporate a model into a dynamics setup after it has been written, compile the model along with
the CONEC and CONET files (if any) and create a dll (typically the dsusr.dll).
Activity DYRE recognizes user-written models and processes them correctly only if:
1. They are specified on the special USRMDL, USRLOD, USRREL, USRAUX, USRFCT, and
USRDCL data records in the Dynamics Data Input File (see User-Written Models).
and
2. They are written assuming the subroutine calling sequences given in Section 23.4 Model
Calling Sequence Rules.
23-18
Program Operation Manual Model Writing Notes
The model developed in Section 23.5 Writing the Basic Model was written with the calling sequence
required for plant-related models. The corresponding DYRE data record might be:
101 'USRMDL' 1 'DEMOEX' 4 0 0 3 2 0 0.05 100. 0.4 /
User-written models for generating plant equipment, load characteristics and relays, line relays,
auxiliary-signal, FACTS devices, and dc lines must be written so as to be compatible with the
USRMDL, USRLOD, USRREL, USRAUX, USRFCT, and USRDCL data records, respectively,
given in User-Written Models. It is strongly recommended that other equipment models also be
compatible with the USRMDL data record requirements; however, user-written models for nonplant
equipment which do not conform to the above constraints may be introduced into a simulation using
the approach described in Section 21.9.1 Manual Model Addition.
While the excitation system model developed in Section 23.5 Writing the Basic Model was required
to initialize an entry in the VREF array, turbine governor, stabilizer and excitation limiter models
have no initialization duties other than initializing their own STATEs and VARs.
Plant-related models use the approach shown in the previous example to obtain machine and bus
array indices.
For user-written cross-compound governor models (i.e., IC is eleven on the USRMDL data record),
the machine index of the low pressure unit is obtained as in the following example:
I2=IBITS(MACNUM(ISLOT),16,16)
where IBITS is the FORTRAN intrinsic function for extracting a sequence of bits, and ISLOT is the
second argument of the model’s SUBROUTINE statement as in the DEMOEX model.
The DEMOEX model is written under the assumption that all of its constant parameters have
nonzero values. If a constant is allowed to be zero, care must be taken in the model to avoid division
by that constant. A common case is the transfer function of a transducer such as the first STATE in
the DEMOEX model.
23-19
Model Writing Notes Program Operation Manual
If Tr is allowed to be zero, statement 200 and the statement following would be replaced by the
following code fragment:
200 IF (CON(J).GT.2.*DELT) GO TO 210

STATE(K)=ECOMP(I)
STORE(K)=ECOMP(I)
GO TO 220
210 DSTATE(K)=(ECOMP(I)-STATE(K))/CON(J)
220 VERROR=VREF(I)+VOTHSG(I)-STATE(K)
This is somewhat more general in that the IF statement checks for a small time constant and makes
the transfer function algebraic if the time constant is less than two time steps. This approach
reduces the risk of numerical integration instability. This coding technique is recommended when-
ever transfer functions are likely to be characterized by small time constants.
The proper handling of limits is critical to the accurate modeling of equipment. Generally, there are
two types of limits:
1. A clip (or a windup limit). The STATE variable may be driven beyond its limits, but the value
used downstream is the limited value.
2. A hard limit on the transfer function (or a limit without windup). The STATE variable itself is
limited and its time derivative is not allowed to drive it beyond its limit.
Both types of limits occur in practice and the user must determine which is appropriate in a given
situation.
The limit in the DEMOEX model is a clip. To model it as a limit without windup, the MODE three
calculation at statement 300 should be changed to:
300 IF (STATE(K+1).LT.0.) STATE(K+1)=0.

EFD(I)=STATE(K+1)
In addition, after calculating DSTATE(K+1) and before the RETURN statement in MODE two, the
following statements should be added:
IF (STATE(K+1).GT.0.) RETURN
STORE(K+1)=0.
IF (DSTATE(K+1).LT.0.) DSTATE(K+1)=0.
Note that the output of a transfer function block must be limited before it is used in any calculations.
This is the case in our example because STATE(K+1) is limited in MODE three; recall that at each
simulation time step, MODE three calculations are done first, followed by the network solution and
then the MODE two calls of subroutines CONEC and TBLCNC.
The data checking code shown in Figure 23-3 requires that CON(J) (i.e., Tr) be greater than two
simulation time steps and less than 0.2 seconds. Otherwise, Tr is tabulated along with the standard
activity DOCU report of the model. The remaining model constants would be checked using similar
UNLESS blocks.
23-20
Program Operation Manual Extended Term Simulation
Coding such as that shown in this example is suitable for all plant-related models. Models called
from subroutines CONEC and CONET are handled in essentially the same manner but have two
additional duties in activities DOCU and DYDA:
1. The model must determine if selective mode is active, and if so, if it should do anything or
simply RETURN. The following code fragment, assuming a bus type model, with the bus
number contained in ICON(I), handles this function:
IF (IBDOCU.GT.0)
. IF (ICON(I).NE.IBDOCU) RETURN
...FIN
2. For line type models, it becomes a little more complicated. In activity DOCU, both ends of
the branch need to be looked at and, if either is equal to IBDOCU, the model should act. In
activity DYDA, however, only one end (e.g., the from bus of an ac branch) should be
checked so that the record appears only once in the output.
3. In activity DYDA, the model must check for the AB interrupt code before writing its output
record. Code such as in the following code fragment must be inserted before the first execut-
able statement:
CHARACTER IVEC(1)*2
SAVE IVEC
DATA IVEC/'AB'/
Then the following code is needed immediately preceding the activity DYDA WRITE state-
ment:
CALL CONINT(IVEC,1,JJ)
IF (JJ.NE.0) RETURN
23.7 Extended Term Simulation

The differential equation treatment shown in the above example illustrates that required for the
state-space explicit integration method used in the STRT/RUN, ESTR/ERUN and GSTR/GRUN
activity sequences. Additional model coding for the Z-form trapezoidal integration is required before
using the extended term simulation MSTR/MRUN activity sequence; details are given in the PSS®E
Program Application Guide.
It is strongly recommended that models first be developed, tested and used with activities STRT
and RUN using the modeling techniques described in this section. For users with the Extended
Term Simulation Section of PSS ® E, the model should be augmented to be valid with
activities MSTR and MRUN only after accurate modeling has been achieved with activities STRT
and RUN.
23.8 Coordinated Call Models

Many equipment models are called during the network solution to calculate current injections which
are dependent on the voltage at the bus to which they are connected. Models that contain both
differential equation responsibilities and current injection responsibilities meet their modeling
requirements in PSS®E by being implemented as coordinated call models. Such a model is called
from subroutine TBLCNC or CONEC (see Section 21.4.1 Subroutines TBLCNC and CONEC) for
calculations related to its differential equations, and from subroutine TBLCNT or CONET (see
Section 21.4.2 Subroutines TBLCNT and CONET) for current injection calculations. Models for
23-21
Writing a Basic Load Model Program Operation Manual
equipment such as static Var systems, dc lines, FACTS devices, and loads are usually implemented
as coordinated call models (see activity DYRE).
In a coordinated call model, the model is called at its primary entry point (i.e., the name specified
on its Dynamics Data Input File data record and on the model’s SUBROUTINE statement) for the
standard MODE one through four state variable calculations. The model is also called at a supple-
mentary entry point at each iteration of the network solution to inject the model’s contribution into
the CURNT array, and once more following network solution convergence for any post-solution
housekeeping required (e.g., updating one or more of the model’s VARs). The supplementary
ENTRY point name of a coordinated call model is formed by replacing the first character of the
SUBROUTINE name with a T. Clearly, coordinated call models, both those from the PSS®E Model
Library as well as user-written models, must have their primary entry point name beginning with a
character other than T.
23.9 Writing a Basic Load Model

A user-written load model must be written as a coordinated call model (see Section 23.8 Coordi-
nated Call Models). The fundamental steps in writing such a model are identical to those outlined
in Section 23.5 Writing the Basic Model. The primary entry point is written using an approach similar
to that used for DEMOEX earlier in this chapter.
A simple example is used to illustrate the procedure. Consider a load model which is to apply the
same frequency sensitivity factor to the three standard load characteristics (see Section 6.3.13
Load). If PQ is the total complex load (i.e., the sum of the three characteristics) at the present value
of voltage, the frequency sensitive load is calculated as: PQ * (1. + K * pu frequency deviation).
We may now allocate memory locations in the various dynamics data arrays (refer to Table 21-1
Dynamic Simulation Arrays).
Model inputs:
VOLT(IB) the complex voltage at bus IB

BSFREQ(IB) pu frequency deviation at bus IB
Model outputs:
CURNT(IB) complex current injection array used during the network solution
TPLOAD(I) effective MW load
TQLOAD(I) effective Mvar load
Other model variables:
CON(J) K, the frequency sensitivity factor

CLODFR(1,I) complex nominal constant MVA load at load I
CLODFR(2,I) complex nominal constant current load at load I
CLODFR(3,I) complex nominal constant admittance load at load I
Thus, our model requires one CON (J), and no STATEs, VARs or ICONs. The index I shown above
is the index array index assigned to the load at which the model is to be called, and the index IB is
the bus sequence number of the bus to which the load is connected.
23-22
Program Operation Manual Writing a Basic Load Model
Following the model naming and calling conventions of PSS®E load-related models (see Load-
Related Models and Section 23.4 Model Calling Sequence Rules), the CALL statement for this
model will be:
CALL DEMOBL ( I, ISLOT, ISLOT2 )
The model subroutine may now be written. Because no state variables are involved and no special
initialization calculations are required (the initial condition bus frequency deviation is zero), no
calculations are required in MODEs one through four of the model’s primary entry point and no
special coding is required for handling extended term simulations (see Section 23.7 Extended Term
Simulation).
23-23
In the model’s supplementary entry point, the bus sequence number must be determined. If the load
is out-of-service, the model does no further calculations. The starting array index in the CON array
for use in this model call is determined. The coding is:
C
C BUS SEQUENCE NUMBER NEGATIVE IF LOAD IS OUT-OF-SERVICE
C
IB=NUMLOD(I)
IF (IB.LE.0) RETURN
C
C GET STARTING 'CON' INDEX
C
J=LDSTRT(1,ISLOT)
In the above code fragment, I is the load array index and IB is the bus sequence number at which
load I is connected (see Bus Sequence Numbers).
In load characteristic models, it is important to recognize that the network solution subroutine SITER
has already made an injection into the CURNT array corresponding to the values present in the
standard load characteristic array CLODFR. It is the model’s responsibility, therefore, to inject the
difference between the total load as calculated by the model and the standard load characteristic
already injected. This may be done either by injecting the incremental amount, or by first making an
injection to cancel out the standard injection from CURNT and then injecting the new total load
model injection.
The following code fragment calculates the total load injected by SITER expressed in MVA
(PQOLD), and the total effective load as corrected for frequency sensitivity (PQNEW). It places the
active and reactive components of the effective load into the TPLOAD and TQLOAD arrays, respec-
tively. Finally, it injects the load increment into the CURNT array. The coding is:
C
C CALCULATE TOTAL LOAD FOR STANDARD CHARACTERISTICS
C
VM=ABS(VOLT(IB))
C
PQOLD=CLODFR(1,I)
IF (VM.LT.PQBRAK) PQOLD=PQOLD*CNSTPQ(VM)
C
S=VM*CLODFR(2,I)
IF (VM.LT.0.5) S=S*CNSTCR(VM)
PQOLD=PQOLD+S
C
PQOLD=PQOLD + VM*VM*CONJG(CLODFR(3,I))
C
C CALCULATED DESIRED TOTAL LOAD INJECTION
C
PQNEW=PQOLD*(1.+CON(J)*BSFREQ(IB))
C
TPLOAD(I)=REAL (PQNEW)
TQLOAD(I)=AIMAG(PQNEW)
C
C INJECT LOAD INCREMENT (MODEL INJECTION - STANDARD INJECTION)
23-24
Program Operation Manual Writing a Basic Load Model
C
CURNT(IB)=CURNT(IB)-CONJG((PQNEW-PQOLD)/VOLT(IB))
The complete basic model subroutine may now be assembled from the above code fragments as
Augmenting the model to handle the requirements of MODEs five through eight follows the
approach as outlined for plant-related models (see Figure 23-3), except that the LOADID and
NUMLOD arrays are used in place of the MACHID and NUMTRM arrays.
23-25
SUBROUTINE DEMOBL(I,ISLOT,ISLOT2)
C
INCLUDE 'COMONFOR.INS'
C
INTEGER I,ISLOT,ISLOT2
C
C I = LOAD ARRAY INDEX
C ISLOT = SHARED DATA ARRAY ALLOCATION TABLE INDEX
C ISLOT2 = PRIVATE DATA ARRAY ALLOCATION TABLE INDEX
C
C DO NOTHING IN 'DOCU', 'DYDA', 'ADD/EDIT CONSTANTS' FUNCTIONS FOR NOW
C
REAL CNSTCR, CNSTPQ
EXTERNAL CNSTCR, CNSTPQ
C
INTRINSIC ABS, AIMAG, CONJG, REAL
C
INTEGER IB, J
REAL VM
COMPLEX PQNEW, PQOLD, S
C
IF (MODE.GE.4) RETURN
C
C NO STATE VARIABLE CODE NEEDED IN MODES 1 THROUGH 4
C
RETURN
C
C SUPPLEMENTARY ENTRY POINT
C
ENTRY TEMOBL(I,ISLOT,ISLOT2)
C
C BUS SEQUENCE NUMBER NEGATIVE IF LOAD IS OUT-OF-SERVICE
C
IB=NUMLOD(I)
IF (IB.LE.0) RETURN
C
C GET STARTING 'CON' INDEX|
C
J=LDSTRT(1,ISLOT)
C
C CALCULATE TOTAL LOAD FOR STANDARD CHARACTERISTICS
C
VM=ABS(VOLT(IB))
C
PQOLD=CLODFR(1,I)
IF (VM.LT.PQBRAK) PQOLD=PQOLD*CNSTPQ(VM)
C
S=VM*CLODFR(2,I)
IF (VM.LT.0.5) S=S*CNSTCR(VM)
PQOLD=PQOLD+S
C
PQOLD=PQOLD + VM*VM*CONJG(CLODFR(3,I))
C
C CALCULATED DESIRED TOTAL LOAD INJECTION
C
PQNEW=PQOLD*(1.+CON(J)*BSFREQ(IB))
C
TPLOAD(I)=REAL (PQNEW)
TQLOAD(I)=AIMAG(PQNEW)
C
C INJECT LOAD INCREMENT (MODEL INJECTION - STANDARD INJECTION)
C
CURNT(IB)=CURNT(IB)-CONJG((PQNEW-PQOLD)/VOLT(IB))
C
RETURN
END
Figure 23-6. Basic DEMOBL Model Routine
23-26
Chapter 24
Event Studies
Chapter 24 - Event Studies
Run Activity Event Studies - GUI

Dynamics Tree View>Dynamics>Event Studies>Add Event Study [Open]
Event Study file (*.evs)
24.1 Overview
Event Studies are a user-defined series of events that can be replayed over and over with data
values and settings changed interactively. Event Studies consist of one or more Event Items. Event
Items currently consist of network equipment connection and disconnection Events and Fault
Events.
When the Event Study is run as a Dynamics Event Study, Event Items are implemented as Distur-
bance APIs when a match is available, and as general Network APIs when no defined disturbance
API exists e.g. Load connect/disconnect events. Event Items in a Dynamics Event Study have a
time element associated with them and are performed in ascending time sequence.
When the Event Study is run as a Power Flow Study, Fault Event Items are mapped to SCMU APIs
and network Event Items are mapped to Network APIs. Currently, simultaneous Fault Events are
not supported and so any simultaneous Events in the Event Study are de-activated and only the
first encountered Fault Event is performed.
Dynamics and Power Flow event studies can be accessed in several different ways. Event studies
can be added and viewed by accessing the Dynamics tab in the Tree View. Individual event items
can be added to the active study from the tree view, from the diagram, and from the event spread-
sheet. The event spreadsheet enables the user to edit the events in the active study.
Event Studies are preserved in an external file with an *.evs suffix. Through the use of the Event
Study file, defined Event Studies maybe used with more than one set of files.
24.1.1 Event Item Type

The following table describes the supported Event Types and their implementation when run in
Dynamics and Power Flow Study modes.
Table 24-1. Supported Event Types

Event Type Dynamics Implementation Power Flow Implementation
Connect Bus Re-connect Bus - RECN Re-connect Bus - RECN
24-1
Event Studies PSS®E 34.2
Overview Program Operation Manual
Table 24-1. Supported Event Types (Cont.)

Event Type Dynamics Implementation Power Flow Implementation
Disconnect Bus Disconnect Bus - DSCN Disconnect Bus - DSCN
Connect Machine Machine Status switch Machine Status switch
Disconnect Machine Machine Status switch Machine Status switch
Connect Load Load Status switch Load Status switch
Disconnect Load Load Status switch Load Status switch
Branch/Transformer Close
Connect/Close Line Branch/Transformer Status switch
Disturbance
Branch/Transformer Trip
Disconnect/Trip Line Branch/Transformer Status switch
Disturbance
Multiple unbalanced network solu-
Bus Fault Bus Fault Disturbance
tion - SCMU
Branch/Transformer Line Fault Multiple unbalanced network solu-
Line Fault
Disturbance tion - SCMU
Calculate and Apply Unbalanced Multiple unbalanced network solu-
Unbalanced Bus Fault
Bus Fault tion - SCMU
Multiple unbalanced network solu-
Unbalanced Line Fault Calculate and Apply Branch Fault
tion - SCMU
Vref Change Vref Change Disturbance (not applicable)
24.1.2 Event Study Properties

The user specifies the general parameters which will be used when the event study is run. All fields
are initially filled with default values, however the user may edit them all.
The following fields are used only if the Event Study is run as a Dynamics Event Study. The values
in these fields have no significance if the Event Study is run as a Power Flow Event Study.
Table 24-2. Dynamics Event Study Properties
Property Description
Study length Total duration of the event study in seconds.
Integration step Time interval, in seconds, between steps.
Tolerance PSS®E dynamic simulation convergence tolerance.
Iteration limit PSS®E dynamic simulation iteration limit.
Print interval Number of steps between text outputs.
Graph interval Number of steps between channel file outputs.
Plot interval Number of steps between plot results output.
The active study is the only study to which event items can be added from the diagram and from
the network tree. There are two ways in which an event study becomes the active study.
• The event study currently being added automatically becomes the active study.
24-2
PSS®E 34.2 Event Studies
Program Operation Manual Overview
• Selecting the event study pop up menu displays an option to set a particular event
study to be the active study.
The active study is the one which will be executed when the option to Run Dynamic Study or Run
Power Flow Study is selected. When you exit the program, the studies are saved to the named file.
A flag indicating which of the studies is the active study is also saved, so that when the file is read
back in, the same event study will still be the active study. If the active study is deleted from the tree
view, no study is active until another is added or a remaining one is made active by selecting the
Make Active Study choice on the popup menu.
If there is an event which should not be included when an event study is executed, it can easily be
deactivated in the event spreadsheet. This eliminates having to delete and reconfigure events
which may be needed at another time.
24.1.3 Adding an Event Item

The user specifies the Event Items which will be part of the selected study.
Table 24-3. Event Item Properties
Name User-specified; can be edited to suit the user.
User-specified event type:
• Unbalanced Bus fault
• Unbalanced Line fault
• Line fault
• Bus fault VREF change
• Disconnect Load
Event Type • Connect Load
• Disconnect Bus
• Connect Bus
• Disconnect Machine
• Connect Machine
• Line trip
• Close Line
For Dynamics Event Study only.
Event initiation
time (sec) The time at which this event item occurs; this value must be less than the total
time duration of the entire event study.
Admit- R (ohms); default = 0
tance/Fault
impedance X (ohms); default = 0
24-3
Event Studies PSS®E 34.2
Overview Program Operation Manual
Table 24-3. Event Item Properties (Cont.)
User-specified network elements:
• Bus
• Load
Network Items
• Machine
• Branch
• 3-Winding Transformer
24.1.4 Running an Event Study

There are two types of event studies, a dynamic study and a power flow study. In order to run a
Dynamic Study, dynamics data must be present. If an event study file has been read into the
program, event items in the active study will also be indicated on the one-line diagram. More that
one Event Item can be associated with any Network Item and only one Event symbol will be
displayed on the Network Item in the diagram.
24-4
Chapter 25
Scenarios
Chapter 25 - Scenarios
Run Activity Scenarios - GUI

File>Scenarios>New Scenarios…
File>Scenarios>Open Scenarios…
File>Scenarios>Save Scenarios…
File>Scenarios>Close Scenarios…
File>Scenarios>Edit Scenarios…
Scenario Files (*.pssxml)
25.1 Overview
The Scenario Manager is designed to eliminate the file management complexities that arise when
using PSS®E by keeping track of and organizing the files that are used with PSS®E. Scenarios
are groups of files that are used to perform a study. They can consist of any files on either local or
remote machines, and can be of any type, including network files, both Power Flow and Dynamics,
in both the raw and binary forms, Slider Diagrams, Bus Location and Subsystem configuration files,
Contingency analysis files (subsystem Description files, Monitored Element file, Contingency file,
Distribution Factors file) and Sequence and OPF data files. All the files used in the study are kept
track of in a Scenario file, and, through the use of zipping functionality, all files can be stored in a
single zip file. The Scenario file format is based on XML, so it is easily readable by all text editors
(see Figure section / Sample Scenario File). When a Scenario file is opened in PSS®E two things
happen, all the files designated to load in the Scenario file are opened and the file selectors on all
25-1
Scenarios PSS®E 34.2
Scenario Creation Program Operation Manual
dialogs will be pre-populated with all files in the Scenario that are of the type required by the
selector.
Figure 25-1. Sample Scenario File
25.2 Scenario Creation

A Scenario can be created through the GUI or through the API. See GUI, API. When done through
the GUI a default group named "Group" will be added to the new Scenario automatically and will be
set as the active group and the startup group in order to easily facilitate the population and usage
of the Scenario. When creating a New Scenario through the API there will be no automatic group
creation and configuration, additional API calls will be needed to create a new group.
No file name is required when a new Scenario is created, however a file name can be supplied
through the API call. If a file name is supplied, the new Scenario will be saved to that location after
it is initialized.
The default root path for a new Scenario will be the current working directory, unless a valid file
name was supplied through the API, in which case the root path will be the directory location of the
supplied file name.
25-2
PSS®E 34.2 Scenarios
Program Operation Manual Scenario Population and Configuration
A newly created Scenario will also mark its creation date, the username of the creator, the current
version of PSS®E, and the current version of Scenario Manager.
25.3 Scenario Population and Configuration

Once a Scenario is loaded into PSS®E, either through opening a Scenario file or creating a new
one, there are several methods that can be used to add files to the Scenario. Files may be added
one at a time through the API (See API) or through the GUI by means of selector dialog, drag and
drop, or file tracking (See GUI). When a file is added to the Scenario that file item will have several
values associated with it. These values are the path, type, and load. The path tells the Scenario
where the file is located. The type attribute defines what the file type is. Since PSS®E does not
enforce specific file extensions the type attribute is used to associate the files with defined PSS®E
file types defined here. The load attribute is used to determine if and when a file will be loaded when
the Scenario is opened.
Many file adding methods in the GUI will allow the user to add multiple files of different types at
once. However, since there are no standard extensions for PSS®E, an attempt will be made to
associate default extensions to their related PSS®E types. If a file is added with a non-default
extension its type attribute will be left blank for the user to define later. If a file has an extension that
is the default extension of a different PSS®E type the attribute can be modified later, as can all attri-
butes of the files, through the API or GUI.
To allow for better flexibility Groups have been introduced. Groups are nothing more than a collec-
tion of files, but they can allow a user to organize a Scenario in whatever manner they see fit. A file
can be placed in multiple Groups, so while some Groups can be completely different sets of files,
others could be slight variations of each other, possibly having a slightly different Saved Case but
the same automation files. New Groups can be created through the API or GUI. Several methods
are available for copying and moving files from Group to Group as well as making duplicate Groups
or combining Groups in the Scenario through the API and GUI.
25.4 Using a Scenario in PSS®E

Using Scenarios in PSS®E presents several alternative methods for using the PSS®E GUI,
however, some functions will require an active group to work. One of the main features that will
become active with or without an active group is the population of the file selector fields in the GUI.
Each file selector will be populated with a list of files of the type the field is looking for. If the file
selector field is for an input file and there is a defined active group, and an order has been desig-
nated for the desired file type, then the file at the top of the order will automatically be selected.
However, no automatic selection will be made if the file selector field item will be used for output, or
if there is no active group.
Another difference is the open file and save file dialogs. If there is an active group then an alterna-
tive open/save file dialog will be shown which lists the files contained in the Scenario in order to
facilitate the quick opening of files already defined in the Scenario. If the user would like to open or
save a file not in the Scenario there is a button to bring up the standard open/save dialog.
Lastly, as files are accessed in PSS®E any files not already present in the active group will be kept
track of and the user will be prompted to add the new files if desired. However, if there is no active
group then the user will not be prompted until and active group is selected.
25-3
Saving and Packing a Scenario Program Operation Manual
25.5 Saving and Packing a Scenario

A Scenario can be saved in two different forms. The first form is the Scenario XML File, which
contains the Scenario definitions and paths to all files in the Scenario, but not the files themselves.
The second form is a Zip file, which is an archive of all of the files in the Scenario as well as the
Scenario XML File. The Zip file is in essence a single file solution to containing all data used in
PSS®E allowing a user to easily hand an entire study or other piece of work to another user. Either
file type can be read into PSS®E, however when a zip file is read in, PSS®E will use the data files
from within the zip file and not the original file. This will be reflected in the path of each file in the
scenario.
25.6 Opening and Unpacking a Scenario

As stated in the previous section, there are two forms a saved Scenario can take. If a Scenario XML
File is opened, then the file is read and Scenario makes note of the locations of all of the files. If a
Zip file is opened, then the Scenario Manager will look for a Scenario XML File with the same name
as the Zip file. If no file inside the Zip file matches that criteria the Scenario Manager will then look
for any XML File. If this fails it will then attempt to open each file as a Scenario XML File. If no
Scenario XML file is found the Zip file will be ignored. While Scenario Manager can now read and
write directly to the zip file there may come a time when the files need to be unzipped. When
Scenario Manager is told to unzip the archive it will attempt to place files in locations based on
several unzipping options and the file paths stored in the Scenario XML File.
When unzipping, each file in the archive is categorized as either a Root File a Local File or a Remote
File. Each category of file has an option for resolving file conflicts which can be set to "skip", "ask",
or "overwrite". If the conflict resolution option for a particular file category was set to "skip" then
when an attempt is made to extract a file of that category and another file is already in its destina-
tion, the file will not be extracted and no note of the conflict will be made. If the option is set to "ask",
then when a conflict occurs the file will not be extracted, but a notification of the conflict will be made
so the user can make a decision on what action should be done to resolve the conflict. If the option
is set to "overwrite" then the file is extracted and the file at the destination will be replaced with the
file from the archive, if a file was previously there.
In addition to these three options there are options for the placement of Local Files and Remote
Files. The Scenario Manager will always attempt to extract Root Files to the same location relative
to the Root Path. However, there are several options for the placement of the other two categories
which are "do not unzip", "place in root directory", and "place by absolute path", and Local Files
have the additional option for "place by relative path". The "do not unzip" option means any file in
that category will not be extracted. The "place in root directory" option means an attempt will be
made to extract the file to the root path defined in the Scenario. Selecting the "place by absolute
path" means an attempt will be made to extract the files to the same path the files were in before
being placed in the archive. Selecting "place files by relative path" means the extraction process
will attempt to place the files in the same location they were in before, relative to the root path. For
example if the root path at the time the archive was created was "C:\Users\Joe\Docu-
m e n t s \ P s s e \ St u d y 5 " and the file was located at "C:\Users\ Joe
\Documents\Psse\Models\joemodels.dll" and the archive was extracted at "C:\Users\Jack\Docu-
ments\Psse\Joe5" joemodels.dll would be extracted to
"C:\Users\Jack\Documents\Psse\Models\joemodels.dll", or in relative form
"..\Models\mymodels.dll".
The GUI will prompt the user if any conflicts are found and allow the user to choose a course of
action for each file. The user can choose to "ignore", "retry", or "overwrite" a conflict. Ignoring will
result in the file not being extracted, whereas overwrite will result in the file being extracted and the
25-4
PSS®E 34.2 Scenarios
Program Operation Manual Scenario Terms
file at the destination being deleted. Retry can be used to try the extraction again using a different
file name, or can be used to try again with the same name after the user may have moved or
renamed the file at the destination. If a conflict occurs when a retry is attempted the user will be
prompted again.
There are several API calls that can be used through python to check and resolve differences.
There is also a batch API call to resolve differences, but since there is no method for returning data
though batch commands there is no way to know what conflicts occurred.
25.7 Scenario Terms

File - The file is the simplest item of a Scenario. These items can be considered data sources,
though they do not contain the actual data. Instead these items contain the address of a data
source, such as a file on the local system, a file on a remote computer, or even a database. If the
data source is moved or deleted the file item will become invalid as it will no longer point to a valid
data source.
A PSS®E file type is assigned to each file to associate the file with the relevant PSS®E routines.
For example a .cnv file can be associated with the Saved Case file type so it will show up in a
selector for Saved Cases. Each file type association will be given by a unique 3 character file type
designation. The file types and their corresponding unique identifiers can be found on this table
(here).
Each file will also have a load order attribute which will determine if and when the file is loaded when
the group the file is part of is loaded. Each file can also have an argument string which will be used
to pass additional arguments to the opening process when the file is being automatically loaded.
Some files have different argument strings and the GUI provides a simple way to define the appro-
priate string for each file.
Group - A group is a collection of files and can be thought of as the organizational level of the
Scenario. Groups can contain files that are in other groups of the same Scenario, but cannot
contain the same file twice. Each group has its own load order which defines what files should be
opened when the group is opened, what order to open the files in, and what order the files should
be listed in when a selection box is populated. One group in a Scenario can be designated the
startup group.
Scenario - The scenario is the highest level of organization for the Scenario Manager tool. It can
be seen as a kind of suitcase, allowing the user to place many items inside of it and keep track of
them all from a single item.
The scenario can contain any number of groups and one of the groups can be designated the
startup group. The scenario will also keep track of its creation and modification dates and the users
associated with those dates.
Another important piece of information for the scenario is the root path which plays an important
role when using the zip functions of the Scenario Manager.
Load Order - This is the order in which files will be opened and/or arranged when making a
selection.
Only files that are "memory resident" will be loaded. Some examples of "memory resident" files are
Saved Case, Snapshot, and Slider files. These files contain data about the system that will be
stored in PSS®E while the program is running. Many of these file types will only be allowed a single
file of that type to be selected for loading since opening multiple files of the same time would result
25-5
Scenario Terms Program Operation Manual
in the overwriting of data that was loaded from the previous file, e.g. Saved Case files. Some files,
such as Saved Case and Power Flow Raw Data files, also contain similar information. Since
loading both would once again overwrite previously loaded data, only a single file from that category
is allowed to be selected for automatic loading. In this case a single Saved Case or a single Power
Flow Raw Data file can be selected for automatic loading, but not both. Several other file types have
similar groupings, such as Snapshot and Dynamics Data files. However, the number of files that
can be automatically loaded through Power Flow Raw Change Data or Dynamics Add Data files is
not limited since these files augment the data in PSS®E.
Examples of files that are not "memory resident" would be Subsystem Description Data, Monitored
Element Data, Contingency Description Data, Distribution Factor Data, AC Contingency Solution
Output, PV Solution Output, and QV Solution Output files. These files are the inputs and/or outputs
of certain PSS®E activities, but the information in them does not stay in PSS®E memory once the
activity is finished. These files may be assigned an order, with each non "memory resident" PSS®E
file type having its own order. This order specification will force a specific arrangement of the files
when populating a selection box with that file type.
Root Path - This defines the top level of the tree where root files will be located. This path is also
where the zip file will be created when executing the scenario zip function with the default argu-
ments. When a zipped scenario is moved and then unzipped, the tree that was below the root path
when the scenario zip was created will be recreated at the current location of the zip file. This new
location of the zip file will then define the new root path.
Startup Group - The group whose load order will be enacted upon opening of the scenario file.
Active Group - The group whose load order was last run. The startup group (if defined) will always
be the first active group under the default scenario opening procedure. All file tracking operations
will interact with this group. If a Scenario does not have a startup group, or was opened in a way
that skipped the running of the startup group, then no group will be the active group when the
Scenario is initially opened.
Root File - A file that is located at or below the root path. These files could be on a local machine
or a remote machine depending on what the root path is.
Local File - A file that is located on a local machine, i.e. access to that file is available from the
current machine even if no network connection is available. This does not include files at or below
the Root Path.
Remote File - A file that is located on a machine that is not the local machine, i.e. a network connec-
tion would be needed to access the file. This does not include files at or below the Root Path.
25-6
Chapter 26
Node-breaker Modeling
Chapter 26 - Node-breaker Modeling
26.1 About the Node-breaker Model

Two types of network models are commonly used in power system planning studies: node-breaker
and bus-branch. The bus-branch model is typically used for off-line planning studies, where
common voltage level elements are consolidated into one logical bus. In contrast, the node-breaker
model offers a full-topology model that includes detailed nodes, breakers and other switching
devices within substation configuration representations. Real-time system operations typically use
the node-breaker model to recognize and operate the individual switching devices when making
system operation condition changes.
The recent trend in the power industry is to use node-breaker models for both planning and opera-
tion studies for the following reasons:
• There is a lot of redundant work to maintain two models concurrently. It is quite labor
intensive and also difficult to identify discrepancies between node-breaker and bus-
branch models.
• Mapping bus numbers in the bus-branch model to node numbers in the node-breaker
model is very difficult, and validation of the off-line model with real time data is hard to
achieve.
• The node-breaker model is ideal for many planning studies: simulating breaker actions
and multiple-terminal line contingencies, simulations of splitting and merging buses
due to breaker operations.
It should be noted that the full-topology model for planning studies typically does not contain other
devices aside from the major switching devices such as breaker disconnect switches; therefore
these planning node-breaker models are more a simplified version than the full-topology node-
breaker models used by operations. Moving data between a bus-branch model and a node-breaker
model can historically prove to be an arduous task, and prone to errors.
Prior to PSS®E version 34, the only way to model node-breaker in PSS®E was to model each node
as a bus and each switching device as a regular AC branch or zero impedance lines. With this
method, the simulated node-breaker model is no different than the bus-branch model. However,
using this direct method to model the node-breaker topology has some adverse impacts on plan-
ning studies, such as:
• Requiring huge numbers of connection nodes (buses) and breakers (lines and zero
impedance lines).
26-1
Node-breaker Modeling PSS®E 34.2
Node-breaker Modeling in PSS®E Program Operation Manual
• The components are always connected to buses and difficult to identify.

• Transitioning from the bus-branch model to the node-breaker model is not automatic,
and is time consuming and difficult.
In contrast, the ideal benefits of an integrated node-breaker modeling system for planning studies
are:
• Node-breaker contingency events can be properly simulated and validated.

• Breaker failure events can be simulated.
• The node-breaker model is represented on a substation by substation basis.
• The ability to display both a bus-branch view and the substation view.
• Power flow results can be reported on bus-branch and node-breaker models.
• The addition of node-breaker representations will not affect computational speed or
solution stability.
• Hybrid node-breaker and bus-branch modeling is allowed in the same power flow case.
26.2 Node-breaker Modeling in PSS®E

In order to overcome the disadvantage of having to model node-breaker topology using traditional
buses, branches and zero-impedance lines, and to meet the above requirements of an ideal inte-
grated node-breaker modeling system, a dual-level method to model node-breaker is provided in
PSS®E by which the full-topology model is represented at both the system and substation levels.
This allows users to interact with the network through the traditional bus-branch view, while also
having the ability to drill down into the details of breakers and switches as required. By using state-
of-the-art topology processing techniques, the design can support tens of thousands of additional
nodes without the loss of speed or accuracy in the power flow solution.
The PSS®E node-breaker data model is implemented as an extension to the standard bus-branch
data model, providing an interconnection between buses and nodes. The bus-branch and node-
breaker models are seamlessly linked with the complex node-breaker detail hidden from view until
the user needs to drill down and perform operations at the breaker level.
To illustrate this, the PSS®E node-breaker representation of a bus-branch model is shown in

Figure 26-1.
26-2
PSS®E 34.2 Node-breaker Modeling
Program Operation Manual Node-breaker Modeling in PSS®E
Figure 26-1. PSS®E Basic Node-breaker Terminology
Each full-topology model consists of the traditional bus-branch model, along with as many substa-
tion models as are needed. Substation models are an additional level of detail built on top of bus-
branch models. These substation models are optional; if none exist in the case, then the full-
topology model is identical to its bus-branch model. When detailed node-breaker substations are
present, additional operations and functionalities are available specifically for node-breaker anal-
ysis, including calculation of flows on switching devices within a substation, switching device related
contingencies, isolation operations and others.
26-3
Node-breaker Modeling in PSS®E Program Operation Manual
Figure 26-2 and Figure 26-3 show the bus-branch model at bus 203 using GOUT, and a substation
diagram of the same bus. Buses with boxes drawn around them indicate that they have an under-
lying substation model.
Figure 26-2. Bus-branch View of a Bus
Figure 26-3. Detailed node-breaker view of same bus
In the bus-branch model, buses are the points to which other components such as branches, loads
and machines are connected.
26-4
Program Operation Manual Topology processor
In the node-breaker model, terminals describe the connections to the nodes in a substation. The
FROM and TO buses of a branch define its connections in the bus-branch model but each branch
end may also have a terminal connection to a node.
In Figure 26-3, above, the branch from Bus 154 to Bus 203 is explicitly modeled in the bus-branch
model as being connected between buses 154 and 203. These buses however are also topological
buses, each representing a group of nodes within separate substations. In the full-topology model,
as shown in Figure 26-4 below, the branch is more specifically connected between terminal node 4
of Substation 1 containing topological bus 154, and terminal node 4 of Substation 2, containing
topological bus 203.
Figure 26-4. Branch 154 to 203 node terminal connections in the Substation Model
Terminal connections to nodes in a substation can be any of the devices supported in the PSS®E
power flow raw data file, with the current exception of induction motors, DC lines, and FACTS
devices. Details of the format for inputting substation terminal component data are found in Section
1.28.4, Equipment Terminal Data of the Data Formats Reference Manual.
26.3 Topology processor

In the full-topology model, a bus is called a topological bus if it represents a group of nodes in a
substation. It is typical to have multiple network buses or topological buses represented in a single
substation. A bus without any nodes is a connectivity bus. A full-topology model may consist of both
topological buses and connectivity buses.
As shown in Figure 26-3 above, bus 203 represents nodes 1 through 8 in the substation. When all
nodes of a main network bus are connected by closed switching devices, they are represented by
one bus in the bus-branch model at the system level. This bus is termed the original, or parent, bus.
As changes are made in bus-branch models, these changes will automatically be propagated to the
substation models. For example, if a bus is disconnected (through DSCN), then all its nodes,
connected devices and branches are also disconnected. If the original parent bus is simply set out-
of-service (type code of 4), then all its nodes are placed out of service, but branches are not
affected.
Changes which may cause the automatic running of the node-breaker topology processor include:
• Adding substation models

• Adding/deleting nodes and changing the status of nodes
• Adding/deleting switching devices and changing the status of switching devices
26-5
Topology processor Program Operation Manual
• Changes in terminal nodes of branches, transformers, loads, bus fixed shunts,

machines and switched shunts
• Changing the status of a branch or transformer connected to a node
The topology processor takes substation switching device connections and statuses as inputs to
group the nodes into electrically connected bus sections, assigning a topological bus for each
group, and moving components to the right topological bus. Internally, the topology processor will:
1. Check for connectivity errors in the bus-branch model and substation models
2. Generate node groups by locating all nodes which are connected together by closed circuit
breakers and disconnect switches.
3. Assign a topological bus to each group, create a bus-section and re-route components to
the bus as needed.
4. Form into electrical "islands" all of the buses connected together by AC lines, including
transmission lines, and transformers. An island must have at least one system swing bus
(bus type code of 3), otherwise that portion of the system is isolated and shut down.
As substation switching devices are opened, a splitting of the original bus may occur, resulting in
two distinct topological bus sections. When a new active node group is created and a topological
bus section is needed, the bus data of the original bus is copied to the new bus section, including
area/zone/owner numbers, voltage limitations, base kV, voltage magnitudes and angles. The bus
number is the same as the original bus, with a section identifier (Bus 154-4 for example).
The section identifier is assigned as the minimum node number of the node group of which the bus
section is comprised. Bus sections may come and go as switching devices are opened and closed
and, for this reason, bus numbers of bus sections are always referenced and identified by the parent
bus number and a bus section number. The branches, transformers, three-winding transformers,
loads, fixed shunts, switched shunts, and machines that are attached to the nodes in the group will
remain connected to those nodes but will move to the new topology bus section to which those
nodes now belong.
For machines that are moved to a new bus section, the new bus section becomes a generator bus
with plant data. The parent bus also remains a generator bus. If all machines are connected to the
new topological bus, then the original bus still remains a generator bus, although without any
machines. Plant data for each will be updated accordingly. If the parent bus is a swing bus (type 3)
but does not have any machines, then one of its bus sections will be assigned as the swing bus and
the parent will be assigned as a generator bus (type 2).
In Figure 26-5, the switching devices between nodes 1 and 4, and between nodes 2 and 10, have
been opened, causing nodes 4 and 10 to be electrically separated from the remaining nodes in the
substation.
26-6
Program Operation Manual Topology processor
Figure 26-5. Substation bus split into 2 bus sections due to switching operations
Immediately after any switching operation, the node-breaker topology processor automatically
updates the underlying bus-branch and node-breaker model connections.
For the above example, an informational message indicates the split, and displays the newly
assigned bus section numbers:
Bus 154 is split into the following bus sections due to operations of
switching devices:
Bus section 154- 1
Bus section 154- 4
Bus section 154-4 now contains nodes 4 and 10, plus load 2, while bus section 154-1 contains all
other remaining nodes and their terminal connections.
In PSS®E reports and messages, all bus sections will be uniquely identified by the parent bus
number and a section number:
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS(R)E MON, MAY 16 2016 15:55
PSS(R)E SAMPLE CASE BUS DATA
ALL DATA CATEGORIES WITH SEQUENCE DATA
S H U N T S X--- NORMAL --X X- EMERGENCY -X
BUS#-SCT X-- NAME --X BASKV CODE LOADS FIXED SWITCHED VOLT ANGLE AREA ZONE OWNER VMAX VMIN VMAX VMIN
101 NUC-A 21.600 2 0 0 0 1.01000 -11.0 1 1 1 1.10000 0.90000 1.10000 0.90000
102 NUC-B 21.600 2 0 0 0 1.01000 -11.3 1 1 1 1.10000 0.90000 1.10000 0.90000
151 NUCPLNT 500.00 1 0 3 0 1.00071 -14.1 1 1 1 1.10000 0.90000 1.10000 0.90000
152 MID500 500.00 1 1 1 1 1.03913 -24.0 1 2 1 1.10000 0.90000 1.10000 0.90000
153 MID230 230.00 1 1 0 0 1.05336 -25.7 1 3 1 1.10000 0.90000 1.10000 0.90000
26-7
Creating a substation Program Operation Manual
154- 1 DOWNTN 230.00 1 3 1 1 0.99751 -33.3 1 3 1 1.10000 0.90000 1.10000 0.90000

154- 4 DOWNTN 230.00 1 1 0 0 0.84512 -36.5 1 3 1 1.10000 0.90000 1.10000 0.90000
When switching devices are closed, resulting in node groups being merged back together, an
existing bus section will no longer needed. The nodes and their connections are automatically
moved back to the bus or bus section to which they are being merged into and the unneeded bus
section is deleted.
In Figure 26-5, when one of the switching devices between either nodes 1 and 4 or between nodes
2 and 10 is closed, then all nodes are again reconnected, and the following message indicates that
the extra bus section is no longer needed:
Bus Section 154-4 [DOWNTN 230.00] is not needed due to operations of switching
devices
At this point, only bus 154 remains, containing all 14 nodes. The additional bus section bus that had
been introduced is removed.
26.4 Creating a substation

The procedure to manually build a full-topology model consists of the following steps:
• Build a bus-branch model,

• Expand one or more connectivity buses into topological buses by creating substations.
• Set up node terminals connections for branches and components.
• Place substation switching devices between nodes within the substation.
The data for the node-breaker model, including the substation definitions, nodes, substation
switching devices, and connections to network components is described in the node-breaker raw
data file format Section 1.28, Substation Data of the Data Formats Reference Manual. This data
can be entered or changed through the PSS®E spreadsheet or PSS®E Powerflow data file.
Since the node-breaker model in PSS®E is an extension to the existing bus-branch model, it is
possible to add or remove the node-breaker data without any loss of functionality to the bus-branch
model. The internal details of the data mapping and topology processing are completely hidden.
To assist with the building the substation models, a substation configuration builder tool provides
the means to automatically generate a generic node-breaker topology substation, based on several
commonly used substation configurations: ring bus, breaker-and-a-half, double-bus-double-
breaker, etc. A graphical representation of the substation is automatically created in the form of a
substation single-line diagram (Substation SLD). The layout of the substation SLD can be manually
changed for proper placement of terminals to approximate the actual configuration of the substa-
tion. New substation components can also be added or existing components deleted. This can be
done through either the network data dialog or through the diagram itself.
26-8
Program Operation Manual Viewing a substation
To run the substation configuration builder, select Node-Breaker>Configuration Builder… from

the main PSS®E menu. The Build a Substation Configuration dialog is shown in Figure 26-6.
Figure 26-6. Automatic Node-Breaker Substation Configuration Builder Dialog
It is also possible to open the substation builder dialog by doing a right-mouse-click on a bus
displayed within the spreadsheet view, or in a diagram, and selecting Build a substation….
Within the dialog:
• The Substation number field will automatically be populated with the lowest available
number that has not already been used for other substations. This number can be
modified as desired.
• The Substation name can be entered but is optional. It is used in reports and on
diagrams.
• The bus number of the bus that is to be expanded into the substation model must be
entered. If the Configuration builder was started from a right-mouse-click on a partic-
ular bus, then this field will automatically be populated with that bus number.
• Select the type of substation layout to build.
• It is possible to have the substation generated without having a new diagram displayed.
If this is desired, uncheck the option to automatically generate station diagram.
Once Go is selected and the substation components are created for that bus, the dialog will remain
open and another bus can be added for inclusion in the same substation, or a different substation.
26.5 Viewing a substation

To view an existing substation, select Node-Breaker>Generate substation display from the main
PSS®E menu. A Select Substation dialog will be displayed where the desired substation number
can be entered.
To view a diagram of an existing substation from the bus spreadsheet or a network diagram, right-
click on the bus that is within the substation of interest and select Generate substation display
PSS®E will either find your custom SLD file for that substation (found by substation name), or it will
create one on-the-fly. If a bus is not associated with a substation, then the option to "Build a substa-
tion…" will be shown on the menu instead.
26-9
Delete a Substation Program Operation Manual
26.6 Delete a Substation

To purge a substation from the network go to the Substation tab of the Network data > Node-Breaker
spreadsheet. Click on the box to the left side of the Substation Number of the substation to be
deleted. When the entire line is highlighted, either press the Delete key or select Delete from the
Edit menu or right-click drop down menu.
The deletion of a substation will cause all components within that substation to revert solely to their
bus-branch representation. Any network components, such as equipment and lines that are
connected to topology bus sections, will be moved back to the parent network bus and the topology
bus sections will be deleted. All nodes and switching devices will also be deleted.
26.7 Remove a Bus from within a Substation

To remove a bus from a substation, go to the Bus tab of the Network data spreadsheet and right-
click on the record of the bus or bus section that is to be removed and select Remove bus from
substation. This results in immediate action with no further dialog. When complete a message will
be displayed in the Progress area that the bus has been removed from the substation.
The removal of a bus from a substation will first move all network components, such as equipment
and lines that are connected to any topology bus sections of that bus, back to the parent bus. The
associated topology bus sections are then deleted, along with all nodes and substation switching
devices connected to the bus.
The Remove bus from substation activity can also be performed from within a network or substation
diagram. Right-mouse-click on the desired bus or on a node associated with the desired bus and
select Remove bus from substation from the menu.
Figure 26-7. Remove Bus from substation from Bus Spreadsheet
26-10
Program Operation Manual Convert a Topology Bus Section to a Network Bus
26.8 Convert a Topology Bus Section to a Network Bus

The Convert Bus Section to Bus activity converts a bus section topology bus that is not the parent
bus, to a full network bus.
To run the Convert Bus Section to Bus activity, select Node-Breaker>Convert bus section to
bus…. The resulting dialog is shown in Figure 26.7. Convert a Bus Section to a Bus.
Figure 26-8. Convert a Bus Section to a Bus
Enter the bus number and a node number of the section to be converted, separated by a space or
comma, or alternatively, use Select… to choose a bus section from a list of buses in the network.
Then enter the desired new bus number to be used for the section being converted and optionally
a new name. Click OK when complete. A message will be displayed indicating completion of the
action.
The Convert Bus Section to Bus operation can also be invoked from a network diagram, substation
diagram or on the Bus spreadsheet by doing a right-mouse-click on the bus, node or bus record
respectively.
26-11
Check Substation Topology (STREE) Program Operation Manual
26.9 Check Substation Topology (STREE)

The full-topology model is represented by one bus-branch model and additional substation models.
It is deemed valid if the neither the bus-branch model nor any of the substation models have topo-
logical errors, and the bus-branch model and substation models are consistent. Using Activity
TREE, the bus-branch model is topologically correct if:
• All in-service buses are connected back to a Type 3 (swing) bus through the in-service
ac network
• There are no in-service branches connected to Type 4 (disconnected) buses
Just as the TREE activity is used to validate the bus-branch model, the STREE activity is used to
validate the node-breaker model in the presence of substations.
Activity STREE checks for two types of topological errors: continuity of substation networks and
consistency between bus-branch and substation models. A substation model is topologically
correct if:
• A substation switching device is closed, and its two end nodes have the same service
status.
• Nodes connected by closed substation switching devices are in the same node group
(bus section).
A group with only in-service nodes is defined as an active group; each active group within a substa-
tion must be represented by an in-service topological bus (or bus section) in the bus-branch model.
A node group consisting of out-of-service nodes is defined as an inactive group; an inactive node
group may or may not have a unique topological bus in the bus-branch model, and it may share the
same topological parent bus as an active node group.
All node statuses are handled internally by the topology processor so it is not likely that topology
errors due to differing node statuses will be encountered.
For a branch or two-winding transformer, if one of its end buses is a topological bus, the corre-
sponding terminal node must be one of the nodes in the substation and it must have the same
topological bus as the end bus. Furthermore, if the branch is in-service, the terminal must belong
to an active node group.
Similarly, any loads, fixed shunts, switched shunts or machines connected to a topological bus must
have a terminal node associated with the same topological bus. In the bus-branch model, the equip-
ment is treated as in-service when both its status and the bus status are in-service. Inconsistency
may happen if:
• The topological bus and the equipment are in-service, but

• The terminal node belongs to an inactive node group represented by the topological
bus
To launch the STREE activity, select from the main menu bar, Node-Breaker>Check substation
topology (STREE)…
26-12

PSS®E 34.2
Figure 26-9. Check Substation Topology (STREE) Activity
Within the dialog window shown in Figure 26-9, select which substations to perform the checking on:
26-13
• Substations with switching checks only those substations where switching data has been changed
• All substations to checks all substations
• Selected substation to checks only the specified substation
The activity then checks each selected substation and lists any errors that exist for each.
26.10 List Substation Data (SLIST)
List Substation Data (SLIST)

The List Substation data (SLIST) activity lists, for each substation, its number and name, followed by all the components within the substation.
The components include nodes, substation switching devices and network system components such as loads, shunts, machines, branches and
transformers.
To run the activity, select Node-Breaker>List substation data (SLIST)…

PSS®E 34.2
Figure 26-10. List Substation Data Report dialog
Within the dialog shown in Figure 26-10, select either:
• All substations to report data for all substations.

26-14
• Selected substation to report data for a specific substation.

The resulting report shows each substation number and name, followed by a node report containing node number, name, corresponding bus
section, and status. This is followed by the list of substation switching devices, displaying the FROM node, TO node, name of the switching device,
its current and normal status, reactance and ratings.
This is followed by a list of all components connected to each node within the substation. For each of the connected loads, bus fixed shunts,
switched shunts or machines in the substation, the topological bus section number and name, along with the terminal node number and name
are displayed. For each branch and two-winding transformer, it's FROM and TO buses, nodes, and corresponding stations are reported, along
List Substation Data (SLIST)

with the circuit identifier. For each three winding transformer, it's FROM/TO/TO buses, nodes and stations are displayed, along with the circuit
identifier.
A sample substation report is shown in Figure 26-11.
Program Operation Manual List Substation Data (SLIST)
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS(R)E THU, MAY 19 2016 9:58

PSS(R)E SAMPLE CASE
ALL DATA CATEGORIES WITH SEQUENCE DATA
Substation: 1 [STATION_1]
X------------------ NODE ------------------X X----------- BUS -----------X ST

1 STATION_1_1_1 154- 1 DOWNTN 230.00 1
2 STATION_1_1_2 154- 1 DOWNTN 230.00 1
3 STATION_1_1_3 154- 1 DOWNTN 230.00 1
4 STATION_1_1_4 154- 4 DOWNTN 230.00 1
5 STATION_1_1_5 154- 1 DOWNTN 230.00 1
6 STATION_1_1_6 154- 1 DOWNTN 230.00 1
7 STATION_1_1_7 154- 1 DOWNTN 230.00 1
8 STATION_1_1_8 154- 1 DOWNTN 230.00 1
9 STATION_1_1_9 154- 1 DOWNTN 230.00 1
10 STATION_1_1_10 154- 4 DOWNTN 230.00 1
11 STATION_1_1_11 154- 1 DOWNTN 230.00 1
12 STATION_1_1_12 154- 1 DOWNTN 230.00 1
13 STATION_1_1_13 154- 1 DOWNTN 230.00 1
14 STATION_1_1_14 154- 1 DOWNTN 230.00 1
Substation switching devices

X--------------- FROM NODE ----------------X X---------------- TO NODE -----------------X CKT X---------------- NAME ---
-------------X ST NST X RATE1 RATE2 RATE3
1 STATION_1_1_1 3 STATION_1_1_3 1 1
1 0.00010 0.00 0.00 0.00
1 0.00010 0.00 0.00 0.00
1 0.00010 0.00 0.00 0.00
1 0.00010 0.00 0.00 0.00
1 0.00010 0.00 0.00 0.00
1 0.00010 0.00 0.00 0.00
1 0.00010 0.00 0.00 0.00
2 STATION_1_1_2 10 STATION_1_1_10 1 0
1 0.00010 0.00 0.00 0.00
2 STATION_1_1_2 11 STATION_1_1_11 1 1
1 0.00010 0.00 0.00 0.00
2 STATION_1_1_2 12 STATION_1_1_12 1 1
1 0.00010 0.00 0.00 0.00
2 STATION_1_1_2 13 STATION_1_1_13 1 1
1 0.00010 0.00 0.00 0.00
2 STATION_1_1_2 14 STATION_1_1_14 1 1
1 0.00010 0.00 0.00 0.00
1 0.00010 0.00 0.00 0.00
4 STATION_1_1_4 10 STATION_1_1_10 1 1
1 0.00010 0.00 0.00 0.00
5 STATION_1_1_5 11 STATION_1_1_11 1 1
1 0.00010 0.00 0.00 0.00
6 STATION_1_1_6 12 STATION_1_1_12 1 1
1 0.00010 0.00 0.00 0.00
7 STATION_1_1_7 13 STATION_1_1_13 1 1
1 0.00010 0.00 0.00 0.00
8 STATION_1_1_8 14 STATION_1_1_14 1 1
1 0.00010 0.00 0.00 0.00
X-------- LOAD BUS ---------X ID X------------------ NODE ------------------X

154- 1 DOWNTN 230.00 1 9 STATION_1_1_9
154- 1 DOWNTN 230.00 3 11 STATION_1_1_11
154- 1 DOWNTN 230.00 MO 12 STATION_1_1_12
154- 4 DOWNTN 230.00 2 10 STATION_1_1_10
X----- FIXED SHUNT BUS -----X ID X------------------ NODE ------------------X

154- 1 DOWNTN 230.00 1 13 STATION_1_1_13
X--- SWITCHED SHUNT BUS ----X X------------------ NODE ------------------X

154- 1 DOWNTN 230.00 14 STATION_1_1_14
Non-transformer branches and two winding transformers

X----------- BUS -----------X X------------------ STATION ------------------X X------------------ NODE ------------
------X CKT
FROM 154- 1 DOWNTN 230.00 1 STATION_1 8 STATION_1_1_8
TO 153 MID230 230.00 0 0 2

TO 155 FACTS TE 230.00 0 0 1

TO 205 SUB230 230.00 0 0 1

TO 3008 CATDOG 230.00 0 0 1
26-15
List Substation Data (SLIST) Program Operation Manual
W1
1
2
Figure 26-11. List Substation Data report

4 STATION_1_1_4
0
0
0
1 STATION_1
0
0
0
4.1600
230.00
230.00
230.00
INDGEN1
EAST230
4 DOWNTN
WEST
154-
9154
203
3005
TO
FROM
TO
TO
26-16
Program Operation Manual Substation Flow Report (SPOUT)
26.11 Substation Flow Report (SPOUT)

The Substation Flow Report activity calculates and reports flows on all switching devices within
selected substations.
To launch the activity, select Node-Breaker>Substation flow report (SPOUT)…
Figure 26-12. Substation Flow Report dialog
In the Substation Power Flow Report dialog shown in Figure 26-12, select which substation to
report on:
• All substations to output flow reports for all substation switching devices
• Selected substation to report on only the flows in a specific substation
For each topological bus section with a substation, a table reports on the FROM and TO node of
each substation switching device in the substation, along the type of switching device it is, the MW
and MVar flows, and rating and percentage.
A sample report output looks as shown in Figure 26-13.
26-17
Substation Flow Report (SPOUT) Program Operation Manual
PTI INTERACTIVE POWER SYSTEM SIMULATOR--PSS(R)E WED, FEB 17 2016 18:23
PSS(R)E SAMPLE CASE
ALL DATA CATEGORIES WITH SEQUENCE DATA Rating set: 1 % I for substation switching devices
Substation: 3 [SUB_STATION_03] Bus: 154 [DOWNTN 230.00]

X--------------- FROM NODE ----------------X X---------------- TO NODE -----------------X CKT X---------------- NAME ---
-------------X TYPE MW MVAR RATING %
1 SUB_STATION_03_1 2 SUB_STATION_03_2 1 BREAKER
-344.02 3.98 0.00
-103.89 -10.29 0.00
274.04 -245.15 0.00
-596.70 113.20 0.00
-2.00 1.21 0.00
-172.35 -97.86 0.00
370.00 185.00 0.00
230.00 192.00 0.00
242.50 97.25 0.00
100.00 80.00 0.00
2.41 -197.13 0.00
0.00 -122.22 0.00
Figure 26-13. Substation Power Flow Report
26-18
Program Operation Manual Isolate Item by Breaker
26.12 Isolate Item by Breaker

The Isolate Item by Breaker activity will attempt to isolate a specified component of the network by
opening surrounding system or substation breakers.
Once invoked, the activity will systematically seek to isolate the component by opening each
connected branch, transformer, or non-breaker switching device until a system or substation
breaker is opened. If any DC devices are encountered, the process will block these devices and not
continue along the search path for breakers. When either a breaker is opened, or a DC device is
encountered, the search in that particular direction stops.
The search for breakers will propagate outward for a specified number of levels in every direction.
When breakers are successfully opened in all directions sufficient to isolate the component, the
process successfully stops. If the component is not successfully isolated within the given number
of levels outward, the process will terminate with a message.
To run the Isolate Item by Breaker activity, select Node-Breaker>Isolate item by breaker.
Select the desired type of component to be isolated from the drop-down menu, including lines,
transformers, connected equipment, substation switching devices, and nodes. Then select the
specific item to be isolated. If a substation switching device is to be isolated, simply enter the
'Substation number, From node, To node, CKT ID'. If a node is to be isolated, enter the 'Substation
number, Node number'.
The option to modify the number of levels outward in which to search for breakers can also be modi-
fied. The larger the number, the wider and more extensively the network will be taken out if breakers
are not located nearby. The default number of levels can also be modified through Misc>Change
program settings (OPTN), on the Node-Breaker tab.
It is also possible to invoke the Isolate Item by Breaker operation from a network diagram by doing
a right-mouse-click on the component to be isolated and selecting the Isolate item by Breaker
26-19
Isolate Item by Breaker Program Operation Manual
option as shown in Figure 26-14.
Figure 26-14. Performing Isolate by Breaker from a diagram
During the Isolate operation, progress output will display the breakers that are opened. If
successful, this will be followed by a TREE report on any islands created.
Opened breaker "1" from node 5 [SUB_STATION_03_5] to node 1 [SUB_STATION_03_1] in substation 3 [SUB_STATION_03]
Opened system breaker "1" from bus 219 [ 230.00] to bus 3005 [WEST 230.00]
Terminated search for breakers along path after VSC DC device "VDCLINE1"
SWING BUSES:
BUS#-SCT X-- NAME --X BASKV AREA BUS#-SCT X-- NAME --X BASKV AREA BUS#-SCT X-- NAME --X BASKV AREA
301 NORTH 765.00 3 401 COGEN-1 500.00 4 402 COGEN-2 500.00 6
3011 MINE_G 19.400 5
ISLAND:
BUS#-SCT X-- NAME --X BASKV AREA BUS#-SCT X-- NAME --X BASKV AREA BUS#-SCT X-- NAME --X BASKV AREA
** NONE **
If the operation is not successful in isolating the component, a message such as the following will
be displayed at the end, and the islanding report will not be run.
Reached maximum of 4 levels outward; unable to isolate line by opening

breakers
26-20
Program Operation Manual Isolate Item by Breaker
The impact of the isolate operation, whether successful or not, will be reflected in the network data
and be visible on network diagrams, as shown in Figure 26-15.
Figure 26-15. Diagram displaying resulting actions of Isolate operation
An Isolate by Breaker report will also be generated displaying the specific network components
impacted by the Isolate operation. A sample of the report is shown in Figure 26-16.
26-21
Isolate Item by Breaker Program Operation Manual
The following buses have been set to out-of-service (type code 4):
BUS#-SCT X-- NAME --X BASKV

3007 RURAL 230.00
219 230.00
303 230.00
3008 CATDOG 230.00
3009 URBNWEST3009230.00
3010 INDMOTOR1 21.600
3018 CATDOG_G 13.800
The following nodes have been set to out-of-service:
BUS#-SCT X-- NAME --X BASKV NODE X--------------- NAME -----------------X

154 DOWNTN 230.00 5 SUB_STATION_03_5
The following branches/two-winding transformers have been disconnected:

X----------- FROM BUS -----------X X------------ TO BUS ------------X
BUS#-SCT X-- NAME --X BASKV NODE BUS#-SCT X-- NAME --X BASKV NODE CKT
154 DOWNTN 230.00 5 3008 CATDOG 230.00 1
219 230.00 303 230.00 1
219 230.00 3005 WEST 230.00 1
303 230.00 3007 RURAL 230.00 1
3007 RURAL 230.00 3008 CATDOG 230.00 1
3008 CATDOG 230.00 3009 URBNWEST3009230.00 1
3008 CATDOG 230.00 3018 CATDOG_G 13.800 11
The following three-winding transformers have been disconnected:
X--------------- XFRMER ---------------X X------ WINDING 1 BUS ------X X------ WINDING 2 BUS ------X X------ WINDING 3 BUS
------X CKT
X---------------- NAME ----------------X BUS#-SCT X-- NAME --X BASKV BUS#-SCT X-- NAME --X BASKV BUS#-SCT X-- NAME
--X BASKV
3WNDSTAT2 3008 CATDOG 230.00 3012 URBNWEST3012230.00 3010 INDMOTOR1 21.600 2
The following switching devices have been opened:
X------------------ STATION ------------------X X----------------- FROM NODE -----------------X X------------------ TO

NODE ------------------X CKT
ST # NAME NODE # NAME NODE # NAME ID
3 SUB_STATION_03 1 SUB_STATION_03_1 5 SUB_STATION_03_5
1
The following VSC DC devices have been blocked, or converters taken out of service:
X--VSC DC--X X------ CONVERTER BUS ------X CTRL X------ CONVERTER BUS ------X CTRL
X-- NAME --X MDC BUS#-SCT X-- NAME --X BASKV TYPE BUS#-SCT X-- NAME --X BASKV TYPE
VDCLINE1 1 3005 WEST 230.00 2 3008 CATDOG 230.00 0
Figure 26-16. Isolate by Breaker Report
26-22
Program Operation Manual Restore from Isolate
One or more isolate operations can be sequentially performed, with the network state reflecting the
comprehensive outcome. To restore the network to its state prior to the first isolate operation, use
the Restore from Isolate activity, described below.
26.13 Restore from Isolate

The Restore from Isolate activity restores the working case to the state is was in just prior to the
initial Isolate, or to the state prior to the first Isolate operation after a previous Restore.
To run the Restore from Isolate activity, select Node-Breaker>Restore from Isolate. The opera-
tion will be immediate, with no dialog window. When complete, a message will be displayed to the
Progress area:
Working case restored to state prior to ISOLATE actions
The Restore from Isolate operation can also be performed from the diagram by doing a right-
mouse-click on any component in the diagram, and selecting Restore from Isolate.
The resetting of all network states back to their pre-isolation values will be reflected in the working
case.
26-23
Restore from Isolate Program Operation Manual
26-24
Appendix A
Activity Summary
Each PSS®E activity performs a specific single function. Each activity requires that certain data be
Appendix A - Activity Summary
present in working memory and/or in one or more of the PSS®E temporary files, and may influence
the contents of working memory and/or the temporary files. The following table summarizes many
of PSS®E activities, together with their prerequisites and brief descriptions of their functions.
A-1
Activity Summary
Table A-1. PSS®E Activities
Working Case
Icon Navigation, [GUI], Tab Selection Activity ID Function Requirement(s) Activity Prerequisite(s)
File>New… Create a new case, case with diagram,
--- ---
[New] diagram, or plot book.
File>Open… Open power flow Saved Case file and Previous contents of the
CASE Saved Case file (*.sav)
[Open] establish it as the working case. working case overwritten.
Generators represented as
current sources (activity
File>Open… Validly specified power flow CONG must have been
DYRE Read a Dynamics Data File case, solved to an accept- executed).
[Open] able mismatch level.
Dynamics Model Raw Data
File (*.dyr)
File>Open… Add machines to an existing plant, enter

Validly specified power flow Machine Impedance Data
A-2
MCRE machine impedance data, and split the

[Open] case. file (*.rwm)
plant loading among individual machines.
File>Open… Read power flow source data records Validly specified power flow Power Flow Raw Data file
RDCH
[Open] from a file case. (*.raw)
If reading change data, the

File>Open… Read power flow source data records working case must contain a
READ ---
[Open] from a file. validly specified power flow
case.

File>Open… Read transaction raw data from a Trans-
Validly specified power flow Transactions Raw Data File
REMM actions Raw Data File, replacing all
[Open] case. (*.mwm)
existing transaction data.
Positive sequence network
File>Open… where sequence data is to
RESQ Read sequence data for fault analysis Sequence Data file (*.seq)
PSS®E 34.2
[Open] be read must be present in
the working case.
Table A-1. PSS®E Activities (Cont.)

PSS®E 34.2
Working Case
File>Open… Validly specified power flow Optimal Power Flow Data
ROPF Read optimal power flow data.
[Open] case. File (*.rop)
File>Open… Restore dynamics working memory from Dynamics Snapshot Data

RSTR ---
[Open] a binary Snapshot File File (*.snp)
Read a Source Form Snapshot File into current sources (activity
File>Open… Validly specified power flow CONG must have been
dynamics working memory. The previous
SRRS case, solved to an accept- executed).
[Open] contents of dynamics working memory
able mismatch level.
are destroyed. Dynamics Snapshot Raw
Data file (*.srs).
File>Save…
Validly specified power flow
[Save Network Data] SAVE Create Saved Case file (*.sav) ---
A-3
case.
Case Data
File>Save… case. Generators represented as
Write simulation model data in the form of current sources (activity
[Save / Show Dynamics Data] DYDA Dynamics data must be
a Dynamics Data File. CONG must have been
Dynamics Model Data present in dynamics working executed).
memory.
File>Save…
[Save Network Data] RAWD Create Power Flow Raw Data file. ---
case.
Power Flow Raw Data
File>Save… Write working case as IEEE Common
Activity Summary
Format for the Exchange of Solved Load Validly specified power flow
[Save Network Data] RWCM ---
Flow Cases. The 132-character record case.
IEEE Format Power Flow Data tape format is used.
Activity Summary
Working Case
Write dynamic model data of plant-related
models:
• Inertia and Governor Response
File>Save… Data File (for activity INLF) Validly specified power flow
case. Dynamics data must
[Save / Show Dynamics Data] RWDY • Breaker Duty Data File (for activity ---
be present in dynamics
Machine Parametric Source Data BKDY) working memory.
• branch impedance data for
branches with relay models (for the
PSSPLT activity RELY)
File>Save… case. If generator reactive Machine impedance data
powers are to be used in must be correctly specified
[Save Network Data] RWMA Create Machine Impedance Data file.
calculations, the case must for those machines to be
A-4
Machine Impedance Data be solved to an acceptable processed.

mismatch level.
File>Save…
Write transaction data in format suitable Validly specified power flow
[Save Network Data] RWMM ---
for activity REMM. case.
Transaction Data
File>Save… Validly specified power flow
Create Optimal Power Flow Raw Data
[Save Network Data] RWOP case with optimal power ---
File

Optimal Power Flow Data flow data appended to it.
File>Save… Validly specified power flow

[Save Network Data] RWSQ Create Sequence Data File case with sequence data ---
Sequence Data appended to it.
File>Save…
PSS®E 34.2
Dynamics working memory
Save a Snapshot of dynamics working
[Save / Show Dynamics Data] SNAP must contain the appropriate ---
memory in a binary file.
Snapshot Data dynamics data.

PSS®E 34.2
Working Case
File>Save… Write channel selections from an existing Dynamics data must be
[Save / Show Dynamics Data] DMPC simulation setup to a new Snapshot in present in dynamics working ---
Dump Output Channels Response File format. memory.
File>Scenarios>New Scenario…
Create a new PSS®E study.
[Save As]
File>Scenarios>Open Scenario…
Open an existing PSS®E study.
[Open]
File>Scenarios>Save Scenario… Save an existing PSS®E study.
Close an existing PSS®E study without

File>Scenarios>Close Scenario
saving changes.
A-5
File>Scenarios>Edit Scenario…
Edit an existing PSS®E study.
[PSS®E Scenario Editor]
Compare selected totals of power flow
File>Compare… case. Both cases solved to
data and solution results contained in the
--- CMPR an acceptable mismatch Saved Case file (*.sav)
Case Totals working case and a designated Saved
level if comparing losses,
Case.
mismatches, or interchange.
Compare selected power flow data, fault case. Both cases solved to
File>Compare… analysis data, and solution results an acceptable mismatch
--- DIFF Saved Case file (*.sav)
Powerflow Cases contained in the working case and a level if comparing bus volt-
Activity Summary
designated Saved Case. ages, line flows, or line
losses.
Activity Summary
Working Case
File>Compare… Compare selected power flow data, fault
case. Both cases solved to
analysis data, and solution results of
--- [Compare] DFTI an acceptable mismatch Saved Case file (*.sav)
subsystem tie lines contained in the
Tie Lines level if comparing line flows
working case with a Saved Case.
or line losses.
File>File information
(SIZE/SHOW/BUSN)… List unused bus numbers in a specified Validly specified power flow
--- BUSN
[File Information] bus number range case.
List unused bus numbers in a range
(SIZE/SHOW/BUSN)…
--- SHOW List Saved Case and Snapshot files. None
[File Information]
A-6
List Save case and Snapshot files

(SIZE/SHOW/BUSN)…
--- [File Information] SIZE List the number of system components. Non-null power flow case.
List the number of system
components
File>Case titles, short & long … Re-enter individual lines of the 16 line
--- CHTI Non-null power flow case.
[Case Titles] long title.

File>Import>Long Title… Accept source data records from a file or
--- RETI the and place them into the 16 line long Non-null power flow case.
[Select file containing long case title] title.
File>Import>ECDI File
---
PSS®E 34.2
[Economic dispatch data file]

PSS®E 34.2
Working Case
If bus voltages and/or line
File>Import>DRAW file… Import a one-line diagram of a portion of flows are to be printed, Diagram View
--- DRAW the working case from prior version of validly specified power flow
[Open] PSS®E. case solved to an accept- Draw Data file (*.drw)
able mismatch tolerance.
File>Import>Image file… Diagram View
---
[Open] Bitmap file (*.bmp)
File>Renumber buses in auxiliary
files (RNFI)…
List changes in bus numbers created by Bus Number Translation
[Renumber Buses in Auxiliary Files] activity BSNM for the auxiliary data input
Validly specified power flow file (*.trn) containing
--- or RNFI files used by activities RESQ, GDIF, records of the form:
case.
File>Renumber buses in Diagram DYRE, MCRE, ECDI, INLF, BKDY,
ASCC, GCAP, ACCC, and ANSI. old bus # new bus #
(RNFI)…
A-7
[Bus number translation file]

--- File>Exit STOP Close all PSS®E files and exit None
Edit>Preferences… Specify GUI performance and file
--- None
[Program Preferences] management.
Diagram>Annotation… Validly specified power flow

Annotate and color-code one-line
[Powerflow Data Annotation] case solved to an accept- Diagram View
diagram.
[Diagram Range Checking] able mismatch level.
Diagram>Generate graphical report

(GRPG)…
case solved to an accept-
Send a specified drawing to a specified Graphical Report Data file
Activity Summary
[Graphical Report Data file] GRPG able mismatch level if
graphics output device. (*.grp)
Graphical Report Data file (*.grp) network data is to be
[Terminal Read] included on the drawing.
Activity Summary
Working Case
Diagram>Generate graphical power Validly specified power flow
flow bus display (GOUT/GEXM)… GOUT/G Display power flow solution results in
EXM graphical form for one bus at a time.
[Select Bus] able mismatch level.
Locate bus (icon only) Validly specified power flow

Locate a specified bus on one-line
case solved to an accept- Diagram View
[Select Bus] diagram.
Diagram>Results>Powerflow Display power flow solution results on
case solved to an accept- Diagram View
results one-line diagram.
Display impedance data from power flow
Diagram>Results>Impedance data case solved to an accept- Diagram View
solution results on one-line diagram
A-8

Diagram>Results>Graphical differ- Compare differences in power flow solu- case.
ence data… GDIF tion results and power flow boundary Diagram View
condition data with a Saved Case. Both cases solved to an
[Compare Cases on a Diagram]
acceptable mismatch level.
Diagram>Results>ASCC Fault anal-
ysis results… Display three phase and single line to
Diagram View
ground faults on one-line diagram.
[Display Fault Analysis Results]
Diagram>Results>IEC Fault Anal- Display IEC fault analysis results on one-

Diagram View
ysis results line diagram.
Diagram>Results>Reliability Anal- Display probabilistic reliability results on

Diagram View
ysis results one-line diagram.
Diagram>Results>Dynamics Anal- Display dynamic analysis results on one-

Diagram View
PSS®E 34.2
ysis results line diagram.

PSS®E 34.2
Working Case
Power Flow>Solution>
Parameters…
[Solution Parameters]
Power Flow>Solution>Solve Validly specified power flow
(NSOL/FNSL/FDNS/SOLV/ MSLV)… Apply a decoupled Newton-Raphson
case with voltages that are a
NSOL power flow iteration to the network
[Loadflow solutions] reasonable estimate of a
modeled in the working case.
Newton solution.

(NSOL/FNSL/FDNS/SOLV/ MSLV)… Apply the Newton-Raphson power flow
FNSL iteration to the network modeled in the
working case.
Newton solution.
Power Flow>Solution>Solve
A-9

(NSOL/FNSL/FDNS/SOLV/ MSLV)… Apply a fixed slope decoupled Newton-
FDNS Raphson power flow iteration to the
network.
Newton solution.

(NSOL/FNSL/FDNS/SOLV/ MSLV)… Apply Gauss-Seidel power flow iteration case with voltages that are a
SOLV No series capacitors.
[Loadflow solutions] to the network. reasonable estimate of a
Gauss solution.
Power Flow>Solution>Solve Validly specified power flow The working case may
(NSOL/FNSL/FDNS/SOLV/ MSLV)… Apply modified Gauss-Seidel power flow
case with voltages that are a contain series capacitors
MSLV iteration to the network modeled in the
[Loadflow solutions] reasonable estimate of a only between Type 1
working case.
Activity Summary
Gauss solution. buses.
Power Flow>Solution>AC contin- Validly specified power flow Distribution Factor Data
gency solution (ACCC)… Calculate and report contingency case
ACCC case solved to an accept- File corresponding to the
power flow solutions.
[AC Contingency Solution] able mismatch tolerance. network condition.
Activity Summary
Working Case
Power Flow>Solution>Multi-Level
AC contingency solution…
[Multi-Level AC Contingency Solution]
Power Flow>Solution>Implement
Generation dispatch…
[Implement Generation Dispatch]
Power Flow>Solution>AC correc-
tive actions…
[AC Corrective Actions]
Data changes specified.
Power Flow>Solution>N-R solution Solve the network contained in the No prior power flow solu-
with inertial governor dispatch working case. Validly specified power flow tions in working case.
A-10
(INLF)… INLF Activity INLF may be used either as an case, solved in the pre- Inertia and Governor
[N-R Solution with Inertial / Governor inertial power flow or as a governor event condition. Response Data File (*.inl)
Redispatch] response power flow. containing machine data
for all in-service machines.
Perform the optimal ordering function,
Power Flow>Solution>Order setting up an internal ordering of system
network for matrix operations buses to optimize the sparsity of the Validly specified power flow
(ORDR)… ORDR
Jacobian and triangularized admittance case.

[Order Network] matrices used in the network solution
activities.
Decompose the admittance matrix of the
network contained in the working case Activities CONG and
Power Flow>Solution>Factorize Validly specified power flow
FACT into its triangular factors for subsequent CONL (normally)
admittance matrix (FACT) case.
use in activity TYSL and in the network executed.
PSS®E 34.2
solution used in dynamic simulations.

PSS®E 34.2
Working Case
Validly specified power flow Activities CONG, CONL
Power Flow>Solution>Solution for Solution intended for the solution of case with voltages corre- (normally), and ORDR
switching studies (TYSL)… network conditions at the instant following sponding to the preswitching executed.
TYSL
the execution of a switching operation or network condition, and with
[Solution for Switching Studies] fault application. impedance data specified Switching applied and
for all machines. activity FACT executed.
Power Flow>Solution>PV
analysis…
[PV Analysis]
Power Flow>Solution>PV analysis
using previous results…
[PV Parameters]
A-11
Power Flow>Solution>Implement
PV transfer…
[Implement PV Transfer]
Power Flow>Solution>QV
analysis…
[QV Analysis]
Power Flow>Solution>QV analysis
using previous results…
[QV Parameters]
Perform data changes necessary to elec-
Power Flow>Changing>Discon- trically disconnect selected buses in the
Activity Summary
nect/Reconnect bus working case. For each bus specified, the Validly specified specified
(DSCN/RECN)… DSCN
bus type code is set to four and all power flow case.
[Disconnect / Reconnect Bus] branches connected to the bus are
placed out-of-service.
Activity Summary
Working Case
Power Flow>Changing>Discon-
nect/Reconnect bus Perform the data changes necessary to
(DSCN/RECN)… RECN electrically reconnect selected buses in
case.
the working case.
Power Flow>Changing>Join buses Joins pairs of buses, retaining the identity
(JOIN)… Validly specified power flow
JOIN of one of the two buses and removing the
case.
[Join Buses] other completely from the working case.
Power Flow>Changing>Split buses

(SPLT)… Split buses, introducing an additional bus Validly specified power flow
SPLT
for each split bus. case.
[Split Buses]
Power Flow>Changing>Tap line Tap any nontransformer ac branch at a
(LTAP)… Validly specified power flow
LTAP designated location along the line, intro-
A-12
case.
[Tap Line] ducing a new bus.
Power Flow>Changing>Move Disconnect the to bus ends of selected

network elements (MOVE)… branches and reconnect them to different Validly specified power flow
MOVE
buses. Move selected loads, switched case.
[Move Network Elements] shunts, machines and plants.
Power Flow>Changing>Delete
network elements (PURG/EXTR)… Remove outaged equipment from the
PURG working case, packing all tables to
[Delete Buses and Outaged Network case.

remove gaps in numeric sequence.
Elements]
Power Flow>Changing>Delete
network elements (PURG/EXTR)… Remove buses and their connected
equipment from the working case, Validly specified power flow
[Delete Buses and Outaged Network EXTR
packing all tables to remove gaps in case.
Elements]
PSS®E 34.2
numeric sequence.
Remove Buses from Case

PSS®E 34.2
Working Case
Modify total load, generation (positive case. If generation is to be
Power Flow>Changing>Scale generator powers), motor load (negative scaled, and a Type 3 bus is
generation, load, shunt (SCAL)… SCAL generator powers), bus connected capac- in the subsystem being
[Scale Powerflow Data] itors, and/or bus connected reactors in a scaled, the working case
specified subsystem of the working case. must be solved to an
acceptable mismatch level.
Power Flow>Changing>Trans- Set the tap adjustment enable flags of all

former adjustment flags (TFLG) adjustable transformers connecting spec- Validly specified power flow
TFLG
ified buses to either zero (disable) or one case.
[Transformer Adjustment Flags] (enable).
Power Flow>Changing>Economic Perform a unit commitment and economic
Dispatch (ECDI) Validly specified power flow Economic Dispatch Data
ECDI dispatch calculation for machines
case. File (*.ecd)
A-13
[Economic Dispatch] residing in the working case.
Allows the user to change the status of

induction machines that are in-service,
Power Flow>Changing>Outage but that have been set to the "stalled" (for Validly specified power flow Economic Dispatch Data
ImOutage
"stalled"/"tripped" induction machines motors) or "tripped" (for generators) state case. File (*.ecd)
by the power flow solution, to out-of-
service.
Power Flow>Reports>Area/zone Summarize area interchange between an

based reports… area and every other area. Interchange is Validly specified power flow
INTA evaluated on the basis of the metering case solved to an accept-
points designated for each area tie able mismatch tolerance.
Inter area/zone flow>Output for Areas branch.
Activity Summary
Power Flow>Reports>Area/zone Summarize zone interchange between a
based reports… zone and every other zone. Interchange Validly specified power flow
INTZ is evaluated on the basis of the metering case solved to an accept-
points designated for each zone tie able mismatch tolerance.
Inter area/zone flow>Output for Zones branch.
Activity Summary
Working Case
Power Flow>Reports> Area/zone
based reports… Validly specified power flow
List a summary of the loadings on all ties
TIES case solved to an accept-
[Area / Zone Based Reports] from each interchange area
Tie line>Output for Areas
Power Flow>Reports> Area/zone
based reports… Validly specified power flow
List a summary of the loadings on all ties
TIEZ case solved to an accept-
[Area / Zone Based Reports] from each zone
Tie line>Output for Zones
Power Flow>Reports> Area / owner Report generation, load, bus shunt, line
/ zone totals… Validly specified power flow
shunt, line charging, losses, net inter-
AREA case solved to an accept-
[Area / Owner / Zone Totals] change, desired net interchanges for
Report on Areas areas.
A-14
Power Flow>Reports> Area / owner

/ zone totals… Report summary of owner totals of gener- Validly specified power flow
OWNR ation, load, bus shunt, line shunt, line case solved to an accept-
charging, and losses in the working case. able mismatch tolerance.
Report on Owners
Power Flow>Reports> Area / owner
/ zone totals… Validly specified power flow
ZONE Report zone totals case solved to an accept-

Report on Zones
Power Flow>Reports>Bus based Wide format power flow solution output
reports… activity, including branch current loadings Validly specified power flow
[Bus Based Reports] LAMP in amps case solved to an accept-
Powerflow output>Wide format Activity LAMP lists the mismatch at a bus able mismatch tolerance.
PSS®E 34.2
output>Output with amps only when it exceeds 0.5 MVA.

PSS®E 34.2
Working Case
Power Flow>Reports>Bus based
reports… Wide format power flow solution output Validly specified power flow
LOUT activity. Activity LOUT lists the mismatch case solved to an accept-
[Bus Based Reports]
at a bus only when it exceeds 0.5 MVA. able mismatch tolerance.
Powerflow output>Wide format output
reports… Narrow format power flow solution output Validly specified power flow
POUT activity. List bus mismatch only when it case solved to an accept-
[Bus Based Reports]
exceeds 0.5 MVA. able mismatch tolerance.
Powerflow output
reports… Validly specified power flow
Summarize conditions of power flow
SUBS case solved to an accept-
[Bus Based Reports] working case.
Subsystem summary / totals
A-15
Power Flow>Reports>Limit Read machine capability curve data and

checking reports… check var loadings and limits against
Validly specified power flow Machine Capability Data
GCAP Machine Capability Curve Data File.
[Limit Checking Reports] case. File (*.gcp)
Machine reactive power limits may be
Reactive capability updated.
List generating plant loading data Validly specified power flow
Power Flow>Reports>Limit including power output, reactive power case. Plant outputs and volt-
checking reports… limits, and scheduled and actual voltage. ages are valid only if the
GENS
[Limit Checking Reports] The report may be limited to plants at a working case is solved to an
Generator bus reactive power limit, in-service plants, or acceptable mismatch
all plants. tolerance.
Activity Summary
Power Flow>Reports>Limit Print a summary of in-service machines case. Machine outputs and
checking reports… including power output, terminal voltage, voltages are valid only if the
GEOL
[Limit Checking Reports] and current. The report may be restricted working case is solved to an
Machine terminal to overloaded machines. acceptable mismatch
tolerance.
Activity Summary
Working Case
Power Flow>Reports>Limit
checking reports… List transmission lines where current Validly specified power flow
OLTL loading is greater than a specified case solved to an accept-
percentage of the selected rating. able mismatch tolerance.
Branches
checking reports… List transformers where MVA loading is Validly specified power flow
OLTR greater than a specified percentage of the case solved to an accept-
selected rating. able mismatch tolerance.
Branches
checking reports… Check current flow in each ac series Validly specified power flow
RAT3 branch for which at least one nonzero case solved to an accept-
rating is specified able mismatch tolerance.
Branches
A-16
checking reports… Check current flow in each ac series Validly specified power flow
RATE branch for which a nonzero rating is case solved to an accept-
specified able mismatch tolerance.
Branches
Power Flow>Reports>Limit Validly specified power flow

List voltage controlled buses and their
checking reports… case. Bus voltages are valid
controlling equipment: local and remote
REGB only if the working case is
[Limit Checking Reports] generators, switched shunts, trans-
solved to an acceptable

Regulated buses formers, and FACTS devices.
mismatch tolerance.
Power Flow>Reports>Limit List controlling transformer summary
checking reports… Validly specified power flow
where ratio or phase shift angle may be
TLST case solved to an accept-
[Limit Checking Reports] adjusted by the power flow solution
activities
PSS®E 34.2
Controlling transformer

PSS®E 34.2
Working Case
checking reports… Validly specified power flow
List buses where per unit voltage magni-
VCHK case solved to an accept-
[Limit Checking Reports] tude is outside a specified range
Out-of-limit bus voltage
Power Flow>Reports>AC Contin-
gency reports…
Power Flow>Reports>Append to
AC Contingency solution output
file…
Power Flow>Reports>Multiple AC
A-17
Contingency run report…

[Multiple AC Contingency Run Report]
Report network conditions within the dc
network formed by each unblocked multi-
Power Flow>Reports>Multi- terminal dc line. Results listed include the
section / able mismatch tolerance.
terminal DC line solution output dc voltage at each dc bus, flows between
MTDC Unblocked multiterminal dc
(MTDC) the dc network and the ac converter
lines must be present in the
station buses, and flows on each dc link
working case.
in the network.
Power Flow>Reports>Export
ACCC, PV/QV results to Excel…
[Export PSS®E Data/Result to Excel]
Activity Summary
Activity Summary
Working Case
Power Flow>Convert Loads and
Generators… Convert all online machines from their
Validly specified power flow Machine impedance data
power flow representation to the Norton
[Convert / Reconstruct Loads and CONG case solved to an accept- must be correctly specified
current source model used in dynamic
Generators] able mismatch level. for all online machines.
simulations and switching studies.
Convert Generators>Use ZSOURCE
Power Flow>Convert Loads and Convert constant MVA loads to a speci-
Generators… fied mixture of constant MVA, constant
[Convert / Reconstruct Loads and current, and constant admittance loads. A
CONL case solved to an accept-
Generators] different split among the three character-
Convert/Reconstruct Loads>Convert istics may be specified for the real and
constant MVA loads reactive components of load.
Power Flow>Convert Loads and Validly specified power flow

A-18
Generators… Reconstruct power, current, and imped- case. If the existing voltage
ance loads at selected buses and then vector is used in the load
[Convert / Reconstruct Loads and RCNL
convert to a new specified mix of constant reconstruction, the working
Generators]
power, current, and impedance case must be solved to an
Convert/Reconstruct Loads acceptable mismatch.
Power Flow>Equivalence
Networks…>Net boundary bus Model the net inflow at boundary buses
mismatches (BGEN) as equivalent generation and/or load. A Validly specified subsystem
BGEN
[Equivalence Networks] bus is assumed to be a boundary bus if of a solved power flow case.

Net boundary bus mismatches its mismatch exceeds 0.5 MVA.
(BGEN)
Networks…>Build electrical equiva- Build an electrical equivalent of Type 1 Validly specified power flow
lent (EEQV) EEQV buses in the specified subsystem of the case solved to an accept-
PSS®E 34.2
[Equivalence Networks] working case. able mismatch level.
Build electrical equivalent (EEQV)

PSS®E 34.2
Working Case
Networks…> Equivalence radial / 2- Build an electrical equivalent of all radial
point buses (EQRD/RDEQ) Validly specified power flow
and, optionally, two-point Type 1 buses,
EQRD case solved to an accept-
[Equivalence Networks] except those connected to three-winding
Equivalence radial / 2-point buses transformers.
(EQRD/RDEQ)
Power Flow>Equivalence Build an electrical equivalent of radial

Networks…> Equivalence radial / 2- and, optionally, two-point Type 1 buses,
point buses (EQRD/RDEQ) except those connected to three-winding Validly specified power flow
RDEQ transformers. When sequence data is case solved to an accept-
contained in the working case, the zero able mismatch level.
Equivalence radial / 2-point buses sequence network is also calculated as
(EQRD/RDEQ) an electrical equivalent.
A-19
Networks…>Net generation with Net generation with the load at all but
load (NETG/GNET/IMNET) Validly specified power flow
specified generator buses. The type code
NETG case solved to an accept-
[Equivalence Networks] of any bus where generation is netted is
Net generation with load changed to one.
(NETG/GNET)
Networks…>Net generation with Net the generation with the load at speci-
load (NETG/GNET/ImNet) Validly specified power flow
fied generator buses. The type code of
GNET case solved to an accept-
[Equivalence Networks] any bus where generation is netted is
Net generation with load changed to one.
(NETG/GNET)
Activity Summary
Networks…>Build three sequence Build a three sequence equivalent of a Validly specified power flow
Sequence data included in
equivalent (SCEQ) SCEQ subsystem of the working case under case reflecting classical fault
the case (activity RESQ).
classical fault analysis assumptions. analysis assumptions.
Activity Summary
Working Case
Power Flow>Equivalence Net induction motors with the load at
Networks…>Net Generation Validly specified power flow
specified generator buses. The type code
ImNet case solved to an accept-
With load (NETG/GNET/ImNet) of any bus where generation is netted is
[Equivalence Networks] changed to one.
Power Flow>Equivalence Net induction motors with the load at all

Networks…>Net Generation Validly specified power flow
but specified generator buses. The type
NetIm case solved to an accept-
With load (NETG/GNET/ImNet) code of any bus where generation is
[Equivalence Networks] netted is changed to one.
Power Flow>Linear Network>DC Apply the dc analogy network solution Validly specified power flow
network solution and report algorithm to the network in the working case, normally solved to an
(DCLF)… DCLF
case and, optionally, to that network with acceptable mismatch
[DC Network Solution and Report] the status of a specified branch changed. tolerance.
A-20
When ranking contingen-

Power Flow>Linear Network>Single cies with respect to line
Estimate the severity of single branch Validly specified power flow
contingency ranking (RANK)… overloading, Subsystem
RANK outage contingencies on the basis of a case solved to an accept-
Description Data File and
[Single Contingency Ranking] linearized network model. able mismatch tolerance.
Monitored Element Data
File
Power Flow>Linear
Network>Create/modify SUB, MON

and CON configuration files…
[Configuration File Builder]
PSS®E 34.2

PSS®E 34.2
Working Case
For subsystem definition
and monitored element
Power Flow>Linear Network>Build Build a Distribution Factor Data File in the
specification: Subsystem
distribution factor data file form required by the linear network anal- Validly specified power flow
Description Data File,
(DFAX)… DFAX ysis activities OTDF, DCCC, TLTG, SPIL, case solved to an accept-
Monitored Element Data
POLY, IMPC, and LLRF, and by the AC able mismatch tolerance.
[Build Distribution Factor Data File] File, Contingency Descrip-
Contingency Solution.
tion Data File or manual
entry of data.
Power Flow>Linear Network>DC Estimate contingency case line flows for Distribution Factor Data
contingency checking (DCCC)… single or multiple event contingency File corresponding to the
DCCC case solved to an accept-
cases on the basis of a linearized network network condition in the
[DC Contingency Checking] able mismatch tolerance.
model. working case.
Power Flow>Linear Network>DC
A-21
corrective actions…
[DC Corrective Actions]
Power Flow>Linear Network>Calcu-
late and print distribution factors Report distribution factors corresponding Validly specified power flow Distribution Factor Data
(OTDF)… OTDF to single event contingency cases for a case solved to an accept- File (*.dfx) corresponding
[Select Distribution Factor data file to set of monitored lines and interfaces. able mismatch tolerance. to the network condition.
calculate factors for]
Power Flow>Linear Network>Trans-
mission interchange limits Distribution Factor Data
calculation (TLTG)… Transmission interchange limits File corresponding to the
TLTG case solved to an accept-
calculation network condition in the
[Transmission Interchange Limits able mismatch tolerance.
working case
Calculation]
Activity Summary
Activity Summary
Working Case
File corresponding to the
Power Flow>Linear Estimate the transmission interchange network condition in the
Network>Sequential participation limits of a specified subsystem on the working case.
interchange limit (SPIL)… basis of a linearized network model. Inter-
SPIL case solved to an accept- Subsystem Participation
change limits are calculated for the base
[Sequential Participation Interchange able mismatch tolerance. Data File corresponding to
case and for single or multiple event
Limit] contingency cases. the subsystem definitions
in the Distribution Factor
Data File.
Power Flow>Linear Network>Inter-
change limits with two opposing Estimate the transmission interchange
Validly specified power flow Distribution Factor Data
systems (POLY)… limits of a specified subsystem with two
POLY case solved to an accept- File corresponding to the
opposing systems on the basis of a
[Interchange Limits with Two able mismatch tolerance. network condition.
linearized network model.
A-22
Opposing Systems]
Power Flow>Linear Network>Inter-
change limits calculations (POLY) -
previous results…
[Interchange limits with two opposing
systems (POLY) - parameters]
Power Flow>Linear
Network>Midwest MW-mile calcula-
Contact Midwest ISO
MWMI Supports Midwest ISO planning modules. (http://www.midwes-

tion (MWMI)…
tiso.org/home).
[Midwest MW-miles calculation]
Power Flow>Reliability>Reliability
assessment …
[Probabilistic Reliability Assessment]
PSS®E 34.2
Power Flow>Reliability>Substation
reliability assessment …
[Substation Reliability Assessment]

PSS®E 34.2
Working Case
Power Flow>List Data…
Report buses in the working case in Validly specified power flow
[List Data] ALPH
alphabetical order. case.
Bus names
List power flow data: all components
Power Flow>List data… connected to the bus including all trans-
[List Data] EXAM mission lines, transformers, dc lines, and Non-null power flow case.
Examine Powerflow / sequence data FACTS devices originating or terminating
on that bus.
Report power flow data contained in the
[List Data] LIST Non-null power flow case.
working case.
Powerflow>All data
Power Flow>List Data… Validly specified power flow
A-23
Report optimal power flow data contained

[List Data] LSTO case with optimal power
in the working case.
OPF flow data appended to it.

[List Data] OUTS List outaged equipment. Non-null power flow case.
Outaged equipment
[List Data]
Powerflow>Fixed bus shunts SHNT List bus shunts.
case.
Powerflow>Switched bus shunts or
Powerflow>Fixed bus shunts
Activity Summary
Power Flow>List Data… List all sequence data, including trans- Sequence data must be
[List Data] mission lines, transformers, dc lines, and contained in the working
SQEX Non-null power flow case.
Examine Powerflow / sequence FACTS devices originating or terminating case (i.e., activity RESQ
data>Sequence data on that bus must have been executed).
Activity Summary
Working Case
Power Flow>List Data… Validly specified power flow
[List Data] SQLI List specified category of sequence data case with sequence data
Sequence data appended to it.
Power Flow>Check Data>Branch Perform several checks on the parame-

parameters (BRCH)… BRCH ters associated with ac branches in the Non-null power flow case.
[Check Branch Parameters] working case.
Power Flow>Check Data>Check / Display local and remote generators, Validly specified power flow
Change controled bus scheduled switched shunts, transformers, and case. Bus voltages listed
voltages (CNTB)… CNTB FACTS devices that control voltage at are valid only if the case is
[Check / Change Controlled Bus buses in a designated subsystem of the solved to an acceptable
Scheduled Voltages] working case during power flow solutions. mismatch level.
Power Flow>Check Data>Check /

A-24
Change transformer adjustment Change transformer adjustment data

data (TPCH)… Validly specified power flow
TPCH associated with voltage and flow control-
case.
[Check / Change Transformer Adjust- ling transformers.
ment Data]
List buses not in the tree of a swing bus
Power Flow>Check Data>Buses not Validly specified power flow
TREE by island, along with island load, shunt
in swing bus tree (TREE) case.
and generation totals.
Power Flow>Renumbering Areas /

Owners / Zones…
Validly specified specified
[Renumbering Areas / Owners / ARNM Re-assign buses to a specified area
power flow case.
Zones]
Area assignments>Reassign Buses
PSS®E 34.2

PSS®E 34.2
Working Case
Owners / Zones…
[Renumbering Areas / Owners / Change the area numbers of selected Validly specified power flow
LDAR
Zones] loads in the working case. case.
Area assignments>Reassign
Buses/Loads
Owners / Zones… Change the ownership assignments of
selected buses, loads, machines, Validly specified power flow
[Renumbering Areas / Owners / OWNM
branches, FACTS devices, and/or VSC case.
Zones]
dc lines in the working case.
Reassign …
A-25
Owners / Zones…
[Renumbering Areas / Owners / Change the zone numbers of selected Validly specified power flow
LDZO
Zones] loads in the working case. case.
Zone assignments>Reassign
Buses/Loads
Owners / Zones…
[Renumbering Areas / Owners / ZONM Change zone numbers of buses
case.
Zones]
Zone assignments>Reassign Buses
Activity Summary
Activity Summary
Working Case
Power Flow>Renumber buses>By
Bus Number…
[Renumber Buses by Bus Number]
Bus Name…
[Renumber Buses by Bus Name] Change the numbers of selected buses in
BSNM the working case. A file recording the bus
Power Flow>Renumber buses>By case.
number changes may be generated.
Packing…
[Renumber Buses by Bus Packing]
Subsystem…
[Renumber Buses by Subsystem]
A-26
Fault>Setup for special fault calcu- Set the voltages of all buses in the
lations (FLAT)… Validly specified power flow
FLAT working case to one per unit at zero
case.
[Setup for Special Fault Calculations] phase angle.
Build and factorize the three sequence

admittance matrices in preparation for the Validly specified power flow
Fault>Setup network for unbal- unbalanced network solution case, with sequence data
anced solution (SEQD)… activity SCMU and for the branch unbal- appended, solved to an
SEQD ance activity SPCB. acceptable mismatch level
[Setup Network for Unbalanced with bus voltages corre-

Solution] Setup network for unbalanced solution sponding to prefault network
may also be performed from the SCMU condition.
and SPCB dialogs.
Fault>ANSI fault calculation Validly specified specified

(ANSI)… Calculate fault currents according to the power flow case with
ANSI
ANSI standard C37.5-1979. sequence data appended to
PSS®E 34.2
[ANSI Fault Current Calculation] it.

PSS®E 34.2
Working Case
IEC Fault Calculation Data
Fault>IEC 60909 fault calculation
file (*.iec)
(IECS)… IECS IEC 60909 fault calculation
Fault Control Data file
[IEC 60909 Fault Calculation]
(*.fcd)
Fault>Automatic sequence fault
calculation (ASCC)… Calculate and report three phase and Validly specified power flow
ASCC single line to ground faults at all buses in case with sequence data
[Automatic Sequence Fault a specified subsystem. appended to it.
Calculation]
CONG must have been
Fault>Circuit breaker interrupting Calculate and report circuit breaker inter- executed).
duty (BKDY)… rupting duty for three phase faults at all
BKDY case must reflect the pre- Normally, the load charac-
A-27
buses in a specified subsystem of the

[Circuit Breaker Interrupting Duty] fault network condition. teristics must be modified
working case.
with CONL prior to
execution.
Breaker Duty Data File.
case with sequence data
Fault>Separate pole circuit breaker appended to it. It must be The branch to have the
(SPCB)… Calculate the positive sequence pi-equiv-
SPCB solved to an acceptable unbalance must be
alent of a single branch unbalance.
[Separate Pole Circuit Breaker] mismatch level with bus removed from service.
voltages corresponding to
the preunbalance condition.
Fault>Solve and report network
Activity Summary
Solve the network in the presence of Validly specified power flow
with unbalances (SCMU/SCOP)… Activity SEQD must be
SCMU unbalanced conditions and print a case with sequence data
successfully executed.
[Multiple Simultaneous Unbalances] summary report. appended to it.
Activity Summary
Working Case
Fault>Unbalanced network tabular Activity SCMU must have

Solve the network in the presence of
output (SCOP)… Validly specified power flow successfully solved the
SCOP unbalanced conditions and print a
case. network in the presence of
[Multiple Simultaneous Unbalances] summary report.
unbalanced conditions.
OPF>Solve… Validly specified power flow

Apply interior point solution to the
NOPF case with optimal power
[OPF Solution] nonlinear power flow network.
flow data appended to it.
OPF>Data…
OPF>Data tables…
[OPF Data Tables]
Modify any of the optimal power flow
A-28
OPF>Parameters… Validly specified power flow

solution option settings currently in effect.
NOPF case with optimal power
[OPF - Change Parameters] Settings can be saved in an Optimal
flow data appended to it.
Power Flow Options File (pssopf.opt).
Trans Access>Data…
Trans Access>Allocations> Mega-
watt shift factors… Generate transmission pricing reports:
[Megawatt Shift Factors] Vector Absolute MW-mile allocation
Transaction events must
matrix, Vector Absolute MW-mile genera-
Trans Access>Allocations> Vector have been previously intro-

tion shift factors, Vector Absolute MW- Validly specified power flow
Absolute MW-mile ALOC duced into working memory
ohm allocation matrix, Vector Absolute case.
Trans Access>Allocations> Vector via activity REMM or the
MW-ohm generation shift factors, Vector
Absolute MW-ohm transaction editor.
Sum MW-ohm allocation matrix, branch
Trans Access>Allocations> Vector mileage summary.
Sum MW-ohm
PSS®E 34.2

PSS®E 34.2
Working Case
Transaction events in
working memory via activity
Trans Access>Calculators>Impact Report incremental MW flow impact on REMM or the transaction
on monitored elements… Validly specified power flow editor.
IMPC monitored elements due to a transaction
case.
[Impact on Monitored Elements] event. Distribution Factor Data
File (*.dfx) corresponding
to the network condition.
Report line loading relief, including: incre- Transaction events previ-

mental changes in transaction event ously introduced into
Trans Access>Calculators>Line
curtailments required to achieve a target working memory via activity
loading relief by transaction
monitored element MW flow adjustment, Validly specified power flow REMM or the transaction
adjustment… LLRF
distribution factors of monitored element case. editor.
[Line Loading Relief by Transaction flow to transaction event magnitude, and Distribution Factor Data
Adjustment] modification of the distribution factor
A-29
File corresponding to the

tolerance. network condition.
Trans Access>Summa-
ries>Summary of branch mileage
by owner
Dynamics>Simulation>Solution
parameters…
[Dynamic Solution Parameters]
Dynamics>Simulation>Simulation
options…
[Dynamic Simulation Options]
Activity Summary
case, solved to an accept- Generators represented as
Dynamics>Simulation>Perform Initialize models for state-space simula- able mismatch level. current sources (activity
STRT
simulation (STRT/RUN)… tion and test initial conditions Dynamics data must be CONG must have been
present in dynamics working executed).
memory.
Activity Summary
Working Case
Advance dynamic simulation through current sources (activity
case.
Dynamics>Simulation>Perform time, solving the network, calculating time CONG must have been
RUN Dynamics data must be executed).
simulation (STRT/RUN)… derivatives, and performing numerical
integration at each time step. present in dynamics working
Activity STRT success-
memory.
fully executed.
Initialize the dynamics models for testing Validly specified power flow
Dynamics>Simulation>Perform case. Generators represented as
excitation system response with indi-
exciter simulation (ESTR/ERUN)… current sources (activity
ESTR vidual units operating in isolation. Dynamics data must be CONG must have been
[Perform Exciter Simulation Test] Activity ESTR overrides manual selec- present in dynamics working executed).
tions of output channel assignments. memory.
Dynamics>Simulation>Perform Validly specified power flow
A-30
exciter response ratio simulation Execute simulation of excitation system case.

CONG must have been
(ESTR/ERUN)… ERUN response with individual units operating in Dynamics data must be executed).
[Perform Exciter Response Ratio isolation. present in dynamics working
ERUN successfully
Simulation Test] memory.
executed.
case, solved to an accept-
Dynamics data must be
Initialize all dynamics models from the

present in dynamics working Generators represented as
Dynamics>Simulation>Perform network conditions contained in the
memory. current sources (activity
extended term simulation MSTR working case in preparation for extended
(MSTR/MRUN)… term simulation calculations (i.e., for All equipment models used CONG must have been
in the system dynamic executed).
activity MRUN).
model must have been
upgraded for use in the
PSS®E 34.2
extended term simulation
mode.

PSS®E 34.2
Working Case
Dynamics>Simulation>Perform Advance the extended term dynamic Validly specified power flow
extended term simulation simulation through time, solving the case.
CONG must have been
(MSTR/MRUN)… MRUN network, calculating time derivatives, and Dynamics data must be executed).
[Perform Extended Term Dynamic performing numerical integration at each present in dynamics working
time step. Activity MSTR success-
Simulation] memory.
fully executed.
Initialize the dynamics models for testing
Dynamics>Simulation>Perform the governing response of individual units Validly specified power flow
governor response simulation case. Generators represented as
in isolation. Output channel assignments
(GSTR/GRUN)… current sources (activity
GSTR are overridden, and the speed deviation Dynamics data must be CONG must have been
[Perform Governor Response and mechanical power of each machine present in dynamics working executed).
Simulation] with a connected governor model are memory.
placed into output channels.
A-31
Dynamics>Simulation>Perform Validly specified power flow
governor response simulation Execute a simulation of the governing case.
CONG must have been
(GSTR/GRUN)… GRUN response of individual units operating in Dynamics data must be executed).
[Perform Governor Response isolation. present in dynamics working
Activity GSTR success-
Simulation] memory.
fully executed.
Dynamics>Channel Setup Wizard
[Channel Setup Wizard]
Activity Summary
Activity Summary
Working Case
Dynamics>Define simulation
output (CHAN)>Bus quantity
[Assign Channels for Bus Quantities]
output (CHAN)>Line quantity
[Assign Channels for Line Quantities] Validly specified power flow
Dynamics>Define simulation case, solved to an accept- Generators represented as
output (CHAN)>Load quantity Designate quantities which are to be able mismatch level. current sources (activity
CHAN monitored during dynamic simulation
[Assign Channels for Load Quantities] Dynamics data must be CONG must have been
calculations
Dynamics>Define simulation present in dynamics working executed).
output (CHAN)>Machine quantity memory.
[Assign Channels for Machine
A-32
Quantities]
output (CHAN)>Misc quantity
[Assign Channels for Misc. Quantities]
case, solved to an accept- Generators represented as
Dynamics>Define simulation Designate quantities which are to be able mismatch level. current sources (activity
output by subsystem (CHSB) CHSB monitored during dynamic simulation
Dynamics data must be CONG must have been
[Select Channels by Subsystem] calculations.

memory.
case. Generators represented as
Dynamics>Model maintenance… Perform table maintenance functions for current sources (activity
DYCH Dynamics data must be
[Model Maintenance] plant-related dynamics models CONG must have been
PSS®E 34.2
memory.

PSS®E 34.2
Working Case
Dynamics>List>Models and data Report models referenced in dynamics case. Generators represented as
(DOCU)… setup. The report may be restricted to current sources (activity
DOCU Dynamics data must be
those models for which constant data CONG must have been
[List Dynamics Model Data] fails a reasonableness check. present in dynamics working executed).
memory.
Report contents of any or all of the
following:
• CON array
Dynamics>List>Dynamics data • VAR array Dynamics data must be
(DLST)… DLST present in dynamics working
• STATE array
[List Dynamics Data Common] memory.
• ICON array
• Main output channel selections
A-33
• CRT plot channel selections

Dynamics>List>Model storage case. Generators represented as
locations… List plant-related models referenced in current sources (activity
MLST Dynamics data must be
dynamics setup. CONG must have been
[List Model Storage Locations] present in dynamics working executed).
memory.
Dynamics>Launch NEVA Eigen-
value analysis
Force Generator Conversion (icon

only)
Activity Summary
Update Plot Book (icon only)
Update Dynamic Diagram (icon only)

Activity Summary
Working Case
Initialize all dynamics models from the Validly specified power flow
Dynamics>Build matrices for network conditions contained in the case, solved to an accept- Generators represented as
LSYSAN program (ASTR)… working case and construct the state variable mismatch level. current sources (activity
ASTR
able system matrices required by the CONG must have been
[Build Matrices for LSYSAN] Linear Dynamic Analysis program, Dynamics data is located in executed).
LSYSAN. dynamics working memory.
I/O Control>Direct Report output

(OPEN)… Preselect report destination: terminal, file,
OPEN None
or high-speed printing device.
[Report Output Destination Selector]
I/O Control>Direct Progress output
(PDEV)… Assign destination progress report output
PDEV to the terminal, a file, or a hard copy None
[Progress Output Destination printing device.
Selector]
A-34
None, although in practice,

Assign destination of the dialog output of
I/O Control>Direct Prompt output… activity ODEV would be
a Response File or an IPLAN program to
ODEV executed only from a
[Prompt Output Destination Selector] the terminal, a file, or a hard copy printing
Response File or an IPLAN
device.
program.
None, although in practice,
Assign destination of the dialog output of
I/O Control>Direct Alert output… activity ODEV would be
a Response File or an IPLAN program to
ODEV executed only from a
[Alert Output Destination Selector] the terminal, a file, or a hard copy printing

Response File or an IPLAN
device.
program.
I/O Control>Set path for use with
"&" filenames (PATH)… Designate a pathname to be used as a
PATH prefix for all filenames to be entered with None
[Define PATH by selecting any file in an ampersand (&) preceding them.
PSS®E 34.2
the desired directory]
PSS®E 34.2 Activity Summary
Working Case
Icon Navigation, [GUI], Tab Selection Activity ID Function Requirement(s) Activity Prerequi
I/O Control>Start recording…

[Select Program Automation File to Record user action for part or all of work
None
Record] session
I/O Control>Stop recording
I/O Control>Run program Automa-

tion file… IPLAN Executable
Program File gener
[Select Program Automation File to EXEC Execute IPLAN Executable Program File
IPLAN language co
Run]
program.
IPLAN File (*.irf)
tion file…
Response File, if a
[Select Program Automation File to IDEV Run Response File
name is specified
Run]
Response file (*.idv)
tion file… Specify a dynamic simulation run in a
high-level language. Output is a PSAS Command fil
[Select Program Automation File to PSAS None
Response File that is automatically (*.psa)
Run]
executed.
PSAS Command file (*.psa)
tion file… Specify a power flow run in a high-level
PSEB Command Fi
[Select Program Automation File to PSEB language. Output is a Response File that None
(*.pse)
Run] is automatically executed.
PSEB Command file (*.pse)
tion file…
[Select Program Automation File to Run Python (*.py) file Python file (*.py)
Run]
Python file (*.py)
Misc>Change program settings Modify PSS®E program settings. New

(OPTN) … program settings remain in effect unless
OPTN None
reset with activity OPTN or overridden
[Program Settings] with the settings from a Saved Case file.
Misc>Display timing statistics
TIME Display timing statistics None
(TIME)
Misc>Reset timing statistics to zero TIME,
Reset timing statistics None
(TIME) INIT
Misc>Insert text into the Progress
stream (TEXT) Insert text into the Progress stream of an
TEXT None
active terminal session logging file.
[Insert Text into the Progress Stream]
A-35
Activity Summary PSS®E 34.2
Working Case
Navigation, [GUI], Tab Selection Activity ID Function Requirement(s) Activity Prerequisite(s)
Misc>Select extended bus name
input format
Modify data contained in dynamics
working memory, including model
Dynamics data must be
constants and variables, output channel
Dynamics spreadsheet ALTR present in dynamics working
selections, solution parameters used
memory.
during the simulation, and the two line
case title.
Report files contained in the current
Line mode only CATA none
directory in alphabetical order
case. Generators represented as
Modify the constant data values associ-
Line mode only CCON ated with plant-related dynamic Dynamics data must be CONG must have been
simulation model references present in dynamics working executed).
memory.
Network spreadsheet CHNG Power flow data modification.
Terminate output to the previous action
Command Line Interface only CLOS None
initiated by activity OPEN.
Command Line Interface only ECHO Copies all terminal input to a file.
Modify the 2-line case heading and the Validly specified power flow
Line mode only EDTR
16-line long title case.
Find bus number from bus name or
Command Line Interface only FIND
partial bus name.
Link to power flow activity selection, PSS®E must have been
Command Line Interface only LOFL enabling execution of any Command Line initiated at its dynamic simu-
input power flow activity. lation entry point, PSSDS4.
Change equipment identifier (machines,
loads, fixed bus shunts, ac branches,
Command Line Interface only MBID
multi-section line groupings, dc lines,
FACTS devices, and interarea transfers).
Modify line resistances of nontransformer
branches. All in-service branches that
Command Line Interface only MODR case solved to an accept-
have one or both of their ends in the
specified subsystem are processed.
Line mode only PRTI Print the 16 line long title Non-null power flow case.
Return to dynamic simulation activity
selection from power flow activity selec-
Command Line Interface only RTRN tion. Establish connectionsbetween
models and network elements, and
update output channel addresses.
Network spreadsheet SQCH Sequence data modification activity.
Line mode only TREA Power flow data input from the terminal.
Line mode only TRSQ Sequence data input from terminal.
A-36
PSS®E 34.2 Activity Summary
Working Case
Icon Navigation, [GUI], Tab Selection Activity ID Function Requirement(s) Activity Prerequi
Command Line Interface only USER Power flow user-written activity.
Set/display current Line Mode language
Line Mode only Version
version being interpreted.
Prints brief summary documentation of
Line Mode only HELP
line mode activities at progress device
A-37
Activity Summary PSS®E 34.2
A-38
Appendix B
PSS®E Documentation
PSS®E and its auxiliary programs are documented in a set of manuals. Your installation may not
Appendix B - PSS®E Documentation
include all of the documents listed below, depending upon which of the optional program sections
are included in your lease of PSS®E.
PSS®E Program Operation Manual: This manual is a comprehensive working guide to

PSS®E, independent of interface differences, documenting operational procedures and
providing characteristic results.
PSS®E Program Application Guide: discusses the engineering aspects of formulating prob-
lems for PSS®E and interpreting its results. The two part guide can be considered an engi-
neering textbook specifically related to system modeling and techniques within PSS®E for
engineers responsible for planning and operations studies.
The Program Operation Manual and the Program Application Guide discuss the use of PSS®E from
different viewpoints and hence complement each other. The user is encouraged to become familiar
with both of these manuals.
PSS®E Installation Guide: contains installation instructions.
PSS®E GUI Users Guide: describes the use of the power flow functions, Optimal Power Flow
program, and dynamic simulation functions of PSS®E using the Graphical User Interface
(GUI) introduced at PSS®E-30.
PSS®E Command Line Interface (CLI) Users Guide: describes the structure and general
operation of PSS®E for those customers who prefer operation using command line input.
PSS®E Model Library: provides data sheets and model descriptions for all dynamic models
supported by PSS®E dynamic simulation activities.
PSS®E Application Program Interface (API): describes the interfaces to the various engi-
neering functions of PSS®E. Included are the syntax details for accessing APIs in the batch
command facility introduced at PSS®E-25 and in the Python programming language intro-
duced at PSS®E-30.
PSS®E Compatibility Reference: complete documentation of compatibility of the current

release with prior releases of PSS®E and prior Optimal Power Flow (OPF) releases as a
separate application. This document also contains version histories.
B-1
PSS®E Documentation PSS®E 34.2
PSAS User’s Ready Reference and PSEB User’s Ready Reference: describe the
Command File structures that allow the PSS®E user to specify many routine power flow
and dynamic simulation runs, activity PSAS and activity PSEB respectively, in English
sentence form. These command files are created by the user with a text editor before
starting up PSS®E. The PSAS and PSEB commands are translated into a PSS®E
Response File for immediate execution or for subsequent processing as a standard PSS®E
Response File.
Graphic Report Generator GRPG User’s Ready Reference: document summarizing the
commands recognized by activity GRPG.
PSSPLT Program Manual: describes the use of the simulation channel output file processing
program used for plotting dynamics study results.
IPLAN Program Manual: describes the Siemens PTI IPLAN programming language and the
use of the IPLAN compiler. Compiled IPLAN programs may be executed by PSS®E activity
EXEC.
PSS®E–WECC Data Conversion Manual: describes the auxiliary programs WECCLF,

WECCDS, and RAWECC. These auxiliary programs convert data between the Western
Electricity Coordinating Council (WECC) power flow and stability program data formats and
PSS®E input data file formats.
UCTE Data Exchange Format Application Guide and Manual: document summarizing
conversion from UCTE data exchange format 2.0 (UCTEDEF) for power flow and three-
phase short circuit studies into PSS®E-31 raw file format, and viceversa.
Transmission Line Characteristics (TMLC) Program Manual and

PSS®E Line Properties Calculator Manual: document a pair of auxiliary programs available
to calculate line impedances from a transmission corridor definition.
Saved Case Data Extraction Subroutines Programming Manual: describes a program-

ming interface whereby users may develop FORTRAN programs that access power flow
data directly from PSS®E Saved Case Files.
Additional Resources for PSS®E: a collection of additional resource materials, including

auxiliary and utility applications, printing assistance, the FLECS Fortran-to-Fortran Trans-
lator, the latest compiler information, etc.
B-2
Appendix C
Legacy Activities
Appendix C - Legacy Activities
C.1 DRED
The coordinate data editing activity DRED is no longer supplied with PSS®E. It has been replaced
by functions in the Diagram View of the Graphical User Interface (GUI) which provide for the modi-
fication of the one-line diagram. The PSS®E GUI Users Guide, Chapter 3 describes the Diagram
View.
C.2 GRED
The graphical report data editing activity GRED is no longer supplied with PSS®E.
C.3 SCGR
The graphical fault analysis activity SCGR, which applied a sequence of single faults at buses in
the working case, is no longer supported. The Line Mode dialog of activity SCGR is implemented
in the Line Mode interpreter and the results have been mapped to the active Slider Diagram.
®
PSS E GUI Users Guide, Section 3.11, Displaying ASCC Fault Analysis Results
C.4 DRAW
Implement Activity DRAW - CLI

ACTIVITY?
>>DRAW
ENTER COORDINATE FILE NAME, BINARY OPTION (-1 TO EXIT):
>>
The one-line diagram drawing activity DRAW has been replaced by the Diagram View of the Graph-
ical User Interface (GUI). The PSS®E GUI Users Guide, Chapter 3 describes the Diagram View.
The old Line Mode dialog of activity DRAW is implemented in the Line Mode interpreter and results
in the execution of the Diagram View’s one-line diagram function.
C-1
Legacy Activities PSS®E 34.2
DRAW Program Operation Manual
®
PSS E GUI Users Guide, Section 3.4.2, Importing a DRAW File
Section 8.1, Drawing a One-Line Diagram from a Drawing Coordinate File
C.4.1 Drawing Coordinate Data File Contents

The selection and position of network elements on each one-line diagram is specified via a user-
supplied Drawing Coordinate Data File. The records in the Drawing Coordinate Data File define the
elements to be drawn, their location on the diagram, and annotation options. A Drawing Coordinate
Data File may be constructed and/or modified manually via the host computer’s text editor.
The Drawing Coordinate Data File consists of records of the following general form:
record type , option , data values
The record type is a two-character code describing the type and significance of the data contained
on the remainder of the record. The option field (which may be a blank or B) specifies a one- or two-
character code, which designates options to be used in drawing the equipment or graphical element
specified by the record. The occurrence of the single character B in the option field is treated as a
blank option field. The option field should always be preceded and followed by commas. The
remainder of each record specifies positional data and other drawing information.
There are two categories of records: control records and graphical element records. The control
records (types HD, EN, VO, RA, VL, AN, CO, CL, and GR) are used to control the reading of the
file and the specification of diagram options such as character size. The graphical element records
describe the network elements (i.e., the buses, branches, and other equipment), as well as
elements such as text strings, symbols and straight lines, which are to be drawn on the diagram.
Records in the file may appear in any order with the exception of the header record (type HD), which
must be the first line, and the terminator record (type EN), which must be the last line. In addition,
only the GN, BL, and LF summation participation record may be specified between a SU record and
the corresponding EN record of a summation block structure (refer to Summation Block Structure).
In addition, only LI branch records may be specified between TT record and the corresponding EN
record of a three-winding transformer group. (refer to Two-Terminal dc Transmission Line Record -
DC and Multi-Terminal dc Transmission Line Record - MD).
The x- and y-axis coordinate values must not be specified as negative numbers on any data
record.
On any data record on which buses are specified, the bus identifier is taken to be the bus number
when the numbers input option is in effect, and the extended bus name, enclosed in single quotes,
using the names input option (refer to Section 3.3.3 Program Run-Time Option Settings and activity
OPTN).
C-2
PSS®E 34.2 Legacy Activities
Program Operation Manual DRAW
Header Record - HD
The header record, which must be the first record in the Drawing Coordinate Data File, is of the
form:
HD, O, DRAWX, DRAWY, CHRX, XSIZE, 'f', TITLEY
where:
O Is a valid option (blank, S, N, A, or L); below.

DRAWX Is the length of the horizontal (x-axis) side of the drawing in inches. If DRAWX is
less than 7.5 activity DRAW automatically changes it to 7.5 in.
DRAWY Is the length of the vertical (y-axis) side of the drawing in inches exclusive of the
banner block at the bottom of the drawing.
CHRX Is the character height in inches; default is 0.05 in.
XSIZE Is a scaling factor specified in inches; default is zero. If XSIZE is greater than zero,
activity DRAW does not ask the user if the drawing size is to be changed immedi-
ately preceding the drawing of the diagram. Rather, the drawing size is
automatically scaled by the ratio XSIZE/DRAWX.
’f’ Is a single-character orientation flag enclosed in single quotes. It controls the orien-
tation of text written on lines perpendicular to the title block. If this flag is specified
as ’R’, such text is positioned to be read when viewing the drawing from the right
side (relative to the title block being at the bottom). An ’L’ positions such text to be
read from the left side. The flag default is ’R’.
TITLEY Is the length of the vertical (y-axis) side of the banner block at the bottom of the
drawing in inches; default is 0.5 in.; maximum is 2.0 in.
DRAWX and DRAWY define the size of the box that is drawn around the one-line diagram. If these
quantities are not entered, activity DRAW calculates the dimensions of the box.
The valid entries in the option field are as follows:
blank Draw a one-line diagram of the portion of the working case as specified in the
Drawing Coordinate Data File.
N No printing on the one-line diagram. This option suppresses all text on the drawing.
This option is useful in the initial debugging of a new Drawing Coordinate Data File.
A Accept the network specified in the Drawing Coordinate Data File. This option is
called the accept mode and is used to draw a diagram of a network not necessarily
part of the working case. If bus numbers are selected in the dialog portion of activity
DRAW, they are printed; if the name option is selected, a dummy name is printed
for each bus. Bus voltages and tap ratios are printed as one per unit. If branch flows
are selected, they are printed as zero; if the impedance option is selected, imped-
ances are printed as zero.
L Same as the A option, but with annotation suppressed.
C-3
Terminator Record - EN
A terminator record, EN, is required both as the last record of each summation block structure (refer
to Summation Block Structure), as the last record of each three-winding transformer group, and as
the last record of the Drawing Coordinate Data File. If the Drawing Coordinate File is not concluded
with this record, activity DRAW proceeds as if the EN record was encountered.
Voltage Level Record - VO

The voltage level specification record is used to specify three voltage level breakpoints. If voltage
levels are selected during the range checking selection portion of the dialog, the voltage levels
specified on the VO data record are taken as the default base voltage breakpoints.
The voltage level specification record is of the form:
VO, O, V1, V2, V3
The option field O is either a blank or F. The F option forces the voltage level annotation option on
the one-line diagram even if this range checking option is not specifically selected in the interactive
dialog of activity DRAW. V1, V2, and V3 are specified in kV in ascending order.
By default, the line used in drawing the bus and its connected branches is generated as follows:
On Monochromatic Devices On Pen Plotters On Color CRTs

Base kV < V1 One dot wide Pen # 1 White
V1 < base kV < V2 Two dots wide Pen # 2 Red
V2 < base kV < V3 Three dots wide Pen # 3 Green
V3 < base kV Four dots wide Pen # 4 Blue
On monochromatic devices, when only two voltage levels are specified, it is suggested that they be
drawn using one and three dots. When any of the three voltage breakpoints is specified as zero, or
is less than or equal to the preceding voltage breakpoint, the corresponding line width or color is not
used to distinguish among buses at different voltage levels. Therefore, if the user wishes to distin-
guish between buses up to 138 kV and those greater than 138 kV, the VO data record could be
entered as VO, ,138,138 or VO, ,138,0.
The default line widths, pen numbers, or colors for designating voltage levels may be overridden by
specifying a CO record (refer to Color Specification Record - CO).
Bus Records - BU and BN

Buses to be included on the one-line diagram are specified in bus data records in the Drawing Coor-
dinate Data File. Bus data records are of the form:
BU, O, IB, X1, Y1, X2, Y2, I1, I2
or:
BN, O, IB, X1, Y1, X2, Y2, I1, I2
where:
O Is a valid option (blank, R, N, V, or S); below.
C-4
IB Is the bus identifier (number or name).

X1,Y1 Is the (x,y) coordinate of one end of the bus, specified in inches.
X2,Y2 Is the (x,y) coordinate of the other end of the bus, specified in inches.
I1 Is an integer variable used to control the position of the bus annotation (bus name
and/or number or voltage and/or angle) that is printed at the left end of a horizontal
bus or the top of a vertical bus. I1 is the number of character widths to move the
annotation to the right. A negative value of I1 moves the annotation to the left. I1 is
limited to the integers between -10 and 10 inclusive, and has a default value of zero.
I2 Is an integer variable used to control the position of the bus annotation that is
printed at the right end of a horizontal bus or the bottom of a vertical bus. I2 is the
number of character widths to move the annotation to the right. A negative value of
I2 moves the annotation to the left. I2 is limited to the integers between -10 and 10
inclusive, and has a default value of zero.
Bus data record types BU and BN behave identically except in the component checking option of
activity DRAW.
Buses must be either horizontal (Y1 = Y2) or vertical (X1 = X2).
For vertical buses, I1 and I2 values of zero place the respective annotation adjacent to the busbar
on the right side. A value of -1 places the annotation adjacent to the busbar on the left side; values
of -2 through -10 move it additional character widths to the left.
blank Print bus voltage and/or angle at the right (if a horizontal bus) or bottom (if a vertical
bus), and the bus identifier (number and/or name) at the opposite end.
R Reverse identifier and voltage fields (identifier at right or bottom, as appropriate).
N Print bus name/number but not voltage or angle.
V Print bus voltage and/or angle but not the bus identifier.
S Suppress all annotation for the bus.
The R option may be used in combination with the N or V option. For example, specifying RN in the
option field causes the voltage annotation to be suppressed and the bus identifier to be written at
the right end of a horizontal bus or the bottom of a vertical bus.
By default, Type 4 buses and their generation, loads, and shunts are drawn with dotted lines and
annotation values other than the bus identifier(s) are either zeros or not displayed. This default
manner of drawing out-of-service equipment may be overridden by specifying a CO record (refer to
Color Specification Record - CO).
The minimum information necessary in a bus data record is:
BU, ,IB, X1, Y1, X2, Y2
C-5
Branch Record - LI
The ac transmission lines and transformers to be included on the one-line diagram are specified in
branch data records in the Drawing Coordinate Data File. Branch data records are of the form:
LI, O, IFROM, ITO, ICKT, XF, YF, XT, YT, SDF, SF, SDT, ST
where:
O Is a valid option (blank, F, T, SP, N, A, FA, TA, BX, FX, TX, SX, BN, FN, TN, S, SN,
C, FC, TC, SC, R, RN, X, XA, E, EN, EX, RC, or EC); below.
IFROM Is the from bus identifier.
ITO Is the to bus identifier.
ICKT Is the circuit or multi-section line grouping identifier; default value is '1'.
XF,YF Is the (x,y) coordinate of the line at the from bus end, specified in inches.
XT,YT Is the (x,y) coordinate of the line at the to bus end, specified in inches.
SDF Is the single character L, R, U, or D (for left, right, up, and down, respectively) indi-
cating the direction of the stub drawn at the from bus.
SF Is the length of the line stub drawn at the from bus. It is specified in inches and may
be entered as zero. The default value is 0.125 in.
SDT Is the single character L, R, U, or D (for left, right, up, and down, respectively) indi-
cating the direction of the stub drawn at the to bus.
ST Is the length of the line stub drawn at the to bus. It is specified in inches and may be
entered as zero. The default value is 0.125 in.
Each branch data record causes a line to be drawn in three line segments: a line from each of the
from and to buses where direction and length are characterized by the parameters SDF and SF at
the from bus and SDT and ST at the to bus, and a line connecting the end points of these two stub
segments. It is recommended that the coordinates be specified such that the length of the line is at
least 0.5 in. to accommodate the line annotation.
A value of zero for SF or ST suppresses the drawing of the stub segment at the corresponding bus'
(x,y) coordinates as specified on the data record; in this case, the corresponding stub direction
code, SDF or SDT, is ignored. This is useful for those situations where it is desirable to have a
branch drawn with more than three line segments. To do this, two or more branch data records are
entered in the Drawing Coordinate Data File for the branch, with the appropriate coordination of the
(x,y) coordinates and use of option field specifications. The following records illustrate an applica-
tion of this approach:
BU, ,10 1.0 0.5 1.0 1.5

BU, ,20 4.5 5.5 5.5 5.5
LI,F ,10 20 1 1. 1. 3. 1. R .125 L 0.
LI,SN,10 20 1 3. 1. 3. 6. U 0. D 0.
LI,T ,10 20 1 3. 6. 5. 5.5 R 0. U .5
ST should also be specified as zero when the R, RN, X, XA, E, EN, EX, RC, or EC option is specified
in the option field (and therefore the to bus is not to be drawn). SF and ST should not be zero if
the corresponding bus is included in the Drawing Coordinate Data File and the corresponding (x,y)
coordinates coincide with coordinates on the busbar. Otherwise, the branch annotation will not be
printed in the proper position.
C-6
Branch coordinates should not be specified such that the two stub endpoints coincide or overlap
(i.e., the line connecting the two stubs has zero length or retraces the stub paths).
A pair of tables summarizes the valid entries in the option fields of branch coordinate data records.
Table <$TableTitleC-1 applies to branches for which bus coordinate data records for both of its
endpoint buses are included in the Drawing Coordinate Data File. Its columns correspond to the
various levels of line annotation available in activity DRAW:
(1) Print the branch flow at the from bus end (bus IFROM).
(2) Print the branch flow at the to bus end (bus ITO).
(3) Draw a transformer symbol.
(4) Print the tap ratio and, if it is non-zero, the phase shift angle.
(5) Print the phase shift angle but not the tap ratio.
(6) Draw a series capacitor symbol.
When one of the series capacitor options C, FC, TC, or SC is specified on a branch coordinate data
record and the branch is either a transformer, a positive reactance branch or being treated as a zero
impedance line, the branch is annotated as if the option blank, F, T, or SN, respectively, had been
specified. For the remaining options listed in the table that include transformer annotation, if the
branch is not a transformer, the transformer annotation columns are ignored and the from and to
buses are annotated as indicated in Table <$TableTitleC-1.
C-7
Table C-1. Options For Branch Coordinate Data Records
(1) (2) (3) (4) (5) (6)

Tap Ratio Series
From Bus To Bus Transformer and Phase Phase Shift Capacitor
Option Flow Flow Symbol Shift Angle Angle Symbol
blank    
F   
T   
SP  
N  
A    
FA   
TA   
BX   
FX  
TX  
SX 
BN  
FN 
TN 
S or SN
C   
FC  
TC  
SC 
* If the branch is a transformer, flow is printed on the tapped side; the transformer symbol, tap
ratio, and phase shift angle are not printed. If the branch is not a transformer, flow is printed at
both ends.
Table <$TableTitleC-2 lists those option field values that must be used on branch coordinate data
records for open ended radial lines, where the from bus (bus IFROM) has a bus record included in
the Drawing Coordinate Data File and the to bus (bus ITO) does not. Its columns correspond to the
various levels of line annotation available for such branches:
(1) Print the branch flow at the from bus end (bus IFROM).
(2) Draw a transformer symbol.
C-8
(3) Print the tap ratio and, if it is non-zero, the phase shift angle.
(4) Print the phase shift angle but not the tap ratio.
(5) Draw a series capacitor symbol.
The to bus number and/or name is printed at the to bus end of the line in accordance with the bus
annotation option as selected during the dialog of activity DRAW, as specified on the bus annotation
specification record, or as set to default values (refer to Bus Annotation Record).
When one of the series capacitor options RC or EC is specified on a branch coordinate data record
and the branch is either a transformer, a positive reactance branch or being treated as a zero imped-
ance line, the branch is annotated as if the option R or EX, respectively, had been specified. For the
remaining options listed in the table that include transformer annotation, if the branch is not a trans-
former, the transformer annotation columns are ignored and the from bus is annotated as indicated
in Table <$TableTitleC-2.
By default, the North American transformer symbol is used where transformer symbols are drawn.
A European transformer symbol may be selected by specifying a transformer annotation specifica-
tion record (refer to Transformer Annotation Record).
By default, out-of-service branches are drawn with dotted lines and no flows are printed. This
default manner of drawing out-of-service equipment may be overridden by specifying a CO record
(refer to Color Specification Record - CO).
In an impedance diagram, the specified option is ignored. The branch impedance is printed at one
end of the line; total line charging and, optionally, a selected line rating are printed at the other end.
For branches with one of the option field values listed in Table <$TableTitleC-2, the impedance is
printed at the from bus end and the charging and rating annotation is suppressed.
Table C-2. Special Options for Open Ended Radial Lines
(1) (2) (3) (4) (5)

Tap Ratio Series
From Bus Transformer and Phase Phase Shift Capacitor
Option Flow Symbol Shift Angle Angle Symbol
R or RN 
X   
XA   
E or EN
EX 
RC  
EC 
The minimum information necessary in a branch data record is:
LI, , IFROM, ITO,, XF, YF, XT, YT, SDF,, SDT
C-9
Transformer Record - TR
A special two-winding transformer record type is provided to specify transformers when the A or L
option is entered on the header record or the suffix AC is specified in invoking activity DRAW.
Because these options indicate that the network to be drawn is not necessarily in the working case,
the TR record provides the user with the ability to designate that a network branch is a transformer.
When a transformer record is entered, activity DRAW assumes that the tapped side of the
transformer is the from bus (bus IFROM) and the untapped or impedance side is the to bus
(bus ITO). (When executed in non-accept mode (refer to Header Record - HD), DRAW accesses
the working case to determine whether or not a branch is a transformer, as well as determining each
transformer’s tapped impedance side relationship.)
The format and options of the transformer data record are exactly the same as those of the branch
data record (type LI) described in Branch Record - LI. The TR record behaves as does the LI record
when the diagram is coordinated with the working case.
Three-Winding Transformer Record - TT

Three-winding transformers to be included on the one-line diagram are specified in three-winding
transformer groups in the Coordinate Data File. Each of three-winding transformer groups consists
of:
• One three-winding transformer record TT (see below).

• Followed by branch records LI (see below).
• Followed by one terminator record EN (refer to Terminator Record - EN).
Three-winding transformer records are of the form:
TT, O, IFROM, ITO, ILAST, ICKT, X, Y
where:
O Is a valid option (blank, or S); below.

IFROM Is the Winding 1 bus identifier.
ITO Is the Winding 2 bus identifier.
ILAST Is the Winding 3 bus identifier.
ICKT Is the three-winding transformer circuit identifier; default value is '1'.
X,Y Is the (X,Y) coordinate of the reference point of the star point bus, specified in
inches.
blank Print the tap ratio for all windings of the three-winding transformer.
S Suppress all annotation for the three-winding transformer.
The three-winding transformer record in the three-winding transformer group are followed by
branch records LI. Refer to Branch Record - LI for the correct form for branch records. There are
two limitations for these records:
• IFROM should be 0 to indicated that the branch is a part of three-winding transformer.

• The valid options are TN and SN only.
C-10
The following records illustrate an example of three-winding transformer group:
TT,' ', 160 152 153 1 5.875 4.000

LI,'TN', 0 153 1 5.875 3.875 5.875 3.250 D 0.125 U 0.125
LI,'TN', 0 152 1 6.000 4.125 6.000 4.750 U 0.125 D 0.125
LI,'TN', 0 160 1 5.750 4.125 4.250 4.250 L 1.500 D 0.125
EN
Two-Terminal dc Transmission Line Record - DC

Two-terminal dc transmission lines to be included on the one-line diagram are specified in dc trans-
mission line data records in the Drawing Coordinate Data File. The dc line data records are of the
form:
DC, O, NDC, X1, Y1, X2, Y2, SDF, SF, SDT, ST
where:
O Is a valid option (blank, N, F, FN, T, TN, or S); below.

NDC Is the two-terminal dc line number.
X1,Y1 Is the (x,y) coordinate of the dc line at the rectifier converter station bus, specified in
inches.
X2,Y2 Is the (x,y) coordinate of the dc line at the inverter converter station bus, specified in
inches.
SDF Is the single character L, R, U, or D (for left, right, up, and down, respectively) indi-
cating the direction of the stub drawn at the rectifier bus.
SF Is the length of the line stub drawn at the rectifier bus. It is specified in inches and
may be entered as zero. The default value is 0.125 in.
SDT Is the single character L, R, U, or D (for left, right, up, and down, respectively) indi-
cating the direction of the stub drawn at the inverter bus.
ST Is the length of the line stub drawn at the inverter bus. It is specified in inches and
may be entered as zero. The default value is 0.125 in.
Each two-terminal dc line data record causes a line to be drawn in three line segments in a similar
manner in which ac branches are drawn. Refer to Branch Record - LI for details on the use of the
data parameters SDF, SF, SDT, and ST.
As with ac branches, it is not permissible to specify a dc line’s coordinates and stub lengths such
that the two stub endpoints coincide or overlap.
blank Print flow at each end. The converter tap settings and dc symbols are drawn.
N No printing of dc symbols or converter tap settings. Flows are printed at both ends.
F Print flow at rectifier bus end only. The converter tap setting and dc symbol are
drawn.
FN No printing of dc symbol or converter tap setting. Print flow at rectifier bus end only.
T Print flow at inverter bus end only. The converter tap setting and dc symbol are
drawn.
C-11
TN No printing of dc symbol or converter tap setting. Print flow at inverter bus end only.
S Suppress all printing on the dc line.
The power flowing into a dc line is the apparent ac system complex load as n at the converter bus
(i.e., PACR and QACR at the rectifier end, and PACI and QACI at the inverter end).
By default, blocked two-terminal dc lines are drawn with dotted lines and no flows are printed; the
dc symbols are drawn. This default manner of drawing out-of-service equipment may be overridden
by specifying a CO record (refer to Color Specification Record - CO).
For an impedance diagram, the specified option is ignored and the commutating reactances, in
ohms, are printed at each end of the line. The dc line resistance, in ohms, is printed above the
commutating reactance at the rectifier end of the line, and the minimum alpha and gamma angles
are printed at the corresponding dc symbols.
If the A or L option is specified on the header record, or AC is specified in invoking activity DRAW
using line mode, the working case is ignored and the dc line coordinates are not checked against
the coordinates of the appropriate buses because the buses involved are normally determined from
the working case and not from the dc data record.
The minimum information necessary in a dc line data record is:
DC, , NDC, X1, Y1, X2, Y2, SDF,, SDT
Multi-Terminal dc Transmission Line Record - MD

Multi-terminal dc transmission line converters to be included on the one-line diagram are specified
in multi-terminal dc line records in the Drawing Coordinate Data File. Multi-terminal dc data records
are of the form:
MD, NDC, IB, X1, Y1, X2, Y2
where:
NDC Is the multi-terminal dc line number.

IB Is the bus identifier. Bus IB must be a converter station bus of multi-terminal dc line
NDC.
X1,Y1 Is the (x,y) coordinate of the line on the busbar, specified in inches.
X2,Y2 Is the (x,y) coordinate of the end point of the straight line segment, specified in
inches.
The length of the line specified by the coordinates (X1,Y1) and (X2,Y2) should be at least 1 in. The
line specified by the coordinates must be either horizontal (Y1 = Y2) or vertical (X1 = X2).
At the end of the line connected to the bus, the power flowing into the dc line (i.e., the apparent ac
system complex load as n at the converter bus) is printed. The dc symbol is drawn at the midpoint
of the line, and the converter alpha or gamma angle, as appropriate, and tap position are printed at
the end of the line segment.
By default, at each converter of a blocked multi-terminal dc line for which an MD record is specified,
the multi-terminal dc line is drawn with a dotted line and the flow, angle and tap are shown as zero;
the dc symbol is drawn. This default manner of drawing out-of-service equipment may be over-
ridden by specifying a CO record (refer to Color Specification Record - CO).
C-12
Multi-terminal dc line converters are annotated identically in impedance and flow diagrams.
While the dc link connections within multi-terminal dc lines are not handled automatically by activity
DRAW, the ends of these line segments may be appropriately connected by using straight line
records (refer to Straight Line Record - SL).
Load Records - LO, LP, LC, and LY

Bus loads to be included on the one-line diagram are specified in load data records in the Drawing
Coordinate Data File. Load data records are of the form:
La, O, IB, X1, Y1, X2, Y2
where:
La Is either LO, LP, LC, or LY and defines the load characteristic; below.
O Is blank or the load identifier; below.
IB Is the bus identifier.
inches. This is the end at which the arrow head is drawn.
The length of the line specified by the coordinates (X1,Y1) and (X2,Y2) should be at least 0.25 in.;
a longer length may be needed depending on the magnitude of the load and the character size
specified on the HD record. The line specified by the coordinates must be either horizontal
(Y1 = Y2) or vertical (X1 = X2).
The LP, LC, and LY data records are used to display the constant power, constant current, and
constant admittance load characteristics, respectively, of the load at bus IB for which the identifier
is contained in the option field of the data record. If the option field contains a blank, the sum of the
appropriate load characteristic for all in-service loads at bus IB is printed.
The LO data record is used to display the sum of the three load characteristics for the load at bus
IB for which the identifier is contained in the option field. If the option field contains a blank, the total
in-service load at bus IB is printed. The specified load identifier is printed inside of the load symbol.
By default, out-of-service loads are drawn with dotted lines and annotation values are shown as
zero. This default manner of drawing out-of-service equipment may be overridden by specifying a
CO record (refer to Color Specification Record - CO).
In an impedance diagram, nominal loads are printed (i.e., at one pu voltage).
C-13
Shunt Record - SH
Bus shunts to be included on the one-line diagram are specified in shunt data records in the
Drawing Coordinate Data File. Shunt data records are of the form:
SH, O, IB, X1, Y1, X2, Y2
where:
O Is a valid option (blank, L, S or R); below.

inches. This is the end at which the capacitor or reactor symbol is drawn.
a longer length may be needed depending on the magnitude of the shunt and the character size
specified on the HD record. The line specified by the coordinates must be either horizontal
blank The shunt printed is the sum of the fixed shunt and switched shunt devices.
L The shunt printed is the fixed shunt (refer to Bus Data).
S The shunt printed is the switched shunt (refer to Switched Shunt Data).
R When the reactive component of the shunt is zero or when in accept mode, a
reactor symbol is drawn; under these conditions when the R option is not specified,
a capacitor symbol is drawn.
The R option may be used in combination with the L or S options (i.e., RL or RS).
Constant admittance load is not included as bus shunt; these are drawn as loads (refer to Load
Records - LO, LP, LC, and LY).
By default, shunts at Type 4 buses are drawn with dotted lines and annotation values are shown as
zero. This default manner of drawing out-of-service equipment may be overridden by specifying a
On a flow diagram, shunt MW and Mvar are printed; on an impedance diagram, nominal shunt
values are printed. The sign of the reactive component of shunt admittance determines whether a
capacitor or reactor symbol is drawn. When this quantity is zero, a reactor symbol is drawn if the R
option is specified; otherwise, a capacitor symbol is drawn.
C-14
Generator Record - GE
Generators to be included on the one-line diagram are specified in generator data records in the
Drawing Coordinate Data File. Generator data records are of the form:
GE, O, IB, X1, Y1, X2, Y2
where:
O Is blank or the machine identifier; below.

inches. This is the end at which the circle is drawn.
a longer length may be needed depending on the magnitude of the generation and the character
size specified on the HD record. The line specified by the coordinates must be either horizontal
By default, out-of-service plants and machines are drawn with dotted lines and annotation values
are shown as zero. This default manner of drawing out-of-service equipment may be overridden by
specifying a CO record (refer to Color Specification Record - CO).
On a flow diagram, generator MW and Mvar are printed; on an impedance diagram, the generator
reactive power limits replace the Mvar output on the drawing.
When the option field is left blank, plant totals are printed. Otherwise, the option field specifies the
identifier of a machine in a multimachine plant for which the data is to be printed. The machine iden-
tifier is printed inside the generator circular symbol. Thus, if several machines at a bus are to be
drawn, one generator data record in the Drawing Coordinate Data File is required for each one.
To specify a machine with a machine identifier of B, the option field must be specified as BB (refer
to comments in Drawing Coordinate Data File Contents above).
Facts Device Record - FD

FACTS devices to be included on the one-line diagram are specified in FACTS device data records
in the Drawing Coordinate Data File. FACTS device data records are of the form:
FD, O, FACTID, X1, Y1, X2, Y2, STBDIR, STBLTH, DEVTYP
where:
O Is a valid option (blank, B, N, S, T); below.

FACTID Is the facts device identifier.
X1,Y1 Is the (x,y) coordinate of the line connection at the sending bus, specified in inches.
For UPFC and SSSC devices, this is the coordinate point associated with the series
element line connection that connects the send and terminal buses. For a
STATCON device, this is the coordinate point associated with the shunt device
connection line.
C-15
X2,Y2 Is the (x,y) coordinate endpoint of the line connection, specified in inches. For
UPFC and SSSC devices, this coordinate is located on the terminal bus and termi-
nates the line connection between the send and terminal buses. For STATCON
devices, this is the coordinate point associated with the end of the shunt device stub
line. The line specified by the coordinates must be either horizontal (Y1 = Y2) or
vertical (X1 = X2).
STBDIR Is the single-character L, R, U, or D (for left, right, up, and down, respectively) indi-
cating the direction of the shunt stub drawing relative to the send bus (X1,Y1)
coordinate. For SSSC and STATCON FACTS devices, this field may be blank and
is ignored.
For horizontal send bus bars, only L,R values are allowed with L assigned as
the default. For vertical send bus bars, only U,D values are allowed with D
assigned as the default. STBDIR is ignored for all SSSC and STATCON devices.
STBLTH Is the length of the shunt stub offset relative to the (X1,Y1) coordinate of the send
bus. It is specified in inches with 0.125 in. as default. For SSSC and STATCON
FACTS devices, this field may be blank and is ignored.
For UPFC FACTS devices, the shunt stub line is drawn starting at the point defined
by the shunt stub drawing direction and the shunt stub offset length relative to
(X1,Y1). The shunt stub line is drawn with a length of 0.2 in. The shunt FACTS
device rectangle and ground symbols are drawn at the end of the shunt stub line.
DEVTYP Is the FACTS device type (1-UPFC device, 2-SSSC device, 3-STATCON). The
default type is 1. This field may be blank and is ignored when DRAW is executed in
non-accept mode.
blank, B Display flows on series, bridge, and shunt elements.

N Do not display any flows.
S Display flows only at send bus and shunt element end.
T Display flow only at terminal bus.
For UPFC and SSSC FACTS devices, a circle with an arrow depicting power flow direction is drawn
midway on the line connecting the sending and terminal buses. For UPFC FACTS devices, two lines
are drawn connecting the shunt rectangle and the circle. By default, out-of-service FACTS devices
are drawn with dotted lines, and annotation values are blanked.
Straight Line Record - SL

Arbitrarily located straight lines to be included on the one-line diagram are specified in straight line
data records in the Drawing Coordinate Data File. Straight line records are of the form:
SL, O, X1, Y1, X2, Y2
where:
O Is a valid option (blank, D, H, n, Dn, or Hn); below.

X1,Y1 Is the (x,y) coordinate of one end of the line, specified in inches.
X2,Y2 Is the (x,y) coordinate of the other end of the line segment, specified in inches.
C-16
Straight lines may be used, for example, to designate area boundaries, or to show the dc link
connections within multi-terminal dc lines.
blank Draw solid straight line segment.

D Draw dotted straight line segment.
H Draw dashed straight line segment.
By combining any of these options with the numbers one through eight (e.g., 2, D5), a line width,
pen number or color is designated for the drawing of the straight line. It is the user’s responsibility
to ensure that the designated number is appropriate for the graphics output device being used (e.g.,
6 would be invalid for a pen plotter with only four pens). If the numeric option is invalid, a device
dependent default is used.
Text Specification Record - TX

The text specification record allows strings of characters to be written anywhere on the one-line
diagram. Text specification records are of the form:
TX, O, X, Y, TSIZ, TANG, '...text...'
where:
O Is a valid option (blank, or 1 through 8; blank and 1 are equivalent); below.

X,Y Is the (x,y) coordinate of the first character of the text string, specified in inches.
TSIZ Is the character height specified in inches. TSIZ must be between 0.05 and 1.5 in.
TANG Is the angle of rotation of the character string, specified in degrees between 0 and
360; 0 degrees is the angle at which the title lines are written on the diagram.
text Is the character string. It must be enclosed in single quotes and is limited to 40
characters.
The option field is used to designate a line width, pen number or color for the drawing of the text. It
is the user’s responsibility to ensure that the designated number is appropriate for the graphics
output device being used (e.g., 6 would be invalid for a pen plotter with only four pens). If the
numeric option is invalid, a device dependent default is used.
Clip Specification Record - CL

The clip specification record defines the size of the clipping window where the user may zoom in or
out on a selected portion of the diagram. The clip specification record is of the form:
CL, , X, Y
where:
X,Y Define the size of the window along the x- and y-axes, respectively, and are speci-
fied in inches.
The clipping window defines the portion of the diagram, which is drawn in pages when zooming is
enabled.
C-17
There are no options recognized on the clip specification data record.
Grid Record - GR
The grid record enables the overlaying of a coordinate grid upon the one-line diagram. The grid
record is of the form:
GR, , GRDRES
where GRDRES is the grid resolution specified in inches. Horizontal and vertical lines composing
the grid are spaced GRDRES inches apart. GRDRES is restricted to the range 0.1 through 1.0 in.
and has a default value of 0.125 in. If it is less than 0.1 in., lines are drawn 1/10 of an inch apart; if
it is greater than 1.0, lines are drawn 1 in. apart.
There are no options recognized on the grid data record.
Color Specification Record - CO

The color specification record allows the user to override the default line width, pen number, or color
conventions for denoting voltage levels, heavily loaded and out-of-service branches, and buses
where voltages are out-of-limits. The color specification record is of the form:
CO, , EQOUT, LNOVR, BSUND, BSOVR, V1, V2, V3, V4
where:
EQOUT Defines the line width, pen number, or color to be used in drawing out-of-service
equipment. EQOUT must be between zero and eight. If the default of zero is speci-
fied for EQOUT, out-of-service equipment is drawn with dotted lines.
LNOVR Defines the line width, pen number, or color to be used in drawing heavily loaded
lines. LNOVR must be between zero and eight. If the default of zero is specified for
LNOVR, overloaded lines are drawn with dashed lines.
BSUND Defines the line width, pen number, or color to be used in drawing buses where
voltage magnitudes are below a specified threshold. BSUND must be between zero
and eight. If the default of zero is specified for BSUND, undervoltage buses are
drawn with a dashed line on the bottom portion of the busbar.
BSOVR Defines the line width, pen number, or color to be used in drawing buses where
voltage magnitudes are above a specified threshold. BSOVR must be between zero
and eight. If the default of zero is specified for BSOVR, overvoltage buses are
drawn with a dotted line on the top portion of the busbar.
V1,V2,V3, Define the line width, pen number, or color to be used in denoting voltage levels
V4 (refer to Voltage Level Record - VO). The values specified must be between zero
and eight. If not entered, V1 through V4 default to one through four, respectively.
On color CRTs, the use of color to designate the conditions specified by EQOUT, LNOVR, BSUND,
and/or BSOVR takes precedence over the voltage level color if that option is also enabled.
It is the user’s responsibility to ensure that the numbers designated on the CO record are appro-
priate for the graphics output device being used (e.g., 6 would be invalid for a pen plotter with only
four pens). If any value is invalid, a device dependent default is used.
C-18
Symbol Record - SY
The symbol record allows symbols from the graphics character set to be drawn anywhere on the
one-line diagram. The symbol record is of the form:
SY, O, ISYM, X, Y, SIZE, ANGLE
where:

ISYM Is the symbol number assigned to the symbol to be drawn. Figure C-1 shows the
symbols contained in the graphics character set. ISYM must be between 1 and 155.
X,Y Is the (x,y) coordinate of the reference point of the symbol, specified in inches. The
intersections of the dotted lines in Figure C-1 show the reference points for the
symbols contained in the graphics character set.
SIZE Is the symbol height specified in inches. SIZE must be between 0.05 and 1.5 in.
ANGLE Is the angle of rotation of the symbol, specified in degrees between 0 and 360; 0
degrees is the angle at which the title lines are written on the diagram. The symbols
in Figure C-1 are drawn at zero degrees.
The option field is used to designate a line width, pen number, or color for the drawing of the symbol.
It is the user’s responsibility to ensure that the designated number is appropriate for the graphics
C-19
Figure C-1. Graphics Character Set
C-20
Rating Specification Record - RA

The branch rating specification record specifies the rating set and percentage loading threshold to
be used in identifying heavily loaded branches on the one-line diagram. Using this option, all
branches to be drawn that have a non-zero value for the selected rating and where current loading
at either end exceeds the specified percentage of the selected rating are flagged by being drawn
with dashed lines. This default manner of drawing heavily loaded lines may be overridden by spec-
ifying a CO record (refer to Color Specification Record - CO).
If either the line rating range checking option or one of the % RATING line flow annotation options
is selected, the rating set and percentage loading threshold specified on the RA record are taken
as the default values.
The rating specification record is of the form:
RA, O, RAT, PCTRAT
where:
O Is a valid option (blank or F; below).

RAT Is one of the strings RATE, RATEA, RATEB, or RATEC. If RATE is specified, the
rating set established as the default rating set program option is selected (refer to
Section 3.3.3 Program Run-Time Option Settings and activity OPTN). Otherwise,
the designated rating set is selected.
PCTRAT Is the percentage loading threshold. The default value is 100%.
blank The line rating range checking option is initially disabled and may be activated in the
interactive dialog of activity DRAW.
F Force the line rating range checking option on the one-line diagram even if it is not
specifically selected in the interactive dialog.
Voltage Limits Specification Record - VL

The bus voltage limits specification record specifies the voltage range to be used in identifying
buses with high or low voltages. Using this option, buses with a voltage below the specified
minimum have the lower portion of their bus box drawn with a dotted line. Buses with a voltage
above the specified maximum have the upper portion of their bus box drawn with a dashed line.
This default manner of drawing buses outside of voltage limits may be overridden by specifying a
If the voltage limits range checking option is selected during the interactive dialog of activity DRAW,
the voltage limits specified on the VL record are taken as the default limits.
The voltage limits specification record is of the form:
VL, O, VMIN, VMAX
where:
O Is a valid option (blank or F; below).

VMIN Is the low-voltage threshold limit specified in per unit.
C-21
VMAX Is the high-voltage threshold limit specified in per unit.
blank The voltage limits range checking option is initially disabled and may be activated in
the interactive dialog of activity DRAW.
F Force the voltage limits range checking option on the one-line diagram even if it is
not specifically selected in the interactive dialog.
Diagram Annotation Record - AN

The one-line diagram annotation specification records specify branch, bus, and equipment annota-
tion options. Selections specified on AN records are taken as the default selections during the
interactive dialog of activity DRAW.
As shown in the following paragraphs, the option field on the AN record defines the diagram anno-
tation option being specified.
Line Annotation Record

The line annotation specification record is of the form:
AN, LI, ANNOPT, SGNOPT
The valid entries in the ANNOPT field are as follows:
MW-MVAR Display MW and Mvar line flows; this is the default line annotation option.
MVA Display MVA line flows.
MVA-PCRATE Display MVA line flows and current loading as a percentage of rating.
MW-PCRATE Display MW line flows and current loading as a percentage of rating.
AMP-PCRATE Display current loadings in amps and as a percentage of rating.
AMP-PUCUR Display current loadings in amps and per unit.
Z Display line impedances and charging.
Z-RATE Display line impedances, charging, and the selected rating.
NONE Suppress branch annotation; transformer and dc symbols that would be drawn
using the other branch annotation options are still drawn.
The valid entries in the SGNOPT field are as follows:
SIGN Flow direction is indicated using the standard PSS®E sign convention: positive for
power leaving the bus, and negative for power arriving at the bus.
ARROW Flows are printed unsigned and arrows in front of the flow values indicate flow
direction.
In calculating percentage loading, current expressed as MVA (refer to Non-Transformer Branch

Data and activity RATE) is calculated at the appropriate end(s) of the branch and is used in calcu-
lating the loading percentage. The rating set used is as defined on any RA record (refer to Rating
Specification Record - RA), as defined by the rating set program option setting (refer to activity
OPTN), or as overridden in the program dialog.
C-22
When current in amps is selected, the current in per unit is printed for any branch for which the
required bus base voltage has not been entered (i.e., if it is zero).
On an impedance diagram, unless NONE is specified for ANNOPT, the ANNOPT entry is ignored
and branches are annotated as described in Branch Record - LI and Two-Terminal dc Transmission
Line Record - DC.
Bus Annotation Record

The bus annotation specification record is of the form:
AN, BU, NAMOPT, VLTOPT
The valid entries in the NAMOPT field are as follows:
NAME Display the twelve-character bus name. If a bus has a blank name, no identifier is
printed for the bus. This is the default bus identification option when the names
output option is in effect.
NUMBER Display the bus number. This is the default bus identification option when the
numbers output option is in effect.
BOTH Display the bus name above the bus number.
NONE Suppress bus identification annotation.
The selection of bus names, which are up to twelve characters, may require adjustment of coordi-
nates in the Drawing Coordinate Data File if the diagram was set up using the numbers output
option (bus numbers are at most six digits).
The valid entries in the VLTOPT field are as follows:
VPU Display bus voltage magnitude in per unit. This is the default bus voltage annota-
tion option.
VPU-ANGLE Display bus voltage magnitude in per unit and phase angle in degrees.
VPU-KV Display bus voltage magnitude in per unit and kV.
KV Display bus voltage magnitude in kV.
KV-ANGLE Display bus voltage magnitude in kV and phase angle in degrees.
ANGLE Display bus voltage phase angle in degrees.
NONE Suppress bus voltage annotation.
On a flow diagram, when voltage in kV is selected, the voltage in per unit is printed for any bus
where base voltage has not been entered (i.e., if it is zero).
On a flow diagram, voltage and/or angle are printed as zero for any bus where type code is four
(i.e., for disconnected buses).
On an impedance diagram, for any VLTOPT specification except NONE, bus base voltages in kV
are printed.
C-23
Equipment Annotation Record

The equipment annotation specification record specifies the annotation option for load, generator,
shunt, and multi-terminal dc line elements and is of the form:
AN, EQ, ANNOPT
MW-MVAR Display MW and Mvar values. This is the default equipment annotation option.
MVA Display MVA values for load, generator and shunt elements. Multi-terminal dc
lines have MW and Mvar displayed.
NONE Suppress equipment annotation.
On an impedance diagram, unless NONE is specified for ANNOPT, the ANNOPT entry is ignored
and equipment is annotated as described in Multi-Terminal dc Transmission Line Record - MD,
Load Records - LO, LP, LC, and LY, Shunt Record - SH, and Generator Record - GE.
Activity Annotation Record

Activity annotation specification records define the branch annotation conventions to be used when
the Drawing Coordinate Data File is specified to activity GDIF. These records are of the following
form:
AN, AC, ACTNAM, ACTOPT
The valid entries in the ACTNAM field are GDIF and SCGR. An activity annotation record is ignored
unless its ACTNAM field matches the name of the activity being executed.
The valid entries in the ACTOPT field are as follows:
IGNORE Ignore the option field on each branch record and display data at both ends of the
branch. Branches where LI or TR coordinate data records contain one of the radial
line option field entries (see Table <$TableTitleC-2) are annotated at the from bus
end only. The use of multiple branch records to define the branch path is detected
using this option and such branches are annotated on their first and last line
segments. This is the default convention used by activity SCGR.
HONOR Annotate each branch according to the option field on its branch record. This is the
default convention used by activity GDIF.
Transformer Annotation Record

The transformer annotation specification record is of the form:
AN, TR, ANNOPT
NA-SYM Use the North American transformer symbol (symbol number 140 of Figure C-1 for
two-winding transformer and symbol number 155 of Figure C-1 for three-winding
transformer) and display only primary winding for two-winding transformer; this is
the default transformer annotation option.
C-24
EU-SYM Use the European transformer symbol (symbol number 151 of Figure C-1 for two-
winding transformer and symbol number 154 of Figure C-1 for three-winding trans-
former) and display only primary winding for two-winding transformer.
NA-WN2 Use the North American transformer symbol (symbol number 140 of Figure C-1 for
two-winding transformer and symbol number 155 of Figure C-1 for three-winding
transformer) and display both windings of two-winding transformer.
EU-WN2 Use the European transformer symbol (symbol number 151 of Figure C-1 for two-
winding transformer and symbol number 154 of Figure C-1 for three-winding trans-
former) and display both windings of two-winding transformer.
Summation Block Structure

The summation block structure provides for:
• Initializing a summing variable; usually, the initial value of the summing variable is zero,
but a non-zero value may be specified.
• Specifying individual ac branches, generator buses, and/or load buses where active
power components of line flow, generation, and load, respectively, are added to or sub-
tracted from the summing variable.
• Specifying a character string to be printed in front of the calculated value of the sum-
ming variable anywhere on the one-line diagram.
Each summation block structure consists of:
• One summation record, SUM or SU (see below).

• Optionally followed by one or more summation participation records GN, BL, and LF
(see below).
• Followed by one terminator record, EN (refer to Terminator Record - EN).
Summation records are of the form:
SU, O, '...text...', X, Y, TSIZ, TANG, CNST
where:

text Is the character string to be displayed in front of the summing variable's value. It
must be enclosed in single quotes and is limited to 40 characters.
X,Y Is the (x,y) coordinate of the first character of the text string, specified in inches.
TSIZ Is the character height specified in inches. TSIZ must be between 0.05 and 1.5 in.
TANG Is the angle of rotation of the character string, specified in degrees between 0 and
360; 0 degrees is the angle at which the title lines are written on the diagram.
CNST Is the initial value to be assigned to the summing variable. The default value is zero.
The option field is used to designate a line width, pen number, or color for the drawing of the text.
It is the user's responsibility to ensure that the designated number is appropriate for the graphics
C-25
The summation record in the summation block structure may be followed by summation participa-
tion records. These define the generator buses, load buses, and ac branches where active power
components are to be included in the summation. The summation participation records may be
entered in any order and are of the following forms:
GN, O, IB (for bus generation)

BL, O, IB (for bus load)
LF, O, IFR, ITO, ID, DIR (for ac branch flow)
where:
O Is a valid option (blank, + or -). Blank or + indicates that the active power of the
corresponding network element is to be added to the summing variable; - indicates
that it is to be subtracted from the summing variable.
IB Is a bus identifier.
IFR Is the from bus identifier.
ITO Is the to bus identifier.
ICKT Is the circuit or multi-section line grouping identifier; default value is '1'.
DIR Is either F or T and indicates flow direction. Line flow is always calculated at the bus
IFR end of the line; if DIR is F, flow is in the bus IFR to bus ITO direction, and if it is
T, flow is in the bus ITO to bus IFR direction. DIR is F by default.
If an element specified on a summation participation record is out-of-service, it does not contribute

to the summation.
The following records illustrate an example of the summation block structure:
SUM, ,'AREA 1 = ', 4.8 2.4 0.12 45. 0.

GN,+,101
GN,+,102
LF,-,151 201 1 F
LF,-,152 202 1 F
BL,-,151
EN
C-26
Program Operation Manual BMAT
C.5 BMAT
Activity BMAT and the PTI network loss coefficient program, BMATRIX are no longer supplied with
PSS®E.
C.6 MENU
Activity MENU is no longer supplied with PSS®E.
C.7 WORK
At PSS®E-28, the use of a power flow working file by PSS®E was eliminated. Therefore, the
working case retrieval activity WORK no longer exists.
C.8 XLIS
The windows-based power flow data modification activity XLIS is no longer supplied with PSS®E.
It has been replaced by similar functions in the Spreadsheet View of the Graphical User Interface
(GUI). Chapter 2 of the PSS®E GUI Users Guide describes the Spreadsheet View.
C.8.1 Equipment Status Changes and the Spreadsheet View

In addition to modifying parametric data, the service status of equipment in the working case may
be modified from the Spreadsheet View.
Associated with each ac series branch is a status flag which is initially set to one (for in-service) or
zero (for out-of-service) as specified on the branch data record or in the transformer record block
when a new branch is introduced into the working case with activities READ, TREA, or RDCH. The
status of a branch may be modified by changing this flag. Out-of-service branches and their data
remain with the case as it is saved and retrieved with activities SAVE and CASE, and are simply
ignored during the execution of other PSS®E activities such as SOLV or POUT.
If branch status changes isolate a bus, the user must change the bus type code to four. Activities
TREE and OUTS and the power flow solution network connectivity check option (see Section 3.3.3
Program Run-Time Option Settings and activity SOLV) aid the user in identifying isolated buses and
islands.
When the specified branch is a member of a multi-section line grouping (see Multi-Section Line
Grouping Data), the same status change is automatically implemented in the working case for all
branches in the multi-section line. In addition, the bus type codes of the dummy buses are changed
to:
4 When the branch is being removed from service.

1 If the branch is being placed in-service and the bus has no generator data associ-
ated with it.
2 If the branch is being placed in-service and the bus has generator data associated
with it. In this case, the individual machine status flags, which are not changed in
this status processing of multi-section lines, determine which machines are returned
to service.
C-27
XLIS Program Operation Manual
The bus type codes of the endpoint buses of the multi-section line grouping are not changed in the
status processing of a multi-section line. As with single section lines, it is the user’s responsibility to
ensure that branch statuses and bus type codes are coordinated.
When changing the status of a three-winding transformer, status values of 0 through 4 are permitted
(see Transformer Data); the status flags of the three two-winding transformers which comprise the
three-winding transformer are set to the appropriate values. As with multi-section line groupings
and two terminal branches, the bus type codes of the endpoint buses of the three-winding trans-
former are not changed in the branch status processing.
FACTS devices may be blocked in a similar manner. A value of zero for MODE, the control mode
flag, indicates a blocked FACTS device (see FACTS Device Data).
The status of individual machines at a generator bus may be modified by changing the machine
status; plant total power output and power limits are automatically updated following a change of
machine power or status. A plant may be taken out-of-service either by changing the status of all
units at the bus to zero or by changing the bus type code to one or four (this is the recommended
approach because power flow solution activities will run slightly faster). Conversely, for a machine
to be treated as in-service, both its status must have the value one and the bus type code must be
either two or three.
Similarly, the status of an individual load at a bus may be modified by changing its load status, and
the status of an individual fixed bus shunt may be modified by changing its shunt status.
C-28
Appendix D
Command Line Options
Appendix D - Command Line Options
D-1

Executable Command Line Options
-buses {startup}
PSSE -inifile -embed -rspfile / -pyfile -argstr
-pyver -resetwrk
AcccBrwsGrid -inifile
-inpfile / {infile}
ConvertRaw -inifile {inver} {outfile} -nolog
{outver}
-inpfile / {infile}
CreateRaw -inifile -nolog
{outfile} {outver}
LineProp
ScenarioMgrCnvt
WECCLF -inifile
PSSPLT -inifile -gnikool -inpdev
D-2
IMD -inifile -gnikool

ASPNLF -inifile -nogui -inpdev
CMDYRE -inifile -nogui -inpdev
CNVxx -inifile -nogui -inpdev
CNVDRW -inifile -nogui -inpdev
CNVRSQ -inifile -nogui -inpdev
COMDAT -inifile -nogui -inpdev

COMFOR -inifile -nogui -inpdev
DBUILD -inifile -nogui -inpdev
RAWxx -inifile -nogui -inpdev
LSYSAN -inifile -inpdev
PSS®E 34.2
PLINC -inifile -inpdev
PSAP4 -inifile -inpdev

PSS®E 34.2
Executable Command Line Options
-buses
PsseCmd -inifile -inpdev
-pyver
TMLC -inifile
VCV -inifile
IPLAN <filename> -inifile -loop -comp / -run / -crun -[no]inc -[no]arg -[no]list -[no]stat -search
)
-input
WECCDS -inifile
) -dyre
-rwm -msg -motor -gnet -gwind -bfreq
-rdch
psseinit -inifile -buses
Meaning of symbols in table

a command line option specified
D-3
-name
as "name", followed by a value
-name named option with no value
/ set of options, only one allowed
[] option modifier
positional option (no option
<>
name)
unnamed option (order matters,
{}
but not position)

() all required if any are used

Meaning of command line options
options that take arguments (e.g. -inpdev filename):
-inifile specify an ini file (i.e. override default)
-inpdev specify a response file and arguments
-rspfile specify a response file
-pyfile specify a python file
-argstr specify arguments for -rspfile or -pyfile
-inpfile specify batch file; a series of sets of command line options
-gnikool set GUI mode (on or off)
-buses specify number of buses (i.e. override default)
Named options that do not take arguments (e.g. -embed)
-nogui suppress GUI; run from console
suppress GUI and run in background while batch commands are
-embed
supplied
D-4
-nolog suppress log file (log file generated by default)

-resetwrk reset the program workspace to system defaults
Unnamed arguments (i.e. specify values only)
{startup} one of the PSS®E startup files, see list below
{infile} input filename
{outfile} output file name

{inver} input file version
{outver} output file version
see IPLAN manual for those options that
Notes:
are unique to IPLAN
PSS®E 34.2
the options that are unique to WECCDS
correspond to the interactive dialog
-pyver specify the release of the python interpreter to be loaded

PSS®E 34.2
PSS®E startup files
These files either define a case or can be read in without a case. They are recognized by file extension:
*.pssxml, *.zip Scenario file
*.sav Saved case file
*.raw Power Flow raw data file
*.snp, *.srs Snapshot file
*.py, *.idv, *.irf, *.pse, *.psa, *.pyc, *.pyw Automation file
*.sld, *.sldxml, *.slt Slider file
*.out Channel output file
*.evs Event study file
*.dll Dynamic link library
*.cfg Comtrade file
D-5
*.drw Coordinate data file

*.xml PSSE XML configuration file

Command Line Options PSS®E 34.2
D-6

Program Operation Manual Del PSS

Uploaded by

Copyright:

Available Formats

Program Operation Manual Del PSS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Program Operation Manual Del PSS

Uploaded by

Copyright:

Available Formats

PSS®E 34.

Siemens Industry, Inc.

Chapter 2 - File System

Creating Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

Chapter 4 - Operating Modes

Subsystem Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8

Chapter 5 - Power Flow Data Entry, Modification, and Display Activities

CC=4 and CC=14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20

Electrically Disconnecting a Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-56

5.23.2 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-84

5.34.1 Importing a Long Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-114

Listing Outaged Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-138

5.49.1 Operation of Activity RAWD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-160

Chapter 6 - Power Flow Solution Activity Descriptions

Capacitor Commutated DC Lines. . . . . . . . . . . . . . . . . . . . . . . . . . 6-30

6.9.6 Substation Reliability Assessment Analysis . . . . . . . . . . . . . . . . . . . . . . . . .6-81

Performing Multi-Level AC Contingency Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-147

6.18.2 Implementing a Specific PV Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-223

Chapter 7 - Geomagnetically Induced Currents

Chapter 8 - Linear Network Analysis

Estimating Severity Rankings for Single Line Outage Contingencies . . . . . . . . . . . . . . . . . . . 8-29

Performing Interchange Limit Analysis with Two Opposing Systems . . . . . . . . . . . . . . . . . . . .8-78

Chapter 9 - Network Reduction

9.8.1 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27

Chapter 10 - Unbalanced Fault Analysis

10.6.15 Secondary Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-31

Calculating pi-Equivalent, Single Transmission Line Unbalance . . . . . . . . . . . . . . . . . . . . . 10-103

Chapter 11 - Power Flow Reports

11.6.1 Operation of Activity LODR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-34

11.23.1 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-94

Chapter 12 - Balanced Switching

Converting Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6

Chapter 13 - Transmission Pricing and Open Access

13.3.1 Output Report Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5

Chapter 14 - Optimal Power Flow

OPF Modeling Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-14

14.14.1 Solution Termination Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-62

Chapter 15 - Dynamic Simulation Activity Descriptions

Auxiliary Signal Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-18

Initializing Models for State-Space Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-52

Initializing Models for Extended Term Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-86

Chapter 16 - Program Automation

Unattended Execution of PSS®E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12

Chapter 17 - Result Retrieval

Chapter 18 - Implementing the Powerflow Customization Interface (PCI)

Chapter 19 - Using the Remedial Action Scheme API

Chapter 20 - Miscellaneous Activity Descriptions

Selecting Prompt Output Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-3

Chapter 21 - Dynamic Simulation Setup and Procedures

21.5.2 Performance Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-16

Chapter 22 - Example Data Files

Chapter 23 - Model Writing

Writing the Basic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-11

Chapter 24 - Event Studies

Chapter 26 - Node-breaker Modeling

Appendix A - Activity Summary

Appendix B - PSS®E Documentation

Appendix C - Legacy Activities

C.4.1 Drawing Coordinate Data File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2