This is documentation for RT ticket #3353.
Any of the plots on this page can be opened in a new window/tab for a higher resolution view.

Following a lead from Shengli that he sees HFT tracks with BTOF hits in Run 16 dAu that have a nonsensical pseudorapidity, I looked for any signs of this myself in MuDsts from the DEV nightly tests. I looked at the Run 16 dAu ITTF, unoptimized sample and confirmed his observation.

I found two clear primary tracks in events 13 and 70 (where 0 is the first event), but there appear to be plenty more.

Here is the z position of the last point on the track vs. cosθ as defined by p_z/p for long (last point radius > 140 cm) primary tracks whose vertex is within 5 cm of z=0 for all events (nightly test processes 500 events), and then for just event 13 and event 70:

Black: no HFT, no BTOF
Green: no HFT, BTOF
Red: HFT, no BTOF
Blue: HFT, BTOF





The upper left and lower right quadrants of these plots should be empty!!! Clearly something is wrong when a track originating from near z=0 can have a significant positive p_z but end up exiting the TPC at large negative z!

It does appear that the outlying bands are all primary tracks with HFT (modulo a smaller class of tracks which I'll note later), but it isn't quite true that all tracks with HFT sit in the outlier bands.

Also, it appears that the outlier band shifts from one offset to another from event to event. To demonstrate this, below are several plots with groups of 20 events in each, where the color represents the event number within the group. Here I only show tracks with HFT hits, but no restriction on BTOF. One can clearly see the outlier bands have a uniform color indicating they are from one event.

Events 0 - 19 (contains event 13, which is hard to see because it is yellow), but there also appears to be another milder outlier event in red)		Events 60 - 79 (contains event 70)
Events 100 - 119 (no apparent outliers)		Events 120 - 139 (may contain two outlier events?)
Events 160 - 179 (random group)		Events 440 - 459 (random group)

Here is the same coloring by event, but for all events restricting to tracks with HFT (left) and without HFT (right). The outlier bands are predominantly in HFT tracks, but there is some other odd class of non-HFT tracks in the right plot that shows a different, more horizontal band which doesn't appear to correlate with events!




I can easily re-make the left (HFT tracks) plot above but using globals (it's harder to do for the non-HFT tracks plot because I'd have to figure out how to restrict to originating from a vertex near z=0 without using quantities I'm plotting, while for HFT globals the first point on the track is in a PXL layer that's not far from the primary vertex). Interestingly, the HFT globals do NOT have the outlier bands seen in the HFT primaries!



I will add some other observations about the primary tracks that I will not show in plots:

• I see no definitive dependence on which HFT layers (PXL1, PXL2, IST, SST) are included or excluded.
• Placing a cut on the minimum number of hits on the tracks makes little impact (most of these tracks have more than 30 hits).
• Optimized vs. unoptimized nightly tests show no difference.
• StiCA nightly test is not identical (there are different tracks and vertices, after all), but suffers the same issues.
• In the Run 16 AuAu200 nightlies, the smaller horizontal band non-HFT class is still there, but it's hard to say clearly if there are outlier bands for the HFT tracks. I only see about ~10 outlier tracks for 500 events, and they all seem to be from different events.

-Gene

_____

Useful MuDst quantities:

Vertex z cut: abs(PrimaryTracks.mFirstPoint.mX3)<5
BTOF requirement: PrimaryTracks.mBTofPidTraits.mPathLength>0
HFT requirement: (PrimaryTracks.mTopologyMap.mMap0&126)>0
PXL1 requirement: (PrimaryTracks.mTopologyMap.mMap0&2)==2
PXL2 requirement: (PrimaryTracks.mTopologyMap.mMap0&4)==4
IST requirement: (PrimaryTracks.mTopologyMap.mMap0&16)==16
SST requirement: (PrimaryTracks.mTopologyMap.mMap0&64)==64
Plotted quantity: PrimaryTracks.mLastPoint.mX3:PrimaryTracks.mP.mX3/sqrt(sq(PrimaryTracks.mP.mX1)+sq(PrimaryTracks.mP.mX2)+sq(PrimaryTracks.mP.mX3))

_____________________

Update 1:

I found 13 tracks from event 70 where I could easily match up the global track to the primary track. In so doing, I could compare the momentum component fractions: p_x/p, p_y/p, p_z/p for globals vs. primaries. One can see that it is only the z component which really gets impacted going to primary.

Red: p_x/p
Black: p_y/p
Blue: p_z/p
Green: global geometry at first hit (PXL) = primary geometry at first hit (primary vertex)



Hypothesis: the primary vertex z is shifted from where the HFT tracks expect, thus bending all of the HFT tracks significantly in the z direction. It is not clear to me how tracks are allowed to bend so much over so short a distance (the PXL sits only a few cm from the vertex) as to take a 0.5 GeV/c global track with p_z/p of -0.4 and turn it into a 0.7 GeV/c primary track with p_z/p of +0.4 (this is a change in the pointing angle θ of 47°). Here is Δ = (p_z/p)_global - (p_z/p)_primary vs. p_primary [GeV/c], demonstrating that these are NOT just soft tracks:




-Gene

_________

Update 2:

Here's a look at the hits on HFT tracks in r = sqrt(x²+y²) vs. z (all units [cm]) space from event 70. The upper panel has the primary vertex in red. The lower panel is zoomed in on the HFT hits and the colors represent the individual tracks, with the primary vertex at r near 0 in purple, clearly shifted in z by a couple cm from where all the HFT tracks expect it, but somehow the tracks bend to it without dropping the PXL1 hit!



The primary vertex in this case is reported to be at:

x:-0.396368+-0.124729
y:-0.293761+-0.101879
z:-1.8996+-0.173812

This is the highest ranked (and only positively ranked) of 15 vertices found by Minuit in the event. The next closest ones on either side are at +8 and -24 cm in z.

-Gene