IN IMPLEMENTATION OF THE
COMBINED SIMULATION LANGUAGE
behorend bij het proefschrift
Issues of Parallelization in
Implementation of the Combined Simulation
Language COSMOS
van Dirk L. Kettenis
Ephoron virgo, die na 50 jaar afwezigheid zich in de zomer van 1992 weer massaal rnanifesteerde als zomersneeuw, geen eendagsvlieg blijkt te zijn.
In een specificatie van een continu model mag de tijdstap die gebruikt wordt bij de numerieke oplossingstechniek van de
differentiaalvergelijkingen niet voorkomen.,
3. Het welzijn van mens en dier is gebaat btil eett
vermindering van de vleesconsumptie.
4.. Een voorbeeld van onzorgvuldig omgaan met
het dimensiebegrip in de atletiek is het gebruilc van de term tijdsnelste voor de niet-winnaar die
zich op grand van de prestatie alsnog plaatst
voor een volgende ronde.
Nu de secundaire arbeidsvoorwaarden van arnbtenaren op zijn hoogst marktconform zijn of binnen kort zullen zijn, heeft hun werkgever
geen excuus meer voor het feit dat de primaire
arbeidsvoorwaarden onder de norm van de
markt liggen.,
6. Ads de Betuwelijn nodig is, zou deze door het
natte deel van Rijkswaterstaat moeten warden aangelegd.
iGezien vanuit historisch perspectief verdient ieert, therapeut die lcruiden voorschrijft eerder de kwalificatie regulier dan de urtiversitair
Dat de bijdrage van de medici bij het gezond maken van de mens bescheiden is, blijkt uit de terrninologie dat de dokter de patient slechts beter maakt.
De huidige publicatiecultuur zorgt er voor dat de
wetenschapper niet meer bij blijft in zijn vak.
Door de kaders waarin het onderzoek plaats vindt op universiteiten is men daar in het
tijdperk van de Rederijkers aangeland.
De sexuele revolutie is pas voltooid als woorden als scluzamstreek en schaamhaar uit het normale spraakgebruilc zijn verdwenen.
IN IMPLEMENTATION OF THE
COMBINED SIMULATION LANGUAGE
COSMOS
PROEFSCHRIFT
ter verkrijging van de graad van doctor aan de Technische Universiteit Delft,
op gezag van de Rector Magnificus Prof. ir. K. F. Wakker, in het openbaar te verdedigen ten overstaan van een commissie,
door het College van Dekanen aangewezen, op maandag 3 oktober 1994 te 13.30 uur
door
Dirk Leonardus KETTENIS werktuigkundig ingenieur
Prof. dr. H. Koppelaar
en de toegevoegd promotor: Prof. dr. ft. E. J. H. Kerckhoffs
CIP-GEGEVENS KONINKLIJKE BIBLIOTHEEK, DEN HAAG Kettenis, Dirk Leonardus
Issues of parallelization in implementation of the
combined simulation language COSMOS / Dirk Leonardus Kettenis. - [Si.. : s.n.j. - Ill.
Thesis Technische Universiteit Delft With index, ref. -With summary in Dutch.
ISBN 90-9007472-4
Subject headings: simulation languages / computer simulation.
©1994 D. L. Kettenis
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying,
Contents
Preface
1Introduction
2 Simulation 9.1 Models 2.1.1 Continuous Models 2.1.2 Discrete Models 2.1.3 Combined Models 2.2 Experiments3 Simulation Languages
3.1 Continuous Simulation Languages 3.1.1 Explicit Block Languages 3.1.2 Implicit Block Languages 3.1.3 Descriptive Languages
3.1.4 Some Other Simulation Languages 3.2 Discrete Simulation Languages
3.2.1 Next-Event Simulation Languages 3.2.2 Activity-Scanning Languages 3.2.3 Process-Interaction Languages 3.2.4 Transaction-Flow Languages
3.2.5 Languages Based on General-Purpose Languages 3.3 Combined Simulation Languages
3.3.1 COSY 3.3.2 PERSONAL PROSIM 3.4 Other Developments 3.5 Language Overview ix 1 7 10 11 14 15 17 19 22 22 27 33 35 36 37 38 38 39 42 43 46 50 52 57
The Simulation Language COSMOS 61 4.1 General Overview 62 4.2 Discrete Models 64 4.3 Continuous Models 68 4.3.1 Prey-Predator System 70 4.3.2 Discontinuities 72 4.4 Continuous Submodels 77 4.5 Combined Models 82 4.6 Experiment Description 87 4.6.1 Iterative Frame 90 4.6.2 Monitors 93
4.7 Other Language Constructs 96
4.7.1 CASE-statement 96
4.7.2 FOR-statement 97
4.7.3 Simulation Operators 101
4.8 Relation to Other Languages 104
4.8.1 Model Description 105
4.8.2 Experiment Description 110
5
Implementation of COSMOS on Sequential Architectures 113
5.1 Continuous Simulation 114
5.1.1 Sorting 114
5.1.2 Handling Discontinuities 115
5.1.3 Synchronizing Continuous Process Objects 123
5.1.4 Implementation of Continuous Objects 127
5.1.5 Basic Continuous Algorithm 128
5.2 Discrete Simulation 130
5.2.1 Implementation of Discrete Objects 131
5.2.2 Implementation of WAIT UNTIL-statement 133
5.3 Combined Simulation 134
6
Parallel Simulation
1396.1 Parallel Continuous Simulation 141
6.2 Parallel Discrete Simulation 147
6.2.1 Conservative Method 149
6.2.2 Optimistic Method 153
7 Towards Parallel Implementation of COSMOS
1617.1 Communication among Objects 163
7.2 Discrete Objects 164
7.2.1 Translation of Scheduling Statements 165
7.2.2 Concurrent Events 170
7.3 Continuous Objects 173
7.4 Algorithms 176
7.4.1 Node Manager 176
7.4.2 Clusters of Continuous Objects 181
7.5 Sequential versus Parallel Results 184
7.6 Implemented Software 186
8
Performance of Developed Parallel System
1878.1 The Test Model 188
8.2 Workload and Messages 191
8.3 Experiments and Results 193
8.4 Discussion 199
8.4.1 The Test Model 199
8.4.2 Integration Algorithm 199
8.4.3 Communication 200
8.4.4 Packing of Messages 202
8.4.5 Time Warp 203
9 Epilogue
2059.1 The Simulation Language COSMOS 205
9.2 Some Simulation Applications 206
9.3 Parallel Simulation 208 9.4 Future Research 210
Summary
213 Bibliography 217Author Index
237Index
241Samenvatting
253Curriculum Vitae
259Preface
This thesis is based on work carried out during the years 1979 to 1993. Dur-ing the period before 1979 I came to the conclusion that the simulation field is divided into two camps: the so-called continuous and discrete simulation. The daily practice I met in the agricultural research is that seldom a "con-tinuous". simulation model is completely continuous. During 1979 Prof. Dr. Tuncer Oren, University of Ottawa, Canada, spent his sabbatical leave at the Computer Science Department of Wageningen Agricultural University, the Netherlands. At that time Tuncer was involved in defining the simulation language GEST. Although I liked the GEST language and the underlying con-cepts, I thought the language was in some aspects not flexible enough. The idea to develop a new simulation language which supports both continuous and discrete models came to my mind during the discussions with him. This simulation language, COSMOS, is central to this thesis. The discussions dur-ing all these years with Prof. Dr. Francois Cellier, The University of Arizona and formerly Swiss Federal Institute of Technology, Zurich, were stimulating and helpful.
I never thought of writing a PhD thesis about the work. Several people
suggested to me to write a thesis, but the daily routine at the Computer
Science Department of Wageningen Agricultural University kept me away from it. Prof. Dr. Francois Cellier and Prof. Dr. Ralph Huntsinger, Califor-nia State University Chico, CaliforCalifor-nia, USA and The University of Calgary, Canada, have played an important role in convincing me to write a thesis. Finally during 1991, Prof. Dr. Jr. Eugene Kerckhoffs, Delft University of Technology, the Netherlands, and University of Ghent, Belgium, persuaded
me to prepare this book. I would like to express my thanks to him and Prof. Dr. Henk Koppelaar, Delft University of Technology, for their guidance and stimulating discussions during the preparation of the thesis. Eugene offered the possibility to work with an advanced multiprocessor computer system. This challenge was among the reasons to start writing this book.
Only a few people are specialists in both continuous and discrete simula-tion. Since this thesis is about combined continuous and discrete simulation, it has been necessary to discuss several details of both simulation
method-ologies. Therefore, some of the details will be well known to researchers working with continuous models, but are not known to researchers working with discrete models, and vice-versa. When the reader encounters such parts while reading this book, I hope she or he will be able to appreciate that.
Developing a compiler and a run-time system for a simulation language is quite a job. Many of my students and trainees from other educational institutions have contributed to completing the software. Among them
spe-cial credit must be given to, in random order, Cora van der Meer, Eus
Schrauwen, Koos Keune, Kees de Gooijer, Eite van der Veen, Bob de Vos, Hans Rottier, Kees Bos, Michel Goris, Jan Willem Hofstee, and Henk van Sonsbeek. They spent remarkably more time on their respective tasks than they were obliged to. Roel Dolsma programmed the postscript version of the graphical output. Thanks to his effort the cosmos output could be included in this thesis. Boudewijn Pelt programmed my ideas about implementing the software for combined simulation on a parallel computer system. Frits Wedman and Bernard Kroes, both of Delft University of Technology, are acknowledged for their help to master some problems with the NCUBE2 parallel computer system.
I am pretty sure that the words I have used in this thesis may be found in more than one English dictionary. The words I have chosen and the order in which I have written the words are what concerns me. Many people have helped me from time to time. I would like to express my thanks to my co-worker Dr. Jr. Gert Jan Hofstede, who read some parts of the manuscript and gave useful suggestions to improve the text. I would like to thank
Ian Cressie, Centre for Agricultural Publishing and Documentation, and Hanneke Pompe, Department of Agricultural Engineering and Physics, for their occasional help when I could not find the proper formulation in English. I am grateful to Francois Cellier for answering many questions about the English language I have sent to him by electronic mail. Wherever he was, his reactions came from a variety of places on this globe, often without hardly any delay.
Credit must also be given to my co-workers at the Computer Science Department. In particular I wish to express my indebtedness to Drs. Eric van Ammers, Drs. Mark Kramer, Jan Ockeloen, Gerard Gaasbeek, Hans Vierbergen, Gea Brussen, and my former co-worker Dr. Jr. Jan den Dulk for their support. I wish to acknowledge my deep indebtedness to Prof. Jr.
Maurice Elzas for his guidance during the greater part of my scientific life. I wish to express my thanks to my parents for the opportunity which they provided to enable me to reach this level of education. Furthermore, I wish to thank them for the many things I have learned from them. I am not less grateful to my wife Els for her partnership and friendship. I hope that I have not stolen too many hours from family life with her and our children Mark and Roel.
At the Wageningen Agricultural University, the Netherlands, it is not possible to study for any degree in Computer Science. Therefore, the condi-tions for research at the Computer Science Department are less than ideal. Besides, progress of research is limited caused by the fact that only a few students are interested in taking part in technology oriented research. That I still have been able to complete this work, is a source of satisfaction tome.
Furthermore, I hope the completion of this work will be a stimulus to my co-workers to carry on with their research work and to finish a thesis.
Chapter 1
Introduction
Because of its flexibility, computer simulation has replaced mathematical analysis and physical prototyping as the preferred method of research in many applications. In computer simulation, the computer mimics, in one
way or another, the behaviour of a system under study. Since most re-searchers or designers have easy access to powerful computers, most simu-lation studies, nowadays, are performed with help of a computer. For that reason the qualification computer often is not used. Accordingly, one should read in the sequel "computer simulation" where "simulation" is used.
To be able to mimic behaviour of a system, the computer needs
in-structions. The set of instructions forms a model. As will be discussed in Chapter 2, there are several types of model. The most important categories are continuous models and discrete models. Until the end of the seventies most people thought any system could be modelled by either a continuous or discrete model. The most important reason supporting that idea is that the application areas were far apart. Discrete models are also employed in operations research, and they are often used to study queueing problems. At present discrete models are employed in, among others, chip design. Contin-uous models are employed mainly to study technological systems. In contin-uous models changes of the state of the model are thought to be smooth. In a continuous model, however, sometimes discontinuous changes will occur. Discontinuous changes are caused by, for example, model simplifications. Simulation software, such as simulation languages, in use at the end of the seventies to experiment with continuous models, did not support discon-tinuous changes. Furthermore it became clear that some of the dynamics of a system could be modelled better with help of discrete submodels. At
that time the idea to construct a simulation language supporting both
con-tinuous and discrete models came to my mind. Later, it appeared to me
that Fahrland (1970) proposed the same idea in 1970. In Section 3.3 the developments of Fahrland and some other language designers in the field of combined continuous and discrete simulation languages will be described.
Programs resulting from simulation are usually large and complex. For that reason, special attention has to be given to documentation of simulation models. The process of modelling a system is characterized by conceiving a model, and validating and adapting the model in an iterative process. This process is known as the model life cycle. Thus, in the first period of the
lifetime of a model, the model will be changed frequently. Later, when the model matures, the discovery of new knowledge about the system under study becomes a reason for updating the model. Application of techniques collectively referred to as software engineering techniques is a consequence of the model cycle in producing simulation programs. So, the language to be designed has to support the software engineering techniques. The most important issues are:
Modularity: The human mind cannot deal with more than about seven, plus or minus two, concepts at a time (Miller, 1956). When the number of factors in a problem increases beyond this limit, one forgets details and confuses interactions. The result is that one makes significantly more errors. If a model is properly subdivided into components, it is possible to focus one's attention on each component.
Control structure: A good language should provide for well-defined clearly bounded compound statements, such as IF-THEN-ELSE, and at least one repetition statement.
Structure of data: The data structure in a simulation program must form a logical representation of the components of the system being
modelled.
Interactions: Unrestricted communication between program modules through global data blocks leads to increased complexity and confusion within the model. The answer to this problem is to use locally defined data for calculations within modules and a well-defined communication path for transmitting data between modules.
Clear separation between model and experiment: A clear model should
not contain data and code for, for example, collection of statistics
or collection of data with the purpose to prepare a plot. The point
of separation between model and experiment can be raised from a software engineering point of view, but it can also be raised from a
system theory point of view. The last point is based on work of Oren and Zeigler (1979) and will be taken in this thesis.
As will be discussed in this thesis, most continuous simulation languages in use today do not support the software engineering principles mentioned above in full extent. Since construction of a validated simulation model is a
labour-intensive job, reusability of models is an important issue. Language constructs supporting reusability of models are lacking in simulation lan-guages. Notably, there is a need for submodels and for a strict separation of the description of experimental details from the model description. In this thesis the simulation language cosmos is described. The language was
designed to support continuous, discrete, and combined models. In contrast to the continuous simulation languages, the structure of models in cosmos may be variable. This means that the number of differential equations in the model may vary during the simulation experiment. Furthermore,
cos-mos was designed to support the software engineering techniques mentioned before.
There was an additional reason to start the project to design the simula-tion language cosmos. At the Computer Science Department of Wageningen Agricultural University, the Netherlands, a simulation course has been part of the curriculum since early 1970. In that simulation course both contin-uous and discrete simulation are discussed. The reason to do so is that in agriculture, and many other application areas, models are combined. One of the topics students learn in this course is that the type of model to be used depends on the details needed to answer the questions raised by the pur-pose of the simulation study. This means that one produces a continuous, discrete, or combined model of a system depending on the necessary detail in the model. If a combined simulation language is not available, combined models cannot be developed easily. Besides, from an educational point of view, it is not a satisfactory situation to force students to learn two com-pletely different simulation languages. Since the students then will develop the view that continuous and discrete simulation have nothing incommon.
With simulation, virtually any level of detail and complexity can be mod-elled. When the level of detail and the complexity of the model increase, computation time to simulate the model increases with them. The speed of computing facilities becomes a limiting factor. A simulation program that
ties up days of fast computing resources for a single execution run is not a useful design tool. For example, in computer hardware design or in telecom-munications network design, computation of the trajectories will take too long. Since hardware costs are decreasing, multiprocessor computer systems can be affordable for many applications. At present, programming of (mas-sively) parallel computer systems is a task for specialists. Most simulation
users do not have the necessary skills. The ordinary simulation user is not a programmer, but is merely a domain specialist. More user-oriented sim-ulation software must be available to the simsim-ulationist to make (massively) parallel computer systems accessible. An existing simulation language, in this case COSMOS, implemented on an advanced computer system will give a more easy access.
In cosmos, formulation of the model and description of the experiment are independent of the type of the computer used. At present, cosmos is implemented on VAX under the VMS operating system, on personal computer under MS /DOS, and on SUN under SUNOS. In this thesis, the initial impe-tus to implement cosmos on the NCUBE2 multiprocessor computer system is given. The host of the NCUBE is a SUN workstation running under the SUNOS operating system. The communication from the host to the NCUBE2 runs under the VORTEX operating system and cooperation of the nodes is organized by the VERTEX operating system. Since cosmos is implemented as a pre-processor to the c programming language, C has to be available. Running the compiler for the computer system used will generate the nec-essary code at the speed the hardware provides, without any change in the code.
This thesis is organized as follows. In Chapter 2 simulation will be intro-duced. In Chapter 3 a historic overview of simulation languages will be given. Since many simulation languages are on the market, the overview given will be far from complete. The overview will be limited to what I think to be the most important developments. In Chapter 4 a general view of the sim-ulation language cosmos will be presented. To demonstrate the language several examples are given. In Chapter 5 the implementation of cosmos on traditional sequential computers is described. The language has been implemented in the (procedural) programming language C. In Chapter 6 an overview of research in parallel and distributed simulation will be presented. The term "distributed simulation" is reserved for simulation experiments performed on interconnected computer systems, where the computer sys-tems can be at different locations. The adjective "parallel" is connected to a computer system if the interconnected processors, with or without shared
memory, are within one cabinet. The research described in this thesis will be oriented towards software. Since the developed software can run in prin-ciple on both parallel and distributed computer systems, the words parallel and distributed can be used interchangeably. In this thesis I give preference to the adjective "parallel." The adjective "distributed" is used for mod-els described by partial differential equations. Research in so-called parallel or distributed discrete-event simulation has received much attention in the last decade. During the last decade, research in distributed or parallel con-tinuous simulation has been oriented towards special applications, such as solving particular partial differential equations. Therefore, the main topic of
Chapter 6 will be parallel discrete-event simulation. In Chapter 7, ideas to parallelize cosmos will be discussed. The ultimate goal is to implement ex-ecution of cosmos generated programs on a parallel computer system. This chapter, however, gives basic algorithms needed to implement the language. The main point of Chapter 7 will be the description of algorithms developed for parallel continuous and combined continuous and discrete simulation. The developed combined simulation algorithm is based on Time Warp, a well-known parallel discrete-event simulation algorithm. The software that has been developed will be tested with a combined continuous and discrete example. Test model and performance of that model will be studied in
Chapter 2
Simulation
Both in everyday life and in science simulation plays an important role. Many definitions of simulation can be given. Pritsker (1979), for example, gives twenty-two definitions for simulation. The following definition given by Shannon (1975) fits my purpose best:
"Simulation is the process of designing a model of a real system and conducting experiments with this model for the purpose either of understanding the behaviour of the system or of evaluating various strategies (within, the limits imposed by a criterionor set of criteria) for the operation of the system."
In this definition both concepts model and experimenting are included. Zeigler (1976), however, distinguishes between modelling and simulation. Modelling is the process of designing a model and simulation is
experiment-ing with a model. In this thesis simulation includes both modellexperiment-ing and
experimentation with a model.
In the definition for simulation the concept model is present. Cellier (1991) cites the definition given by Minsky:
"A model (M) for a system (S) and an experiment (E) is anything to which E can be applied in order to answer questions about S." There are various kinds of models, for example:
Scale model employed to determine air resistance of a moving car or the resistance of a ship moving in the water.
Road map to be able to find an address in a city.
Analogy model, for example a water analogy to forecast macro-econom-ical developments (Phillips, 1950).
Computer model.
In this thesis the focus is on models that can be given as computer programs. Simulation can be applied in various contexts. To mention a few:
Development of control systems.
Development of mechanical systems (Rieder and Busby, 1986). Weather forecast.
Forecast of crop growth.
Research in crop growth (Penning de Vries and van Laar, 1982). Organization of production processes.
Scheduling of maintenance of aircrafts.
Development of information systems (Sol, 1982) or communication net-works.
Military applications such as battle simulations.
Training of pilots and other members of a crew of an aircraft or space-ship.
Literature research (Hopkins, 1992).
Simulation is applied for several reasons. For example, experimenting with the real system is too costly, too dangerous, impossible, or is not ethical. Computer simulation has demonstrated to be a flexible tool. Therefore, it has replaced mathematical analysis and physical prototyping as the preferred method in many applications. The goal of a simulation study is to solve a problem or to optimize the performance of a real system.
The first phase of a simulation study is to make a model. To be able to model a system quantitatively, knowledge of the scientific discipline the system is based on should be available. In addition to that, preferably, the variables in the system have to be quantifiable. The models employed in the
technology field often are based on physical laws and the variables can be quantified easily. Consequently, technological systems, in general, meet the requirements for quantitative modelling. However, in so-called soft systems most models are based on intuition and such systems have some properties that make a quantitative approach cumbersome or even inadequate. Soft systems are found, for example, in biology, ecology, and sociology. Such sys-tems are classified as ill-defined (Spriet and Vansteenkiste, 1982). Validation of models of technological systems is relatively easy. Validation of models of ill-defined systems is difficult. Models of ill-defined systems, however, are useful, since experimenting with those models provides more insight in the field. The newly acquired knowledge can be applied to formulate more solid models. One has to be careful, however, with extrapolations basedon ex-periments with intuitive models. The techniques discussed in this thesisare applicable to both technological and soft systems.
Karplus (1976) has pictured simulation applications in a spectrum, see
Figure 2.1. Near the white end of the spectrum we find models basedon solid knowledge and with quantifiable variables. At the black end of the spectrum intuitive models can be formulated only.
Each model will have parameters. The values of the parameters depend on physical constants, for example, and the values may vary depending on
the environment the system under study is situated. These parameters, often, can be measured, but sometimes other techniques, such as parameter identification techniques (Spriet and Vansteenkiste, 1982), must be employed to find the values. In stochastic models some of the phenomena will be mimicked by random numbers. For reliable results of the simulation study, the distribution functions of the random numbers have to be chosen based on measurements in the real system and have to be validated carefully. The most important task in a simulation study is to sustain the validity of the model. Especially in stochastic models, a careful design of experiments is essential for reliable results.
A (computer) model is a computer program that describes the behaviour of the system. A model consists of variables, static structure, and instruc-tions that specify the changes of the state of the system. For this thesis the following types of instructions are relevant:
Mathematical equations such as algebraic equations and differential equations.
arouse public opinion gain insigt economic test theories physiological social ecology experimentation with control strategies air pollution hydrological aircraft control prediction for action process control electric circuits performance prediction product design dyna-mics
Figure 2.1: Spectrum of simulation applications (Karplus, 1976) Models of the first category are so-called continuous models. Models of the second category are discrete models or discrete-event models.
2.1
Models
A model of a system imitates, in one way or another, the behaviour of that system. In that respect a model is an abstraction of reality. According to Zeigler (1976) each system has one so-called base model. This base model reacts in exactly the same way as the real system in each experiment. For many systems, for example, so-called ill-defined systems, the base model cannot be formulated because the knowledge of the system is not sufficient. Apart from the base model each system has as many simplified models as one can imagine. Simplified models are only valid under certain experimental conditions. In everyday simulation life, in general, it will be difficult, if not
impossible, to sustain that a model is the base model. Experimentation with simplified models, however, can give satisfying results. Newton's laws, for example, have been applied in the past, and are in use today, to compute the movements of masses. Newton's laws are applied in spite of the fact that theory of general relativity has shown that they give incorrect answers under some circumstances. A model often is not more than a hypothesis. It is not possible to prove that a hypothesis holds. Sooner or later a hypothesis will
black white
be proved to be refuted. In the same way, it is hard, if not impossible, to justify that a model is valid given the experimental conditions. Although difficult, validation of a model is important. A lot of simulation studies were not successful because the model was not validated properly.
Models can be categorized in different ways, see for instance Oren (1979). In this thesis only dynamical models will be considered. In dynamical mod-els, one or more independent variables are present. Time is often the inde-pendent variable or one of the indeinde-pendent variables. One way to categorize models with time as independent variable is based on the way time pro-gresses: continuous-time models versus discrete-time models. Different def-initions are found for time models. According to Oren, in discrete-time models discrete-time is represented by integral numbers. In this thesis I will follow the definition given by Cellier (1979). According to Cellier a discrete-time model is described either by difference equations or by sequences of time events or by a mixture of both. Models made up of difference equa-tions are not discussed in this thesis. Discrete-time models are discrete-event models where the independent variable will change instantaneously and can hold real values. In the following both continuous and discrete models will be discussed.
2.1.1
Continuous Models
In a continuous model, changes of the state are assumed to be continuous. Moreover, the independent variable, often time, is increasing continuously. A continuous model is formed by a system of ordinary differential equations or algebraic equations or both. Some phenomena may be mathematically described by more than one independent variable, for example diffusion pro-cesses such as transport of heat in a conducting medium. Such a system is called a distributed system. Dynamic behaviour of a distributed sys-tem is described with the help of partial differential equations. Vemuri and Karplus (1981) is a good reference for more details about distributed sys-tems and for numerical techniques to solve partial differential equations. General-purpose simulation languages seldom provide for tools to describe such models. Special-purpose languages have been developed, such as ELL-PACK (Houstis, 1977) and FORSIM VI (Carver, 1979) to mention a few. To be able to solve a partial differential equation with the help of a general-purpose simulation language, the partial differential equation has to be approximated by a system of ordinary differential equations ("method of lines"). Most commonly, the approximation is accomplished by segmentation of thegiven
system (Vemuri and Karplus, 1981). In Section 4.7.2 an example of a system described by a partial differential equation will be given.
Experimenting with continuous models evolved from control theory. To be able to test or adjust the control of a process, it is necessary to model the process to be controlled. Sometimes the real control unit is coupled to the model, but it is also possible to model the control unit. Initially a model that was an electronic analogy of the real system was composed with the help of a soldering iron. From that practice the generally applicable analog computer evolved. Nowadays analog computers have almost completely been replaced by general-purpose digital computers. Only in some real-time ap-plications special-purpose analog and digital hardware is employed (Spriet and Vansteenkiste, 1982). Examples are AD10 (Gilbert and Howe, 1978) and AD100 (van Schieveen, 1986) from Applied Dynamics International and SIMSTAR 2000 (Landauer, 1983) from Electronic Associates Incorporated.
Continuous simulation, nowadays, is applied in various fields. Continuous simulation is applied mainly in technology, but also in research in economi-cal (Bruckmann and Fleissner, 1989). social (Sushil and John, 1990; Darling and Richardson, 1990), physiological (among others medical applications) (Rideout, 1991), industrial (Forrester, 1961), biological and ecological sys-tems (de Wit and Goudriaan, 1974; Forrester, 1971). Computer modelling and simulation is important in research in environmental sciences (Farmer and Rycroft, 1981).
The system of differential equations describing the dynamic behaviour of the system has to be solved. Although some systems of differential equations can be solved by analytical methods, in simulation, differential equations are solved by numerical integration algorithms. The differential equations may be specified explicitly or implicitly. Numerical ordinary differential equations solvers can be used to solve explicit differential equations. However, for many physical systems, it is much easier to formulate the differential equations in an implicit fashion. To solve implicit differential equations with the help of numerical differential equation solvers, the equation must be transformed into an explicit system of equations or iterative techniques must be applied. This is the approach taken in this thesis. Alternatively, more efficient so-called differential algebraic equation solvers or DAE solvers can be applied (Brenan et al., 1989).
Numerical problems arise where the dynamic behaviour of the model is discontinuous or the system of differential equations is stiff. Cellier (1979), for example, describes a model of a system to control the motion of a train
fifth order system and 12 conditions describing all possible discontinuities. If the model is simulated by a variable-step integration algorithm without special attention to discontinuities, execution time is a multiple compared with execution using software that pays special attention to discontinuities. In Cellier's example the factor was over forty. In a numerical integration step including a discontinuity, a relatively large number of failed steps are needed
to be able to compute the state variables of the model according to the
specified accuracy. This is because computation of the step size in a variable-step integration algorithm is based on continuous behaviour. Therefore, the estimation for the step size of the numerical integration algorithm is far from reliable when a discontinuity is present in a step. What is even more
important, however, is that Cellier (1979) proved that the results of the
simulation of the model of control of the motion of a train with software that treats discontinuities incorrectly are completely wrong.
If the behaviour of a model is continuous apart from a relatively small number of discontinuities, in simulation terminology, the model is treated as continuous. Discontinuities can be part of the system under study, or they can arise as a result of discontinuities in input signals. In addition, discontinuities can arise from simplification of the model. The bounce of a ball off a floor, for example, is a continuous phenomenon. The equations involved in the bounce of the ball are complex. A simplified model results if, at the moment of the bounce, the vertical component of the velocity is reduced by a factor and the direction of the vertical velocity is changed. The simplified model is more clear and it takes less time to compute a solution of the model equations. How to deal with discontinuities will be discussed in Sections 4.3.2 and 5.1.2.
As illustrated before, discontinuities will cause numerical problems if they are not treated correctly. So-called stiff systems of differential equa-tions create similar problems. A system of stiff differential equaequa-tions can be solved by numerical integration algorithms with a large stability region (Gear, 1971). An integration algorithm with a small stability region will spend much time to solve the system of stiff equations. This is caused by the limited size of the integration step. Furthermore, one cannot rely on the solution of a nonstiff system solver when it is applied to a stiff system of differential equations.
2.1.2
Discrete Models
In discrete models state changes are discrete and the independent variable, here solely time, conceptually is continuous. While experimenting with dis-crete models, the independent variable will disdis-cretely jump from one state to next state. State changes are so-called events and the moment an event occurs is known as event time. An alternative name for discrete model is discrete-event model. Application of discrete models will be found in
man-agement sciences or operations research. The work in an assembly line, or scheduling maintenance of airplanes or busses can be studied through discrete-event models, see for instance (Sierenberg and Achterberg, 1993; Pegden, 1982). Other examples can be found in automobile plants, steel foundries, telephone exchanges, ticket reservation systems, military applica-tions, or transport systems to mention a few. An example of application of discrete-event models in Biology is presented by Hogeweg and Hesper(1986). Hofstede (1992) indicates the usefulness of simulation for development of de-cision support systems.
In the systems described above events occur. Examples of events are arrival of a customer at a counter in the post office or arrival of a car at a gas station. It is, however, also possible to represent a system that behaves continuously by a discrete (event) model. In discrete modelsthe events and the time at which an event takes place are described. The events have to be grouped in a certain order. To describe discrete-event models, four world views can be employed: next event, activity scanning, process interaction, and transaction flow.
Next event
In the next-event world view the events will be grouped, based on the
time an event occurs. This means that all events that take place at the same moment in a model will be grouped in one programming unit such as procedure or subroutine. Since activities of all the components at the same event-time will be grouped into one routine, the modeller must have an overview of the complete system. For complex systems, however, to have an overview of the complete system is hard for a human being.
Activity scanning
In the activity-scanning world view, all kinds of activities that occur in a system will be described including the conditionsthat have to be fulfilled before such an activity can take place. This way of describing a
discrete-event model is close to a checklist of all activities in a system. Process interaction
In the process-interaction world view, events will be organized around the components that are responsible for the activities at the event. In this world view, one software unit (a process) becomesa scenario of one component of the real system. While designing a model, the modeller needs only to consider that particular component and interactions of that component with other parts of the system. A process-interaction model will be a natural replacement of the real system.
Transaction flow
The transaction-flow world view takes also a scenario view of the sys-tem. In transaction flow temporary objects will be directed through a network of simulation elements. In a model for a gas station, for example, cars arrive, occupy the gas pump, and after a while visit the cashier, and will leave the system. When the car needs a facility with a limited capacity, the gas pump or the cashier in this example, and this capacity is not sufficient, the car will be placed in a queue automatically. For simple queueing problems transaction flow models are relatively simple, but for more complex systems a transaction flow
model is far from simple, and, more importantly, cannot be adjusted to even minor changes.
In discrete-event models, some phenomena will often be represented by stochastic variables. Examples are service time of a customer or arrival time of a car at the gas station. This means that discrete-event models, often, are nondeterministic. Experiments with such models have to be designed carefully.
2.1.3
Combined Models
Continuous and discrete simulation have developed separately. The appli-cation areas do not have much in common. Continuous methodology and discrete simulation methodology, however, have common ground. The sepa-ration suggests there are systems that can only be represented by continuous models and there are systems that can only be represented by discrete
mod-els. That is not true. It is possible to makea discrete model of a system with continuous behaviour, and one may represent a system with discrete behaviour in a continuous model. What type of model will be used depends
on the level of detail needed in the model. In Industrial Dynamics (Forrester, 1961), for example, one studies problems of management science. In general, a model built to study problems in management science is represented by discrete-event models. In the world view of Industrial Dynamics, however, the system is studied at a higher level of aggregation, where, for example, the status of an individual customer order is not of interest. Filling of a car at a gas station can be described with the help of a differential equation. Modellers developing discrete-event models are not interested in the level of detail of the filling process. The filling process then is represented by a number drawn from a statistical density function.
In a complex system one may think of representing some real components by discrete submodels and other components by continuous submodels. The
choice for one or the other model type depends on the level of detail in
accordance with the simulation objectives. This can be illustrated by the following example (Cellier and Blitz, 1976).
In traffic control, it is possible to distinguish between the following
mod-els:
Macroscopic model
The single vehicle is not considered but only traffic flow with accom-panying densities. The result is a partial differential equation. The macroscopic model is continuous. With the help of this model a global view of the system can be studied. Waiting periods of vehicles and lengths of queues, for example, cannot be computed.
Microscopic model
Vehicles enter the system considered, travel through it from one cor-ner to the next one with queueing situations in front of traffic lights. Dynamic behaviour of the vehicles and the drivers are not included in the model. This leads to a discrete-event model. Waiting periods of vehicles and length of queues can be computed with a microscopic model. Since dynamic behaviour of a vehicle and its driver is not in-cluded in the model, reaction-time of vehicle and driver are neglected or are represented simplified. If reaction-time of vehicle and driver are important for the result of the study, the model is inadequate.
Submicroscopic model
Dynamics of the vehicles, and possibly dynamics of the driver, are included in the model. This leads to a combined model.
The macroscopic, microscopic, and submicroscopic models mimic the same physical system. The different modelling techniques have been
se-lected to suit the objectives of the simulation study. The example given above illustrates that in certain situations a combined model can serve the purposes of the simulation study better than a discrete or continuous model. Another illustration is an elevator system, with dynamic behaviour of the car included in the model. Including the dynamic behaviour can lead to more accurate model, since one can expect that the time the car needs
to start or to stop depends on the total weight of persons in the elevator.
Siikonen (1993) reports about such a system for elevator traffic simulation. Fahrland (1970) presents several other examples of systems that may lead to combined models. The traffic control example illustrates clearly that the type of model does not depend on the type of system. So, it is possiblethat the modeller will work with both continuous and discrete (sub)models. This evokes the need for combined continuous and discrete simulation languages.
2.2
Experiments
Simulation developed from practice, and for a long time a theoretical foun-dation was missing. Since Zeigler's book (1976) thissituation has changed. The concept of experimental frame (Zeigler, 1976; Zeigler,1984; Elzas, 1984) is most important for the work described in this thesis. According to Zeigler, the experimental frame characterizes a limited set of circumstances under which the real system is to be observed or experimented with. Validity of a model of a real system can only be studied in relation to the experimental
frame. Both real system and model have to be observed under the same
experimental conditions. Elements of the experimental frame are, among others, initial condition of the model, the set of output variables to be stud-ied, and statistical functions of variables to be collected. Oren and Zeigler (1979) have illustrated that model and experiment description have to be different parts of a simulation program. A model of a grocery store, for ex-ample, can be employed to study the system to measure client satisfaction during rush hours. The same model can be employed to measure utilization of the cashier during store opening. In the given example the experimen-tal frame will differ, and among others, statistics have to be gathered on different variables. If in the simulation program, model and experiment descriptions are not separated, the model part of the program has to be
adapted, although in both experiments the model is the same.
Oren and Zeigler raised the point of separation of model and experiment description based on simulation methodology. This point is supported by the software engineering point of view. To make a model understandable, the model description must represent the real system and should not rep-resent activities that are not prep-resent in the real system, such as collection of statistics. When in real life, for example, statistics have to be collected of the time spent by the cashier on making the bill for customers, the task will be given to somebody else. If the cashier has to do that task, it will disturb performance of the cashier too much. If one has included the activi-ties necessary for collection of the statistics in the model, the model will be less understandable compared with a model describing the daily procedures of the cashier only. Moreover, to be able to reuse a model, as submodel in another larger model, for example, it has to be without experimental details, since experimental conditions will most likely vary in each instance of its use.
In Chapter 4 the simulation language cosmos is discussed. In cosmos the term experimental frame is borrowed from Zeigler (1976; 1984). An experimental frame describes the conditions under which the model has to be studied. In addition to that, in cosmos the experimental frame consists of so-called run-control commands, such as the numerical integration algorithm to be applied to solve the differential equations. In the definition given by Zeigler, an experimental frame does not limit the number of experiments, it just limits the set of circumstances. Since cOSmos is not an abstract but a real vehicle to experiment with models, the number of runs must be limited. In one simulation run, output trajectories of a model will be computed over a period defined by the initial situation to a condition to finish the simulation has been fulfilled.
Chapter 3
Simulation Languages
According to Webster's Seventh New Collegiate Dictionary a language is defined as:
"a systematic means of communicating ideas or feelings by the use of conventionalized signs, gestures, marks, or especially articulate vocal sound" and
"the suggestion by objects, actions, or conditions of asso-ciated ideas or feelings."
In this definition is included the formulation of ideas as a result of reasoning. Computer languages and in particular simulation languages will be employed to represent thought about complex systems. This means that a simulation language is also a cognitive device to structure perception, representation, and reasoning about classes of problems. There are intimate relationships between thought and language, and language and methodology. Kreutzer
(1986) writes:
"Simplicity, expressiveness, flexibility, and efficiency of modelling methods are at least partly conflicting goals between which suit-able tradeoffs have to be made."
Most probably the conflicting goals and the different domains of application are the reason why there are so many simulation languages, and program-ming languages, on the market. In this chapter, an overview of the simula-tion languages is given. I do not have the intensimula-tion to mensimula-tion each existing simulation language. I will give an overview of the classes of languages and will mention some languages representing a class.
19
Graphical representations, such as Petri nets and icon-based systems, have found wide application in both continuous and discrete simulation ap-plications. Advantages of graphical representations are that structural
con-nectivity and symmetry are emphasized and visualized. Things that are
conceptually related appear closely together. Such graphical systems do not require any programming skill. For some people it seems to be easier to work with graphical representations than working with a nongraphical language, which is more abstract. In icon-based systems a model is built using standard icons that are available on the screen. Provided that the options available
fit the needs, modelling with such a system is quite comfortable. Many
users, however, have the opinion that the icons available are not sufficient and the user will be forced to "fool the language" to have the model behave as he wants. The main disadvantage of graphical representations is that they are not compact enough for more complex structures. Current hard-ware supports zooming techniques. Zooming can solve the above mentioned problem only partly, since the overall view will be lost easily. Icon-based systems are most often applicable in one or a few domains. Cognitive psy-chological research has shown that graphical languages can be learned more quickly and are better suited for novice and intermittent users. Engineers are trained to think logically instead of visually. Therefore, engineers will prefer a procedural language. Products based on a procedural language take longer to learn but offer greater flexibility in building models of a real system (Shneiderman, 1987). Computer simulation, nowadays, is applied by both people with and without a training in Computer Science. I can imagine that some people prefer to employ graphical tools, since they are then freed from learning the syntax of a language. Because of their larger flexibility I have a strong preference for tools that apply generally; therefore, nongraphical representations will be discussed mainly.
Simulation programs can be formulated with the help of general-purpose programming languages, such as FORTRAN and PASCAL, or with the help of special-purpose languages, so-called simulation languages. Programming of a model in a general-purpose programming language has some advantages, such as:
Often the researcher knows the general-purpose programming language, so there is no need to learn a new language especially for the task. If the language of choice is a well-known programming language, the resulting computer program is portable to other computer systems.
A well-known programming language is widely used, so there will be well-engineered compilers and run-time systems available. The result-ing computer program will execute at optimal speed and accuracy. Programming of a model in a simulation language has the following advan-tages:
The structure of the model can be represented closer to the structure of the system under study if the simulation language is adequately chosen.
The language is tailored to the specific application area, so the lan-guage is closer to the "lanlan-guage" the researcher understands.
For the modeller, it is not necessary to pay attention to implementa-tion details, such as realizaimplementa-tion of certain typically simulaimplementa-tion oriented structures, such as event-list and numerical integration algorithm. De-scription of the collection of data and representation of the results of the simulation study is more user oriented in a simulation language. It is easier to concentrate on the (modelling) problem.
The resulting program will be a documentation of the modelalso un-derstood by nonspecialists.
Since the language is at a higher level than a general-purpose program-ming language, the resulting program will be smaller, and because of that more comprehensible.
Simulation is a research tool. Often the researcher is not a professional
programmer. A language akin to the research field makes it more
convenient to program.
Depending on the problem and the local situation,one will choose a simu-ration language or a general-purpose programming language. There are a lot of simulation languages on the market. A simulation language can be based on another programming language, often a general-purpose language. Then a library of subroutines or procedures is developed. Routines of the library can be linked to a simulation program written in the same general-purpose programming language. In this way, the designer does not define a new lan-guage, but he produces a so-called "simulation package." An advantage of a package is that the user does not need to master a new language, and there
is no need to construct a compiler for the "new language." Expressiveness of a package, however, is limited.
As was discussed in Chapter 2, traditionally, the simulation field falls into two categories: continuous and discrete. The same difference is evident in the computer tools employed to specify simulation programs. Traditionally, there were simulation languages on the market specifically oriented towards experimenting with continuous models, so-called continuous simulation lan-guages, and discrete simulation lanlan-guages, oriented towards experimenting with discrete-event models. Later on, tools for describing combined contin-uous and discrete models have come available.
3.1
Continuous Simulation Languages
There are three groups of continuous simulation languages: Explicit block languages.
Implicit block languages. Descriptive languages.
In the sequel these categories will be discussed. The categories are listed in chronological order of development. Explicit block languages were developed in the fifties, however, recently developed languages are still in use today. In these languages, it is not possible to formulate an arithmetic expression, model formulation is far from the mathematical description of the system. The first implicit block languages were developed during the sixties. The model presented in the language is closer to the mathematical model since expressions can be used. Provisions for discontinuities in a model are, in general, not available in the implicit block languages. Descriptive languages are influenced by the software engineering methodology, and description of discontinuities and handling of discontinuities at run time are provided for.
3.1.1
Explicit Block Languages
As discussed in Chapter 2, continuous simulation has evolved fromcontrol theory. From the practice in control theory the analog computer evolved. The early simulation languages provide a complement of functional elements similar to those of the analog computer. These languages model the elements and organization of analog computers, and provide for numerical routines
that are equivalent to standard components of an analog computer such
as integrator, summer, multiplier, and function generator. As the analog computer patchboard electrically links analog computing elements, an early continuous simulation language interconnects the numerical routines. The early simulation languages included the peculiar features of analog comput-ers. For example, ASTRAL, developed in 1958 incorporated the gain and sign reversal of amplifiers and scale factors needed for programming ana-log computers, but not essential to digital computer programming. Selfridge (Giloi, 1975) was the first to propose a digital simulation language. Selfridge implemented a language in 1955 (Brennan, 1968). DEPI is another early con-tinuous simulation language. Elzas (1975) reports that DEPIwas developed by Lesh and Curl for an IBM 704 digital computer at the California Institute of Technology in 1959. Since in the early languages each programming block represents a standard analog computer operation, these languages became known as so-called explicit block languages.
Next trend in simulation languages was to eliminate those aspects pecu-liar to analog computer simulation, such as scaling and inversion of sign of an amplifier. The block structure, however, was still apparent. In the early languages, each block has a number. An output, indicated by the number of the block, can be used as an input to another block. To be able tocompute, for example, the expression: xy+yz+xz, this expression must be formed by input xy, yz, and sz computed by other blocks into asummer. Each block has a limited number of inputs. To be able to compute the given expression a summer with three inputs is needed. If the simulation language provides for summer blocks with only two inputs, the modeller is forced to use two summers to compute the value of the given expression.
Explicit block languages have several drawbacks:
In general, the number of inputs to a block is limited. As was illus-trated before, more blocks are needed in case the number of needed
inputs is larger than the block provides. The restricted number of
inputs complicates formulation of the model more than strictly neces-sary.
In case the number of blocks needed to model a system is large, the program turns out to be too complex, caused by linking of too many blocks. Models up to approximately 20 blocks are readable. Larger models are hard to be understood by man.
subsystems, maintenance of models represented in these languages is difficult.
Well-known examples of simulation languages of described type are MIDAS (Peterson et al., 1964), developed in 1963, and PACTOLUS (Brennan and Sano, 1964), developed in 1964, and 1130/c5mP (Brennan and Silberberg, 1967). Compared with the predecessors, the format of MIDAS is more compre-hensible and MIDAS permits, in addition to block numbers, symbolic names for blocks. The mythological names Pactolus and Midas reflect nicely the competition between the languages. Pactolus is the name of a river in Asia Minor. There was a curse laid on King Midas such that everything what he touches, including food, changed into gold. King Midas washed himself in this river to become free from this curse.
Explicit block languages became popular mainly because these languages could be implemented on small computer systems. Compilers for explicit block languages are relatively simple, and compilation of a program is fast compared with compilers for more complex languages. A more recently im-plemented explicit block simulation language, THTsim (van Dixhoorn, 1982), was originally developed to run on a PDP11 computer. The PDP11 computer was an instrumentation computer, and provided for analog input and output channels. It was, for example, relatively easy to couple an analog plotting device to the PDP11. Later on, THTSIM has been renamed to TUTSIM and became quite popular on personal computers (Meerman, 1981; Meerman,
1983). Description and dealing with discontinuities are not implemented in TUTSIM. In another example of an explicit block language PSI (van den Bosch, 1981), discontinuities are included (van den Bosch and Visser, 1990). In PSI one gives names to the blocks, in TUTSIM however, blocks have to be
referenced by numbers.
To give some idea how a model is specified in an explicit block language an example is given. The example describes the population of predator and prey. One of the models employed in the population dynamics is the so-called Lotka-Volterra differential equation. The mathematical model is:
= fp
bp2- cpr
(3.1)dt
dr
= gr
dpr (3.2)dt
In (3.1) and (3.2) p and r represent the number of prey specimen and the
number of predator specimen respectively; f, b, c, d, and g are
parame-ters that influence the relationships between prey and predator. Figure 3.1
INT, 3,4,7 INT, 8,9 CAI, 1 GAI, -5 MUL, 1,1 MUL, 1,2 GAI, -6 GAI, -2 GAI, 6 where INT is an integrator GAI is a constant MUL is a multiplier
Figure 3.1: Prey-Predator model in TUTSIM
shows the TUTSIM code for this model. If one does not know the TUTSIM language, the code cannot be understood. The code in the figure illustrates that an explicit block simulation language cannot be employed for model documentation purposes. In Figure 3.2 the same model is represented using symbols in use for analog computer elements. This block diagram represents the relations more clearly, although the symbols used have to be known.
Additionally TUTSIM provides for the model specification in the so-called bond graph notation (Karnopp and Rosenberg, 1975). The bond graph
method has been developed to formulate easily dynamic models in special-ized physical and engineering fields of mechanics, electromechanics, electro-magnetism, physical transport phenomena, chemical reaction kinetics, and many others. The method is attractive to control engineers in particular. The simulation engine of TUTSIM is poor compared to other simulation lan-guages, such as ACSL (Cellier, 1991). CAMAS is a new bond graph modelling system (Broenink, 1990) that provides fora better simulation engine. CAMAS runs on SUN workstations and it has a graphical user interface.
In this thesis, PSI has been chosen to represent the category of explicit block languages that name the blocks in the model. The prey-predator model is given in PSI in Figure 3.3. The PSI program consists of a structure
defi-Figure 3.2: Block diagram for the program in figure 3.1
nition and a parameter definition part. Besides, among others, run-control information has to be specified. In contrast to TUTSIM, in PSI one can give gains for the inputs of a summer and an integrator in the parameter defini-tion part. So there is no need to use GAI blocks in PSI. For the integrator one has to specify the initial value. Since the number of parameters of a block is limited to three, it is not possible to have three inputs as derivative to the integrator block with a gain different from the default value one. Since the derivative for prey consists of three outputs of other blocks, and the gain is different from one, an additional summer is needed. The additional summer
is specified on the first line in the structure. DPREY is the name of the
block representing the derivative of the prey population. SUM indicates this block as a summer. The inputs of DPREY follow the SUM indication on the first line of the structure in Figure 3.3. Since the derivative of the predator consists of a sum of two factors, these factors can be inputs to the integra-tor that solves the predaintegra-tor equation. An additional summer to compute DPRED is not needed. The second and third lines specify integrators with their respective inputs. The fourth and fifth line define multipliers to
Structure:
DPREY, SUM, PREY, KWAD, PROD PREY, INT, DPREY
PRED, INT, PRED, PROD KWAD, MUL, PREY, PREY PROD, MUL, PREY, PRED
Parameters:
DPREY, f, -b, -c PREY, ip, DPREY PRED, ir, -g, d
where:
INT = Integrator SUM = summer MUL = Multiplier ip = Initial value for prey ir = Initial value for predator.
Remark: f, b, c, g, d, ip, and ir have to be numbers Figure 3.3: Prey-Predator model in PSI
In the parameter definition part numbers must be given for the initial values. The symbols of the coefficients given in the mathematical model (3.1) and (3.2) are used in the figure. In a real program given to the PSI translator,
one has to specify numerical values instead.
3.1.2
Implicit Block Languages
In 1964 language designers started to combine the analog block modelling and the conventional digital programming. Rudimentary blocks, such as summer, multiplier, and divider, are not present in the generation of sim-ulation languages that were developed at that time. Those blocks are not needed anymore, since the modeller can use operators, such as addition, multiplication, and division, instead. In the next generation of continuous simulation languages, however, the block structure is still apparent. There-fore, these languages became known as implicit block languages. Each block
TITLE PREY-PREDATOR LOTKA-VOLTERRA
PREY = INTGRL(PI,F*PREY-B*PREY*PREY-C*PREY*PRED) PRED = INTGRL(RI,-G*PRED+D*PREY*PRED)
INCON PI=0.5,RI=0.5
PARAM F=0.1732,B=0.0577,C=0.0867,D=0.1640,G=0.2310 TIMER FINTIM = 100.,OUTDEL = 1.0
METHOD RKS OUTPUT PREY, PREP END
STOP
END JOB
where:
INTGRL Integrator operator
PI, PRInitial value for prey and pred respectively
PREY Number of prey specimen PRED Number of predator specimen
F, B, C, G,and D Coefficients used in (3.1) and 0.2)
FINTIM specifies the stop condition of the run
OUTDEL specifies the communication interval for preparation of a plot
METHOD RKSspecifies the integration method used( RICS is short for Runge-Kutta-Siropson
Figure 3.4: Prey-Predator model inCSMP
is implemented as a function and can be used in an expression such as a function call in general-purpose programming languages. Inputs to func-tional blocks can be given at the place of the formal input parameters of the function declaration. Most implicit block simulation languages are based on a general-purpose programming language. Often, FORTRAN has been
chosen for that purpose. Since in most general-purpose programming lan-guages a formal parameter can be substituted by a complexexpression, the number of inputs to a functional block is not limited as is the case in the explicit block languages In Figure 3.4 the Lotka-Volterra model describing the prey-predator system is given in CSMP,one of the languages of this class.
Compared with the model in an explicit block language, see Figure 3.1 and 3.3, the code is more akin to the mathematical model.
own engineering laboratories (Syn and Linebarger, 1966). DSL/90 has be-come available in 1965 and is based on the FORTRAN language. The language has been implemented as a pre-processor to FORTRAN and the format of the statements was close to that language. Another early example of an implicit block language is MIMIC, which began as a second generation version of MI-DAS. In 1967 IBM came on the market with S/360 CSMP (Speckhart and Green, 1976). CSMP was followed by CSMP III with some new features such as additional output versatility, several new functional blocks and a more user-friendly array form of the INTGRL function. At present, CSMP and CSMP III are not supported by IBM anymore. These languages have been succeeded by DSL/VS (Syn et al., 1985).
During the sixties many continuous simulation languages of the implicit block language category came on the market. The Society for Computer Sim-ulation International (formerly SimSim-ulation Councils Incorporated), a techni-cal society devoted to the field of simulation, has published a standard of the so-called CSSL languages (Strauss, 1967). CSSL stands for Continuous System Simulation Language. In the standard desirable features and overall struc-ture of a continuous simulation language have been defined. Well-known languages according to the CSSL standard, in use today, are ACSL, Advanced Continuous Simulation Language (Mitchell and Gauthier, 1976; Mitchell and Gauthier Associates, 1987), and CSSL IV (Nilson, 1984). Besides ACSL and CSSL IV, Xerox Data Systems has developed the si..1 language as a successor of SLANG. SIA. (and SLANG) has been implemented only on computers manu-factured by Xerox Data Systems. At the time Xerox Data Systems stopped producing computers, the sL1 language vanished from the market. Both ACSL and CSSL IV have been implemented as a pre-processor to FORTRAN, and have been implemented on various computer types. ACSL, for example, has been implemented on mainframe computers and on personal computers. DESIRE (Korn, 1989) has been designed for maximum interactivity and for execution speed. The model equations, therefore, are microcompiled into threaded code. Interestingly, the compilation takes place when the simula-tion starts. The price to be paid for the fast execusimula-tion of a simulasimula-tion is a reduction in programming comfort (for example model equations have to be given in computational order), program reliability (no compile-time checks),
and program robustness (run-time checks) (Cellier, 1991).
In a model, usually, there are computations to be executed at the
be-ginning and the end of each run. For example, certain parameters of a
model might be considered basic; secondary parameters and initial condi-tions are often expressed as funccondi-tions of the basic parameters. Evaluation
