Data Provenance for Simulation Codes
Provenance records the complete lineage of a simulation result, so any number can be traced to the exact code, inputs, and environment that produced it.
Trusting a number
A simulation result is only as credible as the record of how it was made. Provenance is the systematic capture of that record: which code version, which inputs, which data libraries, which computing environment, and which sequence of steps produced a given output. Without it, a result cannot be checked or defended.
What to capture
- Exact code version, ideally a commit hash of the source
- All input files and parameters, with checksums
- External data such as cross-section or atomic libraries and their versions
- The computing environment: compilers, libraries, and settings
- The full chain of steps if the result is from a pipeline
Content addressing
A robust way to identify inputs and outputs is by a cryptographic hash of their content. Two files with the same hash are identical; a changed input yields a different hash. Content addressing lets a system detect silently altered inputs and confirm that a re-run used exactly the same data.
Why fusion needs it
Fusion design decisions rest on simulations, and those simulations feed public claims and peer review. Provenance makes it possible to answer, for any figure, exactly how it was computed, to reproduce it, and to update it correctly when an input changes. It is the backbone of honest, auditable analysis.
Practical implementation
Provenance is captured automatically by the workflow system rather than recorded by hand, since manual records drift from reality. Every run writes a manifest of its inputs, versions, and outputs, stored alongside the results so the lineage travels with the data.
Kronos treats provenance as a requirement: reported physics numbers are tied to versioned inputs and a documented pipeline that can regenerate them.