# The Real Cost of AI-Porting 250k Lines of Fortran > Source: > Published: 2026-08-16 03:08:34+00:00 [AI](https://sourcefeed.dev/c/ai)Article # The Real Cost of AI-Porting 250k Lines of Fortran An agent moved Nagoya's 27-year-old typhoon simulator to GPUs, and the validation harness did the heavy lifting. [Rachel Goldstein](https://sourcefeed.dev/u/rachel_goldstein) A team from Nagoya University and the University of Tokyo just published one of the most instructive data points yet on agentic coding at scale: they pointed [Claude Code](https://claude.com/claude-code) at [CReSS](https://cress-nagoya.github.io/CReSS/), a 250,000-plus-line Fortran typhoon simulator in continuous development since 1998, and came out the other side with 162 numerically validated GPU kernels and a 5.1x application-level speedup on an NVIDIA H100 versus a 72-core Grace CPU. The headline number is real, but it's the least interesting thing in the paper. The interesting thing is where the three months of work actually went — and it wasn't code generation. ## The port nobody wanted to do by hand Weather and climate codes are the final boss of legacy modernization. They're enormous, numerically fragile, and carry decades of embedded scientific judgment — CReSS's outputs have been compared against real typhoon observations for 27 years, and that accumulated validity is the asset you cannot break. The manual track record here is sobering: Japan's ASUCA model (about 150k lines) took a dedicated multi-year effort to get onto GPUs, MeteoSwiss spent years moving COSMO via [OpenACC](https://www.openacc.org/) directives, and Météo-France's multi-million-line ARPEGE is widely cited as effectively unportable by hand. The going rate has been "a specialized team and several years per model." Against that baseline, the CReSS result — one workflow, roughly 100 hours of interactive GPU-node time spread over about three months — is a genuine order-of-magnitude compression, and that's the fair comparison, not "how fast can an agent write OpenACC directives." ## The agent didn't port the code. The harness did. The workflow is where practitioners should slow down and take notes. CReSS contains 387 OpenMP parallel regions; a real typhoon scenario (an 899×899×128 grid, about 100 million points, 360 timesteps) exercises 162 of them. The team had the agent extract each executed region into a standalone kernel, then — and this is the load-bearing step — generate a dump-based benchmark for every kernel by capturing physically meaningful simulation state from actual runs. Each GPU translation to OpenACC was then validated element-wise against dumped reference data, and the whole application was validated end-to-end on top of that. That kernel-extraction-and-benchmark phase consumed more than half of the total wall-clock time. Capturing a single state dump meant about an hour of simulation re-execution, and the authors are candid that small static-analysis mistakes were brutally expensive: legacy Fortran habits like passing a minimal dummy array where a full-domain argument is expected, or arrays that are only valid under certain runtime conditions, would silently poison a dump and force re-runs. Their "cost-aware recovery" tweaks cut required dump executions from as many as seven per workflow run down to one to three. LLMs reading Fortran can't see runtime state, and in a code like this, runtime state is the ground truth. The validation harness earned its keep in a very concrete way: five of the 162 kernels produced numerical discrepancies that pure code review would never catch. In one, a temperature of 233.16002 K on CPU versus 233.16000 K on GPU landed on opposite sides of a threshold comparison; others involved intrinsic-function differences in `exp()` , `log()` , and `sqrt()` , and tiny deltas that flipped branch conditions inside cloud microphysics. In a weather model, a flipped microphysics branch isn't a rounding footnote — it's a different storm. "It compiles and the output looks plausible" is not validation in this domain, and the paper demonstrates exactly why. ## Is 5.1x actually good? Yes — for a first-pass directive port, it's respectable, and you can sanity-check it with napkin math. Per timestep, the H100 (96 GB HBM, roughly 4 TB/s) ran in 1.88 seconds versus 9.51 seconds on the Grace CPU (about 512 GB/s). Atmospheric stencil codes are memory-bandwidth-bound almost by definition, so the theoretical ceiling for this pairing is roughly the ~8x bandwidth ratio. Capturing about 65% of that with OpenACC directives and no hand-tuned CUDA is solidly in line with what expert human porting teams have historically achieved on their first pass — which is precisely the point. The agent didn't beat experts; it matched the expert baseline at a fraction of the human cost. The caveats matter, though. This is a single-GPU, single-scenario result from a preprint: 162 of 387 regions are ported, so other model configurations would trigger unported kernels and another round of the workflow. There's no multi-node scaling data, and OpenACC in practice means the NVIDIA HPC compiler stack, so you're trading Fortran portability for vendor alignment. And the numbers come from the paper itself — credible authors with prior published work using Claude Code on GeoFEM, and CReSS's own lead developer on the byline, but not yet peer-reviewed. ## What to steal from this If you're staring at your own legacy modernization problem — Fortran to GPU, COBOL to Java, monolith to services — the transferable lesson is that the agent is the cheap part and the oracle is the product. Before you let an agent touch anything, the CReSS recipe says: instrument the real system to dump genuine runtime state, build a per-unit replay benchmark from those dumps, and make element-wise comparison the gate every transformation must pass. Budget accordingly — the Nagoya team, who knew this code intimately, still spent over half their time on harness construction, not translation. The other lesson is about failure economics. Agent mistakes weren't dangerous here because validation caught them; they were dangerous because *recovery* was expensive — an hour of re-simulation per bad dump. When you design an agentic pipeline over a system with slow feedback loops, engineering the cost of a retry down matters more than engineering the error rate down. My read: this is a genuine shift, not a demo. Not because the model got smarter, but because a small HPC team showed that validation-centric scaffolding turns an unreliable code generator into something that can safely traverse a quarter-million lines of scientifically load-bearing Fortran. The multi-year GPU porting project is now a one-quarter project — for teams willing to build the harness first. The ones who skip that step will rediscover kernel number 163 the hard way. ## Sources & further reading [Rachel Goldstein](https://sourcefeed.dev/u/rachel_goldstein)· Dev Tools Editor Rachel has been embedded in the developer tooling ecosystem for nearly eight years, covering everything from IDE wars and package-manager drama to the quiet rise of AI-assisted coding. She has a soft spot for open-source maintainers and an unhealthy number of terminal emulators installed on a single laptop. ## Discussion 0 No comments yet Be the first to weigh in.