Utilisation du tracker de CMS au niveau 1 du trigger 5 Novembre 2012

Temps de latence: qqs ms 1. Introduction 2. Dimensionnement du système 3. Implication possible Problème Principe → Le trigger de CMS: Niveau 1 (L1) Purement hardware, reçoit des données à 40MHz, utilise actuellement le spectromètre à muons et les calorimètres. Temps de latence: 6.4ms. Niveau 2 (HLT) Software, reçoit des données à 100kHz. Utilise l’ensemble du détecteur. Temps de latence: qqs ms ~1kHz enregistrés 2

Comment utiliser le tracker au niveau 1? 1. Introduction 2. Dimensionnement du système 3. Implication possible Problème Principe → Evolution du trigger avec la luminosité: → Au niveau 1, on ne peut pas mesurer précisément l’impulsion des muons (pas de tracker), surtout à haut pT (courbure très faible) Plateau si L1 sans tracker. Le niveau du plateau est lié à la luminosité Avec le tracker on peut attaquer ce plateau Comment utiliser le tracker au niveau 1? 3

→ Reconstruire des traces: 1. Introduction 2. Dimensionnement du système 3. Implication possible Problème Principe → Reconstruire des traces: Extraction des infos du tracker et acheminement au système de trigger → Pour le moment, cette reco se fait uniquement par soft dans CMS et ATLAS. Etape 1 Identification des groupes de hits compatibles avec des trajectoires de particules (Pattern Reco) → Algorithmes complexes, très gourmands en CPU → Le niveau 1 requiert une approche purement hardware. Techniques très différentes. Etape 2 Extraction des paramètres des traces (Track Fit) → On paramétrise le problème en amont (simulations) Envoi des infos au trigger L1 central 4

(Memoires associatives) 1. Introduction 2. Dimensionnement du système 3. Implication possible Problème Principe → Principe de la reco hardware des traces: Pattern Reco (Memoires associatives) 1 Gare de triage FEDs Données 2 Track Fit (FPGA) 3 Données Trigger CARTE(S) TRIGGER 5

→ L’état de l’art: 1. Introduction 2. Dimensionnement du système 3. Implication possible Problème Principe → L’état de l’art: → Système mis en place dans l’expérience CDF au Tevatron → Sera mis en place dans ATLAS (mais au niveau HLT) en 2016 (upgrade phase 1) → Quelques infos techniques sur le système mis au point part ATLAS (FTK): Technical proposal: http://hep.uchicago.edu/~shochet/FTK_NSF/FTK_TP.pdf → Chacune des fonctions (PR, TF, Triage) est implémentée sur une carte différente. → La première étape est de voir si ce système est adaptable à CMS… → Les principaux problèmes dans notre cas: La gestion du flux de données entrant (plusieurs dizaines de Tb/s) Le temps disponible (quelques microsecondes) L’organisation des données dans le système trigger … 6

(Memoires associatives) 1. Introduction 2. Dimensionnement du système 3. Implication possible → Envoi des données au système trigger: Pattern Reco (Memoires associatives) 1 Gare de triage FEDs Données 2 Track Fit (FPGA) L1 central board 3 Données CARTE(S) TRIGGER L1 7

→ Géométrie du tracker phase II: 1. Introduction 2. Dimensionnement du système 3. Implication possible Flux en entrée Identification des traces Reconstruction des traces → Géométrie du tracker phase II: March → Ce projet est en concurrence avec un autre, dont la géométrie est plus adaptée au trigger L1. Utiliser une géométrie standard au L1 est clairement plus complexe, mais permet de conserver une bonne qualité de données offline. → Les caractéristiques des traces à reconstruire au L1 sont très importantes, mais on ne les a pas pour le moment (on devrait les avoir en 2013)…. → On est partis sur des estimations conservatives, donc sur un dimensionnement ‘pessimiste’ → Le détecteur est divisé en secteurs indépendants, afin de réduire le flux de données entrant dans chaque système L1 trigger 8

→ Reduction du flux de données entrant: 1. Introduction 2. Dimensionnement du système 3. Implication possible Flux en entrée Identification des traces Reconstruction des traces → Reduction du flux de données entrant: SW = 0.5 High-Pt stub → L’electronique frontend fabrique des stubs à partir de coincidence entre 2 détecteurs proches. → En utilisant des stubs on gagne au moins un facteur 10 sur les rates → Pour des événements typiques à très haute lumi (PU 200), les rates varient entre qqes centaines de kHz par cm2 et 2MHz/cm2, selon la distance entre le module et le point d’interaction SW = 2 Low-Pt stub → Les rates de stubs par module seront compris entre 10 et 50MHz → En comptant 50 bits par stubs, cela donne des flux moyens compris entre 500 et 2500Mb/s par module. → Si on connait la taille des secteurs, on peut estimer les flux de données à envoyer à chaque trigger. 9

(Memoires associatives) 1. Introduction 2. Dimensionnement du système 3. Implication possible → Mémoires associatives: Pattern Reco (Memoires associatives) 1 Gare de triage FEDs Données 2 Track Fit (FPGA) L1 central board 3 Données CARTE(S) TRIGGER L1 10

Hits compared to a bank of prestored patterns 1. Introduction 2. Dimensionnement du système 3. Implication possible Flux en entrée Identification des traces Reconstruction des traces → Principe    Feed event hits into the AM …   L1 event Hits compared to a bank of prestored patterns  Find matches in one pass  To the track fit… List of patterns for the event 11

1. Introduction 2. Dimensionnement du système 3. Implication possible Flux en entrée Identification des traces Reconstruction des traces → Caractéristiques techniques du chip AM utilisé par ATLAS (développé par l’INFN Pisa): → Fréquence de fonctionnement : 100 MHz → Nombre de lignes d’entrée (1 ligne = 1 layer): 8 → Flux maximal en entrée (par ligne): rc = 2.5 Gb/s → Nombre maximal de patterns par chip: Nc: 30000 → Soit Ni le nombre de patterns par secteur, et ri le flux d’entrée par ligne pour tout le secteur, le nombre de chips nécessaire pour un secteur est théoriquement Ni∙ri Nchips = Nc∙rc → Exemple, pour 200000 patterns par banque avec un taux d’entrée de 10Gb/s, il faut 27 chips… Le système d’ATLAS contient 128 chips par carte. → Définir une banque optimale est primordial pour un bon dimensionnement du système. Ce travail est actuellement effectué à l’IPNL. 12

→ Definition des secteurs: 1. Introduction 2. Dimensionnement du système 3. Implication possible Flux en entrée Identification des traces Reconstruction des traces → Definition des secteurs: → We define sectors using ‘brute force’ method: We choose a ladder in the innermost layer We look where are going the 2GeV/c m+/- crossing this ladder March → No sector overlap in the innermost layers. Sectors with 3 layers (14/15 modules in r/f) Sectors with 4 layers (16 modules in r/f) → We tested 2 different sector sizes (3/4 layers) 13

→ Flux, par layers, dans la partie AM: 1. Introduction 2. Dimensionnement du système 3. Implication possible Flux en entrée Identification des traces Reconstruction des traces → Flux, par layers, dans la partie AM: → Les infos sont mises en forme et envoyées aux chips AM par la gare de triage, qui récupère ensuite les patterns matchées. → A partir des flux de stubs par module, et des secteurs, on peut estimer le flux total de données à envoyer à chaque chip AM: March Layer 5 6 7 8 9 10 Input rate for 3 layers (in Gb/s) 0,0 7,4 10,4 9,1 Input rate for 4 layers (in Gb/s) 5,6 → Ces flux peuvent être ramenés à des valeurs acceptables en utilisant plus de chips 14

(Memoires associatives) 1. Introduction 2. Dimensionnement du système 3. Implication possible → TrackFit: Pattern Reco (Memoires associatives) 1 Gare de triage FEDs Données 2 Track Fit (FPGA) L1 central board 3 Données CARTE(S) TRIGGER L1 15

xi2>e Fake track → Step 1: eliminating fake candidates March 1. Introduction 2. Dimensionnement du système 3. Implication possible Flux en entrée Identification des traces Reconstruction des traces → Step 1: eliminating fake candidates → Each track has n coordinates, and could thus be defined has 1 coordinate in an n-dimensional space. March → In most cases, the track is totally defined by l parameters (pT,d0,…). It means that an l-dimensional space is sufficient to define all the tracks. → Transformation from the detector space to this optimal space can be found using Principal Component Analysis x0 x1 xn … = M ∙ Track in the system with l principal components Track in the detector reference system → If we project the n coordinates of a good track on the new space, one obtains l large values, and n-l residuals. If the sum of squared residuals is larger than a certain value, the track candidate can be rejected. ∑ xi2>e Fake track n-l 16

y = p1∙x2 + p2∙x + p3 pi ≈ f(xi) ≈ g(xi) 1. Introduction 2. Dimensionnement du système 3. Implication possible Flux en entrée Identification des traces Reconstruction des traces → Step 2: estimating track parameters → Suppose we can find a linear parametrization for the track (eg parabola for cicular track in the transverse plane). March y = p1∙x2 + p2∙x + p3 → The parameters pi can be extracted via a multidimensional least squares fit. Then they can be expressed as a function of the coordinates: pi ≈ f(xi) ≈ g(xi) → Using the new space simplifies the job, but in practice you can do that with the main coordinates… → En paramétrisant les traces, on réduit le problème à une série de multiplications et d’additions. Potentiellement implémentable dans un FPGA (solution choisie dans ATLAS). 17

1. Introduction 2. Dimensionnement du système 3. Implication possible Projet ANR possible (en collaboration avec ATLAS LPNHE et CMS PISE): réaliser un démonstrateur incluant les trois fonctionnalités, afin d’avoir une première estimation de la latence du système d’ici 2015. → Carte trigger: Le FTK d’ATLAS est composé de 3 cartes. Regrouper les fonctionnalités sur moins de cartes permettrait de réduire la latence (important pour nous). L’INFN de Pise travaille déjà sur une optimisation de la carte AM, et peut donc collaborer avec nous sur ce point. → AM chip: Le chip d’ATLAS nous suffit dans un premier temps. Les dvlpts actuels concernent l’augmentation de la taille des banques (passage en 3D), pas forcément utiles pour nous (pas inintéressants pour autant…). → Track Fit: Peut être développé à partir de FPGAs. Projet a priori plus simple que le développement de la carte. March 18

 Feed event hits into the AM 1. Introduction 2. Status 3. Plans Principle Barrel-endcap geometry Expected stub rates The procedure → Some of the main difficulties:  Feed event hits into the AM → Which data rates should we expect at 20/40 MHz? Can we extract them towards the AM board? → Can the AM board input lines sustain such rates? → Can we do the pattern matching (well, everything…) in the available latency (~3ms)?  Find matches in one pass → What is the maximum acceptable size for the pattern bank? → What is the optimal pattern bank?  To the track fit… → What is maximum acceptable rate of matching pattern after the AM board? → How to remove efficiently the fake/duplicate pattern? → How to send the info to other L1 systems? 3 AM Pisa Meeting G. Baulieu, S. Viret

From tracker to superstrip 1. Introduction 2. Status 3. Plans Sector used and superstrip definition Bank generation Pattern matching on simple events Pattern matching on PU events → Superstrip definition: From tracker to superstrip → A superstrip is simply a bunch of strips in one module of the tracking detector. March → The superstrip address is the info sent to the AM board. Is is coded on a certain number of bits, depending on the superstrip resolution. Superstrip encoding → The encoding is divided into 4 parts, giving module and intra-module SS position in Z and f direction (R is not necessary) → We are not using pixel info yet, so our Z intra-module encoding is very basic for the moment. 12 AM Pisa Meeting G. Baulieu, S. Viret

→ The baseline: March 1. Introduction 2. Status 3. Plans Sector used and superstrip definition Bank generation Pattern matching on simple events Pattern matching on PU events → The baseline: → The bank generation software process iteratively using a set 20M Pgun m+/m- with pT bet. 2 and 100 GeV/c → The coverage is defined as the proportion of tracks in the sector matching a pattern in the bank. March → The coverage you require is one of the parameters driving the size of the bank. Convergence for 3 layers, 16 strips Convergence for 3 layers, 32 strips 90% cov  700000 patterns 95% cov  350000 patterns 90% cov  200000 patterns → The superstrip size (see plots) is significantly affecting the bank size. → With 32 strips, for an equivalent coverage, 3.5 times less patterns than with 16 strips are necessary → With 4 layers, one needs 700000 patterns to get a 90% coverage with 32 strips (not enough stat with 16 strips) 13 AM Pisa Meeting G. Baulieu, S. Viret

1. Introduction 2. Status 3. Plans Sector used and superstrip definition Bank generation Pattern matching on simple events Pattern matching on PU events → Few definitions: Efficiency = # of primary tracks (ie coming from IP) contained in at least one activated pattern # of primary tracks (with at least one stub per layer) Fake rate = # of activated patterns containing NO primary track # of activated patterns Redundancy = # of primary tracks activating more than one pattern # of primary tracks activating a pattern → We want a good efficiency for particle with Pt>2GeV/c, with the lowest possible fake rate, and keep the redundancy a low as possible. 19 AM Pisa Meeting G. Baulieu, S. Viret

→ Results on mu+/mu-: 1. Introduction 2. Status 3. Plans Sector used and superstrip definition Bank generation Pattern matching on simple events Pattern matching on PU events → Results on mu+/mu-: → Baseline result for 3 layer sector, using the classic bank, requiring exactly 3 stubs on the pattern → Slow turn-on curve (we’re aiming for 2GeV/c), but low fake rate and redundancy 90% coverage 3 layers 16 strips 0 DC bit → The slow turn on comes from tracks with missing stubs, and from the fact that it’s difficult to populate the bank at low Pt. eff = 88.9% fake = 1.1% redundancy = 3.8% → First point can be solved by adding missing stubs possibility, second point by adding DC bits. 20 AM Pisa Meeting G. Baulieu, S. Viret

→ Effect of missing stubs, DC bits: 1. Introduction 2. Status 3. Plans Sector used and superstrip definition Bank generation Pattern matching on simple events Pattern matching on PU events → Effect of missing stubs, DC bits: 90% coverage 3 layers 16 strips 0 DC bit 90% coverage 4 layers 32 strips 0 DC bit Baseline Go to 4 layers, accept 1 missing stub per pattern eff = 88.9% fake = 1.1% redundancy = 3.8% eff = 96.3% fake = 2.4% redundancy = 90.3% Add DC bits Add DC bits 90% coverage 4 layers 32 strips 3 DC bits 90% coverage 3 layers 16 strips 3 DC bits Go to 4 layers, accept 1 missing stub per pattern eff = 97.2% fake = 1.9% redundancy = 6.6% eff = 99.6% fake = 4.0% redundancy = 91.0% 212 AM Pisa Meeting G. Baulieu, S. Viret

→ Result for electrons (worst case for single particle): 1. Introduction 2. Status 3. Plans Sector used and superstrip definition Bank generation Pattern matching on simple events Pattern matching on PU events → Result for electrons (worst case for single particle): 90% coverage 3 layers 16 strips 0 DC bit 90% coverage 4 layers 32 strips 0 DC bit March Baseline Go to 4 layers, accept 1 missing stub per pattern eff = 68.5% fake = 32.5% redundancy = 3.5% eff = 84.4% fake = 41.6% redundancy = 91.4% Add DC bits Add DC bits 90% coverage 4 layers 32 strips 3 DC bits 90% coverage 3 layers 16 strips 3 DC bits Go to 4 layers, accept 1 missing stub per pattern eff = 87.2% fake = 51.8% redundancy = 6.1% eff = 93.2% fake = 49.6% redundancy = 90.2% 21 AM Pisa Meeting G. Baulieu, S. Viret

→ Conclusion on simple events: 1. Introduction 2. Status 3. Plans Sector used and superstrip definition Bank generation Pattern matching on simple events Pattern matching on PU events → Conclusion on simple events: → The addition of DC bits and missing stubs is significantly improving the turn on of efficiency curve. → For muons (and also for pions), we can be within the requirements (Pt>2GeV/c with >90% efficiency). → The convergence for electrons is also pretty good, but as expected a bit worse. → The price to pay is a larger redundancy (when adding DC bits), and a larger fake rate (when adding missing stubs). Depending on the difficulty to sort this out at the trackfit stage, this could be or not a problem. → Next step is to look at heavy pile up events (200PU). 22 AM Pisa Meeting G. Baulieu, S. Viret

→ Results with 200 PU events: 1. Introduction 2. Status 3. Plans Sector used and superstrip definition Bank generation Pattern matching on simple events Pattern matching on PU events → Results with 200 PU events: 90% coverage 3 layers 16 strips 0 DC bit 90% coverage 4 layers 32 strips 0 DC bit Go to 4 layers, accept 1 missing stub per pattern eff = 11.0% fake = 29.7% redundancy = 2.3% avg pat/sec = 0.6 eff = 21.7% fake = 68.3% redundancy = 83.1% avg pat/sec = 11.0 Add DC bits Add DC bits 90% coverage 4 layers 32 strips 3 DC bits 90% coverage 3 layers 16 strips 3 DC bits eff = 23.7% fake = 67.3% redundancy = 4.0% avg pat/sec = 2.6 Go to 4 layers, accept 1 missing stub per pattern eff = 33.7% fake = 90.2% redundancy = 82.6% avg pat/sec = 53.7 23 AM Pisa Meeting G. Baulieu, S. Viret

→ Rates of matched patterns with 200 PU events at 20MHz: 1. Introduction 2. Status 3. Plans Sector used and superstrip definition Bank generation Pattern matching on simple events Pattern matching on PU events → Rates of matched patterns with 200 PU events at 20MHz:   N DC bits 1 2 3 Sector with 3 layers Total pattern rate (in MHz) 11,2 12,4 22,2 52,4 Good pattern rate (in MHz) 7,9 8,1 10,5 17,1 Sector with 4 layers 219,8 214,2 428,6 1073,2 69,7 57,3 70,0 105,2 March → The fake rate is clearly larger in PU events (not really a surprise). → The efficiency looks small, but is mainly driven by poor efficiency on the huge amount of low Pt particles. At higher Pt the efficiency is close to 1. → We reach 90% at ~15GeV/c. This is far from 2GeV/c, but this is a very first look, there is plenty of room for improvement (stub cuts, higher resolution pattern bank,…) → The 2GeV/c is not out of reach at all… 24 AM Pisa Meeting G. Baulieu, S. Viret