2012-01-27 Fast Pixel Pattern Recognition

7/27/2019 2012-01-27 Fast Pixel Pattern Recognition

1/19

Olivier Callot

Fast Pixel pattern recognition

General strategyGeometry

Data organisationCode and tricks

Comments on software

27 January 2012


2/19

Olivier Callot

Context

Wenbin had implemented a first version It gives very promising results in terms of efficiency and ghostrates, 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 2012Understand 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

20 January 2012Recent developments in Pattern recognition 2


3/19

Olivier Callot

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 withoverlap and RF foil.



4/19

Olivier Callot

Can we use the DetectorElement ?NO as it is too slow !

No need to apply a matrix operation to transform local to globalcoordinates

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

X = x0 + ax * row + bx * column

Y = y0 + ay * row + by * columnZ = 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 it27 January 2012Fast Pixel patter recognition 4


5/19

Olivier Callot

Hit preparation

First convert the raw data to space positionA cluster is: sensor number, chip number, row and column in chip.

Process the geometry once to get a parameterisation of the x,y,zposition 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

Similar to PatVelo, FastVelo,

No new operator Hits organised per sensor

Sorted by x coordinate at the end of the decoding.

This takes 0.11 msWenbin was using standard tools 1.70 ms



6/19


7/19Olivier Callot

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

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 areoutside the allowed x range for this first


Sensor 0

Sensor 1

After the red hit, restart here for the green one


8/19Olivier Callot

Some constraints are applied:Hits must not be already used

Define used as being on tracks with more than 3 hits as there aresome ghosts at this level.

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

No concept of pointing to the vertex area

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

27 January 2012Fast Pixel patter recognition 8


9/19Olivier Callot

The pair is extrapolated First towards lower z

Find 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 than100 mm, as extrapolation is inaccurate

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



10/19Olivier Callot

What is a binary search ?

Time is proportional to log2 of the multiplicity

Useful when multiplicity is greater than ~10



11/19Olivier Callot

The pair is extrapolated First towards lower z

Find 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 than100 mm, as extrapolation is inaccurate

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

Fast, limited dependency on the occupancy

If not found in a sensor of the same side, start to look at the other sidesensors 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!



12/19Olivier Callot

Final fit to remove bad measurementsRemove iteratively the worse hit if2 higher than 16.

Extra hits on the same sensors are added This is essentially the next hit on the list, as the hits are sorted in x

2 must be less than 16.

This handles the overlap between chips

But there is a problem for wide clusters, i.e. more than 2 pixels inone direction

Currently this is making 2 clusters, typically 2 pitches apart

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

A better clustering is needed

More than 2x2

Detection of track-in-a-wafer and clean them

Long series of pixels making a line



13/19Olivier Callot

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 tracksAt least 60% of the hits should be unused

Problems when some hits are not too well aligned. They can beremoved, and then free to do a second track with all by the 2 seed hitsalready 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.



14/19Olivier Callot

Tooling of the pattern code

For this code (PatPixel) as for FastVelo, PatXXXOne can selectively debug the processing of a given MC particle.

Print statements are triggered by the hit belonging to the MCparticle

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 thendebug the processing of these hits as indicated earlier

This tooling is a must to understand the pattern!



15/19Olivier Callot

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% ) Efficiency long tracks : 99.0% with 1.2% clones

Efficiency long tracks over 5 GeV: 99.7% with 0.5% clonesHit efficiency 98.44%, hit purity 99.93%

Time per event : 1.12 ms 0.11 data preparation, 0.80 tracking, 0.21 conversion to LHCb::Track

This last conversion is NOT needed in HLT1, and probably alsooffline.

One could (should) work without new / delete for tracks

We dont by expensive CPU for memory management!20 January 2012Recent developments in Pattern recognition 15


16/19Olivier Callot

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 availableWe should remove obsolete tests, i.e. non square pixels, if they

are obsolete.

Do not just copy what existedNo need for any half box geometry

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



17/19


18/19Olivier 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.



19/19Oli i C ll t

Software effort to be coordinatedClean-up of not-needed legacy

Strict adhesion to LHCb standardsAnd 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 forthe strip option

Need simulation, new detector element, handling of more zones inthe 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, athigh luminosity.

Documents

2012-01-27 Fast Pixel Pattern Recognition