adapt tracking HitPattern to phase-2

[slava77]

As of 14_1_X still the HitPattern does not describe access/strorage in the context of the the phase-2 tracker.

• improve the documentation
• the phase-2 specific names should be added to overload equivalent accessors of the phase-1 tracker

This issue is to keep track of the updates

[cmsbuild]

cms-bot internal usage

[cmsbuild]

A new Issue was created by @slava77.

@Dr15Jones, @makortel, @sextonkennedy, @smuzaffar, @antoniovilela, @rappoccio can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[slava77]

@fabiocos @VourMa

[slava77]

type trk,tracking

[makortel]

assign reconstruction, upgrade

[cmsbuild]

New categories assigned: reconstruction,upgrade

@jfernan2,@mandrenguyen,@srimanob,@subirsarkar you have been requested to review this Pull request/Issue and eventually sign? Thanks

[fabiocos]

@martinamalberti @kdeleo FYI

As far as MTD is concerned, the existing implementation made by @lgray at the beginning is no more fully valid, and needs to be adapted. For BTL (see https://github.com/cms-sw/cmssw/blame/master/DataFormats/TrackReco/interface/HitPattern.h#L38 ) there are no more different types from geometry I17 onwards, a different substructure indexing could be added, for instance tray/readout unit. For ETL (see https://github.com/cms-sw/cmssw/blame/master/DataFormats/TrackReco/interface/HitPattern.h#L39) the detector has changed, there are now two discs for each side, and there are no more rings but faces and sectors, although the encoding https://github.com/cms-sw/cmssw/blob/master/DataFormats/TrackReco/src/HitPattern.cc#L149 provides them in a compact form.

In any case, the only collection of tracks to my knowledge containing MTD hits are the tracks refitted by the TrackExtenderWithMTD, producing a collection that is not saved but in the RECO content, and generally not used, as the MTD information is associated to generalTracks through a set of ValueMap objects. Nevertheless it will have to be updated.

Our present interest is to check the hit pattern just in front of BTL/ETL, in the very last layers, to help assessing the probability that the link of a track to a MTD hit is correct and not just random. The classification described at https://github.com/cms-sw/cmssw/blob/master/DataFormats/TrackReco/interface/HitPattern.h#L29 seems to refer to the Phase1 detector structure. Phase2 detector structure should be different according to the Tracker TDR: is this correct?

Of course one could just loop on the hits and look at their position in the detector, as soon as the hit collection is still available in the event.