Simulating the City

Recall the test that defines a twin: model plus live data plus simulation plus a feedback loop into decisions. The first two give you a living mirror. Simulation is the third ingredient, and it is what separates a twin from a very good monitoring screen. Visualisation answers 'what is happening, and where?' Simulation answers a fundamentally different and harder question: 'what would happen if?'

The distinction matters because the two rest on completely different footings. A visualisation is grounded in measurement - it shows data that was actually collected from the real city, so its honesty is a question of whether the sensors are accurate and current. A simulation is grounded in a model - a set of rules, equations or learned patterns that claim to capture how the city behaves - and it is run to produce numbers about situations that have not occurred and cannot be measured. That is an enormous leap. When a dashboard says a junction is congested, you can in principle go and look. When a simulation says a proposed junction will be congested in 2031, there is nothing to look at; you are trusting the model's account of cause and effect.

This is why simulation is both the most powerful and the most dangerous thing a twin does. Powerful, because testing an intervention in a model before pouring concrete is vastly cheaper and safer than testing it on the street - you can try a pedestrianisation, a drainage upgrade or a new tower a hundred times in the model and only build the one that works. Dangerous, because a simulation wraps a set of assumptions in the authority of precise output, and a decision-maker who forgets that the number came from a model rather than from reality can be badly misled. The skill this module builds is holding both truths at once: simulation is the reason twins are worth building, and every simulation result is a conditional estimate - 'if the model and data are right, then roughly this' - never a fact about the future.

Urban simulations come in several families, and knowing which family a result came from tells you a lot about what it can and cannot claim. Most city models are one of three kinds, or a combination.

Agent-based models simulate a population of individual 'agents' - people, vehicles, households - each following simple behavioural rules, and let the overall pattern emerge from their interactions. A pedestrian-evacuation model, a model of how commuters choose routes, or a model of how a neighbourhood gentrifies are typically agent-based. Their great strength is capturing emergent, bottom-up behaviour that no equation dictates from above: congestion, crowding, tipping points. Their great weakness is that the results depend entirely on the behavioural rules you gave the agents, and real people are far more varied and surprising than any rule set - especially in an Indian city, where movement, street use and the informal economy follow logics that tidy agent rules rarely capture.

Physics-based models apply the laws of physics and engineering to the city's fabric: how air flows between towers (computational fluid dynamics), how heat builds in a district, how water spreads in a flood, how a structure responds to load. These rest on well-established science, so within their domain they can be genuinely predictive - but they are computationally heavy, acutely sensitive to boundary conditions and input geometry, and still simplifications of messy reality. Their binding use belongs to qualified engineers, not a designer reading a twin.

Statistical and machine-learning models learn patterns from historical data - predicting tomorrow's energy demand, air quality or ridership from what happened before. They can be remarkably accurate when the future resembles the past, and fast to run. But they are weakest exactly when you need them most: at the novel interventions a twin exists to test, where there is no historical precedent to learn from, and they can silently encode the biases of their training data. In practice, serious urban twins stitch these families together - an ML model feeding an agent-based traffic model feeding a physics-based air-quality model - and each hand-off is a place where error and assumption accumulate.

This is the sentence to carry out of the whole module, so it is worth stating bluntly: a simulation is only as good as the model it runs and the data it is fed. A flawless model fed stale or biased data produces confident nonsense; perfect data run through a model that misrepresents how the city works produces confident nonsense just as surely. Output precision - a number to three decimal places - says nothing about accuracy. The computer will always return an answer; whether that answer bears any relation to reality is a separate question the software cannot answer for you.

Three discipline points follow. First, calibration and validation. A credible model is tuned so that, when fed past conditions, it reproduces what actually happened (calibration), and is then checked against independent data it was not tuned on (validation). A simulation that has never been shown to reproduce the known past has no earned claim on the unknown future. Always ask: has this model been validated, against what, and how well did it do? Second, garbage in, garbage out - the oldest rule in computing and the most ignored in city twins. If the informal settlements are not in the data, the flood model will not flood them on screen even as it floods them in life; if a road's real capacity is mis-entered, the traffic result is wrong from the first step. Much of a twin's value rides on data you may never see. Third, the model is a simplification with a boundary - it was built to answer particular questions and is silent, or simply wrong, outside that scope. A mobility model knows nothing about air chemistry; asking it a question it was not built for yields an answer-shaped artefact, not knowledge.

None of this is a reason to distrust simulation wholesale - it is the reason to use it well. A validated model, run on good data, within its intended scope, with its assumptions on the table, is one of the most valuable instruments a city has. The failure is not simulating; the failure is forgetting that the map is not the territory and selling the map as the territory.

No simulation predicts the future; at best it estimates a range of plausible futures with stated confidence. A simulation result that arrives as a single bare number - '47,000 vehicles per day' - is being presented dishonestly, because it hides the uncertainty that every model carries. The honest form of the same result is a range with its assumptions named: 'between roughly 40,000 and 55,000, assuming the new housing fills at the planned rate and fuel prices hold, with most uncertainty coming from how many residents switch to the metro.'

Uncertainty in an urban simulation comes from several stacked sources, and it compounds. There is input uncertainty - the data is never perfectly accurate or complete. There is parameter uncertainty - the behavioural rules and coefficients are estimates, not facts. There is structural uncertainty - the model's very conception of how the city works may be partly wrong. And there is the deep uncertainty of human and political behaviour, which no model fully tames: people respond to a new road by driving more (induced demand), adapt in ways the model never encoded, or make collective choices that defy any rule. A twin that projects decades ahead is stacking uncertainty on uncertainty, and its far-future numbers should be read as illustrative directions of travel, not forecasts.

The professional response is not to abandon simulation but to treat uncertainty as a first-class output rather than an embarrassing footnote. Run the model many times across plausible inputs (sensitivity analysis) and report the spread. State assumptions openly. Compare scenarios against each other rather than trusting any single absolute number - the relative result ('A floods less than B') is usually far more robust than the absolute one ('A floods to 0.8 metres'). And keep binding engineering conclusions - the flood depth a drain must carry, the wind load a facade must resist - with the qualified engineers and their validated, accountable models, never with a designer's read of a planning twin. Module 4.4 turns this discipline into a decision-support method; the rest of this module applies it to mobility and to the environment.