More information on the simulated track

[jkiesele]

I am currently working on the following:
Additions:
A1) extrapolation of each generated particle to the first HGCal layer (whether it decayed or not). Corresponding 4 branches (exx,exy,exeta,exphi) are added to the ntuple. Needed for DNN studies.
A2) origin vertex information (x,y,z), there used to be only the decay vertex information

Bugfixes:
B1) change all extrapolations to FullSim rather than FastSim. FastSim does not do a good job in the inhomogeneous field in the endcaps

Changes:
C1) Right now, each electron or particle that fulfils "myTrack.genpartIndex()>=0" gets fully propagated to the HGCal and it's decay vertex is set to the first HGCal layer, even if it decays in the meantime. This overlaps with the additions in A1 and was always affected by bug B1. Please let me know if this feature is used by anybody. Since the same information is now given by addition A1, I would propose to remove this feature.
For the DNN studies, I need the information on the real decay vertex, that I would otherwise need to add for these particular particles in new branches.

[clelange]

@beaudett @artlbv - would you be OK with removing the FastSim part in the code, basically making readOfficialReco the default, which would mean using SimTracks and SimVertices instead of TrackingParticle and TrackingVertex? And what do you think about the other points?

[beaudett]

Hello,

it is not really FullSim vs FastSim: we are not doing FastSim here, just using the FastSim propagator. That said, I have no objection to use an more sophisticated propagator as long as it does not slow down the ntuplizer (too much).
About propagating tracks with ".genpartIndex()>=0" up to the entrance of HGCAL even if interacted in the tracker is intended for electrons. Indeed, it is a position that can directly be compared to the electron supercluster position. So please, keep it. It can be restricted to be electrons and photons if you so wish.

Generally, I think it is simpler to use SimTracks and SimVertices everywhere. And similarly, I think it is better to use the HepMCProduct to retrieve the hard vertex position.

Florian

[jkiesele]

@beaudett
Thanks for the quick feedback. To be precise, I do not intend to remove the propagation for electrons. On the contrary, I added this propagation for all particles. I was only advertising the following:
Use the genpart_dvx etc branches to store the real decay vertex for all particles, and use the new branches genpart_exx etc to store their projection to the HGCal for all particles. This way it is consistent.

[jkiesele]

Just as an addition.
The CPU time consumption is not increased significantly by changing to the FullSim tools. I did not do a real performance check, but the real time needed to process about 10 events is not changed.
I would also propose to add an additional branch:

• the mother index of each generated particle. This allows to consistency match them on ntuple level with only one int (if needed we could even go to a 16-bit int) more.

To summarize the branches I would like to add:

• genpart_exphi : extrapolated to the HGCal phi-coordinate
• genpart_exeta: extrapolated eta coordinate (yes, it does change)
• genpart_exx: extrapolated x
• genpart_exy: extrapolated y

---

• genpart_ovx: origin vertex x
• genpart_ovy: -"- y
• genpart_ovz: -"- z
• genpart_mother: mother index w.r.t the saved particles

I can add switches to those blocks, but I would consider the first block interesting for most users.

[artlbv]

Would it be possible then to also use this extrapolation further in the propagation of the tracks through HGCAL, i.e. for the genpart_posx/y/z branches?

[jkiesele]

Hi Artur,
yes, it is already implemented this way ;)

[rovere]

@jkiesele do you happen to have a working branch I can try to merge to my devel with all the aforementioned developments?

[jkiesele]

Hi Marco,
this is a good idea. You can find the developments here:
https://github.com/jkiesele/reco-ntuples
Everything is tested except for the propagation within the HGCal. But the implementation is straightforward, so if there are any issues, they are small.