Our ability to simulate Earth’s climate has always depended on two things: our physical understanding of the climate system and the computational power available to study it. Over the last few decades, both have advanced. The climate models we run today are much more capable than those used in the early CMIP years, but they are also far more expensive to execute.
The result is a familiar tension for the climate community: the science asks for more experiments, finer resolutions, and more detail, while the computing cost keeps rising.
Climate simulations keep getting more expensive
There are three main reasons.
The first is resolution. Higher resolution means we can represent natural processes more faithfully. This matters for regional patterns, extremes, and the structure of the circulation itself. But the cost is steep: reducing grid spacing also forces smaller time steps and increases the amount of work per simulated year. In practice, higher resolution is one of the strongest drivers of growing compute demand.
The second is model complexity. Climate models have evolved into full Earth System Models, including biogeochemistry, aerosols, chemistry, vegetation, ice sheets, and other interactive components. Each added process makes the model more realistic, but also more expensive to run and harder to scale efficiently. Coupling these components introduces synchronisation and communication overheads that can reduce performance even when the base model physics is unchanged.
The third is the size of the scientific question itself. CMIP is not a single experiment, but a coordinated effort across many modelling centres, models, and ensembles. This means the computational cost is not just one expensive run. It is the combination of many models, many ensemble members, and many experiments run by different modelling centres on different HPC systems.
Seen from this angle, the growth in CMIP is not surprising. Science has become broader, more detailed, and more ambitious. Computing demand follows naturally.
HPC has evolved, but there are constraints
For a long time, performance gains came from faster CPU cores. That era is over. Single-core performance has improved much more slowly than it used to, largely because CPU frequency increases have hit power and thermal limits. Modern HPC systems no longer rely on a few very fast processors. They rely on many cores, deep parallelism, and increasingly on accelerators.
This shift matters for climate models because they do not automatically benefit from new hardware. They have to be adapted to use it well. More powerful hardware does not directly translate into faster science.
Climate codes are particularly challenging in this context. They are large, long-lived, and sensitive to changes. They involve multiple numerical methods, many interactions between components, and large data movement. All of which makes them harder to parallelise than many other HPC workloads. As a result, HPC systems have become more powerful, but climate applications are being pushed into a programming landscape that is not always easy for them to exploit, leading to inefficient use of compute resources.
HPC peak performance is not the whole story
HPC discussions have traditionally focused on peak performance. This is, of course, a key metric for any supercomputer, but it is only part of the picture.
As supercomputers have grown larger and more complex, it has become harder to keep them running efficiently. Over the past 15 years, top systems have roughly doubled their peak performance every two years. In contrast, performance per watt, a measure of energy efficiency, has doubled more slowly, roughly every 2.4 years, while total system power has continued to increase, doubling approximately every eight years.
These trends highlight an important point: scaling to larger systems comes with inherent inefficiencies, and increasingly more energy is required to operate the fastest machines used by the climate community. This directly affects the cost of doing science.
At the same time, peak performance does not easily translate into application performance. A system that looks excellent on paper may still be a poor match for climate workloads if it offers high theoretical floating point operations per second (FLOPS) but limited memory bandwidth, weak I/O, or poor support for communication-heavy applications.
This is why measuring more than wall-clock time is becoming essential. To understand the real cost of climate simulations, we need metrics that reflect actual workloads: model configuration, queue delay, energy consumption, I/O overhead, coupling cost, memory usage, and more. Without these metrics, it is difficult to quantify computing demands, compare models, identify bottlenecks, or argue for hardware architectures that better fit the needs of the community.
To give a sense of scale, achieving a key performance milestone for the kilometre-scale digital twin in Destination Earth requires around 450 nodes and about 1.2 million core-hours per simulated year on MareNostrum5. Using a representative cost of €0.02 per core-hour, this corresponds to roughly €25,000 per simulated year.
This is only a rough estimate, and for a high-end configuration, but it illustrates the scale of the computational cost behind today’s most ambitious climate simulations.
CMIP7 and beyond
The next phase of CMIP continues the same trend: more accurate models, higher resolution, more process details, larger ensembles, and more data. That is scientifically exciting, but it also makes the computational side of climate research more important than ever.
The key point is simple: if the climate community wants to keep increasing ambition, it also needs to start measuring the cost of that ambition systematically. Otherwise, we can see the growth in science, but not the growth in the resources it requires.
Computational metrics should become part of how we plan and evaluate CMIP activities. Beyond quantifying those costs, they can help answer practical questions: Which models are limited by I/O, coupling, or not scaling? Which hardware designs are best suited for climate workloads? Where can we reduce computing costs without compromising scientific value? They also open the door to harder—but necessary—questions: Which experiments are disproportionately expensive? And how do we balance scientific benefit against computational cost?
