The Compute Substrate
A tiered mix of cloud HPC and owned bare-metal that carries every offline workload from Monte Carlo transport to twin retraining.
One substrate, many workload shapes
The L0 compute substrate is not a single machine class. It is a heterogeneous pool sized to the three dominant workload shapes Kronos runs: embarrassingly parallel Monte Carlo transport, tightly coupled multi-physics finite-element solves, and dense GPU training. Each shape stresses a different resource, so the substrate is provisioned along three axes rather than one.
- CPU-dense partitions for particle transport, where per-history work is light but histories number in the billions
- Low-latency interconnect partitions for implicit MHD and thermomechanical solves that exchange halos every iteration
- GPU-dense partitions for PINN, GNN, and surrogate training with high memory bandwidth demand
Cloud plus bare-metal
Bursty study campaigns, parameter sweeps, and retraining spikes run on elastic cloud HPC. Steady, latency-sensitive, or data-gravity-bound work runs on owned bare-metal near the petabyte pulse archive. The split is an operational and reproducibility decision, not an economic one: bare-metal gives byte-stable numerics and unshared interconnect; cloud gives elasticity for wide sweeps.
Abstraction over the pool
Workloads never target hardware directly. They target the hardware abstraction layer, which resolves a declared workload profile to a concrete partition. A neutronics job asks for CPU histories and scratch bandwidth; a training job asks for GPUs and a checkpoint volume. The scheduler places them, and the same job specification reproduces on cloud or bare-metal.
This substrate feeds both machines. A breeder blanket neutronics sweep and a burner end-cell MHD solve can share the same pool at the same time, differentiated only by their declared profiles. The substrate is machine-agnostic; the physics lives in the workloads, not the metal.
Sizing is driven by campaign cadence: the batch-retraining loop, the Monte Carlo variance targets, and the sweep breadth set peak demand. The substrate is deliberately over-provisioned in interconnect and storage bandwidth relative to raw FLOPs, because Kronos workloads are more often bandwidth- and communication-bound than compute-bound.