L3 Algorithms: status and plans for the near future

D Trigger Workshop: 22nd April 2002

Dan Claes and Terry Wyatt.

Design:

L1 L2 L3 tape 10kHz 1kHz 20-50Hz

Currently:L1 L3 tape . 100Hz 20-50Hz

• Factor ~ 5 rejection needed

• Calorimeter-based filtering only (jets, electrons, taus)

• Next steps (p11.06 release) to commission:

Muons, tracking, track-based primary vertexing, and hot cell killing (L3 NADA).

Time budget for L3 i/o, event building, filtering 100 nodes * 10-3 s = 0.1 s

Level 3 Jargon• Tool: Does the real work

– Unpacks raw data, finds tracks, clusters – Identifies physics objects (e, , , jet ,, W, Z)

• Filter: Applies (simple) cuts on objects – e.g. pt() > 10 GeV

• Filter Script: Defines a L3 trigger condition– Logical .AND. of one or more filters– If all filters in a script are .TRUE. trigger is satisfied and

event is recorded• ‘Mark and Pass’:

– Selects unbiased sample of input events to be recorded• ‘Forced Unbiased’

– Events written out exclusively because ‘Mark and Pass’ bit set

ScriptRunner

Author: Moacyr Souza (Fermilab/LAFEX)

L3 central code management: Jon Hays (Imperial)

In order to save processing time:• Only a partial reconstruction of each event is performed,

depending on the L1/L2 trigger information• For each L1/L2 trigger that fires:

– One or more L3 filter scripts run– Details of which filters/tools are called by each script is determined

by the triggerlist• Tool results are kept in case they are needed again

Short term goal: to run a filter L3FMuon

• with ‘tight / loose / a-stub’-like quality criteria• cutting on muo_local pT

Mainly needed for single muon triggers(which currently have a L1 prescale of ~40)

L3TMuon (local muon track reconstruction)

original author: Paul Balm (NIKHEF) current responsibles: Christophe Clement (Stockholm) , Martijn Mulders (Fermilab), Martin Wegner (Aachen)

+ L3TMuon uses much of the ‘offline’ muon reco code

L3TMuon

Issues:• Unpacker• Memory leaks and timing problems• Keeping up with updates to the offline muon

code• Efficiency/rejection

P11.04.01 version run online in special runs:• Run 150554: 120k mu1ptxctxx_fz (central)• Run 150556: 70k mu1ptxbtxx_fz (forward)

Unpacker

• Dynamic unpacker: recognises from the raw data which crates/modules are being read out.

• Written by Scott Snyder.• Shown to give ~ identical results to

old unpacker + the correct cfg.dat file.• Released (p11.04.00)

Memory Leaks• Longstanding problem of ~2 kByte/event memory leak• Traced to problem in muon_geometry• Fixed (Rick Jesik) in p11.04.00 version• Unfortunately, p11.04.00 contained many other changes to the ‘offline’ muon software, which caused huge memory leak• Temporary cure: revert to ignoring MDT modules with >30 hits (which was p11.03.00 default) p11.04.01 release• Some evidence of residual low level memory leak when run online (in single muon special runs)

Memory Leaks

Timing

• p11.04.01 default rcp parameters (maxopt version running on 1 GHz PIII)• mean time/event ~100 ms• when run online ~50 out of 200,000 events took more than 30 seconds to process

• p11.04.01 parameters tuned to reduce time taken: - extrapolation step size - number of track-fit iterations - number of A/BC segments considered • mean time/event ~16 ms• expected to eliminate time-outs

Efficiency (pT = 5 GeV single muons)

‘Loose’ L3 muon

‘Tight’ L3 muon

‘Loose’ efficiency ~80% (cf. geometrical acceptance ~90%)

Poor ‘tight’ efficiency in central region (track fit fails to converge – also seen in ‘offline’ reco.)

Rejection measured on single muon test runs

defaultparameters

tuned parameters

central forward

Next Steps for L3FMuon• Take another single muon test run (with

tuned parameters)– A test run with a cosmic trigger has been taken

and showed no obvious signs of timing or memory problems

• Get L3FMuon running full-time– Global_CalMuon6.00 exits with loose L3FMuon

hanging off L1 single muon and muon-jet triggers (100% Mark&Pass)

• Optimise parameters:– Memory/timing efficiency/rejection

Next Steps for L3FMuon

• Fix reco memory leak that occurs when MDTs have many hits

• Stricter procedures for production releases of ‘offline’ muon reco software– Including a specific requirement for L3FMuon

tests BEFORE code changes released to production branch

• Longer term: We need a serious analysis of the cost/benefit of retaining/breaking the link between L3TMuon and muon reco

Recent progress in L3 central tracking

• Offline quality unpacking and geometry for L3• Improved SMT-CFT matching• Proposal for stand-alone tracking filter• Track-based primary vertex tool

Recent improvements in CFT unpacker: • replace global threshold with individual channel thresholds • up to date thresholds and cable maps

Offline quality geometry implemented for SMT and CFT in L3

(Will be released in p11.06.00)

When improved thresholds/cable maps/geometry are available:• requires no code changes• but care in archiving/version-tagging (general problem!)

SMT UnpackingCFT Unpacking

Principal author: Robert Illingworth (Imperial College)

Level 3 Global Track Finding author: Daniel Whiteson (Berkeley)

a global (SMT plus CFT) track finder • Find axial CFT tracks• Match stereo CFT clusters• Extend into SMT• Require 8/8 axial CFT hits if no matched axial SMT hits• Require 7/8 axial CFT hits if 3 matched axial SMT hits• If CFT axial/stereo match fails:

• CFT-SMT match done in xy-only• but SMT stereo information still used to give 3D tracking

(this is a new feature implemented in p11.06.00)

Current L3 global tracking performance

track (rad) z at dca (cm)

Number of axial hits on track

CFTonly

Number of stereo hits on track

Comparison of L3 and offline tracking

number of tracks track (rad)

q/pT (GeV-1) dca (cm)

A possible stand-alone track-based filter• Require at least one track with pT > cut• Try out on events with single muon triggers

Rejection factor (all events)

Efficiency(events withtight offline muonwith pT>3.0)

Rejection vs.Efficiency

At 50% efficiency,rejection of ~25

Timing for global track tool

Time per event (ms)On d0mino (debug version)

+ about 30 ms per event for unpack tools

CFT Tracking Algorithm - L3TCFTTracker

Principal author: Ray Beuselink (IMPERIAL)

P11 tool certification: Robert Illingworth and Chris Barnes

A possible plan for filtering on single muon triggers

• EITHER: Loose L3 muon • OR: Central track

– (i.e., using redundancy to improve efficiency)– N.B. Tracking will not be perfect for a long time– (If you don’t like this, you can always exclude these event by using the

L3 trigger names)

• Longer term:– May need to require track-muon match (at least for low pT) Tool exists (Paul Balm) – Also investigate track-Calorimeter MIP match Tool under development (Martin Grünewald)

We could require an .OR. of:

L3 Primary Vertex needed soon!

author: Guilherme Lima (UERJ/Brazil)

Has yet to be tested on REAL DATAOpportunity for new person to get involved!

1) Histogram technique using SMT hits

2) L3TVertexFinder Track-based vertexing toolauthor: Ray Beuselinck (Imperial)

Recently upgraded to use either CFT or Global candidate tracks as input

Chris Barnes, Per Jonsson (Imperial) testing

N.B. Marseille group (Arnaud Duperrin, Mossadek Talby,Eric Kajfasz) hope to be actively involved in testing tracking, vertexing.

L3TEle Electron Tool authors: Volker Buescher (Mainz) Ulla Blumenschein (Mainz)

Current filter:• simple 0.25 cone• applying cuts on

• ET

• e.m. fraction (>0.9)• transverse shower shape

, : energy weighted cluster axis position

i

iii

EE

r22 )()(

Electronefficiency inWHebbMonte Carloevents

Rejection inCEM(1,5)data events

Events rejected by:pt cute.m. fractionshower shapeelectron candidates

pT electron (GeV)

pT electron (GeV)

Cuts on transverse shower shape

Cut recommended by L3 group

Cut accepted by trigger board

Single electron triggers

• At L1 we have two (unprescaled) single electron triggers:– CEM(1,10)– CEM(2,5)

• At L3 we run the same two single electron filters:– pT > 15 GeV, emfrac > 0.9

– pT > 12 GeV, emfrac > 0.9, shower shape

• We do a similar thing with CEM(1,5) – (heavily prescaled)

• Most of the rest of the e.m. trigger list CEM(1,10).and.X is relatively uninteresting

Rejection factors for single electron filters

L1 trigger Trigger name expected actual

rejection rejection

CEM(1,10) EM_HI 5.2 5.1

EM_HI_SH 5.3 4.2

(3.6)

CEM(2,5) EM_HI_2CEM5 8.3 7.1

EM_HI_2CEM5_SH 11.4 10.1

(6.7)

CEM(1,5) EM_LO 18.8 16.3

EM_LO_SH 9.5 9.8

(7.8)

(run 149334)

(numbers in brackets represent the .or. of the two parallel filter scripts)

Further developments for single electron triggers ?

• More sophisticated treatment of transverse and longitudinal shower shape– Studies in progress

• Add in parallel to the two current filters: – Higher pT cut and softer e.m. fraction cut?– Stand-alone track filter?– Matched track+ looser e.m. cuts?– Matched preshower + looser e.m. cuts?– Do we have enough L3 trigger bits?– Alternative: have one filter that combines all available

information (with details of the trigger decision stored in L3PhysicsResults)

• Try CEM(1,8).CEM(2,2) at L1?

L3TJet Tool author: Volker Buescher (Mainz) Rejection of L1-accepts makes use of:

• high precision calorimeter readout available at L3• simple cone algorithm

identify (and reject) low-ET events passing L1 trigger sharpen the turn-on curve

•running online stably since early Sept’01

DATA runs 142871-142874

e.g., Fraction of

events passing L3FJet(1,15)

pT of leading offline JCCA jet (GeV)

• Main effect smearing turn-on is lack of primary vertex at L3

• QCD group has adjusted each L3 jet pT cut to the value at

which the relevant L1 trigger “reaches ~ 100% efficiency”: L1 Trigger Trigger Name Actual Rejection Estimated Rejection

CJT(2,3) jt_25tt 74075/2684 = 28 37

CJT(2,5) jt_45tt 41142/1889 = 22 38

CJT(3,5) jt_65tt 30391/1110 = 27 47

CJT(4,5) jt_95tt 8270/ 160 = 52 117

CJT(4,7) jt_125tt 1742/ 37 = 47 69

(run 149334)

• Calorimeter non-linearity corrections implemented in calorimeter unpacker for p11.06.00 (Marumi Kado)

• Killing of hot cells needed - Marumi Kado, Gregorio Bernardi are implementing offline NADA into L3

Running online since 17-Jan-2002

Example:mu1ptxatxx_CJT(1,3) + L3Tau (pT > 10 GeV)gives rejection factor ~ 5.5

Z QCD

L3FTauHadronic Level3 TauTool author: Gustaaf Brooijmans (Fermilab) current responsible: Yann Coadou (Upsala)

Based on calorimeter jet shape variables

Other tools on a longer timescale• cps and fps cluster finding and unpacking• missing ET

• tools to associate objects in different detectors (e.g. track to muon)

• b-tag: impact parameter, secondary vertex• tools to calculate "physics" quantities

– (e.g., inv. mass, delta_eta)• tools to identify physics event types

– (e.g., W, Z, stream definitions)– How to organise this? Hang W and Z script off each relevant L1/L2

bit? (limited number of L3 bits?)– Keep raw data on reco output of W/Z candidates?

Many opportunities for new people to get involved!

Level3 Requirements for certification of Code

•Fully tested on a Linux system. •Works "out of the box" (No private mods to code or RCP files)

•No crashes/memory leaks on samples of order 100K events: •real data and Monte Carlo.

•Timing studies •Performance studies/plots DOCUMENTED

•Efficiency, rejection, physics distributions these tests may run the tool singly, but:

•Must run on data with triggerlist exercising all released tools•The filter code must be tested, as well as associated tools. •Must test persistency of physics_results:

•Write out events. •Read back in to check physics distributions.

•Verification: run trigger simulator on real data and check that results agree with those obtained online.•Shadow nodes (in the future) to test new code ‘online’

L3 Monitoring• L3 filter statistics for each trigger available to shift

crew via daq_monitor• ‘physics_results’ for each tool written out on each

accepted event• debug_info• l3fanalyze program: produces rootuple

– Each tool must provide methods to fill rootuple– Used for offline checks of data quality– Plan to run online as ‘examine’ – use root to fill monitoring

histograms from rootuple– Extra person needed to work on this!

• L3 monitoring needs to get a lot more systematic and routine!

Can we do more sophisticated online monitoring in the L3 nodes?

• For example, collect histograms, measure efficiencies– L3 does a pretty complete reconstruction of the data

• Make use of the 90% of the events that we reject? – Measure trigger turn-on curves (for L1 and L2 as well as L3)– Do background studies– (Why write out events and have the huge overhead in having to run offline reconstruction and storing them permanently if they are needed for relatively simple operations that can be performed adequately in L3?)– Write out a stream with L3PhysicsResults and no raw data? Or a ‘not for reco’ stream?

• Best way to concatenate results from monitor processes running on each of the 100 L3 farm nodes not worked out yet.

Will require extra resources at L3, but the potential return (in terms of spotting trigger problems and in saving offline resources) might make this a very cost-effective investment.

This will also be the case if we find that lack of cpu power is limiting the sophistication of the event reconstruction and/or filtering that is possible in L3.

L3 central infrastructure: opportunities for new people to get involved

• Scriptrunner + central L3 code infrastructure, release management

• Monitoring/Quality control:– quality control macros – migration to online – "bit-wise" on/offline check – matching L3 objects to MC/L1/L2/reco objects

• Calibration/alignment technical infrastructure • L3RhysicsResults on thumbnail• Development of "user" and "physics analysis" tools

Conclusions, outlook.• Currently factor ~ 5 rejection needed at L3

• Calorimeter-based filtering (jets, electrons, taus) only

• Next steps (p11.06 release):

• Commission muons, tracking, primary vertex, NADA

• Get more systematic monitoring for L3

• When L2 turns on we’ll still need factor ~ 5 rejection at L3, but will have to work harder to achieve it!

• When Tevatron/L1 track and calorimeter triggers/DAQ all turn on we’ll need a much larger rejection factor!

• Lots of interesting challenges and lots of scope for clever ideas in the months ahead!

To find out more:

• L3 Algorithms web-pages:http://www-d0.fnal.gov/computing/algorithms/level3/home.html

• L3 Algorithms working group meetingstake place every week, Wednesday 14:00-15:30 in the Farside • Talk to Dan Claes (dclaes@unlhep.unl.edu) or

Terry Wyatt (twyatt@fnal.gov) about the opportunities to get involved!