Simulation Modeling

Learning Objectives

• To be able to describe what computer simulation is
• To be able to discuss why simulation is an important analysis tool
• To be able to list and describe the various types of computer simulations
• To be able to describe a simulation methodology

What Is Simulation?

• A simulation model represents a system so that it mimics the system’s pertinent outward qualities.
• Executing the model is performing a simulation — often the next best thing to observing the real system.
• With a credible model, we infer how the real system will behave, then use that inference to understand and improve performance.
• Standard definition: a numerical technique for conducting experiments on a computer, using logical and mathematical relationships that describe a system’s behavior over time.
• Computer models add a layer of abstraction — full control, plus constructs a physical simulation cannot offer (e.g. emergency conditions in a flight simulator).
• The first rule: a simulation is only a model of the real thing — never confuse the model with the system.

Why Simulate? The Emergency Department

• Patients arrive randomly (varying by day and hour); triage sends critical patients to a bed, others to admitting and a waiting room.
• Care requires shared doctors, nurses, beds, and equipment (MRI, X-ray); patients are eventually discharged or admitted.
• Typical measures of performance:
  • Average number of patients waiting; average waiting time and total time in the department
  • Average rooms required per hour; average utilization of doctors and nurses
• We cannot experiment on the real system without endangering patients — so we model it and test changes on the model.
• Analytical queueing models fall short here: complex policies for allocating doctors, nurses, and beds, plus dynamic non-stationary arrivals, exceed their capability.

When Is Simulation the Right Tool?

• Prefer simulation when the understanding gained is worth the time and cost of building and running the model.
• Good uses of simulation include:
  • Understanding how complex interactions and randomness affect performance
  • Comparing a fixed set of design alternatives against performance goals
  • Training people to prepare for disruptive events
  • Models used repeatedly for decision making, or for high-cost decisions
  • Designing a system that does not yet exist to ensure it meets specifications
• Key strength: simulation can model the entire system and its complex inter-relationships — capturing complexity too costly or risky to experiment with directly.

Descriptive, Predictive & Prescriptive Modeling

• Simulation encapsulates all three modeling methods of data analytics:
  • Descriptive — uses historical data to describe what happened
  • Predictive — uses data to anticipate what may happen
  • Prescriptive — indicates what should be done (system design)
• A simulation model is both descriptive and predictive; coupled with optimization or a rigorous design process, it becomes part of prescriptive modeling.
• It describes how a system works, uses descriptive input models, and predicts future response through what-if scenarios.
• Unlike regression, neural networks, or random forests, simulation explicitly encodes domain knowledge — the physical and logical rules relating components, not just discovered correlations.

Simulation for Prescriptive Analysis

• Although descriptive at heart, simulation can prescribe a solution by conveying the required behavior of a proposed system.

• The simulation model predicts behavior; input models characterize the system and its environment.
• An evaluative model compares output to goals; an alternative generator proposes scenarios; feedback revises the inputs toward a recommended solution.
• Example: size a drive-up pharmacy so that P(wait > 3 minutes) < 10% by varying the number of pharmacists.
• Complex problems (hundreds of inputs, competing objectives) call for simulation optimization and heuristic search.

What Is a System?

• A system is a set of inter-related components working together toward a common objective.
• It is embedded in an environment, taking inputs and producing outputs through internal components.

• How you model a system depends on the model’s intended use and how you perceive the system.
• Setting the boundaries drives the level of abstraction — e.g. does the ED model include ambulance dispatch or the operating room?
• Two rational people can conceptualize the same thing as two entirely different systems, based on their world view.

Classifying Systems

• Man-made vs. natural; physical vs. conceptual.
• Deterministic vs. stochastic — is random behavior an important component of the system?
• Static vs. dynamic — does the system change significantly with respect to time?
• A dynamic system is discrete if its state changes at discrete points in time, continuous if the state changes continuously.
• The discrete/continuous distinction is purely a function of your level of abstraction.

• This book primarily examines stochastic, dynamic, discrete systems.

System State & Variables

• The state of a system is the set of variables that describe it at any time: \(\{x_1(t), x_2(t), \dots\}\).
• Discrete variables take a countable set of values; continuous variables take an uncountable (real-valued) set.
• The variables in the state determine the system type — consider an airplane:
  • Number of parts operating to spec (0/1) → a discrete system
  • Temperature of each part → a continuous system
  • Velocity plus number of wheels deployed → a combined system
• When the state changes only at discrete points in time, we call those points events.

Discrete-Event vs. Continuous Simulation

• Discrete-event: observations are gathered only at selected points in time when changes occur — these points are events.
• Continuous: the system is described for all points in time, often via differential equations integrated step-by-step.
• Fast-food counter — queue length and waiting time change only when a customer arrives or is served → observe at discrete points.
• Oil tanker loading — the oil level flows continuously and cannot be divided into discrete pieces → a continuous model.
• Combined continuous-discrete modeling mixes both: a tanker arrival event plus continuous filling.
• This book uses discrete-event simulation models.

Randomness in Simulation

• Arrival and service processes usually occur randomly — to simulate a system, we must be able to model that randomness.
• Model each random phenomenon as a random variable governed by a probability distribution (e.g. Poisson arrivals imply exponential inter-arrival times).
• Characterize the randomness through direct observation, historical data, or plausible assumptions.
• With historical data, prefer fitting a probability model over driving the simulation directly from the raw data.
  • Replaying one day’s data is not simulating different days.
• Given a probability model, random samples are generated from uniform (0,1) random numbers to place future events on the time scale.

A Simulation Methodology

• Built on the general DEGREE problem-solving steps, specialized for simulation into five phases:

1. Problem Formulation — define the problem and system, establish performance metrics, build a conceptual model, document assumptions
2. Simulation Model Building — model translation, input data modeling, verification, and validation
3. Experimental Design & Analysis — preliminary runs, final experiments, analysis of results
4. Evaluate & Iterate — documentation, model manual, user manual
5. Implementation

• Iterate: start with small models that work, then build up until the desired fidelity is reached — don’t try to model the world.

The Five Phases of the Methodology

The DEGREE-based simulation methodology

Verification vs. Validation

• Verification — does the program perform as intended?
  • Debug and locate coding errors: improper flow control or entity creation, failure to release resources, logical/arithmetic or statistics errors
  • Repeat scenarios with identical random-number seeds, stress the model via sensitivity analysis, and test individual modules
• Validation — does the model adequately represent the real system?
  • Review the model with personnel familiar with the system to judge realism
  • Statistically compare model output to real-system output for significant (and practical) differences
• These receive limited emphasis in this text (educational examples), but both are essential in professional practice.

Simulation Languages & Why Kotlin/KSL

• Discrete-event simulation involves a tremendous volume of computation and a complex logical structure — computers are essential.
• Writing it from scratch in a general-purpose language (C/C++, Java, Kotlin) demands above-average programming skill.
• The repetitive mechanics — event ordering, random-number generation, automatic statistics collection — are ideal for a library.
• Simulation tools range from programming-oriented (SIMSCRIPT) to drag-and-drop (Arena, ProModel), trading flexibility against ease of use.
• Kotlin was chosen for its ease of use and available open-source libraries; the KSL (Kotlin Simulation Library) supports both the event-view and the process-view.

Overview of the KSL

• The KSL (Kotlin Simulation Library) is a framework of Kotlin classes that facilitate discrete-event simulation modeling.
• Free, open source under the GPL license; a JVM-based Kotlin library hosted at rossetti/KSL on GitHub.
• Organized as two open-source projects:
  • KSLCore — the main project with core development functionality
  • KSLExamples — the textbook examples plus additional illustrative examples
• KSLProjectTemplate is a separate Gradle starter project preconfigured to use the KSL as a dependency.
• KSLCore packages support random number generation, statistics, reporting, and discrete-event modeling via both views.
• Purpose: support education and research — clearly demonstrating how simulation works rather than leaving it a black box.

A First KSL Program

• Generate normally distributed data, collect statistics on it, and print a summary report.
• To use classes from a library, you must import them.

import ksl.utilities.io.StatisticReporter
import ksl.utilities.random.rvariable.NormalRV
import ksl.utilities.statistic.Statistic

fun main() {
    // a normal random variable: mean = 20.0, variance = 4.0
    val n = NormalRV(20.0, 4.0)
    // a Statistic collects and summarizes the observations
    val stat = Statistic("Normal Stats")
    val data = n.sample(100)
    stat.collect(data)
    // StatisticReporter pretty-prints statistical summaries
    val reporter = StatisticReporter(mutableListOf(stat))
    println(reporter.halfWidthSummaryReport())
}

• NormalRV creates the random variable, Statistic collects the data, and StatisticReporter formats the output.

Simulation as a Profession & Key Takeaways

• Simulation is a career path — your learning is only getting started; get involved through the Winter Simulation Conference and societies (INFORMS-SIM, ACM/SIGSIM, IEEE/SMC, SCS).
• Selected rules of good professional practice:
  • Only study problems with clearly defined objectives and performance metrics
  • Never simulate when a simpler, more direct technique will solve the problem
  • Never accept results based on a sample size of one — report the sample size, average, and a measure of variation
  • Use a tested random-number generator and take steps to mitigate initialization bias
  • Always verify and validate your models
• Remember the first rule: a simulation is only a model — but a powerful one for understanding and improving systems.