CRD503 Week 1: Why model crowds: from disasters to defensible synthetic ground truth

What this field is — in one sentence

Crowd dynamics simulation is the science of using a computer to predict how groups of people move, so that engineers can make buildings and events safer before anyone is hurt. Everything in this course is detail underneath that single sentence.

This is the opening week of CRD503, and it assumes no simulation background at all. The only prerequisites are comfort with Python and a willingness to reason about numbers. Before we touch any mathematics, we ask one question: why does this field exist? The answer is concrete, and it is grim. It is written in death tolls and coroners' inquiries, and in the slow recognition that a crowd of ordinary, freely-moving people can — under the wrong geometry and density — become a collectively lethal system that no single person intended to create. From that recognition come three distinct engineering jobs for a crowd model. By the end of this week you will be able to tell those jobs apart, say which course goal each serves, and read the first real numbers the course works with: a three-point density-and-speed dataset the lab produced with its own crowd-simulation tools.

The words you need

A handful of terms recur all semester. Each is defined here in plain language; none requires memorising, because every one comes back in context.

Crowd — many people sharing a space at the same time.
Density — how crowded a spot is, measured in people per square metre. This is the workhorse term of the whole course.
Simulation — a computer imitation of reality, used to test ideas safely.
Ground truth — the real, correct answer you check a guess against.
JuPedSim — a free, open-source pedestrian crowd video-game engine. You hand it a floor plan and a set of walkers with destinations, and it computes, step by step, where each person walks. Think of it as a tiny but realistic crowd video game.
PedPy — a companion tool that reads the walking paths JuPedSim produces and reports two plain numbers for each moment: how crowded it was (density) and how fast people moved (speed). Think of it as the scoreboard that watches the game and writes down the result.
Fundamental diagram — the curve showing how walking speed changes as a space fills up. As density rises, speed falls. It is the single most important pattern in this field, and we build it up from a traffic-jam picture before any equation appears.
Voronoi — a way of splitting a floor so that every point belongs to its nearest person, giving each person a patch of floor to "own." We draw this picture before we use it.

Two of these — fundamental diagram and Voronoi — look intimidating and are in fact simple. You will meet a concrete everyday picture for each before any symbol is introduced.

Why bother: crowd deaths are physics, not panic

Crowd fatalities invite a natural misdiagnosis. Reports after an incident reach for words like "panic", "stampede", or "surge", and those words point blame at individual behaviour — as if the crowd somehow chose to be dangerous. The scientific record tells a different story. Across more than thirty large crowd disasters since 1945 — together accounting for over 4,000 deaths and tens of thousands of serious injuries — the victims were, in most cases, not killed by an external hazard but by the physics of the crowd itself. When density crosses a critical threshold, even small involuntary body movements pass force from person to person. Shock waves form. People lose their footing. Anyone who falls becomes an obstacle, and the pressure of the people behind cannot be resisted by will alone.

Hold onto that reframing: physics, not panic. It is the intellectual foundation of everything that follows.

Three disasters anchor the course, and each one asks a different question of a simulator.

Hillsborough, Sheffield, 1989. At an FA Cup semi-final, 96 people died in a section of standing terracing that became fatally overcrowded in the opening minutes of the match. Hillsborough is the canonical demonstration that pressure build-up in a densely packed crowd is a life-threatening physical force on its own, independent of any external threat. The dangerous variable was not the total stadium capacity but the local density in a bounded pen fed by an undersized access tunnel. A simulator that can resolve local density and pressure can reproduce the preconditions; one that only counts heads misses the mechanism entirely. The question it asks a simulator: at what local density does a bounded section become lethal?

Mina, Mecca, September 2015. During the Hajj pilgrimage, at the Jamarat Bridge stoning ritual, two crowds met head-on at a narrow junction and produced casualty counts exceeding 2,000 by independent estimates — among the deadliest crowd disasters on record. The geometry was not new: catastrophic accidents had occurred at the same site in 1990 (over 1,400 deaths), 1994, and 1998, and the site had been substantially rebuilt in between. That the hazard persisted despite physical redesign is the lesson: changing the geometry does not guarantee safety unless its effect on density and pressure is quantitatively checked. The question it asks a simulator: can pilgrims be re-routed before density crosses the lethal threshold?

Seoul Itaewon, October 2022. In the Itaewon neighbourhood of Seoul during Halloween, at least 159 people died in a crowd crush when large numbers of revellers funnelled into a narrow sloping lane from several directions with no crowd management in place. This was not a stadium with a single entrance funnel but an outdoor street network — exactly the class of geometry for which simulation-based planning tools have been developed. It is also the disaster that motivates this course's hardest goal: responders could not act because no sensing system had been trained to recognise dangerous crowding, and you cannot ethically stage a real crush to collect training data. The question it asks a simulator: how do we build and train a sensing system before the next festival?

Taken together, the three cases make a structural argument. Deaths arise from density-driven force, and density is governed by geometry, by how fast people enter, and by how they are routed. All three are inputs to a crowd simulation. So the question a simulator is built to answer is: given this geometry, these flows, and these routes, where and when does density exceed safe levels, and what design or management change reduces it?

One model, three jobs

The same simulator gets used in three very different ways. They share the underlying tool but differ in what counts as a useful output and what "correct" even means.

Safety assessment. Here a model checks whether a planned or existing venue can carry its design load without producing locally dangerous densities. The outputs are density maps, pressure over time, and evacuation-time estimates under normal and emergency conditions. This was the original motivation for crowd simulation: planning a pedestrian facility by conventional rules of thumb does not guarantee you avoid jams and blockages, especially in an emergency. The job needs the density and pressure physics to be qualitatively right. This course goal is served by understanding what the simulator computes and where its limits lie.

Facility design. Here a model is used not to audit a fixed design but to improve one. The classic example is a counter-intuitive result: placing a column just upstream of a bottleneck can increase the flow through it under panic-like conditions by around thirty per cent. Finding such non-obvious fixes requires a model that captures collective self-organisation — lane formation, zipper effects, clogging oscillations — which only some simulators reproduce. The job needs the relative flow between competing designs to be right. This goal motivates Weeks 4 through 6, which vary geometry and read off the resulting changes in flow and density.

Synthetic ground truth for sensing. Here a simulator that faithfully reproduces how people walk is used to generate labelled crowd data at any scale, density, and geometry we want. For researchers building wireless sensing systems — inferring occupancy from WiFi or Bluetooth — real labelled data is expensive, ethically constrained, and tied to one building: a dataset gathered in one place cannot simply be reused elsewhere. A trustworthy simulator removes that constraint. The job needs the trajectory statistics — how far apart people stand, how fast they walk, how speed depends on density — to match real measurements. This is the strictest of the three tests, and it is the one this course evaluates most rigorously. It is served by Weeks 8 through 12, and its validity rests on a condition Week 10 formalises: the simulated paths must be validated against real pedestrian behaviour before the substitution is honest. This week introduces the requirement; later weeks supply the evidence.

The three jobs of a crowd model. One simulator serves all three, but each defines "correct" differently — qualitatively correct physics for safety, correct relative flow for design, and trajectory statistics that match reality for synthetic ground truth. The third, this course's primary target, is the strictest.

What the tools actually measure

JuPedSim plays out the crowd: at each instant, every walker picks a direction and speed given its destination, the walls around it, and its neighbours. The collective result is the set of phenomena crowd engineers care about — people forming lanes in two-way flow, clogging at a bottleneck, and the slowdown as a space fills, which is next week's subject.

PedPy then reads those walking paths and turns them into numbers. The measurement at the heart of this course is Voronoi density. Picture drawing a map of the floor so that every point belongs to the nearest person; each person ends up owning a patch. A tiny patch means a tightly packed neighbour, so a person's local density is simply one divided by their patch area. Written out, for person i with patch area |A_i|:

\rho_i = \frac{1}{|A_i|} \qquad [\text{people per square metre}],

In plain words: give every person the patch of floor nearer to them than to anyone else; a small patch means a crowded neighbour, so one-over-area is that person's local density. (The Greek letter \rho, "rho", is what we write for density throughout the course.)

Averaging over the N people in the measurement region gives the room's density at that instant, \bar{\rho} = \frac{1}{N}\sum_{i=1}^{N} \rho_i.

This per-person measure is preferred over the naive whole-room estimate \rho = N / A_{\text{room}} because it attaches a density to each individual rather than smearing one number across the whole floor. The two agree only when the crowd is spread out evenly — which, as this week's workbook confirms, is the case at the sparse occupancies we look at today, but not in a clustered crowd.

Pairing each person's density \rho_i with their instantaneous speed v_i, across people and time, gives the density-and-speed relationship known as the fundamental diagram v(\rho). Its defining property is that it only ever slopes downward:

\frac{\mathrm{d}v}{\mathrm{d}\rho} \le 0,

In plain words: the more crowded it gets, the slower people walk — speed never rises with density.

The fundamental diagram is the single most important empirical law in this field, and Voronoi density is the measurement convention this course uses to read it off walking paths.

A first look at the lab's numbers

Before any theory, let us simply look at three measurements the lab has already produced. We call this reference experiment EXP-S1 — short for Experiment Series 1, the lab's reference pedestrian-flow dataset. It is the same little experiment we return to almost every week, which is why it gets a short name. The setup is a 96 m² seminar room (8 m by 12 m) in which walkers loop around a closed path, so the crowd never drains away. The lab ran it at three crowd sizes and recorded 180 seconds of steady walking at each, giving three density-and-speed measurements.

The lab's three verified runs:

People	Mean Voronoi density (people/m²)	Mean Voronoi speed (m/s)
4	0.042	1.169
16	0.167	1.139
48	0.500	0.708

Speed falls every single step as density rises. The strength of that trend has a name: the per-seed Spearman rank correlation is −1.0. A Spearman correlation is a score from −1 to +1 for whether two things move together; +1 means they always rise together, 0 means no pattern, and −1 means one always rises exactly as the other falls. A score of −1.0 here means that every single time density went up, speed went down — no exceptions. The speed at the sparsest condition (1.17 m/s) is ordinary unimpeded walking pace for an adult; the speed at the densest (0.71 m/s) shows the beginning of congestion-driven slowdown. You cannot yet derive this relationship or explain its shape — that is Week 2. What you can do now is load these numbers and confirm the trend.

The lab's three measured (density, speed) points, plotted as recorded. A 12-fold density increase costs roughly 39% of free-flow speed. No model curve yet; that derivation is Week 2.

A word on the numbers we quote. Each value is a steady-state mean — an average taken after the crowd has settled into its flow, not in the messy first moments. Turning on a shower gives a useful analogy: the temperature swings for a few seconds before settling, and you quote the settled temperature, not the wild first instant. The lab discards the startup transient — the first 17% of each run, which is the first 30.6 seconds of the 180-second run — before averaging.

The workbook this week stays deliberately small. Its first cell holds the three verified (people, density, speed) triples as plain constants; nothing is downloaded from the lab's storage in Week 1, since the per-path data is only loaded in Week 6. A second cell reads the triples, checks the Voronoi density against the trivial whole-room estimate N / A (they agree at these sparse occupancies), and reproduces the reported Spearman correlation of −1.0 with an explicit check. A density-against-time figure shows each run settling onto its measured steady level after the discarded startup; the settled levels are the real measured values, while the rising shape is illustrative, because in Week 1 we only have the single published steady-state value per run. A final figure plots the three (density, speed) pairs as the scatter above — the teaser for the curve you will derive next.

Density against time. The number quoted for each run is the settled steady-state mean (dashed line), taken after discarding the first 30.6 seconds of startup. The settled levels are the real measured values; the rising shape is illustrative.

Do not read more into these three points than they contain. The 96 m² room, at the crowd sizes tested, can only reach the free-flow and light-congestion regimes; dense and jam-flow conditions would need a different geometry or far more people. That limit is noted here so you are not tempted to extend the near-straight appearance of three sparse points into a global model.

The big payoff: when can a simulation replace real data?

The third job — simulation as a stand-in for real labelled data — requires a methodological commitment that separates rigorous work from naive data fabrication. The commitment is this: a simulated walking path may substitute for a real one in a downstream sensing experiment only if the simulation has been validated against real pedestrian behaviour at the conditions where it will be used.

What does "validated" mean here? Think of tuning a radio: you turn the knobs until the station comes in clearly, adjusting the settings until the output matches the real signal as closely as you can. Validation works the same way. Given real reference data z_{\text{ref}} — either detailed walking paths or aggregate statistics — the model's settings p (desired walking speed, how strongly people avoid each other, how much space they keep, and so on) are chosen to make the simulation output as close as possible to that reference:

p^\star = \arg\min_{p}\; \mathrm{dist}\big(\mathrm{sim}(p),\, z_{\text{ref}}\big).

In plain words: turn the simulator's knobs until what it produces looks as close as possible to real data; the best setting p^\star is the one with the smallest mismatch. Here \mathrm{sim}(p) is the simulator's output for settings p, z_{\text{ref}} is the real reference, and \mathrm{dist} measures how far apart they are.

When the reference z_{\text{ref}} is a fundamental diagram — the measured speed-versus-density relationship — checking the match is the standard test for realistic kinematics. A simulator that passes it has shown, in the strongest available sense, that its density-and-speed behaviour matches the population it models. That is exactly the trend a WiFi or Bluetooth sensor would feel, which is why the first claim of the substitution argument reduces to reproducing the fundamental diagram. Surveys of data-driven validation reach the same conclusion from the data-science side: both path-level fidelity and density-level fidelity are necessary, and neither alone is enough — a simulator can produce plausible individual paths while getting the density profile wrong, or the reverse.

The course's substitution argument therefore rests on three claims:

The simulator reproduces the real fundamental diagram for the geometry and crowding where the sensing experiment will run. (Weeks 2–3 establish this.)
The simulation's floor plan and walker settings match the real building where the sensor will be deployed. (Weeks 4–5 establish this.)
The sensor's signal model — how Bluetooth or WiFi radio propagates in that geometry — is realistic. (Weeks 8–9 establish this.)

If all three hold, a path drawn from the simulator is, in the senses that matter, indistinguishable from a path drawn from a real experiment in that building, and a sensing model trained on simulated data will generalise to real data. If any one fails, the substitution is not defensible and the trained model will show a sim-to-real gap. This is why the course spends three weeks on pedestrian dynamics before introducing any wireless signal: the substitution argument is not a shortcut but a longer, more principled route to a trustworthy dataset.

The 12-week arc

The course is organised around the three jobs, with each resting on the foundations built in the weeks before it.

Weeks 1–3 — kinematic foundations. Why models exist (this week). The fundamental diagram: its empirical basis, its derivation from Voronoi statistics, and its reproduction in simulation (Week 2). The walker model's settings, their physical meaning, and the tuning workflow (Week 3). These weeks supply the evidence the safety and ground-truth claims need.

Weeks 4–6 — safety assessment and facility design. Density and pressure as design variables. Evacuation modelling. Sweeps over geometry: door width, obstacle placement, entry-rate changes. By Week 6 you will be able to run a parametric study, interpret it, and make a defensible design recommendation.

Weeks 7–9 — the platform and the data pipeline. JuPedSim and PedPy end-to-end on the lab's platform. Reproducible runs, and the EXP-S1 setup in full detail. The Bluetooth and WiFi signal models are introduced and validated against the walking-path output, turning the simulator from a planning tool into a data-generation pipeline.

Weeks 10–12 — synthetic ground truth for sensing. Estimating occupancy from Bluetooth and WiFi using paths generated by the validated simulator. Diagnosing the sim-to-real gap. Week 12 closes by revisiting the three substitution claims and assessing how far the course has discharged them.

Every week advances a specific claim in one of the three jobs. When a result seems peripheral — a PedPy measurement study in Week 6, a Voronoi derivation in Week 2 — it is building evidence for a claim you will invoke later.

The 12-week arc, mirroring the CRD503 curriculum. Weeks 1–3 build kinematic foundations, 4–6 cover safety and design, 7–9 build the platform and pipeline, and 10–12 deliver synthetic ground truth for sensing. Each row names the job(s) that week advances.

Looking ahead

Next week derives the fundamental diagram from first principles, introduces the Voronoi measurement method formally, and places the lab's three points against real-world pedestrian measurements. You will run the full analysis on the existing walking paths and produce the scatter yourself, so the three numbers previewed this week become the output of a reproducible computation rather than entries in a table.