university of 
 
 illinois library 
 At urbana-champaign 
 
The person charging this material is re- 
 sponsible for its return to the library from 
 which it was withdrawn on or before the 
 Latest Date stamped below. 
 
 Theft, mutilation, and underlining of books are reasons 
 for disciplinary action and may result in dismissal from 
 the University. 
 To renew call Telephone Center, 333-8400 
 
 UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN 
 
 <L o 
 
 %*. ' ° m 
 
 
/V,' I 
 
 U(aJ. 
 
 m<ui\ 
 
 UIUCDCS-R-77-866 
 
 UILU-ENG 77 1717 
 COO-2383-0039 
 
 nt 
 
 A UNIVERSAL LANGUAGE FOR CONTINUOUS NETWORK SIMULATION 
 
 by 
 Thomas Fred Runge 
 
 
 May 1977 
 
 DEPARTMENT OF COMPUTER SCIENCE 
 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 
 
 URBANA, ILLINOIS 
 
 OniveTSity oi Illinois 
 ,t Urbana Cti: 
 
UIUCDCS-R-77-866 
 
 A UNIVERSAL LANGUAGE FOR CONTINUOUS NETWORK SIMULATION* 
 
 by 
 Thomas Fred Runge 
 
 May 1977 
 
 DEPARTMENT OF COMPUTER SCIENCE 
 
 UNIVERSITY OF ILLINOIS AT URB ANA- CHAMPAIGN 
 
 URBANA, ILLINOIS 61801 
 
 *Supported in part by the Energy Research and Development Administration 
 under contract US ERDA/EY-76-S-02-2383, and submitted in partial 
 fulfillment of the requirements of the Graduate College for the degree 
 of Doctor of Philosophy. 
 
Digitized by the Internet Archive 
 in 2013 
 
 http://archive.org/details/universallanguag866rung 
 
iii 
 
 ACKNOWLEDGMENTS 
 
 The author wishes to express his gratitude to Professor C. W. Gear 
 for his invaluable ideas and supervision. The author is also indebted to 
 Peter Watterberg and Mitchell Roth for their efforts toward implementing 
 the graphical and numerical software, to Al Whaley and Neal Hennegan for 
 their useful advice, and to Barbara Armstrong for her speedy and accurate 
 typing of this thesis. Finally, the author extends his appreciation to the 
 Energy Research and Development Administration for their financial support. 
 
IV 
 
 TABLE OF CONTENTS 
 
 Page 
 
 1. INTRODUCTION 1 
 
 1.1. Introduction of Research — Continuous Network 
 
 Simulation Languages 1 
 
 1.2. Definition of Digital Continuous Simulation 3 
 
 1.2.1. Continuous/Discrete Digital Simulation 3 
 
 1.2.2. Digital/Analog Continuous Simulation 6 
 
 1.3. Sample Network Problem 9 
 
 2. SURVEY OF DIGITAL SIMULATION LANGUAGES. 17 
 
 2.1. Essential Simulation Processes 17 
 
 2.2. Basic Language Characteristics 18 
 
 2.3. Essential Features of Simulation Languages 25 
 
 2.4. The First Simulation Languages — Digital Analog Simulators 25 
 
 2.4.1. ASTRAL 26 
 
 2.4.2. DYSAC 27 
 
 2.4.3. JANIS 28 
 
 2.4.4. MIDAS 29 
 
 2.4.5. PACTOLUS 29 
 
 2.5. Early Equation-Oriented Languages 30 
 
 2.5.1. Functional Capabilities 32 
 
 2.5.2. Statement Format 33 
 
 2.5.3. Built-in Operators 33 
 
 2.5.4. Facilities for Extending the Operator Set .... 36 
 
 2.5.5. Diagnostics 39 
 
 2.6. Modern General Purpose Languages 40 
 
 2.6.1. General Trends 40 
 
 2.6.2. CSSL-III 45 
 
 2.6.3. CSMP-III 48 
 
 2.6.4. RSSL 48 
 
 2.6.5. DARE-P 50 
 
 2.6.6. ACSL 53 
 
 2.6.7. GASP IV 53 
 
 2.6.8. Tabular Summary of Modern General Purpose Features 54 
 
 2.7. Special Purpose Languages — Electrical Circuit Analysis. . 56 
 
 2.7.1. ECAP 56 
 
 2.7.2. AEDNET 57 
 
 2.7.3. ECAP-II 57 
 
 2.7.4. SCEPTRE 58 
 
 2.7.5. SUPER*SCEPTRE 58 
 
 3. THE MODEL LANGUAGE 65 
 
 3.1. Introduction — Design Goals and Fundamental Features ... 65 
 
 3.2. Graphical and Card-Oriented Modeling 68 
 
 3.3. Overall Model Structure — Elements and Subelements .... 70 
 
Page 
 
 3.4. Element Definition 70 
 
 3.4.1. Element Modeling Sequence — Parameters and 
 
 Default Values 70 
 
 3.4.2. Global and Local Variables and the Independent 
 Variable 73 
 
 3.4.3. Topology — Terminals, Terminal Types, Terminal 
 Variables, and the Generalization of Kirchoff's 
 
 Laws 74 
 
 3.4.4. Connections and Subelement Invocation 79 
 
 3.4.5. Equations 85 
 
 3.4.6. Logical Switching of Equations 95 
 
 3.4.7. Initial Value Assignment 98 
 
 3.4.8. Termination Logic 98 
 
 3.4.9. Output 100 
 
 3.5. Function Subprograms, Subroutines, and Table Functions. . 101 
 
 3.6. Run-Control 104 
 
 3.6.1. Parameter Assignments 105 
 
 3.6.2. Model Invocation and Response Testing 106 
 
 3.7. Diagnostics 107 
 
 CONCLUSIONS 114 
 
 4.1. Present Implementation of MODEL 114 
 
 4.2. Possible Extensions of MODEL 117 
 
 4.2.1. Portable Library Support 117 
 
 4.2.2. Other Terminal Variable Types 119 
 
 4.2.3. Higher Order Derivatives and Derivatives 
 
 of Expressions 119 
 
 4.2.4. Additional Array Operators 120 
 
 4.2.5. Additional Strip Terminal Operators 121 
 
 4.2.6. Logically Structured Blocks of Equations 122 
 
 4.2.7. Initial Values and Ranges 122 
 
 4.2.8. Boundary Values 123 
 
 4.2.9. Additional Output Operators 123 
 
 4.2.10. On-line Simulation 123 
 
 APPENDICES 
 
 MODEL TEXT DIALECT STATEMENTS AND THE ORDER OF THE 
 
 INPUT FILE 127 
 
 B. SAMPLE MODEL AND OUTPUT 131 
 
 C. IBM 360 BATCH MODE JOB CONTROL 143 
 
 D. MODEL ERROR MESSAGES 149 
 
 VITA 153 
 
VI 
 
 LIST OF FIGURES 
 
 Page 
 
 1.1. Overall structure of the MODEL continuous simulation package . 2 
 
 1.2. Graphical representations of storm sewer network elements. . . 14 
 
 2.1. Major classifications of digital continuous simulation 
 languages 21 
 
 2.2. Macros for an electrically controlled pressurized process, S . 39 
 
 2.3. Table of features of modern general purpose packages 55 
 
 3.1. Mnemonic pictures for topological macros 69 
 
 3.2. Terminal type definitions 78 
 
 3.3. Voltage summer 83 
 
 3.4. MODEL operators and precedences 87 
 
 3.5. MODEL built-in functions 88 
 
 3.6. Capacitor 91 
 
 3.7. Spring 92 
 
 3.8. Reservoir 93 
 
 3.9. Static, prismatic beam in two dimensions 95 
 
 3.10. Idealized hysteresis loop with slope S 97 
 
 3.11. MODEL system control parameters 106 
 
 3.12. Format of MODEL error and warning messages 110 
 
 4.1. Strip terminal summing element 121 
 
 Bl. Storm sewer network 134 
 
1. INTRODUCTION 
 
 1.1. Introduction of Research — Continuous Network Simulation Languages 
 
 The research on which this thesis is based was undertaken as part 
 of the development of a general purpose package for digital simulation of 
 continuous systems based on ordinary differential equations. The overall 
 structure of the package which has been developed is outlined in Figure 1.1. 
 In particular, this thesis is concerned with continuous simulation modeling 
 languages and with the design and development of MODEL, a 'universal' 
 language for continuous network simulation, for use within this package. 
 Thus, we will be concerned primarily with the processes of Figure 1.1a — 
 that is, with the language features which support the formulation of 
 continuous system models. We will concern ourselves with the implementations 
 of the modeling support, model analysis, and integration processes only to 
 the extent that these implementations facilitate or encumber the provision 
 of desirable modeling language features. 
 
 Our research efforts were guided by both short-range and long- 
 range goals. Our short-range goal was to produce and distribute a widely 
 applicable and easy-to-use language for continuous network simulation, to 
 the long-range end of furthering the study of languages for simulation in 
 the physical sciences. By distributing the language to a number of 
 installations where different types of continuous simulation problems are 
 being studied, we will be able to measure the utility of various language 
 features within the context of this class of problems. 
 
 These primary goals led us to a set of secondary short-range 
 objectives for the language to be developed. Our desire for a language 
 which is widely applicable and easy to use implies that the language 
 should be flexible enough to accommodate very complex networks, yet require 
 little sophistication for simple problems. Thus, the language should 
 support different levels of problem and user sophistication. The desire 
 to facilitate the modeling of complex networks led us to desire to support 
 hierarchical models conveniently, since most physical systems are naturally 
 hierarchical — that is, they can be described at a series of levels of 
 increasing complexity. To facilitate distribution of the language to a 
 number of installations having potentially different hardware and operating 
 
c 
 
 
 o 
 
 
 •H 
 
 
 4-1 
 
 
 CO 
 
 
 u 
 
 
 M 
 
 
 CD 
 
 
 4-1 
 
 
 c 
 
 
 •H 
 
 
 TD 
 
 (1) 
 
 G 
 
 60 
 
 cfl 
 
 CO 
 
 
 M 
 
 en 
 
 a 
 
 •H 
 
 to 
 
 en 
 
 D- 
 
 >^ 
 
 
 iH 
 
 c 
 
 CO 
 
 o 
 
 C 
 
 •H 
 
 to 
 
 4-1 
 
 
 CO 
 
 r-H 
 
 iH 
 
 <u 
 
 3 
 
 T3 
 
 a 
 
 O 
 
 •H 
 
 2 
 
 en 
 
 
 en 
 
 • 
 
 3 
 
 Xi 
 
 O 
 
 rH 
 
 3 
 
 • 
 
 C 
 
 iH 
 
 ■H 
 
 
 4J 
 
 <D 
 
 C 
 
 M 
 
 O 
 
 3 
 
 O 
 
 60 
 
 
 •H 
 
 hJ 
 
 fe 
 
 W 
 
 
 P 
 
 
 © 
 
 
 
 
 »*-! 
 
 
 <D 
 
 
 -C 
 
 M 
 
 . 
 
 o 
 
 H 
 
 a 
 
 
 a. 
 
 0) 
 
 3 
 
 M 
 
 tn 
 
 3 
 
 
 6C 
 
 60 
 
 •H 
 
 c 
 
 En 
 
 •H 
 
 
 .— 1 
 
 
 cu 
 
 
 T3 
 
 
 o 
 
 
 a 
 
 
 CD 
 u 
 
 3 
 60 
 •H 
 
environments we further sought portability in the implementation of the 
 language and flexibility in the model execution environment. 
 
 The discussion of features of the MODEL language and their 
 motivations will be continued at length in Chapter 3. In the remainder 
 of this chapter, we will define the area of digital continuous simulation 
 and present a sample network which might be modeled for continuous 
 simulation. Chapter 2 presents a survey of existing continuous simulation 
 languages. Chapter 4 offers some conclusions concerning the present 
 implementation of MODEL and prospects for its further development. 
 
 1.2 . Definition of Digital Continuous Simulation 
 
 Simulation has been broadly defined in [1] as "the development 
 and use of models for the study of the dynamics of existing or hypothesized 
 systems." This close relationship between simulation and system modeling 
 is a very important concept. The various well-established simulation 
 methodologies — continuous, discrete, digital, and analog — are in fact 
 distinguished by differences in the types of models which they employ and 
 resulting differences in the methods used to trace model behavior, rather 
 than by inherent differences in the physical systems to be simulated. 
 In general the purpose of the study determines which aspects of the 
 physical system are to be modeled. This in turn has a major influence 
 on the selection of a methodology for the study. Additional considerations 
 involved in selecting a methodology frequently include the desired accuracy 
 and repeatability of the simulation, the allowable running time, and the 
 ease of modeling. 
 
 In the remainder of this section, we will distinguish digital 
 continuous simulation from the other well-established simulation methodologies, 
 namely discrete simulation and analog simulation. 
 
 1.2.1 Continuous/Discrete Digital Simulation 
 
 There exist two basically different digital simulation methodologies — 
 continuous and discrete. Continuous simulation is characterized by models in 
 which response phenomena occur continuously and in parallel as a function of one 
 or more independent variables. System states are modeled by a set of real- 
 valued dependent variables and responses are modeled by a simultaneous set of 
 
differential and nondif ferential equations in these varibles. The behavior 
 of a model is traced by a numerical approximation to the integral of the 
 set of equations. Typical applications of continuous simulation are to 
 systems modeled as initial value problems in ordinary differential and 
 nondif ferential equations with time as the independent variable. Steady- 
 state models and models involving multiple independent variables are less 
 frequently simulated with general purpose packages because automatic 
 techniques for the solutions of the boundary value problems and systems of 
 partial differential equations posed by these models are less well-developed 
 than those for initial value problems in ordinary differential equations. 
 Applications of continuous simulation arise most frequently from engineering 
 problems in the physical sciences — for example, in the analysis of electrical, 
 mechanical, and structural networks. Other applications include economic and 
 population dynamics models. 
 
 Discrete simulation is characterized by models in which response 
 phenomena occur as a sequence of events or interactions at discrete points 
 in the independent variable (nominally time). System states are modeled by 
 a set of entities having certain attributes and by a set of files or 
 processes in which these entities reside. Responses are modeled by 
 procedural events which alter the system state by creating or destroying 
 entities, changing their attributes or the files in which they reside, and 
 scheduling future events. The behavior of a model is traced by the use of 
 an event schedule which controls the execution of scheduled events and the 
 updating of simulated time to the point at which the next event is 
 scheduled to occur. Typical applications of discrete simulation are to 
 systems modeled as a sequence of probabilistically interdependent steps or 
 events. These applications arise most frequently from problems in operations 
 research and gaming — for example, in analyses of multi-task job shop, 
 corporate, and military strategies in which attention is focused on 
 individual events rather than on average or aggregate behavior. 
 
 Distinct continuous and discrete methodologies for digital 
 simulation have arisen primarily from differences in the aspects of 
 physical systems on which attention is to be focused rather than from 
 inherent differences in physical systems themselves. It can be 
 
said that a continuous model represents the aggregate or average of some 
 discrete model and a discrete model represents a sampling or microscopic 
 view of some continuous model. One could argue that all physical systems 
 are discrete at the atomic level. However, modeling at the atomic level 
 is frequently impractical. In these cases continuous simulation can be 
 employed. For example, population dynamics could be modeled by tracing 
 individual births and deaths in a discrete simulation. However, for large 
 populations this would be impractical and an aggregated continuous model 
 using differential equations would be more useful. 
 
 A system which is modeled best with discrete methods for some 
 studies may be modeled best with continuous methods for other studies 
 which have different purposes. For example, discrete simulation is 
 frequently applied to corporate systems for the purpose of predicting 
 the short range effect of corporate policies within an environment which 
 can be predicted in a probabilistic fashion at best. However, continuous 
 simulation can be more useful for corporate studies which focus on the 
 long-range effect of policies on performance in stable environments. In 
 such a study reported by Smith and Waltz in [2], a series of continuous, 
 deterministic environments and an algebraic formulation of the management 
 policies allowed the system to be modeled most profitably with continuous 
 methods . 
 
 When the numerical methods used to approximate the integration of 
 differential equations are considered, the distinction between continuous 
 and discrete methodologies becomes somewhat less clear. Digital computers 
 are inherently discrete. Consequently, these methods are discrete, 
 approximating solutions at a series of discrete points in the independent 
 variable. However, the classification 'continuous' is appropriate when 
 the model is continuous and discretization is carried out automatically. 
 On the other hand, the classification 'discrete' applies to finite 
 difference models even though finite difference equations are a crude 
 means of approximating the integration of differential equations. This 
 further supports the contention that discrete models represent samplings 
 of continuous models and continuous models represent aggregations of 
 discrete models. 
 
In the remainder of this thesis we will restrict our attention to 
 continuous simulation. However, many systems which are best modeled in a 
 primarily continuous fashion (such as an electrical network) include some 
 discrete responses (such as capacitor ionization). Thus, a widely 
 applicable continuous simulation package must include some facilities for 
 modeling discrete responses. 
 
 1.2.2. Digital/Analog Continuous Simulation 
 
 Both digital and analog methodologies have been widely employed 
 for continuous simulation studies. In the past two decades, the major 
 emphasis of continuous simulation has shifted from analog to digital 
 methods for a number of reasons. We now turn to a discussion of the 
 relative merits of analog and digital methods before restricting our 
 attention to digital continuous simulation. 
 
 Analog simulation involves modeling a system by physical 
 analogues whose behavior mimics that of the system to be studied. The 
 behavior of the system is traced by observation of the physical model over 
 real time. The nature of physical models at the level at which they can 
 be conveniently monitored is predominantly continuous. Thus, analog 
 simulation has been developed as a methodology for continuous simulation. 
 Examples of analog simulation studies include the use of scale models and 
 wind tunnels in aerodynamic analysis, the use of structural scale models 
 in earthquake analysis, and the use of liquid models in gas flow analysis. 
 However, in the remainder of this section, we will restrict our attention 
 to analog simulations in which physical systems are modeled by dc electrical 
 analogues. This is the only general purpose methodology for analog 
 simulation developed to date, and by far the most common. 
 
 In electrical analog simulation, the magnitudes of dependent 
 problem variables are represented by voltages. Operations on these 
 variables are implemented via electrical analogues such as integrators, 
 adders, multipliers, dividers, and other function generators. By 
 appropriately wiring the inputs and outputs of selected analogues, the 
 user can construct a circuit which represents a simultaneous set of 
 differential and nondif f erential equations — that is, a continuous model. 
 The set of equations can then be integrated by the continuous operation of 
 the analog circuit in real time. 
 
General purpose dc analog computers became available soon after 
 World War II. Their ability to represent and solve models based on 
 ordinary differential equations led to their widespread use for continuous 
 simulation. In addition to the essential ability to model differential 
 equations, electrical analogues are well suited for continuous simulation 
 in that : 
 
 1. their nature of operation is both continuous and parallel; 
 
 2. the speed of solution is fast and independent of the 
 problem's complexity; and 
 
 3. they allow the convenience of immediate access to results. 
 Analog simulation does have its drawbacks, however. Complex 
 
 networks of analogues and tedious patchboard wirings are required to 
 represent sophisticated differential systems. Other major problems 
 concern the scaling of variables and the accuracy of the solution. 
 
 For a lOOv analog computer all voltages must remain within the 
 range of -lOOv to +100v. If a variable exceeds the maximum voltage, the 
 corresponding amplifier becomes saturated and the solution becomes 
 erroneous. Thus, all variables must be scaled so that none exceeds the 
 maximum voltage during the simulation. This can be a tedious task since 
 a large model will include many variables and one does not normally know 
 the maximum values they will attain. Furthermore, voltages cannot be 
 allowed to remain too small or noise will become a problem. 
 
 The accuracy of an analog simulation depends on the accuracies 
 of the analogues employed. The accuracies of electrical analogues 
 typically vary from .005 to .03 of full scale. Because of limitations on 
 component accuracies an accuracy of 1% for a simulation of modest 
 complexity is considered excellent. Consideration for the accuracy of the 
 simulation also imposes a limit on the maximum running time permissible 
 in an analog simulation. 
 
 On first comparison with analog computers, the discrete 
 procedural operation of digital computers makes them appear ill-suited 
 for continuous simulation. A complex numerical integration procedure is 
 required to trace the behavior of the model. This generally represents 
 a programming effort which is too large to be cost-productive for a single 
 simulation study. Furthermore, these digital procedures require greater 
 
running time than do analog simulations and their running time is very much 
 dependent on the complexity of the model. However, the use of a digital 
 simulation package featuring automatic integration accrues many advantages 
 for the user. Principal among these are: 
 
 1. the power and flexibility of digital computers for 
 language interpretation allows models to be formulated 
 at a much higher level than patchboard wiring; 
 
 2. the coding of problems which involve discrete responses 
 or logic is much simpler than with analog methods which 
 require the use of relays and threshold gates; 
 
 3. digital simulations are more easily interfaced to 
 
 complex procedures for such things as parameter 
 
 .2 
 optimization; 
 
 4. digital integration using floating point arithmetic can 
 achieve much greater accuracy than can analog computers; 
 
 5. the scaling problem of analog simulation is eliminated. 
 Digital floating point arithmetic can represent both 
 extremely large and extremely small quantities accurately; 
 
 6. digital computers can supply a wider variety of mathematical 
 functions than can analogues; 
 
 7. maintenance of digital simulation models is easier than 
 maintenance of an analog circuit. Periodic calibration 
 and accuracy tests are not required; 
 
 8. digital simulation allows more rapid switching from one 
 model to another than does analog simulation; 
 
 9. storing a digital simulation model is easier than storing 
 an analog circuit; 
 
 10. the user is free to concentrate on his problem, rather 
 than on analog intricacies. 
 Thus, although digital simulation was originally used only to 
 generate check solutions for analog simulations, by 1964 Brennan and 
 Linebarger [4] were observing that "The transcendance of digital computers 
 for simulation is inevitable...." By 1969 a number of good packages for 
 digital simulation were available and Brandin and Schram observed in [5] that 
 "a significant number of models associated with differential equations are 
 being simulated exclusively and preferentially on digital computers." 
 
The present trend is toward digital continuous simulation using 
 languages which are continually increasing in power and flexibility. The 
 advantage of using an analog computer is restricted to problems which require 
 the excellent frequency response of analog simulation such as real time 
 applications. 
 
 1.3. Sample Network Problem 
 
 Many areas of systems study lead to continuous models which pose 
 initial value problems in ordinary differential equations. Among these are 
 electrical, mechanical, structural, and fluid system studies. Many such 
 studies can be conducted most conveniently via network models — that is, via 
 models which consist of a number of elements with 'defined' or 'well- 
 understood' properties, inter-connected in a manner which could be original 
 and/or subject to change during the design process. The 'well-understood' 
 properties of the network elements are specified by sets of equations 
 involving a variety of types of variables and parameters while the connective 
 properties of the network are specified by generalized application of Kirchoff's 
 laws. For such models a network simulation language such as the ECAP-II 
 language for electrical circuit analysis [6] offers the convenience of macro- 
 like invocation of network elements, high-level alteration of network 
 interconnections during the design process, and automatic generation of the 
 connective equations arising from the application of Kirchoff's laws to the 
 nodes of the network. 
 
 The principal drawback of existing network simulation languages is 
 that they have been designed for limited classes of applications. Connections 
 in these languages transmit variables which are natural only for the intended 
 discipline. For example, connections in electrical network languages transmit 
 single voltages and currents while connections in a structural network 
 language might transmit six components of displacement and six components of 
 force. Application of these languages to a different discipline requires 
 extensive user effort either in rewriting the language translator to 
 accommodate the model or in reformulating the model into the existing language. 
 Furthermore, these languages lack facilities for conveniently modeling general 
 network elements via equations. Typically, these languages provide a fixed 
 set of elements which can be extended only be defining new elements in terms 
 of equivalent circuits constructed from the basic elements. 
 
 Overcoming these drawbacks, as implied by our goal of producing a 
 widely applicable language for continuous network simulation, will be the 
 
10 
 
 subject of further discussion in Chapter 3. In the remainder of this section, 
 we will illustrate some of the principles of continuous network modeling by 
 describing a sample problem from this area. The system to be considered is 
 a fluid network consisting of interconnected reservoirs, pipes, sources, and 
 drains. The formulation of a model for such a network in the MODEL language i; 
 shown in Appendix B, along with selected portions of the output produced by 
 the compilation of this model. 
 
 The purpose of this hypothetical study is to analyze the behavior 
 of a proposed storm sewer system under various driving functions representing 
 rainfall to determine whether the rainfall can be accommodated without 
 flooding the streets. The nature of the problem suggests a continuous 
 methodology using the idealized Bernoulli equations of fluid mechanics 
 which state that the quantity 
 
 V 2 /2G + P/GAMMA + H 
 remains invariant along any flow line in a steady flow situation. The 
 variables in this quantity are: 
 
 G the acceleration due to gravity, a constant throughout 
 the system; 
 
 GAMMA the density of the fluid, a constant throughout 
 the system; 
 
 V the fluid velocity at the point in question; 
 
 P the fluid pressure at the point in question (above 
 one atmosphere) ; 
 
 H the height of the point in question (above some 
 reference point) . 
 The Bernoulli equations represent an idealization of the physical system 
 since they do not model head loss along the flow lines. We employ this 
 idealization for the sake of simplicity only. The head loss could be 
 modeled if desired. 
 
 To accomplish this study a network model linking four types of 
 fluid elements — sources (rainfall), reservoirs (sewer basins), pipes, and 
 sinks (drains) — is desired. The properties of these elements are well- 
 understood and can be modeled as described below. The behavior of inter- 
 connections between these elements is also well-understood and can be 
 modeled by the respective application of Kirchoff's current and voltage 
 laws to the fluid flow and to the Bernoulli quantity at each node of the 
 network. These laws state that fluid does not accumulate in any node and that 
 
11 
 
 the Bernoulli quantity assumes the same value at all points connected in a 
 common node. Since the functional description of a node remains the same 
 regardless of the number or type of elements connected to it, and since 
 specific interconnections are likely to be changed during the design process, 
 it would be very convenient to employ a modeling language which can handle 
 these connective properties automatically. In the following discussion, we 
 will assume automatic handling of node equations and will not model these 
 properties explicitly. 
 
 Source Element 
 
 This element represents the entry of rainfall into the sewer 
 network at a storm drain. It might be represented graphically as shown 
 in Figure 1.2a. The element model consists of one connection point, or 
 terminal which is labeled by the integer 1 and the equation 
 
 -FLOW = F(TIME) 
 
 3 
 where -FLOW represents the rate of flow out of this element (i.e., the 
 
 rate of rainfall) and F is some function of time which describes this rate, 
 
 The value of the Bernoulli quantity at the source terminal is not of 
 
 interest and thus is not modeled explicitly. 
 
 Reservoir Element 
 
 This element represents a storm sewer basin. It might be 
 represented graphically as shown in Figure 1.2b. The reservoir has three 
 connection points. Terminal represents the point of connection to a 
 source element, and terminals 1 and 2 represent points of connection to 
 other reservoirs or to fluid sinks. In addition to the values of FLOW 
 and B, the Bernoulli quantity, at each terminal the following quantities 
 are used in modeling the reservoir: 
 
 HS the height of the reservoir's surface 
 
 AS the area of the reservoir's surface 
 
 A the area of the outlet at terminal 1 
 
 H 1 the height of the outlet at terminal 1 
 
 P.. the pressure of the fluid at terminal 1 
 
 V the velocity of the fluid at terminal 1 
 
 A„ the area of the outlet at terminal 2 
 
 H~ the height of the outlet at terminal 2 
 
 P the pressure of the fluid at terminal 2 
 
 V„ the velocity of the fluid at terminal 2 
 
12 
 
 The areas and heights, except for HS, are assumed to be parameters 
 of the element. This parameterization allows the same basic reservoir element 
 to be used throughout the network. HS and the fluid pressures and velocities 
 are local variables of this element. HS is the crucial variable since its 
 value determines whether or not the sewer backs up into the street. When the 
 reservoir element is used in a network, an initial value will be specified 
 for HS. This represents the height of the fluid in the reservoir prior to 
 the rainfall. For the sake of simplicity we assume that the initial level 
 of fluid in the reservoir will cover the outlets at terminals 1 and 2. This 
 allows the definition of the reservoir element to be completed by the 
 equations: 
 
 1. HS'*AS=FLOW + FLOW + FLOW 
 
 2. V x = -FLOW 1 /A 
 
 3. V 2 = -FLOW 2 /A 2 
 
 4. B = V 2 /(2*G) + P /GAMMA + H 
 
 5. B 2 = V 2 2 /(2*G) + P 2 /GAMMA + H 2 
 
 6. B = HS 
 
 7. B = HS 
 
 Equation 1 relates the rate of change in the height of the reservoir's 
 surface, HS', to the rates of flow into the three terminals. Equations 
 2 and 3 define the fluid velocities directed out of the reservoir at 
 terminals 1 and 2. Equations 4 and 5 relate the Bernoulli quantities B 
 and B„ to fluid velocity, pressure, and height. Equations 6 and 7 equate 
 the values of the Bernoulli quantity at terminals 1 and 2 to the value at 
 the reservoir's surface. The fluid pressure at the surface is assumed 
 to be one atmosphere and the fluid velocity at the surface, HS', is 
 assumed to be so small that it has no effect on the value of the Bernoulli 
 quantity there. Thus, the value of the Bernoulli quantity at the surface 
 is assumed to be HS. 
 
 Pipe Element 
 
 This element can be used to interconnect reservoirs and fluid 
 sinks. It might be represented graphically as shown in Figure 1.2c. The 
 element model includes two connection points — terminals 1 and 2 — , the 
 associated variables B-. , FLOW , B , and FLOW , and the following variables 
 and parameters: 
 
13 
 
 A the cross-sectional area of the pipe, a parameter of the element; 
 
 V the velocity of the fluid through the pipe, a local variable; 
 
 H the height of terminal 1, a parameter; 
 
 P, the fluid pressure at terminal 1, a local variable; 
 
 H„ the height of terminal 2, a parameter; 
 
 P 9 the fluid pressure at terminal 2, a local variable. 
 
 The definition of the pipe element is completed by the equations: 
 
 1. FLOW + FLOW = 
 
 2. V = FLOW /A 
 
 3. B = V 2 /(2*G) + H + P /GAMMA 
 
 4. B = V 2 /(2*G) + H + P /GAMMA 
 
 5. B x = B 2 
 
 Equation 1 specifies that no fluid accumulates in the pipe. Equation 2 
 defines the velocity of the fluid directed from terminal 1 toward terminal 2 
 through the pipe. Equations 3 and 4 define the Bernoulli quantity at 
 terminals 1 and 2, respectively, while equation 5 equates these quantities. 
 
 Since the head loss along a flow line is not modeled in this 
 study, the pipe element simply transmits the applied flow and Bernoulli 
 quantity. Thus, it affects connected elements as though it were only a 
 terminal. If the fluid pressures and velocities within the pipes are not 
 of interest, the use of the pipe element is not necessary. Reservoirs and 
 sinks can be connected directly. 
 
 Fluid Sink Element 
 
 This element represents the flow of fluid out of the storm sewer 
 network and might be represented graphically as shown in Figure 1.2d. It 
 has one terminal which can be connected to a reservoir either directly or 
 through a network of pipes. The sink has two parameters, A and H, which 
 represent the cross-sectional area and height of the drain. The definition 
 
 of the sink element is completed by the equati 
 
 on 
 
 B 1 = FLOW 2 /(2*G*A 2 ) + H 
 which defines the Bernoulli quantity at the drain, where the pressure is 
 assumed to be one atmosphere. 
 
 A network model of a storm sewer system can be constructed by 
 simply interconnecting various instances of the elements described above, 
 assuming automatic handling of the connective equations. 
 
14 
 
 Figure 1.2a. Fluid source element (rainfall) 
 
 Figure 1.2b. Reservoir element 
 
 'oQ 
 
 3)o' 
 
 Figure 1.2c. Pipe element 
 
 OU » 
 
 Figure 1.2d. Fluid sink element 
 
 Figure 1.2. Graphical representations of storm sewer network elements 
 
3 
 
 15 
 
 NOTES 
 
 Continuous and discrete methodologies are sometimes coupled in so-called 
 combined simulations. These simulations accommodate both discrete and 
 continuous aspects of physical systems by using continuous methods to 
 model and trace continuous responses and discrete methods to model and 
 trace discrete responses. A good example of a combined simulation of 
 a tanker fleet can be found in A. A. B. Pritsker's GASP IV text [3]. 
 
 Analog circuits are sometimes interfaced to digital procedures in hybrid 
 simulations. Typical applications of hybrid simulation are systems in 
 which some computations require the very high accuracy of digital methods 
 while others require the extremely rapid response of analog circuits. 
 For example, hybrid simulation is often employed in ballistic missile 
 and space vehicle applications involving guidance systems which require 
 very high accuracy and control systems which require very high 
 frequency response. 
 
 For the sake of consistency all values of FLOW, are assumed to be directed 
 into the element in question. Thus, the rate of rainfall is -FLOW , the 
 rate of flow directed out of the fluid source element. 
 
16 
 
 LIST OF REFERENCES - CHAPTER 1 
 
 [1] "In My Opinion," Editorial Comments 
 J. McLeod 
 Simulation 5 (6), p. 381, December 1965 
 
 [2] "Corporate Financial Management using Digital Simulation" 
 G. G. Smith III and P. W. Waltz, Jr. 
 
 Proceedings CSSL Conference on Applications of Continuous System 
 Simulation Languages , pp. 105-114, June 30- July 1, 1969, San 
 Francisco, California 
 
 [3] THE GASP IV SIMULATION LANGUAGE 
 A. A. B. Pritsker 
 John Wiley and Sons, Inc., New York, New York, 1974 
 
 [4] "A Survey of Digital Simulation: Digital Analog Simulators" 
 R. D. Brennan and R. N. Linebarger 
 Simulation 3 (6), pp. 244-258, December 1964 
 
 [5] "Introduction to Continuous System Simulation" 
 D. H. Brandin and S. H. Schram 
 
 Proceedings CSSL Conference on Applications of Continuous System 
 Simulation Languages , pp. 17-28, June 30- July 1, 1969, San 
 Francisco, California 
 
 [6] "ECAP-II — A New Electronic Circuit Analysis Program" 
 
 F. H. Branin, G. R. Hogsett, R. L. Lunde, and L. E. Kugel 
 
 IEEE Journal on Solid State Circuits SC-6 (4), pp. 146-166, 1971 
 
17 
 
 2. SURVEY OF DIGITAL SIMULATION LANGUAGES 
 
 Whereas modeling for analog simulation is carried out by wiring 
 electrical analogues on a patchboard, modeling for digital simulation 
 requires the use of a programming language, which we will refer to 
 subsequently as a simulation language. Simulation studies can be and 
 have been programmed in most popular computer languages. We will restrict 
 our attention to languages intended specifically for simulation, which are 
 by far the most convenient programming languages for these applications. 
 We will begin this survey of simulation languages by considering the 
 essential processes involved in a simulation from the highest level of 
 abstraction. We will classify simulation languages into several broad 
 categories on the basis of how certain of these processes are carried out 
 by the languages or by the simulation packages with which they are 
 associated. Then we will proceed to survey languages in greater detail 
 in terms of their features, implementations, and the design goals behind 
 their development. 
 
 2.1. Essential Simulation Processes 
 
 A simulation study typically involves the iterative execution 
 of the processes below: 
 
 1. Derivation of a model from a given physical system. 
 
 2. Formulation of a problem- descriptive model of the system. 
 Such a model describes the problem to be solved but 
 includes no explicit statement of the algorithmic solution. 
 
 3. Formulation of a procedure- adequate model. This model 
 explicitly describes the algorithmic solution to the 
 extent required by the integration program. 
 
 4. Integration of the model under programmed control. 
 
 For the most part, process 1 is the province of the simulation 
 language user. No simulation packages exist which can automatically 
 observe the operation of a physical system and postulate a mathematical 
 model based on these observations. On the other hand, the term 'simulation 
 package' implies that process 4 can be carried out automatically. Many 
 simulation studies would not be cost-productive if both the system model 
 and the integration algorithm had to be programmed as 'one-shots'. 
 
18 
 
 Processes 2 and 3 are facilitated to varying degrees by various 
 simulation languages. Since we are primarily concerned with simulation 
 languages in this survey, we will concentrate most on these processes. 
 Model derivation and integration techniques will be dealt with sparingly 
 and only where they touch on language principles. 
 
 2.2. Basic Language Characteristics 
 
 The usual characterizations of simulation languages concern 
 the classes of models for which they are intended and the structural / 
 requirements of the model definition. The classes of models which are 
 accommodated give rise to the classification of languages as either 
 special purpose or general purpose. Special purpose languages are 
 intended only for a limited class of applications, such as electrical 
 circuit analysis. General purpose languages can accommodate a wide 
 range of applications, typically all systems which can be described in 
 terms of ordinary differential and non-differential equations, with 
 certain restrictions which we will discuss shortly. 
 
 The structural requirements of the model definition give rise 
 to the classifications of languages as either block-oriented or equation- 
 oriented, and as either procedural or parallel. Block-oriented languages 
 are those in which the equations that describe the model are formulated 
 in terms of networks of interconnected functional blocks. This is a very 
 convenient format for applications in network analysis because the user 
 need not formulate a mathematical model. In equation-oriented languages, 
 on the other hand, the model is formulated as a set of equations which is 
 derived more or less directly from the problem-descriptive mathematical 
 model. This permits equation-oriented languages to be widely applied. 
 
 Procedural languages are those which require the formulation of 
 equations or blocks to be ordered in some procedural fashion to accommodate 
 the algorithmic integration of the model. In other words, they require a 
 procedure-adequate model definition. In contrast, parallel languages 
 permit the equations or blocks to be formulated as an unordered, or 
 parallel, set. The language processor of a parallel simulation package 
 automatically synthesizes a procedure-adequate model from the parallel, 
 problem-descriptive model. Thus, parallel packages take care of process 3 
 as well as process A. 
 
19 
 
 With the definitions of the terms 'special purpose', 'general 
 purpose', 'block-oriented', 'equation-oriented', 'procedural', and 
 'parallel' in hand we will proceed by discussing where the popular 
 simulation languages fall in terms of these categorizations. We will 
 also introduce a number of languages to be considered as examples in 
 observations which will be made later. 
 
 The first general purpose languages which were developed were 
 block-oriented due to a desire to combine the computational ability of 
 digital computers with the structural organization of analog computers 
 then in use for simulation. Models were constructed from interconnected 
 functional blocks which corresponded for the most part to available 
 analog elements such as integrators, multipliers, etc. Both parallel 
 and procedural versions of such languages were developed although the 
 parallel versions were generally accepted as easier to use and less 
 error prone. Some examples of general purpose block-oriented languages 
 are ASTRAL, DYSAC, JANIS, MIDAS, and PACTOLUS. 
 
 Modern general purpose languages are usually equation-oriented 
 due to a desire to provide for generality with a relatively easy-to-use 
 structural format. Block-oriented languages are very useful for constructing 
 models from a set of pre-defined components, particularly in special purpose 
 network applications. However, for general models the most frequently 
 occurring component is simply an equation. Thus, it is easier to construct 
 general models directly from differential and algebraic equations than 
 from pre-defined functional blocks. Despite the fact that parallel 
 languages are generally easier to use, there are popular general purpose 
 procedural equation-oriented languages as well as parallel ones. Some 
 examples of general purpose parallel equation-oriented languages are MIMIC, 
 DSL/90, CSSL-III, CSMP-III, ASSL, DARE-P, and ACSL. The most important 
 general purpose procedural equation-oriented language is GASP IV. 
 
 Special purpose languages have arisen due to a desire to provide 
 extremely easy to use languages for certain limited applications. They 
 are usually block-oriented and parallel. Their block-orientation arises 
 from the desire to make them easy to use rather than general. Most of the 
 block types required for modeling are pre-defined within the language, 
 freeing the user of having to formulate differential equations defining 
 their behavior. A block may model a construct which involves many 
 
20 
 
 equations, such as transistor, or a single transfer function. Modeling 
 is frequently facilitated by the automatic association of certain network 
 equations, such as Kirchoff's laws in electrical circuit analysis, with 
 block connections. 
 
 The typical parallel structure of special purpose languages 
 also arises from the desire to make them easy to use. Freeing the user 
 of having to model at an equation level in these applications seems to 
 imply that he should also be freed of having to order the implied 
 equations in a procedural fashion. 
 
 The characteristics mentioned above allow special purpose 
 languages to achieve great modeling power within their scopes of applica- 
 tions. While the package takes care of processes 3 and 4, the use of 
 pre-defined blocks and connection-implied equations allows operations 
 1 and 2 to be automatically processed to a large extent as well. Typically 
 the user needs only to select the desired blocks and specify their 
 configuration in order to construct the desired model. 
 
 In this survey we will limit our specific comments concerning 
 special purpose languages to languages for electrical circuit analysis. 
 The most important observations made in this connection can be applied 
 to nearly all special purpose network languages. Examples of special 
 purpose, parallel, block-oriented languages for electrical circuit 
 analysis include ECAP, ECAP-II, AEDNET, SCEPTRE, and SUPER* SCEPTRE. 
 
 The tree structure of Figure 2.1 indicates where digital 
 simulation languages generally lie in terms of their scopes of application 
 and model structures. The languages which we have selected as examples 
 have been placed in this tree to emphasize their characteristics. The 
 MODEL language which is the subject of the subsequent chapters is a 
 parallel, equation-oriented, general purpose language which is designed 
 to allow it to be used in a convenient block-oriented, special purpose 
 fashion for network applications. 
 
21 
 
 LO ^D 
 
 O -H 
 
 , . M H 00 ' — ' O^ 
 
 
 o 
 
 H 
 
 H 
 
 1 — 1 
 
 P^ 
 
 1 — ' 
 
 o 
 
 H 
 
 
 1 
 
 CO 
 
 I 
 
 CO 
 
 1 
 
 w 
 
 pi 
 
 (J 
 
 CO 
 
 CO 
 
 CO 
 
 CO 
 
 CO 
 
 <c 
 
 o 
 
 s 
 
 a 
 
 c_> 
 
 o 
 
 <! 
 
 o 
 
 <3 
 
 o 
 
 CM 
 
 P-i 
 CO 
 
 rn 
 
 i — 
 
 i — i 
 
 r^ 
 
 
 i — i 
 
 .J 
 
 
 3 
 
 
 H 
 
 a 
 
 ro 
 
 H 
 
 < 
 
 £ 
 
 ITI 
 
 vO 
 
 W 
 
 1 — ' 
 
 1 — ' 
 
 3 
 
 C 5 
 
 CO 
 
 o 
 
 <ti 
 
 H 
 
 H 
 
 
 ^ 
 
 U 
 
 O 
 
 ►-> 
 
 p- 
 
 in 
 
 CM 
 
 
 W 
 
 CM 00 CO P-< 
 
 ,_, CM >— ■■ W 
 
 P-i Ph 
 
 <C < . 
 
 a o w 
 
 w w <3 
 
 H 
 
 UJ 
 
 !5 
 P 
 
 W CO 
 pi * 
 
 Pi 
 
 w 
 p-1 
 
 CO CO 
 
 tn 
 
 oj 
 
 00 
 CO 
 
 a 
 
 e 
 o 
 
 •H 
 •U 
 CO 
 
 1 
 
 CO 
 
 en 
 o 
 
 5 
 
 •u 
 
 C 
 
 o 
 
 V 
 
 CO 
 •u 
 
 •H 
 00 
 •H 
 
 en 
 C 
 o 
 •I-l 
 
 •U 
 
 CO 
 
 o 
 
 •H 
 
 o 
 
 •rn 
 cO 
 
 OJ 
 
 1-1 
 
 3) 
 
 •H 
 
22 
 
 In addition to the above methods of classifying simulation 
 languages, we now introduce a new classification based on the type of 
 integration algorithm to which a language is designed to interface. 
 Although this may seem an artificial method of classifying languages, 
 we intend to show that it is both appropriate and important. To this 
 end we introduce the notions of explicit and implicit integration. 
 
 Explicit integration methods are memory functions. The 
 
 computation of the state vector, x> at time t does not depend on the 
 
 derivative vector, x, at time t, but only on values of x and x at 
 
 previous times. The vector equation 
 
 x(t) = M(x(t - At), x(t - At),...) 
 
 describes an explicit integration method. Method M is used to compute 
 
 the state vector at each time step. The state derivative vector is then 
 
 calculated directly from the formulation. For this reason the state 
 
 equations must be explicitly formulated. This means that each equation 
 
 must have a single state derivative, x., or a single auxiliary variable, 
 
 y., as its left hand side, and each x. and y. must appear as the left 
 i 11 
 
 hand side of exactly one equation. This format allows the state and 
 auxilliary equations to be used as assignment statements which directly 
 compute x(t) and y(t), once they are arranged in the proper sequence. 
 In explicit block-oriented languages, the explicit formulation is 
 handled by the simulation package, which formulates all equations. In 
 explicit equation-oriented languages, the user must supply a set of 
 explicit equations. 
 
 State derivatives may not appear on the right hand sides of 
 explicit equations unless they are also defined as auxiliary variables. 
 Thus, an explicit state formulation can be represented in vector form as 
 
 Z(t) = g(x(t), Z(t), t) 
 x(t) = f(x(t), y(t), t) 
 Although the first of these equations is implicit in vector form (X(t) 
 is a direct function of y(t)), explicit methods require that no algebraic 
 loops be present in the formulations of the individual y.. In the absence 
 of any such loops, the equations can be arranged in a fashion which allows 
 direct sequential computation of a solution to the simultaneous equations. 
 This involves sorting the equations so that each auxiliary variable is 
 
23 
 
 assigned a value before it is used on the right hand side of another 
 equation. For example, we consider the equations below which define 
 part of the pilot ejection study (see [13]). 
 
 X = XDOT 
 
 Y = YDOT 
 
 XDOT = U*COS(a) - V 
 
 A. 
 
 YDOT = U*SIN(a) 
 If executed in the above order, these assignment statements would not 
 compute a simultaneous solution of all equations because the auxilliary 
 variables XDOT and YDOT are assigned values after they are used on the 
 right hand sides of other assignments. It is necessary to sort this 
 sequence into one such as 
 
 XDOT = V*COS(a) - V 
 X = XDOT 
 
 YDOT = V*SIN(o) 
 Y = YDOT 
 
 in order to obtain a simultaneous solution using explicit methods. 
 
 This sorting process is what is meant by the formulation of a 
 procedure-adequate model. If sorting (of equation or block statements) 
 must be performed by the user, the language is called procedural. If 
 sorting is performed by the package, the language is called parallel. In 
 either case, if sorting can be accomplished it is computationally 
 equivalent to performing appropriate substitutions of functions of x(t) 
 and t only for any y.(t) which appear. Thus, sorting obtains an equivalent 
 state formulation which can be represented as 
 
 x(t) = f(x(t), t). 
 The sequence of direct computation to be performed at each time step is then 
 
 x(t) = M(x(t - At), x(t - At),...) 
 
 x(t) = f(x(t), t) 
 which is clearly explicit. 
 
24 
 
 Implicit integration methods perform a computation of x(t) 
 which depends on x(t) as well as on past values of x and X. The 
 vector equation 
 
 x(t) = M(x(t), x(t - At), x(t - At),...) 
 describes an implicit integration method. These methods are called 
 implicit because they introduce algebraic loops into the computations. 
 Even if the state formulation is sorted, or equivalently is given by 
 
 x(t) = f(x(t), t) 
 the system of equations which must be solved at each time step is 
 implicit. This system is 
 
 x(t) = M(x(t), x(t - At), x(t - At),...) 
 
 x(t) = f(x(t), t) 
 where x(t) is a direct function of x(t) and vice versa. Because of 
 these algebraic loops, implicit integration methods must use iteration 
 rather than direct computation to evaluate x. and x at each time step. 
 
 In the past, general purpose simulation packages have always 
 used explicit integration methods because the better numerical stability 
 of implicit methods was not thought to justify the higher computation time 
 required for iteration. However, implicit integration can be justified 
 for numerical reasons (see [1]). Therefore, we consider it important to 
 consider the effect of implicit integration methods on the ease with 
 which certain desirable language features can be realized. As a starting 
 point we can observe that the two major restrictions present in explicit 
 equation-oriented modeling — the explicit state formulation and the 
 requirement that the set of equations be sortable — would not be present 
 in an implicit language. Because implicit integration does not rely on 
 sorting and direct computation of the state derivatives, parallelism is 
 achieved without sorting and the set of state equations need not be 
 sortable or explicitly formulated. The state formulation for implicit 
 integration was presented above as 
 
 x(t) = f(x(t), t) 
 solely for the sake of consistency. State equations for implicit 
 integration can be written in any form and are more accurately represented 
 by the general vector equation 
 
 g(x(t), x(t), t) = [0] 
 
 At present the special purpose package ECAP-II is the only widely 
 
 2 
 available package which uses implicit integration exclusively. 
 
25 
 
 2.3. Essential Features of Simulation Languages 
 
 There are certain features which are required of any digital 
 simulation language which is to be useful for simulation studies. These 
 features are summarized below. They are included at this point because 
 they transcend the boundaries of the various language types and have 
 been present in varying degrees in all simulation languages which have 
 been developed. 
 
 Essential Features of Simulation Languages 
 
 1. a facility for formulating state equations, including 
 some logical capabilities; 
 
 2. parameterization of the model; 
 
 3. control over the simulation — initialization, termination, 
 repeat runs; 
 
 4. recording and output of data — printing, plotting; 
 
 5. control over the integration — error criteria, stepsizes; 
 
 6. accommodation of changes in the above. 
 
 It is worth restating that most characterization of languages 
 is done in terms of their facilities for state formulation (e.g. equation- 
 oriented vs. block-oriented, parallel vs. procedural). However, the 
 realizations of others of these features will also prove useful as 
 illustrations of shortcomings, high-water marks, and new techniques in 
 simulation languages. 
 
 In the following we will trace the historical development of 
 goals and features for general purpose simulation languages in some 
 detail. Then we will consider a representative family of special 
 purpose languages (for electrical circuit analysis) . Special purpose 
 languages will be discussed in considerably less detail since they 
 differ dramatically from general purpose languages only in the level 
 of abstraction at which modeling is performed (and in the classes of 
 models which they support) . 
 
 2 .A. The First Simulation Languages — Digital Analog Simulators 
 
 The first simulation packages offered general purpose block- 
 oriented languages. These packages were initially developed to generate 
 check solutions for analog simulations. Later, many were designed and 
 
26 
 
 used profitably for problem solving. All were designed very much in the 
 structural fashion of analog simulation--modeling was accomplished in 
 terms of a more or less fixed set of interconnected blocks, including an 
 integrator block to describe differential equations. Analog simulation 
 was well developed while digital computers were still in their infancy. 
 Thus early simulation users were all users of analog simulation. For this 
 reason Brennan and Linebarger observed in their excellent survey [2] that 
 the block-diagram approach to simulation corresponded to the way an 
 engineer visualized a system (at that time) . Engineers familiar with 
 simulation had learned to visualize systems in the form of an analog set- 
 up diagram. Brennan and Linebarger summarize in part by stating that 
 "...it is of paramount importance to capture the interest [in digital 
 simulation] of analog users in order that their vast experience not be 
 lost as simulation enters a new era." Thus, designers of digital 
 simulation packages and languages initially opted to copy closely the 
 structural design of analog computers. The general purpose block- 
 oriented packages which emerged from this effort have been commonly 
 labeled Digital Analog Simulators or DAS. 
 
 In terms of providing the essential features, DAS languages were 
 adequate but inconvenient. They so closely resembled analog simulation 
 that they typically reflected the limitations of analog elements in their 
 operator repetoires — i.e. the choice of functional blocks was limited, 
 limits were placed on the number of inputs and outputs a block could have. 
 DAS languages also frequently required block interconnections to be 
 specified in a rigid format. Thus, they were not really a convenient 
 means for general purpose modeling, merely a familiar means. Furthermore 
 logical switching of system structure was generally available only through 
 the use of relay elements and logical control over the simulation was rare. 
 Typical termination logic consisted only of a total time specification. 
 Most DAS languages did accommodate changes in a reasonable fashion, 
 allowing any one of the structure, control, and parameter sections to be 
 altered without affecting the others. 
 
 2.4.1. ASTRAL 
 
 Despite their shortcomings, languages of the DAS family introduced 
 a number of language and implementation features which increased the power, 
 
27 
 
 flexibility, and ease of use of digital simulation. One of the most 
 innovative was ASTRAL [3], developed at Convair Astronautics in 1958. 
 ASTRAL is most significant as the first parallel language. The automatic 
 sorting logic required to synthesize a procedure-adequate model from a 
 problem-descriptive or parallel one was first presented by Stein and 
 Rose in [4] and first implemented in ASTRAL. 
 
 ASTRAL was also the first simulation language to be implemented 
 via a compiler, rather than an interpreter. When digital simulation is 
 used to generate a check case for analog simulation, a program is 
 usually run once and discarded. In this case an interpretive approach 
 is quite efficient. However, when problem solving is the goal, and long 
 runs or many runs with the same configuration are required, a compiler 
 approach is clearly desirable. The ASTRAL compiler achieved further 
 advantage by using FORTRAN as its target language. By using FORTRAN 
 as the intermediate language, a package can avoid having to support 
 features to the machine level via its own software. Efficient code can 
 be produced fairly quickly by exploiting the considerable efforts expended 
 by FORTRAN designers. Since many simulation operations can be programmed 
 quite easily in a small subset of FORTRAN, only minimal effort is required 
 of the simulation package to support these operations. Thus, ASTRAL 
 introduced an excellent concept which reduces the amount of simulation 
 software required at very little cost to the user. In fact, a reliance 
 on FORTRAN is often to the advantage of the user. For example, it was a 
 simple matter for ASTRAL to include a 'special element' block, defined 
 by an ordinary FORTRAN assignment statement which could utilize any 
 standard FORTRAN library function. In this fashion, ASTRAL was the first 
 simulation language to offer an extendible operator set. This represented 
 a first step toward increased operator flexibility for simulation languages 
 
 2.4.2. DYSAC 
 
 DYSAC [5] , which was developed at the University of Wisconsin in 
 1961, introduced an algebraic block connection language which was the most 
 significant step toward greater ease of use since ASTRAL introduced 
 parallelism. DYSAC used a symbol which consisted of a letter followed by 
 two digits to represent the output of each block. While the letters 
 
28 
 
 identified the block types (e.g. N, M, A, P for integrator, multiplier, 
 adder, and potentiometer, respectively), the digits identified the 
 particular block. Thus, N02 represented the output of integrator 
 number 2.DYSAC allowed a sum of products of block outputs to be specified 
 as the input to an integrator. Thus, the single connection statement 
 
 N02 = P06N02 + P05P07N01 
 might serve to define the desired output of integrator number 2. In the 
 absence of this algebraic capability, four connection statements to the 
 effect 
 
 M01 = P06N02 
 
 M02 = P05P07N01 
 
 A01 = M01 + M02 
 
 N02 = A01 
 would be required, introducing three unnecessary auxilliary variables, 
 M01, M02, and A01 . 
 
 The observation of Brennan and Linebarger that this algebraic 
 interconnection feature provides 'simplicity and clarity' and shows 
 'great concern for the user' is very significant in that it shows an 
 early desire for the type of algebraic capability provided by equation- 
 oriented languages. Unfortunately, like the parallelism of ASTRAL, the 
 algebraic capability of DYSAC was not imitated by most DAS languages. 
 
 DYSAC was also the first language to provide extensive problem- 
 specification error and computational difficulty diagnostics. This 
 feature is very important as program failures without diagnostics are 
 extremely frustrating and have been much too frequent in digital simulation. 
 
 2.4.3. JANIS 
 
 Reliance on FORTRAN for simulation support was carried beyond the 
 level of ASTRAL by another compiler- implemented DAS language, JANIS [6], 
 which was reported at Bell Labs in 1963. JANIS accepted a simple FORTRAN 
 subset as its input, and implemented functional blocks as FORTRAN subroutines, 
 State formulation was specified by a procedural sequence of CALL's to 
 functional block subroutines. Block numbers were used as the arguments of 
 these CALL's to specify the inputs for each block. While this basic 
 structure was no more complicated than most other procedural DAS languages, 
 it permitted two great increases in power for the user conversant with 
 FORTRAN. Operator extension could be achieved by defining new functional 
 
29 
 
 blocks as FORTRAN subroutines. Furthermore, powerful logical control 
 over the system state was available by interspersing FORTRAN conditional 
 branching statements among the CALL's. 
 
 2.4.4. MIDAS 
 
 Perhaps the most significant DAS of all is MIDAS [7]. It was 
 developed at Wright Patterson Air Force Base in 1963. MIDAS has been 
 widely credited with popularizing digital simulation, as attested by its 
 use at nearly a hundred installations. Brennan and Linebarger believe 
 this total to exceed the combined useage of all previous simulation 
 packages. The widespread use of MIDAS was made possible by its imple- 
 mentation on the popular IBM 7090. However, it suggests another important 
 feature, portability, which we will have more to say about later. MIDAS 
 was the first parallel language since ASTRAL and thus was also significant 
 in that its widespread use helped to popularize parallel languages, just 
 as tbe parallelism of MIDAS accounted in part for its popularity. MIDAS 
 presented a significant innovation of its own, an element for solving 
 implicit equations. An implicit equation such as 
 
 x = f(x, y) 
 where x appears on both sides of the equation (that is, as both output 
 and input of the block f) usually requires an iterative method of solution. 
 All simulation packages before MIDAS used explicit integration, and 
 provided no mechanism for iterating implicit equations. Although MIDAS 
 also employed explicit integration, the implicit element provided by 
 MIDAS served to break such algebraic loops, which would otherwise result 
 in sort failures, by iterating the implicit equation without time advance 
 until convergence was attained. It is worth noting that implicit 
 integration algorithms require no special processing in order to handle 
 implicit equations since they handle all equations implicitly. 
 
 2.4.5. PACTOLUS 
 
 PACTOLUS [8], which was developed by Brennan for IBM in 1964, was 
 significant in its interactive approach to digital simulation. This 
 package served to demonstrate that, with an appropriate terminal, digital 
 simulation allows the user the sort of familiarity — that is, interaction — 
 with his model that had previously been restricted to analog simulation. 
 PACTOLUS was developed as an interpreter for the IBM 1620, a small scientific 
 
30 
 
 computer. By use of the typewriter, sense switches, and 1627 plotter it 
 allowed the user to interrupt a simulation and alter its configuration, 
 parameters, initial values, or control section while observing the response 
 of the system. PACTOLUS became very popular among the previously untapped 
 audience of small installations. In addition, a completely compatible 
 version was developed for the IBM 7090. Thus, the user who had access to 
 both computers could perform the initial checkout off-line and then switch 
 to the 1627 for fine tuning of the model. 
 
 PACTOLUS provided a somewhat better capability for implicit 
 equations than MIDAS. PACTOLUS also achieved a degree of operator flexibility 
 previously attained only by JANIS by including nine special elements whose 
 functions could be easily specified by the user. 
 
 General purpose block-oriented simulation packages — or DAS's — were 
 applied to a wide range of systems. With the first such packages the limited 
 set of available operators and the rigid format requirements of the languages 
 proved great drawbacks. Later languages allowed more flexible operator sets 
 and formats but still exhibited the principal shortcoming of all DAS's — 
 algebraic and differential equations had to be broken down into functional 
 blocks; a tedious and error-prone process. 
 
 On a superficial level DAS languages seem quite similar to the 
 characterization we have presented of special purpose languages. However, the 
 similarity extends only to the specialized block-oriented structure of each. 
 Whereas special purpose languages can automatically formulate equations for 
 limited applications on a level which is hidden from the user, DAS languages, 
 which were intended for general application, required the user to formulate 
 all equations himself through the tedious medium of blocks which modeled 
 electrical analogues. Thus, it is not surprising that DAS languages have been 
 succeeded in usage by general purpose equation-oriented languages. 
 
 2.5. Early Equation-Oriented Languages 
 
 The environment in which the first equation-oriented languages were 
 developed was well summarized by Clancy and Fineberg [9] in 1965. The trend 
 which they observed was toward extension of the power and utility of simulation 
 programs. Parallelism was recognized as an extremely useful language feature. 
 Clancy and Fineberg state that parallelism "may be an all-inclusive, rational 
 statement of the essential nature (of simulation languages)" and urge that 
 
31 
 
 "If the programmer is to 'think parallel 1 , he must be freed of ordering problem 
 statements." Three other features introduced by DAS languages, the compiler 
 approach to implementation, the provision of extendible operator sets, and 
 reliance on FORTRAN support, had also gained widespread acceptance. Meanwhile, 
 the variety and complexity of functions available through the built-in operator 
 sets continued to increase. 
 
 However, the greatest increase in utility achieved by simulation 
 programs developed during this period came about through the introduction 
 of equation-oriented languages with advanced functional and logical 
 capabilities and through the removal of arbitrary format restrictions and 
 analog holdovers. The need for complex networks to represent algebraic 
 and functional expressions had proved a great inconvenience in the use of 
 DAS languages. So too had restrictive features like absolute rather than 
 symbolic labeling, poor logical capabilities, fixed input card formats, 
 required commas and decimal points, and the lack of numerical literals. 
 Along with improved functional and logical features, the new equation- 
 oriented languages offered the use of literals and symbolic names without 
 reference to arbitrary block numbers. Great progress was also made 
 toward a free problem statement format. In the remainder of this section 
 we will discuss MIMIC and DSL/90, the two most significant equation- 
 oriented languages developed during this period, in some detail. 
 
 MIMIC and DSL/90 
 
 Both MIMIC [10] and DSL/90 [11] are general purpose parallel 
 languages implemented via compilers. Both were developed for the IBM 7090 
 family of computers and both were released in 1965. MIMIC is the 
 successor of MIDAS and was developed by Petersen and Sansom at Wright 
 Patterson Air Force Base. DSL/90 is a descendant of JANIS and was 
 developed by Syn and Linebarger at the IBM Development Labs. Both MIMIC 
 and DSL/90 are explicit languages. Thus, the state equations must be 
 formulated explicitly and must constitute a sortable set. Within these 
 limitations, MIMIC and DSL/90 allow great functional power in the 
 formulation of the state equations. We will begin this discussion of 
 their most important features by considering the functional capabilities 
 of MIMIC and DSL/90 statements. 
 
32 
 
 2.5.1. Functional Capabilities 
 
 Both MIMIC and DSL/90 allow free use of fully symbolic variable 
 
 names, numerical literals, and the common infix arithmetic operators +, -, 
 
 *, and / within any equation. Both allow expressions involving any of the 
 
 built-in operators to be nested to any level of parenthesis. Together 
 
 these features provide a great improvement over DAS languages in the 
 
 functional complexity which can be expressed in a single statement. As 
 
 we have seen, a single DYSAC connection statement could be used to express 
 
 a sum of products as the input to an integrator. Another DAS language, 
 
 DES 1 [12], carried algebraic capabilities to the ultimate by allowing 
 
 nested sums of products and quotients to be expressed in a single block 
 
 connection statement, but failed to provide infix operators for the 
 
 3 
 common arithmetic operations. MIMIC and DSL/90 fill this need and 
 
 provide the full algebraic capability of DES 1. MIMIC and DSL/90 also 
 
 provide greater functional capability in a single statement by allowing 
 
 nesting of all built-in operators, not just the common arithmetic operations, 
 
 The usefulness of nesting built-in operators is evident in the 
 consideration of a solution to a system such as Mathieu's equation 
 x + (a - 2q cos wt)x = where a, q, and w are constants. 
 This equation describes a number of engineering and mathematical systems. 
 To formulate this problem in DES 1 would require three blocks; two 
 integrators and a cosine function generator. Three connection statements 
 would be needed. More connection statements would be needed in any other 
 DAS language because multiplication and addition blocks would be required. 
 However, if x is to be the only output variable, this system can be 
 expressed in a single statement in either MIMIC or DSL/90. These state- 
 ments would be 
 
 DSL/ 90: X=INTGRL(XO,INTGRL(0.,-X*(A-2*Q*COS(W*TIME)))) 
 MIMIC: X=INT(INT(-X*(A-2*Q*C0S(W*TIME)),0.),X0) 
 where X(0) = XO and X(0) = 0. 
 
 The nesting of the integration, cosine, and arithmetic operators 
 permits a problem statement which closely resembles the manner in which 
 the user envisions the system — that is, as a single differential equation 
 with initial values. The principle advantage of operator nesting is 
 that it eliminates the need for complex networks to represent expressions 
 which are regarded as single functional elements. This also means that 
 nesting eliminates the need to explicitly formulate most auxiliary variables. 
 
33 
 
 There are two important differences in the functional complexity 
 which can be expressed by single MIMIC and DSL/90 statements. The first 
 concerns a restriction on the manner in which the INTGRL operator can be 
 imbedded algebraically in DSL/90. DSL/90 requires that INTGRL be the 
 rightmost term at every level of its usage. This artificial restriction 
 is imposed to facilitate the recursive extraction of implied auxilliary 
 variables from nested occurrences of INTGRL. MIMIC allows the INT 
 operator to be embedded freely at all levels of nesting and is more 
 convenient in this respect. The second important difference concerns 
 the manner in which user-defined functions can be used. DSL/90 allows 
 user-defined function operators to be embedded in expressions as freely 
 as the built-in operators. In this respect DSL/90 is more convenient 
 than MIMIC, which allows no embedding of user-defined functions. 
 
 2.5.2. Statement Format 
 
 With respect to providing a flexible format for problem 
 statements, DSL/90 is clearly superior to MIMIC. In brief, MIMIC can 
 be characterized as requiring adherence to fixed input card fields and 
 strict ordering of data cards. DSL/90, on the other hand, offers a free 
 input card format and unordered, symbolic data entry. This eliminates 
 much of the frustration produced by coding and keypunch slips and allows 
 easier changing of parameter and initial values. 
 
 2.5.3. Built-in Operators 
 
 Both DSL/90 and MIMIC offer substantial improvements over DAS 
 languages in their facilities for supporting essential mathematical, 
 logical, and simulation control operations. The most significant 
 differences between DSL/90 and MIMIC with respect to these built-in 
 operators stem from DSL/90' s heavy reliance on FORTRAN for software 
 support. The DSL/90 compiler uses FORTRAN as its target language and 
 accepts a subset of FORTRAN mathematical and logical operations within 
 its input language. DSL/90 also relies on a user-written FORTRAN 
 program to control the simulation study. In contrast, the MIMIC compiler 
 produces near machine-level function code and all built-in operations 
 must be supported to this level by MIMIC software. Thus, MIMIC logical 
 and simulation control operators are quite different in form from the 
 corresponding FORTRAN operators used in DSL/90. 
 
34 
 
 Mathematical Operators 
 
 As we have seen in the discussion of their functional capabilities, 
 MIMIC and DSL/90 provide significant advances over DAS languages in the ease 
 with which mathematical operations can be programmed. Both languages provide 
 the most frequently used simulation operators, such as integration, 
 differentiation, implicit equation solution, time delay, and zero-order hold. 
 Both also provide the most frequently used function generators, such as 
 absolute value, square root, exponentiation, logarithm extraction, and the 
 trigonometric functions. There are some differences in the more sophisti- 
 cated operators provided by DSL/90 and MIMIC, but most operators not common 
 to both can be implemented relatively easily by the user. The implementation 
 of DSL/90 allows it to offer all standard FORTRAN library functions as 
 built-in operators. 
 
 Logical Operators 
 
 As we have mentioned, MIMIC and DSL/90 take quite different 
 approaches to the implementation of logical operations, but both permit 
 much easier logical switching of the state formulation than did any DAS 
 languages except JANIS. 
 
 DSL/90, like JANIS, relies on FORTRAN conditional branching for 
 support of logical state switching. Since DSL/90 is a parallel language, 
 special procedural blocks are provided for branching operations. 
 Conditional branches are intermixed with FORTRAN and/or DSL/90 statements 
 within procedural blocks. These statements are not resequenced by the 
 sorting process. Instead, the procedural blocks are treated as units 
 in the sorting process, allowing the conditional sequencing inside the 
 blocks to be handled in the FORTRAN step. 
 
 MIMIC supports state switching by means of logical control 
 variables, or LCV's. An LCV may be attached to any MIMIC statement to 
 control its execution at each time step of the simulation. MIMIC provides 
 a function switch operator to convert arithmetic relations into LCV's and 
 a standard set of Boolean operators to logically combine LCV's. This 
 approach is more elegant than DSL/90' s in that no proceduralism is 
 introduced into the parallel language. 
 
35 
 
 Simulation Control 
 
 Simulation control encompasses three essential operations; 
 establishing the termination conditions for each run, testing of system 
 responses between runs, and generating repeat runs with altered 
 parameter and/or initial values. 
 
 DSL/90 and MIMIC allow both time and dependent variable 
 termination thresholds to be established. This is an improvement over 
 most DAS languages, which allowed termination to be specified by elapsed 
 time only. As regards response testing and repeat runs, DSL/90 again 
 relies on FORTRAN while MIMIC employs LCV's. 
 
 DSL/90 supports testing of system responses and repeat runs 
 by allowing the model to be invoked as a subroutine from a FORTRAN 
 main program which is submitted with the model. System responses may 
 be tested and parameter values may be assigned by any FORTRAN procedures. 
 For simple studies very little programming sophistication is required, e.g. 
 
 DO 10 1=1,5 
 PARAM=P(I) 
 CALL DSL 
 10 CONTINUE 
 On the other hand, sophisticated studies can make use of FORTRAN procedures 
 for things such as parameter optimization. DSL/90 was the first language 
 to provide this type of simulation control, which is clearly desirable. 
 
 MIMIC supports response testing via LCV's. The termination of 
 a run causes a particular LCV to become 'true'. This LCV can be used to 
 cause the execution of a set of MIMIC statements which perform response 
 testing and parameter assignment. Simulation runs are automatically 
 repeated until the supply of data cards is exhausted, so every run must 
 read at least one data card. 
 
 Input/Output 
 
 DSL/90 allows parameter and initial values to be assigned 
 symbolically, e.g. 
 
 PARAM Pl=5. ,P2=7.3E+4 
 ICON X=0.0 
 
36 
 
 These data cards may be placed at any point in the input deck and, with 
 the exception of the label in columns one through five, may be punched 
 in free format. 
 
 MIMIC data cards must be grouped after the END statement and 
 parameter values must be specified in the order in which the parameters 
 are defined in the body of the program. Data cards are divided into 
 fixed fields, which further increases the likelihood of errors. Trivial 
 errors are also invited by the restriction that data entered in the 
 exponential form must be right-justified in the data field, while data 
 entered in the normal form need not be. 
 
 DSL/90' s facilities for data entry are clearly easier to use 
 than those of MIMIC or the DAS languages. As concerns output facilities, 
 both DSL/90 and MIMIC provide the same basic set as did most DAS 
 languages: printing, plotting, and the selection of titles and recording 
 intervals. MIMIC provides a wider variety of plot options, including 
 the ability to form cross-plots. 
 
 Integration Control 
 
 DSL/90 provides extensive features for controlling the integration 
 process. These include selection of the algorithm to be used (choice of 
 four, or a user-supplied algorithm), selection of the minimum and maximum 
 step sizes to be used, and specification of error tolerances for individual 
 state variables. These are useful features for sophisticated users, but 
 of dubious value for novices. All were present in some DAS languages. 
 MIMIC allows only the specification of minimum and maximum step sizes. 
 
 2.5.4. Facilities for Extending the Operator Set 
 
 User-Defined FORTRAN Subroutines 
 
 As we have seen, some DAS languages like JANIS allowed user- 
 defined FORTRAN subroutines to be included in a simulation program. Both 
 DSL/90 and MIMIC carry this feature farther than their DAS predecessors, 
 though MIMIC exceeds JANIS in this respect only in allowing expressions 
 as arguments. 
 
 MIMIC requires adherence to strict format rules in the definition 
 and use of FORTRAN subroutines. At most five of these may be used in any 
 MIMIC program and they must be called by pre-defined names. Each 
 
37 
 
 definition must include exactly seven arguments and the single output 
 value must be defined as the seventh argument. User-defined FORTRAN 
 subroutines are implemented as if they were function subroutines (i.e. 
 subroutine SRI is invoked in the form Y=SR1 (arg. , . . . ,arg ) ) but they 
 may not be nested or embedded algebraically in equations. Each 
 reference must be the only term at the highest level of the right hand 
 side, just as if it were a DAS functional block. 
 
 In DSL/90, the user may define FORTRAN function subroutines. 
 No restrictions are placed on their definition and use, other than those 
 imposed by FORTRAN. Any number of function subroutines with fully 
 symbolic names may be defined. References may be nested and embedded 
 algebraically in any fashion permitted by FORTRAN. Thus, DSL/90 
 represents the ultimate in usage of FORTRAN function subroutines, being 
 fully as flexible as FORTRAN itself. Of course, this represents no 
 great expense of effort within DSL/90 since FORTRAN is the target language, 
 
 MIMIC Subroutines and DSL/90 Macros 
 
 MIMIC also allows extension of its operator set by the use of 
 subroutines written in the MIMIC language. MIMIC subroutines offer few 
 advantages over FORTRAN subroutines, about the only one being that no 
 knowledge of FORTRAN is required. Since MIMIC does not allow use of the 
 integration operator in subroutines, they serve as function generators 
 rather than as a means of defining state variables. Apparently, because 
 MIMIC subroutines are only intended as function generators the statements 
 within a MIMIC subroutine are not sorted with respect to each other. One 
 could argue that a procedural language can be very useful for describing 
 the generation of a complicated function. However, proceduralism in MIMIC 
 subroutines is unnatural because MIMIC statements are otherwise processed 
 in seemingly parallel fashion. Proceduralism for function generation 
 seems better provided by an associated high level procedural language, 
 like FORTRAN. Like the FORTRAN subroutines permitted within MIMIC, 
 MIMIC subroutines may take expressions as arguments but may not be 
 nested or embedded in equations. 
 
 DSL/90 allows greater extension of its operator set by its 
 introduction of the use of macros in simulation languages. DSL/90 macros 
 
38 
 
 may consist of a mixture of DSL/90 and FORTRAN statements. Like MIMIC 
 subroutines they are repeatable procedural blocks with parameter variations. 
 The important difference between the two stems from the in-line generation 
 of macro statements which takes place at each macro invocation in the 
 program. After this preprocessing, the statements generated by macros 
 can be handled like any other statements. Thus it represents no difficulty 
 to support the integration operator within macros. In contrast it would 
 be difficult to support the integration operator within subroutines 
 because normal subroutine linkage does not suffice to establish which 
 arguments are defined as state variables within the body of the subroutine. 
 At the very least, the compiler must inform the integration program which 
 state derivatives are to be integrated and thus the compiler must 
 determine all state variables. Since DSL/90 macros support the integration 
 operator, they can be used to define frequently occurring subsystem states 
 in a hierarchical model as well as to generate functions. This facility 
 makes them much more powerful than MIMIC subroutines. 
 
 Unfortunately, like MIMIC subroutines, DSL/90 macros are 
 sequenced as blocks and are not sorted internally. This denies the user 
 the advantage of parallelism in defining subsystem states and also fails 
 to take advantage of an important difference in the capabilities of 
 macros and subroutines in parallel languages. Subroutines must, of 
 course, be sequenced as blocks. However, since macros are expanded 
 during pre-processing, it is possible for each statement generated by a 
 macro to be sequenced into the sorted program separately. This facility 
 would be more in keeping with the nature of a parallel language and in 
 some cases would serve to break what would otherwise be algebraic loops. 
 
 For example, in modeling an electrically controlled, pressurized 
 process, one might define macros to represent the elements of Figure 2.2. 
 E is a voltage which represents a pressure measured in the process S. 
 The pressure transducer converts this signal into the pressure P . The 
 atmospheric adapter adjusts P for the ambient air pressure P . The 
 adjusted pressure is P„ . The transducer converts P~ into a voltage 
 signal, E which is used to control process S. If the two macros are 
 to be sequenced as blocks, they represent an algebraic loop. The input 
 of the atmospheric adapter, P , is determined by the transducer, while 
 one of the inputs of the transducer, V is determined by the adapter. 
 
39 
 
 However, if the statements generated by the transducer can be sequenced 
 separately, the loop can be broken by the sequence 
 
 p i ■ £(E i> 
 
 P 2 " P l + P 
 E 2 = f" 1 (P 2 ) 
 
 PROCESS S 
 
 -O- 
 
 PRESSUPvE TRANSDUCER 
 
 ' (E ] 
 .-1 
 
 P x = f(E x ) 
 
 V 
 
 (P 2 ) 
 
 -O 
 
 ATMOSPHERIC 
 ADAPTOR 
 
 P = P - P 
 2 1 
 
 Figure 2.2. Macros for an electrically controlled, 
 pressurized process, S. 
 
 Table Functions 
 
 Both DSL/90 and MIMIC provide another important means of 
 extending their operator sets — the ability to enter tabular data functions, 
 This feature, which allows experimentally observed functions of one or 
 two variables to be included in system model formulations, was not 
 commonly available in DAS languages . 
 
 2.5.5. Diagnostics 
 
 Since the innovations of DYSAC, users have become increasingly 
 concerned with the desire for extensive and easily understandable diagnostics 
 Little information concerning DSL/90 diagnostics is available to this 
 author. Tt is clear that MIMIC does not offer extensive diagnostics at the 
 
40 
 
 problem description level. MIMIC does a fine job of reporting format 
 errors and references to undefined variables and operators. However, 
 diagnostics concerning algebraic loops and syntax errors in arithmetic 
 expressions are not input statement specific. They are reported at 
 the near machine code level rather than at the problem description 
 level. This makes problem debugging unnecessarily difficult, and nearly 
 impossible for the user who is unfamiliar with assembly languages. 
 
 2.6. Modern General Purpose Languages 
 2.6.1. General Trends 
 
 The development of the third generation of general purpose 
 simulation languages was channeled largely by the efforts of the SCi 
 Committee on Simulation Software, which was organized in 1965. During 
 the preceding years, a large number of digital continuous system simulation 
 packages had been reported. The SCi Committee grew out of a general 
 feeling that some sort of control and direction was needed in the area of 
 digital continuous simulation in order to insure orderly development of 
 the field. The Committee's efforts to provide this direction took the 
 form of a set of specifications for a proposed continuous system simulation 
 language (generically called a CSSL) , which was published in 1967 [13]. These 
 specifications were presented in the form of a communication language, with 
 little concern paid to strict detail or to problems of implementation. In 
 this form they inspired a family of languages and paved the way for most of 
 the significant developments which have followed. 
 
 In the next few pages we will turn to a discussion of the primary 
 goals for language development which were presented in [13]. This discussion, 
 along with some elaboration on the part of this author, will provide the 
 framework for a discussion of the most significant languages and features 
 developed since 1965. 
 
 SCi Committee on Simulation Software — Goals for Language Development 
 
 In their survey [9], Clancy and Fineberg had proposed a user- 
 oriented organization for simulation languages, with basic subsets for 
 less sophisticated users and more complex features for experts. In this 
 way the language would not be tied to any particular programmer level. 
 
41 
 
 This goal was also emphasized by the SCi Committee, which considered the 
 applicable programmer levels of an ideal language to include the engineer 
 or scientist unfamiliar with digital techniques; the simulation analyst, 
 and the skilled digital applications programmer. To provide such a 
 user-oriented organization the SCi Committee first desired "to provide 
 an extremely simple and obvious programming tool for the novice user 
 with a straightforward task." This implies: 
 
 1. a minimal set of operators capable of handling, in a 
 simple manner, most problems involving differential 
 equations ; 
 
 2. retention of proven features such as equation-oriented 
 languages and parallelism; 
 
 3. a complete set of problem-oriented diagnostics. 
 Second, an attempt was made to provide great power and 
 
 flexibility for the sophisticated programmer with a major programming 
 task. This led to the requirements: 
 
 1. a CSSL should provide an open-ended operator set with simple 
 procedures for generating operators; 
 
 2. a CSSL should act as an adjunct to an established procedural 
 language, e.g. FORTRAN, Algol, PL/I; 
 
 3. a CSSL should provide a programmable rather than a rigid 
 structure for a simulation study. 
 
 Open-ended Operator Set — Macros 
 
 Most of the attention concerning an open-ended operator set 
 was focused on the provision of macros. The SCi Committee observed that 
 "The single most important user feature is the concept of a macro. The 
 user may define macros for individual problems to represent commonly 
 used sets of descriptive information. These macros are referenced in 
 his program exactly as though they were operators of the language. In 
 addition, the user has the capability of creating his own macro library 
 which will appear to the system as an extension of and/or replacement 
 of the system library. Thus, each user may completely alter the semantics 
 |of the language while preserving the syntax and the structure of the 
 operational environment." 
 
42 
 
 The macro concept touches on what Clancy and Fineberg considered 
 to be the principle drawback of equation-oriented languages. They felt 
 that there is a loss of familiarity in some problems when common block 
 operators are not emphasized. They further observed that it may be 
 inconvenient to express certain operators in equation form, including 
 control system transfer functions and non-linearities such as hysteresis, 
 dead space, and limiters. These operators are much more familiar as 
 functional blocks. Clancy and Fineberg suggested that the language 
 format be flexible enough to match the natural forms of diverse problems. 
 Equations should be available as a means of directly modeling differential 
 equations and blocks should be available for operators common to popular 
 applications. Clearly, macros provide a convenient means of defining 
 common operators in terms of equations so that they may then be invoked 
 in a form similar to blocks. The SCi Committee considered this optional 
 block notation, available in DSL/90, to be a proven feature which should 
 be retained. 
 
 Furthermore, nested macros are particularly useful for modeling 
 complex, hierarchical systems. The case for hierarchical modeling 
 techniques is well presented by Clymer in [14] . Since many physical 
 systems are nearly, if not perfectly, hierarchical, it is very important 
 for a simulation language to provide means such as nested macros for 
 structuring models in a hierarchical fashion. 
 
 Adjunct to an Established Procedural Language 
 
 We have previously noted the usefulness of an associated 
 procedural language (nominally FORTRAN) for exercising logical control 
 over the system state, extending the function list via user-defined 
 subroutines, and for programmed control over the repetitive execution 
 of the model. For simple problems little or no use of the associated 
 procedural language is required — to the advantage of the user with no 
 programming experience. On the other hand, the associated procedural 
 language provides a very flexible and powerful programming tool for 
 sophisticated programmers and problems. The associated procedural 
 language can be employed to further advantage if it is also the target 
 language of the simulation language compiler. In this case the simulation 
 package can make extensive use of existing software support. It is this 
 
43 
 
 dependency on the associated procedural language for programming flexibility 
 and for software support that was advocated by the SCi Committee in stating 
 that the simulation language should act as an adjunct to an established 
 procedural language. Such a structure has the further advantage of allowing 
 the experienced programmer to alter the intermediate model, either to 
 avoid recompiling the simulation language model or to recover from errors 
 in the simulation compiler. Should the simulation package itself be 
 programmed in the associated procedural language, a high degree of package 
 portability can also be achieved. The importance of portability was 
 recognized by the SCi Committee, which considered one of the essentials 
 of an ideal language to be that it be usable on all scientific computers. 
 
 Programmable Structure 
 
 The type of facility which is meant by a programmable structure 
 for a simulation study is the ability to embed the simulation model within 
 a procedural program which controls its repetitive operation. This 
 program would typically serve to test system responses from previous 
 executions, alter model and control parameters, and rerun the model 
 until the study, or some part thereof, is completed as a single batch 
 mode job. An example of a simulation study for which a programmable 
 structure is very useful is the calculation of the envelope of safe 
 pilot ejection, which has become a benchmark problem in the area of 
 digital simulation. The purpose of this study is to determine the 
 trajectory of a pilot ejected from a fighter aircraft and to ascertain 
 whether he will strike the vertical stabilizer of the aircraft. Different 
 combinations of aircraft speed and velocity are investigated since the 
 drag on the pilot, which in part causes his horizontal motion relative to 
 the aircraft, is a function of both air density and velocity. Thus, a 
 number of simulation runs with different values of the altitude and 
 velocity parameters are required. It is convenient to be able to program 
 this sequence of runs as a single batch mode job which alters parameter 
 values procedurally between runs rather than reading parameter data for 
 each run. Thus, a programmable structure is quite useful. Furthermore, 
 it is useful for the programmed structure to be conditionally dependent 
 on previous solutions. For example, if ejection is safe at altitude h 
 and velocity V, it will certainly be safe at altitude h for smaller 
 velocities v < V. 
 
44 
 
 A programmed structure is conceptually simplified if the model 
 can be invoked as a subroutine. In many cases it is also useful for the 
 controlling program to be able to interface with large, user-supplied 
 programs for such things as parameter identification and optimization. 
 Since only relatively slow algorithms exist for some classes of simulation 
 studies, such as parameter identification and optimization, one can also 
 see the usefulness of interactive control over a simulation. Perhaps the 
 best argument for the provision of a programmable or interactive structure, 
 rather than a rigid structure, is the observation of the SCi Committee 
 that "The language designer's view of simulation is formalized in the 
 structure of his language and subsequent applications are limited to this 
 concept." Thus, flexible facilities for structuring simulation studies 
 should be provided, lest the rigid structure which seemed appropriate to 
 the language designers prove to be a liability to potential users. 
 
 In the remainder of this section, we will focus on what we 
 consider to be the most significant general purpose languages developed 
 since 1965. These are the SCi Committee-sponsored CSSL-III [15], IBM's 
 CSMP-III [16], DARE-P [17] — developed at the University of Arizona, the 
 Raytheon Company's RSSL [18] dialect of CSSL-III, E. L. Mitchell and 
 J. S. Gauthier's ACSL [19], and A. A. B. Pritsker's GASP IV [20]. 
 
 Before considering these languages individually we will present 
 a brief discussion of their many common features. These are summarized 
 in the following. 
 
 Common Features of CSSL-III, CSMP-III, DARE-P, RSSL, ACSL, and GASP-IV 
 
 1. all are general purpose, explicit, equation-oriented 
 languages implemented via compilers. All except GASP-IV 
 are parallel languages; 
 
 2. all act as adjuncts to FORTRAN. In all cases, FORTRAN is 
 both the associated procedural language and the target 
 language of the simulation compiler; 
 
 3. all offer extendible operator sets via user-defined 
 FORTRAN subroutines. All except DARE-P and GASP-IV 
 offer the use of macros; 
 
 4. all offer procedural sections and the use of nearly any 
 FORTRAN statements within these sections. This is most 
 useful for logical switching of the system state; 
 
45 
 
 5. all except GASP-IV offer nearly free (explicit) equation 
 formats, fully symbolic names and symbolic data input; 
 
 6. all offer great functional capabilities by allowing all 
 built-in operators and user-defined functions to be 
 freely nested and embedded in equations; 
 
 7. all offer a flexible complement of operators for data 
 recording, printing, and plotting; 
 
 8. all offer operators for solving implicit equations; 
 
 9. all allow the user to enter tabular data functions; 
 
 10. all offer flexible control of simulation studies via 
 programmable structure or interactive operation; 
 
 11. all offer a choice of integration methods, step sizes, 
 and error tolerances. 
 
 2.6.2. CSSL-III 
 
 CSSL-III is the product of a line of development at Control Data 
 Corporation which began with the sponsorship of the SCi Committee on 
 Simulation Software in 1967. Like previous versions of CSSL, CSSL-III, 
 which was released in 1971, adheres closely to the specifications presented 
 in [13]. 
 
 Structuring 
 
 CSSL-III provides generous structuring capabilities. Simple 
 problem statements may be unstructured by default, consisting of a single 
 DYNAMIC block. Sophisticated studies may be explicitly structured via 
 INITIAL, TERMINAL, and DYNAMIC regions. These codes are executed, 
 respectively, before, after, and at each communication interval of the 
 model simulation. 
 
 Simple problems are structured by default as one DYNAMIC region. 
 The model equations are specified in the parallel DERIVATIVE subregion of 
 the DYNAMIC region. The remainder of the DYNAMIC region specifies the 
 model termination condition, the integration parameters (method, step 
 size, error tolerance), and any data recording calculations which need 
 be performed only at communication intervals. The explicit equations 
 of the DERIVATIVE subregion are, of course, executed during each time 
 step of the integration. 
 
46 
 
 The INITIAL and TERMINAL regions are procedural codes which 
 permit nearly any FORTRAN statements and may invoke any user-supplied 
 FORTRAN subroutines. They can perform response testing and parameter 
 setting. Studies consisting of repeat runs can be specified by condi- 
 tional branches from the TERMINAL region to points within the INITIAL 
 region. 
 
 A programmed study is invoked by a deck of CSSL run-control 
 cards which must be submitted to the CSSL-III compiler along with the 
 model definition. The CSSL-III executive interprets these cards 
 sequentially at run time. At the very least, a START command must be 
 supplied to transfer control from the interpretive monitor to the 
 INITIAL region. Other run-control commands serve to set or reinitialize 
 parameters and select output variables and formats for the study. A 
 SPARE command is also included to permit linking to any user-supplied 
 FORTRAN subroutine with that name. The run-control language permits no 
 branching or looping, but does permit repetitive, parameterized operation 
 of the programmed study. Each time execution reaches the end of the 
 TERMINAL region, control returns to the executive for subsequent studies. 
 
 CSSL-III allows further program structuring by means of segments, 
 which are the simulation language equivalent of the closed subroutine of 
 procedural languages. Segments are the highest level blocks within a 
 program. Each segment contains its own INITIAL, TERMINAL, and DYNAMIC 
 regions and performs a complete simulation. Segments communicate to the 
 rest of the program through a user-specified set of variables and their 
 execution is sequenced by FORTRAN statements. CSSL-III segments provide 
 a structure applicable to simulations using multirate integration (through 
 multiple DERIVATIVE subregions) in a single independent variable. This 
 structure also allows a solution to one set of differential equations to 
 be used, for example, to calculate the initial conditions for the 
 solution of another set of equations as part of an iterative algorithm. 
 
 Operational Environment 
 
 CSSL-III is designed to facilitate on-line operation from a 
 remote terminal under machines of the CDC 6000 series. The advent of a 
 package with advanced language and computational features which could be 
 run as a batch job or in a very rapid turnaround, time-shared environment 
 was a significant development. The terminal user can perform text-editing 
 
47 
 
 and recompilation of the source program on-line and the program can write 
 data on the remote terminal after (though not during) the model execution. 
 Data recorded during a CSSL-III run is routed by the output monitor at the 
 point between reaching the model termination condition and the execution 
 of the TERMINAL region. 
 
 When running on-line, the user may interrupt the CSSL-III study 
 at any point, but would typically do so only to break long output sequences 
 or to abort a portion of the study. A TELEX operator (peculiar to the 
 KRONOS operating system for CDC 6000 series machines) can be used to 
 specify an address in the TERMINAL region to which control is transferred 
 at an interrupt. If the TELEX instruction is omitted, control is 
 transferred to the executive, which proceeds to interpret the next run- 
 control card. 
 
 CSSL-III' s on-line operation and interpretive run-control point 
 toward an interactive operation similar to that of less powerful predecessors, 
 like PACTOLUS. For true interaction the features of CSSL-III need only be 
 extended to allow run-control commands to be issued one by one from the 
 remote terminal and to allow monitoring output to be written on the terminal 
 during, rather than after, the model execution. 
 
 M acro Capabilities 
 
 CSSL-III provides very powerful macro capabilities. The CSSL-III 
 language includes a macro interpretive language which can be employed in 
 macro definitions. This language includes a powerful set of commands which 
 are interpreted at the macro level. A macro loop, for example, will 
 generate the included statements as many times as the loop is executed. 
 The CSSL-III language also incorporates a symbolic macro library from which 
 previously defined macros can be selected for modeling. User-defined 
 macros can be added to the symbolic library, which also provides a number 
 of system macros for such operations as hysterisis, limited integration, 
 and first order pole. After macro references are expanded by the macro 
 interpreter, all statements generated by macros are sequenced individually 
 into the sorted model. 
 
48 
 
 Arrays 
 
 CSSL-III allows the definition and use of array variables and 
 includes an array integration operator. This represents an advance in 
 functional capability for systems which can be described in part by array 
 operations. However, common operations such as array multiplication and 
 addition must be implemented by user-supplied code. References to 
 particular array elements are supported in one dimension only. For two 
 or three dimensional arrays the user must program the subscript 
 calculations himself. 
 
 2.6.3. CSMP-III 
 
 The IBM CSMP-III package, released in 1971, is very similar to 
 CSSL-III. Like CSSL-III, CSMP-III is the product of a line of development 
 dating back to the SCi Committee on Simulation Software publication [13] , 
 and adheres closely to these specifications. CSMP-III is somewhat less 
 sophisticated than CSSL-III. Here we will focus attention briefly on 
 those features of CSSL-III not available in CSMP-III. Otherwise, the two 
 languages are all but identical in terms of structure, power, and flexibility. 
 
 CSMP-III does not provide a macro interpretive language. No 
 commands are interpreted on the macro level. Macro expansion consists 
 simply of generating the statements of the macro definition sequentially, 
 with parameter substitutions. 
 
 CSMP-III does not allow programs to be divided into segments. 
 Thus, any given programmed study may involve the solution of only one set 
 of differential equations. All equations must be integrated by the same 
 method and at the same rate. 
 
 Finally, CSMP-III apparently includes no special provisions to 
 facilitate on-line operation. Its predecessor, CSMP-S/360 [21], was 
 operated in batch mode only. However, a batch compatible interactive 
 version of CSMP was reported by Fairley [22] in 1971. 
 
 2.6.4 RSSL 
 
 RSSL is an advanced dialect of CSSL-III which was developed by 
 E. L. Mitchell and J. S. Gauthier at the Raytheon Company in 1973. RSSL 
 is designed to accept, without change, any program written in CSSL-III. 
 
49 
 
 It includes innovations in the handling of macros, the run control 
 language, syntax analysis and the allocation of interval data space. 
 
 Macros 
 
 The RSSL translator uses a stack to handle macro expansions 
 so no artificial limit is imposed on the degree of macro nesting. 
 Furthermore, the user need not avoid the names of system macros and 
 operators in naming macros. The user dictionary is searched first in 
 the symbol look-up procedure. 
 
 Run-control Language 
 
 RSSL adds three new operators to the run-control language of 
 CSSL-III. The PROCED command allows the definition of run-control 
 procedures. These are lists of sequential commands which may then be 
 invoked by a single word. The DISPLY command can be used to print the 
 current values of a list of variables. This is a very useful feature 
 in a time-shared environment. The ACTION command can be used to schedule 
 data changes at particular values of the independent variable. This is 
 useful mainly for diagnostic purposes. For example, both RSSL and 
 CSSL-III provide an NDBUG command for snapshot printouts. The command 
 NDBUG=10 causes all problem variables to be printed at the first ten 
 time steps. The ACTION command allows the user to obtain debug listings 
 at points surrounding areas of suspected difficulty by changing the 
 value of NDBUG. The following example illustrates this operation and the 
 form of the ACTION command. 
 
 ACTION ' VAR '=4.75,' VAL ' =10 , ' LOC ' =NDBUG 
 This command sets the value of NDBUG ('LOC*) to lO('VAL') at time 4.75. 
 This is a somewhat confusing format, but a nice feature for debugging. 
 
 RSSL run-control also includes provision to overcome the usual 
 problem of high data volume through a remote terminal. Output commands 
 can route monitoring information to the terminal while sending high 
 volume output to a local line printer. 
 
 Syntax Analysis 
 
 The RSSL translator performs syntax analysis on the model source 
 code, an improvement over reliance on FORTRAN syntax analysis, which is the 
 
50 
 
 policy of CSSL-III where arithmetic expressions are concerned. FORTRAN 
 syntax error messages are confusing to the user, since variable names are 
 changed and parallel statements are rearranged before the FORTRAN step. 
 RSSL does not perform a full syntax analysis, only the first error on any 
 given card is located. 
 
 Internal Space Allocation 
 
 All data internal to the RSSL translator is stored in floating 
 tables which can be expanded and compressed as necessary. Thus, no 
 artificial limits exist on any program elements. Previous languages all 
 had fixed limits on the total numbers of such things as parameters, 
 integrators, variables, etc. 
 
 2.6.5. DARE-P 
 
 DARE-P (for Portable) was released in 1975 by Project DARE, 
 under the direction of J. J. Lucas and J. V. Wait at the University of 
 Arizona. In addition to its great portability, DARE-P is significant 
 for its centralized run-control and its flexible features for filing 
 and displaying solutions. 
 
 Portability 
 
 The DARE-P language acts as an adjunct to ANSI standard FORTRAN 
 [23] . The DARE-P package is programmed almost entirely in this subset of 
 FORTRAN, resulting in great portability. To further enhance portability 
 by reducing core requirements, the package is modularized into overlays. 
 The amount of machine dependent code is kept to a minimum by the use of a 
 machine-independent filing structure for solution histories and for 
 communications between the overlays, and by techniques such as packing 
 characters two per word rather than using a tighter packing which assumes 
 a word length of more than 16 bits. Machine dependent code is isolated 
 in separate modules, and an implementation guide is available to aid in 
 bringing DARE-P up at new installations. 
 
 The DARE-P package requires only the most usual sort of hardware 
 Aside from sufficient memory (roughly 17K DEC 10 words or 21K CDC 6400 
 words, for example) DARE-P requires an input device for entry of a 
 problem specification file, a mass storage device for filing operations 
 
51 
 
 and overlay swapping, and an output device capable of printing 132 
 characters per line. DARE-P can produce CalComp compatible plotter 
 output for installations having a CalComp compatible plotter. 
 
 Run-control 
 
 All DARE-P run-control is programmed in the LOGIC block, which 
 invokes the model execution as a subroutine. The default form of the 
 LOGIC block consists of a CALL RUN statement which executes the model once. 
 The user may program the structure of a study by using CALL RUN statements 
 in conjunction with nearly any ANSI FORTRAN statements. Special subroutines 
 are provided for reinitializing the system, adding new output variables, 
 and filing solution histories during runs, and parameter values may be 
 selectively altered by assignment statements. The LOGIC block can invoke 
 any user-supplied FORTRAN subroutines. These features give convenient 
 control with a wide degree of freedom. For example, large codes for 
 parameter optimization can be linked to DARE-P without changing the 
 standard system. 
 
 The centralized run-control of DARE-P is conceptually simpler 
 than the structure of CSSL-III where branching, looping, and interfaces 
 with FORTRAN routines are programmed in the INITIAL and TERMINAL regions, 
 and the specification of output variables and filing operations are 
 handled in the run-control deck. Furthermore, the notion of INITIAL and 
 TERMINAL codes with the model execution implicitly sequenced between them 
 unnecessarily restricts the manner in which a study must be conceptualized. 
 The user may feel more natural with a structure showing CALL RUN explicitly 
 between the initial and terminal codes, or with several CALL RUN statements 
 spaced throughout the program. However, CSSL-III 's run-control is 
 somewhat more powerful than that of DARE-P, allowing different output 
 operations and formats to be specified for particular invocations of the 
 programmed study. 
 
 Solution Recording and Display 
 
 The DARE-P LOGIC block supports a flexible complement of filing 
 operators for recording solution histories and solutions during and after 
 model runs. By default, all state variables are output variables and 
 their solution histories are saved on the TIME file. New output variables 
 may be added via the OUTPUT list command. The automatic recording of all 
 
52 
 
 solution histories can be disabled and re-enabled by means of CALL STROF 
 and CALL STRON, respectively. This can reduce the overhead substantially 
 and thus is very useful when a complete solution history is not required. 
 Time histories of selected output variables may be recorded by executing 
 a CALL SAVE list before the model execution. Each CALL SAVE, up to five, 
 uses a different system file to avoid overwriting. Final values of the 
 output variables may be saved after a run by a CALL STORE command. This 
 permits solution files from intermediate runs to be saved and re-entered 
 in subsequent runs via the CALL RESET command. The system STORE file may 
 be used to store end results for subsequent output to magnetic tape or cards, 
 
 DARE-P also offers a flexible complement of output operators. 
 Conventional printing and plotting of variables against time is supplemented 
 by operators which cross-plot up to seven variables against another and 
 operators which overplot one variable from up to five solution histories. 
 Operators are provided to produce time-plots, cross-plots, and over-plots 
 on the line printer and to produce magnetic tape files for CalComp 
 compatible time-plots, cross-plots, and over-plots. Over-plots are not 
 provided by the CSSL-III and RSSL packages. 
 
 Equations 
 
 The equations of a DARE-P model are specified in the DERIVATIVE 
 block. The DARE-P language allows for two DERIVATIVE blocks, permitting 
 segmenting as in CSSL-III. However, it is unclear to this author if the 
 DARE-P run-time overlay presently supports this feature — the first DARE-P 
 release did not. 
 
 The format of DARE-P equations is somewhat more natural than the 
 formats of other languages. The differentiation operator is represented 
 by a period following a variable name. Differential equations are 
 specified in the form je. = expression rather than in the familiar analog 
 form 
 
 X=INT (expression) 
 It is worth noting that the use of the differentiation operator rather than 
 the integration operator, together with the ability to formulate equations 
 implicitly, would allow first order differential equations to be presented 
 in their most common form. Therefore, this minor difference is of some 
 importance. 
 
53 
 
 DARE-P does not include any macro capabilities, but a version 
 with a macro handler is anticipated at the Swiss Federal Institute of 
 Technology in [24] . 
 
 2.6.6. ACSL 
 
 ACSL was reported in 1976 by E. E. L. Mitchell and J. S. Gauthier, 
 the developers of RSSL. ACSL incorporates the same structure as RSSL and 
 CSSL-III. An ACSL model consists of INITIAL, TERMINAL, DYNAMIC, and 
 DERIVATIVE regions and is exercised by sequential run-control statements. 
 The important innovation of ACSL is its interactive operation. Like 
 CSSL-III and RSSL, ACSL is designed to be run on-line from a remote 
 terminal. ACSL achieves true interaction in that run-control commands 
 can be issued and executed on-line and data can be displayed during the 
 model execution. ACSL may also be run in batch mode when appropriate. 
 
 The ACSL run-control language offers all features of RSSL 
 run-control with the exception of the ACTION and SPARE commands. The 
 model execution is invoked by a START command which transfers control 
 to the INITIAL region. The completion of the TERMINAL region or an 
 interrupt from the user transfers control back to the run-control 
 interpreter for the next command. Monitoring output may be routed to 
 the remote terminal during model execution. The monitoring interval may 
 be any integral multiple of the communication interval for solution 
 histories to reduce the frequency of transmissions to the remote terminal. 
 High volume data can be routed to a local line printer or plotter if 
 available. 
 
 ACSL incorporates all of the advanced features of RSSL. These 
 include its macro interpretive language, dynamic allocation of all 
 internal table space, arrays, and array integration operator. ACSL also 
 performs full syntax analysis at the source level. 
 
 Some concern is indicated in [19] for making the ACSL model 
 definition section machine independent. Versions of ACSL are reported 
 running on CDC 6000 series and UNIVAC 1108 machines. 
 
 2.6.7. GASP IV 
 
 GASP IV, reported in 1973, represents a different line of 
 development than the languages discussed previously. It is a procedural 
 language in which model definitions are programmed directly in FORTRAN. 
 
54 
 
 This package is unfit for the novice user due to its lack of parallelism 
 and symbolic naming capabilities. However, it provides the advantage 
 of efficiency for the sophisticated simulation programmer who considers 
 the overhead associated with advanced features such as sorting to be a 
 hindrance. In addition to continuous models, GASP IV supports discrete 
 and combined models and provides extensive features for discrete modeling. 
 
 Concerning continuous simulation, GASP IV is considerably less 
 powerful than the languages discussed previously. It provides no macros 
 and only a limited set of built-in operators to aid the user in describing 
 complex continuous models. It does, however, provide the facility for 
 incorporating user-written FORTRAN subroutines in a GASP IV model. 
 
 A continuous GASP IV model is usually programmed as four FORTRAN 
 subroutines. These specify the initialization procedures, the recording 
 of system status, the output (in addition to the standard GASP IV 
 summary report), and the state equations. Run-control is programmed in a 
 FORTRAN main program which invokes the model execution as a subroutine 
 via CALL GASP. Great flexibility is thus available for response testing 
 and initialization, but the user must take care of such things as 
 dimensioning and allocating COMMON storage for GASP variables. 
 
 GASP IV is highly portable, being programmed almost entirely 
 in ANSI FORTRAN. 
 
 2.6.8. Tabular Summary of Modern General Purpose Features 
 
 The most important features of the modern general purpose 
 languages which we have discussed are summarized in Figure 2.3. In this 
 author's opinion, ACSL and DARE-P are the most advanced languages to 
 date. ACSL is unsurpassed in modeling features and can be operated 
 interactively. DARE-P is cited for its centralized run-control in the 
 form of a FORTRAN calling program and for its flexible features for 
 recording, filing, and displaying solutions. DARE-P is further recommended 
 for its great portability and nominal cost. 
 
55 
 
 CSSL-III RSSL DARE-P ACSL GASP IV CSMP-III 
 
 iASIC FEATURES 
 Parallel 
 
 Equation-Oriented 
 Symbolic Naming 
 Associated Procedural 
 
 Object Language 
 Implemented by Compiler 
 
 )PERATOR EXTENSION 
 
 Symbolic Parameter Input 
 Numerical Output 
 Graphical Output 
 Cross-Plots 
 Over-Plots 
 
 — FORTRAN- 
 
 Logical Control 
 
 
 
 
 
 
 
 (via Procedures) 
 
 * 
 
 * 
 
 * 
 
 * 
 
 * 
 
 * 
 
 User-Defined Subroutines 
 
 * 
 
 * 
 
 * 
 
 * 
 
 * 
 
 * 
 
 Subroutine Library 
 
 * 
 
 * 
 
 * 
 
 * 
 
 *1 
 
 * 
 
 Macros 
 
 * 
 
 * 
 
 2 
 
 * 
 
 
 * 
 
 Macro Library 
 
 * 
 
 * 
 
 
 * 
 
 
 ■k 
 
 Macro Interpretive 
 
 
 
 
 
 
 
 Language 
 
 * 
 
 A 
 
 
 * 
 
 
 
 [NPUT/ OUTPUT 
 
 
 
 
 
 
 
 DIAGNOSTICS 
 Problem-Level 
 Syntax Analysis 
 
 PROGRAMMED STRUCTURE 
 
 Initial and Terminal Codes 
 Procedural Main Program 
 
 OPERATIONAL ENVIRONMENT 
 Batch 
 On-Line 
 Interactive 
 Portable 
 
 Figure 2.3. Table of features of modern general purpose packages 
 
 The GASP IV package has extensive run-time library routines for discrete 
 simulation, but the routines for continuous simulation are rather limited 
 
 A version of DARE-P with macro handling capability similar to those of 
 CSMP-III is available from the Swiss Institute of Technology, Zurich, 
 Switzerland . 
 
56 
 
 2.7. Special Purpose Languages — Electrical Circuit Analysis 
 
 Many specialized packages have spun off from the central development 
 scheme of continuous simulation. Applications of these include electrical, 
 structural, and chemical applications, to name a few. These languages are 
 distinguished from modern general purpose languages in that most, if not all, 
 modeling is carried out by selecting and connecting predefined element types 
 which are natural to the intended discipline. These languages provide great 
 convenience for suitable applications, but lack high-level facilities for 
 handling elements and connections outside the intended discipline and for 
 solving user-supplied equations. Here we will concentrate on languages for 
 electrical network analysis, which are a representative family of special 
 purpose languages. We will be concerned with features for network-oriented 
 model formulation rather than with generally applicable features such as 
 run-control and input/output. Advanced run-control and input/output features 
 can be incorporated in special purpose languages as well as general 
 purpose ones, though no existing special purpose packages provide the 
 flexibility of DARE-P , for example, in these respects. The most important 
 specialized features to be presented — graphical modeling, topological 
 macros, and the provision of specialized interdisciplinary modeling 
 capabilities — can be incorporated profitably in special purpose languages 
 for virtually any network applications in the physical sciences. So too 
 can interactive operation, which we have discussed in the survey of general 
 purpose languages. 
 
 2.7.1. ECAP 
 
 ECAP [25] is a linear circuit analysis package released by 
 IBM in 1965. It represents the most basic realization of a special 
 purpose language. All modeling is performed by interconnecting predefined 
 elements which represent the common linear elements of electrical circuits. 
 All equations are specified by the elements and their connections so the 
 user does no modeling at the equation level. However, there is no 
 facility for defining new elements, either in terms of basic elements or 
 in terms of equations. 
 
 Even in a relatively unsophisticated language like ECAP great 
 modeling power is inherent. In order to model an RLC circuit in a general 
 purpose language such as ACSL, an engineer would be forced to derive an 
 
57 
 
 explicit formulation of the state equations. A procedure for this 
 derivation, in which the state variables are a subset of the capacitor 
 voltages and induction currents, is described in [26] among others. 
 
 This is a tedious and time-consuming process for many engineers, 
 
 4 
 particularly for complex circuits. To model a linear RLC circuit 
 
 using ECAP, on the other hand, one need only select the elements and 
 
 specify their parameter values and interconnections. 
 
 ECAP's inability to handle nonlinear elements, including diodes 
 
 and transistors, is a severe handicap for circuit analysis. Furthermore, 
 
 ECAP converts a source language model into a set of nodal equilibrium 
 
 equations to be solved at each time step of the integration. This 
 
 technique requires complete recalculation of the equations whenever a 
 
 parameter is changed, making circuit design with ECAP extremely expensive. 
 
 2.7.2 AEDNET 
 
 AEDNET [28] is a sophisticated but nonportable package for linear 
 and nonlinear circuit analysis reported at the MIT Electronic Systems Lab 
 in 1966. AEDNET operates interactively on a time-shared computer and a 
 CRT display unit, which provides on-line plots of circuit responses. 
 Interactive operation (or extremely rapid batch-mode turnaround) is a 
 virtual necessity for a computer-aided circuit design package. AEDNET 
 was a great improvement over the long turnaround typical of batch mode 
 packages like ECAP. 
 
 AEDNET models are composed of linear and nonlinear time-varying 
 resistors, capacitors, inductors, dependent and independent sources, and 
 special elements which represent user-written subroutines. These elements 
 are selected and connected graphically at the display unit, providing 
 highly symbolic modeling. AEDNET also provides a macro facility. 
 Topological terminal subnetworks can be defined by equivalent circuits 
 composed of basic elements. These subnetworks can then be represented, 
 selected, and topologically interconnected graphically in the same fashion 
 as the pre-defined elements. 
 
 2.7.3. ECAP- I I 
 
 ECAP-II [29] is an advanced version of ECAP developed by Branin 
 et. al. at IBM in 1971. It incorporates nonlinear analysis and macro 
 
58 
 
 capabilities. Nonlinearities can be described by tables, built-in function 
 operators, and user-supplied subroutines. Topological terminal subnetworks 
 can be constructed from basic elements and previously defined subnetworks. 
 ECAP-II was the first widely available package to take advantage of the 
 sparse matrix structure typical of electrical circuits and many other physical 
 systems (see [30]) and to employ an implicit integration method tailored 
 for these typically stiff systems (see [31]). These techniques significantly 
 reduce running time, offering cheaper analysis and somewhat faster turnaround. 
 
 2.7.4. SCEPTRE 
 
 SCEPTRE [32], reported by Bowers and Sedore in 1971, is quite 
 similar to ECAP II. These languages have essentially the same pre-defined 
 elements, features for representing nonlinearities, macro capabilities, 
 and syntax. SCEPTRE has been applied in a variety of disciplines, 
 including pollution studies and biomedical research, in addition to electrical 
 circuit analysis (see [33]). In these applications SCEPTRE integrator 
 elements are used to formulate state, equations as in DAS languages. 
 However, a single SCEPTRE block can be defined to represent many equations, 
 relieving the end-user from explicitly stating each equation. 
 
 2.7.5. SUPER*SCEPTRE 
 
 An advanced version of SCEPTRE, SUPER*SCEPTRE [34], was reported 
 by Bowers and others at the University of South Florida in 1975. SUPER*SCEPTRE 
 includes all features of SCEPTRE and the analysis is performed by the SCEPTRE 
 program. The SUPER*SCEPTRE language also incorporates terminal models for 
 mechanical systems, digital-logic devices, control system transfer functions 
 and nonlinear effects. In each case a generous complement of terminal models 
 are built-in and new ones can be constructed from 'scratch' or from macro 
 subnetworks. Terminal models of all types can be combined conveniently in 
 a single model to describe electro-mechanical and similar interdisciplinary 
 systems. 
 
 The preceding survey is representative of the current state-of- 
 the art, but is not intended to be complete. A brief list of other modern 
 general purpose languages includes DYNAMO II [35] — popular for economic 
 system dynamics but not generally applicable to engineering problems, SL-I 
 [36] — running only on Xerox installations, FORSIM V — a procedural FORTRAN 
 language which supports partial differential equations, and SLANG [38] and 
 
59 
 
 PROSE [39] — two languages developed at TRW, Corp. There also exist packages 
 designed for interactive operation on a dedicated mini-computer, such as 
 CSMP 1130 [40], and DARE-I and II [41]. These packages have limited 
 computational and language features but are very useful for real-time 
 simulations . 
 
60 
 
 NOTES 
 
 1 
 
 Differential equations of explicit form x(t) = f(x(t), t) are often 
 
 solved by so-called 'implicit' methods such as predictor-corrector 
 
 methods. In these methods, an explicit predictor, M , is used to 
 
 predict the next values of x. 
 
 x P (t + At) = M (x(t), x(t),...) 
 
 — p — — 
 
 after which an 'implicit' corrector, M , is used to correct the 
 prediction 
 
 x(t + At) = M ]; (x(t), f(x P (t + At), t),...) 
 
 However, these methods are really explicit as they can be rewritten 
 as 
 
 x(t + At) = M_(x(t), f(M (x(t), x(t),...), t),...) 
 I — p — — 
 
 2 
 
 3 
 
 4 
 
 which is an explicit computation. 
 
 Many packages allow the user a choice of integration algorithms. Some 
 of these offer implicit as well as explicit methods, but require 
 explicit equation formulations to interface with the explicit methods, 
 when used. 
 
 For example, the nested sum A*B+C/D would be specified as a DES-1 
 block input by the expression SUM(MPY(A,B) ,DIV(C,D) ) . 
 
 In fact, this process is quite time-consuming even when performed 
 automatically by packages which derive state equations for explicit 
 integration. See [27], Furthermore, explicit formulation of the 
 state equations is an impossible task for general nonlinear networks. 
 
61 
 
 LIST OF REFERENCES - CHAPTER 2 
 
 [1] "A User's View of Solving Stiff Ordinary Differential Equations" 
 L. F. Shampine and C. W. Gear 
 
 Department of Computer Science Report UIUCDCS-R-76-829, University 
 of Illinois at Urb ana-Champaign, 1976 
 
 [2] "A Survey of Digital Simulation: Digital Analog Simulators" 
 R. D. Brennan and R. N. Linebarger 
 Simulation 3 (6), pp. 244-258, December 1964 
 
 [3] "A Compiler with an Analog-oriented Input Language" 
 M. L. Stein, J. Rose, and D. P. Parker 
 Proceedings 1959 Western Joint Computer Conference , pp. 92-102 
 
 [4] "Changing from Analog to Digital Programming by Digital Techniques" 
 M. L. Stein and J. Rose 
 Journal of the ACM 7 (1), pp. 10-23, January 1960 
 
 [5] "DYSAC: A Digitally Simulated Analog Computer" 
 J. R. Hurley and J. J. Skiles 
 Proceedings AFIPS Spring Joint Computer Conference 23 , pp. 69-82, 1963 
 
 [6] "JANIS, A Program for a General Purpose Digital Computer to Perform 
 Analog-Type Simulations" 
 E. R. Byrne 
 Proceedings ACM National Conference , Denver, Colorado, August 1963 
 
 [7] "MIDAS, An Analog Approach to Digital Computation" 
 R. T. Hartnett, F. J. Sansom, and L. M. Warshowsky 
 Simulation 3 (3), pp. 17-24, September 1964 
 
 [8] "PACTOLUS — A Simulation Language which makes a Digital Computer feel 
 like an Analog Computer" 
 R. D. Brennan 
 Simulation 3 (2), pp. 13-21, August 1964 
 
 [9] "Digital Simulation Languages: A Critique and a Guide" 
 J. J. Clancy and M. S. Fineberg 
 Proceedings AFIPS Fall Joint Computer Conference 27, pp. 23-36, 196"S 
 
 [10] MIMIC DIGITAL SIMULATION LANGUAGE. REFERENCE MANUAL 
 Control Data Corporation, Sunnyvale, California, 1968 
 
 [11] "DSL/90 — A Digital Simulation Program for Continuous System Modeling" 
 W. M. Syn and R. N. Linebarger 
 Proceedings AFIPS Spring Joint Computer Conference 28, pp. 165-187, 1966 
 
 [12] "DES-I. A Real-Time Digital Simulation Computer" 
 M. Pavelsky and J. V. Howell 
 Proceedings AFIPS Fall Joint Computer Conference 24 , pp. 459-471, 1963 
 
62 
 
 [13] "The SCi Continuous System Simulation Language (CSSL)" 
 
 J. C. Strauss, D. C. Augustin, M. S. Fineberg, B. B. Johnson, 
 R. N. Linebarger, and F. J. Sansom 
 Simulation 9 (6), pp. 281-303, December 1967 
 
 [14] "The Modeling of Hierarchical Systems" 
 A. B. Clymer 
 
 Proceedings CSSL Conference on Applications of Continuous System 
 Simulation Languages , pp. 1-16, June 30- July 1, 1969, San 
 Francisco, California 
 
 [15] CDC Continuous System Simulation Language III (CSSL-III) 
 User's Guide, Form 17304400 Revision A 
 Control Data Corporation, Sunnyvale, California, 1971 
 
 [16] IBM Continuous System Modeling Program III (CSMP-III) 
 
 Program Reference Manual, IBM Application Program File Form SH19-7001-0 
 IBM Corporation, White Plains, New York, 1971. 
 
 [17] "DARE-P — A portable CSSL-type simulation language" 
 J. J. Lucas and J. V. Wait 
 Simulation 24 (1), pp. 17-28, January 1975 
 
 [18] RSSL Raytheon Scientific Simulation Language 
 User Guide/Reference Manual, BR-7468 
 Raytheon Data Systems, Turn Norwood, Massachusetts 
 
 [19] "Advanced Continuous Simulation Language (ACSL)" 
 
 E. E. L. Mitchell and J. S. Gauthier 
 Simulation 26 (3), pp. 72-78, March 1976 
 
 [20] THE GASP-IV SIMULATION LANGUAGE 
 A. A. B. Pritsker 
 John Wiley and Sons, Inc., New York, New York, 1974 
 
 [21] "The System/360 continuous system modeling program" 
 R. D. Brennan and M. Y. Silverberg 
 Simulation 11 (6), pp. 301-308, December 1968 
 
 [22] "Continuous System Simulation Languages: Design Principles and 
 Implementation Techniques" 
 R. E. Fairley 
 University of Colorado Report //CU-CS-034-73, December 1973 
 
 [23] "American National Standard FORTRAN" 
 ANSI X3.9 
 American National Standards Institute, New York, New York, 1966 
 
 [24] "Continuous System Simulation by Use of Digital Computers: A State- 
 of-the-Art Survey and Prospectives for Development" 
 
 F. E. Cellier 
 
 Swiss Federal Institute of Technology, 1975 
 
63 
 
 [251 1620 Electronic Circuit Analysis Program [ECAP] 
 
 User's Manual, IBM Application Program File H20-0170-1 
 IBM Corporation, White Plains, New York, 1965 
 
 [261 NETWORK ANALYSIS (2nd Edition) 
 M. E. Van Valkenburg 
 Prentice Hall, Inc., Englewood Cliffs, New Jersey, 1964 
 
 [27] "Comprehensive Active Network Analysis by Digital Computer — A 
 State-Space Approach" 
 C. Pottle 
 
 Proceedings Third Annual Allerton Conference on Circuits 
 and System Theory , pp. 659-668, 1965 
 
 [281 "AEDNET: A Simulator for Nonlinear Networks" 
 J. Katzenelson 
 Proceedings of the IEEE 54 , pp. 1536-1552, 1966 
 
 [291 "ECAP-II — A New Electronic Circuit Analysis Program" 
 F. H. Branin, G. R. Hogsett, R. L. Lunde, L. E. Kugel 
 IEEE Journal on Solid State Circuits SC-6 (4), pp. 146-166, 1971 
 
 [301 "Direct Solutions of Sparse Network Equations by Optimally 
 Ordered Triangular Factorization" 
 W. F. Finney and J. W. Walker 
 Proceedings of the IEEE 55, pp. 1801-1809, 1967 
 
 [311 "The Automatic Integration of Stiff Ordinary Differential Equations" 
 C. W. Gear 
 Proceedings IFIP Congress 1, pp. 187-193, 1968 
 
 [321 SCEPTRE: A COMPUTER PROGRAM FOR CIRCUITS AND SYSTEMS ANALYSIS 
 J. C. Bowers and S. R. Sedore 
 Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1971 
 
 [331 "Applying Computer Analysis Programs to New Areas" 
 J. C. Bowers and D. B. Goodrich 
 Proceedings IEEE-ORSA Joint National Conference , October 1971 
 
 [341 "Systems Analysis using SUPER*SCEPTRE" 
 
 J. C. Bowers, J. E. O'Reilly, Jr., G. A. Shaw, and F. R. Tepper 
 Simulation 25 (5), pp. 158-162, November 1975 
 
 [351 DYNAMO USER'S MANUAL (2nd Edition) 
 A. L. Pugh 
 MIT Press, Cambridge, Massachusetts, 1963 
 
 [36] SL-I Reference Manual 
 
 Xerox Data Systems, El Segundo, California, 1970 
 
 [37] F0RS1M— A FORTRAN Package for the Automated Solution of Coupled 
 Partial and/or Ordinary Differential Equation Systems 
 User's Manual, Atomic Energy of Canada, Ltd., Chalk River, Ontario, 1974 
 
64 
 
 [38] "SLANG — A Problem Solving Language for Continuous Model Simulation 
 and Optimization" 
 J. M. Thames 
 
 Proceedings of the 24th ACM National Conference , pp. 23-41, San 
 Francisco, California, 1969 
 
 [39] "PROSE — A Problem Level Programming System" 
 J. M. Thames 
 Solveware Associates, San Pedro, California, 1973 
 
 [40] 1130 continuous system modeling program 
 
 Program Reference Manual, IBM Application Program File H20-0282 
 IBM Corporation, White Plains, New York, 1967 
 
 [41] "Project DARE: Differential Analyzer REplacement by on-line 
 digital simulation" 
 G. A. Korn 
 Proceedings AFIPS Fall Joint Computer Conference 35 , pp. 247-254, 1969 
 
65 
 
 3. THE MODEL LANGUAGE 
 
 3.1 . Introduction — Design Goals and Fundamental Features 
 
 The development of MODEL was motivated by a desire to extend the 
 power and flexibility of modern simulation languages in order to 
 
 1. provide very general and easy to use modeling features; 
 
 2. facilitate computer aided network design in a wide 
 variety of applications; 
 
 3. provide a convenient structure for hierarchical models; 
 
 4. support different levels of user sophistication; and 
 
 5. offer a flexible environment for simulation studies. 
 No existing general purpose languages provide facilities for network 
 analysis, while existing network analysis languages do not provide the 
 convenient modeling generality which is desired to meet goals 1 and 2. 
 Typically, network analysis languages impose restrictions on network 
 element types and topology due to the manner in which the network 
 equations are formulated. None of these languages provides a convenient 
 facility for defining arbitrary network elements through user-supplied 
 equations. Those user-supplied equations which can be handled must be 
 formulated in block-oriented fashion using the available element types 
 much as in DAS languages. 
 
 In order to meet goals 1 and 2, MODEL combines and extends the 
 most powerful modeling features of general purpose and network analysis 
 languages. MODEL is a general purpose, equation-oriented language which 
 can also be used in a convenient and powerful block-oriented fashion for 
 a wide range of specific network analysis applications. Features of 
 MODEL incorporated or extended from modern general purpose languages 
 include generalized equation-oriented modeling, equation-based macros, 
 and powerful functional capabilities. Facilities more commonly associated 
 with special purpose network analysis languages include topological 
 constructs which can be tailored for particular applications and symbolically 
 connected to construct network models and (in the local implementation) 
 graphical modeling. The provision of highly symbolic topological macros 
 facilitates computer aided network design by permitting very natural 
 problem statements which allow rapid, high level alteration of the network 
 
66 
 
 model during the design process. The provision of generalized features 
 for defining arbitrary topological macros permits MODEL to be applied in 
 a specialized fashion to a wide range of networks, including electrical 
 circuits, structural and mechanical systems, and network flow problems. 
 Equation oriented modeling allows any initial value problems in ordinary 
 differential equations to be conveniently formulated and solved with MODEL. 
 
 MODEL facilitates hierarchical modeling by providing a structure 
 which allows very simple conversion of macros into models and vice versa. 
 Models may be structured into any number of levels of macros and any macro 
 can be conveniently adapted to stand alone as a model. Conversely, any 
 model may be conveniently used as a macro in the construction of higher 
 level models. MODEL permits macro definitions to be altered independently 
 at each level so subsystem models can be refined and verified independently 
 in 'bootstrapping' a hierarchical model. 
 
 The local implementation of MODEL allows extensive libraries of 
 macros to be defined and utilized. This is a convenient facility for 
 special purpose modeling in that topological macros for particular 
 applications need be defined only once. Furthermore, topological macros 
 for particular applications can be defined by sophisticated users for use 
 by novices. While some equation-oriented modeling is required to construct 
 basic topological macros for a particular application, very little 
 sophistication is required to construct network models from library macros. 
 When appropriate constructs are present in the macro library, MODEL can 
 take the form of a special purpose language in which all modeling is 
 performed by interconnecting highly symbolic, predefined blocks. 
 
 In general, MODEL allows equation-oriented and topological 
 modeling to be freely combined in any macro or model. Topological macros 
 for different disciplines may be combined easily in interdisciplinary 
 models. For example, a pressure meter can be modeled by a topological 
 macro which interfaces a water pipe to an electrical control system. 
 
 MODEL is implemented to allow flexibility in the modeling and 
 model execution environments. Two versions of MODEL will be available soon. 
 Tn the 'local' version, MODEL interfaces to the DRAGON interactive 
 graphical modeling and library support package [1], which is nearing 
 completion. DRAGON acts as a front-end to the MODEL compiler, which has 
 
67 
 
 been completed. The input to the MODEL compiler is completely text-oriented and 
 the compiler itself is highly portable, as is the numerical support. Thus, a 
 nongraphical version of MODEL can be used at many other installations. The 
 interactive graphical version of MODEL allows macros and topological 
 connections to be represented graphically at a remote terminal. This 
 permits extremely symbolic modeling which cannot be matched in a text- 
 oriented language. The portable version of MODEL includes nearly every 
 convenience of modern equation-oriented and nongraphical network analysis 
 languages. Some library support may be provided as an extension of the 
 
 portable version of MODEL in the future. 
 
 A MODEL simulation is controlled by a user-supplied FORTRAN program 
 
 which calls the integration procedure as a subroutine. This type of run- 
 control was selected to allow virtually any FORTRAN procedure to be interfaced 
 easily to a simulation study. The MODEL compiler translates a user's model 
 into FORTRAN, which is also the language employed for the compiler and 
 numerical support. The translation and subsequent simulation of a model can 
 be accomplished in any fashion reasonable for a large, FORTRAN-based software 
 package. The package is presently operated as a sequence of jobs or job 
 steps in batch mode. At the local installation it will soon be feasible to 
 invoke these steps on-line from a remote terminal and to receive output 
 from the simulation while it is in progress. The portable version of MODEL 
 could also be used in this fashion at other installations having appropriate 
 hardware/software configurations. Some preliminary thought has been given 
 to extending local support to interactive operation, with run-time 
 interpretation of run-control statements. On-line or interactive simulation 
 is very desirable for computer aided design because it permits rapid 
 evaluation of design alternatives. 
 
 MODEL also offers the user every opportunity to alter any FORTRAN 
 interfaces to the simulation study without recompiling the model. MODEL is 
 the first simulation language to allow a noninteractive run-control program 
 (the FORTRAN run-control program) to be conveniently altered without 
 recompiling the model as well. 
 
 MODEL is also significant as the first implicit general purpose 
 language. The use of an implicit integration method was motivated by 
 numerical considerations (see [2]), but is also highly desirable from the 
 language point of view. MODEL equations maybe formulated implicitly. 
 Together with the use of the differentiation operator ('), this permits 
 a very convenient and natural format for first order ordinary differential 
 
68 
 
 equations. The use of the differentiation operator is restricted only in 
 that it must be applied to variables, rather than to expressions or 
 derivatives although the organization of MODEL makes it feasible to handle 
 the derivatives of expressions. Higher order derivatives and the derivatives 
 of expressions are currently expressed through the introduction of auxiliary 
 variables although a routine extension to MODEL would allow these types of 
 derivatives to be handled directly. In addition to allowing a freer equation 
 format, the use of an implicit integration method makes the MODEL language 
 inherently parallel. 
 
 3.2 . Graphical and Card-Oriented Modeling 
 
 As we have mentioned, an interactive graphical version and a 
 portable text-oriented version of MODEL will soon be in use. Graphical 
 modeling is performed interactively at a remote terminal under the DRAGON 
 support package whose use is described in [1]. Text-oriented modeling is 
 described here and in the user's manual for MODEL [3]. Any differences 
 between the language description given here and that given in [3] reflect 
 changes in the previous version of MODEL which will be incorporated into 
 our updated user's manual. 
 
 For the purpose of distinguishing between graphical and text 
 oriented modeling features, we will refer to the DRAGON dialect and the 
 text dialect of MODEL. The principal differences between the two 
 dialects are the manner in which macros are represented and inserted into 
 a model, the manner in which topologies are defined, and the provision of 
 libraries by DRAGON. In the DRAGON dialect, macros are constructed 
 interactively and represented by mnemonic pictures such as those shown 
 in Figure 3.1. Macros are inserted into a model graphically using 
 DRAGON's extensive commands for positioning mnemonic pictures on the 
 display screen. Macro connection points, called terminals, and 
 connections between these terminals are also expressed graphically. 
 These features permit highly symbolic modeling which cannot be matched 
 in a text oriented language. In the text dialect, text statements are 
 used to represent and insert macros into a model and to define and connect 
 terminals . 
 
 DRAGON maintains three permanent libraries: the element (or 
 macro) library, the terminal (topology) type library, and the FORTRAN 
 library. During an interactive modeling session, temporary libraries 
 are developed through selection of items from the permanent libraries and/or 
 
69 
 
 through user-supplied definitions. The temporary libraries are called the 
 element menu, the terminal type menu, and the FORTRAN menu. The items on 
 a menu can be selected for use in modeling by pointing at the name of the 
 desired item in the menu display area. The entire FORTRAN menu is 
 included in the model automatically. The manner in which items are 
 transferred from the permanent libraries to the menus and vice versa 
 is described in [1]. The definition and use of menu items is discussed 
 here as well as in [1] . 
 
 The only other noteworthy difference between the two dialects 
 of MODEL is the method of identifying problem statements. In the DRAGON 
 dialect, the desired function is selected graphically. In the text 
 dialect, keywords are used to indicate the statement type. With these 
 exceptions all modeling is text-oriented in both dialects and the syntax 
 and semantics of the text strings are identical. Very few restrictions 
 are placed on the order of problem statements and a free format is 
 provided for all text-oriented modeling. There are no fixed column 
 positions. Blanks are significant only as separators and are otherwise 
 ignored . 
 
 The statements of the text dialect of MODEL are listed in 
 Appendix A, which also describes the order in which the input file must 
 be organized in the text dialect. 
 
 ^WV 
 
 o— ///////-o 
 
 oc 
 
 DO 
 
 RESISTOR 
 
 SPRING 
 
 PIPE 
 
 Figure 3.1. Mnemonic pictures for topological macros 
 Terminals are represented by circles 0. 
 
70 
 
 3.3. Overall Model Structure — Elements and Subelements 
 
 The MODEL language makes no distinction between macros and models. 
 In both the DRAGON and text dialects, models are defined in exactly the 
 same fashion as macros. This lack of distinction has the implications that 
 any model can be easily added to the DRAGON' s macro library and any macro 
 can make use of all modeling features of the MODEL language. There are no 
 fixed limits on the depth to which macros may be nested or the number of 
 macros which can be employed in any model. Furthermore, macro definitions 
 may be altered independently at each level of usage. By this we mean that 
 a change in the definition of macro M does not necessarily imply that the 
 definitions of macros which invoke M or are invoked by M must also be 
 changed. This structure was chosen to facilitate the use of the macro 
 library, particularly for modeling hierarchical systems. Subsystem 
 models can quite easily be refined and verified independently in 'bootstrappini 
 a hierarchical model. 
 
 In the remaining discussion, we will refer to macros as 'elements'. 
 When discussing a particular element, it will often be convenient to refer 
 to those elements which it invokes as its 'subelements'. Topological 
 elements are also sometimes called 'networks' . We use this nomenclature 
 to avoid unnecessary distinction between models and macros and to emphasize 
 the fact that all models are themselves language elements (i.e., macros). 
 
 The MODEL language processor will expand any number of element 
 references nested to any depth, provided sufficient core is available. 
 MODEL does not, however, provide a macro interpretive language to support 
 macro-level features such as loops, branches, and conditional expansion. 
 Extensive use of features such as these usually leads to excessive 
 compilation times and thus is rarely warranted. These features have not 
 been implemented in MODEL for this reason and out of an attempt to keep 
 core requirements to a minimum in the language processor. A macro 
 interpretive language may be added to MODEL at some future time. 
 
 3.4 . Element Definition 
 
 3.4.1. Element Modeling Sequence — Parameters and Default Values 
 
 In the text dialect, the name, parameters, and default parameter 
 values, if any, of an element may be defined in a single statement of the 
 general form 
 
71 
 
 ELEMENT e It-name { parm {(d , d )}{ =def-exp ] ;}* 
 
 This statement begins the definition of the element elt-name . All subsequent 
 statements until the next ELEMENT statement or the end of the element 
 definitions serve to define this element. The statements within any element 
 definition may appear in virtually any order. The only restriction is that 
 statements which specify nondefault parameter values and connections for 
 a subelement must follow the statement which invokes that subelement . Each 
 statement type may be used any number of times. When statements of the same 
 type are grouped together within an element definition, it is not necessary 
 to include the keyword for each statement. Any statement which does not 
 begin with a keyword is assumed to be of the same type as the last previous 
 keyword. When the statement following an ELEMENT statement does not begin 
 with a keyword, it is assumed to be an equation statement. Elements may be 
 defined in any order, regardless of the level at which they are invoked. 
 Thus, MODEL offers the most flexible text-oriented modeling sequence of 
 any language presently available. 
 
 In the generalized ELEMENT statement above, elt-name is the name 
 of the element being defined. All names defined in MODEL must be 
 alphanumeric strings of eight characters or less and must begin with a 
 letter. Each use of parm represents a parameter name. All parameters and 
 variables defined in MODEL are floating point quantities and may be scalars 
 or arrays of one or two dimensions. Parameters may represent state or 
 auxiliary variables whose behavior is specified by the equations of the 
 element, or they may represent adjustable constants. The dimensions of 
 parameter arrays are defined in the form parm (d_ 13 d-) where d and d are 
 integers. The dimensions may be omitted when the parameter is a scalar. 
 Default parameter assignments may be defined in the form parm (d- s dp) = 
 def-exp . Default values are typically constants, but def-exp may be any 
 well-defined MODEL expression whose variables are known within the element 
 elt-name . Def-exp must have the same dimensions as parm . The permissible 
 forms for scalar and nonscalar MODEL expressions are described in section 
 3.4.5 which deals with MODEL equations. Default parameter assignments may 
 be omitted when not desired. 
 
 There is no restriction on the number of parameters an element can 
 have. Many parameter definitions can be included in the ELEMENT statement 
 separated by semicolons. The ELEMENT statement must be a single card image 
 
72 
 
 (72 columns), but the DEFAULTS statement may also be used to define 
 additional parameters. This statement has the general form 
 
 DEFAULTS { parm Ud^, d^)}{ =def-exp };}* 
 Any number of DEFAULTS statements may be used in any element. 
 
 Because elements may be defined in any order in the text dialect 
 it is necessary for the user to specify which is the highest level element 
 of the model so the language processor can begin the model analysis with 
 that element. This is done by the ANALYZE statement which has the form 
 
 ANALYZE model-name 
 where mode l-name is the name of the highest level element. This statement 
 precedes the first ELEMENT statement of the input file. If no ANALYZE 
 statement is included, analysis will begin with the element named in the 
 first ELEMENT statement of the input file. 
 
 In the DRAGON dialect, an element is defined at the end of its 
 interactive construction process. The user selects the SAVE function and 
 types in the name by which the element is to be known, e.g., 
 
 {SAVE} name 
 This adds the element's definition to the temporary library (called the 
 menu) , allowing it to be used in the construction of other elements or to 
 be passed to the language processor for compilation and execution. The 
 elements of a model may not be defined in arbitrary order in the DRAGON 
 dialect. Before one element can be used in the construction of another 
 some definition of the first element must be present in the menu. However, 
 in most cases a lower level element of a model may be altered without 
 redefining the higher level elements of the model. The operations involved 
 in the construction of an element can be carried out in any meaningful 
 order and may be repeated any number of times. 
 
 In the DRAGON dialect, the parameters of an element and their 
 default values, if any, are defined prior to SAVEing the element in the 
 menu. Selection of the PARM function allows the user to type in the 
 parameter definitions in the same format as the DEFAULTS statement of the 
 text dialect. Any number of text lines may be entered without reselecting 
 the PARM function. 
 
73 
 
 3. A. 2. Global and Local Variables and the Independent Variable 
 
 In addition to parameter sets, sets of global and local variables 
 may be defined within any element. These are state and auxiliary variables 
 whose behavior is modeled by equations. Local variables are specific to the 
 element in which they are defined. Global variables may be referenced in 
 the equations of the element in which they are defined as well as in the 
 equations of its subelements, their subelements, etc. A variable which is 
 declared as a global in some element E is automatically defined within any 
 subelements of E and need not be explicitly declared in those elements. 
 Like parameters, local and global variables may be scalars or arrays, and 
 no restrictions are placed on the number of variables which can be defined 
 in any element. 
 
 Variable scoping is a very useful feature for hierarchical 
 models, particularly when subsystem models are to be refined independently. 
 MODEL allows the most flexible variable scoping of any simulation language. 
 Other general purpose languages assume that any variables which appear in 
 the body of a macro and are not among its parameters are local to that 
 macro. Thus, variables can have global scope only if they are parameters 
 of all macro invocations. 
 
 In the text dialect, global and local variables are defined by the 
 GLOBALS and LOCALS statements whose general forms are . 
 
 GLOBALS { global {(d , d)};}* 
 LOCALS { local Ud, d_ 2 )};}* 
 Here global and loaal represent variable names and the optional dimensions 
 are represented by (d , d_ ) . Any number of GLOBALS and LOCALS statements 
 may be used in any element . 
 
 In the DRAGON dialect, global and local variables are defined by 
 selecting either the GLO VAR or the LOC VAR function and typing in the 
 definitions in the same format as the GLOBALS and LOCALS statements of the 
 text dialect. Any number of text lines may be entered without reselecting 
 the function. 
 
 The independent variable is known by the default name 'TIME' and 
 can be referenced in the equations of any element. The independent variable 
 can be renamed by the statement 
 
 RENAME ind-var-name 
 where ind-var-name is any legal MODEL name by which the independent variable 
 is to be known. In the text dialect, the RENAME statement must precede the 
 
74 
 
 first ELEMENT statement of the input file. In DRAGON, a RENAME statement 
 can be added to the header block of an element by selecting the HEADER 
 function and typing the statement. When an element is sent to the MODEL 
 compiler, its header block is automatically included in the input file. 
 
 3.4.3. Topology — Terminals, Terminal Types, Terminal Variables, and 
 
 the Generalization of Kirchoff's Laws 
 
 Topological modeling is accomplished through the use of terminals 
 which represent the connection points of an element. Terminals can be 
 used to model a wide variety of connectors, including electrical and flow 
 problem junctions and structural and mechanical joints. We will begin 
 this discussion of topological modeling by considering the manner in 
 which terminals are defined, distinguished, and assigned terminal types. 
 We will then discuss the significance of the terminal variable sets 
 which are associated with each terminal of a given type, and the manner 
 in which terminal variable behavior is defined by terminal connections. 
 The manner in which topological elements are connected into networks 
 is described in the next section. 
 
 Terminals may be either external or local in scope. Local 
 terminals represent intra-element connection points. The local terminals 
 of an element may be connected only within the definition or construction 
 of that element. External terminals represent inter-element connection 
 points. When a subelement is invoked, each of its external terminals is 
 connected to some terminal in the invoking element. Local and external 
 terminals may be freely interconnected any number of times within any 
 element. The external terminals of an element allow it to be connected 
 as a subelement. Local terminals provide a flexible means of connecting 
 the external terminals of subelements into a network. In DRAGON, local 
 terminals can also enhance clarity in the graphical representation of an 
 element. If this mnemonic picture is complex, it may be inconvenient to 
 represent a desired connection in the usual fashion as a straight line 
 between two terminals. A connection line which would otherwise pass 
 through some part of the picture can be rerouted by the introduction of 
 local terminals. 
 
 Each terminal within an element is distinguished by a unique 
 integer called its terminal ID number. Terminal ID numbers provide the 
 
75 
 
 means of distinguishing terminal variable references in the equations of 
 the element . In the text dialect , terminal ID numbers also provide the 
 means of distinguishing terminal references in connection statements. 
 
 In the text dialect, terminals are defined by the TERMINALS 
 statement. This statement defines terminals with local scope. Defined 
 terminals are given external scope by the EXTERNALS statement. The basic 
 formats of these statements are the same. Terminals are identified by 
 ID number and may be referenced singly, e.g. 
 
 TERMINALS 1 
 ; in consecutively numbered groups, e.g., 
 
 EXTERNALS 2-5 
 ; or in any combination of these fashions, e.g., 
 
 TERMINALS 2-5 10 6-8 
 EXTERNALS statements may appear either before or after the TERMINALS 
 statements which define the terminals. Terminals need not be defined in 
 the order of their ID numbers and the set of terminal ID numbers defined 
 within an element need not be consecutive. 
 
 In the DRAGON dialect, selection of the TERM function allows 
 the user to define terminals by pointing at the positions on the screen 
 where terminals are desired. This causes the terminals to be displayed 
 graphically as small circles (0) , and to be assigned ID numbers which can 
 be displayed alongside the terminals. External terminals are specified 
 by selecting the MAKEX command and pointing at the terminals which are to 
 have external scope. 
 
 MODEL imposes no fixed limits on the number of local or external 
 terminals which can be defined in any element. 
 
 We have mentioned that MODEL terminals can be used to model a 
 wide variety of connectors. This variety is accommodated by allowing the 
 terminal type of each terminal to be selected from DRAGON 's library of 
 terminal types or defined by the user. We will first describe the manner 
 in which terminal types are associated with the terminals of an element, 
 and then discuss the definition and significance of terminal types. 
 
 In the text dialect, a terminal type may optionally be associated 
 with each group of terminal ID numbers defined in a TERMINALS statement. 
 Thus, the general form of the TERMINALS statement is 
 
 TERMINALS { te rm- no - te rrn- no type } * 
 where type represents the terminal type name. For example, suppose CONTROL 
 
76 
 
 is the name of a terminal type which models an electrical control junction 
 and FLUID is the name of a terminal type which models a junction in a flow 
 network. Then the statement 
 
 TERMINALS 1 CONTROL 2 3 FLUID 
 would define terminal 1 with type CONTROL, terminal 3 with type FLUID, and 
 terminal 2 with undefined type. 
 
 In the DRAGON dialect, selection of the ASG TYPES function allows 
 the user to select a terminal type from the menu and associate this type 
 with terminals of the element under construction by pointing at the 
 desired terminals. 
 
 In either dialect, it is not necessary to define the type of 
 every terminal. Connections between terminals of different types are not 
 allowed so the MODEL language processor can determine the types of most 
 terminals from the types of terminals to which they are connected. A 
 terminal's type will be undetermined only if no terminal to which it is 
 connected, either directly or indirectly, has been assigned a type. 
 
 The definition of a terminal type consists of the specification 
 of its terminal type name and of the sets of terminal variables which are 
 to be associated with each terminal of that type. The terminal variables 
 represent generalizations of Kirchoff's voltage and current laws and hence 
 are divided into two sets, called the E-set and the I-set. Terminal 
 variables are automatically 'transmitted' through terminal connections. 
 E-type terminal variables (the members of the E-set) act like voltages 
 transmitted through connections. Each variable of the E-set automatically 
 assumes the same value at all terminals connected in a common node. I-type 
 terminal variables act like currents transmitted into an element through 
 its external terminals and transmitted out of an element through the 
 external terminals of its subelements. Under this sign convention each 
 variable of the I-set automatically sums to zero over all terminals 
 connected in a common node. This insures that I-type variables (e.g., 
 currents) do not accumulate at any node. 
 
 MODEL imposes no restrictions on the number of terminal types 
 which can be defined or the number which can be used within any element. 
 
 In the text dialect, terminal types are defined by TYPE 
 statements which precede the first ELEMENT statement of the input file. 
 These statements serve to define terminal types for use within the elements 
 in the input file. 
 
77 
 
 In the DRAGON dialect, terminal types are defined by selecting 
 the MOD TYPES command and typing in the definition. This adds the terminal 
 type to the menu and allows it to be selected for use via the ASG TYPES 
 command which we have previously described. 
 
 The format for terminal type definitions is the same in both 
 dialects. The general form in the text dialect is 
 
 TYPE type-name E({ ename {(d 3 dj};}*) l({ iname{ (d 3 dj};}*) 
 type-name represents the name of the terminal type, ename and iname 
 represent a terminal variable name. The dimensions of the terminal 
 variables represented by (d , d~) are optional and may be omitted for 
 scalar variables. The terminal type definition must be a single card 
 image, but otherwise MODEL imposes no restrictions on the number of 
 terminal variables which can be associated with any terminal type. Either 
 the E-set or the I-set may be omitted if no terminal variables of one type 
 are required. 
 
 The TYPE statements of Figure 3.2 illustrate the terminal type 
 definition format and the use of E-type and I-type terminal variables to 
 represent various network junction effects. The symbol % denotes comment 
 text . 
 
 MODEL is the first language to generalize the application of 
 Kirchoff's laws which are common network principles. The automatic 
 imposition of these laws at each node of the network offers the convenience 
 of topological modeling in a wide variety of applications. Terminal 
 variables can be used to model junction effects such as deflections, 
 forces, stresses, strains, pressures, flow rates, and many more. Topo- 
 logical modeling is conceptually simplified by allowing symbolic names to 
 be selected for terminal types and terminal variables. Interdisciplinary 
 modeling is facilitated by allowing the definition and use of any number 
 of terminal types. Generality is provided by allowing terminal variable 
 behavior to be defined by user-written equations as well as by the 
 automatic application of Kirchoff's laws. Equation modeling of terminal 
 variables will be illustrated in section 3.4.5. First, we will discuss 
 the invocation and connection of subelements. 
 
78 
 
 % ELECTRICAL JUNCTION 
 
 TYPE ELECTRIC E (VOLTAGE) I (CURRENT) 
 % FLUID JUNCTION 
 
 TYPE FLUID E (PRESSURE) I (FLOW) 
 % CONTROL JUNCTION 
 
 TYPE CONTROL E (LEVEL) 
 
 % STRUCTURAL PIN JOINT: MODELED IN TERMS OF 
 % FORCES AND DEFLECTIONS IN THREE DIMENSIONS 
 
 TYPE PINJOINT E(DEFLX;DEFLY;DEFLZ) I (FORCEX; FORCE Y ;FORCEZ) 
 
 % STRUCTURAL JOINT :MODELED IN TERMS OF STRESS 
 
 % AND STRAIN TENSORS IN TWO DIMENSIONS. 
 
 % STRESS (l)«-a STRAIN (1H£ 
 
 x x 
 
 % STRESS (2)«-a STRAIN (2)«-€ 
 
 y y 
 
 % STRESS (3)<-t (SHEAR) STRAIN (3)+- Y (SHEAR STRAIN) 
 TYPE S JOINT E (STRESS (3)) I (STRAIN (3)) 
 
 Figure 3.2. Terminal type definitions. 
 
79 
 
 3.4.4. Connections and Subelement Invocation 
 
 Intra-element connections are specified differently than 
 inter-element connections in both dialects of MODEL. We will first 
 discuss intra-element connections — that is, connections between the 
 local and external terminals of a single element. Then we will consider 
 the manner in which subelements are invoked and connected into a network. 
 
 In the text dialect, intra-element connections are specified 
 by the CONNECT statement which has the general form 
 
 CONNECT { tevm-no - term-no }* 
 
 In the DRAGON dialect, intra-element connections are specified 
 by selecting the CONNECT function and pointing at the pairs of terminals 
 to be connected. Connections appear on the screen as a straight line 
 joining the two terminals. 
 
 In both dialects, the local and external terminals of any 
 element may be freely interconnected with no topological restrictions. 
 
 In the text dialect, subelements are invoked by the SUB-ELEMENT 
 statement which has the general form 
 
 SUB-ELEMENT sub-elt-name { parm=expj }* 
 sub -e It-name is the name of the element to be invoked. The pavm=exp 
 represent a sequence of nondefault parameter assignments for the subelement, 
 They may be specified in any order. Parameter assignments can be any well- 
 defined MODEL expressions whose variables are known within the invoking 
 element. Parameter assignments can be omitted when default values are 
 defined. A single SUB-ELEMENT statement is used for each subelement 
 invocation. When many parameter assignments are needed, the NON-DEFAULTS 
 statement can also be used. This is the complement of the DEFAULTS 
 statement and has the general form 
 
 NON-DEFAULTS { parm=exp$ * 
 where parm represents a parameter name and exp represents the expression 
 whose value is to be assigned to that parameter. Parameter values may be 
 assigned in any order in the NON-DEFAULTS statement. Any parameters which 
 are not assigned values in SUB-ELEMENT and NON-DEFAULTS statements will 
 assume their default values if these are defined. 
 
 In order to accommodate multiple invocations of the same element, 
 each NON-DEFAULTS statement must follow the SUB-ELEMENTS statement to which 
 it refers and no other SUB-ELEMENT statements may intercede. 
 
80 
 
 The use of the ELEMENTS, DEFAULTS, SUB-ELEMENT, and NON-DEFAULTS 
 statements is illustrated in the following example. The element EX has 
 parameters which are defined by the statements 
 
 ELEMENT EX PI ;P2=5 ;P3 (4 ,4) 
 
 DEFAULTS P4=4;P5 
 It is invoked by an element which includes the statements 
 
 LOCALS X;Y;A(4,4) 
 
 SUB-ELEMENT EX P1=X+Y;P3=A 
 
 NON-DEFAULTS P5=21 
 For this invocation of EX, PI will be replaced by X+Y . P2 and 
 P4 will be replaced by their default values, 5 and 4, respectively. P3 
 will be replaced by A which might be an array of state variables whose 
 behavior is defined by EX. P5 will be replaced by 21. 
 
 In the DRAGON dialect, subelements are invoked by pointing at 
 the desired element name in the menu and then pointing at the terminals 
 to which the subelement is to be connected in the proper sequence. The 
 subelemenr's graphical representation will then be displayed between the 
 terminals to which it is connected. Local terminals can be defined by 
 pointing at vacant areas of the screen rather than existing terminals. 
 If the subelement has no external terminals, the user points at the area 
 of the screen where the subelement' s. graphical representation (which may 
 be only its name) is to appear, and no terminals are defined. Parameter 
 assignments for the subelement are specified by selecting the CH PARMS 
 command. This displays the list of default parameter assignments for the 
 subelement which was entered via the PARMS command. To change a default 
 assignment the user points at and then retypes the text line in question. 
 As in the text dialect, the nondefault parameter assignments may be any 
 expressions involving variables and parameters of the invoking element 
 and global variables. 
 
 In the text dialect, subelements are connected into a network by 
 the SUB-CONNECT statement. This statement has the general form 
 
 SUB-CONNECT { term-no }* 
 The term-no represents the ID numbers of the terminals in the invoking 
 element to which the subelement is to be connected. Their order corresponds 
 to the order in which the external terminals of the subelement are defined 
 in its TERMINALS statements. Like the NON-DEFAULTS statement the SUB-CONNECT 
 
81 
 
 statement must follow the corresponding SUB-ELEMENT statement with no other 
 SUB-ELEMENT statements interceding. 
 
 In both dialects of MODEL, subelements may be freely inter- 
 connected through the terminals of the invoking element . MODEL imposes no 
 restrictions on inter-element topology. Many network analysis packages 
 impose such restrictions due to the manner in which they formulate the network 
 equations. Most network analysis packages formulate explicit state 
 equations from the network topology by matrix methods. Many of these 
 packages cannot integrate topologies which involve equivalent state 
 variables (parallel capacitors and serial inductors are frequent examples 
 in electrical circuit analysis) because of resulting matrix singularities. 
 MODEL determines the state variables symbolically from the tableau of 
 implicit equations, and (together with its associated numerical software) 
 automatically removes equivalent variables and redundant equations. Thus, 
 there is no problem with matrix singularities due to equivalent state 
 variables, either in the state formulation or in the integration. 
 
 The SUB-CONNECT statement can also be used to establish pseudo-ID 
 numbers for the external terminals of subelements. This would be done to 
 allow the equations of the invoking element to reference I-set variables at 
 these terminals. References to E-set variables do not present the same 
 problem because these variables assume the same value at the terminal to 
 which they are connected. However, when two or more external subelement 
 terminals are connected to the same local terminal (which is typically the 
 case) , a reference to an I-set variable at that terminal would not be 
 well-defined. References to I-set variables at local terminals are not 
 allowed due to the lack of a convenient convention for the direction of 
 flow at these terminals. Thus, it may be necessary to reference an I-set 
 variable at an external subelement terminal. A pseudo-ID number to be 
 used for such a reference can be defined by attaching it to the ID number 
 of the connected terminal in the SUB-CONNECT statement. For example, 
 
 SUB-CONNECT 3 4-1 2 
 establishes -1 as the pseudo-ID number of the second external terminal 
 of subelement EX. In the DRAGON dialect the PSID function can be used to 
 establish and display a pseudo-ID number. After selecting the PSID function 
 the user identifies the external subelement terminal by pointing at the 
 connected local terminal and typing the subelement name. A generated pseudo- 
 ID number will then appear on the screen. 
 
82 
 
 An experimental feature of the text dialect is the strip 
 terminal. Strip terminals allow elements to be used with a variable 
 number of external connections without shorting any connections together. 
 This feature is provided for modeling elements which have a variable 
 number of input lines such as the voltage summer of Figure 3.3. The use 
 of the strip terminal allows the voltage summer to be modeled by a single 
 element regardless of the number of input lines used in each invocation. 
 Any number of terminals may be directly connected to an external strip 
 terminal of a subelement . Each such connection causes MODEL to generate 
 a terminal within the subelement to receive the connection. 
 
 Strip terminals are defined in the TERMINALS statement by 
 prefixing their ID numbers with the letter S, i.e., 
 
 TERMINALS SI 2 3 
 Strip terminals always have external scope and need not be declared as 
 external in an EXTERNALS statement. 
 
 The external strip terminals of a subelement are connected into 
 a network by CONNECT statements in the invoking element. To permit these 
 terminals to be identified in CONNECT statements it is necessary to define 
 a unique pseudo-ID number for each strip terminal invoked by an element. 
 This is done in the SUB-CONNECT statements by entering Sn in place of a 
 connection to the invoking element. For example, the statement 
 
 SUB-CONNECT S7 1 2 
 specifies that the first external terminal of subelement SUMMER is a strip 
 terminal which will be referenced in the CONNECT statements of the invoking 
 element as terminal number 7. 
 
 The SUB-CONNECT statement does not define a connection to the 
 external strip terminal of SUMMER as it does for the other two external 
 terminals. Connections to the strip terminal are specified in CONNECT 
 statements of the invoking element. The statement 
 
 CONNECT 3-7 4-7 5-7 6-7 
 causes the generation of four external terminals in subelement SUMMER. 
 These terminals are connected to terminals 3, 4, 5, and 6, respectively, of 
 the invoking element. This is illustrated in Figure 3.3b. 
 
 Connections between two strip terminals or between a strip 
 terminal and another terminal of the same element are not allowed. 
 
83 
 
 2 
 -O 
 
 3 
 -O 
 
 TERMINALS SI CONTROL 2:3 CONTROL 
 
 EXTERNALS 2:3 
 
 EQUATIONS LEVEL(2)=MAX(LEVEL(1)) 
 
 LEVEL(3)=SUM(NSTRIP(1) ,LEVEL(1)) 
 
 Figure 3.3a. Voltage summer modeled by the statements 
 
 SUB-ELEMENT SUMMER 
 SUB-CONNECT S7 1 2 
 CONNECT 3-7 4-7 5-7 6-7 
 
 Figure 3.3b. Voltage summer connected into a network by the statements. 
 
 Figure 3.3. Voltage summer ({} represents the strip terminal).* 
 
 *The strip terminal is not presently supported by DRAGON. Thus, the 
 figures above represent conceptualizations of the voltage summer, rather 
 than mnemonic pictures constructed with DRAGON. 
 
84 
 
 For strip terminals to be useful there must be some special 
 operators available for referencing the generated terminals in the equations 
 of the subelement. We will continue the example of a voltage summer to 
 illustrate the possibilities which presently exist. 
 
 The element SUMMER has three external terminals, defined by 
 the statements 
 
 TYPE CONTROL E (LEVEL) 
 
 TERMINALS SI CONTROL 2:3 CONTROL 
 
 EXTERNALS 2:3 
 The input lines are connected to the strip terminal. External terminals 
 2 and 3 transmit the maximum and the sum, respectively, of the input 
 levels. This can be expressed in the equations of SUMMER in the form 
 
 LEVEL ( 2 ) =MAX (LEVEL ( 1 ) ) 
 LEVEL (3 )=SUM (NSTRIP (1), LEVEL (1)) 
 References to strip terminal variables such as LEVEL (1) are treated in a 
 special way when they appear as function arguments. If subelement SUMMER 
 is connected by the statements 
 
 SUB-CONNECT S7 1 2 
 CONNECT 3-7 4-7 5-7 6-7 
 then LEVEL(l) will be replaced in the argument list above by the sequence 
 of arguments 
 
 LEVEL(3) ,LEVEL(4) ,LEVEL(5) ,LEVEL(6) 
 Here 3, 4, 5, and 6 are the ID numbers of the terminals generated by the 
 connection of terminals 3, 4, 5, and 6 of the invoking element to the 
 external strip terminal of SUMMER. In the first equation above, MAX refers 
 to the built-in FORTRAN library function for the maximum of a variable 
 number of arguments. In the second equation, SUM refers to a user-written 
 FORTRAN function subroutine which forms the sum of a variable number of 
 arguments. NSTRIP is a built-in operator whose value is the number of 
 terminals directly connected to a strip terminal. In this case, strip 
 terminal 1 has four direct connections in the invoking element so NSTRIP (1) 
 is four. It is used to indicate the number of actual arguments in each 
 reference to SUM. The second equation also illustrates that other 
 arguments may precede (or follow) a reference to a set of generated 
 terminal variables. 
 
85 
 
 MODEL is the first network analysis language to provide a strip 
 terminal. In other languages, a variable number of input lines can be 
 modeled only by defining many external terminals and connecting only as 
 many as are needed in each invocation. This method can be used in MODEL 
 as well. E-set and I-set variables are set to zero at unconnected 
 terminals. Strip terminals could prove to be a great convenience where 
 applicable. The use of a strip terminal could avoid the necessity of 
 defining a different version of an element for each number of input lines 
 which might be employed. However, the present features for referencing 
 strip terminal variables are only rudimentary. This would be an 
 appropriate area for future development of MODEL, perhaps as a subset 
 of a macro (element)-interpretive language. 
 
 3.4.5. Equations 
 
 MODEL allows the equations of each element to be formulated 
 implicitly. By this we mean that the general form of an equation is simply 
 
 where eccp and exp r represent arbitrary algebraic or first order ordinary 
 differential expressions involving constants, variables, and parameters 
 known within the element and built-in and user-defined operators. 
 (Parameter assignments are a special case of this form in which the left 
 hand side is a single parameter.) There is no need for the user to derive 
 an explicit state formulation. As the first implicit equation-oriented 
 language, MODEL offers the most flexible and convenient format for 
 equations of any existing language. MODEL is also the first language to 
 allow the differentiation operator (') to be embedded freely in expressions. 
 This obviates the necessity of introducing auxiliary variables in order to 
 reference state derivatives as one must in explicit languages. Any 
 algebraic or first order ordinary differential equation which represents 
 a desired relationship between problem variables and parameters can be 
 entered directly. It is presently necessary to introduce auxiliary 
 variables to represent higher order derivatives and the derivatives of 
 expressions, but a routine extension of MODEL would allow the differentiation 
 operator to be applied to derivatives and expressions as well as to 
 variables and parameters. 
 
86 
 
 In addition to allowing a very flexible equation format, the 
 use of an implicit integration method means that no special operator is 
 needed to solve implicit equations. Furthermore, the set of equations 
 need not even be sortable — that is, algebraic loops may be present as 
 is often the case in complex network problems. Thus, MODEL can be used 
 to solve a larger class of problems than can explicit languages. 
 
 The operators which can be used in MODEL equations and parameter 
 assignments are the differentiation operator, standard infix operators 
 for scalar and array arithmetic, built-in functions, and functions 
 defined by the user or selected from the DRAGON library. All of these 
 operators can be freely embedded in expressions and, with the above- 
 mentioned restriction on the use of the differentiation operator, all 
 can be freely nested to any level of parenthesis. 
 
 The operators available in MODEL are listed in Figure 3.4 along 
 with the precedences which determine the ordering of operations in 
 expression evaluation. Arithmetic expressions are evaluated in the 
 usual order (the same as FORTRAN) . Parentheses may be freely inserted 
 to change the order of evaluation. Built-in, user-defined, and MODEL 
 library functions all have the same precedences and are grouped together 
 under the heading 'functions'. The built-in functions are' listed in 
 Figure 3.5. User-defined functions are discussed in section 3.5. The 
 relational and logical operators <, >, &, and |, will be discussed in 
 section 3.4.6 which deals with the logical switching of equations. 
 
 MODEL is the first language to provide infix operators for the 
 common array operations of addition (+) , subtraction (-) , multiplication 
 (*) , and inner product (.). FORTRAN functions defined by the user or 
 selected from the DRAGON library can also operate on arrays, as can the 
 differentiation operator. Dimensioned expressions involving array 
 variables and operators may be embedded in any equation. For example, 
 if F is a 4 x 4 array of coefficients and X is a 4 x 1 state vector, 
 then the single array equation 
 
 X' = F*X 
 can be used in place of the four associated scalar equations. MODEL does 
 not presently support array indexing in equations. The equations must 
 operate on arrays as indivisible entities. A routine extension of MODEL 
 would permit indexing in equations. Indexing is presently possible at the 
 FORTRAN level in the run-control program and FORTRAN function programs. 
 
operator 
 
 input precedence 
 
 stack precedence 
 
 ( 
 
 function 
 
 unary- 
 
 * (array or scalar) 
 
 / 
 
 . (inner product) 
 + (array or scalar) 
 - (array or scalar) 
 
 (relational) 
 
 (relational) 
 
 (logical and) 
 
 (logical or) 
 
 13 
 
 13 
 
 12 
 
 12 
 
 10 
 
 10 
 
 9 
 
 8 
 
 8 
 
 7 
 
 7 
 
 6 
 
 5 
 
 4 
 
 1 
 
 3 
 
 2 
 
 11 
 
 11 
 
 10 
 
 10 
 
 9 
 
 8 
 
 8 
 
 7 
 
 7 
 
 6 
 
 5 
 
 unary+ 
 
 1 (differentiation) 
 
 (not defined)** 
 
 1 
 
 (not defined)** 
 (not defined) 
 
 Figure 3.4. MODEL operators and precedences. 
 
 *The differentiation operator can presently be applied only to variables and 
 parameters and thus is implemented as a suffix to the variable or parameter 
 name . 
 
 **The unary+ and right parenthesis operators are never placed on the 
 operator stack. 
 
 The input and stack precedences have usual meanings. In parsing 
 equation syntax, each operator is stacked as it is read and removed from the 
 stack when all of its operands are known. If the input precedence of the 
 operator being parsed is higher than the stack precedence of the operator 
 on top of the stack, the input operation takes precedence and its result is 
 an operand of the stack operator. The input operator is simply pushed on top 
 of the stack. Thus, A+B*C means A+(B*C) and -A**B means -(A**B). If the 
 stack precedence is greater than or equal to the input precedence, the stack 
 operation takes precedence. Operators are popped from the stack until the 
 stack precedence becomes less than the input precedence. The input operator 
 is then pushed on top of the stack. Thus, A*B+C means (A*B)+C and A**B*C 
 means (A**B)*C. If the stack and input precedences of an operator are the 
 same (i.e., *) , the operator associates left to right. If the stack 
 precedence of an operator is less than its input precedence (i.e., **) , the 
 operator associates right to left. 
 
88 
 
 
 function name 
 
 corresponding FORTRAN 
 
 ■- ■ iiuiaiy j-uiiui-luu 
 
 LOG 
 
 DLOG 
 
 EXP 
 
 DEXP 
 
 SQRT 
 
 DSQRT 
 
 ATAN 
 
 DATAN 
 
 ABS 
 
 DABS 
 
 COS 
 
 DCOS 
 
 SIN 
 
 DSIN 
 
 MAX 
 
 DMAX1 
 
 MIN 
 
 DMIN1 
 
 SQUARE 
 
 
 STEP 
 
 
 description 
 
 natural logarithm of the argument 
 
 e raised by the argument 
 
 positive square root of the argument 
 
 arc tangent (in radians) of the 
 
 argument 
 
 absolute value of the argument 
 
 cosine of the argument (in radians) 
 
 sine of the argument (in radians) 
 
 maximum of the arguments 
 
 minimum of the arguments 
 
 square of the argument 
 
 Step function 
 
 Figure 3.5. MODEL built-in functions. 
 
89 
 
 The equations may reference any terminal variable associated 
 with any terminal of the element with the exception of I-set variables 
 at local terminals. Terminal variables are identified by the variable 
 name followed by the terminal ID number in parentheses, i.e., FL0W(2) . 
 If FLOW is an I-set variable, FLOW (2) is the rate of flow directed into 
 the element at external terminal number 2. If the value of FL0W(2) is 
 negative, the simulated fluid is flowing out of the element. When a 
 pseudo-ID number is used to reference an I-set variable at an external 
 terminal of a subelement, the direction convention is the same — the 
 I-set variables represent rates of flow directed into the subelement. 
 Thus, if -2 is the pseudo-ID number of an external subelement terminal, 
 FL0W(-2) is positive if simulated fluid is flowing into the subelement, 
 and is negative if the flow is out of the subelement (and thus into the 
 invoking element) . 
 
 In the text dialect, equations are entered by the EQUATIONS 
 statement which has the general form 
 
 EQUATIONS { exp =exp r ; } 
 If the EQUATIONS statement is the first statement within the element 
 definition, it is not necessary to include the keyword EQUATIONS. This 
 permits elements which include only equations to be defined with a minimum 
 of effort. 
 
 In the DRAGON dialect, equations are entered by selecting the 
 EQUATIONS function and typing in the equations. 
 
 In any well-defined model, there will be one equation for each 
 variable present. The variables of a model consist of the global and 
 local variables, parameters, and terminal variables of each element which 
 is invoked. In general, each element should include one equation for each 
 global and local variable defined in the element. In some cases a variable 
 is defined in one element while its behavior is defined by an equation 
 of a subelement which references it as a global variable or is invoked 
 with it as a parameter. The behavior of parameters is frequently defined 
 by the parameter assignments used in invoking the element (i.e., P=5, 
 P=X+Y*Z) . Sometimes a parameter represents a state or auxiliary variable 
 whose behavior is defined by an equation of the element. In these cases, 
 the parameter will simply be replaced by a variable of the invoking 
 element (i.e., P=X) and the invoked element will include an additional 
 
90 
 
 equation which defines the parameter's behavior. The parameters of the 
 highest level element of the model are assigned values in the run-control 
 language . 
 
 As concerns terminal variables, each distinct E-type (voltage) 
 and I-type (current) variable of the network must be defined by an 
 equation in some element. The manner in which equations defining 
 terminal variable behavior are associated with elements depends on the 
 meaning of the elements — there is no rigid general rule. The two most 
 common fashions of defining terminal variable behavior are described in 
 the following two paragraphs. 
 
 Functional elements which have distinct input and output lines 
 typically include one equation for each terminal variable at each external 
 'output' terminal. In these cases, one and only one 'output' terminal 
 will be connected to each node. The voltage summer of the previous 
 section is an example of such an element. 
 
 Elements which make no distinction between input and output 
 terminals typically include one equation for each E/I-set pair at each 
 external terminal. There is only one equation for each pair of terminal 
 variables because the terminal variables of a network are not usually 
 distinct — i.e., connecting two terminals essentially equivalences their 
 terminal variables (with a difference in sign for I-set variables) . 
 Thus, equations defining the behavior of the terminal variables of one 
 element are present — in effect — in connected elements. In these cases, an 
 element with M unconnected external terminals, each having P pairs of 
 E/I-set variables, will typically include MP equations defining terminal 
 variable behavior. In elements with multiple external terminals (M>1) 
 there is typically one equation for each I-set variable. This equation 
 relates the values of the I-set variable at all of the external terminals 
 usually by summing these values to zero. For each E/I-set pair the 
 remaining M-l equations relate the values of the E-set variable at the M 
 external terminals. 
 
 The remainder of this section presents four examples of element 
 definitions which illustrate the use of equations to define terminal 
 variable behavior in the fashion described in the preceding paragraph. 
 These examples come from the areas of electrical, mechanical, fluid, and 
 structural networks. The elements to be modeled are a capacitor, a spring, 
 a reservoir, and a beam. 
 

 91 
 
 Capacitor 
 
 A graphical representation of a capacitor and the MODEL text dialect 
 statements which define this element are shown in Figure 3.6. 
 
 ] 2 
 
 O 1 I O 
 
 TYPE ELECTRIC E(V) 1(1) 
 
 ELEMENT CAPACITOR C 
 TERMINALS 1:2 ELECTRIC 
 EXTERNALS 1:2 
 EQUATIONS I(l)+I(2)=0 
 
 V(1)'-V(2)'=I(1)/C 
 
 Figure 3.6. Capacitor. 
 
 The capacitor has one parameter, C, which is its capacitance. 
 Terminals 1 and 2 are external terminals of type ELECTRIC with E-set 
 consisting of V, the voltage, and I-set consisting of I, the current. 
 The first equation states that any applied current is transmitted through 
 the capacitor. The second equation relates the voltage across the capacitor 
 to the current through it according to the capacitor equation 
 
 V = 1/C /i dt 
 This equation has been differentiated to yield 
 
 V = i/C 
 We have expressed this equation as if positive current enters at terminal 
 1, representing the voltage across the capacitor as V(l) - V(2) and the 
 current through the capacitor as 1(1). This yields the equation 
 V(l)' - V(2)' = I(l)/C. Since 1(1) = -1(2), this is equivalent to the 
 equation V(2) ' - V(l)' = I(2)/C, which is the natural form when positive 
 current enters at terminal 2. 
 
 The capacitor model could be connected to any similarly modeled 
 electrical elements such as other capacitors, resistors, inductors, 
 voltage and current sources and sinks, diodes, transistors, etc. 
 
 Spring 
 
 A graphical representation of a spring and the MODEL text dialect 
 statements which define this element are shown in Figure 3.7. 
 
92 
 
 o ///////// — o 
 
 TYPE MECH E(X) 1(F) 
 
 ELEMENT SPRING K;L 
 TERMINALS 1:2 MECH 
 EXTERNALS 1:2 
 EQUATIONS F(l)+F(2)=0 
 
 K*(X(2)-X(1)-L)=F(2) 
 
 Figure 3.7. Spring. 
 
 The spring has two parameters, K and L, which are its spring 
 constant and its undeformed length, respectively. Terminals 1 and 2 are 
 external terminals of type MECH with E-set consisting of X, the displacement, 
 and I-set consisting of F, the force. The first equation states that 
 applied forces are transmitted through the spring. 
 
 The second equation relates the deformation of the spring to the 
 force exerted by the spring according to Hooke's law, KAX = F. The positive 
 X axis is assumed to be in the direction from terminal 1 toward terminal 2. 
 Thus, the deformation of the spring is expressed as X(2) - X(l) - L. The 
 associated force exerted by the spring is F(2) whose positive direction 
 is from terminal 2 toward terminal 1. Hence the equation 
 
 K*(X(2) - X(l) - L) = F(2) 
 
 This spring model could be connected to any similarly modeled 
 mechanical elements such as other springs, fixed and movable masses, 
 forces, etc. 
 
 Reservoir 
 
 A graphical representation of a reservoir and the MODEL text 
 dialect statements which define this element are shown in Figure 3.8. 
 
 The reservoir has three parameters, AO, Al , and HI, which are 
 the area of the reservoir's surface, the cross-sectional area of the 
 outlet, and the height of the outlet, respectively. Local variables HO, 
 PI, and VI are used to represent the height of the reservoir's surface, 
 the pressure at the outlet, and the velocity of the fluid through the 
 outlet. The outlet is represented by terminal 1. This is an external 
 
93 
 
 terminal of type FLUID with E-set consisting of B, the sum of the kinetic, 
 potential, and intrinsic energy of the fluid, and I-set consisting of FLOW, 
 the flow rate of the fluid. 
 
 ZI o 
 
 TYPE FLUID E(B) I (FLOW) 
 GLOBALS GAMMA; G 
 
 ELEMENT RESERVOIR A0;A1;H1 
 LOCALS H0;P1;V1 
 TERMINALS 1 FLUID 
 EXTERNALS 1 
 
 EQUATIONS HO'*AO-FLOW(1)=0 
 V1=-FL0W(1)/A1 
 
 B(l)=Pl/GAMMA+Vl**2/(2+G)*Hl 
 B(1)-H0 
 
 Figure 3.8. Reservoir. 
 
 The first equation defines the rate of change in the height of 
 the reservoir's surface, HO', in terms of the rate at which fluid flows 
 out of the reservoir which is -FL0W(1) by convention. The second equation 
 defines the velocity of the fluid flow through terminal 1, VI, in terms of 
 the rate of flow. The last two equations define the pressure, PI, and 
 total energy, B(l), of the fluid at terminal 1. They make use of the 
 Bernoulli equations of fluid mechanics applied to a steady flow situation. 
 These equations state that the quantity 
 
 V 2 /2G + H + P/GAMMA 
 has the same value at any point along a flow line. The variables in this 
 quantity are 
 
 G the acceleration due to gravity 
 
 GAMMA the density of the fluid 
 
 V the velocity of the fluid at the point in question 
 
 P the pressure of the fluid at the point in question 
 (above one atmosphere) 
 
 H the height of the point in question 
 
94 
 
 The equation 
 
 B(l) = PI/GAMMA + V1**2/(2*G) + HI 
 relates the total energy at terminal 1, B(l), to the fluid pressure, velocity, 
 and height there. The equation 
 
 B(l) = HO 
 equivalences the values of the Bernoulli quantity at terminal 1 and at the 
 surface, where the pressure is one atmosphere and the velocity, HO', is too 
 small to affect the Bernoulli quantity appreciably. 
 
 The reservoir model could be connected to any similarly modeled 
 fluid elements such as other reservoirs, pipes, flow sinks and sources, etc. 
 
 Beam 
 
 A graphical representation of a structural beam and the MODEL 
 text dialect statements which define this element are shown in Figure 3.9. 
 The beam parameters and terminal variables represent the following 
 
 quantities: 
 
 2 
 E Young's modulus, in lbs/ft . This depends only on 
 
 the material of the beam; 
 
 I Moment of inertia of the beam about the axis perpendicular 
 to the plane of bending; 
 
 A Cross-sectional area of the beam; 
 
 L Length of the beam; 
 
 DX Displacement of the terminal in the X direction; 
 
 DY Displacement of the terminal in the Y direction; 
 
 DTH Angular rotation of the terminal in the XY plane; 
 
 PX Force applied at the terminal in the X direction; 
 
 PY Force applied at the terminal in the Y direction; 
 
 MXY Moment applied at the terminal in the XY plane. 
 
 The equations of Figure 3.9 model the terminal variables of the 
 beam in a static situation (see [4]). This illustrates the use of MODEL 
 to solve static as well as dynamic systems. Since no derivatives or 
 differential equations are present and the independent variable is not 
 used, a structural network modeled in this fashion will be solved at 
 only one, arbitrary value of TIME. 
 
 The beam model could be connected to any similarly modeled 
 structural elements such as other beams, loads, and immovable masses. To 
 
95 
 
 represent a vertical beam it is necessary to replace PX and DX with PY and 
 DY in the equations and vice versa in order to maintain a single 
 coordinate system. 
 
 1 2 
 
 \ i i in 1 1 n a 1 1 1 1 1 a 1 1 1 1 a 1 1 1 ii 1 1 1 1. 
 
 o 
 
 in in ii 1 1 a i mi in in it i nuii 
 
 The positive direction conventions for the terminal variables are 
 
 PX(1) 
 
 PY(1) 
 Ol 
 
 2 o 
 
 PX(2) 
 PY(2) 
 
 TYPE STRUCT E(DX;DY;DTH) I(PX;PY;MXY) 
 
 ELEMENT BEAM E;I;A;L 
 
 TERMINALS 1:2 STRUCT 
 
 EXTERNALS 1:2 
 
 EQUATIONS PX(1)=(E*A/L)*DX(1) 
 
 PY(1)=(6*E*I/(L*L))*((2/L)*DY(1)-DTH(1)-DTH(2)) 
 
 MXY(l)=(2*E*I/L)*((-3/L)*DY(l)+2*DTH(l)+DTH(2)) 
 
 PX(2)=(E*A/L)*DX(2) 
 
 PY(2)=(6*E*I/(L*L))*((2/L)*DY(2)-DTH(1)-DTH(2)) 
 
 MXY(2)=(2*E*I/L)*((-3/L)*DY(2)+2*DTH(2)+DTH(l)) 
 
 Figure 3.9. Static, prismatic beam in two dimensions. 
 
 3. A. 6. Logical Switching of Equations 
 
 MODEL supports the logical switching of equations via IF, THEN, 
 ELSE IF, and ELSE clauses within EQUATIONS statements. The general form 
 of a conditional equation is 
 
 IF aond THEN eqn 
 {ELSE IF aond THEN eqn}* 
 
 ELSE eqn 
 Each use of eqn represents any MODEL equation. Each use of aond represents 
 a condition such as X < Y & Y > Z. The relational operators < (less than) 
 and > (greater than) can be used to define threshold relations between 
 arbitrary scalar expressions. The logical operators & (and) and (or) 
 can be used to define arbitrary conditions consisting of logically combined 
 threshold relations. 
 
 The logical switching of equations is illustrated by the following 
 example which is an extension of the capacitor model of the previous section 
 
96 
 
 This model is an idealized air capacitor to which the additional parameters 
 VMAX and RL have been added. VMAX represents the maximum voltage across 
 the capacitor. When the capacitor voltage reaches VMAX, the air between 
 the capacitor plates ionizes. This establishes a conductive path with 
 resistance RL across the capacitor. The capacitor will then draw a greater 
 current due to its lower impedance in the ionized state. This current 
 may eventually drain the capacitor voltage below VMAX at which point the 
 capacitor resumes its normal operation. 
 
 This situation can be modeled by replacing the capacitor equation 
 V(l) 1 - V(2)' = I(l)/C with the conditional equation 
 
 IF ABS(V(1)-V(2)) > VMAX THEN V(l) - V(2) = I(1)*RL 
 
 ELSE V(l)* - V(2)' = I(l)/C 
 Logical switching of equations is also useful in a spring model 
 to describe the nonlinear operation of the spring when a threshold value of 
 AX is exceeded. In this case we might represent the spring's undeformed 
 length as a local variable whose initial value is specified as a parameter, 
 and add the parameters DELMAX to represent the threshold AX, and C to 
 represent the modulus of stretching. The spring could then be modeled 
 by the equations 
 
 F(l) + F(2) = 
 
 K*(X(2)-X(1)-L) = F(2) 
 IF X(2) - X(l) < DELMAX THEN L 1 = 
 ELSE L' = C*(X(2)'-X(1) ') 
 The conditional equation above describes an idealized hysteresis 
 effect. In general, an idealized hysteresis loop with slope S such as the 
 loop shown in Figure 3.10 can be modeled by the conditional equation 
 IF X' > & Y < S*(X-P1) THEN Y' = S*X f 
 ELSE IF X' < & Y > S*(X-P2) THEN Y' = S*X' 
 ELSE Y' = 
 or by the more concise conditional equation 
 
 IF X' > & Y < S*(X-P1)|X' < & Y > S*(X-P2) THEN Y 1 = S*X' 
 ELSE Y' = 
 
 
Figure 3.10. Idealized hysteresis loop with slope S, 
 
 In a reservoir model, one might use a conditional equation to 
 describe the situation when the reservoir is drained. For example, if 
 fluid never enters the reservoir through terminal 1, one might add the 
 conditional equation 
 
 IF HO < HI THEN HO' = 
 ELSE HO' = HO' 
 The ELSE clause is needed only to conform to the syntax of a conditional 
 equation since it obviously has no effect on the system solution. 
 
 A conditional structure of IF, THEN, and ELSE clauses was 
 chosen over the provision of procedural blocks, and conditional branching 
 statements because the former requires no familiarity with concepts of 
 procedural control and branching. It is this author's opinion that IF, 
 THEN, and ELSE clauses are more natural for the inexperienced programmer 
 than are procedural branching statements. Although a conditional 
 equation is a procedural sequence in which ELSE clauses are executed only 
 when the preceding IF clauses are 'false', it is natural to think of a 
 conditional equation as a single parallel statement. Within this framework 
 users with no procedural programming experience can define models which 
 include logical switching of equations in a quasi-parallel fashion. Any 
 necessary procedural code can be interfaced to the model in the form of 
 FORTRAN subroutines. 
 
 Presently each THEN and ELSE clause must contain a single equation, 
 A routine extension of the MODEL language would allow parallel blocks of 
 equations to be structured in these clauses. 
 
98 
 
 3.4.7. Initial Value Assignment 
 
 Initial values for MODEL variables, parameters, and their 
 derivatives are specified via the INITIAL statement. In the text dialect 
 this statement has the general form 
 
 INITIAL { var = eonst-eocp; }* 
 In DRAGON, the INITIAL function is selected and the remainder of the statement 
 is typed in. Each use of var represents a variable, parameter, or derivative 
 of the element. Each use of oonst-exp represents any expression whose 
 operands are constants, parameters of the highest level element of the model, 
 or variables or parameters which are equivalenced to one of these. Initial 
 values may be scalar or higher-dimensioned expressions. They may be passed 
 as parameters to an element allowing different initial values for each 
 invocation. Parameterization of initial values in the highest level element 
 of a model allows initial values to be specified at run time. 
 
 One initial value may be assigned for each variable/derivative 
 pair in the model. After the initial values specified by the user are 
 assigned, the numerical software will compute initial values for uninitial- 
 ized variables and derivatives which yield a steady initial state of the 
 model. Thus, it is not necessary to specify an initial value for every 
 variable/derivative pair. 
 
 Some initial values are typically required to begin the simulation 
 from a desired system state. In using the spring and reservoir models of 
 section 3.4.5, for example, one might want to specify the initial displace- 
 ments of the spring endpoints or the initial height of the reservoir's 
 surface. This is facilitated by passing initial values as element parameters. 
 For example, one might add the parameter HINIT and the statement 
 
 INITIAL HO = HINIT 
 to the definition of the reservoir model. This would allow the initial 
 height to be independently specified for each reservoir used in a fluid 
 network. 
 
 3.4.8. Termination Logic 
 
 The conditions under which the model execution is to be terminated 
 are specified by means of the STOP clause within an EQUATIONS statement. 
 The form of this clause is IF aond STOP {=n) where cond represents any 
 condition as described in section 3.4.6 and n represents an optional 
 
99 
 
 constant termination code specified by the user. An ELSE clause is not 
 allowed after the STOP clause. 
 
 Every model must include at least one termination condition. 
 A termination condition might be a simple threshold on the independent 
 variable , i.e., 
 
 IF TIME > 10 THEN STOP 
 or it might be a logical combination of thresholds in variables and 
 parameters of the element which represents either normal or abnormal 
 termination. For example, the statement IF V(l) > VMAX THEN STOP = 1 
 might be included in an element which models a fuse to terminate the 
 simulation if the fuse blows. If this condition arises during the 
 simulation, execution of the model will stop. The termination code '1' 
 will be printed and also assigned to the system variable ISTOP. The 
 printed termination code communicates the termination condition to the user 
 while the system variable ISTOP allows the FORTRAN program which controls 
 the model execution to alter the control sequence according to the 
 termination condition. If no termination code is specified, ISTOP will 
 have the value . 
 
 A termination code may be a parameter to the element in which 
 the STOP clause is specified provided that this parameter is always 
 replaced by a constant when the element is invoked. This allows a 
 different termination code to be associated with each instance (that is, 
 each copy) of the element invoked in the model. 
 
 Parameterization of termination conditions allows these conditions 
 to be controlled by the invoking element. Parameterization of termination 
 conditions in the highest level element of the model allows these conditions 
 to be controlled at run time through the assignment of values for the 
 parameters of the highest level element. 
 
 Simple thresholds on the independent variable can also be 
 specified in the run-control language through the system parameter TSTOP. 
 For example, the assignment TSTOP = 10 in the run-control language has 
 the same effect as the clause 
 
 IF TIME > 10 STOP 
 
100 
 
 3.4.9. Output 
 
 The variables of an element whose histories are to be recorded for 
 output are specified via the OUTPUT statement. In the text dialect, this 
 statement has the general form 
 
 OUTPUT {var;}* 
 where var represents a variable name. In DRAGON, the output variables are 
 specified by selecting the OUTPUT function and typing in the remainder of 
 the statement. 
 
 The output variables are recorded at regular intervals during the 
 integration of the model. The frequency at which values are recorded — or 
 the communication interval — is specified through the COMINT system control 
 parameter. The interval in the independent variable between recording 
 
 operations is simply the value assigned to the COMINT parameter. The default 
 
 _2 
 value for COMINT is 10 . Non-default values are specified in the run-control 
 
 program, which is discussed in section 3.6. 
 
 Solution histories can be recorded on any logical unit number 
 between 6 and 90. Unit 6, the standard line printer unit, is used for 
 default. A different logical unit can be specified by means of the UNIT 
 statement, which has the general form 
 
 UNIT n 
 where n is any integer between 6 and 90. In the text dialect, this statement 
 precedes the first element definition of the model. In the DRAGON dialect, 
 the UNIT statement is entered in the header block. 
 
 A title for the solution history can be specified via the TITLE 
 statement, which has the general form 
 
 TITLE title-string 
 where title-string is any character string. Like the UNIT statement, the 
 TITLE statement precedes the first element definition of the model in the 
 text dialect and is entered in the header block in the DRAGON dialect. 
 
 The user is free to examine and alter the FORTRAN subroutine which 
 is used to record system states so great flexibility in data recording is 
 available at the FORTRAN level. Present plans call for MODEL itself to be 
 extended to provide flexible operators for recording, filing, and restoring 
 solution states at a higher level. A sophisticated plot package [5] will 
 also be interfaced. 
 
101 
 
 The FORTRAN subroutine RECORD, which performs the solution recording, 
 is shown for a sample model in Appendix B. RECORD has four arguments, INIT, 
 IUNIT, N, and A. The values of the output variables are passed to RECORD in 
 the vector A whose length is N. IUNIT is the logical unit number specified 
 in the model or the default unit, six. INIT is a flag which is zero when 
 the initial state is recorded and one after the integration begins. When 
 the initial state is recorded, the output title and labels (which are the 
 names by which the output variables are known in the model) are recorded as 
 a header for the solution history. The labels indicate the order in which 
 the values of the output variables appear in the array A. Since these labels 
 appear clearly within subroutine RECORD, it is quite easy for the user 
 familiar with FORTRAN to alter this subroutine to perform more sophisticated 
 recording and output operations. 
 
 3.5 . Function Subprograms, Subroutines, and Table Functions 
 
 The user can define FORTRAN function and subroutine subprograms 
 to evaluate special functions needed in equations, conditions, and initial 
 and parameter values. Scalar functions can be defined as function 
 subprograms while nonscalar functions are defined as subroutines. Within 
 MODEL equations both types of subprograms are referenced as functions. 
 When a subroutine is defined, the vector or array result must be the last 
 dummy argument of the definition. In referencing the subroutine in MODEL 
 equations, this argument is omitted as is the CALL statement. MODEL 
 automatically generates the CALL statement inserting a MODEL-generated 
 address for the result. The result is then automatically inserted into 
 the equation in the place of the subroutine name. This permits the 
 convenience of function-type referencing for both scalar and nonscalar 
 functions — subprogram references may be freely nested and embedded in 
 expressions. No other language allows subroutine references to be 
 nested or embedded in expressions. 
 
 Each FORTRAN subprogram used in a model must be defined by a 
 FORTRAN source or object subprogram and its syntax must be defined by a 
 MODEL subprogram syntax statement. The MODEL subprogram syntax statement 
 permits MODEL to analyze the syntax of subprogram references and, in the 
 case of subroutines, to perform the automatic insertion of the nonscalar 
 result into the expression which references the subroutine. The FORTRAN 
 
102 
 
 subprogram performs the function evaluation during the model execution. 
 It may be defined by passing the FORTRAN source code through MODEL, or 
 by submitting it to the FORTRAN step or compiling it separately and including 
 the object code in the link-load step. The latter two alternatives 
 allow FORTRAN subprograms to be altered without recompiling the model. 
 Standard link-editor commands at most installations permit this approach 
 to be used to replace subprograms whose source code was passed through MODEL. 
 The MODEL subprogram syntax statements have the general forms 
 
 FUNCTION funo-name n-args 
 
 SUBROUTINE funo-name n-args {RVECTOR {d-}| 
 
 CV ECTOR {d }| 
 ARRAY {d d }} 
 where funo-name represents the name of the subprogram and n-args represents 
 the number of arguments used in referencing the subprogram in MODEL equations, 
 Thus, for a subroutine which is defined with M dummy arguments (the last of 
 which is its result), n-args should be M-l since the last argument is 
 omitted in subroutine references within MODEL equations. The optional 
 RVECTOR, CVECTOR, or ARRAY clause is used to specify the extent of the 
 nonscalar result. The RVECTOR clause specifies that the result is a row 
 vector, that is, 1 x n. The CVECTOR clause specifies a column vector, 
 n x 1. The ARRAY clause specifies an array, n x m. If the result always 
 has the same extent, the extent can be specified by the optional integers 
 d and d*. If the extent of the result depends on the actual arguments 
 used in referencing the subroutine, no extents are specified in the 
 subprogram syntax statement. In this case, the extent of the result must 
 be defined as the first dummy argument (for vectors) or as the first two 
 dummy arguments (for arrays) of the subroutine. This allows a single 
 subroutine to be used for an operation such as taking the transpose of a 
 matrix, regardless of the extent of the array. Only integer constants 
 may replace these dummy arguments when the subroutine is referenced in 
 MODEL equations. If the SUBROUTINE statement includes no RVECTOR, 
 CVECTOR, or ARRAY clause, the result is assumed to be an array whose 
 extent is specified in this fashion. 
 
 In the text dialect, subprogram syntax statements precede the 
 first ELEMENT statement of the input file. In DRAGON, subprogram syntax 
 statements are entered by selecting the HEADER function and typing in the 
 
103 
 
 statements. This enters the syntax statements in the header block of the 
 element under construction. When the MODEL compiler is invoked from 
 DRAGON, the statements in the header block of the highest level element of 
 the model are included in the input file passed to the compiler. 
 
 In the text dialect, any FORTRAN source codes which are passed 
 through MODEL must be placed in a different part of the input file than 
 the model definition — see Appendix A. In DRAGON, a FORTRAN source code is 
 added to the FORTRAN menu by selecting the FORTRAN function and typing in 
 the source code. When the MODEL compiler is invoked from DRAGON, the entire 
 FORTRAN menu is included in the input file passed to the compiler. 
 
 Any legal FORTRAN subprograms which do not use blank common are 
 allowed. The MODEL compiler allows at most 24 FORTRAN subprograms to be 
 defined for use in MODEL equations. A MODEL subprogram syntax statement 
 must be provided for each of these. A syntax statement is not required 
 for FORTRAN subprograms which are called in the run-control program or in 
 other subprograms but are not referenced in MODEL equations. Any number 
 of these subprograms can be accommodated. 
 
 The user-supplied FORTRAN code and the FORTRAN code produced by 
 MODEL can be listed by including a FLIST statement either before the first 
 element definition of a text dialect model or in the header block of a 
 DRAGON dialect model. This is useful for diagnostic purposes and for the 
 purpose of altering any of these FORTRAN codes without repeating the 
 MODEL step. 
 
 MODEL allows empirical data functions of one variable to be 
 defined in tabular fashion. In the text dialect, this is done through 
 the TABLE statement. TABLE statements must follow the last element 
 definition of the input file — see Appendix A. The TABLE statement has 
 the general form 
 
104 
 
 TABLE tabno 
 
 -2 -2 
 
 x t 
 — n — n 
 
 tabno represents a unique integer by which the specific table function is 
 identified. The x_. represent the points at which the function values, _t . , 
 are known empirically. The x. must appear in increasing order. 
 
 In DRAGON, table functions are defined in the same way as FORTRAN 
 subprograms. Selection of the FORTRAN function allows the user to type the 
 name by which the table function will be known in the library, followed by 
 the TABLE statement. The table function is then added to the FORTRAN menu 
 and automatically passed to the MODEL compiler when it is invoked. 
 
 Any number of table functions may be defined. They may be 
 referenced in the equations of any element in the form TABLE { tabno , org ) 
 where tabno represents the integer which identifies the specific table 
 function and avq represents the point at which the table function is to be 
 interpolated (or extrapolated) . 
 
 3.6. Run-Control 
 
 The execution of a simulation model is controlled by a FORTRAN 
 run-control program which can utilize system control parameters, system 
 subroutines which invoke the model execution, any any user-supplied FORTRAN 
 subroutines. The parameters and variables of the highest level element 
 can be referenced as FORTRAN variables, permitting parameter adjustment and 
 response testing procedures which are as simple or as sophisticated as the 
 user's understanding of FORTRAN permits. When the run-control program is 
 submitted to MODEL with the model definition, MODEL automatically inserts 
 declarations for these FORTRAN variables, relieving the user of this task. 
 These variables reside in COMMON storage sc the user need not pass them 
 as arguments to the model execution. MODEL also automatically inserts 
 EQUIVALENCE statements which map the names by which these parameters and 
 variables are known in the model into members of the FORTRAN arrays where 
 variables are maintained during the model execution. This permits references 
 at the problem description level in the run-control program. 
 
105 
 
 The run-control program need not be submitted to MODEL, however. 
 When desirable, the run-control program can be submitted at the FORTRAN or 
 object step rather than the MODEL step. In these cases, a printed 
 diotioncwy of the parameters and variables of the model can be obtained 
 by including a MAP statement before the first element definition (text 
 dialect) or in the header block (DRAGON dialect) of the model. This 
 dictionary lists, element-by-element, the problem-level names and 
 corresponding FORTRAN array members for each variable and parameter of 
 the model. The dictionary allows the user to insert appropriate 
 EQUIVALENCE statements or to reference model variables directly as members 
 of the FORTRAN arrays. The dictionary for a sample model is shown in 
 Appendix B. 
 
 When the run-control program is not submitted to MODEL, declarations 
 and COMMON statements for the FORTRAN arrays in which variables are 
 maintained must be inserted by the user. These can be copied exactly as 
 they appear in the default run-control program produced by MODEL. The 
 default run-control program can be printed for this purpose by including 
 an FLIST statement before the first element definition of the model. 
 Appendix B shows the default run-control program for a sample model. 
 
 3.6.1. Parameter Assignments 
 
 Parameter values can be assigned or read by any FORTRAN procedure 
 prior to and between invocations of the model. Parameter assignments are 
 by exception only. Once assigned a value a parameter will keep that value 
 until reassigned. This applies to the parameters of the highest level 
 element and to the system control parameters whose names and meanings are 
 shown in Figure 3.11. Default assignments for the system control parameters 
 are automatically included by MODEL in default run-control programs and in 
 non-default run-control programs submitted to MODEL (see Appendix B) . When 
 the run-control program is not submitted to MODEL, the values of all system 
 control parameters must be assigned by user-supplied code. 
 
106 
 
 parameter 
 TSTART 
 
 TSTOP 
 
 HMIN 
 HMAX 
 EPS 
 
 DEL 
 
 ISTOP 
 COMINT 
 
 meaning 
 
 initial value of 
 independent variable 
 (nominally time) 
 
 terminal value of time 
 
 minimum time step 
 
 maximum time step 
 
 maximum relative error 
 for each time step 
 
 maximum relative error in 
 system initialization 
 
 termination code 
 
 frequency of solution 
 recording 
 
 default value 
 
 10 
 
 10 
 
 -2 
 
 10 
 
 -5 
 
 10 
 
 -5 
 
 10 
 
 Figure 3.11. MODEL system control parameters 
 
 3.6.2. Model Invocation and Response Testing 
 
 Two system subroutines, RUN and CONTIN, are provided for 
 invoking the model execution. The difference between these subroutines 
 is that RUN establishes an initial state for all variables before 
 beginning the integration while CONTIN proceeds from an established 
 state. Execution of CALL RUN causes the independent variable to assume 
 its initial value (TSTART) and the initial values specified in INITIAL 
 statements in the model to be assigned, after which the values of the non- 
 initialized variables are adjusted to attain a steady initial state of the 
 model. On the other hand, CALL CONTIN causes no such state initialization 
 prior to the integration. Integration proceeds from the last terminal state 
 of the model or from some state which was previously recorded and restored 
 by user-supplied code. The termination prameter(s) must, of course, be 
 altered before continuing from a previous terminal state. Otherwise, CALL 
 CONTIN will cause immediate termination of the model execution. 
 
 The sequence of calls to RUN and CONTIN in a programmed study 
 is controlled by the FORTRAN code of the run-control program. Any FORTRAN 
 procedures can be used to test system responses (i.e., variable values), 
 alter parameter values, and determine the control sequence between runs. 
 
107 
 
 The integer variable ISTOP, which indicates the condition which caused 
 termination, is particularly useful for the latter purpose. 
 
 The FORTRAN run-control used by MODEL allows great flexibility 
 for sophisticated studies while requiring very little sophistication for 
 simple problems. Non-parameterized models can make use of default run- 
 control (CALL RUN). A non-default run-control program may be as simple 
 as (for example) 
 
 Pl=5 
 
 P2=3.9 
 
 CALL RUN 
 or as complex as procedures for parameter optimization. Use of the 
 dictionary allows the FORTRAN run-control program to be submitted after 
 the MODEL step, and standard link editor and loader options permit any 
 of the FORTRAN programs produced by MAP to be altered without recompiling 
 the model. 
 
 Only the parameters and variables of the highest-level element 
 can be referenced at the problem-description level in the run-control 
 program. Lower-level elements may be invoked many times in a model. Thus, 
 the names of their variables and parameters may not be unique within the 
 model. The use of global variables permits a variable within a lower- 
 level element to be equivalenced to a global variable of the highest 
 level element which can be referenced at the problem-description level. 
 Alternatively, the use of the dictionary allows the user to reference the 
 FORTRAN array member which represents any variable directly. 
 
 3.7. Diagnostics 
 
 MODEL provides extensive diagnostics concerning errors and possible 
 errors in the model definition. MODEL reports all errors in the model 
 definition rather than stopping the model analysis after some fixed number 
 of errors have been found. Highlights of this error checking include a 
 complete source language equation syntax analysis and a complete analysis 
 of terminal connections. MODEL attempts only the most trivial error 
 correction such as the truncation of identifiers whose names are longer 
 than eight characters. More sophisticated error correction is not attempted 
 because the MODEL-to-FORTRAN step is much less expensive than the FORTRAN-to- 
 
108 
 
 object and model execution steps which would be useless if MODEL made a 
 wrong correcting assumption. The numerical software produces diagnostics 
 for such computational difficulties as the inability to find a steady 
 initial state, the inability to achieve the prescribed error tolerance 
 within the allowable range of step sizes, and underflow or overflow 
 resulting from the inversion of an ill-conditioned matrix. 
 
 The diagnostics produced by MODEL are classified as either error 
 messages or warning messages. Error messages describe situations which 
 are certain errors such as an equation with a missing operator or the 
 connection of two terminals of different types. Warning messages describe 
 trivial errors which are corrected by MODEL such as a variable name which is 
 
 longer than eight characters, and situations which may or may not be actual 
 
 2 
 errors such as an unequal number of equations and variables. 
 
 A MODEL program is terminated after the model compilation if 
 any error messages are produced. Since warning messages may or may not 
 signal actual errors, two options are available in response to these 
 messages. By default the execution of the model will be attempted if only 
 warning messages are produced by the compilation. Alternatively, the user 
 can cause the execution to be aborted in response to warning messages by 
 including an ABORT statement either before the first element definition of 
 the model (text dialect) or in the header block (DRAGON dialect). 
 
 Diagnostics may be produced at three distinct points in the 
 analysis performed by MODEL. During the input phase of model analysis, all 
 syntax errors except those in equations and initial values are reported. 
 These messages appear after the source line which is in error and the 
 position within the line at which the error was detected is indicated by 
 the cursor character @. Each specific error in an element definition 
 detected during the input phase is reported only once regardless of the 
 number of times that element is invoked. Thus, these errors do not cause 
 identical messages to be repeated for each instance of an element in the model. 
 
 During the expansion phase of model analysis, each element instance 
 invoked in the model is expanded into a set of equations. The equation and 
 initial value syntax analysis and connection analysis are performed during 
 this phase. Error and warning messages produced during this phase are 
 specific to a particular element instance. Thus, some such messages may 
 be repeated for each instance of a given element. This is necessary because 
 
109 
 
 certain potential errors concerning equations and connections depend on the 
 context of the instance (i.e., the global variables of higher-level elements 
 and the types of externally connected terminals) . Diagnostic messages 
 produced during the expansion phase are accompanied by the element name, 
 qualified by the names of its ancestors in the element invocation tree. 
 These messages are also accompanied by a line of text which clearly identifies 
 the cause of the error such as the equation in error and the position within 
 the equation at which the error was detected. 
 
 During the output phase of the model analysis, the expanded set 
 of equations which represents the model is translated from an internal 
 representation to a set of FORTRAN subroutines. Error and warning messages 
 produced during this phase concern the set of equations of the model as a 
 whole and are not specific to any particular element or instance. These 
 messages are accompanied by a line of text which clarifies the cause of 
 the error or possible error such as the number of variables and the number 
 of equations if these are different. 
 
 The format of MODEL error and warning messages is shown in 
 Figure 3.12. Figure 3.12a shows a generalized diagnostic message. The 
 first line indicates the source line cursor position and is used only in 
 messages produced during the input phase. The second line gives the element 
 name and message number. Messages produced during the input and output 
 phases will indicate INPUT and OUTPUT, respectively, as the element name. 
 Messages produced during the expansion phase will indicate the name of the 
 element in error, qualified by the names of its ancestors in the element 
 invocation tree to identify the particular element instance. The message 
 number is included to aid the user in looking up the message in Appendix A 
 of the user's manual [3]. The third line of the message describes the 
 particular error which was detected. Appendix D lists these error 
 descriptions along with the associated error numbers. The fourth line of 
 the message identifies the cause of the error, for example, by listing the 
 equation in error and the position at which the error was detected. The 
 fourth line is not necessary for messages produced during the input phase. 
 Thus, all messages consist of three lines. 
 
 Figures 3.12b, c and d are sample messages which might be 
 produced by MODEL. Figure 3.12b is the warning message caused by a terminal 
 type name which is longer than eight characters. Figure 3.12c is the error 
 
110 
 
 message caused by an equation which has a missing operator. Figure 3.12d is 
 the warning message caused by a difference in the number of equations and 
 the number of variables in the model. 
 
 {@ indicating source line cursor position } 
 IN ELEMENT name ERROR run 
 description of error 
 { identification of cause of error ) 
 
 Figure 3.12a 
 
 (source line) TYPE STRUCTURAL @ E(DX;DY;DZ) I(FX;FY;FZ) 
 IN ELEMENT INPUT WARNING 13 
 TERMINAL TYPE NAME SHORTENED TO 8 CHARACTERS 
 
 Figure 3.12b 
 
 IN ELEMENT RESIST0R(2) .AMP. RADIO ERROR 43 
 EQUATION IGNORED. OPERATOR MISSING BEFORE @ 
 V(2) - V(l) = 1(1) @ R 
 
 Figure 3.12c 
 
 IN ELEMENT OUTPUT WARNING 7 
 
 SYSTEM MAY BE SINGULAR. NUMBER OF EQUATIONS _, = NUMBER OF VARIABLES 
 
 NUMBER OF EQUATIONS: 7, NUMBER OF VARIABLES: 6 
 
 Figure 3.12d 
 Figure 3.12. Format of MODEL error and warning messages. 
 
Ill 
 
 NOTES 
 
 Keywords and delimiters appear in normal type and must appear in the 
 same fashion in specific statements. Italics indicate tokens to be 
 supplied by the user. Braces are used to enclose optional phrases. 
 The asterisk is used to indicate phrases which may be repeated any 
 number of times. The semicolon is used as the delimiter for sequences 
 of phrases. It is not necessary to include a semicolon after the 
 final phrase of any sequence. 
 
 Analysis of electrical and structural networks frequently leads to one 
 or more redundant node equations and one or more 'floating' variables. 
 For example, the simple electrical circuit below involves four voltages 
 and four currents — one voltage/current pair at each designated terminal. 
 There are eight equations present of which the first four below come 
 from the definitions of the battery and resistor elements and the 
 remaining four come from the two terminal connections. 
 
 1. V(1)=V(0)+1.5 
 
 2. I(0)+I(1)=0 
 
 3. V(3)=V(2)-I(2)*R 
 
 4. I(2)+I(3)=0 
 
 5. V(1)=V(2) 
 
 6. I(l)+I(2)=0 
 
 7. V(0)=V(3) 
 
 8. I(0)+I(3)=0 
 
 However, this system of eight equations in eight variables can be 
 simplified by eliminating the voltages V(l) and V(2) with equations 
 5 and 7 and eliminating the currents 1(1), 1(2), and 1(3) with equations 
 2, 6 and 4. This simplification yields the system 
 
 9. V(1)=V(0)+1.5 
 
 10. V(0)=V(1)-I(0)*R 
 
 in which one of the voltages is free to 'float', and the redundant 
 node equation 
 
 8. I(0)+I(3)=0 
 
 which is implied by equations 2, 6, and 4. MAP will automatically 
 perform simplifications like those above and will also recognize 
 and remove redundant equations such as equation 8. Thus, MAP would 
 reduce this trivial network to a system of two equations (9 and 10) 
 in three variables (V(l), V(0), and 1(0)). However, this does not 
 mean that the network model is in error. The numerical software will 
 simply fix one of the voltages at zero, effectively reducing the 
 network to a system of two equations in two variables. 
 
112 
 
 It is worth noting that if V(0) is fixed in the model (say at zero), 
 MAP will reduce this network to two assignment statements to the effect 
 
 V(l)=1.5 
 
 I(0) = (V(1)-V(0))/R 
 
 which need only be executed once. 
 
113 
 
 LIST OF REFERENCES - CHAPTER 3 
 
 [1] DRAGON User's Manual 
 P. Watterberg 
 M.S. thesis to appear. Currently at Sandia Labs, Albuquerque, New Mexico, 
 
 [2] "A User's View of Solving Stiff Ordinary Differential Equations" 
 L. F. Shampine and C. W. Gear 
 
 Department of Computer Science Report UIUCDCS-R-76-829 , University 
 of Illinois at Urbana-Champaign, 1976 
 
 [3] "Simulation Modeling with GRASS and MAP" 
 T. F. Runge 
 
 Department of Computer Science Report UIUCDCS-R-75-712 , University 
 of Illinois at Urbana-Champaign, 1975 
 
 [4] NON-LINEAR STRUCTURES 
 K. I. Majid 
 John Wiley and Sons, Inc., New York, New York, pp. 46-48, 1972 
 
 [5] "Automatic Curve Fitting for Interactive Display" 
 W. L. Chung 
 
 Department of Computer Science Report UIUCDCS-R-75-713 , University 
 of Illinois at Urbana-Champaign, 1975 
 
114 
 
 CONCLUSIONS 
 
 Many of the goals presented in the previous chapters have been 
 accomplished in the present implementation of MODEL, but some desirable 
 features remain to be achieved. In section 4.1 we summarize the present 
 implementation in terms of our language development goals and the extent 
 to which they have been realized. Section 4.2 focuses on desirable 
 features which have yet to be implemented and presents some possible 
 approaches. This section also considers the manner in which certain 
 language extensions are facilitated or restricted by the present implement at ior 
 
 4.1. Present Implementation of MODEL 
 
 The primary short range goal in the development of MODEL was to 
 produce a widely applicable and easy-to-use language for continuous 
 network simulation. Secondary short range goals were to support hierarchical 
 models and different levels of problem and user sophistication conveniently, 
 to allow a large measure of portability, and to permit flexibility in the 
 modeling and integration environments. These goals have been realized to a 
 large extent in the present implementation of MODEL. 
 
 MODEL'S ability to handle generalized connective properties and 
 to solve any user-written equations make it the most widely applicable 
 network simulation language presently available. MODEL makes the simulation 
 of network models from a great many disciplines possible within a single 
 framework, and the ability to define and employ different terminal types 
 allows interdisciplinary models to be handled directly. Topological modeling 
 features, a free text format, and the implicit formulation of equations make 
 MODEL very easy to use. The local implementation also provides the great 
 convenience of graphical modeling and library support. The portable dialect 
 can be interfaced easily to library support software and in such a configura- 
 tion would be as convenient as any existing nongraphical network languages. 
 Furthermore, the implicit formulation of equations makes MODEL more 
 convenient than existing equation-oriented languages for most non-network 
 applications. 
 
 The structure of the MODEL language was designed to allow the 
 obvious advantages of hierarchical development and modular design within 
 
115 
 
 simulation models. Elements (i.e., modules) may be nested to any depth 
 and may employ flexible variable scoping features. The language makes 
 no distinction between elements which are used at the highest level 
 (e.g., a radio model) and those which are used at lower levels (e.g., 
 an amplifier). Thus, any element can be added easily to the element 
 library for later use as a subelement and lower level elements of a 
 hierarchical model can be adapted easily for independent compilation and 
 simulation. The invocation of a subelement requires only the specification 
 of the parameters and external connections to be used for the subelement 
 instance. Thus, changes in the definition of a lower level element which 
 do not alter the number or type of its parameters and external connections 
 require no corresponding changes in the definitions of higher level 
 elements. These features allow subsystem models to be refined and verified 
 independently in the development of a hierarchical model. 
 
 MODEL is designed to provide convenient support for both the 
 sophisticated user with a complex problem and the novice user with a simple 
 problem. The experienced simulation user-programmer will find it relatively 
 easy to define behaviors at the equation level and construct new elements 
 representing complicated subsystems. FORTRAN procedures of arbitrary 
 complexity can be interfaced to the model to evaluate special functions 
 needed in equations and to control the repetitive integration of the 
 parameterized model; for example, in a parameter optimization study. On 
 the other hand, very little sophistication is required for models involving 
 only straightforward equations and/or the use of predefined library elements, 
 Users unfamiliar with FORTRAN can employ either default or very simple 
 run-control procedures; for example, 
 
 PI = expression 
 
 P2 = expression 
 
 CALL RUN 
 
 END 
 The nongraphical dialect of MODEL was developed to allow its use 
 at other installations where graphical modeling support similar to that 
 provided locally cannot be assumed. Portability is not achieved, however, 
 by simply providing a portable mode of input. Concern must also be given 
 to the portability of 
 
116 
 
 1. the code which translates the user's model (i.e., the 
 MODEL compiler) , 
 
 2. the code into which the model is translated (i.e., the 
 target language of the MODEL compiler) , 
 
 3. the code which exercises the translated model (i.e., the 
 numerical software). 
 
 To enhance portability, American National Standard FORTRAN was 
 chosen as the language in which all of the these codes ultimately will be 
 written. The MODEL compiler produces only ANS FORTRAN and work is underway 
 to remove all nonstandard FORTRAN from the numerical software. The greatest 
 difficulty in achieving the portability of ANS FORTRAN has been experienced 
 in coding the MODEL compiler. FORTRAN is not a convenient language for 
 programs which consist largely of data structure and symbol manipulation. 
 For this reason, the compiler was not coded directly in FORTRAN, but rather 
 in a locally developed language, PLW [1]. PLW is a PL/l-like language which 
 is compiled into more portable FORTRAN. Presently PLW produces some non- 
 standard FORTRAN. However, a future implementation of PLW will employ only 
 ANS FORTRAN, permitting the software package to be distributed more widely. 
 
 Even the use of only ANS FORTRAN does not achieve great portability 
 where I/O and character manipulation operations are concerned. When MODEL is 
 implemented at a new installation, it will usually be necessary to rewrite 
 the I/O support and character manipulation routines used by the PLW-produced code. 
 
 The portability of the MODEL compiler produced by the present 
 implementation of PLW is restricted to machines having a word length of 32 or 
 more bits. Efforts are being made to ease the word length restriction, though 
 the numerical software will usually require a precision of 48-60 bits to meet 
 desired accuracy criteria. The subroutines produced by the MODEL compiler 
 employ double precision arithmetic as does the numerical software. A single 
 precision option for machines with sufficient word lengths will be made 
 available in the future. 
 
 The MODEL compiler is organized into overlays to ease its core 
 storage requirements, but a large amount of program and data space (roughly 
 equivalent to 48K 32-bit words) is still necessary. 
 
117 
 
 The portable and structurally simple text file accepted by the 
 MODEL compiler allows flexibility in the modeling environment. This text 
 file can be constructed by the user as a nongraphical model and can also be 
 interfaced relatively easily to graphics and/or library support software, as 
 is done locally. Flexibility in the model execution environment is provided 
 by allowing the translated model and the numerical software to be used in 
 any fashion reasonable for a large, FORTRAN-based software package. The 
 translation of the user's model can be invoked as a separate job or as the 
 initial step of a ' compile-and-execute' job. The integration of the translated 
 model can be invoked as a subroutine from any user-written FORTRAN procedures, 
 which may be executed in batch mode or on-line. Efforts have been made to 
 facilitate the alteration of the translated model, the run-control program, 
 or any other FORTRAN interfaces to the simulation study at the FORTRAN step, 
 without recompiling the model. Listings of the variable dictionary and the 
 default run-control program, which are produced by the MODEL compiler at the 
 user's option, are invaluable when the translated model or the run-control 
 program are to be altered after the MODEL step. 
 
 Our long-range goal is to further the study of languages for 
 simulation of physical systems. The efforts reported here constitute a 
 certain advancement, but the language has not yet been widely used. It 
 will certainly profit from feedback from users with a variety of types of 
 problems. To reach a wide variety of users it is necessary to distribute the 
 MODEL compiler and numerical support to a number of installations. This will 
 be attempted in the near future. The compiler has been implemented and tested 
 and the testing of the numerical software is nearly complete. Some further 
 programming is required to finish the graphics and library support package 
 so that feedback can also be obtained from users of the local graphical dialect 
 
 4.2. Possible Extensions of MODEL 
 4.2.1. Portable Library Support 
 
 Library support is invaluable for saving element, terminal type, 
 and FORTRAN function definitions between modeling sessions and for allowing 
 library definitions to be shared by several users. The portable dialect of 
 MODEL presently provides no library support because this software must be 
 rather inefficient to be highly portable. However, portable library support 
 would prove useful for users who cannot or do not wish to code library 
 support software for their particular installation. 
 
118 
 
 A portable library support routine (hereafter called an LSR) could 
 be written in PLW and compiled into FORTRAN to act as a front end to the 
 MODEL compiler. The libraries (one each for elements, terminal types, and 
 FORTRAN codes) would consist of text files which could be accessed sequentially 
 and rewound (i.e., tape or disk files). The LSR would read the input file 
 (nongraphical model), recognizing statements such as 
 
 LIBRARY ELEMENT name 
 
 LIBRARY TYPE name 
 
 LIBRARY FORTRAN name 
 which might appear at the beginning of the model or within the element 
 definitions. References to library definitions would be stored internally 
 in tables which could be expanded during the gathering of library element 
 definitions. After constructing the initial tables of requested library 
 definitions, the LSR would read from the element library, checking the name 
 of each library element against the names of the requested elements. Upon 
 finding a desired definition the LSR would copy it into the model and remove 
 the reference from the library element reference table. During this copying 
 operation, the LSR would note any references to other library definitions 
 which occur within the library element and add them to the appropriate table 
 if they are not defined in the model or already present in the table. Any 
 subelements invoked by the library element would also be handled as library 
 element references. Due to this dynamic nature of the library reference 
 tables, a number of passes through the element library may be required. 
 After each pass the element library would be rewound and read again, until 
 all necessary library elements have been found and copied. Any library 
 element references which remained in the table for an entire pass through 
 the element library would be reported as unresolved. After the processing 
 of the library element references, the terminal type and FORTRAN code 
 reference tables would be completed and these libraries would each be read 
 once to copy the necessary definitions into the model. 
 
 The LSR might also recognize statements such as 
 
 SAVE ELEMENT name 
 
 SAVE TYPE name 
 
 SAVE FORTRAN name 
 within the model and copy any definitions referenced by these statements 
 into the appropriate libraries. 
 
119 
 
 4.2.2. Other Terminal Variable Types 
 
 A natural question concerning terminal variables is whether there 
 should be other types available in addition to E- and 1-types. As previously 
 reported in [2], we have not been able to find any other types which appear 
 to be fundamental. To quote from [2]: "If a variable is not of E-type 
 (usually representing some intrinsic quantity such as voltage, pressure, 
 position) It can often be transformed into an I-type variable. Since the 
 zero sum rule at nodes is a form of a conservation equation, choice of 
 variables that are conserved (e.g., momentum, energy, mass, current) will 
 usually give an I-type variable. For example, we might be tempted to use 
 PRESSURE, FLOW, and TEMPERATURE to characterize a water pipe connection. 
 However, at a junction of more than two pipes, TEMPERATURE is not of either 
 variable type. If instead we use HEATFLOW (= TEMPERATURE*FLOW) , this is an 
 I-type variable because heat satisfies a conservation law in the absence of 
 other energy sources." 
 
 "The possibility of allowing user-specified equations to 
 characterize the terminal variables associated with nodes was also considered. 
 Since there does not seem to be a need for this generality, and since it is 
 possible to use a connective element which can contain arbitrary equations, 
 this idea was abandoned." 
 
 4.2.3. Higher Order Derivatives and Derivatives of Expressions 
 
 In many cases it would be convenient for the user to refer to 
 higher order derivatives (e.g., y.") and to derivatives of expressions 
 (e.g., g'(y, y ' , _t ) ) directly without having to introduce auxiliary variables 
 (e.g., z = y.' or z = g(y_, y ' , t ) ) . This feature could be implemented in 
 MODEL through a relatively modest programming effort. Auxiliary variables 
 would still be required since the numerical software cannot solve the 
 equations for higher order derivatives or for the derivatives of expressions. 
 However, the introduction of these auxiliary variables could be handled 
 automatically. The MODEL compiler already Includes facilities for internal 
 generation of auxiliary variables and equations, which are sometimes 
 introduced for the sake of efficiency or numerical stability. This makes 
 it quite feasible for the compiler to perform transformations on user-written 
 equations such as 
 
 f fy_> Z'» S'(v_, y_\ t), t) - -► fOy_, y_ f , z\ t) = and z = g(y_, y_' , t) 
 where g represents an expression or derivative and z is an automatically 
 generated auxiliary variable. 
 
120 
 
 4.2.4. Additional Array Operators 
 
 MODEL provides a number of features in support of array operations 
 such as the use of infix operators for addition, subtraction, multiplication, 
 and inner product of arrays and vectors, an array differentiation operator, 
 and FORTRAN functions which can operate on arrays and vectors and return 
 nonscalar results. The latter allows virtually any other desired array 
 operation to be accomplished at the FORTRAN level. However, some further 
 support by MODEL would be convenient for the user, particularly the provision 
 of subscripting in equations. Implementation of subscripting would require 
 double parentheses for references to subscripted terminal variables. For 
 example, FL0W(1) would refer to the scalar flow at terminal 1 while 
 P(l)(3) would refer to the third element of the vector P at terminal 1. 
 
 If subscripting is supported in the equations, users will want to 
 take advantage of facilities for repeating an equation several times with 
 varied subscripts. Looping operations could be provided but macro-level 
 operators for the generation of equations with subscript modifications would 
 be more in keeping with MODEL'S parallel nature. These macro operators could 
 be provided as part of a general macro interpretive language for equations, 
 but a general macro interpreter would probably require too much program 
 space in the MODEL compiler to be cost-effective. The provision of two 
 macro-level operators which we will call REPEAT and INSERT would suffice to 
 support array operations conveniently. 
 
 The REPEAT operator would cause an equation to be generated 
 repeatedly while specified subscripts were varied over a specified range. 
 For example, 
 
 REPEAT(4 8 1) A(3, $) = 
 would cause the generation of four equations in which the subscript 
 indicated by $ would be stepped through the range 4 to 8 by increments of 
 1. It would be useful to nest the REPEAT operator in some cases, for example, 
 
 REPEAT(1 8 1 ; $ 8 1) A($, $$) = 
 (where $ refers to the outer index and $$ to the inner index of repetition) 
 would cause all but the lower triangular members of the 8x8 array A to be 
 set to zero. 
 
 The INSERT operator would cause terms within a single equation to 
 be repeated while their subscripts were varied over a specified range. 
 For example, 
 
 INSERT(1 7 2+) B($) = 
 
121 
 
 would cause B($) to be repeated while $ was stepped from 1 to 7 by increments 
 
 of 2. The occurrences of B($) would be separated by the specified operator 
 
 +. In other words, the expanded equation would be B(l) + B(3) + B(5) + B(7) = 0. 
 
 The possibility of allowing the dimensions of array variables 
 declared within an element to be passed as parameters to that element was 
 considered. Such dummy parameters would have to be replaced by constants 
 rather than variables, but would allow different dimensions to be used in 
 various instances. However, we have not yet encountered an application 
 which warrants the implementation of this feature. 
 
 4.2.5. Additional Strip Terminal Operators 
 
 Present features for generating equations involving the terminal 
 variables connected to a strip terminal are only experimental and clearly 
 inadequate. The NSTRIP operator is useful for inserting the number of 
 connections to a strip terminal into a function reference, but the available 
 method of inserting the connected terminal variables into a function 
 reference is inconvenient because standard FORTRAN does not support varadic 
 functions. At the very least, an operator which copies these terminal 
 variables into a vector is needed. This would allow a single FORTRAN 
 function to be used — for example, to compute the sum of the connected 
 variables — regardless of the number of connections to the strip terminal. 
 
 A slightly different form of the REPEAT and INSERT operators 
 described in the previous section would also be useful for the generation 
 of equations involving strip terminal variables. For example, a user might 
 define the summing element of Figure 4.1 using a strip terminal to 
 accommodate any number of input connections without shorting them together. 
 
 
 ^vW- 
 
 ^° 
 
 Figure 4.1. Strip terminal summing element 
 The equations which define the behavior of this element when terminal 1 is 
 connected to terminals n. , n ~ , . . . , n, are 
 
122 
 
 1. VCtij) - I(n 1 )*R = V(0) 
 
 2. V(n 2 ) - I(n 2 )*R = V(0) 
 
 k. VCn^) - I(n k )*R = V(0) 
 k+1. 1(0) + I(n ) + I(nJ+...+ I(n k ) = 
 Equations 1 through k could be generated by the statement 
 
 REPEAT(STRIP 1) V($) - I($)*R = V(0) 
 which would indicate that the equation is to be generated repeatedly while 
 the terminal ID numbers indicated by $ are replaced first by n-. , then 
 n „ , . . . , n, . Similarly, equation k+1 would be generated by the statement 
 
 INSERT(STRIP 1 +) 1(0) + I($) = 
 
 4.2.6. Logically Structured Blocks of Equations 
 
 Presently, each conditional THEN and ELSE clause can contain only 
 a single equation. Thus, it is necessary to repeat the same condition 
 several times to define a model in which several equations change at some 
 common threshold state. In such cases it would be convenient to structure 
 blocks of equations in conditional clauses. IF, THEN, and ELSE clauses are 
 recognized in a module of the PLW compiler which calls the equation/condition 
 parser as a subprocedure, so it would be relatively easy to alter this code 
 to accept any number of equations in THEN clauses, followed by a like 
 number in the ELSE clause. 
 
 4.2.7. Initial Values and Ranges 
 
 Presently MODEL allows only one initial value to be specified for 
 each variable/derivative pair in a model, due to the manner in which the 
 steady state numerical support is programmed. However, in some models it is 
 most convenient to specify the desired initial state by giving initial 
 values for both a variable and its derivative. It would also be useful 
 in some cases to specify a range of values in which a variable or 
 derivative is to fall initially; particularly, when the equations of the 
 model are undefined outside a certain range and when more than one mathematical 
 solution to the steady state exists. This type of initial value specification 
 would also speed the calculation of the steady state by providing a first 
 approximation (i.e., the midpoint of the specified range) to the initial 
 
123 
 
 value of the given variable or derivative. Both of these features will be 
 implemented in MODEL as soon as they are supported by the steady state 
 software. Minimal effort will be necessary for MODEL but a major rewrite 
 of the steady state routines will be required. 
 
 4.2.8. Boundary Values 
 
 The possibility of extending the numerical support to include 
 parallel shooting methods for the solution of boundary value problems in 
 ordinary differential equations is presently being investigated. If this 
 extension is made, the specification of boundary values will be implemented 
 in MODEL. A boundary value statement would have much in common with an 
 initial value statement. Thus, the implementation of this feature in 
 MODEL should not be difficult. 
 
 4.2.9. Additional Output Operators 
 
 A great deal of output flexibility is presently available at the 
 FORTRAN level, but it would be convenient if high-level operators for 
 recording, restoring, and filing solution histories and states were available 
 without extensive user-supplied FORTRAN codes. These operators could be 
 provided as a set of system subroutines which could be called from the run- 
 control program. For example, FORTRAN subroutines called SAVE, RESTORE, 
 and FILE could be added to the numerical support and called with a logical 
 unit number as their argument. SAVE would write the current system state to 
 the specified unit and RESTORE would read the state on the specified unit 
 into the system. A call to FILE would cause the output from a subsequent 
 integration to be recorded on the specified unit. A plot package interface 
 would also be very useful and is scheduled for implementation. Desirable 
 options include line-printer plots, cross-plots, and over-plots. 
 
 4.2.10. On-line Simulation 
 
 When the DRAGON graphics and library support package is completed, 
 modeling at the local installation will be carried out interactively under a 
 PDP-11 running DRAGON. However, model translations and simulations are 
 presently limited to batch mode due to the nature of the link between the 
 PDP-11 and the IBM 360 on which these programs are currently run. Completed 
 models can be sent from the PDP-11 to the IBM 360 for translation and 
 simulation, and output from the simulation can be routed back to the PDP-11 
 
124 
 
 and subsequently to the remote terminal, but the response time in batch mode 
 may be quite lengthy. Work is presently underway to replace the IBM 360 in 
 this configuration with an INTERDATA 732. When a rewrite of the PDP-11-to- 
 INTERDATA 7 32 link driver is completed, the INTERDATA can be used in 
 dedicated fashion to support the simulation package. The model translation, 
 FORTRAN compilation, and simulation steps submitted from the PDP-11 will be 
 handled very rapidly, and output from the simulation will be sent across 
 the link to the PDP-11 during the integration. The PDP-11 will have immediate 
 access to this output, which will be formatted and displayed on the remote 
 terminal on-line. 
 
 A cursory investigation of the requirements for interactive 
 simulation at the local installation has been conducted. The ability to 
 display solutions on-line will be available soon, as described above. The 
 other principal requirement would be a run-time interpreter capable of 
 altering parameter values and invoking system subroutines (e.g., RUN, CONTIN, 
 SAVE, RESTORE, FILE) in response to commands issued by the user at a remote 
 terminal. The ability to display current values of model variables and to 
 change the output variables at the remote terminal would also be useful. 
 Implementation of these features will depend on detailed studies of their 
 feasibility and cost-effectiveness, which have not yet been made. 
 
1 
 
 125 
 NOTES 
 
 FORTRAN function subprograms can return only scalar results but MODEL 
 allows FORTRAN subroutines to be referenced as functions to compute non- 
 scalar results. See section 3.5. 
 
126 
 
 LIST OF REFERENCES - CHAPTER 4 
 
 [1] "The PLW Compiler" 
 
 W. van Melle and L. Lopez 
 
 Department of Computer Science Report UIUCDCS-R-74-664, University 
 
 of Illinois at Urbana-Champaign, 1974 
 
 [2] "A Generalized Interactive Network Analysis and Simulation System" 
 C. W. Gear 
 First USA- JAPAN Computer Conference, pp. 559-566, 1972 
 
127 
 
 APPENDIX A 
 MODEL TEXT DIALECT STATEMENTS AND THE ORDER OF THE INPUT FILE 
 
128 
 
 The text-oriented input file of the MODEL compiler consists of 
 four sections which must appear in the order below. This is the order in 
 which MODEL text dialect programs must be formulated. 
 
 Section 1: Specification of the highest level element name, independent 
 variable name, logical unit number and title of the output file, FORTRAN 
 subprogram syntax definitions, terminal types, and MODEL compiler 
 options. The statements in this section can appear in any order. This 
 section may be omitted if default compiler options and assumptions 
 concerning the model name, independent variable name, and output unit 
 number are desired and no output title, user-defined FORTRAN subprograms, 
 or terminal types are required. 
 
 general form of statement 
 
 
 page where described 
 
 ANALYZE modelname 
 
 
 72 
 
 RENAME ind-var-name 
 
 
 73 
 
 UNIT unit-no 
 
 
 100 
 
 TITLE titles tring 
 
 
 100 
 
 FUNCTION func-name n-args 
 
 
 102 
 
 SUBROUTINE func-name n-args 
 
 {RVECTOR {d}\ 
 CVECTOR {d}\ 
 
 Li 
 
 ARRAY {d d 2 }} 
 
 102 
 
 TYPE type-name E({ename{ (d„ . 
 
 , d 2 )};}*) 
 
 77 
 
 I({iname{ (d , 
 
 , d 2 )};}*) 
 
 
 FLIST 
 
 
 105 
 
 MAP 
 
 
 105 
 
 ABORT 
 
 
 108 
 
129 
 
 Section 2: Element definitions. The elements can be defined in any 
 order. The statements within an element definition may appear in any 
 order with the exception that NON-DEFAULTS and SUB-CONNECT statements 
 must follow the corresponding SUB-ELEMENT statement. At least one 
 element must be defined. 
 
 general form of statement 
 
 ELEMENT elt-name { parm {(d 3 d )}{ =def-exp };}* 
 
 DEFAULTS { parm {(d , d ) }{ =def-exp } ; }* 
 
 GLOBAL S { global {(d 3 d 2 )};}* 
 
 LOCALS { looal {(d £3 d)};}* 
 
 TERMINALS { term-no - term-no { type }}* 
 
 J. Cl 
 
 EXTERNALS { term-no -term-no }* 
 
 J. Cs 
 
 CONNECT { term-no - term-no }* 
 SUB-ELEMENT sub-elt-name { parm=exp ;}* 
 NON-DEFAULTS { parm=exp ; }* 
 SUB-CONNECT { term-no }* 
 EQUATIONS {exp =exp r \}* 
 
 or IF oond THEN exp = exp 
 
 {ELSE IF aond THEN exp = exp }* 
 ELSE exp = exp 
 
 or IF oond THEN STOP {=n) 
 INITIAL { v ar=oonst-exp ; }* 
 OUTPUT {var^}* 
 
 page where described 
 71 
 72 
 73 
 73 
 75 
 75 
 79 
 79 
 79 
 80 
 89 
 95 
 
 98 
 
 98 
 
 100 
 
 Section 3: Table function definitions. Table functions may be defined 
 
 in any order. This section may be omitted if no table functions are required 
 
 general form of statement 
 TABLE tab-no 
 
 2i 2 t 2 
 
 page where described 
 104 
 
 x t 
 
 — n —n 
 
130 
 
 Section 4: Run-control program and FORTRAN interfaces. If nondefault 
 run-control is specified, the MAIN statement must be the first statement 
 of this section, and the run-control program must follow. The $DEFAULT 
 statement must be included immediately before the first executable statement 
 of the user's run-control program to allow MODEL to insert COMMON statements 
 variable declarations, and default control parameter assignments into run- 
 control program. When the run-control program is to be compiled separately, 
 these COMMON statements, declarations, and assignments must be copied by the 
 user. FORTRAN subprogram source codes follow the run-control program. 
 Section 4 may be omitted if default run-control is used and no FORTRAN 
 interfaces to the model are required, or if the run-control program and 
 other FORTRAN interfaces are to be compiled separately. 
 
 general form of statement page where described 
 
 MAIN 130 
 
 non- executable FORTRAN statements of run-control program 
 
 $DEFAULT 130 
 
 executable FORTRAN statements of run-control program 
 other FORTRAN source codes 
 
 Appendix C shows the IBM 360 job control statements which invoke 
 the compilation and execution of a MODEL program and indicates the positions 
 within the job control program at which the various sections of the input 
 file are to be inserted. Sections 1, 2, and 3 of the input file follow the 
 job control statements for the first (input) step of the MODEL compiler, 
 MAP. Section 4 of the input file follows the job control statements for the 
 second (expansion) and third (output) steps of MAP. The job control 
 statements for the fourth step of MAP and for the FORTRAN and model 
 execution steps follow section 4 of the input file. Any data cards to be 
 read by the run-control program or other user-supplied FORTRAN programs 
 must be inserted at the appropriate point in the execution step job 
 control program. 
 
131 
 
 APPENDIX B 
 SAMPLE MODEL AND OUTPUT 
 
132 
 
 This appendix shows the MODEL text-dialect formulation of a storm 
 sewer network which is constructed from interconnected elements similar to 
 those described in section 1.3. Figure B.l is a graphical representation 
 of the network. Rainfall enters from the source elements and is collected 
 below the street in two small reservoirs. The water in these reservoirs 
 drains into a large reservoir from which it drains out of the network 
 (e.g., into a stream). The purpose of the simulation is to determine 
 whether the reservoirs overflow during a storm. This can be determined 
 from the values of the variables which represent the heights of the water 
 in the reservoirs. 
 
 The elements used in this network differ somewhat from those 
 described in section 1.3. The fluid sink equation 
 
 B(0) = FLOW(0)**2/(2*G*A**2) + H 
 has been rewritten as 
 
 FLOW(O) = ABS(SQRT(2*G*A**2*(B(0) - H))) 
 to insure that the flow is greater than zero and thus is directed into 
 the sink element. In addition, two new elements are employed. The cap 
 element is used to plug an unconnected outlet by setting the flow through 
 it to zero. The drain element is similar to the sink element but includes 
 another terminal and equation to allow the drainage flow to be directed 
 into another element (e.g., the large reservoir). 
 
 The MODEL text-dialect formulation of this network and the network 
 dictionary, run-control program, and output subroutine RECORD 
 produced by the MODEL compiler are shown below. The dictionary includes a 
 node map which identifies the nodes of each element by listing the ID numbers 
 of the terminals connected to each node. For each external terminal of the 
 node a different ID number is listed on the following line. This is the ID 
 number by which the external terminal is known in the next higher-level 
 element. These numbers permit the user to trace external connections through 
 
133 
 
 the node map for the higher-level element. Since variables on one terminal 
 will be either equivalent to or the negatives of the corresponding 
 variables of a connected terminal, FORTRAN variables are not assigned 
 for every terminal variable of the network. For example, only one FORTRAN 
 variable is assigned for each E-type terminal variable on any connected 
 set of terminals. Thus, the node map is very useful for tracing terminal 
 variables of the network to the corresponding FORTRAN variables of the 
 integration. 
 
134 
 
 . 18 2 13, 
 
 Figure Bl. Storm sewer network. 
 
135 
 
 % STORM SEWER NETWORK TEXT DIALECT SOURCE FILE 
 
 ANALYZE SEWER 
 
 TYPE FLUID T(B) I (FLOW) 
 
 MAP 
 
 FLIST 
 
 TITLE STORM SEWER LEVELS 
 
 ELEMENT SEWER 
 
 GAMMA=62.43 ; G-32. 
 TERMINALS 1-9 FLUID 
 RLOPALS GAMMA ; G 
 
 SUB-ELEMENT SOURCE OAREA=1000. 
 SUB-CONNECT 1 
 
 SUB-ELEMENT SOURCE OAPEA=1000. 
 SUB-CONNECT <" 
 
 SUB-ELEMENT RESEPV AS=100. ; HINIT-5. 
 
 "<1 = .75 ; Kl-5. ; A2-.75 ; H2=5. 
 SUB-CONNECT 1 2 3 
 
 SUB-ELEMENT RESERV AS=100. ; HINIT-5. 
 
 A1-.75 ; Kl-5. ; n 2=.75 ; H2-5. 
 
 SUR-CONNECT 4 5 6 
 
 SUB-ELEMENT CAP 
 SUB-CONNECT 2 
 
 SUB-ELEMENT DRAIN A-.75 ; H.-5. 
 SUB-CONNECT 3 7 
 
 SUB-ELEMENT DRAIN A=.75 ; M-5. 
 SUR-CONNECT 5 7 
 
 SUB-ELEMENT CAP 
 
 SUB-CONNECT 6 
 
 SUB-ELEMENT RESERV A c =1000. ; HINIT-O. 
 
 "1=1. ; Kl-O. ; ^2-1. ; H2-0. 
 SUB-CONNECT 7 8 9 
 
 SUB-ELEMENT CAP 
 SUB-CONNECT 8 
 
 SUB-ELEMENT SINK A-l . ; H=0. 
 SUB-CONNECT 9 
 
 % PRIMITIVE ELEMENTS 
 
 ELEMENT SOURCE OAREA 
 
 RAINRATE= ( - . 05*TIME*TIME+360.*TIME ) /7. 776E7 
 FLOW(0)--RAINRATE*OAREA 
 
 % THE RAINFALL RATE IS REPRFSFNTFD BY A PARABOLA OPEN TO -Y AXIS 
 
136 
 
 c AT TIME=0 1AINRATE=0 
 
 % AT TIME=3600 (1 HOUR) MAX RAINRATE OF 6IN./HR. IS REACHFP 
 
 % AT TIMF=7200 (2 HOURS) RAIMRATE=0 AGAIN 
 
 TERMINALS FLUID 
 
 EXTERNALS 
 
 LOCALS RAINRATE 
 
 ELEMENT RESERV AS ; HINIT ; A1 ; HI ; 42 ; H2 
 !IS'*AS=Fl.0W(0)+FL0W(l)+FL0l'(2) 
 V1=FL0W(1)/A1 
 
 V2=FLOW(2)/p.2 
 
 r(l)=Vl*Vl/(2*G)+Pl/GAMMA+Hl 
 
 B(2)=V2*V2/(2*G)+P2/GAMMA+H2 
 
 R(1)=HS 
 
 B(2)=HS 
 INITIAL HS=I!INIT 
 OUTPUT HS 
 
 LOCALS HS ; VI ; PI ; V2 ; P2 
 TERMINALS 0-2 FLUIO 
 EXTERNALS 0-2 
 
 ELEMENT CAP 
 
 FLOW(0)*0 
 
 TERMINALS KLUID 
 EXTERNALS 
 
 FLEMFNT DRAIN A ; H 
 
 FL0W(0)+FL0''J(1)=0 
 
 FL0W(0HBS(SORT(2*G*A*A*(B(0)-H))) 
 TERMINALS 0-1 FLUIO 
 EXTERNALS 0-1 
 
 ELEMENT SINK A ; H 
 
 FLOW(OKBS(SOPT(2*G*A*A*(B(0)-H))) 
 TERMINALS FLUID 
 EXTERNALS 
 
 0/ || 
 
 L'SER-Sl'PPLIEO MAIN PROGRAM 
 
 7, 
 
 MAIN 
 
 ".' 
 
 S^EFAULT 
 
 % 
 
 TST0P=7200. 
 
 m 
 
 ! J1 V\X=60. 
 
 Of 
 
 C0MINT=60. 
 
 r 
 
 DEL=1.0-9 
 
 01 
 
 EPS=l. n »-4 
 
 0.' 
 
 CALL RUN 
 
 % 
 
 END 
 
 % NETWORK DICTIONARY PRODUCED BY MODEL COMPILER 
 DICTIONARY - NODE MAP 
 
137 
 
 ELEMENT SEWER. SOURCE (1) 
 
 NOOE(O): 0, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 10, 
 
 ELEMENT SEWER. S0URCE(2) 
 
 HODE(O): 0, 
 
 IDENTICAL TERMINALS If! ELEMENT ABOVE: 11, 
 
 ELEMENT SEWFP.RESERVfl ) 
 
 NODE(O): 0, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 12, 
 
 MODE(l): 1, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 13, 
 
 N0DE(2): 2, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 14, 
 
 ELEMENT SEWER. RESERV(2) 
 
 NODE(O): 0, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 15, 
 
 NODE(l): 1, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 16, 
 
 N0DE(2): 2, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 17, 
 
 ELEMENT SEWER. CAP(l) 
 
 NODE(O): 0, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 18, 
 
 ELEMENT SEWER. DRAIN(1 ) 
 
 NODE(O): 0, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 19, 
 
 NODE(l): 1, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 20, 
 
 ELEMENT SEWER. DRAIN (2) 
 
 f, ODE(D): 0, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 21, 
 
 M 0DE(1): 1, 
 
 IDENTICAL TERMINALS IN ELEMFNT ^ n VE: 22, 
 
 ELEMENT SEWER. CAP (2) 
 
138 
 
 MODE(O): 0, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 23, 
 
 ELEMENT SEWER. RFSERV(3) 
 
 NODE(O): 0, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 24, 
 
 NODE(l): 1, 
 
 IDENTICAL TERMINALS IN ELEMENT AROVE: 25, 
 
 N0DE(2): 2, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 26, 
 
 ELEMENT SEWER. CAP (3) 
 
 NODE(O): 0, 
 
 IDFNTICAL TERMINALS IN ELEMENT AROVE: 27, 
 
 ELEMENT SEWER. SINK(1 ) 
 
 MODE(O): 0, 
 
 IDENTICAL TERMINALS IN ELEMENT ABOVE: 28, 
 
 ELEMENT SEWER(l) 
 
 •JODE(l): 1,12,10, 
 
 N0DE(2): 2,18,13, 
 
 M0DE(3): 3,19,14, 
 
 N0DF(4): 4,15,11, 
 
 N0DE(5): 5,21,16, 
 
 N0DE(6): 6,23,17, 
 
 N0DE(7): 7,24,22,20, 
 
 NODE(B): 8,27,25, 
 
 NODF( ;; 0: 9,28,26, 
 
 DICTIONARY - VARIAPLE MAP 
 ELEMENT SEWER(l) 
 
 GLOBAL VARIABLES 
 
 OUTPUT NAMFS 
 
 SAMMA 
 
 
 62.43^0 
 
 
 
 32. DO 
 
 T ERMINAL 
 
 VARIABLES 
 
 OUTPUT NAMES 
 
 FLOW(IO) 
 
 
 ZT(3) 
 
 FLOW(ll) 
 
 
 ZT(5) 
 
 FL0W(12) 
 
 
 -7T(3) 
 
 FL0W(13) 
 
 
 -0 
 
 FL0W(14) 
 
 
 ZL(1) 
 
139 
 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 FLOW 
 
 15) 
 16) 
 17) 
 18) 
 19) 
 20) 
 21) 
 22) 
 23) 
 24) 
 25) 
 26) 
 27) 
 28) 
 
 -ZT(5) 
 
 ZL(4) 
 
 -0 
 
 
 
 -71(1) 
 
 ZL(1) 
 
 -ZL(4) 
 
 ZL(4) 
 
 
 
 ZL(7) 
 
 -0 
 
 ZL(8) 
 
 -ZL(8) 
 
 ELEMENT SEWER. SOURCE (1 ) 
 
 LOCAL VARIABLES 
 RAINRATE 
 
 PARAMETERS 
 OAREA 
 
 OUTPUT NAMES 
 ZT(2) 
 
 OUTPUT NAMES 
 1000. HO 
 
 TERMINAL VARIAPLES OUTPUT NAMES 
 R(0) NONE 
 
 ELFMENT SEWER. S(HIRCE(2) 
 
 LOCAL VARIABLES 
 PAINRATE 
 
 OUTPUT NAMES 
 ZT(4) 
 
 PARAMETERS 
 OAREA 
 
 OUTPUT NAMES 
 1000.H0 
 
 "ERMINAL VARIAPLES OUTPUT NAMES 
 
 «(0) 
 
 NONE 
 
 ELEMENT SEWER. RESERV(l) 
 
 LOCAL VARIAPLES 
 
 CUTPl'T f!A M ES 
 
 HS 
 
 7Y(1) 
 
 VI 
 
 ZG(1) 
 
 PI 
 
 7 L(2) 
 
 V2 
 
 7Y(2) 
 
 P2 
 
 7L(3) 
 
 PARAMETERS 
 
 OUTPUT NAMES 
 
 5.S 
 
 100.00 
 
 mm 
 
 5. n 
 
 M 
 
 .75 !1 il 
 
 Ml 
 
 5. JO 
 
 A2 
 
 .7500 
 
140 
 
 H2 5.00 
 
 TERMINAL VARIABLES OUTPUT NAMES 
 
 BO) ZY(1) 
 
 B(2) ZY(1) 
 
 ELEMENT SEWER. RESERV(2) 
 
 LOCAL VARIABLES 
 
 OUTPUT NAMES 
 
 HS 
 
 ZY(3) 
 
 VI 
 
 7Y(4) 
 
 PI 
 
 ZL(5) 
 
 V2 
 
 ZG(2) 
 
 P? 
 
 ZL(6) 
 
 PARAMETERS 
 
 OUTPUT NAMES 
 
 AS 
 
 100.00 
 
 HIMIT 
 
 5.00 
 
 Al 
 
 .7500 
 
 HI 
 
 5.00 
 
 A2 
 
 .7500 
 
 H2 
 
 5.00 
 
 TERMINAL VARIABLES OUTPUT NAMES 
 B(l) ZY(3) 
 
 B(2) ZY(3) 
 
 ELEMENT SE'-'ER.CAP(1 ) 
 
 ELEMENT SEWER. 0RAIN(1 ) 
 
 PARAMETERS OUTPUT NAMES 
 A .7530 
 
 H 5.^0 
 
 TERMINAL VARIABLES OUTPUT NAMES 
 B(l) NONE 
 
 ELEMENT SEWER. DRAIN(2) 
 
 PARAMETERS OUTPUT NAMES 
 A .7500 
 
 H 5. JO 
 
 ELEMENT SEWER.CAP(2) 
 
 ELEMENT SEWER.?ESERV(3) 
 
 LOCAL VARIAP1.ES OUT D UT NAMES 
 
141 
 
 HS 
 VI 
 n l 
 V2 
 P2 
 
 ZY(7) 
 ZG(3) 
 ZL(?) 
 7Y(3) 
 ZL(10) 
 
 PARAMETERS 
 
 OUTPUT NAMES 
 
 AS 
 
 TOOO.no 
 
 HINIT 
 
 O.DO 
 
 M 
 
 1.00 
 
 HI 
 
 O.DO 
 
 A 2 
 
 l.DO 
 
 H2 
 
 O.PO 
 
 T ERMINAL VARIABLES OUTPUT NAMFS 
 B(l) ZY(7) 
 
 B(2) ZY(7) 
 
 ELEMENT SEWER. CAP(3) 
 
 ELEMENT SEWER. SINK(l) 
 
 PARAMETERS OUTPUT NAMES 
 A 1 . ^0 
 
 H O.i^O 
 
 GENERATED VARIABLES OUTPUT NAMES 
 SUB ZY(5) 
 
 SUB 7Y(6) 
 
 SUP ZY(9) 
 
 % RUN-CONTROL PROGRAM PRODUCFO BY MOPEL COMPILER 
 
 C0MM0N/VARS/7Y(9),ZD(9),ZDD(7 t 9) t ZL(10),ZT(5),ZG(3) 
 COMMON/SYSPRM/HMIN,HMAX,EPS,DEL,TSTART,TSTOP,COMINT,ISTOP 
 DOUBLE PRECISION ZY("),ZD(9) ,ZDP(7,9) ,ZI (10) ,ZT(5) ,ZG(3) 
 +,HMIN t HMAX t EPS t DEL i TSTART,TST0P i COHINT 
 
 p*** 
 
 C*** DECLARATIONS FOR SOURCE NAMES r 'F GLOBAL AMD LOCAL VARIABLES 
 
 C*** AND n ARAMFTFRS ^F THE HIGHEST-LEVEL ELEMENT APPEAR HFPF WHEN 
 
 (:*** PRESENT IN THE MODEL AND WHEN NOT EOUAL TO A CONSTANT, 
 p*** 
 
 C*** FOUIVALENCE STATEMENTS MAPPING SOURCE NAMES TO INTEGRATION 
 
 C*** VARIABLES APPEAR HERE. 
 ^•** 
 
 C*** USER'S NON-EXECUTABLE RUN-CONTROL STATEMENTS APPEAR HERE 
 
 C*** DEFAULT VALUES FOR SYSTEM CONTROL PARAMETERS FOLLOW 
 HMIM=l/)-6 
 HMAX-1.0-2 
 EPS-l.D-5 
 
***• 
 
 142 
 
 PEL=l. n -5 
 TSTART=0.HO 
 TST0P=1.H0 
 C0MINT=1.0-2 
 ISTOP=0 
 USER'S EXECUTABLE RUN-CONTROL STATEMENTS FOLLOW 
 TSTOP=7200.PO 
 "MAX=60. r >0 
 COM I NT= 60. nn 
 PEL=1. P - Q 
 FPS=l.D-4 
 CALL RUN 
 FF!D 
 
 % OUTPUT SUBROUTINES PRODUCED EY MODEL COMPILER 
 
 SUBROUTINE RECORD(INIT,IUNIT,N,A) 
 
 C RECORD '/RITES THE N OUTPUT VALUES IN ARRAY A TO UNIT 
 C IUMIT WHEN INIT NOT EQUAL ZERO. WHEN INIT EQUAL ZERO 
 C RECORD "RITES THE TITLE AND LABELS 
 DOUBLE PRECISION A(N) 
 IF (INIT."E.O) GOTO 9000 
 WRITE (IUNIT.l) 
 1 F0RMAT(1H,29X,49HTITLE STORM SEWER LEVELS 
 + ,23f! ) 
 
 WRITE(IUNIT,2 ) 
 2 F0RMAT{1H,9X 
 +.8HTIME ,13X 
 +.8HHS ,13X 
 +.8HHS ,18X 
 +,8HHS ,18X 
 
 +) 
 
 RETURN 
 9000 '!RITE(IUNIT,9100) A 
 9100 F0RMAT(1H,5026.16) 
 
 RETURN 
 
 END 
 
 SUBROUTINE REP0RT(7G,7T,7L,ZY) 
 C REPORT COPIES THE OUTPUT VARIABLES INTO ARRAY A 
 C AND n ASSES A TO SUBROUTINE "ECORD FOR OUTPUT 
 
 DOUBLE PRECISION ZG(1 ),ZT(1 ),ZL(1 ),ZY(1 ),A(4) 
 
 n (l)=7T(l) 
 
 *.(2)-ZY(l) 
 
 *• 3)«ZY(3) 
 
 . r (4) = 7Y(7) 
 
 CALL PEC0RD(1,£,4,A) 
 
 RETURN 
 
 END 
 
143 
 
 APPENDIX C 
 IBM 360 BATCH MODE JOB CONTROL 
 
144 
 
 This appendix lists and describes an IBM 360 job control program 
 which performs a MODEL compilation, FORTRAN compilation, and model integration 
 as a sequence of steps in a single batch mode job. This job control program 
 is included here to illustrate the steps to be executed, the necessary 
 communication between these steps (i.e., file I/O), and the various input 
 streams for MODEL code, FORTRAN code, and data cards. It is not necessary 
 to adhere to the job control given here to use the MODEL package. For 
 example, the package can be used on other computers, and tape files can be 
 used instead of disk files. It is also possible to perform the necessary 
 steps as a sequence of jobs. In this case the job control program shown 
 here would be split into two or more parts (e.g., one job which performs 
 the MODEL compilation, a second which performs the FORTRAN compilation, 
 and a third which performs the model integration). When this is done, the 
 compiled codes must be written to permanent files instead of temporary ones 
 such as shown here. 
 
 The job controls used for MODEL compilation, FORTRAN compilation, 
 and model integration are described briefly below. The job control program 
 is listed at the end of this appendix. 
 
 The job control shown here uses two in-line procedures, WGO and 
 WFORT. WGO invokes the IBM loader to link-edit, load, and execute one or 
 more object decks from the file(s) associated with SYSLIN. WGO is used to 
 execute the MODEL compiler and the numerical software. WFORT invokes the 
 FORTRAN G compiler on the file(s) associated with SYSIN and writes the 
 object deck for these codes to the disk file &&LINKFILE. It is used to 
 compile the output from the MODEL compiler. 
 
 The MODEL compiler is a four step process. Object decks for the 
 four steps are catalogued in the data set USER.P3503.LMOD under the names 
 MP1, MP2, MP3, and MP4 and are executed by WGO. Object decks 10$ and 
 PLFSUBSX from the same catalogued data set are also included in each step. 
 10$ contains the 10 support routines and PLFSUBSX contains the character 
 manipulation routines used by the MODEL compiler. 
 
 The MODEL compiler uses I/O files declared as FORTRAN logical 
 units 5, 6, and 91 through 99. Unit 5 is used for the input streams. The 
 MODEL language input (sections 1, 2, and 3 of the input file as described 
 in Appendix A) follows the first step of the MODEL compiler. FORTRAN code 
 which is passed through the MODEL compiler (section 4 of the input file) 
 
145 
 
 follows the third step of the MODEL compiler. The model source listing and 
 any error messages which are produced are written to unit 6. The fixed 
 portions of the MODEL error messages are catalogued as USER. P3503. MACROS (ERMW) 
 and are read as needed from unit 93. Temporary disk files are used for the 
 remaining units. Units 91 and 92 are used for communication between steps. 
 Units 97, 98, and 99 are used as intermediate files during the construction 
 of the FORTRAN output, which is written in final form on units 95 and 96. 
 Unit 95 contains the run-control program, any other FORTRAN submitted by 
 the user, and subroutine RUN. Unit 96 contains the other FORTRAN subroutines 
 produced by MODEL. The model dictionary is produced on unit 94. The 
 dictionary and the FORTRAN codes are copied to unit 6 if requested by the user, 
 
 The FORTRAN output of the MODEL compiler is compiled by WFORT. The 
 input file, SYSIN, consists of the disk files &&BLK95 and &&BLK96 created 
 by MODEL through FORTRAN units 95 and 96. User-supplied FORTRAN can also be 
 included in this step. The object code produced by the FORTRAN compiler is 
 written to the temporary disk file &&LNKFILE. 
 
 The object deck representing the model, &&LNKFILE, is linked with 
 an object deck of the numerical software, USER.P3503.LMOD(NSP) , and the 
 model is integrated as the final job step. FORTRAN unit 5 is used for 
 user-supplied data cards and unit 90 is used for temporary disk storage. In 
 the near future the integration step will be replaced by two steps, the 
 first of which will perform the steady state analysis and certain sparse 
 matrix operations and the second of which will perform the integration. 
 
146 
 
 //iiodel jo 7 '. 
 
 /*id ps= ^ame-'usfr' 
 
 /''•ID CODE= 
 
 /*ID REGION=200r.,TI?*E= ,IOREQ= ,LIIIES= 
 
 *** PROCEDURE DEFINITIONS 
 *** 
 
 //"go r^oc liefil2=Mjser.f3503 j,mod ? ,ppog=tb>!Loadr, 
 
 // LIBFILE-'RYSIVTCLLIB ' ,OBJBISF=FASS 
 
 //GO EXEC PGM=&rEOG,REGION=56E,PARM=LET 
 
 //FT?6F00] DD SYSOUT=/ 
 
 //SYEEIE DD DS:?=£LIBFIL2,DISP=ST:R 
 
 // DD D5i:=SYSl.FORTIJB, DISPOSER 
 
 // DD DSN=SYSl.FORTUOI,DI5P=SER 
 
 // ?T> DSN=SLIBFILE,DISP=SER 
 
 //SYSLIN DD DSN=£&LNKFILE,UNIT=DISK, 
 
 // SPACE=(TPi<:,l),DISP=(MOD,&OEJDISF) 
 
 // "iD DDSAME-SYSIW 
 
 //SYSLOUT DD SYSOUT=A 
 
 //EYSPRINT DD SYSOUT=A 
 
 //SYSUDUMP DD SYSOUT=A 
 
 // PEND 
 
 //TORT PROC LEVEL-G 
 
 //FORT EXEC PGM=UIFORT&LEVEE,REGION=116K 
 
 //EYSLI1I DD DSN=&&LNKFIEE,DISP=(nOD,FASS) , 
 
 // SPACE= (TRK, (20,20) ) ,UNIT=BISK,DCB=BLKSIZE=400 
 
 //EYEFRINT DD SYSOUT=A 
 
 //PYSPU1TC!! DD DUIEIY 
 
 //SYS7DIP DD DSN=&&SYSUT3,UNIT=DISK,SPA.CE=(800,50, , , ROUND) , 
 
 // DCB=(RECFI!=FB,LRECL=SO,BLEEIZE=SOO) 
 
 //EYEUT1 DD DSN-S&SYSUT] ,U;a t I7=DIST:,SPACF.= (1050,50, , .ROUND) 
 
 //SYSUT2 !')D DSN»&&SYSUT2,UNIT=DISK,SPACE-(4096 t 30, , ,ROUND) 
 
 // PEND 
 
 *** 
 
 *** 4 PAES MODEL COMPILATION 
 *** 
 
 //PI LXEC '7GO,PARM= , LET l EP=PL T .v T f^AIN' ,REGION=125K 
 
 //SYSLIN DD DSK=USER.P3503.L!!OP(KP1) ,DISP=SKR 
 
 // DD DSN=USER.P3503.LKOD(IO$),DISP=SI'R 
 
 // ! D DEN=USFR.P3503.LHOD(PLFEUBSX) ,BISP=SER 
 
 //I T93F001 DD DSN=USER.F35C3. MACROS (ERMW) , 
 
 // LABEL=(, ,,III),DISP=SHR,DCE=BUFNO=l 
 
 //] T96i ooi dd dsnai:e=s&eek96,u:, t it=eyeda,space=(tr:c,(io,2)), 
 
 // DCB= (PvECFM=FB,LPECL=72,BLKSI2E=1440,EUF:TO=1) , 
 
 // :)ISP= (NET\ PASS) 
 
 //FT91F001 DD DSKAMT-&&3LK01,UniT-fiY5T)\,SPACE-(TRK, (10,2)), 
 
 // DCB=(PJCCFM=VS,BLKSIZE=1230,EiTN0=l),DISF=(NEtf,PASS) 
 
 //FT92r001 DD DSNAME=a&BLK92,UNIT=SYSDA,SPACE=(TRK, (10,2)) , 
 
 // riCE» (EECKi«V£ ,BLKSIZE=3510,Bl FNO=l) ,DISP=(NEU,PASS) 
 
 //, T05F001 i D * 
 
147 
 
 Aft* 
 ft** 
 
 //?2 exec • 
 
 //FYSLPJ 
 
 // 
 
 // 
 
 //FT93F001 
 
 // 
 
 //FT94F001 
 
 // 
 
 // 
 
 //FT91F001 
 
 // 
 
 //FT92F901 
 
 // 
 
 //: s 3 :.xic ■ 
 
 // r YrLI!I 
 
 // 
 
 // 
 
 //FT?3r001 
 
 // 
 
 //FT94F001 
 
 // 
 
 // 
 
 //FT?5r001 
 
 // 
 
 // 
 
 //FT96F001 
 
 // 
 
 // 
 //FT97^001 
 
 // 
 // 
 //FTOfjfOO] 
 
 // 
 
 // 
 
 //FT31FQ01 
 // 
 //FT92F001 
 
 // 
 
 //FTO5V03] 
 *** 
 
 *** 
 
 //r4 LXEC ' 
 
 //SYSLIN 
 
 // 
 
 // 
 
 //FTC5F001 
 
 // 
 
 // 
 
 // 'T96F001 
 
 // 
 
 // 
 
 //FT99T'001 
 
 // 
 
 !IODi:L LANGUAGE INPUT STATEMENTS 
 
 :co 
 
 !)D 
 DD 
 
 ;:n 
 
 ED 
 
 :D 
 
 : GO 
 DD 
 DD 
 
 D 
 
 DD 
 
 [JD 
 
 ID 
 
 >D 
 
 DD 
 
 DD 
 i e: 
 
 , FARM- ' LET, EF-PL-.JMAIN ' , REGION-200K 
 DSN=USER.P3503.L*fOD(MP2),DISP=SIIR 
 DSN=USER.F3503.LMOD(IO$),DISF=FHR 
 DSW«l'SER.P3503.U-IOD(PLF!5l T ESX),DISP-SIiiE 
 DSN-USER . "'3503 . : IACROS (ERMW) , 
 LABEL- (, , ,!:■:) ,DISP=EUR,DCE=EUFN0=1 
 DSNAfE=&&ELK94,UNIT=FYSPA , SPACE= (TRK, (l p , 2) ) , 
 
 rcb- (p.ecfm-fb , lrecl-30 , elkfize-1600 , bufno-l ) , 
 
 disp=(:tew,paS3) 
 
 dsname=£sblk91,unit=sysda, space- (trk, (10,2)), 
 
 DCB- (RECFM-vs,BLKSIZE= 1230, BUF*IO-l),DISP=(OLD, PASS) 
 DSR/\ME=S:&ELK92,UniT=SYSDA, SPACE- (TRK, (10,2) ) , 
 DCE=(IIECFM=VS,BLKSIZF=3 510, BUFNO-1) ,DISP- (OLD, PASS) 
 ,PARlT= , LET,EP=?LvJT'IAIN , ,RECIOK=200K 
 
 ds!I-user.P3503.lmod(l;p3),disp=she 
 dsimjser.p3503.lmod(io$),disp=sne 
 ds>!=user.p3503.lm0d(plfsuesx) ,dtsp= <: ' ': 
 
 DSN-USER. E3503. MACROS (ERMU) , 
 
 LABEL-(,,,IN),DISP=S1IR,DCB=EUFN0=1 
 
 DSNAME=&&BLK94,UNIT=SYSDA, SPACE- (TRK, (10,2)) 
 
 DCB=(RECFM=FB,LPJ:CL=S0,ELKSIZE-1600,EUFNO=l) 
 
 OISP- (MOD, PASS) 
 
 DS:iAME=££BLK95,UiIIT=SYSDA, SPACE- (TRK, (10,2)) 
 
 ?CB=(EECFM=FE,LRECL=72,3Lr.SIZE=1440,BUFI-TO=l) 
 
 r>ISP«(NE7,PASS) 
 
 DSNAME=&&BLK96,UNIT=SYSDA,SFACE- (TRK, (10,2)) 
 
 DCB-(RECFM=FB,LRECL=72,ELKFIZE=1440,BLFNO=1) 
 
 n isp=0 oo, pas?) 
 
 DS?7AME=&&BLK97,U1TIT=SYSDA, SPACE- (TRK, (10,2)) 
 DCB=(RECF!I=FE,LRECL=72,BLKSIZE=1440,EUFITO=1) 
 [3ISr=(KEM, DELETE) 
 
 DSKAME=fx&ELK93,UIUT=SYSPA, SPACE- (TRK, (10,2)) 
 DCE=(RECFT^Fr,LRECL=72,BLKSIZE=1440,BUF 10=1) 
 
 DSNAME- C .&BLK91 , UNIT-SYSDA , S F \CE= (TRR ,(10,2)), 
 
 ■)CB=(RECFM=VS,ELKFIZE=1230,EUFnO=l),DISP= (OLD, PASS) 
 
 DSNAME=S&3LK92,UNIT=SYS1 ■*• , c r ACE- (TRK, (10, 2) ) . 
 
 ' CE=(RECF?:=VS,3LI'.SIZE=3510,BUF"O=l),DISP- (OLD, PASS) 
 * 
 
 ER-: UPPLIED FORTRAN 
 
 r-0,P 1 \PJt= , LET,EP=FL T .7MAIN , ,REGI01J-150E 
 
 DD 
 
 DD 
 
 DD 
 
 >D 
 
 
 DSE-l f?ER.r3503.LMODClP4),DISP-Fnr 
 
 i" " -USEP.F3503.LMOD(IO$),DISP=SFE 
 
 DS f-USER.1 3503.LMOD(PLFSUBSX),DISP=SIIR 
 
 DS:\AME=&&BLK95,Ui:iT-SYSDA, SPACE- (TRK, (10,2)) 
 
 »CB=(FECFH-FB,LRECL=72,BLKST.ZE=1440,BUFNO=l) 
 L*ISP- (MOD, PASS) 
 DSNAMJE=&&BLK96,U?JIT«SYSDA, SPACE- (TRK, (10,2)) 
 
 iCB=(PJECFM-FB,LRECL-72,BLKSIZE»1440,BUFNO=l) 
 
 ISP- (MOD, PASS) 
 DSNAME=&&BIiC99,UNIT-SYSDA, SPACE- (TRK, (10,2)) 
 !>CE=(RECFIt-FB,LRECL=72,BLKSIZF-1440,BUFI\ , 0-l) 
 
148 
 
 // DISP= (NEW, DELETE) 
 
 //FT91F001 V>} DSNANF=£&BLK91,UNIT=SYSDA,SPACE=(TRK, (10,2)) , 
 
 // DCB=(RECFtt=VS,3LKSIZE=l 230, BUFNOl) ,DISP= (OLD, DELETE) 
 
 //FT92F001 DD DSNAME=&&BLK92,m-TIT«SYSDA, SPACE- (TRK, (10,2)) , 
 
 // '>CB=(RECFM=VS,BLX?IZE=3510,BEFNO=1),DIPS= (OLD, DELETE) 
 
 *** FORTRAN COMPILATION 
 *** 
 
 // EXEC T .T0RT,PARM=' !0S0URCE,N0!IAP ' 
 
 //SYFP; DD DSNAME=£aBLX95,UNIT=SYSDA,SPACE= (TRK, (10, 2) ) , 
 
 / / ~JCB= (RECF* i=FB , LRECL=7 2 , BLXSIZE=1440 , BUFNO=l) , 
 
 // ^IPP= (OLD, DELETE) 
 
 // 9D Dr^;A.ME=^&BLE96 ,UKIT=CYSDA, SPACE= (TRK, (10, 2) ) , 
 
 // PCB= (RECFM=VB,LRECL=72,BLKSIZE=1440,BUFi;O=l) , 
 
 // ^ISP= (OLD, DELETE) 
 
 *** y^d * 
 
 *** USER-SUPPLIED FORTRAH 
 *** 
 
 *** MODEL INTEGRATION 
 *** 
 
 // EXEC VT,0, PARM=' LET, EP= IAIN', REOION=150K 
 
 //CYPLIN DD DSN= r <&LNKFILE,UNIT=I)ISK,DISP= (OLD, DELETE) 
 
 // DD DSN=USFR. r '3503.LMOD(nSP),DISP=S!iR 
 
 //FT C J0V001 DD DSK=U5ER.r3503.TEOT,UNIT=DISK,VOL=SER=UIPUBl, 
 
 // SPACE=(1024, (25, 10), RLSE),DISr=(NEW, DELETE), 
 
 // BC3=(KECFI^VBS,LRECL=1020,3LKSIZE=1024) 
 
 //FT05F001 TO * 
 
 *** USER-SUPPLIED DATA CARDS 
 
 /* 
 
149 
 
 APPENDIX D 
 MODEL ERROR MESSAGES 
 
150 
 
 The descriptions of the various errors and possible errors 
 detected by MAP are listed below along with the associated message numbers. 
 Warning messages are identified by a W in the first column. This character 
 is not printed with the message. Blank error descriptions indicate message 
 numbers which are not used. 
 
151 
 
 The descriptions of the errors and possible errors detected by 
 MODEL are listed below along with the associated message numbers. Warning 
 messages are preceded by a V which is not printed when the warning is is- 
 sued. J'.lanl nessa^es indicate Message numbers which are rot used. 
 
 1 ERROR IN MODEL. ANALYSIS ABORTED 
 
 2 INPUT area overflow;, analysis aborted 
 
 3 MODEL NAME HISSING. ANALYSIS ABORTED 
 
 4 ELEMENT IF A KUB-FLEMEHT 01' ITSELF. ANALYSIS ABORTED 
 5 
 
 6 MEOFATION IN MUTUALLY IITDEPENDENT VARIABLES ONLY. MAY BE INCONSISTENCY 
 
 7 NSYSTEM MAY BE SINGULAR. NUMBER OF EQUATIONS -• ■ NUMBER OF VARIABLES 
 
 10 MIE>PROPEP UNIT 'RTMBER. OUTPUT SENT TO UNIT 6 
 
 11 JMODEL TAMP SHORTENED TO 8 CHARACTERS 
 
 12 TYPE INSTRUCTION IGNORED. TYPE NAME MISSING 
 
 13 0TEE/1INAL TYPE NAME SHORTENED TO P CHARACTERS 
 14 
 
 15 
 
 16 TERMINAL TYPE HAS NO VARIABLES 
 
 17 FUNCTION DEFINITION IGNORED. TOO MtANY FUNCTIONS DEFINED 
 
 18 FUNCTION DEFINITION IGNORED. FUNCTION NAMF MISSING 
 VI E'FUNCTION NA* - t SHORTENED TO € C T IAPACTT' P !' 
 
 20 "UNCTION DEFINITION IGNORED. IMPROPER ARGUMENT COUNT 
 
 21 FUNCTION DEFINITION IGNORED. NO ARGUMENTS 
 
 22 TABLF FUNCTION DEFINITION IGNORED. TABLE rtUMBER : r 0T POSITIVE- INTEGER 
 
 23 TABLE FUNCTION DEFINITION IGNORED. TABLE NUMBER USED PREVIOUSLY 
 
 24 ^'independent variable name seortenfd to 3 characters 
 
 25 improper dimension. dimension set to 1 
 
 26 element name missing 
 
 27 './element name shortened to r characters 
 
 28 UMDEFINEE INSTRUCTION IGNORED 
 
 29 ' 'SUB-ELEMENT NAM! SHORTENED TO 3 CHARACTERS 
 
 30 TERMINAL DECLARATION IGNORED, D1PROPER TERMINAL ID NUMEER(S) 
 
 31 '^TERMINAL ID HUNGERS SPECIFIED IN I'RONG ORDER. ORDER REVERSED 
 
 32 '.TERMINAL TYPE NAME SHORTENED TO 3 CIIARACTERS 
 
 33 TERMINAL TYPE NOT ASSIGNED. TERMINAL TYPE NAME UNDEFINED 
 
 34 EXTERNAL TERMINAL DECLARATION IGNORED. IMPROPER TERMINAL IE NUMBEE(S) 
 
 35 EXTERNAL TERMINAL DECLARATION IGNORED. TERMINAL NOT DECLARED 
 
 36 CONNECTION TO SUB-ELEMENT IGNORED. IMPROPER TERMINAL ID NUMEER(S) 
 
 37 CONNECTION 10 SUB-ELEMFNT IGNORED. TERMINAL NOT DECLARED 
 32 CONNECTIO?] IGNORED. IMPROPER TERMINAL ID NUM3EP(8) 
 
 32 CON^LCTION IGNORED. TERMINAL(S) NOT DECLARED 
 
 40 EQUATION IGNORED. BUILT IN FUNCTION ARGUMENT 3EF0RE ? l r : r OT SCALAR 
 
 41 UNRECOGNIZABLE CHARACTEF LEFORF ? IGNORED 
 ^2 EQUATION IGNORED. OPERAND MISSINC BEFORE ? 
 A3 EQUATION IGNORED. OPERATOR MISSINC BEFORE ? 
 
 44 'NA'P; SHORTENED TO 3 CHARACTERS BEFORE ? 
 
 45 EQUATION IGNORED. NUMERICAL STRING EEFORE ? T c TOO LONG 
 
 46 EQUATION IGNORED. UNDEFINED VARIABLE "VIP BEFORE ? 
 
 47 EQUATION IGNORED. UNDEFINED TFRMINAL ID NUMBER BEFORE ? 
 
 48 EQUATION IGNORED. THRONG PORN FOR TEFMINAL in NUMBER BEFORE ? 
 
 49 ROTATION IGNORED. REFERENCF T n UNTYPED TERMINAL BEFORE ? 
 
152 
 
 50 
 51 
 52 
 53 
 54 
 55 
 56 
 57 
 58 
 59 
 60 
 61 
 62 
 63 
 64 
 65 
 66 
 67 
 68 
 69 
 70 
 71 
 72 
 73 
 74 
 75 
 76 
 77 
 78 
 79 
 SO 
 31 
 32 
 33 
 34 
 85 
 36 
 37 
 38 
 89 
 90 
 91 
 ?2 
 
 PC 
 
 »/ 
 96 
 97 
 98 
 
 99 
 
 EQUATION IGNORED. 
 EQUATION IGNORED. 
 EQUATION IGNORED. 
 EQUATION IGNORED. 
 EQUATION IGNORED. 
 EQUATION IGNORED . 
 
 UNDEFINED TERMINAL VARIABLE NAME BEFORE ? 
 
 STRIP TERMINAL VARIABLE REFERENCE IS NOT IN FUNCTION 
 
 TOO MANY FUNCTION ARGUMENTS BEFORE ? 
 
 TOO FD' T FUNCTION ARGUMENTS BEFORE ? 
 
 INCOMPLETE FUNCTION REFERENCE BEFORE ? 
 
 EQUATION 
 
 EQUATION 
 EQUATION 
 EQUATION 
 EQUATION 
 EQUATION 
 EQUATION 
 EQUATION 
 
 IGNORED . 
 IGNORED . 
 IGNORED. 
 IGNORED. 
 
 IGNORED. 
 IGNORED. 
 
 IGNORED. 
 IGNORED . 
 
 MISPLACED 
 UNMATCHED 
 UNMATCHED 
 MISPLACED 
 = MISSING 
 
 ( 
 
 BEFORE ? 
 (S) BEFORE 
 BEFORE ? 
 BEFORE ? 
 
 BEFORE ? 
 
 EXTRA = BEFORE ? 
 
 IMPROPER FORM FOR PARAMETER ASSIGNMENT 
 
 INTEGER DIMENSION EXPECTED BEFORE ? 
 
 UNDEFINED PSEUDO TERMINAL ID NUMBER BEFORE ? 
 
 IF-TIIEN-ELSE IGNORED. OPERATOR-OPERAND TYPE DISAGREEMENT BEFORE ? 
 
 EQUATION IGNORED. ILLEGAL USE OF |,&,< t OP > INSIDE FUNCTION 
 
 IF-TKEN-ELSE IGNORED. IF CLAUSE IS NOT A LOGICAL EXPRESSION 
 
 ELSE CLAUSE (S) IGNORED. NOT PRECEEDED BY IF-THEN 
 
 IF-TEEN-ELSE IGNORED. MISSING THEN CLAUSE 
 
 EQUATION IGNORED. UNMATCHED ( (S) IN ARGUMENT BEFORE ? 
 
 EQUATION IGNORED. UNDEFINED TABLE FUNCTION NUMBER BEFORE ? 
 
 EQUATION IGNORED. COMMA MUST FOLLOW TABLE FUNCTION NUMBER 
 
 INITIAL VALUE ASSIGNMENT IC> T ORED. IMPROPEP FORM 
 
 EQUATION IGNORED. PRECEEDING EXPRESSION UNDEFINED - IMPROPER DIMENSIONS 
 
 EOLATION IGNORED. NO TERMINALS CONNECTED TO STRIP TERMINAL 
 ■TERMINAL IS DOUBLY DEFINED 
 
 WVARIABLE OR PARAMETER NAME SHORTENED TO 8 CHARACTERS 
 DECLARATION OF INDEPENDENT VARIAELF IS NOT NECCESSAEY 
 
 TERMINAL MAS NOT BEEN ASSIGNED A TYPE 
 
 LOCAL CONNECTION IGNORED. TERMINAL TYPE MISMATCH 
 
 EXTERNAL- INTERNAL TERMINAL TYPE MISMATCH 
 
 EXTERNAL TERMINAL IN OUTER ELEMENT REDECLARED AS 
 
 EXTERNAL TERMINAL REDECLARED AS A LOCAL. TOO FEN 
 
 EXTRA CONNECTION (S) TO ELEMENT IGNORED 
 
 REFERENCE TO UNDEFINED SEE-ELEMENT IGNORED 
 DERIVATIVE OF CONSTANT VARIABLE REPLACED BY 
 ^-^EQUIVALENCE OF WO INDEPENDENT VARIABLES IGNORED 
 "./EQUIVALENCE OF INDEPENDENT VARIABLE AND CONSTANT IGNORED 
 
 EXTERNAL CONNECTION HAS UNMATCHED STRIP TERMINAL 
 
 EXTERNAL STRIP TERMINAL NOT ASSIGNED A TYPE 
 
 CONNECTION OF TWO STRIP TERMINALS IGNORED 
 
 CONNECTION TO EXTERNAL STRIP TERMINAL IGNORED 
 
 " "-'' :"- is-:: ignored, else clausi missing after 
 
 '.'INITIAL VALUE ASSIGNMENT FOR AN INDEPENDENT VARIABLE IGNORED 
 INITIAL VALUE UNKNO'/N AT TIME-TSTART. ASSIGNMENT IGNORED 
 
 '.INITIALIZED VARIABLE APPEARS IN NO EQUATIONS 
 IMPROPER DIMENSIONS. VARIABLE OR PARAMETER REDECLARED AS SCALAR 
 EOLATION IGNORED. CONTAINS MORI TNA r - r 6 NESTED NON-SCALAR FUNCTIONS 
 
 A LOCAL 
 
 CONNECTIONS TO ELEMENT 
 
153 
 
 VITA 
 
 Thomas Fred Runge was born in Madison, Wisconsin, on September 6, 
 1949. In 1967 he graduated from Gerstmeyer High School in Terre Haute, 
 Indiana, and was named a National Merit Scholarship Finalist. He was 
 elected to the Phi Beta Kappa and Phi Kappa Phi national honoraries while 
 attending the University of Illinois, where he received a Bachelor of 
 Sciences degree in Mathematics-Computer Science in June 1971. He 
 continued at the University of Illinois as a graduate student and research 
 assistant in the Department of Computer Science from June 1971 to May 1977. 
 He has published an article 'A Universal Language for Network Simulation 1 
 and is a member of the Association for Computing Machinery and of its 
 SIGSIM special interest group. 
 
rmAEC-427 
 
 (6/68) 
 \ECM 3201 
 
 U.S. ATOMIC ENERGY COMMISSION 
 
 UNIVERSITY-TYPE CONTRACTOR'S RECOMMENDATION FOR 
 
 DISPOSITION OF SCIENTIFIC AND TECHNICAL DOCUMENT 
 
 ( See Instructions on Reverse Side ) 
 
 AEC REPORT NO. 
 
 COO-2383-0039 
 
 2. TITLE 
 
 A UNIVERSAL LANGUAGE FOR CONTINUOUS NETWORK SIMULATION 
 
 TYPE OF DOCUMENT (Check one): 
 
 2] a. Scientific and technical report 
 ^} b. Conference paper not to be published in a journal: 
 
 Title of conference 
 
 Date of conference 
 
 Exact location of conference 
 
 Sponsoring organization 
 
 □ c. Other (Specify) 
 
 RECOMMENDED ANNOUNCEMENT AND DISTRIBUTION (Check one): 
 
 a. AEC's normal announcement and distribution procedures may be followed. 
 
 ~3 b. Make available only within AEC and to AEC contractors and other U.S. Government agencies and their contractors. 
 H c. Make no announcement or distrubution. 
 
 REASON FOR RECOMMENDED RESTRICTIONS: 
 
 SUBMITTED BY: NAME AND POSITION (Please print or type) 
 
 C. W. Gear 
 
 Professor and Principal Investigator 
 
 Organization 
 
 Department of Computer Science 
 University of Illinois 
 Urbana, Illinois 61801 
 
 ^j&L&Sttf*- 
 
 Date 
 
 May 1977 
 
 FOR AEC USE ONLY 
 
 AEC CONTRACT ADMINISTRATOR'S COMMENTS, IF ANY, ON ABOVE ANNOUNCEMENT AND DISTRIBUTION 
 RECOMMENDATION: 
 
 PATENT CLEARANCE: 
 
 a- AEC patent clearance has been granted by responsible AEC patent group. 
 LJ b. Report has been sent to responsible AEC patent group for clearance. 
 
 1 I c. Patent clearance not required. 
 
3LI0GRAPHIC DATA 
 5, iET 
 
 [Tile and Subtitle 
 
 1. Report No. 
 
 UIUCDCS-R-77-866 
 
 i UNIVERSAL LANGUAGE FOR CONTINUOUS NETWORK SIMULATION 
 
 f, uthor(s) 
 
 'homas Fred Runge 
 
 i/crforming Organization Name and Address 
 
 )epartment of Computer Science 
 Iniversity of Illinois 
 irbana, Illinois 61801 
 
 | Sponsoring Organization Name and Address 
 
 Inergy Research and Development Administration 
 Jashington, DC 
 
 3. Recipient's Accession No. 
 
 5. Report Date 
 
 May 1977 
 
 6. 
 
 8> Performing Organization Rept. 
 
 N °" UIUCDCS-R-77-866 
 
 10. Project/Task/Work Unit No. 
 
 11. Contract /Grant No. 
 
 US ERDA/EY-76-S-O2-2380 
 
 13. Type of Report & Period 
 Covered 
 
 thesis research 
 
 14. 
 
 I Supplementary Notes 
 
 1 Abstracts 
 
 The research on which this thesis is based was undertaken as part of the development 
 of a general purpose package for digital simulation of continuous systems based on 
 ordinary differential equations. The overall structure of the package which has 
 been developed is outlined in Figure 1.1. In particular, this research is concerned 
 with continuous simulation modeling languages and with the design and development of 
 MODEL, a 'universal' language for continuous network simulation, for use within 
 this package. Thus, we will be concerned primarily with the processes of Figure 
 1.1a — that is, with the language features which support the formulation of 
 continuous system models. We will concern ourselves with the implementations of the 
 modeling support, model analysis, and integration processes only to the extent that 
 these implementations facilitate or encumber the provision of desirable modeling 
 language features. 
 
 1 Key Words and Document Analysis. 17a. Descriptors 
 
 continuous simulation 
 network analysis 
 simulation languages 
 
 1. Identifiers /Opcn-Iinded Terms 
 
 V COSAT1 Field/Group 
 
 Availability Statement 
 
 unlimited distribution 
 
 19. Security Class (This 
 Report) 
 
 timri assifii:d 
 
 20. Security Class (This 
 Page 
 
 UNCLASSIFIED 
 
 21. No. of Pages 
 
 157 
 
 22. Price 
 
 F 'M NTIS-35 ( 10-70) 
 
 USCOMM-DC 40329-P71 
 

 *fi ! *; 
 
jim m lilt