AI agents port CReSS weather code to GPU, hit 5.1x speedup

A new case study describes a validation-centric workflow for using AI coding agents to port large legacy scientific code to GPUs, tested on CReSS, a Fortran weather simulation code of more than 250,000 lines. The authors frame this as more than a coding task: legacy scientific applications like CReSS are scientific assets whose credibility has been built up through long-term development, comparison with observations, and use in domain studies, so a GPU port has to preserve that scientific validity while adapting the code to GPU-centric HPC systems, not just make it run faster.

The workflow itself has four steps, carried out with the help of a CLI-based AI agent that the paper does not name: extract the code's existing OpenMP parallel regions, generate dump-based kernel benchmarks from physically meaningful simulation states, apply OpenACC transformations to move the kernels onto GPU, and validate every result two ways, an element-wise comparison against dumped reference data and an application-level check on the full simulation.

Applied to a real typhoon simulation run through CReSS, the workflow produced numerically validated GPU implementations for 162 target kernels and reached a 5.1x application-level speedup, within what the paper calls practical wall-clock development cost, though it gives no specific figure for that cost. Validation was not just a formality: it caught numerical discrepancies in five of the kernels, traced to floating-point and intrinsic-function differences, including threshold-sensitive branch divergence and cancellation effects, and that feedback was passed back to CReSS's own developers.

The authors' broader conclusion is that for large legacy scientific codes needing this kind of dump-based validation, practical AI-assisted GPU porting is not just about generating correct-looking code. It also has to manage context across long, multi-session porting work, reconstruct runtime state accurately, and absorb the cost of recovering from small mistakes in the AI's static analysis of the code. Their summary line: AI-assisted GPU porting needs validation-centric workflow design, not code generation alone.

Key facts

AI coding agents ported CReSS, a legacy Fortran weather simulation code of more than 250,000 lines, from CPU to GPU using OpenMP-to-OpenACC transformations.
On a real typhoon simulation, the workflow produced numerically validated GPU implementations for 162 target kernels.
The GPU port reached a 5.1x application-level speedup.
Validation by element-wise comparison against dumped reference data caught numerical discrepancies in five kernels, caused by floating-point and intrinsic-function differences, and that feedback went back to CReSS's developers.
The authors conclude that porting large legacy scientific code with AI agents requires managing session-spanning context, reconstructing runtime state, and recovering from small static-analysis mistakes, not just generating code.

Why it matters

Large scientific codebases like weather and climate models are old, often Fortran, and encode decades of validated physics; a wrong number introduced during a GPU port can silently invalidate the science. This case study is a concrete data point on whether today's AI coding agents, the same kind used for ordinary software work, can be pointed at a codebase like that and produce a GPU port that is not just fast but numerically checked. The workflow ported CReSS, a legacy Fortran weather simulation code of more than 250,000 lines, and validated 162 kernels one by one against reference data before trusting the 5.1x speedup it measured on a real typhoon run.

Who it affects

Teams that maintain large legacy scientific or HPC codebases, weather and climate modeling groups, national labs, and university research computing groups deciding whether to move a decades-old Fortran or C simulation onto GPUs. It is also relevant to anyone evaluating AI coding agents for large-scale legacy code modernization more broadly, since the workflow's problems, session-spanning context, runtime-state reconstruction, static-analysis mistakes, are not specific to weather codes.

How to use it

This is a research workflow, not a product to buy. The four steps described are: use an AI agent to extract the code's existing OpenMP parallel regions, generate dump-based kernel benchmarks from physically meaningful simulation states, apply OpenACC transformations to move kernels onto GPU, then validate every result both by element-wise comparison against dumped reference data and by an application-level check on the full simulation. The paper does not name the AI agent, coding tool, or underlying model used, or give a number for the development time it took, so the workflow's cost cannot be estimated from this material.

How solid is it

The result is quantified and validated, not just a demo: 162 kernels were checked element-wise against reference data before the team trusted a 5.1x application-level speedup measured on a real typhoon simulation, and the validation step itself caught five kernels with numerical bugs. That is a meaningfully higher evidence bar than an unverified benchmark claim. What is missing for judging generality: no GPU model or HPC system is named for the speedup measurement, no baseline pre-porting runtime is given to check the 5.1x figure against, it is not stated what share of the full 250,000+ line codebase the 162 ported kernels represent, and the material available gives no individual author names, institutional affiliations, or peer-reviewed venue beyond the arXiv posting itself.

Risks and caveats

The paper's own numbers are a warning as much as a result: five of the 162 ported kernels initially produced numerically wrong output, caused by floating-point and intrinsic-function differences, including threshold-sensitive branch divergence and cancellation effects. Those bugs were only caught because the workflow validated each kernel against reference data; without that step, an AI-driven GPU port could quietly corrupt a scientific code's output while still running and looking fine. The authors also flag friction beyond code generation itself: keeping context coherent across long, multi-session porting work, reconstructing runtime state accurately, and absorbing the cost when the AI's static analysis misses something small. None of that cost is quantified in the material available, so how much effort the approach actually saves cannot be judged from this alone.