Scientific applications continue to rely on legacy Fortran codebases originally developed for homogeneous, CPU-based systems. As High-Performance Computing (HPC) shifts toward heterogeneous GPU-accelerated architectures, many accelerators lack native Fortran bindings, creating an urgent need to modernize legacy codes for portability. Frameworks like Kokkos provide performance portability and a single-source C++ abstraction, but manual Fortran-to-Kokkos porting demands significant expertise and time. Large language models (LLMs) have shown promise in source-to-source code generation, yet their use in fully autonomous workflows for translating and optimizing parallel code remains largely unexplored, especially for performance portability across diverse hardware. This paper presents an agentic AI workflow where specialized LLM "agents" collaborate to translate, validate, compile, run, test, debug, and optimize Fortran kernels into portable Kokkos C++ programs. Results show the pipeline modernizes a range of benchmark kernels, producing performance-portable Kokkos codes across hardware partitions. Paid OpenAI models such as GPT-5 and o4-mini-high executed the workflow for only a few U.S. dollars, generating optimized codes that surpassed Fortran baselines, whereas open-source models like Llama4-Maverick often failed to yield functional codes. This work demonstrates the feasibility of agentic AI for Fortran-to-Kokkos transformation and offers a pathway for autonomously modernizing legacy scientific applications to run portably and efficiently on diverse supercomputers. It further highlights the potential of LLM-driven agentic systems to perform structured, domain-specific reasoning tasks in scientific and systems-oriented applications.
Figures & tables
Kernel
Type
Modularized Subroutine Lines of Code
CG
Memory-bound
165
EP
Compute-bound
129
MG
Memory-bound
139
FT
Memory-bound
230
DGEMM
Compute-bound
177
BIHARMONIC
Memory-bound
256 (132 + 124) *
Table I: Benchmarks used in this work
Figure 1: Agentic AI workflow for autonomous Fortran-to-Kokkos translation, validation, compilation, runtime execution, functionality testing, and performance optimization. Fixer Agents are triggered on error events ( e.g. , failed compilation, runtime fault, or incorrect functionality testing output). Agent invocation limits at each stage are enforced via configurable thresholds ( e.g. , MAX_COMPILE_FIXES ). Function tools invoked by the Build and Run agents ( build \ _kokkos \ _program , run \ _kokkos \ _program ) utilize SLURM to schedule and monitor jobs and Spack to load the correct Kokkos environment on the hardware partitions. All artifacts and metrics are versioned and stored per version run using the store \ _results function.
Figure 2: Example NVIDIA Nsight Compute OPT suggestion
GPU
CPU
Arch.
CPU Cores
NVIDIA A100, 40 GiB HBM2
AMD EPYC 7763
x86_64
64
AMD MI250, 64 GB HBM2e
2× EPYC 7763
x86_64
128
NVIDIA GH200, 96 GB HBM3
ARM Neoverse-V2
aarch64
72
Table II: Hardware Specifications
Software
Version
Software
Version
Spack
1.0.0.dev0
GCC
8.5.0
CMake
3.31.6
Kokkos
4.6.01
CUDA
12.6.3
HIP
6.4.0
Python
3.11.13
OpenAI Agents SDK
0.1.0
LiteLLM
1.73.6
Ollama
0.11.4
Table III: Software Versions
Model
Provider
Type
Size (parameters)
Cost (in/out, per 1M tokens)
GPT-5 [ 20 ]
OpenAI
Proprietary
Unknown
1.25/10
o4-mini-high [ 21 ]
OpenAI
Proprietary
Unknown
1.10/4.40
gpt-oss-120b [ 22 ]
OpenAI
Open- weights
117B total 5.1B active
-
Qwen3.5-397B -A17B [ 23 ]
Alibaba
Open- weights
397B total 17B active
-
Llama 4 Maverick [ 24 ] †
Meta
Open- weights
400B total 17B active
-
Table IV: LLMs Used
Kernel
MIN_N
MAX_N
Num. of Sizes ( n )
Program Iters.
Kernel Reps ( r )
CG
1000
1000000
10
2-5
500
EP
18
28
5
2-5
50
MG
32
256
10
2-10
250
FT
32
128
5
2-5
50
DGEMM
1024
4096
5
2-5
5
BIHARMONIC
64
2048
5
2-5
100
Table V: Runtime Settings for the A100 Evaluation Matrix
Figure 3: Number of Build, Run, and Functionality Tester agent invocations per kernel on the NVIDIA A100, grouped by LLM within each kernel. Each version’s contribution to a bar is averaged over the runs that reached that version, so runs that terminate early contribute to fewer versions; error bars denote ± 1 standard deviation. The five dots above each group show how many of the five runs completed every optimization round through v6 (filled) or terminated earlier (open). An asterisk marks EP with gpt-oss-120b, where no run produced a functionally correct baseline, so no bars are shown.
Model
Type
Functional baseline *
Full workflow completed †
GPT-5
Proprietary
29/30 (97%)
24/30 (80%)
o4-mini-high
Proprietary
28/30 (93%)
17/30 (57%)
gpt-oss-120b
Open-weights
19/30 (63%)
11/30 (37%)
Qwen3.5-397B-A17B
Open-weights
19/30 (63%)
8/30 (27%)
Table VI: Per-model success rates across the 120-run A100 evaluation matrix (six kernels, five runs each, 30 runs per model).
Figure 4: Mean OpenAI API token cost per kernel on the NVIDIA A100 for GPT-5 and o4-mini-high, averaged over the five runs. Each bar is stacked into input token cost (dark) and output token cost (light) and covers the full workflow, including the baseline and all optimization rounds.
Figure 5: Optimization trajectory of the DGEMM kernel on the NVIDIA A100, measured in GFLOPS at the maximum input size across successive versions (v1 baseline through v6). Each panel corresponds to one LLM; the solid line is the median across runs and the shaded band the interquartile range. The gray number beneath each version is the count of runs (out of five) that produced a functionally correct version at that stage.
Figure 6: Optimization trajectory of the biharmonic kernel on the NVIDIA A100, reported as wall-clock speedup over the baseline (v1) at the maximum input size. The panel layout, median line, interquartile band, and per-version surviving run counts follow Fig. 5 . The n in each panel title is the number of runs, out of five, that produced a functionally correct baseline.
Figure 7: Mean runtime of the FT kernel on the NVIDIA A100 against problem size, with runtime shown on a logarithmic scale, comparing the Fortran CPU (OpenMP) baseline, the Kokkos CPU (OpenMP) translation from the best version of GPT-5, and the best Kokkos GPU version produced by different LLMs. Each line is the mean over the five runs.
Figure 8: Mean runtime of the CG kernel on the AMD MI250 against problem size on log-log axes, comparing the Fortran CPU (OpenMP) baseline with the best Kokkos GPU version from each model in the supplementary single-run cross-architecture experiments: GPT-5, o4-mini-high, and Llama 4 Maverick.
Kernel (s = input size)
Best LLM
Achieved Performance
Arithmetic Intensity (FLOP/byte)
% of Roof Achieved
Bound
CG ( s=106 )
Qwen3.5-397B-A17B
998.89 GFLOPS
0.839
76.54%
Memory
EP ( log2s=28 )
GPT-5
6.23 TFLOPS
>104
83.07%
Compute
MG ( s=256 )
o4-mini-high
2.80 TFLOPS
2.898
62.11%
Memory
FT ( s=128 )
Qwen3.5-397B-A17B
268.50 GFLOPS
1.021
16.91%
Memory
DGEMM ( s=4096 )
Qwen3.5-397B-A17B
2.63 TFLOPS
11.666
35.12%
Compute
BIHARMONIC ( s=2048 )
GPT-5
2.91 TFLOPS
16.895
11.07%
Memory
Table VII: Roofline analysis (double precision) for the best-performing version of each kernel on the NVIDIA A100.
Code translation converts programs between languages, frameworks, and representations while aiming to preserve behavior and sometimes improve safety or performance.