Migrate HitPattern to use TrackerTopology #9959
Conversation
I'm not perfectly happy on the solution (exposing some of the internals in HitPattern/TrackBase interface), but I think this is the simplest way to avoid DetIds in PackedCandidate. In principle I could have used TrackerTopology to encode the DetId, but percolating TrackerTopology here would lead to bad interface from the client perspective. Anyway the hit pattern information is already (packed) in the PackedCandidate, so it is only a matter of transforming the existing information to the form of HitPattern.
Here it is not possible to have TrackerTopology object, so some mechanism to deliver only the layer information to HitPattern in a way or another is needed. Fortunately the mechanism used in PackedCandidates works in here too, we just need a separate hit appending function for muons (where the information can still be delivered via DetIds).
|
A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_7_6_X. Migrate HitPattern to use TrackerTopology It involves the following packages: DataFormats/PatCandidates @civanch, @lveldere, @cvuosalo, @ssekmen, @mdhildreth, @monttj, @cmsbuild, @deguio, @slava77, @vadler, @danduggan can you please review it and eventually sign? Thanks. |
|
@cmsbuild please test |
|
The tests are being triggered in jenkins. |
|
+1 |
cmsbuild
added
analysis-pending
comparison-available
dqm-approved
fastsim-approved
orp-pending
pending-signatures
reconstruction-approved
simulation-pending
tests-approved
and removed
analysis-pending
comparison-available
dqm-pending
fastsim-approved
orp-pending
pending-signatures
reconstruction-approved
simulation-pending
tests-approved
labels
Migrate HitPattern to use TrackerTopology
This PR migrates HitPattern to use TrackerTopology instead of the tracker DetId classes. There were two kind of use-cases for filling HitPattern from DetIds:
Case 1 was straightforward to solve by percolating TrackerTopology to all necessary places to be passed to HitPattern.
Case 2 was more tricky, as it was not possible/practical to percolate TrackerTopology. Instead, I decided to skip the creation of a "dummy" DetId altogether, and added a new function to deliver the required information (subdet, layer, stereo bit) to HitPattern (
appendTrackerHit()for tracker, correspondingappendMuonHit()still employs DetId to encode the information as that seemed to be the simplest solution for now).Tested for 1 and 2.ii in CMSSW_7_5_X_2015-06-14-2300 + #9630 with wf 11325 (#9630/#9801 needed to verify 2.ii, i.e. CMSSW_7_6_X_2015-06-29-1100 or later). Case 2.i was tested separately with a file from /RelValTTbar_13/CMSSW_7_1_0-POSTLS171_V15-v1/GEN-SIM-RECO (predating #4455 so that the iorule is activated) by printing out all properties of HitPattern first in the IB, then in the IB+this branch, and finally making a diff of the two printouts (showing no differences).
@rovere @VinInn