Add quantum-kick synchrotron radiation mode

[JPTS2]

Summary

This PR adds a new stochastic synchrotron-radiation mode, quantum-kick.

The existing quantum mode samples individual photon emissions. This is physically detailed and supports photon logging, but it is expensive, especially on GPU backends. The new quantum-kick mode instead samples the stochastic total radiation kick using precomputed total-energy tables. It is intended for cases where the stochastic radiation effect is needed, but individual photon logging is not.

The public API is:

line.configure_radiation(model='quantum-kick')

Internally, this maps to radiation_flag == 3.

Motivation

The main motivation is making stochastic radiation tracking practical on GPU backends.

On the machines tested, CPU performance is not the main differentiator: quantum-kick has broadly comparable cost to photon-by-photon quantum tracking on CPU. The important difference appears on GPU, where photon-by-photon radiation becomes the limiting path.

Using the timing examples under examples/tracking_time on the FCC-ee example line:

• On a Titan V, quantum reached the timing limit at 8 particles.
• On the same Titan V, quantum-kick continued scaling to 16384 particles.
• At the largest shared Titan V point, quantum-kick was about 3.4x faster than quantum.

This matters because the Titan V result is already substantially faster than the CPU machines available for this workflow. In these measurements, a MacBook Pro using 8 OpenMP threads is often around 2x faster than an 8-core HTCondor CPU job, while the Titan V is about 3x faster again for the relevant stochastic-radiation workload. That makes the Titan V roughly comparable to many HTCondor CPU cores for this use case, and this is before testing the H100 GPUs available for production studies.

The intended performance message is therefore:

When individual photon logging is not required, quantum-kick removes the photon-by-photon bottleneck and makes stochastic synchrotron-radiation tracking much more attractive on GPU backends.

Implementation

This PR adds:

• configure_radiation(model='quantum-kick')
• radiation_flag == 3 handling in radiation-enabled elements
• GPU-compatible sampling of the stochastic total radiation kick
• precomputed synchrotron-radiation total-energy tables
• table generation machinery for the total-energy sampler
• Twiss/radiation-analysis compatibility for lines configured with quantum-kick
• timing synchronization fixes needed for credible GPU timing comparisons

The behavior distinction is:

• quantum: samples individual photons and supports photon logging
• quantum-kick: samples the stochastic total kick and does not log individual photons

Examples

The examples under examples/radiation/quantum_kick_vs_quantum/ validate the new model against the existing quantum model.

They cover:

• single-bend kick distributions
• radiation-regime scans
• sampler-call behavior
• FCC-ee emittance evolution
• lifetime/tail proxy behavior

The tracking-time examples under examples/tracking_time/ were used for the performance checks described above. They now also print the raw particle-count and timing arrays used for the plots, making it easier to copy results from different machines and produce comparison figures without modifying the scripts.

Tests

The test suite has been updated so that quantum-kick is treated as a first-class radiation mode wherever the expected particle-coordinate behavior should match quantum.

Updated tests include:

• tests/test_radiation.py

  • added direct radiation_flag=3 checks beside the existing stochastic radiation check
  • kept photon statistics/logging checks specific to quantum
  • added a quantum-kick no-photon-record check
  • added quantum-kick to the ring stochastic tracking comparison

• tests/test_splineboris.py

  • added quantum-kick to the SplineBoris bend-radiation check
  • kept photon statistics/logging checks specific to quantum
  • added a quantum-kick no-photon-record check

• tests/test_elements_thick.py

  • added quantum-kick to the solenoid radiation equivalence tests

• tests/test_radiation_equilibrium_emittances.py

  • added a quantum-kick tracking comparison inside the existing check_against_tracking branch only

• tests/test_radiation_equilibrium_emittances_thick.py

  • same as the thin emittance test: added quantum-kick only inside the tracking-comparison branch

The emittance tracking checks now use 50 particles instead of 30. The previous sample size was too low for a stable stochastic RMS comparison when testing both stochastic radiation modes.

Validation

The targeted updated tests pass locally:

python -m pytest tests/test_radiation.py -vv -s --tb=short --durations=20
python -m pytest tests/test_splineboris.py::test_splineboris_bend_radiation -vv -s --tb=short --durations=10
python -m pytest \
  tests/test_elements_thick.py::test_drift_like_solenoid_with_kicks_radiation \
  tests/test_elements_thick.py::test_solenoid_with_kicks_radiation \
  -vv -s --tb=short --durations=20
python -m pytest tests/test_radiation_equilibrium_emittances.py::test_eq_emitt -vv -s --tb=short --durations=20
python -m pytest tests/test_radiation_equilibrium_emittances_thick.py::test_eq_emitt -vv -s --tb=short --durations=20

Photon logging is intentionally not supported by quantum-kick, because the model samples the total stochastic energy kick rather than individual photons. Tests explicitly check this distinction.

[JPTS2]

Diff size note

Most of the line count in this PR comes from the generated header
xtrack/headers/synrad_total_energy_tables.h. This file contains precomputed
lookup tables for sampling the total synchrotron-radiation energy kick used by
quantum-kick.

The table is generated by:

xtrack/headers/_generate_synrad_total_energy_tables.py