An Agentic Workflow for Legacy HPC Modernization: Converting the Two-Electron-Integral Core of GAMESS
Yuzhong Shen, Masha Sosonkina, Peng Xu, Mark S. Gordon
Old Dominion University · Iowa State University · Ames National Laboratory
cs.AI
Submitted: 2026-08-12
Updated: 2026-08-13
Code: https://github.com/gms-bbg/test-validation
License: http://creativecommons.org/licenses/by/4.0/
Importance score: 75/100
The gist: The paper proposes and evaluates a supervised agentic workflow for modernizing legacy scientific code at production scale, using the conversion of the two-electron-integral core of GAMESS from
Terminology
Summary
The paper proposes and evaluates a supervised agentic workflow for modernizing legacy scientific code at production scale, using the conversion of the two-electron-integral core of GAMESS from fixed-form Fortran 77 to free-form Fortran 2008 as a case study. The central claim is that "a supervised agentic workflow can carry out legacy scientific-code modernization at production scale, with the specification rather than any model as its durable artifact; the reach of that delegation is set by the verification the domain affords, and scientific software affords more of it than is usually recognized."
The workflow consists of three prompt-specialized agent roles
— conversion, testing, and review — that operate under a version-controlled specification that the agents themselves authored and revised, while humans hold a small number of gates.
The agents are sessions of Claude Code, running across four Claude model generations (Opus 4.6, Sonnet 4.6, Opus 4.7, and Opus 4.8). The specification is contained in three agent-authored documents: CLAUDE.md, STYLE GUIDE.md, and AGENT GUIDE.md. Each role works in its own git worktree, and humans retain control over approving side-effecting shell commands, reconciling build configuration, adjudicating results, and approving merges.
The conversion scope was twelve source files, 56,448 lines, and 225 subroutines
comprising the eight int2 files (four ERI implementations: rotated-axis packages, ERIC, and Rys quadrature) and the four-file eftei family. The conversion envelope required free-form 132-column source, IMPLICIT NONE everywhere, REAL(real64) from iso fortran env, INTENT on all dummy arguments, structured control flow, modern relational operators, and COMMON blocks preserved verbatim under explicit deferral annotations. Algorithmic refactoring was forbidden outright to preserve exact equivalence.
The acceptance criterion was bit-for-bit reproduction of chemistry-relevant output: a deviation in the twelfth decimal place counts as a failure rather than drift.
Verification was performed largely by the agents themselves, through two layers: synthetic unit tests (roughly 255,000 synthetic shell quartets exercised across the matrix, with no differences) and integration testing, where each file was validated against the 49 standard GAMESS tests plus two additional calculations (a cc-pVQZ water calculation and a scalar-relativistic DFT calculation on HCl), and against the maintainers' own Jenkins continuous-integration suite.
Results: "All twelve source files pass a 51-test validation battery comprising the 49 standard GAMESS tests and two additional calculations, and across 612 test runs the number of chemistry-relevant differences is zero, and every file also passes the Jenkins tests that are used for continuous integration." The aggregate line count changed by only-0.94%, subroutine count was preserved exactly in every file (225 total), and all 1,066 COMMON statements survived verbatim with deferral annotations. Eleven of twelve files were arithmetically correct on the first conversion, and eleven of twelve compiled cleanly on the first attempt.
Three classes of defects arose. Two were caught by the strict-std=f2008 compiler (scalars passed where rank-1 arrays were expected, and Hollerith literals). One defect escaped both the agents and the compiler: a packed-label construction where four shell indices are packed into a single 64-bit word written through a real-typed alias (DOUBLE PRECISION IX()). The agent translated it faithfully as REAL(real64):: IX(), which was a locally accurate rendering of what the original says
but wrong because the high-order shifts no longer land where they must.
The unit tests never saw it because the affected path is gated by buffer-overflow logic, but the standard tests caught it on the first run of exam01. An agent then localized the regression by subroutine-level bisection (writing a 113-line Python harness), corrected the single declaration (retyping IX to INTEGER(int64)), and generalized the fix into a new audit rule in STYLE GUIDE.md. The total corrective change was six wrong lines out of 55,916.
The paper also identifies a common-mode verification blind spot: unit-test drivers for three files had been captured before-fdefault-integer-8 was standardized across the build, so both sides of the differential comparison shared the same missing flag, making the diff empty and the test pass while being externally invalid. The paper notes that a differential check cannot detect an error in the procedure that generates both of its sides.
The automation boundary is characterized empirically: agents handled reading and comprehending 56,448 lines of F77, emitting conforming Fortran 2008, authoring unit-test drivers, capturing golden references, documenting changes, running style audits, executing the integration battery, diagnosing a regression by bisection, and writing new specification rules from a post-mortem. Humans retained approving side-effecting shell commands, build-driver and baseline plumbing, branch merges, adjudicating whether results are acceptable, reconciling build configuration, and approving pull requests. The paper concludes that human effort did not scale with code volume
and that the useful question when planning agentic modernization is not how much can be automated but where can automated checking be wrong about itself, and that is where the humans belong.
Limitations acknowledged: tests were carried out on a desktop workstation, not HPC clusters; only the standard tests and Jenkins set were used, not the extended GAMESS test suites; changes have not yet been integrated into the production version of GAMESS; and only Anthropic tools (Claude Code and four Claude model generations) were used, with portability to other runtimes treated as a conjecture.
Improvements for AI systems
Improvements to AI systems:
-
Self-auditing specification generation: The AI system should autonomously author and iteratively revise its own version-controlled specifications (like CLAUDE.md, STYLE GUIDE.md, AGENT GUIDE.md) during a task, rather than relying on static prompts. This enables it to encode learned constraints (e.g.,
retype IX to INTEGER(int64)
) into reusable rules for future conversions. -
Multi-role agent orchestration with human gates: The AI system should implement three specialized, concurrently running agent roles—converter, tester, and reviewer—each operating in isolated workspaces, with a human only approving side-effecting commands, merge decisions, and final acceptance. This division of labor improves reliability by having independent verification layers.
-
Bit-exact verification via differential testing: The AI system should generate synthetic unit tests (e.g., 255,000 shell quartets) and compare outputs against golden references at the bit level, treating any deviation in the twelfth decimal place as a failure. This forces the system to prioritize exact equivalence over approximate correctness, catching subtle numerical regressions.
-
Compiler-strictness integration: The AI system should run its generated code under the strictest compiler flags (e.g.,
-std=f2008) during development, not just at final validation, to catch type mismatches (scalars vs. rank-1 arrays) and legacy constructs (Hollerith literals) early, reducing debugging cycles. -
Automated regression localization by bisection: When a test fails, the AI system should automatically write and execute a bisection harness (e.g., a Python script) to isolate the failing subroutine by systematically narrowing the code path, then generate a minimal corrective patch (e.g., six lines out of 55,916) and generalize the fix into a new audit rule.
-
Common-mode blind-spot detection: The AI system should validate its test harness itself by checking that both sides of a differential comparison are generated under identical build configurations (e.g.,
-fdefault-integer-8). It should flag cases where a shared missing flag could make a diff empty and falsely pass, prompting regeneration of golden references. -
Scalable human-effort allocation: The AI system should track where human intervention is actually needed (e.g., approving shell commands, reconciling build configs) and dynamically adjust its autonomy, ensuring that human effort does not scale with code volume but only with verification-critical decisions.
-
Post-mortem rule generalization: After fixing a defect, the AI system should automatically extract the root cause and append a new, explicit rule to its specification documents (e.g.,
never alias integer-packed data through real-typed arrays
), preventing recurrence across future files or projects.
What the improved AI system can do:
-
Convert 56,448 lines of legacy Fortran 77 to Fortran 2008 with 100% bit-for-bit output equivalence across 612 test runs, preserving subroutine counts and COMMON blocks verbatim.
-
Self-author and maintain a version-controlled specification that evolves with each defect found, reducing error rates in subsequent conversions.
-
Operate across multiple model generations (e.g., Opus 4.6 to 4.8) with consistent performance, adapting to hardware and compiler constraints without human re-prompting.
-
Detect and correct its own verification blind spots (e.g., missing compiler flags) by auditing the generation process of both sides of differential tests.
-
Localize and fix regressions in minutes using automated bisection, then encode the fix as a permanent audit rule, achieving a final error rate of 0.01% (six lines out of 55,916).
-
Delegate all comprehension, code emission, test authoring, and documentation to agents, while humans only approve side-effecting commands and final merges, making modernization effort independent of code volume.
Abstract
Modernizing legacy Fortran is a problem of volume: the transformations are individually routine, but the codebases can be enormous, and across much of computational science the work simply goes undone. We propose an agentic workflow that takes this work on at production scale, and we set out to measure how far such delegation can reach. In this work, three prompt-specialized agent roles operate under a version-controlled specification that the agents themselves authored and revised, while humans hold a small number of gates. The arrangement is kept safe by an exact verification oracle inherited from the domain, and the boundary of safe delegation lies exactly where that oracle stops seeing. We apply the proposed workflow in a case study, converting the two-electron-integral routines of GAMESS (General Atomic and Molecular Electronic Structure System), a mature quantum-chemistry package with a 48-year development history, from fixed-form Fortran 77 to free-form Fortran 2008. The scope of this work was twelve source files, 56,448 lines, and 225 subroutines for computing electron repulsion integrals. The agents ran as three Claude Code roles in isolated worktrees, and the work spanned four Claude model generations. Because the GAMESS group ships a standard test suite whose printed energies its user community treats as canonical, we could adopt bit-for-bit reproduction of those energies as the merge criterion, where a deviation in the twelfth decimal place counts as a failure rather than drift. All twelve source files pass a 51-test validation battery comprising the 49 standard GAMESS tests and two additional calculations, and across 612 test runs the number of chemistry-relevant differences is zero, and every file also passes the Jenkins tests that are used for continuous integration.
Sources
- Large Language Model-Based Agents for Software Engineering: A Survey
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
- Fortran2CPP: Automating Fortran-to-C++ Translation using LLMs via Multi-Turn Dialogue and Dual-Agent Integration
- LLM-Assisted Translation of Legacy FORTRAN Codes to C++: A Cross-Platform Study
- From Legacy Fortran to Portable Kokkos: An Autonomous Agentic AI Workflow
Related papers
- MAVEN-T: Reinforced Heterogeneous Distillation for Real-Time Multi-Agent Trajectory Prediction
- Model Discovery Agent: LLM-assisted Bayesian experiment design for data-efficient discovery of mechanistic world models
- The Clinician's Veto: Navigating Trust, Liability, and Uncertainty in Autonomous AI Prescribing
- MindHelper: Closed-Loop Embodied Mental-State Reasoning for Precision Intervention
- Incumbent Advantage: Brand Bias and Cognitive Manipulation Dynamics in LLM Recommendation Systems
- VSAL: A Vision Solver with Adaptive Layouts for Graph Property Detection