Spent-Fuel Tetris

I spent about five months at Holtec, split between shielding modeling and the software side of loading plans for what I call giant nuclear trashcans (dry casks for spent fuel). It was a short stint, but the spent-fuel problem was a fun one. I'll keep this general, but the shape of the problem is interesting and worth describing I think.

A two-stage afterlife

When a fuel assembly comes out of a reactor it is extremely hot, in both senses of the word: thermally hot from radioactive decay, and radiologically hot from a freshly minted inventory of fission products. So it goes into a spent-fuel pool, where water cools it and shields everyone standing nearby. It sits there for years while the short-lived isotopes decay away and the decay heat falls off.

Eventually the pool fills up, or you simply want the assemblies in something more permanent and passive. That's where dry casks come in: big, heavily shielded canisters that cool by natural convection, no pumps required. You move the cooler, older assemblies out of the pool and into casks, which frees up pool space for the next batch coming out of the reactor.

hover / hold for original

The constraints are where it gets fun

You can't just grab the hottest assemblies and stuff them in a cask. Every cask has limits, and the interesting one is the total decay-heat load: pack too much heat into a single canister and you exceed its thermal design. You also care about reactivity and shielding, so it's never just one number.

The naive move is to fill casks with your oldest, coolest fuel, which is easy on the thermal limit. But that's shortsighted, because you also have to think about what's coming. Freshly discharged fuel is the hottest stuff in the building, and it has to land in the pool. If you've used up your pool-to-cask pipeline flexibility, you have a problem.

So the actual game is a balancing act: you mix hot and cold assemblies in each cask so the total stays comfortably under the limit, while keeping the pool able to receive the next round of very hot incoming fuel. Put a couple of young, hot assemblies in a cask and surround them with old, cold ones that have decayed for a decade, and you can use your cask capacity efficiently and keep your pool options open; but it's not quite that simple, because hot assemblies towards the center of the cask is desirable because then your older, colder assemblies act to help shield the radiation from the hot ones, however you now have a slightly harder time dissipating the thermal energy from the hot assemblies. There's always a trade-off and it is a quite complex optimization problem.

It's bin-packing with a time axis

If this is starting to sound like a computer science problem, that's because it is one. You have a set of objects (assemblies), each with attributes (decay heat, age, reactivity, geometry), and a set of containers (casks, and positions within them) with constraints. You want an assignment that satisfies all the constraints while optimizing something you care about: number of casks used, throughput, keeping pool margin, and so on. That's bin packing wearing a lead apron.

The twist that makes it genuinely interesting is time. Decay heat isn't static; it drops along a known curve. An assembly that's over the line today might be fine in eighteen months. So "wait for it to cool" is a legal move, and now you're not just packing bins, you're scheduling. Do you free up pool space now by loading a cask sub-optimally, or do you wait for cooling and pack it tighter later, betting on what's coming off the reactor in the meantime? That tradeoff, repeated across a whole campaign, is the real problem.

Why I think about this a lot

I like problems where the cleanest solution is some unglamorous combination of physics and search. Decay-heat-constrained packing-and-scheduling is exactly that, and it scratched the same itch that good software does.

It's also a decent argument for why domain expertise and software belong together. The physics tells you what the constraints actually are and how they evolve; the code lets you search a space no human can hold in their head. That overlap is more or less the whole thesis of Such Software, where I now do nuclear and radiation modeling alongside the web work. If you've got a gnarly constrained-optimization problem with a physics flavor, it's my favorite kind.