GCRI · Foundry
Modelling and simulation
Risk models range from hydrodynamic flood simulations and power-flow studies to agent-based evacuation models and statistical loss models. They share three engineering needs: enough compute to run ensembles, enough discipline to reproduce a run months later, and enough honesty to state what the model cannot represent. This page sets out how model error enters, compounds through coupling and reaches decisions, how reproducibility is engineered, and where the limits sit.
Modelling and simulation on the record.
Modelling and simulation: how the risk develops.
Workloads, reproducibility and limits. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Structural and parameter error
Every model omits processes and fixes parameters from limited data. Calibration can fit the past for the wrong reasons, so a model that matches history may still fail in the conditions a decision is actually about.
Coupling compounds error
When a flood model feeds a power-network model that feeds a hospital-continuity model, mismatched time steps, grids, units or assumptions produce plausible but wrong cascades. Each hand-off needs a declared contract and a sensitivity test of its own.
Environment drift
A compiler flag, a library update, a different processor or an unrecorded random seed alters results. Without pinned containers, versioned code and recorded configuration, a run cannot be repeated and a change in output cannot be explained.
Extrapolation
Models are validated for a range of conditions and then used beyond it: a new climate, a larger event, a different city. Outside the validated range a model is an assumption with a number attached, and its label must say so.
How modelling and simulation is modelled, measured and tested.
The model, its assumptions, its data and its uncertainty, in the form a scientist or engineer would check. Structures follow published methods. The values drawn are illustrative, not findings.
Model, equations and assumptions
The model structure used for modelling and simulation, the assumptions it makes and how each is tested.
Ri = f(Hi, Ei, Vi, Ci)hazard, exposure, vulnerability and coping capacityEAL = ∑k pk · Lkover events k with annual probability pkxt+1 = A xt + B ut + εtA carries the couplings, u the shock, ε the error| Assumption | Why it is made | How it is tested |
|---|---|---|
| Hazard and exposure are independent within an event | Keeps the loss integral tractable | Compare with a copula fit on joint records |
| Couplings are linear near the operating point | Lets shocks propagate through A | Perturb beyond the linear range and compare |
| Vulnerability curves transfer between places | Local curves are rarely available | Validate against observed losses where they exist |
- Inputs
- versioned datasets with provenance
- Outputs
- distributions, never single numbers
- Code
- released with the model card and tests
- Reproduction
- same data, code, environment and seed
Models in Foundry are designed to couple the domains.
Models would carry NS-12 cards under the proposed Nexus Standards and be documented with the ODD protocol where agent-based. Results go to the Scenario and Stress-Test series.
- Model reviews.
- Validation data.
What is measured, and how well.
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Runs reproduced from recorded inputs | proportion of sampled runs | quarterly | Re-execution audit | OBSERVED |
| Hindcast skill on a held-out period | model-specific skill score | per model version | Validation against observations | MODELLED |
| Ensemble spread | units of the output variable | per run set | Ensemble statistics | MODELLED |
| Variance attributed to each uncertainty source | proportion by input, parameter and structure | per study | Global sensitivity analysis | MODELLED |
| Coupling interface checks passed | proportion of hand-offs | per run | Unit, grid and timing checks | OBSERVED |
| Conservation closure error | units of the conserved quantity | per run | Model diagnostics | OBSERVED |
| Model versions in use with independent review | proportion of versions | per version | Review records | OBSERVED |
| Compute per ensemble member | core-hours or GPU-hours | per run | Scheduler accounting | OBSERVED |
Where the evidence comes from.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| ERA5 reanalysis (Copernicus Climate Change Service) | Hourly atmospheric and land forcing for hindcasts and validation | Free and open, attribution |
| CMIP6 through the Earth System Grid Federation | Climate model projections for scenario forcing | CC BY 4.0 for most models |
| ISIMIP impact model outputs | Harmonised sectoral impact simulations for intercomparison | CC BY 4.0 for most outputs |
| NASA Earthdata | Satellite observations for model evaluation | Free and open, NASA data policy |
| Zenodo | Versioned, citable archives of model code, configuration and data cuts | Licence per record |
| Software Heritage archive | Long-term preservation and persistent identifiers for source code | Free access, licence of each repository |
Who decides, and what the evidence serves.
Foundry prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Programme owners in ministries | Whether a model is fit to inform a policy or investment choice | Validation range, sensitivity, independent review and stated limits |
| Model review leads | Whether a model version may be used for a question, and with which caveats | Hindcast skill, extrapolation check, reproduction test |
| Infrastructure operators | Whether model scenarios are credible enough to size precautions | Ensemble spread, coupling assumptions, comparison with past events |
| Research funders and journal editors | Whether results are reproducible enough to publish or fund further | Archived code, data cuts and the re-execution record |
Outputs this topic produces
- Run records with data cut, code version, container digest and configuration
- Validation reports with the conditions of validity stated
- Ensembles with spread and sensitivity attribution
- Coupling contracts declaring units, time steps and grids
What modellers ask before trusting a result.
- Can this run be reproduced exactly, from the same data cut, code version and configuration?
- Has the model been validated against observations for the conditions it is now used in?
- How much of the spread in results comes from inputs, parameters and model structure?
- Are coupled models exchanging variables with consistent units, timing and assumptions?
Workloads, ensembles and coupling.
Most risk questions need many runs rather than one: ensembles across climate scenarios, Monte Carlo samples across uncertain parameters, or sweeps across adaptation options. These are designed to be scheduled through NXS-COR (compute, nodes and runtimes) across cloud, private infrastructure and edge nodes, with NXS-LAB (research, experiments and simulations) providing governed experiments and reproducible compute, and NXS-DSS (decision cases and deliberation) turning results into option trade-offs for decision-makers.
Coupling is where errors hide. When a flood model feeds a power-network model that feeds a hospital-continuity model, mismatched time steps, spatial grids or unit conventions can produce plausible but wrong cascades. Explicit interfaces, declared assumptions at each hand-off and sensitivity tests on the coupling itself are the standard defences.
How results are kept honest.
Pinned inputs
Frozen data cuts, versioned code and recorded configurations, so a run can be repeated.
Against observations
Hindcasts and out-of-sample checks, with the conditions of validity stated.
Stated, not hidden
Results carry their spread and the main sources of uncertainty.
Limits: reproducibility proves a run can be repeated, not that the model is right. Models extrapolated beyond their validated range, or used for questions they were not built for, remain the most common source of misleading results. Independent review of model choice, separate from the team that built the model, is the standard safeguard.
How it is studied, and what the methods cannot say.
- 01High-performance, cloud and edge computingEnsemble scheduling across tiers · Federated execution next to the dataApplied here
- 02Systems engineeringCanonical system inventory · Contract-first interfaces · Requirements traced to evidenceApplied here
- 03Artificial intelligence and machine learningEarth observation models with spatial validation · Model cards and promotion recordsApplied here
- 04Data engineering, interoperability and stewardshipValidation at the ingest boundary · Frozen data cuts for reproducible productsApplied here
- 05Software and safety-critical systems engineeringFail-closed policy gates · Build provenance and bills of materials · Assurance casesApplied here
Where this page’s references lead.
The bodies and documents this page is read against. Status and editions change; each link goes to the issuing body.
Questions and answers.
Can a result be reproduced exactly?
Why run ensembles instead of one best run?
What is a coupling contract?
Can I run my own model in Foundry?
Are model results published automatically?
Does running a model in Labs validate it?
Contribute evidence from this page.
Reports is the Consortium’s quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
- EmailGateway GW-GCRISend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsGCRISee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Bring a method, a dataset or a question.
Information and enquiries are open today. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.
Legal documents.
Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.