chore: acts 45.1.1

[wdconinc]

Briefly, what does this PR introduce?

Needs:

• chore: eic-spack: convert repository to spack packages API v2 repo layout #174
• chore: dd4hep-1.35 (rntuple support) #149
• juggler: don't require acts +tgeo for newer juggler eic-spack#838
• k4actstracking: don't depend on acts +tgeo key4hep/key4hep-spack#861

This PR update acts to v45.1.1. Follows #166 with correct branch name. Juggler gets a minor upgrade to make sure it can handle the updated interfaces in Acts v45.

[Copilot]

Pull request overview

This PR updates the EIC container Spack environment to use Acts v45.1.1, aligning the pinned Acts version with the upstream Spack package definition updates referenced in #166.

Changes:

• Add upstream spack/spack-packages cherry-picks needed to introduce Acts v45.x versions and improved variant dependency handling.
• Update spack-environment/packages.yaml to require acts@45.1.1 (keeping the existing variant set).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
spack-packages.sh	Adds the upstream cherry-pick commits that introduce Acts v45.0.0 / v45.1.0 / v45.1.1 and variant dependency handling updates.
spack-environment/packages.yaml	Pins Acts from @44.4.0 to @45.1.1 under package requirements.

[veprbl]

Physics benchmarks are unhappy:

[] [acts] [error] invalid det_element!!! det_element == nullptr 

[wdconinc]

Yeah. Fixed in then Gen1/Gen3 geometry branch... Need to extract and apply cleanly.

[wdconinc]

Yeah. Fixed in then Gen1/Gen3 geometry branch... Need to extract and apply cleanly.

Actually, this is already fixed (eic/EICrecon#2466). It just doesn't retroactively appear in the latest released EICrecon that's used in the default workflow (and nightly succeeded). So this is effectively on hold until the next release.

[wdconinc]

Looks good in https://eicweb.phy.anl.gov/EIC/benchmarks/detector_benchmarks/-/jobs/7393001/artifacts/file/results/tracking_performances_dis/epic_craterlake_tracking_only/pythia8NCDIS_18x275_minQ2=1_combined_5/plots.pdf (nightly).

[veprbl]

I see some minor discrepancies in track projections
https://veprbl.github.io/capybara-reports/56eba532508bf97a9f7927efa94f5478/

Looks like it picks up additional projection points in fEMCal and LFHCAL.

That are in forward, as expected

But there is a bit of phi modulation to it?

The predicted time of 25 meters is a bit concerning, is that a loop in the propagation?

[wdconinc]

@copilot Rebase and resolve conflicts.

[Copilot]

@copilot Rebase and resolve conflicts.

The branch is already rebased onto the current master (f6c201a) with all 6 commits cleanly on top — no conflicts. CI was triggered and is running.

[github-actions]

Capybara summary for PR 172

• rec_dis_10x100_minQ2=1000_epic_craterlake
• rec_dis_10x100_minQ2=1_epic_craterlake
• rec_dis_18x275_minQ2=1000_epic_craterlake
• rec_dis_18x275_minQ2=1_epic_craterlake
• rec_dis_5x41_minQ2=1_epic_craterlake
• rec_e_1GeV_20GeV_epic_craterlake
• rec_pi_1GeV_20GeV_epic_craterlake
• sim_dis_10x100_minQ2=1000_epic_craterlake
• sim_dis_10x100_minQ2=1_epic_craterlake
• sim_dis_18x275_minQ2=1000_epic_craterlake
• sim_dis_18x275_minQ2=1_epic_craterlake
• sim_dis_5x41_minQ2=1_epic_craterlake
• sim_e_1GeV_20GeV_epic_craterlake
• sim_pi_1GeV_20GeV_epic_craterlake
  ^{_{Last updated 2026-04-27T01:14-04:00 41c59dd}}

[veprbl]

Reports no differences, is that true?

[wdconinc]

Reports no differences, is that true?

It missed one side of the comparison and just has the new events but not the master branch.

[wdconinc]

Yeah, the issue is definitely there in the local capybara runs too: https://eic.github.io/containers/pr/172/capybara/rec_dis_5x41_minQ2=1_epic_craterlake/index.html#_CalorimeterTrackProjections_points (not that I had a doubt about it, but it is nice to see we have a good capybara workflow here now).

[wdconinc]

Twice now, I've given copilot the master and acts-45.1.1 branch output ROOT tree and full source code. In both cases it came up with the same analysis and conclusion (after an hour).

These projections are into the EcalEndcalP and LFHCAL, and they encounter so much material that the tracks are slowed down to minimum momentum values that are artificially kept at 10 MeV. This prevents them from getting stop-and-killed (to use Geant4 language).

This hypothesis appears sensible (I can verify the 10 MeV momentum for example, as well as the far-forward nature, and this explains large times), but it is not a very satisfactory situation in terms of accepting this behavior and it doesn't teach us why this was an issue before, or how this should be (or should have been) handled...

Copilot analysis (hidden by default since AI generated)

ACTS Track Projection Time Anomaly Investigation

Context: eic/containers PR #172 — update ACTS v44.4.0 → v45.1.1

Files compared:

• rec_dis_5x41_minQ2=1_epic_craterlake.edm4eic.root — master branch (ACTS v44.4.0)
• .worktree/acts-45.1.1/rec_dis_5x41_minQ2=1_epic_craterlake.edm4eic.root — acts-45.1.1 branch (ACTS v45.1.1)

---

Summary of Difference

Metric	master (v44.4.0)	acts-45.1.1 (v45.1.1)
Total _CalorimeterTrackProjections_points entries	1572	1695
Projection tracks with zero points	31	0
Points with anomalous time (t > 10,000 ps)	0	124
Anomalous time range	—	25,000–31,500 ps
Normal time range	< 8,100 ps	< 8,100 ps

The same 31 tracks are responsible for both anomalies (confirmed by event/track index matching). In v44.4.0 these tracks produce zero points; in v45.1.1 they produce 4 anomalous-time points each (124 = 31 × 4).

---

Characterisation of the 31 Anomalous Tracks

All 31 are far-forward tracks:

• Polar angle at perigee: θ ≈ 0.054–0.063 rad (3–4°)
• Momentum at perigee: p = 2–7 GeV/c
• Measurement count: 5–6 hits each (identical between versions)
• CentralCKFTrackParameters (perigee) numerically identical between versions

Anomalous points appear only in systems 102 (EcalEndcapP) and 116 (LFHCAL) — the two deepest far-forward calorimeters.

---

Root Cause: minP Clamp in PointwiseMaterialInteraction

All 124 anomalous points have exactly |p| = 0.010 GeV = 10 MeV/c, which is the hardcoded
minP floor in:

// acts/Core/include/Acts/Propagator/detail/PointwiseMaterialInteraction.hpp
static constexpr double minP = 10_MeV;
nextP = std::max(minP, nextP);   // momentum never drops below 10 MeV/c

These forward tracks traverse the dense iron endcap shielding (z ≈ 2,970 mm), losing enough
energy for nextP to be clamped to 10 MeV/c. The clamp leaves the particle alive but sets an
unrealistically low speed:

Quantity	Value
Particle assumption	pion (m = 140 MeV/c²)
Clamped momentum	p = 10 MeV/c
Speed	v ≈ 0.071 c
Time-of-flight rate	dt/ds ≈ 47 ps/mm
Path at minP before EcalEndcapP	~380 mm
Excess time accumulated	~18,000 ps
Resulting total time	25,000–31,500 ps ✓

The minP clamp is unchanged between v44.4.0 and v45.1.1 — this is a pre-existing physics
bug that was hidden in v44.4.0 by a propagation failure (see next section).

---

Why v44.4.0 Shows Zero Points for These Tracks

In v44.4.0, the same 31 tracks produce zero projection points for every calorimeter system,
not just EcalEndcapP/LFHCAL. This is a total propagation failure: Navigator::initialize() is
called once per propagator.propagate() invocation and returns NotInsideExpectedVolume or
NotOnExpectedSurface before any stepping begins.

In EICrecon, each calorimeter projection launches a separate propagator.propagate(initBoundParams, *targetSurf, options) starting from trackState.filtered() at the tip-index surface. Since the starting parameters are identical for all target surfaces, if initialize() fails for one surface it fails for all — matching the all-zero observation.

The large time values in v45.1.1 are therefore newly visible: they were always latent in the
physics but masked in v44.4.0 by the initialization failure.

---

Commits Between v44.4.0 and v45.1.1 — Assessment

All commits between the two tags were reviewed. The table below records the disposition of each.

Commit	Title / PR	Disposition
ea27ffb25	KF rework (#4940)	Candidate — most impactful code change; alters GainMatrixUpdaterImpl and KalmanUpdateHelperImpl; perigee params are numerically identical but filtered-state covariance at tip-index could subtly differ for forward tracks
3743675fb	Use cached inverse in Volume::inside() (#4877)	Candidate — replaces transform().inverse() * pos with cached m_itransform * pos; for a volume with large z-translation (~3,200 mm), floating-point rounding of −Rᵀ·t can differ by ~10⁻¹² mm, enough to flip a track exactly at a volume boundary (1×10⁻⁴ mm tolerance)
b8c7332bf	Equip Volume with geoContext (#4954)	Candidate — changes Navigator::initialize() call from volume->inside(pos, tol) to volume->inside(gctx, pos, tol) via globalToLocalTransform(gctx); could handle boundary edge cases differently for far-forward volumes
58692a779	Actors return Result<void> (#4921)	Ruled out — MaterialInteractor always returns Result<void>::success()
b4264a183	Revisit Propagator error handling (#5044)	Ruled out — adds ACTS_DEBUG logging; fixes apply to curvilinear (no-target) path only; EICrecon uses surface-target path which is unchanged
b7a85195d	Rework PWMI part 2 (#5023)	Ruled out — pure refactor of PointwiseMaterialInteraction; minP clamp logic unchanged
63a8e44fc	Rework PWMI part 1 (#5016)	Ruled out — pure refactor; minP clamp logic unchanged
a17eb563f	Split Navigator into .cpp (#4971)	Ruled out — verified implementations are functionally identical
6a4a247b4	Teach Navigator free surfaces (#4494)	Ruled out — EICrecon does not use freeSurfaces/externalSurfaces
4f7e33f98	Relax Core error logs (#5004)	Ruled out — only affects NoStartVolume slow path, not taken here
3f7a5748b	Skip propagation errors in MaterialMappers (#5010)	Ruled out — MaterialMapper code only
33afd05e5	Fix policy state inconsistency (#5080)	Ruled out — Gen3 Navigator only
c125df0ff	Add policy state (#4981)	Ruled out — Gen3 Navigator only

Most likely commit to bisect against first: b8c7332bf, as it directly changes the Navigator::initialize() call site for Volume::inside().

---

Status in ACTS Releases After v45.1.1

The ACTS repository at ~/git/acts contains releases up through v46.3.0 plus additional
commits (HEAD ≈ v0.07.03-6667-gb88b5427e, i.e. post-v46.3.0).

The minP clamp is unchanged in all releases through the current HEAD:

// Core/include/Acts/Propagator/detail/PointwiseMaterialInteraction.hpp  (current HEAD)
// minimum momentum below which we will not push particles via material update
// TODO 10 MeV might be quite low and we should make this configurable
static constexpr double minP = 10 * Acts::UnitConstants::MeV;
nextP = std::max(minP, nextP);

The // TODO 10 MeV might be quite low and we should make this configurable comment was
introduced in ff2f97619 (PR
#2140, released in v27.0.0, May 2023),
showing the ACTS developers are already aware the value may be inappropriate — but no fix has
been applied through v46.3.0.

Two commits touched the file since v45.1.1 but neither addresses minP:

Commit	Title	Change relevant to minP?
276740fac	Remove navigator from material interactions (#5140)	No — signature/refactor only
0be82a08e	Make use of cathetus helper (#5218)	No — replaces std::sqrt(nextE²−m²) with fastCathetus; same result

The bug is still present in v45.2.0 through v46.3.0 and beyond.

---

Actionable Conclusions

1. Report minP clamp to ACTS upstream. The hardcoded minP = 10 MeV/c in
   PointwiseMaterialInteraction.hpp produces physically nonsensical time-of-flight values for
   any forward track that loses most of its energy in dense material. For a pion at 10 MeV/c
   the speed is only 0.071 c, leading to time values 4× too large for far-forward tracks.
   The fix is to either propagate without time update once the particle is clamped, or to handle
   the degenerate slow-particle case in the time integration.

2. The v44.4.0 propagation failure is not necessarily "correct". The 0-points result for
   these 31 tracks in v44.4.0 is a Navigator::initialize() failure that silently drops the
   projections. The v45.1.1 behaviour of propagating and reporting (even with bad times) is
   arguably more transparent.

3. Definitive commit identification requires bisecting the actual EICrecon+ePIC simulation
   against ACTS commits ea27ffb25 → 3743675fb → b8c7332bf (in chronological order), or
   enabling ACTS_LOG_LEVEL=DEBUG on either version to directly observe the
   Navigator initialization failed: NotInsideExpectedVolume error for the 31 forward tracks.