Inside Discrete-Event Simulation Software: How It Works and Why It Matters

1. Inside Discrete-Event Simulation Software: How It Works and Why It Matters Thomas J. Schriber, Daniel T. Brunner WSC05’ Presented by Geng Yue Mar 24

2. Syllabus • 1. Nature of discrete event simulation • 2. Basic simulation constructs • 3. Entity states • 4. Entity management data structure • 5. Specific implementations • 6. Why it matters

3. 1. Nature of Discrete-Event Simulation • Event time: discrete; state: usually discrete • Transaction-flow world view: discrete units of traffic that move from point to point while competing for scarce resources • Two or more events often have to be manipulated at the same time point. How to order them? m1 l m2

4. Discrete-Event Modeling Languages • There are different implementations, which aim to provide convenience for modelers. • Arena for example, provides graphical user interface for the users to input the simulation model.

5. 2. Basic Simulation Constructs • Topics includes: • Entity – a unit of traffic • Resources – service machine • Control Elements – support delay or logical alternatives • Operations - an action for an entity

6. Model Execution • The simulation advances with the simulation clock, which advances when an event happens • Carry out all possible actions at the current simulated time -> advance the simulated clock; and repeat; initialize event list get next (nearest future) event from event list time = event time process event (change state values, add/delete future events from event list update statistics n done?

7. 3. Entity States • Active State: current moving state • Ready State: ready but wait due to limited resource • Time-Delayed State: entity waiting for a known future time so they can enter ready state • Condition-Delayed State: remove automatically when conditions permit • Dormant State: modelers set it

8. 4. Entity Management Structure • Active State – kept in a list • Ready State – in current event list • Time-Delayed State – in future event list • Conditional-Delayed State – delay list • Dormant State – user-managed list • All these lists are used to store data and provide easy access to their elements

9. 5. Different Implementation in Tools • The paper together with its WSC96’ version gives 6 representative implementations. • Two examples here: • AutoMod, version 9 (Phillips 1997) • Siman, the core of Arena • To get some intuitive, refer to “A Simple Simulation Language: simlib   P114” of the text book, which is around 30KB in C

10. AutoMod Language

11. Siman Language • It is the engine for Arena.

12. 6. Why It Matters • Trying to re-capture a resource immediately • The first in line is still delayed • Yielding control • Conditions involving the clock • Mix Mode Waiting

13. Why It Helps and Performance Issues • Why it helps: interactive model verification • Performance: given the same model, computer time depends on the design and implementation of the software used to build the model