Speaker
Description
Fusion neutronics has long relied on tools built for fission, adapting transport codes designed around criticality calculations, borrowing finite-element meshers intended for structural analysis, and working around defaults tuned for reactor physics. With a growing fusion industry, increasing demand from private companies, and the reduction in development effort enabled by large language models, it is worth asking: has fusion become large enough to justify its own purpose-built neutronics workflow?
The 14.1 MeV source neutrons in fusion open reaction channels that fission neutrons lack the energy to reach, resulting in activation analysis across a different range of progeny nuclides. Combined with complex streaming path geometries and pulsed operation, fusion workflows present distinct challenges compared to fission. General-purpose codes tend to ship with defaults tuned for fission, from the reactions included in transmutation chains to normalisation factors in post-processing. These are common sources of user error and additional effort in fusion workflows.
Many Monte Carlo transport codes are closed-source or export-controlled (e.g. MCNP). Existing open-source options such as OpenMC have made great progress in accessibility and licensing. However, CAD-based transport workflows that are critical for fusion still rely on external meshing tools that often carry copyleft licenses, which the growing fusion private sector frequently restricts.
Stellarators such as the Proxima Fusion designs, with their non-axisymmetric, twisted geometries, make this especially acute as their plasma-facing components and coil structures simply cannot be faithfully represented in CSG. Fusion devices arguably demand CAD or mesh-based representations as a first-class capability. A fusion-specific code could also include a mesher optimised for particle transport rather than relying on finite-element meshers designed for a different problem.
Narrowing scope to fixed-source transport could bring further advantages: a smaller, more maintainable codebase, less likely to be export controlled, free of copyleft meshing dependencies, and potentially a more natural fit for GPU acceleration. Were such a code started today, AI-accelerated development and modern packaging could significantly reduce the effort involved.
There are clear arguments against, too. Building and validating a new transport code is a significant undertaking, fewer fusion-relevant benchmarks exist compared to fission, and a new code would need to earn trust that established codes have built over decades. Fragmenting developer effort and losing cross-pollination between the fission and fusion communities are real risks.
This work explores what a purpose-built fusion Monte Carlo code could look like and if the perceived benefits justify the endeavour.
| Formatted abstract uploaded? | Done. |
|---|