[esseivaju]

Charged-particle propagation in a magnetic field dominates GPU time in the ATLAS (Athena) offload. In a 4-event single-thread profile on an A100 (VecGeom, CartMapField), the along-step-cartmap-msc-propagate kernel takes 51% of all kernel time. More than 90% of the total is geometry navigation plus the field integration that surrounds it.

FieldPropagator searched for a boundary along the chord of every substep, even deep inside a volume. This PR keeps a lazily computed safety sphere: a ball centered on an earlier substep position, with the safety distance there as its radius, so it contains no boundary. A substep is accepted without a boundary search when its chord end point, plus the intersection tolerance, lies inside the sphere. That search would have found no boundary, so trajectories are unchanged.

The sphere is computed lazily so its cost stays bounded:

• It is never computed before the first internal substep, so a propagation that takes a single substep does no extra work.
• It is not computed for the substep that completes the step, because that would at best trade one boundary search for one safety query.
• After a recomputed sphere fails to contain the chord, it is not recomputed again in the same call, so at most one safety query per call is wasted.

Changes

• detail::SafetySphere (field/detail/FieldUtils.hh): a helper that tests whether a point, with a tolerance, is inside the sphere.
• FieldPropagator: the safety-sphere skip described above. The substep acceptance logic now lives in a local helper shared by both paths, and the algorithm is documented in the class docs.
• find_safety(max) respects its maximum in ORANGE and Geant4:
  • The interface says the result should not exceed the requested maximum, and VecGeom already truncates it.
  • ORANGE ignored the argument, and the Geant4 wrapper returned its cached safety.
  • Both are now truncated, which resolves the TODO in GeoTests.cc and the related CheckedGeoTrackView warnings.
  • UrbanMsc only compares the safety against the maximum it requests, so MSC results are unchanged.
• CheckedGeoTrackView no longer warns about a zero safety when the geometry reports that it doesn't support safety. ORANGE legitimately returns 0 for surfaces without a simple safety.

Results

The CmseTest.coarse field propagation test runs 4 track radii. Boundary crossings, steps, and integrations are identical to before for both VecGeom and ORANGE. Only the navigation call counts change:

Geometry	Boundary searches before	Boundary searches after	Safety queries added
VecGeom	30419 / 19551 / 16170 / 9956	11176 / 7120 / 3634 / 4863	9954 / 6424 / 3285 / 1944
ORANGE	30419 / — / 16170 / 9956	12548 / — / 6128 / 5925	9954 / — / 3268 / 1835

The second radius is the known ORANGE failure case. The total number of navigation queries drops by 30–57%. A test that crosses many thin layers with short steps (LayersTest.revolutions_through_layers) performs no safety queries at all.

Testing

• New and updated tests:
  • SafetySphereTest.contains;
  • navigation-count checks in TwoBoxesTest.electron_interior and LayersTest.revolutions_through_layers;
  • a num_safety column in the CMSE regression result.
• The CMSE test checks two kinds of results:
  • Trajectory results (boundary crossings, steps, integrations): compared exactly for every geometry.
  • Navigation counts (boundary searches, safety queries): these depend on each geometry's safety distances.
    • ORANGE and VecGeom 2.x, where they were measured: compared exactly.
    • Other geometries (VecGeom 1.x, Geant4 core geometry): checked against two bounds instead. The run must skip some boundary searches, and it may waste at most one safety query per propagation.

Follow-up

Seed the initial sphere from the safety distance that UrbanMsc::limit_step already computes at the start of each step. The first substep could then also skip the boundary search. This needs per-track storage of the safety and its center, and is noted as a \todo in the FieldPropagator docs.

Assisted-by: Claude Code (Claude Opus 5.5)

[github-actions]

Test summary

 6 066 files  10 057 suites   6m 48s ⏱️
 1 945 tests  1 932 ✅  13 💤 0 ❌
34 047 runs  33 857 ✅ 190 💤 0 ❌

Results for commit 8c8e965.

[sethrj]

@esseivaju Let's hold off on this before we have a strategy to improve and test especially for the computationally intensive use cases. I don't think safety sphere will work with orange, and as I said earlier, I'm not convinced it's the right approach for calorimeters and trackers (which all have very thin slices).

Before we add more complexity to this class I'd like the AI to refactor the field propagator and some of the boundary mechanics so we can improve testing and extensibility.

Not sure if your AI saw these:

• Add safety cache and evaluate outside of MSC kernels #845
• Add basic safety usage to field propagator #844
• Use safety distance more wisely and improve cacheing of next step/safety #762

[sethrj]

Also I think this refactor should be done in conjunction with MSC reconsiderations, and the MSC also definitely needs refactoring.

But if you just want to try some stuff in this branch and see if you get a performance boost for athena, please by all means go for it :)

[esseivaju]

Yeah I mainly wanted to test whether this was helping in Athena, though as you say within complex geometry l it doesn't really help. This gives a maybe 2-3% improvement in Athena... Interestingly a lot of the kernel time seems to be caused by a few tracks: only 13% of the steps have a propagation kernels taking more than 8ms, yet those 13% of steps represent 47% of the propagation time.

[sethrj]

@esseivaju There's definitely a lot of low-hanging fruit for the field propagator optimization. Better characterizing the behavior in a realistic simulation would be a great first step though: maybe some counters for histograms of tracks -> steps -> substeps -> field convergence loops -> boundary tests ? Easy with AI, super valuable in practice.