MFF Users Manual for the FLEX2 and FLEX3

Model Processors for the FLEX Modelling Paradigm by Curtis White and W. Scott Overton

Bulletin 15 REVIEW DRAFT August, 1974

Forest Research Laboratory School of Forestry 23 (AMFF Oregon State University Corvallis, Oregon Users Manual for the

FLEX2 and FLEX3

Model Processors for the FLEX Modelling Paradigm

by Curtis White

and W. Scott Overton

Bulletin 15

REVIEW DRAFT

August, 1974

School of Forestry

Oregon State University iii

AB STRACT

FLEX2 is a general modelprocessor, patterned after Klir's

General Sequential System Paradigm. The processor is a specific

realization of the general FLEX/REFLEXalgorithm of the FLEX paradigm,

and can process modules oftwo types, FLEX (terminal) modules and

REFLEX (ghost) modules. One FLEX module represents a single-level,

hierarchical model. Each terminal module is a flux oriented realiza-

tion of the general paradigm andmay represent a non.-linear, non-

stationary, environmentally controlledstate variable system model

operating in discrete or continuous timewith explicit memory.

Stochastic components may be included. A ghost (REFLEX) module is a

subsystem oriented realization of the general paradigm and Is operable

only in discrete time. The current standard version (FLEX2) is

restricted to not more than 63 state variables, 40 input variables,

200 memory variables, 120 parameters, and50 output variables per

module, with an upper limit of 250 modules, A smaller version (FLEX3)

has 20 state variables, 20 inputs, 30 outputs, and 70parameters.

Further restrictions will be elaborated in the appropriatepart of

this write-up.

This processor represents the second generation ofprocessor

development according to this system paradigm, the first being

represented by FLEX1 (Overton et al, 1973). Although both are

oriented toward and discussed in terms of ecological modelling, it is not anticipated that utility is restricted to thisarea of study, but

rather that the processor and paradigmare applicable to a large variety of systems models. V

iret ace

This Manual is a culmination of work and conceptual inputs by a number of individuals over approximately three and one-half years. In identifying contributions, relating the manner of evolution of the paradigm/processor, and in indicating directions in which new developments are anticipated, a narrative form is adopted.

In the surnuler of 1971, the Central Modelling Group of the Conif- erous Biome had just completed a series of modelling meetings, in which the structure of the Unit Watershed Model began to take shape. At this time, serious thought was directed toward development of a general model processor, which accommodated a specific model with a minimum of coding. This idea was strongly reinforced by the reali- zation that the General System Theory of George Klir was compatible with the emerging view of what an ecosystem model should be like. My 1972 Bellingham paper summarizes these perspectives, and the 1973 Athens paper (to appear in Pattens 3rd volume, now in press) reflects later developments.

In retrospect, it is of interest that our development of the FLEX processors have followed the FLEX paradigm of hierarchical behavior and control. I wrote the specifications for the external behavior of FLEX1, and the program implementation was made by Jack Colby, this corresponding to the Universe Coupling Structure. Virginia Hunt and Curtis White also contributed to coding and were responsible for debugging and comp:Letion of documentation, Code was "complet&' in Summer 1972, runs were made in Fall 1972, the first manual appeared in January 1973 with firAa:L version in September 1973. Jonna Gourley helped in manual preparation. Colby took a year's leave in late summer, 1972, and White assumed the role of directing processor development

The FLEX2 pccessor followed essentially the same pattern, but in a double cycle. The initial concept of hierarchical assemblages of FLEX Modules, as expressed in my 1972 paper, was implemented in code by Colby with some interaction regarding specifics. We called this multilevel algorithm, REFLEX. Aficr completion of the FLEX1 manual draft, Wh:Lte directed effortst.. i:;.ard completlon of REFLEX. John Fuller was rerained for system ranirLg expertise in Spring 1973 when it became apparent that new aproaches to program structure were needed, These were. outlined by fle and. Fuller, and implemented by Fuller, with assistance from Dave long.

During this period, we had oppor'.unity to exercise FLEX1 in some depth. White and 1 developed a number of iodel versions of the Watershed hydrology model, and several other models, and White trans- lated several models from other code/documentation into FLEX. Then, in the course of a very short period at the end of Summer, 1973, White and I developed a new a1gorithmFLEX/REFLEX, which is presented here vi

as Figures 5 and 6, and associated text. This was integrated into the existing code, and successfulruns were made before the end of the year, but implementation of minor parts of thenew code was incomplete.

Termination of funding, as of December 1973, forced a halt to processor completion until receipt of NSF Grant No. GB-42641 in April, 1974. As of this writing, the processor is operative, and ready for use. Some minor features which were planned for eventual inclusion have not been implemented, but then it isnot intended that this be a terminal form, either ofprocessor or algorithm. Use will discover bugs in the code, and needs for modification.

FLEX2 has the capacity to accommodatea single level model of intermediate size (63 state variables) anda hierarchical model with large subsystems (same number of variables in each). A small version, FLEX3, which we call MINIFLEX,can accomodate 20 state variables, which is small for a single levelprocessor, but intermediate to large for a hierarchical model of several levels. MINIFLEX is consid- erably faster than FLEX2, and it is anticipated that general utility of the pair will not be exceeded byany existing processor or modelling language.

The future of FLEX is in some question. We had hoped that the current year would see extensive testing of the paradigm and processor. These activities should be proceedingat present, and they are badly needed. The concepts of level oriented behavior and response frequency are intellectually satisfying, but they must be made explicit through ecological examples. FLEX is designed to implement these concepts, but It needs exercising. Similarly, the identification of sub-systems, and assemblages of sub-systems, in thecontext of ecological theory, needs much attention.

It is our intent that FLEX2 be maintained at OSU. We have no planned structure for processing off-campus models, butarrangements can be made, and telephone operation is feasible. It is not likely that the code will export well, but a hierarchical documentation, in the paradigm of FLEX, will allow preparation ofnew code according to the requirements and characteristics of whatever computer system is involved. Such documentation is in preparation and will appear at roughly the same time as this manual. In encouragement of implemen- tation of FLEX2 on other computer systems,we will provide any of our documentation and code on request, at cost of copying, and placeno restraint on modification We would appreciate notice and documenta- tion of any improvement or discovered error, and suggest that personal contact with someone familiar with our system may be helpful In trans- lation.

The Review Draft of this manual Is issued in consIderable volume to expose the manual to early wide review. Some reviews are per- sonally solicited, but all users are encouragedto communicate vii

questions, suggestions, and criticisms tome. Current plans are for a revised draft of this bulletin one year after this date.

W. Scott Overton Corvallis, Oregon August, 1974

Acknowledgements

We would like to thank Mona Luebbert and Eva Hofenbredl for their patient and careful typing and retyping of this manuscript. Barbara Love did the excellent typing of the FLEXFORN's of Appendix Section All and Julie Kopplein handled the difficult task of typing the algorithm summary of Section II. Figures were drawn by Kathy Eisley, and Jonna Gourley provided very helpful technical editing.

Work on this project was initiated under National Science Foundation Grant No. GB-20963 to the Coniferous Forest Biomes, and completed under National Science Foundation Grant No. GB-42641. This is contribution No. 961 of the Forest Research Laboratory, Oregon State University. ix TABLE OF CONTENTS

Page

Abstract iii

Preface v

Table of Contents

List of Figures

THE FLEX PARADIGM

Introduction

Paradigm Development

Outline of the FLEX Paradigm

THE FLEX/REFLEX ALGORITHM

Introduction 15

Internal Nodule Processing 15

Higher Level Processing 17

Relationship Between Higher and Lower Level Processing 18

Lower Level Processing 20

Finishing Higher Level Processing 22

Nodule Couplings and External Processing 23

Notes on Total Model Assembly 25

Modeler/Programmer Communication -- The FLEXFORIYI 27

Algorithm Summary 31

III. PROGRANMING IN FLEX2

Introduction 35

Overview 35 x

Programming Details 37

A. Coding the Model FunctIons 37

Z Functions 38

The Test Function 40

G Functions 41

F Functions 42

H Functions 43

Y Functions 45

S Functions 47

B. Preparing a Function Overlay 48

A Note on Naming Files and Overlays 50

IV. USING FLEX2

Introduction 53

Preliminaries 54

Calling FLEX2 55

Commands 57

Editing 58

FLEX2 Commands in alphabetical order 59

B DUMPLUN LAG

CLEAR FIRSTSUB LAGX, LAGZ

CONTINUE FREEZE LEFTSUB

D, DKILL FUNLOAD LIST

DHEAD FUNSOURCE LI STALL

DPRT GHOST LOG, NOLOG

DUMP, NODUMP INPUT LP, LPKILL xi

LPHEAD RIGHTSUB TTYHEAD

LPLUN RESET TTYLUN

LPRT SIMULATE TTYON, TTYOFF

MAPRINT STOP TTYPRT

MODELGET SUNMARY, NOSIThIMARY XD

MODELTYPE TARGET XE

NEWINDEX TITLE XL

NOPRINT TMAX XN

NUMBER TSTART XU

Q TTY, TTYKILL YMAX

R TTY1,...,TTY5 ZD

Data Dump File Manipulations by Satellite Programs 97

Satellite Program *F2PLOT 97

Satellite Program *TRANSFER 98

Satellite Program *F2DPRNT 99

REFERENCES 101

APPENDIX (each appendix is modularly paged)

Al. Error Messages

All. Three Examples

FLEXFORNS, Sample Programs and Runs

Alil. *FLEX3 User Notes

AIV. User Feedback Sheet LIST OF FIGURES

Page

1 Representation of the FLEX Algorithm 10

2. Representation of Hierarchically Stacked Modules 12

3 The Dual Behavioral and Mechanistic Forms 12

Conceptual and Algorithmic Structures of the Mechanistic Form 12

Representation of the FLEX/REFLEX Algorithm 16

Detail of Module Stacking

An Example of Hierarchical Model Structure

FLEXFORN

An Overview FLEX2 Operating System 36 1

I. The FLEX Paradigm

Introduction

One of the basic postulates of current ecological research Is that the methods and theory of systems (systems analysis and general systems theory) can contribute to the investigation of ecosystem processes and the expression of ecosystem generalizations. The FLEX paradigm results from the adaptation of a particular general system theory to the general paradigm of ecosystem modelling Emphasis is on the total system as a coupled collection of subsystems, with specific attention paid to the holistic system properties.

These efforts are developed in the perspective that modelling is the imposition of form and structure on knowledge, hence that modelling is an integral part of the scientific process. The forms and structures which are used in ecosystem models will be the source of the concepts and expressions of the emerging theory, It follows that our attempts to develop a general model form for ecosystems is an attempt to develop a conceptual structure for ecosystem theory and that our proposed paradigm for ecosystem models is a proposed contribution to the general paradigm of ecosystems. The papers by Overton (1972 and 1973) are devoted to this perspective and to the emerging paradigm.

The word paradigm is used in thesense of Kuhn (1962) to represent the relevant body of theoretical and conceptual structures The pro- posed paradigm embraces the currently prevailing ecosystem model structures so far as we have been able to determine. If model forms are needed or desired which are difficult or impossible to express within the paradigm, then the paradigm needs revision.The evolutthn of the paradigm is also the evolution of that part of ecosystem theory which it represents.

The paradigm has evolved in a climate which recognizes the several activities which depend on models and modelling and the several necessary features of good scientific model development:

Communication: a, Working models must be readily communicable

among modellers and scientists. b. Communication among

scientists is one of the primary futitions of models

Criticism: Models must be subjected to the same rigorous

criticism and scientific scrutiny as any other scientific

product Therefore models must be prepared and reported in a

way that facilitates criticism

3 Comparison The comparative study of ecosystems requires the

comparative study of ecosystem models Development of families

of models within which comparisons are facilitated is an

activity of model synthesis.

4 Scientific Validity Models must be consistent with current

ecosystem theory, or the areas of inconsistency must be fully

exposed to recognition and study

5 Theory The model structures become part of the scientific

paradigm, and hence must be meaningful, fruitful, simple, and

elegant

6 Transparency The requirements of communication and criticism,

in particular, require that a model be exposed to view, without

laborious removal of extraneous material. Progress in all of these aspects is substantially implemented by

establishment of a convention for model structure and description. The

FLEX convention is sixply a labeling scheme for the paradigm. Any set

of notations and definitions which reflect thesame structure and form

would represent the same paradigm, and translation ofa model written

in such a convention into the FLEX convention would require only

identification of the isomorphisms. Such translation, however, is a

convenient way to catalog the features of a model, to determine if it

actually lies within the existing paradigm and to identify missing

components in the model description.

This translation is also a convenient way to reduce two models of

the same process or system to a common base, and so identify the simi-

larities and distinctions between them, This is an old modelling device--

putting apparently diverse specific model forms into a more general model form such that the differences are parametrically or structurally

identified. This process is also the basis of the comparative study of any set of diverse systems, and its implementation is a necessary prelude

to the formal comparative study of ecosystems.

The FLEX/REFLEX algorithm is the expression of the paradigm as a sequence of logical and mathematical operations using the notation established by the convention. This algorithm serves as the basis for

the computer realized processor. Such a processor is simply a general program which makes the routine manipulations specified by the algorithm

in a simulation run.

The user translates his model into the algorithm, using the conven-

tion to identify the parts of the general structure being used and their 4

particular form. This process is aided by use of FLEXFOEM, our

standard form for model specification This information is then put

to the processor to make a simulationrun The processor can "process't

any model which can be expressed in the paradigm, allowing the

implementation of a model with minimaltime and effort The modeller

has more time to think about the modelhe has built, or exercise it, or build another one

However, it is important to note thatone can use the convention and paradigm without using theprocessor. Translation of the model iNpiemented in another convention into FLEX,or initial model development in FLEX, accomplishes many of the advantages of the general form,and one can write specific code if the processoris not available, or for whatever reason.

Paradigm Development

R B Fuller (1965) has discussed thenecessity for starting from as general a viewpoint of a problem &s possible, delineating and avoid- ing micro and macro irrelevancies, and elaborating thestatemet of the problem at the appropriate resolutionas the first approximation toward solution (implying the view thata problem properly stated is a problem conceptually solved) developing the FLEX paradigm.

Our approach was to start from the generalsystem theory which we felt would fill the needs ofecosystem modeling and adapt this into a general ecosystem paradigm To implement this, we atteripted to identify properties and constraints of ecosystem models andthen identify a general systems theory which could accomodate those constraints and properties. In practice, the process was not quite so sequential;

Klir's theory was early identified as being compatible with ecosystem modelling needs. Continued exposure reinforced both the validity of his theory and the necessary hierarchical nature of ecosystem models.

The perspective begins with the system point of view; the system has properties some of which are not recognizable as properties of its parts, but which emerge from the system structure. Because of this, parts studied only in isolation are incompletely studied; they must also be studied in the context of the whole system. Further, the manner in which the parts are coupled becomes an integral part of the system, and specification of the couplings, an integral part of specification of the parts.

This view leads to a duality of approaches to system modelling, that of composition and decomposition or synthesis and analysis. The compo- sition approach is to model the behavior of each part and then couple the parts together to form a model of the whole. The decomposition approach is to model the behavior of the whole system and then to decompose the behavior into perceived subsystems or parts. In this approach an explicit whole system model is developed prior to decompo- sition into explicit parts. In composition, one strives to replace the coupled parts with a simplified whole system model.

Recognition of necessity for whole system models, encompassing the system's emergent properties, is not universal. Many investigators hold that parts, properly coupled, will yield the correct whole system behavior. It is true that the holistic properties emerge from the nature 6

of the couplings. But it would seem difficult, if not impossible,to

properly model couplings in the absence ofan explicitly described

holistic system behavior.

Thus we perceive the need fora theory of the ecosystem as an

object. Ecosystems are self-organizing, resilient assemblages of

organisms in interaction with each other andtheir environment.

Ecosystem research must attempt to elaborateconcepts of holistic

behavior Adoption of a model paradigm which identifies holistic

behavior is a step toward this end.

This does not exclude the need for explanationof system behavior.

Explanation traditionally implies descriptionof behavior in terms of the

recognized behavior at the next lower level oforganization, which

description we will classifyas mechanistic In association with the

holistic model, we must constructmechanistic models of how the system

works, based on the best current theory. Behavioral analysis will

reveal the components of the model to whichthe critical behaviors are

the most sensitive and fieldexperiments can then be designed to study

the critical components. Behavioral analysis will also help define the

system's limits of homeostasis.

Thus the first major element ofour paradigm is the stipulation that each ecosystem must be conceptualized and modelledin two ways, 1) holistically, with the system viewedas an object, and 2) mechanistically, with the system viewedas a coupled collection of subsystems, each of which is viewed and modelled holistically The two model forms lead naturally to a hierarchical modelstructure, in that each system or subsystem will be considereda holon, in the terminology of Arthur 7

Koestler (1967). Each system will be (potentially) a subsystem in a

larger system while simultaneously having the capacity of being

represented as a coupled collection of subsystems.

There is an increasing awareness of the advantages of hierarchical

structures in large systems models, and even an argument that real

complex systems must be structured in some such manner (Simon, 1962,

1963). If these arguments are valid, then the search for structure, in

the form of identified near decompositions, or subsystems, must

constitute a major part of the modelling effort, The conceptualization

of meaningful subsystems and subsequent identification of their holistic properties and behaviors are areas in which modellers and models can

contribute to the development of ecosystem theory.

In summary, the identified paradigm constraints are 1) the system model will be hierarchical, and 2) each system will be modelled at two

levels, holistically and mechanistically. *FLEX2 is a general processor which will accomodate this structure. A model module can be either a

FLEX or a REFLEX module, representing either a single level or terminal module, or a ghost module.

Outline of the FLEX Paradigm

The General System Theory of George Klir (1969) seemed to satisfy

the requirements of and provide the structure specified by our theoretical appraisal of the ecosystem modelling problem. The papers by Overton

(1972 and 1973) describe in some detail the development of a general

ecosystem model structure according to Klir's general theory.

Of Klir's five alternate definitions of systems, two form the

foundation of our FLEX Paradigm. The system may be defined, According to its permanent behavior. That is, by a time

invariant relation between the output quantities, on the

one hand, and the rest of the principal quantities, on

the other.

According to its Universe-Coupling (U-C) structure. That

is, as a set of elements (sub-systems), each defined

according to its permanent behavior, and a set of directed

couplings between the elements and between the elements

and the environment.

We refer to these as the holistic and mechanistic model forms,

and explicate them by the FLEX and REFLEX modes of the computational

algorithm.

The concept of principal quantities is a unique feature of Klir's

theory. Klir does not recognize state variables, per se, but rather

input and output variables, plus certain past values of input and

output variables, these collectively comprising the principal vari-

ables. In the FLEX paradigm, we use the state variable designation for

an economical representation of the instantaneous values of the system

outputs, and explicitly identify memory variables as past values of

these variables or of inputs Output variables are then identified as

functions of the state variables The more conventional state variable definition would lump our state andmemory variables together Economy and the conceptual advantage of explicit identification of past values of instantaneous variables justify these modifications inour view.

The general theory is further explicated in our paradigmas an eçpiicit time invariant relation between the instantaneous state variables 9

and the rest of the principalvariables. The form of the relation is

restricted to differenceor differential equations. This must be

consistent within a module butmay vary among modules, as module

couplings are essentially discrete.

Each system or subsystem in theconceptual model is represented by

a module in the realized computer model. A module may be either of the

two types according to which definitionis applied to the system.

Rowever, each module is processedaccording to a modification of Klir's general paradigm of sequentialsystems (Fig. 4.8, Klir, 1969). This has been modified slightly, elaborated,and is presented as Figure 1, for

FLEX modules. (The algorithm is greatly elaboratedin Section ii to accomodate both modes of thesystem definitions.)

Referring to Figure 1, itcan be seen that we do not identify the principal quantities,per se, but rather maintain the identity of input (z), and output (y) variables,with the additional specification of memory variables (M), whichcan include past values of input or state variables. State (x) variables are defined for structuraleconomy and convenience; they are often identicalto output variables, although they also include internal variables.

M, z, and x variables alongwith two parameter vectors, b and r, are available for use by the functions ofthe functional generator.

We have explicated the time invariantrelation referred to in the system definitions as a differenceequation. This does not exclude the use of differential equationssince the algorithm provides for explicit Euler solution. If the model equations are conceptualized as differential equations, then the solutionis an Euler approximation, 10

I I

I I

IFunctional Memory Generator M

L___ - - y(k+j) 0. TheGeneral Paradigm as modified

z(k)

k

k.-.k,l tki-1 I k. AI

L J (k+) b. Elaboration of the Functional Generator

{mz (k)mz(k-j)...mz(k-r) L'!i (k)i(k_i)..n(k_r)

!!i(kq)-m(k-q-1)

C Elaboration of the Memory

Figure 1. Schematic representation of the FLEX algorithm of the general paradigm of sequential systems as modified and explicated from Klir (1969). 11

and a reduced step may be used to obtain a better approximation. If the equations are conceptualized as difference equations, then the solution is exact in whatever time resolution modelled.

Updated x variables are returned to storage. Along with the z's, they are transferred to Memory. The x variables are also filtered by the H filter to produce the output y quantities, Updating of the memory finishes processing.

In accordance with the systems view that a subsystem must be studied in the context of the system of which it is a part, we anticipate that a specific question regarding ecosystem activities or behavior will be answered by simulation of a model structured something as illustrated in Figure 2. The zero subscripts indicate ghost systems controlling the systems at the next lower echelon, and the question to be answered applies specifically to one of the lowest echelon subsystems. Note that each subsystem or group of coupled subsystems in the structure can be studied in isolation with regard to its behavior, or be tuned in isolation to yield the desired behavior. After each is tuned to satisfaction, the subsystems can be appropriately coupled to study behavior of any part in the context of the whole.

Figure 3 illustrates the relationship between forms in our explication of the dual module definition, Terminal subsystems, which are defined by the FLEX algorithm, represent the special case of

Klir's definition according to behavior. Such a module is processed as outlined above.

Hierarchical structure is provided by the REFLEX algorithm, which

is an explication of the definition according to IJ-C structure. Each 12

Figure 2. Schematic representation of hierarchically stacked modules. Those represented by (0) are REFLEX (Ghost) modules, others are FLEX (terminal) modules.

\ / 5(y, ZxM) s=(S1, S2, S3, C)

Figure 3. The system is simultaneously represented by a holistic model form and a mechanistic model form.

CONCEPTUAL ALGORITHMIC STRUCTURE STRUCTURE

Figure 4. The mechanistic model form is conceptualized as a set of coupled subsystems. Its algorithm requires a change, all couplings passing through the ghost system. 13

proper subsystem (i.e., identified in the conceptual structure, Figure4) in REFLEX is modelled according to FLEX or to REFLEX. The ghost system or module, S0, is the integrator of the outputs and provider of inputs for its proper subsystems S0 contains all features of S except the £ functions, which are replaced by the subsystems. The directed couplings between two systems Si and S. are the set of output variables of S which are inputs of S., (See Figure 4)

Since the universe coupling structure provides a finer resolution model than the holistic behavior, the temporal resolution of the proper subsystems will be an integral fraction of the temporal resolution of

S. Each U-C system model will have a resolution parameter, q, which specifies the number of time steps in the subsystems for each step in the whole system. will operate at both resolutions; it will be updated by the subsystems at their resolution and receive outside inputs and send outside outputs according to the resolution of S. Note also that the model of a particular system according to either of these forms will involve exactly the same specification of system inputs and outputs and the same resolution. Thus one form may be substituted for the other without external change, this feature provides the modularity desired

The management of all subsystem coupling through the ghost

system serves two purposes. First, it eliminates the need for rigid

sequential processing of subsystems, since in the present form order of

subsystem processing is immaterial Second, it provides for simultan-

eous regulation of flow relations by both donor and receiver elewents 15

II. The FLEX/REFLEX Algorithm

Introduction

The algorithm will be discussedin two parts. The first part

will detail the execution of thealgorithm on one module. The differ-

ence between the FLEX and REFLEX parts of the algorithmwill be

described. The second part will focuson the linking of modules to

form a hierarchical model and howthe processing is executed on such

an assemblage.

Internal Module Processing

A module is shown in detail inFigure 5. The module ellipse is

broken in half by a dashed lineto 'indicate a difference in processing

levels The higher level filtersinputs and outputs for the entire

module. It operates at thesame time resolution as the other modules which share a common ghost. The lower level does the actual updating

of the variables, in thecase of FLEX, or controls subsystem processing which updates the variables,in the case of REFLEX.

The following elaborated algorithmdescription discusses in detail the logico-mathematicalprocess which is applied to each module. After that a summary of module processingis given., Figure 5. the FLEX paradigm of hierarchical systems. Schematic representation of the FLEX/REFLEX algorithm of \ 17

Higher Level Processing

In Figure 5, the passing of control is shown as a dashed line, the passing of numerical values is shown as a solid line, variable storage is shown as boxes, functions and logical operations as circles. The ZCOMP and YCOMP elipses denote a special type of function filter.

If the module is operating alone (i.e., a single module model), then ZCOMP calculates or reads from data files the values of z. If operating with other modules, control is passed to ZCOMP from another module and values of z are filtered in from ghost (using VARIN),calcu- lated or read from data files.

ZCOMP can use discrete time k, the values of z(k) and M(k) (the memory being past values of z and x). The b and r parameters may also be used, as may previously calculated z values and special functions,

Special functions will appear throughout the module description.

They are simply user-defined subroutines or functions which may be utilized to simplify the programming of those functions which are part of the module. Thus a special function could be used to read data in from a file, or could be used to do linear interpolation, or to remove the need to duplicate coding in g functions.

From ZCOMP control is passed to F1. Here a call is made to

TESTCOMP, which tests user-defined conditions to decide if module processing is to be completed. This provides for event oriented models,

If TESTCOMP returns with a value of one, the module is run; if it returns with a value of zero, control is transferred to the next module. If

TESTCONP is not included, the module will be run. TESTCOMP may be a 18

function of time k, the principal quantities, the b andr parameters, and the special functions.

Relationship Between Higher and Lower Level Processing

Control is passed next to the g functions, Before continuing, note that control is passing from higher level processing to lower level processing. Since lower level processing is concerned with updating x values which are stored in the boxes which stradle the horizontal line on the right in Figure 5, we need a few definitions.

Time for the module is k. k is incremented by one each time a circuit of higher level processing is completed. As noted previously, however, the lower level is processedq times in this interval. k' is used as the time index for lower level processing. It is incremented by one each time a circuit of lower level processingis completed

Although all x values are usually determined by lower level processing, it is sometimes much more convenient to determine them only once during a module cycle and so a way of updating them with a higher level process is provided through the h functions Therefore, x is split conceptually into two subvectors and

Double subscripting of time must be provided for the lower level vector.

Since the double subscript is irrelevant for we replace it with a zero, 19

Thus

x(k) = x(k,O) Ls''°J

During lower level processing we define

x(k,k')=[:1 which indicates that values are not altered during this time. h When we return to higher level processing we have x(k,q) and

After updating we then have h

[(k±lo)j x(k+l) =

We may conceptualize this, in terms of Figure 5, as redefining the x,(k,k'+l) box and transforming it into the x(k,k') box once during each circuit of the lower level processor, whereas x.is updated only once and that is during higher level processing

As a final note, the x vector is not partitioned explicitly,but rather implicitly by the manner of updating. Identityof a vector component which belongs to xh is designated by including an hfunction with the same subscript as the component. Thus, existence of h6 defines

Similarly the inclusion of any f or f or f designates that x6exh. ip p1 pp

xEx An x. may be an element of both vectors, so it can obtain an 1 20

adjusted value based on itsown updated value. Care must be exercised

when using this option. (See the discussion of h functions inSection

III.)

Lower Level Processing

We now return to the point at whichF1 passes control to g, The

g functions are intermediate functions whichare useful in a number

of ways. They may be employed asprocess functions in order to simplify

the definition of the f functions. They may also be used as internal

coupling variables, if the moduleis a REFLEX type, in order to simplify

the computation done in other modules. The g functions' values are stored

through a computation cycle. A function may use as function arguments

any other already defined g values,as well as parameter values, time,

principal quantities ands.

Control now passes to F2. Module type is tested. If the module is

a FLEX module, control passes to the f functions. This type of

module will update thex variables by calculating "fluxes" between them

If the module is a REFLEX type,control passes to F0 which cycles each

of the ghost's subsystems The subsystems couple with each other by updating the values of xin ghost We will continue with the description of the processing of theterminal type until its processing again coincides with the REFLEX type In the section on module linkage we will return to F0 in ghost.

As mentioned above, f functionsrepresent fluxes between the

Thus f.. is the discrete flux fromx tox. This provides for easy iJ 1 implementation of the popular and usefulcompartment type models, 21

The f functions thus form a matrix of functions which describe the fluxes among the vector components of x. To simplify the structure, we do not use an f0. or f.0 to implement environmental couplings, but rather combine them into a net effect, f... In essence f.. is used to affect the 11 11 value of x only. All f.,. fluxes may be collapsed into the diagonal f.. 1 1J 11 elements. This arrangement is used in differential equations models.

F functions have as their arguments the principal quantities, the b and r parameters, g, s, and time k.

Control is passed to F3 which executes the discrete equation

algorithm. Fluxes into and out of each x. are combined into a single

discrete increment. This increment, representing the net change in

x1 from all fluxes, is stored in i(k,k'), This increment is the

adjusted flux which occurs over the time span of l/q.

F4 next assumes control. It does the actual updating for

Thus, it executes the replacement

x0(k,kt+l) = XQ(k,k) + L(k,k')

At F5, control is reintegrated for both FLEX and REFLEX modules.

In both modules x(k,k'+l) has been stored, either as a result of net

flux calculations or as a result of finer resolution subsystem calcu-

lations. Time is advanced from k,k' to k,k+l and x values are

transferred from x(k,kT+l) to x(k,k'). If k' is still less than q

then the cycle is repeated and control is returned to g. If, however,

k'=q then lower level processing is completed and control is passed to

F6 to resume higher level processing. 22

Finishing Higher Level Processing

F makes calls to the h. functions which have been defined. For 6 i each h. which is defined, the value of xicxh(k+l,o) is reset to the value of h.(k). The h's may be functions of k, the principal quantities, parameters and s. They may also use the values of x(k,q) = x(k+l,O), that is, the updated values of the lower level x's. The x,(k+l,O) values are identified as xs (Refer to h function discussion in Section III)

Control is passed to F7. With x(k+l) now calculated all that remains is to update time from k to k+I. One time step is said to have elapsed. Simultaneously all variables are redefined so that the value of x(k+1) replaces the value of x(k) and so on. After the general redefining of variable values, control is passed to YCOMP.

YCOMP is the output filter. If this is the highest ghost in a hierarchical model, or if this module is a terminal running in isolation, or if this module is producing some other observed variables, then YCOMP calculates the values of these variables and outputs them In the case of a terminal module which is a subsystem of a ghost, YCOMP also calculates the values of the coupling variables and transfers them (using VAROUT) to their appropriate storage area in the ghost module The y outputs thus transferred provide the updated values for x(k,k'+l) in the ghost module. As in the FLEX module, y output values may also go to the monitor, line' printer or dump file. 23

Nodule Couplings and External Processing

To place in context the interrelation of ZCOMP, YCOMP and F0, refer to Figure 6. Here each module's internal structure is shown in simplified detail. The ZCONP and YCOMP filters are separated by the principal variables (PV), which include the principal quantities, and the lower level processing ellipse which contains internal variables

(IV) such as g and f functions. A ghost F0 passes control to its subsystem's ZCONP and receives control back from its subsystem's YCOMP.

Inside a subsystem module control is retained by the subsystem module or passed to even lower subsystems. In addition, at each level each module may access external input files and create external output files (F). Overall control is exercised by the run processor (RP).

Control is finally passed back again, sooner or later, to the top ghost in the assemblage. From ghost's YCONP, control returns to the

FLEX2 processor control level which checks time in order to terminate the simulation run if time is equal to the maximum value set.

Time, resolution ratio and their relations to the constructed hierarchy need elaboration. In terms of Figure 6, the ellipse containing IV (the internal variables) cycles q times for each time the module is entered for a terminal module, and subsystems are called q times each for each ghost module. If SO has q3, then Sand S2 would be called three times for each increment of k in S0. S and S2 are on the same level in the hierarchy since they have a common ghost immediately superior to them. They may have different internal q values, so that each cycles through their lower level a different number of times. Thus while their higher levels are synchronized by their 24

Figure 6. Detail of module stacking. The run processor (RP) initial- izes all system variables and controlsa run. Control is passed to the highest module, whichpasses control to its subsystems, which in turn pass controlto subsystems at lower levels. Solid lines indicate variable couplings,the dashed lines control flows. 25

common ghost system, the lower levels may. be used to place each submodule on a different time resolution, either conceptually or operationally.

The memory of each module resides in the higher level. This has profound implications for memory storage. If finer resolution memory is needed, subsystems must be defined to implement this storage.

Notes on Total Model Assembly

Figure 2 shows a schematic design of modules assembled into a hierarchical model. The hierarchical tree may have as many subbranches as desired. However the purpose of the paradigm is to reduce the problem of detail and complexity which are encountered when implementing large scale ecosystem models. The basic principle is to limit side branches to no more than one level (one REFLEX representation) and to fully develop only the main branch of interest down to the finest level of detail. Potential sidebranches should be represented by their holistic models at the appropriate resolution level. The main branch of interest terminates at the target subsystem module, which is the sub- system currently the subject of research. A REFLEX representation of no more than one level may be used for the target subsystem.

Many processes represented in the total model will be represented by very coarse models. These modules influence the target subsystem only infrequently and on a 'strategic' level. Such influence is further moderated and controlled by intermediary systems. Thus, the holistic model form is appropriate. As the level of the target module is approached the subsystems which interact more directly are represented 26

S... Watershed ecosystem E Environment Terrestrial ecosystem S2 Aquatic ecosystem S11 Hydrology system S12 Primary Producer system S13 Consumer and Decomposersystem S14 Nutrient Interchange and Uptake system sill Above Ground subsystem Si12 Below Ground subsystem sill1 Meterological Input subsystem sill2 Canopy subsystem Sill3 Snowpack subsystem sill4 Litter Layer subsystem xl Fast evaporative canopy storage component Slow evaporative canopy storage component x3 Unsatisfied atmospheric moisture demand x4 Thruf all x5 .... Canopy evaporation zl Precipitation z2 Atmospheric moisture demand y3... x3 x4 x5

Figure 7. An example of hierarchic model structure. The system S couples with its environment, and is elaborated as a complex of two subsystems, S1 and S1 is elaborated in terms of four subsystems, Sjj in terms of two,5EU as a system of four subsystems and finally, 1l12is modelled in the FLEX mode Each path must terminate in this mode, but termination may occur at any level. 27

by finer resolution models.' We do not model any process at a finer level of resolution. than that needed to characterize its pertinent behavior for, the question asked,

As an example let us consider Figure 7 which shows the hierarchical structure constructed to ask detailed questions about water dynamics on the exterior crown of an old growth forest. Because water dynamics are studied we need a model of water movement more detailed than the model of primary production or nutrient interchange and uptake. Further, the model of the below ground hydrological subsystem need not be as elaborate as the model of the above ground hydrological subsystem.

We can also see in this diagram why we might want a more detailed model of primary production than a simple holistic one. Since the mechanics of water on the surfaces of tree crowns is dependent on many aspects of the dynamics of tree crowns, we might wish to expand the primary production subsystem to a finer level. Sometimes a holistic

representation of any side branch will be replaced with a mechanistic

representation one hierarchical level deep, but we anticipate that a

second level is seldom, if ever, needed.

The more detailed structures for side branches are used, the more

expensive the overall run will be. The entire object of this approach

is to develop holistic models which have the desired behavior so that

more detailed models are unnecessary for the current question of

interest.

Modeler/Programmer Communication -- The FLEXFORN

One of the objects of the FLEX/REFLEX paradigm is to delimit and 28

separate the functions of modeling and programming. By modeling we mean the theoretical and technical operations of conceptual model construction, including decisions on overall model structure, each subsystem's structure, actual equation forms and parameter values used.

By programming we mean the more or less technical job of implementing a model on a computer and conducting requested numerical solutions of that model. This includes all actual programming duties.

During behavioral studies of the model, the modeler will frequently run the model on the computer. In addition either the modeler or the prograiluiler may be responsible for displaying model output in the desired form (plots, tables, etc.). In total, however, we may delimit modeling responsibilities from programming responsibilities by saying that the modeler must construct the conceptual model and the programmer must implement that model on FLEX2.

The major communications device between the modeler and programmer is the FLEXFORN. A schematic diagram of this form is given as Figure 8.

Examples using the FLEXFORM are included as Appendix II.

The FLEXFORM is a working document so it changes form as we accumulate experience with its use. The form, Figure 8, differs slightly from the older forms included in Appendix II and will undoubtedly change again. Figure 8 is offered as the most useful form which we have used so far.

The FLEXFO1N is a working document in another sense as well: it serves as complete, succinct documentation of the conceptual model in the language of the FLEX/REFLEX convention. Anyone familiar with the convention can understand the model presented with the FLEXFOPN. Com- pletion of the form essentially completes the conceptual model. 29

FLEXFORM FLEX (or REFLEX)

MODULE NUMBER AND TITLE

INVESTIGATOR(S) AND DATE

TIME RESOLUTION

QUANTITY MODELED

DIAGRAM

VARIABLES AND FUNCTIONS

X List Description H Functions Description

-- identification of -- higher level functions -- state variables --

Z Functions Description Y Functions Description

specification and -- output variables -- identification of input variables -- S Functions Description

M List special-use functions --

-- specifications of x and TESTCOMP function if desired z variables retained as memory variables --

G Functions Description PARAMETERS and Figure

- intermediate functions -- B Parameters: list, descrip- t ion and values.

5. F Functions Description R Parameters: list,descrip- t ionand values. -- flux functions -- Initial Conditions: list, des- --OR-- cription, and values.

5. Subsystem List

-- in order of processing also include list of all coupling variables --

Figure 8 30

FLEXFORN

Page 2 of 2

GENERAL RUN INFORMATION

TSTART =

TMAX =

Variables to be monitored: Monitor time frequency:

Variables to be line printed: LP Time frequency:

Variables to be dump filed: Dump tile time frequency:

SATELLITE PROGRAM INFORMATION

Variables to be plotted: Plot time frequency:

CONMENTS

DESCRIPTION OF BEHAVIOR

RUN LOG

Figure 8 continued 31

TheFLEX/REFLEXAlgorithm A Summary

Control level:

Control Processor: This control processor is the first operation of a run. It transfers control to and accepts control from the highest ghost system in the model. The values of y are produced and all variables 0 are initialized for each module immediately upon entering that module for the first time during that simulation run.

F0: This is the conceptual external module controller which passes control from theREFLEXmodule to each direct subsystem. It is inactive in aFLEXmodule. In the Control Processor, F0 keeps track of TNAX and k, and stops the run when completed. In theREFLEXModule, F0 sends control sequentially to all subsystems under the control of the particular module, each of which returns control to F0 on completion of a cycle. After all subsystems have been run, F0 then sends control toF5. It is emphasized that F0 is conceptual. Its processor implementation is not as part of the module.

Module level:

1) ZCOMP: Filter, transform and store inputs in principal variables.

z(k) = zAk, x(k), M(k),s, b, r, z.(k)}, j

F1: Decide whether or not to run module (submodel

TEST(k) = TEST {k, z(k), x(k), M(k), s, b, r}

= u No run, exit back to F0 in ghost.

= 1 Run, proceed. 32

3) Enter lower level processing. Set k' =

Define:

x(k) = x(k,O)=r(k =r(k,o) [X(k)J Loc,o)

=rXh(k,O)1

- Lxk,k')J x(k+l)=r(k+1,o)1L'" J=r(k+l) g: Calculate, store intermediateg functions.

g.(k,k') = g.{k,k', z(k), x(k), x(k,k'), N(k),s, b, r, g.(k,k')},

j

If FLEX (terminal), turn controlover to f.

If REFLEX, turn controlover to F0, the external module control,

for subsystem cycling. Bypass f, F3 and F.

Calculate and store flux values. Flux from x. to x. is f... 1 3 13 f.. (k,k') = f..{k,k', z(k), x(k), x(k,k'), M(k),g(k,k'), s, b, r}

Calculate, store L(k,k') values.

= f.(k,k') - i=l j=l j#r

F: Calculate and store x0(k,k'+l) values usingxk,kt) and

x(k,k'+l) = +

F5 Replace x9,(k,k') withx(k,k'+l). Increment k' by 1. If

k'

(Return to F5 when F0 has control returned from subsystems.) 33 10) F6: From x(k) and x(k,q) generate the values of x.(k+l,0).

xh(k+l,O) = h {k z(k), x(k), x(k,q), M(k), s, b, r}

11) F7: a) Replace x(k) with x(k+l).

Update memory variables. Replace inx(k-r) with mx(k+l-r)

and replace rnz(k-r) with rnz(k+l-r)

Increment k by one. (Replace k+1 with k.)

12) Filter, print outputs.

y.(k) = y.{k, x(k), M(k), s, b, r, y.(k)}, j

13) Return control to F, the external module control, at the next higher

hierarchical level.

Additional definitions:

b, r: The vectors of model parameters which may change from run to

run.

s: Special functions, similar to g functions, which are available

on call and for which the values are not stored by the pro-

ces ser:

5.= s.{k, z(k), x(k), M(k), b, r, s.}, j

and s. cannot be a function of z(k) until z(k) is defined.

q: The resolution ratio. If R0 is the resolution level of a

ghost module and R1 is the resolution level of its subsystem

modules, then q R0 may also be identified as the

resolution level of the higher processor and R1 as the re-

solution level of the lower processor. This means that the

resolution level of the lower level in ghost and the higher

level in each direct subsystem must be identical. Differing

iesolutions nong the ghosts subsystems is handled with the

subsystem q's 35

III. PROGRM1NING IN FLEX2

Introduction

Programming a FLEX2 run involves translating the modeller's information (FLEXFORN, Figure 8) into specific computer commands and formats. If the FLEXFORN sheet is filled in completely, the programmer should have all the information necessary for this translation. FLEX2 is partially FORTRA1T based and programming FLEX2 demands the ability to write

FORTRAN equations. In addition, knowledge of the use of OS-3 (Oregon

State Open Shop Operating System) is necessary, as FLEX2 was written exclusively for this interactive time-sharing system. Information on

OS-3 may be obtained from the OSU Computer Center and a list of relevant materials are listed in the bibliography.

Overview

An overview of the FLEX2 system may be obtained by consulting

Figure 9. This figure illustrates the structural aspects of the

FLEX2 system within the larger structure of the OS-3 system. In addition, the upper portion of this figure is a diagrammatic outline of the steps necessary to program a model for FLEX2. The details of this process are listed in the section Programming Details. An outline of the steps follows.

Translate the model functions into FORTRAN code. The z, g, f, h, and y functions have a standardized format given below. S functions follow the general FORTRAN language format. Generate a function source file for each of the six types of functions, using the OS-3 EDITOR.

Source listings and backup card decks are usually made. Compile each 36

Equations OS-3 packages OS-3 Disk Files OS-3 Coded / Source Function Source Listing Files of Function Editor G,F,H,Y,S Input Equations / ( Binary Object Source Decks Back-up Compile \Z,G,F,H,Y,S Instructions Fortran Card Deck Compiler FLEX2 System Function Command Overlay Files *F2LO Coded ( overlay Online made Interaction Editor Command Input Files Files

( input or *FLg)(2 Online riving Data1 eneral Model Interaction Necessar' Processor Teletype (DataDump \ Monitor File \ \ (Binar ) Line Printer Dump File Listing Requests *F2PLOT Plotting Routine Line Printer an Teletype Plots Dump File Manipulations *F2DPFJ Listing Data Dump Routine File Listing

*TR.#JSFER Plot Interactior BCD Data Data Selection *GFJJ'IT \Duinp File Routine CALCOMP Plots >I,w

Figure 9. An Overview FLEX2 OperatingSystem 37

source file, using the OS-3 FORTRMJ compiler. Use *F2LOAD, pert of the

FLEX2 system, to incorporate all the resultant binary object files into a function overlay which is stored on a disk file under a user-specified name.

The foregoing procedure is repeated for all modules in the model.

Each module will have its own function overlay. When the function overlays are complete, the model is ready for a simulation run.

Programming Details

A. Coding the Model Functions. We are concerned with the z functions, g functions, f functions, h functions, y functions and s functions from FLEXFORN. Although we have been calling them functions, the correct mathematical terminology, they include both subroutines and functions in computer terminology. We will explain these in order. 38

Z Functions

The number of z or input values is limitedto 40. All zvalues

are computed in one subroutine The standard format is

SUBROUTINE ZCOMP (K, X, B, R, Z, TO, T, G) DIMENSION X(l), B(l), R(l), Z(l), G(l)

Z(l) = expression

Z(2) = expression

Calculation of z values

Z() = expression

RETURN

END

The expression may be aconstant,or a time.-varying algebraic

function, or a table look-up Input data are most often read from disk

data files in an s function called by thez function

In subsystems, z functions will usually be usedto filter

information into that subsystem from its ghost This is done by using an internal FLEX2 subroutine named VARIN If, for example, we wish z2

to be assigned the value of g1 in ghost,we would replace

Z(2) = expression in ZCOMF with

CALLVARIN ( Z(2),G(l) )

This automatically sets z2 = g1 in ghost, Variables which may be coupled to directly (i.e. which may appear as the second element in 39

the calling string of VARIN)are z's, g's, and x's in ghost. Ghost memory variables should be accessed throughz or g functions in ghost.

Z values are calculated first by FLEX2. The values are stored internally in that module andmay be used in other functions of that module by simply writing Z(l)or Z(Ol) for z1, etc. in the appropriate equations. The z values may be used byany other functions in the module except the y output functions. 40

The Test Function

The test function allows a modeller to havean event oriented subsystem within the model or even to have the entire model event oriented. The test function decides if this module will be processed during the current time step. Unless the event specified in TESTCOMP occurs, the module will not be processed further. The standard format is

SUBROUTINE TESTCOMP (K, X, B, R, Z, TEST)

DIMENSION X(l), B(l), R(l), Z(l)

Calculation of the value of TEST

TEST = expression

RETUR1'T

END

If TEST returns with a value of zero, then the computational cycle is terminated for the module for this time step. If a value of one is returned, then the computational cycle will be completed. If not included on the function overlay, that is, if the TESTCONP subroutine is not defined by the user, the value of TEST defaults to one

Use of the test function amounts to parameterizing the model structure at the subsystem (or module) level rather than as an internal structure of the subsystem. The calculation of the value of TEST is the second step in the FLEX2 computational cycle. 41

G Functions

The number of g functions is limited to 70. A separate FOPTRAN function is required for each g function. Each g function is coded in the standard format

FUNCTION GØ1(K, X, B,R, Z, KPRIME)

DIMENSION X(l), B(l), R(l), z(l)

Calculation ofthe value of

G01 = expression

RETURN

END

02, 03, , 70 may be substituted above for 01, two digits are required. The calculation of the returned value may be as long and complicated as desired. G functions are defined as intermediate functions; any internal variable which will be used extensively and which retains the same value throughout the k' time increment should be calculated as a g function. G functions may be used as a coupling variable for a single process, to simplify the f function representation for calculation of demands, or for logical operations.

G values are calculated fourth by FLEX2. All defined g functions will be calculated q times per module per computational cycle and the returned values stored internally. The value is available to the f functions or other subsequently calculated g functions or special functions by writing G(0l), G(O2), , G(7Ø) The use of parentheses is crucial and these must always be included 42

F Functions

There is a limit of 63 f functions. A separate FORTRAJT function is required for each defined f... The standard format, repeated for each f function, is as follows:

FUNCTION FØ1Ø1 (K, X, B, R, Z, KPPIME)

DIMENSION X(l), B(l), R(l), Z(l)

Calculation of the value of

FO1Ø1 = expression

RETURN

END

and where 02, 03, , 63 may be substituted for 01 (i e , FØ1Ø2,

F6363); four digits are required. The returned values are stored internally and will automatically be manipulated to calculate the update vector A(k,k') which will be added to the current state variable vector x2,(k,k') to obtain the next time step's state vector x(kk'+l) Please note that the f functions cannot be used to calculate other functions

If the value of one flow determines that of a second, the first value should be calculated as a g function and used in both f functions. A g function must be used with indices in parentheses (e g, FØ1O1 =

G(Ø5) )

The calculation of f values is the sixth step in the FLEX2 cycle,

Just prior to the calculation of the update vector and the new state variable vector. 43

H Functions

The number of h functions is limited to 63. A separate FORTRAN function is required for each h function. Each h function is coded in the standard format

FUNCTION HO1 (K, XS, B, R, Z)

DIMENSION xS(1), B(l), R(l), Z(l)

Calculation of the value of h1

HØ1 = expression

RETURN

END

02, 03,..., 63 may be substituted above for01;two digits are required. Remember that the index of the h1 function defines x1E that is, the x variable with the same index is an element of the higher level x vector. The function h. calculates the new value of x. for the 1 - 1 next time step k+l; it does not calculate an increment to be added to x.. 1 XS in the h function call string is used to remind the user that x is now the updated x vector xs Thus if x1E and ifXS(Ol) is used within a h function, then the value of x1 used is x1(k,q) or x1(k+1,O). However, if x1 c and xS(Øl) is used within a h function, h then the value of x1 used is x1(k,O). Values of x.(k,O) for all x. Ex may be obtained by using the XD (1,0) call to memory. The user should carefully review steps 8, 9 and 10 and the and definitions in the algorithm summary in Section II prior tousing h functions. 44

H values are calculated tenth by FLEX2. All defined h functions are calculated once per module per computational cycleand are not stored internally as h's (theyare stored as the new value of their respective x). It should be stressed that thex variables which have new values calculated by hfunctions do not assume those new values until the end of all h functioncomputation. H functions may not be functions of each other. They may be functions of g(k,q). 45

Y Functions

The number of y output values is limited to 50. Y values are calculated by a subroutine. The standard format is

SUBROUTINE YCOMP (K, X, B, R, Y, XS, T) DI}IENSION x(l), B(l), R(l), Y(l), Xs(l)

Y(l) = expression

Y(2) = expression

Calculation of y values

Y() = expression

RETURN

END

The expression for y.(k) may be a function of k, x(k), M(k), s, b, r, y.(k) for j

Y functions are utilized within the REFLEX structure as an output filter They send back to ghost those outputs which ghost needs These are sent back as the updated values of the corresponding x in ghost

(i e , x(k,k'+l) ) This is accomplished through the use of the internal FLEX2 subroutine named VAROUT If, for example, we wish x1 in ghost to be updated to the value of y3 in this subsystem, we would 46 insert after

Y(3) = expression the call

CALL VAROUT ( Y(3), xs(l) )

This automatically sets x1(k,k'+l) in ghost equal to the value ofy3.

Only XS() may appear as the second variable in the call string

(i.e., only x's may be updated), and only Y() may appear as the first variable (only y's may be used to update ghost x's).

The calculation of the y or output variables is the final step in the FLEX2 cycle. Before the y output is produced, time k is advanced to k+l. Thus the k discussed here is k+l with regard to the k in the preceding function descriptions. The first output y(0) is a translation of the initial conditions, x(0) and M(0), before the first

FLEX2 computation cycle begins. 47

S Functions

Special functions are included for further modeling and programming flexibility. They may be either functions or subroutines.

There is no limit to the number allowed except for the limit on the function overlay size which is 20,0008 (octal) words (see Section

III.B.).

There is no standardized FLEX2 format for the special functions; function and subroutine formats and restrictions listed in the C.D.C.

3300 FORTRAN manual apply. Special functions may not define unlabeled

COMMON area storage. S functions are functions of time k and k', state, input and memory variables, b and r parameters, previously defined g functions and other special functions only. Values of f and y functions may not be used.

Special functions may be used in calculating z values, g va1ues,

f values or values of other special functions. They are useful as

table look-up or data read-in functions, especially for z functions, where real environmental data are entered.

The s functions operate the same way with regard to FLEX2 and any

of its user-defined function sets as functions and subroutines operate with regard to a main FORTRAN program. The values are not stored

internally. A particular s value is recalculated each time it is

needed. No particular time in the FLEX2 computation cycle is assigned

to s functions. 4c3

B. Preparing a Function Overlay. After entering the coded

functions onto disi' files, debugging and coirpiling themin FOPTPAN,

riake the function overlay

While in OS-3 control mode, indicated bya # sign, type

*F2LO, ,..., (CR)

After *F2LOA]J, enter the names or luns of the FORTRAN binary

object files needed; these may include the ZCONP subroutine,g functions,

f functions, h functions, YCOMP subroutine ands functions. Separate

file names with a comma. The standardFORTRANlibrary is always

available. The use of a special library may be included by adding

= " after the last file name. The L parameter may be

included more than once. Type a carriage return (CR) to terminate the

line.

After reading in the userts binary object files, *F2LOAD will

respond by typing

ENTER LITh OFNAME FOR FUNCTION OVERLAY

Type in the name under which you wish tosave the function overlay

The use of a lun is also allowed

The pound sign (#) will be typed after the overlayis made File

protect all overlays Cuidelines are offered for file structure naming

in A Note on Naming Files and Overlays below

The name of the overlay or the lun used for storage will be used with the command FUNLOAD within the FLEX2 system. This name or lun must be entered correctly for the overlay to be loaded and used by

FLEX2.

There is a size limit of 20,0008 or819210 words on the overlay. 49

If too many functions are specified, either the structure must be reworked or part of the model deleted. *F2LO1J error messages are discussed in Appendix Section A.I. 50

A Note on Naming Files and Overlays

The translation of several models into FLEX2 has demonstrated the necessity for a file naming convention to keep the user andprogrammer from getting lost in a maze of file names The following convention has proved useful

First, construct a 3 to 5 alphanumeric character code for each module. Thus, for a litter decomposition model we might use LIDE.

This code will form the root names of our files.

Function file names for source decks are obtained by appending a

letter and number If this is the first Z subroutine, i e , the first of several options, use LIDEZ1 as its file name; if it is the fourth

Ffunction file of several alternate files,use LIDEF4, etc. G functions

become LIDEG , Special functions become LIDES_, and Y functions become

LIDEY

Compiled FORTRAN binary files are named with a * prefix. Source

FORTRAN files are named without a * prefix. Binary decks are public files so they may be used from a different job number. Backup card decks of the source files should always be maintained.

For the suffix of parameter files, use I, B, R, or N along with a number. Prefix these with a * so that they may be used from another job number. For example, *LI]DEI4, *LIDER3, *LIDEN12.

Function overlay names have an * prefix and a two digit (no letter) suffix. Thus *LIDEO1, *LIDEO2.

Data dump file names should have a * prefix and a suffix of D with a number, i.e., *LIDED1, *LIDED2. 51

Such a name structure carries with it implicitly the FLEX structure, allowing a simple mnemonic code with varying endings to stiuulate one's memory With a knowledge of the three to five letter code, a run may be made very quickly without consulting a long list of file names.

We strongly advise the user to file protect all files, especially public files (those whose name begins with a 53

IV. USING FLEX2

Introduction

The actual use of FLEX2may be divided into three parts. The

relationship of these partsis diagrammed in the lower portion of

Figure 9, An Overview FLEX2Operating System,

First, a variety of informationis input to the FLEX2 processor

This includes the overlaynames and various module and model structuring

commands. Such information may be entered lineby line or by using a previously constructed command file

Second, the actual simulation run(s)is (are) made. The FLEX2 computation cycle is repeated untila terminating condition is reached

(i e , time has reached its final value,a non-recoverable error has occurred, etc.). During the run, a monitor listing ofsome of the system's variables is possible, A complete line printer listing of the run is produced, if desired,and all output varables are duriped todfile

Third, the dumped data may be manipulatedto produce line printer or Calcomp plots. These plots, in addition to the line printedoutput, are helpful in understanding the behavior ofa modi. 54

Preliminaries

Before a call is made to FLEX2, the logical unit numbers (lun's)

for line printer and dump file output must be equipped1 Each module

must have its own line printer lun and dump file lun If output from

two or more modules is sent to the same lun, the intermingled output

will be difficult to identify on line printer listings and impossible

to use in satellite programs.

We equip all line printer and dump file luns to files (FILE); after

the run we save the dump files and then equipa lun to an actual line

printer (LP), label it and copy all the line printer files to this lun.

By this procedure, we label only one line printer unit and our output

stays together When copying line printer files, always use SØ

in the COPY parameter string As an exairple

#EOLIP, lun =FILE, lun =FILE, , lun =FILE (CR)

FLEX2 simulation run

END OF FLEX2 SFSSION

#EOUIP, lplun =LP (CR)

#LABEL, lplun /SAVE FOR user identification (CR)

#COPY, 1= lun /R, 0= lplun , S=Ø (CR)

Pepeat COPY with each lun from firstEQUIP

Logical unit numbers 50 and above are used by FLEX2, so restrict user- equipped luns from 1 to 49.After a simulation run we recommend resetting the luns 50-59 and 62-99 to unequipped status prior to calling

FLEX2 again by typing

#RESET,50 (CR) 55

Calling FLEX2

While in OS-3 control rode, type *FLFX2 folloved by various parameters These parameteis and their uses are

C: Continue parameter. Presence of C indicates a continuation of an earlier session, with a partially constructed model, a totally constructed modelreadv for simulation or an interrupted simulation run

to be continued. The W parameter must also be used. Absence of C

indcateb starting from sratch

D = : Data dump lun or name. All variables being dumped from the target module (identified with the TARGET corunand)WiJi-

go to thisin or nane Defaults to no dump file

I = : input control lun or name. Lun or name fro

hich commands will be read Defaults to lun 60

L = : Line printer ion or name. All variables sent

to the line printer from the target module go to this lun or name.

Defaults to no line çrinter listing,

T = : Monitor (output control) lun. Lun to which all monitor output will be sent. Defaults to ion 61.

W = : Work ion. This is the luri on which the model will be constructed, i.e., modules and function overlays stored. The

ion must be equipped to a RAF prior to calling FLEX2. If a name is

used, file protection must be removed Defaults to ion 50

Any or all of these parameters may be deleted with the specified

defaults resulting. The order in which they are entered is immaterial.

Each parameter should be separated from the next by a comma 56

If the user is at an interactive terminal (TTY, CRT or Tekscope), the FLFX2 system will respond by typing a heading and the statement

ENTER INPUTS/COMMANDS. FLEX2 has its own command sign, a "greater than" sign (>) which signals that the system is ready to accept a command

Examples

*FLEX2 (all default values used)

*FLEX2, L=3Ø, D=4Ø (line printer lun set to 30, dump file lun set to 40)

*FLEX2, L=3O, D=4Ø, W17 (same as above, but lun 17 has been equipped to the model file and a previous session's work on that model is being continued)

*FLEX2, L=3Ø, T=15, D=4 (same as above, but input C, W=l7, 1=5 commands will be read from lun 5, monitor output will be sent to lun 15) 57

Commands

The various FLEX2 commands willnov' be detailed. There are

basically three types of commands used in FLEX2. The first type is

used to structure an individual module and enter the variousparameter

values necessary for a run. The second type is used to structure the

modules into a model if the REFLEX algorithm is being used. The third

type is used to instruct the processor about beginning a simulationrun,

fetching and filing modules, resetting aftera run, etc. The commands

are presented in alphabetical order after the editing section.

More than one command may appearon each lane after the command

sign. The INPUT= and the TITLE= commandsmust

end the line they appear on, soany commands sharing the line must be

typed first. Each line may be up to 136 characters long, including

spaces and editing symbols (80 characters for batch mode). Each command

is separated from the next by aspace or spaces. Commands may be edited before typing carriage return (CR). Consult the Editing section following.

Each line of command input terminated bya carriage return is processed as a whole by FLEX2. After the commands and edit symbols are processed, FLEX2 may print one of several possible messages. A command sign is then typed indicating that FLEX2 is ready for furtter input If an error message occurs, consult Appendix Section Al for the proper response.

Each command entry begins with a general representation of that command. Any lower case letters which are included representa number or name typed by the user. Underlines have been used to indicate missing numbers which the user must also enter. 58

Editing

FLEX2 uses two symboLs or editing of input. These are the backslash (\), and the at sign (@) The use of each will now be explained.

Often the character typed is not the intended one. The backslash operates as a back spacer. Each time it is used, a character is deleted from the line or character string. Deletions are consecutive. For example

INN\PUU\T-\= *LII\DEI1 would be read by FLEX2 as

P\PUT=*LIDEI1

Pnother example is

FONL\ \ \ \UNLOAD=*LIDEØ1

The first backslash deletes the L, the second the preceding N, the third the preceding A and so forth The backslash here operates exactl the same as the backslash in the OS-3 EDITOR

Sometimes so many mistakes have been made that it is desirable to begin the line again Use the at sign (@) This operates for FLEX2 exactly the same way that it does for the OS-3EDITOP,that is, the at sign deletes all preceding characters After typing this symbol, follow it with the line as it should have appeared For example

N-\=l2 TRNTL@NUMBER=l2 TSTART=lØ TMAX=l5 (CR)

The at sign followed by a carriage return sends nothing to FLEX2

Pemember that the length of a line in FLEX2 is limited to 136 characters (80 in batch mode) including spaces and editing symbols. 59

B( )=,,..., (vector)

B(i)= (element)

This module structuring conimand is used to enter the values of the b parameters. They may be entered as a vector with parentheses oniy or as an element with the index i inside the parentheses.Values in the vector are separated by commas.

Values may be entered in any format. Decimal points are not required for integer values.

Examples:

B( )=l.2, 3, 17.8, .02, (Sets b1l.2,b23.O, b317.8,

-l.E-3, 3 b4=.02, b5=-.00l, b6=3.)

B(5)= 02 (Sets b5= 02)

CLEAR

This command is a processor oriented command which instructs the processor to reinitialize the current module to its default values. effect, CLEAR wipes the module completely clean so that it may be restructured by following commands.

Example:

MODELGET( )= 1,2 CLEAR (Clears module 1,2) 60

CONTINUE

This command is a processor oriented command which instructs the

processor to continue a run interrupted by a manual interrupt or by

use of the FREEZE command.

Example:

CONTINUE

D=

DKILL=

This pair of module structuring commands is used to specify which

variables go to the dump file (D=) or no longer go to the dump file

(DKILL=). Only one variable may be specified with a single command.

Variables which can go to the dump file are z's, g's, fts, x's,

and y's All y variables are automatically dumped if the YMAX command

is used Dump file manipulation is described in the satellite program

information section.

Examples:

D=X(6) D=Y(7) D=F(1,3) 6' J7and f13 go

to the dump file )

DKILL= Y(5) DKILL= F(l,5) (y5 and f15 no longer

go to the dump file.) 61

DHEAD

This module structuring command prints a list on the control output

(monitor) lun of all variables currently sent to the dump file.

Example:

DHEAD

DPRT=

This module structuring command specifies the time interval frequency for sending variables to the dump file. It defaults to a value of one, i.e., variables are dumped every time step.

Example:

DPRT=5 (Variables are dumped every

fifth time step, i.e., k=O,

5, 10, ..., TMAX.) 62

DUMP

NODUMP

These corimands are of the modulestructuring type The first

instructs the processor that dump file outputis desired, the second

that no dump output should be made. The use of NODUMP does not

preclude use of the LOC command The default is DUMP if the command

TARGET is used, otherwise, NODUMP.

Examples:

DUMP

NODUMP

DUHPLUN= lun

This module structuring command specifies the lunto which DUMP output should be sent If not equipped previously the lun will autonatically be equipped to a file No default value is provided

If no DTJMPLUN command is used with DIThIP, theerror message "LLN0

UNDEFINED' will be printed This command need not be used for a target module if D= was used in the parameter string of the call to FLEX2

Example

DUNPLUN=30 63

FIRSTSUB( )

This model structuring command is used to communicate the hier- archical model structure to the processor. This command must be used after all module definition and structuring is complete.

FIRSTSUB( )= is followed by the module sequence number of the module which will be the first processed subsystem of the ghost system currently in core, i.e., the last module called into the processor with the MODELGET command.

Example:

MODELGET( ) 1, 7, 3 (S, will be the first I,3 ,2 FIRSTSUB( )= 1, 7, 3, 2 subsystem processed of all

subsystems of S73) 64

FREEZE

This processor instruction command directs theprocessor to store

a current image of itself and any run inprogress onto the RAF

designated by the W=in the parameter string of the call to *FLEX2

This image maybe saved under some name.

Vhen work on the model is resumed the savedfile is copied onto

a lun equipped to a RAF and this lun is passed to theprocessor with

the W parameter of the *EX2 call. *FLF)(2 will load the image into core. A run may be continued using the CONTINUE commandor module and model structuring may be resumed.

Example

FREEZE 65

FUNLOAD= lun or name

This module structuring command instructs the processor to load

the function overlay on the lun or saved under the name specified during use of *RLOJ (see IIIB Preparing a Function Overlay) The

function overlay contains the binary (compiled) FORTPAN functions which

constitute the model structure, as well as information necessary for

linkage with the processor.

Examples:

FUNLOAD=25

FUNLOAD=25/R (/R necessary if rewind

desired.)

FUNLOAD=MODELOV (/R not necessary since

a named file is automati-

cally rewound.) 66

FUNSOURCE= lun or name

This is a module structuring command, althoughit does not

specifically affect the module's structure, whichis used to pass the

lun or name where the source (BCD) FORTRAN functionsare stored so that

the processor can access source functionsrequested using the LIST

command

Exan'ples

FUNSOURCE= 15

FUNSOURCE= l5/R

FTJNSOURCE= *SOJJRCE

GROST( )= ,

This model structuring command indicates which moduleis the ghost

for the current module As with FIRSTSUB, GhOST must be used after all module definition and structuringis complete GPOST( )= is followed by the module sequence number of the ghostsystem of the current module in core

Example

NODELGET( )= 1,2,5,3

CHOST( ) 1,2,5 is the ghost

system of S253 ) 67

INPUT= lun or name

This processor oriented instruction directs FLEX2 to read further commands from the lun or name given. FLEX2 will continue to read commands from this lun or name until another flTPUT= command is encountered, or STOP is encountered, or no further commands are given

which will cause an ttERROR ON. . .' error statement. See also the use of 1= in the parameter call string of FLEX2.

Examples:

INPUT= 60 (Returns control to the

user's device (TTY, CRT,

etc.) after reading covinands

off a file.)

INPUT= 17/R (Rewinds lun only when

requested )

LNPUT= *EcpJIl 68

LAG=

This module structuring command starts thestructuring of the merory LAG indicates the maximum number of past valuesto be retained

in meniory for each lagged variable (Lagped variables are indicated by other commands ) Each module has its own memory structure so each may be completely different Defaults to no memory

Examples

LAG= 5 (I'aintain in memory values

of indicated variables for

time, k-i, k--2, ., k-5.)

LAG= (As above, but for time k-i,

.., k-7.) 69

LAGX()= ..,

LAGZ( )= , ,.., These module structuring commands are used to initialize the memory. The vector after = lists the indices of the elements in the x and z vectors to be included in memory. Each x. or z. will have its 1 i past values maintained for the number of past time steps indicated with theLAGcommand (seeLAG). LAGX( )=must precede theLAGZ( ) command.

Fxampie:

LAG 5 (x1, x3, x5, x6, x7, z2,

LAGX( )= 1,5,3,7,6 and z7 will be maintained LAGZ( ) = 2,7 in memory for timek-i, k-2, ..., k-5.) 71)

LEFTSUB( )= -,

This model structuring command indicateswhich module will be processed immediately before thecurrent module LEFTSUB must be used after all module definitionand structuring is complete The module sequence number passedis the number of the module which is to be processed immediatelyprior to the current module The subsysteri indicated must be at thesame hierarchical level as the in-core module and must share a common ghostsystem.

Example:

MODELGET( ) = l7,3,4 (Subsystem S733 is

LEFTSUB( ) = 1,7,3,3 processed just before

processing S734.) 71

LIST=

This module structuring command is used to list any variable or parameter values or function forms which the processor currently has stored.

The following symbols may appear on the right side of the equal sign following LIST:

(1) Forms returning a numeric value

B(i) LPLUN X(i) DPRT MODELTYPE XS(i) DU1PLUN N XD(i) F(i,j) Q XN(i) FUNSOURCE R(i) Y(i) G(I) T YMAX INPUT TSTART Z(i) LAG TMAX ZD(i) LPRT TTYPRT

(When i or j is shown replace with actual index number. XCI)

corresponds to x. (k,k') and XS(i) corresponds to x. (k,kt+1).)

Forms returning a YES/NO response

DUMP SUMMARY LOG TTYON

Forms returning source code (precede with FUNSOURCEcominand.)

'FXXXX (i.e., 'FØ2O3) 'YCOMP 'GXX (i.e., 'GO5) 'ZCOMP 'HXX (i.e., 'HO7)

(Must use a single quote (') as the first character in above forms.)

Examples

LIST = B(5) (Value of b5 listed.)

LIST = DUMP (NO or YES as the case may be)

LIST = 'F03Ø3 (Source code for f33 listed )

LIST = XS(5) (Updated value XS listed.) 72

LISTALL

This module specific command requests that a SU1ARY of the current module be listed on the monitor (TTY) lun. See SWANARY command for information listed.

Example

LISTALL

LOG

NOLOG

This pair of module structuring commands turns the line printer output listing on(LOG)and off (NOLOG) Default is LflC condition it

TARGET command used, otherwise default isNOLOG.

Examples:

NOLOG 73

LP =

LPKILL =

These module structuringcommands specify which variables go to

the line printer file (LP=)or no longer go to the line printer

(LPKILL=) Only one variable may be specifiedwith a single command

Variables and functions whichcan be used arez's, g5, f's, x's,

and y's. It is a good idea to send thesame variables to both the

dump and log filesso that a hard copy of the dump file is available.

Examples:

LP = Y(5) LP = G(3) LP = F(1,2) (y5, g3 and f12 go

to the line printer

file )

LPKILL = G(4) LPKILL = X(13) (g4 and x13 no longer

go to line printer

file.)

LPHEAD

This module structuring commandlists on the monitor lun names of all variables currentlygoing to the line printer

Example:

LPHEAD 74

LPLUN = lun

This module structuring command specifies which lun is the line

printer file for the in-core module. If lun is not equipped, it will

be equipped to a file. No default value is used. If LPLUN is not

used after specifying LOG, the errormessage "LUN0UNDEFINED" will

result, This command need not be used for a module if TARGET is used

and L= was used in the parameter string of the call to FLEX2.

Example:

LPLUN = 44

LPRT =

This module structuring command specifies the time interval

frequency for sending values to the line printer file Default is one, i e, values are line printed every time step

Example

LPRT = 10 (Variable values are printed

every tenth time step,1e

k=O, 10, 20, , ThAX ) 75

MAPPRINT

This processor level command directs theprocessor to print on the

monitor (TTY) lun amap or listing of the module sequence numbers of

all modules currently defined.

Example:

MAPPRINT

MODELGET( )= -, , ...,

This processor level command instructs theprocessor to (a) file away any module currently in-core onto the RAF work file; (b) bring into core the module identified by the given modulesequence number; or

Cc)if the module does not exist, createa new module with the prescribed module sequence number and perform preliminary initializationson that module.

Module sequence numbers are the identification numbers usedto differentiate between modules. The sequence may be up to 12 numbers in length. Each number must be between 1 and 63. Zero's may not be embedded into number sequence, i.e., theymay only occur at the end. 76

The module sequence number should correspond to the subsystem numbering scheme used by the modeller. The first number may be any

number and corresponds with an edition or version number. Thus module

20 would be the S0 system for the model identified as number 20 (perhaps

an aquatic food chain system). The first subsystem S1 would be 20,1,1.

This allows storage on the same RAF work file of more than one model, or

several versions of the same model, with identical or conflicting

hierarchical structures.

The limit of 12 numbers implies a limit of 12 hierarchical levels.

Each system may have up to 63 subsystems.

The module broUght into core with the MODELGET( ) = command is the

subject of all ensuing module structuring commands until another

MODELGET( )= command is given.

Examples:

NODELGET( )= 1 (Fetch subsystem S0 of model 1.)

MODELGET( )= 20 (Fetch subsystem S0 of model 20.)

MODELGET( )= 15,5,2,2,1,3 (Fetch subsystem S52213 of

model 15.) 77

NODELTYPE

This module structuring command differentiates between ghost and terminal modules If MODELTYPE is 0 (zero), this is a terminal or

FLEX module. If MODELTYPE is 1 (one), this is a ghost or REFLEX type module. Default value is 0 (terminal).

Examples:

MODELTYPE = 1 (A ghost module.)

MODELTYPE= 0 (A terminal module )

NEWINDEX( ) =-, , ..,

This processor level command changes the module sequence number of the module. Future MODELGET commands must use the new sequence number.

In addition to changing the index of the in-core module itself, the user must alter all GHOST, FIRSTSUB, LEFTSUB and RIGHTSUB commands in associated modules to reflect the change.

Example:

MODELGET = 23,1,2 (Changes subsystem 1,2 NEWINDEX = 23,1,5 to S15.) 78

NOPR TNT

This module specific command shuts off printing ofreset values.

When an x variable falls below its lower limit duringa run, the processor will print the value and then set the variable to its lower limit (see XL), If a variable is near the lower limit, rounding errors may make the value fall below the lower limit, causing messages like

(assuming a zero lower limit)

X(lØ) =-l.86265E-Ø9IN lØØØØØ

X(2)= -l.49Ol2E-Ø8IN 1ØØØØØØØØØØ

X(9)= -9.3l323E--1ØINlØØØØØØØØØ

This is essentially worthless information. If the reset values being printed by a run are not wanted, shut the printing off with NOPRINT.

Default is printing. May only be reset to print condition by using

CLEAR, so this command should be used with caution.

Example:

NOPRINT 79

NUMBER =

This module structuring command defines the number of x variables and also sets many default values. NUMBER must be the first command after MODELGET when structuring a module.

NUMBER must be used before changing x related values, such as

XL, XN, XU, when the module is accessed after initial structuring.

The value of NUMBER may be checked using N with the LIST command.

Examples:

NODELGET( ) = 12, 1, 3 (First call to module.)

NUMBER 5

RESET (Call during a multiple run.)

MODELGET( ) = 12, 1, 3

TTY = Y(4) TTYKILL = Y(9) NUMBER = 6XN(1) = 5 80

0=

This module structuring coiiuiiand specifies the time resolution ratio between higher and lower level processing. For the ghost module, q refers

to the number of times each subsystem module will be processed. Thus,

if the ghost operates at weekly resolution and the subsystemsat daily resolution, then Q=7 for the ghost module.

For terminal subsystems, q refers to the number of lower level processing cycles made for each time step. The command Q5 would be equivalent to using At=.2 as the time step. This makes possible an

Euler solution to differential equations.

Q defaults to one and is reinitialized by the CLEAR command.

Examples:

Q= 5

Q = 12 81

R()=_,_,.",- (vector)

R(i) = (element)

This module structuring command is used to enter the values of the r parameters. They may be entered as a vector with parentheses only or as an element with the index included between the parentheses.Values in the vector are separated by commas.

Values may be entered in any format Decimal points are not reauired for integer values.

Examples

R( ) = 607, 39, -1 2E4, 3, 02 (r1 = 607, r2 = 39,

r3 = -12000., r, = 3. and

.02.) 5 R(17) = 3.9R(2O) = 8 (r17 = 3.4, and

R(5) = 63.9 63.9.) 82

RIGHTSUB( )= -, -, ..,

This node1 structuring command indicates which module will he processed immediately after the current module. RIGHTSUB must be used after all module definition and structuring is complete. The module sequence number passed is the number of the module to be processed immediately after the in-core module. The subsystem indicated must be at the same hierarchical level as the in-core model and must share a common ghost system.

Examples:

MODELGET( )= 1, 1 (S1 and S2 are subsystems

GHOST ( ) = 1 of S0 and S1 is to be

RIGPTSUB( )= 1,2 processed just before S2.) 83

RESET

This processor level command reinitializes the entire currently defined model to its condition just prior to the last SIMULATE command, except any b or r parameters changed during the run. The b or r parameters retain the last change. If the command SIMULATE is used after RESET and exterior data files are rewound, an exact duplication of the previous run would be made. This command is extremely useful when making multiple runs

Example:

RE SET

S IMULATE

This processor level command instructs the processor to store the in-core module on the RAF work file and begin the simulation run.

Simulation will continue until terminated by time reaching TMAX or interrupted by the user depressing the BREAK key or as a result of

FLEX2 aborts. After an interrupt, the OS.-3 control mode instruction

MI will return the run to FLEX2 command mode (See also CONTINUE and

FREEZE.)

Example

SIMULATE 84

STOP This processor level coniinand directs the processor to terminate the current modelling session.Control Is returned to OS-3. Example:

STOP

SUMMARY

NOSUNMARY

This pair of module specific corunands turns the monitor sunimarvon and off.The summary information Includes model, run time, logical unit numbers used, initial X values, parameter values, and monitor values, and indices of defined functionsThe summary goes to the line printer and dump file so a monitor summary Is not necessary after the initial debugging run(s). Default condition is Examples:

NOSUNMARY

SUNMAR? 85

TARGET

This module structuring command identifies the current module as the target or key system of interest. Several defaults are reset for the identified target module; DUMPLUN becomes the lun passed with the D parameter in the FLEX2 call and LPLUN becomes the lun passed with the L parameter. LOG, DUMP and TTYON are the default conditions for the target module.

Example:

TARGET TITLE =

This module specific command assignsan alphanuireric title to the model output to identify the run If TITLE is not used, an identifying date and time label is still included The title may be up to 80 characters long Editing symbols have their saire editing function within the title and the bckslash may be used to backspace Fditing symbols are not printed TITLE must be the last command on the input line

Examples:

TITLE = WATERSHED MODEL. RUN 3 X(5) = 17.

LAG = 7 TITLE = FIRST RUN (ok)

TITLE = FIRST RUNLAG = 7 (The title will be

FIRST RUNLAG = 7

but LAG will not be

set to 7.) 87

TNAX=

This model structuring command is used only in the top ghost of the hierarchical model or in the FLEX module for single level models.

TMAX sets the terminating time for the simulation run.

Default is to print initial conditions only. TMAX must be larger than TSTART or the run aborts.

Example:

MODELGET( ) = 1

NUMBER = 3 TMAX=52

TSTART =

This model structuring command is used only in the top ghost of the hierarchical model or in the FLEX module for single level models.

TSTART sets the initial or starting time of the simulation run. Initial time in each subsystem is zero. Default is zero.

Example:

MODELGET( )= 1

NUNBE = 3

TSTART = 7 TMAX = 14 88

TTY=

TTYKILL

These module structuring commands specify which variables go to the monitor (TTY, CRT or TEKSCOPE) unit (TTY = ) or no longer go to the monitor (TTYKILL = ) Only one variable may be specified with a single command These commands are similar in operation to LP/LPKILL and

D /DKILL

Variables which can go to the monitor include z's, g's, f's, x's, and y's. Monitored variables may be changed mid-run.

Examples

TTY = Y(7) TTY = F(6,6) (i7 and f66 go to the

monitor.)

TTYKILL = Y(7) TTY = Y(6) (y7 no longer goes to the

monitor, y6 goes to the

monitor.) 89

TTY1=

TTY2 =

TTY3 =

TTY4 =

TTY5 =

These module structuring commands specify names up to 8 characters long for labelling the first five variables which go to the monitor. the monitor listing, the processor will print the specified name rather than the FLEX2 designation for each variable listed in a command The

default is the use of FLEX2 standard designations,1e , Y(l), X(3), etc

Example:

TTY1 BIOMASSTTY2 = FOOD (The first output column will be labelled BIOMASS, TTY3 = LENGTH the second FOOD, the third LENGTH, Fourth and fifth columns, if printed, will have FLEX2 designations.)

TTYIIEAD

This module specific command prints on the monitor lun a list of all variables currently going to the monitor,

FxaPlp le

TTYHEAD 90

TTYLUN = lun

This module specific command identifies the lun of the monitor

Do not send monitor outout from more than one module to thesame lun to avoid mixing monitor outout, thus making it unintelligible Default is 61 for all modules. (See TTYON)

The target module monitor output goes to the lun after the T parameter in the FLEX2 call string.

Examples:

TTYLUN = 80

*FLEX2, = 7 (Subsystem S3 sends its

monitor output to lun 7.)

MODELGET = 1,3 NUMBER = 5 91

TTYON

TTYOFF

This module specific command specifies whether or not monitor output is desired. Default condition is TTYOFF in all modules except the target module (see TARGET).

Examples:

TTYOFF

TTYON

TTYPRT =

This module structuring command specifies the frequency of output to the monitor lun. Since printing variables every time step is expensive both in money and time, an integer larger than one should be used for most monitoring. Default value is one.

Example:

TTYPRT = 10 (Monitor output printed

every tenth iteration.) 92

XD (i,r) = (element)

XD (,r) - , , (column vector)

XD (1, ) , .., (row vector)

This module structuring command sets the memory variables to their initial conditions. The memory is set up as a matrix with rows representing the delayed x's and z's ar:d the columns the k-r th past values of the variables.

Values may be entered by element or by either vector method.This command must follow the LAG, LAGX and LAGZ commands. Default values arc zero. If all memory defaults to zero, one XD or ZD command is still required to initialize memory.

Examples

LAG = 7 LAGX = 1,2,3

XD(l,5) = 7.3 (x1(k-5) = 7.3)

(l, ) 3.1,2,1.2 (x1(kl) = 3.1, x1(k-2) = 2,

and x1(k3) =

x1(k--7) default to zero )

XD( ,4) 17 3, 9 1, -3 (x1(k-4) = 17 3, x2(k-4) = 9 1,

and x3(k-4) = '-3.)

Note: The element form is used for accessing x's in Memory by all user-defined functions. 93

XE= (vector)

XE(i) = (element)

This module structuring command specifies the amount by which

the x. variable indicated may change in a single computation cycle.

If

A. > XE. J

and XEi 0

then an error message is printed. If XE(i) is 0 (the default value)

no checking is done.

Example:

XE(17) = 3.9 (If 7I> print) XE( )= 5,lØ,lOØ (If A1I>5,A2 >100

XL(i) (element)

XL( ) = .., (vector)

This module structuring command specifies the lower limit of the particular x.. If the x. value falls below the specified lower limit,

the variable will be reset to its lower limit and the value will be printed on the monitor lun. (See NOPRINT.) Default value is zero.

Examples:

XL(5) = -37 (Lower limit for x5 = -37.)

XL( )= 2O,2Ø,-1ØØ (Lower limit for x1 = 20,

for x2 20 and for x3 -100.) 94

XN(i) = (element)

XN( ) = , (vector)

This module specific command sets the initial conditions for the

indicated to thevalues stated. Default is zero. 1 Examples:

XN(17) = 23 (x17(0) = 23)

XN( ) = 5,5,17,4.2, lE-3 (x1(0) = 5, x(0) = 5,

x3(0) = 17, x4(0) = 4.2,

and x5(0) = ,00l)

XU(i) = (element)

XU( ) = (vector)

This module structuring command specifies the upper limit for that x1 If the upper limit is exceeded, an error message is printed 100 Default value is 10 .

Examples:

XU(l4) =9000 (Upper limit for x14 = 9000.)

XU( ) = 1E4, -lØØ, .973 (Upper limit for x1 = 10000,

= -100, and for x3 = .973.) 95

YNAX=

This module structuring command specifies the number of y variables defined. All y's go to the dump file. This command should precede any commands which assign variables to the dump, log or monitor luns.

Example:

YNAX = 17 (y1, y2, ..., y go to .

the dump file.) 96

ZD(i,r) = (element)

ZD( ,r) = , , ..., (column vector)

ZD(i, ) , , .., (row vector)

This module structuring commandsets the memory variables to their

initial conditions. The memory is set up as a matrix withrows

representing the delayed x's and z's and the columns thek-r th past

values of the variables.

Values may be entered by elementor by either row or column vector.

This command must follow LAG, LAGX and LAGZcommands. Default values

are zero. ZD operates similarly to XD. If all memory defaults to zero,

one XD or ZD command is still required to initializememory.

Examples:

LAG = 4 LAGZ = 1,3,5

ZD(l,3) = 17 (z1(k--3) = 17.)

ZD( ,3) 7, .4, lE-4 (z1(k-3) = 7, z3(k-3) = .4,

and z5(k-3) = .0001)

ZD(l, ) = 4 , 2 , 1 (z1(k 1) = 4, z1(k-2) = 2,

and z1(k-3) = 1 z1(k-4)

defaults to zero.)

Note: The element form is used for accessing z'sin Memory by all user-defined functions, 97

Data Dump File Manipulations by Satellite Programs

Line printer plots, Calcomp plots, BCD files of selected variables, and line printer listings may be generated from the dump files by several satellite programs,

A. Satellite Program *F2PLOT, This program produces line printer plots from a FLEX2 dump file and a plot specification file. The calling procedure is:

#EQUIP,l=

#EQUIP,2=

#REWIND,1 ,2

#*F2PLOT

The program prints a model title, then asks "PLOT?" If a plot is desired, type "YES"; if not, type "NO."When the first plot is indicated the program reads information from the specification file and plots the data.

For subsequent plots, in addition to asking "PLOT?", the program asks

"SAME SPECS?" If the specifications desired for a plot are the same as

the previous plot, type "YES."The program will process the plot. If

specifications are different, type "NO" and the prograni will read a set

of information from the specification file.

Specification File

Title Card Col. 1-80 identifying title

Specification Card Col. 1-2 number of variables

selected for plotting

(limited to 10 or fewer)

3-6 starting time 98

7-10 time step multiple (n)

11-14 stopping time

3. Variable card(s) 1-2 position in dump file

(use as many 3-10 alpha name of variable

as number of (first character of name is

selected variables) plotting symbol)

11-20 maximum value

21-30 minimum value

The time variables can be used to select a subset of the data.

Rather than starting at the first time step on the dump file, a later

starting time may be specified. The stopping time can be used similarly

to cut off a plot before the end of the dump file, The time step multiple (n) is used to skip records;every nth record is plotted. Note

that this refers to records on the dump file. That is, if these records are for every fifth iteration (producedby using the command DPRT = 5 prior to the simulation run) and if the plot time step multiple is two, then every other record will be plotted, i.e., every tenth iteration.

B. Satellite Program *TP.SFER. This program creates a BCD file from the dump file. The BCD file may be used as driving data for a different model, as input to specially written analysis programs to produce sums, means, etc., for special listing or in *GRAFIT to produce

Calcomp plots.

*TPANSFER closely parallels *F2PLOTin operation. The calling procedure is identical, except for name; *T}ANSFER is called instead of

*F2PLOT. The program prints the model title, then asks "DO?"If a BCD file for the module is desired, type "YES"; if not, type "NO."After 99

printing the transfer specifications for doublechecking,the program

will ask "TIME?" If time (k) is to be includedon the file as the first

variable, type "YES"; if not, type "NO."

Several dump files may be processed sequentially. The program will

ask "SAME SPECS?" If the transfer specifications are thesame, type

"YES"; if not, type "NO" andanother set of specifications will be read

from the specification file.

The *TRANSFER specification file has much thesame structure as

the *F2PLOT file. Minor changes include a format card and the variable

count. After the specification card isa format card which gives the

format of the BCD file produced. Parentheses must enclose the format.

For example, the format card might be

(8F9.4)

E, F, and X format specificationsare legal.

On the specification card the firsttwo columns still indicate the number of variables transferred and thisis still limited to ten or

fewer. If time (k) is included do notcount it as one of the variables

(i.e., 11 total values may be transferred).However time will count in the format statement. As an example cards two and three might read

7 0 2700

(8F1Ø,4)

In this case time is included,508 values appear on the file. Time is the first variable transferred with theother variables following in the same order as their variable cards.

C, Satellite Program *F2DPRNT If a line printer listing of a simulation run or a copy of the dump file itselfis desired, it may be 100

generated using the data dump file and the FLEX2 Satelliteprogram

*F2DPRNT. Run from a teletype in OS.-3 control mode as follows:

#*F2DPRNT, I = dump file nameor lun, D = dump copy lun,

L = lp copy lung P n (CR)

A copy of the values of all variables sent to the dump filegoes to the dump copy lun. A copy of all variables sent to the line printer which also went to the dump file goes to the lpcopy lun. The integer after

P is the print interval desired. Thus, if n was 5 every fifth record sent to the dump file would be printed on the appropriate lun. D and L have their lun values default to 61. P defaults to one whether included in parameter string or not. 101

REFERENCES

3100, 3200, 3300 and 3500. Computer Systems Fortran Reference Manual,

Control Data Corporation, Documentation Department, 3145 Porter

Drive, Palo Alto, California. Publication Number 60057600,

Revision B. 157 p. 1966.

Dayton, Fred. OS-3 Editor Manual, Oregon State University Computer

Center, Oregon State University, Corvallis, Oregon 97331,

Publication CCN-70-7(r). 73 p. 1971.

Freeman, Herbert. Discrete-Time Systems. John Wiley, New York.

241 p. 1965.

Fuller, R. Buckminster. "Introduction to Omni'-Directional Halo"

and "Omni-Directional Halo" in No More Second Hand God and Other

Writings, Southern Illinois University Press, Carbondale,

Illinois. 163 p. 1963.

Klir, George J. An Approach to General Systems Theory, Van Nostrand

Reinhold, New York. 323 p. 1969.

Klir, George J. (Ed,) Trends in General Systems Theory, Wiley-

Interscience, New York. 462 p. 1972.

Koestler, Arthur. The Ghost in the Machine, MacMillan, New York.

384 p. 1967. 102

Kuhn, Thomas S. The Structure of Scientific Revolutions, University

of Chicago Press, Chicago. Second edition, 172 P. 1970.

Overton, W. Scott. "Toward A General Model Structure fora Forest

Ecosystem". Pages 36-47. IN: Proceedings -- Research on

Coniferous Forest Ecosystems-- A Symposium. Franklin, J. F.,

L. J. Dempster and R. H, Waring (Eds.), Pacific NorthwestForest

and Range Experiment Station, Forest Service, USDA, Portland,

Oregon. Available from Superintendent of Documents, U.S.

Government Printing Office, Washington, D.C. 20402. Stock

Number 0101-0233. Price $2.50. 322 p. 1972.

Overton, W. S., J. A. Colby, J. Gourley and C. White. FLEX1 User's

Manual, Internal Report 126, Coniferous Forest Biome, U.S.!

International Biological Program, Seattle, Washington. 101 p.

1973.

Overton, W. S. "The Ecosystem Modelling Approach in the Coniferous

Biome' in Systems Analysis and Simulation in Ecology,Volume III,

edited by Bernard C Patten (In Press).

OS-3 Reference Manual for OS-3 Version 4.3, Oregon State University

Computer Center, Oregon State University, Corvallis, Oregon 97331.

Publication CCM-70-8R. 89 p. 1973. 103

Simon,Herbert A. "The Architecture of Complexity". Pages 63-76.

IN: General Systems Yearbook,. Volume X. von Bertalanffy, L.

and A. Rapaport (Eds.) 211 p, 1965.

Simon, H. A. "The Organization of Complex Systems" IN: Hierarchy

Theory: The Challenge of Complex Systems. Pattee, Howard H.

(Ed.) Braziller, New York. 156 p. 1973. Al.1

Al. ERROR NESSAGES

For the most part, *FLEX2error messages are self-explanatory. The major difference lies between the instruction

REENTER and the instruction

REENTER VALUE which is printed only when anerror is detected on commands entered from a TTY. In the first case the command, equal sign, and the valuemust be typed again (as well as anything whichfollowed that command on the same input line.). In the second case, only the value inerror and what was entered to the right of it need be re-entered

If the cause of the error isnot apparent, enter: ?? This will cause a complete error message to be printed.

Below is a complete list of *FLEX2error messages and their meanings.

VSYN represents an internal variable symbolof FLEX, BASESYN represents

any command keyword (i.e. CLEAR, XD( , ), xN( ), etc.), SYN represents any symbol (i.e. misspelled commands, etc.), andK represents theKth character position in the input record (ccuntingfrom the left.).

"Err on Keord BASESYM while scannin: BASESYM at 'osition0invalid

definition of array bounds in VARDEF."This indicates an error

in the *FLEX2 processor and should be broughtto the attention of

the FLEX maintenance personnel.

"Err on Keyword BASESYM whilescanning BASESYN at position0error

in VARDEF -- invalid type." *FLEX2 error. See 1. Al. 2

"Err on Keyword BASESYI4 while scanning SYM at position K:

keyword not defined." *FLEX2 was expecting a new command

(keyword) but the new SYJYI was not a keyword. Recover by

re-entering entire command.

invalid keyword." Same as 3a, except SYM was .not an alpha

numeric symbol - check array bounds or format of previous

conpiand.

invalid character after keyword." In some cases an

sign is needed after a command and this did not appear.

Or parentheses were mismatched. Recover by re-entering

entire command.

non-integer subscript." An integer subscript was expected

(i.e. X(8)), but something else occurred. Recover by

re-entering entire command.

subscript exceeds array bounds." A subscript was larger

than the maximum allowed (i.e. X(84)).Recover by re-

entering entire command.

f value must be integer " SYM was probably not a number

Recover entering correct value or by re-entering entire

command

g value must be real " SYM was probably not a number.

Recover by re-entering only the quantity(ies) on the right

side of the '=' sign.

h. variable cannot be specified again." Some commands cannot

be specified twice without using CLEAR. BASESYM is the Al. 3

erroneous command. This message occurs only if another

command has been processed between the two specifications

(i.e. you may change NUMBER if you do so immediately after

the first entry). Recover by entering CLEAR for the module

effected.

value must be a symbol." *FL2 does not recognize the SYM

because it has a digit as its first character. Recover by

re-entering entire command.

end of file - processing not complete."An end of file was

reached before completing the processing of a command. Re-

cover by re-entering quantity(ies) on the right side of the

'=' sign.

character string too long."The SYM for keyciord BASESYM

must be 8 characters or less. Recover by re-entering

entire command.

1. equal sign not found."The next character after a command

was not an '=' sign. Recover by re-entering entire command.

invalid definition of array bounds in VARDEF."See 1.

another variable must be specified first."To process the

command another command must precede it, e.g. NUMBER

must be specified prior to x limits, initialX's,or any

memory specification; LAG, prior to XD or ZD. Recover

by entering prerequisite command(s), then re-enter entire

command.

unable to equip saved file." There was no saved file with

the given name, it was a public file and someone else was A1.4

using it, or all luns from .1. to 49 are currently equipped.

Enter corrected file names, unequip a lun from 1 to 49 or

try again later.

p. number of subscripts specified is invalid."Either sub-

scripts were used with a non-subscripted command or the

wrong number of subscripts were indicated (too many or too

few commas). Recover by re-entering entire command.

4 "Error on print spec, SYN ignored." The variable requested

cannot be selected for output, or the subscript is non-numeric

or less than 1, or there is an invalid number of subscripts

specified. This print request is ignored.

"Too many print selections." More than 110 variables have been

selected for output. Only the first 110 will be used. (105 for

*F1)(3).

"Invalid lun - SYN ignored."If LP lun was not between 1 and

49, no log (LP listing) could be made. If dump was not between

1 and 49, but was equipped, the run would abort. Recover by

re-assigning luns.

7 "Invalid function file "An empty file, or a non-binary

(uncompiled) function file was used. Recover by re-entering entire

command.

8. "Invalid X dimension."NUMBER was read as 0 or negative or

greater than 63. Recover by immediately re-entering entire

command.

"Too many past values specified." Caused by memory block over-

flow (i.e., total number of variables in memory times maximum A1.5

past values retained is greater than 200or 250 for *FL3)

Recover by entering CLEAR for that module.

"Error condition prevails." Anerror condition reinined uncorrected when the simulate commandwas entered. Recover by correcting last error.

"Abnormal termination of simulation run." Some non-recoverable error has occurred. Recover by starting afresh.

"Error." An error has occurred. Precedes further error clarif i- cation. No further explanation indicatesan inoperable command was entered, or no monitor module existed when the simulate command was given.

"XC ) = sm in NSN K SYM KPRIME = Sm." X( ) has decreased below its lower limit and has beenreset to that lower limit.

"X( ) is out ofrange in NSQN."X( ) has increased above its upper limit.

"Chae in X( ) exceeds limitin MSQN." A( ) exceeded the error limits. Errors 13, 14 and 15 do not terminatea simulation run.

"Recursion overflow." *FLEX2 keeps track of the nesting of functional dependence. Although the g functions need not be indexed in numerical order,so that gj never references a g, j

"Variable not valid for LIST command." Only those variables and commands in the Section IV List commandentry are valid. Recover Al. 6

by re-entering entire command.

18. "Invalid model indices."The module number accompanying a

command contained imbedded zeroes or numbers greater than 63.

Recover by re-entering the command.

l9. "Continue what?" The continue command is not valid unless

preceded at some time bya break and the NI command (possibly

followed by theFREEZEcommand during some earlier simulation).

"Parameter error work file not a RAP or NSF." The lun specified

by the W Parameter in the*FLEX2call was invalid. Recover by

recalling*FLEX2.

"Nodule already exists."The NEWINDEX command was given with a

module number already assigned to another module. Recover by

re-entering the command with a new module number.

"TOOmany F functions." Self explanatory.

"Input processor too large."Contact reflex maintenance personnel.

"NSQN is current module." A model structuring command was entered

that related the current module with itself. MSQN must specify

a different module.

"MSQN does not exist." A model structuring command was entered

that related the current module with a module which does not exist.

"Already defined with another MSQN." A model structuring command

was entered that specified a relation that had been previously

defined. If.you wish to redefine this relation you mustCLEARthis

module and redefine all model structure pointers associated with

it. Al .7

"NSQN does not point backto current map."This will result when

an attempt is made to declare the ?XSQN modulethe right or left

module to two other modules. If you wish to change the model

structure, you must CLEAR the modulescontaining incorrect pointers

and restructure them fromscratch, redefining all pointers lost.

"SQN/current module havedifferent ghosts."A model structuring

conniand was entered that defineda left-right subsystem relation

between modules previouslydefined as having different ghosts. If

you wish to change the modelstructure, you must CLEAR the modules

containing incorrect pointers andrestructure them from scratch,

redefining all pointers lost.

"MSQN has another ghost."This will result when an attempt is made

to declare NSQN module theFIRST SUB of two different ghosts.

Note: MSQN is module sequence number. A1.8

LOADER ERROR MESSAGES. Unless the user recognizes the subprogram or entry

point name as being one of theirown defined functions the message and

circumstances should be reported to *FL2 maintenance personnel.

PPPPP - Subprogram name.

EEEEE -Entry point name. (FORTRANfunction or

subroutine name.)

TTT - Type of 0S3 binary loader card (IDC, RIP,

XNL, EPT, TRA, EXS).

EEEEE UNDEFINED SYMBOL IN PPPPP

The external symbol orFORTRANsubroutine name

EEEEEwas used in program PPPPP, but after loading

no such entry point orFORTRANsubroutine was

found.

EEEEE DUPLICATE SYMBOL IN PPPPP

While loading routine PPPPP, the entry pointor

FORTRANsubroutine nameEEEEEwas found a second

time. Often this is caused by loading two copies

of the same subprogram.

NON-LOADER FILE LUN XX

ILLEGAL BCD RECORD LUN XX

The loader was instructed to load from LUN XX.

However, the information on LUN XXwas not a loader file. Al .9

CAN NOT EQUIP SAVE RILE XXXX

The loader was asked to equip file XXXX. However,

either no such file exists, or the file is busy.

PPPPP TTT CARD OUT 0F SEQUENCE

Missing, extra, or scrambled cards in a loader

file.

PPPPP TTT CHECKSUMERROR

Either a card has been incorrectly read or

punched or the card type (TTT) is TRA which

Indicates that there are extra or omitted

cards. Every binary loader record is check

summed except for the TRA card which contains a

checksum for the complete subprogram.

PPPPP DATABLOCK SIZEERROR

A labeled common area In program PPPPP was

larger than the same labeled common area In

a previous program and the loader could not

expand the labeled common area without causing

a memory allocation overlap.

PPPPP MEMORY OVERFLOW

Program PPPPP caused the sum of all memory used

by routines and labeled common to exceed 8K A1.1O

words. This error occurs if the size of all

the user-defined functions is too large (seeSection IIIB).

LIBRARY FORMAT ERROR

A file or logical unitwas declared a library

but was not in the correct loader library

format.

PPPPP EXS FORMAT ERROR

EXS card not in proper format.

PPPPP EEEEE EXS STRING LOOP

The loader, while following an external linkage

chain, has detected a loop. If this is the only

error, it may indicate that the program that

generated the binary deck PPPPP has madean error.

LUN XX RECORD SIZE ERROR

A record too long f or the loader input buffer

has been read.

PPPPP TTT ILLEGAL RELOCATION

Relocatable jnformatin is not relocated Ina

meaningful way. This error should not normally

occur. Al.1l

LUN XX REWOUND

Logical unit XX was left at end-os-data. The

loader will rewind the unit before reading from

it.

LUN XX EMPTY

The logical unit is both at loadpoint and at

end-o-.data. A1.12

*p2LO AN]) *F3LO ERROR MESSAGES

flWALID OR NO F IAJWETER

This indicates that either (a) no F

command appeared in the parameter string or (b)

no lun is available. The solution to (a) is

obvious. To solve (b), unequip some lun

between 1 and 10 and try again. This seldom

occurs.

TOO NANY FUNCTIONS SPECIFIED

If more than 70 g functions or 63 f functions

were specified, this will occur (35 g's and

20 f's for *FL)(3) A1.13

0S3 ERROR NESSAGES

The following messages may result from FLEX programmingerrors

Suggestions for correction are given; however, if theerror persists,

the message and circumstances should be reportedto the *FLEX2

maintenance personnel.

ILLEGAL INSTRUCTION . .

A linkage error has occurred. This most likely means that a

parameter string for one or more of the F, G, H, ZCOI'IP, YCOMP,

VARIN, VAROUT routines is incorrect,or a user-defined subroutine

or function is called with an incorrect parameter string.

MENORY PROTECT VIOLATION . . .

LUN nn IINDEFINEB

Make sure the lun is correctlyset up by a DLUN, LPLUN, or TTYLUN

command. A2. 1

All. Three Examples

FLEXFORMS, Programs and Runs

The following three examplesare all based on exactly the same model.

This was done to showsome of the flexibility in model representation

afforded by FLEX2. The model used is one ofenergy flow in the English

Channel (highly modified from Harvey,1948 and Brylinsky, 1972). Each

example consists of a FLEXFORHor REFLEXFORN, FORTRAN programs, command files

and a simulation run. In addition, the first example also hasa sample batch

run command file included.

The first example shows the modelin FLEX representation. The second

example shows the model in REFLEXrepresentation, as does the third. The

second differs from the third inthat the second is structured so as to

minimize run cost by minimizingnecessary calculations while the third is

structured so that each modulemay be uncoupled and run in isolation with

no programming modifications.

It should be obvious from examinationof the following examples that

there is no "right" way of modelimplementation. Different structures have

different benefits. These examples are offeredas guidelines.

Brylinsky, Michael. "Steady-State Sensitivity Analysis ofEnergy Flow in a Marine Ecosystem," pages 81-100. IN: Systems Analysis and Simulation in Ecology, Volume II, B. C.Patten (ed.), 592 page. 1972.

Harvey, H. W. "On the production of livingmatter in the sea off Plymouth," J. Marine Biology Association,United Kingdom, 29:97. 1950. A2 .3

FtEX MODEL OF: English Channel Cyclic Version 1

INVESTIGATORS: Overton and White

DATE: 4/12/73

TIME RESOLUTION: Weekly

QUANTITY: Biomass Equivalents

VARIABLES AND FUNCTIONS

1. X LIST Description (Reflex correspondence in parentheses)

Phytoplankton (x1 in C, x1 in PP)

x2 Zooplankton (x1 in FC)

x3 Pelagic Fish (x2 in PC)

Benthic Fauna (x3 in FC)

x5 Deniersal Fish (x in PC)

Detritus (x1 in IU, x3 in G)

x7 Bacteria (Microorganisms) (x2 in IU, x1in C)

x8 Free Nutrients (x3 in IU, x5 in G)

2. Z FUNCTIONS Des cript ion

= 13.2754 Insolation (z1 in G)

4. G FUNCTIONS Description

rb (l_eb l)(leb3X8)(l_efZ1) Phytoplankton production g1 mu14 1 (g1 -" C) lb5 A2 .4

g2 = b5g1 Nutrient demand (g3 in G)

g3= b6x2 b 7x Food chain demand for phytoplankton (x6 in G, y1 in FC)

= b8x3 + b9x Demand for zooplankton (g1 in FC)

g = min{g, b10x2 Consumption of zooplankton (g2 in FC)

g =min{g3, bx Consumption of phytoplankton (g2 in G)

g = b x /g Phytoplankton consumption by zooplankton c6 6 2 3 (g3 in FC)

= g6b7x'g3 Phytoplankton consumption by benthic fauna (g, in FC)

g9 = min{b12x(l_ebi3X6),x6} Growth increment of bacteria (g1 in113)

5. F FUNCTIONS Description

f Production, respiration & consumption (f1 in PP) 1

f =g -rx Consumption, respiration (f in FC) 2,2 7 2 2 = g5b8x3/g, Consumption of zooplankton by pelagic fish in FC) 1 2 = g5b9x,/g1 Consumption of zooplankton by benthic fauna (f1 in FC)

= b16x2 Detritus input (f15 in FC)

1:33 = -r3x3 Respiration (f22 in FC)

= bx Detritus input (f in PC) 2,5 = g8 - Consumption, respiration (f33 in FC)

f min{b x,b Consumption of benthic fauna by L,5 1LfL x } demersal fish (f3 in PC) A2 .5

= b18x Detritus input Cf in FC)

f5,5= -r5x5 Respiration (f1 in FC)

f =b x Detritus input (f5 in FC) 5,6 19 5 f6,7= g9 Transfer from detritus to bacteria Cf1 2in lu)

f =rx Release of free nutrients (f2 in hi) 7,8 77 = Free nutrient amount (f33 in ItJ)

7. Y FUNCTIONS Description

y1= x1

See description under X List.

= x8 A2.6

PARAMETERS

8. B PARAMETERS

List Value Description

b1 22

b2 -.1

b3 -.1

b -.1

b5 .08 Stoichiometric parameter.

b6 .41

.056

b8 .075

b9 .007

b10 .17

b11 .41

b12 2

b13 -.1 Cycle parameter.

b1 .007

b15 .1

b16 .04

b17 .0016

b18 .0013

b19 .0017 A2.7

9. R PARAIyIETERS

List Value .202634 .3231115

r .088367 3 .1119356 .0709257

r7 .9 640958

10,. INITIAL CONDITIONS

List Value XN: x 20. 1 x2 8.3 9.9 85. 6.2 10.

x7 .7

10

GENERAL RUN INFORMATION

TSTART = 0

TMAX = 104 A2. 8

MONITOR: y1, y6, y7, y8

MONITOR TIME RESOLUTION: 10

LP, DUMP: All y's

z y8

DIAGRAM

COMMENTS: Exact duplicate of Reflex English Channel Version 1.

BEHAVIOP b5 is the stoichiometric parameter

If b5 < 08, x8 increases monotonically

If b5 > .09, x9 decreases monotonically.

b13 - -1 Generates persistent cycles between detritus and bacteria of phase 4year. b13 = -.5: These cycles are much shorter and quickly damps. A2.9

PROGR.AjS

0000i:C ECYC1n 00002 SUBROU1INE. izCOMP(K,(, Es,b,z, T0,T) 00003: DIMENSION(1) 0004 (1)=13.2754 00005: RETUHN 00006: END ECYC1(1 00008: FUNCTION &01(K,X,b,R) 00009: DIMENSION X( 1),E( 1),FR( 1),( 1) 00010: 00011: C(1.-EXPb(4)*(1))),X(8),h(5)) 00012: RETUFN 00013: END 00014: FUNCTION (-02(K,x,E,f,) DIMENSION X( l),b( 1),F( 1),( 1) 00016: 00017: RETURN 00018: END 00019: FUNCTION C-03(K,X,b,R,) 00020: DIMENSION X( 1),b(1),b(1),(1) 00021: 00022: RETURN 00023: END 00024: FUNCTION c04U<,x,b,R,) 00025: DIMENSION XC 1),b( I ),R(1),( 1) 00026: 04=bC8 *X(3)+E3(9)( 4) 00027: RETURN 00028: END 00029: FUNCTION (05(K,x,B,R,) 00030: DIMENSION XC 1)b( 1)3R( I),( 00031: 1) 00032: RETURN 00033: END 00034: FUNCTION 06(K,x,B,R,) ø035: DIMENSION XC 1)b( 1),f( 1),C1). 00036: f06=FMIN(c(o3),b( 11)*X( 1)) 00037: RETURN 00036: END 00039: FUNCTION C07(K,X,B,R,fl 00040: 00Øi: 00042: RETURN 00043: END 00044: FUNCTION (08(K,X,b,R,) 0004b: UIMENSION X 1),k( 1)kC1)( 1) A2.1O

00046: (0(06)*b(7)*X(4)/((03) 00047: RETURN 00048: END 00049: FUNCTION t09CKX,b,R,) 00050: DIMENSION 00051.: C-;09=FMI NC b( 12) *X( 7 * (1 -EXP BC 13) *X( 6)fl, X (6)) 00052: kETUkN 00053: END 00054:0 ECYC1F1 00055: FUNCTION F0101 (,X, B,,fl 00056: DIMENSION X( 1),E( 1),h( 1),( 1) 00057: 00058: RETU1N 00059: END 00060: FUNCTION F0202(K,X, b 00061: DIMENSION XC 1),E( 1),}( 1),( 1> 00062: F0202=C(cY1)-F(2*x(2)-B(16)(2) 00063: fETUFN 00064: END 00065: FUNCTION FO2O3(K,.,b,k,fl 00066: DIMENSION XC 1),b( 1),}( 1),( 1) 00067: 00068: RETUFN 00069: END FUNCTION F0204CK,X,b,R,fl 00071: DIMENSION XC 1)B( 1),F( 1),E( 1) 00072: 00073: kETUFN 00074: END 00075: FUNCTION F0303(K,X,b,f,) 00076: DIMENSION X(1),b(1),b(1),(1) 00077: F0303=-R(3)*X(3)-Bc17)*x(3) 00078: RETUhN 00079: END 00080: FUNCTION F0404CK,X,E,j,E) 00081: 00082: 00083: 1ETURN 00084: END 00085: FUNCTION F0405(<,X,}3,f,fl 00056: DIMENSION XC 1),b( 1),}'( 1),( 1) 00057: 00088: 1ETUkN 00089: END 00090: FUNCTION FOSOSCK, X, B, I,fl A2 .11

00091: DIMENSION XC 1),B( 1),R( 1),(1) 00092: F0505=-R(5*X(5)_b(19)*X(5) 00093: RETURN 00094: END 00095: FUNCTION FO6O6(l.<,X,h,R,) 00096: DIMENSION 00097: 00098: RETURN 00099: END 00100: FUNCTION F0607(K,X,E,R,) 00101: DIMENSIONX(1),b(1),f(I),(1) 00102: F0607=c-(09) 00103: RETURN O010'i: END 00105: FUNCTION FO708(1<,X,L,h,) 00106: DIMENSION XC I)E(1),R( 1)( 1) 00107: F0708=R(7)*X(7) 00108: RETUiN 00109: END FUNCTION F08O8U<,X,E,F.,) 00111: DIMENSION XC 1),b( 1),1c( 1)(1) 00112: F0808-(-02) 00113 RETURN 0011': END 00115:C ECYCIY1 00116: SUBROUTINE YCOMP(K,X,E,FS,Y,XS,T) 00117: DIMENSION 00118 Y(1)=icCD 00119: Y(2)X(2) 00120: Y(3)=X(3) 00121: Y(4)=X(I) 00122: Y(5XC5 00123: Y(6)=X(6) 0O12: Y(7)=X(7) 00125 00126: RETURN 00127: END A2. 12

CONMAND FILE *ECYCUil

00001 :oL)ELoT )1 002:LbErc=4 TA10 0 I FUNL0AL*ECYC101

3 ci 4: 30005:T'Y(1)TTYY(6) 1iY(7) Ii(Y(8) T'IYl=FH'(TU Ti=UETITL.1TY3=bACTEIP TTYl=NUTiI ENT 00007:LPY(1) LF'=YC2) Li=Y(3)LP=Y(A) LF=Y(5) LE=Y(6) L.PY(7) Lf-Y(8) 00003:L()=22,-. 1,-. 1, .f$,. 075, 007,17, .L1,2,-. ls 007, .04, .0016, 13, .367,1119356, .0709257, k, .9640958 000 11:XN( )u,5 .3,9.9,35,6.2, 10,7, 10 1 I TLE=ENCLI SH CH1EL CYCLI C 0 1 fWN 1 0 013:I ttLII = 60

BATCH RUN

Ocicici 1:CJJh,777777,X,CUiTIS WHITE 0 02:[II=3C0 (300,3:COLKS 1 )0k) 0 (ECUI P, 4OFILE, 4'4FILE, 5*ECYC11 00005:C*LE?c2,L=A4, L)=4C I'nLIi=5 OLLJ:TIYCWi' SIMULP,TE 00008: i P (1r-,40 øciici 10:C SfvE, 'b=*ECYC1D1 J00u1:tECUIF, 33=LF ci0012:C*LPLhUEL, 33/SAVE FOiCUiTIS/ HITE 013:[CjFY,I=44/,0=33,=0 0u014: CLJC)kr TELETYPE RUN A2 .13

#rL()U1r, 11'ILL #O,IhAN, 1**ECYCI, . iJ= 1

/iCOPY,1=1/is -NO Ot'cS£Jt' VCOiF -NO ttmOFSF3i'c (1 - NO EbfsJj-.S ETh (c NO O-<.5 FOk (-03 -NO EiOS FOt-. (.4. - NO Et\J 1iJhC L'5 No -OtS 3Fc(06 - NO C J1 i\ 0 EilcJ S FX-( 03 -NO EJ'h0 FUY (9 -j() J E') o1c;1 -NO hOi FU t'02 02 -NO hi\Oh FOt 023 - N) E'z'Ok O0 o204 -N) LkOr iJiS L3J3 I\JEi)r FOt NO Li\Or 0Av)5 NJ ERkOk Oi j5ç5 - NJ rhUz-SFUr'. O60 6 - NO EOh. Ok F 0607 -NJ t-i3r fUrs F07 03 - NO LOhONS FOr'. F005 - NO Etk'.)h FOc'C-)MP #*r2LUAL), 56,L*i't'KL b LN'1E LLN Oh NANE Jk FUNCi1'.)N OVrL!Y.

#t\EL EASE:, 56

#*rLEX2, L'4's0= 10

* * * * * * * * * * * * * * * *4:4: * * * * * * * * ** * * * * * * * * * * * *:,2r)3 V.() FLEX / hEFLEX (ENLOAL NOL)eLPtJCESS)b

UlL(-f US1 E. I GOMP.N1) A2.14

LNIEJc INfrU1S/COANL)S >INPUT=*ECx'U1 1 F;Na.iNFL1S/GOvI,ND >S IUL Al .

iE3t3/74 4:S6 -M E'.(LtNCiPNNELCr'CLIC\iE,. 1. F'ij\ 1. ( ø831656 kLELE:iE:Nc. icc.

1ATE.vP.iIbLE 8 TTY -hIN1 IN1 EiVAL I\IjjL TIsv.. () )Pif UUF IiAL I itii\AiIJ Ic' LP i-rIN1 IiVL I fEj(jI)i'rAi I) I

C)IsOL I £'PuT LUN 6t CUNi r)L DU IrLJ LUN 61 LINE f'IIi LUN 44 UNC1IJNINFUI LUN 52 ifliuU"t LL\ Lu- LL'N 44

I) .( ) (3) (4) (5)

(6) C 7) C 8)

II II MLic 2. UuLE I 8 3(. CC 9 UtliE.cc o'. 5.Ct)E. 1 6.C0E VC 1 ;0t*.Cl 7 CLtiL- i1 1 CCCCL.CI Ut-rEk LI'fi l.()k)CE1 I.QCcE1j, 1.UE.CCL12C 1.cCFIc0I .Q;iøFI0U I Ø(J 1 UC I LLLh_1 CU 1 1CC

LO iILI :,i f OE CE. 00 CE CU Ct. CU CE CC CE CU CE00 CE. CU

LIiviI 1 CE CC CE 00 CE 00 CL (? CE W CE CC CE ("0 CL k0

c UON NIS2.C263E.-I 3.231IL-Ui .367E-C2 I I19E-U1 7.26E.-C2 CE. CC

hCiNt(\N'Is2.'uicE. 1 -1.'VLCE-U1 -1.LiC(.t-U1 -1.LC(c-(i '.(C0CL-' A2.15

. 1ç-L1 5. 6C.OLE-02 7 s0-c;2 7.c0T-31 .7(E-1 41('ü- 1g.(U(UE tC -1.u'1Vt-I 7.vCJ t'(Q- I

I. I 6L VL- 3 1 -03 I icr (E -( 3

0/3/7 ':56 1M E.t\cLi-i URPNNi.L CYCLIC 1.iU\1. C 08301b56 tt)vhL tLI1'').Ii rLO FUNUiI)1\.-* =

1 3 3 b 1 B k ( I.J) * ki (: 0 0 t(,J) * * * ( r( 3,J) 0 t * 0 0 0 0 0 i( ',J) 0 * * C U '(5,J) 0 0 0 0 * C j ç, ( 6,J) o 0 0 0 0 * * C f.(7,J) C 0 0 0 o 0 * r(j,J) 0 0 0 0 0 0

ItUICIES Ot DJNED (FUN0TiO'.s 1 2 3 L 5 6 7 8

Ij\UICkZ ' DEYINED H1Li1'JCIION

Co; SLbI0Ufl. IS ULiIND C)MF UtI\OLiTIN IS L)It\E.D

I -p(-_ t13/30/74 : 56 f; N(Li k-( ChPNNEL C'CLIC VEk.I. I C. 30 16 56 MJUL bL.Nth 'ii.1LIU O000 P2. 16

UNE HYT') UE1I hI 1 US hACi E \L A NUiiI ENF

0 20.ø00O 10.0000 .700000 10.000000

I 16.6204S 9.583fl1 .910102 9.96795

2 14.733c.fl B.36404 ).15AE315 1.1S416

3 13.S24 7.39729 1.4iI339 1V.66111 4 13.1t3i 6.6))0 1.5666 11.3DL1b6

S 13.151665 5.433313 f.b90 12.261YL

6 13.3231' 4.3S561 1.39/Uô 13.133'-9

I 1$.564 3.5Ifos: 1.3631t

I

II\'iEI\LPI L

N.ODL(-EIt'L51LE NEATCThNP\U H"'l r.i' INP1 /COPND >iJULL(E1 ( )=1 iNfvc= I C)N II NUE

OLD )DLL

9 19.96131 3.012139 .335401 13.S51996

10 22.77 1011 2.9S594' 2I'.i3o3 13.33 56-4

t.NU)} ,LEc SILLA1L.)N ENThrI/CJViAi\D5 >'-E

t\U OF' *tL?S2SESsIU'J A2 .17

REFLEX MODEL OF: English Channel Version 1

INVESTIGATORS:Overton and White

DATE: 4/12/73

TIME RESOLUTION: Weekly

QUANTITY: Biomass Equivalents

MODEL NUMBER: 1,0 TITLE: Ghost Module (G)

VARIABLES AND FUNCTIONS DIAGRAM

1. X LIST Description

xl Phytoplankton

x2 Consumers

x3 Detritus

Bacteria

x5 Free nutrients

x6 Phytoplankton demand by consumers

x7 Input to detritus by consumers A2. 18

2. Z FUNCTIONS Description

z1 = 13.2754 Insolation

4. GFIJNCTIONS Description

min[bl1_eb2x11_3x51b1) g1 Phytoplankton production

= min(x6,b5x1} Phytoplankton consumption by consumers.

g3 = b6g1 Nutrient demand.

Y FUNCTIONS

= xl

See description under X List.

y7 =

PARAMETERS

B PARAMETERS

List Value Description

b1 22. b1 in ECYC1. Maximum primary production (P.P.)

-.1 b in ECYC1. Coefficient of pytoplankton's influence on P.P.

-.1 b3 inECYC1. Coefficient of free nutrient influence on P.P. A2. 19

b1 -.1 b in ECYC1. Coefficient of insolation's influence on P.P.

b5 .41 b11 in ECYC1. Maximum proportion of phytoplankton which may be consumed in one week.

b6 .08 b5 in ECYC1. Stoichiometric parameter.

10. INiTIAL CONDITIONS

List Value

XN: x1 20

109.4

x 10 3

.7

x5 10

x6 8.163

x7 .4689

GENERAL RUN INFORMATION

TSTART = 0

TMAX = 104 q=

NO )NITORING

LP, DUMP: All y's

LP, DUMP frequency:

Variables to be plotted: 1' Y2' y3,yt+,Y5

Plot frequency: 1 A2 .20

MODEL NUMBER: 1,1 TITLE: Primary Production Module (PP)

DIAGRAM

VARIABLES AND FUNCTIONS

X LIST Description

xl Phytoplankton

Z FUNCTIONS Description

z1 = g1 in S Phytoplankton Production

z2 = g2 in S0 Phytoplankton consumption by consumers

5. F FUNCTIONS Description

= z - r x - z Production, respiration and 1,1 1 1 1 2 consumption

7. Y FUNCTIONS Description

= x1 ; y1 to x1 in S0 Phytoplankton biomass A2 .21

PARMIETERS

R PARANETERS List Value Description r1 .202634 r1 in ECYC1

INITIAL CONDITIONS List Value

XN: x1 20

GENERAL RUN INFORMATION

NO MONITOR, LP OR DUMP OUTPUT A2 .22

MODEL NUMBER: TITLE: Food Chain Module (FC)

DIAGRAM

VARIABLES AND FUNCTIONS

1. X LIST Description

xl Zooplankton

x2 Pelagic Fish

x3 Benthic Fauna

Demersal Fish

x5 Detritus Increment

2. Z FUNCTIONS Description

z1 = g2 in S.0 Phytoplankton consumption by consumers.

in S0 Phytoplankton demand by consumers (current)

= x7 in S Input to detritus from consumers (last cycle). A2. 23

G FUNCTIONS Description

g1=b2x2+b1x3 Demand on zooplankton

= min{g1,b5x1} Consumption of zooplankton

=z1b1x1/z2 Phytoplankton consumption by zooplankton

=z1b3x3/z2 Phytoplankton consumption by benthic fauna

F FUNCTIONS Description

f11=g3-r1x1 Consumption, respiration

f1,2 = gb2x/g1 Consumption of zooplankton by pelagic fish

= g2b31g1 Consumption of zooplankton by benthic fauna

=b8x1 Detritus input

f22 = -r2x Respiration

= b9x2 Detritus input

f33 = g-r3x3 Consumption, respiration

= min{b6x3,b7x} Consumptionofbenthic fauna by demersal fish

f35=bx3 Detritus input

f1.f =-r1x Respiration

f5=b11x1 Detritus input

f5 = -z3 Reinitialize detritus increment

7. Y FUNCTIONS Description

y1=b1x1+b3x3;y1to in Demand for phytoplankton

- + +x3+ Food chain biomass y2 tox2inS0 y3 = x5; y3to in S0 Detritus input from food chain A2. 24

P ARANETERS

8. B PARAMETERS

List Value Description

b1 .41 b6 inECYC1. Coefficient of phytoplankton consumption by zooplankton.

b2 .075 b8 in ECYC1. Coefficient of zooplankton consumption by pelagic fish.

b3 .056 b7 in ECYC1. Coefficient of phytoplankton consumption by benthic fauna.

b1 .007 b9 in ECYC1. Coefficient of zooplankton consumption by benthic fauna.

.17 b10 in ECYC1. Maximum proportion of zooplankton which may be consumed in one week.

.007 b14 inECYC1.Maximum proportion of benthic fauna which may be consumed in one week.

.1 b15 in ECYC1. Coefficient of benthic fauna consumption by demersal fish.

b5 .04 b16 in ECYC1. Coefficient of zooplankton input to detritus.

b9 .0016 b17 inECYC1. Coefficient of pelagic fish input to detritus.

b10 .0013 b18 inECYC1.Coefficient of benthic fauna input to detritus.

b11 .0017 b19 in ECYC1. Coefficient of demersal fish input to detritus. A2 .25

R PARAMETERS

List Value Description

r1 .3231115 in ECYC1.

.088367 in ECYC1.

r3 .119356 in ECYC1.

.0709257 in ECYC1.

INITIAL CONDITIONS

List Value

XN: 8.3

x2 9.9

85.

6.2

.4689

GENERAL RUN INPOBMATION

q= 1

NO MONITOR, LP OR DUNP OUTPUT A2 .26

MODELNUMBER: 1,3 TITLE: Interchange Uptake Module (lu)

zi, z2 ' y2 y3

xl x2 x3

DIAGRAM

VARIABLES AND FUNCTIONS

X LIST Description

Detritus

Microorganisms (bacteria)

x3 Free Nutrients

Z FUNCTIONS Description

in S0 Phytoplankton demand for free nutrients

z2 = in S0 Detritus input

3. GFUNCTIONS Description bx g1 = min{b1x2(l-e 2 1), x1 Growth increment of bacteria A2. 27

5. F FUNCTIONS Description

= Accumulation of detritus 1

= g1 Net growth of bacteria

= r1x2 Release of free nutrient

-z1 Accumulation of free nutrient

7. Y FUNCTIONS Description

y1 = x1; y1 to x3 in S0 Detritus

y2 = x2; y2 to in S0 Bacteria biomass

y3 = x3; y3 to in S0 Free nutrient

PARAMETERS

8. B PARAMETERS

List Value Description

b1 b12 in ECYC1

b -.1 b13 in ECYC1 2

9. RPARANETERS

List Value Description

r .9640958 r7 in ECYC1 A2.28

10. INITIAL CONDITIONS

List Value

XN: 10

.7

10

GENERAL RUN INFORMATION q=

TARGET: MONITOR: All g's

MONITOR frequency; 1

LP, DUNP: All y's

LP, DUMP frequency: A2.29

COMMENTS: This is an exact translation of the single level English Channel Cyclic Version 1 Model (Code: ECYC1).

BEHAVIOR: See notes under English Channel Cyclic Version 1 Model. A2. 30

PROGRAMS

00001:C ECRGZ1 00002* SUBROUTINE ZCOMP(K,X,BR,Z,TO,T) 00003; DIMENSION X(1),E(1),R()).Z(1) 00004, Z(1)-13.2754 00005* RETURN 00006: END 00007sC ECRGGI 00008: FUNCTION Gel CK,X,S,R?Z) 00009; DIMENSION X(1),9(1),R(1),Z(1) 00010* 00011: 1 (1 .-EXP(B(4)*Z(1 ))),X(5)/B(6)) 00012: RETURN 00013: END 00014: FUNCTION G02(K)X,B,R.Z) 00015: DIMENSION XC1),B(1),R(1),Z(;) 00016* G02-FMIN(X(6),B(5)*X(1)) 00017: RETURN 00018* END 00019; FUNCTION GO3CK.X,B,R,Z) 00020: DIMENSION XCI ),B(3 ),R(3 ),Z(1) 00021 * G03B(6)*G.1) 00022; RETURN 00023; END 00024C ECRGYI 00025; SUBROUTINE YCOMP(KIX,B,R,Y,X$,T) 00026: DIMENSION X(1).B(I,,R(1),y(1) 00027, Y(1).X1) 00028* Y(2)'X(2) 00029: Y(3)-X(3) 00030* 'f(4)wX(4) 00031: YC5)Xc5) 00032: YC6)-X(6) 00033: YC7.Xe7) 00034* RETURN 00035: END A2 .31

00001:C ECRPZI 00002: SUBROUTINE ZCOMP(K,X,B,R,z,TO,T,G) 00003: DIMENSION Xci ),BC1 ),R(1 ).Z(1 ).G(1) 00004; CALL UARIN((1),G(i,) 00005; CALL VARIN(Zc2),G(2)) 00006; RETURN 00017; END 00008sC ECRPF1 000098 FUNCTION F010l(K,X,B,R,Z) 00010: DIMENSION X(1),B(1),R(1),Z(1) 00011: F0iO1-Z(1 )-R(1 )*X(1 )-Z(2) 00012: RETURN 00013; END 00014; SUBROUTINE YCOMP(K,X,B,R,y,X5,T) 00015; DIMENSION X(1),B(1),R(1),y(1),X5(1) 00016: 'fCi)*X(l) 00017: CALL VAROUTCYc1),X$(I)) 00018$ RETURN 00019* END A2.32

00001:C ECRF1 00002: SUBROUTINE COMP(1<,ic, B, 10,T (-) 00003: DIMENSION ( 1),B( 1)h( 1),( 1),1-( 1) CALL VAhIN(( 1),G(2)) 00005: CALL VARIN(E(2),X(6)) 00006: CALL VARIN((3),X(7)) 00007: RETURN 00008: END 00009:C ECRfl-1 00010: FUNCTION 01(<,X,B,R,) 00011: DIMENSION X(1),B(1),R(1),(l) 00012: c01=b(2)*X(2)+E( 4)*X( 3 00013: RETURN 00014: END 00015: FUNCTION (02(K,,BsR,) 00016: DIMENSION X( 1),E( 1),R( 1),( 1) 00017: (-02=FMIN((-(1),B(5)*X(1)) 00018: RETURN 00019: END 00020: FUNCTION (03U<,X,b,R,) 00021: DIMENSION X(1),b(1),R(1),(1) 00022: Ø3( 1)*b( 1)*X( 1)/(2) 00023: RETURN 00024: END 00025: FUNCTION (04(<,X,B,R) 00026: DIMENSI ON X( 1), b( 1)s R( 1),( 1) 00027: ,04=( 1)*b(3)*X(3)/E(2) 00028: RETURN 00029: END 00030:C ECRFFI 00031: FUNCTION F0101(K,X,13,R,) 00032: DIMENSION X( 1),B( 1),k( 1),( 1) 00033: F0101=(3)-k(1)*X(1) 00034: RETURN 00035: END 00036: FUNCTION F0102(K,X1bR,fl 00037: DIMENSION X( 1).iB( l),h( 1),( 1) 00038: F0102=c-2*B(2)*X2)/C-(1) 00039: RETURN END 00041: FUNCTION FU103(K,X,b,Ri) 00042: DIMENSION X( 1),B(1),R( 1),(1) 00043: F0103=(-(2)*i3(4)*X(3)/(1) 00044: RETURN 00045: END A2.33

00046; FUNCTION F0105(K,XB,R,) 00047; DIMENSION X(1),B(1),R(1),Z(1, 00048: F0105B(3)*X(;) 00049; RETURN 00050: END 00051: FUNCTIoN F0202(K,x,S,R,z) 00052; DIMENSION X(1),B(I),R(;)zc1) 00053* F0202-R(2)*X(2) 00054; RETURN 00055: END 00056; FUNCTION F0205(}c,X,a,R,z) 00057! DIMENSIoN X(1),B(1),R(j),Z(1) 00058: F0205tB(9)*x(2) 00059; RETURN 00060; END 00061; FUNCTION F0303(g,X,B,RZ) 00062: DIMENSION X(1),8(1),R(1),Z(;) 00063* F0303.G(I&)-R(3)*X(3) 00064: RETURN 00065: END 00066: FUNCTION F0304(}C,X,B,R,Z) 00067: DIMENSION X(1),B(1),R(1),Z(1) "068: 069: RETURN 00070; END 00071: FiNCT ION F0305 (}C,X,, R Z) 00072: DIMENSION X(1),B(1),R(1),Z(1) F03O5B(1O)*X(3) 00074: RETURN 00075; END 00076: FUNCTION F0404(K,X,B,R,Z) 00077: DIMENSION X(1),B(1),R(I),Z(;) 00078w F0404-R(4)*x(4) 00079: RETURN 00080: END 00031; FUNCIQN F0405(}C,X,B,R,z) 00082: DIME1S!ON X(I),B(j),R(1),Z(;, 083; F0405ts1( 11 )*X(4) 000814: RETURN 00085: END 00086; FUNCTIONF0505(K,X,B,R,z) 00087; DIMENSIONX(1)IB(l),R(1),Z(1) "088; F0505=Z(3) 00089: RETURN 00090: END A2 .34

00091:C ECRFY1 00092; SUBROUTINE YCOMP(KJX,BPR,Y,XS.T) 00093$ DIMENSION XC1).Bc1)R(I),yc1),x$(1, 00094: 00095: YC2)X(I )+X(2)+X(3)+X(4) 00096; 00097: CALL VAROUTCYc 1 ),XS (6)) 00098; CALL VAROUT(Y(2,X5(2)) 00099: CALL VAROUT(Y(3),X$(7)) 00100; RETURN 00101: END A2.35

00001 iC ECRIZI 00002: SUBR()UTiNE ZCOMP(K,X9,R,Z,TO,T,G) X(1 )B(1 ),R(1 ),Z(1 ),G(1 ) CALL 00005: JNCZ(2),X(7)) 00006; 0e007 00003:C ECRIG1 00009* F7iZON G1(X,X,BR1Z) 00010; 1ti!N X(l),B(1),R(1),E(1) 0011; 00012; 00013; 014;C ECRIfl 00015: rWCTN F0l01OC,X,B,R,Z) 00016 X(1),BCi),R(1),Z()) 007: F14wZ(2) 00018* R1TtJRN 00019 00020; FUN F0102(K,X.B,R,Z) 00021; X(1 ),9(2 ),R(1 ),Z(1 ) 00022: 00023: 00024: 00025: FU'O1'i P0203(X,X,8,R,Z) 00026: ON XC1),B(1),R(1),Z(1) *X(2) 00029; kO r0303(K,XB,R,Z) 00031; Di XCI ).S(1 ),R(1 ),Z(1 ) 00032: 00033: 00034* 00035;C ECRIY 0036 x YCOp7P(,XB,R, Y,XS.T) 037 XC! ),B(t ),R(1 ),YC1 ),X5C1 ) 00038; Y 0003 00040: 00041: CAlL VoUT(Yc!)X$(3)) 00042 CALL.LeflCLJT(Y(2),XS(4)) 00043: CAL. 'floUTCY3XS(5)) A2 . 36

COMMAND 'ILE *ECRCONI

I: 133LGa F ( ) = 1 vJ4: J3iz=7 f'IA'c1.)4 =1 J4LOAO=Gt

)4:IF'Jt LOG 44.:LLi=2. Lr'(1) L'() Lr((3) LPY(Z) LY() LY() LtY(7) 46:OJLJ.J=1 4/i47 : 3 ( ) - .41 4E:i'J( )= 4119.414 .7, 13,. l3 3r:UjfL=EJ(3LI1 C{'J'JL è'LK r

44426: FL 1L= h3LI 1'JEL Et'LE ji -- s31.)r\I 'J. C. 44421: JSJM.' 43428: 1JtirLGr ( ) = 1,3 9:'JJ8=3 )=I"JiL3D=*ECj41 4.4434: FG1 .37)33j :YMA<=3 32:TFY=Y1) FFY=Y(2) fFYY(3) 34433: FTYI=:NI fJs rfy2=SACILr rrY3=JNIi'Jr 44434:Lr=Yj)LT(2) L'((3) 36:()=.96 958 44431:438:)sJ1'14, fFYF=81, 1.4 4.4439:fIFL!=E'.JGLI-f CdA\HL LE

I A2.37 TELETYPE RUN

#:JIP, 1=FIL2

#COPY, I1/: - "JO rr3jF3 C3MP - FO u1 rrc3S t3 ') 2 -'JO rOS (3 3 -'JO Err3S i/*F2LJO, 5,L=*

#WI li), 1 r'Fr.J, I*Cr'r1,X,0=1 #C0r(,I=I/ - "JO 0r<) F3: 3Yj -'JO E.r

#*F2LO\O, D6, L*rFXLI3 E74F-LJ'J 3 .'JAMEFOrF'J."JCFIJ"J 3VerL\Y.

#&.Ur'Y, 11f-' -'JO r<'J FJ ZCOMP - "'JO r

#LA5, 56 #E9I 10, I

1*4CtI , X,O I

#COy, I = I / -'40 EO5 F0 C3M - '13 £OS F3 G211 - NO Err<3 Gi2 - NO 'NOr F0 G3 NO E<-3tS F3 G NO 3r5 FOF1øI NO OS R3 -'43 E±OS i'3 413 -NO EO F3 t'4145 - N3Er3 tL)< -'40 E0r FO<

'43 Ci i'O: r'43IJ

- NO '3 ) 334' 'JO E:3rS r0' i")34 NO 3 FU - NO Et3S F3r j4t - NO -0rS FOr F453 -'40 Er'Or3 F'0: 'CO1P #*2L3AD., 6,L=*i(LI3 E.'J r LJ\J O FO FLJ'JCTIJ'J 3JELA'(. *ECr4 I A2.39

3@'ILt, i1L.' /4IILi #*tLEX2, L=44)=4J

* * * * * * * * * * * * * * * *4c * * * * * * * ** * * * * * * *FL(/OS3 J2.3 FLEX / 'FLEX GENAL MO)EL P.00ESSOr *********** ** ** ******************** ** **

MODELGEF MJST NEXT CJM1J1)

ENFErINPJFS,00N1MANDS >1 .'JP'JT= *(3'j

NtW MO L--NJMBEMJsr 3E 'JEXF COlM\'J&)

NEW M EL--NJM3 MJST E3E NEXT COMMA'h)

NEW MOOEL--NJM3E MiST 3E NEXf COMM4'JL)

OLDM3DEL

OLD MODEL

OLD MODEL

OLDMODEL

ENFEr1NP'JT3/C3a14'jDs >SIMULrE A2 . 40

GE 49/i9/74 1:33 M EGLIS1 G1A'J.'JEL rEFLEX tJ'J I -- I.U. CW 49091333 MO)EL SEflNCE 'JO.1340 344 4404

TIME DETtI TJS 84C1E.0 .'JUiIE'J F

'4 14 744404 1 0

8 3.181962 .663359 14.415645 16 3.542438 .448149 8.876795 24 4.623 .043335 4.146714 32 4.334351 .040322 1.316454 40 4.492563 .044442 .993132 48 4.582156 443r44 .79134 56 4.634364 .0344 .778751 64 4.651828 .040034 773689 72 4.661761 .000444 .773689 84 4.666534 .033044 .778689 88 4.668903 .044444 .778689 96 4.674149 .044444 .778689 144 4.674736 .403000 .778689

EJO OF FLEX SIMULFIO'J

ri.I\IPJFS/CQMMA.'JD5 >5 lOt'

E) OF *FL<2 SESSIO'4 A2 .41

REFLEX MODEL OF: English Channel Version 2

INVESTIGATORS: Overton,White

DATE: 11/26/73

TIME RESOLUTION Weekly

QUANTITY: Biomass Equivalents

MODEL NUMBER: 2,0 TITLE: Ghost Module (G)

RESOLUTION

Weekly

S3 Interchange Weekly and Uptake = 1

ALGORITHM DIAGRAM

CONCEPTUAL DIAGRAM A2 . 42 VARIABLES AND FUNCTIONS

1. X LIST Description Pkytoplankton biomass Food chain bioivass Detritus Bactaria biotuass Free nutrient Food chain demand for pliytoplankton Input to detritus by food chain

2. Z FUNCTIONS Description z1= 13.2754 Insolation

Y FUNCTIONS Description

See X list

= x7

PARAMETERS

10, INITIAL CONDITIONS

St Value

x1 20 109.4

1Q

x5 10 x6 8.163 x7 .46888 A2 .43

GENERAL RUN INFORMATION

TSTART = 0

TMAX = 104 q=

NO MONITORING

LP, DUMP: All y's

LP, DUMP frequency: 1

Variables to be plotted: y1, y5

Plot frequency: 1 A2 .44

MODEL NUMBER: 2,1 TITLE: Primary Production Module (PP)

zi, z

VARIABLES AND FUNCTIONS

X LIST Description

xl Phytoplankton biomass

Z FUNCTIONS Description

z = z in S Insolation 1 1 o

z = x in S Free nutrients 25 o = x6 in S Phytoplankton demand byconsumers = mm (z3, b5x1) Phytoplankton consumption byconsumers

4. G FUNCTIONS Description

min1(1 b2x1) (l_eb3Z2)(l_eb4Z1) z2/b6 Phytoplankton production

F FUNCTIONS Description

= - r1x1 - Production, respiration, consumption

7. Y FUNCTIONS Description

yl = x1, y1 to x1 in Phytoplankton biomass A2 .45

PARAMETERS

8. B PARAMETERS Description

List Value

b1 22 Maximum primary production (PP)

b2 -.1 Coefficient of phytoplankton's influence on PP

-.1 Coefficient of free nutrient's influence on PP

b4 -.1 Coefficient of insolation's influence on PP

b5 .41 Maximum proportion of phytoplankton which may be consumed in one week

b6 .08 Stoichiometric parameter

9. R PARAMETERS Description

List Value

r1 .202634 Respiration coefficient of phytoplankton

10. INITIAL CONDITIONS

List Value

XN: x 20

GENERAL RUN INFORMATION

q= 1

NO MONITOR, LP OR DUNP OUTPUT A2.46

MODEL NUMBER: 2,2 TITLE: Food Chain Module (FC)

VARIABLES AND FUNCTIONS

1. X LIST Description

xl Zoop lankton

x2 Pelagic Fish

Benthic Fauna

Demersal Fish

Detritus Increment

Phytoplankton demand by consumers

2. Z FUNCTIONS Description

=X1 In S0 Phytoplankton biomass

= mm (x6, b12z1) Phytoplankton consumption by consumers

4. G FUNCTIONS Description

= b2x2 + b4x3 Demand on zooplankton

= mm (g1, b5x1) Consumption of zooplankton

= z2b1x1/x6 Phytoplankton consumption by zooplankton 3 g4 = z2b3x3/x6 Phytoplankton consumption by benthic fauna A2 .47

5. F FUNCTIONS Description

f1,1 = g3 - r1x1 Consumption, respiration

fi,2 = gbx/g Consumption of zooplankton by pelagic fish

f1,3 = Consumption of zooplankton by benthic fauna

f1,5 = b8x1 Detritus input

-rx Respiration

= b9x Detritus input

f3,3 = g4 - r3x3 Consumption, respiration

f34 = min{b6x3 b7x4 Consumption of benthic fauna by demersal fish

f3,5 = bx3 Detritus input

f4,4 = -r4x4 Respiration

f4,5 = b11x Detritus input

f5,5 = -x5 Reinitialize detritus increment

6. H FUNCTIONS Description

h6 b1x1 + b3x3 Calculate phytoplankton demand by consumers

7. Y FUNCTIONS Description

y1 x1 + + + X4; Food chain biomass

y1 to x2 in S0

= x6;y to in Demand for phytoplankton S y3 bx1 + b9x2 + b10x3 b11x4;

y3 to in Detritus input from food chain S A2.48

PARAMETERS

8. B PARAMETERS

List Value Description

b1 .41 Coefficient of phytoplankton consumption by zooplankton

.075 Coefficient of zooplankton consumption by pelagic fish

.056 Coefficient of phytoplankton consumption by benthic fauna

.007 Coefficient of zooplankton consumption by benthic fauna

.17 Maximum proportion of zooplankton which may be consumed in one week

.007 Maximum proportion of benthic fauna which may be consumed in one week

.1 Coefficient of benthic fauna consumption by demersal fish

.04 Coefficient of zooplankton input to detritus

.0016 Coefficient of pelagic fish input to detritus

b10 .0013 Coefficient of benthic fauna input to detritus

b11 .0017 Coefficient of demersal fish input to detritus

b12 .41 Maximum proportion of phytoplankton which may be consumed in one week A2 . 49

R PARAMETERS

List Value Description

.3231115 Respiration coefficient of zooplankton

.088367 Respiration coefficient of pelagic fish

.119356 Respiration coefficient of benthic fauna

.0709257 Respiration coefficient of demersal fish

INITIAL CONDITIONS

List Value

XN: 8.3

x2 9.9

x3 85.

6.2 4 x5 .46888

x6 8.163

GENERAL RUN INFORMATION q=

NO MONITOR, LP OR DUMP OUTPUT A2. 50

MODEL NUMBER: 2,3 TITLE: Interchange and Uptake Module (IU)

Zi, Z2, Z,Z Yl' Y2, Y3

x2 x3 'V I

VARIABLES AND FUNCTIONS

1. X LIST Description

xl Detritus

Microorganisms (Bacteria)

Free Nutrients

2. Z FUNCTIONS Description

=Z1 in S Insolation

z2 = x1 in S Phytoplankton biomass 1b3(l_eb4Z2) (l_eb5X3) (l_eb6)1 - mm Phytoplankton Lx3hl)7 J production in S Detritus input from food chain 0

4. G FUNCTIONS Description

g1 =minb1x2(l_eb2X1), x1}Growth increment of bacteria

g2 = b7z3 Nutrient demand A2. 51

5. F FUNCTIONS Description

fl,1 = Accumulation of detritus

= g1 Net growth of bacteria

= r1x Release of free nutrient

f3,3 = -g Free nutrient uptake by phytoplankton

7. Y FUNCTIONS Description

y1 = x1; y1 to x3 in S Detritus 0 x2; y2 to x4 in S0 Bacteria biomass

y3 = x3; y3 to in S Free nutrient

PARAMETERS

8. B PARAMETERS

List Value Description

b1 2 Bacteria growth. rate coefficient

b2 -.1 Coefficient of detritus influence on bacterial growth

b3 Maximum primary production (P. P.)

b4 Coefficient of phytoplankton's influence on P.P.

Coefficient of free nutrient's influence on P.P.

b6 Coefficient of insolation's influence on P.P.

Stoichiometrjc parameter A2. 52

R PARANETERS

List Value Description

.9640958 Respiration coefficient of bacteria

INITIAL CONDITIONS

List Value

XN: 10

x2 .7

10

GENERAL RUN INFORNATION

q= 1

TARGET: MONITOR: All y's

MONITOR frequency: 1

LP, DUMP: All y's

LP, DUMP frequency: 1 A2.53

PROGRAMS

00i;C ECRIZ2 00002: SUBROUTINE ZCOMPCK,X.,B,RIZ,T0,T,G) 00003: DIMENSION X(l),B(1),Rc1)jz(1),c(1) 004; CALL VARIT4(Z(1),Z(1)) 00005: CALL. VARIIq(Z(2),X(;)) 00006; 00007* 008; CALL VARIt4(Z(4),x(7)) 00009: RETURN 00010; END 00011:C ECRGG2 00012; FUNCTION 001 (K,X,B,R,Z) 00013: DIMENSION X(1),B(1),R(l),Z(1) 014; GOIicFMINBtI*X(2)*(1.....EXp(B(2)*X(1))),X(l)) 00015: RETtYTt 00016: END 00017: FUNCTION G02(K,X,B,R,Z) 00018; DIMENSION X(1),B(3),R(1),Z(I) 00019: G02rE(7)*Z(3) 00020; RETURN 00021; END 00022:C ECRIF2 00023: FUNCTION F01OJ(K,X,B,fi,Z) 00024 DIMENSION X(1),B(1),R(1),z(I) 00025: F0101Z(4) 00026: RETURN 00027: END 00028; FUNCTIoN F0102(K,X,B,R,Z) 00029; DIMENSION X(l),B(1),R(l).Z(1) 030: F0102c3(1) 00031: RETURN 00032: END 00033; FUNCTION F0203(}(,X,B,R,Z) 00034: DIMENSION X(1),B(1),R(1),Z(1) 00035: FO2O3R(1 )*X(2) 00036: RETURN 00037: END 00038; FUNCTION F0303(K,X,e,R,z) 00039 DIMENSION X(1),9(1),Rc1),z(1) 040: F03O3G(2) 00041 RETURN 00042 END 00043;C ECRIYI SUBROUT INE YCOMP CM, X, B, R,Y, XS, T) 045 DIMENSION Xci ),B(j ).R(1 ),y(J),X5(1 ) A2. 54

00001C ECRFZ2 00002; SUBROUT INE ZCOPIP (K, X, B, R, Z, TO. 1,G) 00003* DIMENSIoNX(3),9(1),B(l,,Z(l),G(l) 00004: CALL. VARINZ(1,,X(1,) 00005, Z(2)FMIH(X(6),B(12)*Z(1,) 00006: RETURN 00007, END 00008:C ECRFG2 00009: FUNCTION 001(K,X,B,R,Z) 00010: DIMENSION X(1)B(1),R(1),Z(1, 00011: G01-B(2)*X(2)+8(4)*X(3) 00012; RETURN 00013: END 00014* FUNCTION G02(K,X.B,R,Z) 00015: DIMENSION X(1),B(1),R(l).z(1) 00016: G02FMDj(G(1 ),0C5)*X(I)) 00017: RETURN 00018; END 00019: FUNCTION G03(K,X,B,R,z) 00020: DIMENSION X(1),$(l),R(1),Z(I) 00021: G03-Z(2)*B(1 )*XC1 )/X(6) 00022, RETURN 00023; END 00024; FUNCTION G04(K,X,B,R,Z) 00025: DIMENSION X(1),B(1).R(1),Z(1) 00026: G04Z(2 )*B(3 )*X(3 )/X(6) 00027; RETURN 00028: END 00029* C ECRFF2 00030: FUNCTION FOIO1(K,X,E,R,z, 00031: DIMENSION X(l),B(1),R(I),Z(1) 00032: F0101-Gc3,R(1 )*X(1) 00033* RETURN 00034: END 00035: FUNCTION F0102(K,X,9,R,Z) 00036: DIMENSION X(l),B(1 ),R(1 ).Z(1) 00037: F0102.G (2 )*S (2 )*X(2 ),(3 (1) 00038; RETURN 00039: END 00040: FUNCTION F0103(K,X,B,R,z) 00041 * DIMENSION X(i ).B(1 ),R(1 ),Z(1 ) 00042: F0103-G (2 )*S (4 )*XC3 )/G CI) 00043: RETURN 00044$ END 00045: FUNCTION ?0105(K,X,B,R,Z) A2. 55

00046; ?(i)XC1) 00047; 00048; YC3)Xc3) 00049: CAL!.. VAROUT(Y(1),X$(3)) 00050* CALL VAROUT(Y(2),X$(4)) 00051; CALL. VAROUT(Y(3),XSC5)) 00052: RETURN 00053: END

00001;C ECRPZ2 00002; SUBROUTINE ZCOMP(M,X.,B,R,z,TO,T,G) 00003; DIMENS'N X(1),B(1),R(1),Z(1,,G(1) 0O4; CALL VARIN(Z(1),Z(l)) 0Ø5; CALL VARIN(Z(2),X(5)) CALL VARIN(Z(3)Xc6)) 00007: Z(4)-FMIN(B(5)*X(; ),(3)) 00008: RETURN 00009; END 00010;C ECRPGI 00011; FUNCTION G01 (K1X,B.R,Z) 00012: DIMENSION X(1)B(1)jiR(I)Z() 00013: 0 A*(1..EXP(B(4)*Z(1 ))),Z(2)/B(6)) RETURN 00016; END 00011;C ECRPF2 J018; FUNCTION F01O1(K,X,B,R,Z) 00019: DIMENSION X(l),B(1:.R(1),z(1, 00020: 00021* RETURN 00022: END 00023:C ECRPYI 00024; SUEROUTINE YCOMP(K,X,8,R,y,x$,T) DIMENSION XCI ),8(1 R(I ).Y(1 ),XS(1 ) 00026: YC.X(1) 00027 CALL VAROtITCYC I ),XS( 1)) 00028; RETURN 00029: A2 56

00046: DIMENON X()4,BC1),R(I),Z(1) 00047: F005B(8)*X(l) 00048: RETURN 00049: END 00050; FUNCTION F0202(K,X,9,R,Z) 00051: DIMENSION XCI ),(1 ),R(1 ),ZC1 ) 00052: ?0202R(2)*x(2) 00053: RETUN 00054: END 00055: FUNCTION FO2OSCM.,X,B,R,z) 00056: DIMENSOJ X(1),B(1,,R(l),Z(1) 00057; F020(9)*X(2) 00058: RETURN 00059: END 00060: FUNCTION F0303(K,X,B,R,z) 00061: DX$ØN X(1),B(I),R(I),Z(I) 00062: F030wE3(4).R(3)*X(3) 00063: RETURN 00064: END 00065: FUNCTION F0304(K,X,B,R,Z) 00066; DIMENSION X(!),S(1),R(1),Z(1) 00067: F0304*FMIN(B(6)*X(3),B(7)*X(4)) 00068: RETURN 00069: END 00070: FUNCTION F0305:,X,B,R,z) 00071: DIMENSION X(I),B(1),R(I),Z(1) 00072: F0305rE(1O)*X(3) 00073: RETURN 00074: ND. 00075: FUNCTZON F0404(K,X,B,R,Z) 00076: DIMENSION XCI)8(1),R(1),Z(l) 077: F044R(4)*X(4) 00078: RETURN 00079: END 00080: FUNCTION F0405cKX,B,R,Z) 00081* DDIENSION X(1)B(I),R(1),Z(1) 00082: F04O5BU 1 )*X(4) 00083: RETURN 00084; END 00085: FUNCTION F0505(K,X,B,R,Z) 00086: DIMENSION X(1),B(1),R(1),Z(;) 00087: F05O5X(5) 00088: RETURN 00089: END 00090:C ECRFY2 A2 /57

00091: SUBROUTINE YCOMP(K,X,B,R,y,XS,T) 00092, DIMENSIONX(1),B(1).,R(3),y(1),XS(1) 00093 Y(1)X(1 )+X(2)+X(3)+X(4) 00094* YC2).X(6) 00095: 00096: CALL VABOUTrYcl),XS(2)) 00097: CALL 'JAROUT(Y(2)X$(6)) 00098: CALL VAROUT(Y(3),XS(7)) 00099: RETURN 00100: END OO101sC ECRFHI 00102$ FUNCTION H06(1<,X.B,R,z) 00103: DIMENSION X(1),B(J),R(1),Z(1) 00104: H06.B(1)*Xc1)+B(3)*X(3) 00105: RETURN 00106: END

00001*C ECRGZI 00002; SUBROUTINE ZCOMP(JCsXB,RaZaTO,T) 00ø03 DIMENSION X(1),B(1),R(1),Z(1) 00004: ZC1)-13.2754 00005: RETURN 00006: END 00007:C ECRGYI 00008: SUBROUTINE YCOMP(K,XJB,R,Y,XS,T) 00009; DIMENSIONX(I).B(1),R(j),y(I) 00010: YI)-X(1) 00011: Y(2)-XC2) 00012, Y(3).X(3) 00013: Y(4)aX(4) 00014: Y(5)-X(5) 00015: Y(6)-X6) 00016: Y(7)aX(7) 0001?: RETURN 00018: END A2.58

CW4AND FILE *ECRCON2

00001:MOL)ELC-ET( )2, 3 00002:NU?iBER=3 0=1 FUNLJAD=*ECRJ 02 00003: TAROET 00004: YAX=3 00005:T1y=y(1) TTY=Y(2) TTY=Y(3) 00006: TTY 1=UETtJ TUS TTY2=EACTERI A TTY3NUTRJ ENT 00001:LP=YC1) LP=Y(2) LP=Y(3)

00009: f( )= 9640958 00010:XNC )= 10, .7 10 0001 1:TITLE=ENOLISH CHANNEL REFLEX RUN 2 -- I .U. CW 000 12:ODEL0ET( )=2, 1 00013:NU1jER=1 0=1 FUNLc.AD=*ECRpO2 00014:TTYQFF LO0NJDUMP 00015:LPLUN=25 LP=Y(1) 000 16 : )=. 2026 34 I?c o ,- C )/JA 1.fiJcc). 1,.L,.I,.4 I . 00018:XNO=20 000 19:NDSUvARy 00020:TITLE=EN(:LIsH CHANNEL REFLEX RUN 2 P.P. CW. 00021 :MODELOET( )=2, 2 00022:NUNOER=6 0=1 FUNLOAD=*ECRFO2 00023:TTYQFF NODUMP LO1 00024:LPLUN=30 LP=X(1) LP=X(2) LP=X(3) LP=X(4) LPX(5) LPX(6)

00026:b( )= .3233115,. O88367 1119356, 0709257 00027:XN()=8.3,9,9,85,6,2,.46888,8.163 øO028:TITLE=LNt.LI5H CHANNEL REFLEX RUN 2-- FOOD CHAIN. CW 00029 : NJ SUMMARY 00030:M)DEL(-ET( )2 0003I:NU3ER7 TMAX=1040=1 FUNLOAD=*ECROO2 00032:YMAX=7 øU33: IIYOFF LO(- DUMP 00034:LPLUN=20 LP=Y(1) LP=Y(2) LP=Y(3) LFY(4) LPY(.5) LP=Y(6)LPY(7) 00035: UUMPLUN=21

O0037:T1iLE=ENLI5H CHANNEL RERLEX RUN2 -- OHOST. CW 00039:1QDEL(-ET=2 FIRSTSUI3Q=2,l 00040:MODEL(ETO=2,j OHOSTQ=2 fcj(-HTSUE()2,2 O'1:MODEL(-ETc=2,2 OHQSTQ=2 LEFTSUF()=2,1 RI(HTSUEc:)=2,3 00042:MODELCET( )=2, 3 OHOST( )=2 LEFTSUb( )2, 2 00043:INPUT=6O A2.59

TELETYPE RUN

#JI?, 1=FLL E3rJ I=**3

E.'JFE LJ'J O 'JAM FLH tJ.'JCrI3.'J OJLAY. *C:jvj2 A2 .60

#-ELE\SE, 6 #EWI 'Ji), 1 1=**rcj, )(,O1 C3PY. 11 /r -'J3Er3rIJ ZC3MP - 3 i'3r FOr YCOM

4f LJ4 3 '4AMi FJr< OJL4Y. *EC32 #EIJJELASE, I 6 #'OrTr'\1,

#OOPY, I=1 /.- -'J3 OSF3r C3I 'JO JS FO G)1 :o JJH (3 'O E:'NOS FOr '4 I I -J3 E3r F43 3 rQ F3 F'4?3 -'JJ io '3)3 -.'J3Er'N3 r'3r YCO1? #*F2LOAO, 56,L=*FLIa E'1rE L'J'J3- 'JME FOr FJ'JCrIOJ J./ELAY. #LAS 36 #Wj4O, I #FQf4;,I=**EC*2, 0=1 4C3,Y,I=I/ - JO rrOS FO ZCJM, -'JO O-S F3 G1 -'JO Er'O.-3g'J F(')11 - 'JO FO YCOMP #'.LOD, 56,L=FiLli3 'J1Er'LJJ Or.'JM FO J'JCFIO JILtY. 4J'4flI, I #)JIt,=IL, 44=iILt A2.61

?#*FLEX2, L4sO44

*FLEX2/0S3 FLEX / rEFLEX GEAL MODEL 'rOCESSOr ******* *******************4************ MJDELGEF1JST 3E 4EXF CDMM'JD i'J-'Jrs/c3MM'Jos >p.jpj r=*rco '4E4 MOOELJM3Er MJSF 3E Exr COMMAh) NW MODEL--.'JJMB MUSF 3E JEXf COMMA'h)

NEW MODEL-- JM3EI MJST BE EXF COMMA\D

OLD MODEL

OLD MODEL

OLD MODEL

OLD MODEL

E'4FE I\JPJTS/COMN1ANDS >:osJi1ry>MJDELGEF( )=2, rrr= 3 OLD MODEL

E"Ji) OF *rLiç SESSION 1E 5WOr( A2.62

#-sEr, #*FLEX2, Lz44, D43, C. WZWOR.< E'JFER INPJrS/COMM;\JOS SI M iL A r

PAGE @9/17/74 9:1a AM ENGLISH CHA'HEL REFLE.

rIME DErRIrus BACTERIA 'FJIRIE'JF

0 1.@32J .70i000 10.c 8 3.181962 .663359 14.015645 16 3.502038 .008149 8.876795

#MI

MODELGET MJST BE NI(F COMMANi)

ENTER INPUFS/COMMANDS >FrEEZE

END OF *FLE2 SESSION

#RESET,52),59 #*FLEX2, L=44, 0=40, C, W=WOR<

ENTER INPJTS/COMMANDS >CON F I 'JUE 24 4.044623 .000305 4.146710 A2.63

32 4.334051 .000022 1.816054 40 4.492563 .000002 .993132 48 4.582156 .000000 .791840 56 4.630364 .000000 .778751 64 4.651828 .000000 .778689 72 4.661761 .000003 .778689 80 4.666534 .000000 .778689 85 4.665903 .0000.0.0. .778689 96 4.67010.9 .000000 .778689 104 4.670736 .000000 .778689

END OF' REFLEX SIMULATION

ENTER INPUTS/COMMANDS STOP

END OF *FLEX2 SESSION A3.1.

Aill. Use of *FL3

*FL3 is an alternate version of *FL2 with reduced size and cheaper, faster processing. Each module is represented in the computer by a data block in which all values are stored and with a function overlay on which all user detailed functions are stored. Because of limited core size, data blocks and function overlays must be swapped in and out of core. *F'TX3 uses smaller data blocks. Thus reduces swap time for data blocks.More data blocks may be in core at one time (10 vs 3) which even further reduces swapping and greatly increases processor speed.

The following table summarizes the differences between *FLEX2 and *FLEX3

Maximum number of *FLEX2 *FLEX3

x variables 63 20 z inputs 40 20 y outputs 50 30 b parameters 100 50 r parameters 20 20 g functions 70 35 f functions 63 20 h functions 63 20 Memory Variables 200 250

Function overlay processor *F2LO *F3LOAD

In all other respects, *FLEX2 and *FLEX3 are compatible. Satellite programs accept both dump file types. A4. 1

A.IV User Feedback Sheet

Although *FLEX2 and *FLEX3 havebeen carefully scrutinized and de- bugged, it is well known thatany non-trivial program has bugs. If you discover a bug, we would liketo know about it. Also, if you would like to be put on a mailing listso that new commands, processor improvements, release of new versions,etc. can be sent to you, please indicateso.

Any comments or questionson any part of the manual would be appreciated.

Address all correspondenceto:

FLEX Users Group doW. Scott Overton Forest Research Lab Oregon State University Corvallis, Oregon 97331

Name:

Address:

I would likemy name added to your mailing list.

COMMENTS, QUESTIONS, BUGS: