+The current design of the GTT involves several steps. Universally, a GTTInputConversion step which performs such conversions as $\frac{1}{R} to $p_T$ and $tan(\lambda)$ to $\eta$. Currently in emulation, this takes information from the 96-bit [TrackWord](https://github.com/cms-sw/cmssw/blob/master/DataFormats/L1TrackTrigger/interface/TTTrack_TrackWord.h) and overwrites the corresponding fields with the GTT converted values, leaving the Track in a non-canonical state. In [firmware](https://gitlab.cern.ch/GTT/LibHLS/-/tree/master/DataFormats/Track?ref_type=heads), the HLS code for the Track [struct](https://gitlab.cern.ch/GTT/LibHLS/-/blob/master/DataFormats/Track/interface/Track.h?ref_type=heads) represents this non-canonical state as separate fields, rather than a single 96-bit word. Afterwards, multiple TrackSelection (TS) modules are configured/instantiated, potentially 1 for each downstream algorithm, such as VertexFinding (VF), TrackJets (and thus TrackHT/TrackMissingHT), TrackMET, mesons, $W\rarrow~3\pi$, and so on. The VertexFinder takes selected tracks and uses (as baseline/extension) a histogramming method to identify the Primary Vertex (PV), weight either with track $p_T$ or a Neural Net score. Downstream, multiple modules of TrackVertexAssociation (TVA) are run, taking selected tracks from one of the TS modules, the PV from VF, and they output vertex-associated tracks. These are inputs to JetFinding (JF), meson finding, MET, and others.
0 commit comments