My nodal core simulator almost didn’t make it.
On paper, everything was there. In practice, it crawled. With ~38 variables per node, finding the global power shape in an EPR-sized core took on the order of 2,000 iterations. Not unstable—just painfully slow. The solver kept chasing small corrections across the core without ever settling efficiently.
The problem wasn’t the physics. It was how I was asking it to converge.
One evening in Otaniemi, over tuna pizza and Velvet lager, it clicked: stop trying to converge everything at once.
After each iteration:
ix the intranodal flux shape.
Assume outgoing partial currents ∝ node-averaged flux.
Solve only the scaling factors to satisfy the neutron balance in each node.
Rescale and repeat.
Separate shape from amplitude.
I went back to VTT that night, coded it through, and had it ready by morning.
30 iterations.
Same physics. Different perspective.
And the interesting part: the local flux shape has almost no effect on the global one during convergence. Most of that intranodal detail was just slowing things down.
Still the most satisfying fix I’ve ever made.
***
Anyone can write a nodal core simulator. Getting one to calculate the power distribution is not the hard part.
The hard part is everything that follows: making it converge without drama, behave smoothly across the whole operating range, couple cleanly to thermal-hydraulics, and stay stable when the inputs are less than perfect—as they always are. It has to be fast, predictable, and boring in the best possible way. Something you trust enough to use without thinking about the tool itself.
I built my own nodal code, ARES, about 25 years ago. It worked. But I also learned where the real effort goes. Not in the equations, but in all the small, unglamorous decisions that make the code behave like a tool instead of a prototype.
That is why I have a lot of respect for the people at Studsvik Scandpower. In a small market, they’ve done a genuinely top-class job—not just getting the physics right, but making the whole thing smooth, consistent, and usable year after year.
Writing the simulator is maybe five percent. Making it practical is the other ninety-five.
***
What hurts my brain about many reactor concepts is the basic philosophy of loading the core with extra neutrons and then spending much of the cycle absorbing them away. It feels like driving with full throttle and controlling speed with the brakes.
Yes, there are good practical reasons for it. Batch loading demands excess reactivity at the beginning of the cycle, and shutdown systems must remain strong and unambiguous. But the underlying picture still feels backward: first create the surplus, then work hard to suppress it.
The VVER-440 at least hints at a more intelligent direction. Its fuel followers move out of the core with the absorber section, so the core does not simply alternate between absorber and empty water column. That is already a step away from pure neutron destruction as the only control philosophy.
The natural thought is to take that idea further. Use core inserts that are less about killing neutrons and more about being inert to them. Replace absorber, where possible, with reflector or some other weakly perturbing structure that preserves neutron economy during normal operation. As fuel is consumed, gradually reel the followers in. On scram, let them fall out of the core, inserting negative reactivity as they fall.
The last part is non-negotiable: scram must stay negative with a margin. Whatever elegance is introduced for power operation must never blur the shutdown function. A reactor may be allowed to run gracefully, but it must still stop brutally.
But that’s what core analysis is for.