Add additional information to the SimTracks
#46979
Conversation
- is or not from backscattering - is or not a primary - the GenParticle ID is always saved if available and returned with a specific method, while the old genpartIndex() returns -1 if it's not a primary as before
|
cms-bot internal usage |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-46979/43059 |
|
A new Pull Request was created by @AuroraPerego for master. It involves the following packages:
@civanch, @cmsbuild, @kpedro88, @mdhildreth can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
@cmsbuild please test |
|
+1 Size: This PR adds an extra 32KB to repository Comparison SummarySummary:
|
| private: | ||
| int ivert; | ||
| int igenpart; | ||
|
|
||
| math::XYZVectorD tkposition; | ||
| math::XYZTLorentzVectorD tkmomentum; | ||
|
|
||
| bool crossedBoundary_; |
There was a problem hiding this comment.
@AuroraPerego this changes a member of a persistent object, how do we ensure backward compatibility here? How are we correctly interpreting all the old files? I do not see a rule in the classes_def.xml
| @@ -88,6 +93,8 @@ class TrackWithHistory { | |||
| bool storeTrack_{false}; | |||
| bool saved_{false}; | |||
| bool crossedBoundary_{false}; | |||
| bool isFromBackScattering_{false}; | |||
There was a problem hiding this comment.
these additions seem to duplicate information already available in TrackInformation, where are they needed because they cannot be replaced by TrackInformation?
There was a problem hiding this comment.
answering to myself, apparently the SimTrackManager is based on TrackWithHistory at present
| @@ -34,8 +34,9 @@ class SimTrack : public CoreSimTrack { | |||
| bool noVertex() const { return ivert == -1; } | |||
|
|
|||
| /// index of the corresponding Generator particle in the Event container (-1 if no Genpart) | |||
| int genpartIndex() const { return igenpart; } | |||
| bool noGenpart() const { return igenpart == -1; } | |||
| bool isPrimary() const { return (trackInfo_ >> 1) & 1; } | |||
There was a problem hiding this comment.
@AuroraPerego , track info defined in all cases, when tracking of given particle is started. If it is not true to me it is a bug. Primary particle if defined at start tracking.
| int genpartIndex() const { return igenpart; } | ||
| bool noGenpart() const { return igenpart == -1; } | ||
| bool isPrimary() const { return (trackInfo_ >> 1) & 1; } | ||
| int genpartIndex() const { return isPrimary() ? igenpart : -1; } |
There was a problem hiding this comment.
I would guess that it is not a good solution.
|
-1 we discussed MC truth during 2023-2024 and not do real change of MC truth, because we preserve Run3 results. Any change for Run3 is a problem. |
PR description:
Looking at the SimTracks and SimVertices in single pion events we found some "orphan" vertices that were triggering the creation of
SimClusters not associated with anyCaloParticle.For example, when a particle enters HGCAL we stop keeping track of the history, if it does backscattering and enters the barrel calorimeters we lose the connection with the initial particle.
With this additional information, we can connect the orphan
simClusters to the original particle that created them and flag those that come from backscattering.This information will be used at the
SimClusterlevel in theCaloTruthAccumulatorin a follow-up PR.Note: the behaviour of the already existing methods (
genpartIndex()andnoGenpart()) has not been changed to preserve backward compatibility and the newgetPrimaryID()method is used to obtain thegenParticleindex.The logic with the
uint8_tinstead of a list ofboolreduces the class size and gives the possibility to add more flags / categories in the future.PR validation:
tested on a single pion workflow enabling Geant4-related cout.
FYI @rovere @felicepantaleo @fabiocos