A climate model's expensive years come after the paper is published. The initial run that produced a result might take weeks of supercomputer time. Keeping that model running, archiving its output, and answering questions about it for a decade costs far more. Funding structures were not built for that asymmetry.

The bill arrives after the paper

Grant panels fund projects. A project has a start date, an end date, and a deliverable. For a climate modeling project, the deliverable is typically a set of simulations and a paper describing them. The supercomputer time to produce those simulations is budgeted. The cost of maintaining the model code after the grant ends is not.

This is a small oversight with large consequences. A model like CESM or HadGEM is a living codebase when a paper appears, with dependencies, compiler requirements, and input datasets that need to be readable by future versions of the same software. Someone has to keep it compiling. Someone has to answer emails from users who downloaded the output.

That someone is usually a postdoc or a research scientist whose salary comes from the next grant. The maintenance work is invisible in the publication record. It does not generate citations. It does not produce novel results. It is the kind of labor that gets done because people care about the community, not because the funding model rewards it.

What a climate model actually costs

Supercomputer hours dominate the lifetime cost of a model, but not in the way most people assume. The initial spin-up and production runs for a major intercomparison project can consume millions of core-hours. Those runs are expensive, but they are also the ones that get budgeted because they are tied to a specific deliverable.

The expensive part is the tail. A model that was state-of-the-art in 2015 still gets used in 2026 for paleoclimate work, for regional downscaling, or for teaching. Each of those uses requires a working build environment. Compilers change. Libraries update. The model that ran fine on a Cray in 2015 may not compile on a GPU-based system in 2026.

Data storage grows faster than the publication rate. A single model intercomparison can produce petabytes of output. That output is valuable for years, but the cost of keeping it accessible falls on whichever institution happens to host the archive. The original grant that paid for the simulation has long since closed.

Personnel costs are the most underestimated line. A model is a community of people who know how the code works, which parameters are fragile, and which output variables are trustworthy. When those people leave, the knowledge leaves with them. Rebuilding it takes years.

Publication incentives distort the ledger

Academic incentives reward novelty. A paper that describes a new model configuration or a new set of projections is publishable. A paper that describes how to keep an old model running is not. The result is a system that funds the creation of new models and leaves the maintenance of existing ones to whoever happens to be around.

Citations do not pay for electricity. A highly cited model may be used by hundreds of researchers, but the hosting institution receives no direct revenue from those citations. The cost of running the model for a new user falls on the same institutional budget that already supports the original team.

Grant panels fund starts, not continuations. A proposal to extend a model's lifetime by five years is less competitive than a proposal to build something new. Reviewers want to see innovation. Maintenance looks like a lack of ambition, even when it is the most scientifically valuable thing the team could do.

Model intercomparisons strain shared resources. When a major intercomparison project launches, every participating group needs to run their model on the same grid, with the same forcing, and deliver output by a deadline. The shared infrastructure at national centers absorbs the peak. That absorption is a subsidy, and it is not counted in any project budget.

The hidden infrastructure of model runs

National centers subsidize individual projects in ways that are hard to see from the outside. A university group that runs a climate model on a national supercomputer pays for the core-hours through a competitive allocation. The allocation covers the compute. It does not cover the staff time at the center who help the group debug the job, nor the storage costs for the output.

Queue times shape research questions. If a model run takes three weeks to get through the queue, a researcher will design experiments that require fewer runs. That constraint is real, and it biases the science toward questions that can be answered with a small number of simulations. The bias is rarely acknowledged in the resulting papers.

Energy costs vary by region and season. A data center in a cool climate pays less for cooling than one in a warm climate. A center that runs its supercomputer during off-peak hours pays less for electricity. Those differences are not reflected in the allocation process, which treats a core-hour as a core-hour regardless of where or when it is used.

Archival data outlives original grants. A dataset produced in 2010 may still be downloaded in 2026. The institution that hosts it has been paying for that storage for sixteen years. The original grant that funded the data collection ended in 2013. The archive is now a public good with no dedicated funding line.

What the accounting does not show

There is no standard metric for the lifetime cost of a climate model. Institutions report compute allocations, storage volumes, and personnel counts in different ways. A model that looks cheap at one center might look expensive at another, not because the underlying costs differ, but because the accounting conventions differ.

Attribution across institutions is murky. A single simulation may involve code from one group, forcing data from another, and analysis from a third. When the bill comes due for maintaining the code or archiving the output, it is not clear who should pay. The default is that the hosting institution pays, which creates an incentive to avoid hosting.

In-kind contributions go uncounted. A senior scientist who spends ten percent of their time answering questions about a model is making a contribution that does not appear in any budget. A programmer who fixes a build issue on their own time is doing the same. These contributions keep the infrastructure alive, and they are invisible to funders.

Uncertainty ranges apply to budgets too. Any estimate of a model's lifetime cost depends on assumptions about how long it will be used, how many users it will attract, and how much storage prices will change. Those assumptions are rarely stated, which makes the estimates hard to compare. A related piece on this site about container captures for reproducibility touches on the same problem of long-term usability.

Practical steps for funders and modelers

Budget for post-publication compute explicitly. A proposal that includes a line item for maintaining the model for five years after the paper is published is more honest than one that assumes the work ends when the grant ends. Funders should require that line item for any proposal that creates a new model configuration.

Treat model maintenance as a funded activity. A grant that pays for a software engineer to keep a model compiling is not less innovative than one that pays for a new simulation. It is the infrastructure that makes the simulation possible. Review panels should evaluate maintenance proposals on their own terms.

Publish cost-per-run estimates alongside results. A paper that reports the core-hours, storage volume, and personnel time required to produce its simulations gives readers a way to understand the true cost of the science. That information also helps other groups plan their own work.

Extend grant timelines to match model lifetimes. A three-year grant is a poor fit for a model that will be used for fifteen years. Longer grants with periodic reviews would allow teams to plan for maintenance and archiving without constantly writing renewal proposals.

Coordinate shared infrastructure across projects. When several groups use the same model, they can share the cost of maintaining it. A consortium model, where institutions pool resources for a common codebase, spreads the burden and reduces duplication. This site has argued that reproducibility depends on treating code as a long-term asset, not a disposable artifact.