Methodology

One model, three ways to run it

Each simulation has a single model file written in plain JavaScript with no dependencies. The interactive page imports it, and the downloadable simulation.js is the same file with a command-line runner attached, so the page and the package cannot drift apart. The code excerpts on each page are extracted from that file at build time rather than copied by hand.

The Python port, simulation.py, is written line by line against the JavaScript model and uses only the standard library.

Reproducible randomness

All stochastic models draw from one pseudo-random generator, xoshiro128**, implemented identically in both languages (see pseudo-random numbers and seeds). Every model takes a seed; the default is 42. The same seed produces the same run on the page, in Node and in Python.

That claim is tested, not assumed. Before every release, each package is run in Node and in Python with the default parameters, with a second seed, and with a second set of parameter values, and the summaries and full result tables are compared. A package whose two implementations disagree fails the release check. Where a model uses functions whose last-bit results can differ between runtimes — relevant only for chaotic systems — the model documents how it avoids or bounds the difference.

Checking against theory

A simulation that runs is not necessarily a simulation that is right. Each model has automated tests of the properties its mathematics guarantees, for example:

• conservation laws — S + I + R = N in the SIR model, the invariant of the Lotka–Volterra system, energy in an undamped oscillator;
• exact results — the final-size equation of an epidemic, Black–Scholes prices, Erlang C waiting probabilities, the birthday-problem product formula;
• statistical behavior at large sample sizes — estimates within a few standard errors of the known value;
• structural properties — transition probabilities that sum to one, a glider that moves one cell diagonally every four generations;
• regimes where a formula stops applying — a queue with arrival rate at or above its service rate is reported as unstable rather than given a steady-state average.

Pages also show these checks to the reader as outputs, such as numerical drift in a conserved quantity or the simulated value next to the theoretical one.

Numbers on the pages

The “Example result” on every page, the readouts shown before the page’s script runs, the model.json example and the example.csv file are all produced by running the model with its default parameters and seed 42 during the build. Result numbers in the explanatory text are filled in from that run rather than typed. The output of the SimPy examples in SimPy examples was produced by running them with the stated library version.

Numerical methods

• Differential-equation models use the classical fourth-order Runge–Kutta method with a fixed step, chosen so that halving it does not change the reported results materially. Euler vs Runge–Kutta explains the choice.
• Queueing models are discrete-event simulations with an explicit future-event list.
• Continuous random quantities are sampled exactly where possible (exponential gaps, normal increments), not approximated by small time steps.

Sources

Explanations are based on the original papers, standard textbooks and official documentation, listed under References on each page. Papers are linked by DOI where one exists. References are included only when their details have been checked; nothing on the site cites a source for a claim the source does not make.

Limits of simplified models

Most models here are the simplest version of an idea: homogeneous mixing in an epidemic, constant volatility in a stock-price model, identical agents in a segregation model. Simplicity is the point — it exposes the mechanism — but it means the models are for understanding and experimentation, not for forecasting real epidemics, markets or cities. Each page has an “Assumptions & limitations” section that says what its model leaves out.