1

T1-T3 in L1 algorithm 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 1st step

in L1 using TT & T1-T3

(A question of time and money)

T1-T3 in L1 algorithm T1-T3 in L1 algorithm Status ReportStatus Report

Jose A. HernandoJose A. Hernando(2/2/04)(2/2/04)

2

Status Report: T1-T3 in L1 algorithm 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 KHzAfter 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 buffersAnd 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

From Zurich: L1 confirmation (or) 1From Zurich: L1 confirmation (or) 1stst step of HLT 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

From Zurich: L1 upgrade, efficiency vs retentionFrom 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 ms8.5 average Velo-TT candidates IP

• If we track less candidates we can reduce time

Efficiency (after L0) vs Output rate

5

From Zurich: L1 upgrade, # tracks to be confirmedFrom 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

Towards new tracking working codeTowards 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

Hits Tracks (Forward)ForwardTrackAlg

HitCreatorIT/OT ClustersPlanes

Tracks (TT)

Tracks ForwardTrackToolTrack

geoL1Buffer

geoRawBuffer

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

HitCreator

Planes

HitsPlanes

7

Status of new tracking working codeStatus 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

Pattern-search histogramPattern-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 eventTracks ordered by Pt (velo-TT)

Callo’s (pattern-search) histogram

9

Conclusion and plansConclusion 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?