Title: Automatic computer generation of solution precedures to large sets of nonlinear simultaneous equations via GENDER
Full Citation
Permanent Link: http://ufdc.ufl.edu/UF00098195/00001
 Material Information
Title: Automatic computer generation of solution precedures to large sets of nonlinear simultaneous equations via GENDER
Physical Description: xii, 511 leaves. : illus. ; 28 cm.
Language: English
Creator: Cunningham, James Richard, 1942-
Publication Date: 1972
Copyright Date: 1972
Subject: Equations, Simultaneous   ( lcsh )
Chemical Engineering thesis Ph. D
Dissertations, Academic -- Chemical Engineering -- UF
Genre: bibliography   ( marcgt )
non-fiction   ( marcgt )
Thesis: Thesis -- University of Florida.
Bibliography: Bibliography: leaf 510.
General Note: Typescript.
General Note: Vita.
 Record Information
Bibliographic ID: UF00098195
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: alephbibnum - 000577177
oclc - 13924236
notis - ADA4871


This item has the following downloads:

PDF ( 11 MBs ) ( PDF )

Full Text










The author wishes to express his indebtedness to the chairman of

his supervisory committee, Dr. A. W. Westerberg, Associate Professor

of Chemical Engineering, for suggesting the research topic and for pro-

viding the necessary guidance. The author also wishes to thank the

members of the supervisory committee: Dr. F. P. May, Professor of

Chemical Engineering, Dr. R. G. Selfridge, Professor of Mathematics and

Director of the Computing Center, and Dr. F. D. Vickers, Associate

Professor of Computer and Information Sciences.

Thanks also are extended to the National Science Foundation, which

provided financial support through grant GK-18633. In addition to

providing the funds for my research assistantship, this grant defrayed

the extensive computer expenses incurred during the debugging of the

135 subprograms constituting the GENDER System.

Without this assistance and support, the development of GENDER would

not have been possible.



ACKNOWLEDGEMENTS........................................................ iii

LIST OF TABLES................................................... vii

LIST OF FIGURES.................................................. ix

ABSTRACT.......................................................... xi


I. INTRODUCTION.......................................... 1

SYSTEM................... ............................. 5

III. DATA MANIPULATION AND STORAGE......................... 11

III.1. Data Handling................................. 11

III.l.a. Lists............................. 11

III.l.b. Files............................... 14

III.l.c. Memory Allocation................... 14

111.2. Special Data Structures....................... 16

III.2.a Networks ........................... 18

III.2.b Sparse Incidence Matrices........... 18

111.3. Implementation Details........................ 22

*III.3.a. COAST............................... 22

*III.3.b. REMOTE.............................. 33

*III.3.c. NETPAC......... ................. .... 43

*III.3.d. SIMPAC ........... .............. ... 57

IV. DATA BASE....... ...................................... 66

IV.1. Service Module, SECEDE ........................ 66

IV.2. Solution Procedure, GENDER List............... 68


IV.iS. Input/Output Facilities....................... 68

IV.4. Implementation Details........................ 70

*IV.4.a. SECEDE.............................. 70

*IV.4.b. SECIAO.............................. 85

*IV.4.c. GENDER List ......................... 89

*IV.4.d. GENIAO.............................. 98

V. ANALYSIS ALGORITHMS ................................... 101

V.1. Hungarian Output Assignment Algorithm.......... 102

V.2. Speed-Up Precedence Ordering Algorithm........ 103

V.3. Barkley Motard Minimum Tear Algorithm....... 104

V.4. Implementation Details........................ 105

*V.4.a. HASSAL.............................. 106

*V.4.b. SPEDUP .............................. 107

*V.4.c. BEMOAN.............................. 112

VI. INTERPRETATION ........................................ 114

VI.1. Link Editor ................................... 115

VI.2. Converter...................................... 116

VI.2.a. SOLVE............................... 119

VI.3. Interpreter ................................... 120

VI.3.a. MATH ................................ 122

VI.3.b. Subroutines......................... 122

VI.4. Implementation Details......................... 125

*VI.4.a. LINKED .............................. 125

*VI.4.b. COVERT .............................. 126

*VI.4.c. GLINT ............................... 128



VII. USER MANUAL....................................... 130

VII.1. Input Data Preparation ................... 130

VII.2. Program Preparation ......................... 131

VII.3. Additional Algorithms....................... 134

VII.4. GENDER as a Design Tool..................... 134

VIII. EXAMPLES ............................................ 137

VIII.1. A Simple Analysis Strategy.................. 147

VIII.2. Equilibrium Flash.......................... 147

VIII.3. Binary Distillation ......................... 155

IX. CONCLUSION ........................................ 165

IX.1. Convenience Aspects......................... 165

IX.2. Additional Algorithms....................... 166

IX.3. A Final Note on GENDER ...................... 168

APPENDICES...................................................... 169

Appendix A............................................. 170

Appendix B............................................. 498

Appendix C............................................... 501

Appendix D.............................................. 504

BIBLIOGRAPHY..................................................... 510

BIOGRAPHICAL SKETCH............................................. 511


Table Page

1 COAST Verbs............:................................ 28

2 LEND Components Required by REMOTE ..................... 42

3 Auxiliary Data Fields Required by NETPAC............... 44

4 NETPAC Verbs........................................... 55

5 Data Fields Required for Ordinate Entries.............. 59

6 Data Fields Required for SIM Elements.................. 61

7 Information Block Components Pertinent to the SIM....... 62

8 SIMPAC Verbs.................. ......................... 64

9 Data Fields for SECEDE.................................. 75

10 File Entries for SECEDE ................................ 77

11 SECEDE Files.......................................... 79

12 Information Block Components Pertinent to SECEDE........ 86

13 Data Fields for GENDER................................. 90

14 The List Entries of GENDER ............................. 93

15 Information Block Components.Pertinent to GENDER List.: 99

16 Data Fields for SPEDUP Working Lists................... 109

17 List Entries on SPEDUP Working Lists ................... 110

18 Data Fields for the BEMOAN Working Ordinate............ 113

19 Operator Set ........................................... 121

20 GLINT Error Codes..................................... 123

21 Information Block ...................................... 132

22 The Code Name/Variable Assignmentsfor a
Distillation Tray...................................... 140

23 The Constant/Code Name Assignments for a
Distillation Tray........................................ 141

LIST OF TABLES (Continued)

Table Page

24 Values for Information Block Components................ 149



Figures Page

1 GENDER Architecture................................. 9

2 Typical List Structures ........................... 12

3 Typical Hierarchical File.......................... 15

4 A Simple Network.................................. 19

5 Sparse Incidence Matrix.......................... 20

6 A User Mask ...................... .............. 24

7 PUSH................... .......................... 30

8 POPUP............................................. 32

9 File Structure.................................... 34

10 A Record.......................................... 38

11 Trace (Start).................................... 47

lla Trace. (Step 1)..................................... 48

llb Trace (Step 2)..................................... 49

lc Trace (Step 3)................................... 50

lid Trace (Step 4)...................................... 51

lle Trace (Completed)................................... 52

12 Sparse Matrix..................................... 58

13 An Equilibrium Stage............................... 138

14 SECIAO Data for a Distillation Tray................. 142

15 Data for COIN..................................... 148

16 Equilibrium Flash................................... 150

17 SECIAO Data for Equilibrium Flash.................. 153


Figures Page

18 Data for VARIAO................................... 154

19 Simple Distillation Column ........................ 156

20 SECIAO Data for Simple Distillation Column......... 158

Abstract of Dissertation Presented to the
Graduate Council of the University of Florida in Partial
Fulfillment of the Requirements for the Degree of Doctor of Philosophy



James Richard Cunningham

December, 1972

Chairman: Arthur W. Westerberg
Major Department: Chemical Engineering

Fundamentally, chemical process plant design is the solution of a

large set of nonlinear simultaneous equations. For large and complex

equation sets, it is frequently not possible for the design engineer to

determine readily how the solution should proceed. Algorithms have been

developed which analyze equation sets with respect to solution procedure.

The algorithms do not generally attempt to solve the equation set, but

merely provide the directions for solving to the design engineer. While

computer implementation of certain algorithms analyzing equation sets

has been accomplished, little emphasis seems to have been placed on the

implementation of a complete analysis system integrating a number of

algorithms. This dissertation presents an automatic and machine-indepen-

dent system permitting the design engineer to direct solution procedure

generation and execution via selections from a spectrum of analysis


GENDER is the acronym for General Engineering Design Routines. The

primary objective of GENDER is the development of a complete solution

procedure. To be complete, a solution procedure must reflect (1) decision

variable selection, (2) output set assignment, (3) tear variable selection

and (4) precedence ordering. These attributes are provided to a solution

procedure by GENDER through a minimum tear analysis strategy. While only

the minimum tear strategy has been furnished with the first version of

GENDER, the GENDER System has been designed to readily accept additional

analysis algorithms, expanding the analysis strategy repertoire.

The design engineer, having generated a solution procedure for an

equation set, may perform the translation of the solution procedure into

FORTRAN for execution. However, an interpreter capable of direct

execution of a solution procedure is provided in GENDER. The interpreta-

tion capability, while sparing the engineer from the drudgery of trans-

lation, has a somewhat more noble purpose. If the design problem involves

constrained optimization, the solution procedure will be subjected to a

series of revisions as additions or deletions to the set of binding con-

straints are required. The optimization-solution procedure generation-

execution cycle is potentially faster for interpretation than for FORTRAN

execution owing to the elimination of the translation and compilation steps.

GENDER depends extensively upon list processing techniques. In fact,

the solution procedure has been implemented as a list. In the list format,

the revisions and rearrangements associated with an analysis strategy may

be conveniently performed on a solution procedure. The application of

list processing techniques is not restricted to the solution procedure

alone, but permeates the GENDER System. Linked data structures of note

include a paged storage system (REMOTE) and the sparse incidence matrix.

The former is notable for compatability with mass memory and the latter

for memory conservation (on machines lacking virtual memory).



The objective of process design is the determination of equipment

specifications and operating conditions which will meet certain produc-

tion goals developed by management. Process design problems are not

particularly amenable to solution. The equations quantitatively

describing the equipment characteristics may be highly nonlinear, a

situation further confounded by the presence of recycle streams. The

recycle stream is necessary to economic operation, but it imparts a

cyclic character to the design calculations just as it imparts a cyclic

character to the process flow. To these complexities of process design,

yet another must be added. Processing plants are frequently complex

entities, consisting of many individual processing units connected by a

make of piping. This is particularly true if the process engineer

intends to extend the scope of the plant model to include not just the

major features of the process, but all unit operations. That is, the

mathematical model is to resemble the processing plant as closely as


The availability of large, powerful computers has caused process

engineers to revise the design procedure. Prior to his introduction to

computers, the engineer was forced to simplify the process model to

facilitate the completion of hand calculations in a reasonable amount of

time. While short-cut techniques were developed for some unit operations,

the "assumption" reigned as the arme supreme. Unlike the human brain,

the digital computer is well suited to complex and repetitious calcula-

tions. The engineer could now expect solutions for large and complex

process models without the uncertainties of simplification.

The new exactness permitted to the process engineer by the digital

computer proved to be something less than a complete blessing. The

programs developed by the engineer from the mathematical models all too

frequently either failed to converge, giving no answer, or generated

unreasonable answers. Research, both industrial and academic, determined

that the computational difficulties were characteristic of particular

formulations of a model. Further, certain formulations of a model may

require more information to initiate cyclic calculations than other

formulations. What had developed at this point was a new field of

endeavor for process engineers: the study of process models. This study

begins where the traditional concept of mathematical modeling ends.

The result of mathematical modeling is the development of an equa-

tion set descriptive of, for instance, a unit operation. This set of

equations is not unique. That is, the algebraic rearrangement of one

model produces another equivalent model. It is this rearrangement and

its effects which have captured the attention of the process engineer.

The result has been a variety of algorithms for selecting a particular

model formulation.

The algorithms are rather specific in character, dealing with only

a particular aspect of a process model. Algorithms have been developed

for selecting the output variables for a set of equations, for selecting

the variables for which value estimates are required to initiate cyclic

calculations and for ordering the equations so that the calculation of

each variable value will depend only upon variable values already

calculated. These operations are respectively known as output set


assignment, tear variable selection and precedence ordering. The process

engineer employs selected algorithms sequentially to convert the original

model he formulated into an equation set amenable to computer solution.

The particular selection of algorithms may be referred to as an analysis

strategy. The strategy is largely dictated by the objectives of the

design engineer, such as a minimum tear solution or a rapidly converging

solution. Unfortunately, the execution of an analysis strategy must be

primarily manual. Only a few algorithms have been programmed, all of

which are machine dependent and isolated from other analysis capabilities.

The next step in this evolutionary development of process design

would seem to be totally automatic process model analysis. The notion

of automatic design is not original to this work (Kevorkian and Snoek,

1972; Soylemez, 1971; Mahand Rafal, 1971), but has been attempted

previously. It is the limitations of other automatic design systems

which have encouraged the present effort, the General Engineering Design

Routines (GENDER) System. GENDER does not restrict the design engineer

to a single analysis strategy by virtue of a library of analysis algori-

thms. Further, the inclusion of additional algorithms has been made

relatively easy. While it is possible to convert the product of an

analysis strategy, which we shall call a solution procedure, into FORTRAN

code for execution, the GENDER System provides the capability of directly

interpreting the solution procedure to produce a solution to the design

problem. As a feature designed to permit compact problem representation,

GENDER can accept indexed variables and equations. Finally, the GENDER

System affords the design engineer with a problem solving medium permit-

ting the convenient modification of the original design problem during

the execution of the analysis strategy and/or interpretation of the

solution procedure. This feature is essential to constrained


optimization where fluidity in the inclusion and exclusion of constraints

is an absolute necessity. While many of these features have appeared

in previous attempts at automatic design packages, they have to date

not all appeared in a single automatic design system.



The heart of the GENDER System is the solution procedure and is essen-

tially the set of instructions for solving a set of simultaneous equations.

In order to make possible direct machine interpretation of the solution,

the solution procedure must be explicit and complete. The purpose of

this chapter is to introduce the concept of the solution procedure, its

terminology and its relation to the GENDER System.

In Chapter I and in the proceeding paragraph the term equation was

used for a model constituent. To be more precise, the model constituents

are actually equations and solved equations. That is, the model is

composed of algebraic relations between variables and constants, but

having the form

f(x,y,z,...) = 0

rather than the solved equation form

x = F(y,z,...)

In the solved equation form, the x is called the output variable. An

equation may be transformed into a solved equation by selecting a variable

to be the output and performing the algebraic rearrangement necessary

to place this variable alone on the left-hand side of the equality.

Certain of the equations defining a processing plant may be

constraints. Normally one thinks of constraints as inequalities.

However, inequalities are readily converted to qualities via the intro-


duction of slack variables. GENDER, at least in its current version,

is prepared to manipulate equality constraints only. Being identical

to the equations describing the process, the constraints could be

grouped with them without differentiation. However, during constrained

optimization the set of active constraints varies in numbers and

composition. To permit the free inclusion (exclusion) of constraints

into (from) a problem, constraints are regarded as distinct model

constituents and are carefully differentiated from all other model


Normally an equation is permitted but a single output variable,

with one exception. The external routine (ER) is a special model

constituent which may possesses more than one output variable. In

essence, the ER is a subprogram for determining values to output variables

given the values of the input variables. An ER may be encoded in any

acceptable programming language.

To facilitate .the incorporation of existing subprograms in a

plant model, a mechanism for indicating prechosen output variables is

essential. The mechanism selected for GENDER is a weighting scheme with

an integer scale of 0 to 9. Each variable in each equation and ER is

assigned a weight in the 0 to 9 range. This weight is the cost of

assignment as an output variable. Thus, for an existing subprogram,

the output variables are all weighted at 0 while the input variables

are all weighted at 9. This weighting scheme allows the design engineer

to indicate to GENDER his preferences with respect to output set assign-

ment. For instance, similarity of a new model with one or more previous

models may suggest at least a partial output assignment. The weighting

mechanism allows the engineer to guide GENDER in performing the initial

output assignment and may reduce execution t.ne depending on the ultimate

degree of similarity between the solution procedures for the models.

In addition to output set selection, analysis of the equation set

must also order the equations and, if possible, subdivide the functions

into smaller groups. Initially, the plant model is treated as a single

large group of equations. The decomposition of the large problem into

a multitude of smaller problems is obviously advantageous. Equations

which are acyclic in character may be grouped, although the equation

grouping normally reflects the presence of a cyclic character. It is

permitted by GENDER to have groups as members of groups. Thus, we

may have, for example, a cyclic group appearing as a constituent of

another cyclic group, or even as a constituent of an acyclic group.

Once tear variable selection has rendered all cyclic groups apparently

acyclic (by ignoring all occurrences of the tear variables except in the

equations where they are the output), it is possible to order all

members of groups and to order all of the groups so that the information

flow is strictly forward. That is to say, the value of a variable is

never required as the input to a equation before it has been calculated

as the output of a previous equation. This then is the concept of

precedence ordering.

The solution procedure must reflect the output set assignment,

grouping, tear variable selection and precedence ordering. The solution

procedure must also indicate decision variable selection, the decision

variables being the unassigned variables following output set selection.

Numerous strategies exist for acquiring these ingredients to the solution

procedure, but for completeness all must explicitly appear.

The solution procedure is called the GENDER list. The GENDER list

consists of group, each group possessing a body of equations, ER's or

groups. Each equation and ER appears once somewhere on the GENDER list.

Its position on the GENDER list is dictated by precedence ordering.

Space is reserved with each equation and ER to indicate the selected

output variables. Similarly space is reserved for the recording of

the decision and tear variables associated with each group. The

completed solution procedure will.generally be evolved from a skeletal,

random listing of the equations in a single group called the crude GENDER


The completed solution procedure contains all of the instructions

for solving the equation set, but is as yet not amenable to interpretation.

The conversion operation transforms equations into solved equations via

algebraic arrangement. In lieu of destroying the original equation set,

the converter operates on a copy of the equations. This feature of

GENDER preserves the original model should reanalysis of all or a

portion of the solution procedure be required. This eventuality might,

for' instance, be realized if convergence difficulties of a cyclic group

are encountered. Once subjected to conversion, the solution procedure

is transformed into an ordered and grouped list of solved equations

ready for numerical evaluation.

The GENDER System is divided into five major program levels as

shown in Figure 1. The program packages COAST (level 1), REMOTE (level

2), SIMPAC and NETPAC (level 3) are discussed in Chapter III. These

packages provide the capacity to manipulate certain data structures

essential to GENDER. Chapter IV introduces the data base SECEDE and

provides greater detail on the GENDER list. The algorithms available

for problem analysis are discussed in Chapter V. Level 4 of GENDER

is devoted entirely to the analysis algorithms. The highest current

GENDER level is level 5. On this level is found the input/output

__ _

-- I-I .


-I I












... .

facilities and the programs relative to interpretation of the GENDER

list. The description of the input/output facilities has been incorpor-

ated into Chapter IV. The notion of GENDER list interpretation is treated

in Chapter VI. Chapter VII is'a brief user's guide to the GENDER System.

In this chapter the expansion of the repertoire of analysis algorithms

is discussed, as well as the employment of GENDER as a design tool.

Illustrative problems are presented in Chapter VIII. This work is

concluded in Chapter IX with some remarks on the limitations and

possible future of GENDER.

Particularly in the next four chapters, some sections are extremely

detailed. In addition to being difficult to read, they are likely only

of benefit to readers contemplating algorithmic additions or modifications

to the GENDER System. For this reason, these sections are identified

by an in the section number and may be omitted by readers not requiring

the' implementation details of GENDER.



III.1. Data Handling

The algorithms for solution procedure development suggest certain

data structures. Effective implementation of the algorithms requires

the availability of these data structures. Unfortunately, the data

structures require vast quantities of on-line memory. A large scale

problem would, by virtue of the data structures developed during problem

analysis, very quickly reach the bounds of on-line memory. Fortunately,

not all of the data structures need exist at one time, making feasible

the sharing of memory. A priori, the. memory required by each phase of

problem solving is unknown. Thus, the simple partitioning of memory is

an infeasible sharing policy.

Two basic and complementary data storage mediums have been provided:

lists and files. The list permits complex data structures which may be

readily rearranged, expanded or contracted. The penalty for this flexi-

bility is high access times. Reaching a particular location may be

accomplished only by stepping through all preceding list locations.

Conversely, the file allows rapid random access of any location. Files

are, however, restricted to a strictly sequential structure. Memory

sharing is accomplished by a dynamic memory allocation procedure. For

readers not familiar with list processing, Knuth (1968) provides a

complete discussion of list processing principles and structures, including

memory allocation.

III.l.a. Lists
Figure 2 is an illustration of three possible list structures. As







indicated pictorially in Figure 2, the structure of a list is relatively

arbitrary. The arrows in Figure 2 represent the connection between list

entries and are called links. Thus one data item (at least) in a list

entry is a pointer to an adjacent entry on the list. This flexibility

has not been restricted to structure alone. Each entry on a list

possesses the attributes of size, quantity of data and organization of the

data within the list entry. All of these attributes are also arbitrary.

The structure of a list, while arbitrary, is specified by the

programs which generate and manipulate the list. That is, the degrees

of freedom permitted in the selection of a list structure are consumed

by the programmer of a list processing application. Since one of the

objectives was machine independence, and since word size and memory size

vary from machine to machine, it seemed necessary to segregate the

organization of data within list entries from the tailoring of list

structures to meet strictly programming requirements. This has been

accomplished by designing the list processor to accept the data organiza-

tion parameters as data prepared and supplied by the user. These parameters

are further discussed in Chapter VII.

The utility of a list processor lies mainly in the usefulness of

its operations. We shall call the subprograms providing these operations

"verbs." Verbs have been provided for obtaining and releasing list

entries and for making and breaking the links between list entries.

These verbs form the nucleus of the structure manipulation power of the

list processor. Another set of verbs provides the capability for trans-

ferring information to or from a list entry. Of great utility is the

ability to search a list for the occurrence of a particular set of data

values. A verb providing this service is also included in the list


III.l.b. Files

Figure 3 is an illustration of a typical hierarchical file. The

arbitrariness of structure present in lists has, for files, been reduced

to the specification of the number of levels in the hierarchy. Rapid

access to randomly selected entries at any level is the incentive for the

sacrifice of arbitrariness in structure. Owing to the sequential storage

of file entries in on-line memory, large contiguous blocks of memory

allocation may be required. It is, therefore, vital that the file system

utilize core effectively. However, the sequential nature of the file

entries makes possible the transfer of file data to mass memory devices.

This enables the release of on-line memory normally occupied by files

during problem solution phases not relying on the file data. Further,

even when file data is required, it is possible to retrieve only portions

of a file.

SA file entry is essentially the same as a list entry, except that

the explicit specification of links, as in the list entry, is absent.

The organization of data within a file entry is accomplished identically

as for a list entry. Thus, the file entry shares the same arbitrariness

of data organization provided for the list entry.

Many fewer verbs need be provided for file manipulations than for

lists since link manipulations are not required. In fact, three verbs

are sufficient. One verb is required to provide a file entry and

transfer data into it. A second verb provides the capability for retriev-

al of data from a file entry. Finally, the third verb permits the

searching of a file for a particular set of data values.

III.l.c. Memory Allocation

The particular memory allocation strategy adopted for GENDER

continues the theme of flexibility and arbitrariness. Each phase of


problem solving is allocated memory only as it is required. An accounting

mechanism keeps track of the memory assigned to each phase. This mechan-

ism permits the release of memory assigned to a particular phase once its

task is complete. The released memory may then be reallocated to another

phase of problem solving. The allocation, release and re-allocation

capabilities give memory the fluid character essential to providing a

time varying memory distribution in response to the time varying demands

of the solution phases.

The dynamic allocation of memory provides an opportunity for

fracturing memory into small isolated segments. This eventually would

prevent the servicing of a request for a large continuous allocation

of memory. Though procedures such as garbage collection have been

proposed for reclaiming the isolated memory, these procedures have not

been used for GENDER. The need for large blocks of memory has been

avoided by designing the file system so as to utilize only reasonably

sized continuous blocks of memory.

III.2. Special Data Structures

Networks Since the algorithms for solution procedure development

in many instances specify rearrangements of the solution procedure, a list

structure was adopted. Hence, the solution procedure became known as the

GENDER list. During the course of evaluation of the entries on the GENDER

list via the interpreter, an anomaly may be encountered necessitating

reanalysis of a portion of the GENDER list. In fact, all of the GENDER

list from the anomaly to the list end is subject to reanalysis. Consider

the following set of equations.

Y_(,u) = o
(z,v) = 0
If reanalysis of Y is required, Z would be subject to reanalysis,

although reanalysis of Z would result in no change. Instead of the list

structure, suppose a structure is substituted in which each entry precedes

only those entries that it influences. Then, Y and Z would appear on

parallel paths since they are independent. This structure is a network,

and was adopted for the solution procedure (which is still called the

GENDER list).

Sparse Incidence Matrices (SIMs) Incidence matrices provide a

convenient and lucid medium to express the problem to which an algorithm

is to be applied. In fact, many algorithms for solution procedure gener-

ation are most easily explained in terms of their effect on incidence

matrices. This is to suggest that incidence matrices may be a natural

and effective tool in the implementation of these algorithms. Unfortun-

ately, matrices are relatively expensive in terms of memory requirements.

This is particularly damaging in light of the intention to construct

GENDER so as to be applicable to large scale problems. In chemical

engineering, and perhaps in other disciplines as well, most equations

contain only a small number of variables compared to the total number

of variables in the problem. The average incidence for several chemical

engineering applications examined was approximately three to four variables

per equation. The majority of the incidence matrix elements are null. By

considering the matrix elements to be list entries, and by disregarding

all null elements, the use of incidence matrices is made.possible without

the disadvantage of excessive memory requirements. The elements form the

orthogonal list structure shown previously in Figure 2. For example,

if an equation contained only two variables, then the row would be composed

of only two list entries. The columns represent variables so that each

,of the two row list entries are also members of the orthogonal column

lists as well.


III.2.a. Networks

A network is an extension of the forward-backward list structure

to permit each list entry more than a single forward and a single back-

ward link. The capacity for parallelism is furnished by auxiliary lists

called divergers. All list entries other than diverger entries are

referred to as network nodes. Figure 4 depicts a node followed by three

parallel nodes.

Networks have virtually all of the attributes associated with a

forward-backward list structure. The arbitrariness of data organization

within the nodes is somewhat restricted by the requirement that certain

data entries be present as an integral part of the structure. Highly

parallel structures may suffer with respect to access times as a result

of large divergers.

The network verbs implemented are essentially concerned with the

peculiarities of network linkages. The list processing verbs for data

transfer serve equally well for nodes as for list entries. Subprograms

are provided for the connection and for the separation of nodes. A

complementary pair of function subprograms permits the extraction of

linkage data, one for the forward link and one for the backward link.

The policy of providing the capability for searching list structures is

continued here for networks. Finally, a rather special verb is provided

enabling an orderly, predictable tracing from node to node through a

network. This verb, a function called NEXT, has proven to be of consider-

able utility.

III.2.b. Sparse Incidence Matrices

Sparse incidence matrices are actually a hybrid of the orthogonal

list and of the file data structures. Figure 5 illustrates a sparse

node node node

Figure 4. A Simple Network.




incidence matrix consisting of two equations and three variables. The

files required for the sparse incidence matrix are termed ordinates. Each

file entry contains a pointer to a row or column of the matrix. For simplic-

ity, when reference is made in general to a row or column the term vector

will be employed.

Even with the inclusion of the two ordinates, the memory conservation

remains substantial. Consider a system of 1,000 equation in which 1,000

variables are incident. The resulting incidence matrix must contain no

fewer than 1,000,000 words of memory if stored as a standard two dimen-

sion array. Allowing three words per non-null element (for the horizontal

link, vertical link and data item), the elements of a typical sparse

incidence matrix would consume only about 9,000 words. The ordinates

and supporting data structures would require at most approximately 30,000

words. Thus, the memory savings afforded by the sparse incidence matrix

exceeds 960,000 words over the simple two dimensional array. If the

ability to pack information into list and file entries is utilized to

its fullest extent, the size of the sparse incidence matrix may be reduced

by as much as 50% depending upon the word length. The penalty for

memory conservation is increased access time. A matrix vector may be

accessed randomly and relatively quickly by virtue of the ordinates.

Reaching a particular element list entry, however, can be accomplished

only by tracing the selected vector from element to element until the

desired element is accessed.

The nature of the subprograms provided for the manipulation of

sparse incidence matrices are rather specific in character. Each sub-

routine is designed to fulfill the requirement by one or more of the

algorithms for a certain sparse incidence matrix operation.

111.3. Implementation Details

The implementation of the data handling facilities discussed in

Sections III.1 and III.2 has been partitioned into four program packages.

COAST is the name given to the program set providing the core allocation

and list processing capabilities. The subroutines furnishing the file

manipulations constitute the REMOTE system. NETPAC and SIMPAC are

respectively the network and the sparse incidence matrix program sets.

Each of these packages are discussed in detail in the subsections to


The remainder of Chapter III may be omitted by any reader not

requiring a knowledge of the programming details. A knowledge of

these details is not expected to be generally advantageous except to those

readers planning additions to the algorithm library, alterations to an

existing algorithm, or alterations to the GENDER facilities.

* III.3.a. COAST

To achieve machine independence, FORTRAN was selected as the program-

ming medium. To provide the space required for the development of list

structures, a COMMON declaration was employed to reserve a vector named

ALLOC. The length of ALLOC is a user specified parameter. The position

of a word of memory within ALLOC is referred to as the absolute address,

or simply address, of that word. For example, the fifth ALLOC word has

an address of five.

The memory allocation strategy adopted for GENDER is the buddy system.

To reduce the administrative effort required in supervising the allocation

of ALLOC to user programs, ALLOC is partitioned into multi-word segments.

Segment size is also an adjustable parameter. To permit the allocation

of space in sizes other than a single segment, consecutive segments may

be combined to form buddies. In fact, two contiguous blocks of memory

of equal size may be combined to form a buddy. Requests for space are

satisfied by supplying the smallest buddy satisfying the request. Should

only a larger than necessary buddy be available, a request for a lesser

amount of space may be satisfied by first fracturing (splitting into two

parts) the larger buddy. All of the available buddies of each size are

linked together forming an available space list for each buddy size. The

operations necessary for memory management are provided by the subprograms


In order to facilitate the release of ALLOC segments by user

programs, an accounting system is necessary. The accounting device

adopted is a mask. Each bit of the mask represents an ALLOC segment. A

set bit in a user's mask indicates that the corresponding segment is

assigned to that user. Each user program is assigned a user mask on its

initial request for space. Figure 6 is an illustration of a user mask.

A similar mask, established before allocation commences, is provided to

record segments released by user programs. Whenever the buddy available

space lists become sufficiently depleted that a request for core cannot

be honored, then the space represented by the return mask is re-buddied

and returned to the available space lists. This strategy eliminates

execution of the costly re-buddying process unless it is absolutely

necessary. CORN is the program furnished to permit the release of ALLOC

segments by a user. The program LIST accomplishes the update of a user

mask as memory segments are made available to a user program.

A user program requestsspace via a five word vector called a space

utilization record (SPUR). The first word of the vector contains the

address of the user mask. For the initial space request, this word must

contain the integer zero. The second word will contain the pointer to


/ /,/f1$#'


cC 0
*/ U

/ T\ -


\ j1
/ .-'I--\


the space provided during allocation. The third and fourth vector

components are respectively the quantity and the size in words of the

requested list entries. The list entries are manufactured from a

buddy of the appropriate size and provided to the user program as an

available space list. The last component of the SPUR indicates the

list type, a subject to be considered later in this section. Several

programs requiring ALLOC space may share a SPUR vector, thereby sharing

the allocated core.

Information is contained within list entries in data fields. A

data field consists of either all or a portion of a list entry word.

Data fields consisting of only a few bits are usually referred to as

flags. A data field appearing in one or more consecutive list entry

words constitutes a data type. The collection of all data types

associated with the entries of a particular list structure constitutes

a list type. The quantitative specification of a data type requires four

parameters. The first two delimit the bounds of the data type within a

list entry. For example, if these parameters are valued at 1 and at 4,

the data fields of this data type appear in words 1 through 4 of the

list entry inclusively. The second pair of parameters delimits the

bounds of the data field within a list entry word. The third word,

called a shift, is the integer by which a list entry must be divided

to place the first bit of the data field in bit position 1 of the

dividend. For instance, if the data field begins in bit position 3,

dividing by a shift of 4 will translate the field the required two

positions. The last parameter is a field mask comprising set bits

indicating the bit pattern of the data field. The field mask should

be right justified to the first bit position of its single word. The

collection of all sets of these four parameter vectors constitutes

the list entry definition (LEND) specifying the organization of data

fields within the list entries of a list type. Thus, a LEND is required

for each data type. COAST utilizes the subroutine COIN to accept the

LEND's from a user as data. COIN is the only COAST routine requiring


In order to accomplish the transfer of information to or from

the data fields within a list entry, the data fields involved in the

transfer operation must be uniquely identified. It is to be permitted

that a single transfer operation may involve many data fields from

many different data types. Thus, the transfer operation requires two

vectors, one reserved for the values of the data fields and a second to

identify the data fields. The latter vector consists of three words per

data type involved in the transfer, plus an additional word specifying

the number of data types. Each three word set comprises a data type,

the'occurrence of the first field for transfer and the occurrence of the

last field for transfer. For example, a three word set (4, 2, 7)

indicates that the data type is 4, the first field transferred will be

the second and the last field transferred will be the seventh. The

transfer for data type 4 will consume six words of the value vector.

All of the COAST verbs performing data transfer operations employ the

vectors described here, except COPY. COPY performs the direct list entry

to list entry transfer of information, and does not require a vector for

value storage.

The first occurrence in a list entry of data type 1 was selected

for the forward link. Similarly, the first occurrence of data type

2 is reserved for the backward link when backward links are required.

Technically, links are simply data fields and may be manipulated as data

fields using the data transfer subprograms. The convention adopted

regarding data types for links permits the creation of faster, more

convenient verbs specific to link manipulations.

It is the nature of the forward-only list to prohibit the access

to the predecessor of a list entry. The absence of the backward link

makes necessary special handling of operations involving the removal

of entries from a forward-only list. In particular, if the last entry

is to be removed, it is not possible to set the forward link in its

predecessor to zero since the address of the predecessor is unknown.

In this situation, the last list entry becomes a private termination

cell, PTC, (Cooper and Whitfield, 1962/3) and is fitted with a forward

link of 1. Thus, a unity forward link is the identifying characteristic

of a PTC. PTC's remain linked into the list but are not otherwise an

active part of the list. If the list entry is to be removed from a

forward-only list, the entry itself cannot be physically removed as its

precursor in the list (which points to it) is not known. However,

by copying the entire contents of the list entry following the one

to be removed into the list entry to be removed, one has created

the effect of removing the chosen entry. The list entry following is

then deleted from the list and added to the user's available space


Table 1 presents a list of the COAST verbs which are the primary

list processing subroutines. Omitted from Table 1 are those COAST

programs which are not of direct utility to the programmer of a list

processing application. Three verbs included in the table require

further attention.

LOCATE, as its name implies, searches a list for the occurrence

of a specified pattern of data field values. The data specification

vector employed in data transfer operations provides LOCATE with the



H- 4-

C) a) 1

a) P4H
Uo co 4> C
m cu H p

co H H H a 41
E *H c r-- E
r O 4-' C I0

a) c *ri 4 p-
(0 U l 0> U- EU

(3 ( r H r K (
m (n 0 m
0) 3 CU ,) U) l: 'CU p) Cw
CU 0 Q) *H Cr H > CU
3 4-' E W H *H 4-' 0

UO CO C 4-' ) )
Pr4 0 :- .H ) 4 4 H E
a) -i ro (v -P 41
H c ) CU H n 0 O rl- H
U) H CU cUi CU >I C) H
Q < 'w q-4 4, 4-!' 0 Cq
- 4-' 'u) C 0 0CU C + 4-
co0 Mw U H ) i C 'o CU n U)
2 -1 U r-l 'H A cu ) a) c 4-' *H r- C
0 0 A m0
w4 > H >) 'U CU C C CU C 04 C i p H
CU 'H $4 fl tC4H > > cU CU a) ui C CU
E .- 'U a) > C 4 4-
<. H o -' *m- CU1 4 p p
0- < ) CV $4 a) C) z) (U)$4X4-'U) u)C

CD CD w co 0 0 0 0r-l
u L 4 -I P

0 0 Cr

oU ) CU $4 co)

4-) N co *z H 4-
CU *H CU CU C(3 )
Z H C cu '
m C 4 CUu

C *H CU *H
(-) -l i--

identification of the data fields to be inspected. LOCATE permits two

modes of operation which are referred to by the descriptors "AND" and

"OR". In the "AND" mode, LOCATE is directed to accept as a match the

first list entry found to contain the specified data pattern in its

entirety. The "OR" mode relaxes this requirement for matching somewhat.

In the "OR" mode, the data pattern is partitioned according to data

type. The partitions are compared individually to their respective

data fields of a list entry. The search is successful when a list

entry is encountered possessing the fields of a data type which match

the corresponding data value partition. In either mode, the search may

be specified to proceed in the forward direction, in the backward direc-

tion or specified to encompass the entire list (accessible from the

specified starting point).

Like LOCATE, the verbs PUSH and POPUP involve both links and

data, but unlike LOCATE result in alterations to the list structure.

The.PUSH operation is pictorially presented in Figures 7.

Although the illustrations are based on a forward-backward list, PUSH

operates essentially the same on forward-only lists with two exceptions.

Owing to the absence of the backward link, the push-up mode and the

insert-before mode cannot be performed per se. If the position of the

data on the list is the important consideration and not the address of

the particular list entry containing the data, then the insert-after

mode and the push-down mode may be taken as the equivalent of the

push up and insert before modes.respectively. The verb POPUP is

essentially the inverse of the verb PUSH. Figure 8 shows the POPUP

operation in the forward direction. In the case of forward-backward

lists, POPUP is symmetrical and will operate equally well in the backward









I I )

k :

)O 4
*)C o m c


a -?f a


C b"l



direction. Thus, if POPUP from C to B (according to the backward link)

is specified, the entries from B through C in the forward sense will

be transferred to the user available space list. The data source will

be list entry C. In the example of Figure 8, if the operand C were

replaced by Q, POPUP would remove from the list all entries from B to

the end of the list. For a forward only list, B would of course

become a PTC. Again, the symmetry of POPUP allows this mode of operation

for forward-backward linked lists.

As stated at the beginning of this section, machine independence

was a goal of the GENDER system design. Unfortunately, the logical

operations "AND", "OR" and "exclusive OR" are required for the mask

manipulation operations. These logical operations cannot be conveniently

provided directly in FORTRAN, necessitating recourse to assembly language.

These operations are basic machine instructions and required little

effort to prepare for the IBM-360 or 370. This is expected to be true

for all other machines as well.


Avoidance of dependency of the hierarchical file

storage system, REMOTE, on large continuous partitions of the ALLOC

vector was a paramount consideration in the design of REMOTE. The

design is to require file storage in smaller ALLOC partitions, which

are somehow connected together to give the illusion of being contiguous.

As a further constraint, the linkage mechanism must not seriously

interfere with the intention to permit file storage and retrieval form

mass memory.

Figure 9 shows the structure *adopted for use by REMOTE. The

catalogue consists of a forward-backward linked list of ALLOC segments

(which could contain, say, 32 or 64 words each). The forward and

S 34
register 1

register 2

Figure 9. File Structure.


record 1

record 2

backward links are respectively the first and second words of each

catalogue segment. All other catalogue segment words may contain the

address of a register. A register is identical in structure to the

catalogue. Each register segment word (excluding the first and second)

may contain the address of a record segment. The set of all record

segments referenced by a single register constitutes a record. It is

customary, since a one-to-one correspondence exists between registers

and records, to say that the catalogue refers to records.

It is in the record segments that the files are stored. Record

segments may be any desired multiple of the ALLOC segment size. The

size is specified via the SPUR vector introduced in the preceding section.

The continuity of a record (or should we say apparent continuity) is

achieved by virtue of its register. The absolute addresses of all record

segments participating in file storage are kept in the register segments.

Zero contents of a register segment word indicate that the corresponding

record segment has not yet been requisitioned from ALLOC. A negative

integer stored in a register segment word indicates that the contents

of the corresponding record segment are currently resident on mass


Let us briefly review the objectives and constraints noted in the

first paragraph of this section before pursuing the features permitting

the hierarchical character of file storage. The use of record segments

certainly satisfies the stipulation of eliminating any dependence of

the file system on large partitions of ALLOC. The registers provide

the linkage mechanism for the record segments which is thus segregated

from the records and interference with mass memory operations is

therefore minimal. Further, the linkage mechanism seems to satisfy

the requirement to provide rapid random access and gives the record

apparent continuity to the user. It is important to note, however,

that these objectives were met without creating a support structure

that would require a large amount of memory. For example, consider

an ALLOC segment to be 32 words and a record segment to be 64 words.

A catalogue segment and a register segment, a total of 64 words, can

hold the addresses for up to 30 record segments or a total of 1920

record words. Thus, the support structure (catalogue and registers)

only consumes slightly over 3% of the total memory allocated to a file

storage application.

The responsibility for the hierarchical character of the file

storage system belongs to the directory concept. Consider, if you

will, a file consisting of single word file entries. Into each file

entry place the address of a file. This then is the notion of a

directory. It is a file which refers to subsequent files. One or more

of these subsequent files may also be a directory.giving rise to the

hierarchical property. However, care must be exercised with respect to

the addresses employed in the directory entries. If absolute addresses

are used, the file system would become dependent upon the particular

ALLOC buddies serving as record segments. This would seriously impair

the use of mass memory. An addressing scheme independent of the absolute

addresses of the record segments is required; a relative addressing

scheme is used.

The relative address of a particular word in a record is simply

the integer identifying its sequential position within the record. That

is, the ninth word of a record has for its relative address the integer

9. (We shall adopt the convention that the word "address" appearing

without the modifier relative will be taken to mean "absolute address.")

The absolute address is readily calculated from the relative address

by using the register. If a record segment has 64 words in it then

relative address 132 is in the third record segment, word 4. The

absolute address of the third record segment is kept as the third entry

in the register.

When preparing to add a new file to a record already containing

one or more files, it is necessary to know where the last file ends.

To this end, the first word of each record (the word in relative address

1) is reserved for the relative address of the first empty word in the

record. It is also advantageous, when manipulating a particular file

within a record, to know how many file entries constitute the file and

how mary words each file entry occupies. A special file entry appears

as the first entry of each file containing these two parameters. We

shall call this file entry the parameter entry of a file.

Figure 10 is an example of the contents of a record. In this

example, 16 words are occupied by files, so that the first record word

contains 17. The first file commences in word 2 of the record with its

parameter entry; this special entry is illustrated as occupying two

words. It indicates that the first file contains two single word

entries, whose contents here are 6 and 11. In particular, this first

file is a directory and its entries contain the relative addresses of

two other files. For instance, in word 11 we find the parameter entry

of a file composed of two file entries of two words each.

Quite naturally, the question arises, as to how access to a partic-

ular file entry may be achieved. Access to a particular file entry

entails selecting the appropriate record (ie, the address of its register)

from the catalogue, and then making selections from each directory to

reach the desired file. Once having accessed the file, by using the

word number
(Relative Address) record Relative address of next
unused entry
1 17
2 Parameter
3 1 Entry directory
F-- 6
5 11
S3 Parameter
7 1 Entry File 1


11 2 Parameter
13 File 2



Figure 10. A Record.

number of words per file entry, reaching any particular file entry has

been reduced to a problem primarily in counting.

The required selections to be made from the catalogue and

directories are specified by a vector, LISTER. The first word of

LISTER is its dimension, or in other words one plus the number of

choices. The record to be selected from the catalogue is indicated in

the second LISTER word. If the dimension of LISTER is N, then the

next (N-3) components of LISTER specify selections from the directory

hierarchy. (There is no requirement that directories need be employed

if a record is to contain only a single file.) Finally, the last LISTER

component, the Nth, identifies the particular entry from the file

selected. For example, if the record shown in Figure 10 is record

number 10, then the LISTER vector (4, 10, 2, 1) will result in the

access of the file entry commencing at relative address 13. (Word 1

indicates the length of the LISTER vector which is 4. The 10 says the

address of the register for this record is in the tenth entry in the

catalogue. The 2 says we are to go to entry 2 of the initial directory

which points us to file 2. The 1 indicates we want the first word of

the file which is word 13.)

The LISTER vector provides sufficient information for accessing

an entry in an existing file, as in the transfer of data from a file

entry. When data is to be stored in a file which until this point has

not existed, supplemental information is required about the size of

any new directories, the size of the new file and the number of words

per file entry. This supplemental information is required to insure

that sufficient space is reserved (since later entries may be added)

for each new directory and file added to a record. This information

is provided by a second vector supplied by the user, the length of which

is 2+ the number of directories. If LISTER(l) is N, then the

number of components in the auxiliary vector is (N-l). Note that it is

necessary only to provide the number of entries in each directory and

not also the directory entry size since by convention the directory entry

size is permanently fixed at unity. Directory sizes account for the

first (N-3) components of the auxiliary vector. The remaining two

components are respectively the number of file entries and the file

entry size. The supplemental information is of utility only for those

directories which have not previously been established. Components

corresponding to existing directories are ignored.

Consider a file processing scheme involving the access of many

entries on a particular file. The catalogue and directory selections,

if repeated for each file entry, would constitute needless repetition

since access of the same file would be the result each time the selection

sequence is executed. Thus, it is desirable to provide the means of

reaching another entry in a file from a file entry that has already

been accessed. The move relative to a given file entry to reach another

is specified by providing the distance (i.e. number of file entries) of

the move and the direction of the move. The LISTER vector is the vector

for this information. LISTER(l) is set to 1, indicating the move-relative

mode. LISTER(2) contains the displacement as a signed integer, with

positive and negative values indicating forward and backward displacements

respectively. The LISTER vector (1, 1) would access word 14 of the

previous example. Repeating with (1, 1) wbuld then accessword 15, and

so forth.

If movement relative to a particular file entry is to be accomplish-

ed, one must know exactly the location of that file entry. Unfortunately,

knowing the location of a file entry involves more than simply knowing

its absolute or relative addresses, though these addresses are certainly

essential. It is also necessary to have available theaddress of the

record segment, the sequence number in the record of the.record segment,

the register segment address and the particular record segment word

referencing the record segment. This is by no means a complete list,

for many other parameters have been found to be of utility in expressing

positions within files or of utility in executing the relative move

itself. To provide a storage medium for these parameters, a vector,

JCLOAD, has been created. This vector consists of 30 components, each

of which is described by the comments to program C4ADRS in Appendix

A. For most users it will be sufficient to know that the vector exists

and is provided by the user, and that user changes to the vector are

prohibited if the relative movement option is to be exercised.

As a result of the sequential appearance of file entries within

the files, no verbs for link manipulations are required. In fact, the

user is provided with only three verbs for performing manipulations of

file storage. These are STORE to store data in a file entry, FETCH

to retrieve a copy of data in a file entry, and FIND to locate a file

entry containing a particular data value pattern. The specification of

the data fields to participate in the data transfer operations is

accomplished identically as in the description in the preceding section

for COAST. REMOTE does require certain restrictions with respect to

data types. Table 2 gives the data types, with their LEND components,

which are necessary. Beyond these four data types, the user is free

to organize the LEND in any convenient fashion. The V in Table 2

indicates locations where the user may exercise choice.

One eventuality of file storage has until now been neglected.

It is possible that a file entry occupying several ALLOC words may not













0 0. > >
o 4 >"
o o. o

H l Cl ) '~I



( C
: C

exactly fit at the end of a record segment. Two policies are possible.

One, the file entries are required to be continuous, risking the waste

of a few words per record segment. Two, the partitioning of file

entries between record segments is to be allowed. If the file entries

are not small with respect to record segment size, the latter policy

is clearly more desirable with respect to efficient use of memory.

Since the sizes of file entries and of record segments are choices

permitted to the user, and since the restriction of the user's freedom

to organize a file structure was to be minimized, the partitioning of

file entries is allowed by REMOTE. As with the JCLOAD vector, the

user need not be aware of file entry partitioning to successfully employ

REMOTE. The user may prevent partitioning by a judicious choice of the

record segment size or of the number of words required by the parameter

file entry initiating the file. This latter play is implemented by the

word index selection in the LEND component for data type 4. The parameter

entry (See Figure 10) is structured with data type 4 concluding the

entry. Thus, by adjusting the number of fields subtended by data type

4, it is possible to regulate the size of the parameter entry without

otherwise disturbing its contents.


The basic network structure has been discussed in Section II.2.a.

As noted there, certain data fields are essential to the network structure.

That is, the links alone are insufficient to adequately define a network


Table 3 is a list of the data fields augmenting'the link fields.

Of these additional fields, only data type 3 and the first two fields

of data type 5 are ofanessential nature. In order to differentiate

nodes from diverger entries, some unambiguous feature must be provided




S) O




0 V
Cn Co Co

,.) Co 1

'H 0=



*H Co




4 b0o eC
Co C *H V
t *r > 00
$4 > to C 0
> m) H
S4J 4-1
41 0 z r4
Co Co .Co tt o
S. 4-' q
C 4 C *H3
$4 m Co 0;
to 4-' C0 0 $4

00 0 Co 0 0
Co : :
0- $4
*rl C (D O 1 r1

*H C CO 0 0
4 ,M O V $4

VH 0 0 0 0

C ,
tH 444 Q0)







H r ,

HH >r l,



to each. This feature is a flag, which is zero for a diverger entry.

The first field of data type 3 serves as the flag. The + symbol in the

LEND for data type 3 indicates that the mask may encompass more than

a single bit. The first two fields of data type 5 contain the number

of paths leaving a node in each direction. These fields are absent

from diverger entries.

The remaining data fields listed in Table 3 are not essential to

the network structure, but are required if the network is to be traced

using the verb NEXT.

The trace strategy employed is somewhat involved. Each trace is

assigned a unique trace key. We shall call this key the master trace

key. The purpose of the key is to flag the nodes which have been encoun-

tered by the trace so they may be distinguished from those which have

not yet been reached. This is necessary since several paths may lead to

the same node. Upon the first encounter of a node,which is indicated by

its trace key being unequal to the master trace key, the trace key is set

equal to the master key and the counter in field 3 of data type 5 is

set to unity. Successive encounters with this node will be indicated by

the trace key matching the master key. The counter is incremented by one

at each encounter of the node. When the counter matches the first field

of data type 5 for a backward trace or the second field of data type 5

for a forward trace, a node has truly been "reached." Further, it is

only upon meeting this criterion that the links leading from a node in

the direction of trace may be examined.

The trace strategy was dictated primarily by the needs of the

interpreter in evaluating the components of a solution procedure. No

component may be evaluated until all preceding components have been

evaluated. That is, no node is considered as reached until all paths

leading into the node have been followed. Figures 11 through lle

illustrate the steps in tracing a simple network. The data fields

appear in the nodes shown in the order of their occurrence in Table 3.

For simplicity, each is assumed to occupy an entire word. An appears

beside each node as it is reached.

Let us consider Figure llc. The count does not match the number

of backward paths. This causes the trace procedure to backtrack and

consider the path parallel to B. For more complex networks, it is

necessary to distinguish the parallel paths yet to be considered from

those which have already been inspected. This distinction between paths

is facilitated by an auxiliary push-down list. Each entry on this list

points to a diverger entry. These diverger entries are the first on

their respective divergers which have not yet participated in the trace.

The top member of this list always points to the last parallel path

encountered and the first to trace when the current path terminates.

It may be noted that the sub-nodal network trace key played no

part in the trace illustration. This trace key is the master key for

networks existing as auxiliaries to network nodes. The import of the

network within a network will be pursued in Chapter IV. When the

sub-nodal networks are present in a network structure, the trace pro-

cedure accounts for their presence by entering each auxiliary network

just prior to advancing to the next node on the main list. For

example, if node A of the trace example presented in Figures 11 through

lle possesses a sub-nodal network, node B is not considered to directly

follow A in the network trace. Rather, the first node of the sub-nodal

network follows A in the trace. A unity identification flag identifies

nodes possessing sub-nodal networks. All nodes possessing flags greater

than unity are not permitted sub-nodal networks.






Figure 11. Trace (Start).

Figure lla. Trace (Step 1).

Figure lib. Trace (Step 2).

Figure llc Trace (Step 3 no node selected).

Figure d. Trace (Step 4).
Figure lld. Trace (Step 4).

Figure lle. Trace (Completed).

As a result of networks within networks, the auxiliary list

employed by the trace procedure must be complicated somewhat. The paths

yet to be inspected at each level in the network must be segregated

from those of all other levels. This segregation is accomplished by a

list composed of one entry per network level. Each entry points to a

list indicating the remaining parallel paths on a particular level.

The manipulation of this auxiliary list structure is not required of

NETPAC users.

The subroutine NEXT is the NETPAC verb providing the trace

capability. NEXT requires only that the user indicate the address

of a current node and the value of the master trace key. NEXT performs

all of the network and auxiliary list manipulations necessary to provide

the user with the address of the next node in the trace sequence.

The COAST verbs require SPUR vectors to indicate the size of list

entries and the list type. In order for the NETPAC verbs to employ the

COAST verbs, it is necessary to provide a battery of SPUR vectors,

since many different sizes of list entries appear in the networks used

in GENDER. One SPUR is required for each list entry size. To satisfy

this requirement, a sequence of SPUR's graduated in sizes from a

single word list entry up to the largest possible list entry size are

stored in a continuous ALLOC partition. It is expected that this SPUR

block will typically be less than the ALLOC segment size.

Having the SPUR block only solves half the problem. To be able

to select the proper SPUR, one must know the sizes of the various list

entries constituting the network. A vector, which we shall call the

information block, contains this data. The values for each information

block component are provided as data by the user. Only three pair of

the 28 information block components are required by NETPAC. These pair

are components 8-9, 20-21 and 22-23, and are associated with networks

employing list types 2, 6 and 5 respectively. Networks have been

restricted to list types 2, 6 and 5 primarily as a programming conven-

ience since the use of NETPAC external to GENDER is doubtful. Information

block components 8, 20 and 22 indicate diverger entry sizes, while

components 9, 21 and 23 are node sizes. The identification flag

distinguishes nodes from diverger entries. Although more than one

type and size of node may appear in a network, NETPAC requires access

only to data types 1 through 5. Since every node contains these data

fields, the SPUR for any node will suffice NETPAC. For the user's

convenience, information block components are reserved for the sizes

of the other nodes permitted to list types 2 and 5. Discussion of the

remaining information block components is deferred to the particular

chapters to which they are relevant.

The information block introduced in the preceding paragraph resides

in ALLOC. The address of this block is recorded in the seventeenth

ALLOC word. Consequently, access to information block data is relatively

simple and the data is available to all GENDER subroutines sharing ALLOC.

It would seem advisable to make similar provisions for the SPUR block.

In fact, a vector, NIMBL, has been invented to contain the addresses

of the network and the SPUR block. NIMBL also contains the value of

the master trace key. The address of the NIMBL, thus, furnishes suffi-

cient data to permit the access and manipulation of a network.

Table 4 is a list of the NETPAC verbs. BREAK and COUPLE appropri-

ately adjust the path counters, as well as performing the necessary

link manipulations. One node to be separated from a second via BREAK


o 10

0a a

$ 'a

C S '
So '4 m4
0 a)

40 0 ,0 .0 a a
S 0 4
4 0 0 05
H 3 M c H
04 o o) +

( 0(
H 0 0 ZH

1- 0 co E-

maE 0 ; -i

.) 4 aozz

< ci $4 H H
E- u u CD P. w cu

1a C pn H 0C

must be specified by its absolute address. Although the second node

may also be specified by its absolute address, it may be designated by

reference to a path leading from the first node. Referring to Figure

11, node A may be separated from node C by providing BREAK with the

addresses of both A and C, or with the address of A and the integer 2

indicating the second diverger entry. The path specification mode is

available to both forward and backward directions. That is, A may

either precede or follow C. BREAK is designed to provide the calling

program with the path position if the addresses of both nodes are

specified, or with the address of the second node otherwise. This

feature has proven to be of use in the algebraic package, GALAP.

COUPLE requires the specification of the addresses of both nodes

to be connected and the specification of the path positions. While the

order of diverger entries is of little consequence to solution procedure

network, the arrangement of parallel paths is of considerable importance

in GALAP. Consequently, COUPLE has been designed to permit selective

path placement.

The verb SEARCH provides the capability to search a network for

a specified pattern of data values. The data values and the correspond-

ing data fields are provided to SEARCH identically as for the COAST

verb LOCATE. SEARCH employs NEXT in performing the network trace.

Networks possessing a single starting node and a single terminal node

may be readily searched in either direction. However, a network having

multiple terminal nodes cannot be completely searched in the backward

direction. The selection of a terminal node to serve as the initial

trace node excludes from the trace, at the very least, the other terminal



Section III.2.b provided a glimpse at the sparse incidence matrix

structure. This section will further detail this most important data


The ordinates of an SIM (sparse incidence matrix) are applications

of REMOTE. However, this need not have been the case. The ordinates

might simply have been continuous partitions of ALLOC. An ordinate of

1,000 entries would require a maximum of approximately 9,000 words.

This would constitute a demand for a buddy unlikely to be available,

except when specially provided. The implementation of the ordinates

as REMOTE records eliminates the requirement for special supervision

of the ALLOC allocation mechanism. Further, the use of a record as an

ordinate entails no further sophistication of the REMOTE facilities.

Figure 12 shows a sparse incidence matrix with the ordinates

detailed as REMOTE records. This matrix is the same as the one in

Figure 5, but shown here in more detail. List type 3 has been selected

for the ordinates. A number of data fields are required for each

ordinate entry. For convenience, these fields are tabulated in Table

5. A few of these fields require further clarification. The status

flag is a relatively small field reserved for use by the solution

procedure generation algorithms discussed in Chapter V. When equal

to one, the dimension flag indicates the substitution of a pointer to

an auxiliary data block for the name in data type 9. The auxiliary

data block contains the name, dimensionality and index values as whole

word entries each. The name is more properly called a code name. The

code name uniquely identifies the occurrence of a function, ER, constraint

or variable in the data base SECEDE. SECEDE and the rationale of code

names is discussed in Chapter IV. Data type 8 has no significance for

row ordinate


4 V

o 0

0 0 *H
0 U CQ

10 -i-

o4 H


H 0
C4 4J p
4-1O C0






in '0 t- w

0' 0 N CO
1 H- H- -



O *-


a .





0 H


the column ordinate entries, since all columns represent only variables.

The group mentioned in Table 5 for data type 8 will be pursued

subsequently in Chapter IV and is more properly called a protected

group. For our purposes in this section, it is sufficient to regard

a protected group and the ER (for external routine) simply as functions.

That is, they are functional relationships involving two or more

variables. If the multiple output flag is set to one, the output

assignment in data type 13 is replaced by a pointer to a list of output

assignments. Two words are required for each list entry. The first

contains the link and the second contains the output assignment. An

output assignment is simply a row or column number depending on whether

the ordinate pertains to columns or to rows respectively.

Each element of a sparse incidence matrix must also carry some

information in addition to the links. In particular, it is necessary

to-know to which column and row an element belongs. This information

is provided by fields reserved for the row and the column indices.

Other fields are required, but are of a more specialized nature. Table

6 summarizes the data fields appearing in each element. The field for

the sensitivity may be omitted at the user's option. The status flag

and output selection cost are required for the output assignment and

other algorithms. List type 4 is reserved for the SIM elements.

The 28 component information block introduced in the preceding

section contains components pertinent to the SIM. Table 7 indicates

the information block partition dealing with the SIM.

As in the case of networks, a SPUR block is essential in construct-

ing and performing manipulations on an SIM. The SPUR's required

correspond to LOAD vector size (30 words), the element size, ordinate

i- -



4H CO *E

0 4
g '- CO
* > H C
O 0 0 H
> r


>> >>>

Hl 'c cC -, LO- so L




'! '0

g- .,-





0C 'U

ri 0


Srl f





C w
a r


S P4






0 ,*H


* S

0 H

P 0>

o Z u


0 o


0) *0

c o

0 0

o po

Hr r- r-l

segment size and list ent-iy sizes from a single word up to the largest

required for an auxiliary data block. This largest list entry size is

determined as (2 + maximum dimensionality). The maximum dimensionality

is contained in the fifteenth information block component. The

individual SPUR's appear in the SPUR block in the order of their

enumeration above. The point of reference in the SPUR block was selected

as the sixteenth word of the block. That is, the address used to

access the SPUR block is the first word of the SPUR for a single word

list entry. Decrementing this address by five accesses the SPUR for

an ordinate segment.

Not only has the SPUR block been adapted from NETPAC, the SIMBL is

not unlike the NIMBL. The first two words point respectively to the

column catalogue and the row catalogue. The third SIMBL word points

to the SPUR block. The description of the SIM structure in detail is

completed by stating that the address of the LOAD vectors are contained

in the catalogues. That is, the address of the LOAD vector for the

row ordinate appears in the second catalogue word.

It is permissible for an SIM to be equipped with more than a

single row and a single column ordinate. Working.or temporary ordinates

are frequently utilized by the solution procedure generation algorithms.

Because of the inclusion of the LOAD vector addresses in the catalogues,

all ordinates are odd numbered REMOTE records.

The majority of the SIM verbs are specialized in nature, dealing

with a single, generally repetitive SIM operation. The SIM verbs are

listed in Table 8. The SIM generator, SIMGEN, performs a great deal

more than a simple SIM manipulation. SIMGEN uses the list of functions,

ER's, etc. belonging to a partition of the solution procedure (called

0 H



u O

m (O

Tl 0

0 +0


ma' C
'0 0
04-' r




M 4



0 0
o o

c '




- 0








m >



r3 0
0 U

41 0

*r4 0
!H o


0) 0n
*H 0

'0 4
0 '


a group) for which further analysis is required as the basis for SIM

generation. Each functional relationship is assigned a row in the

order of occurrence in the group. SECEDE furnishes SIMGEN with the

incidence and output assignment cost data. SECEDE is described in

Chapter IV. In addition to structuring the SIM, SIMGEN also initializes

the row, column and element status flags at zero. The utility of the

SIMPAC verbs will become more obvious in Chapter IV.



The information constituting a system of equations and the

associated solution procedure must be readily available. One approach

to the data base would have been the inclusion of all information

relative to an equation set within the solution procedure. As noted

in the proceeding chapter, the network structure was adopted for the

solution procedure for reasons of flexibility and ease of manipulation.

The concept of the unified data base would, during certain operations,

encumber the solution procedure with much more data than required. An

alternative approach involves providing the general information apart

from the specific information pertinent to the solution procedure.

IV.1. Service Module, SECEDE

The general information phase of the data base must at times augment

the information within the solution procedure. For instance, during

generation of a sparse incidence matrix the variables appearing in an

equation must be known. Since this information is not contained within

the solution procedure (as SIM generation is one of the few instances

when it is required), it must be extracted from the general information.

Further, since the equations on the solution procedure are subject to

re-ordering, it seems appropriate to require rapid random access to

the general information.

The file system, REMOTE, described in Chapter III not only fulfills

the requirement for rapid random access, but also permits the release


of ALLOC space by the transfer of data not currently required to mass

memory. The application of REMOTE to the storage of information

relative to an equation set is termed the service module (SECEDE).

.The organization of data within SECEDE required careful considera-

tion. First, the construction of a library of data relative to various

processing units is to be permitted. Second, the organization must

permit the deletion or inclusion of units from SECEDE. Finally, SECEDE

should permit the reorganization of the flowsheet (i.e.,connections

between units). All of these considerations are essential if the

employment of GENDER during the synthesis phase of design is to be

feasible. The first two requirements are satisfied by assigning each

unit to a separate record. The third requirement is satisfied by

restricting all of the information on stream connections to a single

record called the zeroth unit. Thus, reorganization of a flowsheet

would involve changes only to the zeroth unit unless additional units

or unit substitutions are involved as well.

It is, of course, not known a priori what position a unit, which

may be from a library, might occupy in the service module. This

necessitates a code name assignment scheme for the variables and

equations which will produce unique codes. The variables and equations

within each unit are sequentially assigned code numbers commencing with

unity. The unique code is developed by adding to the code number, as

assigned within the unit, the unit number multiplied by an arbitrarily

selected scale factor. For instance, variable 5 of unit 9 would be

known by the code 905 if the scale happens to be 100. The code 905

differentiates this particular variable from the fifth variable of all

other units.


IV.2. Solution Procedure, GENDER List

For the reasons noted in Chapter III, the solution procedure is

a network application. It is expected that many solution procedures

will involve cyclic calculations. The GENDER list must reflect the

existence of such cycles. Special nodes are provided, called groups,

which represent the occurrence of a special set of functional relation-

ships. These may be cyclic, or may be grouped because of other common


The group node appears in the network as a representation of the

group members. Membership within a group is indicated by the nodes

of a network called the group body. Each group contains the address of

its group body. Groups as well as equations, ER's and constraints may

belong to a group body. The group bodies give the GENDER list a

dimension of depth i.e., networks within networks.

The GENDER list must be a complete specification of the solution

procedure it represents. That is, the GENDER list must reflect decision

variable selection, output set assignment, precedence ordering, tear

variable selection, and selection of the method for resolving cyclic

calculations. Data fields and/or auxiliary lists are provided to store

all of the foregoing information with the exception of the precedence

order. The precedence order is reflected by the arrangement of the

nodes on the GENDER list.

IV.3. Input/Output Facilities

The initial point for a GENDER list is generally expected to be

the crude GENDER list generated by a program called CUDGEL. Each

equation, ER and constraint is represented by an entry on the crude

GENDER list, but missing are the details and auxiliary lists necessary

for a complete solution procedure specification. Though this may be


the usual starting point, it will not always be most convenient. For

instance, a solution procedure might be completely developed, but

interpretation prohibited by the lack of a value for an algorithm

selected decision variable. For operation in a batch machine environ-

ment, this eventuality would cause the effort of analysis to be wasted

unless recovery facilities are provided. While one obvious solution is

to require estimates for all variables prior to initiating analysis to

prevent the development of this particular situation, an inordinate

amount of effort would be required from the user. This is but one

instance of when an analysis might be wasted. Others exist, and

enumerating precautions against all is unlikely. The recovery mechanism

has been incorporated into the input/output facilities.

While the recovery provisions are not automatic, they do posses the

virtue of simplicity. When the development or interpretation of a

solution procedure must be abandoned, the service module and the solution-

procedure may be saved for use at a later time in one of two ways. Both

SECEDE and the GENDER list reside in the ALLOC vector. Hence, a copy

of the contents of ALLOC will save SECEDE and the GENDER list. The

second approach involves the output of only SECEDE and the GENDER list.

This latter strategy will greatly reduce the output volume, but this is

not the primary advantage. The format of output may be adjusted to

produce a much more manageable medium. Particular significance will

be attached to each output record and the output records formatted

according to content.

The medium selected for storage of service modules and solution

procedures for later use is punched cards. Thus, when the solution of

a problem must be aborted, the programs SECIAO and GENIAO may be directed

to produce respectively the contents of SECEDE and of the GENDER list

in card form. These cards may later be read by SECIAO and GENIAO to

resume solving the problem. Observe that a solution procedure, complete

in every detail, may be stored in card form as readily as a partially

complete solution procedure. In fact, a library of solution procedures

may be amassed to eliminate repetitive analysis of problems which are

frequently solved.

The format of each card generated by SECIAO and by GENIAO is

presented in Appendix A in terms of data formats. This is permissible

since the input and output formats are identical. For the convenience

of the user, a printed output will always be provided with card output.

In fact, a printed only output mode may be selected for both SECIAO

and GENIAO should the punched card output not be desired.

IV.4. Implementation Details

The remainder of this chapter delves into the implementation details

for SECIAO and for GENIAO. These details will be of utility only to

those users wishing to prepare programs which directly access either

SECEDE or a GENDER list. Most users should find the program comments

for SECIAO adequate to encode properly the statement of the problem as

SECIAO data. The printed output of both SECIAO and GENIAO is preceded

by a table indicating the composition of each type of output line. A

third subprogram, VARIAO, completes the input/output facility package.

VARIAO supplies a user with a list of variables for which values are

required. VARIAO is provided primarily.for use by the interpreter,

GLINT, to indicate variables encountered for which values have not

been provided.


Basically, the service module, SECEDE, is an application of REMOTE.

The REMOTE system is founded on the premise that all entries of a file

are of the same size. Unfortunately, exceptions to this fundamental

premise may arise. For example, SECEDE is required to store functions

in terms of the variables, operators and constants of which they are

composed. All three entry types require data fields for an identifica-

tion flag and a code name. However, the variable also requires fields

for the dimensionality and, if applicable, the indices. While it

would certainly be possible to insist that all file entries representing

a function be equal in size, the opportunity for wasting considerable

ALLOC space would just as certainly be present. This eventuality would

be realized for all functions containing only a few dimensioned variables

with respect to the total number of entries.

The apparent inconsistency between storing functions as REMOTE

files and efficient memory utilization can be reconciled, albeit

artificially. To each file entry add another data field containing

the length of the entry. Moving from one file entry to the next would

involve adding the file entry length to the current position in the

file. Except for the variations in file entry length, this procedure

is decidedly reminiscent of the relative move capability already present

in REMOTE. In fact, if REMOTE were led to believe that the file entry

length is unity, and if the actual entry length is used as the number

of file entries to advance, then movement can be accomplished via the

REMOTE relative move mechanism.

Before proceeding, we should clearly'differentiate the two types

of entries discussed in the preceding paragraph. When establishing a

file, the JCFINE vector specifies the file entry length. This is a

fixed number and is the length employed in specifying the length of a

file. The entry of variable size is not a true file entry. It is
rather a sequence of one or more words of a file which we choose to

treat as a single entity and to which we attach special significance.

Let us assign the acronym ASE to the adjustable size entries, while

reserving the term file entry to mean true file entry in the REMOTE


A file composed of ASE's strongly resembles a forward-only list.

That is, the length stored in each ASE serves as the link to the next

ASE. Consequently, we shall refer to this scheme as relative linking,

and to the stored length as the relative link. The last ASE must

contain zero for the relative link just as a terminal list entry must

contain zero for the forward link. Since the identification flag

stipulates the fields within the last ASE, and since the LEND stipulates

field placement within the ASE, the zero length specification presents

no hindrance to data transfer.

A hindrance to data transfer does, however, exist. The file entry

length must be specified as unity to permit relative linking. Normally,

REMOTE will not permit data transfer operations to exceed the bounds

of a file entry. The ASE's are expected to be multi-word entries. To

circumvent this problem, REMOTE was adjusted to permit the violation

of file entry bounds if LOAD(29) isset equal to -1. The user must

ensure that LOAD(29) is properly set before attempting access to any

file. LOAD(29) should be 0 for all files not employing relative linking.

As we noted earlier, an ASE file resembles a forward-only list.

Consequently, it is not possible to randomly access the ASE's. This

need not be the case. Suppose the relative links are removed from the

ASE's and placed at the beginning of the file. The value of the

relative links would, of course, be different since the relative link

is the number of words to advance from the current position to the ASE.

What we have developed is the notion of a directory, employing relative

links instead of relative addresses, which is internal to a file. The

term internal directory shall be employed to describe this placement

of the relative links.

Files containing ASE's in the list format will be called sequential

access files, SAF's. Files containing unlinked ASE's and an internal

directory will be called random access files, RAF's. The RAF does not

provide a storage capability which can not be duplicated by an ordinary

REMOTE file structure without recourse to ASE's. This could be

accomplished by establishing each ASE as a separate file and providing

a directory permitting random access to the separate files. However,

this structure demands that the relative access be accomplished at

the expense of repeating all catalogue and directory hierarchy selections

for each access. The RAF structure permits the access computations to

commence with the internal directory, since this directory and the ASE's

are actually all members of a single file making the REMOTE relative

address capability applicable. That is to say, the RAF access time

would be generally shorter.

SECEDE consists of at least five records, each record containing

from one to five files. These files include all three types; ordinary

REMOTE files of equal sized entries, SAF's and RAF's. Each record

will be given individual attention. In the discussion to follow, the

notation (t i f j) will be used. The letters i and j represent integers

indicating data type and data field respectively. The letters t and f

should be translated as type (i.e.,data type) and field. If we were to

speak of a data field (t5f9), we will be considering the ninth field

of data type 5. On occasion it may be convenient to expand our field

designation shorthand to include a range of fields for a single data

type. For example, (t5f7-9) is translated as fields 7 through 9 of

data type 5.

Armed with the above bit of cryptography we are prepared to inspect

the purpose and contents of record one. Tables 9 through 11 may be of

assistance in this discussion. The first record consists of a directory

and two files. The files contain respectively decision and tear

variables and are of the SAF type. Each of the ASE's contain the data

fields (tlfl-3), plus an additional two words for each degree of

dimensionality. The two word allocation for each index is required to

permit the specification of minimum and maximum of an index range. A

single ASE may represent, for a dimensioned variable, a single component

or many components. Each word reserved for an index contains the fields

(t9fl, tlOfl, tllfl, tl2fl, tl3fl, tl4fl, tl5fl), which correspond to

the seven constituents permitted in an index calculation as discussed

in'Appendix B. These constituents, in the order of the fields, are

mapping flag, mapping index, operator flag (0 for multiplication by

scale and 1 for division by scale), sign flag for scale (0 for positive

and 1 for negative), scale, sign flag for offset (0 for positive and

1 for negative) and the offset. The mapping flag may be either 0 for

no map, or may be 3 indicating mapping to another index of the same

variable. If the mapping flag is 0, data types 10-14 are ignored and

the offset is taken to be the index value. As a matter of convention,

all data structures requiring the seven part indices will employ data

types 9-15 exactly as described here.

The second and third records in SECEDE each contain only a single

file. These files are ordinary REMOTE files composed of file entries

all equal in size. Each file entry contains alphameric characters

forming the name of an operator in the case of record two or the name

H ''
a r
S a
c Ei

o ^
10 a
a) 0.^

Hl R


& 0

0r rd

CO 3d

0 n4 >
H Hc

CL| 1-0
0 4-;
o 4>

-4 a)
$4 *HHi-
*rH 0 CO
'0 PL, C)
a) 4-' tB
a) 04-
-4-a co

M : 0

H ci co m 'C C 0

*i- E
H )


a)-j' a)
0 0V'0
a)i *H 0
Co H- $1 C

4 a) ,0 *)

03 m) 0)
O > w.
Ca ) >;f
$40 aD Ca )
a) a) a).
^i,0 e- a)

:2:> CM 0


u) 43

,4 4
a 0) a)

., 1 0 .11
H $4l Cci

*H 0 4
o ca

a) a) -4-i$
*10) [.0 COa

a) a) 0,>
ri E >
rl ^1o crl

0 0 '0 ^
Z Z I-
m *i r
LC1 C) Orl?-
,n ,n cus
e e (u
3 F3 rl3

s; i- r-

r-H H m H H H
r-i r-A r-i H r-

0 > > CT
S > >

cq H > cq

c Cm "t m



*H *H

0 0
>4-J X

0 0

M) co 0

O. CO ,

=5 co

Hl- r-H H H

H lH H-l -l -I H H Hr- H

r-l -l H H H

r-- oo o
Hl -l -l



\'D COm


C) 0I
0 0 0 0
4 HE H

4- r
a 0a ,0 0 C (c
,0 ae>
( 0C0 *

4-4 0 0 4-
I pi-0 E u
0) 00U 4-01 Ce
l C1 (U 0O 0 *rl
0' n E' o Z 1.) o

S- C N H-i H H-


H 0'
i-l ck
i 4-i 41'
Q4- *' ;-
4-1' C '0

ft3 34 r44
4-' 4-' 4-' 4-'

4-1 41 41

r-1 C, 4 C,

r- r- H "

'P 4- 4-' '4 4-1
"C 'od

40 i 0 "H 03 0

_-' 4-' 4-' l|-' 4-'1 -
n t n 00 ^--
3 3 "1- 3 3
s i d d jc t
r- ll r- i~ -1 i-


' + H

4- C4 004

ft + + H
0 13 -l 4-

CO O '0 00

ll 1-1 H-

o H


r-I c



,n E

> 0

H- r-I r-

l lO l
r-i r- r-I

: +

0 0
M *

0 ca

(0 *H 1 0 0 0

W > C) *H a *H H
> -4 0
S> C I O I

r- i r i r ( O U O (1) Wt
H E p 0 CC W 0r :3 :3 0D
H E O O 0 m M m O C C i r-
m m a O *H > -j m m I
> E p C 1 ; IC
*H tB Io n 44 m cz 44 2 IH ql 44 >
H C > O > > i O IT O I O Ci O 0 a
o0 O H- r-H H I0 C 0 HC)
*H > 41 C r 0 *H C- ^ H C C C E 4

*I C C H 0 H C) > 10 0 10 w C i i IC 0 IC
cl E C4 E E VE 9 C
c 0 :3 0 0 oe z; 0 me 0 7 c O m
SE- ) C > H C > C >
H 4I C C C C fl C- U C- *H C- C- C- IC ,0 IC f


C) I


- 0






I : I





) C4) P4
*- -' *^
a K os

I I I I I H l l lo 'o I I I I

-H I I H N o H -H H H H H -H H io

H H mC t W O W w w) U) w I) m w

1-1 *H

E-I C.)


r. *
0 m
0 .5

0 0 0
0O 00

0 0 0
a 00 0t
4+ CD Q)

0 0 0

0 0 0 0
H +0 U
H 00 0 0

U *H

4 U) 0
0 0 0 'O 0

co C 7o 9 +
S00 c00 H .0
o aE li a) O

(H O 4o'

a a) 0) H
0 0 0

0 +
1 4 20 0 0
0 0 4H*H 0
4 m1 ++ e

R 3 0
0 0

*H H f H

: 1

of a method in the case of record three. A method is a user prepared

subroutine for supervising the convergence of a cyclic calculation

during interpretation. The notion of a method is further pursued in

Chapter VII. The entries of records two and three may be described as

(tlfn), where n is the number of words per name.

The processing units are regarded in GENDER to be completely

separate entities. To form a processing plant, the units must somehow

be connected together to permit the transfer of material between the

units. This physical connection of units is represented algebraically

by a connection equation. For example, VCN201 = VCN422 is a connection

equation relating variable code name (VCN) 201 to variable code name 422.

If the scale factor for unit numbers employed in developing the unique

code names is 100, then this example indicates the equality of variable

1 of unit 2 with variable 22 of unit 4. It is entirely possible that

a single variable may appear in several connection equations. That is,

many variables may share a common value. This leads to the notion of

a common storage location for the value of all variables sharing a

common value as stipulated by connection equations. Further, if the unit

variables are connected by the sharing of value storage locations, the

need for explicitly stating the connection equations in either SECEDE

or the GENDER list is eliminated.

Unit 0 is contained within record four of SECEDE and is reserved

for common variables. This record contains three files. The first

file is an RAF and contains data relative -to the dimensionality of the

common variables. The similarity of function between this file and

the DIMENSION statement in FORTRAN suggested the name declaration file.

Apart from those containing relative pointers, each declaration file

ASE will contain the fields (tlf(2+d)), where d is the dimensionality.


Field (tlf2) contains the dimensionality. The d fields reserved for

the indices indicate the maximums of each index. The field (tlfl) is

the pointer to the value storage location. The field is an absolute

pointer which is'computed by the program SECIAO during the establishment

of SECEDE. In particular, the absolute address corresponds to an entry

of the common variable value file. Although this file is only the

second on the record, a LISTER of (4, 4, 3, 1) must be employed to

permit access. The second directory entry is reserved for the number

of common variables. The variable value file consists principally of

entries of the form (tlfn), where n is the number of words per floating

point value. All values are in floating point format. While a single

entry containing (tlfn) is satisfactory for scalar variables, many such

entries are required for dimensioned variables. If a dimensioned

variable appeared on the file expanded into its components, the access

of any variable, appearing later in the file than the dimensioned

variable, would require knowledge of the number of dimensioned variable

components. That is to say, the random access feature of the file

is greatly compromised. As an alternative, let us consider partitioning

the variable value file into two divisions. The primary division

appears first in the file and contains one entry per variable. For scalar

variables, the primary entry is simply the value. For dimensioned

variables, the primary entry is of the form (tl7fl, tl8fl), with the

fields containing respectively the integer 21 and a relative link to

the first of a sequence of entries in the secondary partition. This

sequence of entries encompasses the values of every component of the

dimensioned variable. The integer 21 is provided as a safety measure

but has proven to be of only occasional utility.

_ _

The third file of unit 0 is the common variable name file and is

referenced by the fourth directory entry. The entries of the variable

name file are identical to those of the operator name and method name

files of records two and three.

Each record following record four is designated as a unit. The

unit records are considerably more complex than any record we have

previously considered.

A unit record comprises eight major file divisions, four of which

are further subdivided by second level directories. The individual

files are all of types we have already considered in the first four

records. The first entry of the first level directory references an

eight entry second level directory. Entries 1, 3, 5 and 7 of the

second level directory reference declaration files for variables, ER's,

equations and constraints. Directory entries 2, 4, 6 and 8 are respec-

tively reserved for the numbers of variables, ER's, functions and

constraints. The four declaration files are essentially the same as the

common variable declaration file of record four.

The variable declaration file requires the addition of a data type

1 field between the value address and the dimensionality, making each

entry of the form (tlf3+d). This additional field is reserved for the

code name of a common variable. When a unit variable is declared

common by a non-zero (tlf2) field, the common variable code name and

value supercede those of the unit variable during preparation and

interpretation of the GENDER list. That is, the common declaration

substitutes for the connection equation. The remaining three declaration

files require only the fields (tlfl+d), where the field (tlfl) is the


The second and third first level directory entries refer to the

variable and constant value files. The variable value file is identical

to the common variable file of record four. The constant value file

is quite similar to the variable value file, except that all constants

are single entities making the provisions for dimensioned variable

components unnecessary for the constant variable file.

The ER and the variable name files correspond to the first level

directory entries.four and five. The name files are structured identi-

cal to the files of the second and third records.

The first level directory entries remaining correspond to the ER,

equation and constraint files. Let us consider the equations. Each

equation is recorded on a separate SAF. The equation SAF's are recorded

on the equation directory, which is in turn recorded on the first level

directory. For example, the LISTER vector (5, 5, 7, 1, 1) would be

appropriate to accessing the first equation of unit 1. The equation

SAF is not unlike the decision and tear variable SAF's. The first ASE

pertains to the equation and is of the form (tlf3, 2xd). The field

(tlfl) will always be the relative link in an SAF. The fields (tlf2)

and (tlf3) are respectively the number of outputs and the dimensionality.

The indices are recorded exactly as they were for the decision and tear

variables. Each ASE after the first ASE represents a variable, operator

or a constant. A field, (t5fl), is employed as an identification flag

Flag values range from 0 to 2 and correspond in order to an operator,

a variable or a constant. The operator and constant entries are

identical and consist of the fields (tlfl, t5fl, tl6fl), with (tl6fl)

containing the operator or constant code name.

The variable ASE contains the fields (tlfl, t5fl, t7fl, t8fl, tl9fl,

Ixd). In order of appearance commencing with (t7fl) these fields are

an output selection .cost flag, variable code name, dimensionality and

the indices. The algorithm employed for output set assignment permits

the use of weights to influence the output set selection process.

The weights represent a cost of assignment and are scaled from 0 to

10. One word is reserved for each index which are in the seven part

format described for the decision and tear variable files. The ER and

constraint files are identical to the equation files except that

operators and constants do not appear in the ER files.

* IV.4.b. SECIAO

In the previous chapter, it was noted that certain support struc-

tures to the sparse incidence matrix were of utility. Much the same

situation exists here for SECEDE. The file entries are of varying

compositions and sizes, suggesting the use of an information block to

serve as a reference table.

The twenty-five word information block, mentioned in Chapter III

with respect to networks and SIM's, is again pressed into service.

Information block components 1 through 7 are reserved for data pertinent

to SECEDE. Table 12 list these components. It should be noted that

component 2, the length of a floating point value, is uniform throughout

SECEDE. All variables will either all be single precision or all be

double precision.

Apparently all of the ALLOC space required for SECEDE is in the

form of record segments, making the use of a SPUR block a somewhat

dubious feature. This is, however, not necessarily the case. In the

previous section, the description of the variable declaration ASE's

included a field reserved for the address of a storage location. While

this is perfectly satisfactory for scalar variables, a single address

may not be sufficient for a dimensioned variable. In particular, if

n H 4-

9 0 0 0

t o C) I) C)
Sa, -

D E ) ci 0
O 0 0 C

41 4-.J c Q r

o Hcu

S 4 00 co 41 rl 7- o
C 0 !< C) 0 01

> u ua H
S 04 *H 0 c H 0 C-
M 0 0 cO *

S00 O 0 0 0 CO
Ca X 4r 1 (

( 04-1 c a co *
t 0 ClC 4 u 0

0 C ci
C 0 0 0 co o c iC
M C Wcci ci) C 0 C)0

0 H NJ co c- LI) 10 c



the value locations reserved for a dimensioned variable extend over

several record segments, the single address will be inadequate. This

situation is remedied by establishing for each dimensioned variable a

dimensioned variable address resolution block, DIVARB. It is the

address of the DIVARB which appears in the declaration file for a

dimensioned variable. The DIVARB encompasses (2+d+r) words, where

d is the dimensionality and r is the number of record segments.contain-

ing values of the components to a dimensioned variable. The first word

of the DIVARB contains the dimensionality d. The next d words contain

the ranges of the indices. The (d+2)nd DIVARB word is called the offset.

The offset is the integer which when added to the address of the record

segment containing the first variable component will give the address

of that first variable component. For example, suppose that the values

of a dimensioned variable commence with the 2902 nd word of ALLOC.

Further, suppose the record segment address is 2861. The offset to be

recorded in the DIVARB would be 41. The remaining or DIVARB words

are reserved for record segment addresses. The DIVARB permits rapid

address resolution for a dimensioned variable component. The variable

value file is a linear storage medium necessitating the conversion of

multi-index sets into a single index. That is, the set of indices for

an array component must be converted into the single equivalent index

for the storage of the array as a vector. Except for the length of a

record segment and the number of words per value, all of the data

necessary for both the index conversion and the address resolution is

contained within the DIVARB.

The need for a SPUR block is now some what obvious. The size of

the SPUR block (i.e. the number of SPUR's required), however, is not

clearly defined. The DIVARB size depends not only on the dimensionality,

but also on the number of components of a dimensioned variable. The

dimensionality and number of components will remain unknown to SECIAO

until input of the variable declarations commences. Although it would

be possible to complete variable declaration input before preparing the

SPUR block and establishing the DIVARB's, it is unnecessary to do so

and may even result in the wastage of ALLOC space. A SPUR stipulating

a list entry size larger than one half the ALLOC segment size will

waste a portion of each segment allocated. This cannot be avoided.

However, the SPUR itself can be eliminated. We shall reserve a single

SPUR for all large DIVARB's, employing it by altering the list entry

size contained in the fourth SPUR word. The SPUR block adopted for

SECEDE consists of (2+(ALLOC segment size)/2) five word SPUR's. The

first SPUR is provided for the requisition of DIVARB's larger than one

half of ALLOC segment size. The second SPUR is appropriate to record

segment acquisition. The remaining SPUR's are graduated in list entry

size from 1 to one half of ALLOC segment size. It is the address of

the SPUR for the record segment which is considered to be the address

of the SPUR block.

The use of REMOTE requires a LOAD vector. In particular, two LOAD

vectors are required by SECIAO for manipulating SECEDE. The LOAD vectors

are furnished as a single vector 60 words in length which is called the

LOAD block.

The entire service module is bound together by a service module

block, SECBL. The first word of SECBL contains the address of the

SECEDE catalogue. The remaining SECBL words are pointers to the SPUR

block, the LOAD block and to an allocation of space reserved for index


University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs