L3 Algorithms: status and plans for the near future

1
L3 Algorithms status and plans for the near
future

• D? Trigger Workshop 22nd April 2002
• Dan Claes and Terry Wyatt.

2
Design
Time budget for L3 i/o, event building, filtering
? 100 nodes 10-3 s 0.1 s
Currently

3
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(?) gt 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

4
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

5
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

• 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)

6
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)

7
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)

8
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 gt30 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)

9
Memory Leaks
10
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

11
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.)
12
Rejection measured on single muon test runs
central
forward
default parameters
tuned parameters
13
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 MarkPass)
• Optimise parameters
• Memory/timing efficiency/rejection

14
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

15
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

16
SMT Unpacking CFT Unpacking
Principal author Robert Illingworth (Imperial
College)

• 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!)

17
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)

18
Current L3 global tracking performance
track ? (rad)
z at dca (cm)
CFT only
Number of axial hits on track
Number of stereo hits on track
19
Comparison of L3 and offline tracking
number of tracks
track ? (rad)
q/pT (GeV-1)
dca (cm)
20
A possible stand-alone track-based filter

• Require at least one track with pT gt cut
• Try out on events with single muon triggers

Efficiency (events with tight offline muon with
pTgt3.0)
Rejection factor (all events)
At 50 efficiency, rejection of 25
Rejection vs. Efficiency
21
Timing for global track tool
Time per event (ms) On d0mino (debug version)
about 30 ms per event for unpack tools
22
CFT Tracking Algorithm - L3TCFTTracker
Principal author Ray Beuselink (IMPERIAL)
P11 tool certification Robert Illingworth and
Chris Barnes

23
A possible plan for filtering on
single muon triggers
We could require an .OR. of

• 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 dont 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)

24
L3 Primary Vertex needed soon!
1) Histogram technique using SMT hits
author Guilherme Lima (UERJ/Brazil)
Has yet to be tested on REAL DATA Opportunity for
new person to get involved!
2) L3TVertexFinder Track-based vertexing tool
author 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.
25
L3TEle Electron Tool authors Volker
Buescher (Mainz) Ulla
Blumenschein (Mainz)

• Current filter
• simple 0.25 cone
• applying cuts on
• ET
• e.m. fraction (gt0.9)
• transverse shower shape
• ?,? energy weighted cluster axis
  position

26
Electron efficiency in WH?e?bb Monte Carlo events
pT electron (GeV)
Rejection in CEM(1,5) data events
Events rejected by pt cut e.m. fraction shower
shape electron candidates
pT electron (GeV)
27
Cuts on transverse shower shape
Cut recommended by L3 group Cut accepted
by trigger board
28
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 gt 15 GeV, emfrac gt 0.9
• pT gt 12 GeV, emfrac gt 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

29
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)
30
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?

31
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 Sept01

32
e.g., Fraction of events passing L3FJet(1,15)
DATA runs 142871-142874
pT of leading offline JCCA jet (GeV)

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

33

• 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

34
L3FTauHadronic Level3 TauTool
author Gustaaf Brooijmans (Fermilab) current
responsible Yann Coadou (Upsala)
QCD
Z???
Based on calorimeter jet shape variables
Running online since 17-Jan-2002 Example mu1ptxa
txx_CJT(1,3) L3Tau (pT gt 10 GeV) gives
rejection factor 5.5
35
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!

36

• 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

37
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!

38
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.

39
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.
40
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

41
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 well 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 well need a much larger
  rejection factor!
• Lots of interesting challenges and lots of scope
  for clever ideas in the months ahead!

42
To find out more

• L3 Algorithms web-pages
• http//www-d0.fnal.gov/computing/algorithms/level3
  /home.html
• L3 Algorithms working group meetings
• take place every week, Wednesday 1400-1530 in
  the Farside
• Talk to Dan Claes (dclaes_at_unlhep.unl.edu) or
  Terry Wyatt (twyatt_at_fnal.gov)
• about the opportunities to get involved!