Slava Krutelyov
Slava Krutelyov
> Looping over particleFlow candidates (`vector "particleFlow" "" "RECO"`) in those problematic events, I see that pt, eta, phi of one pf candidate is `-nan` in those events. @slava77 so...
> I guess this issue is happening more often now if mkFit is giving a higher fraction of displaced tracks with high uncertainty. Is it known or expected? Maybe the...
> Hi Slava, here is some more info on the track > > ``` > In [9]: print(track.pt(), track.eta(), track.phi(), track.p()) > 5.456 -2.620 -1.916 37.67 > In [12]: track.numberOfValidHits()...
https://github.com/cms-sw/cmssw/blob/5a3dd48730c2b88d67d1304788801e26e605cd36/RecoParticleFlow/PFTracking/src/PFTrackAlgoTools.cc#L259 is supposed to reject the track with `dpt/pt >~ 10 * 0.06^2 ~ 0.036` ... or is this track from elsewhere (`NuclearInteractionTrackImporter` ?)
> In [12]: track.numberOfValidHits() > Out[12]: 5 considering eta 2.6 and 5 hits, it would not be the shortness of the mkFit candidates. There is perhaps another feature: mkFit merges...
> I'm not sure what the interplay of CKF (which I guess would be used for a refit) and mikfit is then. there should be none: the final track fits...
> But won't it depend on the hits that mkfit has decided are part of the track? Perhaps I misunderstood the initial concern. My response implying no interplay was referring...
@Dr15Jones please add compression details wrt `reco::Track` `generalTracks` branch; the other kind of tracks (electrons or muons) are less frequent and would not affect the total compression as much. A...
> > A more appropriate for the momentum would be to go to q/p (or 1/pt), theta, phi, or even the pt,eta,phi used in the Particle representation; the compression has...