Run 12 UU GridLeak vs. Sector

 In the midst of studies of using the new TPC alignment in SpaceCharge & GridLeak calibration of Run 12 UU data, I took a look at the remaining GridLeak distortion vs. sector. I modified StSpaceChargeEbyEMaker to make separate histograms for the 24 sectors in measuring gapf, and I then made plots of the fit gapf values vs. sector for st_centralpro files at 6 different luminosities (except 5800 Hz, which was st_physics), from 1000 events processed with the chain: "P2012b,AgML,mtdDat,btof,fmsDat,BEmcChkStat,Corr4,CorrX,SCScalerCal,goptsce100020,OSpaceZ2,OGrid Leak3D,-hitfilt". (Note: with the CorrX chain option, the new TPC alignment is used, so I did also use an Run 12 UU TPC T0 with new alignment, but the old [from last year] SpaceCharge & GridLeak calibration [and everything else not superceded by the new alignment]).

Here are the results, where blue points are from positively charged tracks only, red are negatively charged, and green is charge-inclusive. The open circles shown at sector 25 are the values inclusive of all sectors. Thus, the green open circle (inclusive of charge and sector) is the value which is actually used in the calibration.


Sectors 3, 14, 20, and 22 are missing hits on padrows near the inner-outer junction, so they are absent from these histograms.

There does not appear to be a clear charge ordering for most sectors, but there is in sector 6, where there is also a clear remnant distortion that grows with luminosity. This sector 6 issue was also seen by Jan Balewski in his GL vs. anode studies in summer 2012, and noted in his You do not have access to view this node to S&C at that time.

Sector 7 may also be showing a smaller but similar effect.

Here the same sector-by-sector data is shown (negated for clarity) in a surface plot vs. luminosity (zdcx) and sector:



____________________

Next one can ask whether sector 6 is under- or over-corrected (i.e. it has more or less GridLeak distortion than the other sectors respectively). I determined this by running a couple jobs on the same data with GL scaled by ±10%. The result is clear, as seen in the following plots, that sector 6 is over-corrected and reducing the value of GL raises the value of gapf (bringint it closer to zero in this example).



These plots can further give us some estimate of how much less GridLeak distortion there is in sector 6. The rest of the sectors move by ~-0.04 when GL is dropped by ~20%. But sector 6's gapf is perhaps ~0.07 away from the rest of the sectors. The implication is that sector 6 has ~20% * ~(0.07/0.04) = ~35%, or about ~1/3rd less GridLeak distortion than the other sectors.

At first, that seems rather large. But take for a moment the possibility that one of the fat anode wires next to the inner/outer sector gap in sector 6 is dead (disconnected). Might we then expect to see an effect on this scale? Our present understanding of the GridLeak is that it is ~half and half due to inner vs. outer sector contributions. Could the current observation be consistent with ~half? I personally doubt so...

Perhaps it is also the case that the GridLeak distortion arises from the last two anode wires, not just the last (fat) one. In that case, one of the two wires might account for about twice as much of the leak as the other, thus having one contribute ~1/6th of the total GridLeak, and the other ~1/3rd. With that hypothesis, sector 6 might be missing the ~1/3rd contribution, and sector 7 might be missing a ~1/6th contribution. Unfortunately for this hypothesis, GridLeak Simulations indicate that only the last wire has any chance of contributing. Hmmm.

_____________

For interest, I tried re-running all 6 luminosities once more, this time with 8% less GL overall (GL scaled down with 0.92), and sectors 6 and scale GL scaled down with factors of 0.65 (35%) and 0.85 (15%) respectively. Here is the result, which seems roughly reasonable, given the statistics and the fact that this isn't quite the right calibration for the rest of the sectors anyhow. More statistics could be used to fine-tune, but this seems like it might be a viable correction to implement.



-Gene