PSSE Reference
PSSE Reference
May, 2011
Chapter 2 - Printing
2.1 Printer Drivers: Microsoft and Siemens PTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.2 Siemens PTI Printing Parameter Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Most of these programs are normally executed through shortcut icons (see Figure 1-1 and Figure 1-
2); others, as noted below, are primarily intended to be executed from the Command Prompt. Note
that all PSS®E programs may be executed from the Command Prompt if the user prefers.
Application* Description
AcccBrwsGrid The ACCC Post-processor is an application that reports the results of the PSS®E con-
tingency screening analysis performed by the PSS®E AC Contingency Calculation.
DBUILD Incorporates information on user-written plant-related models into the data file used by
activity CCON.
Application* Description
Compiles programs written in the IPLAN programming language in preparation for their
IPLAN
specification to the PSS®E activity EXEC.
PLINC Plots incremental cost curve data as contained in an Economic Dispatch Data File.
Calculates the transmission line constant data required by many power system analysis
TMLC
programs.
VCV Plots generator V-curves; see PLINC and Generator Reactances and Saturation Data.
* These applications, when viewed in the PSSBIN directory, will have the current PSS®E version number appended to
the name of the executable (*.exe) file. A corresponding .BAT file with the names listed in the table initiate the corre-
sponding .exe file. In most applications the name of the .BAT file should be used.
Application* Description
CHECKPDD Check to see if the system driver for the Activator locks has been installed.
CMDLUSR Command file to compile any number of FOR, F90, F, C, and CPP files. (Be sure to
read the restrictions listed at the top of this file!)
Createusrdll An application program used for creating a PSS®E dynamic simulation user dll. This
combines the functions of compile.bat and cload4.bat of PSS®E dynamic simulation.
REACTPSSE32 Reactivate PSS®E with a new activation string (will not install any additional files).
REMOTEUP Program for updating data stored in certain types of hardware locks.
ShowLockNum Program to display the SuperPro lock number connected to the computer.
Command-Line Only program to set the Start In directory in the PSSLF4 and PSSDS4
STARTIN
shortcuts to the current directory.
* These applications, when viewed in the PSSBIN directory, will have the current PSS®E version number appended to
the name of the executable (*.exe) file. A corresponding .BAT file with the names listed in the table initiate the corre-
sponding .exe file. In most applications the name of the .BAT file should be used.
Application* Description
CMDYRE From a PSS®E Dynamics Data File and a Machine Impedance Data File, builds a file
containing card image records in the IEEE format for the exchange of stability data.
COMDAT From a file containing card image records in the IEEE format for the exchange of
stability data, builds a PSS®E Dynamics Data File and a Machine Impedance Data File.
COMFOR From a file containing power flow data records in IEEE Common Tape Format, builds a
PSS®E-24 Power Flow Raw Data File.
CNVDRW From a Drawing Coordinate Data File in the format required for PSS®E-15 through
PSS®E-23, builds a Drawing Coordinate Data File in the form required by PSS®E-24 or
later.
CNVRSQ From a Sequence Data File in the format required for PSS®E-21 or earlier, builds a
Sequence Data File in the form required by PSS®E-22 through PSS®E-26.
CONVERTRAW Reads any previous PSS®E Power Flow Raw Data File produced by PSS®E-15 or later,
and builds a PSS®E Power Flow Raw Data File in any later format.
CREATERAW Reads a PSS®E Saved Case File, and builds a PSS®E Power Flow Raw Data File
compatible with PSS®E-15 or later.
From a file containing card image records in the PJM PSAP Version 4 or 5 power flow
PSAP4
program data format, builds a PSS®E-23 Power Flow Raw Data File.
Converts Western Electricity Coordinating Council (WECC) power flow program data
WECCLF
format to PSS®E RAWD format.
* These applications, when viewed in the PSSBIN directory, will have the current PSS®E version number appended to
the name of the executable (*.exe) file. A corresponding .BAT file with the names listed in the table initiate the corre-
sponding .exe file. In most applications the name of the .BAT file should be used.
The following sections describe each auxiliary program and references an execution time param-
eter file, along with the name of its parameter file (see PSS®E Program Operation Manual,
Section 3.3.3: Program Run-Time Option Settings):
The auxiliary program AcccBrwsGrid is a Windows® application that post-processes the ACCC
Solution Output file (*.acc) and provides spreadsheet-style reports of these results. This application
is documented in its own Help window.
The auxiliary program DBUILD constructs the binary data file used by the plant-related model data
changing activity, CCON. In addition to information on the standard models that are supplied with
PSS®E, DBUILD allows the user to include in the binary data file information on user-written plant-
related models being used in his system model.
DBUILD first processes the source file containing data on the PTI-supplied plant-related models. It
then instructs the user to enter the name of a data file that contains records describing user-written
models. This file is then processed and the request for a user file is again made. This cycle is
repeated until a zero or simply a carriage return is entered in response to the request for a filename.
Information on each model is contained on a series of records in the file. The first record for each
model block is of the form:
$ name,NC,NI,'desc'
where:
This is followed by NC records describing the NC CONs used by the model in the same order as
they appear on the model's data sheet, followed by NI records describing the model's NI ICONs in
the same order as they appear on the data sheet. Each of these records is of the form:
NW,ND,'text'
where:
Currently, the 'desc' field on the first record and the NW and ND items on the remaining data records
are ignored; these data items may used in a future update.
Following is an example for the block of records which may be used for the model CSVGN4:
The auxiliary program IMD plots induction motor torque, current and power factor versus slip or
speed. These values may also be presented in tabular form. IMD may also calculate and report
motor conditions for specified values of terminal voltage, speed, motor base, and system base.
Initial estimates of model data may be provided in a data file that contains a DYRE format data
record for one of the models CIM5BL, CIMTR1, CIMTR2, CIMTR3, or CIMTR4. Model parameters
in equivalent circuit form may then be modified interactively. IMD outputs equivalent circuit param-
eter data as used by CIM5BL; output may be either in tabular form or in the form of a dynamics data
input record for use by activity DYRE.
Machine manufacturers typically supply the user with a set of induction machine curves and/or a
partial set of machine parameters. Users must estimate the remaining equivalent circuit parame-
ters. IMD is used to plot and/or print induction motor characteristics based on available data and
user estimates. Curves may be compared to those supplied by the manufacturer and parameters
may be modified interactively. This process is repeated until a set of plots reasonably match those
supplied by the manufacturer.
The PSS®E Program Application Guide contains additional details on motor modeling in PSS®E
and the use of IMD.
The auxiliary program IPLAN compiles programs written in the IPLAN programming language in
preparation for their specification to the PSS®E activity EXEC. IPLAN is documented in the PSS®E
IPLAN Program Manual.
The auxiliary program LINEPROP calculates electrical parameters for overhead transmission and
distribution lines. It is described in the PSS®E Line Properties Calculator Manual. LINEPROP is
supplied to those PSS®E users whose installation includes the Transmission Line Characteristics
Program section of PSS®E. PC lessees who receive LINEPROP also receive the TMLC program
and its documentation, Transmission Line Characteristics (TMLC) Program Manual. LINEPROP is
replacing the older TMLC program and should be used in lieu of TMLC. TMLC will be dropped in a
future release.
The auxiliary program LSYSAN is used to perform small disturbance dynamic analysis. LSYSAN is
supplied to those installations whose lease includes the Linear Dynamic Analysis Program section
and is documented in the PSS®E Program Application Guide.
The auxiliary program PLINC plots incremental heat rate curves from an Economic Dispatch Data
File of the form used by activity ECDI (see PSS®E Program Operation Manual, Section 5.31:
Performing Unit Commitment and Economic Dispatch). Curves for up to four machines may be
plotted on each page.
The auxiliary program PSSPLT processes PSS®E dynamic simulation Channel Output Files. It is
documented in the PSSPLT Program Manual.
The auxiliary program TMLC calculates the transmission line constant data required by many power
system analysis programs. It is described in the Transmission Line Characteristics (TMLC) Program
Manual. TMLC is supplied to those PSS®E users whose installation includes the Transmission Line
Characteristics Program section of PSS®E. PC lessees who receive TMLC also receive the
LineProp program and its documentation, PSS®E Line Properties Calculator Manual. TMLC is
being replaced by LINEPROP and will be dropped in a future release.
1.1.10 V Curves
Auxiliary Program VCV
The auxiliary program VCV calculates full load EFD for a user specified set of machine parameters,
terminal voltage and machine loading. Optionally, the generator V curves may then be plotted. VCV
accepts machine parameters as used in the PSS®E generator models GENROE, GENROU,
GENSAE, and GENSAL.
Machine manufacturers typically supply the user with a set of synchronous machine V curves
and/or a partial set of machine parameters. Users must estimate the remaining parameters. VCV is
used to plot V curves based on available data and user estimates. Curves can be compared to
those supplied by the manufacturer and parameters can be improved interactively. This process is
repeated until a set of plots reasonably match those supplied by the manufacturer. This approach
is particularly useful if the machine's saturation constants are suspect.
Consequently, if you have a customized DSUSR.DLL (created by using CLOAD4) in your directory,
and you start Dynamics with C:\WORKING\ONE set as your working directory, your custom DSUSR
will be loaded instead of the default. If, on the other hand, you start Dynamics C:\WORKING\TWO
set which does not contain a customized DSUSR.DLL, the default copy will be loaded from PSSLIB.
Default copies of all of the user-replaceable DLLs, DSUSR, DSUSRNEW, PSSUSR, PSSUS-
RNEW, IPLUSR, and IPLUSRNEW are stored in PSSLIB. If you wish to permanently change the
default for one of these DLLs, you may, for example, create a new DSUSR.DLL file by running
activity DYRE, compiling your new CONEC.FLX and CONET.FLX, running CLOAD4, and then
copying the resulting DSUSR.DLL file into the PSSLIB directory. Once placed there, your new copy
will become the default for all future executions of Dynamics.
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
directory the directory that contains the customized DLL. Alternatively, if you choose to start
programs from the 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-32 shortcuts. PSS®E-32 includes a program called
STARTIN, which should be run from the PSS®E-32 Command Line. When executed, this program
(after prompting) will change the working directories of all standard (noncustom) shortcuts associ-
ated with PSS®E-32 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 their original settings, use the shortcut
"PSSE-32 Example Directory" under the PSS®E Utilities menu, to bring up a command prompt and
give the STARTIN command.
filename.bat
which will compile the CONEC and CONET subroutines. The compilation must be run from the
Command Prompt. Once the compilation is complete, you must execute CLOAD4 at the Command
Prompt to create a new DSUSR.DLL file.
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 will compile any number of FLX, FOR, F90, F, C, and
CPP files at one time. For example, the command:
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 directo-
ries 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.
User-Written Models
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 automatically 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:
Createusrdll is an application program used for creating a dynamic simulation user dll. This
combines the functions of compile.bat and cload4.bat. You can launch the program from the
desktop icon created at PSS®E installation or from the Windows® Start menu.
Option Description
The successful compilation of the source files, corresponding “object” codes are automat-
ically added to List of Model Object/Lib Files.
Additionally, other pre-compiled (i.e., existing) object/library files can be added to the list
Input using one of the following methods.
Object/Library • Object/Library files from input text file when opened using Open File List.
File(s)
• Select one or more files using [Browse] button.
• Enter the filename.
This will populate the right side box titled List of Model Object/Lib Files.
Remove and These controls are used for removing Source or Object/Lib Files from Selection.
Remove All The following methods can be used to remove files from either the List of Model Source
Files, or the List of Object/Lib Files.
• Select a file and use Remove button to remove selected file.
• Use Remove All to remove all files.
• Double click a filename to remove selected file.
When a file is removed from List of Model Source Files the corresponding file
from the List of Model Object/Lib Files is not removed.
Move Up Moves one or more source files up the List of Model Source Files. When a FORTRAN
source file is a FORTRAN module file, this file needs to compiled first, so that the .mod
created by compiler is available for other FORTRAN source files during their compilation.
To move a file up, select the appropriate source file in List of Model Source Files and use
Move Up button to bring the selected file ahead of another FORTRAN file.
Compiles all the files in List of Model Source Files, and adds the resulting objects to List of
Compile
Model Object/Lib Files.
This creates a dll by linking all the files in List of Model Object/Lib Files. The dll thus
Create DLL
created will be stored in the file whose name was specified in Output dll File.
Option Description
Compile+Create Compiles all the files in List of Model Source Files, adds objects to List of Model
DLL Object/Lib Files, and creates a dll by linking all the files in List of Model Object/Lib Files.
Open File List Specification of the user dll filename, the source files to be compiled, and the names of
object/library files (collectively called File List) that are needed for creating the user dll can
be done via GUI as explained above. Having specified the files needed for creating the dll,
File List can be saved in a text file using the Save File List. Alternatively the text file con-
taining File List can be created using a text editor in a format as given in Application
Notes.
Save File List This saves the source filenames, object/library filenames and dll name (i.e., File List) to a
text file. This file then can be opened using Open File List button. The file is saved in a
format described in Application Notes.
Application Notes
The format of Input Text File is as given below.
# File: mymodelfiles.txt
# Input to "createusrdll" program.
# Any text on a line after "#" is treated as comment.
# The file has three sets data records, with each record title as:
# [dll name], [source filenames] and [object/lib filenames].
# Provide only one dll name in [dll name] record.
# Provide each source filename (.flx, .for, .f90, .f) on a separate
line in [source filenames]
# record.
# Provide each object (.obj) or library (.lib) on a separate line
in [source filenames] record.
[dll name]
c:\work_dir\myusrmodel.dll
[source filenames]
c:\work_dir\mymodel_module.for
c:\work_dir\mymodel.for
c:\work_dir\mycontroller.flx
[object/lib filenames]
c:\work_dir\mymodel.dll
c:\work_dir\pssewind.lib
c:\work_dir\myother.obj
The auxiliary program CMDYRE32 reads a Dynamics Data file (*.dyr) and its corresponding
Machine Impedance Data file (*.rwm) and outputs the data in IEEE dynamics data format1. See
PSS®E Program Operation Manual, Section 14.1.1: Dynamics Model Raw Data File Contents and
Section 5.4.1: Machine Impedance Data File Contents, respectively, for content information.
Through a brief dialog, the user is instructed to designate the two input files and the output file. Prog-
ress messages may be directed either to the user's terminal or written to a message file.
The user is given the option of including or omitting data records for machines designated as out-
of-service in the Machine Impedance Data File. If such machines are included, their power fractions
are set to zero on their output file data records.
The user has the opportunity to designate the system base MVA and to specify descriptive
comment lines to be included in the output file.
Not all PSS®E models correspond to models in the IEEE format. Any model references which are
ignored or approximated are tabulated at the message device.
For machines for which XTRAN is nonzero in the Machine Impedance Data File, the same bus
number and name is included on the generator data record as the terminal and high voltage side
buses. It is the user's responsibility to reconcile the bus identification with the power flow case in
the target program.
The auxiliary program COMDAT reads a data file in IEEE dynamics data format1 and outputs the
data in the form of a Dynamics Data file (*.dyr) and its corresponding Machine Impedance Data file
(*.rwm). See PSS®E Program Operation Manual, Section 14.1.1: Dynamics Model Raw Data File
Contents and Section 5.4.1: Machine Impedance Data File Contents, respectively, for content
information.
Through a brief dialog, the user is instructed to designate the input file and the two output files.
Program messages may be directed either to the user's terminal or written to a message file.
The user is given the option of upgrading classical and transient level machine representations to
subtransient level models; details on this conversion are given below.
Upon completion of COMDAT, the user should review and reconcile any program messages before
reading the data into PSS®E.
The following assumptions and data changes are made in converting the stability data into PSS®E
format.
1 The IEEE dynamics data format is defined 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.
Generator Data
If the generator model designation is not specified, COMDAT assumes the following:2
S1 = 0.11
S2 = 0.48
If T"do < 0.04, T"do = 0.04 s.
If Xd < 0.0:
Xq = 0.96Xd pu
Xq = 0.95Xd pu
2 All time constants are entered in seconds, and all reactances are entered in per unit on a machine MVA base and
machine rated terminal voltage.
For IEEE "2.n" models (i.e., GENSAL and GENROU), COMDAT assumes:
DC1 IEEEX1
DC2 EXDC2
DC3 IEEEX4
AC1 EXAC1
AC2 EXAC2
AC3 EXAC3
AC4 EXAC4
ST1 EXST1
ST2 EXST2
ST3 EXST3
Governor Data
The IEEE type one, two, and three speed governing models are handled as the PSS®E models
IEEEG1, IEEEG2, and IEEEG3, respectively. For the type one model, the following data changes
are made:
If Uo = 0.0, Uo = 1.0
If Uc = 0.0, Uc = -1.0
The auxiliary program COMFOR reads a data file in IEEE power flow data format3 and outputs the
data in the form of a PSS®E-24 Power Flow Raw Data File (see PSS®E Program Operation
Manual, Section 5.2.1: Power Flow Raw Data File Contents). Only the 132 column format is
recognized.
Through a brief dialog, the user is instructed to designate the input and output files. Program
messages may be directed either to the user's terminal or written to a message file.
3 The IEEE power flow data format is defined in Common Format for Exchange of Solved Load Flow Cases, IEEE
Transactions on Power Apparatus and Systems, Vol. PAS-92, No. 6 November/December 1973, pp. 1916-1925.
The user is given the option of specifying a "generator netting file". If specified, this file contains bus
numbers, entered one per line in free format, of buses whose generation is to be netted with their
loads. Such buses become PSS®E Type 1 buses.
The following assumptions and data changes are made in converting the Common Format data into
PSS®E format.
Bus Data
All single quotes ( ' ) in bus names are changed to dashes (-).
Generator Data
IEEE Type 0 buses with nonzero generation are set to Type 2 buses with fixed generator output.
IEEE Type 1 buses are set to fixed generator output Type 2 buses. If the desired voltage (Vsched)
is zero, the scheduled voltage is set to the average of the voltage limits.
If final voltage < 0.0, Vsched = 1.0 pu on machine terminal voltage base
Transformer Data
If step size < 0.0,
If Type 4 transformer (phase shifter), STEP = 1.25º
Otherwise, STEP = 0.00625 pu on bus voltage base
For voltage controlling transformers, if (VMA-VMI) < STEP,
VMI = VMA - STEP
VMA = VMA + STEP
For flow controlling transformers, if VMA < VMI,
VMI = VMA - 2.5 MW/Mvar
VMA = VMA + 2.5 MW/Mvar
If RMA < RMI,
RMI = RMA - 4.0*STEP
RMA = RMA + 4.0*STEP
Zone Data
All single quotes ( ' ) in zone names are changed to dashes (-).
The auxiliary program CNVDRW reads a PSS®E-15 through PSS®E-23 Drawing Coordinate Data
File and outputs data in the Drawing Coordinate Data File format required by the current release of
PSS®E (see PSS®E Program Operation Manual, Section C.4.1: Drawing Coordinate Data File
Contents).
Through a brief dialog, the user is instructed to designate the input and output files.
All data records are copied verbatim except for data records describing loads. The interpretation of
the option field on the "LO" record has been changed, and "LP", "LC" and "LY" records have been
introduced (see PSS®E Program Operation Manual, Load Records - LO, LP, LC, and LY). In addi-
tion, the load symbol is larger than it was at PSS®E-23 and earlier releases of PSS®E in order to
accommodate the load identifier when an individual load is being drawn. The endpoint coordinates
on load records are modified so that the end of each load symbol lies at the same location that it
did before.
Following the data conversion process, another pair of data files may be specified.
The auxiliary program CNVRSQ reads a PSS®E-21 (or earlier) Sequence Data File and outputs the
data in the Sequence Data File format required by PSS®E-22 through PSS®E-26.
Through a brief dialog, the user is instructed to designate the input and output files.
All data records are copied verbatim except for data records describing zero sequence mutual
couplings on which the geographical "B" factors are converted to conform to their more flexible defi-
nitions introduced in PSS®E-22 (see PSS®E Program Operation Manual, Zero Sequence Mutual
Impedance Data).
The auxiliary program CONVERTRAW reads a PSS®E Power Flow Raw Data File in any of the
formats required by PSS®E-15 through PSS®E-31, and outputs data records in the Power Flow
Raw Data File format required by a selected PSS®E release later than that of the input file. The
following format conversions are supported:
PSS®E-31 PSS®E-32
The user is instructed to designate the Power Flow Raw Data File input and output filenames, as
well as the PSS®E revisions of the input and output files. The user also indicates if any of the input
file records use extended bus names as bus identifiers. The output records are then written.
The "old" format data file is expected to be in the form required by activity READ or READ,NAME;
specifically, the first three records are assumed to be the Case Identification Data records.
where:
Character INNAME*260 Is the name of Input Power Flow Raw Data file (input; no default allowed).
Character INVERSTR*12 Is the version number corresponding to the format of INNAME
(input; no default allowed).
INVERSTR is in the format of a PSS®E release number.
Example: If INNAME format is of PSS®E-29.5.1:
INVERSTR = ’29’
= ’29.5’
= ’29.5.1’
Integer NUMNAM Is the flag for bus number or name specification on input records
(input; no default allowed).
NUMNAM = 0 bus numbers.
NUMNAM = 1 bus names.
Is the name of Output Power Flow Raw Data file (input; no default
Character OUTNAME*260
allowed).
1.3.7 Create Power Flow Raw Data File for Use by Legacy PSS®E Releases
Auxiliary Program CREATERAW
The auxiliary program CREATERAW reads a Saved Case File written by the PSS®E activity CASE
of PSS®E-16 or later, and outputs data in the Power Flow Raw Data File format required by a
release of PSS®E which preceded the current release. CREATERAW can output data records in
formats compatible with the following PSS®E releases:
If the specified Saved Case File was written by PSS®E-30 or later and contains any six digit bus
numbers, and a Raw Data file prior to PSS®E-30 is to be created, an appropriate error message is
printed and CREATERAW is terminated.
If the Saved Case File specified to CREATERAW was written by PSS®E-30 or later, control modes
for switched shunts are left at their current values.
where:
Character INNAME*260 Is the name of Input Power Flow Saved Case file (input; no default
allowed).
Character OUTNAME*260 Is the name of Output Power Flow Raw Data file (input; no default
allowed).
Character OUTVERSTR*12 Is the version number corresponding to the format of OUTNAME
(input; no default allowed).
OUTVERSTR is in the format of a PSS®E release number.
Example: If INNAME format is of PSS®E-29.5.1:
INVERSTR = ’29’
= ’29.5’
= ’29.5.1’
The auxiliary program PSAP4 reads a data file in the format of the PJM Power System Analysis
Package (PSAP) power flow program version 4 or 5, and outputs the data in the form of a
PSS®E-23 Power Flow Raw Data file. This file may be converted to a file in the current PSS®E
Power Flow Raw Data File format (*.raw) using the auxiliary program CONVERTRAW. See PSS®E
Program Operation Manual, Section 5.2.4: Subsystem READ.
Through a brief dialog, the user is instructed to designate the input and output files. Program
messages may be directed either to the user's terminal or written to a message file.
The following assumptions and data changes are made in converting the PSAP data into PSS®E
format.
Bus Data
All single quotes ( ' ) in bus names are changed to dashes (-).
Base voltages are decoded from the last four characters of the 12-character bus name. If a value
greater than 999 is decoded, the last three characters are used. If a valid numerical value is not
found in the final four, three, or two characters, the bus base voltage is set to zero.
Generator Data
Nonregulating buses with generation are set to Type 2 buses with fixed generator output.
Branch Data
Impedance is converted from "MVA BASE" or percent to per unit.
BUSTIEs are given an impedance of j0.0001 pu on system bus voltage and MVA base.
Transformer Data
If phase shift angle is nonzero:
Phase shift angle is negated
If TAP = 0.0, TAP = 1.0 pu
If second line data card is read and TAP = 0.0, TAP = 1.0
For voltage controlling transformers, when no second line data card is entered, the tap step is set
to 0.00625 per unit on system bus voltage base. The desired voltage band is set to the desired
voltage setpoint +0.00625 per unit if a nonzero controlled bus is specified, and to 0.9 pu through 1.1
pu if no controlled bus is specified. When the second line data card is entered, the designated
voltage band is used and the tap step is determined from the ratio limits and the number of tap posi-
tions available.
For MW controlling phase shifters, the MW flow limits are set to the desired MW flow +2.5 MW.
Phase shift angle limits are negated and interchanged.
For Mvar controlling phase shifters, the Mvar flow limits are set to the desired Mvar flow +2.5 Mvar.
The tap step is determined from the ratio limits and the number of tap positions available.
The auxiliary programs WECCLF, RAWECC, and WECCDS, which convert data between the
WECC power flow and stability program data formats and PSS®E data input file formats, are
described in the PSS®E–WECC Data Conversion Manual.
From a Power Flow Raw Data File in the format required for PSS®E-24 through
PSS®E-26, builds a Power Flow Raw Data File in the form required by PSS®E-27 or
CNV27 PSS®E-28, and then provides for the conversion to PSS®E-27 or later of any corre-
sponding Sequence Data File which is in the form required for PSS®E-22 through
PSS®E-26.
From a Power Flow Raw Data File in the format required for PSS®E-27 or PSS®E-28,
CNV29
builds a Power Flow Raw Data File in the form required by PSS®E-29.
From a Power Flow Raw Data File in the format required for PSS®E-29, builds a Power
CNV30
Flow Raw Data File in the form required by PSS®E-30.
From a Power Flow Raw Data File in the format required for PSS®E-30, builds a Power
CNV31
Flow Raw Data File in the form required by PSS®E-31.
From a Power Flow Raw Data File in the format required for PSS®E-31, builds a Power
CNV32
Flow Raw Data File in the form required by PSS®E-32.
RAW23 From a PSS®E Saved Case File, builds a PSS®E-23 Power Flow Raw Data File.
RAW26 From a PSS®E Saved Case File, builds a PSS®E-26 Power Flow Raw Data File.
RAW28 From a PSS®E Saved Case File, builds a PSS®E-28 Power Flow Raw Data File.
RAW29 From a PSS®E Saved Case File, builds a PSS®E-29 Power Flow Raw Data File.
RAW30 From a PSS®E Saved Case File, builds a PSS®E-30 Power Flow Raw Data File.
RAW31 From a PSS®E Saved Case File, builds a PSS®E-31 Power Flow Raw Data File.
In a very small number of cases, you may wish to use a Siemens PTI graphics driver. If so, the
details are described in Siemens PTI Printing Parameter Files. Siemens PTI spool device drivers
operate by referencing the primary PSS®E printing parameter file, PARMPR.DAT. When a Siemens
PTI output device is selected, PARMPR.DAT is accessed (along with supplemental parameter files)
and its user-specified printing parameters are applied to the output. In the following sections, all
PSS®E parameter files are referred to without their “.DAT” file extensions.
2.2.1 PARMPR
PARMPR is the printing parameter file referenced by PSS®E. PARMPR contains instructions to
PSS®E on how, where, and in what format to send output to a printer, plotter, or file. These instruc-
tions are referred to as printing parameters. For example, you could customize such printing
characteristics of a Siemens PTI spool device as start and end strings, banner pages, queue types,
and page orientation.
Below is a sample PARMPR file with five printer entries including comment lines. Each entry in the
file contains one or more parameter assignments in the following form:
where:
PRINTER 1 = WIN-PRINTER,WIN-PRINTER
!
! Print to HP Laserjet - portrait orientation.
PRINTER 2 = LPT1,HP_Portrait
PRINTER_TYPE 2 = 0
START_STRING 2 = ’ ’,27,’&l0O’,27,’(s16.66H’
END_STRING 2 = ’ ’,27
!
! Print to HP Laserjet - landscape orientation.
PRINTER 3 = LPT1,HP_Landscape
PRINTER_TYPE 3 = 0
START_STRING 3 = ’ ’,27,’&l1O’,27,’(s16.66H’
END_STRING 3 = ’ ’,27
!
PRINTER 4 = COM2,QMS_PS,POSTSCRIPT,PSPLOT
PRINTER_TYPE 4 = 2
!
PRINTER 5 = LPT1,NX-1000,STAR
PRINTER_TYPE 5 = 0
END_STRING 5 = 12
Printer #1 is reserved for access to the default Microsoft printer and should not be redefined.
Printer #1 contains the keyword, WIN-PRINTER, to access the Microsoft Windows default printer.
This entry uses Microsoft drivers. All other entries use Siemens PTI spool device drivers.
Printers #2 and #3 are different entries for the same HP Laserjet Series II printer attached to LPT1.
The start string for Printer #2 indicates a portrait page orientation and condensed print. Printer #3
includes a start string indicating a landscape page orientation and condensed print.
Printer #4 is a QMS 800 II PostScript printer on COM2. Before using, be sure COM2 is set properly
via the MODE command.
Printer #5 is a STAR NX-1000 dot-matrix printer on LPT1. An END_STRING is used to give a form-
feed (12) at the end of the print job.
The beginning-of-job and end-of-job strings for a PostScript printer are specified in the
PSCRIPT.DAT file. Use of such strings is HIGHLY recommended.
Comment lines may be used anywhere in the parameter files. The format for comment lines is:
! string
* string
where string can be any sequence of characters.
If any modifications are made to PARMPR while PSS®E is running, the program must be restarted
to implement the changes. Refer to the Guide to Printing and Plotting for detailed descriptions of
the available parameters for PARMPR.
When used for graphics output, the <default> PostScript printer must have PSPLOT listed as
one of its name “aliases.”
These parameter files are discussed in detail under the sections where they apply. The parameters
available for PARMPS, PARMPW, and PSCRIPT are located in the Guide to Printing and Plotting
along with instructions on their usage.
2.3 Printing
2.3.1 Graphics
When a graphics activity such as activity GRPG is selected from a PSS®E program, a Graphic
Device Selector dialog box is displayed prompting you to choose the destination of the output. A list
of available output device names is displayed with their corresponding device codes. Note also that
an optional parameter file containing directives similar to those in PARMPW, may be supplied in the
box provided.
Double-click on a
device to select it, or
type the device code
in the input box
OR
Outputs to the screen in black and white. Uses the default Windows
29/MS-Windows (B&W)
display driver.
2.3.2 Text
The IO CONTROL,OPEN dialog box displays a list of devices for text output. Available printers,
both Microsoft and Siemens PTI driven, are listed, too.
Printers as
Defined in
PARMPR
To print to a file,
click on the File
button and enter a
filename below
Scroll for
Number of
Copies
OR
Outputs to a file. Must specify a filename. If the TEMP Directory is not set in PSS3200.INI,
File
output goes to the Windows TEMP file.
3.1.1 Introduction
Fortran v66 contains four basic mechanisms for controlling program flow: CALL/RETURN, IF, DO,
and various forms of the GO TO.
FLECS is a language extension of Fortran which has additional control mechanisms. These mech-
anisms make it easier to write Fortran by eliminating much of the clerical detail associated with
constructing Fortran programs. FLECS is also easier to read and comprehend than Fortran.
This manual is intended to be a brief but complete introduction to FLECS. It is not intended to be a
primer on FLECS or structured programming. The reader is assumed to be a knowledgeable
Fortran programmer.
For programmers to whom transportability of their programs is a concern, it should be noted that
the FLECS translator source code is in the public domain and is made freely available. The trans-
lator was written with transportability in mind and requires little effort to move from one machine to
another. The version of FLECS described in this manual has been implemented on machines on
which Siemens PTI software is supported.
The manner of implementation is that of a preprocessor which translates FLECS programs into
Fortran programs. The resulting Fortran program is then processed in the usual way. The translator
also produces a nicely formatted listing of the FLECS program which graphically presents the
control structures used. FLECS will accept this nicely formatted listing file as input, so only one form
of a FLECS source program needs be maintained.
Indented To
Listing Fortran
Compiler
If the programmer chooses not to supply line numbers, the translator may be instructed to assign
sequential numbers and place them in the last five columns of the listing and Fortran output files.
Thus, errors from the compiler may still be related to the FLECS listing.
The beginning FLECS programmer should discover and make special note of the details of the
mechanism by which Fortran compiler error messages may be traced back to the FLECS listing on
the system being used.
Structured Statement
Keyword Specification
IF (X.EQ.Y) U=V+W
Keyword Specification
Each structured statement consists of a control phrase which controls the execution of a set
of one or more statements called its scope. Also note that each control phrase consists of a
keyword plus some additional information called the specification. A statement which does not
consist of a control phrase and a scope is said to be a simple statement. Examples of simple
statements are assignment statements, subroutine CALLs, arithmetic IFs, and GO TOs.
In FLECS there is a uniform convention for writing control phrases and indicating their scopes. To
write a structured statement, the keyword is placed on a line beginning in Column 7 followed by its
specification enclosed in parentheses. The remainder of the line is left blank. The statements
comprising the scope are placed on successive lines. The end of the scope is indicated by a FIN
statement. This creates a multiline structured statement.
IF (X.EQ.Y)
U = V+W
R = S+T
FIN
The FLECS form of the IF statement will generally override the Fortran IF statement. There-
fore, FLECS programs should use only the FLECS form of IF statements! See x-refsection\
(Restrictions and Notes) for more details.
DO (I = 1,N)
A(I) = B(I)+C
C = C*2.14-3.14
FIN
The statement number has been eliminated from the DO specification since it is no longer
necessary, the end of the loop being specified by the FIN.
IF (X.EQ.Y)
U = V+W
DO (I = 1,N)
A(I) = B(I)+C
C = C*2.14-3.14
FIN
R = S+T
FIN
When the scope of a control phrase consists of a single simple statement, it may be placed on the
same line as the control phrase and the FIN may be dispensed with. This creates a one-line struc-
tured statement.
IF (X.EQ.Y) U = V+W
DO (I = 1,N) A(I) = B(I)+C
Since each control phrase must begin on a new line, it is not possible to have a one-line structured
statement whose scope consists of a structured statement.
IF (X.EQ.Y)
DO (I = 1,N) A(I) = B(I)+C
FIN
In addition to IF and DO, FLECS provides several useful structured statements not available in
Fortran. After a brief excursion into the subject of indentation, we will present these additional struc-
tures.
When writing a FLECS program on paper, the programmer should adopt the indentation and line
drawing conventions shown below. When preparing a FLECS source program in machine readable
form, however, each statement may begin in Column 7. When the FLECS translator produces the
listing, it will reintroduce the correct indentation and produce the corresponding lines. The
programmer may introduce his or her own indentation if he or she is careful to insert blanks and .'s
in exactly the format used by FLECS. This approach is sometimes useful when making corrections
to existing FLECS programs and there is no need to generate a new listing file (which, if generated,
would presumably replace the original input file as the FLECS source file).
Example of indentation:
IF (X.EQ.Y)
U = V+W
DO (I = 1,N)
A(I) = B(I)+C
C = C*2.14-3.14
FIN
R = S+T
FIN
2. Program as entered into computer. Program could also be entered as shown in step 3.
IF (X.EQ.Y)
U = V+W
DO (I = 1,N)
A(I) = B(I)+C
C = C*2.14-3.14
FIN
R = S+T
FIN
3. Program as listed by FLECS translator.
IF (X.EQ.Y)
. U = V+W
. DO (I = 1,N)
. . A(I) = B(I)+C
. . C = C*2.14-3.14
. ...FIN
. R = S+T
...FIN
The correctly indented listing is a tremendous aid in reading and working with programs. Except for
the dots and spaces used for indentation, the lines are listed exactly as they appear in the "raw"
source program. That is, the internal spacing of columns is preserved. Once a file has been
processed by FLECS the first time there will seldom be any need to refer to a straight listing of the
unindented source. Comment lines are treated in the following way on the listing to prevent inter-
ruption of the dotted lines indicating scope. A comment line which contains only blanks in Columns
2 through 6 will be listed with Column 7 indented at the then-current level of indentation as if the line
were an executable statement. If, however, one or more nonblank characters appear in Columns 2
through 6 of a comment line, it will be listed without indentation. Blank lines may be inserted in the
source and will be treated as empty comments.
In-line comments may appear on any line in a FLECS program. The beginning of an in-line
comment is signalled by an exclamation mark (!). That is, neither an exclamation mark nor any char-
acters following it are passed to the Fortran output file. If an actual exclamation mark is needed in
a FLECS program it may be entered by placing two exclamation marks together (i.e., "!!" will result
in a single "!" being passed to the Fortran output file).
Decision Structures
Decision structures are structured statements which control the execution of their scopes on the
basis of a logical expression or test.
IF
Description: The IF statement causes a logical expression to be evaluated. If the value is
true, the scope is executed once and control passes to the next statement. If the value is
false, control passes directly to the next statement without execution of the scope.
IF (L) S
Examples: TRUE
L S
IF (X.EQ.Y) U = V+W
FALSE
IF (T.GT.0.AND.S.LT.R)
. I = I+1
. Z = 0.1
...FIN
UNLESS
Description: "UNLESS (L)" is functionally equivalent to "IF(.NOT.(L))", but is more conve-
nient in some contexts.
UNLESS (L) S
Examples: FALSE
L S
UNLESS (X.NE.Y) U = V+W
TRUE
UNLESS (T.LE.0.OR.S.GE.R)
. I = I+1
. Z = 0.1
...FIN
WHEN...ELSE
Description: The WHEN...ELSE statements correspond to the IF...THEN...ELSE state-
ment of FORTRAN 77, PL/1, Pascal, etc. In FLECS, both the WHEN and the ELSE act as
structured statements although only the WHEN has a specification. The ELSE statement
must immediately follow the scope of the WHEN. The specifier of the WHEN is evaluated
and exactly one of the two scopes is executed. The scope of the WHEN statement is
executed if the expression is true and the scope of the ELSE statement is executed if the
expression is false. In either case, control then passes to the next statement following the
ELSE statement.
Examples:
TRUE
L S1
WHEN (X.EQ.Y) U = V+W ! Sample in-line
ELSE U = V-W ! comment
FALSE
WHEN (X.EQ.Y)
. U = V+W S2
. T = T+1.5
...FIN
ELSE U = V-W
WHEN (X.EQ.Y)
. U = V+W
. T = T-1.5
...FIN
ELSE
. U = V-W
. T = T+1.5
...FIN
WHEN and ELSE always come as a pair of statements, never separately. Either the
WHEN or the ELSE or both may assume the multiline form. ELSE is considered to be
a control phrase, hence it cannot be placed on the same line as the WHEN. Thus
"WHEN (L) S1 ELSE S2" is not valid.
CONDITIONAL
Description: The CONDITIONAL statement is based on the LISP conditional. A list of
logical expressions is evaluated one by one until the first expression to be true is encoun-
tered. The scope corresponding to that expression is executed, and control then passes to
the first statement following the CONDITIONAL. If all expressions are false, no scope is
executed. (See, however, the note about OTHERWISE below.)
CONDITIONAL
. (L1 ) S1
. (L2 ) S2 TRUE
. . . L1 S1
. . .
. . . FALSE
. (LN ) SN
...FIN TRUE
L S
2 2
Examples:
FALSE
CONDITIONAL
. (X.LT.-5.0) U = U+W
. (X.LE.1.0) U = U+W+Z TRUE
. (X.LE.10.5) U = U-Z Ln Sn
...FIN
FALSE
CONDITIONAL
. (A.EQ.B) Z = 1.0
. (A.LE.C)
. . Y = 2.0
. . Z = 3.4
. ...FIN
. (A.GT.C.AND.A.LT.B) Z = 6.2
. (OTHERWISE) Z = 0.0
...FIN
The CONDITIONAL itself does not possess a one-line form. However, each "(Li) Si"
is treated as a structured statement and may be in one-line or multiline form.
The reserved word OTHERWISE represents a catchall condition. That is, "(OTHERWISE)
Sn" is equivalent to "(.TRUE.) Sn" in a CONDITIONAL statement.
SELECT
Description: The SELECT statement is similar to the CONDITIONAL but is more special-
ized. It allows an expression to be tested for equality to each expression in a list of expres-
sions. When the first matching expression is encountered, a corresponding scope is
executed and the SELECT statement terminates. In the description below, E, E1,...En
represent arbitrary but compatible expressions. Any type of expression (integer, real,
complex, character...) is allowed as long as the underlying Fortran system allows such
expressions to be compared with an .EQ. or .NE. operator.
SELECT (E)
. (E1 ) S1
. (E2 ) S2
TRUE
. . . E = E1 S1
. . .
. . .
FALSE
. (EN ) SN
...FIN
E=E TRUE S
2 2
Examples:
FALSE
SELECT (OPCODE(PC))
. (JUMP) PC = AD
. (ADD)
E=E TRUE S
. . A = A+B n n
. . PC = PC+1
. ...FIN FALSE
. (SKIP) PC = PC+2
. (STOP) CALL STOPCD
...FIN
The catchall OTHERWISE may also be used in a SELECT statement. Thus, "(OTHER-
WISE) Sn" is equivalent to "(E) Sn" within a "SELECT (E)" statement.
The expression E is reevaluated for each comparison in the list. Thus lengthy, time
consuming, or irreproducible expressions should be precomputed, assigned to a variable,
and the variable used in the specification portion of the SELECT statement.
LOOP Structures
The structured statements described below all have a scope which is executed a variable
number of times depending on specified conditions.
DO
Description: The FLECS DO loop is functionally identical to the Fortran DO loop. The only
differences are syntactic. In the FLECS DO loop, the statement number is omitted from the
DO statement, the incrementation parameters are enclosed in parenthesis, and the scope
is indicated by either the one line or multiline convention. Since the semantics of the Fortran
DO statement vary from one Fortran compiler to another, a flowchart cannot be given. The
symbol "I" represents any legal incrementation specification.
Examples:
DO (I = 1,N) A(I) = 0.0
DO (J = 3,K,3)
. B(J) = B(J-1)*B(J-2)
. C(J) = SIN(B(J))
...FIN
WHILE
Description: The WHILE loop causes its scope to be repeatedly executed while a speci-
fied condition is true. The condition is checked prior to the first execution of the scope.
Thus, if the condition is initially false the scope will not be executed at all.
WHILE (L) S
Examples: FALSE
NEXT PASS
L
WHILE (X.LT.A(I)) I = I+1
TRUE
WHILE (P.NE.O)
. VAL(P) = VAL(P)+1 EXITLOOP
S
. P = LINK(P)
...FIN
REPEAT WHILE
Description: By using the REPEAT verb, the test can be logically moved to the end of the
loop. The REPEAT WHILE loop causes its scope to be repeatedly executed while a spec-
ified condition remains true. The condition is not checked until after the first execution of
the scope. Thus, the scope will always be executed at least once and the condition indi-
cates under what conditions the scope is to be repeated.
Examples:
NEXTPASS
S
REPEAT WHILE(N.EQ.M(I)) I = I+1
EXITLOOP
REPEAT WHILE (LINK(Q).NE.0)
. R = LINK(Q)
. LINK(Q) = P L TRUE
. P = Q
. Q = R
...FIN FALSE
UNTIL
Description: The UNTIL loop causes its scope to be repeatedly executed until a specified
condition becomes true. The condition is checked prior to the first execution of the scope,
thus if the condition is initially true, the scope will not be executed at all. Note: "UNTIL (L)"
is functionally equivalent to "WHILE (.NOT.(L))."
UNTIL (L) S
Examples: TRUE
NEXTPASS
L
UNTIL (X.EQ.A(I)) I = I+1
FALSE
UNTIL (P.EQ.O)
. VAL(P) = VAL(P)+1
. P = LINK(P) S
EXITLOOP
...FIN
REPEAT UNTIL
Description: By using the REPEAT verb, the test can be logically moved to the end of the
loop. The REPEAT UNTIL loop causes its scope to be repeatedly executed until a specified
condition becomes true. The condition is not checked until after the first execution of the
scope. Thus, the scope will always be executed at least once and the condition indicates
under what conditions the repetition of the scope is to be terminated.
Examples:
NEXTPASS
REPEAT UNTIL(N.EQ.M(I)) I = I+1 S
EXITLOOP
REPEAT UNTIL (LINK(Q).EQ.0)
. R = LINK(Q)
. LINK(Q) = P FALSE
L
. P = Q
. Q = R
...FIN TRUE
REPEAT FOREVER
Description: By using the keyword FOREVER it is possible to set up an "infinite loop" that
will normally be terminated by an END= or ERR= branch. Alternatively, an EXITLOOP,
EXITPROC, or GO TO statement can be used to exit from such a loop. Notice that this
statement has no one-line form.
REPEAT FOREVER is functionally equivalent to REPEAT UNTIL(.FALSE.).
REPEAT FOREVER
.
NEXTPASS
. S
.
...FIN S
Examples:
EXITLOOP
REPEAT FOREVER
. READ (8,10,END=90) X
10 . FORMAT (F10.2)
...FIN
90 I=I+1
Procedure names may be any string of letters, digits, and hyphens (i.e., minus signs) beginning with
a letter and containing at least one hyphen. Internal blanks are not allowed. The only restriction on
the length of a name is that it may not be continued onto a second line.
INITIALIZE-ARRAYS
GIVE-WARNING
SORT-INTO-DESCENDING-ORDER
INITIATE-PHASE-3
A procedure declaration consists of the keyword "TO" followed by the procedure name and its
scope. The set of statements comprising the procedure is called its scope. If the scope consists of
a single simple statement, it may be placed on the same line as the "TO" and procedure name,
otherwise the statements of the scope are placed on the following lines and terminated with a FIN
statement. These rules are analogous with the rules for forming the scope of a structured statement.
TO procedure-name
Examples of procedure declarations:
TO RESET-POINTER P = 0
TO DO-NOTHING CONTINUE
TO SUMMARIZE-FILE
. INITIALIZE-SUMMARY
. OPEN-FILE
. REPEAT UNTIL (EOF)
. . ATTEMPT-TO-READ-RECORD
. . WHEN (EOF) CLOSE-FILE
. . ELSE UPDATE-SUMMARY
. ...FIN
. OUTPUT-SUMMARY
...FIN
An internal procedure reference is a procedure name appearing where an executable statement
would be expected. In fact an internal procedure reference is an executable simple statement and
thus may be used in the scope of a structured statement as in the last example above. When control
reaches a procedure reference during execution of a FLECS program, a return address is saved
and control is transferred to the first statement in the scope of the procedure. When control reaches
the end of the scope, control is transferred back to the statement logically following the procedure
reference.
Here is a complete (but uninteresting) FLECS program which illustrates the placement of the proce-
dure declarations:
. IF (X.NE.0)
. . COMPUTE-RESULT
. . TYPE-RESULT
. ...FIN
...FIN
CALL EXIT
------------------------------------
TO GET-A-VALUE-OF-X
. WRITE (1,10)
10 . FORMAT (’X = ’)
. READ (1,*) X
...FIN
------------------------------------
TO COMPUTE-RESULT XSQ = X*X
------------------------------------
TO TYPE-RESULT
. WRITE (1,30), XSQ
30 . FORMAT (’X-SQUARED = ’,F7.2)
...FIN
END
Notes concerning internal procedures:
1. All internal procedure declarations must be placed at the end of the program just prior to the
END statement. The appearance of the first "TO" statement terminates the body of the
program. The translator expects to see nothing but procedure declarations from that point
on. Care must be taken that the program flow of the main body of the program does not acci-
dentally "fall" into a procedure, that is, the last statement of the main body should be a
RETURN or GOTO statement.
2. The order of the declarations is not important. Alphabetical by name is an excellent order for
programs with a large number of procedures.
3. Procedure declarations may not be nested. In other words, the scope of a procedure may
not contain a procedure declaration. It may of course contain executable procedure refer-
ences.
4. Any procedure may contain references to any other procedures (excluding itself).
6. All program variables within a main or subprogram are global and are accessible to the
statements in all procedures declared within that same main or subprogram.
8. The FLECS translator separates procedure declarations on the listing by dashed lines as
shown in the preceding example.
EXITPROC
The EXITPROC statement is used to exit from an internal procedure before the final FIN statement
is encountered at the bottom of the procedure. An example would be:
TO TEST-EXITPROC
C .
. READ(1,*) IFLAG
. IF (IFLAG.EQ.-1) EXITPROC ! All done
.
. (Read & process data)
.
...FIN ! Normal return location
Using EXITPROC outside of an internal procedure (i.e., in the main program) will result in an error
message.
The EXITLOOP statement will cause a jump to the statement following the last statement making
up the current loop. Use a GO TO statement (or redesign your program!) if you need to exit more
than one looping level.
The NEXTPASS statement generates a jump to the incrementing statement (in the case of a
FLECS- type DO loop) or to the "test" clause (in all other cases). The following example shows how
both of these statements can be used:
EOF = .FALSE
REPEAT UNTIL (EOF)
. DO (IAC=1,NACROS)
. . READ (LUNIT,40,END=50) NADR
. .
. . (Process NADR)
. .
. . NEXTPASS ! On to the next DO-loop index
50 . . EOF = .TRUE.
1. FLECS must invent many statement numbers in creating the Fortran program. It does so by
beginning with a large number (usually 32767) and generating successively smaller
numbers as it needs them. Do not use a number which will be generated by the translator.
A good rule of thumb is to avoid using 5 digit statement numbers.
2. The FLECS translator must generate integer variable names. It does so by using names of
the form "Innnnn" when nnnnn is a 5 digit number related to a generated statement number.
Do not use variables of the form Innnnn and avoid causing them to be declared other than
INTEGER. For example the declaration "IMPLICIT REAL (A-Z)" leads to trouble. Try
"IMPLICIT REAL (A-H, J-Z)" instead.
3. The translator does not recognize continuation lines in the source file. Thus Fortran state-
ments may be continued since the statement and its continuations will be passed through
the translator without alteration. However, an extended FLECS statement which requires
translation may not be continued. The reasons one might wish to continue a FLECS state-
ment are: a) it is a structured statement or procedure declaration with a one-statement
scope too long to fit on a line, or b) it contains an excessively long specification portion, or
c) both of the above. Problem a) can be avoided by going to the multiline form. Frequently
problem b) can be avoided when the specification is an expression (logical or otherwise) by
assigning the expression to a variable in a preceding statement and then using the variable
as the specification.
4. IF statements must not be continued on a following line. FLECS treats all logical IF state-
ments as FLECS statements, none of which can be continued in the normal Fortran fashion.
(i.e., by putting a nonblank character in Column 6). This problem may be circumvented by
setting a temporary LOGICAL variable equal to (condition) and then having an IF statement
which tests the LOGICAL variable. Alternatively (or in addition) the IF statement can be
rewritten to be a multiline FLECS-type statement.
5. FORTRAN 77 block-IF statements should not be used in a FLECS program. The syntax of
FORTRAN 77 block-IF statements will confuse the FLECS translator and generate error
messages.
6. Blanks are meaningful separators in FLECS statements; don’t put them in dumb places like
the middle of identifiers or key words and do use them to separate distinct words like
REPEAT and UNTIL.
7. Let FLECS indent the listing. Start all statements in Column 7 and the listing will always
reveal the true structure of the program. (As understood by the translator, of course.) As
mentioned in Section 3.1.5: Indentation, Lines, and the Listing it is possible to type in an
indented listing, but this practice should generally be limited to making minor changes to
existing programs.
8. As far as the translator is concerned, FORMAT statements are executable Fortran state-
ments since it doesn’t recognize them as extended FLECS statements. Thus, only place
FORMAT statements where an executable Fortran statement would be acceptable. Don’t
put them between the end of a WHEN statement and the beginning of an ELSE statement.
Don’t put them between procedure declarations.
TO WRITE-HEADER TO WRITE-HEADER
. PAGE = PAGE+1 . PAGE = PAGE+1
. WRITE(3,40) H,PAGE . WRITE(3,40) H,PAGE
...FIN 40 . FORMAT(70A1,I3)
40 FORMAT (70A1,I3) ...FIN
10. In scanning a parenthesized specification, the translator scans from left to right to find the
parenthesis which matches the initial left parenthesis of the specification. The translator,
however, is ignorant of Fortran syntax including the concept of Hollerith constants and will
treat Hollerith parentheses as syntactic parentheses. Thus, avoid placing Hollerith constants
containing unbalanced parentheses within specifications. If necessary assign such
constants to a variable, using a DATA or assignment statement, and place the variable in
the specification.
IF (J.EQ.’(’) LP = ’(’
IF(J.EQ.LP)
11. The FLECS translator will not supply the statements necessary to cause appropriate termi-
nation of main and subprograms. Thus it is necessary to include the appropriate RETURN,
GOTO, STOP, or CALL EXIT statement prior to the first internal procedure declaration.
Failure to do so will result in control entering the scope of the first procedure after leaving
the body of the program. Do not place such statements between the procedure declarations
and the END statement.
12. A RETURN or STOP statement just before a FIN can cause trouble because FLECS may
insert an unlabeled statement (normally a GO TO) directly after the RETURN or STOP. The
Fortran compiler may then complain because there is no path to the unlabeled statement.
The error message from the compiler will normally be in the form of a warning and will not
affect the generated code. However, with some compilers you can eliminate the message
by using a procedure call such as GO-RETURN or GO-STOP in place of the RETURN or
STOP. The GO-RETURN procedure would look like:
TO GO-RETURN
RETURN
99 CONTINUE
FIN
where a dummy CONTINUE statement has been added to 'fool' the compiler. A similar
set up would be used for GO-STOP.
13. A problem similar to that in (12) will arise if a GO TO statement is the last statement before
the FIN in a SELECT block:
SELECT (X)
. (A)
. . J=1
. . Y=3.5
. . GO TO 10
. ...FIN
. (B)
. . I=9
. . Z=8.6
. ...FIN
...FIN
The GO TO 10 may upset the Fortran compiler in the same way as in (12). That is, a
'NO PATH TO STATEMENT' error will be generated. With some compilers, this prob-
lem can, if desired, be eliminated by putting a dummy labelled CONTINUE statement
following the GO TO 10.
3.1.10 Errors
This section provides a framework for understanding the error handling mechanisms of the FLECS
Translator. The system described below has proven to be quite workable.
The FLECS translator examines a FLECS program on a line by line basis. As each line is encoun-
tered it is first subjected to a limited syntax analysis followed by a context analysis. Errors may be
detected during either of these analysis. It is also possible for errors to go undetected by the trans-
lator.
Syntax Errors
When a syntax error is detected by the translator, it ignores the statement. On the FLECS listing,
the characters *IGNORED* are printed in Columns 1 to 9 to indicate that the statement has been
ignored. The nature of the syntax error is given in a message on the following line.
The fact that a statement has been ignored may, of course, cause some context errors in later state-
ments. For example, the control phrase "WHEN (X(I).LT.(3+4)" has a missing right parenthesis. This
statement will be ignored, causing, as a minimum, the following ELSE to be out of context. The
programmer should of course be aware of such effects. More is said about them in the next section.
Context Errors
If a statement successfully passes the syntax analysis, it is checked to see if it is in the appropriate
context within the program. For example, an ELSE must appear following a WHEN and nowhere
else. If an ELSE does not appear at the appropriate point, or if it appears at some other point, then
a context error has occurred. A frequent source of context errors in the initial stages of development
of a program comes from miscounting the number or FIN’s needed at some point in the program.
With the exception of excess FIN’s which do not match any preceding control phrase and are
ignored, (as indicated by *IGNORED* being printed in Columns 1 to 9 of the listing file) all context
errors are treated with a uniform strategy. When an out-of-context source statement is encountered,
the translator generates a "STATEMENT(S) NEEDED" message. It then invents and processes a
sequence of statements which, if they had been included at that point in the program, would have
placed the original source statement in a correct context. A message is given for each such state-
ment invented. The original source statement is then processed in the newly created context.
By inventing statements the translator is not trying to patch up the program so that it will run
correctly. Rather, it is simply trying to adjust the local context so that the original source statement
and the statements which follow will be acceptable on a context basis. As in the case of context
errors generated by ignoring a syntactically incorrect statement, such an adjustment of context
frequently causes further context errors later on. This is called propagation of context errors.
One nice feature of the context adjustment strategy is that context errors cannot propagate past a
recognizable procedure declaration. This is because the "TO" declaration is in context only at inden-
tation level 0. Thus, to place it in context, the translator must invent enough statements to terminate
all open control structures which precede the "TO." The programmer who modularizes his program
into a collections of relatively short internal procedures, limits the potential for propagation of
context errors.
Undetected Errors
The FLECS translator is ignorant of most details of Fortran syntax. Thus, most Fortran syntax errors
will be detected by the Fortran compiler, not the FLECS translator. In addition, there are two major
classes of FLECS errors which will be caught by the compiler rather than the translator.
The first class of undetected errors involves misspelled FLECS keywords. A misspelled keyword
will not be recognized by the translator. The line on which it occurs will be assumed to be a Fortran
statement and will be passed unaltered to the compiler which will no doubt object to it. For example,
a common error is to spell UNTIL with two L’s. Such statements are passed to the compiler, which
then produces an error message. The fact that an intended control phrase was not recognized
frequently causes a later context error since a level of indentation will not be triggered.
The second class of undetected errors involves unbalanced parentheses. (See also Note 10 in
Section 3.1.9: Restrictions and Notes.) When scanning a parenthesized specification, the translator
is looking for a matching right parenthesis. If the matching parenthesis is encountered before the
end of the line, the remainder of the line is scanned. If the remainder is blank or consists of a recog-
nizable internal procedure reference, all is well. If neither of the above two cases hold, the
remainder of the line is assumed (without checking) to be a simple Fortran statement which is
passed to the compiler. Of course, this assumption may be wrong. Thus the statement
WHEN (X.LT.A(I)+Z)) X = 0
is broken into
keyword "WHEN"
specification "(X.LT.A(I)+Z)"
Fortran statement ") X = 0"
Needless to say, the compiler will object to ") X = 0" as a statement.
An undetected error in one line may trigger a context error in a much later line. Noticing the context
error, the programmer does not proceed with compilation and hence is not warned by the compiler
of the genuine cause of the error. One indication of the true source of the error may be an indenta-
tion failure at the corresponding point in the listing.
Other Errors
The translator detects a variety of other errors such as multiply defined, or undefined procedure
references. The error messages are self-explanatory. (Really and truly!)
TRUE FALSE
L S L S TRUE TRUE
NEXTPASS
L S1 L
FALSE TRUE FALSE
FALSE
S2
EXITLOOP
S
EXITPROC
CONDITIONAL SELECT (E) CARRY-OUT-ACTION
. (L1 ) S1 . (E ) S TO CARRY-OUT ACTION
. (L ) S . (E12 ) S 12 TO CARRY-OUT ACTIONS
. .
2
.2 . . .
EXITPROC
. . . . . . S
. . . . . .
. (LN ) SN . (EN ) SN
...FIN ...FIN DO (I) S
FIN
L1
TRUE
S1 E = E1 TRUE S1
Note: Place RETURN, STOP, or CALL EXIT statement
ahead of the first TO statement.
FALSE FALSE
TRUE Note: OTHERWISE can be used as a catchall condition or
L2 TRUE S2 E =E2 S2
expression in CONDITIONAL and SELECT statements.
FALSE FALSE
Legend:
L = Logical Expression
TRUE TRUE S = Statement(s)
Ln Sn E = En Sn
E = Expression
I = DO Specification
FALSE FALSE
REPEAT UNTIL (L) S REPEAT WHILE (L) S REPEAT FOREVER WHILE (L) S
NEXTPASS
NEXTPASS
NEXTPASS
NEXTPASS
FALSE
S S L
S
EXITLOOP
EXITLOOP
TRUE
EXITLOOP
EXITLOOP
L FALSE L S
TRUE
TRUE FALSE
3.2.1 Introduction
This document describes the specific manner in which the FLECS32 preprocessor is used on PC
systems. You should be familiar with the FLECS-to-Fortran Translator which describes the features
found in all implementations of FLECS as supplied by Siemens PTI. The write-up below also
describes a number of additional limitations and enhancements in the FLECS32 package.
FLECS32 filename
where 'filename' is either the name of a file in the current directory or a pathname specifying a file
in some other directory. If the input file ends with “.FLX” there is no need to specify the “.FLX” when
giving the FLECS32 command. Examples are:
Any errors detected by FLECS32 will be displayed on the terminal as well as being written to the
listing file.
-EXPAND
funit -WIDTH n -F77 -DEBUG
-NOEXPAND
-LIST NO NUM
YES funit
-X filename NONUM
NO NUM
-FTN YES funit
filename NONUM
• An input tree-filename.
• A FLECS32 LIST output tree-filename.
• A Fortran output tree-filename.
• The unit numbers to be used for reading the input file and the $INCLUDE file(s), and
writing the LIST and Fortran output files. If nested $INCLUDE files are used, the file unit
used to read the second-level file(s) will be obtained by adding 1 to the “funit” used to
read the first-level $INCLUDE file(s).
• Whether or not (YES/NO) an output file is to be produced.
• Whether or not (NUM/NONUM) line numbers are to be inserted on the right side of the
output file(s).
-SEARCH * C:\SYSCOM
which would cause the current directory to be searched first, followed by a search
of the C:\SYSCOM directory.
If you use ‘-SEARCH’, you should also specify ‘-EXPAND’ for proper results.
The -INPUT and -SOURCE specifications are optional. If neither is specified, the first name
following the FLECS32 command is assumed to be the input tree-filename. Except for the
YES/NO/NUM/NONUM key words, all the “-” specifiers may be abbreviated as shown by the under-
lining in the description of the FLECS32 command line shown at the beginning of this section. The
order of items following the -I, -SO, -L, -X and -F specifications is immaterial. (As indicated above,
the order of “names” following the -SEARCH option IS important.) Any items which are not specified
will be set to their default values. Not specifying any options is equivalent to: