L1 Track Finding For a TiME Multiplexed Trigger

Transcription

1 V INFIERI WORKSHOP AT CERN 27/29 APRIL 215 L1 Track Finding For a TiME Multiplexed Trigger DAVIDE CIERI, K. HARDER, C. SHEPHERD, I. TOMALIN (RAL) M. GRIMES, D. NEWBOLD (UNIVERSITY OF BRISTOL) I. REID (BRUNEL UNIVERSITY) P. VICHOUDIS (CERN) G. ILES, G. HALL, T. JAMES, M. PESARESI, A. ROSE, A. TAPPER, K. UCHIDA (IMPERIAL COLLEGE)

2 introduction the time multiplexed trigger System architecture track finding using hough transform software simulation hardware implementation demonstrator the future 2

3 the time multiplexed trigger HL-LHC will run up to an integrated luminosity of 3 fb -1 To constrain trigger rate CMS will need to use also tracker informations for L1 trigger purpose CMS will have a complete new tracker for the Phase II upgrade New tracker will adopt double sensors module (PS & 2S modules) A correlation between hits in a two sensors consistent with high pt track will be called a stub Tracks under a certain threshold can be then rejected stub!"##$$$$$$$$$$$$%"&'$ +$**$ y z $$$$$$$$+))$µ*$ x 3

4 the time multiplexed trigger Similar concept used in the HLT All data from one event flow to a single processing node Requires two layers with passive switching network between them (Pre-processors & Main processors) 4

5 TMT motivation Motivation from physics All data in one place improves algorithm performance Especially true for tracking algorithms, that are intrinsically non-localised in space No constraints to algorithms from fixed data routing The trigger algorithms will change during the running period Motivation from implementation A single module design (less resources for design, testing, operations) TMT fits naturally in FPGAs Zero communication between processor modules Only require one module to test full system functionality Motivation from operations Updated algorithms can be tested in the running system parasitically Failures do not bias the trigger System can also be remapped on the fly to replace bad hardware 5

6 TMT Architecture Conceptual architecture defined using current hardware (Imperial MP7) μtca card designed for CMS upgrade L1 calorimeter trigger FPGA Virtex-7 72 I/O optical links (12 Gbps) Total bandwidth >.9 Tbps 6

7 TMT Architecture: detector mapping FE Links 3.2 Gbps per link Pre Processor (PP) Pre Processor (PP) Pre Processor (PP) 1 Gbps per link Main Processor (MP) To Global Trigger Maximum # links to the MP (72) limits # PP connected Need to divide tracker into 5 trigger regions in η ( η 1.) unshared)modules) shared)modules) TP)defini1on)(σ z =5cm))for)luminous)region)in)z) ONE TRIGGER REGION ~ 4 unshared PPs, ~15 shared PPs (sending data to two MPs in different η regions) Stream data into each MP over 24 BX 24 MPs required 7

8 ALGORITHM overview Stub Formatting Pre-Processors (PP) Stub Filtering Stub Clustering Stub ordering Main Processor (MP) Transmission to GT Fitted track selection Track candidate fitting Track candidate filtering Track candidate finding Buffers/time multiplexing Stub mapping to global coordinates 8

9 Track finding: hough transform To build track candidates we proposed an approached based on the Hough Transform HT sorts stubs into candidates before selection and final track fitting HT BASICS Straight lines considered in terms of slope-intercept parameter (a,b) Point (x, y) > Line (a,b) Line (x, y) > Point (a, b) y = a x + b b = x a + y 9

10 Track finding: hough transform HT PARAMETERS Stub Parameter from detector Φ, r; (better resolution) β Stub coordinate transformation Estimating production angle β, using angle of locally straight line β=φ stub - φ Track Parameters in HT m=.6/p T ; c= β Valid for p T > 2 GeV/c Δx local Δφ ~ Δx / δ Δφ δ also Δφ β φ = φ stub 1

11 Track finding: hough transform Implementation Each trigger region subdivided in 64.2 rad β sectors Hough Transform applied to each sector Bin stub in (m, c) space Arrays are filled following a β ordering Currently evaluating alternative sorting (Φ, mixed Φ-β) c HT Array (Dimuon PU14).2 h_hough 24 Entries 956 Mean x Mean y RMS x RMS y m A typical filled array for one slice in β has ~ 6 stubs, each giving multiple entries 9% occupied cells 3 entries on average per cells How can we find our tracks? 11

12 Track finding: hough transform Background sources Real tracks from PU events and secondary vertices ( secondary tracks ) irreducible Random stub combinations, not lines in r-z projection remove in filter Currently we apply two main stage of filtering, using R and η coordinates Correlation of PU tracks with high-pt tracks remove in fitter c HT Array (Dimuon PU14 with register cut) h_hough 2 Entries 12 Mean x 8.2e 5 18 Mean y.7812 RMS x RMS y We require at least one hit in 5+ different layers/disks m 12

13 Track finding: Pile-Up At the High Luminosity LHC we will need to be able to work with an average of 14 pile-up events per bunch-crossing The algorithm has been tested using samples with different pile-up content Crucial parameters are n. filtered cells, fake rate and tracking efficiency 13

14 L1 TRACK FINDING FOR A TIME MULTIPLEXED TRIGGER Track finding: #filtered cells Signal candidates Secondary cand Duplicates Fakes Average cells content in a TTbar PU14 event Filtered Cells (TTbar PU14) h_tot_filt_cells Entries 5 3% 6% 6 Mean RMS % % #Filtered Cells 14

15 Track finding: #filtered cells vs. PU Filtered Cells Filtered Cells Filtered Cells Filtered Cells 14 h_tot_filt_cells Entries 5 Mean 16.6 RMS h_tot_filt_cells Entries 5 Mean RMS h_tot_filt_cells Entries 5 Mean 34.9 RMS h_tot_filt_cells Entries 5 Mean RMS PU2 PU6 PU1 PU #Filtered Cells #Filtered Cells #Filtered Cells #Filtered Cells Filtered Cells Filtered Cells Filtered Cells Filtered Cells 6 h_tot_filt_cells Entries 5 Mean RMS h_tot_filt_cells Entries 5 Mean 66.9 RMS h_tot_filt_cells Entries 5 Mean 113 RMS h_tot_filt_cells Entries 5 Mean 117 RMS PU PU16 PU18 5 PU #Filtered Cells #Filtered Cells #Filtered Cells #Filtered Cells

16 Track finding: Efficiency Algorithm Efficiency Algorithm Efficiency Algorithm Efficiency vs. eta (TTbar PU14) h_eff1_eta Entries Mean.68 RMS η Algorithm Efficiency vs. phi (TTbar PU14) h_eff1_phi Entries 445 Mean.3227 RMS Total Efficiency Total Efficiency Total Efficiency vs. eta (TTbar PU14) h_eff_eta Entries 4 Mean.6 RMS η Total Efficiency vs. phi (TTbar PU14) h_eff_phi Entries Mean.6315 RMS Known issues exist with endcap-barrel region and with φ boundaries Improved filtering could compensate this loss φ boundaries issue due to a coarse beta segment size definition (not submultiple of π).1.1 Algorithm Efficiency " algo = φ stable signal tracks found by HT generated stable signal tracks passing filtering Total Efficiency " tot = φ stable signal tracks found by HT total generated stable signal tracks * Charged particles that can pass through the whole tracker before decaying are considered stable (K, p, e, μ, π) 16

17 Track finding: Efficiency vs. Pile-Up Efficiency Efficiency vs. PU HT/GEN Samples Muons Electrons Pions Protons Algorithm not strongly affected by PU Low electrons efficiency mainly due to Βremsstrahlung May be a possibility to recover this by special binning for very high pt stubs Pile-Up " tot = stable signal tracks found by HT total generated stable signal tracks 17

18 IMPLEMENTATIOn: Data flow optimisation Other optimisations are currently under investigation 18

19 Array implementation ARRAY CONCEPT: eastbound traffic: the stubs move towards east two entry points: west and north (sorting mechanisms) cell readout condition: when stub entries with at least 4 (or 5) different r values (corresponding to different detector layers) paschalis.vichoudis@cern.ch 19

20 Cell implementation Systolic array function Stubs enter at N, S and W sides Stubs automatically propagate eastwards through the matrix Various routing methods under study Implementation status 25x25 array implemented in MP7 Splitting across multiple FPGAs is straightforward to reach 32x32 Intrinsic strength of architecture Future devices likely to be be multi-die 2

21 demonstrator: short term plan Input%Data%Buffers% IPBus% single%mp7%as%main%processor% runs%on%1/(tm%period)%events% stub%mapping%to%global%coordinates% track%candidate%finding% track%candidate%filtering/buffering% track%candidate%fi5ng% MP% uhal% fi6ed%track%selec8on/de:ghos8ng% Output%Data%Buffers% IPBus% %test%bench%for%algorithm%development% %es6ma6on%of%resource%requirements% %extrac6on%of%rough%processing%latency%% Working operation of a single MP (aka one subsegment) will be tested Including interface to PP (1~12.5 Gbps protocol block) Time-schedule: July 215 for single board, September for multi-board More technical details on the demonstrator in Aaron s talk 21

22 demonstrator: long term plan shared'module'pps' 72%x%% 1Gb/s% 72%x%% 1Gb/s% uhal% uhal% unshared'module'pps' Expanded system for track filter/fitter testing Emulate a whole trigger segment, planned for late 215 More technical details on the demonstrator in Aaron s talk 22

23 the future SIMULATION Continue tuning and optimisation of Hough transform algorithm Develop r-η track filter algorithm and specify interface to track fitter Look further into electron/hadron efficiencies Code is currently rewritten to have a more modular structure Implementation Complete 32x32 array demonstrator Develop CMSSW emulator for TMT track finder Three way comparison: CMSSW VHDL simulation hardware test Demonstration Single board testing expected during the Summer Full multi-board demonstrator data by September 215 Bring in filter and fitter for complete slice test by end of

24 thanks! * This project has received funding from the European Union s Seventh Framework Programme for research, technological development and demonstration under grant agreement n