Fix some LaTeX

Author: Nick Manganelli

L1Trigger/L1TTrackMatch/Readme.md

@@ -1,17 +1,17 @@
 # Global Track Trigger
-This section describes several componenets of the Global Track Trigger, the CMS subsystem downstream of Level-1 Track Finding, which performs Level-1 vertex-finding for the L1 Correlator Layer 1 (for PF Candidate / PUPPI reconstruction) and globally builds track-only objects such as Jets, HT, MET, mesons (including phi and rho), etc to be sent to the Global Trigger.
+This section describes several componenets of the Global Track Trigger, the CMS subsystem downstream of Level-1 Track Finding, which performs Level-1 vertex-finding for the L1 Correlator Layer 1 (for PF Candidate / PUPPI reconstruction) and globally builds track-only objects such as Jets, HT, MET, mesons (including $\phi$ and $\rho$), etc to be sent to the Global Trigger.
 
 ## Data Flow Overview
 
-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$, occurs first. 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. Afterward InputConversion, multiple TrackSelection (TS) modules are configured/instantiated, potentially 1 for each downstream algorithm, such as VertexFinding (VF), Displaced Vertexing, 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), weighted either with track $p_T$ (baseline) or a Neural Net score (extended). Downstream, multiple modules of TrackVertexAssociation (TVA) are run (in the baseline, a simple cut-based algo, and in extended algorithm/E2E, a track-association network discriminant cut), taking selected tracks from an appropriate TS modules, the PV from VF, and outputting vertex-associated tracks. These are inputs to JetFinding (JF), meson finding, MET, and other algorithms. In firmware, the outputs from vertex-finding are streamed to the L1 Correlator Layer 1, and all algorithms (including vertex-finding) outputs are sent to the L1 Global Trigger.
+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$, occurs first. 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. Afterward InputConversion, multiple TrackSelection (TS) modules are configured/instantiated, potentially 1 for each downstream algorithm, such as VertexFinding (VF), Displaced Vertexing, TrackJets (and thus TrackHT/TrackMissingHT), TrackMET, mesons, $W~\it{to}~3\pi$, and so on. The VertexFinder takes selected tracks and uses (as baseline/extension) a histogramming method to identify the Primary Vertex (PV), weighted either with track $p_T$ (baseline) or a Neural Net score (extended). Downstream, multiple modules of TrackVertexAssociation (TVA) are run (in the baseline, a simple cut-based algo, and in extended algorithm/E2E, a track-association network discriminant cut), taking selected tracks from an appropriate TS modules, the PV from VF, and outputting vertex-associated tracks. These are inputs to JetFinding (JF), meson finding, MET, and other algorithms. In firmware, the outputs from vertex-finding are streamed to the L1 Correlator Layer 1, and all algorithms (including vertex-finding) outputs are sent to the L1 Global Trigger.
 
 ### GTT Input Conversion
 Input conversion handles the change from 1/R (really q/R) to $p_T$ and $tan(\lambda)$ to $\eta$. In LibHLS, this is controlled with a few constants that denote how many integer and fixed-float bits should be used. In emulation, constants are located inside the GTT plugin under ConversionBitWidths.
-LibHLS [$\eta$ module](https://gitlab.cern.ch/GTT/LibHLS/-/tree/master/Modules/ConversionEta?ref_type=heads) and [$p_T$ module](https://gitlab.cern.ch/GTT/LibHLS/-/tree/master/Modules/ConversionPt?ref_type=heads)
+LibHLS $\eta$ [module](https://gitlab.cern.ch/GTT/LibHLS/-/tree/master/Modules/ConversionEta?ref_type=heads) and $p_T$ [module](https://gitlab.cern.ch/GTT/LibHLS/-/tree/master/Modules/ConversionPt?ref_type=heads)
 CMSSW [plugin](https://github.com/cms-sw/cmssw/blob/master/L1Trigger/L1TTrackMatch/plugins/L1GTTInputProducer.cc)
 
 #### Status (October 2024)
-The Input conversion in Firmware centrally stores conversion constants and consistently uses the central GTT format (struct) for tracks. Meanwhile, the emulator is in a somewhat different spot, with a low-granularity conversion of $p_T$ with 7 integer bits and 3 float bits (currently consistent with firmware). For reading the $p_T$ back, different algorithms make different assumptions about the width of the datatype, either the actual ap_fixed<10,7> with 7 integer bits, or ap_fixed<14,9>. This works because of a bit-shift that 0-pads the 2 least significant bits of the actual ap_fixed<10,7> data stored in the previoius canonical L1T $\frac{1}{R}$ word; ergo the least significant integer bits are aligned under either interpretation. The $p_T$ conversion also uses an 8-bit LUT to map track values from the ap_int datatype to ap_fixed, which means that the least significant bits are ignored, dropping 2**2 in resolution. Because of the non-linear conversion, this produces strong discretization of high-$p_T$ tracks. A possible remediation of this would involve either splitting the LUT so that a more granular version is applied to high-$p_T$ tracks, or equivalently residual/correction-LUTs to adjust the response where needed. Either approach should require a modest increase in LUT resources but improve the conversion loss. Additionally, studies on $\phi$ mesons and reconstructing $B_s$ from them indicates that the $\eta$ conversion is a significant source of error, but also the $p_T$ appears to have biases (which may have a charge dependence). The latter indicates that there may be an inconsistent use of half-bin shifting in calculations somewhere. The $\eta$ conversion uses a 128-sized LUT (owing to symmetry in the transform, it's cut in half relative to a simple calculation), into an ap_fixed<8,3> datatype; the LUT should be increased by a factor of 2^3 at least to ap_fixed<11,3>, improving the granularity significantly for $\phi$ meson reconstruction.
+The Input conversion in Firmware centrally stores conversion constants and consistently uses the central GTT format (struct) for tracks. Meanwhile, the emulator is in a somewhat different spot, with a low-granularity conversion of $p_T$ with 7 integer bits and 3 float bits (currently consistent with firmware). For reading the $p_T$ back, different algorithms make different assumptions about the width of the datatype, either the actual ap_fixed<10,7> with 7 integer bits, or ap_fixed<14,9>. This works because of a bit-shift that 0-pads the 2 least significant bits of the actual ap_fixed<10,7> data stored in the previoius canonical L1T $\frac{1}{R}$ word; ergo the least significant integer bits are aligned under either interpretation. The $p_T$ conversion also uses an 8-bit LUT to map track values from the ap_int datatype to ap_fixed, which means that the least significant bits are ignored, dropping 2**2 in resolution. Because of the non-linear conversion, this produces strong discretization of high $p_T$ tracks. A possible remediation of this would involve either splitting the LUT so that a more granular version is applied to high $p_T$ tracks, or equivalently residual/correction-LUTs to adjust the response where needed. Either approach should require a modest increase in LUT resources but improve the conversion loss. Additionally, studies on $\phi$ mesons and reconstructing $B_s$ from them indicates that the $\eta$ conversion is a significant source of error, but also the $p_T$ appears to have biases (which may have a charge dependence). The latter indicates that there may be an inconsistent use of half-bin shifting in calculations somewhere. The $\eta$ conversion uses a 128-sized LUT (owing to symmetry in the transform, it's cut in half relative to a simple calculation), into an ap_fixed<8,3> datatype; the LUT should be increased by a factor of 2^3 at least to ap_fixed<11,3>, improving the granularity significantly for $\phi$ meson reconstruction.
 
 ### Vertex Finder (VF)
 #### FastHisto (FH) - Baseline Algorithm
@@ -62,7 +62,7 @@ The MET module has bit-accurate agreement between firmware and emulation. The LU
 ### Phi and Rho Meson Finding
 These currently exist as simulation+emulation studies in private CMSSW branches, with ongoing work to create HLS-based firmware modules.
 
-### $W\rarrow 3\pi$ (W3pi)
+### $W~\it{to}~3\pi$ (W3pi)
 CMSSW [TkTriplet](https://github.com/cms-sw/cmssw/blob/master/DataFormats/L1TCorrelator/interface/TkTriplet.h)
 CMSSW [plugin](https://github.com/cms-sw/cmssw/blob/master/L1Trigger/L1TTrackMatch/plugins/L1TrackTripletEmulatorProducer.cc)
 CMSSW [configuration](https://github.com/cms-sw/cmssw/blob/master/L1Trigger/L1TTrackMatch/python/l1tTrackTripletEmulation_cfi.py)