[jtravs]

A draft, stacked on #517, then #516, which should land first. No number changes: every bit of a launch and every digest is as it was, and tests hold both.

What changed

• A large launch builds in threads, with its admittance formed once. The passes over a beam's elements ran on one thread, and the admittance ran twice. The sum that scales the field stays one sum in one order, so it stays on one thread.
• The transverse residual comes from exact squares and math.fsum, the same bits as the rational sum, without a Python Fraction per node.
• Digesting an array not held in its order works block by block. A broadcast input no longer becomes a whole volume to digest, and a byte-swapped one no longer takes a copy. Closes ArrayDigest.of expands a broadcast input to a full volume #493.

Why

At 768 × 768 × 600, a free-space launch took about three minutes to build, longer than the steps of a short point.

Intel Xeon Gold 6240, 18 cores, 18 threads, twice each, unprofiled	before (s)	after (s)
Simulation.from_free	169, 179	14.9, 14.9
translate	30.3, 27.5	7.2, 7.8
runner	3.8, 3.0	3.5, 3.3

A shared machine, so read these as sizes rather than exact ratios.

How it was verified

Local, on the stack: tests/test_pulses.py, test_cartesian_precision.py, tests/output/test_field_retention.py, test_monitor.py, test_process.py and test_structure_figures.py, 724 passed before the last merge from #517, and rerun after it; ruff clean.

Tests hold the launch's bits across thread counts (tests/test_pulses.py), the residual against the rational sum (tests/test_cartesian_precision.py) and a broadcast input's digest and peak memory (tests/output/test_field_retention.py).

What's left of the plan for this

• A runner's points still rebuild the monitor's geometry. I measured that on the SEP 44 branch and left it: at 512 x 512 x 600 a point's monitor takes 21 ms and its bind 16 ms, against a step of 1.76 s.
• A scan worker builds a backend per point, and whether keeping one SimulationRunner would pay is unmeasured where it could #298 and A plane-reducing scan needs a full Output implementation #499, a scan worker keeping a runner and a reducing scan as a callable, aren't in this PR. A lockstep batch observes every member's field at every plane, even when the scan keeps none #299 only matters if measured above its 5 %.
• A run's fixed host cost is unprofiled: 0.1–0.3 s on capillaries, about 6 s on kerr_beam_384 #347 stays open: this takes the launch's part of a run's fixed cost, and doesn't profile the rest.

Not run

No GPU run, since this changes host Python only. macOS, Windows, the slow lane and coverage: left to CI.

Links

Closes #493, by hand once the stack lands, since Closes only acts on a PR based on main. Relates to #347. Depends on #517 and #516.

Suggested labels: performance.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XGENPtq9Gp7VCh5QmcDdzQ

[read-the-docs-community]

Documentation build overview

📚 solprop | 🛠️ Build #35653830 | 📁 Comparing 4cc6af0 against latest (8ed26dd)

  🔍 Preview build  

23 files changed · ± 23 modified

± Modified

• genindex.html
• dev/backends.html
• dev/benchmarks.html
• dev/kernel-contract.html
• _modules/solprop/boundaries.html
• _modules/solprop/fourier.html
• _modules/solprop/pulses.html
• _modules/solprop/spatial.html
• _modules/solprop/transverse_monitor.html
• api/generated/solprop.backends.driver.html
• and 13 more...

[jtravs]

Folded into #520, at the maintainer's request for far fewer PRs: each one and each push costs a full CI run. This description keeps its tables and per-section verification, and the code is in that branch.