# Presentation: 893535

## L3 Algorithms: status and plans for the near future

- D**** Trigger Workshop:  22nd April 2002
- Dan Claes and Terry Wyatt.

## Design:

- _Currently:_

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

## L3TMuon     (local muon track reconstruction)

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

- default
- parameters

- 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

## SMT Unpacking

- 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 Unpacking**_
_**CFT 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**

- CFT
- only

**Number of stereo hits on track**

## Comparison of L3 and offline tracking

**     ****number of tracks****                                       ****track ******** (rad)**

**q/p****T****   (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 with**
**tight offline **
**muon**
**with p****T****>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:**

***author: ******Guilherme Lima****** *****(****UERJ/Brazil****)**

_*Has yet to be tested on REAL DATA*_
*Opportunity for new person to get involved!*

_**1) Histogram technique using SMT hits**_

_**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.*
***	******	***

## L3TEle  Electron Tool 

***     ******authors: ******Volker Buescher****** *****(****Mainz****)**
***                    ******Ulla Blumenschein*** (**Mainz**)

- Current filter:
-  simple 0.25 cone
-  applying cuts on
** ****E****T**
** ****e.m. fraction (>0.9)**
** ****transverse shower shape**
***            ************,************ : energy weighted cluster axis position***

**Electron**
**efficiency in**
**WH********e********bb**
**Monte Carlo**
**events**

**Rejection in**
**CEM(1,5)**
**data events**

- Events rejected by:
- pt cut
- e.m. fraction
- shower shape
- electron candidates

**p****T ****electron (GeV)**

**p****T ****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

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

##    which the relevant L1 trigger “reaches ~ 100% efficiency”: 

-    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.](http://www-d0.fnal.gov/computing/algorithms/level3/home.html)__[fnal](http://www-d0.fnal.gov/computing/algorithms/level3/home.html)__[.](http://www-d0.fnal.gov/computing/algorithms/level3/home.html)__[gov](http://www-d0.fnal.gov/computing/algorithms/level3/home.html)__[/computing/algorithms/level3/home.html](http://www-d0.fnal.gov/computing/algorithms/level3/home.html)_
- L3 Algorithms working group meetings
- take place every week, Wednesday 14:00-15:30 in the Farside
- Talk to Dan Claes (dclaes@unlhep.unl.edu) or Terry Wyatt (_[twyatt](mailto:twyatt@fnal.gov)__[@](mailto:twyatt@fnal.gov)__[fnal](mailto:twyatt@fnal.gov)__[.](mailto:twyatt@fnal.gov)__[gov](mailto:twyatt@fnal.gov)_)
-    about the opportunities to get involved!