MSIM 602: Based on CS 475575, Simulation Engines

1
MSIM 602 Based on CS 475/575, Simulation Engines

• M. Overstreet
• Old Dominion University
• Spring 2007

2
Computer Science Concerns in Simulation

• Efficient execution
• In terms of both time and memory requirements
• Best algorithms and data structures
• Tools, languages, packages to support simulation
• Here well focus on efficient executions

3
Concern Execution Speed

• In many situations faster is better
• Sometimes just to skip over uninteresting or
  non-instructive parts
• But often because for efficiencys sake
• Both peoples and machines
• Unnecessary waiting is wasteful
• But not always the first concern
• Animations often require fixed speed to be
  understood
• Person-in-the-loop (that is, people interacting
  with a running simulation)
• To give people time to respond
• Make situation more realistic

4
Execution Speed Issues

• Graphics intensive simulations (or virtual
  reality) support may dominate CPU load
• Performance concerns dominated by graphics
  issues. Not topic of this class.
• Performance always a concern perceived need for
  ever bigger simulations
• Efficiencies not needed for all simulations, but
  it doesnt hurt.
• If building simulation tools,

5
Fixed-time Step Implementation - 1

• Imagine a simulation that consists of many
  entities
• E.g., planes, tanks, boats, people, ...
• Manufactured parts, customers, workers, network
  components, etc.
• In many simulations, entities come and go (from
  the point of view of the simulation), move around
  and occasionally interact.

6
Fixed-time Step Imp - 2

• Pick an appropriate value for delta-t
• Set simulation clock to 0
• While( simulations not over )
• For each entity
• Check each entity to see if it needs to do
  anything, for example
• It may run out of gas, a part could break, etc.,
  etc.
• It might detect that another entity is close
  enough for it to respond to. It should respond.
• End for
• Move mobile entities to new location
• Velocity delta-t
• Increment simulation clock by delta-t
• End while

7
Choice of delta-t

• Should be small enough so that the simulation is
  still valid
• Too small bad, too big bad
• If too small, simulation spends most of its time
• Inc sim time by delta-t
• Check to see if anything happens
• If too small, most of the time nothing does
• Inc sim time and repeat
• If too big, miss events
• Military sim based on checking if missile comes
  close to plane
• Occasionally missiles fly through planes, but no
  one notices

8
Some Implementation Details

• Example say some parts break randomly
• For simulation to be valid, we need to know which
  random distribution to use.
• Suppose a part breaks at sim time t0.
• Program takes whatever actions needed when part
  breaks.
• Program generates a random number, say x0, and
  stores (t0 x0) in a variable, say
  nextFailureTime.
• Then each time the simulation checks to see if
  the entity containing the part needs to do
  something, one thing it checks is if
  nextFailureTime is close enough to simulation
  time.
• Until it breaks. It then reacts, generates a
  new nextFailureTime

9
Point

• In many simulations, things are scheduled to
  occur, sometimes randomly, sometimes at fixed
  time increments
• Customer arrivals
• Parts failure
• Sun sets
• Weather changes
• For some simulations, random events are
  scheduled to occur at particular times, e.g.
• To meet training objectives
• Emergency events (engine failures) in aircraft
  simulators
• To see how systems responds events of concern

10
How Done Efficiently?

• Choose appropriate data structures
• Time-based
• Things an entity is supposed to do in the future
  (there may be several) are kept on a time-ordered
  list.
• With each increment of sim time, this list is
  checked to see if the entity is supposed to do
  anything at the current time.
• Location-based
• If entities interact based on proximity, then
  maintain lists of entities region by region. As
  entities move from one region to another, they
  move to another list.
• When an entity is checked to see if it interacts
  with another entity at the current sim time, the
  lists of its region and possibly adjacent regions
  are scanned.
• Whatever-based whatever determined by needs
  of model

11
Time management

• Overhead often reduced if we skip time values
  when nothing happens
• If sim involves graphics, less opportunity for
  this
• A tank driving from point A to point B is
  depicted graphically as smoothly moving along a
  route
• Its location is a continuous variable
• Some simulation languages allow users to turn
  graphics on and off as desired.
• Generally runs much faster without graphics since
  can skip over periods of time when nothing
  happens.

12
Discrete Event Simulation Engine

• Any simulation has time management components
• Sim. lang. (Arena, GPSS, CSIM18, Simula) include
  a simulation engine that manages time
• Basic services of sim engine
• Manage (set) the simulation clock. sim. time is
  readable by
• user, but usually cannot be changed
• Advance time, that is, advance the simulation
  clock
• (again normally cannot be done be user)
• Ensure model actions occur when they should
• - Time-based some actions occur at a
  specified times
• E.g., store closes at 5 p.m.
• - State-based some actions occur
  whenever a condition
• holds whenever a blue
  tank is close to a red tank, it
• shoots

13
Sim Engine - Imp

• Basic language construct
• schedule( code, time), as in
• schedule( arrival, clockexp(5.0) )
• where clock is the current sim time and exp is a
  neg. exp. random var, arrival is some code that,
  say, checks to see if a server is avail, etc.
• Assume model consists of (and only of)
• initial event (initialization), including at
  least one schedule op
• set of event routines (like arrival above) that
  model what the system does when that event
  occurs.
• So the model consists entirely of events (chunks
  of code to be run at scheduled times) and a
  schedule op (for future events)

14
Sim Engine - Imp

• Each event routine has a name. Main thing making
  this a simulation is that events are scheduled to
  occur (run) at a particular sim clock time.
• Events change attributes of objects and perhaps
  schedule additional events by name and time.
• A basic data structure to support this is a
  priority queue (where event time is priority).
• Schedule op is an insert into a list ordered by
  the time at each event is to occur

15
A standard data structure Priority Queue

• Each entry has two fields
• Priority
• Data
• Operations
• Return and remove entry with highest (or lowest)
  priority
• Add a new entry
• Optionally return value of highest (or lowest)
  priority
• Think of this as a list with entries sorted by
  priority
• But whether to sort or not is an implementation
  decision
• Note 1 Its not a queue, i.e., not necessarily
  first-in, first-out
• Note 2 In simulation, its commonly called an
  events list because it contains a list of events
  and the time they occur. The times are the
  priorities of the priority queue

16
Sim Engine - Imp

• To do simulation, user writes an init routine and
  several event routines.
• Sim engine
• clock set to 0
• runs init event // it should put at least one
  event on events list
• while ( events list not empty )
• get next event (routine name and time) delete
  from list
• clock set to its event time
• run event code
• end while
• write report (maybe)

17
Discrete event simulation

• This approach is called discrete event simulation
  since
• Sim clock jumps from the time at which an event
  is scheduled to occur to the time the next event
  is scheduled to occur
• So time is not continuous it jumps for one value
  to the next as determined by the times at which
  events are scheduled to occur

18
Sim Engine - Imp 2

• What if the modeler thinks in terms of what
  causes actions rather than in terms of scheduling
  actions?
• CSL (for Control and Simulation Language) view
• Model consists of a collection of activities of
  the form
• condition
• initial set of actions
• time delay
• final set of actions
• Example (from a port sim)
• Condition
• (NumShipsWaitinggt0) (TugAvail)
  (NumBerthsgt0) (highTide)
• InitialActions
• NumShipsWaiting--
• TugAvail false
• NumBerths--
• TimeDelay
• wait TravelTime
• FinalActions
• TugAvail true

19
Sim Engine - Imp 2

• So each action typically consists of two parts
• contingent dependent on state, not time
• determined dependent on time, not state
• So two lists
• contingent
• things that need to checked to see if their
  conditions are met
• determined
• things that need to occur at a particular time

20
sim engine - imp 2

• call init
• UNTIL end-of-simulation DO
• // Run all possible contingent events before
  adv. clock
• UNTIL the contingent events list is empty OR
  every
• condition fails
• search the list, testing the condition of
  each entry
• if a condition is true
• from event from list
• run the code
• END UNTIL
• // Advance the clock
• clock time of first event on determined
  events list
• // Run determined events
• remove first event from determined events
  list
• call that code
• END UNTIL
• Note 1 assumes items are added to both list as
  needed.
• Note 2 some implementations do not keep the 1st
  list.

21

• END