Clarifying Scientific Concepts Part 10: Simulation

Simulation Modeling

The advent and proliferation of computing, programming languages, and software has undoubtedly had a significant impact on the way science is carried out. Simulation modeling is now quite indispensable within the toolkit of the modern scientist. I would go so far to say that you simply cannot do modern science without the aid of a computer in one form or another. This is true for physical sciences and biological sciences as well as social sciences; even non-traditional scientific disciplines like quantitative finance. In fact, most of my initial experience in this during grad school came through studying stochastic processes in financial engineering courses, in addition to Monte Carlo Methods in Bayesian statistics and state space modeling in economics (as well as DSGE models). Since then, I've been interested in simulating social complexity via agent based models. Most modeling cannot be done unless within the context of computer simulation, which requires knowledge of algorithms, data structures, and computational complexity, for understanding how to implement your model. This is obviously a prolific aspect of science. So in this section, I want to describe the function of a simulation, how it augments the scientific toolkit, and various simulation methods, ones that I am more familiar with given my education and work experience.

When we simulate, we are simulating some process or system. This shows it's generality, because we can essentially represent just about anything as a system or process, which means we can describe the properties, components, relationships, behavior, dynamics and architecture of just about any system computationally; allowing us to reason about the real system under discussion in a controlled setting. A simulation is an imitation of the dynamics of a real-world process or system over time. This computational representation is studied, like non-computation models, for a variety of tasks including: "what if" analysis, scenario analysis, intervention analysis, stress testing, modification, or pretty much anything else. The alternative approach to simulation is direct experimentation, which is infeasible in many situations. Simulations are often cheaper, faster, more likely to be replicated, safer, and ethical. In many cases it's also just practically impossible to model as system mathematically with closed form solutions; systems are often intractable and too complicated to solve. Approximations via simulation tend to be much more suitable for rapid experimentation. Like any model, it is not assumption free; these assumptions are encapsulated in our formulation of the model. Simulation models allow us to modify our assumptions and test the implications.

These models are essential for engineering any system with significance. Consider the car you use, how did the engineers determine it's reliability? They used simulation methods to guide the design process. How do airlines have such high reliability? The use simulations to understand how the plane will operate under a variety of scenarios, this influences their design decisions. How does the airline ensure timely arrival of planes and coordinate thousands of daily trips? They use simulation methods, among other methods like optimization. How did researchers identify a vaccination so quickly during the COVID pandemic? This is multifaceted, and involves simulation at every step. Supercomputers like those at Lawrence Livermore National Laboratory were used for rapid drug discovery. Identifying an effective drug involves discovering a molecular structure. You can imagine the combinatorial explosiveness of the search space; doing this purely by gathering information from experiments is simply not feasible for rapid turn discoveries. Supercomputing allows you to simulate the effectiveness of a proposed structure, narrowing down the search space for researchers, allowing them to identify an effective structure more quickly by searching more dense regions of probability space. In addition, simulations were used for epidemic forecasting. Country level microsimulations quantified how distancing, lockdowns, and closures could keep hospitals from being overwhelmed. Suppose you have normal capacity at a hospital, with limited ability to scale; massive stress on that system might overwhelm it, leading to excess deaths. Therefore, from a policymakers perspective, they might want to know these counterfactual situations, and adjust their policy accordingly. Closures were also determined based on simulations. Airflow models revealed how respiratory particles move indoors, guiding ventilation, filtration, and layout choices, and which facilities are likely locations to have a massive outbreak, which subsequently impacts hospital stress. In each of these cases, simulations gave us usable answers while experiments and trials were still spinning up. This particular problem, shared among many complex problems, often involves systems of systems. Modeling and simulation allows researchers to understand how various systems interact; we can effectively integrate multiple models of systems to understand how they all interact. This is something that is very difficult without the use of computational resources. Supercomputers enabled the possibility of rapid computational experimentation, which lead to effective decision support. Put simply, computer simulation has a direct impact on the policy that effects your life.

There are essentially 3 x 2 types of simulations. Think of it as a grid, where each cell represents a combination of the various elements of a simulation. There are stochastic vs deterministic simulations, static vs dynamic simulations, and discrete time/event vs continuous time/event simulations. So you can have a discrete time dynamic stochastic system, a stochastic continuous time continuous event simulation, a deterministic dynamic time discrete event simulation etc. Each of these dimensions represent different aspects of the system under discussion. Stochastic systems have random components, dynamical systems are time dependent, and continuous systems are those where the system state can be represented numerically as a non-finite number. On the contrary, deterministic systems do not contain randomness, static representations do not depend on time, and discrete representations refer to systems where the states can be represented as a finite number. Each combination implies different sets of methods. It is entirely up to the research to decide how to model the system, but the decision is not arbitrary. Sometimes it is just easier to represent a system statically, this is often the case in economics. Introducing more moving parts makes the system harder to understand, so researchers must find a sweet spot between model complexity and granularity, and how well it answers questions. For example, in economics we have DSGE models that rely on the "representative agent". This is a sort of idealization about how people make decisions in an economy, imposed upon the entire collection of agents; the "representative agent" represents how everyone who is "rational" would make economic decisions. It assumes away any underlying network structure and heterogeneity. It idealizes the economic decision independent from other factors. This form allows us to have nice compact modeling formulations that are solvable or easy to reason about. But obviously, it does not have to be done this way. Agent based models on the contrary, allow the modeler to encode heterogeneity. We can then run simulations "from the ground up", and use these results to reason about a real world economy. This also comes with its own set of costs and sacrifices. These models are harder to validate and make sense of. Therefore, decisions to represent systems depend upon these considerations.

What are the elements of a simulation model? Well, it depends on the type of model and the domain you're studying. This taxonomy will be biased towards discrete event simulations, but I think pretty much every simulation will implicitly refer to these elements. There are two objects of simulation:

• Entities: individual elements of the system that are being simulated and whose behavior is being explicitly tracked. Each entity can be individually identified;
• Resources: also individual elements of the system but they are not modelled individually. They are treated as countable items whose behavior is not tracked.

These decisions are made by the modeler, and depend on the system under discussion. How do we organize the entities and resources?

• Attributes: properties of objects (that is entities and resources). This is often used to control the behavior of the object. In a more comprehensive simulation, an attribute might be the type of features that distinguish entities.
• State: collection of variables necessary to describe the system at any time point. These fully characterize the system. For example, in a queuing system, it might be wait time.
• Queue: collection of entities or resources ordered in some logical fashion. This refers to how the entities are processed within the system

There are certain actions available to the entities, which change state. Below are terminology that refer to these operations:

• Event: instant of time where the state of the system changes. An event describes the possible ways the state can change, and locates the time in which that change took place.
• Activity: a time period of specified length which is known when it begins (although its length may be random). This may be specified in terms of a random distribution.
• Delay: duration of time of unspecified length, which is not known until it ends. This is not specified by the modeler ahead of time but is determined by the conditions of the system. Very often this is one of the desired output of a simulation.
• Clock: variable representing simulated time.
• Processes: a type of event that has start-end rules with, including decision logic, policies, and control rules.

Exogenous factors can be modeled; for example, demand for a product (assuming the firm has no external influence on its demand) can be used to simulate stress and bottlenecks on a system. These often have corresponding probability distributions. Simulation models are initialized with initial state and have a determined run length or stop criteria, since we can't model simulations indefinitely. State variables are often analyzed or turned into metrics, so we can reason quantitatively about the system behavior over time, and how the system responds to exogenous factors or parametric adjustments. These are useful for V&V (verification and validation), important aspects of the entire modeling process. This formulation is discrete event focused, but System Dynamics also tracks this approach; except we are interested in things like stocks, flows, and feedback loops which often requires differential or difference equations.

When engaging in modeling and simulation, you typically follow a pattern a common pattern. The workflow below works for discrete-event and agent-based models, system dynamics, Monte Carlo risk models, and hybrid approaches.

1. Frame the decision and the system: Start with the decision you want to inform: “Should we add a second checkout?”; “How sensitive is revenue to demand volatility?”; “What policy reduces infection peaks?”. Then declare the scope, what’s inside your model (entities, resources, policies) and what is exogenous (arrivals, prices, weather). State performance measures you’ll report (e.g., mean wait time, 95th-percentile queue length, throughput, cost, peak prevalence). Finally, capture success criteria: the level of accuracy, speed, and confidence you need for the simulation to be useful.
2. Build the conceptual model:
   • Entities and states: What things move or change (patients, packets, orders, molecules)? What states can they occupy (waiting, in service, recovered, failed)?
   • Processes and rules: How do states change—by scheduled events (arrivals, service completions), by interactions (agent meetings), or by continuous flows (stock-and-flow)?
   • Time treatment: Decide if you advance time by events (jump to next event; classic discrete-event), by fixed steps (∆t; good for differential equations or when events are dense), or hybrid (event-driven with sub-stepping for continuous parts).
   • Resources and constraints: Servers, machines, beds, CPU cores, budgets. Specify capacities, calendars, and priorities.
   • Randomness: Where uncertainty lives (interarrival times, service durations, agent behaviors, failure times) and how you’ll model it (distributions, correlations).
   • Policies and controls: Schedules, routing rules, admission limits, pricing, triage—these become the levers for scenarios.
3. Input modeling: turn messy data into usable distributions: Simulations are only as credible as their inputs. Collect data (logs, sensors, EMR, telemetry) and clean it. For each stochastic input, decide whether to use empirical distributions (sample with replacement), parametric distributions (fit exponential, lognormal, Weibull, etc.), or mechanistic sub-models (e.g., time-of-day Poisson rate). Check goodness-of-fit (visual QQ plots and CDF overlays are often more informative than a single p-value). Model seasonality and trends explicitly (piecewise rates or time-varying parameters), and capture dependence if it matters (copulas, shared random seeds, correlated draws). Document assumptions you cannot measure.
4. Choose a paradigm:
   • Discrete-event simulation (DES): Best for queuing, logistics, manufacturing, networks. You maintain an event calendar, a future event list, and process handlers that update state and schedule downstream events. You observe sharp changes at discrete times (arrivals, completions).
   • Agent-based simulation (ABS): Best when micro-level behavior and interaction drive macro outcomes (epidemics, social systems, markets). Each agent carries rules; the system emerges from interactions. Often run with small time steps or event hooks.
   • System dynamics (SD): Best for feedback-heavy, aggregate systems (stocks, flows, delays). You write coupled differential or difference equations and integrate in time.
   • Monte Carlo (MC): Best for pure uncertainty propagation: sample inputs, evaluate a deterministic model, aggregate outputs. Often baked into other paradigms.
5. Implement a Minimal Version: Write the minimal version that runs end-to-end: initialize state, advance time, process one or two event types, stop cleanly, and produce a single metric. Only then add detail. For DES, implement: (a) a priority queue for the future event list; (b) handlers that update system state and schedule new events; (c) resource logic (seize, wait, release) with queue disciplines and priorities. For step-based models, implement a stable integrator and verify simple invariants (non-negativity of stocks, conservation of mass).
6. Verification: prove you built the model you meant to build: Verification is about correctness of implementation. Use unit tests for event handlers and resource logic; seed the RNG and check exact outcomes on toy cases. Run extreme scenarios (infinite capacity → zero waiting; zero arrivals → idle servers) and check that outputs hit obvious limits. Step through the first few events by hand and ensure your trace matches logic. If you refactor, keep these tests to prevent regressions.
7. Validation: prove the model is a good stand-in for reality: Validation compares model outputs to real system behavior or to accepted theory. Start with face validity: do SMEs agree that queues and bottlenecks look right? Then do historical fit: feed the model observed inputs and compare outputs (means, percentiles, time series structures). Where you lack data, check theoretical limits. If discrepancies persist, adjust structure before tuning parameters; calibration should be the last mile, not a crutch.
8. Experiment design: plan runs that answer the question: Simulations are experiments. Define scenarios (policy sets), factors, and responses (KPIs). Decide warm-up period (discard initial transient until the system reaches steady behavior), run length (long enough to stabilize averages or cover cycles), and replications (independent runs with different seeds). Use common random numbers (setting a seed) to reduce variance when comparing alternatives: drive scenarios with the same underlying randomness to isolate policy effects. For broad sensitivity, consider factorial designs, Latin hypercube sampling, or Sobol sequences to explore the space efficiently.
9. Randomness, variance, and confidence: Stochastic outputs need uncertainty quantification. For each scenario, compute point estimates (means, percentiles) and intervals (confidence intervals for means via batch means or replication-deletion; bootstrap for quantiles). Report not only averages but also distributions and tails if risk matters. If estimates are too noisy, apply variance reduction techniques: CRN (for comparisons), antithetic variates (use paired negatively correlated streams), or control variates (leverage a correlated, known-mean statistic to shrink variance).
10. Sensitivity, uncertainty, and robustness: Test how conclusions change when inputs shift. Vary fitted parameters within their uncertainty (e.g., confidence regions of arrival rates) and plot how KPIs move; this guards against overconfidence in a single fitted distribution. Run global sensitivity when many inputs might interact. Summarize results in terms a decision-maker can act on: “Across plausible demand and service variability, adding one nurse reduces the 95th-percentile wait by 18–27%.”
11. Prepare results for presentation: Presentation matters. Show (a) the question; (b) the conceptual picture; (c) key assumptions; (d) validation checks; (e) experimental design; (f) results with uncertainty; (g) the recommendation. Use counterfactual comparisons (“Policy B vs A”) and keep plots honest: label warm-ups, show intervals, avoid over-precision. Include a model card: version, seed strategy, input sources and dates, known limitations, and intended use.
12. Reproducibility and governance: Fix a random seed policy (e.g., separate streams per process/entity class), lock software versions, and write a one-command script/notebook to rerun experiments. Check the model into version control with tests and the conceptual spec. If the model informs material decisions, add model risk controls: peer review, change logs, and periodic re-validation when the real system drifts. There are common errors or red flags you must consider when evaluating simulation models. For example, over-modeling detail you cannot validate; using a single replication; comparing scenarios with different random streams; hiding uncertainty; and skipping the conceptual model. The antidotes are baked into the steps above: minimal viable model first, disciplined input modeling, seeded replications, and transparent validation.

For centuries, science advanced through a conversation between theory (general laws that explain) and experiment (careful interventions that test the theory). Computation adds a third voice: it makes consequences of theories calculable and creates experimental worlds we can manipulate when the real one is too slow, too fast, too distant, or too dangerous. It fundamentally reshapes what counts as evidence, how we reason about mechanisms, and the pace at which we discover them. Many theories are expressed as equations with no closed-form solutions. Numerical methods—finite elements for materials, lattice Boltzmann for fluids, MCMC for Bayesian inference, agent-based updates for interacting systems—turn those tough theories into executable models. Running them becomes a kind of experiment: we “prepare” initial conditions, “apply” perturbations, and observe outcomes with virtual sensors. Climate models, collisionless galaxy simulations, or whole-cell models are not thought experiments; they’re computable laboratories where we can ask counterfactuals no wind tunnel or telescope can reach. Classic experiments test a handful of conditions. Computation makes parameter sweeps routine: thousands of runs mapping where a mechanism holds, fails, or bifurcates. It also enables simulation-based inference; when the likelihood is intractable but we can simulate from a model, we compare simulated and observed patterns to estimate parameters or even select models. This widens the scope of testable theories, especially in ecology, epidemiology, and parts of the social sciences where controlled experiments are scarce.

Because runs are cheap relative to fieldwork, we can search vast design spaces: new materials with targeted band gaps, synthetic pathways with lower energy cost, or intervention policies that flatten epidemic peaks. Surrogate models and emulators (e.g., Gaussian processes, neural operators) compress expensive simulations into fast predictors, turning day-long computations into millisecond queries and allowing automated experiment planning: the machine proposes the next promising condition, we compute or measure it, and the loop continues. This extends to what is known as "The Fourth Paradigm" of science. Computation fuses mechanistic models with machine learning: physics-informed networks that respect conservation laws; Bayesian calibration that quantifies parameter uncertainty; data assimilation that corrects forecasts on the fly. The result isn’t just better prediction; it’s stronger explanations because the space of plausible models is continuously pruned by both data and constraints. With code acting as an instrument, credibility depends on how we build and check it: verification, validation, and uncertainty quantification. Because the “experiment” is code, reproducibility has a precise form: share the code, the random seeds, the data, and the environment. Version control, containers, notebooks, and workflow managers turn papers into executable artifacts. This raises the bar: claims must survive re-runs, re-fits, and re-perturbations by others, not merely rest on prose descriptions of a setup. Computation gives us algorithmic instruments and precision that reveal signals no human eye could extract unaided. Good computational science is explicit about limits, documents assumptions, and triangulates across theory, simulation, and empirical data.

The day-to-day workflow has changed. Instead of a long wait between theory and a few decisive experiments, we iterate rapidly: sketch a mechanism → code a minimal model → test on stylized cases → confront with data → refine. This cadence accelerates theory building (by surfacing edge cases and counterexamples early) and sharpens experimentation (by making pre-registered predictions and power analyses simulation-aided). Computation doesn’t replace theory or experiment; it mediates between them. It makes theories executable, experiments interpretable, and both of them scalable. When we treat code as a first-class scientific instrument—with rigorous verification, validation, and uncertainty quantification—we get a third arm strong enough to lift questions that were previously out of reach.