Sie sind auf Seite 1von 19

Olivier Callot

27 January 2012

Fast Pixel pattern recognition


General
Data

strategy

Geometry

organisation Code and tricks


Comments

on software

Context
Wenbin

had implemented a first version

It gives very promising results in terms of efficiency and ghost rates, measured on high mu events
99.5

% efficiency 2.2 % ghost rate

But more work is needed


~10%

clone rate ~53 ms per event !!!!


I

started to work on it in the first days of 2012

Understand the geometry and the features Get digitized events (no standard Digi tapes with MC truth!) Understand the pattern Tune it Make it fast and efficient

Olivier Callot Recent developments in Pattern recognition 20 January 2012 2

Geometry
48

sensors with 12 chips each

6 chips (3x2) at one z, 6 other at a different z Each chip is 256x256 pixels Clustered 2x2 by TELL40

The rest is similar: right and left sensors at different z with overlap and RF foil.
Recent developments in Pattern recognition 20 January 2012 3

Olivier Callot

Can

we use the DetectorElement ?

NO as it is too slow ! No need to apply a matrix operation to transform local to global coordinates
A

chip is flat enough so that one can make a linear approximation


X = x0 + ax * row + bx * column Y = y0 + ay * row + by * column Z = z0 + az * row + bz * column

No need to handle the first and last row/columns separately


The

pixel size is (as far as I understood) different, but for the pattern this is irrelevant. Compute the parameters using pixel 1,1 and 254,254 and extrpolate to 0 and 255

Cluster size not used so far


Re-clusterization

needed as TELL40 wont do it


27 January 2012 4

Olivier Callot

Fast Pixel patter recognition

Hit preparation
First

convert the raw data to space position

A cluster is: sensor number, chip number, row and column in chip. Process the geometry once to get a parameterisation of the x,y,z position of each pixel
9

parameters per chip, 12 chips per sensor, 48 sensors


Manageable data volume In a dedicated sensor object.

Update

the geometry of the detector moves, i.e. opening position

Set PatPixelHit objects using a tool to manage the memory


to PatVelo, FastVelo, No new operator Hits organised per sensor Sorted by x coordinate at the end of the decoding.
Similar

This

takes 0.11 ms
Recent developments in Pattern recognition 20 January 2012 5

Wenbin was using standard tools 1.70 ms

Olivier Callot

Main loop
The

standard (strip) code makes quadruplets

This is the basic RZ tracking, the only one in HLT 4 consecutive sensors, same side, same (angular) zone
Then

allow one missing sensor, still with 4 hits (in 5 sensors)

Here

we have directly space point measurements

We can be less strong in our requirements In other words, we can take only 2 points, this gives already 4 coordinates
Loop

on all sensors starting from highest Z

Take the next sensor on the same side Iterate on all pairs of hits Extend this pair up- and downstream, allowing missing sensors.
Olivier Callot Recent developments in Pattern recognition 20 January 2012 6

To

make the loop fast:

Hits are sorted by x in each sensor. Loop on the hits in the first sensor
Loop

on the hits in the second sensor, start at the previous hit compatible with the previous hit of the first sensor.
A hit at a too low x cant be used when the first sensor hit is at higher x
Loop

is aborted as soon as a track is found or as soon as we are outside the allowed x range for this first Sensor 0

Sensor 1

After the red hit, restart here for the green one
Olivier Callot Recent developments in Pattern recognition 7

20 January 2012

Some

constraints are applied:

Hits must not be already used


Define

used as being on tracks with more than 3 hits as there are some ghosts at this level. concept of pointing to the vertex area

The pair must have a direction within 400 (x) and 300(y) mrad
No

For backward tracks, be more strict.


Backward

is defined as

z of the seed sensor < 200 mm and zClosestToBeam at higher z than the first hit
We

need only the pointing tracks (PV use only)

Ask for R-at-beam < 1 mm

Olivier Callot

Fast Pixel patter recognition

27 January 2012

The

pair is extrapolated
the closest hit in the next sensor same side.
Distance to expected x position less than150 micrometers 2 should be less than 100 (this is the test in y also) Double these tolerances if the Z distance to the previous hit is more than 100 mm, as extrapolation is inaccurate

First towards lower z


Find

Use

a binary search to find the first hit at xExpected 150 um

Olivier Callot

Recent developments in Pattern recognition

20 January 2012

What

is a binary search ?

Time is proportional to log2 of the multiplicity Useful when multiplicity is greater than ~10

Olivier Callot

Fast Pixel patter recognition

27 January 2012

10

The

pair is extrapolated
the closest hit in the next sensor same side.
Distance to expected x position less than150 micrometers 2 should be less than 100 (this is the test in y also) Double these tolerances if the Z distance to the previous hit is more than 100 mm, as extrapolation is inaccurate

First towards lower z


Find

Use If

a binary search to find the first hit at xExpected 150 um

Fast, limited dependency on the occupancy

not found in a sensor of the same side, start to look at the other side sensors also.
Tracks can cross the boundary But at least 2 hits should be on the same side

Stop

when 5 sensor numbers have been missed

Count 2 for each sensor missed when working only on one side.

Then extrapolate to higher z, skipping the previous station


It

would have been found earlier!

Olivier Callot

Recent developments in Pattern recognition

20 January 2012

11

Final

fit to remove bad measurements

Remove iteratively the worse hit if 2 higher than 16.

Extra

hits on the same sensors are added


must be less than 16.

This is essentially the next hit on the list, as the hits are sorted in x
2

This handles the overlap between chips But there is a problem for wide clusters, i.e. more than 2 pixels in one direction
Currently A

this is making 2 clusters, typically 2 pitches apart

This is not good: The second cluster is at 2*12 sigma = 6.9 sigmas

better clustering is needed


More than 2x2 Detection of track-in-a-wafer and clean them
Long series of pixels making a line

Olivier Callot

Recent developments in Pattern recognition

20 January 2012

12

Filter

short tracks, with only 3 hits

Should be on 3 different sensors Should be all 3 unused 2 per DoF should be less than 6.
Filter

also on longer tracks

At least 60% of the hits should be unused


Problems

when some hits are not too well aligned. They can be removed, and then free to do a second track with all by the 2 seed hits already used

Hits are now tagged as used.

Tracks

are stored at the end, when all are found.

The check of all 3 hits unused on 3 cluster tracks is applied again, to be order independent.

Olivier Callot

Fast Pixel patter recognition

27 January 2012

13

Tooling of the pattern code


For

this code (PatPixel) as for FastVelo, PatXXX

One can selectively debug the processing of a given MC particle. Print statements are triggered by the hit belonging to the MC particle
No

cost (test a bool !) when the debug option is not set

A debug tool should be specified for the MC truth match.

There

is an algorithm to list missed MC particles

List MCParticles not reconstructed, or having multiple tracks (clones) Can also print the ghosts, with their MC hit association, and then debug the processing of these hits as indicated earlier
This
Olivier Callot

tooling is a must to understand the pattern!


Recent developments in Pattern recognition 20 January 2012 14

Performance of PatPixel
Measured

on 900 simulated events

2 1033 conditions, mu~4, i.e. difficult! In average 150 tracks reconstructed per event

Ghost rate = 0.9

(standard LHCb, mu=1.5 : ~6% ) 99.0% with 1.2% clones

Efficiency long tracks : Efficiency long tracks over 5 GeV:

99.7% with 0.5% clones

Hit efficiency 98.44%, hit purity 99.93%


Time per event :
0.11

1.12 ms

data preparation, 0.80 tracking, 0.21 conversion to LHCb::Track This last conversion is NOT needed in HLT1, and probably also offline. One could (should) work without new / delete for tracks
We dont by expensive CPU for memory management!
Olivier Callot Recent developments in Pattern recognition 20 January 2012 15

Comments on software

I had a look at the detector element and some tools

We

should follow the LHCb coding conventions !

Name rules. Coding rules.


Several

versions of the layout are available

We should remove obsolete tests, i.e. non square pixels, if they are obsolete.

Do

not just copy what existed


The

No need for any half box geometry


pixel gives directly a space point, in the LHCb frame.

Olivier Callot

Fast Pixel patter recognition

27 January 2012

16

Some

information is missing for pattern

Overall sensor boundaries Central hole size


Performance

is important

30 MHz event processing is a challenge Make sure the code is appropriate


Avoid

memory management if not absolutely needed A vector implies a new to get space to store it, and a delete later, which are not visible in the code !
Management

is important

A clear responsible, with whom one can discuss Regular meetings to track progresses and milestones
A

nice place to attract people to contribute

Knowledge sharing is vital.


Some

people will retire before the project is running


Fast Pixel patter recognition 27 January 2012 17

Olivier Callot

Summary
The

Pixel tracks can be reconstructed

In a FAST way, around 1 ms per event Very efficiently, over 99.5% With very few bad guys
Ghosts

are in fact not always real ghosts, but tracks made with a mother and daughter inside the Velo

The

code is available

But the clustering should be implemented


No

linger a clustering done in TELL40 Handling of wide clusters, of track-in-the-wafer

It can and will certainly be improved


Data

model to be improved for HLT usage.

Olivier Callot

Fast Pixel patter recognition

27 January 2012

18

Software

effort to be coordinated

Clean-up of not-needed legacy Strict adhesion to LHCb standards


And

improve them if you feel this can help

Start a team for knowledge sharing


Some

people will retire Dont re-invent the wheel

And

also try to make a working reconstruction for the strip option


Need simulation, new detector element, handling of more zones in the sensors,
In

principle easy, but has to be tried to measure what could be obtained, with all our current expertise with this sort of detector, at high luminosity.

Olivier Callot

Fast Pixel patter recognition

27 January 2012

19