The Global Centre for Risk and Innovation (GCRI)
High-performance computing runs the weather forecasts, climate projections, engineering simulations, genomics and AI training that modern science and public services rely on. National capacity depends on machines, software, skilled people, energy and long-term funding. This page sets out how HPC capacity is built and used, how it is measured, and what evidence serves the research funders and agencies that plan national computing.
GCRI · In development · service level R0
High-performance computing is the use of supercomputers and parallel processing to run large simulations and analyses, from weather forecasts to genomics and AI. National capacity depends on machines that age fast, software and skilled people to use them, power supply and long-term funding.
For high performance computing, in GCRI's spatial-intelligence reading, the map opens on night lights, population density and true-colour imagery with true colour from NASA GIBS, framed on the contiguous United States; every other NASA layer, live feed and forecast waits in the layer list.
The interactive map needs JavaScript; the layer list and sources are below.
Layers 3
Connected activity, for this page
Keyboard, with the map focused
Hold Ctrl or ⌘ and scroll to zoom
Latest available
NASA GIBS / EOSDIS · ASTER GDEM (METI, NASA) · Blue Marble (NASA) · © OpenStreetMap contributors (ODbL) · Natural Earth
Loading the latest NASA imagery.
Drag to move. Ctrl or ⌘ and scroll, pinch or the buttons to zoom; hover for the values under the pointer; reset returns to the region.
For high performance computing, in GCRI's spatial-intelligence reading, the map opens on night lights, population density and true-colour imagery with true colour from NASA GIBS, framed on the contiguous United States; every other NASA layer, live feed and forecast waits in the layer list.Satellite and model products as NASA publishes them, each with its own date; indicators, not assessments of any place; claim ceiling INTEGRATED.
Layers and dates
HPC/GPU workloads and scientific compute. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Some problems need one very large machine running one job; others need many smaller jobs. Planning for one does not serve the other.
Supercomputers are replaced every few years as performance per watt improves. Gaps between systems interrupt the work of forecasting and research centres.
Codes must be ported and optimised for new architectures such as GPUs. Shortages of research software engineers leave capacity underused.
Large systems draw megawatts. Energy cost and grid capacity increasingly decide where and how large new machines can be.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Capability computing | Using a large share of a supercomputer for a single, very large job. |
| Capacity computing | Running many smaller jobs at the same time to maximise total throughput of a system. |
| Research software engineer | A professional who develops and maintains software used in research. |
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 |
|---|---|---|---|---|
| Sustained performance on standard benchmarks | floating point operations per second | twice yearly | TOP500 list | OBSERVED |
| Energy efficiency | floating point operations per watt | twice yearly | Green500 list | OBSERVED |
| System utilisation | percent of available node hours used | monthly | Centre usage records | OBSERVED |
| Allocation oversubscription | ratio of requested to available hours | per call | Allocation records | OFFICIAL |
| Research software engineers employed | count | annual | Centre staffing records | REPORTED |
| Codes ported to accelerators | percent of major community codes | per assessment | Centre reports | REPORTED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
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 |
|---|---|---|
| TOP500 and Green500 lists | Performance and energy efficiency of the most powerful systems | Public, TOP500 terms |
| EuroHPC Joint Undertaking reports and access calls | European supercomputers and allocation | Public, EU terms |
| National HPC centre annual reports | Usage, allocation and science outputs | Public records, terms per centre |
| ESFRI roadmap and landscape analysis | European research infrastructure planning | Public, EU terms |
| WMO reports on numerical weather prediction capacity | Computing used by meteorological services | Public, WMO terms |
Data and Compute 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 |
|---|---|---|
| Research funders and science ministries | What computing capacity to fund and where | Capacity and demand reviews; oversubscription |
| HPC centres | How to allocate time and support users | Utilisation and allocation analyses |
| Meteorological and climate services | When to procure the next system | Performance and workload evidence |
Large simulations divide a problem into many pieces that must exchange data constantly. Performance depends not only on processor speed but on memory bandwidth, the interconnect between nodes and input and output to storage. A system that is fast on paper can be slow for a given code if these are unbalanced.
Accelerators such as GPUs deliver much more arithmetic per unit of energy for suitable workloads, which is why AI training uses them. But many scientific codes were written for conventional processors and need substantial effort to use accelerators well. Architecture shifts therefore create a software burden and a skills burden, not just a procurement decision.
Profiling the actual codes and data volumes a community runs. Limits: future workloads, especially AI, are hard to predict.
Standard tests of computing performance. Limits: no benchmark represents all workloads, and peak figures overstate real performance.
Modelling demand, utilization and replacement cycles with optimization and operations research. Limits: depends on funding cycles and hardware availability.
Measuring useful work per unit of energy, linked to power systems engineering. Limits: comparisons across workloads are difficult.
The current service level is R0: information and enquiries. 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.