Following Jan's study using the 3D BeamLine calibration method on Run 12 pp500 data, which shows an apparent luminosity dependence, I took a quick look at the Run 12 UU data by spinning over MuDsts from the P12ic preview production and using the 2x2D BeamLine method. In summary, I find a similar dependence, with BeamLine intercepts that appear to move by about 0.5 mm, in step with luminosity changes.

Cuts: vertex rank > -3 (greatly reduces pileup),  |V_z| < 100 cm, |V_r| < 4 cm
(I tried restricting to |V_z| < 30 cm, |V_r| < 1 cm to reduce pile-up even further, but saw no differences)

Using 2035 files I found on disk spanning days 132-135, each with generally 800-900 vertices that pass the above cuts, I can get beamlines for each file, so I got many beamline positions even within single fills (the calibration is usually done on a fill-by-fill basis). Here are x0 and y0 vs. ZDC coincidence rate (zdcx) from all 2035 files, where color denotes the time (e.g. purple is day 132, red is day 135).

 There is some fill-to-fill variance, but also a clear zdc-sum (zdce+zdcw) dependence of ~400 microns in x0 and ~300 microns in y0 (~500 microns total), made even more obvious with profile histograms of x0 and y0:

 Nothing so obvious in dx/dz and dy/dz profiles:

_________

Next, I examine just a single fill. Here is the zdcx rate for fill 16852 vs. time in seconds (arbitrary zero), which shows a rise due to the turn-on of stochastic cooling in RHIC, before the usual decay in luminosity. Points in red correspond to during runs 13133031 and 13133041-45, which were in my sample for the BeamLines:

And here are the calibrated x0 and y0 values in profile vs. hour of the day:

This makes it even more clear that the calibrated values aren't showing a BeamLine position which drifts during a fill, as both the rise and fall of the luminosity is mirrored here. In the next plot, one can see that (y0,x0) during fill 16852 traces out an arc around (0,0), perpendicular to a radial line:

This behavior is consistent with my study on the effects of not-fully-calibrated SpaceCharge & GridLeak on the vertex-finding. It is less consistent with being due to miscalibration of GridLeak for sectors 3 and 20 (which is likely the case because of reduced anode voltages for these two sectors in channels where GridLeak ions are believed to be produced) because those sectors are at 3 o'clock and 4 o'clock respectively, and should result in more vertical (orthogonal to their radial lines) displacements of tracks & vertices.

-Gene

__________

Follow-up: we discussed at the 2012-07-19 TPC meeting, and Yuri brought up the point of excluding the first padrow in the TPC back in the days of inner tracking, possibly because of SpaceCharge and/or GridLeak distortion effects there. Perhaps with high luminosities this is becoming an issue for vertex-finding.