Sparse comments

[sarafiorendi]

Tracks:

• https://github.com/CMSBParking/BParkingNANO/blob/master/BParkingNano/plugins/TrackMerger.cc#L115 I would not require HP to PFCands and nothing on lost tracks → possible biases (just save the boolean)
• tag & probe side tracks → I would propose to save one collection of tracks and add a variable to perform the split later, in case it's needed. https://github.com/CMSBParking/BParkingNANO/blob/master/BParkingNano/plugins/TrackMerger.cc#L141

Trigger:

• not clear to me what is "l1seed_2" https://github.com/CMSBParking/BParkingNANO/blob/master/BParkingNano/plugins/TriggerObjectTableBParkProducer.cc#L85
• matching to L1: not optimal using deltaR, especially for lowPt muons, because coordinates of the L1 are defined at MB2 while offline are at vertex. Can be refined, e.g.:
  • use full extrapolation of offline track to MB2 (not sure if it works on miniOAD)
  • use rectangular dEta and dPhi (with large dPhi) instead of dR Btw, do we really need this info?

Gen Particles:

• double check if, with the current set of GEN particles, we can understand if the B emitted a photon (e.g. B+ -> Kmumu+gamma). As far as I understand only photons with pT > 10 GeV are saved.

Variables that could be useful to save once we have the full chain:

• final state particle isolation (useful for signal selection, at least in the mumu channel)
• mumu (ee) mass uncertainty from the kinematic fit (for ee, it requires that changes from Arabella on refit of gsf tracks are included)
• b vtx coordinates
• track is a muon? electron is a muon?

[mverzett]

I would also be in favour of merging the Muon and TriggerMuon collection, making the triggering an additional flag. I realise is mostly a matter of taste, but I think it would make the cross-check with George's code a bit easier.

[gkaratha]

Hi all,

Regarding to the trigger:

• Perhaps we should consider the "triggered" function on muon pat. it will reduce the lines to ~4
• I have no strong opinion for two vs one collection as long as 1) We can remove the tag side if needed 2) We can apply Dz cut to muons and save only the "final" product (all cuts including Dz) 3) If we want to consider mu + 2 tracks reconstruction (in past we made some steps there), then cuts will be very crucial to reduce combinations

[sarafiorendi]

Additional comments to be addressed at some point:

• DCA for tracks now is calculated and save wrt the vertex of "one" trigger muon https://github.com/CMSBParking/BParkingNANO/blob/90c57480ded2cd0abea18c588a1be4410a99f3e8/BParkingNano/plugins/TrackMerger.cc#L149, basically chosen based on its order in the trgMuons collection. Since probably we don't want to compute and save the DCA of each track wrt to every trgMuon, I would suggest to save DCA wrt to a fixed point (e.g. BS) and, in case, use a different approach to separate tag/probe tracks (if we still need to do this separation).

[gkaratha]

Hi all,

I also have a question: What about events without trg muon matched to offline? Are we keeping them or not?