AuAu 53 GeV - Evaluating performance

First I looked at the number of vertices in these collisions:

I was surprised that there didn't seem to be a correlation between the bbc rate and the number of vertices.  I did not normalize the plot on the right for the number of events, so perhaps if I looked a little harder the correlation would become obvious.


This is the x,y and z position of the index 0 (primary) vertex.  Comparing it to the Vz from other detectors, we get:

There is good agreement between the vpd Vz and the Vz from the vertex finder, though there is an offset about 2.5 cm if one looks at the vpd Vz - Vz distribution.  I have taken this into account for my definition of a "good" vertex (once the vpd is calibrated, this will probably go away).


Then I looked at the reference multiplicity versus the bbc rate.  Already, one can see a weird kink at high refMult, and that the average refmult (the black line shown in the right plot) decreases with increased rate.  Actually, it really looks like all of the files with the strange refMult came from one period.  Perhaps this should be looked into.


Next I looked at the distribution of the tof multiplicity versus the primary vertex refmult.   The left plot shows this distribution for all vertices.  This distribution is repeated again for the black points in the center plot.  The red points are defined as "good" vertices, which is |vpd vz - vz - 2.5| < 6 cm.  This cleans up some vertices, but not all of them.  It does not do anything with the secondary structure.  The red points are repeated in the right plot, and then points from low BBC rate events are recorded in blue.  So the secondary structure is coming from high rate events.

The function shown is:
TF1* func = new TF1("func","[0]*x*x+[1]*x+[2]",0,450);
    func->SetParameter(0,0.006);
    func->SetParameter(1,2);
    func->SetParameter(2,-30);

I have used this to define "better" events by selecting only those events that fall above this black line.
In this sample, there are:
There are 834434 events
There are 744434 events with a vertex
There are 408335 events with a good vertex (vpd vz and vz agree)
There are 355434 events with a good vertex not split (vpd vz and vz agree, above the black line).

It should be noted that it appears the issue isn't split vertices, because these have a higher than expected refMult for the given tof Mult.  Rather it looks like pile-up tracks are being added to the vertex in question.