Parallel Decomposition and Load Balance
Scrollable formula. Use Left and Right arrow keys to reveal hidden content.
Scrollable table. Use Left and Right arrow keys to reveal additional columns.
Scrollable figure. Use Left and Right arrow keys to inspect hidden content.
Parallel decomposition divides a numerical-relativity problem among processes, threads, or devices. It changes execution order, communication, memory placement, and sometimes floating-point reduction, so it can affect both time to solution and bit-level results. Performance evidence is meaningful only for a fully specified physical problem and accuracy target. Strong and weak scaling, compute and communication time, imbalance, and reproducibility must be reported together; a raw core count or peak throughput is not a scientific result.
Helpful background. Formulations of General Relativity supplies the evolved systems, Ordinary Differential Equations supplies time stepping, Computational Relativity supplies reproducibility standards, and Probability and Statistical Inference supplies uncertainty summaries for variable timings.
Decompose work and data
Section titled “Decompose work and data”Structured grids are commonly split into blocks with ghost exchanges. Spectral-element and discontinuous-Galerkin codes distribute elements and send interface traces. Particle, ray, or Monte Carlo work may require dynamic queues. The partition should minimize surface-to-volume communication while respecting memory limits and keeping work balanced.
Record the global mesh, local blocks or elements, refinement hierarchy, ghost width, communication graph, process and thread topology, affinity, device mapping, and solver collectives. A task graph can overlap communication with computation and expose irregular parallelism; Kidder et al. 2017, §4, §§5.1–5.3, Figures 4–6 and §6 describes this design in a discontinuous-Galerkin relativity code.
Load is not proportional to cell count when refinement levels subcycle, primitive recovery iterates variably, or horizon and radiation tasks are localized. Weight partitions with measured costs, then report compute, communication, idle, and imbalance times separately. Repartitioning has a migration cost and can perturb cache or reduction order; include it in the total.
Strong and weak scaling
Section titled “Strong and weak scaling”For strong scaling, hold the complete physical problem fixed. With time on resources, define
relative to an explicitly reported baseline , not an inferred serial run that could not hold the problem. Saturation occurs when communication, synchronization, and insufficient local work stop reducing .
For weak scaling, increase global problem size so work per resource is approximately fixed. State exactly which dimensions, AMR blocks, samples, or modes grow. Weak scaling is not comparable if the physics changes from a smooth wave to a shock-rich case or if refinement activity per resource changes. Report multiple repetitions, median and spread, warm-up policy, queue and filesystem effects, and whether initialization and output are included.
Kalinani et al. 2025, §§3.9–3.11, §4 and §§5.1–5.4, Tables 3–5 provides a modern GPU-accelerated GRMHD example with explicit code tests and scaling. Its reported machine and workload are contextual evidence, not a portable speed factor for another architecture.
Specified wave and scaling record
Section titled “Specified wave and scaling record”Use one physical problem for accuracy, strong scaling, and weak scaling:
The base domain is , all faces are periodic, and . Use fourth-order centered differences, RK4, and CFL ; run grids with to . The primary reference is the analytic solution above. Compare the volume-weighted relative error and the phase of the independently computed Fourier coefficient. Accept the solution only if , , and the last two refinement ratios are consistent with fourth-order convergence to within .
For strong scaling set node, hold the complete problem and output cadence fixed, and run on otherwise identical nodes. For weak scaling, tile unit cubes along , retain the same periodic wave and cells per cube, and assign one cube per node. Pin ranks, threads, devices, and affinity per node. Use one warm-up followed by seven measured repetitions and report medians and interquartile ranges. The eight-node strong-scaling efficiency must be at least , and the eight-node weak-scaling efficiency at least . More importantly, every layout must retain and ; its field difference from the corresponding one-node decomposition, after restricting to the same physical cube, must be at most in relative norm. The named machine and software environment are part of the record, so these efficiency limits are test criteria rather than portable claims.
The weak-scaling tile needs its own accuracy qualification. For the stated fourth-order derivative, a Fourier mode with sees the modified wave number
Applying the RK4 polynomial for steps gives amplitude at . Its phase error is approximately at and at . These are direct evaluations of the discrete Fourier symbol, not timings or a three-dimensional implementation test. They explain why a tile cannot meet the declared phase target merely by adding nodes.
Observed discrepancy: not available—specification only.
Preserve the scientific solution
Section titled “Preserve the scientific solution”Before comparing performance, demonstrate that every decomposition meets the same error target. Run an analytic wave or stationary black hole across several process counts and layouts. Compare constraints, conserved quantities, horizon invariants, and waveform phase. Non-associative reductions can shift last bits; the shift should remain below the declared numerical uncertainty and must not change convergence or failure decisions.
Use a production-representative benchmark with pinned resolution and output cadence. Also report a communication-focused microbenchmark only as diagnosis. Vary block size and rank placement, and identify the resource count at which efficiency loss outweighs wall-time gain. The validity domain is the named machine, software stack, compiler, network, and workload.
Environment and failure criteria
Section titled “Environment and failure criteria”Pin machine and partition, node and device model, interconnect, compiler, MPI and accelerator runtimes, affinity, process/thread/device layout, problem configuration, input checksum, output cadence, profiling method, and code revision. A clean interface could be scale-run --config binary-grid.toml --layouts layouts.yaml --output run/, emitting timings by category, hardware counters where available, scientific diagnostics, repetition statistics, and environment metadata. It specifies a rerun record rather than claiming universal performance.
Reject a scaling claim with no real baseline, changed resolution or physics, omitted I/O that dominates production, single noisy timings, or speed obtained by loosening tolerances. Failure modes include load weights measured on an unrepresentative phase, global reductions at every substep, oversubscribed threads, hidden device transfers, and a decomposition whose different reduction order pushes an observable beyond its error budget.
Diagnostic
Section titled “Diagnostic”A run is four times faster on eight times as many GPUs, but waveform phase differs from the baseline by twice the accepted error because the accelerated layout uses a different reduction and looser primitive-recovery tolerance. Is the speedup valid for the scientific claim?
Solution
No. The two runs do not meet the same numerical target, so their wall times are not comparable as time to the validated result. Restore identical tolerances, quantify reduction-order sensitivity, repeat timings, and require phase, constraints, and conserved quantities to agree within the declared uncertainty. Then report speedup and efficiency relative to the actual baseline.
References
Section titled “References”- Kalinani, J. V., Ji, L., Ennoggi, L., et al. (2025). “AsterX: A new open-source GPU-accelerated GRMHD code for dynamical spacetimes.” Classical and Quantum Gravity 42, 015010. arXiv.
- Kidder, L. E., Field, S. E., Foucart, F., et al. (2017). “SpECTRE: A task-based discontinuous Galerkin code for relativistic astrophysics.” Journal of Computational Physics 335, 84–114. arXiv.