Who needs five digits of accuracy anyway

At the ANS Mathematics & Computational topical conference this spring, I heard a rumor (from a very well-placed source) about an ironic error in MCNP.

MCNP is considered by many in the labs and industry to be "the" nuclear simulation program of choice. It's a Monte Carlo transport program with continuous energy data and the ability to represent virtually exact geometry (with no truncation error for smooth surface, unlike in deterministic methods). It's had many decades of development, and it's been tested and tweaked considerably to match up with experimental and numerical benchmarks. Naturally, then, a simulated result from MCNP is often used as a reference answer when comparing new codes.

No simulation can exactly represent reality: there are always errors in data, simplifications in the physics, etc. This should always be kept in mind when doing computational anything. Case in point, I heard of a "run-off" benchmark between MCNP and another reactor code, SCALE. The result was that MCNP got the right answer and SCALE was wrong: the only problem was that their definition of the "right" answer was based on an MCNP-run calculation.

The error in MCNP—which you can verify yourself with the card entry print 98—is laughably simple yet indeterminately old. Avogadro's number, which converts between the number of atoms and the mass in a material, is programmed to be 6.022043447E+23 rather than the correct 6.02214179E+23. (In fact, it's written to 16 digits of "accuracy" even though only about ten are scientifically known to any precision.) The irony is that if they change Avogadro's number, their carefully benchmarked answers will come out "wrong."

It's not a huge problem, since I doubt most answers would be sensitive to such a small perturbation, but it serves as a warning to carefully consider the difference between "true" and "best approximation."