Cross-code k-eff discrepancies are hard to audit. A thread will report that OpenMC and SCALE disagree by a few hundred pcm on a criticality or depletion case, but the inputs, the nuclear data library, and the exact code commit usually drift between the two runs, so the gap cannot be pinned to one cause.
SMRFORGE is an open-source, screening-grade SMR reactor-physics engine (v0.14.0) built around that problem. It screens a case with its own engine and can escalate the case to OpenMC for a continuous-energy transport result, then seals the whole run as a signed, offline-verifiable evidence bundle.
Here is one benchmark, HTR-10 first criticality (IAEA TECDOC-1382 Part 2), with the SMRFORGE OpenMC escalation run taken from its sealed bundle.
| Source | k-eff | 1 sigma | library |
|---|---|---|---|
| Measured (TECDOC-1382 Part 2) | 1.0000 | 0.0037 | n/a |
| SMRFORGE via OpenMC (sealed bundle) | 1.016588 | 0.001023 | ENDF/B-VIII.1 |
C/E for the SMRFORGE run is 1.01659, about +1659 pcm over the measured value. That offset tracks the documented HTGR continuous-energy over-prediction seen across the published Monte Carlo literature (graphite thermal scattering, TRISO double heterogeneity), and no parameter was tuned toward k = 1.
To be precise about what this measures, the k-eff is OpenMC’s continuous-energy result, with SMRFORGE as the harness that ran it on the sealed inputs and the evidence layer that signed and froze it, so the offset is OpenMC against the measured benchmark, not a SMRFORGE accuracy claim.
Run provenance, read from the bundle.
OpenMC 0.15.3 (commit 27e38e8), continuous energy
engine_version 0.14.0+85c9b00
data_library endf/b-viii.1
12000 particles, 80 active, 25 inactive, rng_seed 1
explicit TRISO + explicit pebble bed (16960 pebbles, 9689 fuel)
Python 3.11.16, Linux x86_64
A reader checks it offline two ways. Verify recomputes the SHA-256 digests over inputs, result, and provenance, rolls them into bundle_sha256, and checks the Ed25519 signature over that digest against the pinned public key. Reproduce re-runs OpenMC on the sealed inputs and accepts a re-run within the sealed 3 sigma tolerance on k-eff, not bit for bit.
Limitations, stated plainly. This is screening-grade work, not a licensing code. The HTR-10 reflector uses the benchmark’s homogenized atom densities, so coolant channels are not resolved. First criticality means rods withdrawn, with no explicit rod absorber. Reference status for this card is not yet earned; the run is tagged lab-escalation. The optional RFC 3161 timestamp, when one is present, is shape-checked only by the verifier (base64 DER, first byte 0x30), never cryptographically validated, so it stays an unverified claim of time until a separate RFC 3161 check runs.
Feedback I would value. Is the OpenMC escalation handoff (same sealed inputs, 3 sigma k-eff acceptance) a sensible contract, and is anything missing from the HTR-10 setup for an independent reproduce. Repo is at gitlab.com/smrforge/smrforge and a standing reproduce and tamper challenge is at https://smrforge.io/break-the-seal.html.