CMS-HGCAL / reco-ntuples

Home of the Ntuplizer for the HGCAL reconstruction software studies
6 stars 36 forks source link

More information on the simulated track #45

Open jkiesele opened 7 years ago

jkiesele commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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:

To summarize the branches I would like to add:

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

artlbv commented 7 years ago

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 commented 7 years ago

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

rovere commented 7 years ago

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

jkiesele commented 7 years ago

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.