Code Benchmarking and Cross-Verification
Benchmarking runs independent codes on identical problems to build confidence, expose bugs, and establish reference solutions the community can trust.
Why cross-check codes
A single code can be wrong in ways its own tests miss. Benchmarking runs two or more independently developed codes on exactly the same problem and compares results. Agreement builds confidence that both solve the physics correctly; disagreement flags a bug or a hidden assumption in at least one of them.
Kinds of benchmark
- Code-to-analytic: compare against a known exact solution
- Code-to-code: compare independent implementations on a shared problem
- Code-to-experiment: compare against measured data (this is validation)
- Community exercises: many groups solve a common specification
Designing a fair benchmark
A meaningful benchmark specifies the problem precisely: geometry, inputs, physics options, and data. Ambiguity in the specification is the commonest reason codes disagree for uninteresting reasons. Well-run benchmarks publish a locked problem definition so that differences reflect the codes, not different interpretations of the task.
Reference solutions
Successful benchmarks produce reference solutions: agreed answers to standard problems that new codes can test themselves against. In neutronics, for instance, an open code is often benchmarked against an established reference tool on the same geometry and data library before it is trusted for design.
A continuing practice
Benchmarking is not a one-time certification but an ongoing habit. Every significant code change, new physics option, or new application regime warrants re-checking against known references, because confidence earned on old problems does not automatically transfer to new ones.
Kronos treats cross-verification as part of standing behind a result: important numbers are checked by more than one route where practical.