Note: There was a discussion of HFT tracks matching to the primary vertex in FastOffline from a year-and-a-half ago in the midst of Run 14...See this thread, which referred to this presentation. The discussion's focus was not the displaced vertices as an additional category of events, but if one looks at slide 17 of that presentation, they are clearly present in the "Tracking with HFT" plot. Instead, plots on slides 14 & 20 of that presentation do not obviate a subdivision of HFT-included events, but imply that all HFT-included events have diminished primary track association to the vertex. Therefore, this blog post may be unique in focusing on the second category of HFT-included events.

__________


 In the process of calibrating the BeamLine constraint for Run 14 AuAu 200 data (useful for UPC collisions), I found a notable set of artificially located vertices for real events. These bad vertices sit near (0,0), which hints at a long-standing issue with the Minuit Vertex Finder showing a bias towards (0,0) (see this for more information).

Here are y vs. x and y vs. number of daughters for the primary vertex (its "mult"iplicity) for a set of the data with some pile-up cuts in place:



It is worth emphasizing that these bad vertices are NOT pile-up vertices. In AuAu200, it is not too difficult to exclude pile-up. Here I demonstrate that by showing the fraction of mult which has prompt TPC hits vs. the fraction that has TOF matches (left plot uses mult as the color; right plot uses rank as the color). One can easily construct a metric to exclude the pile-up which is located in the lower left corner of this plot. (I wish it were this easy in pp collision data!)


For calibration purposes, I can cut on multiplicity to remove the bad vertices (I will not focus on that here). But that's not an option for people doing analyses. At low multiplicity, the fraction of bad vertices exceeds 10%! Some things I learned discussing this with Mustafa:

1. People using the HFT in the heavy flavor PWG are not using the primary tracks: they do require events to have a found Minuit vertex, then take the global tracks associated with that vertex, and use KFVertex to find a new vertex. So they effectively use nothing about MinuitVF other than it has found a vertex.
2. A qualitative look at Mustafa's ntuples showed that KFVertex typically found a vertex in the proper location for these bad vertices. (note: there were also other classes of vertices found at the proper location well in one of the VFs, but not the other, but the ones I am focusing on here were indeed found well by KFVertex).

Note that this is a very incomplete sampling of PWG usage of the data. We have little information about what other users are doing.

Searching for clues to the cause, I found what is likely a side effect, but not a cause. For these bad vertices, the vertices are found using global tracks that have a reasonable fraction of HFT hits on the tracks. However, once the vertex is found and the tracks are refit as primary tracks, most of the HFT hits in PXL2 and IST are thrown off! Curiously, the hits in PXL1 are not excluded as much. NB: the requirement we use in reconstruction is that global tracks get at least 3 HFT hits (following the weighting scheme 9,3,9 for the data without SSD), but there is no check at the primary track re-fit stage on the number of HFT hits used.

	y vs. global partner track fraction with layer	y vs. primary daughter track fraction with layer
PXL1
PXL2
IST

-Gene