june1 2020 garsoft - indico.fnal.gov · 7 june 1, 2020tom junk | garsoft tracking raw hits viewed...

GArSoft Tracking ProgressTom JunkMPD MeetingJune 1, 2020

Summary of Updates• Address split tracks in GArSoft- Vector Hit Finder line fit upgrade to PCA- Added a cut around the ROC gaps for TPC Clusters

• Bugfix in the CompressedHitFinder (Thanks, Leo!)• Added a Vee-finder module to GArSoft for identifying Kshorts

and Lambdas using Susan Born's selection requirements• Attended the ACTS workshop (suggested by Vivek).

June 1, 2020 Tom Junk | GArSoft Tracking 2

Vector-Hit Finder Upgrade• I had seen in the event display that vector hits (short, linear

track segments) would not always point along the string of hits.• Causes track splitting. A vector hit locally points in the wrong

direction.• Old line-fit algorithm: Do six fits (y vs x), (z vs x), (z vs y), (x vs

y), (y vs z), (x vs z) and pick the ones where the "independent" variable has the biggest range. Not very robust.

• New algorithm – use Principal Components Analysis. Requires diagonalizing a 3x3 matrix but ROOT's tools are quick.

• Anecdotally looks better on the event display


Example with Too-Short Vector Hits


Actually made with the PCA algorithm, but it happens much less often now.

Example with Better Vector Hits


Pad rows are visible in the upper left. They are in the OOROC and so are farther apartPerhaps my dX cut of 0.5mm on TPC cluster length is too tight.

Mitigation Strategies• Bigger windows for TPC Cluster finding – coalesce nearby hits into better-measured

average clusters

• I did this with the TPC-cluster resolution plots made for the last collaboration meeting. Expanded the averaging out to 5 cm (default is 1 cm in Y,Z and 5 mm in X) Got fewer TPC clusters but they were better measured when isolated. Need to retune nhits cuts after clustering differently.

• The X cut is probably too small – longitudinal diffusion has a sigma of 3 mm at 250 cm drift. Charge is detectable out to a couple of sigma, so that's 12mm – 2-3 TPC clusters expected to be strung out in X for each true deposit.

• Drawback of increasing these distances: Very short tracks at the primary vertex may get absorbed into their neighbors.

• ROC-dependent TPC cluster parameters – look a fixed number of pads away, not a fixed distance. Diffusion is constant over chamber face, but pad size is not.

• Could require longer vector hits

• Could iterate. First stage of track finding/fitting uses coarse clusters. Refine TPC clusters in dense tracking environments.


Gaps between ROCs• Further investigation into split tracks showed that they were

being broken along the boundaries between ROCs.


Raw hits viewedend on (no clustering).

No pads where thereare cover electrodes.

Charge hitting coverelectrode is notdetected.

Centroid of what's leftis pushed awayfrom the gap.

Caused vector hits notto point at each other.

Added a Cut on TPC Clusters Near Cracks• Cut away TPC clusters 5 cm away from the center of the gaps.- probably a little aggressive: First anode wire is ~1 cm away from

the center of the gap, and my cluster width cut is 1 cm. Tightened to 3 cm on Friday.

- need to add a cut between IROC and OROC – additional cracks there, but they are smaller. Also between CROC and IROC.

- cut is on TPC cluster position, not hit position.- Cut needs to be on TPC cluster position at the ROC. Eventually,

we'll need a Lorentz-angle-corrected TPC cluster position due to the radial component of B. But that's a later stage.

• Possible refinement – fit a Gaussian to the visible charge distribution, allowing for some of it to be missing. Currently we just take the centroid.


Bugfix to Hit Finder• Leo had spotted that true energy deposits were not showing up

as hits.• Found that the hit splitter in CompressedHitFinder_module.cc

was not writing the last hit in a string of several split ones in a waveform snippet.

• Sometimes that last hit is the only one!• Fix à 20 to 30% more hits on a small sample of simulated

neutrino events. Expect charge and position resolutions to improve.


K0s Finder Added to GArSoft Reco

• I was encouraged by the good work Susan Born did. Kaon mass peak looks good, and efficiency was high! 57% without requiring exactly two tracks in a vertex.

• Alan had said that the reconstruction needed to address this. We had written track info out to AnaTrees and the Kshort analysis could be done with the tracks.

• But it still makes sense to take Susan's Kshort selection and put it into the reconstruction path as Kshorts ID may be valuable in later recostages (not just analysis)

• For example, we know that the particles in Kshort decay are charged pions. May take advantage of that in predicting energy loss vs momentum.

• Drawback – to try out new cuts, one has to rerun reco. Or develop algorithms at the ntuple analysis level and port them back into reco.


New Data Product: Vee• Similar to Vertex, but contains a little more information- position, timestamp, four-momentum (TLorentzVector)- two tracks assumed- The four-momentum depends on the mass hypothesis for the two

tracks (one Kshort hypothesis and two Lambda hypotheses)• π+ π -

• p π -

• π - p

• Storage of Vee information added to AnaTree


Vee Selection• Based on Susan Born's work- Two tracks per vee (but no requirement on tracks per event)- Track length cut – each 100 TPC clusters- Momentum cut: 100 MeV per track- Opening angle cut -- angle must exceed 0.1 radians- No vertex requirement, but two tracks must pass within 1 cm of a

common point extrapolated linearly from their ends (can be made better if ends are far apart).


Test with a Kaon Bomb (single particle gun)

• 200 MeV isotropic kaons, generated in a cylinder of radius 250 cm and half-length of 250 cm. Ran 10000 events.


Some distributions oftrue MC Kshort decay points

Had a few more Kshorts in theMCParticles than generated –could be GEANT4 made anotherMCParticle after aninelastic scatter on 14/10000events.

Fiducial/Total = 40%Br(Kà π+ π -)= 69%

Reco Kaon Bomb Distributions


Matchedvee-findingefficiency=1308/2755=47%

cf. Susan's58%. I hadan extra openingangle cut,and a differentsample.

More Realistic Kaon Production• Susan explored this too.• Kaons are produced in neutrino scatters and not just particle

guns.• Colliders can get away with looking for vertices displaced from

the primary vertex. Usually the beam position is well known, at least in two dimensions.

• Neutrino scatters look like displaced vertices.• All pairs of tracks coming from a neutrino scatter are Kshort

candidates if we don't do something about it.• Doing something about it: Require another track that passes

close by but isn't part of the Vee. Code is in place but need a big enough sample of neutrino interactions to test it on.


Why You Need Another Track


With µ misid'd as a π, this lookslike a Lambda and if the p is misid'das a π, it is a Kshort candidate.

µ-

p

𝝂

𝝂µCC

Kshortπ+

π -

Possibly no primary vertex – maybejust one track sometimes.

µ+

n

𝝂

𝝂µCC DIS

Some To-Do's on the Vee Finder• Require oppositely-charged tracks (charge of a track depends

on which end we're looking at. Method exists; Thanks Leo!)• Identify the Lambda hypotheses by charge. Lambda vs.

Lambdabar hypotheses can be labeled (is the pion positive ornegative? The Proton?). We probably have almost zero Lambdabar's in the sample, so this can be cut on too.

• Have a minimum cut on opening angle. A maximum cut might be of use. Or a diagonal cut in mass and opening angle.


Low-momentum Kshort decay, or is it an elastic scatter? May have to look at theother ends of the tracks.

ACTS Tracking Package• On Vivek's suggestion, I looked at ACTS: "A Common Tracking

Software"- https://arxiv.org/abs/1910.03128- https://gitlab.cern.ch/acts

Migrated to GitHub last month:- https://github.com/acts-project/acts

• And I attended the first day of the ACTS workshop last week:https://indico.cern.ch/event/917970/timetable/?view=standard


https://arxiv.org/abs/1910.03128

https://gitlab.cern.ch/acts

https://github.com/acts-project/acts

https://indico.cern.ch/event/917970/timetable/%3Fview=standard

My Impressions of ACTS• Looks like a new (ish) project – got started a couple of years

ago.• Code is "fresh" and modern. (C++17) A good thing!• Contains geometry interface (more on this later), Track fitter

(Kalman Filter), vertexing• Designed to be generic so one can apply it to more than just

one detector (tracking software tends to be tied very specifically to a particular detector's geometry and quirks).

• Most developers have an ATLAS predisposition• Designed to be fast – with HL-LHC coming, ATLAS tracking

CPU usage will grow faster than linearly with pileup vertex count. Parallelism (multithreads) and GPUs/FPGAs are in their targets. Better to build this in from the get-go than to retrofit.


My Impressions of ACTS• It has a lot of features, but...• It relies on "Sensitive Surfaces". Tracks are extrapolated to

measurement surfaces – silicon layers, wire layers, pad rows, something with a known position in at least one dimension.

• Measurements are made on these surfaces and have uncertainties in 2D.

• Tracking works best when tracks travel through the surfaces and not parallel to them.

• Not all detectors are like this. TPCs in particular are inherently 3D (when read out as such).

• Attempts to extend ACTS to TPCs have invovled defining many artificial surfaces extending through the tracking volume (see the sPHENIX talk for example).


My Impressions of ACTS• sPHENIX and FASER had problems with tails on the

momentum residual distribution – added as a high-priority action item.

• Fabian Klimpel gave a talk (I missed it in person) on extending ACTS to include surface-free tracking. Mostly a to-do list.

• We might be able to steal vertexing code from ACTS. Or use it as is once some of the work is done to generalize it. Or contribute!

• GPU/multithreading may be solving a problem we don't (yet) have. Tracking just takes a few seconds/event in GArSoft.


From the ACTS Workshop Live NotesTPC/DC discussion:2 approaches: find closest approach then do either global kalmanfilter formalims, or do it in curvilinear coordinates after collapse onto curvilinear coordinatesFreeParameter tracking will be used as an extension (for gaseous detectors). The surface-based tracking is still the fundamental approach (necessary for Alignment etc.).AI: check with ALICE how this is doneTony: move space points onto cylinder, does this help?> Follow up by Andi


june1 2020 garsoft - indico.fnal.gov · 7 june 1, 2020tom junk | garsoft tracking raw hits viewed...

Documents