1. 1 T1-T3 in L1 algorithm  Idea (F. Teubert) Use extra tracking information to measure the large Pt that triggers the event (L1, HLT). Based in the fact that most of “fake” triggers in L1 are due to bad Pt assignment using TT.  Scenarios: L1 confirmation  Measure Pt of some large IP tracks with TT & T1-T3 in L1 L1 upgrade  Redo L1 algorithm as the 1 st step in L1 using TT & T1-T3 (A question of time and money) T1-T3 in L1 algorithm Status Report Jose A. Hernando (2/2/04)

2. 2 Status Report: T1-T3 in L1 algorithm  Previous study (Zurich 11/03) Using HltLongTracking L1 confirmation  Loose 5% in signal efficiency and reducing the output to 20 KHz  After l1Conf (rough) ~70 ms/event in HLT L1 upgrade  Gain in 1.4 factor in the signal efficiency at the same L1 output 40 KHz.  We only need to track 6 (maybe 4) tracks  Rough time estimation it is 8 ms extra in L1 Long tracks are better than Velo-TT tracks  Current Study The changes New trigger code structure  Rewrite and validate the “new” code Should run in L1 and Raw buffers  And if possible in TDR data Some “minor” bugs in old code  (100 um cutoff in vertex search) The questions Using new trigger structure  Confirm previous results How much extra tracking information do we need?  T1 and T3 only or a fraction of them? Better time estimates

3. 3 From Zurich: L1 confirmation (or) 1 st step of HLT  We L1 confirmation : We can reduce the rate to 20 KHz we with a cost ~5% efficiency  Rough time estimations (1 GHz PIII) Redo some L1 calculation  ~ 6 ms Do the full tacking of some candidates  ~9 ms Current HLT time budget  50 ms If we reduce the rate by ½ each L1- confirmed event will have  ~35 ms reconstruction  ~35 ms HLT decision Efficiency (after L1) vs Output rate

4. 4 From Zurich: L1 upgrade, efficiency vs retention  Comparison between current L1 and upgrade L1 We gain a factor 1.3-1.4 for the hadronic channels B( ,  ) we go from ~62% to ~84% We did not include here the muons channels, (L1 upgrade would have M2- M5 and eff. will be even better)  Rough time estimation Current L1 takes 8 ms Full tracking could add 8.4 ms  8.5 average Velo-TT candidates IP If we track less candidates we can reduce time Efficiency (after L0) vs Output rate

5. 5 From Zurich: L1 upgrade, # tracks to be confirmed  How many Velo-TT tracks do we need to confirm (to match and track in T1-T3)? Order the tracks candidates (IP window) by decreasing Pt Match/track only the n-first  (n= 2,4,6)  With only need to track 4-6 Velo-TT tracks to get almost the full performance. So the long tracking could cost 4-6 ms  50%-80% of the L1 current time  50% more CPU’s for L1?  Do we need T1-T3, can we confirm tracks with only T2, or only T1&T3? we do not know yet, work in progress (structure of the tracking code) B( ,  ) efficiency (L1 upgrade) vs Output rate

6. 6 Towards new tracking working code  Approach (metamorphosis) Start from HltLongTrack package (O. Callot + N. Arnaud) Modify step by steps but keeping it alive (working)  The changes in the “Forward” reconstruction Use of TrgTrack and TrgState, and the new TrgProviders Link with MC via channelID Separate tracking from hit allocation A specific Tool to forward track a single track candidate geo Hits Tracks (Forward) ForwardTrackAlg HitCreator IT/OT Clusters Planes Tracks (TT) Tracks ForwardTrackTool Track geo L1Buffer geo RawBuffer Different versions of the algorithm L1-Raw(HLT) buffer, or TDR-DaVinci Common part for TT only Use TrgTracks as Input/Output It calls the Forward tracking tool It does clone killing HitCreator Planes Hits Planes

7. 7 Status of new tracking working code  Status Hit Creator from IT/OT clusters (TDR-DaVinci data)  In future L1 and Raw buffers Forward Tracking Algorithm and Tool are working  Maybe I did no break anything!  Still some minor clean-up Both algorithms will need extra clean up in a future.  Discussion with Callo, and my presentation in Amsterdam The code it is almost a butterfly (but still in cocoon state) Velo tracks (left) & Forward Tracks (right) Before (up) and after (below) restructure of the code 150 minbias event (before L0)

8. 8 Pattern-search histogram  Patter Recognition Forward Tracking (somehow)  Using input direction & q/p  Define a z-plane ref and a x window (depending on p)  Project x-hits onto that plane histogram: Callo’s (or pattern-search) histo  Use the histo-peaks as tracks seeds  Plan: Investigate how the patter-search histo behaves with less stations Use as reference DsK, and B(pi,pi) channels  Where are the 2 largest pt tracks from the signal? I can run the tracking finding tool only with the hits of the MCParticle! A minbias event Tracks ordered by Pt (velo-TT) Callo’s (pattern-search) histogram

9. 9 Conclusion and plans  Status Forward tracking, based in the code of Ollivier’s it is working in the new structure  Some minor changes needed.  Other changes in the future, but not immediately. Timers are in place.  with my histo/ntuple gaudies… to be replace by the new Gaudi algorithm. Investigating the “possible” degradation of the track patter-search histogram with less stations  Plans Recheck that the “new” tracking code it is working With Lausanne: L1 decision algorithm implementation (we can both use it) Validate the previous results  I sent some jobs over the weekend but.. they crashed.. A memory leak at my age!! Investigate the patter-search histogram with less stations.  We will still see the peak?  We need to invent another method?