GArSoft Update: Hits and Tracks Tom Junk HPGTPC Meeting July 13, - - PowerPoint PPT Presentation

GArSoft Update: Hits and Tracks

Tom Junk HPGTPC Meeting July 13, 2018

Two Zooms on a GENIE veCC Event in the Middle of the Detector

July 13, 2018 Tom Junk | GArSoft Update 2

Hits are located at the pad (y,z) locations, and arrival time gives x. Grid pattern noticeable on tracks. Distribution in x is much narrower Hit-finder is a simple threshold algorithm

From June 22: Track Finder and Fitter

• Start with Hits à Make Tracks
• Pattern Recognition Step: Want homogeneity and isotropy
• Sort hits in X (drift direction = E field direction – B field direction)
• Loop over sorted hits. Add hits to tracks if hit is near the last one

added to that tracks. Make a new track if hit is too far from any track in the list

• Rather naive – follows kinks, may have delayed split, may get

confused by delta rays

• Extended Kalman filter track fitter
• Initial version included in tracker1_module.cc
• Five track parameters – as a function of x, have (y, z, curvature, phi,

slope)

July 13, 2018 Tom Junk | GArSoft Update 3

Tracker To-Do from June 22

• Fit tracks in both directions. In a collider, we know which way the

tracks go. Here, not so much.

• Add parameters evaluated at both ends or along the way to the track

data product. Add track-hit associations.

• Look at displaying tracks in the event display
• Cluster hits into "clusters" a la ALICE. Diffusion spreads out charge

among many pads. Clusters are easier to track than pad hits.

• Improve pattern recognition
• Start new tracks if angle changes too much – especially important near

primary vertex

• Prune delta rays.
• Deal with very low Pt curlers (are they really straight or corkscrews?)

July 13, 2018 Tom Junk | GArSoft Update 4

Initial Try at Pattern Recognition

July 13, 2018 Tom Junk | GArSoft Update 5

GArSoft's event display draws tracks by drawing associated hits in different colors. No concept of helical track parameters in the event display (tracks in unmagnetized LAr are just collections of hits) Initial tracker does not add

• r subtract hits, just runs

Kalman filter, and so evd just shows pattern-recognition step output. Not too bad, but the pair of close tracks gets split a lot Curves are MC truth. Colored dots are patrec-clustered hits.

Cluster Nearby Hits

• ALICE clusters charge depositions on nearby channels before

running tracking. Fewer objects to deal with, better resolution.

• I added a step to the compressed hit finder (which just takes the

zero-suppressed blocks and calls them "hits") by collecting together hits within 1 cm in x (along drift) and 5 cm in (y,z) (adjustable parameters), before creating hits for storage.

• Charge centroids, charge sums, and RMS updated with

component hits.

• Hits are now no longer associated with a channel (channel = 0

now).

• Could call the new objects "clusters" like ALICE, but there's

already a cluster data product in GArSoft (we're not using it yet).

• Hit clustering is switchable via fcl parameter

July 13, 2018 Tom Junk | GArSoft Update 6

Patrec on First Event with Clustered Hits

• Much better!

July 13, 2018 Tom Junk | GArSoft Update 7

Curves are MC truth. Colored dots are patrec-clustered hits. Two views of the same event

Still Not Perfect Near Vertex

July 13, 2018 Tom Junk | GArSoft Update 8

Zoomed further in. The green cluster

• verstays its welcome.

It extends into the blue, purple, and yellow tracks, and continues along red and purple. Pattern recognition is a little too forgiving when tracks kink Also anisotropic – hits are sorted in x and stepped in just one direction

Patrec Improvements

• Address anisotropy and over-greediness of clusterer:
• cluster in both directions in x
• Look for disjoint subsets shared by both clusterings.
• If a cluster is split in one direction and not the other, split it.
• Now makes short clusters – to work on putting these back together!
• Need to check the fitter first as extrapolating tracks to add hits

requires precise track parameter measurements.

• Track fitter has a minimum number of hits requirement
• Should be a multi-stage approach: Find long, easy tracks first. Assign

hits to them in crowded environments. Find vertex and use as a constraint if necessary.

• Look for short tracks using remaining hits.

July 13, 2018 Tom Junk | GArSoft Update 9

Fitting Tracks

• No event display of helical track parameters (yet).
• 10 bars of gas à multiple scattering and energy loss are

important.

• Drawing a helix on top of hits will miss the points even when the

parameters are correct at the end.

• Which end?
• Quote both! Kalman filter

is the right tool as it gives track parameters at the end. Need to fit each track twice

• though. Maybe start with a single

helix fit?

• My own hacky track/hit display

made from text dumps

July 13, 2018 Tom Junk | GArSoft Update 10

x, y, and z are in cm

It didn't always work perfectly

July 13, 2018 Tom Junk | GArSoft Update 11

Curvature sign not correct

• n blue end.

Red end – curvature probably too big. I had some bugs in my initial track parameter guesses to start off the Kalman fit. Debugged but still not quite perfect, especially when the track kinks at one end I checked ALICE's circle-from-three-points method – works! But the curvature sign was ALICE-specific Tunable parameters in the fit: uncertainties on the measured hit positions, and extrapolation uncertainties from one step to the next. x, y, and z are in cm

Some Software Improvements

• I added a new TrackPar class to have a place for tracking

utilities

• Method for finding the distance from a point to a helix
• art data product design guide discourages adding lots of code to

the class definitions of data to be stored on disk and tape.

• I added a Vertex data product
• I added 64-bit timestamps to RawDigit, Track, Vertex, and

Cluster data products. Hit already has a time as a float (relative to some trigger). But tracks, clusters and vertices have their

• wn times.
• Near-term to do: write a vertex finder. Many examples from

colliders assume some prior knowledge of where a vertex can be.

July 13, 2018 Tom Junk | GArSoft Update 12

Particle Charge

• The charge of a particle depends on which way we propose it is

going!

• There's a two-fold ambiguity in how to specify track parameters

in a detector where the tracks can start from any direction and go in any direction.

• Need to assign a vertex first before one can assign a charge.
• Event may have a primary vertex and a secondary interaction,

making it at least a little ambiguous.

• To think about – develop tools to provide interpretations of the

event first.

July 13, 2018 Tom Junk | GArSoft Update 13

More Example Tracks

July 13, 2018 Tom Junk | GArSoft Update 14

x, y, and z are in cm