Modeling and Simulation Course

by Vincent E. Asor, PhD Auxiliary materials

About this document Comments to the course on Modeling and Simulation (M&S)
This is a complementary document with comments on the slides included in the presentation "simcourse.ppt". Before using the slides and the below material in your simulation course, take into account the following. Obviously, it is supposed that you have certain experience in modeling and simulation, and perhaps you already are delivering similar courses. The present course slides and comments may help you in the task. If you are registered user of the slides, feel free to modify them, add new material or withdraw some topics. Remember that neither the slides nor the below text is the text-book for the course. Those are merely figures, general ideas and corresponding comments. I suggest that you do not pass the below text (except the course program) to your students. This is an auxiliary material for the teacher use, not for the students. The course is designed as the basic course on M&S. You perfectly know how wide is the topic, and how rapidly the methodology and software of M&S growths. It is hardly possible to treat all what should be said about M&S in one basic course. This slide set is used at the School of Engineering, Universidad Panamericana, Mexico City. The course duration is one semester (17 weeks), three hour per week. You must adapt the material to the specifications of your course. It is common that the teachers, in particular in the M&S field design their course to what they know and do best, and sometimes limit the course to a particular software or a specific topics (like discrete simulation, Monte-Carlo or even time series processing). The present course is an attempt to include as many basic ideas as possible. Some topics are omitted, sometimes intentionally, but mainly because of the physical limitation of the course (like variance reduction, finite element method, applications of some standard software and virtual reality). Software. This is NOT a course on the use of M&S software packages. Most of the known software packages that claim to be "easy and friendly" are equipped with manuals of several hundred of pages each, and would need a whole course with hundreds of exercises to dominate the package. Other important question is the licensing. What a student, who passed the course can do in M&S if he has no software he can legally use in her/his research or professional work? So, the use of expensive fully functional packages in such a course is of little usefulness for the students. Some software packages have free student versions (like GPSS or Stella, Arena) that you can use. Of course you must check the availability of such copies, their limitations and possibilities of upgrades. In this course we use such version to teach the ideas of GPSS and Stella. Other exercises and general simulation ideas are based on the use of the PSM++ Simulation System. PSM++ is a general purpose, well integrated system that includes continuous (ODE, Signal-flow, Bond-graphs), discrete (queuing, discrete events) and combined simulation. You can use PSM++ slides in your classes, or ignore the related slides as you wish. PSM++ is a low cost software, that can be acquired with discount for the users of this material. The PSM++ summary and demo can be found on http://www.raczynski.com/pn/pn.htm

Other package you can use for discrete simulation is QMS (Queuing Model Simulator), http://www.raczynski.com/pn/qms.htm . The demo version is free, and it permits to run small models. Note that this demo includes the complete QMS manual, which can be useful as an auxiliary text. Text books. In my opinion, we have no good text books for M&S basic course at all. Combining some available publications you can perhaps complete the necessary course text. Try to avoid books which are focused on one software tool only, or one particular M&S topic. I suggest you use my Simulation Encyclopedia available from http://www.raczynski.com/pn/encyk.htm . As the price of the download is as low as US$10, you may ask your students do acquire it. At the end of the slide set you will find a lot of other references (books, articles), which may help you also. The slides should be treated as a working material. They are not edited in an "attractive" format, some of them show scanned figures. Few slides have a background color or design. Note that in some slides animation is used. It is supposed that you are quite familiar with the use of MS PowerPoint presentations and with the use of animation. You should clearly explain to your students that this set of slides is NOT any complete text of the course. Those are main ideas and figures only. In the learning process, the student must use text books and other references according to your indications. The present auxiliary text is for your use rather than for the students. The section 7 (Advanced topics) is optional in a basic simulation course. You may include it to the course, depending on the level of student preparation and to the course duration. Note that the last section (7.4.1. Differntial Inclusions - a case study) is described here in the form of a complete article, with figures.

Modeling and Simulation

Course program

1. Introduction 1.1. Definition of computer simulation 1.2. Importance of modeling and simulation in business and manufacturing system management 1.3. Modeling and simulation as complementary tasks 1.4. Computer simulation as an interdisciplinary tool 1.5. Examples of application in various fields of science, technology and life 2. General concepts of modeling 2.1. Continuous and discrete models and simulation 2.2. The model: components, descriptive variables and interaction rules 2.3. The concept of model state 2.4. Descriptive variables: input, state, output, model parameters, state transition and output functions 2.5. Experimental frames and simplified models 2.6. Model validation, verification and credibility 2.7. Classification of dynamic systems 3. Chronology of M&S methods and software development 4. Discrete simulation 4.1. Probability, distributions and random numbers generation 4.2. Simulation "Monte Carlo" 4.3. Object- and agent-oriented simulation. Model time, event messages and event queue 4.4. CSL 4.5. GPSS 4.6. PSM++ 4.7. The "Three phases" strategy in event simulation 4.8. Object-oriented simulation - ideas of Simula67 5. Continuous simulation 5.1. Analog machines 5.2. Possible continuous model representations: ODE, Signal Flow, Bond Graphs 5.3. Examples of continuous ODE models 5.3.1. Mass in movement 5.3.2. Car suspension 5.3.3. Stirred tank 5.4. Numerical methods for ODEs 5.5. Direct coding of a continuous simulation program 5.6. Exercise for ODE simulation : car suspension 5.7. Signal Flow Graphs (SGF) 5.7.1. Nodes and links, SFG and block diagrams 5.7.2. Examples: an automatic control system, an electric circuit 5.7.3. Eliminating equations and coding from the simulation task

5.7.4. Signal flow module of PSM++ - link types 5.7.5. Signal flow module of PSM++ - an exercise 5.8. Bond graphs 5.8.1. The bond and the related variables 5.8.2. Node and bond types, causality 5.8.3. Examples: application to mechanical systems 5.8.4. Exercises 6. System Dynamics (SD) 6.1. System thinking. Definition of SD by Jay Forrester 6.2. Basic concepts 6.3. SD software tools 6.4. Examples: business dynamics, ecology 7. Advanced topics 7.1. Distributed simulation 7.2. High Level Architecture 7.3. Discrete Event Specification Formalism (DEVS) 7.4. Other possible tools: Differential Inclusions (DIs) in modeling and simulation 7.4.1. Advanced case study: Stock market simulation using DIs 7. References

The slides
Comments and auxiliary text
Identify the slides by the slide ID on the upper right corner of each slide, and not by the slide number (bottom right). In the following there are some comments and explanations for the slides, each section starting with the slide ID.
1. This is a copy of a transparency stolen from Dr. Ralph Huntsinger, past President of The Society for Modeling and Simulation in San Diego. Ralph always starts his presentation with this transparency. Obviously he is right: SIMULATION is FUN!! As a simulationist you must learn how the rice grows, how shoes are fabricated, how a plane flies, how galaxies are formed, how molecules interact, how social structures grow, how an epidemic propagates and many other things. This interdisciplinary aspect makes modeling and simulation so fascinating. 1A. Those are merely a few suggested references. A bigger list of references is given at the end of the presentation. 1.1. Definitions computer simulation. There are many definitions of computer simulation. For example, A. Alan B. Pritsker defines it as the representation of the dynamic behavior of the by moving it from state to state in accordance with well-defined operating rules (Pritsker, Introduction to Simulation and SLAMII, John Wiley and Sons, 1984). Many authors define simulation in the similar way, with emphasis to the changes of the modeled system state in time. Bernard P. Zeigler in Theory of Modeling and Simulation, John Wiley and Sons, 1976 writes: We can therefore define simulation as the technique of solving problems by the observation of the performance, over the time, of a dynamic model of the system. In somewhat more general way, we can define the modeling as the relation between real systems and models, and simulation as the relation between models and computers. In the article of A.A.B. Pritsker, Compilation of definitions of simulation, SIMULATION, August 1979, pp.61-63, you can find about 30 different definitions of computer simulation. Most of the authors tend to define simulation in terms of the software they develop or use. However, the common approach is that relating simulation with the changes of the model state in time. 1.2. Importance of modeling and simulation in business and manufacturing system management. The figure is shown due to Inyong Ham, The Pennsylvania State University, The creator of the Group Technology. It is worth to note that the creator of the Group Technology, who gave fundaments to manufacturing information systems, considers modeling and simulation one of the central elements of the information system in any manufacturing organization.

1.3. As stated on the slide, we can define the modeling as the relation between real systems and models, and simulation as the relation between models and computers. The general concepts of modeling are treated in Section 2 1.4. Both modeling and simulation are interdisciplinary tasks. The following series of slides illustrates this. Those are merely some selected applications, ranging from manufacturing to ecology and literature. 1.5.A. A fragment of a manufacturing model. QMG module of the PMS++ simulation system. This application is carried out to detect bottlenecks and to see the statistics of the buffers, machines and operations in a manufacturing system. The user creates the model graphically on the screen, gives the block parameters and the rest is being done automatically by the software. The red boxes are buffers, blue rectangles are machines, green vertical rectangles are assembly operations. 1.5.B. This is an animations of a simulated production cell, PSM++ simulation system. The products enter the system, then travel over a transportation facility (closed conveyor) and occupy (if possible) one of the three service facilities. After receiving the service, the items enter a buffer and then the quality check. Some of them are rejected and must go back to the conveyor, others go out. The items move on the screen, so that the target user can see how the system works. 1.5.C. A System Dynamics model of a factory. This is a screenshot of the Stella program. System dynamics is other approach to the simulation of factories and other systems. This is a global approach, rather than discrete event simulation as in the previous examples. Se the System Dynamics section for more detail. 1.5.D. A system dynamics model, similar to the model of the slide 1.5.C. The demand has a random component. Done with the SimBall program. 1.5.E, 1.5.F. An application of System Dynamics approach in the classes of literature. This model was created not to write new theater works, but to explain to the students the dynamics of Hamlet story. The model was widely discussed on one of the System Dynamics conferences several years ago, as a highly interdisciplinary application of system thinking. The slide 1.5.F is the screenshot of the corresponding Stella model. It can be see how the characters interact with each other and what feedback interactions are introduced. 1.5.G, 1.5.H, 1.5.I. A model of a stock market with bandwagon effect, with one stock type. P is the action price, n is the demand, ne is the uncertain component of the demand (uncertain or false information). The "bandwagon" feedback represents the market panic or euphoria, caused by the rate of the price change. This is a signal flow graph representation of the model (see the Signal Flow Graphs section). 1.5.H shows the same model introduced to the Simulink module of MatLab. On the slide 1.5.I we can see the market response to a change in the price. It reveals strong rapid oscillations, that means that the market is close to loose its stability.

1.5.K, 1.5.L, 1.5.M. Those are some screenshots of a project carried out at the Universidad Panamericana, by the School of Engineering and the Faculty of Laws. This is the simulation of legal processes, that result from the sell-buy operation of actions between two companies. The trade union of the selling company may not accept the operation, and announce the strike. The legality of the strike is negotiated, and if there is no agreement, the strike begins. The financial state of the selling company becomes bad, and the buying company may demand the change of the conditions or the cancellation of the whole operation. This invokes a series of legal events, that normally is quite complicated. The model is used as an didactic aid in the classes on laws. 1.5.N. This PSM++ program is an "ecological game". It simulates a population of entities which grow in a limited environment. First, the screen is filled with food (green area). Several initial entities appear and begin to multiply. To survive, the entity must eat. In some random time instants each entity pollutes the environment (red areas). The pollution is permanent, while the food is renewable. However, no food can reappear on a polluted spot. If some food is available in the neighborhood of the entity, it replicates, producing up to eight new entities. The entity population grows, and those which remain inside the populated areas do not have enough food to reproduce and survive. 1.5.O. Fluid dynamics simulation. This is one of the most difficult tasks in simulation. The fluid dynamics equations are quite complicated and so are the numerical methods and simulation programs. The screenshot shows a gas flow in a duct. This is a section of the duct; the simulation is three-dimensional. Fluids5 program. 2.1. The division of modeling and simulation field into discrete and continuous parts is well known and practical. This division is perhaps somewhat doubtful: in the real world nothing is exactly "discrete in time" or "continuous". From the conceptual point of view, in my opinion, this division is too simplified and artificial. However, in the simulation practice, it is useful, in particular to classify and select simulation software. The simulation tools for discrete and continuous models are very different. (See chapter 5). As stated on the slide, in continuous simulation we deal with a continuous model, where both the model time and the system state change continuously. In the discrete simulation, the time jumps from one event to another, and each event can change the model state and generate other events at the same time instant or in the future. In discrete simulation the model time jumps from one event to another, and the events change the model state. The duration of the event execution (in the model time) is equal to zero. Observe, however that both of the above simulation modes are only approximations of the reality and, in fact, their ideal implementations can only provide an illusion. Continuous simulation on digital computers does not exist, simply because in a digital computer nothing is continuous. The discrete event models do not describe the real world, because a real event cannot occur within null time interval. General concepts of modeling. First of all, recall that a system can be defined as a set of components that are interrelated and interact with each other. These interrelations and interactions differentiate the system from its environment. The system is supposed to be organized in order to perform one or more functions or to realize one or more specific goals.

The commonly mentioned properties of systems include: Aggregation that means that systems can be grouped into categories that can be nested into lager aggregates. Non-linearity - System needs not to be linear that is it not necessarily satisfies the principle of superposition. In other words, the behavior of a system cannot be derived from the sum of behaviors of its components. Consult: Holland, J., 1995, Hidden order, Addison-Esley Now, we can talk about system modeling. P. Bratley, L.F. Bennet and L.E.Schrage in their book A guide to Simulation, Springer-Verlag, 1987, say: A model is a description of some system intended to predict what happens if certain actions are taken. This is perhaps one of the most essential definitions of what a model of a real system is, although it needs some additional explications. Many years ago A.Rosenblueth and N.Wiener pointed out that modeling is one of the central needs of scientific reasoning. Dealing with models we must take into account many factors, like the level of simplification, experimental frame, model validity, tractability, credibility and the aim of modeling among others. Bernard P. Zeigler (Theory of Modeling and Simulation, John Wiley and Sons, 1976) gives some basic concepts on modeling. First of all, we must define the model components as elemental parts of the model, like clients in a bank, ships entering a harbur, cars on a street etc. Each component is described by the descriptive variables that include input, state and output variables. The set of all descriptive variables in a model is the experimantal frame of the model. The same real system may have several different experimental frames. For example, a possible experimental frame for a model of an electronic circuit may include currents and voltages in all circuit elements. Other experimental frame may include the temperatures of all elements (ICs, resistors etc.) and the temperature distribution in the printed circuit. Obviously, the two experimental frames lead to different models and satisfy different modeling purposes. Each experimental frame results in the corresponding simplified model, as shown on slide 2.5. The basic model is that which reflects exactly the bahvior of the real system. Such model normally does not exist. Note that the aim of the modeling task, as well as the technical limitations (the computer on which we want to run the resulting simulation program) reduce the number of possible simplified models. This helps us to select the appropriate simplification. If there is more than one simplification that satisfies these criteria, we must apply other selection rules (e.g. modeling cost). If no model exists that satisfies our aim and technical limitation, then no modeling is possible. Remember that looking for something that does not exist is simply a waste of time. The concepts of model validity, verification, and credibility are treated in other sections. It is well known in the operations research that some problems that have a nice mathematical description cannot be solved using the hardware we actually have. The same occurs with models prepared to be run on a computer as a simulation task. Some models are computationally intractable, which means that they are too time-consuming or expensive to be realized. A modeling and simulation task is intractable if its computational complexity increases exponentially with the number of its descriptive variables. The computational complexity can roughly be define as the minimal cost of guaranteeing that the computed answer to our question (simulation task) is within a required error threshold. A mostly cited example of an intractable problem is the salesman problem, namely the simulation of all possible routes of a salesman that must visit various cities. The aim of such

simulation is to find the route with shortest distance possible. Other examples in continuous system simulation can be found in fluids dynamics applied to problems like reentry of space shuttle to the atmosphere of the earth (modeling the airflow around the craft). For more discussion on intractability consult Joseph F. Traub and Henryk Wozniakowski, Braking intractability, Scientific American, January 1994, or Arthur G. Werschulz, The computational complexity of differential and integral equations: An information-based approach, Oxford University Press, 1991. 2.2. While constructing a model, we must not forget to clearly identify its components, descriptive variables and interaction rules. The model descriptive variables are input, state, output variables and the model parameters. Input means all what affects the model from outside, the cause of model movement. The state of the model is the most important group of variables, that must be carefully specified (see the next slide). Output variables are defined by the user. These are simulation results which will be printed, stored or plotted. 2.3.A, 2.3.B, 2.3.C. Model state. Let U { s , t } be the input to the system over the interval [ s , t ], where s and t are two time instants, s < t. We define X(t) as the state of the system at the moment t if and only if a function F exists, such that X( t ) = F( t ,U { s , t } , s , X( s )) In other words, it is necessary that the system state at a moment t can be calculated using some past state in time instant s and the input function over the interval between the two moments of time. Here we assume that the system is causal in the sense that its state at a moment does not depend on any variable values in the future time instants. For example, the state of a system that has one spring, one mass and one damper linked together is given by the mass position and velocity. All other descriptive variables of this system are parameters, inputs (e.g. external forces), or some output functions defined by the modeler. In the case of an electric red composed by any number of resistors and one capacitor, the sate is a (scalar) value of the capacitor voltage. In this case all the currents in the resistors can be calculated provided we know the capacitor voltage and the external excitations (input signals). System state may be a scalar, a vector or an element of certain more abstract space. For example, the state of the model describing the changes of the temperature distribution inside a piece of metal belongs to the space of all differentiable functions of three variables defined in the region occupied by the modeled body. 2.4. Descriptive variables. This slide shows graphically how the descriptive variables change. The set of input and state variables defines the future state, through the function . Function transforms the state into the set of output variables. A more detailed interpretation and more advanced issues on this transformations is explained in the DEVS section (slide 7.3). 2.5.A, 2.5.B, 2.5.C. Experimental frames and simplified models.

The set of all descriptive variables in a model is the experimental frame of the model. The same real system may have several different experimental frames. For example, a possible experimental frame for a model of an electronic circuit may include currents and voltages in all circuit elements. Other experimental frame may include the temperatures of all elements (ICs, resistors etc.) and the temperature distribution in the printed circuit. Obviously, the two experimental frames lead to different models and satisfy different modeling purposes. On the slide 2.5.B two possible experimental frames are shown. The frame of simplified model 1 includes the clients in a barber shop as separate objects in the computer memory. The waiting line is a set of waiting clients. The barber is a server that can be free or busy at the moment. The frame 2 (simplified model 2) is more simplified: now the queue is merely an integer number that tells how many clients are waiting. Simplified model 2 can be simulated using Monte Carlo simulation, provided we know the rate of client arrivals and the service time distribution. Observe however, that using model 2 we loose the possibility of simulating the clients as (possibly different) objects. This means, that in the simplification 1 we can observe each client, equip him/her with different service requirements, and even make him/her to report on the simulation screen each time something occurs. Each experimental frame results in the corresponding simplified model, as shown on slide 2.5.C. Here, the basic model is that which reflects exactly the behavior of the real system. Such model normally does not exist. Note that the aim of the modeling task, as well as the technical limitations (the computer on which we want to run the resulting simulation program) reduce the number of possible simplified models. This helps us to select the appropriate simplification. If there is more than one simplification that satisfies these criteria, we must apply other selection rules (e.g. modeling cost). If no model exists that satisfies our aim and technical limitation, then no modeling is possible. Remember that looking for something that does not exist is simply a waste of time. 2.6.A, 2.6.B, 2.6.C. Model validation, verification and credibility Model validity is one of the central problems in modeling and simulation. Consider a real dynamic system and its model. Let S be the operation of modeling (passing from real system to its model). By x(t) we will denote the system state in the time instant t , by y(t) the system output, by the state transition function that maps the state x(t) and input over [t, t+h] into the new state x(t+h). The same letters with suffix s denote the corresponding items for the model. Our model is said to be valid if and only if the following diagram of slide 2.6 commutes. In other words, starting with x(t) we must obtain the same model output ys(t+h) independently of the way we go. This must be satisfied for any possible initial state and input. The above definition of model validity is somewhat difficult for practical applications. A more practical concept is the "input-output" validity that can be illustrated by the following scheme of slide 2.6.B. The model is supposed to be I/O valid, if the outputs from model and from the real system are "sufficiently" near. What "sufficiently" means is the individual judgement of the modeller. Obviously, the above property must be satisfied for a long time interval, and perhaps for future model inputs. As we do not know what inputs signals will affect our model, the only way to check the I/O validity is to compare the model behavior and the real system output using some historic data.

Observe that according to the first definition any approximation of a real continuous system by a model with discrete time is invalid. Indeed, in a real system a disturbance may come within the time period of dircretization, being not detected by the discrete model. If the input signals have high frequencies, the aliasing phenomenon may result in completely wrong results. Other source of error is the time-discretization itself that implies its own errors. The most direct way to make the discrete model more exact is to decrease the sampling time for the discrete model. However, there are limitation for such approach, mainly caused by the computer resolution and limitations of a numerical method applied for trajectory integration. Anyway the modeler must look for a reasonable compromise. Invalid models are often results of wrong assumptions. Creating a simplified model we idealize the real system that may result in physically wrong models. Consider a simple example of the electric circuit shown on slide 2.6.D. Let the initial voltage for the capacitor C1 be equal to V, and initial voltage for C2 equal to zero, C1=C2=C. After closing the switch, the two voltages become obviously equal to each other and equal to V/2. Now, consider a simplified model of the circuit. We assume that all elements are "ideal", which means that the capacitors have no internal resistance or inductance, the same assumption taken for the conductors (R=0). Now calculate the initial energy of the circuit. It is equal to (CVV)/2 (C square V divided by two). After closing the circuit, the total energy is 2(C(V/2)(V/2))/2 = (CVV)/4. Where the half of the initial energy went? Our model cannot explain this. In other words, the model is invalid. The very simple reason is that it is too simplified. Now, consider other model, where the connecting wires have resistance R. It is easy to show that the half of the energy is dissipated in the wire resistance during the transient process. Moreover, that this energy does not depend on the value of the resistance. This means that the previous simplified model is not the limit case of the second model, with R approaching zero. Note also that the model validity depends on the actual experimental frame. The first model of our circuit is valid if the experimental frame only includes the (static) voltages. However, if we add the system energy to the experimental frame, this model becomes invalid and we must look for another one. Program verification must be done to check that the simulation program operates in the way that the author of the model thinks it does; the program must be free of bugs and consistent with the model. Such checking is never absolutely complete. The program testing problem is a complex one and widely treated in data processing systems, but the problems are similar. Good verification makes the simulation model and program more believable to the user. 2.7.A, 2.7.B. Classification of dynamic systems In the classification given on the slide 2.7.B we relate the each class to the power of the set of all possible system states. This is somewhat simplified approach. From the mathematical point of view, we should use the term power of the set of classes of equivalence of input signals instead of number of possible states. Roughly speaking, a class of equivalence of inputs is the set of all input functions that provide the same system response over a given time interval. For example, if the system is an integrator, it will give the same response equal to zero, if the input is equal to zero everywhere, or almost everywhere, that is, except of a set

of points of total measure zero. But there is an infinite number of different functions with this property. So, all these input functions belong to the same class of equivalence. However, this is not a course on mathematics, so it is better to use the term number of possible states, understanding by this the power of the set of all possible states. The slide 2.7.B contains short characteristics of the following system classes. Finite automata finite number of possible states. For example a light switch, a computer. Modeling tool: discrete events. Infinite automata infinite but enumerable set of possible states. For example a waiting line without limit, infinitely growing population. Modeling and simulation tool: discrete events. Concentrated parameter systems for this class, the power of the set of all possible states is equal to the power of the set of all real numbers. For example RC circuit, a mass moved by a spring and a dumper. Main modeling tool: ODE (Ordinary Differential Equations). Distributed parameter systems the power of the set of all possible states is greater than the power of the set of all real numbers. For example: diffusion process, 3D heat distribution in a piece of metal, waves on the water surface. Main modeling tool: PDE (Partial Differential Equations). 3.A - 3.G. These are some important dates and events in the development of Modeling and Simulation. The details are on the slides, no additional comments needed. 4, 4.A. Discrete simulation. Imagine a small barbershop with one client queue and one barber. Let the aim of our simulation is to observe how the client queue changes during a day of work. What really influence the queue length are the client arrival rate and the average service time. To satisfy our simulation aim we do not need to simulate how a client moves inside the shop or how much he/she weights. What we must simulate are events like arrival, seizing the server (start service) and releasing the server (be served, go out). These events can be supposed to happen in a discrete time instants, in other words we will not simulate the process of opening the door and passing from the door to the waiting place. We suppose that all this occurs instantly. So, the events occur in certain time instants, and nothing happens between consecutive events. This means that the model time can jump from one event to another. The model time is a real variable, but takes a discrete, may be random, values. This is what happens in discrete event simulation: only the events are simulated, and the time does not advance continuously, but rather in finite intervals. In this way we achieve a good speedup of the simulation. The problem is, however, how to manage the event queue (not the client queue of our example) inside the simulation system. The model time must jump to the next event, so we must every time select the nearest event or to maintain the event queue sorted by the execution time. Anyway, this is always the problem of sorting. A simple linear search or sorting where we examine the whole set of events can work with few possible events, but becomes very slow when the number of events grows. As it is a sorting problem, it will not be discussed here in detail. Note only that a discrete event simulation package is so good as good is its event queue management. The first discrete simulation languages like CSL had simple but already good implementations of the event queue management. Then, different strategies of the event scheduling and process interaction appeared.

As stated earlier, in the discrete simulation the model time jumps from one event to another, and the events change the model state. The duration of the event execution (in the model time) is equal to zero. Observe that the discrete event models do not describe the real world, because a real event cannot occur within null time interval. However, in many cases, in particular in queuing models (mass service, manufacturing) discrete event models are widely used and provide a good approximation of the reality. Other advantage of discrete simulation is the simulation cost. The discrete simulation is very fast, compared to the continuous or combined simulation, where the model time cannot advance so rapidly. The most important problem in discrete simulation is the handling of the event queue inside the simulation tool (software and hardware implementations). It can be said that a discrete simulation package is so good as good is its internal clock mechanism, that manages the event queue. See the next slides for more detail. In this chapter we discuss the problems of Monte-Carlo simulation, object-oriented simulation, agent-oriented simulation, theoretical base: DEVS Discrete Event Specification Formalism, and distributed simulation (this is NOT the same as the simulation of distributed parameter systems). The problem is how to distribute simulation tasks between multiple processors. 4.1.A - 4.1.T. Probability and distributions. Any course that includes the discrete simulation, must also provide some comments on probability, distributions and random number generators. However, this is not a course on probability and statistics. It is assumed that the students already have certain knowledge about these topics. Anyway, it would be an error to dedicate more than, say, 20 % of the course to these issues. Here we only suggest some comments on basic issues, to recall what is absolutely necessary. It seems that the distributions mentioned below are the most important in queuing models, but of course those are only few of the huge set of known probability distributions. Start this part with the definition of the probability. It can be seen that frequently students who are familiar with the use of density and cumulative functions fail to define what exactly the probability is. It is also very important to recall what the Poisson process is and explain why in Monte Carlo-type simulation we frequently use the Poisson distribution, while in such software as GPSS, Arena and object-oriented languages the same process is described by the exponential distribution. If the student remembers that the Poisson distributed (integer) variable describes the number of occurrences of an event (for example client arrivals) within a time interval, and the exponentially distributed (real) variable defines the times between the consecutive occurrences (inter-arrival times), he/she will not commit elemental mistakes. It is also important to be aware of possible errors while using the normal distribution. A common error is to use it as the between-arrival time distribution or service time, without implementing an additional procedure that truncates it to positive-only values. 4.1.U, 4.1.V These slides explain the chi square test. It is supposed that the students already have basic knowledge on probability theory and statistics. The items which refer to these topics should only be treated as remainders. The slides contain the following: Chi-square test A frequent question is what probability distribution should be used to generate random numbers for a simulation experiment. This data is difficult to obtain from the end user of the simulation program, who usually has no idea what is the distribution of the time interval of a

simulated operation. If the variable is the between-arrival interval of a Poisson arrival process, you should use the exponential distribution. If it is not the case, you must suppose something and then test your hypothesis. The mostly used test is the chi-square test. . NOTE: Chi-square test does NOT determine if the hypothesis is true. It just tells us if a specific statistical hypothesis should be rejected or not. The procedure is as follows. 0. Select a null hypothesis about the probability distribution for a random variable being examined.(an expectation of some sort). 1. Get at least 30 random values for the variable (perform an experiment to get the data) 2. Calculate the mean and the variance over the data set 3. Create a histogram of m = square root of n intervals, where n is the number of data points, calculate the number of data points Ni (i=1,..,m) that fall in each interval. Note that you must have at least 5 points in each interval. If not, get more data 4. For each interval calculate the expected value Ei using the null hypothesis. To do this, calculate the (theoretical) probability Pi of falling in each interval i, and calculate Ei=nPi, i=1,..,m

5. 6. 7.

8.

Calculate the weighet deviation Define the level of significance a for the test. Usually it is 10 or 5 percent, that is a=0.1 or 0.05 Get the critical value for square chi with parameters a,b where b=m-k-1. The value of k depends on the number of degree of freedom of the null hypothesis distribution. For example, for the normal distribution we have k=2, for the exponential distribution k=1. Compare the value of c with the critical value for square chi distribution, taken from the tables of chi test critical values. If the value of c is less that the critical value, you cannot reject the null hypothesis (this does not mean that the hypothesis is true, it just tells that it cannot be rejected). For example, the value of a=0.05 means that there is only a 5% chance that the deviation c is due to chance alone.

4.2.A. Simulation Monte-Carlo. In the field of numerical methods, Monte Carlo method is applied mainly to evaluate integrals. For example, given a function f(x) with values in [0,1] and defined over the interval [0,1] the Monte Carlo method consists in randomly generating a set of points (x,y) in the square area 1x1 and in counting the points for which y<f(x). If the number of such points is N and the total number of points is M, then the integral of f(x) over the given interval can be approximated by N/M. There are methods to make this procedure more effective, mainly by the reduction of the variance of the Monte Carlo result. In computer simulation we frequently deal with models that include some random parameters, variables or external excitations. In such simulation the resulting system trajectory is a random function, different for each simulation run. Taking some statistics over the resulting values is a Monte Carlo

evaluation of the result. Monte Carlo simulation has been widely used to simulate problems like stock management and simple queuing models. 4.2.B. Simulation Monte-Carlo - example. This flow diagram can be used to implement the simulation for the problem stated on slide 4.2.A. The resulting program is fast and easy to implement. However, remember that this is a rough approximation of the reality. In particular, this program does not take into account the times the clients arrive during each day and the moments when the products come to the inventory place. If a client comes at 10 a.m. and the stock is empty, it may go without waiting, while the product he is looking for is available at 2 p.m.. 4.3.A, 4.3.B. Object-oriented simulation. Recall that in the object-oriented (OO) programming the program is composed by objects. An object is a structure that has its attributes (visible from outside of the object or hidden) and methods. Everything the object knows is in its attributes and everything it can do is in its methods. For example, a particle, which is a component of an N-body system, has a set of attributes that include its position and velocity vectors, its mass, shape, dimensions etc. The methods of the particle should describe the way it interacts with other particles (calculate the external forces) and the particle movement. The difference between OO programming languages and OO simulation tools is that an OO simulation language or package must provide the clock mechanism, transparent for the user. For example, is an object-oriented programming language. Its simulation mechanisms are not in the language definition, but rather in a pre-defined PROCESS class, written in Simula that can be used to create other objects. The PROCESS class handles the model time and the event queue. Other examples of OO simulation are and . The advantage of OO simulation consists in more realistic model building. For example, the classical prey-predator models were formulated in the form of Lotka-Volterra differential equations. Now, the common believe is that Lotka-Volterra equations does not describe what really happens in the real prey-predator systems. Simulating such systems with objectoriented tools we describe the behavior or each of its members, taking into account its position in a geographical region, individual attributes etc. This results in more realistic simulations. The slide contains also a comment on agent-oriented simulation. 4.4. Simulation concepts introduced in CSL. The Control and Simulation Language was one of the first simulation languages, developed in the 50s. In fact, the name is somewhat confusing; the language has no capabilities for automatic control or similar tasks. It is a discrete simulation language that implements the Activity Scanning (AS) simulation strategy. CSL is obsolete and not used recently. However, for historical reasons some CSL concepts are described here in more detail. CSL is based on Fortran. Compared to Fortran, it has three new elements: the clock mechanism, entity class definition and sets of entities. The clock mechanism manages a set of variables named time variables. These variables store various time instants. They are subject to the clock algorithm, and may be used in userdefined logical expressions. The time named CLOCK starts with value equal to zero. Then, all possible model activities are scanned, according to the slide 4.4.A.

The events are defined by the user and normally have the structure indicated on 4.4.A.. In the conditional part of the event the user should use one or more time variables. Moreover, the main condition should be TX EQ 0, where TX is a time variable. So, only the events with corresponding time variables equal to zero will be executed. After terminating activity scanning, the CLOCK is set equal to the value of the nearest time variable greater than the CLOCK, this means to the time instant of next possible event (slide 4.4.B). After this, all the time variables are being decreased by the same time interval. This way, in the next time, the next event(s) will be executed. The time variables can be declared by the user as global variables, or can be attached to model entities (each entity having its own time variable). The following line is an example of a CSL class definition.
CLASS TIME CLIENT SET OUTSIDE, QUEUE, SERVICE

This defines a class named client (e.g. clients in a bank). The word TIME tells that each client has its own time variable. A client may belong to the sets OUTSIDE, QUEUE (waiting to be served) or SERVICE (being served). The reference T.CLIENT.K can be used to refer to the time variable of the client number K. The program code includes only the initial part (initial conditions and the word ACTIVITIES), and then the event codes. The order the user puts the events in the program is not relevant (except possible simultaneous events). The clock part is hidden and runs automatically. The code of an event should contain a conditional part and some operations. The operations are NOT executed if the conditions fail. For example, the arrivals of a client can be described as the following event code.
BEGIN T.ARRIVAL EQ 0 T.ARRIVAL = NEGEXP(20) FIND K OUTSIDE FIRST CLIENT K FROM OUTSIDE CLIENT K TAIL QUEUE

Note that this event reschedules itself to be executed after a random time interval (exponential distribution with mean equal to 20 time units). The main condition is T.ARRIVAL = 0, where T.ARRIVAL is a time variable. FIND finds a client being outside the bank. The client is taken from outside and put as the last one waiting in the queue. The instruction FIND returns also a logical value. If it fails (there are no clients outside), the following "operational" part of the event is not executed. As mentioned above, this description of CSL is given here only for historical reasons. CSL is now obsolete and completely forgotten. However, some important simulation concepts were introduced in this language perhaps for the first time in the history of computer simulation. 4.5.A, 4.5.B, 4.5.C. GPSS Note that this is not a course of the use of any simulation package. In fact, any of the languages and packages mentioned here would need a whole separate course to give a necessary information to a future professional user. What we show here are only a main ides and some examples of application.

The slides contain a comments on GPSS. As for the software, the examples are based on GPSS/H of Wolverine (free student version). The other source can be Minuteman Software, the GPSS for Windows, also available in demo verion for didactic use. Although GPSS is not an object-oriented language in the sense recently used, it, in fact, handles objets (transactions). So, from the simulation point of view, it is object-oriented simulation. GPSS is an old tool, but it is still in use and offers all what is necessary to simulate quite big and complex discrete event models. 4.6.A - 4.6.D. PSM++ If you prefer other simulation tools, simply skip this section. We use PSM++ because it is a well integrated system that supports continuous, discrete and combined models.It is a lowcost tool. To run PSM++ you will need the Borlad's Delphi(TM) installed on your machine. It can be Delphi 6,7 or 2005. PSM++ (Pascal Modeling and Simulation) is a new version of the PASION Simulation System. PASION stands for PAScal simulatION. PSM++ is an object-oriented, Pascalrelated simulation language. The language has a clear process/event structure and is equipped with appropriate environment. The PSM++ translator generates Pascal source code that can be run using a Pascal compiler (actual DOS version generates code compatible with the Borland's Turbo-Pascal 6, the Windows version is compatible with the Borland's Delphi 3, 4 or 5). The following features make PSM++ the most complete and versatile simulation tool. Efficient scheduling and event queue management Inheritance mechanism that permits to add new properties to old processes without intervening the source code of processes declared earlier. State events. Discrete and continuous objects can run concurrently. The state events can be activated by continuous objects as well as by logical conditions changed by discrete objects. The library of PSM++ predefined processes contains various frequently used processes, e.g. a rigid body dynamics and several helpful processes that handle graphics, data, presentation of results and interactive simulation. Program generator for queuing models (QMGW). This module includes graphical editor for queuing schemes, program and report generators. See also an example of a manufacturing model simulation. Program generator for continuous processes (FLOWD) described by signal flow diagrams. Bond Graph editor and analyzer (BONDW). This module includes a Bond graph editor and a program generator that creates source Pascal and PSM++ code for a given Bond graph model. Ordinary Differential Equations (ODE) PSM++ module accepts user-defined sets of differential equations (linear or non-linear). Note that the equations can also be generated automatically by the FLOWD and BONDW modules. These three modules (ODE, FLOWD and BONDW) support several simulation modes: simple simulation (transient process), interactive mode, frequency response and post-mortem dynamic analysis for stochastic systems.

PSM++ Animator includes a Scenario Editor that permits to create 2D scenarios for animated simulation. The user can prepare hs/her scenario using any image editor like the MS Paint, or even a photo taken from the real system. A simple calls to animation procedures from the source program make the user-defined icons move according to the simulated component activities. The Queuing Model Generator of PSM++ generates automatically the necessary data to run the animations. Post Mortem analyzer for stochastic (discrete and continuous) models. Shows variance, confidence intervals etc. as functions of time, particularly useful for the statistical analysis of transient processes. Frequency response. All modules for continuous simulation (Signal-flow, bond graphs and ODE models) provide also the frequency response analysis. The result of this option are Bode and Nyquist plots. CSS - Complex System Simulator. This PSM++ module can be used to create a model that is a combination of submodels of any PSM++ model type (bond graph, ODE, Signalflow, queuing or any other coded directly in PSM++). This results in one simulation program that containes all these submodels interacting with each other and running concurrently. The general concept of PSM++ simulation is to eliminate the coding (programming) and mathematics (deriving of differential model equations) from the simulation task. Of course, if the user likes programming he/she can code his program, and if he/she likes mathematics then he/she can use the ODE module and type the equations directly. Note that a similar package has been developed for C++ users. It is the C++ version of PSM+ +, named Blues Simulation System (BLUESSS). Consult: http://www.raczynski.com/pn/pn.htm http://www.raczynski.com/pn/bluesss.htm

4.7. STRATEGIES OF EVENT AND PROCESS SIMULATION There are three basic strategies in discrete simulation: Activity scanning (AS), Event scheduling (ES), and Process interaction (PI). In this section we treat activity and event as synonyms. More advanced strategies are being developed and can be found in publications on the DEVS (Discrete Event Specification Formalism). Activity Scanning (AS) was the first discrete simulation strategy, developed in the 50s. One of the first implementations was the language CSL - Control and Simulation Language. According to this strategy, the model time is set equal to the time instant of the nearest event. Then, all model activities (events) are scanned and those, which can be executed, are executed, the others remaining inactive. Next, the time jumps to the next possible event, and the whole process is repeated. This clock loop stops if no possible events remain in the model. Obviously an event, while being executed, can schedule itself or other events to be executed in the future, so the event sequence can be long and complicated, even if the source program is relatively short. The Event Scheduling (ES) strategy is somewhat more effective. In the computer memory the event queue is created. Every component or event message of this queue stores the time the event will be executed, and the event identifier. So, the only problem is to maintain the event queue sorted according to execution time. If we do this, then we simply take the first event and execute it, without scanning all possible events. This event queue management is transparent (invisible for the user) and works automatically. The user can schedule events, but cannot redefine the model time or manipulate directly the event queue. The most effective event management algorithms are those that use binary tree techniques to sort the event queue. The Process Interaction (PI) strategy is more advanced. The model is defined in terms of processes that can run concurrently. The rules of interactions between processes are defined, while the specification of a process includes the necessary event scheduling. PI can be implemented in any object-oriented programming language, and became the main feature of Simula, Modsim, PSM++ and other languages. The Three phase strategy in discrete simulation is a combination of these three strategies. The three phases are as follows. 1. Model time jumps to the next event. 2. The event(s) scheduled to be executed at this time instant are executed. 3. All state- and conditional events are revised. Those that can be executed, are. Consult O'Keefe R.M., The three-phase approach: A comment on strategy-related characteristics of discrete event languages and models, SIMULATION, 47(5), November 1986, pp. 208-210. Lin J.T., Lee Chia-Chu, A three-phase discrete event simulation with EPNSim graphs, SIMULATION, 60(6), June 1993, pp. 382-392. 4.8.A - 4.8.D. Ideas of Simula67

This is an object-oriented high level algorithmic language. Developed by Ole-Johan Dahl, Bjorn Myhrhang and Kristen Nygaard in the Norwegian Computer Center in 1967 (see Dahl O., Nygaard B., Simula - an Algol-based simulation language, Communications of the ACM, no.9, pp.671-678). Simula 67 is an extension of Algol 60. The basic concept of Simula is an object. It is a structure composed by attributes and instructions. Schematically, the object has the following structure.
a1,a2,a3,.........,an <------------------------- , I> v1,v2,v3,.........,vn

where a1,a2,...,an are object attributes, v1,v2,v3,...,vn are the corresponding attribute values and I is the instruction list. An attribute may represent a single variable, a data structure or a procedure. The value of a data attribute is a value of corresponding type, while the value of a procedure attribute is the procedure body. The instruction list is a list of Algol instructions that is being executed when the object is created. When created, the object executes the instruction from the list and then detaches itself, remaining inactive. For example, the following object may represent a point on a plane that can calculate its norm (a distance from the origin of the coordinate system).
x,y,real procedure norm < --------------------------,0> begin norm:=abs(x)+abs(y) end;

The object position is not defined by the object itself. The procedure norm is fixed as a "taxi" distance from the origin, and the instruction list is empty. While created, the object does nothing. It may be given the values of x and y. Once defined the object position, the procedure norm can be call from outside the object to calculate its norm. The basic instructions that manage objects are detach and resume. The detach instruction interrupts the object activities (the object waits) and resume activates the object (it continues to execute its instructions). Consider the following example.
Producer ....x.... <------------,begin> while true do begin ........ x:=.......; stock:=x; resume(Consumer); detach; end; end Productor; Consumer ....y.... <------------,begin> detach;

while true do begin ...... y:=stock; stock:=0; ...... resume(Producer); detach; end; end Consumer;

In this example stack is a global variable. After creating these two objects, the Consumer detaches itself and the Producer starts to execute his instructions. The dotted part of this sketch is other instructions. In the case of the Producer, it should "produce" something (variable x) and put it into the stock. Then, it activates the consumer and detaches itself. The Consumer takes the produced goods (variable y) from the stock and "consumes" them. Then, it activates the Producer and remains waiting. This is a very primitive example, only to show how detach and resume can be used. Simula67 has a class Process where the clock mechanism and event queue management are defined. It permits to locate (schedule) the events in model time. In the Process class we should use the instructions passivate and activate instead of detach and resume, respectively. The hold(v) instruction makes the object wait v model time units, so the object activities can be executed in proper model time instants. The inheritance in Simula67 is realized by simple prefixed declarations. For example Process class Producer can be the heading of the producer class. If so, the Producer inherits all properties of a Simula process. This means that it can use the time-related instructions like hold and other mechanisms needed for dynamic modeling. The objects of Simula are instances of the corresponding class definitions. Simula67 was perhaps the first (and excellent) object-oriented language with simulation capabilities. After more than 20 years from its creation it remains one of the most elegant and sophisticated object-oriented languages. The only disadvantage of Simula is its relation to Algol, which is not the most used and practical programming language. Slide 4.8.D depicts the dynamic creation of objects in the computer RAM. This is not only Simula feature, but rather the mechanism implemented in any object-oriented programming language. 5.A, 5.B. Continuous simulation Continuous simulation is the name given to the use of a computer to solve models with continuously changing states. However, in the digital computer nothing is continuous. This means that the continuous simulation is an illusion that can provide good or not so good approximation of the reality (see the next slide 5.B). Continuous models are generally composed of a number of differential equations. In the case of digital computer, this equations are solved numerically (P.Bratley, B.L. Fox and L.E.Schrage, A guide to simulation, Springer-Verlag, 1987). Most of continuous simulation models are ODE (ordinary differential equations) model. Recall that the ODEs work only if the real systemcan be simplified to a concentrated parameter one. In other words, if we model, for example, an electric circuit, all capacitances must be concentrated in ideal capacitor; all resistances must not have internal capacitance or inductance etc. If there is at least one element like a "large line" where the signal propagates with finite velocity, the ODEs can not be used. Other limitation for ODE models applicability

is that the modeled system cannot have other memory than its state. This is the reason why the ODEs fail while applied to complex tasks, like biomedical or ecological system simulation. The widely known field of System Dynamics is nearly completely devoted to ODE modeling. Note that this approach has some risks. Indiscriminate use of ODE models to everything can lead to invalid models and wrong simulation results. First of all, few simulationists take care of the problem of the existence of the ODE model for a particular task at all. Second, even if we find a corresponding differential equation, we must be sure that it has a solution (this is not always the case!). If the solution does not exist, the numerical method we apply can work, but the results are completely wrong. Consult Raczynski S., When System Dynamics ODE models fail, SIMULATION, vol. 67, no.5, 1996. Other kind of continuous dynamic systems are those of distributed parameters. The most typical examples are the temperature distribution problem, diffusion process, the string movement or fluid dynamics. Such models are described in terms of partial differential equations (PDE). Simulation of the distributed parameter systems is much more difficult that of the ODE models. There are many numerical methods that solve the PDEs, but all of them are rather time-consuming. Other approach is to divide the space where the process takes place into small finite elements and then describe the behavior of each element. This is implemented in many widely used methods of finite element that proved to be more effective than the numerical methods for the PEs. 5.1. Analog computers and simulation. A typical example of analog simulation is a wind-tunnel test on a scaled-down airplane physical model. Other way to do analog simulation is to look for an analogy between one physical model and another, for example a mechanical and electrical circuit. A simple electronic circuit with one operational amplifier, one resistance and one capacitor can realize the operation of mathematical integration. As a consequence, it is possible to solve differential equations using combinations of such circuits. The advanced devices with many such circuits and variable interconnections between them are called analog computers. In early 40s and 50s analog computers were commonly used to simulate continuous dynamic systems, mainly automatic control systems, mechanical systems and others. During the ultimate decades analog computers have been loosing importance, because the differential equations they solve can be efficiently solved on digital computers. 5.2.A. Possible continuous model representations. This course does NOT include simulation of distributed parameter systems. To teach this topic we would need a whole course, including partial differential equations, corresponding numerical methods, finite element method and related software. So, we restrict the continuous simulation part of the course to the models with concentrated parameters. Possible model representations: 1. ODE Ordinary Differential Equations Mostly systems of ordinary differential equations (linear or non-linear) of the first order. 2. Transfer functions (the system must be linear). It is recommended to recall the definition of system linearity and give examples of systems that have transfer functions and those which do not. 3. Block diagrams (Example: control systems)

4. Signal flow graphs (Control systems, causal diagrams) 3. Bond graphs physical systems, like mechanisms, circuits. 4. System Dynamics methodology of Jay Forrester, for global models of the dynamics of organizations, urban development, economy, ecology. 5.2.B. Converting an ordinary differential equation of order N into N equations of the first order. This operation is almost always necessary in ODE model simulation. The majority of the simulation languages and packages require this model representation. The advantage of this canonical representation is that we are forced to define the model state, and what results are the model state equations. A simple trick consists in introducing the state vector and assigning a model variable to each state vector component. Not that this in not always possible. If the original equation is f( y (n) , y (n-1) , ., y 1 , y(t) , t )=0, (y (p) being the derivative of order p), we must be able to calculate y (n) from this equation, in terms of the time and other derivatives. Sometimes it is not possible. If we can do this, the state vector should be as follows: ( x 1 , x 2 ,...., x n ) = ( y(t) , y 1 ,...., y (n-1)). An example is given on the slide. 5.3.1. A mechanical example. The equations are: dw M = F (t ) dt dp =w dt dx ( F (t ) + K r ( x p ) ) = +w dt Ka In fact, this is a system of equations of the first order. To express it in terms of the state vector, simply denote the state vector as ( x1, x2, x3 ) = ( w, p, x ). The state equations are as follows. dx1 F (t ) = M dt dx 2 = x3 dt dx3 ( F (t ) + K r ( x3 x 2 ) ) = + x1 dt Ka 5.3.2. Car suspension. This is a simplified model, where the movement only one wheel is being simulated, vertical movement only. To simulate a complete vehicle, we should treat it as a rigid body, moving due to the four (or more) forces produced by the wheels, in 3D. The slide contains the equations. The state vector is ( x1, x2, x3, x4 ).

5.3.3.A, 5.3.3.B. Stirred tank. Both problem statement and the solution are explained on the two slides. It is important to note that in this case the model simplification consists in the word stirred. This means that the concentration of the solution is supposed to be uniform inside the tank. As a consequence, the concentration in not described by the diffusion equation, and the whole problem can be described by the ordinary differential equations (ODE model). Otherwise, we would need a partial differential equation and a quite difficult simulation tool. This is a good example of a physical system model. Note that to start constructing any model of such kind, we must look for an adequate physical balance. This may be balance of volume, balance of flow, balance of thermal energy (NOT temperature) etc., or a combination of any of them. For example, our stirred tank, as specified on the slides, satisfies the balance of liquid volume. But this balance does not provide any relevant equations, because the volume is constant. Here we must use the balance of mass of sugar, because the unknown variable is the concentration (in mass units per volume). 5.4.A - 5.4.E. Numerical methods for the ODEs. This is not a course on numerical methods. So, only some mostly used algorithms will be mentioned in a very abbreviated form. A big part of the continuous models are of type ODE (Ordinary Differential Equations. Recall that the ODE models in most cases can be expressed in the form of a set of ODEs of the first order, as follows. dxi / dt = f i ( x1 , x2 ,...., xn , t ) where xi , i = 1,2,3,....,n are dependent variables, and t is the independent variable, representing the model time in dynamic systems. The boundary conditions for these variables can be as simple as requiring that certain variables have certain numerical values in a given time instants, or as complicated as a set of nonlinear algebraic equations among the variables. The nature of the boundary conditions determines which numerical methods will be feasible to solve the problem. Boundary conditions divide into two broad categories. * Initial value problems where all the dependent variables are given at some starting time instant and it is desired to calculate their changes over some time interval or in some fixed time instants. * Two-point boundary value problems, where the conditions are specified at more than one time instant. Typically, some of the conditions are specified at a starting point and other at the final time. The simplest way to solve the initial value problem is to rewrite the dxs and dts as finite steps Dx and Dt. Then, multiply the equations by Dt. This gives algebraic formulas for the change in the dependent variables, when the time is incremented by the step size Dt. In the limit of making the step size nearly zero, the solution may be a good approximation of the real one. The implementation of this method is the Euler's method. The Euler's method is simple but

not recommended for several reasons; the most important one is the fact that the approximation errors may accumulate during the iteration process. Runge-Kutta methods propagate a solution over an interval by combining the information from several Euler-style steps (each involving one evaluation of the right-hand sides of the equations. Then, the information obtained from these evaluations is used to match a Taylor series expansion of the solution to some higher order. For example, the fourth-order Runge-Kutta algorithm is given by the following formula. k1 = hf ( x j , t j ) k 2 = hf ( x j + k1 / 2 , t j + h / 2) k 3 = hf ( x j + k 2 / 2 , t j + h / 2) k 4 = hf ( x j + k 3 , t j + h) x j +1 = x j + k1 / 6 + k 2 / 3 + k 3 / 3 + k 4 / 6 + O(h 5 ) where h is the integration step (time increment), x j = x(t j ), x j +1 = x(t j + h) j=1,2,3,.... is the consecutive step number, and the k are auxiliary variables. O(z) is a function that tends to zero at least so fast as its argument z does. This means that the above algorithm will approximate well any real solution that is a curve of 4-th order. There are many modifications and higher order versions of the Runge-Kutta method. For example, a widely used 5-th order algorithm of Runge-Kutta-Fehlberg provides a high accuracy solution and also an estimate of the error. Using this estimate the program can repeat the integration step with smaller time increments to achieve the desired accuracy. One of the disadvantages of the Runge-Kutta methods is the fact that for one step evaluation we need several evaluations (e.g. four for the fourth order method) of the system right-hand sides. The regularity assumptions for these methods consist in the continuous differentiability assumption (up to order N) that the right-hand sides of the equations must satisfy inside the integration step. On the other hand, the method has no "memory" that is, no information from previous steps is used, what makes the method somewhat more robust compared to other algorithms, like the multistep predictor-corrector methods. Richardson approximations (not illustrated on the slides). It is a method for improving the accuracy of an approximated solution to a set of the first order ordinary differential equations. It is supposed that the true solution is an analytic function of the integration step size h. The function can be evaluated with various values of h, none of them small enough to yield the accuracy we desire. Then, we fit the obtained solutions to some analytic function and then evaluate it at the point h = 0. For example, the points can be the results of evaluating the solution by the Euler's method in 2, 4, and 6 steps. These three points can be used to evaluate the solution with h = 0 supposing the solution is a second order polynomial function of h. Predictor-Corrector methods. These methods belong to the family of multistep methods. They are mostly used in the problems with very "smooth" equations with very complicated

right-hand sides. If it is not the case, the Runge-Kutta or Richardson approximatio methods dominate. In the multistep methods we approximate the equation right-hand side by a polynomial passing through several previous points and possibly through the actual point, being evaluated at t = (n+1)h. If this point is included, the method is said to be implicit, otherwise it is explicit. The implicit methods must solve an algebraic equation for xn +1 = x((n + 1)h) because this value has not been calculated yet. Normally, the Newton-Raphson method is used. If the value of x at (n+1)h is not used, the approximation can be calculated in one step, and the method is explicit. The predictor-corrector method use both approximations; first, an explicit method is used to estimate the value of x((n+1)h), and then the implicit method calculates (corrects) it using this approximation as the starting point for the Newton-Raphson method. This procedure seems to be complicated, but you should note that all this operations need only one evaluation of the equation right-hand side per integration step. If the model is complicated, the cost of computing (real CPU time) depends mainly on the number of right-hand side evaluations, which makes the multistep methods several times faster than other, e.g. RungeKutta. On the other hand, any multi-step method must use some previously stored values of the dependent variable. If the equations are not regular enough over these consecutive steps, the method fails. In particular, if our model receives discontinuous excitations, or changes its structure (for example switching controllers), the multi-step methods are not recommended. As an example, see the following Adams-Bashworth-Moulton corrector-predictor scheme. x n +1 = x n + x n +1 h ( 23 X n 16 X n1 + 5 X n2 ) ( predictor ) 12 h = x n + ( 5 X n +1 + 8 X n X n 1 ) (corrector ) 12

Here Xk denotes f(xk , tk). Note that in the corrector part the value of x at (n+1)h is taken from the predictor formula, so that the corrector needs no Newton-Raphson iterations to be performed (xn+1 does not appear at the right-hand side of the corrector equation). 5.5.A, 5.5.B. Direct programming for continuous simulation. The slide 5.5.A shows a possible flow diagram of a program you can code in any algorithmic language. Note that if you do this, you should separate the model (equations right-hand sides) from the numerical algorithm you use. Doing this, you will be able to re-use your code for other models. HOWEVER, (slide 5.5.B) Do NOT waste time creating your own code in C++, Pascal, Basic or other algorithmic language, unless absolutely necessary. Use an adequate simulation package. You will complete your project up to 20 times faster!!! 5.6. An exercise. Simulate the car suspension model of slide 5.3.2. This exercise can be done using the ODE module of the PSM++ system. If you use other continuous simulation package that accepts

ordinary differential equations, you can use it as well. If so, skip the rest of this section. Remember that the objective of the simulation is to determine the value of the damper coefficient, to reach a satisfactory behavior of the vehicle. This means that the oscillations generated by an obstacle should have a good damping. On the other hand, with a very rigid damper we have little oscillation, but the initial vertical impulse growths. Note that this is a simplified model, where both the spring and the damper are lineal. Real car suspension has non-linear characteristics of these elements. In fact, ODE models can be non-linear as well. As an advancedexercise, you may ask your students to introduce non-linearities to the model equations. The PSM++ ODE module works with non-linear models too. PSM++ offers code generators for models described by block diagrams, signal flow graphs and bond graphs. This means that most of the continuous models need no programming and even no mathematics provided by the user. Creation of model equations as well as code generation is done automatically. However, sometimes the user prefers to use his own equations to describe the model dynamics. The DIFEQ module can help in creating the PSM++ code for ODE (Ordinary Differential Equations) models. The input to DIFEQ is given by four sets of specification data: additional process attributes and Pascal declarations, auxiliary operations (performed each time before the right-hand sides of model equations are evaluated), model equations (given by the right-hand side expressions) and output operations. DIFEQ can invoke, from its main menu, the other continuous simulation PSM++ modules, like FLOWD (Signal Flow/Block diagrams) and BONDW (Bond graphs). DIFEQ generates PSM++ code that can run in the following simulation modes.

Simple simulation run - generates a complete PSM++ program that provides the plots of selected output variables as functions of time Varying parameter - a series of trajectories is integrated, where a selected parameter is changed in given interval. The results are shown as 2D and 3D plots. Preparing files for VARAN. While running in this mode, the target simulation program repeats the simulation several times. The corresponding trajectories are stored on disk, for further statistical analysis. This mode is used for stochastic models. As the result, various statistics, like variance, confidence intervals etc. are shown as functions of time. Process only - encapsulate parameters. This creates a PSM++ process declaration, which is "self-sufficient". This means it has the parameters and initial conditions encapsulated in the code. Such process only needs to be created and activated to run. It is useful as a possible sub-model for the CSS Complex System Simulator. Simple process only. A PSM++ process (not program) describing the model dynamics is created.

It should be noted that the PSM++ modules FLOWD and BONDW generate equation files that are processed by DIFEQ in the same way as the user-provided equations are. This means that these modules can generate programs that can run in any of the above DIFEQ simulation modes. For more detail consult the PSM++ FLOWD User's Manual. 5.7.1. Signal Flow Graphs (SGFs).

The slide explains the main concepts of SGF. It is very important to emphasize the fact that, unlike in the block diagrams, in a SFG the nodes represent signals (variables) and the arrows (links) are transfer functions or other operators that convert input signal into the output signal. The causality (input-output relation) is determined by the direction of the arrow. Though SFGs are very similar to block diagrams, it is recommended to use SGFs, because this representation has a quite good theoretical background. 5.7.2.A. Signal Flow Diagram - example of a model of an automatic control system. 5.7.2.B. Signal Flow Diagram - example of a model of and electric circuit For the example of slide 5.7.2.B the gain is x K G= = u 1+ K 5.7.3.A. CSSL standard. In 1968 The Simulation Council Inc. published a report on CSSL (Continuous System Simulation Language) Standard. This standard defines the recommended simulation language structure (slide 5.7.3A.). CSSL is a simulation language. In the following, we will use also the term simulation package referring to a simulation software tool. The only difference is that using a language you must provide the code for the model specifications, while using a package you can define the model graphically (using a graphical user interface, GUI), with little or no programming. The model is defined by the model frame, that may be given as a textual or graphical model description, mathematical expressions for the derivatives and boundary conditions, and by conventional programming in an algorithmic language. The standard mathematical form of the model is dx/dt = f (x,t) where x is the system state vector, f is a vector-valued function and t represents the time. The model frame must be provided in such a way that the translator be able to transform this information into the internal state equations of form, as well as initial and terminal conditions (if any). The user can also explicitely provide the expressions for the derivatives. As the result, the ODE solver will calculate the model trajectory, and produce required results. What the solver does is to advance the time and update the ODE solution in consecutive integration steps, over a given time interval. The function f should satisfy the regularity conditions to ensure the existence and, if it is possible, the uniqueness of the solution. Additional conditions are imposed by the particular numerical method used by the ODE solver. Providing these conditions are satisfied, the function f defines the model dynamics. Note that it can depend explicitely on the model time and may include some model parameters. In some publications on CSSL standard this function is equipped with more formal parameters, to express its dependence on external input signals u(t) and parameters p, which results in the following state equations (boldface means vector-valued): (1.3) dx/dt = f(x(t),u(t),p,t)

Some more complicated situations arise when the model specification includes some implicit conditions (for example initial conditions or additional restrictions), given in the form of algebraic equations. Such implicit, differential-algebraic models require more data and some additional algorithms, like the Newton-Raphson method to used at the beginning or at each integration step. Models of this kind appear, for example, when the model specification is given by signal flow graphs or block diagrams where a closed loops of algebraic (static) links exist. The experimental frame includes the experiment commands and menus, that define how to carry out the simulation (initial and final model time, number of repetitions, output variables etc.). The scheme of slide 5.7.3A can be modified to include discrete event or discrete/continuous (combined) models. In fact, the general structure of the package is similar. The Translator module must process not only the ODEs, but also generate the event list for the whole model. The other relevant difference is that a dynamic event list manager must be added to the "simulation engine". This manager must handle the internal event queue and the model time. Note that adding this module we still can simulate continuous models, treating each integration step of the ODE solver as an event, that may be executed concurrently with other, discrete events. The other, more specific requirements are the GUI and model specification modules. In general, a good, general-purpose simulation package should be able to accept both continuous and discrete models. The continuous models may be defined in terms of block diagrams with transfer functions, signal flow graphs, bond graphs of directly the ODEs. This is the "conventional" approach. Recently, many new mathematical tools become popular, like differential inclusions, stochastic models, models with fuzzy elements, and with uncertainty (do not confuse uncertainty with stochastic elements). As for the discrete models, the GUI should be able to accept models like queuing, manufacturing and mass-service or Petri-nets in graphical form, and generate the corresponding event list. Anyway, the discrete event specification should be compatible with the DEVS formalism, mentiond before. 5.7.3.B. Eliminating mathematics and coding from simulation tasks. Our point is that a simulationist needs not to be neither a mathematician nor a programmer. Of course he/she should have a basic knowledge on these topics, but his task is to simulate. Do accomplish the task a simulationist must understand and must be able to describe exactly the model, no necessarily managing differential equations or other mathematics. The software used should, if possible, generate the equations automatically and generate the corresponding computer code. Fortunately, in continuous simulation, these tasks can be done automatically. Such model representations as signal flow graphs and bond graphs are very useful in this approach. The signal flow and bond graph modules of the PSM++ simulation software are good examples of such type of software. 5.7.4. Link types of PSM++ signal-flow module FLOWD 5.7.5. FLOWD - exercise

5.8.1. Bond Graphs Bond graph method, introduced by Paynter in 1961 (Paynter H.M., Analysis and design of engineering systems, MIT Press, Cambridge, Mass., 1961), is the widespread tool in modeling of physical systems. The fact that a bond connects two variables: the effort and the flow, makes this tool the most appropriate for physical systems modeling, because the flow of power is the product of these two variables (e.g. voltage and current, force and velocity, liquid pressure and flow etc.). An excellent overview of bond graphs can be found in Francois Cellier, Hierarchical non-linear bond graphs: a unified methodology for modeling complex physical systems, SIMULATION, April 1992. Recall that a bond graph model is composed by the nodes or junctions and by the links named bonds. A bond is a directed link with a harpoon. The harpoon is placed on the left of the link (related to its direction). The two variables are indicated as follows. The effort is placed on the side of the harpoon and the flow is indicated on the other side (slide 5.8.1). 5.8.2.A - 5.8.2.C Node and bond types There are several types of nodes in bond graph models. At the node of type 0 the sum of flows is equal to zero, while the efforts of all connected bonds are equal to each other. At the node of type 1 the sum of efforts must be zero and the flows of all corresponding bonds are the same. Thus, we can represent graphically any system that obeys a number of balance equations. The node equations for the node 0 and the node 1 are as follows (slide 5.8.1). b d c = 0 (node type 0) and y a e f = 0 (node type 1). The sign of a term in the node equation depends on the direction of the corresponding bond, the outgoing bond having the negative sign of the corresponding variable. Other possible nodes accepted by BOND are as follows. SE node - effort source, for example an external force, ideal voltage source etc. SF node - flow source, e.g. mandated velocity in a translational system, ideal current source. R node - dissipative element, e.g. damper or electrical resistance C node - capacitance, e.g. a spring or electrical capacitance L/I node - Inertia/inductance, for example a moving or rotating mass, electrical inductance. The causality in bond graph diagrams is denoted by a stroke at one of the ends of the bond. This means that the flow variable is evaluated at the end with the stroke and the effort variable at the other end. There are some mandatory causalities, shown on slide 5.8.2.B. For the nodes of type o and 1 the following rules should be observed. On a node of type 0 only one bond can have causality. On a node 1 all bonds but one must have causality stroke. If the causalities cannot be assigned satisfying these rules, then we have the causality conflict. In this case, most of the bond graph packages issue a warning or stop with en error. These causalities may be given by the user. However, the bond graph software should assign causalities automatically. Any graph scanned by BOND module of the PSM++ package is verified and given causalities, if possible. If the user causalities are wrong they are changed and the corresponding message appears. If BOND cannot find a solution (causality conflict), the analysis stops and the error message is issued.

The node-bond combinations are: (a) (SE node) Effort source. The effort e is defined at the node. (b) (SF node) Flow source. The flow f is defined. (c),(d) (R node) Dissipative bonds. The equations are f = e/R and e = fR , respectively. (e) (C node) Capacitance. It has the desired causality as shown. The equation is de/dt = f/C , C being the capacitance (f) (I/L node) Inertia or Inductance. The equation is df/dt = e/L, L is a constant (mass, inductance etc.) (g) (TF bond) Ideal transformer. The equations are e1 = m e2; f2 = m f1, m is a constant (h) (TF bond) Ideal transformer. The equations are e2 = e1/m , f1 = f2/m , m is a constant (i) (GY bond) Ideal "gyrator". The equation is e1 = rf2, e2 = rf1, r is a constant (j) (GY bond) Ideal "gyrator". The equation is f2 = e1/r, f1 = e2/r, r is a constant Note that R node-bond combination and the TF and GY bonds have two possible causalities (slide 5.8.4.A), while the other bonds must have the causalities indicated in the previous figure. The bond direction always can be inverted, which merely changes the sign of both variables. However, we will require that the bonds connected to the R, C and L/I nodes come into these nodes, and the bonds connected to SE and SF nodes go out of them. 5.8.3.A, 5.8.3B. Examples of bond graphs for mechanical systems. 5.8.3.C. An example of an electrical circuit, which bond graph has causality conflict. The physical interpretation is simple: If the voltage V applied to the circuit comes from an ideal voltage source (with zero internal resistance), then we force the voltage on the capacitor. But V can be any function V(t), not necesarrily continuous or derivable. What happens if it is a step function (closing the switch)? At the moment of voltage increase, the current of the capacitor must be infinite (infinite derivative of V(t)). A similar conflict will appear if we apply a forced velocity pulse to a mass, or a forced current pulse to an ideal inductor. 5.8.4. BONDW module of the PSM++ system. The slide shows a resume of the bond graph module of the PSM++ simulation package. 5.8.5. Exercise: Using the BONDW program, simulate the movement of the mass due to the example 2 (slide 5.8.3.B). Consult the manual of BONDW for more examples and details of the program. 6.1. System Dynamics The Field of System Dynamics System dynamics (SD) is a method for studying the world around us. Unlike other scientists who study the world by breaking it up into smaller and smaller pieces, system dynamicists look at things as a whole. The central concept to SD is understanding how all the objects in a system interact with one another. A system can be anything from a steam engine, to a bank account, to a basketball team. The objects and people in a system interact through "feedback" loops, where a change in one

variable affects other variables over time, which in turn affects the original variable, and so on. System dynamics is a computer-aided approach to policy analysis and design. With origins in servomechanisms engineering and management, the approach uses a perspective based on information feedback and mutual or recursive causality to understand the dynamics of complex physical, biological, and social systems. What SD attempts to do is understand the basic structure of a system, and thus understand the behavior it can produce. Many of these systems and problems which are analyzed can be built as models on a computer. SD takes advantage of the fact that a computer model can be of much greater complexity and carry out more simultaneous calculations than can the mental model of the human mind. Over the past three decades SD has been applied broadly in such areas as environmental change, economic development, social unrest, urban decay, psychology and physiology. Jay W. Forrester ( http://web.mit.edu/sloan/www/faculty/forrester.html ), the creator of System Dynamics, defines it as follows. Unlike other scientists, who study the world by breaking it up into smaller and smaller pieces, system dynamicists look at things as a whole. The central concept to system dynamics is understanding how all the objects in a system interact with one another. A system can be anything from a steam engine, to a bank account, to a basketball team. The objects and people in a system interact through "feedback" loops, where a change in one variable affects other variables over time, which in turn affects the original variable, and so on. The seminal book of Jay Forrester Industrial Dynamics (1961) is still a significant statement of philosophy and methodology in the field. Since its publication, the span of applications has grown extensively and now encompasses work in

corporate planning and policy design public management and policy biological and medical modeling energy and the environment theory development in the natural and social sciences dynamic decision making complex nonlinear dynamics

The System Dynamics Society (SDS) is an international nonprofit organization devoted to encouraging the development and use of systems thinking and system dynamics around the world. With members in fifty-five countries, the Society provides a forum in which researchers, educators, consultants, practitioners in the corporate and public sectorsinteract to introduce newcomers to the field, keep abreast of current developments, and build on each other's work. 6.2. Main ideas of System Dynamics (SD) modeling

The SD model construction is quite easy, if we can describe our model in terms of "integrators" (blocks where something accumulates, like man-power, capital, products, materials etc.), and "flows" that are flows of the media being accumulated. The accumulating blocks are called levels or stocks, each of them calculated as the integral of total flow (incomming flows minus outgoing flows). Each flow must have a "valve" that controls it. The valves may be functions of all other levels and flows, so we can introduce any dependencies and feedbacks into the model. The slides 6.4.A - 6.4.D show some examples of SD models. 6.3. SD software tools (no associated slides) DYNAMO A simulation language based on the method of J.Forrester that implements main concepts of System Dynamics. Accepts model expressed in the form of ordinary differential equation or difference equations. The model is described in terms of flows and levels. The levels are integrals of the total flows affecting the level. The flows can be controlled by algebraic functions of the model state (the levels), so any complex feedback system can be simulated. In models of organizations, there are defined flows of information, material, orders, working power, capital, funds etc. The corresponding levels represent the actual state of the organization. Used for models of economic systems, organizations, urban development and similar. iThink This is a System Dynamics tool, closely related to Stella. The iThink authors describe the tool as follows. To make the right decisions in today's fast-changing business world, you need a clear view of the way all the elements of your business work and interact. Strategies, processes, management structure and information systems form a complex web in which each element impacts all the others. ithink gives you a unique 'overview' of your organisation and makes sense of the dynamic, complex interactions which cloud decision-making. ithink lets you model your business and 'test drive' your strategies forward in time, without risk and before you commit resources. Available from the Cognitus Company. Contact: http://www.cognitus.co.uk/bus-solutions.html Powersim Powersim software helps users to develop business models, to analyze and tune the models, and to distribute the simulations to end users on CD-ROM or over the web. Powersim Constructor is used for creating system-dynamics models that are the heart of a business simulator. You begin by creating a diagram or model of your problem or your organization, then add mathematical formulas to each element in the diagram. You create the diagram by using a small set of basic building blocks of which the most important are stocks and flows. A stock represents a pool of materials, people, money, or other resources. A flow represents the activities that increase or decreases the stock.

By linking the stock to the flow, you can model a feedback loop that describes how managers, employees, and customers make decisions based on information they see in their daily environment. Simulate this model and you will see graphs and tables showing how these decisions and assumptions play out over time. In addition to incorporating this powerful modeling methodology, Constructor includes many other features that can help you build large, sophisticated models of your business problem. These include: Large Function Library Add power to your model with over 150 specialized functions including financial, mathematical, statistical, and delay functions. Graphical Functions Model non-linear or imprecise relationships by drawing the relationship in a graph instead of entering an algebraic equation. DDE Connect to Excel and other applications through Dynamic Data Exchange. Arrays Replicate model structures by segmenting your model into multiple competitors, products, vendors, and/or market segments. Co-Models Partition a model into separate files assisting team members in working independently.

Powersim software can be connected to other databases in several different ways: API: Application Programming Interface that lets other programs access Powersim. DDE: Dynamic Data Exchange, which is a standard Windows approach to data exchange between applications. Using the DDE transfer object, Powersim acts as a DDE client, sending and receiving data. Powersim may also act as a DDE server, allowing other applications to start and control Powersim using DDE commands. OLE: Object Linking and Embedding. This feature allows other software programs to control Powersim. For example, a Powersim diagram may be included in an Excel spreadsheet document. Platform: Powersim tools are Windows 95,98 and NT 3.5,4.0 and 5.0 compatible. Powersim tools can also run as a server on an NT machine, and have JAVA clients running the simulation over Intranet or Internet. The only requirement for the clients is that they need a JAVA enabled browser, or a Java Virtual Machine (JVM) installed, which means that the clients can be run on any platform that has a JVM. Contact: Powersim Corporation 1175 Herndon Parkway, Suite 600 Herndon, VA 20170 (703) 481-1270 powersim@powersim.com STELLA It is one of the most known implementations of the concepts of System Dynamics. A STELLA model is defined in terms of levels and flows. Levels are represented graphically as boxes and flow as directed links (arrows). The levels are integrals of total flows that affect

them. The flows can depend on the levels through algebraic functions, depicted as circles. Levels can represent, for example, the capital level of a corporation, the working power or cash. The flows can be cash flow, working power flow, material or machinery flow etc. STELLA, as well as DYNAMO, PowerSim and several other similar tools has been widely used for simulation of dynamic systems in particular in soft systems simulation. VENSIM Vensim is a software package for development of strategic business simulations and, as such, has been adopted by BRB Consulting as our core technology. It is an implementation of the concepts of System Dynamics. Vensim is developed by Ventana Systems Inc. and can be obtained direct from Ventana Systems or from Authorised Redistributors, such as BRB Consulting. See the Ventana Systems Web site for details. SimBall2 This is a new tool for modeling and simulation of dynamic systems. The System Dynamics (SD) approach is implemented. Recall that this approach reflects rather global and continuous model changes. The objects and people in a system interact through "feedback" loops, where a change in one variable affects other variables over time, which in turn affects the original variable, and so on. It is a low cost simple program, available from Raczynski Consulting http://www.raczynski.com/pn/simball.htm 6.4.A - 6.4.D. SD model examples and screenshots Some examples of SD models created with various software tools are shown. Consult also the slides 1.5.E and 1.5.F for an example of a model of Shakespeare's Hamlet. Slides 6.4.C and 6.4.D show a simple ecological "prey-predator" model. Note that the model is highly non-linear. Both the birth rate of wolves and the death rate of rabbits depend on the product of the size of the two populations. Slide 6.4.D shows a possible non-linear oscillations in the system. 6.4.E - 6.4.F. Stock market model - two representations: Simulink and Stella 6.4.E shows a copy of the model mentioned before in simulation examples (slides 1.5.G, 1.5.H). The model equations are explained with more detail in section 7.4.1. In few words, p denotes the current market price, and pr be the real value of the stock. We will denote by n the current demand of the stock expressed in number of units. Suppose that this demand is the sum of the following components. nr is the demand due to the agents being informed about the stock value, while nb is the demand due to the agents who observe the price increase/decrease rate and do their trading based on some kind of predictions. The subscript b stands for the "bandwagon effect". This means that the positive or negative price rate attracts increasing or decreasing numbers of agents, respectively. ne is the demand due to erroneous information. This is the uncertain component of the demand n. The main (negative) feedback loop stabilizes the market. If the current price is equal to the real price, the current price does not change. If so, the demand becomes equal to zero, which means that the number of actions being sold and bought is the same. If, for example, the real price is greater than the current price, the current price will grow to reach an equilibrium. The other, inner feedback is positive and represents the "bandwagon" effect, this means the panic

or euphoria. This feedback will destabilize the market. The bandwagon feedback is charged with the first order inertia, with a small time constant (of several minutes). The corresponding block on the Simulink scheme is denoted as hb, which has the following transfer function K hb ( s ) = 1 + Ts The Stella scheme (slide 6.4.F) represents the same model, expressed in terms of System Dynamics elements. If you derive the equations for the model 6.4.E and 6.4.F, they should be exactly the same. Note how the inertial block hb has been modeled on 6.4.F (the level nb). The equations generated by Stella are shown on 6.4.F. On this slide we can also see an example of a model trajectory, starting with real price different from the current price. If we disconnect the bandwagon effect (put K = 0) and the uncertain demand component (ne = 0), then the response (price) should be a simple exponential curve, stabilizing at the value equal to the real action price. While constructing the Stella model remember that both flows and the level nb should be allowed to change sign. 7.1. Distributed simulation While there are many ways simulation speeds can be improved, clearly the most fundamental is to move from sequential to parallel execution. This means that the simulation task is distributed between multiple processors at the same mainframe or in separate computers running in a network. There the fundamental issue is the extend to which simulations should be synchronized in a conservative manner (i.e., without rollback) as opposed to an optimistic manner (i.e., with rollback). In distributed simulation each processor runs with its own model time clock. Several distributed simulation techniques have been developed, like Chandy-Misra algorithm (Chandy K.M., Holmes V. and Misra J., Distributed simulation of networks, Computer Networks vol.3, no.1, February 1979, pp.105-113), and the Time Warp algorithm (Jefferson D. and Sowizral H. Fast concurrent simulation using the Time Warp mechanism, Distributed Simulation 1985, The 1985 Society of Computer Simulation Multiconference, San Diego, California). The former is pessimistic or conservative, advancing the processor simulation clocks only when conditions permit. In contrast, Time Warp assumes the simulation clocks can be advanced until conflicting information appears; the clocks are then rolled back to a consistent state. Such conflictive situation arises when one of the local clocks (say that of processor A) advances more quickly than some other (processor B). If the object simulated on processor B sends a message to that of processor A in the model time instant equal to 2 (model time clock of B), the message arrives in the object past. But, every received message can change the object behavior, so the object on A must return to the (past) moment of the message and repeat its, perhaps different, trajectory. The situation complicates if the object A has issued messages (in time 3) to object D, and D has send messages at t=3.1 and 3.2 (of model time of D the conflictive model time instant. All these messages must be cancelled and the receiving objects must also roll back their clocks. This may result in a chain of rollbacks, and make the simulation even slower than in the pessimistic mode. Distributed simulation has no application on single machines and PCs. It is being implemented rather on supercomputers and computer networks. Applications belong mostly

to aircraft simulation, communication networks, defense strategy, VLSI chips and similar great-scale models. 7.2.A, 7.2.B. High Level Architecture for simulation The HLA (High Level Architecture) simulations are distributed simulations (i.e. that run on several machines connected in a network). This is a standard with software resources defined by the American DoD that replaces an older standard called DIS. HLA is a standard for constructing distributed simulations. It is intended to facilitate interoperation between a wide range of simulation types and to promote reusability of simulation software. HLA will encompass virtual, constructive, and live simulations from the training, engineering, and analytic domains, including simulations not from the Distributed Interactive Simulation (DIS) community, such as logical time and aggregate level simulations. A group of simulations interoperating under HLA is called a federation. The HLA defines the rules of interoperability, a semi-formal methodology for specifying simulation and federation object classes, and the interface specification that is a precise specification of the functional actions that a simulation may invoke. Parts of HLA are the Run Time Interface (RTI) and Application Programming Interface (API) through which the simulation of a federation (federates) communicate. The High Level Architecture (HLA) provides an architecture for modeling and simulation in order to encourage the interoperation of simulations and the reuse of simulation components, and to encompass a broad range of simulations, including categories of simulations not previously addressed within the distributed simulation community. The challenges involved in doing this include enabling continuous, real- time simulations to interact with time-stepped or event scheduling simulations. The HLA is being developed by the US Department of Defense (DoD). The basic HLA concepts are the federation that is a named set of interacting federates, and the federate which represents a member of a HLA federation. All applications participating in a federation are federates. In reality, this may include Federate Managers, data collectors, live entity surrogates simulations, or passive viewers. An HLA Simulation Object Model (SOM) is created as an individual federation member. The Federation Object Model (FOM) describes a named set of multiple interacting federates. In either case, the primary objective of the HLA Object Model Template (OMT) is to facilitate interoperability between simulations and reuse of simulation components. The primary purpose of an HLA is to provide a specification of the exchange of all public data among federates in a common, standardized format. Thus, the components of an HLA establish the "information model contract" that is necessary to ensure interoperability among the federates. The content of this federation object model describes : - an enumeration of all object classes chosen to represent the real world for a planned federation, - a description of all interaction classes chosen to represent the interplay among real world objects,

- a specification of the attributes and parameters of these classes, - the level of detail at which these classes represent the real world, including all characteristics. Every object found in a federation execution is an instance of an object class that has been defined in the FOM. The FOM also allows for interaction classes (e.g. an explicit action taken by an object that can optionally be directed toward another object) for each object model. The types of interactions possible between different classes of objects, their affected attributes and the interaction parameters are specified. The ownership management group of services allows federates to transfer ownership of object attributes. An attribute is defined as a named portion of the state of an object. Owning an attribute gives a federate the privilege to provide new values to the federation execution for that attribute. The main difference between distributed simulation and HLA is the fact that the simulations do not have direct connectivity with each other. They do not "speak" to each other at all. Rather, they communicate with the Run Time Infrastructure (RTI) which then communicate with the other simulations. The following glossary explains some of the HLA terms. attribute - A named portion of an object state attribute ownership - The property of a federate that gives it the responsability to publish values for a particular object attribute. federate - A member of a HLA federation. All applications participating in a federation are called federates. In reality, this may include Federate Managers, data collectors, live entity surrogates simulations, or passive viewers. federate time - Scaled wallclock time or logical time of a federate, whichever is smaller. Federate time is synonymous with the "current time" of the federate. At any instant of an execution different federates will, in general, have different federate times. federation - A named set of interacting federates, a common federation object model, and supporting RTI that are used as a whole to achieve some specific objective. federation time axis - A totally ordered sequence of values where each value represents an instant of time in the physical system being modeled, and for any two points T! and T2 on the federation time axis, if T1 < T2, then T1 represents an instant of a physical time that occurs before the instant represented by T2. Logical time, scaled wallclock time, and federate time specify points on the federation time axis. The progression of a federate along the federation time axis during an execution may or may not have a direct relationship to the progression of wallclock time. FRED - The Federation Required Execution Details (FRED) is a global specification of several classes of information needed by the RTI to instantiate an execution of the federation.

Additional execution-specific information needed to fully establish the "contract" between federation members (e.g., publish responsabilities, subscription requirements, etc.) is also documented in the FRED. The set of management requirements provides one source of input to the FRED specification, which will be recorded in a standardized format. 7.3. DEVS The Discrete Event Specification (DEVS) formalism is used to describe models in discrete event simulation. In the DEVS formalism, a model M is defined as follows. M = < X , S , Y , int , ext , , > (1)

where X is the input space, S is the system state space, Y is the output space, int : S S is the internal state transition function, ext : Q S S is the external transition function, and Q is the "total state" defined as follows: Q = {( s, e) | s S , 0 e ta ( s )} Here e is the elapsed time since last state transition. The term ta(s) means the time of an internal state transition when no external event occurs. :Q Y is the output function, and is the time-advance function. The DEVS model (1) is also called basic model. To treat complex models with variable structure, the Dynamic Structure Discrete Event System Specification (DSDEVS) is used. This formalism includes DSDEVN dynamic structure network that is the pair <h, Mh >, where h is the network executive name, and Mh is the model of h. We will not discuss the DSDEVS formalism here. In fact, it is not necessary because the DSDEVS network is equivalent to DEVS model (1) and DSDEVS formalism is closed under coupling. Consult: Chow A.C., Zeigler, B, 1994, Parallel DEVS: A Parallel, Hierarchical, Modular Modeling Formalism, Proceedings of the 1994 Winter Simulation Conference Zeigler B.P., Hierarchical, modular discrete-event modelling in an object-oriented environment, SIMULATION 49(5), pp.219-230 Srivastava A., Rammohan K.R., Object-oriented Simulation of a SIMD Computer Using OMT and DEVS Methodology, Proceedings of the Object Oriented Simulation Conference (OOS'94). 7.4.A - 7.4.D. Advanced topics: Differential inclusions A differential inclusion (DI) is a generalization of an ordinary differential equation(ODE). In fact, an ODE is a special case of a DI, where the right-hand F is a one-point set. One could expect that a solution algorthm for a DI might be obtained as some extension of a known algorithms for the ODEs. Unfortunately, this is not the case. First of all, the solution to a DI is a set. Namely, it is a set in the time-sate space, where the graphs of all possible trajectories of a DI are included. Finding the boundary of such set (named reachable set, or

emission zone as in the works of Zaremba and Wazewski) is not an easy task. I will not discuss here more theoretical details about the DIs. A more extended survey can be found in Raczynski, (1996). An excellent book on theoretic background was written by Aubin and Cellina, (1984). Other fundamental publications are those of Zaremba, (1936) and Wazewski, (1961). One of the properties of the reachable set is the fact that if a trajectory reaches a point on the boundary of the RS at the final time, then its entire graph must belong to the RS. This fact is well known and used in the optimal control theory. Observe that any trajectory that reaches a point on the boundary of the RS is optimal in some sense. Such trajectories can be calculated using several methods, the main one being the Maximum Principle of Pontriagin (consult Lee and Markus, (1967). This can be used to construct an algorithm for RS determination. If we can calculate a sufficient number of trajectories that scan the RS boundary, then we can see its shape. We will not discuss here the theoretical issues related to the DIs, which are complicated and need rather a book than a short article. In few words, the solving algorithm generates trajectories that scan the boundary of the reachable set. On each of such trajectories an expression known as hamiltonian is maximized with respect to a control variable (in our case ne ). Integrating a sufficient number of such trajectories we can obtain a good approximation of the reachable set. The DI solver based on the above principles has been presented in several articles; consult Raczynski, (1996) for more detail. One could expect that the reachable set of a DI can be obtained by a simple random shooting, that is, by generating ne randomly and then looking for the boundary of the resulting points reached by the trajectories. Unfortunately, this is not the case, except perhaps some very simple and trivial cases. What we obtain by such primitive random shooting is a cluster of trajectories in a small region that has little to do with the true shape of the reachable set, even if with great number of calculated trajectories. The solution to a DI is the reachable set for the possible system trajectories. This is exactly the solution to the problem of uncertainty in modeling. In this very natural way the uncertainty in dynamic system modeling leads to differential inclusions as a corresponding mathematical tool. Note that this tool is known for about 70 years and that there is wide literature available on the DIs theory and applications. The first works have been published in 1931-32 by Marchaud and Zaremba. They used the terms "contingent" or "paratingent" equations. Later, in 1960-70, T. Wazewski and his collaborators published a series of works, referring to the DIs as orientor conditions and orientor fields. As always occurs with new theories, their works received sever criticism, mainly from some physicists who claimed that it is a stupid way of wasting time while dealing with so abstract an useless theories. Fortunately, the authors did not abandon the idea and developed the elemental theory of differential inclusions. In the decade 1930-40 such problems as the existence and properties of the solutions to the DIs have been solved in the finite-dimensional space. After this, many works appear on DIs in more abstract, infinite-dimensional spaces. Within few years after the first publications, the DIs resulted to be the basic tool in the optimal control theory. Recall that optimal trajectories of a dynamic system are those that lay on the boundary of the system reachable set. In the works of Pontiragin, Markus and Lee, Bellman and many others, one of the fundamental problems are the properties of the reachable sets.

7.4.1.A - 7.4.1.K A case study: application of differential inclusions to stock market simulation The main topic of this article is an approach to the uncertainty problem rather than the detailed stock market modeling. The model used here is a simple sytem dynamics stock market model for the short time market behavior. Models of such kind can provide important hints for financial planning and strategic decisions. Recall that the systems dynamics models are mostly continuous models that reflect certain global and averaged trajectories of a possible changes of the system variables. In models of such kind the human factor is strongly simplified. The behavior of a stock market agent is difficult to model and to predict. Consequently, the application of system dynamics modeling methodology tp this case, as well as to other systems with human factor is doubtful. The other possible approach is agentbased simulation (do not confuse with stock market agents). However, it have been proved that system dynamics models do reflect some properties of the modelled systems. Anyway we should remember that not all what happens in the real world is described by differential equations. The stock market model used in this paper was taken from literature. It is a simple model of a market with only one stock type. For this and similar models consult Andresen (1999), Minsky (1982) or Goodwin (1967), to mention only some of thousands of publication on stock market behavior. Some more qualitative comments on stock modeling and the use of models can be found in less academic sources like Glassman (1998). The main problem in marketing, economic, social and similar (soft) systems modeling is lack of exact information. This uncertainty in model data (initial conditions, parameters, external signals etc.) and even in model structure need a special treatment. The simplest way to get some information about the behavior of a system with uncertainty is to assume some variables to be subject to random changes and to see the resulting model trajectories. The common opinion is that the uncertainty can be treated using stochastic models and probabilistic methods. Note, however, that the very essential definition of uncertainty has nothing to do with stochastic models. It is an error to identify an uncertain variable with a random variable. An uncertain variable or parameter has an uncertain value that may belong to some interval or satisfy some restrictions. It may have no probability distribution and could not be random at all. The approach to uncertainty treatment proposed here is based on differential inclusions and is deterministic. THE MODEL We consider a simple model of the dynamics of one stock type only. This is an Ordinary Differential Equation (ODE) model like the models used in the System Dynamics approach. Let p be the current market price, and pr be the real value of the stock. We will denote by n the current demand of the stock expressed in number of units. Suppose that this demand is the sum of the following components. nr - demand due to the agents being informed about the stock value. nb - demand due to the agents who observe the price increase/decrease rate and do their trading based on some kind of predictions. The subscript b stands for the "bandwagon

effect". This means that the positive or negative price rate attracts increasing or decreasing numbers of agents, respectively. ne - demand due to erroneous information. This is the uncertain component of the demand n. To find the model equations, observe the following facts. The demand n depends on the difference between the real and the current stock price. This difference should be expressed in relation to the price, so we assume that the demand can be calculated as follows. nr = A pr p p (1)

where A is a constant. This demand, in turn, determines the price growth rate, so we have dp / dt = r (t ) = Bf (n) p where f(n) is given as n for n > I f ( n) = I for n < I (2)

(3)

where B is a constant and I is the total number of stock issued. The function f is simply a saturation. This means that the surplus of stocks (which results in negative demand) cannot be greater than I . The component nb that determines the "bandwagon effect" depends on the price increase rate. This reaction of the agents is not immediate and is subject to some inertia. We shall use here a simplest way to represent this, supposing that nb ( s ) = G ( s )r ( s ) where C G(s) = 1 + Ts (4)

Here s is the differentiation oerator and G(s) is a first order transfer function. The equation (4) implies the following. dnb / dt = (CBf (n) nb ) / T (5)

The equations (2) and (5) describe the dynamics of the model. It is a set of two ordinary, nonlinear differential equations that can be easily solved using any continuous simulation tool. On figure 1 we can see an example of possible changes of the demand during two trading days. This trajectory was obtained using the PSM++ simulation system with the following parameters. I = 10000, T = 0.005, pr = 10, A = 476.2, B = 0.00007, C = 14200.

The uncertain (erroneous) component ne was supposed to belong to the interval [-500,500]. The above value of the "bandwagon" time-constant T can be less than assumed. The velue of 0.005 was chosen to slow down the oscillations and make the the example trajectory more illustrative. The model initial conditions for the trajectories of figure 1 and for all other figures were p(0)=8, nb (0) = 0 which means that we start with undervaluated stock, that generates a positive demand.

Figure 1. Possible changes in demand during two trading days.

THE UNCERTAINTY As stated before, the component ne of the estimated demand represents the erroneous data. To obtain the trajectory of figure 1 this component was assumed to be a random variable taken from the interval [-500,500]. This is a common approach in uncertainty treatment. Treating the uncertain parameters as random ones we can obtain a possible model trajectories, or carry out various statistical analysis over a sets of hundreds or thousands of integrated trajectories. However, note that uncertainty should not be confused with randomness. First of all, to consider a variable as random, you must know that it is really random. If so, you must know something about its probabilistic properties, to be able to generate it. In the case of dynamic systems it is not only the probability distribution, but also the spectral density, mutual correlations and other stuff hardly known in practical applications. On the other hand, if a model variable is said to be uncertain, we only assume some interval (maybe infinite), where it belongs and nothing more. The result of the uncertainty analysis should be the reachable set for the model trajectories. Note that such

uncertainty treatment is determinisintic. Other reason to treat the uncertain variables in a non-probabilistic way is that such analysis gives us information about possible extreme values (recall the "law of Murphy"). This also may be useful if we expect that the uncertain variables could be intentionally generated to move the system to the extreme values (manipulated and false information). For example, looking at our model, given by the equations (2) and (5) we can see one uncertain variable, namely ne . In the vector form our model is described by the equation dx / dt = f ( x, ne ) ne [ 500,500 ] (6)

where x is the state vector x = (p, nb) and f is a vector-valued fuction that includes the two right-hand sides of the equations. We do not indicate constant model parameters in the arguments of f. However, ne appears in the right-hand side of (6) because it is a variable and not a fixed parameter. The equation (6) can be written as follows. dx / dx = F ( x) where F is a set defined by f , when ne takes the values from the interval [-500,500]. What we obtained is a differential inclusion instead of a differential equation. This is the proper way to treat the dynamic uncertainty. The solution to a differential inclusion is the reachable set, that is the set where all model trajectories must belong. This is exactly what we need as the result of the uncertainty analysis, and not particular model trajectories. Note that this problem statement is completely deterministic. SOME RESULTS Figure 2 shows the solution to our differential inclusion at the end of a one-day trading. The dotted contour shows the boundary of the reachable set, that is the boundary of the set where the model trajectories must belong, on the price-demand plane. This contour was obtained by storing about 500 model trajectories. To see how useless is a primitive random shooting method mentioned before, the figure also shows the result of such shooting with 10000 trajectories integrated (a small cluster of pixels inside the reachable set). The random values of ne in this primitive shooting were generated on the boundary of the allowed interval [500,500]. While generating ne randomly from inside of this interval, the cluster is even smaller. This does not mean that the computing time needed to solve the DI is 20 times smaller compared to primitive shooting. The point is that the primitive shooting provides no solution at all. On the other hand, the DI solver is rather slow, because of the complexity of the algorithm that needs the hamiltonian to be maximized on each integration step. In the presented case, about 10 minutes of computing time was necessary to get the solution, using a 450Mhz PC. Figure 3 shows a 3D image of the reachable set.

Figure 2. The reachable set at the price-demand plane. A small cluster of points inside the set was obtained with a primitive random shooting.

Figure 3. The 3D image of the reachable set. The trajectories that determine the reachable set are oscillating around the boundary of the reachable set. These non-linear oscillations suggest that the extreme points of the reachable set boundary are reached when the model enters in some kind of "resonance". This is hardly possible with a random excitation, but quite possible when the uncertain parameter is changed intentionally to reach the boundary or extreme points. Figure 4 shows some of such trajectories randomly selected. Note that those are not random trajectories; only their selection is random. Each of the trajectories of figure 4 is a 2D projection of a trajectory that lies on the reachable set boundary. Finally, figure 5 shows the projection of the reachable set on the time-demand plane.

Figure 4. Some randomly selected model trajectories that scan the boundary of the reachable set.

Figure 5. The projection of the reachable set on the time-demand plane

CONCLUSIONS The main point of this article is the application of the differential inclusions to the problem of uncertainty in dynamical systems. The uncertainty problem is deterministic. If we treat the uncertain parameters as random ones, we could obtain very poor estimates of the possible extreme values that the model variable can reach due to the uncertainty. The presented differential inclusion solver works quite well, though it is still under construction. The model of the stock market dynamics is a good example of uncertainty and may provide interesting information about possible stock market behavior and can be used in financial planning.