-------
This report was prepared by the Mitre Corporation, Bedford,
Massachusetts, under Contract No. 68-01-2976.
An environmental protection publication (SW-573) in the solid waste
management series. Mention of commercial products does not constitute
endorsement by the U.S. Government.
Single copies of this publication are available from Solid Waste
Information, U.S. Environmental Protection Agency, Cincinnati, Ohio
45268.
-------
WRAP
A MODEL FOR REGIONAL SOLID WASTE MANAGEMENT PLANNING
Programmer's Manual
This report j3~£jj&) was prepared for the Office of Solid Waste
i£j&£G^ Vernlece Hensey and staff,
under the direction of Donna M. Krabbe
U.S. ENVIRONMENTAL PROTECTION AGENCY
1977
-------
ABSTRACT
WRAP is a Waste Resources Allocation Program which has been
programmed in FORTRAN. WRAP consists of a series of equations which
consider the sources of solid waste generation, a set of sites, and
processes to be considered at those sites, as well as various site
and process capacity constraints. WRAP sorts out the various allocation
options specified by a user and indicates a preferred allocation solution
which is the minimum cost plan that meets all the user-supplied constraints.
This document is addressed to the programming or computer systems analysts
who is responsible for maintaining the WRAP computer program. The manual
contains a detailed description of the program, data base design and
specifications; the logic flow and subprogram specifications, general
maintenance procedures and program size modification requirements; and
an extensive set of appendices which provide a quick reference for the
program table, data forms, data coding sheets, subroutine summary sheets
and subroutine cross references.
-------
ACKNOWLEDGEMENT
The WRAP computer program and Programmer's Manual were made
possible through the hard work of many people at The MITRE Corporation.
For their hard work and support, I extend my thanks and acknowledgement:
Dr. D. Elliott Bell for his sorting routines; David H. Lehman for his
design work, matrix programming, documentation notes and all around
support; Mary V. Mollo-Christensen for her design work, extensive
programming, test implementations, documentation notes, and all around
support; Richard H. Sullen, Jr. for his patience and help in editing
and preparing this document. Special thanks and acknowledgement go to
Paula M. Antonuccio, Elizabeth A, Aprile, Mary A. Jaroncyk, Eleanor M.
Pomerleau and Virginia W. Selman for their patience, fortitude, cheerful!'
ness and typing skills during the preparation of the several drafts and
final version of this document.
-------
CONTENTS
Chapter 1 - INTRODUCTION 1
Chapter 2 - SYSTEM DESCRIPTION 4
System Summary 4
General System Description 4
General Program Functions 7
System Environment 12
Physical Features 12
Support Software 15
Interfaces and Storage 15
Controls 15
Timing 15
Transportability 17
Accuracy and Validity 18
Overview of Inputs and Outputs 18
Inputs 18
Control Records 19
Source Identification Records 20
Site Identification Records 20
Process Identification Records 20
Site-Process Identification Records 21
Transportation Identification Records 21
Truck Constraint Identification Records 22
Starting Basis Records 22
Outputs 22
Print Files 22
Punch Files 24
Logic Control Variables 25
Chapter 3 - DATA BASE SPECIFICATIONS 29
General 29
Purpose 29
References 29
Identification and Description 29
Physical Attributes 29
Labeling and Tagging Conventions 30
Organization 31
Input-Output Files 32
Data Dimensions 33
Data Definitions 35
Input Records and Formats 35
Control - Principle Control Records 37
CONTRL 37
CNTR2 40
-------
Page
CRWFLY - "Crowfly" Measurement Record 41
SOURCE - Source Identification Record 42
SITE - Site Identification Record 43
Process Identification Records 45
PRC1 46
PRC2 47
LNKI and LNKO 48
PRCOST 49
SIPROC - Site Process Identification Record 50
TRANS - Transportation Activity Record 52
TRUCK - Truck Constraint Identification Record 54
Starting Basis Record 55
Temporary Files 55
Pointer Tables 58
Common Storage Allocations 69
Outputs Generated 61
Debugging Outputs 63
Error Messages 63
Input Data Report 64
Punched Output 64
Intermediate LINEAR Solutions Reports 65
Final OUTPUT Solutions Reports 65
Chapter 4 - SYSTEM SPECIFICATION 67
General 67
Purpose 67
References 67
Main Control Procedures 67
MAIN 67
ERROR 72
FIND 72
LXSORT and LXCOMP 73
READIT 73
Other Routines 73
Functional Modules 75
EDIT! - Input Read and Edit 75
CONTRL 75
CRWFLY 79
SOURCE 79
SITE 79
PROCES 80
SIPRC 80
TRANS 80
TRUCK and TBASIS 81
EDIT2 - Input Consistency and Validity Checking 82
ONENUM 82
CNTCHK 82
CKSIPR 84
PRCHK 84
TRNCHK 84
vi
-------
LINKAGE - Network Completion Checking 84
CROWFLY - Network Completion by "Crowfly" 85
ICROW1 85
ICROW2 90
FRONTOUT - Output Reports and Punched Files 90
APRPU 90
PRINT 93
PUNCH! 93
PUNCHM 93
COLUMN - Construction of Matrix Identification Record 93
COLUMN 93
TCOST 98
PCOST 99
KCOST 99
SCOST TOO
TRFAC 100
CPFAC 100
MATRIX - Construction of Matrix Vectors 10°
MATRIX 101
SORBAL 104
IUSPC 104
ISPOB 105
IUSTC 105
IUSIB 1°6
CAPBAL 106
LANCON 107
COST 107
ZCOLMN 1°7
SETR 107
BASIS - Generation of Starting Basis 1°8
LINEAR - Linear Optimizing Algorithm 11°
OUTPUT - Management Report Generation 116
OSTAT 116
ODYN1 119
ODYN2 I/O
Chapter 5 - MAINTENANCE PROCEDURES 121
General 121
Purpose 121
References 121
WRAP Source Tape 122
Sizing and Dimensioning 126
File Requirements I33
Overlay Structure 1^
Error Conditions 137
Data Editing Recommendations I37
Chapter 6 - USER INFORMATION ]3°
General
Program Size
Computer Requirements
vii
-------
Page
WRAP Input Sequence 140
Error Messages and Actions 142
General 142
Unnumbered Messages 143
Numbered Messages 144
REFERENCE 167
Appendix I - FILE FORMATS AND CONTENTS 168
Appendix II - SUBROUTINE SUMMARY SHEETS 188
Appendix III - COMMON STORAGE TABLES 289
Appendix IV - SUBROUTINES AND COMMONS CROSS-REFERENCE TABLES 314
viii
-------
LIST OF ILLUSTRATIONS
Figure Title Page
1 Types of User-Supplied Input Data 5
2 WRAP Matrix Equation Types and Coefficient Classes 6
3 WRAP General System Flow 8
4 Functional Modules of WRAP 9
5 WRAP Program Overlay Structure 16
6 Timing Examples from WRAP Executions 17
7 Input Records Sequence 19
8 WRAP Outputs Generated 23
9 Punched Matrix Data 25
10 Matrix Data Dimensions 33
11 Non-Matrix Data Dimensions 34
12 Process Records Input Sequence 45
13 Output Messages and Reports 62
14 WRAP Top Level Execution Logic Flow 68
15 Files and Commons Referenced in READIT 74
16 EDIT! Module Logic Flow 76
17 EDIT2 Module Logic Flow 83
18 LINKAGE Module Logic Flow 86
19 CROWFLY Module Logic Flow 87
20 FRONTOUT Module Logic Flow 91
21 COLUMN Module Logic Flow 95
22 MATRIX Module Logic Flow 102
23 BASIS Module Logic Flow 1°9
24 LINEAR Module Logic Flow 112
25 OUTPUT Module Logic Flow 117
26 JCL to Compile the LINEAR Module from Tape 123
27 IEBGENER Utility Routine for Dumping WRAP
Tape to TSO I24
28 Source Tape to Partitioned Data Set Using
IEBGENER 124
29 Compile and Link JCL from Cards and Tape 125
30 GO Step JCL 126
31 File Requirements JCL for WRAP Execution 134
32 Overlay JCL Cards 132
33 JCL for Input-Output Files 140
34 Card Deck Setup for WRAP Execution 141
IX
-------
LIST OF TABLES
Table Title
1 WRAP Modules and Associated Subprograms 12
2 WRAP Common Storage Areas 13
3 User-Supplied Program Logic Data 25
4 WRAP Temporary Files 32
5 User Input Groups 36
6 CONTRL Input Record 38
7 CNTR2 Input Record 40
8 CRWFLY Input Record 41
9 SOURCE Input Record 42
10 SITE Input Record 44
11 PRC1 Input Record 46
12 PRC2 Input Record 47
13 LNKI and LNKO Input Records 48
14 PRCOST Input Record 50
15 SIPROC Input Record 51
16 TRANS Input Record 53
17 TRUCK CONSTRAINT Input Record 54
18 Column Identification Record 56
19 Default Values for Input Variables 78
20 WRAP Source Tape Files 122
21 Changeable Arrays for WRAP Program 127
22 Model Sizing Parameters for Matrix Rows 130
23 Model Sizing Parameters for Matrix Columns 131
24 WRAP Overlay Segments and Contents 135
-------
Chapter 1
INTRODUCTION
The millions of tons of solid waste produced anually throughout
the country create difficult decisions that must be addressed at local
levels. These decisions, which were once rather straightforward, are
now complicated by the increasing costs of disposal, new technologies,
environmental regulations, and the unavailability of land for landfill.
These factors facing local decisions makers gives rise to strong pressures
towards the regionalization of solid waste management functions. However,
regionalization system design; and a problem of political consensus
amongst the participants. Both of these problems have to be addressed
by developing and clearly presenting technical and economic data about
the consequences of various regional approaches.
To assist decision makers who are considering the implementation of
regional solid waste management functions, the Environmental Protection
Agency has sponsored the development of a computer model called WRAP
(Waste Resource Allocation Program). Based upon data Inputs provided
by the users, WRAP sorts out the various options and indicates a
preferred solution which is the minimum cost regional plan that meets
all the constraints determined by its users. Use of the model enables
officials to study and analyze the costs and implications of all
available alternatives under consideration. By using WRAP, decision
makers can find answers to such questions as: Which technology should
be selected? Where should the facility and subscribing transfer stations
be located? Whom should they serve? How large should they be? What
will a system that meets all the objectives cost? What are good alterna-
tives and what will they cost? In sum, what is the most economically
preferred regional system design and what are the costs associated with
changing that design?
A key capability of WRAP is its ability to balance the economies
of scale achievable through centralization of processing at one location
against the additional haul costs required for centralization. This
makes it possible to determine what levels of centralization make the
most economic sense.
WRAP consists of a series of equations which consider the sources of
solid waste generation over a given planning region, a set of sites,
and processes to be considered at those sites, as well as various site
and process capacity constraints. The processes can be transfer stations,
resource recovery processes (including the extraction of recoverable
resources to be marketed), secondary processes (which receive the residue
of primary processes as input) and various disposal processes. WRAP
further considers many transportation route alternatives from sources
of waste generation to sites, and from sites to sites, with due allowance
for site traffic constraints.
-------
Processing costs are input to WRAP so as to reflect the economies
of scale available for each process, and revenues from the marketing of
recovered materials. Haul costs are included, which increase directly
with both tonnage and travel time.
WRAP has three essential components:
structure - which assures that each alternative considered is
feasible in the sense that all wastes generated are entered
into transportation, that all wastes arriving at a site are
processed, that all residues generated are processed at the
site or entered into transportation, and that no process
exceeds the indicated tonnage maximums and traffic constraints
are observed,
cost - which assures that each alternative is properly costed,
including economies of scale where appropriate, and
procedure - an organized mathematical procedure which allows
those options which improve the solution to be separated from
those that make it worse, and indicates when the procedure has
identified the least cost solution.
To date, the WRAP model has been used 1n several locations by
decision makers who are considering regional solid waste management. In
Massachusetts, the model was used to identify the most efficient regional
system design for that state's first regional resource recovery system.
And in St. Louis, Missouri, WRAP was used to determine the advantages
of community participation in a proposed regional solid waste management
plan.
Comprehensive information that describes and documents the use of
the WRAP model is available to potential users. This information
comprises three references. A User's Guide; A Programmer's Manual; and a
full documentation of the model applications made for EPA.
This document comprises the .Programmer's Manual, and is addressed
to the programming or computer system analyst who is responsible for
maintaining the WRAP computer program. The manual contains a detailed
description of the FORTRAN program, data base design and specifications;
the logic flow and subprogram specifications, general maintenance
procedures and size modification requirements; input preparation methods
and requirements; and an extensive set of appendices which provide a
quick reference for the program tables, data forms, summary sheets and
examples.
-------
For further information about the WRAP model, call or write:
The System Management Division
Office of Solid Waste Management Programs
Environmental Protection Agency
401 M Street
Washington, D.C. 20460
at (202) 755-9125.
-------
Chapter 2
SYSTEM DESCRIPTION
System Summary
This chapter presents a brief introduction to the optimizing
modeling program WRAP. The presentation includes an overview of the
program, followed by a discussion of environmental characteristics, and
inputs and outputs.
General System Description
WRAP is an optimizing modeling program which selects, sizes and
locates solid waste processing and disposal facilities. Costs for the
model planning period are determined by a specialized fixed charge
linear programming algorithm.
There are two operational modes available: static and dynamic.
The static mode allows for only one planning period. The dynamic
operating mode allows for two to four planning periods. Planning
periods are expressed in years, and, in the dynamic mode, are consecu-
tive over the total planning period.
The principal input data for WRAP are solid waste transportation
network activities. These activities indicate the origin of the waste,
the processing facility (if any) to handle the waste and the disposal
destination (defined as a geographic location). Other data associated
with a transportation activity are the origin's waste tonnage per year,
the haul cost of the waste tonnage from the origin or the processing
facility and the travel distance or time between an origin and a desti-
nation.
Other input data include facility-related costs and revenues,
identification codes and geographic coordinates of the origins and
destinations, truck constraints imposed on a destination, and limita-
tions of waste processing facilities at a particular location. Descrip-
tions of the eight types of input are given 1n Figure 1.
CONTROL DATA describes the WRAP control switches
and constants; includes control op-
tions, planning periods and years,
number of sources, sites, processes
and site-processes, cost data for a
dynamic run and title labels.
-------
SOURCE DATA
SITE DATA
PROCESS DATA
SITE-PROCESS DATA
TRUCK DATA
TRANSPORTATION DATA
STARTING BASIS
describes the original source loca-
tions; includes source identifica-
tion number and name, geographic
coordinates, waste tonnage per years
and haul costs for each model period.
describes the intermediate and
ultimate sites; includes site identi-
fication number and name, geographic
coordinates, number of processes at
the site, preparation costs of the
site and land available.
describes general waste processing
facilities; includes process identi-
fication number and name, process
level code, percent output weight and
density, haul cost per period, capital
lead time, building availability and
Hfe span, Input and output linkage
possibilities, and cost segments and
slopes and Intercepts.
describes a particular process at a
site; includes site and process identi-
fication numbers, linear segments,
waste capacity, revenue per period,
and process level code.
describes truck constraints at sites;
includes identification numbers, and
number of trucks per period.
describes travel activities between
locations; includes Identification
numbers, code of activity, travel
time, distance and speed.
describes an initial feasible solu-
tion for problem matrix; includes one
column number for each matrix equation
or row.
Figure 1. Types of User-Supplied Input Data
of
More descriptive detail for the user input is given in Chapter
this volume and in the WRAP User's Guide.7
-------
Since many of the equation coefficients do not exist, a sparse
matrix technique is used to structure the matrix model prior to the
execution of the fixed charge algorithm. At each stage of matrix
preparation, the program outputs the pertinent data. Figure 2 contains
a list of the eight types of equations and the four classes of
coefficients used to build the matrix.
Equation Types Static Mode Dynamic Mode
Source Balance Yes Yes
Intermediate and
Ultimate Site _
Processing Constraints Yes Yes
Intermediate Site
Input Balance Yes Yes
Ultimate Site
Input Balance Yes Yes
intermediate Facility
Output Balance Yes Yes
Truck Constraints Yes Yes
Site-Process
Capacity Balance No Yes
Land Constraints No Yes
Coefficient Classes
Transportation Activities Yes Yes
Process Activities Yes Yes
Capacity Activities No Yes
Under Utilization
Activities No Yes
Figure 2. WRAP Matrix Equation Types and Coefficient Classes
-------
The actual number of equations of each type is problem dependent.
Refer to, the WRAP User's Guide7 for more detailed information. Chapter
4 of this manual provides specific information on the matrix building
subprograms.
After the necessary matrix vectors are prepared, the user may
exercise one of several control options: (1) terminate execution with
punch out of the matrix data; (2) continue processing with an initial
feasible solution for the linear programming algorithm supplied by the
user; (3) continue processing with starting solution generated by the
BASIS module.
The fixed charge optimization is performed by repeated iterations
in the LINEAR module. Iteration ends when an optimal solution is
reached, or when iteration has reached the last solution phase indi-
cated by the user, or when no feasible solution exists for the problem
as it is structured. In this last case, the system terminates abruptly
with a message to the user.
The final allocation plans are then produced in a printed report
using the algorithm solution and the user-supplied input data. The
algorithm solution includes an objective function value, the planned
disposal activity for-each origin and the activity level anticipated.
By using the user-supplied input data identification, features are
added to the report in addition to the pertinent costing Information.
In the dynamic operating mode, an allocation report is produced for
each modeling period.
Figure 3 illustrates view of the general system flow for the WRAP
model.
General Program Functions
The WRAP program has ten functional modules and a main control
module. The term "module" here refers to a collection of subroutines
which are closely related and which collectively perform a major WRAP
function. Names of modules are shown in upper case; in some cases the
module name is also used for the primary subroutine within the module.
Figure 4 presents the list of modules and their sequence of execution
in the overall program. An in-depth discussion of each functional
is given in Chapter 4.
MAIN is the controlling module which contains the main FORTRAN
computer program, performs data initialization, and invokes all of the
functional modules in the proper sequence. In addition, the module
physically contains some subroutines which are called by more than one
functional module.
The first transfer of control is to the EDIT1 functional module,
which reads the user's input data records. Records in each of six
-------
User
Prepares
Input Data
WRAP Input
Data Cards
Read, Edit,
Store, Print
User Prepared
Input Data
Output Error
Messages and
Reason for
Error and Halt
Input
Data Errors
Severe
Solve Walker
Linear Algor
ithm Exec.
by Phases
Output Final
Results in
Report Format
Figure 3. WRAP General System Flow
8
-------
(MAIN)
Main Control
and Cata
Initialization
(EDIT!)
Read and
Edit User's
Input Data
(EDIT2)
Cross Check
Data for
Consistency
and Existence
(LINKAGE)
Chock for
Completed
Transportation
Links
(CROWFLY)
Generate LlnlcT
and Data
Missing from
Transportation
Activity File J
(FRONTOUT)
Print Input
Data and Output
Other Data at
Jsers Request
(COLUMN)
Build Matrix
Column
Identification
File
(MATRIX)
Construct Matrix
Vectors with
Coefficients
In Rows and
Columns
(BASIS)
Generate an
Initial Feasible
Solution If Not
Supplied
(LINEAR)
Solve the
Optimizing
Problem wi th
Walker Algorithm
(OUTPUT)
Print Final
Formatted Reports,
Punch Solution
Vector
' NORMAl\
END
*Program may be terminated at these
points by user request.
Figure 4. Functional Modules of WRAP
-------
input groups are read and the input fields are checked for validity.
If the first record has bad data, then WRAP execution is aborted
immediately. When the input data have been processed successfully, six
temporary storage files are created and a set of pointer tables are set
up to reference the files. If a severe error is detected in the input
records or the records are out of sequence, the WRAP execution is
aborted.
EDIT2 is the second module to be exercised in a normal logic flow.
This module contains procedures for checking consistency of user data.
The six temporary files, set up by the first editing procedure, pro-
vide the input data for this module. All errors are flagged and
printed. If errors detected are not severe enough to impair the
execution of the remaining modules, control is returned to the main
level; otherwise, for a very severe consistency error, the execution is
terminated. (A very severe error is one which prohibits meaningful
execution beyond the point of error detection.)
It is necessary that all transportation activities be complete and
that all possible sites and sources are linked. The next module,
LINKAGE, controls the checking for the possible activity links as
determined by the user inputs. Tables are built with the identifica-
tion numbers for all possible origins of solid waste and all the
possible disposal destinations. These tables are then checked against
the control data specifications and the transportation activity data
file. Program execution may terminate abnormally at this point depend-
ing on the results of the linkage checking and the status of the user's
control switches. If the user has not requested automatic linkage
generation and links are missing, the execution aborts with a message
to the user. If the user has requested minimum linkage completion by
CROWFLY and the number of links missing exceeds 10 then the execution
aborts. Otherwise execution continues.
The CROWFLY module, which performs automatic transportation
activity file completion, is optional. The user's control data must
request the execution of this module. The routine completes activity
records which have not supplied the travel distance or travel time.
Missing links are also created using a maximum radius criteria or the
shortest link outside of the maximum radius. In order for a link to be
made, the processing facilities involved must allow for the possible
linking. This linking information is obtainable from the process data
group.
If execution is not aborted in the previous functions, the user's
input data is printed by the FRONTOUT module. A special punch capa-
bility is also available. This capability allows the user to request
the program to punch a completed transportation activ-ity file and,
after MATRIX execution, to punch the matrix vectors. The same control
switch for the file punching is also used to indicate whether the pro-
gram execution is to continue or to terminate normally. If severe
errors are detected the execution will abort prior to the punchout.
10
-------
COLUMN is the first of two modules which structure the model matrix.
The matrix column identification records are created and written to a
temporary file by these routines. An internal pointer table is also
generated. The records contain information from the user input data
which is used in the final report and for constructing the storage
allocations for the matrix coefficients. This module differs slightly
for each mode of operation (static or dynamic) since the classes of
coefficients varies with operating mode. In addition to the column
identification data, the fixed and variable costs associated with each
column are also written on the records. The costing equations are
dependent on the operating mode and the class of column being identified.
If the number of columns created exceeds the allowable storage space,
then the program execution is aborted.
The model equations are structured into matrix form in the MATRIX
module. The equation coefficients are stored in a sparse matrix vector.
The row (equations) and column (coefficients) identification numbers
are stored 1n separate vectors. Logic in this module is controlled by
the operating mode. To standardize coefficient generation, the logic
is expressed based on the number of modeling periods specified by the
user. In the static mode there 1s only one modeling period. In the
dynamic mode there may be from two to four modeling periods. Special
checks are made in the dynamic mode to make sure that the processing
facilities exist or are available for use during the particular period.
Also there are two more equation types and two more coefficient classes
in the dynamic operating mode. Then a special dummy row is generated
to assure matrix balance. Finally, a dumrny column 1s generated to be
used for substitution in the first optimizing solution If there are
negative activity levels detected.
The user may request punch out of the matrix coefficients and row
column Identification vectors. This input switch also Indicates
whether WRAP execution 1s to terminate or continue. The matrix punch-
ing is performed by the FRONTOUT module.
BASIS is an optional module which generates an initial starting
solution for the model matrix. Use of the BASIS module is an alterna-
tive to user specification of the starting basis in the input data. A
value or solution is computed for each equation (row) 1n the matrix.
These solutions are stored 1n a vector to be used by the linear pro-
gramming algorithm.
The LINEAR module has all of the routines used for solving the
Walker linear programming algorithm. This module is aborted if a
feasible solution 1s not found or if the initial starting basis (pro-
vided by the BASIS module or by user input) is not feasible. Error
messages are printed when the optimizing process is aborted. The input
data also controls two other features of the LINEAR module: (1) the
number of optimizing phases executed, and (2) the type of solution print-
outs after each execution phase. The final solution printout, generated
11
-------
in the LINEAR module, includes the objective value (cost) of the solu-
tion, the basis values of the solution (the selected activity) and the
activity level (amount of waste tonnage).
The last module, OUTPUT, uses the LINEAR module solutions to pro-
duce planning reports. Since the LINEAR solutions are vectors' of
numeric column pointers, the output module uses the vectors to access
the appropriate column records and prints the user supplied identifica-
tion data along with the report solution. The reports are generated by
column classification and modeling period. Within these two areas,
there are subreports by type of transportation activity or by type of
processing facility. The number of reports generated depends on the
operating mode. In the static mode, there is only one modeling period,
therefore there is only one set of reports. In the dynamic mode, there
are as many report sets as there are model periods. In addition, there
are special sequenced reports 1n the dynamic mode because of the dynamic
matrix model structure.
System Environment
The WRAP program does not require any specialized computer environ-
ment. The program, however, is very large and does require special
handling at execution time. The following sections briefly present a
picture of the physical structure of WRAP and some execution features
that deserve special attention. For more detailed Information on the
operating environment, refer to Chapters V and VI.
Physical Features
The WRAP program is composed of 99 FORTRAN routines with approxi-
mately 7000 source records.The program 1s divided into the 11 modules
discussed in the previous section. Table 1 lists the modules and their
associated subroutines.
Table 1
WRAP MODULES AND ASSOCIATED SUBPROGRAMS __
Module Subprograms
MAIN WRAP*, DEFLT, ERROR, FIND, INITDA, LXCOMP,
OST5RT, READIT, SEGS
EDIT! EDIT!, CONTRL, CRWFLY, LINKS, PRCOST, PROCES,
StPRT, SITE, SOURCE, TBASIS, TRANS, TRUCK
EDIT2 EDIT2, CKSIPR, CNTCHK, ONENUM, PRCHK, TRNCHK
LINKAGE BUILD. LNKCHK
12
-------
CROWFLY CROFLY, CADIST, CONY, CRWLNK, DUP, DUPWRT,
ICROW1, ICROW2, LNKBLD
FRONTOUT APRPU, PRINT, PUNCHM, PUNCH!
COLUMN COLUMN.. CPFAC, CSTCRD, KCOST, PCOST, SCOST,
TCOST,'TRFAC
MATRIX MATRIX, CAPBAL, COST, ED, INITLP, ISPOB,
IUSIB, ISUPC, IUSTC, LANCON, SETC, SETR,
SORBAL, TBREAD, ZCOLMN
BASIS DBLFND, DSTRTB. SSTRTB
LINEAR SWAP, BTRAN, COMEI, DOTPR, ETA6E, ETARB,
EtlRF, ETARI, FORCE, FSORT, FTRAN, INIT, LP,
NEWA, OUT, PASSA, REINV, REMOV, SAVE, SETUA,
SETUB, SIMPL. SWITC, TINY, ZCOLIN
OUTPUT OUTBAS. APRINT^ ODYN1, ODYN2, OSTAT, SER2
Underlined routines are the principle control routines for the
module.
For ease of referencing and maintenance the routines in WRAP are dis-
cussed in module sequence in Chapter 4. Documentation summary for
each routine is presented in alphabetical sequence in Appendix II.
The majority of the data used in WRAP are stored in labeled common
areas. There are 20 common storage areas of varying sizes. Table 2
lists the areas and the storage requirements. Eight direct-access files
are used as temporary storage for input records and matrix column
identification records.
Table 2
WRAP COMMON STORAGE AREAS
Common
Area
Unlabeled
ERRCOD
FRONT
Contents
Description
Major WRAP control variables,
and matrix arrays
Error code identification variable
Control variables input to control data
Number of
Variables
32
1
read and edit logic control 27
13
-------
INK
MAT
OCOM
PNTR
OCOM
PROCCO
READ
RNACO
SBASI
SETREC
SIPRCO
SITECO
SRCCO
SWAPCO
TITLRD
TRANCO
TRKCO
Variables used to check Input
usage and activity linkage
Variables used for structuring matrix
equations and coefficients
Output variables for final report
control
Pointer tables for temporary storage
files
Punch output file variables and
debug switch
Process identification variables
Temporary storage record read
variables
Matrix equation (row) identification
variables
Special basis replacement variables
Column position counter variables
Site-process identification variables
Site identification variables
Source identification variables
Linear algorithm computational and
control variables
Title record variable
Transportation activity record
variables
Truck constraint identification
variables
5
13
5
5
2
20
12
3
2
4
8
6
45
1
7
2
Because of the physical size of the WRAP program, it is advisable
to always execute a job from an object code deck. If possible, the
object code should be stored on a high speed device, since the object
code deck is almost as long as the source code deck.
14
-------
Support Software
This documentation describes a card oriented system, where both
the source code and the object code are assumed to be maintained in
card decks. The user may choose to install the programs on interactive
time-sharing environment. Under those conditions, the particular
installations maintenance software would be utilized. Otherwise, there
are no special support software routines required.
The WRAP program is designed to be executed in a batch job sub-
mittal environment. The program code does not prohibit interactive
execution. The execution time and the core storage requirements, how-
ever, could make interactive program execution costly. If interactive
program submittal for batch processing is possible, it is strongly
recommended, as is interactive maintenance for minor modifications.
Interfaces and Storage
There are no special interface procedures required by the actual
program code. Data which are to be available for different modules and
subroutines are stored in a series of labeled common storage areas and
in eight temporary direct-access files.
The primary area of concern for program interfaces and storage is
the execution overlay structure, shown in Figure 5. This structuring
is required to assure proper program execution when limited core storage
is available. The names in Figure 5 are the modules of WRAP or large
areas of labeled common storage.
Controls
There are two types of program environment controls available to
the user. The first is modification of the size of the program. The
standard version (90 x 360) handles problems with 90 or less rows and
360 or less expanded matrix columns. WRAP may be modified by the user
to accommodate large problems. The amount of computer space necessary
for WRAP execution depends on the program size Implemented.
The second control available to the user 1s modification of the
sizes of temporary storage files. To alter the temporary storage data
sets, definition modifications must be made to the program source code.
Any other logic alterations or data definition changes must also be
made in the source code.
Timing
The WRAP program has a wide range of execution time, since timing
depends on the user control switches and the problem size.
15
-------
MAIN LEVEL
MAIN
Segment 1
ALPHA LEVEL
BETA
51 LEVEL
FRONTOUT and Cannons
Segment 2
EDIT1
Segment 3
EDIT2,
LINKAGE,
CROWFLY,
Segment 4
COLUMN,
MATRIX,
BASIS,
Segment 5
'SWAPCO'
Segment 6
GAMMA LEVEL
LINEAR
Segment 7
OUTPUT
Segment 8
Figure 5. WRAP Program Overlay Structure
-------
Generally, the editing, link checking, and matrix building front
end functions require less than one minute of central processor time on
an IBM/370 Model 158. If the user control switches request early ter-
mination after punching the transportation activity file or the matrix
Vector files, then execution time will be less than one minute regard-
less of the problem size.
Timing increases greatly with the execution of the linear pro-
gramming algorithm, due to the iterative process and the sensitivity
of the problem data. Factors.affecting execution time are matrix vector
dimensions, cost data and activity levels. The most crucial data factor
is the number of columns in the problem matrix. Figure 6 illustrates
some timing information taken from operational tests and exercise runs.
No. of
Rows
75
90
61
60
62
60
60
75
No. of
Columns
254
325
146
148
167
148
148
181
No. of
Slacks
2
9
3
7
3
7
7
4
Last
Phase
3
3
3
3
4
4
4
4
CPU Time
in Seconds
218.29
432.97
211.71
68.52
274.79
238.32
274.20
540.21
Run
Name
ST.L.F
ST.L.A
ST.L.C
MASS A4
ST.L.E
MASS Bl
MASS Cl
ST.L.F1
Note: The times are for illustration only. For more Information
about the specific problems Involved please refer to WRAP
Documentation of Operational and Exercise Runs.8
Fiqure 6. Timing Examples from WRAP Executions
Transportability
The WRAP program is flexible and transportable with respect to the
coding language (ANS Standard FORTRAN IV9) with one exception. The
large data files are stored on temporary direct-access devices The
code used to access these files is IBM FORTRAN IV specific, Otner
computer models may not accept this code.
17
-------
There are no special utility routines called or referenced by the
program code. Standard FORTRAN math routines such as SQRT and ABS are
used in some computations.
As mentioned earlier, because of the physical size of WRAP, overlay
capabilities are used. The special overlay environment is discussed in
more detail under System Environment and fn Chapter 5, Maintenance
Procedures.
Accuracy and Validity
WRAP uses two front-end editing procedures to check the user's in-
put data groups. Error factors are used in the linear programming
algorithm to check for round off problems arid data underflow or over-
flow. No other special accuracy or validity tests are included unless
they are part of the modeling algorithm itself (e.g., the LINEAR module).
The front-end editing procedures found in EDIT! and EDIT2 modules
check the input data for validity and consistency onty. There are no
provisions for setting default values for certain control options and
certain data fields. Whenever the program makes a change to the user's
input data, appropriate messages are output.
The internal data is subject to specific computer software and
hardware configurations. WRAP was developed on an IBM/360 - 370 system
using single precision integer and floating point variables. The
floating point variables have a precision of 7.2 decimal digits in
single precision and integer variables have a precision of 9 dlgtts9-
Because of the iterative nature of the linear programming algorithm,
round off errors may appear in the algorithm solutions.
Overview of Inputs and Outputs
This section presents an overview of the input and output data for
WRAP as viewed by the user. Internally generated data are not reviewed
at this time since these are not directly controllable by the user.
All data are discussed in more detail in Chapter 3, data Base Specifi-
cations.
For background and preparation information on the input data, refer
to the WRAP User's Guide/.
Inputs
Program execution data is input from a sequential data set, normally
the card reader. There are eight types of inputs to be prepared. Five
of the input types are required by every program. Three input types are
optional.
18
-------
All data for a particular tnput type is input sequentially. There
is no special ordering required wttfiin an input type. However a special
ordering is required for the types of user-supplied inputs. Figure 7
illustrates the required input sequence.
1 (Control Record(s)
2 I Source Identification Record(s)
3 fsite Identification Record(s)
4 I Process Identification Record(s)
5 iSite-Process Identification Record(s)
6* (Transportation Activity Record(s)
7* fTruck Constraint Identification Record(s)
8* (Starting Basis Record(s)
*Indicates Optional Input Records
Figure 7. Input Records Sequence
The different input records are determined by their identification code.
The counters provided on the first control record determine the number
of records read for each subsequent type of input. Any input incompat-
ibilities are detected at read-in and the program halts abnormally. The
specific data fields for each input type are described in detail in
Chapter 3 - Data Base Specifications.
Control Records. Four control record inputs are possible. Two
records are always reauired and two records are optional.
1. The first control record is mandatory for all executions.
It contains all of the counters and logic control variables.
2. The second control record is required only for dynamic mode.
It contains costing variables for dynamic computations.
3. The third record is required for all executions, and contains
the user's job title.
19
-------
4. The fourth control record is required only when a "crowfly"
option is to be used (see Table 3 for a definition of
"crowfly" options). The record contains crowfly measurement
variables for travel distance and time computations.
Sou rce Identificat1 on Records. The next input type is four source
location identification.An identification record for each original
solid waste source must be supplied. Each record must have a unique
source identification code as well as the record code.
The identification code for a source record may be any value from
100 - 499. No duplicate codes are allowed. Source identification
records do not need to be in any particular sequence. There must be at
least one source record in the user's input file.
Site Identification Records. The next Input type is the site
identification.There must be one record each Intermediate and ultimate
site. Each record must have an input type code and a unique identification
code. The site identification code may be any number from 500 - 799.
All site records (ultimate and intermediate) are Input In one group.
No special site ordering is necessary; however, for ease of referencing,
the identification code numbers may be assigned to a particular type of
site.
Process Identification Records. The next required Inputs are process
identification records.There are five different types of records
possible for each unique process. Each record has Its own record
identification code. In addition, each process must have a unique
numeric identification code which appears on each of the records
defining the process. The Identification codes may be any number from
900 - 999. Though the processes need not be 1n a particular order, the
records associated with each process must be in a specific sequence:
1. Process identification record one contains the first
part of the process Identification Information.
2. The second process Identification record has the
remainder of the Identification Information.
3. The third process record contains a 11st of the
possible input links to the process. There may
be one or two input link records. Every process
must have a possible input link record.
20
-------
4. The next process record is optional and contains a
list of all the possible output links from the process.
There may be a maximum of two records. This record
must not be input if the process being identified
does not produce output waste.
5. The last process record contain process costing
information. The number of records to be input
is determined by the number of modeling periods
for the planning problem and the number of linear
segments indicated for the particular process.
There may be from one to twelve process cost
records.
Site-Process Identification Records. Site-Process records are
the next input type.There is one record for each process at each site.
Each record must have a set of unique nuroer.1c identification codes.
These codes must match those codes input on previous site and process
identification records. A process that has been designated as already
existing may appear on only one site-process record. There may be a
maximum of 125 records. These records do not need to be in a particular
sequence.
Transportation Activity Records. Transportation activity records
are optional, but will generally be part of the input file. If the
user's control input has indicated execution of "crowfly" option 2 and
a transportation count of zero, then this Input 1s not expected. When
"crowfly" option 2 is not requested, transportation activity records
must be provided so that each source and each site-process with waste
output will have at least one outgoing activity, and at least one in-
coming transportation activity. If the user has requested "crowfly"
option 1, then a maximum of ten activities may be missing from the input
records. Each transportation record must have unique Identification
codes (no duplicate records are permissible). Each record must also
have an activity type code which describes the transportation links.
The activity type codes are:
1 - source to ultimate site;
2 - source to intermediate site;
3 - intermediate site to intermediate site;
4 - intermediate site to ultimate site;
5 - other/special, any of the above not subject
to truck constraints.
21
-------
Truck Constraint Identification Records. The last problem
definition and identification inputs are the optional truck constraint
records. They are required only when the user's control data indicates
that sites are to be subject to truck constraints. There must be one
record for each truck constraint. Each record may have a maximum of
three site identification codes. Each site on a record will be assingea
the truck constraint for the modeling period specified. No special
ordering is necessary for the records for the stte numbers on a record.
Starting Basis Records. The initial starting basis records are
optional and not considered part of the problem identification records.
These records are input only when the user has Indicated their availabil-
ity. The number of records is determined by the number of rows (equations)
in the matrix. There are sixteen basis entries oh a record. Care must
be exercised to assure that the number of basis values read in ts
equivalent to the number of rows to be generated in the matrix building
function.
Outputs
There are three types of outputs generated by WRAP. Figure 8
illustrates the output types.
It should be noticed that the printer file has two mnemoic names.
This features was built into the program to allow the user (with a main
program modification and a job control language change) to choose a
different output device for the front end reports and the planning
reports, if desired.
Print Files. There are six types of outputs written to printer
file JET:
1. All errror messages generated by the program editing
functions and the linear programming algorithm are
written to printer file JEF. Other special warning
messages are also written to this file as error
messages to the user.
2. At the completion of the editing functions all user-
supplied input data, except the transportation activity
file and the starting basis, are output in report
format. Each input type is started on a new report
page.
3. The transportation activity file is output in report
format after the link network has been checked and
all data fields on a transportation record have been
completed.
22
-------
Code/Name
Type
Data
No. Name
ro
to
JEF
OUT
PFILE
PRINTER
Error message and codes
Debugging data
Input identification records
Transportation activities
Matrix vectors
LINEAR module data
Planning Reports
Transportation activities
Matrix vectors
Solution basis
Figure 8. WRAP Outputs Generated
-------
4. When the matrix but!ding process is completed, the matrix
vectors may be reported. This option is determined by the
user's input control data.
5. The amount of output generated by the LINEAR module is
controlled by a user-supplied variable. Under all condi-
tions, the final solution basis is reported in vector
format with column identification codes, and activity
levels. The objective value is also output with the
final solution.
6. When the program is executed with the debugging switch
on, selected variables and arrays at intermediate pro-
cessing checks are printed. The debugging switch is
set in the main program and may be reset at different
places in the main control program logic. This option
should only be used by the programmer who has modified
the input record formats or data specifications.
The planning reports are written to file OUT, which is currently
a printer device. The numeric column identification codes in the
solution basis are translated into column coefficient identification
codes and names. This report also contains the planning period(s) waste
tonnages and costs.
Punch File. The punched card outputs are generated only when
requested by user input control data. The user may request the punch-
out of the completed transportation activity file. This file is punched
in a format that is acceptable for subsequent read in as part of the
user's input data. The user may also request the punchout of the matrix
data. Figure 9 lists the data generated by this request.
Card Type Contents
NAME Last phase of execution, forcing method,
steepest descent request, punch final fasis,
printout options, number of non-zero elements,
number of rows, and number of columns
*ROWS Row identification number, type of equation
indicator code, and right hand side value
*COLS Column identification number, variable cost,
and fixed cost
24
-------
*MATX Row number, column number, and matrix
coefficient
*
A special data identification card is punched proceeding each of
these sets of output data.
Figure 9. Punched Matrix Data
This punched output is directly readable by the original linear pro-
gramming algorithm developed by Compuvisor, Inc., but cannot be used
as input to WRAP. The last punched output that may be requested is the
final solution basis generated by the linear programming algorithm. The
solution basis is punched with the numeric column numbers. The output
format is compatible with the input format required for the starting
basis. The solution basis would normally be punched when a user intends
to make a series of executions with the same basic problem structure but
with minor modifications 1n the problem data definitions.
Logic Control Variables
Program logic control variables are user-supplied, generated
normally and generated by errors. These control variables alter or
direct the flow of logic 1n the WRAP program. Some of these control
values may request early termination of program execution. An early
termination is considered to be any halt 1n execution prior to the pro-
duction of the final planning reports. Errors in some control variables
may cause the WRAP execution to abort immediately or after the module
detecting the error returns control to the main program.
The FORTRAN run-time system also may set termination flags. These
flags usually indicate a problem in the user-supplied Input data which
was not detected by the WRAP editing process.
Tar .-- J lists the user-supplied logic control data.
Table 3
USER-SUPPLIED PROGRAM LOGIC DATA
Control
Variable Action Based
Name Identification On Value
1. MTYPE Mode of Execution 1 = static processing
2 = dynamic processing
25
-------
2. LPHASE
Last Phase of Linear
3. NFORC
4. KOPT
Type of Forcing Method
to Use in Phase 4 of
Linear Program Process
Output Options to be
Used in Linear Pro-
gramming Process Only
5. INDSD
Steepest Descent
Processing Request
6. IBASE
A Starting Basis is
Available for Read-In
7. PBASE
Final Solution is to
Be Punched
3 = terminate pro-
cess tng after
phase 3 is
completed
4 = terminate pro-
cessing after
phases 3 and 4
are completed
1 « single column
forcing into
phase 4 solution
2 « double column
forcing into
phase 4 solution
1 »all programmed
output is gen-
erated
2 = only the initial
input matrix
counts and the
final results are
output
3 = only the final
results are output
do not use
steepest descent
in linear program
approach
use steepest
descent approach
do not try to read;
a basis is not
available, gen-
erate the starting
basis internally
read the starting
basis, do not gen-
erate the starting
basis internally
do not punch the
final solution
basis
punch the final
solution basis
2 -
26
-------
8. ICROW
Crowfly Processing
Options
9. PCROW
Punch the Transportation
Activity File and Halt
or Continue
10. PMODEL
Punch the Prepared
Matrix Model Input
11. ITRUCK
Truck Constraint
Option
12. NPERID
Number of Modeling
Periods
0 a "crowfly" option is
not to be used;
if network is in-
complete ABORT job
1 = use limited "crow-
fly "opt ions; if
more than 10 net-
work links are
missing abort the
job, create up to
10 links if
necessary
2 * use maximum radius
"crowfly" option,
generate a com-
plete transporta-
tion network
do not punch the
file and continue
processing
punch the file and
terminate process-
ing
punch the file
and continue pro-
cessing
do not punch the
data and continue
processing
punch the data and
terminate pro-
cessing
punch the data and
continue process-
ing
0 =
1 =
2 =
0 =
1 =
2 *
1 =
2 =
1
2-4
no truck con-
strained sites, do
not read truck
input file
truck constrained
sites exist, read
truck input file
static case pro-
cessing
upper limit on logic
loops for dynamic
case processing
27
-------
The twelve entries are input on the first user-supplied control record.
These variables represent the major control data that the user* may pro-
vide. Other inputs are also used to determine logic flow. These other-
data are mostly dynamic execution data, and are modeling period specific.
Within each module, logic control variables may also be generated.
These variables are calculation or process specific and are described in
'detail when the particular module is discussed.
The error control variables are generated during the edit process-
ing and the linear programming processing. These variables may cause
program execution to halt abruptly or may temporarily alter the program
logic flow. Under all error conditions, the user is notified of the
activation of an error control variable.
28
-------
Chapter 3
DATA BASE SPECIFICATIONS
General
The WRAP program data base is detailed in this chapter with data
descriptions presented by variable names as they exist in the FORTRAN
program. The data is described in such a way as to be easily re- ,
lated to the analytical descriptions given in the WRAP User's Guide7.
In order that the chapter may be read easily, the majority of the
supportive charts and figures were placed in Appendices I, III and IV.
Purpose
The chapter is designed to help the maintenance programmer
identify and access the program variables necessary for efficient
WRAP maintenance or modification. The specifications, useable by
both the user and the maintenance programmer, include variable defi-
nitions, array dimensions, storage allocations, and expected or com-
puted values. Greatest detail is provided for the user-supplied in-
put data. Eight temporary files are then described followed by the
description of the internal pointer tables used to retrieve the data
from them. The last two sections discuss common storage allocations,
and the several outputs generated by WRAP.
References
In addition to four of the appendices of this volume, the reader
should have access to two other documents for this chapter. The first
is a copy of ANS Standard FORTRAN IV Language Manual and the second is
the WRAP User's Guide?.
Identification and Description
Special data features are described in this section. These
features include physical attributes, labeling and naming conventions,
data organization, and special sizing and dimensioning instructions.
Physical Attributes
The WRAP data base has three types of variables and constants:
(1) integers, (2) floating-point, or real, and (3} alphanumeric. All
of the data have single precision accuracy. Computation constants and
variables are carried internally in binary. Standard FORTRAN TV sup-
port software is used for data conversion during computations and in-
put-output procedures.
29
-------
Data are made available to the program as user-supplied inputs,
and programmed constants and variables which are stored in multi-
dimensioned arrays or single entry variables. The majority of the
arrays are single dimensional with the exception of the special record
pointer tables, the linkage checking tables and the final solution
column pointer table which are multi-dimensional.
Labeling and Tagging Conventions^
The FORTRAN language allows the programmer to implicitly or ex-
pi icity specify the arithmetic type of data stored in a named vari-
able.
The implicit method uses the first letter of the named variable
to determine the arithmetic type. The letters "I" through "N" are
reserved for integer data, and the remaining letters specify floating
point data. The explicit method allows the programmer to code the
type in a definition statement, where the first character in the name
does not have to conform to any specification to indicate arithmetic
type. In FORTRAN IV:
INTEGER - followed by variable names establishes
the integer data type, and
REAL - followed by variable names establishes
the floating point data type.
In the WRAP program the majority of the data is labeled using the ex-
plicit method. This approach allows the data to be named in such a
way as to closely resemble actual data.
A naming pattern was established for the user-supplied input
data. The first characters of the variable name indicat the WRAP
application data type. This pattern was maintained as much as pos-
sible with the internally generated data. The following lists the
pattern used:
Source data "SO"
Site data "SI"
Process data "PR"
Transportation "A"
Site-Process "SP"
Truck data "TR"
Pointer tables "TB"
30
-------
The logic control data do not lend themselves to patterning and are
therefore labeled as closely as possible to their actual descriptive
names. Other internal computational data are labeled to identify
their equation value or matrix component. Temporary computational
variables, implicitly named variables, and subroutine dependent vari-
ables do not always conform to the prefix naming conventions.
Organization
The program data are organized into four groups. These groups
are user-supplied inputs, common storage areas, temporary storage
files and subroutine dependent storage areas. Within each group
there are single entry variables, single dimensional arrays and multi-
dimensional arrays. Application specification data are generally
grouped together within each organizational type.
The user-supplied inputs are read by application group type.
There are nine such groups: control, crowfly, source, site, process,
site-process, transportation activity, truck constraint, and starting
basis. These data are formatted in a sequential file on punched
cards. Appendix I contains the record format sheets for these inputs.
The next data organization group is common storage. There are
20 program defined common storage areas: one unlabeled area and 19
labeled areas. The common storage areas may contain both user-supplied
inputs and internally generated data. A list of the areas is given in
Table 4 in Chapter 2. Detailed lists of the contents of each common
area are given in Appendix III.
There are eight temporary storage files used in WRAP. Seven
files are used to store the user's input data, and the eighth file
is used to store the matrix column identification records created in
the COLUMN module. Files are written and read using format con-
trolled input-output statements. With few exceptions, these files
are duplicates of the input records. The column identification file,
one of the exceptions, contains data taken from various input records
and computed data which is column specific. A description of each
file format is found in Appendix I. The file contents are discussed
in the Temporary File section of this chapter. Table 4 gives the
physical attributes of the eight temporary files.
31
-------
Table 4
WRAP Temporary Files
File
Contents
Specifications
FILE 1
21
FILE 2
22
FILE 3
23
FILE 4
24
FILE 5
25
FILE 6
26
FILE 7
27
'FILE 9
29
Title Data
Source Identification
Data
Site Identification
Data
Process Identification
Data
Transportation
Activity Data
Truck Constraint
Identification Data
Site-Process
Identification Data
Column Identification
Data
max records = 3,
characters/record = 80
max records = 50
characters/record = 70
max records = 50
characters/record = 50
max records = 20
characters/record = 50
max records = 450*
characters/record = 50
max records = 25
characters/record •= 50
max records = 125
characters/record = 80
max records = 360*
characters/record = 140
*Maximum records does not reflect size of current program
version which should only hold 300 records
+This specification changes for different sized program
versions accomplished by code modification
Subroutine dependent data storage is the last organizational
group. Data in this group do not include user-inputs or data that
are assigned to a common storage area. (When data variables in this
group are important, they are described in the later sections and
chapters.) Because of the great variety of data in this group and
the lack of a generalized organization structure, it is not discussed
further.
Input-Output Files
Twelve file definitions are given in the WRAP program. Eight of
the definitions are for the temporary storage files, the other four
files are:
32
-------
Card Reader MUT = 5,
Card Punch PFILE = 7,
Report Printer JEF = 6,
Final Report Printer OUT = 6.
All of the files are defined in the WRAP control program, MAIN.
If the number and type of input-output files required are not
available, then the program code must be altered. This is especially
necessary for the direct-access temporary storage files. Chapter V
discusses maintenance procedures and the Job control language cards
for the input-output files.
Data Dimensions
The WRAP program is fixed size allowing for a matrix with 90 rows
and 360 columns before matrix expansion. The current version also al-
lows for 8100 non-zero elements in the expanded matrix and 450 col-
umns. These limitations are used as the dimensions for the matrix
arrays in the program code.
In addition to the matrix dimensions, the user-supplied inputs
have maximum dimensions. The input maximums are used in the temporary
storage files space allocation definitions and their associated point-
er tables.
Figures 10 and 11 contain the fixed dimensions in the
program.
Matrix Data
Row related arrays 90
Column related arrays - non expanded 360
Column related arrays - expanded 450
Non-zero elements of Matrix arrays 8100
Figure 10. Program Fixed Data Dimensions
33
-------
Source identification records 100
Site identification records and tables 50
Process identification records and tables 20
Process cost Sets 12
Process links in or out 36
Site-Process identification records and
tables 125
Transportation Activities records and
tables 450
Truck Constraint records and tables 25
Possible unique origins for Unking 125
Possible unique destinations for linking 50
Figure 11. Non-Matrix Data Dimensions
An application problem should be sized to be sure that the
dimensions are compatible prior to execution. Sizing procedures are
given in Chapter VI of this volume and 1n the WRAP User's Guide.7
•
The following illustrates some sizing examples and a program version
necessary for execution.
Example 1 Example 2 Example 3
CASE TYPE STATIC DYNAMIC STATIC
SOURCES 29 8 29
SITES-INT 21 6 15
SITES-ULT 13 1 3
PROCESSES 6 46
SITE-PROCESSES 48 10 27
TRANSPORTATION 368* 30 120
TRUCK CARDS 6 02
MODEL PERIODS 1 4 1
ROWS 111* 114* 75
COLUMNS 514* 234 182
Size Recommended 150/600 (new) 120/480 (new) 90/360 (WRAP)
*Where the * indicates that a different sized program version must be
generated and used.
34
-------
When the user requires modifications to the array dimensions,
several steps must be taken. These steps are discussed in detail in
Chapter 5. Three examples of things to consider are given here. (1)
If the array being altered is a pointer table for temporary storage
file (TBPR, TBMATC, TBTRAN, TBSI, TBSIPR, TBSRC), then the file defi-
nition statement and the execution job control record may also have
to be changed to reflect the new direct-access space needs. (2) All
of the arrays are in a common storage area, therefore, the common
storage definition statement must be changed in each subroutine in
which it 1s referenced. (3) Finally, Appendix IV provides informa-
tion on the subroutine-common cross referencing which must be checked
to be sure all modifications are made.
Finally, the user should review the data preparation procedures
as indicated in the WRAP User's Guide? prior to making any changes in
the input data.
Data Definitions
The descriptions and definitions given in this Section are di-
vided into four groups: (1) input records and formats, (2) temporary
storage files, (3) pointer tables, and (4) common storage allocations.
Input Records and Formats
User-supplied inputs are read from file MUT which WRAP code sets
up as MUT = 5.
There are nine groups of user inputs with two groups, control
records and process records, having multiple input formats. The num-
ber of records in each input group is application problem dependent
and program limited. Table 5 contains a list of the input groups and
the record types and record Identification codes within each group.
35
-------
Table 5
USER INPUT GROUPS
Group
Type
Record
Type
Record
Code
Input
Status
Control Main control switches CONTRL
Dynamic Control cost CNTR2
data
Title of Job TITLE
Crowfly Crowfly measurement CRWFLY
data
Source Source identification SOURCE
data
Site Site Identification SITE
data
Process Process identification PRC1
header 1
Process identification PRC2
header 2
Process input links
possible
LNKI
Process output links LNKO
possible
Required always
as first record
Optional second
record for dynamic
mode only
Required always as
second or third con-
trol record
Optional record only
required when crowfly
option Is requested
Required always, one
for each site number
Required always, one
for each site number
V-
Requlred always, one
for each process num-
ber
Required always, one
for each process num-
ber
Required always, at
least one record for
each process
Optional, required only
if a process generates
waste output
36
-------
Process cost data
Site-
Process
Trans-
portation
Truck
Basis
Site-process identi-
fication data
Transportation activ-
ity identification
data
Truck constraint
identification data
Initial feasible
starting basis
PRCOST Required always, at
least one record per
process and no more
than 12 records per
process
SIPROG Required always, one
record for each pro-
cess at a site number
TRANS Optional, usually as
required unless crow-
fly option indicates
building a full ac-
tivity file
TRUCK Optional, only used
when truck constraints
imposed. One record
for each physical
site location con-
strained
Optional, as many
records as needed to
input one entry for
each row in the
matrix
Detailed format forms are provided in Appendix I for each input
record type. For in depth discussion of the data preparation, refer
to WRAP User's Guide.7
Control - Principle Control Records
Control records are the first inputs to WRAP. There are three
record types in this group: (1) WRAP control, CONTRL, (2) dynamic
control data, CNTR2, and (3) job title data, TITLE. The second record
is only required for dynamic mode execution.
CQNIRJL. is the required first input record of the control group.
There are 26 data fields which contain the principle WRAP logic con-
trol values. Table 6 lists CONTRL record fields by variable name
with a definition, a valid numeric data range, and the column posi-
tions. If there are errors in this record, WRAP program execution
aborts immediately.
37
-------
Table 6
CONTRL INPUT RECORD
Variable
CODE (2)
JUMP
MTYPE
LPHASE
NFORC
Variable
Definition
Record identification
code
Special code to transfer
control to linear program
execution. Currently not
used.
Type of execution
1 Static, 2 Dynamic
Indicates last phase of
LINEAR module execution
LINEAR module forcing
Value
Range
CONTRL
0-1
1 or 2
1. 2, 3,
or 4
1 or 2
Columns
1-6
8
9
11
13
KOPT
INDSD
I BASE
PBASE
I CROW
method to be used in Phase
4 execution only
LINEAR module output options 1, 2 or 3
1 = complete
2 = input and output
3 = output results only
LINEAR module steepest de- 1 or 2
scent request switch
1 = no 2 = yes
User supplied starting basis 1 or 2
is available
1 = no 2 - yes
Solution basis is to be 1 or 2
punched
1 = no 2 = yes
"Crowfly" option request 0, 1 or 2
switch 0 = no, 1 = limited,
2 = maximum
15
17
19
21
23
38
-------
PCROW
PMODEL
ITRUCK
NPERID
NSOURC
NISITE
NUSITE
NPROCS
NSIPR
NTRANS
NISTRK
Punch transportation activity 0, 1 or 2
file and continue or stop
execution
0 = no, continue
1 = yes, stop
2 = yes, continue
Punch front-end matrix file 0, 1 or 2
and continue or stop
execution
0 = no, continue
1 = yes, stop
2 = yes, continue
25
1 or 2
1, 2, 3 or 4
Truck constraint data to be
input
1 = NO 2 = YES
Number of modeling periods
1 if STATIC
2, 3 or 4 if dynamic
Number of source records
to be input
Number of intermediate
site records to be input
Number of ultimate site
records to be Input
(NISITE and NUSITE cannot
exceed 50 each must have a
minimum value of 1)
Number of process record 1 - 20
sets to be input
Number of site-process 1-125
records to be input
Number of transportation 1 - 360
activity records to be
input
Number of truck constraint 1 - 50
records to be input
27
29
31
1
1
1
- 100
- 49
- 49
33
36
38
- 35
- 37
- 39
40
43
47
41
45
49
51 - 52
39
-------
STURNT Standard turn around time 00.1 - 51-52
in minutes 60.0
NYEARS Number of years in total 01 - 99 60 - 61
planning period
MYEARS(4) Number of years in each 00 - 99
modeling period of dy-
namic mode
1st period or static *(1) 63 - 64
2nd period (2) 66 - 67
3rd period (3) 69 - 70
4th period (4) 72 - 73
TRPACK Capacity of packer vehicles 00 - 99 75 - 76
in tons per truck
TRTRAN Capacity of transfer in 00-99 78-79
tons per truck
*parentheses are only used to indicate a modeling period,
they are not on the input record
CNTR2 is the next possible control record. This is an optional
record required only for dynamic mode executions. If the model type,
MTYPE, on the CONTRL record has the value of one, this record should
not be part of the input group. If it is present for a static execu-
tion (MTYPE = 1), the program aborts immediately with a read error.
Table 7 illustrates the data on this optional control record.
Table 7
CNTR2 INPUT RECORD
Variable
CODE (2)
CINFLR
CDISCR
Variable
Definition
Record identification code
Inflation rate
Discount rate
Value
Range
CNTR2
0.000-
9.999
0.000-
1.000
Columns
1-5
7-10
12-15
40
-------
(This card is required for a
dynamic mode execution. It
should not be supplied for a
static mode execution.)
The last record in the control group is the job title. The
TITLE record is required for all executions. The user must code
the identification field TITLE even if no specific title is to be
supplied on the record. The text of the user's title may begin in
column 7 and contain a maximum of 74 characters. Only one TITLE
record is acceptable.
CRWFLY - "Crowfly" Measurement Record
The next possible input is optional. A CRWFLY coded record is
only expected when the principle control record indicates that a
"crowfly" option is to be exercised. The field on CONTRL which con-
trols this input is named ICROW. When ICROW is zero, (no "crowfly")
the CRWFLY record must not be in the input file. The program aborts
with a read error if the record is part of the input when ICROW = 0.
The program will also abort if the record is not part of the input
file when ICROW has been given a value greater than zero. The con-
tents of record CRWFLY are given 1n Table 8.
Table 8
CRWFLY INPUT RECORD
Variable Value
Variable Definition Range Columns
CODE(2) Record Identification CRWFLY 1-6
code
RADIUS Maximum radius in miles 001-700 9-11
for crowfly computation
FACTR Nautical miles/minute 0.010- 13-16
of longitude conversion 1.000
factor
SPEED Standard truck travel 01-99 18-19
speed in miles per hour
(This record is required only when Crowfly option 1 or 2 has been
indicated. ICROW is in column 23 of the CONTRL record.)
41
-------
SOURCE-- Source Identification Record
Source records are the next input group. There may be from 1 to
100 records in this group identified by code SOURCE and supplying all
of the identification information necessary for an original waste
source. These records are the first inputs which have special format-
ting features, which appear in other inputs.
Each record in the source group must have a unique identification
number, SOID, with a value from 100 thru 499. No particular ordering
is required, and duplicate identification codes are not permissible.
There are two arrays which may have from 1 to 4 entries, source
tonnage, SOTONS, and source haul cost, SOHC$. These entries are for
each of the 4 possible modeling periods in a dynamic execution. When
the execution mode is static (MTYPE = 1 on the CONTRL record) the
value for SOTONS must be entered in the first field. When the execu-
tion mode is dynamic, the SOTONS values are entered in the field posi-
tion corresponding to the modeling period. If data is not available
for a particular modeling period, the corresponding field is blank.
The geographical coordinates for a location are entered as long-
itude, SOLONG, and latitude, SOLAT, coordinates. The coordinates are
expressed in degrees, minutes and tenths of minutes. Since the values
are read as one numeric entry, blanks may not appear in the field.
For example, if the longitude is 072°7.5", it is given as 72075. The
decimal point is not included. The program code interprets the data
as "7207.5", which is later converted to two separate values "72" and
"7.5" for computations.
Table 9 lists the data entries on a SOURCE input record.
Table 9
^ SOURCE INPUT RECORD
Variable Value
Variable Definition Range Columns
CODE (2) Record identification SOURCE 1-6
code
SOID Source identification 100-499 7-9
code number
SONAME(5) Source name Alpha 10-29
42
-------
SOLONG Source longitude in DDMM.M 30-34
degrees, minutes and
tenth of minutes
SOLAT Source latitude in DDMM.M 35-39
degrees, minutes and
tenth of minutes
SOTONS(4) Source tonnage in 0000.0 - (1)* 40-44
1000 of tons. One 9999.9 (2) 45-49
entry per period (3) 50-54
(4) 55-59
SOHC$(4) Source tonnage haul .00000 -
cost in dollars per .99999 (1) 60-64
ton-minute for each (2) 65-69
period (3) 70-74
(4) 75-79
*( ) Numbers indicate the modeling period and are not placed on
the records
SITE - Site Identification Record
The next input group supplies information for the intermediate
and ultimate waste allocation sites. At least one record must be in-
put for each type of site and a maximum of 50 records for both types
of sites may be input. These records are identified by record code
SITE and a unique identification number from 500 - 799 which is stored
in SIID. For readability and problem definition, the identification
codes are divided as follows:
(1) 500 - 599 for intermediate disposal sites;
(2) 600 - 699 for special final disposal sites;
(3) 700 - 799 for ultimate disposal sites.
The identification numbers are checked during the site editing pro-
cedures for duplication and validity. These numbers are also checked
in the site-process editing procedures for compatibility with the
processing level assigned to the site.
The geographical coordinates, SILONG and SILAT, are processed as
discussed under SOURCE. Sites may be at the same geographical location,
and therefore, are never checked for duplication. The geographical lo-
cations of the site are important for distance calculations in the
43
-------
CROWFLY module, whereas the site identification numbers are used
primarily for application definition.
There are four other data entries on a site record. These pro-
vide site specific information as follows: (1) site use-limitation
code, (limited or unlimited capacity) SICODE, (2) number of processes
possible at the site, SIPROC, (3) site preparation cost, SICOST, and
(4) amount of land available at the site, SILAND. The last entry
SILAND is only supplied when the site is identified as an ultimate
site. The contents of a SITE record are listed in Table 10.
Table 10
SITE INPUT RECORD
Variable
Name
CODE (2)
SIID
SINAME(5)
SICODE
Variable
Definition
Record identification code
Site identification code
Site Name
Site limitation code
Value
Range
SITE
500-799
Alpha
1 or 2
Columns
1-4
6-8
10-29
32
1 = unlimited
2 = limited
SILONG Site longitude in degrees, DDMM.M
minutes and tenth of
minutes
SILAT Site latitude 1n degrees, DDMM.M
minutes and tenth of
minutes
SIPROC Number of processes at 1-9
this site
SICOST Site preparation cost in 00000.01
thousands of dollars 99999.99
SILAND Land available at the 000000 -
site expressed in acre- 999999
feet (only if Its an
ultimate site)
34-38
40-44
46
47-53
55-60
44
-------
Process Identification Records
The PROCESS input group supplies the identification data for a
waste processing facility. There are five record types in this group,
Four of the records are required for process identification. The
fifth record is only required when a process generates waste output
which must be allocated to a final waste disposal process. The con-
tents of each type record are listed in Tables 11 through 14.
Process records are input in sets by process number. Every rec-
ord associated with a particular process must be input sequentially,
as illustrated in Figure 12.
1. PRC1
2. PRC2
3. LNKI
4. * LNKO
5. PRCOST
Process identification header rec-
ord with identification code in
PRID field.
Process identification second header
record. Value in ID must match
value in PRID.
Process input links possible record.
Value in ID must match value in
PRID. There may be 1 or 2 records.
Process output links possible record.
Value in ID must match value in
PRID. There may be 0, 1 or 2 rec-
ords.
Process cost records. Value in ID
must match value in PRID. There may
be from 1 to 12 records depending on
number of modeling periods and num-
ber of cost linear segments.
*0ptional input record
Figure 12. Process Records Input Sequence
Each record in a process sequence must have the process identification
number provided in the record. The input process sequence is repeated
for each process defined by the user's application. There must be at
least one process set; and not more than 20 process sets for a WRAP exe-
cution. The record sequence is problem dependent and WRAP execution
aborts immediately if the process input sequence is incorrect.
45
-------
PRC1 is the first identification record in a process set. This
record contains the process identification number selected from the
values 800 - 999 in field PRID. The process name is given in field
PRNAME. The processing level, PRLEVL, may have four acceptable codes
(A, B, C, or D}7 which must be consistent with the percent waste out-
put field, PRWGT, which indicates how much waste is output from the
process. There are four other data fields used to identify general
processing features: (!) the process existence code, PREXST; (2) the
density of waste output from the process, PRDEN; (3) the process haul
costs, PRHC$, where a process haul cost is given for each modeling
period of the application; (4) the capital lead time in years for the
process, PRLEAD.
Table 11 lists the contents of a PRC1 record.
Table 11
PRC1 INPUT RECORD
Variable
Name
Variable
Definition
Value
Range
Columns
CODE(2) Record identification
code
PRID Process identification
code
PRNAME(5) Process name
PRLEVL Process type level code
PREXST Process existence code
1 = existing
2 = not existing
PRWGT Percent waste output by
weight expressed as a
percent
PRDEN Process waste output
density in Ibs/yard3
PRC1
800-999
Alpha
A, B, C
or D
1 or 2
000.000 -
100.00
0000-9999
1-4
9-11
13-32
36
38
39-43
45-48
46
-------
PRHC$(4)
PRLEAD
Process waste haul cost
per ton-minute for each
model period
Process capital lead time
.00000
.99999
0-9
50-54
56-60
62-66
68-72
74
PRC2, the second process identification record, supplies specific
information about the process availability, PRAVAL, the process life,
PRLIFE, and number of costing segments, PRSEG, available for the pro-
cess. The process identification number supplied in field ID must
match the number supplied in PRID on the PRC1 identification record.
Table 12 lists the contents of a PRC2 record.
Table 12
PRC2 INPUT RECORD
Variable
Name
CODE (2)
PRAVAL(4)
PRLIFE(4)
Variable
Definition
Record identification code
Process availability to
be built in a period
1 = no 2 = yes
Process life if build in
a period (static case a
1 in first field)
Value
Range
PRC2
1 or 2
1, 2,
3 or 4
*(D
(2)
(3)
(4)
(1)
(2)
(3)
(4)
Columns
1-4
7
9.
11
13
15
17
19
21
PRSEG
ID
Number of cost segments
for the process
Process identification
code should match PRID
of record type PRCI
1, 2 or
3
800 or
999
31
78-80
*Parentheses indicate modeling period for input data and are not
included as input
47
-------
LNKI and LNKO are two process linkage records which provide pos-
sible process identification numbers for waste transportation to and
from the process. The first record, LNKI, is required for each pro-
cess identified. The data entries on this record are the process
identification numbers for those processes which may send waste to the
process identified in PRID. A special code is used to indicate that
sources may send waste to the PRID process. This special code roust
be the first entry in the input linkage list, LINKI. If there are
more than 18 possible input links a second LNKI record may be used.
Under all conditions, the process set identification code must be
provided in field ID and must match PRID.
The LNKO record provides the process identification numbers for
all processes that may receive waste output from the PRIU process.
This process record is only required when the PRID process has a per-
cent output weight, PRWGT, greater than zero. (PRWGT is supplied on
the PRC1 record.) With the exception of the special source linkage
code entry on LNKI, the format and specifications for this record are
identical to the LNKI record.
Data contents for these two process records are listed in Table
13.
Table 13
LNKI AND LNKO INPUT RECORDS
Variable Variable Val ue
Name Definition Range Columns
CODE(l) Record identification LNKI or 1-4
code LNKO
LINKI(1) Input possible from an 1 or 2 9
original source on
or LNKI only
1 = NO 2 « YES
LINKO(l) Process number which 800 - '7-9
may be linked to this 999
process as output on
LNKO
48
-------
LINKI (2-36)
or
LINKO (2-36)
Other process numbers
which may be linked
to this process
800
999
ID
Process
number
identification
800
999
11-13
15-17
19-21
23-25
27-30
31-33
35-37
39-41
43-45
47-49
51-53
55-57
59-61
63-65
67-69
71-73
75-77
b
78-80
PRCOST records are the last input in a process set. These are
the process cost records. There may be from 1 to 12 cost records for
each process identified by code PRCOST. The number of cost records
input for each process is determined by the number of cost segments,
PRSEG, as specified on PRC2 and the number of modeling periods,
NPERID, as specified on the WRAP control record CONTRL. Each cost
record must have the process identification code in the last data
field, ID, and the value must agree with the PRID value. A cost rec-
ord supplies cost coefficients for a process linear segment during a
modeling period. In a static execution mode, there is only one mod-
eling period and therefore a maximum of three cost records are read
since the maximum number of linear segments for a process is three.
In a dynamic execution mode, there may be as many as twelve cost rec-
ords, (4 periods with a maximum of 3 segments). A PRCOST record con-
tains a set identification number, SET, a cost segment identification
number, SEGMNT, a capital cost slope, PRSCSLP, a capital cost intercept,
PRCtNT, an operating cost slope, PROSLP, and an operating cost inter-
cept, PROINT.
Table 14 lists the contents of a PRCOST record.
49
-------
Table 14
PRCOST INPUT RECORD
Variable
Name
CODE(2)
SET(*)
SEGMNT(*)
Variable
Definition
Record identification
code
Model period cost set
identifier
Cost set segment
Value
Range
PRCOST
1, 2, 3
or 4
1 , 2 or 3
Col umns
1-6
8
9
**
**
**
**
11-19
21-29
31-39
41-49
78-80
identifier
PRCSLP(*) Capital slope
PRCINT(*) Capital Intercept
PROSLP(*) Operating Slope
PROINT(*) Operating Intercept
ID Process identification
X Code
*The variables are dimensioned for 12 entries, however, only
one is made per input card.
**Slope is expressed as DDD.DDDDDD
Intercept is expressed as DDDDDD.DDD
SIPROC - Site-Process Identification Record
The next input data group is site-process identification. There
may be from 1 to 125 site-process records identified by code SIPROC.
At least one site-process record must be in this group for each site
previously input. SIPROC records may only reference site and process
data that has been supplied on the SITE and the PRC1 records. Table
15 lists the contents of the site-process identification records.
50
-------
Table 15
SIPROC INPUT RECORD
Variable
Name
CODE (2)
SPIDS
SPIDP
SPSEG
SPCAP
SPREV$(4)
SPLVL
Variable
Definition
Record identification
code
Site-process site
identification code
Site-process process
identification code
Site-process segment
code indicating which
cost segments are to
be used (13 = all
segments)
Site-process capacity in
thousands of tons per
year
Site-process revenue
per ton per period
Level of process at
the site
Value
Range
SIPROC
500 - 799
800 - 999
01, 02, 03,
12, 23, 13
00000 -
99999
000.000 -
999.999
A, B, C,
or D
Columns
1-6
8-10
12-14
18-19
21-25
(1) 26-31
(2) 33-38
(3) 40-45
(4) 47-52
54
The identification numbers SPIDS and SPIDP must match site and
process numbers input in the respective data groups. These numbers
do not have to be ordered. The process level, SPLVL, must be the
same as PRLEVL which is provided on the process identification rec-
ord PRC1 for the process SPIDP.
The process level, SPLVL, must be compatible with the site num-
ber, SPIDS:
Site code 500 - 599 level code = A or B
600 - 699 level code = C
700 - 799 level code = D
51
-------
If the codes do not match a warntng message is output and execution
terminates abnormally before all edit checks are performed.
The site-process segment code, SPSEG, is a special code which
indicates the process linear segments to be used for costing calcu-
lations at this particular site. The codes are
01 - use linear segment 1 data
02 - use linear segment 2 data
03 - use linear segment 3 data
12 - use linear segments 1 and 2 data
13 - use linear segments 1, 2 and 3 data
23 - use linear segments 2 and 3 data
The highest segment number to be used must not be greater than the
number of segments, PRSEG, available for a process.
The site-process capacity value, SPCAP, expressed in thousands
of tons per year, is only supplied when the site has been defined as
a limited capacity site. A site is a limited capacity site when
SICODE = 2 on the SITE identification card.
If a site-process has anticipated revenue during a modeling
period then the revenue per ton 1s provided 1n the corresponding
SPREV$ input field.
TRANS - Transportation Activity Record
The next input group records are identified by code TRANS. This
group is optional but in most applications will be part of the user's
input. The number of input records read is controlled by the number
of transportation activities, NTRANS, provided in the main control
record CONTRL. Table 16 lists the contents of a TRANS record. These
records may be only partially completed at time of input. Of the
eight fields available on the card, the first five must always contain
data or WRAP execution aborts. The last three fields may be blank at
input; if so, the program will compute the necessary data if requested
by the user's control data.
52
-------
Variable
Name
Table 16
TRANS INPUT RECORD
Variable
Definition
Value
Range
Columns
CODE (2)
ACODE
Record identification
Activity type code
1 = source to ultimate
site
source to intermediate
site
intermediate site to
intermediate site
intermediate site to
ultimate site
other activities
TRANS
1, 2, 3,
4 or 5
2 =
3 =
4 =
5 =
1-5
7
AOID
AOPR
ADID
ATIME
ADISI
ASPEED
Activity origin identi-
fication code
Activity process at origin
(if origin is a source re-
peat source number)
Activity site destination
identification code
One way travel time in
minutes
One way distance in miles
Speed in miles per hour
100 -
799
800 .
999
500 -
799
-0.1 -
9999.9
000.0 -
999.9
00.0 -
99.9
9-11
3-15
17-19
24-28
30-33
35-37
All identification codes given on a TRANS record must have been
previously defined on either a SOURCE, SITE or PROCESS record. Also,
those TRANS records which give a site code in the origin fieTd, AOID,
must have a corresponding SIPROC record. No special input sequence
is required for the TRANS records.
53
-------
An activity code, ACODE, (1, 2, 3 or 4) is assigned to each
record based on the type of transportation activity between origin
and destination. An ACODE of five is used for transportation activ-
ities that are special or unique7.
The one-way travel time, ATIME, between the origin and desti-
nation must be specified when no "crowfly" option is in effect (ICROW
is zero on the CONTRL record). A negative travel time should be
provided for ATIME when the user does not want the travel time to
affect the transportation costing computation. A negative value
indicates a true zero travel time and no turnaround time will be
added. When the main control record indicates that "crowfly" option
is to be used, the ATIME field may be blank7.
The next data entry is the one-way travel distance between the
origin and the destination, ADISI. This field may be blank when the
travel time, ATIME, is provided, or when "crowfly" calculations are
requested by ICROW = 1 or ICROW = 2.
The last entry is the travel speed, ASPEED, given in miles per
hour. ASPEED may be blank when the travel time, ATIME, is supplied
or a "crowfly" option is in effect as for ADISI.
TRUCK - Truck Constraint Identification Record
Truck constraint records are optional. These records are only
read when the main program control record, CONTRL, has data which in-
dicates their existence. (ITRUCK = 2 and NISTRK >0) These records
are identified by code TRUCK.
Each record may have three site identification numbers. These
sites must be previously defined in the site input data. These iden-
tification numbers are stored in array TRSI. The TRUCK record allows
for truck constraint values for each modeling period. The constraint
values are stored in array TRNO. The number of records read is de-
termined by the truck record variable, NISTRK, on the CONTRL record.
Table 17 lists the specifications for the truck constraint input
records.
Table 17
TRUCK CONSTRAINT INPUT RECORD
Variable
Name
CODE (2)
Variable
Definition
Record identification
Value
Range
TRUCK
Columns
1-5
code
54
-------
TRSI (3)
TRNO (4)
Truck constrained site
identification numbers,
3 possible per record
Maximum number of trucks
at sites for a year in
each period in thousands
of trucks
500 - 7-9
799 11-13
15-17
000.0 - (1) 19-23
999.9 (2) 25-29
(3) 31-35
(4) 37-41
Starting Basis Record
The last input group contains the optional starting basis data.
These records are only read when the user has coded the CONTRL record
with IBASE = 2 indicating that starting basis values are to be read
and not generated by the BASIS module.
Sixteen basis values may appear on an input record, no imbedded
blank fields are allowed since input is terminated when a zero or
blank field is read. The values are provided as four digit integers
in fields separated by a blank. The basis numbers are right justified
in the fields, and leading zeros are not required. There should be
one basis entry for each row (equation) in the problem matrix, and
the values must be equivalent to a column (coefficient) identification
number in the matrix to be structured. Basis records are the last
possible input records and can only be created after the problem matrix
has been properly sized?.
Temporary Storage Files
The WRAP program generates eight temporary storage files which
are defined as direct access, thereby allowing them to be both written-
to and read-from. The eight files contain the following data:
FILE1 Title record information as read from TITLE input record;
FILE2 Source identification records as read from the SOURCE
records;
FILE3 Site identification records as read from SITE records;
FILE4 Process identification records as read from the PRC1,
PRC2, LNKI, LNKO, and PRCOST records;
FILE5 Transportation activity records as read from the TRANS
records;
55
-------
FILE6 Truck constraint records as read from TRUCK records;
FILE7 Site-process identification records as read from
SIPROC records;
FILE9 Matrix column identification records as generated
by WRAP coding.
These files are assigned file numbers 21-27 and 29 respectively.
Most of the data in the temporary files have been presented in
previous sections. The actual record formats are given in Appendix I
of this document. Those data not previously presented, with one ex-
ception, the process useability vector, PRUSBL, on a site process
record are all in the column idendification records and are pre-
sented in this section after the site-process vector. Table 18 lists
the contents of a column record.
Table 18
COLUMN IDENTIFICATION RECORDS
Variable
Name
Other Associated
Variable Names
Description of Data
J or JCNA
CNTYPE
ICODE
ID1
ID2
ID3
SPLVL
CSPSEG
CNA
ACODE, 6, 7, 8
AOID or SPIDS
AOPR or SPIDP
ADID or SPIDS
PRLEVL
SPSEG
Matrix column number, also
record number in FILE9
Column type code
Activity code identified
Origin or.site identifica-
tion code
Origin's process or site-
process identification code
Destination site or site-
process identification code
Processing level for a site-
process
Segment to be used in
computations
56
-------
MPERID
DNAME
PRNAME
DNAME
SOTON
SPCAP
PRWGT
PRDEN
SILAND
SICODE
FCCNA
VCCNA
SONAME or SINAME
PRNAME or SONAME
SINAME
SOTONS
SPCAP
PRWGT
PRDEN
SILAND
SICODE
FC
VC
Model period in which column
is located
Origin's source or site name
Origin's process name
Destination site name
Source tonnage
Destination site capacity in
thousands of tons per year
Percent waste output
Output density
Destination site's available
land
Destination site's type code
Fixed cost for the columns
activity
Variable cost for the columns
activity
The site-process records have a new data entry which is computed
internally. These new variables indicate the useability of a process
during a particular modeling period and is named PRUSBL. A process
useability is determined by examining the process abailability. PRAVAL,
and the life of the process, PRLIFE, if built in a particular modeling
period. The PRUSBL array is generated for dynamic executions only.
The column identification records are special records which pro-
vide identification and measurement data for matrix generation and the
MATRIX module. A record is created for each matrix column in the prob-
lem. These records are also used to produce an initial basis solution
in the BASIS module, and the final solution reports in the OUTPUT
module.
The column identification records have several entries which have
not been previously defined or whose contents may vary depending on
previously defined data.
57
-------
1. The first variable JCNA is a sequential number assigned as
the column identification number. This variable is the first
field in a column identification record and is also the actual
record number in FILE9.
2. CNTYPE is a single digit code assigned to every column
record. The code indicates the type of column activity;
(1) transportation, (2) process, (3) capacity building, or
(4) unused capacity (surplus).
3. ICODE is a partially new variable. For a column with
transportation activity identification, it is the same code
as the transportation activity code, ACODE. Process identi-
fication columns are assigned a code of 6. Capacity building
columns are assigned a code of 7. Surplus activity columns
are assigned a code of 8.
4. Each column identification record has three identification
number fields. Transportation activity columns have the three
identification codes from the transportation activity file -
AOID, AOPR and ADID. The other columns have the identifica-
tion codes from the site process file SPIDS, SPIDP, SPIDS.
These three fields may also be referenced as ID1, ID2, and ID3.
5. The source tonnage entry SOTON is taken from the source waste
tonnage per period table SOTONS(4). Since one column represents
only 1 period, only one tonnage value 1s required per column
record. This field is only used for source transportation activ-
ity columns.
6. The last two entries on the column identification record,
which have not been previously presented, are the fixed cost,
FCCNA, and variable cost, VCCNA, values for the column activity.
These two variables are computed using the costing data for the
particular activity. The values are later re-read and stored
by the MATRIX module for use 1n the LINEAR module. These are
variable type real whose output format specification is F12.3.
Pointer Tables.
Six pointer tables are set up by the program to retrieve data
from the temporary storage files. Each table contains the record
number and main identification numbers (SOID, SIID, SPIDP, etc.) for
the recorded data. These tables are sorted as they are used in dif-
ferent parts of the program, allowing for record retrieval in varying
sequences.
The pointer tables are described here in the order of their storage
allocation in the labeled common PNTR.
58
-------
1. TBSRC (100,2) is a table of pointers to source identifica-
tion records. Column 1 has the source identification number
and column 2 has the disk record number.
2. TBSI (50,2) is a table of pointers to the site identifica-
tion records. Column 1 has the site identification number and
column 2 has the disk record number.
3. TBPR (20,2) is a table of pointers to process identifica-
tion records. Columns are for the process identification and
the disk record numbers.
4. TBSIPR (125,3) is a table of pointers to site-process identi-
fication records. Column 1 has the site identification number,
column 2 has the process identification number and column 3 has
the disk record number.
5. TBTRAN (450,5) is a table of pointers to the transportation
activity records. Column 1 has the transportation activity code,
column 2 has the origin identification number, column 3 has the
origin process identification number, column 4 has the site des-
tination identification number, and column 5 has the disk record
number.
6. TBMATC (360,7) is a table of pointers to the column identi-
fication records. Column 1 has the matrix column number, column
2 has the activity code, column 3 has the first identification
number, column 4 has the process identification number, column 5
has the third (site) identification number* column 6 has the
modeling period number, and column 7 has the disk record number.
Common Storage Allocation
The program data is made available to the various subroutines in
several ways. The most frequently used method is COMMON storage. By
using the COMMON storage accessing method, frequently used data may
be referenced by the same mnemonic names throughout the WRAP program.
The variables in the common storage areas may be user's input, or
program defined data which data may be alphanumeric, integer, or float-
ing point. No particular ordering is used in assigning variables to
the areas. However, those areas used for user's input are allocated
in the same order as the input records.
The common storage areas are briefly identified here. These de-
scriptions present a synopsis of the type of variables stored in each
area. For detailed listing of variables 1n each area, refer to Appen-
dix III. For cross reference Information use Appendix IV.
59
-------
1. Unlabeled common contains variables that are used by almost
every routine in WRAP. The main logic variables and the matrix
vectors generated from user inputs are allocated storage in this
common area. This common area is also referred to as "blank"
common.
2. ERRCOD contains a two dimensional vector. This vector is
assigned module and subroutine identification codes. This com-
mon is primarily used by the editing modules.
3. FRONT contains mostly user inputs from the CONTRL records
which control the input reads and editing procedures. This com-
mon area is not used in the matrix building or linear modules.
4. INK contains variables used for determining the completeness
of the user-supplied transportation activity network. These vari-
ables are vectors of identification codes for all the possible
waste origins and waste destinations with their use check sup-
plied by LINKAGE module.
5. MAT contains the variables used tor structuring the matrix.
This area is used primarily by the MATRIX module.
6. OCOM contains variables used to produce the final solution
reports. This area is only used by the OUTPUT module.
7. PNTR contains the pointer tables for five of the temporary
storage files. These tables are used to retrieve records in the
source, site, site-process, process, and transportation files.
8. POUT contains three variables; the punch file identification
variable, PFILE, the debugging switch variable, IDBUG, and the
final report file variable, OUT.
9. PROCCO contains those variables associated with process
identification. This area has storage allocations for all of
the input variables for one PROCESS input set.
10. READ contains special variables from the column identifi-
cation records. These variables are not defined in any other
common area or are defined in another common and by rules of
FORTRAN must have a new unique variable name and storage al-
location. This common area is used by routines which use data
from the column identification records.
•11. RNACO contains variables which identify the matrix rows
(equations). The vectors contain the identification code for '
each waste origin-process or destination for each row in row
sequence. A special variable indicates the first land con-
straint row.
60
-------
12. SBASI contains special variables used to store informa-
tion from the basis column identification feature in the LINEAR
module.
13. SETREC contains the variables allocated for retrieving
and using a column identification record. The principal array
is the record pointer table.
14. SIPRCO contains variables which identify a particular
site-process.
15. SITECO contains the variables which identify a particular
waste site.
16. SRCCO contains the variables which identify a particular
waste source.
17. SWAPCO contains the variables which are used for the linear
programming algorithm. The majority of the variables are vectors
used for matrix manipulation and iterations. This common area
is the largest one in the WRAP program.
18. TITLRD contains the variable array which holds the job
title as provided by the user.
19. TRANCO contains the variables which identify and describe
a transportation activity.
20. TRKCO contains the arrays which identify and describe a
user imposed truck constraint on a site.
These storage areas are the last data specifications for the WRAP
program. Subroutine specific variables and constants are discussed as
needed within the module presentations in the next chapter. Tables in
Appendix III define the contents of the common storage areas. Those
tables present the COMMON areas in alphabetical sequence, with blank
or unlabled COMMON, first. Within each table the variable names are
presented in the order of their storage. Appendix IV contains a cross
reference listing which indicates which subroutines reference which
common storage area.
Outputs Generated
There are six types of outputs generated in the WRAP program:
(1) optional debugging variables and tables, (2) error messages and
codes, (3) input data report, (4) punched transportation and matrix
decks, (5) intermediate phase solution tables, and (6) final solution
punchout and reports.
61
-------
Debug Switch On
IDBUG > 0
Output to file JEF
All Table
Sorts, Print-
ed
All Check
Points
Printed
All Input
Data as
Read
Error Messages
and Codes to
File JEF
Free Text
Messages
ERROR
Numbered
Messages
ABORT
Messages
Input Data
Report to File
JEF
Formatted
Reports of
Computer In-
t Dat
Punched Data
to File PFILE
PCROW > 0
PMODEL > 0
Intermediate
Solutions to
File JEF
Matrix Rows,
Cols, and
Coefficients
Basis and
Objective
Value
Final Solution
to File OUT
Reports by
Activity
Type
Final Oasis
to File PFILF
r
Final Basis
Solution on
Cards
Figure 13. Output Messages and Reports
62
-------
Debugging Outputs
The optional debugging outputs are controlled by a debug switch
stored in labeled common POUT. This variable, IDBUG, is initialized
to zero in the main program. In order for the switch to be overridden
a new statement must be added to the code setting IDBUG to one. The
The switch may be set and reset in any routine which has POUT common.
The outputs written under control of this variable are unformatted
and subroutine specific, useable only to determine the location of
a program malfunction. These outputs should not be generated unless
a modification has been made to the program.
Error Messages
The next output type includes the error messages and codes. Some
error messages are written without error codes, however, the majority
of the error messages are numerically coded and are written to printer
file JEF. Each message indicates the possible cause of the error and
the severity of the error. These messages and codes are discussed in
detail in Chapter VI. The error messages are primarily written in one
format style; there are few exception to this format. The error mes-
sage format has two forms, one for severe errors and one for warnings:
****M.SS.EE****ABORT
"alphanumeric message"
and ****M.SS.EE****ERROR
"alphanumeric message."
where M is the module number SS is the number of the subroutine or
group of subroutines, and EE is the error number in the subroutine.
For specific error recovery procedures refer to the section on errors
in Chapter VI User Information.
Generally, WRAP execution terminates abruptly when a severe error
is detected. Termination also occurs when an error flag, FLAG, is set
to a severity code indicating the action to be taken after completion
of the subroutine or the module. FLAG may have the following values
and meanings:
1. Abort after routine CONTRL in EDIT1 module.
2. Abort in EDIT2 module before executing CKSIPR.
3. Abort after EDIT2 module before executing the BUILD module.
63
-------
4. Abort before the COLUMN module execution.
5. Warning message printed only, this does not guarantee
that abort will not occur later.
Messages not classified as errors are also written from various
routines. These messages are single line comments which indicate an
action taken by the program. Sometimes the action taken may result
in an error in a later module, or may result in immediate termination
of execution.
All messages are listed and discussed in Chapter V Maintenance
Procedures and Chapter VI User's Information.
Input Data Report
The third output is the input data report. This report presents
the user's data in a formatted output. All control variables are
output on the first page with appropriate labels. The next report
pages contain the source identification records, the site identifi-
cation records, process identification records, site-process identi-
fication records and truck constraint records. The transportation
activity report is generated separately but is similar in output to
the other records. Each report page contains heading lines for each
variable field on an input record. The report pages are included in
the test case example listing in Appendix V.
Punched Output
The user may request the punch out on PFILE of a completed trans-
portation activity file and a matrix data file. Both of these outputs
are optional and are controlled by variables PRCROW and PMODEL on first
input record, CONTROL. The punched transportation activity records
have the same format as the input records. Refer to section TRANS for
more information on these records. These records would normally be
punched after a user has requested transportation activity network com-
pletion by a crowfly procedure. Refer to the input specification for-
mat sheet in Appendix I for detail format of these records.
The second optional punched output is a special matrix description
output. This output includes row and column vectors, and non zero
matrix entries. This punchout may only be used by a standalone LINEAR
module, it may not be read by the current WRAP implementation. The
output formats and sequences for these records are given in Appendix I."
These records have the same format used for the original optimizing
algorithm developed by Compuvisor, Inc.5
64
-------
Intermediate Linear Solutions Reports
The LINEAR module, in addition to error messages, has an output
option which causes the intermediate phase solutions to be written
to printer file JEF. Outputs in this module are controlled by execu-
tion logic and control variable KOPT which is provided by the user
on the main control record, CONTRL.
KOPT =1 All matrix variables and vectors are written to
the printer. All intermediate solution values
and vectors are written. Finally, the final
solution vectors, OSASI and BETAO and the
objective value, OLOOB, is written. Each
solution phase is appropriately labeled.
KOPT = 2 Only the summary count variables for the matrix
rows M, and expanded columns NA, non-zero ele-
ments, NUMNZ, and actual matrix size, MATRIX,
are output. At optimization completion the
final objective value, OLDOB is output along
with the last phase number.
KOPT = 3 The summary counts as in KOPT = 2 are produced
and the intermediate objective values, OLDOB and
phase numbers, PHASE are written.
Final Output Solutions Reports
The user may request the punching of the column identification
numbers from final solution basis, BASIS. This request is indicated
by the variable PBASE on the main control record CONTRL. The solu-
tion identification numbers, stored in the CNA array, are punched in
a format acceptable for input as a starting basis on subsequent exe-
cutions.
The final management reports are written to file OUT which is
defined in the main program. There are three types of final reports:
(1) static execution report, (2) dynamic execution report by model
period, and (3) dynamic execution report by activity code. Each re-
port contains an output line for each equation in the matrix. The
line has identification data supplied by the user's input records,
and the final solution activity level information. New report pages
are started when a solution column activity code (ICODE = 1, 2, 3,
4,~-8) changes. Each new page has column headings indicating the
type of data being reported.
There are two new variables calculated for the static mode re-
ports: (1) total source waste tonnage TONSUM, (2) average system
cost, COSTON. These values are output on the first report page in a
65
-------
static mode. The static report has six possible output pages: (1)
source to ultimate pairs, (2) source to intermediate pairs, (3) in-
termediate to intermediate pairs, (4) intermediate to ultimate pairs,
(5) category five pairs, and (6) processing activity levels. Source
data reported are:
SOID source identification code
SONAME source name
DNAME destination site name
BETAO activity level
MPERID model period
Site data reported are:
ONAME site origin name
PRNAME site origin process name
DNAME site destination name
BETAO activity level
MPERID model period
Process data lines also report the process linear segment value
SPSEG. The category five pairs are reported, as for source or site
data, based on identification code.
The first dynamic report is essentially a static mode report re-
peated for each model period with the omission of SPSEG for processing
activities, and the addition of the capacity building activities and
the capacity underutilization activities. These report lines are
similar to the site data report line except capacity building has the
linear segment value SPSEG.
The second dynamic report has similar report lines to the first
report. As stated earlier the major difference between the reports
is the sort sequence of the final solution. Paging in this report
occurs by activity code rather than model period.
For a detailed explanation and example of the output reports
refer to the WRAP User's Guide.
66
-------
Chapter 4
SYSTEM SPECIFICATION
General
Purpose
WRAP is divided into eleven modules with a total of 98 subroutines
and a main control program. This chapter provides descriptive informa-
tion on each of the modules and their subroutines. The modules are
documented with overall flowcharts and brief narratives are given for
each routine. Appendix II contains individual subroutine summary
sheets to supplement this chapter and Appendix IV contains cross-
reference lists for each module.
Figure 14 illustrates the top level logic flow during a WRAP
execution.
References
In addition to the five appendices in this volume, programmers
should have access to all of the other volumes in the WRAP documenta-
tion (references 6, 7 and 8). Chapter 2, System Summary, should be
read before using this chapter, since a total view of WRAP is pre-
sented therein.
For information on individual routines, refer to Appendix II,
WRAP Subroutine Summary Sheets.
Main Control Procedures
There are nine routines included in the MAIN module, the principal
routine being the control routine, MAIN. The other routines are used
by several modules or are used by the MAIN only. There are four major
support routines and four minor routines. The major routines are
described separately and the other routines are grouped together or
discussed with a particular support routine. These routines are pre-
sented in this section following the MAIN presentation.
MAIN
The MAIN program calls all of the WRAP functions. Figure 14,
which illustrates the WRAP logic flow, is basically the logic flow of
MAIN.
Several data initializations occur in this routine:
67
-------
Initialize
Variables, Table
Pointers
Flags
, and
(EDIT!)
Read 'User Input
and Check for
Validity
Write Temp Files
(EDIT2)
Check User Input
for Consistency
by Reading Temp
Files
Data
alidlty Erro
Severe
Error
Affecting
Site/Process
Error
ffectlng Tra
nsportatio
File
Output User
Input Records
(LINKAGE)
Build L1nk«
Tables and
Check for
Completeness
Links
Missing and
No Crowfl
No
68
-------
(CROWFLY)
Yes
Execute
Crowfly Request-
ed Complete
Links
Output Corn-
outer Trans-
portation A
Act
Yes
( ABORT\
(COLUMN)
Create the Ma-
trix Column
Identification
Records
(MATRIX)
Build Matrix
Rows, Columns,
and Non-Zero
Coefficients
No
(BASIS)
Setup Initial
Starting Basis
Vector if Not in
User Input Records
No
Uutput Ma-
trix Vectors
on Printer
and Cardj
No
-=>fB
69
-------
Optimize the
Matrix by Lin-
ear Algorithm
Thru Phase.
Given by User
Feaslbl
Solution
Found
Yes
Output Final
Management
Reports
HALT
Normal
Figure 14, WRAP Top Level Execution Logic Flow
70
-------
(1) upper limits are set for maximum matrix rows,
MAXM, maximum matrix columns, MAXN, and maximum
number of non zero elements, MAXA;
(2) error flag, FLAG (used by the ERROR subroutine),
is set to 99;
(3) debugging switch, IDBUG, is set to 0;
(4) initial entry in basis vector, BASIS(l), is
set to 0;
(5) eight temporary files are assigned file numbers
and specifications;
(6) four input-output file variable names are set to
device numbers.
After the in-line data initialization, subroutine INITDA is called to
initialize the pointer table arrays which are assigned storage space
in labeled commons PNTR and SETREC.
The first functional module, EDIT!, 1s then called to read, write
to temporary files and edit the user-supplied Input records. If
execution does not terminate in EDIT1, because of input errors, con-
trol returns to MAIN. The input data consistence checks are performed
in the EDIT2 module. Upon completion of this module, the error flag,
FLAG, is tested for a severe error code; if a severe error was
detected then execution is terminated. Otherwise, the input
variables are written to the printer file JEF by the FRONTOUT module
by a call to subroutine APRPU with print control variable PRPU = 1.
The solid waste transportation activity network must be complete
before the matrix building module can be executed. Two routines, BUILD
and LNKCHK, are used in the LINKAGE module for checking completeness
of the network records. LNKCHK tallies the number of missing activity
links. If there are missing links and the user has not requested the
"crowfly" option (ICROW = 0), the WRAP execution will terminate. When
the user has requested "crowfly" option 1 (ICROW = 1) and the number
of missing activity links exceeds 10, the program will terminate.
Otherwise, execution continues by calling CROFLY to perform "crowfly"
computations when ICROW is greater than 0.
The completed transportation activity file is output by the FRONTOUT
module by calling APRPU with print option 2 (PRPU = 2). If the user
has requested execution termination after punching the transportation
file (PRCROW = 1), then WRAP terminates at this point.
The matrix column identification records are created in module
COLUMN. If no severe error is detected in COLUMN, control returns to
71
-------
MAIN where the MATRIX module is called through subroutine MATRIX.
Upon completion of the matrix building, the existence of a user-
supplied starting basis is checked. If a basis was not supplied and
the dynamic mode (MTYPE = 2) was indicated, then DSTRTB is called in
the BASIS module to generate an initial feasible basis. If the
execution mode is static (MTYPE =1), then SSTRTB is called.
Before calling the LINEAR module, the FRONTOUT module is entered
again to output the matrix arrays generated by MATRIX. This output is
optional and is only generated when PMODEL is greater than zero.
Execution may be terminated at this point by user request (PMODEL = 1).
The LINEAR module is entered by a call to subroutine SWAP. Upon
the successful completion of this module, the OUTPUT module is entered
by calling subroutine OUTBAS. This last module generates the final
WRAP solution management reports or output file OUT.
WRAP then terminates at the end of a completed execution.
ERROR
Subroutine ERROR outputs almost all of the error messages from
WRAP. Execution may be terminated in this routine. ERROR is called
by 24 routines from several modules; no other routines are called by
it.
ERROR is called when errors are detected in the user's input or
when a storage overflow is about to occur. Program execution may
terminate immediately for a very severe error or the error flag FLAG
may be set to a severity code which is tested by other routines.
Error messages are printed by this routine based on the error codes
passed by the calling routines. Major logic branching in ERROR is
controlled by the error codes passed from the calling routines. Con-
trol returns to the calling routine if the execution is not terminated
abnormally because of the error code.
For details on the error messages and actions refer to Chapter
6, the section on Error Messages and Actions.
FIND
This subroutine is used to find entries in tables. FIND is
called by 18 routines from all modules except LINEAR and MAIN. This
routine loops through a passed table, TABL, with dimensions ROWS x
COLMS and length NUM, looking at position POSIT for a particular value,
VALUE. If the VALUE is found in POSIT the pointer TPNTR is set to
the location index J and control returns to the calling routine.
Otherwise, TPNTR is returned as 0.
72
-------
LXSORT and LXCOMP
LXSORT and LXCOMP are special routines developed by Dr. D. E. Bell
to sort the muHi-dimensional tables in various entry positions.
The LXSORT routine is called by 14 routines and calls routine
LXCOMP. One common storage area, POUT is referenced by this routine.
File JEF is used to output the sorted table when the debugging switch
is on (IDBUG =1).
LXSORT sorts the rows of the array TABL lexicographically based
on fields IND(l) through IND(NUMB) where TABL, IND, and NUMB are
passed to the routine by the calling routine. The other arguments
passed are ROWS, COLMS, and LENGTH, the maximum dimensions of the
table TABL and the current length.
Subroutine LXCOMP is called by LXSORT to compare IND(LL) values
of TABL(JJ) as LL goes from 1 to NUMB. A control switch CF is set
to -1 if the TABL value is smaller, to 0 1f they are equal and to 1
if the TABL value is larger.
Upon completion of LXSORT, control returns to the calling routine.
READIT
The temporary storage files are read by READIT. This routine is
called by 27 routines. READIT references nine common storage areas,
eight files, and no other routines. READIT reads a file, NFILE, and
stores the information from record L in the common storage areas.
The arguments NFILE and L are passed to READIT by the calling routine.
Each read statement uses variable names from common storage areas so
the records are read and stored directly. Figure 15 presents the
files read and the commons referenced in READIT.
Other Routines
There are three other MAIN module routines. These routines are
assigned to this module because they are referenced by more than
one module and the modules are assigned to different overlays.
(1) DEFLT is a routine which stores a default value
in a variable and writes a message to the user on
file JEF. All variables are passed to DEFLT by the
calling routine.
(2) INITDA is the pointer table initialization routine
called by MAIN. Six temporary file pointer tables
are initialized to zero.
73
-------
1 | 2
(TITLRD) j (SRCCO) 1
3
, (SITECO)
4
, (PROCCO)
5
(TRANCO)
!Read FILE1
CODE,
TITLE
'Read FILE2
CODE,
SOURCE
Read FILE3,
CODE,
SITE
/Read FILE4
CODE,
\ PROCESS
Read FILE9
CNA ID
id FILE? /
(CODE,
>ITE/PROCESS\
i
'Read FILES
TRANS.
I
1
"•
9
(READ)
7
(SIPRCO) i
6
(TRKCO)
Read FILE6.,
CODE,
TRUCKS
Where arable numerals are value of NFILE
Figure 15. Files and Commons Referenced in REAOIT
-------
(3) SEGS is a linear segment number decoding routine
used for process identification records. SEGS is
called by CKSIPR in the EDIT2 module, and COLUMN in
the COLUMN module.
Functional Modules
The WRAP program is composed of one control module and ten
functional modules. Each of the functional modules is described in
this section.
The subroutines used in each module are referenced by name. These
names may be used to locate the subroutine summary sheets in Appendix
II. Each module description includes a flowchart. Appendix IV pro-
vides cross reference tables for each module and common storage
references for each subroutine.
EDIT1 - Input Read and Edit
The first functional module is EDIT1, which is also the name of
the module control subroutine. The primary purpose of this routine
is the reading of the user's input data. Each data group is read and
verified. Data verification is for the existence of data in all of
the input fields and the validity of the value supplied in each
input field.
Figure 16 illustrates the logic flow. Where applicable, sub-
routine names are enclosed in parentheses over the flowchart logic
boxes.
Subroutine EDIT1 is called by the main control program WRAP.
The routine calls a set of subroutines to read and check the user's
input data. All data used by this subroutine are in common storage
areas. There are ten subroutines called by EDIT1.
CONTRL subroutine is called first to read the user's control
and title records.T? an error is detected in the record identifica-
tion fields, program execution terminates abnormally with a call to
ERROR. A selected number of user inputs may be omitted. When these
values are omitted, default values are set by subroutine DEFLT.
Table 19 lists the control variables for which default values are
set. All other data entries on the first control record are checked
for existence and valid range; when an error is detected, an error
severity code is set in FLAG, the subroutine ERROR is called and an
appropriate message is generated. Program continuation is determined
by the severity code value. If the operating mode is dynamic, then
the second control record, CNTR2, is read and checked. Next, the job
75
-------
EDIT!
Initialize
Counter Varia-
bles and Stor-
age
(CONTRL)
/Read Input
''Control Based or
Mode
(ERROR)
Terminate
Program
Abnormally/
(CRWFLY)
< Input Crow-
fly Measure-
ment Data
(.SOURCE)
/Input Source
/ Data Cards;
Check and
\ Check and /
\Ed1t Data /
_ .[ (SITE)
/Input Site
/Data Cards;
\ Check and Edit
(ERROR)
Terminate
Program
Abnormally
No
\Data
(PROCESS)
/ Input Process
Data Cards andx
Groups;Check
\and Edit
(SIPRC)
/•-•"• -----v
/ Input Site \
/ Process Cards A
\ Check and EdiV
\Data /
Figure 16. EDIT! Module Logic Flow
76
-------
Yes
/Input TranspA
'ortatlon Activ-\
ity Data; Check )
' and Edit /
(TRANS)
User Sup
pplied Truck
Data
/Input Truck
/Constraint
\ Data Cards;
\Check and Edit
ser Sup-
plied Basis
Data
Input Start-
ing Basis;
Store Only
Return
to
Main
Circle
Figure 16. (Concluded)
77
-------
title record, TITLE, is read, with the only error check being the
identification code. The title is written to temporary file FILE!
Control then returns to EDIT!.
Table 19
DEFAULT VALUES FOR INPUT VARIABLES
Variable Name
NPERID
MTYPE
LPHASE
NFORC
KOPT
*INDSD
*IBASE
*PBASE
ICROW
PCROW
PMODEL
*ITRUCK
*JiJMP
PREXST
PRAVAL(l)
(when MTYPE = 1)
MYEAR(l)
(when MTYPE - 1)
NYEARS
(when MTYPE = 1)
Valid Value
1, 2, 3 or 4
1 or 2
1, 2, 3 or 4
1 or 2
1, 2 or 3
1 or 2
1 or 2
1 or 2
0, 1 or 2
0, 1 or 2
0, 1 or 2
1 or 2
1 or 2
1 or 2
2
>0
>0
Default Value
1
1
3
1
3
2
1
1
0
0
0
1
1
1
2
NYEARS
MYEAR(l)
78
-------
*These variables are reset to 0 and 1 by sub-
routine CNTCHK to make them compatible with
logic tests in the LINEAR module and other
routines.
If severe errors are detected in CONTRL, WRAP program execution
terminates after an error message 1s output by ERROR. Otherwise,
the input process continues.
CRWFLY reads the "crowfly" control record. This routine is only
executed when the user has coded the ICROW variable with a value
greater than 0. CRWFLY reads the single control record with three
"crowfly" values, RADIUS, FACTR, and SPEED. Each variable field is
checked for range validity. If the record identification field is
in error, then program execution terminates prior to the data validity
check. When there is an error in the crowfly data the ERROR subroutine
is called to set the seventy code and output appropriate messages;
in addition, the crowfly request switch ICROW is reset to 0, thereby
voiding the user's request for exercising the "crowfly" option.
This resetting may cause the program execution to terminate at a
later point.
When control is returned to EDIT1, a check is made to determine
if the crowfly request switch ICROW is zero and the number of user-
supplied transportation activities NTRANS is zero. If both variables
are zero, then execution is immediately aborted; otherwise, processing
of the input data continues.
SOURCE is called by EDIT1. SOURCE reads and checks the source
input records and aborts immediately if the record identification code
is incorrect or if the number of records read does not correspond to
the number of records specified by the user in control variable NSOURC.
Source data is stored in temporary file FILE2. The pointer table
TBSRC is filled with the source identification number, SOID, and a
record number pointer. For each data error detected an error message
is generated and the error severity flag is set accordingly. When the
user has indicated that the "crowfly" option will not be used (ICROW =
0), the source longitude, SOLONG, and latitude, SOLAT, are not checked
since they are not used in later computations. Before returning con-
trol to EDIT!, the source record pointer table TBSRC is sorted into
source number, SOID, sequence by subroutine LXSORT.
SITE reads the site identification records. Since all site
records are read together, the site counts NISITE and NOSITE are
summed to determine the total number of records to be input. The site
identification records are read and written to temporary file FILE3.
The identification code on each record is checked for validity before
79
-------
accepting the input record data. If there is a read error, the
execution terminates. The site type code, SICODE, is converted to
internal representation and the site identification number is stored
in pointer table TBSI along with the number of the record written to
FILES. The site information is then checked for range validity and
existence in the record. Any errors detected are output by ERROR.
The site validity errors are treated as non-severe in the SITE
routine. Prior to returning control to EDIT1, the site record
pointer table, TBSI, is sorted into site number, SIID, sequence by
subroutine LXSORT.
PROCES reads the process identification header records and the
other process records are read by subroutines LINKS and PRCOST* PROCES
reads the first two header records PRC1 and PRC2. Subroutine LINKS,
called by PROCES, reads the possible process link records LNKI and
LNKO and subroutine PRCOST reads the process cost records PRCOST. If
a read error is detected, the WRAP execution terminates in ERROR after
a message is written to the user. Each data field is checked for
validity with an error being generated if the Input is not valid or
does not exist. Default values are set for the process existence
code, PREXST, and the process availability codes, PRAVAL, If they are
not supplied in the input records. After the process link records
are read, checked by LINKS, and sorted by LXSORT, the process cost
records are read and checked by PRCOST. A process record with all
process information is written to temporary file FILE4. The process
identification number and record number is stored in pointer table
TBPR. When all process records have been read without a severe error
being detected, the process pointer table, TBPR, is sorted by process
identification number, PRID, by LXSORT. Control then returns to
EDIT!.
SIPRC is called from EDIT1 to read the site-process identification
records. As with all the input reading routines, execution terminates
if a read error occurs. Error warning messages are written for data
errors determined during the input validity checks. SIPRC creates
a process usability array, PRUSBL, for each site-process record.
Information for this array is obtained from a process record retrieved
by READIT after the process number, SPIDP, on the site-process record
has been located in TRPR by subroutine FIND. The site-process record
is then written to temporary file FILE? and the two identification
codes, SPIDS and SPIDP, are stored in the pointer table TBSIPR along
with the record number. When all site-process records have been
read, the pointer table is sorted into site sequence and process
sequence within site by LXSORT.
TRANS is called only if CONTRL variable NTRANS >0. If the
input sequence includes a transportation activity file, it is read
80
-------
by subroutine TRANS which reads and checks the validity of the input
records. TRANS aborts immediately if the record identification code
is incorrect. After the input record is read, it is written to
file FILES and the pointer table TBTRAN is set with the following
variables:
ACODE - activity code
AOID - activity origin identification number
AOPR - activity origin process identification number
ADID - activity destination identification number
MM - record number
If errors are determined during the record validity check, error
messages are written by ERROR and the error severity flag, FLAG, is
set. When all input records are read and written, the pointer table
TBTRAN is sorted by LXSORT into sort sequence AOID, AOPR and ADID.
Control then returns to EDIT!.
TRUCK and TBASIS are the next two routines called in the EDIT!
module. These are optional subroutines. Their execution is
determined by variables ITRUCK and IBASE, supplied by the user on
the CONTRL input record.
If ITRUCK = 2 and the number of truck constraint records,
NISTRK, is greater than zero then TRUCK is called to read and check
the truck constraint input records. The records are written in tem-
porary file FILE6. Execution aborts if the input record identifica-
tion is invalid or if a read error is detected. Otherwise, warning
messages and flags are generated for the data validity checks.
The last routine called in the EDIT1 module is the routine
which reads the user-supplied starting basis. This routine, TBASIS,
is only called when IBASE - 2, which indicates the basis is available.
TBASIS reads input records until a 0 field is encountered. The values
read are stored in the basis vector BASIS. No check is made to be
sure that the correct number of entries have been read, which may
cause a severe error in the LINEAR module if the number of values is
not equal to the number of rows (equations) in the matrix.
Upon completion of these routines, EDIT! returns control to MAIN.
81
-------
EDIT2 - Input Consistency and Validity Checking
The second editing module, EDIT2, checks the user supplied data
for consistency. The consistency checks are made within an input
group and across various groups. For each error or inconsistency
detected a message is output for the user. Some errors are severe
enough to cause termination of the program at the time of detection,
other errors are warnings at the time of detection.
All input groups are tested by the second edit. If the errors
detected are such that would impair the execution of the remaining
modules the severe error flag, FLAG, is set so that the execution
terminates at the end of EDIT2 or before the execution of a routine
in EDIT2 which would not be successful. If a very severe error,
FLAG = 2, was found in EDIT1 or in subroutine ONENUM, execution is
terminated before execution of SIPRC, the routine which checks the
site-process records. If type two, FLAG » 2, errors are found in
EDIT2, then execution is terminated before the transportation activ-
ity file check in subroutine TRNCHK.
The following routines are called by EDIT2: (1) ONENUM, which
checks for duplicate identification codes for source, site and pro-
cess records; (2) CNTCHK which resets the yes - no variables from
the input CONTRL record and checks the consistency of MYEAR sum and
NYEARS; (3) CKSIPR which cross checks the information on site-
process records with site and process records; (4) PRCHK which checks
the consistency and completeness of possible links in a process
record set; (5) TRNCHK which checks the consistency and validity
of data on a transportation activity record.
Figure 17 illustrates the EDIT2 module logic flow.
ONENDM checks for duplicate source, site and process records.
Error flag, FLAG, is set to 2 if a duplication error is found. The
duplication checks are made using the record pointer tables TBSRC,
TBSI, and TBPR.
CNTCHK resets the "yes - no" values read on record CONTRL. The
following variables are input as one or two on the CONTRL record
but are converted to zero and one for internal computations:
(1) INDSD, steepest descent indicator, (2) IBASE, initial basis input
indicator, (3) PBASE, punch final basis indicator, (4) ITRUCK, truck
constraint input indicator, and (5) JUMP, jump to LINEAR module
indicator (this variable is not used currently). The variable array
MYEAR is checked against the total modeling period in NYEARS. If
the execution is static, these values must be identical; otherwise,
82
-------
(EDIT2)
Initialize
Variables
and Error
Flag
(ONENUM)
Check for
Duplicate, Source,
Site, and Process
Records
No
(CNTCHK)
Reset Control
Variables, Check
for Years
Consistent
No
(CKSIPR)
Cross Check
Site/Process
Against
Site
and Process
Records
(PRCH
Check Process
Records
for
Possible-Link
Data
No
Yes
(TRNCHK)
Check TRANS
File for
Consistency
and Good ID's
Figure 17. EDITZ Module Logic Flow
83
-------
the sum of MYEAR for each modeling period must be equal to NYEAR. If
there is an error, the MYEAR sum is stored in NYEARS.
CKSIPR checks the site-process records. The records are checked
to be sure there is a site record and a process record for each site-
process record. Then the process type, SPLEVL, and linear segment
number, SPSEG, are checked to be sure that a process cost is avail-
able for each segment in each modeling period. If either a site
record or a process record is not found, then the error flag, FLAG,
is set to severe error code two which will cause WRAP to terminate.
PRCHK checks the process record for linking consistency by pro-
cess identification codes. The processes are checked for Input and
output links, as well as validity of linking between process levels.
Process records are retrieved from FILE4 by pointer table TBPRC
indices. If process linking error 1s detected, the error severity code
is set to two for EDIT2 termination. A special check 1s also made to
be sure that at least one process allows waste input from sources.
Refer to the User's Guide for detailed discussion on process linking7.
TRNCHK is the last EDIT2 module routine. TRNCHK checks the
consistency and validity of the input transportation activity file.
Records are checked for duplication by subroutine DUP. Then each
record is checked to make sure that a source and/or site-process
record exists in those files. The next check is to determine if the
origin-destination link is possible, based on the process file with
the links possible tables for each process.
If a severe error is detected, the user-supplied transportation
activity file 1s dumped to file JEF and execution terminates.
LINKAGE - Network Completion Checking
WRAP requires that the transportation activities include at least
one link for every original source and one or two links for every site-
process. The number of links for a site-process is determined by the
amount of output generated at a site-process. If there is no output
waste generated, then no output link is required.
In order that the checking may be performed, two tables are
constructed in subroutine. BUILD. The tables are the origin location
table, ORIG, and a destination table, DEST. These tables are composed
of the identification code numbers for each source, SOID, site-process,
SPIDS and SPIDP, and site, SI ID, as they are taken from the pointer
84
-------
tables TBSRC, TBSIPR, and TBSI. Table lengths are stored in ORIGL
and DESTL.
The transportation activity file is checked against the linkage
tables in subroutine LNKCHK. When a match is made a match flag is
set in the ORIG or DEST array. At the end of the checking, the
missed origins are counted. Missed destinations are also counted
but do not get tabled as missing. If the miss counter, MISS, is
greater than zero, then the program may terminate abnormally if the
user has not requested execution of a "crowfly" option.
Both subroutines, BUILD and LNKCHK, use subroutine FIND to
locate the user's input information in the record pointer tables.
Figure 18 illustrates the logic flow for the LINKAGE module.
CROWFLY - Network Completion by Crowfly
The CROWFLY module is executed at request of the user. Vari-
able ICROW, on input record CONTRL, must have a value greater than
0 to request this module. There are eight subroutines in the module:
(1) CROFLY, the module controlling routine; (2) CADIST, which calcu-
lates distance between two locations; (3) CONV, a function which
converts geographical coordinates; (4) CRWLNK, which creates all
possible links for ICROW1 and ICROW2; (5) DUPWRT, which ch ks each
new transportation activity record for duplication in the existing
file; (6) ICROW1, which performs "crowfly" option 1 network comple-
tion; (7) ICROW2, which performs "crowfly" option 2 network completion;
and (8) LNKBLD, which creates missing links for ICROW1. Figure 19
illustrates the CROWFLY logic.
The two "crowfly" options complete the transportation activity
file. The first, "crowfly" option 1, calculates the missing travel
time for a user-supplied transportation activity and generates the
shortest link activity for up to ten missing links. The second,
"crowfly" option 2, generates transportation activity links and
travel time for all possible links meeting the maximum radius
criteria.
ICROW! is used for "crowfly" option 1. ICROW1 generates one-
way travel time for a user-supplied transportation activity using
travel distance and speed. The travel distance is calculated by sub-
routine CADIST if the input data does not supply it. The distance
calculation uses the geographical coordinates provided in the source
85
-------
Create Origin
Table Using
NSOURC Entries
From TBSRC
(BUILD)
Add to Origin
Table from
TBSIPR if the
Process at a Site
Has Output Waste
(BUILD)
Create Destina-
tion Table
from TBSI
Pointer Table
(LNKCHK)
Test Activity
Records Using
TBTRAN Table to
Find Match
In Origin Table
and Destination
Table
A
Count Missing
Origin or
Destination
Increment
Index, Recycle
to Finish
Table
Figure 18. LINKAGE Module Logic Flow
86
-------
(CROFLY)
Yes
Yes
ICROW!
Crowfly
Option!.
[CROW2
Crowfly
Option2,
N
Figure 19. CROWFLY Module Logic Flow
87
-------
Retrieve 'TRANS'
Record from
FILES Using
TBTRAN
Travel
Distance
Missing
Return
to CROFLY
to Return
to MAIN
(CADIST)
Locate Origin
and Destination
Coordinates.
Calculate Travel
Distance
Calculate Travel
Time and Store
Time and Distance
in Record
Search Origin
Table and Dest
Table for Miss-
ing Links
(CRWLNK)
Generate Link
with Shortest
Travel Distance.
Create New Record
Increment Record
r.nunt
Reduce Miss
Count
88
-------
(CRWLNK)
Create all
Possible
Links
for All Source
Codes
(DUPV
Check New Links
Against Links
Provided 1n
"TRANS" Input
(DUPWRT)
Write, New
'"TRANS'" Record
for Non-Duplicates,
Increase Counter
NTRANS
(CRWLNK)
Create all
Possible Links
for All Site-
Process Records
in Input File
(DUPWRT)
Check New Site-
Process Links
for Duplications
(DUPWRT)
Write New TRANS
Records for
Non-Duplicates
Change NTRANS
Counter
Return
to
CROFLY
Return toy
Figure 19. CROWFLY Module Logic Flow
89
-------
and site data groups and converted by CONV. If a particular
activity does not have a travel speed, ASPEED, then the general
travel speed value, SPEED, supplied for crowfly options is used.
When missing links (all possible links between an origin and
the available destinations) are generated for crowfly-one by LNKBLD
and CRWLNK, only the shortest link for a particular transportation
origin is taken from the missing links table and added to the trans-
portation activity file. If more than ten links are missing, the
program terminates abnormally.
ICROW2 is called for "crowfly" option 2. It generates all
possible transportation activities for every source and site-process.
If the user has supplied any transportation activities, these are
checked in DUPWRT to assure no duplicate activities in the final
file. The user supplied activities already in the file must contain
all the required input data (ACODE, AOID, AOPR, ADID, ATIME, ADISI
and ASPEED). The transportation activities generated by the program
have a travel distance, ADISI, less than or equal to the maximum
radius value, RADIUS, supplied as crowfly input data. If no link for
a particular origin meets the radius criteria, then the shortest link
possible is made for the origin and accepted even though the distance
is greater than the maximum radius.
It should be noted that links are only made to a site if the
available processes at a site will allow the transportation of waste
from the origin. The possible linkages are determined by the user's
information for each process as stored in the LINKI and LINKO tables.
FRONTOUT - Output Reports and Punched Files
The output reports for user-supplied inputs are written and
punched in the FRONTOUT module. This module also produces a matrix
output when requested by the control input on record CONTRL. There
are 4 subroutines included in the module: (1) the controlling rou-
tine, APRPU; (2) the input records reporting routine, PRINT;
(3) the transportation activity records reporting routing, PUNCHT;
and (4) the optional matrix vectors reporting routine, PUNCHM.
Figure 20 illustrates FRONTOUT logic flow.
APRPU calls one routine each time it is executed. The sub-
routine argument PRPU determines which routine is called:
when PRPU = 1, PRINT is called,
90
-------
PRPU
(PRINT)
Output User
Input Records
Output Input Records
Output TRANS Records
Punch, All
'TRANS'
Records
PRPU
- 2
(PUNCHT)
Write to
Printer all
'TRANS'
ords
91
-------
Output Matrix Vectors
PRPU •
3
(PUNCHM),
Punch Matrix
Output Cards
Output to
Printer
Matrix Vectors
Figure 20. FRONTOUT Module Logic Flow
92
-------
when PRPU = 2, PUNCH! is called, and
when PRPU = 3, PUNCHM is called.
PRINT formats the user-supplied input records for a formatted
output report. The first page of the report contains the control
variables from records CONTRL, CNTR2, CRWFLY and TITLE. The second
report page has SOURCE records. The next report pages have records
from the SITE, PROCESS and SIPRC input groups. All report pages
and record fields are labeled in a page heading line. Subroutine
READIT and the pointer tables stored in PNTR common are used to
retrieve the input records from their temporary storage files.
PUNCHT prints and/or punches the transportation activity records
after the records have been checked for completeness. In addition
to producing a written report, PUNCHT also generates a punched trans-
portation activity file when requested by the user control input
variable PCROW on input record CONTRL. PCROW, which is stored in the
FRONT common area, is tested for a value greater than zero to deter-
mine if the activity file is to be punched. The file is punched in
a format suitable to be read by another execution of WRAP. Subroutine
READIT and pointer table TBTRAN, sorted into activity code and
identification code sequence by LXSORT, are used to retrieve the
activity records stored in temporary file FILES. Each report page
generated has a label and field heading line.
PUNCHM is the last subroutine in the FRONTOUT module. PUNCHM pro-
duces a written report and a punched output deck of the matrix vectors
generated in the MATRIX module. If the user input variable PMODEL,
currently stored in FRONT common, is zero, then no output is generated
by PUNCHM. Otherwise the values output are the matrix count variables
and the vectors VC, FC, A, ROW and COL. When PMODEL - 2 the matrix
vectors are only punched; they are not written in a report since the
PMODEL code indicates that WRAP execution 1s to continue and the
matrix vectors will be output in the LINEAR module.
Appendix I contains the format specifications for records
punched and written by PUNCHM.
COLUMN - Construction of Matrix Column Identification Records
This module constructs the matrix column identification records,
stored on FILE9, and the associated pointer table, TBMATC. The file
and table are used to generate the matrix rows, the matrix
coefficients, and the final WRAP solutions report.
COLUMN is the module control routine. There are seven other sub-
routines unique to this module: (1) CPFAC, (2) CSTCRD, (3) KCOST,
(4) PCOST, (5) SCOST, (6) TCOST, and (7) TRFAC. These eight routines
93
-------
compose the costing sub-modu'ie of the column identification record
creation process. The COLUMN subroutine also calls five other routines,
ERROR, LXSORT, FIND, READIT, and SEGS, which are located in the main
control module. Figure 21 illustrates the logic flow for the COLUMN
module.
Structuring the model into the necessary matrix format requires a
predictable reference table. The column identification record generated
in the COLUMN module provides this predictable reference table as well
as the matrix column identification labels and data. A column identi-
fication record generated for each column in the problem matrix con-
tains data from each of the user-supplied input data groups.
In the static execution mode the first columns are created for
each transportation activity. These columns are created in a specified
sort sequence by activity code ACODE. The corresponding identification
records have all data necessary for adequate identification of the
activity, origin, process and destination. The next set of columns
are the process column with one column for each linear segment of a
particular process at a site. The process column- identification
records contain information similar to the transportation activity
column records.
In the dynamic execution mode, the columns and column identifica-
tion records are created in a similar manner except the columns are
generated by modeling period. The process columns are not differentia-
ted by linear segment in the dynamic mode. After the transportation
and process columns are created for all modeling periods, additional
columns are created. The next set of columns are for the capacity
building activities. There is one column for each site, process,
model period and linear segment in which the process is available.
The next set of columns are for process underutilization at a site
during each modeling period.
Every column that is created has a column identification record
generated and written to temporary file FILE5 and a pointer entry
made in TBMATC. The pointer table for the column identification
records, TBMATC, contains the column number, CNA, column type code,
CTYPE, origin number, SOID or SPIDS, process number, SOID or SPIDP,
destination number. SIID, model period, MPERID, and file record
number, REC.
The fixed and variable costs, FCCNA and VCCNA, associated with
each column activity are calculated and stored in the column identi-
fication record. The costing algorithms are dependent op the
program execution mode and the column activity code. The input data
necessary for the computations are retrieved from the various input
data groups while the identification record is being structured.
94
-------
SORT TRANS File
and Initialize
Internal Counters
Calculate Trans-
portation Cost
Factor for Model
Retrieve Trans
Record, Locate
Origin and Site
Process Records
for Activity
(TRFAC)
Locate Process
Record for
Activity Store All
Retrieved Data in
New Column Record
Check for
Existence of
Site Process
During Period
and Waste Tons
Mode \ No
Static
Waste
Existence
Okay
Transportation
Write New
Column ID
Record
Fill In Rec-
ord Pointer
Table TBMATC
Cnd of
Trans
Record
95
-------
Site-Process Records
Create Columns
Locate Site
Process Records,
Site Recprds and
Process Records
(PCOST)
IS
Process \ Ye;
Useable Period
Create One
Record for
Each Process
Segment
(CSTCRD. PCOST)
Calculate
Process Costs
for Each Column
/ Create
/ Column lder\-\
tlficatlon
\ Record
V
Fill In Record
PTR Table,
Increment Counters
All
Site-Process
ecords Use
No
Calculate
COSP
for Process
Columns
/ Write\
/Dynamic Col. \
I Identified- j
\^1on RecordJ
Set Up Entries in
Pointer Table
Increment Counters
\l
96
-------
No
Set Column Code
to 7 Column
Type to 3
Create a Capacity
Bldg Column for
Each Availability
Process in Each
Period
Write Column
Records for
Each Process
Aval, in Perioc
Create Unused
Columns for each
Available Process
in Each Period
Set Column
Code to 8
Sot Column
Type to 4
/Treate Column \
Record for Each!
Available Proc-l
Update Pointer
Tables, Update
Counter, Count
Total Columns
Figure 21. COLUMN Module Logic Flow
97
-------
The cost values are later retrieved and stored in cost vectors, FC
and VC, in the matrix building function.
There are six subroutines used to calculate the fixed and
variable costs associated with each column in the matrix. These sub-
routines are:
TCOST - calculates costs for a transportation activity
PCOST - calculates costs for a linear segment of a particular
site/process
KCOST - calculates costs for a full capacity operation
SCOST - calculates costs for an underutilized operation
TRFAC - calculates the transportation factor for a modeling
period
CPFAC - calculates the capitalization factor for a modeling
period during which a particular site/process exists
Subroutines TCOST, PCOST and TRFAC are used for both static and
dynamic cases.
If the number of column records generated exceeds the maximum,
MAXN, execution aborts after an error message from subroutine ERROR.
TCOST returns the fixed, FC and variable, VC, costs for a
transportation activity. The fixed cost is always zero.
The variable cost calculation depends on the travel time for the
transportation activity, the origin of the activity, the haul cost of
the origin, the standard turn around time at a site, and the
transportation factor for a particular modeling period. For dis-
cussion of this transportation factor, refer to TRFAC.
If the transportation travel time, ATIME, 1s less than zero,
then the variable cost is set to zero. Otherwise the value in ATIME
is used in the variable cost equation.
The origin identification code determines which variable cost
equation is to be used. If the origin identification code, IDI, is
less than 500 then the variable cost value, VC, is calculated using
the source haul cost, SOHC$, for the given modeling period, T, the
round-trip travel time, 2*ATIME, and the transportation factor, TF,
for the given modeling period, T. If the origin identification code,
IDI, is greater than 500, then the variable cost, VC, is calculated
using the process haul cost, PRHC$, the round-trip travel time,
98
-------
the standard turn around time, STURNT, and the transportation factor,
TF, all for a given modeling period T, The transportation cost
equations are:
VC = SOHC$(T)*(2.*ATIME)*TF(T)
or VC = PRHC$(T)*(2.*ATIME+STURNT)*TF(T).
After the costs are calculated, control returns to the calling pro-
cedure. There are no error messages or flags set.
PCQST subroutine returns the fixed, FC, and variable, VC, costs
for a sTte-process. A dynamic case has both costs set to zero.
A static case uses the capital slope, PRCSLP, the operating
slope, PROSLP, and the revenue per input ton, SPREV$, for the variable
cost. The fixed cost is calculated using the capital intercept,
PRCINT, the operating intercept, PROINT, and the site preparation
cost, SICOST. The equations are:
VC = PRCSLP(IPNT)+PROSLP(IPNT)-SPREV$(IPNT)
FC = PRCINT(IPNT)+PROINT(IPNT)+SICOST.
The process cost segments used in the static case are
determined by the subroutine argument IPNT. The value in IPNT is a
linear segment number of the particular site-process.
No error flags are set by this subroutine.
KCOST is used in a dynamic case only. It calculates the fixed,
FC, and variable, VC, costs for operating a process at a site at full
capacity for all modeling periods that the site is in existence.
The variable cost and the fixed cost are each composed of two
sums. The summation index, T, runs from the process starting period
to the last period of its existence. The data required to perform
the calculations are the capitalization factor, CF, which is calcu-
lated by subroutine CPFAC, the life of the process, PRLIFE, the
capital slope, PRCSLP, the operating slope, PROSLP, the capital
intercept, PRCINT, the operating intercept, PROINT, the site prepa-
ration cost, SICOST, the transportation factor, TF, and the site-
process revenue, SPREV$. The equations are summed for IPER = T to
IEND, where IEND is the last period that the process will exist. The
cost equations are:
99
-------
VC = IPRCSLP(IPNT)*CF(IPER)+
£(PROSLP(IPNT)-SPREV$(IPER))*TF(IPER)
FC • £(PRCINT(IPNT)+SICOST)*CF(IPER)+
£(PROINT(IPNT)*TF(IPER))
SCOST returns the fixed and variable cost for running a site-
process at less than full capacity during a particular modeling period.
The fixed cost, FC, is always zero. The variable cost is calucated as:
VC = (-PROSLP(I) + SPREV$(t)) x TF(t)
where I is the cost set linear segment
t is the modeling period
TF is the transportation factor calculated by TRFAC
SPREV$ is the revenue per input ton
PROSLP is the process operating slope.
TRFAC returns a transportation factor, TF, for each modeling period.
In the static case TF = 1. A dynamic case required TF to be calculated
from the sum of the products of the inflation rates, CINFLR, and the
discount rate, CDISCR raised to the power of the model year, m, for
each year in the period.
CPFAC returns a capitalization factor for each model period that
a process exists. The capital committment year 1s calculated and stored
in KFIX. The capitalization factor for each period is then computed and
stored in array CF. For a detailed description of these calculations
refer to the WRAP User's Guide.'
*
MATRIX - Construction of Matrix Vectors
Once the column identification records and the pointer tables
have been successfully created, the matrix vectors are generated in
the MATRIX module. The matrix building routines are usable 1n both
static and dynamic execution modes. The principal logic control is
handled within each equation type by a separate subroutine. There
are nine such routines: (1) SORBAL, (2) IUSPC, (3) IUSIB, (4) ISPOB,
(5) IUSTC, (6) CAPBAL, (7) LANCON, (8) ED, and (9) ZCOLMN.
Each of the first eight routines works in approximately the same
way. The column identification pointer table, TBMATC, 1s sorted and
each entry is examined one by one. If the origin or site identification
number and the column type code match the criteria for the equation
being built, it is selected for a matrix entry. If the current
identification code matches the identification code of the last entry
processed, the entry is made in the current matrix row. If they do nc>t
match, a new row is initialized before the entry is made. This cycle
is repeated for each entry in TBMATC.
100
-------
Once all of the equations are generated, the fixed cost, FC, aid
variable cost, VC, vectors are built by retrieving the column records
and storing the precalculated cost values FCCNA and VCCNA. These
vectors are generated in subroutine COST.
A special row is then added to the matrix by subroutine ED.
This row assures proper matrix equation balance for the land con-
strained sites.
The final part of the matrix building is the generation of the
special 'Z' column 1n subroutine ZCOLMN. This column is primarily
added to the matrix to be used for substitution in the testing for a
feasible starting basis in the LINEAR module when necessary. The co-
efficients for this special column are built into the program. Fixed
and variable cost entries are also made 1n the cost vectors, FC and
VC. The coefficients for this special column are built into the
program. These values (costs and coefficients) are the same for
both static and dynamic execution modes. Figure 22 illustrates
logic flow for the MATRIX module.
MATRIX is the control program that maintains overhead book-
keeping and calls the subroutines to construct the matrix.
MATRIX begins by initializing all counters to zero, and then
sorts the TBMATC table by period, site, process and destination. A
loop is then entered that calls SORBAL, IUSPC, ISPOB and IUSTC in
order. The loop is repeated once for each model period. Within the
loop, before ISPOB and IUSTC are called, M, the row pointer is saved
and then incremented by the number of intermediate and ultimate sites
that exist during the model period for which the loop is being
executed. This allows the later insertion of the intermediate and
ultimate site input balance equation, while maintaining the standard
equation order.
After this loop is finished, TBMATC is sorted by period and
destination. The current value of M is saved and another loop is
entered. Again the loop is executed once for each model period. In
the loop, M is set to the value saved in the previous loop for each
period and IUSTB is called to construct the input balance equations
for the model period for which the loop is being executed. At the
end of the loop, M is restored to the value it had before the loop
was entered.
If this is a dynamic run TBMATC is sorted by site, process,
period and activity call and then CAPBAL and LANCON are called. The
costing vectors are then constructed by the COST subroutine. In a
static case, only COST is called.
The last routine called is ZCOLMN which creates a dummy column to
be inserted into the initial basis if there are negative activity
levels generated during the first phase execution in the LINEAR module.
101
-------
NR = MAXN
RNALDN = 9
NUMNZ = 0
D = 9
"(IxtoRT)
Sort by
Period, Site,'
Process and
Destination
PERIOD «
1
(SORBAL)
Construct
Source
Balance
i
Construct
I&U Site
PROL Constra-,
1nts
[IUSPC)
Save Row Poin-
ter. Skip spa-
ce for Input
Balance Equs.
(ISPOB)
Construct
Intermediate
S/P Output
Balance
(IUSTC)
'Truck
Constraints
Equations
Figure 22. MATRIX Module
Logic Flow
LXSORT)
Sort by
Period, Dest-'
1 nation
102
-------
G>
Period = 1
Save Row
Counter
Set Row Counter
to Sklped Rows
for Period
M « Save (Period)
Reset Row
Counter to
Last Used
Row
V
Capacity
Balance
Constraints
Set up
Costing
Vectors
F'C and VC
(IUSIB)
(ED)
/ Make Dummy
/ Land Constraint^
\ Equation
Yes (LXSORT)
Sort by \
Site, Process, \
Period, Acode /
/
(CAPBAL)
(LANCON)
(COST)
^ (ZCOLUMN)
Create
Dummy
Column
/ RetunA
to
MAIN
103
-------
SORBAL generates the source balance equations. The variable M,
the running count of rows, is initialized to 0, along with NUMNZ, the
number of non-zero matrix entries. The table TBMATC is sorted according
to period, source, process and destination. This completes the
initialization.
The elements of TBMATC are examined in order. If the first
identification code in TBMATC is greater than 499, then it is not a
source, and the program proceeds to construct the SITE/PROCESS CON-
STRAINT EQUATIONS. If it is a source origin, then it is compared to
the previous origin identification code processed. If they do not
match, then the SETR subroutine is called to initialize a new row of
the matrix and make entries in the row identification vector, RNA,
type and right-hand side vectors, INDIC and B. Then processing
resumes as if the origin identification codes had been identical. The
SETC subroutine is called to enter a 1 into the proper row and column
of the matrix. The row is equal to M and the column is equal to
the number of the record of the column identification file corres-
ponding to this TBMATC entry being processed; this number is stored
in the column vector CNA.
The routine steps through TBMATC in this manner until all
sources have been exhausted for a model period. When this happens,
control returns to MATRIX to call the routine to build constraint
equations.
IUSPC starts stepping through the TBMATC table where the SORBAL
routine stopped. If an element of the table does not have a column
activity code of 6, the next table entry is fetched immediately.
If the site ID is not equal to the previous site ID processed, SETR is
called to initialize a new row. Now, if the site ID<700 (an inter-
mediate site) or if processing a dynamic case then either
(1) SICODE = 0, in which case this table entry is ignored and
the next entry is fetched, or
(2) SICODE = 1, in which case the coefflcient.COEF is calcu-
lated as 1000/SPCAP, where SPCAP is read from the CNA
file and inserted into the appropriate row and column
of the matrix.
If the site ID >700 (ultimate site) then either
(1) SICODE = 0, in which case the coefficient COEF is
calculated as 1000/((.605*SILAND)/NYEARS) or
(2) SICODE = 1, in which case the coefficient COEF is
calculated as 1000/MIN I SPCAP I
I .605*SILAND/NYEARSl
and inserted into the appropriate row and column
by calling SETC.
104
-------
This process is repeated for each TBMATC entry for the model
period. When all entries for a model period have been processed,
control returns to MATRIX to begin construction of the site-process
output balance equations.
ISPQB generates the INTERMEDIATE SITE-PROCESS OUTPUT BALANCE
EQUATIONS. For the sake of programming efficiency, this set of
equations and the TRUCK CONSTRAINT equations are built out of order,
but the order in which equations appear in the matrix has been pre-
served. This has been done by computing the number of intermediate
and ultimate sites existing during a model period, and adding it to
M, the row counter. This reserves space for the intermediate and
ultimate site input balance equations when they are finally built
in subroutine IUSIB.
After space is reserved ISPOB steps through the TBMATC table
entry by entry. If the site ID< 500 or ACODE = 7 or 8 for a table
entry, it is ignored and the next entry is fetched immediately.
This also happens if the coefficient bp = 0, where bp = PRWGT/100,
where PRWGT is the percentage of waste remaining after processing.
If the site ID and the process ID are not equal to the site ID and
process ID of the entry just processed, then SETR is called to
initialize another row of the matrix. If ACODE = 6, then -bp is
calculated as the coefficient and inserted into the matrix by SETC.
If ACODE is 3, 4 or 5, a +1 coefficient is inserted into the matrix
by SETC.
All table entries for the period are processed in this manner.
When they have all been done, control passes to the truck constraint
routine
lUSTC differs from the other matrix routines in that it is
driven not by the TBMATC table but by the truck constraint file. A
record of the truck constraint file, FILE6, containing one, two or three
site IDs is read. These identification codes are compared to the site
ID and destination ID of each entry in the TBMATC table. If there is
any match between any one of the site IDs from the file and either the
site ID or destination ID of the table entry, a coefficient is in-
serted into the matrix. If the table entry for ACODE = 1 or 2, then
the coefficient used is EPA, where EPA = 1/TRPACK, where TRPACK is
the capacity of a packer truck. If the table entry has ACODE = 3 or
4, then the coefficient used is EJR, where ETR = 1/TRTRAN, and TRTRAN
is the capacity of a transfer truck. If ACODE = 5, no coefficient
is generated.
Each table entry is checked against each entry in the truck
constraint file. When all comparisons are complete, control returns
to MATRIX to call the routine for the intermediate and ultimate input
balance equations.
105
-------
IUSIB generates the INTERMEDIATE and ULTIMATE INPUT BALANCE
EQUATIONS. For program efficiency the construction of these equations
has been delayed. When the previous four sets of equations have_been
constructed for each of the model periods needed, the IUSIB routine
will start to build the input balance equations. If all periods
have not been processed, then we loop back to the SORBAL routine to
start the construction of the equations for the next period.
Now when all periods are done, the TBMATC table is sorted by
period and destination. M, the row counter, is set to point to the
last row used before the rows reserved for use by the input balance
equation of a given period. The elements of TBMATC are examined one
by one. Elements with an ACODE = 1, 2, 7 or 8 are ignored. If the
site ID equals the previous ID, SETR initializes a new row of the
matrix. If the ACODE = 6, a -1 coefficient is inserted in the matrix.
If the ACODE ^ 6, but the destination ID is< 700 or the site ID<500,
a +1 coefficient is inserted in the matrix. If the ACODE / 6, but
the ID is >700, the coefficient Cp is inserted into the matrix,
where Cp = 750/PRDEN, where PRDEN is the waste output density from
a process.
This process is repeated for each entry of the TBMATC table.
When a period is done, M is set to point to the vacant rows for the
next period. Though both intermediate and ultimate sites are done
by this routine, like equations will still be grouped together be-
cause of the sorting of the TBMATC table by destination ID. When all
periods have been done, control returns to MATRIX to call the routine
to build the capacity balancer equations.
CAPBAL generates the SITE PROCESS CAPACITY BALANCE EQUATIONS
after the row pointer M is reset to point to the last matrix row
constructed. The static matrix is now complete and control passes to
the costing function. If, however, the run type is dynamic, TBMATC
is sorted by site, process and column activity type code. The entries
in the TBMATC are examined in order. If the site ID is 500 or
ACODE = 1, 2, 3, 4 or 5 for an entry, the entry is ignored and
another is fetched.
If ACODE = 6, 7 or 8 (for slack columns, S, and capacity columns,
K, respectively), the site and process ID numbers are compared to
the site and process number of the previous entry examined. If they
do not match, SETR is called to initialize a new row. Now if
ACODE = 7, then SETC is called to insert a -1 coefficient into the
matrix. Otherwise, for ACODE = 8, a +1 coefficient is inserted into
the table.
This process is repeated for the entire table. When the table
is done, control returns to matrix to call the routine to build the land
constraint equations.
106
-------
LANCON constructs the land constraint equations in a straight-
forward manner. Only for those entries in the table for which
ACODE = 6 and the site ID >700 (ultimate sites) is an entry made in
the matrix. A new column is initialized if the site ID of the current
entry does not match the site ID of the previous entry. SETC is used
to insert coefficient dt into the proper column of the matrix where
dt = MYEARS (NPERID)/.605. This process is done for the entire table.
When finished, control returns to MATRIX to call the subroutine to
build the costing vectors.
COST builds the two costing vectors, FC and VC. Both the variable
and fixed cost for each column were calculated when the column
identification record was constructed. Thus, to set up the FC and VC
vectors, each column identification record is read in order and the
costing information assigned to the appropriate entry in the FC and
VC vectors.
When done, control returns to call the dummy column routine
ZCOLMN.
ZCOLMN is the last routine called in the matrix building module.
It is used for both static and dynamic cases. A special matrix column,
referred to as 'Z'.is created.
The last column value N is saved in variable NORIG and labeled
common SBASI. The column counter N is incremented. The new N value is
stored in the column identification vector, CNA, in entry N. The Nth
entry in the variable cost vector, VC, is set to 1000 and the
corresponding entry in the fixed cost vector, FC, is set to 0. For each
equation that is a type 1 (INDIC(I) = 1) a matrix coefficient of -1 is
created. The non-zero counter, NUMNZ, is incremented and the row
number is stored in ROW(NUMNZ), the column is stored in COL(NUMNZ) and
the coefficient is stored in A(NUMNZ).
SETR sets up the matrix row entries. The right-hand side, B, and
type vectors, INDIC, are constructed simultaneously with the matrix
coefficients in the SETR routine. Each time SETR initializes a row
it also sets a right hand side and type value. The value used for
each set of equations is:
Equation RHS Type Relation
Source Balance SOTONS(NPERID) 0
Site/Process 1000. 1 <
Constraints
Intermediate Input 0. 0 =
Balance
107
-------
Ultimate Input Balance 0. 0
Intermediate Output Balance 0. 0
Truck Constraints TRNO(NPERID) 1
Capacity Balance 0. 0
Land Constraints SILAND 1
After all matrix coefficients are generated control returns to the MAIN
program. If the matrix vectors exceed the maximum dimensions (MAXM = 90,
MAXN = 360, MAXA = 8100), then the WRAP program terminates immediately
after an error message is written for the user.
BASIS - Generation of Starting Basis
The starting basis building routines, DSTRTB and SSTRTB, are
special routines which are only executed when the user-supplied input
data does not include a starting basis. There are separate routines
for each execution mode; DSTRTB is for the dynamic mode and SSTRTB is
for the static mode.
A starting basis vector is created using the matrix row identifi-
cation table, RNA, and the column identification record pointer
table, TBMATC. One comumn per matrix row (equation) is selected. A
column may not appear in the basis more than once. All of the potential
slack columns are included in this starting basis. The special 'Z1
column is not included in this internally generated starting basis.
When a basis is successfully generated, one column for each row»
the special starting basis flag is set to true for the linear programming
functions. Figure 23 illustrates the BASIS module logic.
The starting basis is generated in SSTRTB in the following manner:
(1) One slack column is selected for each type 1
(INDIC = 1) row (equation).
(2) For each source the first transportation activity
column with code of 2 (ACODE = 2) for the source
is selected; if no ACODE = 2 exists, then the first
source column with ACODE = 1 is selected for the
basis.
(3) One column per site is selected for the input balance
equations from the activity columns with ACODE = 6.
The process at a particular site with the lowest
108
-------
(SSTRTB)
Initialize
Pointer Sort
Column ID
Pointer Vector
(DSTRTB)
No
Select all Slack
Equations Select
One Column for
Each Source
Select Column
for each
Balance
tio-
Input
Equa-
Select Column
for each
Output Balance
Equation
Initialize
Pointers
Sort Column
Record Table
Select All Slack
Equation Column
Numbers
Select Column
for each Source
for Each Model
Period
Select Column
for each Output
Balance Eq. for
each Period
Select Column
for each Site
Process with K
Columns for
each Period
Select Process
Column for each
Input Balance
Equation for
each Period
Figure 23. BASIS Module Logic Flow
109
-------
PRWGT and the highest linear segment available,
SPSEG, is selected,
(4) A transportation activity column is selected for
each output balance equation. These columns are
selected from columns with ACODE = 5; if no such
column exists then columns with ACODE = 3 or
ACODE = 4 are used for the basis.
The starting basis is thus completed for a static execution.
Both DSTRTB and SSTRTB use the double find subroutine DBFLND.
This routine searches a table to locate two matching values. Sub-
routine FIND is also used by both routines to locate a single matching
value in a sorted table.
The dynamic starting basis is created in DSTRTB. The routine
selects columns in the same way as SSTRTB with two exceptions:
(1) all equation types have columns selected for each modeling period;
(2) additional columns are selected for the site-process capacity
balance equations. These latter columns are selected from columns
with ACODE = 7; if a match is not found, then ACODE = 8 columns are
used.
LINEAR - Linear Optimizing Algorithm
The linear programming module has many subroutines. The reader
is referred to the documents of Compuvisor, Inc., and Dr. Warren Walker
for detailed discussions of the mathematical approaches and the routines,
The discussion presented here is based on those documents.
The normal exit from this module returns an objective value, OLDOB,
a final basis, BASIS, and the basic activity levels, BETAO. There are
several abnormal terminations which cause the WRAP program to abort.
A new logic addition to SETUB makes an attempt to alter the
starting basis. This alternation is made 1f the starting basis is
found to be infeasible due to a negative activity level. When this
occurs the special 'Z' column is substituted for the column with the
largest negative activity level in subroutine ZCOLIN. One more attempt
is made to have the basis accepted. If the second attempt fails, the
program aborts. This substitution approach is only used during the
initialization phase. If a problem occurs later in the algorithm, then
processing terminates with appropriate error messages and outputs.
The normal processing logic of this module is determined by the
user supplied input variable, NPHAS, which indicates the last phase of
execution desired. There are four possible phases of execution. The
special version of this algorithm as implemented in WRAP executes only
110
-------
phases 3 and 4. This change is due to the fact that a starting basis
is always available to start optimization in phase 3 and bypass the
generation of a basis in phases 1 and 2. The BASIS vector is being
user supplied or program generated.
The printed output from this module is controlled by the user-
supplied print control variable, KOPT. The major difference in the
print options is the amount of output generated. Refer to the Chapter
3,Data Base Specifications, for output options available in the LINEAR
module.
Figure 24 illustrates the LINEAR logic flow.
All of the subroutines in this module use 'unlabeled1 common for
referencing the user-supplied inputs, and SWAPCO common for data
referencing and computations that are LINEAR module specific. Only one
output file, JEF, is used for intermediate results and messages to the
user.
The subroutines and their functional descriptions in this module
are:
(1) SWAP controls the progress of the optimizer routines.
It acts as the executive monitor and establishes and
tests various control variables regulating model logic
flow. The use of the principal subroutines is determined
by this routine. The LINEAR flowchart is basically a
flowchart for this routine.
(2) BTRAN calculates the current pricing vector, PI, from
the matrix product of the basic variable costs, and
the inverse activity.
(3) COMEI subroutine prices out the 'A' matrix with current
prices of basis vectors and determines which column is
to be brought into the basis.
(4) DOTPR subroutine uses the Winograd dot product algorithm
to compute the objective function for the current basis.
When execution is in phases 3 and 4 the calculated value
is the fixed charge objective function for the current
basis.
(5) ETAGE subroutine performs a simplex transformation which
creates a new vector, ETA. The pivotal element is
column, COLMI, and row R. The ETA vector is one factor
in the product form of the basis inverse. Any change
in the basis is noted and the basis vector levels and
pointers are updated.
Ill
-------
(SWAP)
Initialize
Variables for
Linear Module
Set Error Val
(SETUA)
Setup A
Matrix and
Initial
Basis
Yes (INIT)
Setup All Slacks
and Artificials,
Test Starting
Basis for
Feasibility
Output Matrix
Variables,
Based on Print
Control Var.
KOPT
(SAVE)
Save First
Solution
Values
Phases
of Execu-
tion 72
No
Peform Linear
Optimization
for Phase 1
or 2
(LP, NEWA)
(SAVE, OUT)
Save and
Output
Results
No
112
-------
(NEWA)
Setup New 'A1
Matrix and
Cost
Vectors
(SIMPL)
Reform Simplex
Iterations Using
Fixed Change
Criteria
(SAVE)
Save Solution
Results
(OUT)
Output Phase 3
Final Optimized
Results
(NEWA, FORCE)
Setup New
A Matrix Use
Forcing 1n
Phase 4
(OUT)
Output
Phase 4 Final
Solution
Figure 24. LINEAR Module Flow Chart
113
-------
(6) ETARB reads the next sparse image of the ETA vector
in reverse sequence into an expanded ETA vector for
use by subroutine BTRAN. Variable R is set to the
pivot row for the transformation.
(7) ETARF reads the next sequential ETA vector in sparse
form into an expanded ETA vector for use by subroutine
FTRAN. This vector is read in a forward direction.
(8) ETARI subroutine records the sparse form of vector
ETA pivoting on row R into vector ETAFI which is the
sequential record of all ETA vectors produced by the
preceding simplex transformations.
(9) FORCE subroutine saves the values necessary for a
quick BASIS restoration and then forces a column into
the current basis. If a better solution is not found,
then the entering BASIS is restored and the forcing
flag, I FLAG, is set for return to the calling pro-
cedure.
(10) FSORT is a utility subroutine which sorts the 'A1
matrix by row and column. It is used during the
initialization procedures of the LINEAR module.
Only the non-zero matrix elements are retained.
(11) FTRAN updates the basis solution come-^in column by all
previous transformations. The transformation vector,
TVEC, is assigned the matrix product of the current
basis inverse times the transformation vector.
(12) INIT subroutine creates and checks the initial basis
and adds artificials and slacks to get a full identity
matrix. Execution is terminated if the initial basis
is not feasible even after 'Z1 column substitution.
When the basis is feasible, the logic sets up variables
for phase 3 execution.
(13) LP is the internal control program for phase 1 and phase
2 iterations. It also solves the application problem
for a strictly linear programming solution exclusive
of fixed charge.
(14) NEWA generates the current 'A' matrix in sparse form
to reduce the computations in phases 3 and 4.
(15) OUT subroutine outputs the LINEAR module input vectors
and results based on the user-supplied print option
variable, KOPT, which is internally equated to two
114
-------
variables, LINK and ISET. If LINK = 0, the OUT routine
is not called. If LINK is greater or less than zero,
then outputs are determined by the value in ISET. Under
all c-nditions the final solution is printed to file
JEF.
(16) PASSA subroutine reads one specific column, GETCO, of
the 'A' matrix in full form and stores it in array
ALPHA.
(17) REINV subroutine reinverts the current basis after
isolating basis vector entries already in original
positions. Levels of activity are recomputed after
basis reinversion. If reinversion cannot occur, WRAP
execution is terminated after vectors and labels are
output to file JEF.
(18) REMOV subroutine removes a row from the basis. The
removed row, ROWOU, has the minimum ratio of activity
level for column J, i.e., BETAO over matrix coefficients
A(I,J). A check is made to determine if the row
leaving the basis is an artificial row and a flag is
set accordingly.
(19) SAVE subroutine stores the current basis vector, the
current objective value, the current level of the basic
variables, and the last column to leave the basis.
(20) SETUA augments the 'A' matrix to get canonical form
with all equality constraints, arranges a sparse matrix
and counts the number of zero entries in a column.
(21) SETUB restores the basic vector to computation status.
If a reinversion occurred naturally during iterations,
then subroutine REINV is called to do a reinversion.
If the starting basis was not acceptable, then sub-
routine ZCOLIN is called to substitute the 'Z' column
for the basis column with the largest negative activity
level and reinversion is tried again.
(22) SIMPL subroutine uses the fixed charge criterion to find
a solution better than that found by the LP subroutine,
or the initial basis as provided by the user or generated
by the program. If simple forcing is used then iterations
are performed until a local optimum solution is found.
(23) SWITC is called after phase 1 to reset cost vectors for
phase 2 iterations by restoring the original structural
costs and updating the pricing vector.
115
-------
(24) TINV tests for inversion requirements. If the ETAFI
vector is full then reinversion occurs unconditionally.
If the last tolerance check showed appreciable error,
tolerance is checked on every iteration and reinversion
occurs when an intolerable error appears, i.e., when the
absolute value of the differences between the previous
cost and the current cost divided by the current cost
exceeds .5.
(ERROR - | (PRCOST) - COST)/COST > .5)
The final solution values are returned in SWAPCO common for output
from the final WRAP module OUTPUT.
OUTPUT - Management Report Generation
The OUTPUT module of WRAP prints the management reports using the
solutions produced by the LINEAR module and the user-supplied input
data as stored in the column identification records created by the
COLUMN module. One report is printed for a static execution mode,
and two reports are printed for a dynamic execution mode. Report
column headings are printed by subroutine APRINT. Subroutines FIND
and READIT are used to retrieve the column identification records.
OUTBAS, the OUTPUT module control routine, initializes the output
variables and sets up a two dimensional array, CRES. This array is
used to sort the solution results into column sequence, activity code
sequence, and modeling period sequence. Matrix column numbers are
retrieved to be punched as the final basis, BASIS, if a punched basis
was requested by the user as indicated by the value of PBASE input on
the CONTRL record. The output logic then branches to call other sub-
routines according to the execution mode as indicated by variable
MTYPE. Figure 25 illustrates the logic flow for the OUTPUT module.
OSTAT is called to print the management report for a static
execution.
The header page for the static report is printed by OUTBAS. It
is headed with the line
"STATIC MODEL RESULTS".
Next, the objective value, OLDOB, is printed as
"OBJECTIVE VALUE IS INCLUDING ALL COSTS FROM
LOADING OF PACKER TRUCKS".
116
-------
(OUTSAS)
Initialize CRES
Vector for
Pointer Use
Calculate Total
Tonnage from
Source Input
Records
Calculate
Average Cost
Per Ton
Output, CoTf,~
Tonnage, Cost
Per Ton
Sort Result
Columns by
Activity Code
STAT)
(OSTAT)
Output Final
Result Tables
by Activity
Code
Add Model
Periods to
Result Column
Tables
Sort CRES
Vector by
Period Code
and 10 Nos.
Output
Sys tern
Cost
(ODYN1)
Retrieve Records
by Period and
Activity Code
T
Output Final
Results,
Report 1
/namic
(OUTBAS)
Sort Results
By Activity
Code, ID'S and
Period
Retrieve Column
Record by
Activity Code,
and Period
(ODYN2)
Output Final
Results
Report 2
Dynamic
Figure 25. OUTPUT Module Logic Flow
117
-------
Then the total tonnage for the model calculated as the cumulative waste
tonnages per year per period, using SOTONS from the Source records summer
over all Source records, is printed. Finally, the
"AVERAGE SYSTEM COST"
per ton is printed as calculated from the objective value and total
tonnage:
OLDOB TONSUM.
The report is then printed, starting on a new page, by OSTAT.
Result data is sorted according to activity type, ACODE, and within
each type by origin code, then process identification code (where
applicable) and destination identification code for transportation
activities (ACODE 1 to 5). Data is sorted by the site code and
then the process code within the processing activities columns
(ACODE =6). A new report page with appropriate headings is started
for each new activity type. The first heading line describes the
activity type. For transportation activities, the line reads:
"TRANSPORTATION ACTIVITY LEVEL DATA FOR
for ACODES 1 to 5
respectively
THE SOURCE TO ULTIMATE FACILITY "
PAIR(S)
THE SOURCE TO INTERMEDIATE
FACILITY PAIR(S)
THE INTERMEDIATE TO INTERMEDIATE
FACILITY PAIR(S)
THE INTERMEDIATE TO ULTIMATE
FACILITY PAIR(S)
THE CATEGORY FIVE PAIR(S)
or
for processing activities (ACODE = 6)
"PROCESSING ACTIVITY LEVELS".
The second header line for all activity types 1s the message:
"ACTIVITY LEVELS ARE IN THOUSANDS OF TONS PER YEAR."
Then the appropriate column headings followed by the descriptive data
with result values are printed for each activity type.
Four Source to Ultimate or Source to Intermediate activities
(ACODE = 1 or 2) only the origin name, ONAME, and identification code,
ID, destination name, DNAME, and identification code, IDS, activity
level, BETAO (ICRS), and model period, MPERID, are printed.
118
-------
For site transportation activities, Intermediate to Intermediate
or Intermediate to Ultimate, where ACODE is 3 or 4, the origin site
name, ONAME, and identification code, ID, the origin process name,
PRNAME, and process code, ID2, destination site name, DNAME, and
site code, IDS, activity level,ACODE, and period are printed.
For special category 5 activities, ACODE = 5, with source (ID
less than 500) origins, the same data variables and column headings
as for normal source origin activities are printed. For category 5
activities with site (ID greater than 499) origins, the same data
variables and headings are printed as for the normal site origin
activities.
For each processing activity, the origin name and identification
code, process name and process code activity level and linear segment,
SPSEG, are printed.
ODYN1 generates the first dynamic report. Model period is the
major sort and within period, activity type, then origin identification
code, process number and destination code as applicable.
The header page for this report consists of the label
"DYNAMIC MODEL OUTPUT"
"MODEL PERIOD MAJOR SORT"
followed by the objective value, OLDOB, printed as
"OBJECTIVE VALUE IS IN THOUSANDS OF DOLLARS DISCOUNTED
TO YEAR ONE INCLUDING ALL COSTS FROM LOADING OF PACKER TRUCKS."
The report itself is then printed by ODYN1 starting on the next
page. A new page is started for each model period and activity
within each period. The first Hne on each page gives the model
period. The rest of the heading lines and data types printed are
identical to the static report for transportation activity types 1 to
5. The report is essentially a static model report repeated for each
model period with the exception of data printed for processing
activities and the addition of two activity types and slacks.
For processing activity columns (ACODE = 6), the origin name
and code, process name and code, activity level and model period are
printed.
"CAPACITY BUILDING ACTIVITY LEVELS" - For these activities
the site name and code, process name and code, model period, activity
level and linear segment are printed.
119
-------
"CAPACITY UNDERUTILIZATION ACTIVITY LEVELS" - For these activities,
site name and code, process name and code, model period and activity
level are printed.
Finally, data for any slacks with land constraints is printed
under the heading
"LAND CONSTRAINT ACTIVITY LEVELS OF SLACKS IN ACRE-FEET"
followed by a column of site identification codes for the slacks and
a column containing their corresponding activity levels.
ODYN2 generates the second dynamic report. This report consists
of the same data and headings for each activity type as does the first
dynamic report. It differs only in being sorted by activity code,
ACODE, as the major sort, then by origin code, process code, destination
code, as applicable, and finally model period as the innermost sort.
The header page contains the lines:
"DYNAMIC MODEL OUTPUT"
"MODEL PERIOD INNER SORT"
followed by the objective value, OLDOB, printed as in the first
dynamic report.
The activity data for slacks is printed in this report as it is
in the first dynamic report.
All output reports are written to printer file OUT. No results
are printed for a solution activity with an activity level, BETAO,
approaching zero, that is, an absolute value less than 0.01.
120
-------
Chapter 5
MAINTENANCE PROCEDURES
General
The maintenance procedures presented in this chapter are for
the installation and execution of WRAP- The program can be installed
on any computer system which supports the FORTRAN IV language and has
at least 270 thousand bytes (66 thousand words of 16 bits) of avail-
able storage. The WRAP program 1s provided in source code on a nine
track unlabled magnetic tape. A source code listing is not provided
with the tape. These listings can be created by dumping the tape or
by compiling the program.
Information is presented for WRAP size modifications. If it be-
comes necessary to modify the code for different problem sizes the
other chapters and appendices in this volume should be used along
with the compilation listings of WRAP and the sizing information pre-
sented herein.
Purpose
This chapter should provide the programmer with sufficient infor-
mation to install and maintain the WRAP program at a particular com-
puter installation. It is assumed that the programmer has access to
facility specific instructions for compiling and executing a large
FORTRAN IV program, so specific instructions are not provided.
Included in this chapter are sections on the WRAP source tape,
sizing and dimensioning the WRAP problem, file requirements, over-
lay structure, and certain error conditions. For detailed presenta-
tion on the WRAP data base and subroutines, refer to Chapter 3 and
4 of this document. For a list of error messages generated by WRAP
during execution, refer to Chapter 6.
References
Other documents that should be available to the programmer to
help maintain the WRAP program are:
(1) IBM System/360 and System/370 FORTRAN IV Language9
(2) IBM System/360 Operating System Job Control Language
ReferencelO
121
-------
(3) IBM System/360 Operating System FORTRAN IV (6 and H)
Programmer's Guide!1
(4) WRAP, Waste Resources Allocation Program - A Model for
Regional Solid Waste Management Planning. User's Gui'de7
WRAP Source Tape
The WRAP source code is supplied on an unlabeled nine track mag-
netic tape written at 1600 bpi. The records are card images with 80
characters and blocked 40 records per block (BLKSIZE « 3200). Each
record is numerically sequenced in columns 77-80.
The source code tape has 12 unlabeled files. The first file con-
tains only the main program, MAIN. Each of the other files contain
all of the routines assigned to a particular module. Refer to Ap-
pendix IV for the names of the individual subroutines in each module.
Table 20 lists the tape files by module name with the number of records
in each module and the number of subroutines in each module.
Module File
MAIN (program)
MAIN (subroutines)
EDIT1
EDIT2
CROFLY
LINKAGE
FRONTOUT
COLUMN
MATRIX
WRAP
Number
1
2
3
4
5
6
7
8
9
BASIS 10
LINEAR 1
1
Table 20
SOURCE TAPE FILES
Number of Records
261
1304
1764
871
804
257
497
1022
969
679
2404
Number of Routines
1
8
12
7
8
2
4
8
15
3
25
122
-------
OUTPUT
Note:
12
794
All files are unlabeled with 80 character records
in 40 record blocks.
Initially each file (module) should be compiled separately. A
binary object deck or load module should be created. The load module
should be stored on a tape or dfsk in a named data set which may be
retrieved at execution time.
Figure 26 illustrates a typical JCL deck to compile a WRAP mod-
ule from the source tape.
//LINEAR JOB (facility accounting information). REGION=128K,
// TIME=5
//COMP EXEC FORTGC,PARM='DECK,NOLOAD,SOURCE',ACCT=COST
//FORT.SYSIN DD UNIT*TAPE,LABEL=(10,NL),
// DISP=(OLD,KEEP),DSN=DUMMY,
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200),
// VOL=SER«XXXXXX
where XXXXXX is the magnetic tape volume serial number
Figure 26. JCL to Compile the LINEAR Module from Tape
Standard IBM utility routines such as IEBGENER may be used to
extract modules or individual subroutines from the source tape, or
to dump the tape to cards or an on-line time sharing system for
source code modification and maintenance. This latter job step may
be highly useful when modifications are necessary to alter file as-
signment and/or the size and dimensions of the WRAP program or to
make any other modifications.
Figure 27 illustrates one method of dumping a file or source code
to a TSO (Time Sharing Operating System) account.
123
-------
//LOAD EXEOIEBGENER,ACCT=COST
//SYSIN DD DUMMY
//SYSPRINT DD SYSOUT=A
//SYSUT1 DD DSN=DUMMY,DISP=(OLD,KEEP),UNIT=TAPE,
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200),
// YOL«SER-[XXmX],LABEL«(2,NL)
//SYSUT2 DD DSN=[TS$(XX],EDrn.FORT,UNIT=DISK,
// DISP=(NEW,CATLG),SPACE=(CYL,(1,1)),
// , DCB=(RECFM=FB,LRECL=80,BUCSIZE=400)
[1] Tape volume serial number.
[2] ISO account number, or data set name.
Figure 27. IEBGENER Utility Routines for Dumping WRAP
tape to ISO
Figure 28 illultrates a method for creating members of a partitioned
data set from a sequential file.
//TPEPDS EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=A
//SYSUT1 DD DSNAME=DUMMY,UNIT=TAPE,LABEL=(1,NL),
// DISP=(OLD,KEEP),DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200)
it VOL=SER=XXXXXX
//SYSUT2 DD DSNAME=WRAPSOR,UNIT=DISK,DISP=(NEW,CATALG,KEEP),
// SPACE=(TRK,(200,100,10)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200),
// VOL=SER=YYYYYY
//SYSIN DD*
GENERATE MAXNAME=9,MAXGPS=4
MEMBER NAME=MAIN
GROUP 1 RECORD IDENT=(4, '026T, 77)
MEMBER NAME=DEFLT
GROUP 2 RECORD IDENT=(4, '0297', 77)
MEMBER NAME=FIND
GROUP 3 RECORD IDENT=(4, '0345', 77)
MEMBER NAME*INITDA
GROUP 4 RECORD IDENT=(4, '0426', 77)'
MEMBER NAME«LXCOMP
Figure 28. Source Tape to Partitioned Data Set Using
IEBGENER
124
-------
Figures 29 and 30 illustrate sample JCL cards for a compile,
link and go execution using source cards, object tape, and object
cards.
//CHECKS JOB (0800,073,DESK),'HENSEY V,REGION=270K,CLASS=H,
// TIME=1
// EXEC FORTGCLG,ACCT=(EXCPS,COST),PARM.LKED='XREF,OVLY,LIST1
XXFORT EXEC PGM=IEYFORT,REGION=128K
//FORT.SYSLIN DD DCB=BLKSIZE=3200
X/SYSLIN DD DSN=&&LOADSET,DISP=(MOD,PASS),UNIT=DISK,
XX SPACE=(80,(200,100),RISE),DCB=BLKSIZE=400
XXSYSPRINT DD SYSOUT=A,DCB=(LRECL=120,RECFM=FBA,BLKSIZE=120)
XXSYSPUNCH DD SYSOUT=(B,,3),DCB=(LRECL=80,BLKSIZE=80,RECFM=FB)
XXSYSUDUMP DD SYSOUT=A
//FORT.SYSIN DD *
(Insert source decks here or change JCL to retrieve source
code from a tape file.)
XXLKED EXEC PGM=IEWL,PARM=(XREF,LET,LIST),COND=(4,LT,FORT)
XXSYSLIB DD DSNAME=SYS1.FORTLIB,DISP=SHR
XXSYSLMOD DD DSN=&&GOSET(MAIN),DISP=(MOD,PASS),UNIT=DISK.
XX SPACE=(1024,(20,10,1),RLSE)
XXSYSUT1 DD UNIT=(DISK,SEP=SYSLMOD),SPACE=(1024,(20,10),RLSE),
XX DCB=BLKSIZE=1024
//LKED.SYSLIN DD
X/SYSLIN DD DSN=&&LOADSET,DISP=(OLD,DELETE)
// DD UNIT=TAPE,DISP=(OLD,KEEP),VOL=SER=TA0242,DSN=WRAPOBJ
X/ DD DDNAME=SYSIN
// DD *
XXSYSPRINT DD SYSOUT=A,DCB=(BLKSIZE=121,LRECL=121,RECFM=FBM),
XX SPACE=(TRK,(10,10),RLSE)
XXSYSUDUMP DD SYSOUT=A
(Insert binary decks and overlay cards here.)
Figure 29. Compile and Link JCL from Cards and Tape
XXGO EXEC PGM=*.LKED.SYSLMOD,COND=((4,LT,FORT),(4,LT,LKED))
XXFT05F001 DD DDNAME=SYSIN
XXFT06F001 DD SYSOUT=A,DCB=(LRECL=133,RECFM=FBA,BLKSIZE=133)
XXFT07F001 DD SYSOUT=(B,,2),DCB=(LRECL=80,RECFM=FB,BLKSIZE=80)
XXSYSUDUMP DD SYSOUT=A
//GO.FT21F001 DD UNIT=KISK,SPACE=(80,(3)),DCB=(RECFM=FB,LRECL=80,
// BLKSIZE=80)
125
-------
//GO.FT22F001 DD UNIT=DISK,SPACE=(105,(100)),DCB=(RECFM=FB,LRECL=105,
// BLKSIZE=2100,BUFNO=1)
//GO.FT23F001 DD UNIT=DISK,SPACE=(70,(50)),DCB=(RECFM=FB,LRECL=70,
// BLKSIZE=1400,BUFNO=1)
//GO.FT24F001 DD UNIT=DISK,SPACE=(950,(20)),DCB=(RECFM=FB,LRECL=950,
// BLKSIZE=9500,BUFNO=1)
//GO.FT25F001 DD UNIT=DISK,SPACE=((50,(450)),DCB=(RECFM=FB,LRECL=50,
// BLKSIZE=1000,BUFNO=1)
//GO.FT26F001 DD UNIT=DISK,SPACE=(50,(25)),DCB=(RECFM=FB,LRECL=50,
// BLKSIZE=1000,BUFNO=1)
//GO.FT27F001 DD UNIT=DISK,SPACE=(80,(125)),DCB=(RECFM=FB,LRECL=80,
// BLKSIZE=1600,BUFNO=1)
//GO.FT29F001 DD UNIT=DISK,SPACE=(140,(360)),DCB=(RECFM=FB,LRECL=140,
// BLKSIZE=2800,BUFNO=1)
//GO.SYSIN DD *
(Insert user-supplied input deck.)
Figure 30. GO step JCL
Sizing and Dimensioning
WRAP is sized for a 90X360 matrix with a maximum of 8100 non-
zero elements. There are arrays dimensioned for 90 rows, 360 columns,
450 expansion columns, and 8100 matrix coefficients. In addition to
the matrix arrays, there are input data arrays which determine the
maximum number of input records. These input limitations are
(1) 100 source identification records;
(2) 50 site identification records;
(3) 125 site-process identification records;
(4) 20 process identification record sets;
(5) 25 truck constraint records;
(6) 450 transportation activity records.
The last limitation (transportation activity) is actually not feasi-
ble in the WRAP program since a maximum of 360 columns are permis-
sible in the matrix.
126
-------
A WRAP application problem must be sized by the user before
executing the program. This section presents information on array
dimensions and matrix sizing. For more detailed instructions on
the matrix sizing refer to the WRAP User's Guide.?
There are 38 arrays which may be altered to create a different
sized WRAP program. These arrays may be related to (1) matrix coef-
ficients, (2) matrix rows, (3) matrix columns before expansion, (4)
matrix columns after expansion,
(6) site identification records
(8) site-process identification
records, and (10) matrix column
lists, in alphabetical sequence
(5) source identification records,
, (7) process identification records,
records, (9) transportation activity
identification records. Table 21
, the alterable arrays, their dimen-
sions, description, relationship, and storage location.
Table 21
CHANGEABLE ARRAYS FOR WRAP PROGRAM
Array
Name
A
ALPHA
B
BASIS
BASMR
BETA
BETA I
Dimensions
8100
90
90
90
450
90
90
Description
Matrix Coefficients
Vector in LINEAR
module
Matrix right hand
side
Solution Basis and
Starting Basis
Basis come-in col-
umn marker
Activity level
Initial Phase
Size Re-
lated to
Coefficients
Rows
Rows
Rows
Expanded
Columns
Rows
Rows
Storage
Location
Unlabeled
Common
SWAPCO
Unlabeled
Common
Unlabeled
SWAPCO
SWAPCO
SWAPCO
BETAO
CNA
Activity levels
90 Result Activity Rows Unlabeled
Levels Common
450 Column Identifica- Expanded Unlabeled
tion Vector Columns Common
127
-------
COL
8100 Numeric Column
Values for Matrix
Coefficient
Coefficients Unlabeled
COLCN
COLPN
CRES
CST
DEST
ETA
ETAFI
ETAND
FC
IBASI
IDRNA
IDRNAD
INDIC
NEWS A
NRPVT
DBAS I
360
361
90,7
360
50,2
90
8100
8100
450
90
90,2
90
90
90
90
90
Non-zero Counter
for Columns
Non-zero Column
Counter Pointers
Results Pointers
Cost Vector
Possible Linking
Destinations
Simplex Trans-
formation Vector
Matrix Expansion
Vector
Row Pointers for
Columns In Reverse
Order
Fixed Costs Vector
Initial LP Calcu-
lated Starting Basis
Row Origin-Process
Numbers
Row Destination
Numbers-
Row Equation Types
Temporary Storage
for Basis
Pivot Row Markers
Saved Basis Solution
Columns
Columns
plus one
Rows and
identifi-
cation keys
Columns
Sites
Records
Rows
Coefficients
Coefficients
Expanded
Columns
Rows
Rows and
pointer keys
Rows
Rows
Rows
Rows
Rows
SWAPCO
SWAPCO
OCOM
SWAPCO
LNK
SWAPCO
SWAPCO
SWAPCO
Unlabeled
SWAPCO
RNACO
RNACO
Unlabeled
REINV
Subroutine
SWAPCO
SWAPCO
128
-------
ORIG
PSIOF
RID
RNA
ROW
TBPR
TBSI
TBSIPR
TBSRC
VC
125,3
360
90,2
90
8100
TBMATC 360,7
20,2
50,2
125,3
100,2
*TBTRAN 450,5
360
Possible Links
for origins
Vector Products
Summation
See IDRNA
Row Identifi-
cation Numbers
Row Matrix Coef-
ficients Numbers
Column Record
Pointers
Process records
pointers
Site records
pointers
Site-Process
pointers
Source Record
Pointers
Transportation
Record Pointers
Variable Costs
Vector
Site-process LNK
records
Columns SWAPCO
Rows and
pointer keys
Rows Unlabeled
Coefficients Unlabeled
Columns and SETREC
identifica-
tion keys
Process
records
Site
records
Site-process
records
Source
records
Transporta-
tion activity
records
Column
PNTR
PNTR
PNTR
PNTR
PNTR
Unlabeled
*The dimensions for this array are too large for WRAP
since the maximum matrix columns is 360. Of these
columns possibly only a maximum of 300 would be
transportation activities.
When an array dimension is to be altered every reference to that
array must be modified in the WRAP code. If the altered array is
related to the user supplied input, then the file definition state-
ments in MAIN and the job control language statements will have to be
129
-------
altered to assure that adequate storage space is available in the
temporary storage file. Appendix III contains the storage allocation
lists for each common storage area and the cross-reference tables in
Appendix IV indicates which WRAP routines reference the various com-
mon storage areas.
The matrix sizing is determined by computing the number of rows
and columns based on the user supplied input for a particular applica-
tion. Table 22 contains parameters considered for determining the num-
ber or rows in the matrix. Table 23 contains the parameters which de-
termine the number of columns (pre-expansion) fn the matrix.
Table 22
MODEL SIZING PARAMETERS FOR MATRIX ROWS
Equation Type
Static
Rows Generated
Dynamic
Source Balance
Equations
Site Processing
Equations
Input Balance
Equations
Output Balance
Equations
Truck Constraint
Equations
Capacitation
Equation
1 for each source
1 for each limited
intermediate site
1 for each ultimate
site
1 for each site
(intermediate and
ultimate)
1 for each site-
process with posi-
tive output
1 for each site
specified with a
truck constraint
1 always
1 for each source with
waste in each model
period
1 for each limited
intermediate site in
each model period.
1 for each limited
ultimate site in each
model period.
1 for each limited-
ultimate site in each
model period.
1 for each site in
each model period
1 for each site-process
with positive output in
each model period
1 for each site speci-
fied with a truck con-
straint in each model
period
1 always
130
-------
Site-process Capacity none
Balance Equations
Land Equation none
1 for each site-
process which is in-
dicated as being avail
able during each model
period
1 for each ultimate
site
Table 23
MODEL SIZING PARAMETERS FOR MATRIX COLUMNS
Coefficient Type
Static
Columns Generated
Dynamic
Transportation
Activity
Coefficients
Processing
Activity
Coefficients
Special Z Column
Slacks (added by
LINEAR module)
Artificials (added
by LINEAR module)
Capacity Building
Activities
Underutilization
Activity
1 for each sepa-
rate activity
1 for each site-
process linear
segment
1 always
1 for each equa-
tion with inequali-
ties
1 for each equality
equation
none
none
1 for each separate
activity with waste
each model period
in
1 for each site-
process in each model
period
1 always
1 for each equation
with inequalities
1 for each equation
with equalities
1 for each site-
process linear segment
in each model period
if it is available for
capacity building
1 for each site-process
in each model period in
which a corresponding
process activity exists.
131
-------
The non-zero matrix elements are allocated memory based on the
number or rows squared. (90 x 90 = 8100) This allocation is generally
large enough for most matrices since the dimension is for only non-
zero coefficients. It also serves as a controlling factor on the
LINEAR modules matrix reinversion frequency, (i.e., the more space
available for matrix manipulation the fewer reinversions required.)
The post-expansion column dimension is determined by adding the maxi-
mum number of rows to the maximum number of columns, (e.g., ROWS = 90,
COLUMNS = 360, EXPANDED COLUMNS = 90 + 360 = 450)
The following steps must be taken if alteration are to made to
WRAP to change the problem size or various dimensions.
(1) For matrix modifications only change the values of the
variables MAXM, MAXN, and MAXA in the MAIN program where MAXM =
maximum rows, MAXN = maximum columns, and MAXA = maximum non-
zero matrix.
(2) For file modifications only, change the file definition
statements in the MAIN program, the initialization statements
in the INITDA subroutine, and all calls to LXSORT throughout
the programs since the argument list for LXSORT contains a
numeric constant as the second argument indicating the maxi-
mum size of a file pointer table. Change the DATA statement
in subroutine CONTRL. Change the arrays in PNTR or SETREC
common.
(3) Under all conditions locate the arrays that are to be
altered in Table 21.
(4) Use Appendix IV to find all the references to the storage
area affected.
(5) Make the correction to all dimensioning references of the
arrays, after going through the WRAP sizing procedures.
(6) Recompile all routines in which the arrays are referenced.
If the alteration is to reduce the vectors, then nothing needs to
be done unless the intent is to reduce the amount of core storage re-
quired to execute the WRAP program.
Finally, if modifications are made to the temporary files, the
definition statements in MAIN will have to be altered and the job
control language statements will have to be changed. This is especially
true if more disk space is needed, or if the actual device code number
and assignment specifications are changed.
132
-------
File Requirements
The WRAP program requires a minimum of 12 files for job execu-
tion. If the object load module or the source code 1s stored on a
tape or disk, then additional files are necessary to access the pro-
gram code.
WRAP program code defines 12 file numbers 1n the main routine.
All file variable names are defined as integers:
Card Reader MUT = 5
Printer JEF = 6
Final Report Printer OUT = 6
Punch File PFILE = 7
Title Record File FILE1 = 21
Source Records FILE2 = 22
Site Records FILE3 = 23
Process Records FILE4 = 24
Transportation Records FILES = 25
Truck Constraint Records FILE6 = 26
Site-Process Records FILE? = 27
Column Identification Records FILE9 = 29
These files are referenced by many other routines. Appendix IV pro-
vides a cross reference list for the defined file numbers. The eight
temporary files are defined as disk files with different record lengths
and block sizes. The other four files are two printers, a card reader,
and a card punch. Figure 31 illustrates the JCL for the 12 files.
Only one printer file JCL statement is given since both printer files
are assigned to device six.
133
-------
XXFT05F001 DD
XXFT06F001 DD
XX DCB=(LRECL=
XXFT07F001 DD
XX DCB=(LRECL=
XXSYSUDUMP DD
//GO.FT21F001
// DCB=(RECFM=
//GO.FT22F001
// DCB=(RECFM=
//GO.FT23F001
// DCB=(RECFM=
//GO.FT24F001
// DCB=(RECFM=
//GO.FT25F001
// DCB=(RECFM=
//GO.FT26F001
// DCB=(RECFM=
//GO.FT27F001
// DCB=(RECFM=
//GO.FT29F001
// DCB=(RECFM=
//GO.SYSIN DD
Printer
Punch
DDNAME=SYSIN
SYSOUT=A,
=133,RECFM=FBA,BLKSIZE=133)
SYSOUT=(B,,2),
80,RECFM=FB,BLKSIZE=80
SYSOUT=A
DD UNIT=DISlCtSPACE=(80.(3)).
FB,LRECL=80,BLKSIZE=80)
DD UNIT=DISK>SPACE=(105,(100))t
FB,LRECL=105,BLKSIZE=2100,BUFNO=1)
DD UNIT°DISK,SPACE=(70.'(50)).
FB,LRECL=70,BLKSIZE=1400,BUFNO=1)
DD UNIT=DISK.SPACE=(950>(20))>
FB,LRECL=950,BLKSIZE=9500,BUFNO=1)
DD UNIT=DISK,SPACE,SPACE=(50,(450)),
FB,LRECL=50,BLKSIZE=1000,BUFNO=1)
DD UNIT=DISK.SPACE=(50,(25)).
FB,LRECL«50,BLKSIZE»1000,BUFNO-1)
DD UNIT=DISK.SPACE=(80t(125)).
FB,LRECL=80,BLKSIZE=1600,BUFNO=1)
DD UNIT=DISK,SPACE=(140,(360)),
FB.LRECL=140,BLKSIZE=2800,BUFNO=1)
Card.ileadfic)
Operating
System
Generated
TITLE
SOURCE
SITE
PROCESS
TRANS
TRUCK
SITE-PROCESS
COLUMN
User
Sup-
plied
User Input records follow here. (Underlined
numbers in JCL statements are the record
length and the number of records in the file.)
Figure 31. File Requirements JCL for WRAP Execution
If the WRAP program dimensions are altered for any of the vari-
ables written to the disk files, then the JCL must be modified to re-
flect the change. It is also necessary to modify the associated file
definition statement in the main program if the alteration increases
the record length and/or the number of records to be written to the
file. Refer to Figure 32 for the JCL values affected and to Appendix
I for file specification information.
Overlay Structure
The computer storage requirement for a WRAP execution has been
substantially reduced by using overlays. There are eight overlay seg-
ments for the program. Table 24 lists the contents of each overlay
segment by subroutine name or common storage name.
134
-------
Segment Name
and Number
Table 24
WRAP OVERLAY SEGMENTS AND CONTENTS
Contents
Type
MAIN 1
MAIN 1
ALPHA 2
ALPHA 2
BETA 3
BETA 4
BETA 4
BETA 5
BETA
MAIN, ERROR, FIND, LXSORT,
LXCOMP, READIT
ERRCOD, FRONT, POUT, PROCCO,
READ, RNACO, SBASI, SETREC,
SIPRCO, TITLRD.Unlabeled"
DEFLT, INITDA, PUNCHM, PUNCHT,
SEGS, PRINT, APRPU
PNTR, SITECO, SRCCO, TRANCO,
TRKCO
EDIT!, CONTRL, CRWFLY,LINKS,
PRCOST, PROCES, SIPRC, SITE,
SOURCE, TBASIS, TRANS, TRUCK
EDIT2, BUILD, CADIST, CKSIPR,
CNTCHK, CONV, CROFLY, CRWLNK,
DUP, DUPWRT, ICROW1, ICROW2,
LNKBLD, LNKCHK, ONENUM, PRCHK,
TRNCHK
LNK
COLUMN, MATRIX, CAPABL, COST,
CPFAC, CSTCRD, DBLFND, DSTRTB,
ED, INITLP, ISPOB, IUSIB, IUSPC,
IUSTC, KCOST, LANCON, PCOST,
SCOST, SETC, SETR, SORBAL, SSTRTB,
TBREAD. TCOST, TRFAC, ZCOLUMN
MAT
Routines
Commons
Routines
Commons
Routines
Routines
Common
Routines
Common
ALPHA
GAMMA 7
SWAPCO
SWAP, BTRAN, COMEI, DOTPR,
ETAGE, ETARB, ETARF, ETARI,
FORCE, FSORT, FTRAN, INIT,
LP, NEWA, OUT, PASSA, REINV,
REMOV, SAVE, SETUA, SETUB,
SIMPL, SWITC, TINV, ZCOLIN
Common
Routines
135
-------
GAMMA 8 APRINT, ODYN1, ODYN2, OSTAT, Routines
OUTBAS, SER2
GAMMA 8 OCOM Common
This overlay structure must not be altered, it may be removed
from the linkage step but it must not be altered. If the overlays
are not used, the computer storage requirements increase by approxi-
mately 100 thousand bytes.
Figure 32 contains the required overlay cards in the input
sequence.
ENTRY MAIN
INSERT MAIN,FIND,READIT.LXSORT.LXCOMP
INSERT SETREC,READ,RNACO,FRONT,SIPRCO.PROCCO
INSERT POUT.SBASI
OVERLAY ALPHA
INSERT SRCCO,SITECO,TRANCO,TRK.CO,PNTR,TITLRD,ERRCOD
INSERT INITDA.DEFLT.SEGS.APRPU,PRINT,PUNCHM.PUNCH!,ERROR
OVERLAY BETA
INSERT EDIT1,CONTRL,SOURCE,SITE,PROCES,SIPRC,TRANS,TRUCK,TBASIS
INSERT LINKS,PRCOST.CRWFLY
OVERLAY BETA
INSERT EDIT2,ONENUM,CNTCHK,CKSIPR,PRCHK,TRNCHK,DUP,BUILD,LNKCHK
INSERT ICROW2,DUPWRT,CRWLNK,LNKBLD,CROFLY,CADIST,CONV,ICROW1
INSERT LNK
OVERLAY BETA
INSERT COLUMN,TCOST,PCOST,KCOST,SCOST,TRFAC,CPFAC,CSTCRD
INSERT MATRIX,TBREAD,SETC,SETR,INITLP,SORBAL,IUSPC,ISPOB,IUSTC,IUSIB
INSERT CAPBAL,LANCON,COST,ED,ZCOLMN
INSERT DBLFND.SSTRTB.DSTRTB
INSERT MAT
OVERLAY ALPHA
INSERT SWAPCO
OVERLAY GAMMA
INSERT SWAP,FSORT,FTRAN,LP,SETUB,BTRAN,TINV,FORCE,REINV,PASSA
INSERT ETAGE.COMEI,OUT,INIT,NEWA,SIMPL,SETUA,ETARI,REMOV,ETARB,SAVE
INSERT SWITC,ETARF,DOTPR
INSERT ZCOLIN
OVERLAY GAMMA
INSERT OUTBAS,OSTAT,ODYN1,ODYN2,SER2,APRINT
INSERT OCOM
Figure 32. Overlay JCL Cards
136
-------
Error Conditions
Errors which are generated during WRAP execution are discussed
in Chapter 6. If any other errors occur the debugging switch may be
turned on in the MAIN program. The variable IDBUG may be set to one
and the main program recompiled. This switch which cause intermedi-
ate outputs to be generated by the editing modules should only be
used by the programmer when there is a question about the input data
editing checks.
A word of caution, subroutine LXSORT tests the debugging switch
and outputs every array that it sorts, so the printout may be exten-
sive. To delete this output, reset IDBUG in LXSORT or delete the
output statements in LXSORT and recompile the routine.
Any other errors, not detected by the program code, should be
traceable by examining the outputs generated when the debugging switch
is on.
If it becomes necessary to alter the WRAP program, the chapters
in this volume and the appendices should be examined thoroughly before
making the alterations.
Data Editing Recommendations
If the user has some questions about the application problem, it
is advisable to execute only the front end modules of WRAP. This
front end execution may be accomplished by inputing certain execution
control data on the first input record CONTRL:
(1) setting the PCROW variable to punch and stop, or
(2) setting the PMODEL variable to punch and stop, or
(3) inserting a stop in the MAIN program before the
LINEAR module.
This early termination process uses less than one minute of computer
time. The LINEAR module may use from five to twenty minutes of com-
puter time based on the particular problem. So it is advisable to
make sure that the application specifications are valid.
137
-------
Chapter 6
USER INFORMATION
General
This chapter presents information for using the programmed WRAP
model. The program is assumed to be in object code and ready for ex-
ecution with the user-prepared input records. The areas covered are
program sizing, computer requirements, input sequence and error mes-
sages.
For detailed information on data preparation and final report
interpretation refer to:
(1) WRAP, Waste Resources Allocation Program, A Model
for RegionaT SolYd Waste Management Planning,
User's Guide?.
(2) WRAPvWaste Resources Allocation Program, A Model
for Re^ional Solid Waste Management PIanning,
Ope ra tion aland Exe re i se'
Program Size
The WRAP program allows for a matrix with a maximum of 90 rows
(equations), 360 columns (coefficients), and 8100 non-zero matrix
entries. Prior to execution, the anticipated matrix size should be
determined to be sure that the particular application meets the size s
constraints. The sizes are determined before the matrix expansion in
the LINEAR module.
In addition the program controls for maximum user input as fol-
lows:
100 Source Identification records
50 Site Identification records
20 Process Identification sets (each set may have from
5-18 records)
125 Site-Process Identification records
300 Transportation Activity records
25 Truck Constraint records
138
-------
6 Starting basis records (maximum of 90 entries,
16 entries per record).
If the particular application will not fit in the 90 x 360
model, then the program code must be modified to provide the addi-
tional storage required. In addition to changing the code, the com-
puter requirements, as presented in the next section, will also have
to be modified. The users may also reduce the size of the model and
thereby reduce the computer memory requirements for a WRAP execution.
Chapters provides information for the programmer to make the
necessary modifications to WRAP for the various program sizings that
may be required.
Computer Requi rements
The computer requirements for the execution of WRAP are not com-
plex. The two major requirements are computer memory and direct-
access devices.
The memory requirements for the 90 x 360 WRAP model are 270K
byte of storage. This requirement must be modified if the model di-
mensions are altered to accommodate a larger matrix which uses more
memory or process a smaller matrix which uses less computer memory.
Memory is usually requested by the user in a job control language
statement on the first control card. The statement is expressed as
REGION=270K.
The input-output file requirements are: a card reader, a card
punch, at least one printer, and a disk with storage for at least
eight files. Figure 33 illustrates the job control language input
cards prepared for the input-output devices.
//FT05F001 DD DDNAME=SYSIN
//FT06F001 DD SYSOUT=A,DCB=(LRECL=133,RECFM-FBA,BLKSIZE=133)
//FT07F001 DD SYSOUT=(B,,2),DCB=(LRECL=80,RECFM«FB,BLKSIZE=80)
//SYSUDUMP DD SYSOUT*A
//GO.FT21F001 DD UNIT=DISK,SPACE=(80,(3)),DCB=(RECFM=FB,LRECL*80,
// BLKSIZE=80)
//GO.FT22F001 DD UNIT=DISK,SPACE*(105,(100)),DBC=RECFM=FB,LRECL=105,
// BLKSIZE=2100,BUFNO=1)
//GO.FT23F001 DD UNIT=DISK,SPACE=(70,(50)),DCB=(RECFM=FB,LRECL=70,
// BLKSIZE=1400,BUFNO=1)
//GO.FT24F001 DD UNIT=DISK,SPACE=(950,(20)),DCB=(RECFM=FB,LRECL=950,
// BLKSIZE=9500,BUFNO=1)
//GO.FT25F001 DD UNIT=DISK,SPACE=(50,(450)),DCB=(RECFM=FB,LRECL=50,
// BLKSIZE=1000,BUFNO=1)
//GO.FT26F001 DD UNIT=DISK,SPACE=(50,(25)),DCB=(RECFM=FB,LRECL=50,
// BLKSIZE=1000,BUFNO=1)
139
-------
//GO.FT27F001 DD UNIT=DISK,SPACE=(80,(125)),DCB=(RECFM=FB,LRECL=80,
// BLKSIZE=1600,BUFNO=1)
//GO.FT29F001 DD UNIT=DrSK,SPACE-(140,(360)),DCB=(RECFM=FB,LRECL=140,
// BLKSIZE=2800,BUFNO=1)
//GO.SYSIN DD *
User-prepared input records I
Figure 33. JCL for Input - Output Files
These control statements would have to be modified if any changes are
made to increase the space requirements of the files or if the actual
devices are to be altered.
WRAP Input Sequence
The WRAP program may be executed from a card deck, a magnetic
tape, and/or a disk file. Under any and all conditions, a particular
input sequence must be followed. Options for Input variations are not
presented here; for these a user should refer to his facility. This
section does not discuss user data, but presents information on how to
input the prepared data and the program into a computer.
The input execution sequence for a WRAP object deck is shown in
Figure 34. The input sequence checklist should include:
1. Request for appropriate region size on the
Job Card (REGION = XXXK), where XXX is thousands
of bytes of storage.
2. Request for enough execution time for completion
of the execution (TIME = mm) where mm 1s number
of minutes of computer time.
3. Ordering of input deck:
job control card(s)
job execution card
object deck
overly control cards
I/O file description cards
CONTRL first user's input record
Optional control record CNTR2
TITLE record
140
-------
V-'
sT'.rvr r AS i si
TRUCK DMA
TRA!, SPORT i /
TATI:N DATA
:snr./pROc:ss
DATA
// 7
,' PROCESS 1
L. ... DATA
// J\_
SITE DATA
I SOURCE DATA
* I CROWFLY DATA
^ (
I TITLE
I/
* .''CONTROL DATA
i/o DEVICES! _
OCL
J
/
1
Lir,
Job
// OVERLAY /
' ' CARDS 1 1
' "~ A \ /
" OBJECT / J/
/ DECK / \
, i /
:K i.p/\n ! /
C.ird ' i
*ontionaT Input cards
depending on user
requirements
(Contains REGION statement)
Figure 34. Card Deck Setup for WRAP Execution
141
-------
Optional CRWFLY record
SOURCE records
SITE records
Process records in sets by process
identification code (each set
PRC1, PRC2, LNKI, optional LNKO,
and PRCOST records)
SIPR records
TRANS records
Optional TRUCK records
Optional Starting Basis records
For format specifications for the input records refer to Ap-
pendix I.
The user may execute WRAP from other input devices. Only the
control statements are affected by such a change, the actual input
sequence must remain the same. For information on how to make these
changes, consult with your computer installation.
If for any reason the overlay structure is not to be used, then
the overlay statement records need to be removed from the input se-
quence and the REGION request increased by 100K bytes.
Error Messages and Actions
General
The WRAP error messages are listed in this section by error num-
ber. There are some unnumbered messages which are listed first. The
format for the messages as presented here is:
Error NUMBER "message" ROUTINE
Action: what happens in WRAP
Remedy: what must be done to correct the error.
where "message" is the message as written to output file JEF, and
ROUTINE is the name of the subroutine where the error is detected.
As stated before, some errors are severe and cause immediate
termination of WRAP. Other errors are not in themselves severe and
therefore are warnings of possible future problems which will cause
142
-------
the immediate termination of WRAP. Still other errors cause a de-
layed termination, that is execution will terminate but only after
as much processing as possible is accomplished. These last errors
usually occur in the EDIT2 module.
Unnumbered Messages
"LINKAGE MISSING FOR CROWFLY =
MISS =
Action: If ICROW = 0 or 1 then program
terminates after executing list-
out of transportation activity file.
Remedy: Check input transportation records,
and source and site-process records
for proper Unking and complete use.
"USER REQUESTED SHORT RUN __ PCROW/PMODEL"
Action,: Program terminates after punching
either transportation activity
records or matrix model vectors.
Remedy: Check control card codes for PCROW
and/or PMODEL if this action was
not desired.
"DEFAULT VALUE SET FOR
Action:
VAR1 IS SET"
Remedy:
Program continues after setting
a default value in storage location
'var'.
Check CONTRL record for missing
variables or mispunched values.
Correct and resubmit.
"CROWFLY VALUE MISSING:
Action
ICROW WAS SET TO 0"
Program continues after setting
ICROW = 0.
BeiDej3y_: Since this error may cause an
error later, check the CONTRL
record fields and the CRWFLY
record for all variables.
MAIN
MAIN
DEFLT
CRWFLY
143
-------
"'PRNAME1 'PRID' 'PRLEVL1 IS A VALID PROCESS,
BUT HAS 0% OUTPUT"
Action: Program continues
Remedy; None required. This is only a
message to user about his process
codes and output waste amounts,
since ultimate sites, D level
are the only ones assumed to have
0% output.
"NYEARS SET EQUAL TO SUM OF MYEARS PER PERIOD =
'YRSUM'"
Action; Program changes value stored in
NYEARS if it differs from the sum
of years in all model periods.
Execution then continues setting
NYEARS to the computed year total.
Remedy: Check control record for NYEARS
variable and MYEAR/period values.
"****THIS PROGRAM HALTS BASIS NOT GOOD****"
Action; Program terminates
Remedy: Check application problem
and starting basis values.
Starting basis is causing
infeasible solution.
"SLACK OR ARTIFICIAL IN BASIS BUT NOT IN COLUMN
TABL"
Action: Program continues, does not include
slack or artificial in final report.
Remedy: Check application problem.
Numbered Messages
2.00.01 "HALT ON READING BASIS - BAD DATA OR
INPUT FORMAT"
Action: Program stops immediately.
PROCES
CNTCHK
IN IT
OUTBAS
TEASIS
144
-------
Remedy: Check starting basis Input
records, be sure all entries
are valid and no spaces are
imbedded between fields.
2.01.01 "PROGRAM HALT AFTER CONTRL - SEVERE ERROR EDIT1
ON CONTROL CARD"
Action: Program terminates after CONTRL
subroutine.
Remedy: Check data entries on CONTRL
record. See User's Guide'.
2.01.02 "PROGRAM HALT AFTER CRWFLY - CROWFLY EDIT1
OPTION WAS SET TO ZERO. BUT NO TRANSPORTATION
CARDS TO BE SUPPLIED."
Action: Program terminates after
CRWFLY subroutine execution.
Remedy: Check ICROW value and NTRANS
value on CONTRL record. Also
check input deck sequence and
card code values.
2.02.01 "HALT ON READING CONTROL - INVALID CARD #1 ID CONTRL
CODE OR CARD OUT OF SEQUENCE."
Action: Program terminates.
Remedy: Check input sequence and con-
trol card code on first input
record.
2.02.02 "HALT ON READING CONTROL - INVALID CARD #2 CONTRL
ID CODE OR CARD OUT OF SEQUENCE."
Action: Program terminates.
Remedy: Check execution mode and 2nd
input record control code field,
should be CNTR2 if mode is dynamic.
2.02.03 "HALT ON READING CONTROL - INVALID TITLE CONTRL
CARD ID OR CARD OUT OF SEQUENCE."
Action: Program terminates.
145
-------
Remedy; Correct card code TITLE
and check Input sequence.
2.02.04 "HALT ON READING CONTROL - BAD INPUT DATA CONTRL
OR CARD OUT OF SEQUENCE."
Action: Program terminates.
Remedy: Check Input control records
a card has an error (mispunch,
multipunch, etc.) or 1s an end
of file card.
2.02.1". "STATIC MODEL, BUT NUMBER OF PERIODS NOT CONTRL
EQUAL TO ONE"
Action: Program continues with error
flag set which may cause
termination later.
Remedy: Check control data input record to
correct for inconsistency.
2.02.12 "DYNAMIC MODEL, BUT NUMBER OF PERIODS EQUAL CONTRL
ONE"
Action: See 2.02.11
Remedy; See 2.02.11
2.02.13 "INVALID NUMBER OF YEARS FOR AN EXISTING CONTRL
PERIOD."
Action; Warning message. Program
continues, may terminate
later.
Remedy: Check control input record for
modeling years within valid range.
2.02.14 "INVALID TOTAL YEARS IN MODEL" CONTRL
Action: See 2.02.13
Remedy: Check control input record
for validity of data.
146
-------
2.02.15 "NUMBER OF SOURCES (NSOURC) IS NOT IN
VALID RANGE."
Action: See 2.02.11
Remedy: See 2.02.14
2.02.16 "NUMBER OF INTERMEDIATE SITES (NISITE) IS
NOT IN VALID RANGE."
Action: See 2.02.15
Remedy: See 2.02.14
2.02.17 "NUMBER OF ULTIMATE SITES (NUSITE) IS NOT
IN VALID RANGE."
Action: See 2.02.13
Remedy: See 2.02.14
2.02.18 "TOTAL NUMBER OF SITES IS TOO LARGE."
Action: Error flag is set to
warning. Program may
terminate later.
Remedy: Check problem sizing then
restrictive application.
Check for validity of count
fields NISITE and NUSITE.
2.02.19 "NUMBER OF PROCESSES (NPROCS) IS NOT IN
VALID RANGE."
Action: See 2.02.18
Remedy: Check NPROCS entry. Recheck
problem application for correct
sizing limitations.
2.02.20 "NUMBER OF SITE/PROCESSES (NSIPR) IS
NOT IN VALID RANGE."
Action: See 2.02.18
Remedy: Check NSIPR value. Recheck
problem application for
correct input sizing
limitations.
CONTRL
CONTRL
CONTRL
CONTRL
CONTRL
CONTRL
147
-------
2.02.21 "NUMBER OF TRANSPORTATION ACTIVITIES NOT CONTRL
IN VALID RANGE."
Action: See 2.02.18
Remedy: Check NTRANS to be sure it
fits the program sizing
limitations.
2.02.22 "CROWFLY MODE IS 0 AND NUMBER OF TRANSPORTATION CONTRL
ACTIVITIES (NTRANS) IS LESS THAN ONE."
Action: 2.02.18
Remedy: Check ICROW and NTRANS for
data validity. Refer to
User's Guide for correct
usage of codes.7
2.02.23 "TRUCK-CONSTRAINT EXISTENCE CODE INCONSISTENT CONTRL
WITH NUMBER OF TRUCK CONSTRAINTS (NISTRK)."
Action; 2.02.18
Remedy: Check ITRUCK and NISTRK entries.
Refer to User's Guide for code
usage information.7
2.02.25 "VALUE GIVEN FOR STANDARD TURNAROUND TIME CONTRL
IS INVALID."
Action; 2.02.18
Remedy: Refer to User's Guide for
data preparation limitations.7
2.02.26 "VALUE GIVEN FOR PACKER VEHICLE CAPACITY CONTRL
IS INVALID."
Action: 2.02.18
Remedy: 2.02.25
2.02.27 "VALUE GIVEN FOR TRANSFER VEHICLE CAPACITY CONTRL
IS INVALID."
Action: 2.02.18
Remedy: 2.02.25
148
-------
2.02.29 "DISCOUNT RATE IS NOT IN VALID RANGE."
Action: 2.02.18
Remedy; 2.02.25
2.03.01 "HALT ON READING CROWFLY - BAD INPUT DATA."
Ac t ion: Program terminates.
Remedy: Check input record for bad
data fields.
2.03.02 "HALT ON READING CROWFLY - INVALID ID CARD."
Acti on: 2.03.01
Remedy: 2.03.01
2.04.01 "HALT ON READING SOURCES - INVALID CARD ID
CODE OR CARD."
Action: 2.03.01
Remedy: 2.03.01
2.04.02 "HALT ON READING SOURCES - BAD DATA OR
INCORRECT NUMBER OF SOURCE CARDS."
Action: Program terminates.
Remedy: Check input sequence. Check
records for bad data entries.
2.04.11 "INVALID SOURCE IDENTIFICATION NUMBER _"
Action: Warning flag set. Program
may terminate later for another
error from this error.
Remedy: Check User's Guide for valid
source codes. Correct input
record.
2.04.12 "CROWFLY MODE NOT 0, BUT COORDINATES ARE
INVALID FOR SOURCE ."
Action: 2.03.11
CONTRL
CRWFLY
CRWFLY
SOURCE
SOURCE
SOURCE
SOURCE
149
-------
Remedy: Check User's Guide. Correct
data entries. If source is
linked, this error may not
be serious.
2.04.13 "STATIC MODEL, BUT TONS PER YEAR INVALID SOURCE
IN FIRST PERIOD FOR SOURCE ."
Action: 2.04.11
Remedy: Check input record for correct
placement of data. Refer to
User's Guide for valid data
entries.
2.04.14 "INVALID TONS PER YEAR FOR AN EXISTING SOURCE
PERIOD FOR SOURCE ."
Action: 2.03.11
Remedy: 2.03.14
2.04.15 "INVALID SOURCE HAUL COST FOR AN EXISTING SOURCE
PERIOD FOR SOURCE ."
Action: 2.04.11
Remedy: 2.04.13
2.05.01 "HALT ON READING SITES - INVALID CARD ID CODE SITE
OR CARD OUT OF SEQUENCE."
Action: 2.03.01
Remedy: 2.03.01
2.05.02 "HALT ON READING SITES - BAD DATA OR INCORRECT SITE
NUMBER OF SITE CARDS."
Action: 2.04.02
Remedy: 2.04.02
2.05.11 "INVALID CONSTRAINT CODE FOR SITE ." SITE
Action: 2.04.11
Remedy: Check User's Guide for valid
site constraint codes. Correct
input record.
150
-------
2.05.12 "INVALID SITE IDENTIFICATION NUMBER ." SITE
Action: 2.04.11
Remedy: Check User's Guide for valid
site identification codes.
Correct input record.
2.05.13 "INVALID NUMBER OF PROCESSES AT SITE ." SITE
Action: 2.04.11
Remedy: Check input record, then
refer to User's Guide for
process at site limitations.
2,05.14 "CROWFLY MODE NOT 0, BUT COORDINATES ARE SITE
INVALID FOR SITE ."
Action: 2.04.11
Remedy: Check User's Guide. Correct
data entries by adjusting
geographical coordinates.
2.05.15 "SITE IS A NON-ULTIMATE SITE WITH LAND." SITE
Action; 2.04.11
Remedy: Check site codes on record
for consistency. Refer to
User's Guide data preparation
information.
2.05.16 "INVALID LAND AVAILABLE FOR ULTIMATE SITE ." SITE
Action: 2.04.11
Remedy: 2.05.15
2.05.17 "INVALID LAND AVAILABLE FOR INTERMEDIATE SITE
SITE ."
Action: 2.04.11
Remedy; 2.05.15
2.06.01 "HALT ON READING PROCESS - INVALID HEADER 1 PROCES
ID OR CARD OUT OF SEQUENCE."
151
-------
Action: Program terminates.
Remedy: Check input sequence and
record identification codes.
2.06.02 "HALT ON READING PROCESS - INVALID HEADER 2
ID OR CARD OUT OF SEQUENCE."
Action: 2.06.01
Remedy: 2.06.01
2.06.03 "HALT ON READING PROCESS - BAD DATA OR
INCORRECT NUMBER OF PROCESS CARDS."
Action: 2.06.01
Remedy: Check input sequence. Check
input record data entries.
Refer to User's Guide for
data preparation procedures.
2.06.04 "HALT ON READING PROCESS COSTS - INVALID
COST CARD ID OR INCORRECT NUMBER OF COST
CARDS."
Action; 2.06.01
Remedy: 2.06.01
2.06.05 "HALT ON READING PROCESS COSTS - BAD DATA
OR INCORRECT NUMBER OF COST CARDS."
Action: 2.06.01
Remedy: 2.06.01
2.06.06 "HALT ON READING LINKS - INVALID INPUT
LINK CARD OR CARD OUT OF SEQUENCE."
Action: 2.06.01
Remedy: 2.06.01
2.06.07 "HALT ON READING LINKS - FIRST INPUT LINK
IS ZERO."
Action: 2.06.01
PROCES
PROCES
PRCOST
PRCOST
LINKS
LINKS
152
-------
Remedy: This is a special link which
indicates source linkage possible
it must be 1 or 2. Check input
record.
2.06.08 "HALT ON READING LINKS - INVALID OUTPUT LINK LINKS
CARD ID OR CARD OUT OF SEQUENCE."
Action: 2.06.01
Remedy: 2.06.01
2.06.09 "HALT ON READING LINKS - FIRST OUTPUT LINK LINKS
IS ZERO."
Action: 2.06.01
Remedy; Check codes on record.
Refer to User's Guide for
data preparation information.
2.06.10 "HALT ON READING LINKS - BAD DATA OR LINKS
IMPROPER END TO LINKS."
Action: 2.06.01
Remedy; 2.06.09
2.06.11 "LEVEL CODE INVALID OR MISSING FOR PROCES
PROCESS ."
Action: Warning. Program may
terminate later because
of this.
Remedy: 2.06.09
2.06.12 "INVALID PROCESS IDENTIFICATION NUMBER ." PROCES
Action: 2.06.11
Remedy: 2.06.09
2.06.13 "INVALID PERCENT OUTPUT BY WEIGHT FOR PROCES
PROCESS ."
Action: 2.06.11
Remedy: 2.06.09
153
-------
2.06.14 "INVALID HAUL COST FOR PROCESS ."
Action: 2.06.11
Remedy: 2.06.09
2.06.15 "AVAILABILITY CODE INVALID OR MISSING
FOR PROCESS ."
Action: 2.06.11
Remedy: 2.06.09
2.06.16 "INVALID LIFE CODE FOR PROCESS ."
Action: 2.06.11
Remedy; 2,06.09
2.06.17 "INVALID NUMBER OF SEGMENTS FOR PROCESS
Action: 2.06.11
Remedy: 2.06.09
2.06.21 "INVALID COST IDENTIFICATION CODE FOR
PROCESS ."
Action: 2.06.11
Remedy: 2.06.09
2.06.31 "INVALID SOURCE INPUT LINK INDICATOR
FOR PROCESS ."
Action: 2.06.11
Remedy: 2.06.09
2.06.32 "INVALID INPUT LINK IDENTIFICATION NUMBER
FOR PROCESS ."
Action: 2.06.11
Remedy: 2.06.09
2.06.33 "INVALID OUTPUT LINK IDENTIFICATION NUMBER
FOR PROCESS
PROCES
PROCES
PROCES
PROCES
PRCOST
LINKS
LINKS
LINKS
154
-------
Action: 2.06.11
Remedy: 2.06.09
2.07.01 "HALT ON READING SITE/PROCESS - INVALID SIPRC
CARD OR ID OR CARD OUT OF SEQUENCE."
Action: Program terminates.
Remedy: Check input sequence and
input record identification
codes.
2.07.02 "HALT IN SITE/PROCESS - BAD DATA OR SIPRC
INCORRECT NUMBER OF SITE/PROCESS CARDS."
Action: 2.07.01
Remedy: Check input records and data
entries. Refer to User's
Guide for data preparation
instructions.
2.07.11 "INVALID SITE ID - FOR A SITE/PROCESS." SIPRC
Action: Warning. Error flag set
to terminate after finishing
edit check.
Remedy: 2.07.02
2.07.12 "INVALID PROCESS ID FOR A SITE/PROCESS." SIPRC
Action: 2.07.11
Remedy: 2.07.02
2.07.13 "INVALID SITE/PROCESS CAPACITY FOR SITE ." SIPRC
Action: 2.07.11
Remedy: 2.07.02
2.07.14 "INVALID SITE/PROCESS 'WHICH SEGMENTS' SIPRC
FOR SITE ."
Action: 2.07.11
Remedy: 2.07.02
155
-------
2.07.15 "INVALID LEVEL CODE FOR SITE ."
Action: Warning. May cause
other errors later.
Remedy: 2.07.02
2.07.16 "PROCESS DATA NOT FOUND FOR PROCESS
ON SI/PR"
Action: 2.07.11
Remedy: 2.07.02
2.08.01 "HALT IN TRANSPORTATION - INVALID CARD ID
OR CARD OUT OF SEQUENCE."
Action: Program terminates.
Remedy; 2.07.01
2.08.02 "HALT IN TRANSPORTATION - BAD DATA OR
INCORRECT NUMBER OF TRANSPORTATION CARDS."
Action: 2.08.01
Remedy: 2.07.02
2.08.11 "INVALID TRANSPORTATION ACTIVITY TYPE CARD
Action: 2.07.11
Remedy: 2.07.02
2.08.12 "INVALID TRANSPORTATION ORIGIN ID ."
Action: 2.07.11
SIPRC
Remedy: 2.07.02
2.08.13 "INVALID TRANSPORTATION DESTINATION ID _
Action: 2.07.11
Remedy: 2.07.02
2.08.14 "TRANSPORTATION TRAVEL TIME IS ZERO, BUT
CROWFLY OPTION WAS NOT REQUESTED ."
156
SIPRC
TRANS
TRANS
TRANS
TRANS
TRANS
TRANS
-------
Action: 2.07.11
Remedy: 2.07.02
2.08.15 "INVALID TRANSPORTATION PROCESS ID ." TRANS
Action: 2.07.11
Remedy: 2.07.02
2.08.16 "TRANSPORTATION PROCESS FOR SOURCE TRANS
DOES NOT MATCH ORIGIN ID."
Action: 2.07.11
Remedy: 2.07.02
2.09.01 "HALT IN TRUCK READS - INVALID CARD ID TRUCK
OR CARD OUT OF SEQUENCE."
Action: 2.07.01
Remedy: 2.07.01
2.09.02 "HALT IN TRUCK READS - BAD DATA OR INCORRECT TRUCK
NUMBER OF TRUCK CARDS."
Action: 2.07.01
Remedy: 2.07.02
2.09.11 "SITE ID IS INVALID ON A TRUCK TRUCK
CONSTRAINT CARD."
Action: 2.07.11
Remedy: 2.07.02
2.09.12 "INVALID TRUCK CONSTRAINT VALUE GIVEN TRUCK
FOR AN EXISTING PERIOD."
Action: 2.07.11
Remedy: 2.07.02
3.01.01 "SEVERE ERROR BEFORE SITE/PROCESS CHECKS - EDIT2
CANNOT CONTINUE EDIT2 CHECKS."
Action: Program terminates.
157
-------
Remedy: Check all previous error
messages. Refer to User's
Guide for data preparation
instructions.
3.01.02 "SEVERE ERROR IN EDIT2 - CANNOT CHECK
TRANSPORTATION FILE."
Action: 3.01.01
Remedy: 3.01.02
3.02.11 "MORE THAN ONE SOURCE RECORD INPUT FOR
SOURCE ID ."
Action: Warning. This error will
cause termination before
end of EDIT2 checks.
Remedy: Check input record. Reexamine
application. Refer to User's
Guide for data preparation
instructions.
3.02.12 "MORE THAN ONE SITE RECORD INPUT FOR SITE
ID __."
Action: 3.02.11
Remedy: 3.02.11
3.02.13 "MORE THAN ONE PROCESS RECORD INPUT FOR
PROC ID ."
Action: 3.02.11
Remedy: 3.02.11
3.03.11 "MANDATORY YEAR DATA IS INVALID (LESS
THAN OR EQUAL TO 0)."
Action: 3.02.11
Remedy: 3.02.11
3.04.11 "MORE PROCESSES FOUND ON SITE
THAN SPECIFIED ON SITE/PROCESS~CTRD."
158
EDIT2
ONENUM
ONENUM
ONENUM
CNTCHK
CKSIPR
-------
Action: 3.02.11
Remedy: 3.02.11
3.04.12 "PROCESS LEVEL DOES NOT MATCH SITE
LEVEL CODE FOR SITE."
Action: 3.02.11
Remedy: 3.02.11
3.04.13 "SITE/PROCESS LEVEL IS INCONSISTENT WITH
SITE ID "
Action: 3.02.11
Remedy: 3.02.11
3.04.14 "PROCESS COST CARD MISSING FOR A SEGMENT IN
A PERIOD PROCESS AVAILABLE TO BE BUILT "
Action: 3.02.11
Remedy: 3.02.11
3.04.15 "NUMBER OF SEGMENTS AND WHICH SEGMENTS
ARE . INCONSISTENT. SITE "
Action: 3.02.11
Remedy: 3.02.11
3.04.16 "AN EXISTING PROCESS IS READ ON MORE
THAN ONE SITE "
Action: 3.02.11
Remedy: 3.02.11
3.04.17 "NO RECORD INPUT FOR PROCESS "
Action: 3.02.11
Remedy: 3.02.11
3.04.13 "NO RECORD INPUT FOR SITE
Action: 3.02.11
CKSIPR
CKSIPR
CKSIPR
CKSIPR
CKSIPR
CKSIPR
CKSIPR
159
-------
Remedy: 3.02.11
3.05.11 "LINKAGE ALLOWED FROM LEVEL C PROCESS PRCHK
TO SOURCES."
Action; Warning. A source was linked
to a Level C and was accepted.
Remedy: Check link records, and transpor-
tation file inputs. Refer to
User's Guide for data preparation
instructions.
3.05.12 "INPUT LINK IS INCONSISTENT WITH LEVEL OF PRCHK
PROCESS "
Action: Warning. A level is linked
possibly to an incorrect level.
Remedy: Check process input records.
Refer to User's Guide for data
preparation instructions.
3.05.13 "AN INPUT LINK DOES NOT HAVE THE PROCESS PRCHK
AS A POSSIBLE OUTPUT LINK OR WAS NOT A PROCESS
ENTERED."
Action: Warning. Cross checking processes
are not compatible.
Remedy; Check process link records. Refer
to User's Guide.
3.05.14 "OUTPUT LINK INCONSISTENT WITH LEVEL PRCHK.
OF PROCESS "
Action: 3.05.12
Remedy: 3.05.12
3.05.15 "AN OUTPUT LINK DOES NOT HAVE PROCESS PRCHK
AS AN INPUT LINK POSSIBLE OR WAS NOT A
PROCESS ENTERED."
Action: 3.05.13
Remedy: 3.05.13
3.05.16 "NO PROCESS ALLOWS LINKAGE TO SOURCES1' PRCHK
160
-------
Action: Warning. Execution
terminates after EDIT2.
Remedy: Check input links records.
Check other errors generated.
Refer to User's Guide instructions.
At least one process must allow
sources to link.
3.06.11 "ACTIVITY TYPE DOES NOT MATCH ORIGIN AND TRNCHK
DESTINATION "
Action: Warning. WRAP terminates after
EDIT2.
Remedy: Check input record. Refer to
User's Guide for data preparation
instructions.
3.06.12 "DUPLICATE ID TRANSPORTATION RECORDS TRNCHK
FOUND WITH DIFFERENT TIME DATA "
Action: 3.06.11
Remedy: 3.06.12
3.06.13 "NO SITE/PROCESS RECORD WAS INPUT FOR AN TRNCHK.
ORIGIN/PROCESS GIVEN "
Action: 3.06.11
Remedy: 3.06.11
3.06.14 "NO RECORD WAS INPUT FOR ORIGIN " TRNCHK
Action: 3.06.11
Remedy; 3.06.11
3.06.15 "NO RECORD WAS INPUT FOR DESTINATION " TRNCHK
Action: 3.06.11
Remedy: 3.06.11
3.06.16 "ORIGIN/DESTINATION LINK NOT POSSIBLE " TRNCHK
Action: 3.06.11
Remedy: 3.06.11
161
-------
3.07.11 "DUPLICATE TRANSPORTATION RECORDS FOUND DUP
FOR ORIGIN ONE WAS DELETED."
Action: Warning. This does not
cause any subsequent error.
Remedy: Check input record sequence.
4.03.01 "NO LINKS FOUND IN ICROW2 MODE FOR A ICROW2
SITE ORIGIN."
Action: Program terminates.
Remedy: Check process records
for input and output
possible links, Correct
for missing linkage.
4.04.11 "A DESTINATION WAS NOT LINKED" LNKBLD
Action: Program continues.
Remedy: This is a warning message.
The user has supplied a site,
but has not provided an input
link to the site. Check site
record inputs and transportation
activity records.
4.05.01 "TOO MANY TRANSPORTATION LINKS BUILT IN DUPWRT
CROWFLY"
Action; Program terminates.
Remedy: Recheck application. Increase
transportation activities supplied
by user, or change (tighten)
crowfly measurements because
more than 450 transportation
activities are being generated.
4.06.01 "TOO MANY TRANSPORTATION LINKS BUILT IN CRWLNK
CROWFLY"
Action: Program terminates.
162
-------
Remedy: More than 125 links are made
for one waste origin. Recheck
application problem. Tighten
crowfly maximum radius value
to reduce links possible.
5.01.01 "MAXIMUM NUMBER OF COLUMNS IN CREATING COLUMN
TRANSPORTATION COLUMNS"
Action: Program terminates.
Remedy: Check application problem.
Choose another program version
if dimension size is a problem.
Check User's Guide.
5.01.02 "MAXIMUM NUMBER OF COLUMNS EXCEEDED COLUMN
IN CREATING SITE/PROCESS COLUMNS."
Action: Program terminates.
Remedy: Check application problem.
Recheck sizing procedures
refer to User's Guide.
5.01.03 "MAXIMUM NUMBER OF COLUMNS EXCEEDED IN COLUMN
CREATING K COLUMNS"
Action: Program terminates.
Remedy: See 5.01.02
5.01.04 "MAXIMUM NUMBER OF COLUMNS EXCEEDED IN COLUMN
CREATING S COLUMNS"
Action; Program terminates.
Remedy: See 5.01.02
6.01.00 "MATRIX VECTORS EXCEED DIMENSIONS" SETR
Action: Program terminates. SETC
Remedy: Equations and coefficients
exceed allowable space.
Check sizing procedures
in User's Guide.
163
-------
11.1.4 "THE CURRENT BASIS IS NOT INVERTABLE. REINV
RE INVERSION WAS PROCEEDING FROM THIS
INITIAL BASIS (LIST) TO THIS CURRENT
BASIS (LIST) WITH THE ACTIVITIES
INDICATED BELOW ALREADY TRANSFORMED
(LIST). THE ACTIVITY WITH THE
CURRENT FORM (LIST) HATM COMPUTA-
TIONALLY FEASIBLE PIVOT ELEMENT."
Action: The program terminates.
Remedy: Reexamine application
problem definition.
11.1.5 "THE CURRENT BASIS IS NOT INVERTABLE. REINV
IT HAS A NEGATIVE ACTIVITY LEVEL, BASIS
(LIST), LEVEL (LIST)."
Action; The program terminates.
Remedy; Reexamine application
problem definition.
11.1.6 "NUMBER OF ELEMENTS IN INITIAL-A-MATRIX, SETUA
INCLUDING REQUIRED SLACK AND SURPLUS
VARIABLES HAS EXCEEDED THE LIMIT ALLOWED
FOR STORAGE. PROBLEM TERMINATED DUE TO
INITIALIZATION PROCEDURES OVERFLOWING
AVAILABLE STORAGE."
Action: The program terminates.
Remedy: Refer to matrix sizing
instructions for the method
of predetermining number of
elements that will be in the
A-matrix.
164
-------
11.1.7 "NUMBER OF COLUMNS, INCLUDING REQUIRED SLACK SETUA
AND SURPLUS VARIABLES, HAS EXCEEDED THE LIMIT
ALLOWED FOR STORAGE. PROBLEM TERMINATED DUE
TO INITIALIZATION PROCEDURES OVERFLOWING
AVAILABLE STORAGE.
Action: Program terminates.
Remedy: Refer to sizing instructions
for determining maximum number
of columns that will be established
for the matrix.
11.1.8 "DUPLICATE ROW AND COLUMN LOCATIONS FSORT
ENCOUNTERED DURING SORT ROUTINE"
Action: Program terminates.
Remedy: Reexamine problem and
matrix structuring
specifications.
11.1.9 "UNBOUNDED SOLUTION WITH COLUMN IN THE REMOV
BASIS."
Action: Program terminates.
Remedy: Reexamine application and
starting basis entries.
11.1.10 "MATRIX OVERFLOW" SWAP
Act i on: Program terminates.
Remedy: Reexamine application problem.
Check sizing procedure then use
larger version if necessary.
165
-------
11.1.11 "NO FEASIBLE SOLUTION" SWAP
Action: Program terminates.
Remedy: Reexamine application and
input variables. Recheck
User's Guide for help on
preparing Inputs.
11.1.11A "ERROR Z COLUMN IN BASIS. PROGRAM HALTS" SWAP
Action: Program terminates.
Remedy: Recheck application problem
and input specifications.
Final solution is not feasible.
11.13.1 "ERROR NEW COLUMN TO BE INSERTED. OLD SETUB
COLUMN = , NEW COLUMN = "
Action; Program continues. Changes
columns in the basis solution
to remove negative activity
levels.
Remedy; Recheck application and starting
basis input values.
166
-------
REFERENCES
1. Walker, W. Adjacent extreme point algorithms for the fixed charge
problem. Technical Report No. 40. Ithaca, N. Y., Cornell University,
College of Engineering, Department of Operations Research, Jan. 30, 1968.
23 p.
2. Berman, E. B. A model for selecting, sizing, and locating regional solid
waste processing and disposal facilities. M73-111. Bedford, Mass., The
MITRE Corporation, Oct. 1973. 61 p.
3. Berman, E. B., and H. J. Yaffe. Region design analysis for regional
resource recovery system for northeastern Massachusetts. MITRE
Technical Report MTR-2945. Bedford, Mass., The MITRE Corporation,
Nov. 1974. 39 p.
4. Walker, W. E. A heuristic adjacent extreme point algorithm for the
fixed charge problem. P-5042. New York, The Rand Institute,
June 1973. 21 p.
5. FCSS; the fixed charge solution system; user manual, (n.p.), Compuvisor
Inc., Mar. 15, 1970. 21 p.
6. MITRE Corporation. WRAPping up the solid waste management problem: a
model for regional solid waste management planning. Washington,
U.S. Environmental Protection Agency, Office of Solid Waste Management
Programs, 1976. (In preparation.)
7. Berman, E. B. (MITRE Corporation). WRAP, a model for regional solid
waste management planning: users' guide. Washington, U.S. Environmental
Protection Agency, Office of Solid Waste Management Programs, 1976.
(In preparation.).
8. Berman, E. B. WRAP, a model for regional solid waste management planning:
documentation of operational and exercise runs. MITRE Technical
Report MTR-3219. Bedford, Mass., The MITRE Corporation, 1976. (In
preparation.)
9. IBM System/360 and System/370 FORTRAN IV language, llth ed. GC28-6515-10.
New York, IBM Corporation, May 1974. 169 p.
10. IBM System/360 Operating System: job control language reference.
OS Release 21.7. GC28-6704-3. New York, IBM Corporation, Apr. 1973.
361 p.
11. IBM System/360 Operating System FORTRAN IV (G and H) programmer's guide.
GC28-6817-4. New York, IBM Corporation, Sept. 1973. 257 p.
167
-------
APPENDIX I
FILE FORMATS AND CONTENTS
Appendix I contains a table of input variable names, record formats
for input data, descriptive sheets for the temporary storage files and
formats for the punched matrix data. For definitions and descriptions
of the input variables, refer to the common storage tables in Appendix
III, since all input variables are allocated space in a common area.
168
-------
VARIABLE NAMES BY INPUT RECORD CODES
CARD CODE
CONTRL
CNTR2
TITLE
CRWFLY
SOURCE
SITE
PRC1
PRC2
LINKI
LINKO
PRCOST
SIPROC
TRANS
TRUCK
VARIABLE NAMES
JUMP, MTYPE, LPHASE, NFORC, KOPT, INDSD, IBASE,
PBASE, ICROW, PCROW, PMODEL, ITRUCK, NPERID,
NSOURC, NISITE, NUSITE, NPROCS, NSIPR, NTRANS,
NISTRK, STURNT, NYEARS, MYEAR(4), TRPACK,
TRTRAN
CINFLR, CDISCR
TITLE(19)
RADIUS, FACTR, SPEED
CODE(2), SOID, SONAME(5), SOLONG, SOLAT,
SOTONS(4), SOHC$(4)
CODE, SIID, SINAME(5), SICODE, SILONG, SILAT,
SIPROC, SICOST, SILAND
CODE, PRID, PRNAME(5), PRLEVL, PREXST, PRWGT,
PRDEN, PRHC$(4), PRLEAD
CODE, PRAVAL(4), PRLIFE(4), PRSEG, ID
CODE, LINKI(18), ID (repeat for second card)
CODE, LINKO(18), ID (repeat for second card)
CODE(2), PPERIOD, PSEG, PRCSLP(i), PRCINT(i),
PROSLP(1), PROINT(I), ID
(where 1B1, to 12 on separate records)
CODE(2), SPIDS, SPIDP, SPSEG, SPCAP, SPREV$(4).
SPLVL
CODE(2), ACODE, AOID, AOPR, ADID, ATIME,
ADISI, ASPEED
CODE(2), TRSI(3), TRNO(4)
169
-------
AL.THCS
'PSOGSAWMAME i PROGRAM NUMBER
STATEMENT
"c~l so-
.1 ;
ClA
j *
RD.
CO
-J _»
!
•
r
1
1
S
D
-
s
,
C10N.T
1
I"1
R
f
4-r
CiARrD
xf
~f-
0;"D
1 '
E
H---J-.
T^
C!N
1
I
1
C|AR
c
1
ClA
C
1
j
o
T
R
0
R
D
0
Z
E
L
-
D
CIRjWF
E
E
iL
s
T
«
^
_
Y
COBTRAN STATE*
DATE
i s' c :i 12 a v 3 i< :• a 3 r 21 22 n n z »|nja s a 31 2
«
i ?
a b
-> »
h
j
*§L
L
•
c
5
%
•
C
ft
t
C
*
>
±
j
t
': J
! i i
*-
0
z
M
i , \
O
-«
>
5
*
O
o
1 ! ' ~l : ':.-h!
^
7|JT
i
,
g|j
-J
SZ
: i
Fl
1
> |S
J 2
j"
'I
\ 1 i
I !
! S
i = i
-
L
i
< J
! : ' '. : '
S !
• .. j i
b
j
1 I
j
i
: n
1 1
; Jli:
'
j
f
j
9-*!
**"•
: :• '
|
Ii
t-
t
K
at
I
. i !
O
d
a
IT
C
£
i
-
ID
01
a
9
E
t.
o
HJ
TK
33J435K J'illMe .IVC'* «,«««'«!» il 5253 54
J i»
i ''
t
N
IT
0
U
S
Z
-
t
ei
L
i
f
o-
•f a
a 5
— j
it
•
t
k.
O *
W 0
fl
f
T.
—
l)
^
DO
4
i
—
-
i
' i i
i
1 Z '
i o
Ei
, f
|-
•
•
»
-
S
f
i
4
—
t
i
t
°;
s«
"r
_i-
i
55 56 5?l M » SO 61 SJ S3 w! 65 « er' a B HlJ'l
c
j
*
-
o"^"
Ml6
,
-p
ii
52
i-
.
-
inmiirto
(
1 YE*** EMM ,
' ! P>E»K>0 '
1 1
)
f
1
!
72
.
4
'AGE
>F
oe/nnCATK>N
1
J dF
TRUCK
i
1
'
—
l
i
.
79
1
L
to
--
-------
AUTOS
STA-EME.HT
C '
1 .
_L
i « ;
CIARD
ICOD E
I
1 -
L ! :
.
t
J FORTRAf, STATEMENT
i •
SjO U R C E
|-
1
T
f
-4-
i
i
i
i
\-
\
i
' t
|
-~--
i j
"I"*
-
-
j
i
••
i
r
'
i i' s :i u.
•
1-8
,
i j
. '
, I
', \
i i
; ;'
i
(
i
i
i
— -
13
H
a
a r
V
PROGRAM NAME j PSOGRAH MfclfiER ' OATE
9 r, Ii'22'23 2*;5
X.27
21 a MjJl H\B,VX!X'V'»'-'n'.*lv. 12
• . • tOUt'l RAMI 1
; HOIttt COtC (08- 4»») : i '
' ' " " ' ; ' 1
' i
j 1
.
f
l
r '
f ' f
" [ '
: E
t
, f ; 1 I
1 , AJ
' ,, i ' i
i i
i 1 I
M M
i
j '
j
i
S
'
|
i
r
i ' ' " r h f
i'
'
II
i 1
'
• JL
;
I i \ M
MM
f !
i
i
i
i
1
s
1
i
i
1 '
Is
a S
55 S52
x w 1 a J:
j
w, -
I I '
~!_IT
,
; ^
'
3
.
. -
•I? . *i
1 1
' 1 :
i
j
i
1
— — •--
i
i ^
a «
i j
e-'g c
~pr«
' >• i
'
(i
JPK
MX
rod
6
SC SI
S2 S3 M
55
MJSJ'H'H
e taiMAJae '
ro»a /TEAK
PC* too
i
I i
;
; ill | I
' i1! i
• i * t
—T+-
-r-k
j
i
v
«
<
i •
i
TJ
— i
' i '
-^
—
i
1 ;
i *
,(
,T*CA™
n
M 7^
! ' *ouotc Kta. coir • •
l* » rt* TOC-KOI
I'1''.'.'**
mtoa i
! i
i
>--
1 1 ; 1*1 ' l ' *
^
i^
.
-
-
-'
j
-1
f j , I
.
'
'
;
i
• '
1
1
_L
-
!
4
I
h- — i —
_LU
i —
~
--
-
-------
ro
A,-,**
ST*TE*EST
C;A
3 4
C'ODE
;
1
' j
SJl TE
1
-M
i !
4-1
11
I
i
i
t
i
-
—
-I
:
"-"1
i-
—
5
t
}
T
F<*r,>,
('I I J I
I*
Jls
a
.
i
i
i
\
i
\
',
i
:
i
i
I
ST*T&W
^OGRA-H^
PROGRAM MJW8ER
DATE
"- ' *\ ; '"; 1 - Ji '- i ' i
ttm caD^pcxM «»i l
;
1 ;
; ! i ' i
• • . , •
f i f 1
I \
i f ' •
; ' 1 !
! f
1 I
i
1 * » 1
i-'^
i
I
j
1 i
i !
|
i •
.
i
(
i
i
\ \
1
-•
i
fc
I ;
,;
i
i i
(
f
[
I
i
s
I
*
ji »,»!* » »'» «;«
--
i
! ,
te . X
IUMI
I
t ;
> T
t
j
r
-
1
J.
Is
-f-
42
« 44
s
X
a ™
j
1
45
-
4£
M
M
u
o
E
0
o
-
47
« 49 B 51
M
l-
as
't S 8 i
l" S, 0 |
-
i
~
S* a 56.JT MASS'S! 51 62
-
-
1
; i
L*s
31*
j
-H-t
i
JJ
!
t'
-
-
j i1
-
1
i
i !
Q H 8 K 67
1
I • : i
I
f
i
! i1 t
ii ; ' '
""
;
J
1
'
«
i
i
_
-
B
n
71
72
'AGE
5F
D&mnCAnoN
74
--
75
75
77 78
79 0
-------
ALTMOS
STATQlE.N"
c"! *°-
i
C'A
i i i
=t D
ClOOE
1
I ,
—
P-R"C~
I
I 1
i
b
i
-4
1
i
i
1
I
j
1
1
1
I
1
1
1
I
1
|
•
-f
-
C
0
M
T
«
f
FMT^^TE-E
i t » a.:: J J
•~
1
t
t
!
i •
;o|
f
i
-
j
i i
PROGRAM NAME ' PROGRAM NUW3ER j DATE
f :
^
^ a M'll B S K 2!|22 ZJ,24;25J« 27 i S^'joilM! , S3 J/JiVj? 3»'«|«.4!-42. O M 6- « C 4»J48,a|51
nioecii •«« !
(PMCM* «Xt fOtfll 1 ' ' •
1
!
\
i
f
j
—- 1
1
i
t
i
' '
_
I
i
— !— ^
I
!
: j
i
i
'
i
"""
1*
: i
i
— t
H
—
i
-•
;
j
»
c.
^f?t-
!
-
—
— ( — ( —
i !
-4-
Ir
i
-j 1
' j
.
tr
•i~r t
,
j
-
;
-
!
52 U W
I
55
i
i
i
•
i
f
-
;
-
-
FM «*»!<•> ' T '
! ' ' i > ; '
____ _j
i <
j
-
.
-
-
-'
-
i " '
-Trf-*-
-
TT1
i i '
_
-
( : '
-
i
" !
3
-~tr
r
— . —
j
i
•f
T
i
j
!
—
—
»
PAGE
Of
«*T*KA™
n i* n 76 r?
[ i
—i
-i
-i
1
h
. -i —
-
7! 79
-
-
K
-
-
-
-------
AUTHOR
PROGRAM NAME
PROGRAM NUMBER
DATE
PAGE
OF
'!'
i'4
ClAR
,0
ClOD'E
i i •
II
1
i
r
i-h-
|
PjR.C
-
-
1
J-
1
-
1
t
1
1
1
1
a
i
!
1
5 6
7 1
-
-
9
i
1
-
-
-
10
RVAILABL
-
-
-
11
i fc
9 .j
»
S3
3
-
._.
13 1
4
-
-
-
15
.
IS
-
1)
11
jj|3
=SB
£
-
» 20
-
?
4
2
23
24
25
K
27
a
n
30
31
a
w
32
n
34
35
n
37
39
3]
40
41
42
43
44
^
e
u
47
U
4)
50
SI
52
B
—
54
55
5C
5
58
»
6D
(1
12
a
64
65
0:
ei
61
i
69
7i
n
74
75
7C
77
-
71
i
h
C
«
Q
n
8
60
3~
J
~
-------
ALT-OP | PROGRAM NAME
^TAT^EN,
:|? i'i s
C-'A R D
\ ' '
ClOOE
.
L'NtK I
I ,
t- I i -
1
1 I
- t - T
1
f
fl
t
1
1
t
'
I
1
1
|
1
I
1
i
1
1
— t
1
— i
K
-I
— !
-
0
—
-
0
H
T
i
FO.T.AMSTAT**,
PROGRAM NUMBER
DATE
1 i B !; 2,13 'A £ %'V B'S'R 2!J22 23 M B 28 2)
•:»
111
J »
1-
!
~
;
»
i
__
i
"
|
|
; j
- — _
i i
. J
!
i
;
••
i
4
1
f '
j
i
-
' i
I
I
• r
?
[~
i
1 1
i
L i
,
29 29
i
3D
31 32
J3 J4 35 X 37 3t » «
-w
! i
4 —
i
41 U O it
1
1
i
t
i
--
..
1
«l« C
1
i :
1
; !
-
-
--
_
a e ss'si
--
-
52 S3 M
"
-
S
it
57J M 49 6C (1 U »V B S ST| «| B
-
_
-
-
-
1
i
i
i
i
-
ft
i
i
-
i
i ;
1
^
i
_
» 71
-
_
77
PACE
OF
^^CAIK*
73
_
74I7SI76 77
-
-
-
-
-
n
.
b
1
n'M
Q
M
*j
-
-
-
r~
—
-
-------
PROGRAM NUMBER
DATE
PAGE
OF
' STi *£«£}<•
FCftTSAN STATEMENT•
DBfTOCATlON
«. 17! *;»!»'
CiARD
CM If At!
tLOft
;M 3t,
i1?"?*!'": ;
MM
II »2|O
t
i;sij>;|aii4|2ii«i>r|«|i>'g!-H-
!COS T
"[-'--r-*-
LLLL
rr?'
I ' I
r^M
H- • i ! I i I i
-------
M**»
^T.TMHT
• 1.1 '
s
ClAR D
icoo
E
M '
? i
1 . ! .
s;i PR
c
° '
T
1 |7
OC
!
'
ZlU-
iH i
i
i
i
i
i
i
i
i
i
i
j ,
—
-
i
: i i
1 i
MTBAW 5T»TEu£N1
PROGRAM NAME
1 1 S{11 !};Q'H IS li 17
i
' <
S«2
"rF
, t
i ,
• !
;
i
(
!
j ;
Si-
T*f
• ,
!
; i
* a
^
B
s;
i
i
i
a
"|nia»a
j ,
lit1
IM
i
1
PROGRAM MUCER
DATE
a
a
a
a
3D
31
32
33
34
i
«i/e
i
37
•ml
'• j
j
i
; |
3i a
Ml 1
«
K
41
W
»
4Z
1
1
43
M
44
e
«
47
41 4
J »
,
SI
a
a
M
;
8
M
D
*
a
*
s>
•
a
«
.
M
12
|
O
(4
*
H
i7
a
e
n
71
72
PACE
OF
•KKT-CA™
73
74
n
7S
77
79
n
10
-------
»LTHO9
STATEMENT
c"! *>•
i ; ] '< i
C'A R D
ICO'DE
. i . . ,
I
M-L
T'R A
"1
1 — •
1
,'
1
_!__
. i. j
-r
_.j_.
i
i
i
N S
i —
~
-
i
£
T
i
-
:ORT«xs $TAT£M£SJ
PROGRAM NAME
PROGRAM NUMBER
DATE
i > a1 !! j L' 14 ;•) :» :; B s;s'n Z2'a;;4]ala
i
* ' M^
' 5«S.
' Sfft,
. S7S
f ;
TT"
it
'
i
1
~1
-
&
S«u
- -V—
i1
• !
;
i
5
So*
ZSo
M
i :
1
| i
i. i
i
,
i
I.
27
a
j
F^
"
j
1
-
29
30
»
1
•
c
31
&
12
z
33
•
•
j
•
«
-
3S
1
*
r a s « (i
l?l
£»(
^
—
1
i
I
:
1
C'C'U
i
!
i
: i
6i
?! I !
.•-;•;:
i
)
i
I
1
-------
A'wTrOft
C '
,!
l|< J.4 S
ClARO
1COD
E
• i '' 1
j ' -
t l
TsRUC
' i i
1 '
i '
1 S '
i \-
i
i
i
1
|
1
i
i
j
a
K
: 1
'
i
! :
f
1 ; •
1 !
i \
C
0
M
T
i
FORTRAX STATEMENT
PROGRAM NAME
71 J.»jUjU,D;t4 15
• [ fin it
:C4MCMX-»
^ j
' 1
^-
i
! _[_
b
')
1 t
E
t
•_ j t
1
i f
; 1
»
niu- n
i
i
B
a
|
H
i
a
23, NjS
1
i
PROGRAM NUMBER
DATE
»
•'
27 1
•h)
s
a
Kl
31 31 12
a »
•T
i
•
4
«
42
43
44
«
«
47
•
«
so! si
57
a
S4
S 5*
i
S)
»»,» u.'srcjM B;K c
!
i
i
*
P
i
;
-
-
,
-
v
-
»
71
n
PAGE
Of
CfNTtHCtnON
n
74
75
K
77
71
n
n
-------
Record: Starting Basis
Maximum Entries: 90
Maximum Value for Entries: 450
Record Format: 16(14, IX)
Variable: BASIS(90)
RECORD READ BY: TBASIS
RECORD PUNCHED BY: OUTBAS
Starting Basis Record Information
File Name: FILET
File Number; (for JCL) 21
Created In Routine: CONTRL
Retrieved In Routine(s); READIT
Minimum Records: 1
Maximum Records: 1
Record Length: 80 characters
Record Format: A4, A2, 18A4, A2
Record Variables: (in order of sequence 1n record) CODE(2),
TITLE (19)
FILE1 Record Format for Title Information
180
-------
File Name: FILE2
File Number: (for JCL) 22
Created In Routine: SOURCE
Retrieved In Routine(s); READIT
Minimum Records: 1
Maximum Records: TOO
Record Length: 105 characters
Record Format: A4, A2, 13, 5A4, 6F7.1, 4F7.5
Record Variables; (1n order of sequence 1n record) CODE(2), SOID
SONAME(5), SOLONG, SOLAT, SOTONS(4), SOHC$(4)
FILE2 Record Format for Source Identification Variables
File Name: FILE3
File Number: (for JCL) 23
Created In Routine; SITE
Retrieved In Routine(s); READIT
Minimum Records; 1
Maximum Records: 50
Record Length: 70
Record Format: A4, Al, 13, 5A4, IX, II, IX, 2(F7.1, IX), II,
F8.2, 16
Record Variables: (in order of sequence in record) CODE(2), SIID,
SINAME(5), SICODE, SILONG, SILAT, SIPROC, SICOST,
SILAND
FILE3 Record Format for Site Identification Variables
181
-------
File Name: FILE4
File Number: (for JCL) 24
Created In Routine: PROCES
Retrieved In Routlne(s): READIT, PRCHK
Minimum Records: 1
Maximum Records: 20
Record Length: 950
Record Format: 13, IX, 5A4, 3X, AT. IX, II, F7.2, IX, 14, IX,
4(F8.5, IX), II, 9(11, IX), 212, 7213, 1212,
12F11.6, 12F12.3, 12F11.6, 12F12.3
Record Variables: (in order of sequence 1n record) PRID, PRNAME(5),
PRLEVL, PREXST, PRWGT, PRDEN, PRHC$(4), PRLEAD,
PRAVAL(4), PRLIFE(4), PRSEG, LINKNO, OLNKO,
LINKI(36), SET(12), PRCSLP(12), PRCINT(12),
PROSLP(12), PROINT(12)
FILE4 Record Format for Process Identification Variables
File Name: FILES
File Number: (for JCL) 25
Created In Routine: TRANS, DUPWRT, ICROWT, tNKBLD
Retrieved In Routine(s); READIT
Minimum Records: 1
Maximum Records: 360 or 600
Record Length: 50 characters
Record Format: II, IX, 3(13, IX), 2X, F7.1, IX, F6.1, IX, F5.1
Record Variables: (in order of sequence 1n record) ACODE, AOID,
AOPR, ADID, ATIME, ADISI, ASPEED
FILE5 Record Format for Transportation Activity Variables
182
-------
File Name: FILE6
File Number: (for JCL) 26
Created In Routine: TRUCK
Retrieved In Routlne(s); READIT
Minimum Records; 0
Maximum Records; 25
Record Length: 50 characters
Record Format: A4, A2, 3(13, IX), 4(F7.1, IX)
Record Variables; (1n order of sequence 1n record) CODE(2), TRSI(3),
TRNO(4)
FILE6 Record Format for Truck Constraint Identification Variables
File Name: FILE?
File Number: (for JCL) 27
Created In Routine: SIPRC
Retrieved In Routlne(s); READIT
Minimum Records; 1
Maximum Records; 125
Record Length: 80 characters
Record Format: A4, A2, IX. 13, IX, 13, 3X, 12, IX, 14, IX,
4(F8.3, IX), Al, 411
Record Variables: (in order of sequence in record) CODE(2), SPIDS,
SPIDP, SPSEG, SPCAP, SPREV$(4). SPLVL, PRUSBL(4)
FILE? Record Format for Site-Process Identification Variables
183
-------
File Name: FILE9
File Number: (for JCL) 29
Created In Routine; COLUMN
Retrieved In Routine(s); READIT
Minimum Records: 1
Maximum Records: 360
Record Length: 140 characters
Record Format; 13, 211, 313, Al, 12, II, 15A4, F7.1, 14, F7.2, 14,
16, II, 2F12.3
Record Variables: (in order of sequence 1n record) CNA, CNTYPE,
ICODE, ID1, ID2, 103, SPLVL, SPSEG, MPERID,
ONAME(5), PRNAME(5), DNAME(5), SOTON, SPCAP,
PRWGT, PRDEN, SILAND, SICODE, FCCNA, VCCNA
FILE9 Record Format for Column Identification Variables
184
-------
Column
1-4
11-30
41
46
51
Data Name
NAME
TITLE
NPHAS
NFORC
IN DSD
Data Type
4 character identification 'NAME1
20 character alphanumeric
1 digit 1, 2, 3 or 4
1 digit 1 or 2
1 digit 0 or 1
56
61
PBASE
KOPT
68-71
73-75
77-79
NUMNZ
M
N
NO = 0 YES = 1
1 digit 0 or 1
NO « 0 YES = 1
1 digit 1, 2, or 3
complete » 1
I/O = 2
output « 3
4 digit field right justified
integer value
3 digit field right justified
integer value
3 digit field right justified
integer value
Matrix Output Job Name and Control Card
185
-------
Row ID Card
Columns
1-4
Data Name Data Type
X 4 character identification field
"ROWS"
Row Data Card
Columns
Data Name
1-4
6-7
11-20
J (RNA)
INDIC
B
Data Type
4 digit integer right justified
2 digit Integer right justified
10 digit floating point right
justified with a punched decimal
point
Column ID Card
Column
1-4
Data Name Data Type
K 4 alpha characters "COLS"
Column Data Card
CqUimn.
1-4
11-20
21-30
Data Name Data Type
J (CNA) 4 digit integer right justified
VC 10 digit floating with decimal
point
FC 10 digit floating with decimal
point
Matrix Output Row and Column Identification Data
186
-------
Matrix ID Card
Col umn
1-4
Matrix Data Card
Column
1-4
6-9
11-20
21-24
26-29
31-40
41-44
46-49
51-60
61-64
66-69
71-80
Data Name
D
Data Name
XI (ROW)
Yl (COL)
Zl (A)
X2 (ROW)
Y2 (COL)
Z2 (A)
X3 (ROW)
Y3 (COL)
Z3 (A)
X4 (ROW)
Y4 (COL)
Z4 (A)
Matrix Input Termination Card
Column
1-4
Data Name
Data Type
4 alpha characters "MATX"
Data Type
4 digit Integer right justified
4 digit integer right justified
10 digit floating point right
justified with decimal point
Formats as for XI, Yl and Zl
These fields are optional
Data Type
4 digit integer all zeros
Matrix Output Identification and Data
187
-------
APPENDIX II
SUBROUTINE SUMMARY SHEETS
WRAP PROGRAM SUMMARY SHEETS
Summary sheets for the WRAP program are presented in this appen-
dix. A summary sheet is also given for the principal controlling
program, MAIN. The sheets are presented in alphabetical sequence
following the index provided for rapid referencing.
Each summary sheet provides Information in the following-areas:
(1) program name, (2) overlay location and segment number, (3) func-
tional module name, (4) author name(s), (5) declaration or entry
statement, (6) information about the entry statement arguments,
(7) purpose of the program, (8) names of the routines calling the
program, (9) names of the routines called by the program, (10) names
of referenced common storage areas, (11) names of referenced input/
output files, and (12) error codes and messages generated.
There are 99 summary sheets in this appendix.
188
-------
WRAP
PROGRAM SUMMARY SHEET
1) MUJI: APRINT 2) OVERLAY; GAMMA 3) MODULE: OUTPUT
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT; SUBROUTINE APRINT (ACODE, MPERID)
6) ARGUMENT TYPES; ACODE and MPERID are single precision integer variables
specifying column code type and modeling period.
7) STATEMENT PURPOSE: This routine prints headings for final model results
based on the BASIS column activity code (ACODE), the model execution type
code (MTYPE) and model period.
8) CALLED BY; ODYN1, ODYN2, OSTAT
9) CALLS ROUTINES: None
10) COMMONS REFERENCED: FRONT
11 > FILES REFERENCED:
(fi) pn-nter
12) ERROR CODES AND MESSAGES GENERATED:
Only the page headings for the final solution reports are generated.
189
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: APRPU 2) OVERLAY: ALPHA 2 3) MODULE: FRONTOUT
4) AUTHOR(S): v. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE APRPU (PRPU)
6) ARGUMENT TYPES: PRPU is an integer variable with numeric value of 1, 2 or 3.
7) STATEMENT PURPOSE: APRPU is the front end output control routine. After
edit completion, the user supplied input data will be output by PRINT if
PRPU = 1. When PRPU •= 2, the PUNCHT routine is called to output the
transportation activity file. When PRPU « 3, the PUNCHM routine is
called to output the matrix vectors.
8) CALLED BY: MAIN
9) CALLS ROUTINES: PRINT7 PUNCHT, PUNCHM
To"! COTWONS~R'EFER'ENCED: None
~TI) FI LES~RETERTITcTD: None
ERRQR^IMTlJ'^ElsTGES GENEWETJ: NonT
190
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: BTRAN 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AjJTHOR_(iI: Compuvlsor, Inc.
V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE BTRAN
6) ARGUMENT TYPES: • None
7) STATEMENT PURPOSE: Gets the current pricing vector PI, from basic vector
costs and updates at by all previous transformations. The transformations
are obtained by reading the ETAFI vector in reverse sequence from the last
to first entry.. The current price is calculated as the value of the matrix
product CB . B~ .
8) CALLED BY: LP, NEWA, SETUB, SIMPL, SUITC, TINV
9) CALLS ROUTINES: DOTpRj ETARB
COMMONS REFERENCED: Un1abe1ed and SWAPCO
11) FILES REFERENCED: None
12) ERROR CODESMD MESSAGES GENERATED: None
191
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: BUILD 2) OVERLAY: BETA 4 3) MODULE: LINKAGE
4) AUTHOR(S): M. V. Mollo-Chrlstensen
5) DECLARATION OF STATEMENT; SUBROUTINE BUILD
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine builds two tables to check the user supplied
activity links. One table 1s the possible origins, the other table is the
possible destinations. All sources and all site/processes with output must
be origins. All sites must be destinations. Counters for each table length
are summed.
8) CALLED BY: MAIN
9) CALLS ROUTINES; FIND, READIT
10) COMMONS REFERENCED: Unlabeled, FRONT, LINK, PNTR, POUT, PROCCO, 5IPRCU,
SITECO, SRCCO, TRANCO, TRKCO
~TOFILES REFERENCED:JEF (6)
ERROR CODES SAGES GENERATED: Outputs Unking tables when IDBUG is on.
"BEGIN BUILD"
link table
"END BUILD"
192
-------
WRAP
PROGRAM SUMMARY SHEET
0 ROUTINE: CADIST 2) OVERLAY: BETA 4 3) MODULE; CROWFLY
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE CADIST (OLONG, OLAT, OLONG, DLAT, ADISI)
6) ARGUMENT TYPES: OLONG and OLAT real variables for origin coordinates.
DLONG and DLAT real variables for destination coordinates.
ADISI real variable returns calculated distance.
7) STATEMENT PURPOSE: This routine is used to calculate the geographical
distance between two locations. Distance is calculated in-miles after
the coordinates of the two locations are converted from degrees, minutes
and tenths of minutes.
8) CALLED BY; ICROW1, CRWLNK
9) CALLS ROUTINES: CONV (function) (Also uses FORTRAN routines ABS and SQRT)
10) COMMONS REFERENCED: FRQNT
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
193
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: CAPBAL 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE CAPBAL (N)
6) ARGUMENT TYRES: N is a single precision Integer indicating the maximum
number of columns:
7) STATEMENT PURPOSE: Routine constructs the capacity balance equations
for a dynamic run. Coefficients are generated for ACODE * 6, 7 and or
8. Coefficients are either +1 or -1.
8) CALLED BY: MATRIX
9) CALLS ROUTINES: FINDt READIT> SETC> SETR> TBREAD
10) COMMONS REFERENCED: FRQNT> ^ RNTR| pROCOO> $ETREC
11) FILES REFERENCED: Nonfi
12) ERROR CODES AND MESSAGES GENERATED:
None
194
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: CKSIPR 2) OVERLAY: BETA 4 3) MODULE: EDIT2
4) AUTHOR(S): M. V. Mollo-Chrlstensen
5) DECLARATION OF STATEMENT: SUBROUTINE CKSIPR
6} ARGUMENT TYPES: None
7) STATEMENT PURPOSE: CKSIPR does consistency checks and calls the error routine
for site/process data which 1s not consistent with the corresponding process
and site Inputs.
8) CALLED BY: EDIT2
CALLS ROUTINES: ERROR. FIND. LXSORT. READIT. SEGS
10} COMMONS REFERENCED: Unlabeled, ERRCOD, FRONT, PNTR, POUT, PROCCO, SIPRCO,
SITECO
11) FILES RETERENCED: JEF(6)
"T2T"lRRQR CODES AND MESSAGES GENERATED: When IDBUG 1s on
"BEGIN CKSIPR"
setc process checking data
"END CKSIPR"
Error message codes generated (see ERROR for messages)
3.4.11, 3.4.12, 3.4.13, 3.4.14, 3.4.15, 3.4.16, 3.4.17, and 3.4.18
195
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: CNTCHK J) 'OVERLAY: BETA 4 3) MODULE; EDIT2
4) AUTHOR(S): M. V. Mollo-Chrtstensen
5) DECLARATION OF STATEMENT: SUBROUTINE CNTCHK
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: CNTCHK calls the error routine for Inconsistencies in
the year data input on the control card and converts some of the control
variables (INDSD, IBASE, PBASE, ITRUCK, JUMP) to conform to algorithm
tests. I.e., one is substracted from each variable so they = 0 or 1 rather
than 1 or 2.
8) CALLED BY: EDIT2
~9) crilTlOllTTNET:
t ERRQR
~TO]COMMONS _REFERENCED:
Unlabeled, ERRCOD, FRONT, POINT
11} FILES REFERENCED: JEF (6)
CODES^ AND MESSAGES GENERATED: when IDBUG 1s on "BEGIN CNTCHK"
"END CNTCHK"
Error messages 3.3.11
196
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: COLUMN 2) OVERLAY: BETA 5 3) MODULE: COLUMN
4) AUTHQR(S): M. V. Mollo-Christensen
V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE COLUMN
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSED This subroutine creates column identification records
for the matrix. The column identification vector is also generated.
Column records are generated for transportation activities and processes
for a each modeling period, then process linear segment capacity columns
for each period. The record pointer table 1s also generated with column
Identification number, activity code, three identification codes, modeling
period, and record number.
8) CALLED BY: MAIN
9TCALLSROUTINES:CSTCRD, ERROR, FIND, KCOST, LXSORT, PCOST, READIT, SEGS,
SCOST, TCOST, TRFAC
lOTCOMMONS REFERENCED: Un labeled, SETREC, FRONT, POUT, SRCCO, S I TECO , S I PRCO ,
"PRO'CCO, and TRANCO
T) rfiJTREFERENCEin FILE(29), JEF(6)
~T2) ERROR tydETlND MESSAGES GENERATE!?: Outputs debugiing arrays when IOBUG
Is on ABORTS if number of columns exceed 360 or 600 depending on small or
large program version.
Error codes 5.1.1 thru 5.1.4.
197
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: COMEI 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE COKEI (COLMI)
6) ARGUMENT TYPES: COMI 1s integer variable, single precision.
7) STATEMENT PURPOSE: Determines the value of the incoming column vector.
Uses the column for iterations during phases 1 and 2. The selected
.column number 1s stored in COLMI. This vector 1s then brought into
the basis.
8) CALLED BY: LP
9) CALLS ROUTINES: DOTPR> SWITCi PASSA
10) COMMONS REFERENCED: Unlabeled and SWAPCO
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
198
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: CONTRL 2) OVERLAY: BETA 3 3) MODULE: EDIT!
4) AUTHOR(S): M. V. Mollo-Christensen
5} DECLARATION OF STATEMENT: SUBROUTINE CONTRL
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: CONTRL reads the title Input card and the control input
cards. The program checks the input data for validity. Defaults are set
where possible. An error flag is set where data is invalid or missing and the
default values do not apply. CONTRL stores the control card data in COMfON
/FRONT/ and the title data in COMKON /TITLRD/. If the error flag is set to a
severe error code then the program will abort Immediately on return to EDIT1.
Continued on next page.
8) CALLED BY: EDIT!
"9r"CALIS~ROUTrNES: DEFLT. ERROR
10) COMMONS REFERENCED: Unlabeled, FRONT, TITLRD, ERRCOD, AND POUT
IT) FILES REFERENCED: MJTfSK JEF(6), FILE1 (21)
12) ERROR CODES AND MESSAGES GENERATED: When IDBU6 is on
"BEGIN CONTRL"
control data and inputs
"END CONTRL"
Error messages generated 2.2.1, 2.2.2, 2.2.3, 2.2.11 thru 2.2.29
199
-------
CONTRL
7) STATEMENT PURPOSE - Continued
DEFAULTS SET:
No. of periods (NPERID=1)
Model type (MTYPE-1)
Last phase of execution (LPHASE=3)
Forcing method NFORC=1)
LP print option KOPT=3)
Steepest descent INDSD=2
Initial basis IBASE=1
Punch final basis (PBASE=1
Crowfly option (ICROW=0
Punch transportation PCROW=0
Punch model PMODEL=0
Truck constraints ITRUCK=1
Jump to LP (not used) J111P=1)
1f out of range
If value invalid
if value invalid
if invalid
if out of range
if invalid or missing
if IBASE not 1 or 2
1f value not 1 or 2
if value not 0, 1, or 2
if value not 0, 1, Or 2
1f value not 0, 1, or 2
1f value not 1 or 2
always set since this value
1s not currently Implemented
1n logic.
200
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: CONV 2) OVERLAY: BETA 4 3) MODULE: CROWFLY
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: FUNCTION CONV (VAL)
6) ARGUMENT TYPES: VAL 1s a single precision real variable which is the
value to be converted from degrees and minutes.
7) STATEMENT PURPOSE: CONV 1s a function. It 1s used to convert a geographical ;
coordinate from degrees, minutes and tenths of minutes to statutory miles.
The converted value is returned directly to calling procedure.
8) CALLED BY: CADIST
9) CALLS ROUTINES: None
10) COMMONS REFERENCED: N0ne
TV) FILES REFERENCED; None
~~T?)ERROR CODES AND MESSAGES GENERATED:None
201
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: COST 2) OVERLAY; BETA 5 3) MODULE: MATRIX
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE COST
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: Constructs the fixed and variable cost arrays by
reading the column identification records and storing values in FC and
VC respectively.
8) CALLED BY: MATRIX
9) CALLS ROUTINES: READIT
10} COMMONS REFERENCED: Unlabeled, FRONT, MAT, READ
11) FILES REFERENCED; None
~~T7) ERROR COPTS AND MESSAGES GENERATES": RonT
202
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: CPFAC 2) OVERLAY; BETA 5 3) MODULE: COLUMN
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT; SUBROUTINE CPFAC (CF, T)
CF 1s a single precision real array which will return
the capitalization factors for each period. T 1s a single precision
Integer variable Indicating the period.
7) STATEMENT PURPOSE: This routine calculates the capitalization factors for
each modeling period for which a particular site/process is in existence.
It calculates the year at end of which capital is committed. It calculates
the factor for each period process is used. Finally, it sums the product
of compounded Inflation and discount rates for a period.
8) CALLED BY: KCOST
Ty~cTLlS~WTTl:S: None
~T6T~cTiMMS'N"S~REFERENCED: FRONT, SRCCO, SITECO, SIPRCO, PROCCO and TRANCO
1) FILES REFERENCED: None
CODES AND MESSAGES GENERATED:
203
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: CROFLY 2) OVERLAY: BETA 4 3} MODULE: CROWFLY
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE CROFLY
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine 1s called when the user has requested crowfly
option 1 or T.Based on the value of the crowfly selection variable a
crowfly routine is called (ICROW1 or ICROW2).
8) CALLED BY: MAIN
"9T~CALLS. RQUT1NE S: I CROW!, ICROW2
1CI) COMMONS REFERENCED: Unlabeled, FRONT,ERRCOD.POUT
ii) FILES REFERENCED:
12) ERROR CODES AND MESSAGES GENERATED: When IDBUG 1s on prints
BEGIN CROFLY
END CROFLY
204
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: CRWFLY 2) OVERLAY: BETA 3 3) MODULE: EDIT1
4) AUTHOR(S|; M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE CRWFLY
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: CRWFLY reads the crowfly control data card. The data is
checked for validitv. This routine is only called when the crowfly option
switch, ICROW, is equal to 1 or 2. If the data is invalid then ICROW is set
to 0. This may cause the program to ABORT at a later stage of execution.
The input data is stored in COMMON /FRONT/.
8) CALLED BY: EDIT!
9) CALLS ROUTINES: ERROR
"TO'T'TOMMONS REFERENCED: Unlabeled, ERRCOD.FRONT,POUT
TV) FILES REFERENCED: MUT(5). JEF(6)
"MESSAGES GENERATED: Mhen IDBUG is on
"BEGIN CRWFLY"
crowfly data as input
"END CRWFLY"
and "CROWFLY VALUE missinq; ICROW was set
to 0". Error codes generated (see
ERROR for messages) 2.3.1 and 2.3.2.
205
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: CRULNK 2) OVERLAY: BETA 4 3) MODULE: CROWFLY
4) AUTHOR(S): M. V. Mollo-Chrlstensen
V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE CRVILNK (IC.DTAB.IDTAB.IT)
6) ARGUMENT TYPES: 1C single precision integer, DTAB single precision array,
IDTAB single precision array, IT single precision integer.
7) STATEMENT PURPOSE: The routine creates transportation activity links for
crowfly options"! and 2. If crowfly option is 1 only the shortest link is
saved. If crowfly option is 2 all links within the maximum radius are saved,
if no links are within the radius then the shortest link is saved. Logic is
partially controlled by the type of link origin - source or site. A count of
the number of links saved is returned to calling procedure.
8) CALLED BY: ICROW2.LNKBLD
9) CALLS ROUTINES: ERROR,CADIST,FIND,READIT
10) COMMONS REFERENCED: PNTR,SRCCO,SITECO,SIPRC07TRANCO,FRONT,ERRCOD'
TOFILES'REFERENCED; None
~T2T ERROR T(ypTS~A'Nr3 MESSAGES GENERATED: No messages - 4.6.1 calls ERROR if links
savedexceeds"T2J5 since linking tables will not hold more than 125 entries.
206
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: CSTCRD 2) OVERLAY: BETAS 3) MODULE: COLUMN
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE CSTCRD(ID.IPNT)
6) ARGUMENT TYPES: ID is a single precision integer variable
IPNT is a single precision integer variable used as a
table pointer.
7) STATEMENT PURPOSE: This routine determines which process cost card set
should be used to calculate costs for the activity.
8) CALLED BY: COLUMN
"9)CALLS ROUTINES: FIND.LXSORT
TO) COMMQNS~RrFERENCED: PROCCO
IT) FILES REFERENCED: None
MESSAGES GENERATED: Non
207
-------
W R A P
PROGRAM SUMMARY "SHEET
1) ROUTINE: DBLFND 2) OVERLAY: BETA 5 3) MODULE; BASIS
4) AUtHOR(S): V. hiensey
5) DECLARATION OF STATEMENT: SUBROUTINE DBLFND(TABLE,MLEN,MDIM,MEMTRY,MVAU,
MPOS1,MVAL2,MPOS2,fFIND7
ARGUME.NT_TYPE.S_: All subroutine arguments are single precision integers.
TABLE 1s a single precision array of dimensions (MLEN.MDIM).
7) STATEMENT PURPOSE.- This routine is used to find two entries in a two
dimensional table. The second value MVAL2 is a subset variable of the
first variable MVAL1. The find variable (IFIND) is set to 0 and then set
to the table index for the found match.
8) CALLED BY: DSTRTB.SSTRTB
9) CALLS ROUTINES: None
~T6]COMMONS REFERENCED: None
11) FILES REFERENCED: None
12) ERRQjj CODES AND MESSAGES GENERATED: None
208
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: DEFLT 2) OVERLAY: ALPHA 2 3) MODULE: MAIN
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE DEFLT (VAR,NAME,VALUE)
6) AKGI)MEJNT_J_YP_ES: The three arguments are single precision integer variables.
"WR" fs~"hame 67 variable for which default 1s to be set
NAME 1s character name of variable
VALUE 1s value to be set in the variable
7) STATEMENT PURPOSE: This routine stores the default value (VALUE) in the
variable fVART. A message is written to output file 6., giving the variable
name code (NAME) and the new value. The routine Is primarily used to set up
coded default values when the user-supplied data is missing or 1n error.
8) CALLED-BY: CNTCHK.CONTRL.PROCES
9T~CA~LLS' ROUTINES: None
"TOT CJMdNS'REFERENCM- None
~TT)"~nTjr$"Ri:'FERENCEO: JEF(6)
TRROtTCgBErMD MESSAGES GETftRATED: "DEFAULT VALUE SET FOR name IS --value"
where variable name 1s printed In name and the generated value printedTn
value.
209
-------
W R A P-
PROGRAM SUMMARY SHEET
1) ROUTINE: DOTPR 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvlsor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE DOTPR (X, Y. DOT, T)
6) ARGUMENT TYPES: X and Y are real vectors single precision of length 'M1
(number of rows in matrix). DOT is a real variable single precision.
T is an integer variable, single precision.
7) STATEMENT PURPOSE: Calculates the dot product of two vectors. It uses
Winograds algorithm for the computation. The calculated value is the
objective function for the current basis.
8) CALLED BY: BTRAN.COMEI,FORCE,LP,SWAP,SWITC.TINV
9) CALLS ROUTINES: None
10) COMMONS REFERENCED: Unlabeled, and
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
210
-------
WRAP '
PROGRAM SUMMARY SHEET
1) ROUTINE: DSTRTB 2) OVERLAY: BETAS 3) MODULE: BASIS
4) AUTHQR(S): V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE DSTRTB
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine is used in a dynamic case execution to
to generate a starting basis if the user does not supply one. It 1s only
used for dynamic executions.
8) CALLED BY: Main
9) CALLS ROUTINES: DBLFND.LXSORT.READIT.FIND
10) COMMONS REFERENCED: UnTabeled,POUT,SETREC,PNTR,RNACO,SIPRCO,SITECO,PROCCO,
READ,FRONT
IT) FILESREFERENCED: JEF(6)
~TT)~"ERROR CODES"A¥D MESSAGES GENERATED: Debugging data is output when IDBUG is
on. and the two messages beTow
10.01.01
10.01.02
211
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: DUP 2) OVERLAY; BETA 4 3) MODULE: EDIT2
4) AUTHOR(S): M. V. Mollo-Christensen
j'l DECLARATION OF STATEMENT: SUBROUTINE DUP(LD,IERR,OLDTIM,OLDDIS,OLDSPO,L)
6) ARGUMENT TYPES: LD,IERR,OLDTIM,OLDDIS,OLDSPD,L are all Integer
7) STATEMENT PURPOSE: DUP checks If two transportation cards with duplicate
Identification numbers for source, process, and destination are true
duplicates (have duplicate times). If true duplicates, one is removed; if
not an error flag is set.
8) CALLED BY; TRNCHK
9) CALLS ROUTINES: ERROR
10) COMMONS REFERENCED: ERRCOD,FRONT,PNTR.TRANCO
M) FILES REFERENCED: None
~T7)~"ERRoTCODES AND MESSA6ES GENERATED: ERROR Flag (ItiHR) Is set if the cards
are not, true duplicates.Fhis flag is used by TRNCHK to determine severity
code passed to ERROR (i.e., warning or abort after EDIT2 code).
212
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: OUPWRT 2) OVERLAY; BETA 4 3) MODULE; CROWFLY
4) AUTHOR(S): M. V. Mollo-Christensen
V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE DUPWRT (DTAB,IDTAB,IT,NEWREC,TAOID)
6) ARGUMENT TYPES: DTAB and IDTAB are single precision integer arrays,
IT, NEWREC and TAOID are single precision Integer variables.
7) STATEMENT PURPOSE: This subroutine is used to check each activity generated
for crow-fly option 2 against the user supplied activities. If a duplicate
is detected the generated activity is eliminated. If a generated activity is
not duplicative it is written to the transportation activity file. The
activities counter is incremented. Prior to writing the activity record the
origin and destination codes are checked to determine what activity code
should be assigned.
8) CALLED BY: ICROW2
9} CALLS ROUTINES: ERROR
10) COMMONS REFERENCED: Unlabeled. ERRCOD.FRONT.PNTR and TRANCO
IT) FILES REFERENCED: FILE5(25)
T2) ERROR CODES AND MESSAGES GENERATED: ERROR routine is called if total
transportation activities exceed 450 since storage cannot handle more entries.
213
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: ED 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4) AUTHOR(S): 0. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE ED(N)
6) ARGUMENT TYPES: N 1s a single precision Integer which Indicates the
maximum number o'f columns in the matrl .
7) STATEMENT^ PURPOSE: This routine creates a dummy equation to make sure that all
columns with an identification code type 6 have at least two entries. The
matrix coefficient 1s +1.
8) CALLED BY: MATRIX
TTCALLS ROUTINES: READIT.SETC.SETR.TBREAD
10) COMMONS REFERENCED: FRONT,MAT,PROCCO,SITECO
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED,; None
214
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: EDIT! 2) OVERLAY: BETA 3 3) MODULE: EDIT 1
4) AUTHOR(S): M. V. Kollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE EDIT!
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This is the control routine for the first edit checking
of the user supplied input data. The routine calls a set of subroutines,
each of which reads a particular input group. Each of the called routines
also perform range and existence validity checking. Error messages
are output from ERROR.
8) CALLED BY: MAIN
9) CALLS ROUTINES: CONTRL, CRWFLY, ERROR, PROCES , SIPRC, SITE, SOURCE,
TBASIS, TRANS, TRUCK
10) COMMONS REFERENCED: Uniabeied, ERRCOD, FRONT, POUT, PNTR, PROCCO, SIPRCO,
SITECO, SRCCO. TRANCO, TRKCO
11) FILES REFERENCED:JEF ^
TilERROR CODES AND MESSAGES GENERATED:
When IDBUG is on
"BEGIN EDIT!"
lists all EDIT! data inputs as provided by the user.
"END EDIT!"
Error codes are
2.1.1 and 2.1.2 (see ERROR for messages)
215
-------
W R A-P
PROGRAM SUMMARY SHEET
1) ROUTINE: EDIT2 2) OVERLAY: BETA 4 3) MODULE: EDIT2
4) AUTHOR(S): n. y. Kollo-Chnstensen
5) DECLARATION OF STATEMENT: SUBROUTINE EDIT2
6} ARGUMENT TYPES: None
7) STATEMENT PURPOSE: EDIT2 calls a set of routines which do consistency
checks for the data read and checked initially by EDIT! routines.
Immediate abort occurs before CKSIPR if severe error (FLAG = 2) was found
in EDIT! or ONENUM. Immediate abort occurs before TRNCHK if any severe
errors (FLAG = 2) found in CKSIPR or PRCNK.
8) CALLED BY: MAIM
9) CALLS ROUTINES; CKSIPR, CNTCHK, ERROR, OflENUM, PRCHK, TRNCHK
10) COMMONS REFERENCED:Unlabeled, ERRCOD, FRONT, POUT, PNTR, PROCCO, SIPRCO,
SITECO, SRCCO, TRANCO, TRKCO
11) FILES REFERENCED: N^ne
12) ERROR CODES AND MESSAGES GENERATED3.1.1, 3.1.2
debugging messages output when IDBUG is on.
216
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: ERROR 2) OVERLAY: MAIN 1 3) MODULE: MAIN
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE ERROR (NUMOUT, ACTION, IERR, NERR)
6) ARGUMENT TYPES: (All single precision integers)
ACTION - Severity code - determines whether ERROR aborts immediately and if
not; what FLAG is set to.
LERR - an array of length 2; LERR(l) contains the module code, LERR(2)
contains, the subroutine code
NERR - error number of the particular error in a subroutine
NUMOUT - An ID number to be printed; it aids the user in locating the
particular piece of incorrect data.
7) STATEMENT PURPOS_E: Error is called by other routines when errors in user
data or a storage overflow occurs. It either terminates the program
immediately for every severe error or sets an error severity flag (FLAG)
to be tested by other routines to determine if and when to abort. Error
writes a message explaining each error and prints its identification code.
Variable FLAG is stored in FRONT common.
8) CALLED BY: CKSIPR, CNTCHK, COLUMN, CONTRL, CRWFLY, CRWLNK, DUP, EDIT!, EDIT2,
fCROW2, LINKS, CNENUM, PRCHK, PRCOST, PROCES, SETC, SETR, SIPRC, SITE, SOURCE,
TBASIS. TRANS TRNCHK, TRUCK
TT~CALLS ROUTINES: N
10) COMMONS REFERENCED: None
11") FILES REFERENCED: JEF
12) ERROR CODES AND MESSAGES GENERATEDError prints on one line the error
code for a particular error and the severity (either ERROR or ABORT) in the
form:
****M.SS.NN**** ERROR
or
ABORT
(where m is the r-odule code, ss is the subroutine code within the module
and nn is the specific error number.)
This line is followed by a brief description of the error, including an ID
(NUMOUT) where applicable.
217
-------
WRAP
PROGRAM SUKMARY SHEET
1) ROUTINE: ETAGE 2) OVERLAY: GAMMA 1 3) MODULE: LINEAR
4) AUTHOR(S): Coropuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE (COLMI, R)
6) ARGUMENT TYPES:. COLMI is a sirgle precision integer variable. R is a
single precision integer variable.
7) STATEMENT PURPOSE: Performs a simplex transformation. The pivot element
is column CCLMI, row R. It produces an ETA vector which is one factor
in the product form of the basis inverse.
8) CALLED BY: LR> REINV> SIKPL
9) CALLS ROUTINES: ETARI> FTRAN
10) COMMONS REFERENCED: Unlabeled and SWAPCO
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
218
-------
WRAP"
PROGRAM SUMMARY SHEET
1) ROUTINE: ETARB 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEf'HiT: SUBROUTINE ETARB(R)
6) ARGUMENT TYPES:. R is a single precision integer variable.
7) STATEMENT PURPOSE: Reads the next sparse image ETA vector, in reverse
sequence, into an expanded vector for use by BTRAN. It sets the argument
R equal to the pivot row number for the transformation.
8) CALLED BY: BTRAN
9) CALLS ROUTINES:None
10) COMMONS REFERENCED!Unlabeled and SWAPUU
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED:
219
-------
WRAP
PROGRAM SUMMARY SHEEf-
1) ROUTINE: ETARF 2) OVERLAY: GAKMA 7 3) MODULE: LINEAR |
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE ETARF(R)
6) ARGUMENT TYPES: _ R is a single precision integer variable.
7) STATEMENT PURPOSE: Reads one ETA vector in sparse form into'a'complete
expanded from for use by FTRAM. ETA is read in a forward direction. R
is set to the pivot row for the transformation. , ,
8) CALLED BY: FTRAN
9) CALLS ROUTINES: None
10} COMMONS REFERENCED: Unlabeled and SWAPCO
11) FILES "REFTRENCED:
None
12) ERROR CODES AND MESSAGES GENERATED: None
220
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: ETARI 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUiHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE ETARI (R)
6) ARGUMENT TYPES: . R is a single precision integer variable.
7) STATEMENT PURPOSE: This routine maintains a sequential file of ETA vectors.
The vector is used for product calucatior.s or inverse computations. A new
vector is written onto the end of the array in sparse form if the storage
limit has not been exceeded. The argument "R" is used to determine the
pointers necessary.
8) CALLED BY: ETAGE
9)CALLS ROUTINES: None
10) COMMONS REFERENCED: Un1abe1ed and SV,APCO
11) FILES REFERENCED:
"12) ERROR CODES AND MESSAGES GENERATTDl
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: FIND 2) OVERLAY: MAIN 1 3) MODULE: MAIN
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE FIND (TABL, ROWS, COLMS, MUM, VALUE,
POSIT, TPMTR]
6) ARGUMENT TYPES: All arguments are single precision integer variables.
7) STATEMENT PURPOSE: FIND searches a table (TABL) with dimensions (ROWS, COLMS)
and length (HUM) for a matching value for the argument VALUE. The table
column position is defined as POSIT and the location of the rnatch, row is
returned to the calling routine in the pointer variable TPNTR. If no
match is found, then the pointer variable is set to zero.
8) CALLED BY: BUILD, CAPBAL, COLUMN, CRWLMK, CKSIPR, CSTCRD, DSTRTB, ICROW1,
TCRORZ7TNKCHK. ODYN1 , ODYN2, OSTAT, OUTBAS, PRCHK, SIPRC, TRNCHK
9) CALLS ROUTINES: Np~
TO] COMMONS REFERENCED:
11) FILES REFERENCED:
12) ERROR CODES AND MESSAGES GENERATED:
222
-------
W R^A P
PROGRAM SUMMARY-SHEET
1) ROUTINE: FORCE 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE FORCE (ICOL, IFLAG)
6) ARGUMENT TYPES: ICOL is a single precision integer variable - contains
column pointer. IFLAG is a single precision integer variable contains
the return flag.
7) STATEMEMi PURPOSE: FORCE is the column forcing routine used in Phase 4
execution. It saves the values in the current BASIS for fast restoration.
A new column is tried to be forced into the BASIS. If forcing does not find
a better solution, then the previous solution is- restored and control returns
to calling procedure. IFLAG is set to indicate the action taken.
8) CALLED BY: SWAP
9) CALLS ROUTINES!DOTPR, SAVE, SETUB, SIMPL
10) COMMONS REFERENCED: Un1abe1ed and SWAPCO
11] FILES REFERENCED;
12) ERROR CODES AND MESSAGES GENERATED: None
223
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: FSORT 2) OVERLAY: GAW1A'7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: > SUBROUTINE FSORT
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: FSORT performs a bubble sort. The sparse matrix and the
row and column pointer tables are rearranged into column order.
8) CALLED BY: SETUA
9) CALLS ROUTINES: None
10) COHMONS REFERENCED: Unlabeled and SWAPCO
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED:
11.1.8 "DUPLICATE ROW AND COLUMN LOCATIONS ENCOUNTERED DURING SORT ROUTINE"
The program stops.
224
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: FTRAN 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Conipuvisor, Inc. i
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE FTRAN (TVECj
6) ARGUMENT TYPES: TVEC is a single precision floating point array dimensioned
for 10 entries.
7) STATEMENT PURPOSE: FTRAN is called to update the matrix column that is
being brought into the BASIS. The column is modified by all previous
transformations which are kept in product form of the inverse. The
principal objective is to determine which vectors are to be removed
from the current BASIS.
8) CALLED BY: ETAGE, LP, NEWA, REINV, SIHPL
9) CALLS ROUTINES:
10) COMMONS REFERENCED: Un1abe1ed and SWAPCO
11) FILES REFERENCED: ,J
12) ERROR CODES AND MESSAGES GENERATED:
225
-------
WRAP
PROGRAM SUMMAHJLSMEET
1) ROUTINE: ICROWI 2) OVERLAY: BETA 4 3) MODULE: CROWFLY
4) AUTKOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE ICROWI
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine is used when the user has specified the
crowfly 1 option. There are two actions performed: calculation of travel
distance and tir.e for missing input and creation of .shortest links for
missing links. There are a maximum of 10 links.that may be generated.
8) CALLED BY: CROFLY
9) CALLS ROUTINES:CADIST, FIND, LNKBLD, READIT
10) COMMONS REFERENCED: Un1abe1edt FROHT> pNTR> pOUT> SRCCO. SITECO and TRANCO,
Commons
1l) FILES"REFERENCED:
JEF (6), FILE5 (25)
12) ERROR CODES A"D MESSAGES GENERATED:
226
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: KROH2 2) OVERLAY: BETA 4 3) MODULE: CROWFLY
4) AUTHOR(S): M. y. Mollo-Christensen
V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE ICROW2
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine is used when the user requests the crowfly 2
option. This option generates all possible links within a specified travel
radius, checks for duplicates with user supplied data, and alters the
transportation activities counter. Links are generated using the origin
table created by BUILD, and the data files for sources, sites, site/process
and processes.
8) CALLED BY: CROFLY
9) CALLS ROUTINES: CRWLNK> DUPWRT) ERROR, FIND, READIT
10) COMMONS REFERENCED: Unlabeledi PROMT, ERRCOD, PNTR, INK, POUT, TRANCO
11) FILES REFERENCED: JEF (6)
12) ERROR CODES AND MESSAGES GENERATED:'
ERROR (4.3.1) if no' links are made by
CRWLNK because there is a malfunction
some where.
227
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: INIT 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE INIT
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine is used to initialize data for the linear
programming algorithm. The initial feasible solution is set up. A test
of the optional user supplied solution is initated. Artificial variables
are created to balance the matrix for the initial basis.
8) CALLED BY: SWAP
9) CALLS ROUTINES: ^^
10) COMMONS REFEWCED: Unlabeled and SWAPCO
11) FILES REFERENCED: JEF
12) ERROR CODES AND MESSAGES GENERATED:
****THIS PROGRAM HALTS BASIS NOT GOOD****
(The program halts if basis not acceptable since it would
try to start processing in Phase 1 which could cause a time-
out or excess execution time.)
228
-------
W R A P-
PROGRAM SUMMARY SHEET
1) ROUTINE: KJITDA 2) OVERLAY: ALPHA 2 3) MODULE: MAIN
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE INITDA
6) ARGUMENT TYPES:. None
7) STATEMENT PURPOSE: This routine initalizes the pointer table arrays to
zero. The tables are all stored in PNTR coraion and are used 'to retrieve
records from temporary storage files.
8) CALLED BY:
MAIN
9) CALLS ROUTINES: None
10) COMMONS REFERENCED: FRQNTi PNTR> SITECO> SIPRCO, SRCCO, PROCCO, TRANCO,
TRKCO. SETREC
'11) FILES REFERENCED; Nope
12) ERROR CODES AND MESSAGES GE¥ERATED: Hone
229
-------
W R
PROGRAM SUMMARY SHEET
1) ROUTINE: INITLP 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4) AUTHQR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE INITLP (IPER)
6) ARGUMENT TYPES: IPER is a single precision integer which indicates the
modeling period currently being processed.
7) STATEMENT PURPOSE: This routine initializes the beginning and ending
column pointers for a given modeling period.
8) CALLED BY: ISPOB, IUSIB, IUSTC, SCRBAL
9) CALLS ROUTINES:
10) COMMONS REFERENCED: m SETREC
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED:
230
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: ISPOB ' 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE ISPOB (I, IPER)
6) ARGUMENT TYPES: lisa single precision integer which returns record number
"read.IPER is a single precision integer indicating model period.
7) STATEMENT PURPOSE: Routine constructs the intermediated site/process
output balance equations. Selects columns by period for coefficient
calculation and storage.
8) CALLED BY: riATRIX
9) CALLS ROUTINES: INITLP, READIT, SETC, SETR, TBREAD
10) COMMONS REFERENCED:MAT and PROCCO
11) FILES REFERETICETJ:
12) ERROR CODES AND MESSAGES GENERATED: None
231
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: IUSIB 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE IUSI3 (I, IPER)
6) ARGUMENT TYPES: j 'is a single precision integer which indicates record read.
IPER is a single precision integer which indicates current period.
7) STATEMENT PURPOSE: Tnis routine constructs the intermediate and ultimate
sites input balance equations. Coefficients are set to +1, -1, or
(750/density of waste output).
8) CALLED BY: MATRIX
9) CALLS ROUTINES: INITLP, READIT, SETC, SETR, TBREAD
10) COMMONS REFERENCED: MAT and PROCCO
TOFILES REFERENCED: " *~
12) ERROR CODES AND MESSAGES GENERATED: None
232
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE; JUSPC 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE IUSPC (I, IPER)
6) ARGUMENT TYPES: .1 is a single precision integer, indicates the number of
source columns. IPER is a single precision integer indicating current
period.
7) STATEMENT PURPOSE: This routine constructs the intermediate and ultimate
site processing constraint equations. Coefficients are determined by type
of site (limited or unlimited) code.
8) CALLED BY: MATRIX
9) CALLS ROUTINES: READn> $ETR> SETC> TBREAD
10) COMMONS REFERENCED: FRONT, KAT, SIPRCO, SITECO
11) FILES REFERENCED:
12) ERROR CODES AND MESSAGES GENERATED:
233
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: IUSTC 2) OVERLAY: BETA'S 3) MODULE: MATRIX
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE IUSTC (I, IPER)"
6) ARGUMENT TYPES: I is single precision integer which indicates source
column number. IPER is single precision integer indicating period.
7) STATEMENT PURPOSE: This routine constructs the truck constraint equations,
8) CALLED BY: MATRIX
9) CALLS ROUTINES: INITLP> READIT, SETR, SETC, TBREAD
10) COMMONS REFERENCED: FRQNT> m, TRKCO
FILES REFERENCED!
12) ERROR CODES AND MESSAGES GENERATED:
234
-------
r
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: KCOST 2) OVERLAY: BETA 5 3) MODULE: COLUMN
4) AUTHOR(S): D. H. Lehnan
5) DECLARATION OF STATEMENT: SUBROUTINE KCOST (TF, T, IRNT, FC, VC)
6) ARGUMENT TYPES: jF is a single precision real array which contains the
transportation factor. T is a single precision integer variable giving period
IPNT is a single precision integer variable. FC is a single precision'real
variable returning fixed cost. VC is a single precision real variable re-
turning variable cost.
7) STATEMENT PURPOSE: This routine calculates the fixed and variable costs for
running a site/process at full capacity for a particular modeling pericd.
8) CALLED BY: COLUMN
9) CALLS ROUTINES: CPFAC
10) COMMONS REFERENCED: FRONT, SRCCO, SITECO, SIPRCO, PROCCO, TRANCO
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
235
-------
W RJTP
PROGRAM SUMMARY'SHEET
1) ROUTINE: LANCON 2) OVERLAY: BETAS 3) MODULE: MATRIX
~~ I ~~"
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE LAuCOM (H)
6) ARGUMENT TYPES: N is a single precision integer indicating the maximum
nimitTer of coTurr.ns in the matrix.
7) STATEMENT P'JRPOSE: This routine constructs the land constraint equation
for a dynamic rrocel.
8) CALLED BY: MATRIX
9) CALLS ROUTINES: READIT, SETC, SETR, TBREAD
'10) TOHMOiiS REFERENCED: FRONT, HAT, SETREC, SITECO
11) FILES REFERENCED: None
12) ERROR COOES AND MESSAGES GENERATED: None
236
-------
WRAP
PROGRAM SUKMARY SHEET
1) ROUTINE: LINKS 2) OVERLAY: BETA 3 3) NODULE: EDIT!
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE LINKS
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: LINKS re;ds the input and output links cards for a
particular process. The link data is checked as it .is read. The check
is for range only. A valid range is 800-999. On the input links card
a valid source code is 1 or 2. The input and output links are sorted
and stored in two separate tables which are to be stored in the PROCESS
record on the temporary disk file.
8) CALLED BY: PROCES
9) CALLS ROUTINES: ERROR, LXSORT
10) COMMONS REFERENCED: Uniabe1ed> ERRCOD> FROHT> POUTi PROCco
11) FILES REFERENCED; HUT (5)~
12) ERROR CODES AND MESSAGES GENERATED: 2.6.1 through 2.6.10,2.6.31 through 2.6.33.1
Aborts for incorrect card identification code or invalid process identification!
code. Aborts for unexpected end-of-file on input or bad data.
237
-------
WRAP
PROGRAM SUMMARY SHEEI
1) ROUTINE: LNKBLD 2) OVERLAY: BETA 4 3) MODULE: CROWFLY
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE LNKBLD
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE- LNKBLD is called by ICRO'Jl to create missing links as
THdicatecl in tr.e origin linkage table filled by BUILD and LNKCHK. LNKBLD_then
figures the activity type code ^or the link, writes it to the transportation
disk file, and updates the transportation record retrieval table. A message
is printed if any missing destinations are not linked while linking missed
origins.
8) CALLED BY: I CROW!
9) CALLS ROUTINES: CRWLNK, ERROR, FIND, READ1T
10) COMMONS REFERENCED; Unlabeled. ERRCOD. FRONT. INK. PNTR. PROCCO. SIPRCO.
SITECO. SRCCQ, TRANCO
IT] FILES REFERENCED: F]LE5
12) ERROR CODES AND MESSAGES GENERATED: 4.4.11 (a warning - non severe)
238
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: LNKCHK 2) OVERLAY: CETA 4 3) MODULE: LINKAGE
4) AUTHOR^): H. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE LNKCHK (1,','IISS)
6) ARGUMENT TYPES: NMISS is a single precision integer variable which
returns the number of links missed.
7) STATEMENT PURPOSE: This routine checks the origin and destination tables
against the transportation activity file to see if all origins and
destinations are linked at least once. A count of missed links are
maintained. Flags are set in the origin and destination table when
a link has been found.
8) CALLED BY: Main
9) CALLS ROUTINES:FIND
10) co''.:;QtJS REFERENCED: uniabeied, FRONT, PNTR, POUT, SRCCO, SITECO, SIPRCO, j
PROCCO, TRAn'CO, TRKCO and LNK |
11) FILES"REFERENCED: JEF(6) j
12) ERROR CODES AND MESSAGES GENERATED: Qnly link tables are printed ifj
debugging switch is on. I
239
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: LP 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc. '
V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE LP
6) ARGUMENT TYPES:. None
7) STATEMENT PURPOSE: This routine Is an implementation of the revised
simplex method Tor solving linear programming problems. It uses product
form of the inverse and Winograd's algorithm for computing Dot products.
An arbitrary initial basis will be accepted if feasible. The coded logic
is primarily calls to other subroutines.
8) CALLED BY: SWAP
9) CALLS ROUTINES: BTRAN,COMEI,ETAGE,FTRAN,PASSA,REMOV,TINV
10) COMMONS REFERENCED: Unlabeled and SUAPCO
TD FILES REFERENCED:
12) ERROR CODES AND MESSAGES GENERATED:
240
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: LXCOMP 2) OVERLAY: MAIN 1 3) MODULE: MAIN
4) AUTHOR(S): D. E. Bell
5) DECLARATION OF STATEMENT: SUBROUTINE LXCOMP (TABL,JJ",TEST,ROWS,COLHS,IND,
NUKB.CF)
6) ARGUMENT TYPES: TABL is an integer array of dimensions ROWS.COLMS. TEST is
an integer array of length NUMB. IND is an integer array of length 5.
All other arguments are single precision integer variables.
7) STATEMENT PURPOSE: This routine is part of the table sort proems. It
compares the indicated values of a table from 1 to the .specified upper limit
entry. The maximum number of levels for the comparison is set to 5. A
comparison check variable is set to indicate the sort comparison result
sequence.
8) CALLED BY: LXSORT
9) CALLS ROTTTINES:
10) COMMONS REFERENCED: None
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED:None"
241
-------
W R A r
PROGRAM SUMMARY SHEET
1)
4)
5)
6)
7)
8)
9)
10)
ID
12)
ROUTINE: LXSORT 2) OVERLAY: MAIN
AUTHOR(S): D. E. Bell
DECLARATION OF STATEMENT: SUBROUTINE LXSORT (TABL
NUMB)
ARGUMENT TYPES: All arguments are integers and si
IND are arrays. LENGTH is the length of TABL, an
dimensions.
STATEMENT PURPOSE: This subroutine sorts the colur
using a lexicographical algorithm. The sort rows
table IfO. IND may have a maximum of 5 -entries..
entries at any call is provided in NUMB. This roi
sort the internal pointer tables that are used to
temporary direct access devices.
CALLED BY: CKSIPR, COLUf'.N, CSTCRD, DSTRTB, LINKS,
PUNCHT, SIPRC, SITE, SOURCE, SSTRTB, TRANS
CALLS ROUTINES: LXCOMP
COMMONS REFERENCED: None
FILES REFERENCED: JEF(6)
3) MODULE: MAIN
, ROWS, COLKS, LENGTH, IND,
nqle precision. TABL and
d'ROWS and COLMS are the
r.ns of the passed table
are ordered in the special
The maximum number of
Jtine is used frequently to
retrieve data stored on
MATRIX, OUTBAS, PROCES,
ERROR CODES AND MESSAGES GENERATED: If the debugging switch is on then the
sorted table will be v/ritten to file JEF.
242
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: MAIN
2) OVERLAY: MAIN 1 3) MODULE: MAIN
4) AUTHOR(S): V. Hensey
5) DECLARATION OF STATEMENT: None
6) ARGUMENT TYPES: 'None
7) STATEMENT PURPOSE: This is the main control program for WRAP. All modules
are called by this program. If a very severe error is detected in editing
modules the program execution is terminated. Major logic control switches are
tested in this routine. All files are defined or set in this program. IDBUG
is initialized to 0, maximum matrix dimensions are set and error flag set to
99.
8) CALLED BY:
Load module
9) CALLS ROUTINES: APRPU, BUILD, COLUMN, CROFLY, DSTRTB, EDIT!. EDIT2,
INITDA, LNKCHK, MATRIX. OUTBAS. SSTRTB. SWAP
10) COMMONS REFERENCED!uniabeied, ERRCOD, FRONT, POUT, PNTR, PROCCO, SIPRCO,
SITECQ. SRCCO, TRANCO. TRKCO
'11) FILES REFERENCED: MUT(5). JEFfS). PFILE(7). FILE1(21). FILE2(22). FILE3(23),
FILE4(24). FILE5(25). FILE6(26). FILE7(27). FILE9(29).OUT(6)
12) ERROR CODES AND MESSAGES GENERATED:
**** LINKAGE MISSING FOR CROWFLY = (option) MISS = (number)
**** USER Requested Short Run (no) (no) PCROU/PMODEL
PROGRAM ABORTS VERY SEVERE ERROR DETECTED IN EDITS.
243
-------
WRAP
PROGRAM SUMMARY SHEET"
1) ROUTINE: MATRIX 2) OVERLAY: BETA 5 3) MODULE: MATRIX 4
4) AUTHOR(S|: D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE MATRIX
6} ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine is the driving routine for the construction
of the matrix arrays. The right hand side, the equation type vector, and
the costing vectors are created through various subroutine calls. The
routine performs initialization for majority of equation buildina routines.
The routine must have a column identification file and a column pointer
table available.
8) CALLED BY: MAIN
9) CALLS ROUTINES: CAPBAL,COST,ED,ISPOB,IUSIB,IUSPC,IUSTC, LANCON, SXSORT, SORBAL!
10) COMMONS REFERENCED: Unlabeled, ERRCOO,FRONT,MAT,RNACO.SETREC"
11) FILES REFERENCED: None~
12) ERROR CODES AND MESSAGES GENERATED: None
244
-------
W R AT
PROGRAM SUMMARY SHEET
1) ROUTINE: NEWA 2) OVERLAY: GA"MA 7 3) MODULE: LINEAR
4) AUTHOR(S): v. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE NEWA
6) ARGUMENT TYPES:'None
7) STATEMENT PURPOSE: This routine generates the sparse form of the current "A"
matrix. It creates the sparse form to help eliminate redundant computations
during phases three and four. If the matrix is too dense the process is not
recoverable and flags are set to terminate the entire execution.
8) CALLED BY: SWAP
9) CALLS ROUTINES: BTRAN. FTRAN. PASSA. REIflV
10) COKMONS REFERENCED: Unlabeled and S1-/APCO
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
245
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: ODYNI t) OVERLAY: GAMMA 8 3) MODULE: OUTPUT
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE ODYNI
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine generates one of the dynamic case reports.
Output is generated by column and code within modeling period. Paging occurs
on each new column activity code or new modeling period.
8) CALLED BY: OUTBAS
9) CALLS ROUTINES: APRINT, FIND, READIT, SER2
10) COMMONS REFERENCED: Unlabeled. READ. SIPRCO, PROCCQ. OCOM, and SETREC
Tl) FILES REFERENCEDrQUT (6)
12) ERROR CODES AND MESSAGES GENERATED: First final report data for dynamic mode
operation.
246
-------
W R A'P
PROGRAM SUMMARY SHEET
1) ROUTINE: ODYN2 2) OVERLAY: GAMMA 6 3) MODULE: OUTPUT
4) AUTHOR(S): M. v. MoTlo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE ODYM2
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This is the second report generation routine for the
dynamic modeling case. Paging occurs on each new column activity. Also
outputs land constraint activity levels.
8) CALLED BY: OUTBAS
9) CALLS ROUTINES: APRItiT. FIND, READIT, SER2
10) COMMONS REFERENCED: Unlabeled, READ, SIPRCO, PROCCO, OCOM, and SETREC
11) FILES REFERENCED": OUT (6) printer
"12) ERROR" CODES AND MESSAGES GENERATED: Second final report for dynamic mode
execution.
247
-------
W R A_P
PROGRAM SUMMARY SHEET
1) ROUTINE: ONENUM 2) OVERLAY: BETA 4 3) MODULE: EDIT2
4) AUTh'OR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE ONENUM"
6) ARGUMENT TYPES:. None
7) STATEMENT PURPOSE: ONENUM checks the Source,Site, and Process files for
duplicate Identification numbers and calls the ERROR routine- for any
duplicates found.
8) CALLED BY: EDIT2
9) CALLS ROUTINES: ERROR
10) COMMONS REFERENCE; Unlabeled, ERRCOD, FRONT, PNTR, POUT
Ti) FILES REFERENCE!); JEF(G)
12) ERROR CODES ANlTMESSAGES GENERATED: 3.2.11. 3*2.12. 3.2.13
248
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: QSTAT 2) OVERLAY: GAMMAS 3) MODULE: OUTPUT
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE OSTAT
6)' ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine prints the final reports for the STATIC
execution mode. The output is controlled by the activity code. The results
are from the final basis and the activity level data from SWAP. When a new
activity is detected a new report page is started. The activities are
column ordered.
8) CALLED BY: QUTBAS
9) CALLS ROUTINES: APRTNT. FIND. READIT
10) COMMONS REFERENCED: Unlabeled, OCOM, READ, SIPRCO, PROCCO, SETREC
11) FILES REFERENCED: nilT (6)
12) ERROR CODES AND MESSAGES GENERATED:None
249
-------
W R A P-
PROGRAM SUMMARY SHEET
1) ROUTINE: OUT 2) OVERLAY: GAMMA 7 3) MODULI: LINEAR
4} AUTKOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE OUT (LINK, ISET)
6) ARGUMENT TYPES: LINK and ISET are single precision integer variables which
are used to control the logic flow.
7) STATEMENT PURPOSE: This is the output subroutine for the linear programming
algorithm. The matrix data, control data, and the objective value and
results for each phase are output.
8) CALLED BY: SWAP
9) CALLS ROUTINES: None
10) COMMONS REFERENCED: Unlabeled and SWARCO
11) FILES REFERENCED: JEF(6)
12) ERROR CODES AND MESSAGES GENERATED: Only data outputs as requested by the user
1. Matrix arrays and counters
2. Results for intermediate phases (vector format)
3. Results for final phase (vector format)
250
-------
VI R A4>
PROGRAM SUMMARY SHEET
1) ROUTINE: OUTBAS 2) OVERLAY: GAMMA 8 3) MODULE: OUTPUT
4) AUTHOR(S): M. V. Mollo-Christensen
5} DECLARATION OF STATEMENT; SUBROUTINE OUTBAS
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine controls the final output report generation.
The'final linear program results are stored in a special table which is used
to sort the results for different print reports. The final basis is also
punched if the user has requested it (PBASE = 1). The output routine is
used by both static and dynanic cases.
8) CALLED BY: MAIN
9) CALLS ROUTINES: FIND, LXSORT, ODYN1, ODY.N2, OSTAT, READIT
io) COXMONS REFERENCED!uniabeied, SWAPCO, RNACO, READ, FRONT, OCOM, and SETREC
11) FILES REFERENCED: PFILE(7) punch. OUT(6) printer
12) ERROR CODES AND MESSAGES GENERATED: Results are printed on OUT
message: "slack or artificial in Basis but not in column table"
printed
on out
251
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: PASSA 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Kensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE PASSA (GETCO)
6) ARGUMENT TYPES: GETCO is a single precision integer variable which contains
a column number.
7) STATEMENT PURPOSE: This routine retrieves one specified column of the matrix
in full form. (For every row there is an entry.)
8) CALLED BY: COMEI, INIT. LP, NEWA, REINV, SIMPL, TINV
9) CALLS ROUTINES: None
10) COMMONS REFERENCED: Unlabeled and SWAPCO
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
252
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: PCOST 2) OVERLAY: BETA 5 3) MODULE: COLUMN
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE PCOST '(IPNT, FC, VC)~
6) ARGUMENT TYPES: -IPNT is a single precision integer variable indicating cost
set to use in calculation. FC is a single precision real variable returning
fixed cost. VC is a single precision real variable returning variable cost.
7) STATEMENT PURPOSE: This routine calculates site/process fixed and variable
costs. In the dynamic case these costs are zero.
8) CALLED BY: COLUMN
9) CALLS ROUTINES: None
10) COMMONS REFERENCED: FRONT, SRCCO, SITECO, SIPRCO, PROCCO, TRANCO
11) FILES REFERENCED: None
IT)ERROR COTES AND MESSAGES GENERATED: None
253
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: PRCHK 2) OVERLAY: BETA 4 3) MODULE: EDIT2
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE PRCHK
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: PRCHK checks all process records for linking consistency
according to the levels of input and output links listed for each process.
8) CALLED BY: EDIT2
9) CALLS ROUTINES; ERROR, FIND, READIT
TO]COtvlOMS REFERENCED: Unlabeled, ERRCOD. FRONT. PNTR. POUT, SRCCO, SITi'CU.
SIPRCO, PROCCO
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED,: 3.5.11 »chru 3.5.16
254
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: PRCOST 2) OVERLAY: BETA 3 3) MODULE: EDIT1
4) AuTHOR(S): M. V. Kollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE PRCOST
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: Subroutine PRCOST computes the number of cost data cards to
expect as input for a process. It reads the card and checks data for
validity. The costing data read is stored in a set of arrays to be written to
the PROCESS temporary disk storage file. Program will abort if the card
identification code is in error, the process id number is wrong, expected
number of cards in error, unexpected end-of-file, or bad data input.
8) CALLED BY: PROCES
9) CALLS ROUTINES: ERROR
TO)COMMONS REFERENCED: Unlabeled. FRONT. PNTR, POUT. PROCCO. and ERRCOD
11) FILES REFERENCED; MUT(5) Card reader, JEF(6)
12) ERROR CODES AND MESSAGES GENERATED: 2.6.4, 2.6.5, 2.6.21
255
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE; PRINT 2) , OVERLAY: ALPHA 2 3) MODULE: FRONTOUT
4) AUTHOR(S): V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE PRINT
6) ARGUMENT TYPES:•None
7) STATEMENT PURPOSE: This routine prints the user supplied input data. The
data is read from temporary storage on dish files. All user data except
the transportation activity file is printed. Transportation data is printed
by PUNCHT.
8) CALLED BY: APRPU
~9) CALLS ROUTINES: READlT
10) COMMONS REFERENCED: Unlabeled. FRONT, PNTR, PROCCO. SIPRCO. SITECO, SRCCO,
TITLRD, TRKCO
TTJFILES REFERENCED: JEF(6)
IT)ERROR CODES AND MESSAGES GENERATED: None
256
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: PROCES 2) OVERLAY: BETA 3 3) MODULE: EDIT1
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE PROCES
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: PROCES reads the two process header control cards. The
input data is checked for validity. The subroutines LINKS and PRCOST are
called to read the possible linkage cards and the process cost cards. After
all reading the data is stored on the disk file allocated for process data
storage. A special record retrieval table is created and sorted by process
ID number.
8) CALLED BY: EDIT1
9) CALLS ROUTINES: DEFLT, ERROR, LINKS, LXSORT, PRCOST
10) COMMONS REFERENCED: Unlabeled. FRONT. PNTR. PROCCO, ERRCOD, POUT
11) FILES REFERENCED: MUT(5) card reader. FILE4 (24) disk
12) ERROR CODES AND MESSAGES GENERATED: 2.6.1. 2.6.2. 2.6.3. 2.6.11 thru 2.6.17
a) Warning message is printed for PRWGT=0.0
"VALID PROCESS BUT MAS 0.0% OUTPUT"
b) Aborts for incorrect card identification codes and invalid process
numbers.
c) FORTRAN ABORTS for bad card characters.
DEFAULTS:
if PREXST is invalid it is set = 1
if PRAVAL is 'no'for period one in static case PRAVAL is set to
'yes1.
257
-------
W R-A P
PROGRAM SUMMARY SHEET
1) ROUTINE; PUNCHM 2) OVERLAY: ALPHA 2 3) MODULE: FRONTOUT
4) AUTHOR(S); v. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE PUNCHM
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: jhis routine punches the model matrix data if the user has
requested it. Data is punched in a manner to be read as matrix input on a
subsequent execution if desired. In output not requested control returns to
main procedure.
8) CALLED BY: APRPU
9) CALLS ROUTINES: None
10) COKKOHS REFERENCED: Unlabeled. FRONT, and POUT
11) FILES REFERENCED: JEF(6), PFILE(7)
i
12) ERROR CODES AND MESSAGES GENERATED:None"
258
-------
W R AT
PROGRAM SUMMARY SHEET
1) ROUTINE: PUNCH! 2) OVERLAY: ALPHA 2 3) MODULE: FRONTOUT
4) AUTHOR(S): V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE PUNCH!
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine punches the transportation file if user
requested and prints the file in a special format. It calls the sorting
routine to order the file before printing.
8) CALLED BY: APRPU
9) CALLS ROUTINES: LXSORT. READIT
10) COMMONS REFERENCED: Unlabeled, FRONT, POUT, PNTR, TRANCO
11) FILES REFERENCED: PFILE(7). JEF(6)
12) ERROR CODES AND MESSAGES GENERATED: None
259
-------
W R A P
PROGRAM SUMMARY SHEET
1) ROUTINE: READIT 2) OVERLAY: MAIN 3) MODULE: MAIN
4) AUTHQR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE READIT (NFILE, L)_.
6) ARGUMENT TYPES: NFILE is a single precision integer variable which
indicates the -file that is to be read. L is a single precision integer
variable which indicates the record.
7) STATEMENT PURPOSE: This routine performs all of the temporary storage re-
trieval. Data records are read from a direct access device. There are 8
files that may be read. The data are stored in various COMMON storage areas.
The files are BCD formated records with unique record numbers.
8) CALLED BY: BUILD, CAPBAL, CKSIPR, COLUMN, COST, CRWLNK, DSTRTB, ED, ICROW1 ,
ICROW2, ISPOB, IUSIB, IUSPC, IUSTC, LANCON, LNKBLD, ODYN1, ODYN2, OSTAT,
OUTBAS, PRCHK, PRINT. PUNCHT,' SIPRC, SORBAL, SSTRTB, TRMCHK
9) CALLS ROUTINES:
10) COMMONS REFERENCED: PROCCO, READ, SIPRCO, SITECO, SRCCO, TITLRD, TRANCO,
TRKCO _ _ '
11) FILES REFERENCED: FILE! (21). FILE2 (22). FII.E3 (23), FT1 FA (?4) , FTI FR (25),
FILES (26). FILE? (27). FILE9 (29)
12) ERROR CODES AND MESSAGES GENERATED:
260
-------
W R-A P
PROGRAM SUMMARY SHEET
1) ROUTINE: REINY 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Cornpuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE REINV
6) ARGUMENT TYPES: ;!one
STATEMENT PURPOSE: This linear programing routine performs the re-
inversion of the "A" matrix. When necessary the levels of the basis entries
are recomputed.
8) CALLED BY: MEWA, SETUB, TINY
9) CALLS ROUTINES:ETAGE, FTRAN, PASSA
10) COMMONS REFERENCED: Unlabeled and SWAPCO
11) FILES REFERENCED;JEF(6) printer
12) ERROR CODES AND MESSAGES GE'.ERATED:11.1.4 The~current basis is not
invertable. Reinversion was proceeding. 11.1.5 The current basis is not
invertable. It has a negative activity level.
261
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: REMOV 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTKOR(S): Ccmpuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE REMOV (COLM1, ROWOU, IFLAG)
6) ARGUMENT TYPES: All three arguments are single precision integer variables.
7) STATEMENT PURPOSE: This removal subroutine checks for negative entries in the
basis columns in the niatrix rov/s corresponding to the artificials. If a
negative entry is found the artificial for that row is removed from the basis.
If an artificial is not removed then the row with the minimum ratio of
activity level/matrix term for the particular column is removed.
8) CALLED BY: LP
9) CALLS ROUTINES: None
10) COMMONS REFERENCED: Unlabeled and SWAPCO
11) FILES REFERENCED: JEF(6) printer
12) ERROR CODES AND MESSAGES GENERATED: 11.1.9 Unbounded solution with column
in the basis.
262
-------
WRAP
PROGRAM SUMMARY SHEfT
1) ROUTINE: SAVE 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE SAVE-(JBASE, TOBJ,- JLAST, TBETA)
6) ARGUMENT TYPES: JBASE and JLAST are single precision integers. JBASE is
an array. TOBJ and TBETA are single precision floating points. TBETA is an
array.
7) STATEMENT PURPOSE: This routine saves the solution basis and activity levels
after calculating the objective value.
8) CALLED BY: FORCE, SETUB, SWAP
9) CALLS ROUTINES: DOTPR
10) COMMONS REFERENCED:Unlabeled and SWAPCO
11) FILES REFERENCED:None
12) ERROR CODES AND "MESSAGES GENERATED: None"
263
-------
W R A P
PROGRAM SUMMARY SHEET
1) ROUTINE: SCOST 2) OVERLAY: BETA 5 3) MODULE: COLUMN
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEf-H.T; SUBROUTINE SCOST (TF, TV IPNT, FC, VC)
6) ARGUMENT TYPES: TF is a single precision real array with the transportation
factors for each modeling period. T is a single precision integer giving the
current period. IPuT is a single precision integer variable (identifies cost
set). FC is a single precision real variable returns fixed cost. VC is a
single precision real variable returns variable cost.
7) STATEMENT PURPOSE: This routine calculates costs (usually, negative) of
running a site/process at less than capacity for a particular modeling period.
The fixed cost is always zero. The variable cost of the unused capacity has
a negative slope.
8) CALLED BY: COLUMN
9) CALLS ROUTINES: None
10) COMMONS REFERENCED;FRONT, SRCCO, SITECO, SIPRCO, PROCCO, TRAMCO
11) FILES REFERENCED: ftone
TTJERROR CODES AND MESSAGES GENERATED:None
264
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SEGS 2) OVERLAY: ALPHA 2 3) MODULE: MAIN
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE SEGS (NSEG, STSEG)
6) ARGUMENT TYPES: fjsEG is a single precision integer variable, returns
segment count. STSEG is a single precision integer variable, contains
special code.
7) STATEMENT PURPOSE: This routine is used to decode the user-supplied code.
It returns a count of the number of segments possible for a particular pro-
cess. (NSEG) and the first segment to be used (STSEG).
STSEG = 12 then NSEG = 2; STSEG = 1
STSEG = 13 then MSEC = 3; STSEG = 1
STSEG = 23 then NSEG = 2; STSEG = 2
STSEG = 1, 2, or 3 then NSEG = 1; STSEG = STSEG
8) CALLED BY: CKSIPR, COLUMN
9) CALLS ROUTINES: None
10) COMMONS REFERENCED-
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
265
-------
WRAP
PROGRAM SUMMARY-SHEET
1) ROUTINE: SER2 2) OVERLAY: GAMMA 8 3) MODULE: OUTPUT
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE SER2" (ID, ILEV)
6) ARGUMENT TYPES: ID and ILEV are single precision integer variables.
7) STATEMENT PURPOSE: This routine checks to determine if a slack entry in the
BASIS vector is for a land constrained equation. The check is made by
searching the row identification table and then matching the location of the
slack entry against the location of the first land equation.
8) CALLED BY: QDYN1, ODYN2
9) CALLS ROUTINES: None
~10) COMMONS~REFER£NCED:Unlabeled, RNACO, and OCOM
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
266
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SETC 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4} AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE SETC (COEF)
6) ARGUMENT TYPES: COEF is a single precision real variable which contains the
matrix coefficient.
7) STATEMENT PURPOSE: This routine stores the predetermined coefficient into the
matrix vector A. The current row nurr.ber (M) is stored -in ROH. The current
column value (MCMA) is stored in COL. The storage'index NUMNZ is tested to be j
sure it does not exceed the allowable array size, when it is too large EP.RCR
is called, a message is generated and the program aborts.
8) CALLED BY: CAPBAL, ED, ISPOB, IUSIB, IUSPC, IUSTC, LANCON, SOR3AL
9) CALLS ROUTINES: ERROR
10) COMMONS REFERENCED: Unlabeled. ERRCOD. MAT
11) FILES REFERENCED: None
12) ERROR COOES AMD MESSAGES GENERATED: Generates error number 6.3.3.
Ms\ *•*•-, -it r%. i 14-it t i 4- Kir CTDDHD
Message output by ERROR
267
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SETR 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4) AUTHOR(S): V. Hensey
D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE SETR (RHS, ITYPE)
6) ARGUMENT TYPES: RHS is a single precision real variable which contains the
right hand side value. ITYPE is a single precision integer variable which
contains the value for the equation type code.
7) STATEMENT PURPOSE: This routine adds a row to the matrix, sets up the right
hand side, sets up the equation type, and sets up the row identification
vectors. Prior to setup a test is made to make sure that the number of rows
does not exceed dimension allowance if so ERROR is called, a message is
generated, and the program is aborted.
8) CALLED BY: CAPBAL, ED, ISPOB, IUSIB, IUSPC, IUSTC, LANCON, SORBAL
9) CALLS ROUTINES: ERROR
10) COMMONS REFERENCED: Unlabeled, ERRCOD, MAT, RNACO
11) FILES REFERENCED:
12) ERROR CODES ANDMES SAGES GENERATED; Generates error code 6.2.2.
The message is output by ERROR
268
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SETUA 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHQR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE SETUA
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine determines the slack variables necessary,
arranges a sparse "A" matrix and counts the number of zero entries in each
matrix column.
8) CALLED BY: SWAP
9) CALLS ROUTINES: FSORT
10) COMMONS REFERENCED: Unlabeled and SWAPCO
11) FILES REFERENCED":
12) ERROR CODES AND MESSAGES GENERATED: Problem terminated due to initialization
procedures. Overflowing available storage.
11.1.6 Number of elements in Initial A matrix including required and surplus
variables has exceeded the limit allowed for storage which is currently set
at 8100
11.1.7 Number of columns, including required slack and surplus variables,
has exceeded the limit allowed for storage which is currently set at
360
269
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SETUB
2) OVERLAY: GAJ'MA 7 3) MODULE: LINEAR
4) AUTHOR(S): Ccnipuviscr, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE SETUB (ARRAY, 1ST, BTA)
6) ARGUMENT TYPES: ARRAY is a single precision integer array. LST is a single
precision integer variable. BTA is a single precision floating point array.
7) STATEMENT PURPOSE: This routine performs a test of a basis vector. Program
status is set based on the feasibility of the current basis. If it is the
first phase and the basis is not feasible then a special column 'Z' is in-
serted in the basis in place of the column with the largest negative activity
level. Then the reinversion is tried again. If both attempts fail the pro-
gram sets flags for appropriate termination. If basis is acceptable it is
saved.
8) CALLED BY: FORCE, INIT, SWAP
9) CALLS ROUTINES: BTRAN, REINV, SAVE, ZCOLM
10) COMMONS REFERENCED: Unlabeled and SWAPCO
11) FILES REFERENCED: JEF(6) printer
12j ERROR CODES AND MESSAGES GENERATED:11.13.1 ERROR new column to be inserted.
Old Column New Column
270
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SIMPL 2) OVERLAY: GAFMA 7 3) KODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE SIMPL (COLMI)
6) ARGUMENT TYPES: .COLMI is a single precision integer variable which contains
the column trying to enter the basis.
7) STATEMENT PURPOSE: This is the simplex routine. If the phase = 3 then the
fixed charge criterion is used to find a solution better than that found by
the linear programming algorithm. If the execution phase = 4 then the col inn
is forced into the basis. If single forcing is indicated the forcing attetrpt
•will be made and then control returns. If double forcing has been indicated
then iteration continues until a local optimum solution is reached.
8) CALLED BY: FORCE, SWAP
9) CALLS ROUTINES: BTRAN, DOTPR, ETAGE, FTRAN, PASSA, TIMV
10) COMMONS REFERENCED: Unlabeled and SWAPCO
ii) FILES REFERENCED!
12) ERROR COOES AND MESSAGES GENERATED:
271
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SIPRC 2) OVERLAY: BETA 3 3) MODULE: EDIT!
4) AUTHOR(S): M. V. MoTlo-Christensen
5) DECLARATION OF STATEMENT; SUBROUTINE SIPRC
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: Subroutine SIPRC reads the site-process input data cards.
The data is checked for validity. The data is stored on a disk file. A table
of record pointers is created for record retrieval. Using data from the pro-
cess file a new array is created. This array indicates the useability of a
particular process during a modeling period. This routine sets 'a flag to
terminate in EDIT2 if a process on the input card has not been input as oart
of the process data. If invalid card ID code, bad data or an unexpected end
of file is found, the program will be terminated imnediately.
8) CALLED BY: EDIT!
9) CALLS ROUTINES: ERROR, FIND, LXSORT, READIT
10) COMMONS REFERENCED: Unlabeled. FRONT. PNTR. SIPRCO. PROCCO, ERRCOD. POUT
11) FILES REFERENCED: MUT(5). JEF(6K FILE? (27)
12) ERROR CODES AND MESSAGES GENERATED; When IDBUG 1s on: "BEGIN SIPRC"
followed by input data then "END SIPRC".
Error codes 2.7.1, 2.7.2, and 2.7.11 thru 2.7.16
272
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SITE 2) OVERLAY: BETA 3 3) MODULE: EDIT]
4) AUTHQR(S): M. V. MoTlo-Christensen
5) DECLARATION OF STATEMENT; SUBROUTINE SITE
6) ARGUMENT TYPES: None
7) -STATEMENT .PURPOSE; Subroutine SITE reads and checks the validity of data on
the site identification input cards. This data is stored on disk. A pointer
table is created to retrieve records by record number. The table contains the
record number and the site identification number. The program aborts if there
is an input error or an unexpected end-of-file. If the input control card
code is wrong the program will abort.
8) CALLED BY: EDIT!
9) CALLS ROUTINES: ERROR, LXSORT
10) COMMONS REFERENCED: Unlabeled, ERRCOD, FRONT, PNTR, POUT, SITECO
11) FILES REFERENCED: K'JT(5). FILE3 (23K JEF(6)
12) ERROR CODES AND MESSAGES GENERATED: When IDBUG is on ''BEGIN SITE"
Output site data as read "END SITE"
Error codes 2.5.1, 2.5.2, and 2.5.11 thru 2.5.17 see ERROR for messages.
273
-------
W R k P
PROGRAM SUMMARY SHEET
1) ROUTINE: SORBAL 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE SORBAI 'I.IPER)
6) ARGUMENT TYPES: I is a single precision integer v/hich indicates source
column. IPER'.is a single precision integer containing current period.
7) STATEMENT PURPOSE: This routine builds the source balance equations. The
matrix coefficients are set to +1.
8) CALLED BY: MATRIX
9) CALLS ROUTINES: INITLP, READIT, SETR, SETC, TBREAD
10) COMMONS REFERENCED: MAT, READ
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
274
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SOURCE 2) OVERLAY: BETA 3 3) KODULE; EDIT1
4) AUTKOR(S): M. v. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE SOURCE
6) ARGUMENT TYPES;• None
7) STATEMENT PURPOSE: Subroutine SOURCE reads and checks for validity the data
on each source input cerd, this data is stored on disk (file2). Source
creates a sorted pointer table containing an identification number and disk
record nur.ber for each source. Execution term'nates if the card identifica-
tion code is incorrect, bad input characters are read or an end of file is
reached unexpectedly.
8) CALLED BY: EDIT!
9) CALLS ROUTINES: ERROR,LXSORT
10) COMMONS REFERENCED: Unlabeled, ERRCOD, FRONT, PNTR, POUT, SRCCO
11) FILES REFERENCED:File2 (22), JEF(6)
12) ERROR CODES AND MESSAGES GENERATED: when IDBUG is on "BEGIN SOURCE"
source data as input
"END SOURCE"
Error codes generated (see EEEOR for messages) 2.4.1, 2.4.2, 2.4.11 thru
2.4.15
275
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SSTRTB 2) OVERLAY: BETA 5 3) MODULE: BASIS
4) AUTHOR(S): V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE SSTRTB
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine is used to generate a starting basis for the
linear program algorithm. The routine is used for static executions only.
The column identification records and the row identification vectors are used
to determine which columns are placed in the starting basis vector. Only m
entries are assigned.
8) CALLED BY: MAIN
9) CALLS ROUTINES: DBLFND, LXSORT, READIT
10) COMMONS REFERENCED: Unlabeled, POUT, PNTR, RNACO, SETREC, FRONT, SIPRCO,
READ, SITECO, PROCCO
11) FILES REFERENCED: JEF(6)
12) ERROR CODES AND MESSAGES GENERATED: Only debugging messages are produced when
IDBUG is on.
276
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: SWAP 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION1 OF STATEMENT: SUBROUTINE SWAP
6) ARGUMENT TYPES: Mone
7) STATEMENT PURPOSE: This subroutine is the main control routine for the Fixed
Charge Solution System which uses the SWIFT algorithm developed by Walker.
The principal logic flow is controlled and executed from this procedure. Cer-
tain error check variables are initialized by the routine. When execution is
completed or abnormally terminated, control returns to the main calling
routine.
8) CALLED BY: MAIN
9) CALLS ROUTINES: PQTPR. FORCE. INIT. LP. NEWA. OUT. SAVE. SETUA, SETUB, SIf-'PL
10) COMMONS REFERENCED;Unlabeled and SWAPCO
11) FILES REFERENCED:jEF(6)
12) ERROR CODES A.'.'D MESSAGES GENERATED: n.1.10 Matrix overflow, 11.1.11 No
feasible solution, 11.1.11A Z COL IN BASIS. PROGRAM HALTS.
277
-------
W HA-P
PROGRAM SUMMARY SHEET
1) ROUTINE: SWITC 2) OVERLAY: QATOIA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey (MITRE)
5) DECLARATION OF STATEMENT: SUBROUTINE SK'ITC
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine calculates the objective.value at the end of j
phase 1. If artificials remain at a positive level there-'is no feasible I
solution. If the solution is feasible then the variable costs are stored in
the cost vector, the phase is set to 2 and the basis is transformed for
phase 2 execution.
8) CALLED BY: COMEI
9) CALLS ROUTINES: BTRAN, DOTPR
10) COMMONS REFERENCED: imiahPlpH anH
11} FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED: None
278
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: TBASIS 2) OVERLAY: BETA 3 3) MODULE: EDIT!
4) AUTHOR(S): M. V. MoTlo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE TBASIS
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: Subroutine TBASIS reads the user-supplied input starting
Basis. The values read are stored in the vector BASIS. This routine is only
called when the IBASE value on the COMTRL card is set to 2. Reading is
terminated when a zero value is read. Program terminates abnormally if read
errors occur or end of file before expected.
8) CALLED BY: EDIT1
9) CALLS ROUTINES:ERROR
10) COMMONS REFERENCED: Unlabeled, ERRCOD, POUT
11) FILES REFERENCED: HUT(5). JEF(6)
12) ERROR CODES AND MESSAGES GENERATED: When ID3UG is on
"BEGIN TBASIS" and
"END TBASIS"
Error code 2.0.1 see ERROR for message
279
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: TBREAD 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4) AUTHOR(S): D. H. Lehman
5) DECLARATIOH OF STATEMENT: SUBROUTINE TBREAD(I)
6) ARGUMENT TYPES: I is a single precision integer indicating which entry in
pointer table to pick up.
7) STATEMENT PURPOSE: This routine accesses the pointer table (TBMATC) for the
column identification records. The table entries are stored temporarily in
labeled conrnon for subsequent referencing.
8) CALLED BY: CAPBAL, ED, ISPOB, IUSIB, IUSPC, IUSTC, LANCON
9) CALLS ROUTINES: j^
10) COMMONS REFERENCED: MAT. SETREC
11) FILES REFERENCED- None
12j ERROR CODES AND MESSAGES GENERATED:None
280
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: TCOST 2) OVERLAY: BETA 5 3) MODULE: COLUMN
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE TCOST .(.ID, TF,. T, FC, VC)
6) ARGUMENT TYPES: ID is a single precision variable with identification of
current origin. • TF is a single precision array with transportation factors.
T is a single precision integer with current period. FC is a single pre-
cision real variable returns fixed cost. VC is a sing"!? precision real
variable returns variable cost.
7) STATEMENT PURPOSE: This routine calculates the I x, cost and the variable
cost for each transportation activity in a mode1 or period. Fixed costs are
always zero. Variable costs are dependent on o >^r. being a source or a site,
If travel time is less than 0 the variable cost zero.
8) CALLED BY: COLUMN
9) CALLS ROUTINES: None
10) COMMONS REFERENCED: FRONT, SRCCO, SITECO, SIPRCO, PROCCO, TRANCO
11) FILES REFERENCED: Hor\e
12) ERROR CODES AND MESSAGES GENERATED: None
281
-------
W R A-P
PROGRAM SUMMARY SHEET
1) ROUTINE: TINV 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): Compuvisor, Inc.
V. Hensey C^TRS
5) DECLARATION OF STATEMENT: SUBROUTINE TINV
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine performs a matrix reinversion under tv:o
conditions: the current vector is full or the last tolerance check hac more
than a negligible error. Tolerance checks are made every fifth iteration
unless the last check shows appreciable error and then tolerance is checked
on every iteration.
8) CALLED .BY: |_P, SIMPL
9) CALLS ROUTINES: BTRAN, DOTPR, PASSA, REINV
10) COMMONS REFERENCED: UnTabled and SWAPCO
11) FILES REFERENCED: None
12} ERROR CODES AND MESSAGES GENERATED: None
282
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: TRANS 2) OVERLAY: BETA 3 3) MODULE: EDIT!
4) AUTHOR(S): M. v. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE TRANS
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: TRANS reads and does range and existence checking for the
user-supplied transportation activity records. The data is stored on disk
(FILES). A table of record pointers and ID's (sorted by origin ID, then
Process ID, then destination ID) is created for record retrieval. Execution
is terminated immediately if an invalid card ID code, bad data or an un-
expected end of file is found.
8) CALLED BY: EDIT1
9) CALLS ROUTINES: LXSORT, ERROR
TO) COMMONS REFERENCED: Unlabeled, ERRCOD, FRONT, PNTR, POUT, TRANCO
11) FILES REFERENCED: FILES (25). JEFfSK MUT(^)
12) ERROR CODES AND MESSAGES GENERATED:2.8.1, 2.8.2, 2.8.11 thru 2.8.16
283
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: TRFAC 2) OVERLAY: BETAS 3) MODULE: COLUMN
4) AUTHOR(S): D. H. Lehman
5) DECLARATION OF STATEMENT: SUBROUTINE TRFAC (TF)
6) ARGUMENT TYPES: TF is a single precision real array which returns the
transportation.factors for each period.
7) STATEMENT PURPOSE: This routine calculates all of the transportation cost
factors. A factor is calculated for each modeling period. In the dynamic
case the discount rate and inflation rates are used in the calculation.
CALLED BY: COLUMN
9} CALLS ROUTINES: None
10) COMMONS REFERENCED: FRONT, SRCCO, SITECO, SIPRCO, PROCCO, TRANCO
ii) FILES REFERENCED!
12) ERROR CODES AND MESSAGES GENERATED: None
284
-------
W R-A P
PROGRAM SUMMARY SHEET
1) ROUTINE: TRNCHK 2) OVERLAY: BETA 4 3) MODULE: EDIT2
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT; SUBROUTINE TRNCHK
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: TRNCHK checks all transportation input cards for consis-
tency as follows:
1) checks that type code corresponds to IDs
2) checks out duplicate records using DUP
3) checks that origin and process had records read
4) checks that the destination can link to the origin/process.
The user transportation file is printed for checkout if a severe error is
found.
8) CALLED BY: EDIT2
9) CALLS ROUTINES:DUP, ERROR, FIND, READIT
10) COMMONS REFERENCED:Unlabeled, ERRCOD, FRONT, PNTR, SRCCO, SITECO, SIPRCO,
PROCCO, TRANCO, TRKCO, POUT
11) FILES REFERENCED:OEF(6)
12) ERROR CODES AND MESSAGES GENERATED:3.6.11 thru 3.6.16
285
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: TRUCK 2) OVERLAY: BETA 3 3) MODULE: EDIT!
4) AUTHOR(S): M. V. Mollo-Christensen
5) DECLARATION OF STATEMENT: SUBROUTINE TRUCK
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: TRUCK reads and checks data for each truck-constraint
card and stores this data, as read on disk.
8) CALLED BY: EDIT!
9) CALLS ROUTINES: ERROR
10) COKMOHS REFERENCED: Unlabeled. ERRCQD. FRONT. PNTR. POUT. TRKCQ
11) FILES REFERENCED: FI1.F6 (Disk file 26). HUT(S). .IFF(fi)
12) ERROR CODES AND MTSSAGES GENERATED:2.9.1, 2.9.2, 2.9.11, 2.9.12
286
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: ZCOLIN 2) OVERLAY: GAMMA 7 3) MODULE: LINEAR
4) AUTHOR(S): V. Hensey
5). DECLARATION OF STATEMENT: SUBROUTINE ZCOLIN (BASIS, BETA, IOLD, INEW, H)
6) ARGUMENT TYPES: BASIS is a single precision integer array. BETA is a single
precision floating point array, IOLD, INEW, and M are single precision integer
variables.
7) STATEMENT PURPOSE: ZCOLIN is a special linear program routine which changes
a starting BASIS. If a BASIS has a negative activity column in the
initialization phase of the linear program algorithm then this routine is
called. The activity levels are checked and the one with the largest
negative value is replaced by a special column pointer "Z". The phase switch
is reinitialized and control returns for a recheck of the new BASIS.
8} CALLED BY: SETUB
9) CALLS ROUTINES: None"
10) COMMONS REFERENCED:SBASI
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED:None"
287
-------
WRAP
PROGRAM SUMMARY SHEET
1) ROUTINE: ZCOLMN 2) OVERLAY: BETA 5 3) MODULE: MATRIX
4) AUTHOR(S): V. Hensey
5) DECLARATION OF STATEMENT: SUBROUTINE ZCOLMN
6) ARGUMENT TYPES: None
7) STATEMENT PURPOSE: This routine constructs a new matrix column referred
to as "Z". The coefficients are set to -1 for all type 1 equations. The
variable cost is set to $1000 and the fixed cost is set to zero. The last
normal column number is saved in a labeled COMMON.
8) CALLED BY: MATRIX
9) CALLS ROUTINES: None
10) COMMONS REFERENCED: Unlabeled and SBASI
11) FILES REFERENCED: None
12) ERROR CODES AND MESSAGES GENERATED:f^ne"
288
-------
APPENDIX III
COMMON STORAGE ALLOCATION TABLES
There are twenty common storage areas in the WRAP program. This
appendix presents those areas in alphabetical sequence with the al-
located variables in their order of appearance within the area. The
unlabeled common is the first area presented.
The information provided for each variable includes: (1) vari-
able name, (2) dimension (if any), (3) description of contents, (4)
possible values, and (5) FORTRAN data type.
289
-------
UNLABELED COMMON STORAGE
Variable*
KOPT
MUT
JEF
FILE1
FILE2
FILES
FILE4
FILE5
FILE6
FILE?
FILES
FILE9
NFORC
NPHAS
(LPHASE)
INDSD
FC(450)^
VC(360)^
Contents
LINEAR module output
control variable
User's input card
reader file number
Printer file number
Title temporary file
number
Source file number
Site data file number
Process data file number
Transportation data file
number
Truck constraint data file
number
Site-process data file
number
Not used
Column identification
records file number
Forcing to be used in
phase 4--users input
Last phase of model
execution — users input
Steepest descent requested
— users input
Column fixed costs array
Column variable costs array
Value
1 , 2 or 3
5
6
21
22
23
24
25
26
27
28
29
1 or 2
1, 2, 3, or 4
1 or 2
(0 or 1)
Computed
Computed
Data Type4"
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
R
R
290
-------
Variable*
B(90)^
BETAO(90)7*
A(8,00)*
RNA(90)^
CNA(450)^
INDIC(90) ^
BASIS(90)^
ROWCSIOO)^
COL (81 00) ^
"'
»'
NUMNZ^
MAXM^
MAXN74
MAXA?4
Contents
Righthand side vectoi —
capacity constraints array
Old activity levels
Non-zero elements
of "A" matrix
Row ID. for "A" matrix
Column ID. for "A" matrix
Type of equation--(equal
to or less than)
Basis for optimization
Matrix row values
Matrix column number
values
Number of rows in "A"
matrix
Number of columns in
"A" matrix
Number of non-zero elements
in the "A" matrix
^ Maximum number of rows
dimensioned
Maximum number of columns
dimensioned
Maximum number of non-zero
entries for "A" matrix
Value
Computed
Computed
Computed
1-90
1-450
-1, 0, 1
Computed
1-90
1-450
1-90
Computed
1-450
1-8100
90
360
8100
Data Type1"
R
R
R
I
I
I
I
I
I
I
I
I
I
I
I
*Values enclosed in parenthesis are the dimensions of the array
for WRAP. Other values are the actual permissible numeric or character data.
+1 = integer, R = real
^Indicates that this value or dimension may be altered to handle
different sized problems.
291
-------
"ERRCOD" COMMON STORAGE
Variable* Contents Value Data Type*
LERR (2) Array of 2 entries, used Set by I
to pass information about subroutines
errors to the ERROR routine
entry 1 - program module
ID number
entry 2 - subroutine
ID number
*Value in parenthesis is the dimension
+1 = integer
292
-------
"FRONT" COMMON STORAGE
Variable
STURNT
FACTR
CINFLR
CDISCR
FLAG
MTYPE
IBASE
PBASE
I CROW
PCROW
PMODEL
ITRUCK
NYEARS
NPERID
NSOURC
NISITE
Content
Standard turn around
time
Nautical miles/nrin of
longitude
Inflation rate for
dynamic case
Discount rate for
dynamic case
Error severity code
Mode of execution
(static or dynamic)
Availability of starting
basis (no or yes)
Punch final basis (no or
yes)
Crowfly option (no,
option 1 , option 2)
Punch transportation re-
sults (no, stop, continue)
Punch prepared model
(no stop, continue)
Truck constraint option
Total years in planning
period
Number of model periods
Number of sources
Number of intermediate
Value Data Type+
01.0 - 60.0
0.001-1.000
1.0000-9.9999
0.0000-1.0000
0-4
1 or 2
1 or 2;
[0 or 1]^
1 or 2;
[0 or 1] ^
0, 1 or 2
0, 1 or 2
0, 1 or 2
i
1 or 2
[0 or 1] *
01-99
1-4
001-100
00-25
R
R
R
R
I
I
I
I
I
I
I
I
I
I
I
I
sites
-------
Variable*
NUSITE
NPROCS
NSIPR
NTRANS
NISTRK
MYEAR(4)
TRPACK
TRTRAN
JUMP
RADIUS
SPEED
Content
Number of ultimate sites
Number of processes
Number of site/process
Number of transporting
activities
Number of truck records
A vector with four entries,
each entry gives the number
of years in the correspond-
ing model period
Capacity of packer vehicles
Capacity of transfer
vehicles
Jump to model code
(currently not used)
Maximum radius
Standard speed
Value
01-25
01-20
001-125
000-300
00-25
1-99
01-99
01-99
1 or 2
[0 or 1]^
001-700
01-99
Data Type*
I
I
I
I
I
I
I
I
I
I
I
*Values enclosed in parenthesis are dimensions
+1 = integer, R = real
^These variables are read in as either a 1 or 2, but are
converted in Edit2 to 0 or 1.
294
-------
'LNK" COMMON STORAGE
Variable*
ORIG(125,3)
DEST(50,2)
ORIGL
DESTL
MISS
Contents
Possible origins,
1) ID number,
2) process,
3} link check code
Possible destinations
1) ID, 2) link check
Length of origin
table
Length of destination
table
Number of missed links
Value Data Type +
100-499 I
500-699
500-799 I
Computed I
Computed I
Computed I
+1 = integer
*values enclosed in parenthesis are dimensions
295
-------
'MAT" COMMON STORAGE
Variable
MCNA
MACODE
MSITE
MPROC
MDEST
MPEROD
MREC
I START
IEND
IOLDID
IOLDPR
MLE
MEQ
Contents
Current column
identification code
Current column activity
code
Current equation
identification
Current equation
process code
Current equation
destination
Current column model
period
Current record pointer
Starting column for
processing logic
Last column for
processing
Previous or current
equation ID
Previous or current
process ID
Equation type indicator
Equation type indicator
Value
1-360
1-8
100-799
900-999
100-499
500-799
1-4
1-360+
1-360+
1-360+
100-799
900-999
1
1
0
Data Type*
I
I
I
I
I
I
I
I
I
I
I
I
I
*T -
I = integer
+Upper value may change for different sized
program versions
296
-------
OCOM" COMMON STORAGE
Variable*
CRES(90,7)7*
PAGE
NLINE
SERTAF
SCNT
Contents
Basis results
1) column, 2} period,
3) activity code,
4) location, 5) activity
ID, 6} activity process,
7) activity segment number
Page number
Line counter
Row identification
Equation counter pointer
Value
Computed
1-
50
1-907*
0-90 T4
Data Type?*
I
I
I
I
I
*Value enclosed in parenthesis is dimension of array in current
program version
+1 = integer
^Upper limit varies in different sized programs
297
-------
"PNTR" COMMON STORAGE
Variable*
Contents
Value
Data Type*
TBSR (100,2) Table of pointers to
source records on FILE2
Column 1 - source ID
Column 2 - record number
TBSI (50,2)
Table of pointers to
Site records on FILES
Column 1 - Site ID
Column 2 - record number
100-499
1-100
500-799
1-50
I
TBSIPR
(125, 3)
TBPR (20, 2)
TBTRAN
(450, 5)
Table of pointers to
Site/process records
on FILE7
Column 1 - site ID
Column 2 - process ID
Column 3 - record number
Table of pointers to
process records on FILE4
Column 1 - process ID
Column 2 - record number
Table of pointers to
transportation records
on FILE5
Column 1 - type code
Column 2 - origin ID
Column 3 - origin process
ID
Column 4 -
Column 5 -
destination ID
record number
500-799
800-999
1-125
800-999
1-20
1, 2, 3, 4 or 5
100-699
100-499, 800-999
500-799
1-300
^Values enclosed in parenthesis are dimensions of the array
I = integer
298
-------
"POUT" COMMON STORAGE
Variable Contents Value Data Type*
PFILE Output punch file 7 I
IDBUG Debugging switch 0 or 1 I
OUT Output report file 6 I
* I = integer
299
-------
"PROCCO" COMMON STORAGE
Variable*
PRID
PRNAME
PRSEG
PRLEVL
PREXST
PRWGT
PRDEN
PRHC$ (4)
PRLEAD
PRAVAL (4)
Contents
Process identification
number
Name of the process
-Number of segments
Process level code
Code indicating whether
a process is existing
or new
Percent output by weight
Output density
A vector of 4 elements,
each containing the process
haul cost for the period
corresponding to the vector
index
Capital lead time
A vector of 4 elements,
each containing a no - yes
Value
800-999
20 characters
1, 2 or 3
A, B, C or D
1 or 2
(0 or 1)*
00000.00-
0001 -
000.00000 -
0-9
1 or 2
[0 or I]*4
! ' , :
Data Type
I
R
I
R
I
R
I
R
I
I
code indicating whether the
process is available to be
built in the period corre-
sponding to the vector index
PRLIFE (4) A vector of 4 elements,
each indicating the life
of the facility if built
in the period correspond-
ing to the vector index.
Life is given as the num-
ber of the period through
which the facility would
last
0-4
300
-------
Variable*
Contents
Value
Data Type+
LINKI (36)
LINKO C36)
SET (12)
PRCSLP (12)
PRCINT (12)
PROSLP (12)
PROINT (12)
LINKNO
OLNKNO
A vector of 36 elements;
contains ID's of the
input links possible
for a process, first
element indicates (no,
yes) whether sources
can link to the process
A vector of 36 elements;
contains ID's of the out-
put -links possible for a
process
A vector of 12 elements;
contains the cost set
identifiers for cost cards
read
A vector of 12 elements;
contains the capital slopes
per segment per period
A vector of 12 elements;
contains the capital inter-
cepts per segment per period
A vector of 12 elements;
contains operating slopes
per segment per period
A vector of 12 elements;
contains operating inter-
cepts per segment per period
Number of input links that
were read (including source
indicator)
element 1;
1 or 2
elements 2-36:
0 or 800-999
0 or 800-999
11, 12, 13
21, 22, 23
31, 32, 33
41, 42, 43
000.000000 -
000000.000 -
000.000000 -
000000.00 -
1-36
Number of output links read 1-36
*Values enclosed in parenthesis are dimensions of array
+1 = integer, R = real
^Variable input as a 1 or 2 then converted to 0 or 1
301
-------
"READ11 COMMON STORAGE
Variable*
JCNA
NTYPE
ICODE
ID1
ID2
IDS
MPERID
ONAME (5)
DNAME (5)
SOTON
FCCNA
VCCNA
Contents
Column identification
number for a single record
Special code to identify
the type of column
Column activity code
Origin identification for
transportation activities
Site identification for all
others
Origin process identification
Destination identification
for transportation activities,
site identification for all
others
Model period of column
activity
ID1 alphanumeric name
IDS alphanumeric name
Tonnage for a source
activity for a given column •
Fixed cost for column
activity
Variable cost for column
activity
Value
1-360?
1-8
1-8
100-799
100-499,
900-999
500-799
1-4
20 characters
20 characters
0000.0-9999.9
Computed
Computed
Data Type*
I
I
I
I
I
I
I
I
I
R
R
R
Values enclosed in parenthesis are dimensions of the array
+I = integer, R = real
Clipper value may change for different sized program versions
302
-------
"RNACO" COMMON STORAGE
Variable*
RNALND
(IDRNA)
IDRNAD
Contents
Pointer to first equation
number for land constraint
equations
Origin id and process
codes for each row
(equation)
Destination id code
for each row (equation)
Value Data Type +
Computed I
(<90)
100-699 I
800-999
500-799 I
*Values in parenthesis are dimensions of the array in current
program version
+1 = integer, R = real
/Values may change for different sized program versions
-------
"SBASI" COMMON STORAGE
Variable Contents Value Data Type*
NORIG Last column number before Computed I '; '
'Z1 column created
NROWOU Basis column entry Computed I
replaced by 'Z1 column
* I = integer
304
-------
"SETREC" COMMON STORAGE
Variable1
Contents
Value
Data Type'*
TBMATC
(360, 7)F
NSI (4)
Pointers for column
identification record
1) CNA, 2) code, 3) orig,
4
6
) process, 5) destination,
) period, 7) record number
For each period the number
of input balance equations
of rows
Only values
already de-
fined for
identification
values
0-25
COLCNT (4)
MUM (20)
Last column pointer for 1-450
each model period
Not used currently
I
I
*Values enclosed in parenthesis are dimensions of arrays for current
program version
+1 = integer
7*Value changes for different sized program versions
305
-------
"SIPROC" COMMON STORAGE
Variable*
SPIDS
SPIDP
SPSEG
SPCAP
SPREV$ (4)
Contents
Site identification number
Process identification
number
Site-process segment
codes
Site-process capacity
Revenue per input ton
for a dynamic modeling
Value
500-799
800-999
1. 2, 3, 12,
23, or 13
0000-9999
000.000-
999.999
Data Type*
I
I
I
I
R
period
SPLVL Site-process process
level code
PRUSBL (4) Process usability indicator
for each dynamic modeling
period. Code indicates
yes or no
A, B, C or D R
0 or 1 I
*Value in parenthesis is array dimension
+1 = integer, R = real
306
-------
"SITECO" COMMON STORAGE
Variable*
Contents
Value
Data Type"4
SIID Site identification
number
SINAME (5) Site name
SICODE Site limit restruction
code
SILONG Site longitude in
degrees, minutes
SILAT Site latitude in
degrees, minutes
SIPROC Maximum number of
processes allowed at
site
SICOST Site preparation cost
SILAND Maximum land available
at site
500-799
20 characters R
1 or 2 I
[0 or 17
00/01.0 - R
00/01.0 R
1-9 I
±00000.01 - R
000000 - I
999999
*Value in parenthesis is array dimension
I = integer, R = real
is converted from 1 or 2 to 0 or 1 by program
307
-------
"SRCCO" COMMON STORAGE
SONAME (5)
SOLONG
SOLAT
SOTONS (4)
SOHC$ (4)
Source name
Source longitude in
degrees and minutes
Source latitude in
degrees and minutes
Waste tonnage per source
for each modeling period
Haul cost per ton - minute
of source waste for each
modeling period
20 characters
00/01.0 -
00/01.0 -
0000.0 -
9999.9
.00000 -
.99999
R
R
R
R
R
*Value in parenthesis is array dimension
+I = integer, R = real
308
-------
"SWAPCO" COMMON STORAGE
Variable*
ALPHA
(90)*
BEP
BEP1
EP
EP1
HEP
HEP1
TEP
TEP1
BETA ,
(90)*
BETAL
(90)*
ETA (90) ?«
NU
OLDOB
PI
PSI
Contents
Matrix coefficients for
a column
Basic accuracy test
variable
Basic accuracy test
variable
Changing accuracy test
variable (initial)
Changing accuracy test
variable (initial)
Forcing test variable
set to current EP
Forcing test variable
set to current EP1
Accuracy test variable
(initial)
Accuracy test variable
(initial)
Right hand side—capacity
Initial right hand side
Simplex transformation
vector
Calculated PI product sum
Objective value
Cost vector
Calculated ALPHA product
Value
Computed
5.E-9--
5.E-4
5.E-9
5.E-4
Computed
Computed
5.E-4
5.E-4
Computed
Computed
Computed
Computed
Computed
Computed
Computed
Data Type4"
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
sum
309
-------
Variable*
PSIOF^
(360)*
CST (360)^
ETAFI
(8100)
PHASE
IBASE
IETAP
I FORCE
LASTI
INTR
INVT
LAST
LASTO
MAXTR
NIT
NTRAN
OB AS I
(90 )#
PTR
ETAEN
Contents
Vector of various vector
product sum
Algorithm cost vector
Expansion matrix vector
Indicates current phase
or phase error
Indicates initial basis
supplied
Internal ETA vector
pointer
Forcing method in use
Initial last column to
leave basis
Save initial number of
transformation
Inversion control switch
Last column to leave
basis current
Previous last column
Not used
Counter for number of
interactions
Counts transformation for
a phase
Solution basis as stored
Row pointer for processing
Number of entries in ex-
Value
Computed
Computed
Computed
0, 1, 2, 3,
or 4
0 or 1
Computed
Computed
Computed
Computed
0 or 1
Computed
Computed
-
Computed
Computed
Computed
Computed
Computed
Data Type*
R
R
R
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
panded matrix
310
-------
Variable*
ARTIF
IFASE
NPSUH
LIMFI
TOLCH
IB AS I
(90)*
COLPN,
(361)*
COLCN,
(360)*
BASMR,
(450)*
NRPVT
ETAND
(8100)*
Contents
Number of artificials
in basis
Phase to start processing
after initial basis
accepted
Expansion counter
Maximum expansion size M*M
Switch to indicate test
for tolerance
Initial basis from program
Column pointer values
Count of non zero's in
a column
Vector marking columns
into basis
Pivot row vector
Row pointers for a given
column in reverse order
Value
Computed
0 or 3
Computed
Computed
0 or 1
Computed
1-450
1-90
1-450
1-90
1-90
Data Type+
I
I
I
I
I
I
I
I
I
I
I
*Values enclosed in parenthesis are dimensions of arrays in current
program version
+1 = integer, R = real
^Values change for different sized program versions
311
-------
"TITLRD" COMMON STORAGE
Variable*
Contents
Value
Data Type"1"
TITLE (19)
User supplied alpha-
numeric job title
74 characters
*Value in parenthesis is array dimension
R = real
"TRANCO" COMMON STORAGE
Variable
ACODE
AOID
AOPR
ADID
AT I ME
ADISI
ASPEED
Contents
Activity code
Activity origin identi-
fication code
Activity origin process
identification code
Activity destination site
identification code
Activity one way travel
time in minutes
Activity one way distance
in miles
Activity transportation
speed in miles per hour
Value Data Type*
1-5 as input I
6-8 as computed
100-499 I
500-699
800-999 I
500-799 I
±0000.0- R
9999.9
000.0- R
999.9
00. 0-60.0 R
* I = integer, R = real
312
-------
"TRKCO" COMMON STORAGE
Variable*
TRSI
Contents
A vector of 3 elements
Value
500-799
Data Type*
I
giving from one to 3
sites with truck con-
straints given in TRNO
TRNO (4) A vector of 4 elements, (Value ex- R
each giving the maximum pressed in
number of trucks per year thousands of
for the period correspond- trucks)
ing to the index
Values enclosed in parenthesis are dimensions of array
+I = integer, R = real
313
-------
APPENDIX IV
SUBROUTINES AND COMMON STORAGE CROSS-REFERENCES
This Appendix contains lists of cross-references for the
eleven WRAP modules. A printer listing is also provided giving
the names of all the routines (in alphabetical sequence within
each module) in WRAP and indicating which routine contains a
common storage reference and/or an input-output file reference.
As a special entry in the listing a column is also used to indi-
cate which routines check the debugging switch IDBU6 for inter-
mediate debugging outputs.
314
-------
MAIN Module Subroutine Cross-Reference List
Routine
DEFLT
ERROR
Calls
FIND
INITDA
LXCOMP
LXSORT
MAIN
READIT
LXCOMP
Called By
CNTCHK, CONTRL, PROCES
CKSIPR, CNTCHK, COLUMN, CONTRL,
CRWFLY, CRWLNK, DUP, DUPWRT,
EDIT!, EDIT2.-ICROW2, LINKS,
LNKBLD, ONENUM, PRCHK, PRCOST,
PROCES, SETC, SETR, SIPRC, SITE,
SOURCE, TBASIS, TRANS, TRNCHK,
TRUCK
BUILD, CAPBAL, CKSIPR, COLUMN,
CRWLNK, CSTRCRD, DSTRTB, ICROW!,
ICROW2, LNKBLD, LNKCHK, ODYN1,
ODYN2, OSTAT, OUTBAS, PRCHK, SIPRC,
TRNCHK
MAIN
LXSORT
CKSIPR, COLUMN, CSTCRD, DSTRTB,
LINKS, MATRIX, OUTBAS, PROCES,
PUNCHT, SIPRC, SITE, SOURCE,
SSTRTB, TRANS
APRPU, BUILD, COLUMN,
CROFLY, DSTRTB, EDIT1,
EDIT2, INITDA, LNKCHK,
MATRIX, OUTBAS, SSTRTB,
SWAP
SEGS
BUILD, CAPBAL, CKSIPR, COLUMN,
COST, CRWLNK, DSTRTB, ED, ICROW1,
ICROW2, ISPOB, IUSIB., IUSPC, IUSTC,
LANCON, LNKBLD, ODYN1, ODYN2,
OSTAT, OUTBAS, PRCHK, PRINT,
PUNCHT, SIPRC, SORBAL, SSTRTB,
TRNCHK '
CKSIPR, COLUMN
315
-------
EDIT! Module Subroutine Cross-Reference List
Subroutine Calls
CONTRL -DEFLT, ERROR
CRWFLY ERROR
EDIfl CONTRL, CRWFLY, ERROR, PROCES,
SIPRC, SITE, SOURCE, TBASIS,
TRANS, TRUCK
LINKS ERROR, LXSORT
PRCOST ERROR
PROCES DEFLT, ERROR, LINKS, LXSORT,
PRCOST
SIPRC ERROR, FIND, LXSORT, READIT
SITE- ERROR, LXSORT
SOURCE ERROR, LXSORT
TBASIS ERROR
TRANS ERROR, LXSORT
TRUCK ERROR
Called By
EDIT1
EDIT!
MAIN
PROCES
PROCES
EDIT!
EDIT1
EDIT!
EDIT1
EDIT1
EDIT!
EDIT!
316
-------
EDIT2 Module Subroutine'Cross-Reference List
Subroutine Calls Called By
CKSIPR ERROR, FIND, LXSORT, EDIT2
READIT, SEGS
CNTCHK DEFLT, ERROR EDIT2
DUP ERROR TRNCHK
EDIT2 CKSIPR, CNTCHK, ERROR, MAIN
ONENUM, PRCHK, TRNCHK
ONENUM ERROR EDIT2
PRCHK ERROR, FIND, READIT EDIT2
TRNCHK DUP, ERROR, FIND, READIT EDIT2
LINKAGE Module Subroutine Cross-Reference List
Subroutine Calls Called By
BUILD FIND, READIT MAIN
LNKCHK FIND MAIN
317
-------
CROWFLY Motkile Subroutine Cross-Reference List
Subroutine
CADIST
CONV
CROFLY
CRWLNK
DUPk'RT
ICROW1
ICROW2
LNKBLD
Calls
CONV
ICROW!, ICROW2
CADIST, FIND, ERROR, READIT
ERROR
CADIST, FIND, LNKBLD, READIT
CRWLNK, DUPWRT, ERROR, FIND,
READIT
CRWLNK, ERROR, FIND, READIT
Called By
ICROW1, CRWLNK
CADIST
MAIN
ICROW2, LNKBLD
ICROW2
CROFLY
CROFLY
ICROW!
FRONTOUT Module Subroutine Cross-Reference List
Subroutine Calls Called By
APRPU PRINT, PUNCHM, PUNCHT MAIN
PRINT READIT APRPU
PUNCHM APRPU
PUNCHT LXSORT, READIT APRPU
318
-------
COLUMN Module Subroutine Cross-Reference List
Subroutine Calls Called By
COLUMN CSTCRD, ERROR, FIND, MAIN
KCOST, LXSORT, PCOST,
READIT, SEGS, SCOST,
TCOST, TRFAC
CPFAC - KCOST
CSTCRD FIND, LXSORT COLUMN
KCOST CPFAC COLUMN
PCOST - COLUMN
SCOST - COLUMN
TCOST - COLUMN
TRFAC - COLUMN
BASIS Module Subroutine Cross-Reference List
Subroutine Calls Called By
DBLFND - DSTRTB, SSTRTB
DSTRTB DBLFND, FIND, LXSORT, MAIN
READIT
SSTRTB DBLFND, LXSORT, READIT MAIN
319
-------
MATRIX Module Subroutine Cross-Reference List
Subroutine
CAPBAL
COST
ED
INITLP
ISPOB
IUSIB
IUSPC
IUSTC
LANCON
MATRIX
SETC
SETR
SORBAL
TBREAD
ZCOLMN
Calls
FIND, READIT,-SETC,
SETR, TBREAD
READIT
READIT, SETC, SETR, TBREAD
INITLP, READIT, SETC,
SETR, TBREAD
INITLP, READIT, SETC,
SETR, TBREAD
READIT, SETC, SETR, TBREAD
INITLP, READIT, SETC,
SETR, TBREAD
READIT, SETC, SETR, TBREAD
CAPBAL, COST, ED, IUSPC,
ISPOB, IUSTC, IUSIB, LANCON,
LXSORT, SORBAL
ERROR
ERROR
INITLP, READIT, SETR, SETC,
TBREAD
Called By
MATRIX
MATRIX
MATRIX
ISPOB, IUSIB, IUSTC,
SORBAL
MATRIX
MATRIX
MATRIX
MATRIX
MATRIX
MAIN
CAPBAL, ED, ISPOB,
IUSIB, IUSPC, IUSTC,
LANCON, SORBAL
CAPBAL, ED, ISPOB,
IUSIB, IUSPC, IUSTC,
LANCON, SORBAL
MATRIX
CAPBAL, ED, ISPOB,
IUSIB, IUSPC, IUSTC,
LANCON
MATRIX
320
-------
LINEAR Module Subroutine Cross-
Subroutine Calls
Reference List
Called By
BTRAN
COME I
DOTPR
ETAGE
ETARB
ETARF
ETARI
FORCE
FSORT
FTRAN
INIT
LP
NEWA
OUT
PASSA
REINV
REMOV
SAVE
SETUA
DOTPR, ETARB
DOTPR, SWITC, PASSA
-
ETARI, FTRAN
-
-
-
DOTPR, SAVE, SETUB, SIMPL
-
ETARF
PASSA, SETUB
BTRAN, COME I, ETAGE, FTRAN,
PASSA, REMOV, TINV
BTRAN, FTRAN, PASSA, REINV
-
-
ETAGE, FTRAN, PASSA
-
DOTPR
FSORT
LP, NEWA, SETUB,
SIMPL, SWITC, TINV
LP
BTRAN, COME I, FORCE, LP
SWITC, TINV, SWAP
LP, REINV, SIMPL
BTRAN
FTRAN
ETAGE
SWAP
SETUA
ETAGE, LP, NEWA, REINV,
SIMPL
SWAP
SWAP
SWAP
SWAP
COMEI, INIT, LP, NEWA,
REINV, SIMPL, TINV
NEWA, SETUB, TINV
LP
FORCE, SETUB, SWAP
SWAP
321
-------
LINEAR Module Subroutine Cross-Reference List (Concluded)
Subroutine Calls Called By
SETUB BTRAN, REINV, SAVE, FORCE, INIT, SWAP
ZCOLIN
SIMPL BTRAN, DOTPR, ETAGE, FORCE, SWAP
FTRAN, PASSA, TINV
SWITC BTRAN, DOTPR COMEI
TINV BTRAN, DOTPR, PASSA, LP, SIMPL
REINV
SWAP DOTPR, FORCE, INIT, LP, MAIN
NEWA, OUT, SAVE, SETUA,
SETUB, SIMPL
ZCOLIN - SETUB
OUTPUT Module Subroutine Cross-Reference List
Subroutine Calls Called By
APRINT - ODYN1, ODYN2,
OSTAT
ODYN1 APRINT, FIND, READIT, QUTBAS
SER2
ODYN2 APRINT, FIND, READIT, OUTBAS
SER2
OSTAT APRINT, FIND, READIT OUTBAS
OUTBAS FIND, LXSORT, ODYN1, MAIN
ODYN2, OSTAT, READIT
SER2 ODYN1, ODYN2
322
-------
. . _ -.
ROUTINES
MAIM
' DEFLT —
"FIND
INITOA
- LXCOMP-
LXSORT
"MATN
"EADIT
SEGS
E D I T 1
COf'jT^L
CRWFLY
EDITI
LINKS
PRCOST
PRGCES
SIPRC -
SITE
111 SO'JRCt
TBAS1S
TRANS '
TRUCK
E D I T 2
CKSIPR
' 'CNTCHiC""
OUP
' FDIT2
ONENUM
PRCHK "'•
TRNCHK
-L--T--W -K~A
BUILD
LNKCHK •
C R 0 tf F
CAHIST
CO\'V
~ CP.nFL'Y —
ClULN'K
OUPWRT
ICRUW1
ICRO-.V2-
LNKBLD
"F" 3' n- \'— j
APRPU
"PRIMT
PUNCHM
PUNCHT
I
n
'3
j
'
<
x
x
X
X
(
X
X
X
n
<
<
X
x
X
<
<
X
X
x
X
<
<
c
;3
JL
"A
I ''4
...
-*
~~~
'^
—
—
—
7
L
n-
K
i.
X
X
X
X
X
X
X
X
X
x
X
X
X
X
£;
y
X
Y
X
Y
X
X
\
r
V
X
X
3'
f 1
•^»'
'ci
|3
i
X
~
x
x
'X
K
V
x
x
x.
X
x
x
<
x
•<
^
x
<
>;
X
X
X
X
x
x
r
<\
XI
X
x
X
X
x
*i
x
\
x
x
x
V
X
x
x
X
X
X
x
X
,\
X
y;
»;
X
X
u
;J
N
x
X
X
X
X
y
-
C
M 0
A C
T 0
M
"~
...
...
.
-~
;oy
5 P
) k
j |T
r IK
x
I
<
c
"X
< [X
C iX
( p<
c ix
'. X
C">C
c
C X
< X
< X
(
X
X
( X
X
( X.
c :<
( X
X
d x
c x
X
Ix
MO
P
Ic
c
L
X
X
X
X
X
X
X
X
X
X
X
X
X
(X
r
N
_
E
A
n
X
-
X
-
STOIU
R S
H B
A A
C S
::.
—
'Gl
S
T
E
c
X
-•
— •-
— ..
-—
: i
i
X;
o'
'
J
X
X
X
*
J
X!
X
<-
TOT
Si
li
Ti
E
C'
0.
j
i
X
x:
X
X
X
X
X
X
IX
X
X
X
X
4
ra
s
R
C
c
c
X
X
X,
x
x
X
X
X
X
X
X
i*
1
$
~S IT
d I
A:(T
PJ L
3 R
0 D
X
X
x
— x
T T
R R
A k
1 N C
i c n
0
X X
X X
X X
X
X
X
X X
X X
X X
X X
1
3
X
X
X
' ' K
X
I
I
1 1
I
I
I
T
I
I
I
I
-----
...
—
6
X
".
—
h
-1 0
ji u
r T
< X
<
<
<
<
(
c
(
c
-----
'T
J
E
r
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
x
X
X
X
X
X
LF
P
F
1
L-
P
i
X
-
X
X
~3E1
F F
I I
L L
E '.
1
X
X
X
...
'5
JF
I I
Ei E
3j A
X ' X
X X
(
X
,1
L1 X
1C1 -E
5J 6
X X
X X
X
F
I
7
X"
X
X
— ...
*
. —
K
- —
323
-------
r
"•"" fj
ROUTINES
C 0 L U M
-COLUMN! '
CPFAC
'CSTCRD"
KCOST
PCOST "
SCDST
TCuST
TRFAC
M ' A T R - 1
CAP9AL
COST
ED
-— INITLP —
ISP03
IUSIB
IUSPC
— IUSTC — -
LAVCON
""MATRIX" —
SETC
SETR -
SORBAL
TBREAD
ZCOLMN
w
|X
B A 5- I 'S
DfaLFND
DSTRTB--
SSTRTB
.. . .j
X
*
'
N
x-
—
:
A
M
K
X
X
X
X
X
X
X
X
E
R|
K
r
U
•Q
D
"X
-s
X
*,
•
-
.
.
F
R
U
M
T
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
L
M
K
•<
A
T
-
X
X
X
X
X
X
X
X
X
X
X
X
X
X
0
f
0
0
M
— •
U
p
0
U
7
X
-
X
X
0
-
-
_
Mr
V
\
T
R
X
X
X
K
JlOf
p
3
'-»
l_*
/-
v»
0
'X
X
X
X
X
X
X
X
X
X
X
X
X
X
\~
A
E
1)
X
X
X
X
s
-
-
T
R
*\
>;
I
0
-
.-
R
s
3
A
C
I
X
"A
Gl
S
I
X
X
X
X
X
X
<
<
:
5
I
*
")
X
X
X
X
X
X
X
X
JJ
X
TO£
S
I
T
0
X
X
X
X
X
X
X
X
X
X
X
X
TK
S
R
0
X
X
X
X
X
X
X
s
S T
W I
A T
P L
C"K"
0 0
T
R
A
N
0
X
X
X
X
X
X
X
1
R
K
Lr
X
-1 FILE SET.S - —
I
I
I 6 M 0
I U U
1
I
I
I
I -
J
E
-
X
-
X
X
PFFFFFFFF
LEEEt-btht
E12345679
X
324
-------
r
D
' " B
U
G
ROUTINES
LINEAR
3TKAW" ---
COME!
DOT PR
ETAGE
-£TARB
ETARF
"t (AkI
FORCE
FSORT
FTRAM
I NIT
LP
NEW A
OUT
PASSA
REINV
REMOV
SAVE
ScTUA
SETUB
SIMPt.
SWAP
SWITC
TINV
ZCOUIN'
^OUTPUT
APR I NT" -
ODYN1
ODYN2' —
OSTAT
UU 1 bAb X
SER2
r?
L
A
*\
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X.
X
X
X
X
X
X
X
X
X
'E
R
R
C
U
D
..._.
F
,3
L
\
1
--
-
X
A
L M
\' A
K T
_...
3
l-
--
-
X
X
X
X
X
-
-
>
0
J
r
-
-
K.
*.
X
*
*
i
P
• ^
r
r\
j
I
i ;
1
^
d
f
U
C
i
X
X
X
t UK Abe AKt AS "• "I "•
I
*
A
C
•- -
r-
i
c
I
x
X
JS
t
R
r"
C
X
A
X
A
I
P
R
^
-
X
S S
I R
5
T C A
E C
~C~U~
0
—
___.
V
£
0
A
X
X
X
X
X
A
X
X
X
A
X
A
X
X
X
X
X
X
X
X
X
X
T T T I
I R R I 6 M C
T A K I - U U
L N C I T 1
-rr-t-o- 1
DO I
r
i
—
X
K
X
TS"
FFFFFFFF
I I I -I I I I I
LLLLLLLL
-E~E-E-E-E--£-E-E-
12345679
»U.S. GOVERNMENT PRINTING OFFICE: 1977 720-116/5709 1-
325
ya!386
------- |