Exascale Considerations

Where Kronos workloads actually scale toward exascale, where they do not, and why bandwidth and reproducibility bound the frontier.

What exascale means for Kronos

Exascale is only useful where a workload can consume it without falling apart on communication or losing reproducibility. Kronos has both kinds of workload. Monte Carlo neutronics scales almost perfectly and would happily absorb exascale-class throughput; tightly coupled implicit multi-physics solves hit communication walls long before that.

The workloads that scale

Particle transport is the exascale-friendly case. Each neutron history is independent, so a breeder blanket TBR study or a burner 5.44 percent neutron-fraction shielding study partitions cleanly across an enormous node count. The limit is not coupling but variance: more cores buy more histories, and error falls as one over the square root of history count.

The workloads that resist

Implicit MHD and coupled thermomechanics resist naive scaling. They exchange halo data every iteration, so at extreme node counts communication dominates and the strong-scaling curve flattens. Here the frontier is set by the interconnect and the solver's communication-avoidance, not by adding nodes.

Exascale also strains reproducibility. Non-deterministic reduction orders across millions of parallel operations perturb the last bits of a result. For sweeps this is tolerable; for the certified reproducible core it is not, so those runs deliberately trade some scale for deterministic reductions.

Kronos therefore treats exascale as a tool for the wide, independent frontier, chiefly Monte Carlo campaigns and large training sweeps, and treats the coupled reproducible core as a smaller, tightly controlled regime. The point is not to reach a headline scale but to size each workload to where it stops being efficient or trustworthy.