Something significantly changed in forward Lambda decays between 2025-10 and 2026-02

[DraTeots]

I see many discrepancies in Lambdas on DD4Hep on MCParticle level between versions (using the same hepmc3 inputs). In particular:

• We see no N + pi0 decays fully saved in MCParticles
• We see kind of Z cut on lambda decay. Basically lambdas stop decaying before B0.

Environment: (where does this bug occur, have you tried other environments)

• Which branch (main for latest released), 2026-02 to nightly affected. 2025-10 -better

2026-02

2025-10.3

**We compared 3 datasets now: **

• Our own campaign 2025-10 using 2025-10.3 eic-shell container
• First official campaign for meson-structure events of 2026-02
• Our own campaign 2026-03 with 2026-03 image and Baptiste branch using multiple FF detectors to reconstruct lambdas (gives the same result as official 2026-02)

CLARIFICATION:

• Lambdas we look at are decayed by Geant4/DD4Hep. And we saw the classic decay exponents at some point (decay point z).
• I look now at both edm4hep (if available) and eicrecon outputs. In terms of MCParticles they are identical as expected. So it is on DD4Hep side.
• I looked at "decay mode" as looking through MCParticles primary Lambda daughters via EDM4HEP and EDM4EIC C++ reader. Previously it gave 4 variants for lambdas

1. P + Pi- (as in PDG)
2. N + Pi0 (as in PDG)
3. Shower (when you see like 40 daughters). Were the dominating cause is Lambda Recharge - a classic process where in matter Lambda goes Sigma, which instantly decayed back to Lambda and so on. But different hadronic showering is seen.
4. Nothing. It just not decayed OR decay products are not written. And DD4Hep (DD4Hep governs saving to EDM4Hep) doesn't write all shower particles. So it goes as "Undecayed"

Now something is screwed up even on MCParticles level.

Since 2025-02 looking where n+pi0 gone on event by event basis we see:

"Other" lambda decay mode at evt_id=1513 daughters=1
id=5 pdg=2112

So only neutron is saved and never pi0. (even if only interacting particle is saved we should see it, as previsouly we have 20% efficiency of registration).

Steps to reproduce: (give a step by step account of how to trigger the bug)

The reproducer

https://github.com/JeffersonLab/meson-structure/tree/main/analysis/edm4hep_mcpart_lambda

[baptistefraisse]

I would like to report another observation that might be related:

• There is a complete absence of hits in EcalEndcapP, while hits are correctly recorded in LFHCAL.
• This strongly suggests that EcalEndcapP is inactive or not properly configured.
• In contrast, reverting to eic_xl:2025-11 restores the expected behavior, with hits present in EcalEndcapP.

[ayerbeg]

Just to add to Dmitry report.

The following plots show:

1. The full spectra of Lambda endpoint.z up to 30 m
2. The Lambda endpoint.z when NO DAUGHTERS are stored. I took a particular event to show what I mean (MAYBE this one in particular hits the beampipe, but it is just representative of the cases NO DAUGHTERS):
   Particle 4: PDG: 3122 IDX: 4 Charge: 0.000 Mass: 1.115600 GeV GeneratorStatus: 1 SimulatorStatus: 67108864 Momentum: (-3.687, -0.222, 137.324) GeV Vertex: (0.154, -0.006, 36.046) mm Endpoint: (-158.460, -9.536, 5944.133) mm Time: -0.111 ns Number of parents: 2 Number of daughters: 0

3, 4, 5, and 6. The Vertex.z and EndPoint.z of the Lambda decay (when it happen) in order, pi0, n, pi- and p. Obviously, pi0 practically decay immediately, I didn't follow its decay yet.