Fix some LaTeX 2

Author: Nick Manganelli

L1Trigger/L1TTrackMatch/Readme.md

@@ -3,7 +3,7 @@ This section describes several componenets of the Global Track Trigger, the CMS
 
 ## 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~\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.
+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.