Slide 1Calorimeter Trigger Upgrade Workshop, 29/11/[email protected] Track & Calo Trig Simulation D. Newbold, J. Brooke, R. Frazier à Track trigger

Slide 1 Calorimeter Trigger Upgrade Workshop, 29/11/07 [email protected]

Track & Calo Trig SimulationD. Newbold, J. Brooke, R. Frazier

Track trigger ‘requirements’ Track trigger concept

Stacked layers + candidate-driven (‘outside-in’) approach Trigger simulation Implications for calo trigger upgrade Future work…

Goal of giving this talk The ‘concept’ makes assumptions on the new calo trigger Are these justified / reasonable / possible? Who plans to work on track / calo simulation? How to organise coherent all-detector trigger upgrade simulation?


Track Trigger Reqts Will not rehearse again the motivation for upgrade

Goal: maintain ~LHC trigger performance (thresholds, rates) Track trigger functions

A stand-alone track trigger is not necessary For muons: confirmation from tracker of isolated high-pt muon candidates

• + refinement of pt measurement with extra points For calo: increased rejection of fake e/ objects

• + refinement of isolation and jet ID Rejection of uncorrelated (different primary vertex) double combinations

Constraints Operate within few s fixed L1 latency - no ‘selective readout’ Do not add to tracker material / power budget Reasonable bandwidth for readout / Reasonable processing density Robust w.r.t background, inefficiency, alignment, etc Interface to other elements of L1 system

• Muon / calo trigger upgrade can provide enhanced space / pt resolution?


Technical Challenges On-detector

Raw information from tracker is huge in size Communication bandwidth likely to drive on-detector power budget Tracker is a highly integrated electromechanical system

• Trigger functionality must be integral part of new design from the start

Off-detector: experience from existing L1 trigger Communications density / data concentration is the key problem In particular: dealing with overlaps / edges can be very hard Processing density not a constraint; deep pipelining possible

Heavy on-detector data reduction is required Communication between tracker layers is probably impractical Require multiple stand-alone measurements of candidate tracks

Implementation of a track trigger will be challenging! Focus on reduction of the key parameter: readout bandwidth


Trigger Concept: On-Detector Use ‘stacked layer’ concept:

Presented before in inner pixels context

• See past talks of J. Jones et al Use two space-points from

sensors separated by some mm Correlate 2D hits for track stub

position & slope in / Window cut in excludes low-pt

minbias tracks• Also cuts digital logic - important

Modularity to match calo trigger towers (0.0875 in / ) One trigger / readout ASIC per TT performs hit correlation Output 4 candidate stubs (<nch> < 1 at r=0.6m for pt > 3GeV/c) If >4 candidates, count and flag as possible jet activity

• Detailed information is not required, since isolation cut already failed


Trigger Concept: Layout Two (or more) specialised trigger planes in ‘outer tracker’

Low occup. / long lever arm at large r allows coarse-resn sensors• Reduced cost and power consumption for sensor + trigger logic

Outer (r=1.2m) plane for direct correlation with muon / calo objects Inner (r=0.6m) plane for b/g rejection, supports / z measurement O(250) 2.5Gb/s fibre output – see TWEPP 2007 proceedings for details


Trigger Concept: Off-Detector Divide trigger processing regionally

36 regional subsystems each process a half-detector, 20 degrees in Each subsystem process muon, calo and track information Data-sharing (~25% of data) covers track propagation between regions

• Simply a duplication of input data - passive optical splitting?

Track finding Hold track segment info until muon / calo objects are available Seed track building from candidates; define restricted ROI at inner layer

• Cuts down enormously on correlation logic Outer stub eta directions used to identify + request inner layer stubs A match in eta / phi slope (using beam constraint) flags a physical track

• NB: No attempt to determine track pt

Output to global trigger Fixed number of muon / calo / jet candidates with pt / Et, charge, quality Track-based jet tag for isolation purposes

• Also possibility of track-count ID, etc.


Processing Topology

Generic FPGA-based board for all subsystem functions


Track Trigger Simulation Need to confront the various ideas with simulation

Highly topical for evaluation of tracker design ‘straw men’ Some immediate questions for simulation

What are the occupancies for the various tracker layouts? How many trigger layers? Where? How to tune the stacked layers? (spacing versus granularity) Number of candidates per module? Precision of primitives? How much compression is possible? What scheme to use? Optimal stub-finding algorithm (given power constraints, etc)?

• How much can be analogue / digital? Detailed strategy for correlation with calo / muon trigger? Sensitivity to alignment, noise, inefficiency, dead channels, etc Eventually: simulate performance on benchmark channels

This is a great deal of work, phase space is large Need to focus quickly on most promising ideas + pursue There is 100% interplay with the overall tracker simulation effort


Simulation Tools Requirements on simulation tools

Clean interface with tracker simulation• Discussing with tracker upgrade sim group; trig sim cannot use tracker digis!

Clean interface with calo / muon trigger simulation• Evolution of existing emulator? Or completely new code?

Modular – digitisation; trig prim generation; off-detector algorithms Flexible – assume no particular geometry, granularity, sensor type, etc

Work on a first toy prototype now starting First pass at tracker hits -> ‘L1TrackHits’ (barrel only at present)

• No bit-level simulation, but resolutions can be smeared ‘Perfect’ window based stub-finder, no attempt to emulate digital logic Can be driven from four-vectors (incl. pileup) or full simulation

First goal: proof-of-principle for ‘perfect stubs’ electron track correlator Learn lessons for construction of real framework Work with tracker upgrade sim group to understand technical issues


Toy Simulation

Interface to tracker simulation Watershed is effectively the correlator part of module readout chip Assume this corresponds to a physically distinct readout path All trigger simulation takes place in idealised coordinate system We do assume tracker physical modularity matching trigger towers


Existence Proof 500k gen. level minbias events

- barrel only Av. ~6k hits per BX in 60cm

layer from in-time events alone OOT hit occupancy requires

further work


Calo Trig I/F - Reqts Proposed interplay of track and calo

Calo operates as stand-alone trigger• Provides fixed number of candidates to track correlator

Correlator searches for matching tracks• Begin with calo candidate, propagate inwards through tracker layers

Augments “e cand” with charge, track-based position, z-vertex posn. Augments “ cand” with track based isolation flag Augments -jet candidates with track count confirmation Correlator forwards augmented candidates to GT

Requirements Precision: need at least tower-level position information

• Can we make use of ‘strip’-level position in EE? May help with propagation Latency: must leave time for track correlator to operate

• The correlator latency requirement need not be large• Probably dominated by ‘lookup time’ for stub lists in inner layer(s)• Preparation of stub lists in the shadow of calo / muon processing


Summary & Future Work Track trigger concepts exist – at ever-increasing levels of detail Track trigger simulation

Essential as input into tracker design; first toy tools being constructed now ~1.5FTE in UK, hope to go to ~5 by late 2008 (See UK R&D proposal)

• DN, J. Brooke, R. Frazier, G. Heath, A. Rose + new postdocs / grad stdts.• The proposed tracker-trigger watershed is the correlator ASIC

Bit-level simulation is probably not required at this stage (but soon…) Calo / track interface

Track trigger relies on calo (and muons) for operation The hardware is likely to be co-located in regional processors Need to reflect this in a single, consistent, simulation package

Future work Continue proof-of-principle simulation work - few weeks timescale Work closely with tracker upgrade group Put together a single coherent simulation of upgraded trigger

• Need to discuss between track trigger proponents, calo and muon experts


Backup


On-Detector System Parameters Design for track acceptance for pt > 4GeV/c

Largely above minbias spectrum, still good acceptance for jet / tracks Track curvature lies within ±1TT in ; limits data-sharing requirements Sensor doublet must cover all physical high-pt track trajectories

• I.e. physical overlap of sensors

Hit resolution requirements Resolution in dictated by practical limit of layer spacing

• Spacing upper limit from accidental coincidence reduction - to be tuned• At 10mm spacing, resolution > 0.5mm

Resolution in z dictated by slope-matching + vertex z-resolution• At 10mm spacing, resolution > 2mm is adequate (c.f. <dzvtx> ~ 70mm)

Use full-precision 2D layers, also functioning as stereo layers? Readout requirements

(4b+4b) position, (4b+4b) slope (with offset) will allow stub matching Implies ~1200 x 10Gb/s readout fibres Can reduce further (factor of ~10?) using on-detector data compression

• Zero-suppression; pt sorting; variable-sized payload (asynchronous links)

Documents

Slide 1Calorimeter Trigger Upgrade Workshop, 29/11/[email protected] Track & Calo Trig Simulation D. Newbold, J. Brooke, R. Frazier à Track trigger