Problem in MTD simulation track ID management

[fabiocos]

The MTD simulation truth is heavily relying on hit type classification, according to the history of tracks originating it. The type assignment happens within the MtdSD::getTrackID method. While studying the ETL behaviour, a misbehaviour of the classification has been found back-scattering hits (thanks to X. Liu and X. Huang), and it has been traced back to an update of the code introduced in #47186 , where the position of the call to this method within TimingSD::getStepInfo has been modified.

For ETL back-scattering, the information about the hit type is computed in the MtdSD::setHitClassID method, that should be called before the track ID management. This update broke that logic. Moving this method before the call to getTrackID can solve the issue.

Nevertheless there is another possible problem, whose consequences are at present unclear: the TrackInformation content, used in the hit type assignment, is updated in case of a new track at https://github.com/cms-sw/cmssw/blob/master/SimG4CMS/Forward/src/TimingSD.cc#L159 . Moving the call of a method relying on this information before it is likely to cause issues, since some TrackInformation content is not yet defined while being used.

[cmsbuild]

cms-bot internal usage

[cmsbuild]

A new Issue was created by @fabiocos.

@Dr15Jones, @ftenchini, @makortel, @mandrenguyen, @sextonkennedy, @smuzaffar can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[fabiocos]

@martinamalberti FYI

[fabiocos]

@cms-sw/simulation-l2 do you see an issue with the fix in https://github.com/fabiocos/cmssw/pull/new/fc-fixtimingsd-20251030 ? I.e. do we have other cases apart for MtdSD where the region could be EcalRegion?

In my understanding the block filling TrackInformation is called for the first step of a new track, right? So it matters for new tracks originating inside the sensitive volume. That would imply that in getTrackID the storeTrack() information is not updated based on the energy, and the idLastStoredAncestor could be updated in a inconsistent way...

[makortel]

assign simulation

[cmsbuild]

New categories assigned: simulation

@civanch,@kpedro88,@mdhildreth you have been requested to review this Pull request/Issue and eventually sign? Thanks

[civanch]

This situation may happens if GFlash fast sim method is applied for FullSim and if low-energy e+e- is geometrically close to a EcalRegion boundary. We do not adopt this method yet and in view of the problem discussed here we may do two things: really resolve the problem of creation of spots outside EcalRegion or alternatively remove this GFlash method.

In baseline simulation (no GFlash) such situation should not appear, if it is not the case, it should be identified and fixed.

[fabiocos]

@civanch ok, thanks for the explanation. My question is: is the solution proposed in my branch above suitable for any TimingSD, or do you see potential issues with this?
As a side comment, this is an example of the fragility of the way in which we are currently managing the MCtruth...