Towards Transparent Checkpointing with AI-driven Code Generation Hai Duc Nguyen
[email protected] Argonne National Laboratory Lemont, IL, USA
Tekin Bicer
[email protected] Argonne National Laboratory Lemont, IL, USA
arXiv:2606.30921v1 [cs.DC] 29 Jun 2026
Ian Foster
Bogdan Nicolae
[email protected] UChicago and Argonne Chicago, IL, USA
[email protected] Argonne National Laboratory Lemont, IL, USA span heterogeneous infrastructure, from supercomputing centers to scientific instruments. This shift efficiently leverages heterogeneous accelerators and elastic capacity, but also reshapes the failure landscape: long-running MPI jobs that once executed on a single homogeneous batch allocation now span resources whose mean-timebetween-failure (MTBF) varies significantly; fluctuates dynamically as nodes are preempted, evicted, or reassigned under multi-tenant pressure; and is largely unpredictable at job-submission time [6, 23]. Under such circumstances, checkpoint/restart, the dominant resilience mechanism in HPC, faces several important challenges: (1) which data structures within those components are critical and must be protected, and (2) at what point in the code it is safe to checkpoint those data structures. These challenges directly impact the correctness, performance, and scalability of checkpoint/restart solutions used to enable resilient execution. Manual coding of checkpoint/restart solutions to address these challenges can be tedious due to the need to combine performance modeling; deep understanding of interactions under parallelism to maintain a consistent global state at scale; fine-tuning; and debugging. Recent advances in large language models (LLMs) and tool-using coding agents [24] offer a potential alternative that is both cheaper to implement and potentially more efficient. The performance of these systems on bounded software-engineering benchmarks now approaches that of professional developers [13], and their agentic workflows can autonomously read source trees, plan multi-step transformations, and react to validator feedback. We ask: can a frontier LLM coding agent be driven, end-to-end and with no human in the loop, to add production-grade checkpoint/restart resilience to unmodified MPI scientific applications, and at what cost in correctness, performance, and scalability? Key Insights and Contributions. This paper investigates the operational viability of LLM-driven resilience engineering as a building block for flexible scientific infrastructures. The observation we exploit is that the cognitive work of adding checkpoint/restart (identifying the data structures that make up the critical state, the correct place in the code where to checkpoint it, guarantee global consistency at scale, rebuild other data structures on restart based on the critical state) involves structured reasoning that modern coding agents are well suited for. The trade-off space, however, is far from understood: every iteration of the agent costs millions of tokens and tens of minutes of wall time; conservative state-coverage decisions inflate checkpoint footprint and erode scalability; a misidentified
Abstract Adding reliable checkpoint/restart support to an MPI scientific application is a time-consuming expert effort that requires deep knowledge of both the application and resilience. We ask whether a frontier large language model can perform this work end-toend without human intervention. We assemble a benchmark suite of MPI applications spanning diverse domains and computation patterns, and drive an iterative code-generation loop for each application using Anthropic’s Claude Opus 4.7 invoked through the OpenCode CLI. Across six scientific applications, the LLM generates working checkpoint/restart code in 50 minutes on average while consuming 3.4 M tokens per application. The generated code adds negligible overhead during normal failure-free execution on five of six applications and recovers from injected process failures with efficiency comparable to human-engineered checkpoint/restart implementations. These results suggest that automated end-to-end LLM-driven resilience engineering is technically viable today for a meaningful fraction of HPC applications.
CCS Concepts • Hardware → Fault tolerance; • Computing methodologies → Machine learning; • Software and its engineering → Checkpoint / restart.
Keywords checkpoint/restart, LLMs, resilience, HPC, fault tolerance ACM Reference Format: Hai Duc Nguyen, Tekin Bicer, Kyle Chard, Ian Foster, and Bogdan Nicolae. 2026. Towards Transparent Checkpointing with AI-driven Code Generation. In The 35th International Symposium on High-Performance Parallel and Distributed Computing (HPDC ’26), July 13–16, 2026, Cleveland, OH, USA. ACM, New York, NY, USA, 6 pages. https://doi.org/10.1145/3806645.3816239
1
Kyle Chard
[email protected] University of Chicago Chicago, IL, USA
Introduction
Modern scientific computing combines high performance computing (HPC) and artificial intelligence (AI) in complex workflows that This paper is authored by an employee(s) of the United States Government and is in the public domain. Non-exclusive copying or redistribution is allowed, provided that the article citation is given and the authors and agency are clearly identified as its source. Request permissions from owner/author(s). HPDC ’26, Cleveland, OH, USA 2026. ACM ISBN 979-8-4007-2640-8/2026/07 https://doi.org/10.1145/3806645.3816239 1
Table 1: Benchmark applications analyzed in this paper.
place in the code where it is safe to checkpoint silently corrupts a restart. Our goal is two-fold: (1) establish empirically that frontier LLM coding agents can produce correct (w.r.t. failure-free execution output), performant resilience code with no human intervention; and (2) characterize the cost, correctness and performance trade-offs that determine when this approach is practical for per-deployment resilience synthesis on dynamically provisioned, heterogeneous infrastructures. We summarize our contributions as follows:
App
Athena++ C++ CoMD C HPCG C++ LAMMPS C++ OpenLB C++ SPARTA C++
(1) End-to-end LLM-driven resilience pipeline: We design a closed-loop generate–validate–repair pipeline that drives a frontier coding agent to add VeloC-based checkpoint/restart to an unmodified MPI source tree with no human in the loop. The validator builds the generated code, runs it failure-free, injects a single-rank fault, and structurally checks that the application restarts correctly and reproduces the vanilla output (§ 4). (2) Reusable resilience benchmark suite: We assemble six MPI applications covering diverse domains, code sizes, state structures, and checkpoint back-ends. Each is shipped with a resiliencestripped vanilla source (given to the agent) and an upstreamcheckpointed reference (human-engineered baseline) (§ 3). (3) Empirical characterization of the cost, correctness and performance/scalability trade-off: We quantify all three axes across the suite. On cost, the agent converges in a median of two iterations, averaging 3.4 M tokens and 50 minutes of loop wall time per application. On correctness, it consistently identifies a small, sufficient critical-state set and globally safe checkpoint points on every application. On performance, the generated code imposes statistically zero failure-free overhead on five of six apps and recovers from injected faults within ±6% of the upstream human-engineered reference (§ 5).
2
Lang
Checkpoint mech.
LOC
native POSIX POSIX native native native
132K 5.6K 6.2K 627K 338K 174K
process state automatically, but often include caches, transient buffers, and rebuildable state. This can produce oversized checkpoints, limit scalability under elasticity, and complicate portability across heterogeneous nodes. Compiler-assisted approaches [5] narrow the snapshot through static analysis, but require per-language passes and can struggle with the templated, dynamically allocated, irregularly accessed data structures common in modern HPC and AI codes. Although transparent and compiler-assisted approaches can benefit from the same multi-level optimizations, they do not provide the combination we target: low-effort automation with application-level checkpoint efficiency. To our knowledge, no prior work has attempted to study frontier LLM code generation to the point where it allows end-toend automation (i.e., analyze the application code and generate application-level checkpointing that captures a minimal critical state), thus combining the advantages of transparent checkpointing with application-level checkpointing.
3
Resilient Benchmark Suites
To test the effectiveness of frontier LLM models with respect to automated resilience, we assembled a benchmark suite of unmodified MPI scientific applications drawn from a wide spectrum of HPC domains. Three selection criteria apply: (i) each application must be open source and reproducible from its upstream repository; (ii) each must ship with a native checkpoint/restart implementation we can use as the upstream-reference baseline; and (iii) together the suite must cover diverse data-structure shapes (fixed-size arrays, variable-per-rank particle pools, adaptive meshes), per-step synchronization patterns, and checkpoint back-ends. We identified six applications, listed in Table 1, that meet these criteria. These applications span six computational domains and present distinct checkpointing challenges:
Related Work
Application-level checkpointing approaches such as VeloC [22], FTI [4], and SCR [20] require developers to manually declare critical state, place checkpoint calls at safe points, and wire restart logic into initialization paths. By saving only the state needed for recovery, they keep checkpoints small and reduce both runtime and storage overhead. These systems typically rely on multi-level resilience strategies [16, 20], where checkpoints are staged to a fast node-local tier, such as RAM, for recovery from frequent soft failures, then asynchronously flushed to a slower shared tier, such as a parallel file system, to survive critical failures. A rich body of work further optimizes this pipeline: asynchronous flush engines overlap checkpoint I/O with application compute [17, 19]; write aggregation coalesces per-rank writes into stripe-aligned bulk transfers [11]; differential and incremental checkpointing persist only changed bytes [21, 27]; and compression or lossy encoding reduces footprint at modest reconstruction cost [15, 18]. Checkpoint cadence is also optimized: the classical Young [30]–Daly [7] formulas minimize expected wasted work from MTBF and checkpoint cost, while adaptive variants track fluctuating MTBF on dynamically provisioned, multi-tenant resources [8]. These mechanisms reduce resilience cost at scale, but still presuppose the manual instrumentation step we automate: someone must decide what to checkpoint and where. By contrast, transparent checkpointing tools such as BLCR [12], DMTCP [1], and CRIU [28] reduce developer effort by capturing
(1) HPCG [9]: a conjugate-gradient sparse linear solver whose main loop runs a fixed number of independent CG solves and accumulates a residual after each one. (2) CoMD [10]: a classical molecular dynamics proxy in which atoms move under pairwise forces and may migrate between MPI subdomains each timestep. (3) OpenLB [14]: a lattice-Boltzmann fluid solver whose central per-rank object is a large lattice with built-in buffer serialization. (4) SPARTA [25]: a direct-simulation Monte Carlo code for rarefied gases in which particles drift between ranks every timestep, leaving each rank with a different particle count. (5) Athena++ [26]: an astrophysical magnetohydrodynamics code with a mesh topology that evolves via adaptive mesh refinement. 2
LLM (Claude Opus 4.7)
Reference codebase
Remove resilient code Vanilla codebase
Initial prompt Coding Agent (OpenCode)
Resilient code injected “Resilient” codebase
Validation
Retry
Validator
PASS
Inspection
FAIL
Figure 1: End-to-end LLM-driven pipeline for adding checkpoint/restart resilience to an unmodified MPI application. (6) LAMMPS [29]: a production molecular dynamics code with extensive topological connectivity and diverse plugin state.
validator passes before that cap, the resulting code is promoted to the inspection phase analyzed in §5.
Together they mix C and C++ codebases, fixed-size and variablesize per-rank state, and both POSIX and native checkpoint backends, exercising the principal checkpoint patterns encountered in production MPI software.
Metrics and Configurations. The inspection phase collects four metrics per application: (i) Code generation time: cumulative wall time of the LLM/validator loop, including both the agent’s thinking time and the validator’s build/run time; (ii) Total tokens: input plus output tokens consumed across all iterations, a direct proxy for API spend; (iii) End-to-end execution time: wall time of one application run under each scenario, quantifying both instrumentation overhead and recovery cost; and (iv) Per-frame checkpoint footprint: bytes written by a single checkpoint event, capturing the storage cost of the chosen state coverage. All measurements were collected on a single development host with four MPI ranks per application. Per-app input arguments were tuned so one failure-free run takes 60–200 s, short enough to keep the iterative loop tractable yet long enough for failure injection to produce meaningful checkpoint, recovery, and output signals. For every (application, scenario) cell we run three independent trials and report the mean. All runs use the latest released version of VeloC [22].
4
Methodology
Code Generation Pipeline. Figure 1 sketches the end-to-end pipeline to test whether a frontier LLM can autonomously add checkpoint/restart resilience to an MPI scientific code. We strip the upstream source of any existing resilience logic to produce a vanilla codebase; this is the only artifact the LLM ever sees. We then drive an iterative code-generation loop, in which each iteration executes two phases in sequence with no human in the loop: (1) Code Generation. We give Anthropic’s Claude Opus 4.7 [3], invoked through the opencode coding-agent CLI [24], the vanilla source tree plus a fixed instruction prompt that asks it to use VeloC [22] (a multi-level checkpoint/restart runtime designed for HPC) to protect the application against process failure. The agent issues read/edit tool calls on the source tree and writes a modified copy we call the resilient codebase, which must preserve the vanilla code’s functional behavior while adding fault tolerance. The prompt also asks the agent to log its reasoning, intended action, observed result, and next step at every iteration, giving us a per-step transcript of the transformation. (2) Validation. An independent validator builds the resilient codebase and, if success, runs it under two scenarios. Failure-free execution confirms that the modified code still produces output equivalent to the vanilla, ensuring the functional contract is intact. Failure-injected execution kills one rank mid-run, relaunches the binary, and checks four conditions: (i) at least one checkpoint file was written before the kill; (ii) the harness delivered the failure (no spurious early exit); (iii) the post-restart output matches the vanilla, confirming the checkpoint and recovery path reproduces the intended results; and (iv) end-to-end wall time stays meaningfully below a full restart-from-scratch, evidence the checkpoint cadence is operationally useful.
5
Key Findings
We trace what actually happens inside the iterative loop, distilled from the per-iteration opencode_stdout transcripts that record the agent’s reasoning and actions step by step. Across all six applications the transcripts reveal the same four-phase procedure, applied with few app-specific deviations: (1) Reconnaissance. The agent locates the application’s main timestep loop, starting from the entry-point file (main.cpp or equivalent) and following function calls inward. It also locates the VeloC installation on disk and reads the VeloC documentation to learn the API it will need. (2) Critical-state identification. The agent walks the application’s central data structure field by field and labels each field as either rebuildable (the input deck plus the application’s own initialization code can recreate it) or evolving (the value changes inside the timestep loop and therefore must be saved). (3) Implementation. The agent wires VeloC into the application: it initializes the runtime at startup, declares memory regions of evolving fields to checkpoint, calls the checkpoint primitive at a chosen cadence inside the timestep loop, and adds a startup branch that detects an existing checkpoint, restores the saved state, and resumes the loop from the saved counter. (4) Correction. When an implementation fails validation, the agent uses the validator’s failure report, as its primary feedback. Each
If any check fails or the run times out, the loop iterates: the agent receives the original prompt, its previous resilient code, and the validator’s structured feedback (build log, execution stdout/stderr, per-condition pass/fail flags) and is asked to produce a corrected version. Each application is allowed up to ten iterations; if the 3
10
Code time (min) Codegeneration generation time (
100
Total tokens (millions) Total tokens (millio
120
Code generation Validation
80 60 40 20
8
Input Output
6
4
2
0
0 HP
CG
D
CoM
LB
n Ope
RTA SPA
+
At
a+ hen
CG
HP
S MP LAM
D
CoM
nLB
Ope
RTA
SPA
na+
e Ath
+
S
MP
LAM
Figure 3: Total Claude Opus 4.7 tokens consumed by the iterative loop, per app (Output tokens are negligible).
Figure 2: Time consumed by the LLM iterative loop to produce a working checkpoint/restart implementation, per app.
have been both labor-intensive and high-risk. The agent instead implemented a writer/reader pair dedicated to Athena++’s mesh format to dump and reconstruct the critical state from disk.
subsequent iteration begins by analyzing this report, forming a single hypothesis about the likely source of the fault, and applying a targeted fix.
LAMMPS (7 iterations to PASS). LAMMPS has the most complex state in the suite. Its atoms move between ranks as in SPARTA, but it also tracks two things no other app does: bonds and angles that link atoms together (a graph the checkpoint must keep consistent after migration), and many small pieces of state owned by whichever optional physics modules the user enables (each keeps its own counters and random-number state).
This procedure successfully transformed all six vanilla codebases into resilient ones. We walk through each application below to show how the procedure plays out against the codebase’s structure. HPCG (2 iterations to PASS). HPCG is the suite’s simplest case: each CG solve starts from the same zeroed initial vector and no state carries over between solves, so the only critical state is a counter plus the residual array. The agent rejected saving the sparse matrix, multigrid hierarchy, and per-solve scratch vectors as deterministically rebuildable from the input dimensions.
Cross-cutting observations. Two interesting patterns recur across all six apps. First, the agent always starts from a small state-coverage set rather than a conservative everything one: it picks the few fields that actually evolve, defends every rejection in writing, and only adds coverage if validator feedback forces it. This is the proximate reason for resulting checkpoints being small enough to write without measurable runtime overhead. Second, after identifying the critical state, the agents often do not proceed directly to implementation. Instead, they perform additional code reading to find and reuse existing utilities for handling critical-state save/load operations, such as serialization and file I/O. This helps them generate cleaner and lower-risk code.
CoMD (2 iterations to PASS). CoMD is harder than HPCG because state evolves inside the timestep loop: atoms migrate between MPI subdomains every step, so the per-rank atom list (positions, momenta, forces, identifiers) plus a small link-cell bookkeeping array changes continuously. Everything else (simulation box, species table, potentials, link-cell geometry) is fixed at startup, and halo cells are repopulated on the first post-restart timestep by CoMD’s own halo-exchange. The agent saved the atom arrays plus the loop counter and skipped halos.
Time to Construct Resilient Code. The iterative loop consumed 5.0 hours total across the six apps, averaging 50 minutes per app, with a ∼6.5× spread between the fastest (HPCG, 14 min) and the slowest (LAMMPS, 92 min). Figure 2 decomposes per-app loop time into LLM code generation (dark blue, bottom) and validation (light blue, top): code generation dominates on every app, taking a median of 61% of the total (range 50–84%). The bar shapes track the difficulty ordering. HPCG (14 min) and CoMD (22 min) sit at the bottom because their critical state is small and fixed-size per rank, so the first iteration design was structurally correct and the second iteration only fixed a one-line operational glitch. SPARTA (64 min) sits in the middle. Athena++ (87 min) and LAMMPS (92 min) dominate the chart because their richer state surfaces forced multiple iterations to capture and recover correctly.
OpenLB (1 iteration to PASS). OpenLB stores far more data per process than CoMD, and that data is tangled inside an internal object whose layout would be tedious and error-prone to list by hand. Conveniently, OpenLB already provides three helper methods designed for sending the object between processes (return size, pack into a buffer, unpack from a buffer); after an intensive search over the codebase, the agent found and reused them as a black-box serialization, so it never needed to know what the object contains. SPARTA (2 iterations to PASS). SPARTA introduces a new wrinkle: per-rank particle counts vary because particles drift between ranks every timestep, ruling out fixed-size memory regions. The agent used VeloC’s file-based API to write a small structured payload per rank (timestep counter, simulation-time scalars, particle count, particle array, RNG state) and skipped the static grid topology, species tables, and master RNG.
Token Cost. Total tokens across the six apps sum to 20.2 M (average 3.4 M per app), corresponding to roughly $50–400 in API spend at current frontier-model rates [2]. Figure 3 spans ∼28×, from CoMD’s 0.28 M up to OpenLB’s 7.81 M. Token cost correlates only loosely with code generation time. OpenLB tops the chart at
Athena++ (4 iterations to PASS). Athena++ raises the stakes again: its state lives in an evolving AMR mesh tree plus a long list of conditional physics arrays, so field-by-field enumeration would 4
400
Execution Timefailure-in (s) Execution time,
Execution Time (s)failure Execution time,
350 200 Vanilla (no resilience) LLM-modified
150
Reference
100 50 0 HP
CG
D
CoM
nLB
Ope
RTA
SPA
na+
e Ath
+
S MP
300 Vanilla (no resilience) LLM-modified Reference
250 200 150 100 50 0
CG
HP
LAM
Figure 4: Per-app average execution time under the failurefree scenario.
D
CoM
nLB Ope
RTA
SPA
+
na+
e Ath
S
MP
LAM
)
Figure 6: Per-app end-to-end execution time with a failure injected mid-run. (HPCG: LLM 66 KB vs. reference 6 KB; OpenLB: LLM 3 MB vs. reference 157 KB) the LLM is more conservative, persisting diagnostic accumulators the reference recomputes on restart.
LLM-modified Reference
Checkpoint Footprint (bytes)
108
Resilience. Figure 6 shows per-app end-to-end runtime when the validator kills one MPI rank mid-run, then restarts the app. The LLM runtime sits close to the reference on every app, ranging from 6% faster (Athena++) to 3% slower (CoMD, SPARTA), and both are roughly one third faster than the vanilla baseline, which has no checkpoint protection and pays the full 50% wall-clock penalty of restarting from scratch. This is operational evidence the LLMgenerated code does real recovery work: detecting checkpoint files, restoring state, and resuming with overhead bounded by the checkpoint cadence rather than by the size of the original computation.
107
106
105
104 CG
HP
D
CoM
nLB
Ope
RTA
SPA
na+
e Ath
+
S
MP
LAM
Figure 5: Payload size of a full recoverable checkpoint.
6
Conclusion and Future Work
This paper investigates whether frontier LLM coding agents can automate end-to-end checkpoint/restart integration for existing MPI scientific applications. Across six applications with diverse domains, code sizes, data structures, and checkpointing patterns, the agent generated working resilient implementations without human intervention after the initial prompt. The generated code achieved near-zero failure-free overhead on five of six applications, recovered from injected failures with performance close to upstream native implementations, and converged in under two hours per application. These results suggest that LLM-driven resilience engineering can substantially reduce the expert effort required to add productiongrade fault tolerance to a meaningful subset of HPC applications. Future work should improve the robustness, scalability, and usability of this approach. Specialized pipelines with resiliencespecific skills, source-code summarization, checkpoint-state analysis, and targeted validation feedback could reduce cost and improve reliability. Broader evaluations are needed for repeated failures, realistic I/O environments, multi-node executions, and applications with more irregular or distributed state. Finally, generated checkpoint code should become easier to audit, maintain, and integrate into production workflows so that automated resilience generation can be used safely in practice.
7.81 M despite completing in a single iteration, because the agent had to scan a substantial portion of OpenLB’s 338K-line source tree to discover the built-in serialize methods for checkpoint serialization. CoMD sits at the bottom (0.28 M) because of its small codebase and critical state. LAMMPS at 6.91 M is large despite a small state struct because each iteration re-read the integrator and atom-management sources. The stacked decomposition shows that input tokens account for roughly 99% of every bar (19.98 M input vs. 0.19 M output across the suite). Input-context size is the dominant token cost driver, so pre-summarizing or chunking large source trees would translate directly into spend reductions, especially on apps such as OpenLB where exploration substantially exceeded eventual edits. Overhead: Runtime and Storage. Figure 4 shows an important result: the LLM-generated checkpoint instrumentation imposes essentially zero overhead. Five of six apps fall within ±2% of vanilla wall time (from -1.4% for LAMMPS to +0.2% for CoMD and OpenLB), inside measurement noise. The outlier is Athena++ at +15.2%, where the agent chose an aggressive 8 s cadence that trades failure-free performance for faster recovery. The LLM bars also track the upstream reference closely on every app, showing that the generated code matches a human-engineered native implementation. Figure 5 shows full-checkpoint sizes spanning four orders of magnitude, from HPCG’s 66 KB (residual array plus a few scalars) up to CoMD’s 194 MB (full per-rank atom array). LLM and reference agree on the order of magnitude for four of six apps (CoMD, SPARTA, Athena++, LAMMPS). On the two where they diverge
Acknowledgments This work was supported in part by U.S. Department of EnergyContract DE-AC02-06CH11357, and National Science Foundation grants CSSI-2411386 and CSSI-2514056. 5
References
Modeling, Analysis, and Simulation of Computer and Telecommunication Systems. Virtual, Portugal, 1–8. [17] Avinash Maurya, Mustafa Rafique, Thierry Tonellot, Hussain AlSalem, Franck Cappello, and Bogdan Nicolae. 2023. GPU-Enabled Asynchronous Multi-level Checkpoint Caching and Prefetching. In HPDC’23: The 32nd International Symposium on High-Performance Parallel and Distributed Computing. Orlando, USA, 73–85. [18] Avinash Maurya, M. Mustafa Rafique, Franck Cappello, and Bogdan Nicolae. 2023. Towards Efficient I/O Pipelines using Accumulated Compression. In HIPC’23: 30th IEEE International Conference on High Performance Computing, Data, and Analytics. Goa, India, 256–265. [19] Avinash Maurya, Robert Underwood, Mustafa Rafique, Franck Cappello, and Bogdan Nicolae. 2024. DataStates-LLM: Lazy Asynchronous Checkpointing for Large Language Models. In HPDC’24: The 33rd International Symposium on High-Performance Parallel and Distributed Computing. Pisa, Italy, 227–239. [20] Adam Moody, Greg Bronevetsky, Kathryn Mohror, and Bronis R De Supinski. 2010. Design, modeling, and evaluation of a scalable multi-level checkpointing system. In SC’10: The 2010 ACM/IEEE International Conference for High Performance Computing, Networking, Storage and Analysis. New Orleans, USA, 1–11. [21] Bogdan Nicolae and Franck Cappello. 2013. AI-Ckpt: Leveraging Memory Access Patterns for Adaptive Asynchronous Incremental Checkpointing. In HPDC’13: 22nd International ACM Symposium on High-Performance Parallel and Distributed Computing. New York, USA, 155–166. [22] Bogdan Nicolae, Adam Moody, Elsa Gonsiorowski, Kathryn Mohror, and Franck Cappello. 2019. VeloC: Towards High Performance Adaptive Asynchronous Checkpointing at Large Scale. In IPDPS’19: The 2019 IEEE International Parallel and Distributed Processing Symposium. Rio de Janeiro, Brazil, 911–920. [23] Bogdan Nicolae, Justin Wozniak, Tekin Bicer, Hai Nguyen, Parth Patel, Haochen Pan, Amal Gueroudji, Maxime Gonthier, Valerie Hayot-Sasson, Eliu Huerta, Kyle Chard, Ryan Chard, Matthieu Dorier, Nageswara S. V. Rao, Anees Al-Najjar, Alessandra Corsi, and Ian Foster. 2024. Diaspora: Resilience-Enabling Services for Real-Time Distributed Workflows. In NRDPISI’24: The 1st International Workshop on Near Real-time Data Processing for Interconnected Scientific Instruments (colocated with eScience’24). Osaka, Japan, 1–9. [24] OpenCode. 2024. OpenCode: Open-source AI coding agent. https://opencode.ai/. [25] Steven J. Plimpton, Stan G. Moore, Arnaud Borner, Alan K. Stagg, Timothy P. Koehler, John R. Torczynski, and Michail A. Gallis. 2019. Direct Simulation Monte Carlo on Petaflop Supercomputers and Beyond. Physics of Fluids 31, 8 (2019), 086101. [26] James M. Stone, Kengo Tomida, Christopher J. White, and Kyle G. Felker. 2020. The Athena++ Adaptive Mesh Refinement Framework: Design and Magnetohydrodynamic Solvers. The Astrophysical Journal Supplement Series 249, 1 (2020), 4. [27] Nigel Tan, Jakob Luettgau, Jack Marquez, Keita Terianishi, Nicolas Morales, Sanjukta Bhowmick, Franck Cappello, Michela Taufer, and Bogdan Nicolae. 2023. Scalable Incremental Checkpointing using GPU-Accelerated De-Duplication. In ICPP’23: The 52nd International Conference on Parallel Processing. Salt Lake City, USA, 665–674. [28] The CRIU Project. 2024. CRIU: Checkpoint/Restore in Userspace. https://criu.org. [29] A. P. Thompson, H. M. Aktulga, R. Berger, D. S. Bolintineanu, W. M. Brown, P. S. Crozier, P. J. in ’t Veld, A. Kohlmeyer, S. G. Moore, T. D. Nguyen, R. Shan, M. J. Stevens, J. Tranchida, C. Trott, and S. J. Plimpton. 2022. LAMMPS – a flexible simulation tool for particle-based materials modeling at the atomic, meso, and continuum scales. Computer Physics Communications 271 (2022), 108171. [30] John W Young. 1974. A first order approximation to the optimum checkpoint interval. Commun. ACM 17, 9 (1974), 530–531.
[1] Jason Ansel, Kapil Arya, and Gene Cooperman. 2009. DMTCP: Transparent Checkpointing for Cluster Computations and the Desktop. In IPDPS’09: The 2009 IEEE International Parallel and Distributed Processing Symposium. Rome, Italy, 1–12. [2] Anthropic. 2025. Pricing. https://www.anthropic.com/pricing. Accessed: 202605-04. [3] Anthropic. 2026. Introducing Claude Opus 4.7. https://www.anthropic.com/ news/claude-opus-4-7. [4] Leonardo Bautista-Gomez, Seiji Tsuboi, Dimitri Komatitsch, Franck Cappello, Naoya Maruyama, and Satoshi Matsuoka. 2011. FTI: High Performance Fault Tolerance Interface for Hybrid Systems. In SC’11: The 2011 ACM/IEEE International Conference for High Performance Computing, Networking, Storage and Analysis. Seattle, USA, 32:1–32:32. [5] Greg Bronevetsky, Daniel Marques, Keshav Pingali, and Paul Stodghill. 2003. Automated Application-Level Checkpointing of MPI Programs. In PPoPP’03: The 9th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming. San Diego, USA, 84–94. [6] Franck Cappello, Al Geist, William Gropp, Sanjay Kale, Bill Kramer, and Marc Snir. 2014. Toward exascale resilience: 2014 update. Supercomputing Frontiers and Innovations: An International Journal 1, 1 (2014), 5–28. [7] John T Daly. 2006. A higher order estimate of the optimum checkpoint interval for restart dumps. Future Generation Computer Systems 22, 3 (2006), 303–312. [8] Tonmoy Dey, Kento Sato, Bogdan Nicolae, Jian Guo, Jens Domke, Weikuan Yu, Franck Cappello, and Kathryn Mohror. 2020. Optimizing Asynchronous MultiLevel Checkpoint/Restart Configurations with Machine Learning. In HPS’20: The 2020 IEEE International Workshop on High-Performance Storage. New Orleans, USA, 1036–1043. [9] Jack Dongarra, Michael A Heroux, and Piotr Luszczek. 2016. High-performance conjugate-gradient benchmark: A new metric for ranking high-performance computing systems. The International Journal of High Performance Computing Applications 30, 1 (2016), 3–10. [10] Exascale Co-Design Center for Materials in Extreme Environments. 2017. CoMD: Classical Molecular Dynamics Proxy Application. https://github.com/ECP-copa/ CoMD. [11] Mikaila J. Gossman, Bogdan Nicolae, and Jon C. Calhoun. 2024. Scalable I/O aggregation for asynchronous multi-level checkpointing. Future Generation Computer Systems 160 (2024), 420–432. [12] Paul H. Hargrove and Jason C. Duell. 2006. Berkeley Lab Checkpoint/Restart (BLCR) for Linux Clusters. Journal of Physics: Conference Series (SciDAC) 46 (2006), 494–499. [13] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R. Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. In ICLR’24: The 12th International Conference on Learning Representations. Vienna, Austria. [14] Mathias J. Krause, Adrian Kummerländer, Samuel J. Avis, Halim Kusumaatmaja, Davide Dapelo, Fabian Klemens, Maximilian Gaedtke, Nicolas Hafen, Albert Mink, Robin Trunk, et al. 2021. OpenLB: Open Source Lattice Boltzmann Code. Computers & Mathematics with Applications 81 (2021), 258–288. [15] Xin Liang, Sheng Di, Dingwen Tao, Sihuan Li, Bogdan Nicolae, Zizhong Chen, and Franck Cappello. 2019. Improving Performance of Data Dumping with Lossy Compression for Scientific Simulation. In CLUSTER’19: IEEE International Conference on Cluster Computing. Albuquerque, USA, 1–11. [16] Avinash Maurya, Bogdan Nicolae, Mustafa Rafique, Thierry Tonellot, and Franck Cappello. 2021. Towards Efficient I/O Scheduling for Collaborative Multi-Level Checkpointing. In MASCOTS’21: The 29th IEEE International Symposium on the
6