I built an open-source reactor-physics engine where every result is independently checkable — looking for people to break it

[u/Nervous_Ad_2710]

This is my own project, free and MIT-licensed, and I'm posting because this crowd will find the weak spots faster than anyone.

Short version: SMRFORGE is a screening reactor-physics engine for small modular reactors — full-core nodal diffusion, a continuous-energy Monte Carlo, S_N transport, burnup, kinetics, rod worth, the usual screening stack — with a one-step escalation to OpenMC when you want a lab-grade eigenvalue. The part I actually care about is what comes out: every run produces a signed "evidence bundle" that carries the result, the inputs, and the provenance, and that anyone can verify offline and re-run.

A concrete example you can check in a minute: a published OpenMC criticality result, k = 1.00522, sealed. Open smrforge.io/check.html, watch it verify in your browser, then edit a digit and watch it fail and point at the broken section. If you have OpenMC, you can go one step further and reproduce the number from the sealed inputs — the geometry and materials are in the bundle, not described, actually in it.

I try to be honest about grade, because this is the part that usually gets oversold:

Checking against public criticality benchmarks on open ENDF/B-VIII nuclear data is code verification, not validation against a measured experiment.

Every result is labeled screening-to-reference grade and advisory. Nobody should license a reactor on a SMRFORGE number alone, and the tool says so.

One of the benchmarks I'll be publishing is HTR-10 first criticality, where continuous-energy codes over-predict across the literature — and the bundle's C/E says so. A signed result that isn't flattering is more useful than a cherry-picked one.

The distinction I keep coming back to: custody vs correctness. The seal proves this is the number the code produced, unaltered, re-derivable from its inputs. It does not prove the number is physically right — that's on the physics, the model, and your judgment. Separating those two cleanly is the whole idea.

What I'd like from you: run it, try to make it produce a number you can't reproduce, and tell me where the physics or the tooling is thin. Engine repo and the browser demo are in the first comment.

[u/DP323602]

Thanks for an interesting post.

Have you considered any Validation, for example using data from IRPhE benchmarks:

https://www.oecd-nea.org/jcms/pl_20279/international-handbook-of-evaluated-reactor-physics-benchmark-experiments-irphe

[u/Nervous_Ad_2710 → u/DP323602]

Thanks, and you're pointing at the right gap. Let me be straight about where the line is today.

Everything the engine is currently checked against is open and MIT: the reference is OpenMC on open ENDF/B-VIII data, and the benchmark specs I use are openly redistributable. So what I have today is mostly code verification. The screening engine reproduces OpenMC, and you can re-run the continuous-energy case yourself from the sealed inputs. The validation against measured integral data largely lives one layer down, in OpenMC's own track record against those experiments.

IRPhE is exactly the right next step to validate the engine directly against measured data across the fuller envelope, reactivity coefficients, flux and power maps, kinetics, not just k_eff. The honest blocker is distribution: the IRPhE handbook is shared by OECD-NEA under access conditions, so I can't bake its evaluated geometries and atom densities into an MIT-licensed public repo. I keep the open engine to benchmarks whose data is redistributable, which is why it isn't in there today.

Where I do touch an openly published measured case like HTR-10 first criticality, I report the C/E even when it is unflattering: continuous-energy codes over-predict it across the literature, and the sealed result says so rather than burying it. Custody of the number is the part I seal; whether the number is physically right is a separate claim I try never to overstate.

Do you work with the IRPhE evaluations directly? I'd value your read on which cases are worth prioritizing.

[u/DP323602 → u/Nervous_Ad_2710]

Thanks for that reply. It's been a while since I've worked in the field of Verification and Validation, but when I did OECD-NEA reports were pretty much the gold standard for reference data.

In general benchmark selection is aided by considering various measures of similarity between a user's application and available benchmarks. In some cases, some components of calculation uncertainty are assigned on the basis of the differences between applications and benchmarks with regard to such measures.

In fields such as criticality safety analyses, conservative error allowances of order 1000 pcm are often used, so an agreement of about 50 pcm between a model and a benchmark is actually a very good result.