### 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

1### Introduction

2 Simulation 9.1 Models 2.1.1 Continuous Models 2.1.2 Discrete Models 2.1.3 Combined Models 2.2 Experiments### 3 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}

_{187}

8.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

_{205}

9.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

_{217}

### Author Index

_{237}

### Index

_{241}

### Samenvatting

_{253}

### Curriculum Vitae

_{259}

### Preface

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 in_{common.}

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 possible_{that}
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) this_{situation 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 model_{also }
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