Celeritas ORANGE geometry backend: an isolated ≈4.5 % deficit on the ATLAS TileCal test-beam geometry, absent with VecGeom and independent of host/device

[FanxinSun]

Summary

On the ATLAS TileCal test-beam geometry (a different application: this project's own paper target,
not a Celeritas or Geant4 example), the total deposited energy (EdepSum) computed by Celeritas
0.6.3 through the ORANGE geometry backend is 4.3–4.5 % low against native Geant4, on both
host and device. Rebuilding the same Celeritas version against VecGeom 1.2.11 as the geometry
backend, with nothing else changed, makes the deficit vanish on both host and device. We are not
asking Celeritas to adopt VecGeom; we are reporting that the deficit tracks the geometry-backend
choice and not the hardware, and offering a measurement we think is relevant to open issue #762
(see below).

Configuration

• Geant4 11.4.2; Celeritas 0.6.3 (repos/celeritas @ tag v0.6.3, unmodified checkout), built
  twice from the same source: once with CELERITAS_CORE_GEO=ORANGE (this project's original build)
  and once with CELERITAS_CORE_GEO=VecGeom against VecGeom 1.2.11, both CUDA-enabled
  (CELERITAS_USE_CUDA=ON), both against the same Geant4 build.
• Application: atlas-tilecal-integration @ commit 3ba9496 (unmodified), rebuilt against each
  Celeritas prefix. GDML TileTB_2B1EB_nobeamline.gdml.
• Beam: 18 GeV π⁺, stock FTFP_BERT, default 0.7 mm production cuts. 2000 events per cell, one
  fresh seed pair per cell.
• Device: one NVIDIA RTX 5080 (sm_120). Host cells forced Celeritas onto the CPU
  (CELER_DISABLE_DEVICE=1) with no other change to the binary or configuration.
• Observable: EdepSum (the application's own total-deposit sum).

Measurement

Mean ± standard error of the mean, n = 2000 events per cell; native-Geant4 reference
596.860 ± 1.837 (same geometry, same application, from this project's own runs, not re-measured
here):

backend	host	device
ORANGE	570.008 ± 1.843 (−4.50 ± 0.43 % vs Geant4)	571.1415 ± 1.923 (−4.31 ± 0.44 % vs Geant4)
VecGeom	597.6915 ± 1.803 (+0.14 ± 0.43 % vs Geant4, consistent with zero)	594.3295 ± 1.923 (−0.42 ± 0.45 % vs Geant4, consistent with zero)

Device-vs-host at fixed backend is consistent with zero at both backends (+0.20 ± 0.47 % at
ORANGE, −0.56 ± 0.44 % at VecGeom). VecGeom-vs-ORANGE at fixed hardware is not: +4.86 ± 0.46 %
(host), +4.06 ± 0.49 % (device). All percentages against Geant4 and the two device-vs-host
contrasts use one-sided 95 % confidence at a Bonferroni-adjusted family of 8 (z = 2.4977); the two
backend-vs-backend rows are informational, from the same family.

The only structural difference we can point to between the builds' identity records is a capability
flag Celeritas itself reports: internal.geometry.supports_safety is false for every ORANGE cell
in this matrix and true for every VecGeom cell. We have not established that this flag is the
mechanism — it is a correlation across four runs on one geometry, not a demonstrated cause — but
we note it because it is the same "safety distance" concept as issue #762 below, and thought it
worth reporting as a second, independent data point on that topic.

Every run in this matrix (and its three pre-existing companions) passed our own duplicate-event
check (a per-event content comparison across every pair of the six runs) with zero duplicates found
anywhere, before being used above.

Minimal reproduction

1. Build Celeritas 0.6.3 twice, identical CMake flags except CELERITAS_CORE_GEO (ORANGE vs
   VecGeom, the latter needing a VecGeom 1.2.11 install).
2. Build/link an application against each prefix — we used a downstream ATLAS TileCal test-beam
   integration; whether other GDML applications show the same contrast is untested.
3. Run 18 GeV π⁺ through TileTB_2B1EB_nobeamline.gdml, stock FTFP_BERT, default cuts, host and
   device, both backends.
4. Compare total deposited energy against native Geant4 (Celeritas disabled) on the same geometry.

Relationship to open issue #762

We read #762 ("Use safety distance more wisely and improve caching of next step/safety") while
investigating a separate MSC step-limit measurement, on a different geometry and a different code
path (the Urban MSC step limiter's safety cap). There we measured that reducing msc_safety_factor
by a factor of 60 moves the response by only +0.35 ± 0.42 % — the safety term is not what drives
that other discrepancy. This item is a separate measurement, on a separate application, of a
deficit that correlates with supports_safety being false — i.e. with whichever code path
Celeritas takes when the geometry backend cannot answer a fast safety-distance query. We are not
claiming this is the same mechanism as #762, or that it resolves that issue; we report it because
both concern how Celeritas' transport behaves when safety-distance information is or is not
available from the geometry backend, and this may be useful context for whoever next looks at #762.

Question for the developers

Is a backend-specific deficit of this size (≈4.5 %, absent with VecGeom, present at both host and
device) already known or expected for ORANGE navigation under Celeritas 0.6.3? A tracker search on
this item's own topic turned up no existing report; #762 above is the only related issue we found.

What was not established

• No mechanism. Nothing here shows why ORANGE gives a low answer or why it correlates with
  supports_safety=false; only that it does, on this one geometry, at both host and device.
• One seed pair per cell, one run each — no independent-seed repeat beyond the duplicate-event
  check above, no other reproducibility check.
• No worker-count or thread-count scan — each cell ran at the application's own default thread
  count; wall time was not controlled and is not reported here.
• VecGeom's own geometric accuracy against the true ATLAS TileCal geometry is not assessed —
  only self-consistency against this project's own Geant4 and ORANGE results on the same converted
  geometry.
• One application, one particle, one energy (18 GeV π⁺, this test-beam geometry only).

[sethrj]

Hi @FanxinSun , thanks for the detailed report. The most relevant issue is probably #990 , related to the warning message you saw. It's well-known ¹ that multiple scattering models do not converge asymptotically, and in particular the Geant4 MSC method fails to do any displacement when the reported safety distance is zero.

We've had to avoid using ORANGE for problems with a combination of nontrivial geometry and EM physics: we should definitely make the warning more prominent :(

Footnotes

1. Kawrakow, Iwan, and Alex F. Bielajew. “On the Condensed History Technique for Electron Transport.” Nuclear Instruments and Methods in Physics Research Section B: Beam Interactions with Materials and Atoms 142, no. 3 (1998): 253–80. https://doi.org/10.1016/S0168-583X(98)00274-2. ↩