Programming Languages for Simulation - polito.it · Programming Languages for Simulation ... simulation: ! SIMULA ! GPSS/H ! ... among blocks and the overall simulation

1

© TLC Network Group - Politecnico di Torino 1

Programming Languages for Simulation

Michela Meo Maurizio M. Munafò

[email protected] – [email protected]

revised by Paolo Giaccone


From the model to the program

n  The model description and specification for the system to be simulated are not enough: we need to run the model

n  Trivial models can be run by hand (e.g. using an Excel spreadsheet), but those cases are very uncommon

n  We need to convert the model in program to be run on a suitable computer

2


From the model to the program

n  Various solution to convert our model in a computer program: n  Special-purpose programming languages,

dedicated to simulation n  General-purpose programming languages n  Integrated Development Environments

(possibly associated to one of the previous programming languages)


Special-purpose languages n  They are very high level (in terms of

abstraction) programming languages, strictly dedicated to the coding of simulation models

n  They natively offer syntactical tools to represent the main elements for the supported modeling approach n  Event scheduling -> functions for creation and

manipulation of the events

3


Special-purpose languages

n  Examples of programming languages for simulation: n  SIMULA n  GPSS/H n  Arena/SIMAN n  SIMSCRIPT II.5 n  …

n  They support either one or several modeling approaches



n  They are usually proprietary languages n  Often they provide all functions needed

for the generation of random variables and for the statistical analysis of the outputs

n  They can produce intermediate code in a general-purpose language (through a preprocessor) and interact with functions written in such a language

4



n  Pros n  They hide the system management

complexity from the programmer n  Easy to translate the model in a program

n  Cons n  They hide the system management

complexity from the programmer n  For the aim of our course, they are quite

specialized languages


SIMULA: Example Simulation Begin Class FittingRoom; Begin Ref (Head) door; Boolean inUse; Procedure request; Begin If inUse Then Wait (door); inUse:= True; End; Procedure leave; Begin inUse:= False; Activate door.First; End; door:- New Head; End; Procedure report (message); Text message; Begin OutFix (Time, 2, 0); OutText (": " & message); OutImage; End;

5


SIMULA: Example Process Class Person (pname); Text pname; Begin While True Do Begin Hold (Normal (12, 4, u)); report (pname & " is requesting the fitting room"); fittingroom1.request; report (pname & " have entered the fitting room"); Hold (Normal (3, 1, u)); fittingroom1.leave; report (pname & " have left the fitting room"); End; End; Integer u; Ref (FittingRoom) fittingRoom1; fittingRoom1:- New FittingRoom; Activate New Person ("Sam"); Activate New Person ("Sally"); Activate New Person ("Andy"); Hold (100); End;


SIMSCRIPT II.5: Example Preamble '' A simple telephone system model - CACI Products Company '' files: TELPHN1.SRC Normally mode is integer Processes include GENERATOR Every INCOMING.CALL has a CALL.ID Define NUMBER.BUSY and LOST.CALLS as integer variables End ''Preamble

6


SIMSCRIPT II.5: Example Main Activate a GENERATOR now Start simulation Print 1 line with LOST.CALLS thus 15 phone calls were made and ** were lost due to

busy lines End ''Main Process GENERATOR For I = 1 to 15 do Activate a INCOMING.CALL now Let CALL.ID(INCOMING.CALL) = I Wait uniform.f (2.0, 6.0, 1) minutes Loop End ''GENERATOR


SIMSCRIPT II.5: Example Process INCOMING.CALL

If NUMBER.BUSY < 2

Add 1 to NUMBER.BUSY

Wait uniform.f(6.0, 10.0, 2) minutes

Subtract 1 from NUMBER.BUSY

Else

Add 1 to LOST.CALLS

Endif

End ''INCOMING.CALL

7


General-purpose languages

n  Since our model must be coded in a computer program, any programming languages can be used for simulation

n  Usually we will not have any native support to represent the elements of the model

n  In any case, we could use ad hoc dedicated function libraries



n  We need to implement all the management functions needed for the selected modeling approach n  Event scheduling -> creation and management

of events

8



n  There are no specific requirements for the coding of models based on the event scheduling approach: usually the native functions and data structures provided by the language are sufficient

n  We need to provide functions for the event management and the control of the simulation, but it is code easily reusable (e.g. it may be provided by public domain libraries)



n  Pros n  They expose the system management complexity to

the programmer n  Compilers are easily available n  Total control on each part of the simulation

n  Cons n  They expose the system management complexity to

the programmer n  We need to code each part of the simulator,

increasing the possibilities of errors and bugs

9


Integrated Development Environments

n  They are tools, usually graphic, designed to simulate complex systems

n  They provide large libraries of elementary blocks that can be composed to build the model of a large system

n  The system manages the interaction among blocks and the overall simulation



n  Each block can be already coded or it can just be and empty shell for user-provided code

n  Each tool is usually very specialized: new libraries can increase its functions and capabilities, but not the application field (at least not in fields that are completely different)

10



n  Pros n  Rapid prototyping and creation of the simulation

program n  It is possible to simulate without programming n  Rich model libraries

n  Cons n  Hidden simulation complexity n  We need to trust the library on quality and

correctness n  No control on several simulation aspects: we might

ignore key information (e.g. outputs precision) n  Programming user-defined blocks can be a complex

task n  The program efficiency could be reduced


OpNet

11

OMNeT++

n  GUI based simulation environment n  Mainly used to simulate communication

networks n  Large library of publicly available blocks n  Components are coded in C++ and assembled

using a dedicate high-level language (NED) n  Models are based on message exchange

(time advances when a message is received by a component)



OMNeT++

12


ns2

n  Popular integrated environment (not graphical)

n  Oriented to the simulation of Internet n  Large library of block dedicated to the

simulation of TCP/IP, routing and multicast protocols, both in wired and wireless networks

n  Coded using C++ n  Scripting using OTcl

ns2 + network animator


13

ns3 n  evolution of ns2 n  not compatible with ns2 n  written in C++ n  scripting in C++ or Python


ns3 + network animator


14

J-SIM n  written in Java n  scripts in Perl, Tcl, Python


J-SIM + graphical editor


15

JavaNetSim



Discrete-Event Simulators

n  We just discuss some implementation issues common in all discrete-event simulators

16


Structure of the simulator

n  The basic elements of a discrete-event simulator are: n  the main cycle for event analysis (Event Loop) n  the Future-Event Set n  the functions to be executed when each event

happens n  To these key elements we can add:

n  the procedures for data collection and measurement analysis

n  the procedures for the initialization of the simulator n  the termination criteria for the simulation


Data structures

n  Before going in the details of the various simulator parts, we need to define some fundamental information for our simulator and how to represent it n  The simulation time n  The events and their attributes

17


The simulation time

n  The simulation time is a compressed/expanded representation of the time in the real system

n  We could represent time through n  a floating-point variable n  an integer variable


The simulation time

n  The time representation in floating-point format is the nearest one to the real nature of time

n  The probability for two events to happen exactly at the same time is zero

n  We do not need to worry in any special way about the management of contemporaneous events

18


The simulation time

n  The time representation in integer format is suitable for those systems where time evolves naturally in steps (slotted systems)

n  The probability for more than one event to happen at the same discrete time may be not negligible

n  We need to define an order criterion among contemporaneous events


The simulation time

n  Independently from representation format, we need a global indicator for the time evolution: a system clock (current time)

n  It is a global variable, accessible from any point of the simulator, representing the current value of the simulation time

19


Events: data structure

n  Each event must be represented in our program using a composite data type, whose nature will depend on the implementation choice for the Future-Event Set

n  Each event will contain at least: n  the time at which the event is scheduled n  an identifier for the type of event



n  The event scheduling time is the key field, since it is needed to decide which is the next event to be executed, i.e. the one with the smallest scheduling time in the FES

n  The event type is needed to identify which kind of event must happen, and therefore which specific function should be executed

20



n  Often it is useful to associate attributes to each event

n  This permits us to aggregate events according to their general type, to discriminate them later at execution time

n  Example n  In a queueing system with two different kind of

servers, instead of defining distinct events for the two servers, we define a single service event and we store the information on the involved server in an attribute


Event Loop

n  The heart of a discrete-event simulator is the Event Loop

n  It’s a loop, in which: n  the next event is extracted by FES n  the current time is advanced to the

scheduling time of the event n  depending on the event type, the associated

procedure is executed

21


Event Loop: pseudo-code while (termination condition) { extract the event from Future-Event Set; current_time = event->time; switch (event->type) { case TYPE1: procedure_type1(); break;

case TYPE2: procedure_type2(); break;

... } release event; }


Event Loop: termination n  The Event Loop is executed until the

termination condition is reached n  Some possibilities

n  The FES is empty: the system evolution ended naturally

n  The maximum simulation time has been reached n  The maximum number of events has been reached n  The precision conditions on the measurements have

been satisfied n  An anomalous condition has been reached

22


Future-Event Set

n  The Future-Event Set is the key structure of a discrete-event simulator

n  The efficiency of the simulator depends from its implementation

n  We will need to consider the trade-off between implementation simplicity and execution efficiency n  the simpler structures are often the less

efficient, while the most efficient may require a complex implementation


Future-Event Set

n  The Future-Event Set is the set of all the events scheduled for a future execution

n  From this set we will extract each time the one with the minimum scheduling time (Next Event)

n  Any data structure can be used to represent the FES, but obviously some structures are more suitable and more efficient than others

23


Future-Event Set

n  The selected data structure must support in the most efficient way the common operations for the FES n  Insertion of a new event n  Extraction of the next event n  Lookup and deletion of an event

n  The management efficiency for the first two operations is fundamental, while lookup and deletion may be required only for advanced cases and their implementation might be not optimized


Future-Event Set

n  The management efficiency depends a lot from the specific conditions of the simulator n  The sequence of the insertion and deletion

operations n  The average number of events in the FES

n  We use as a reference estimations of the efficiency in worst-case scenarios and order-of-magnitude evaluations

24


FES: Linear list

n  Using a linear list is the most simple way to realize the FES

n  To optimize the insertion, extraction and deletion operations, the list may be n  ordered according the event scheduling time n  bilinked


FES: Linear list

n  Insertion n  It can be done either from the head or from

the tail of the list n  In the hypothesis of scheduling mostly

remote events , the insertion from the tail could be preferable

n  For N events already in the list, the insertion complexity is O(N)

25


FES: Linear list

n  Extraction n  Since the list is ordered, we must just remove the

first event in the list n  Complexity O(1)

n  Lookup and Deletion n  Lookup has the same complexity of an insertion,

O(N) n  If we know in advance that events should be

cancelled, it might be useful to maintain a copy of their reference outside the FES, to be able to cancel them without having to look them up -> complexity O(1)


FES: Linear list

n  The management complexity is generally O(N)

n  The problem is the value of N, that is the number of events on average in the FES

n  For systems not in overload, N is usually small

n  For systems near the overload, that is the category we are mostly interested in, N might be quite large

26


FES: Multiple linear lists

n  We can improve slightly the efficiency in the use of linear lists using several parallel linear lists, one for each event type

n  To get the next event, we extract the minimum among the events at the head of each list

n  Insertion is now O(Ni) and extraction is O(m), being Ni the number of events of type i and m the number of event types


FES: Heap

n  A solution to reduce the insertion complexity is to use data structures different from a linear list

n  A heap is a special tree data structures where elements are partially ordered. Binary heaps can usually be mapped over an array

100 19 7 2 1 25 3 17 36

27


FES: Heap

n  The binary heap has insertion and extraction complexity O(log2N), due to the need to rebalance the data structure after some of those events

n  Besides the insertion and extraction complexity, we need to consider the overhead due to the fact that we might need to reallocate the array when the heap size increases


FES: Hybrid structures

n  It is possible to define hybrid data structures for the FES, designed to reduce as much as possible the complexity while maintaining the computational efficiency

n  A possible efficient solution it to maintain the events in a linear (bilinked) list, adding an “overlay” structure of reference to intermediate positions in the list

28


FES: Hybrid structures

n  The extraction complexity for such a solution is still O(1), while insertion complexity is now smaller than O(N), since insertion is now aided by the direct access to the intermediate positions of the FES

n  We need anyway to consider the increased complexity due to the overlay management


FES: Conclusions

n  FES management is crucial for the simulator to work efficiently

n  Special-purpose simulation oriented languages and IDEs usually provide good implementations for the FES

n  If we code the simulator personally, we need to pay attention to the type of implemented FES

29


FES: Conclusions

n  FES based on linear lists n  easy implementation n  suitable only if the system is not complex or

it is not systematically overloaded n  FES based on heaps or hybrid structures

n  necessary for systems designed to manage a very large number of events

n  reduced performance improvement with respect to linear lists for small systems, due to the management overhead


FES: Conclusions

n  For this course the usage of linear lists is enough, even if they are not the most efficient solution

n  In ‘real world’ situations we must seriously consider the trade-off between the FES management complexity and the gain in efficiency and execution time, so an advanced solution is usually the best choice

30


Measure collection and analysis

n  Our scope is to evaluate the system performance before its actual implementation

n  The performance indexes we are interested in will vary according to the situation but they are typically represented by numeric quantities measured inside the program

n  The key activity of our simulation is to collect samples of those numeric quantities to later proceed to the evaluation of our indexes


Measure collection and analysis

n  Parts of this course is dedicated to the evaluation of the confidence of the measures done and the methods to control the simulation to have guarantees of such confidence

n  In this preliminary phase we want just to recall the various types of quantities that we may need to measure and how such measures can be performed

31


What do we want to measure?

n  Point quantities n  Number of realizations of a certain event

(total number of packets, arrivals, departures, losts, etc.)

n  Maximum or minimum value of a specific quantity (delay, length of a queue, number of users in the system, etc.)

n  For this kind of measures it is enough to use accumulators to be incremented or updated during the program execution


What do we want to measure?

n  Averaged quantities n  Average times (system time, service time,

waiting time, etc.) n  Average numbers (of users in the queue, of

calls, of lost packets, of blocked calls, etc.) n  For these quantities, we are actually

interested to a complete statistical characterization, therefore also to their variance or standard deviation

32


How to measure averages? n  To measure averages requires, as we will see

later, a lot of attentions n  In our simulator we have two possibilities:

n  to collect all the samples of the quantities we are interested in, saving them outside the simulator (in a file) and leaving the statistical analysis of our quantities to an external dedicated program

n  to perform inside the program the needed mathematical operations to produce as outputs only the average quantities

n  Due to the length and complexity of our simulations, the latter possibility is the one usually adopted


How to measure averages?

n  We need to measure different types of averages, depending on the involved quantities n  Point (discrete-time) averages n  Time (continuous-time) averages n  Statistical frequencies

33


Point averages

n  They are used for quantities for which we know the values and the number of samples

∑=

=N

iixN

x1

1ˆ

Time


Point averages

n  In the code n  We accumulate the samples xi

total += sample; nr_samples++;

n  At the end of the simulation we calculate mean = total/nr_samples;

n  In a similar way we can calculate the variance using the estimator

⎟⎠

⎞⎜⎝

⎛⋅−

−= ∑

=

2

1

22 ˆ1

1ˆ xNxN

N

iiσ

34


Time averages

n  They are used for those quantities for which we are interested in the ratio between their value and how long that value holds

∫∞→=

T

Tx dttxT 0

)(1limµ̂

Time

xi-1

ΔTi


Time averages

n  In the code n  We accumulate the areas ΔTi · xi-1

delta_time = current_time – last_time; total_area += old_sample*delta_time; old_sample = current_sample; last_time = current_time;

n  At the end of the simulation we calculate mean = total_area / final_time;

n  The evaluation is slightly more complex since calculation are done at the next sample

35


Statistical frequences

n  We use them to evaluate probabilities

n  In the code n  We count the favorable samples if (condition) { nr_good++; }

nr_samples++;

n  At the end of the simulation we calculate prob = nr_good / nr_samples;

NNp i

i =ˆ


Caveat n  Our calculations are, at the moment, only an

unreliable estimate of the quantities we want to measure

n  We are not considering n  the effect of the start conditions n  the effect of the transient n  the fact we are measuring a single specific

realization of the stochastic process representing the simulated system

n  We will learn later the correct procedures to measure quantities with suitable confidence on their accuracy

36


Initialization

n  Before starting the simulation (entering the Event Loop) we must n  initialize all the variables used to store our

measures n  initialize the data structures needed for the

simulation n  assign a value to all the simulation

parameters, possibly through user inputs n  bootstrap the simulation, scheduling the first

few events


User input n  To study the system, we want to reproduce its

behavior when a certain number of parameters vary

n  Quite obviously, if all parameters were fixed inside the simulation program, we would need a different program for each possible combination of values

n  It is therefore normal to plan for the input of parameters n  interactively n  on the command line n  using configuration files n  through a combination of the previous methods

37


Termination

n  At the end of the Event Loop, before exiting the program, we must inform the users of the simulation results (Duh!)

n  If the simulation ended regularly we will print (on the screen and/or on a file) all the measures collected and any information we consider important to report

n  If the simulation ended anomalously, we will explicitly report this fact, to avoid the possible usage of meaningless data


Simulation!

n  A run of the program corresponds to a single realization of the stochastic process representing the simulated system, i.e. to a single point in the space of the possible results

n  This is not enough: to characterize and study the system we want to explore a large portion of the results’ space

n  We plan a simulation campaign!

38


Simulation! n  To execute a simulation campaign we should:

n  distinguish the input parameters between: n  fixed parameters, whose influence is not a subject of

interest in the specific campaign n  varying parameters, whose effect on the system

performance indexes is the subject of simulation n  identify the output parameters whose variation we

are interested in n  execute simulation runs for each meaningful

combination of the varying input parameters n  aggregate and represent the output data in a way

that explicates their dependence on the varying input parameters


Simulation! n  Varying input parameters

n  For each one we must define a variation range and the number of values in such a range

n  Simulation runs for each combination of values for the parameters

n  For each combination, several runs (with different seed and different duration) to reduce the effect of start conditions and the pseudo-random sequences

n  Complexity increases exponentially with the number of parameters: don’t exaggerate!

n  Representation of the output results n  We need to select the best way to present our

results -> families of parametric plots

39


Simulation!

n  Representation of the output results n  The measures and the data collected by our

simulator will almost always be used to dray parametric plots as a function of the input parameters

n  We choose a format for the output files that

makes the creation of such plots easier, at least for the program we plan to use to produce the graphs (MS Excel, Matlab, gnuplot, …)

Programming Languages for Simulation - polito.it · Programming Languages for Simulation ... simulation: ! SIMULA ! GPSS/H ! ... among blocks and the overall simulation

Documents