In 2011, I introduced and documented a distortion correction for the displacement of the gating grid from its intended position due to the misalignment of TPC (sub)sectors (see Distortion maps due to sector misalignment). One of the notable features of this distortion correction is significant variations near the boundaries between subsectors (inner and outer, or between adjacent sectors). I had not looked at the distortion maps for this in a long time, but doing so now I found that while the map shows many of the features I would expect, it is missing the sharp variations between inner and outer sectors. Here are the maps of the distortions at full drift distances (near the central membrane; all units are [cm] or [radians]):

I traced the missing feature to the following: gating grid z displacements are determined at the innermost and outermost gating grid wires on each subsector using the alignment for that particular subsector. What was happening now was that the innermost gating grid displacements of the outer sectors were being calculated using the inner subsector's alignment, so that it had no discontinuity between the outer edge of the inner sectors and the inner edge of the outer sectors.

I tried using old alignments and going back to the oldest libraries we had available that could run the correction (SL14g) to see if the feature would re-emerge without luck. I did, however, eventually find the code change responsible, committed on 2014-07-01 by Yuri with the comment "Clean up". This was following his introduction of codes for his new TPC alignment procedures. While the new code did specify to use the alignment for each particular sector, it did not specify the inner vs. outer subsector and instead relied on the position being used to do so. As it turned out, the innermost gating grid wire of the outer sectors is at a radius small enough that the code which guesses the padrow from position calculated this not to be in the outer sector. I expect Yuri never tested for a consequence.

I identified two possible solutions: (1) return to the method of requesting the subsector matrix desired (the code is still there), or (2) feed the new code a padrow number from which to determine inner vs. outer (simply an additional parameter). Here are the maps using solution (2):

Now, here is the set of differences between un-fixed and fixed maps (these are essentially "error" maps):

What we can see is that these differences are generally below the 20 μm level, but maximally a few times that in some very localized locations near the corners of subsectors. This is large enough that it can affect tracking. The question is whether it is small enough not to affect physics. My guess is that the answer is that it did not affect physics, but I'm not 100% certain.

Also, there is the option of solution (1). Why they two solutions should return different alignment matrices, I do not know. The above maps are nevertheless very similar for this alternative solution because they are very close, so instead I will show the difference in maps between the two solutions (you can alternatively think of this as the difference in error maps between the two solutions if you prefer as that is equivalent):

Perhaps one way to think of this is that the error maps appear to be roughly an order of magnitude smaller than the distortion correction maps. And the difference in error maps is roughly an order of magnitude smaller than the error maps. I expect this then is at a level which is smaller than other uncertainties, and I don't think it matters which solution is implemented. I will proceed with solution (2) to respect Yuri's intent for the code change he made in 2014.

To get at least one handle on the impact of this, I looked at the changes in numbers of "good" primary tracks for 3 nightly tests of 500 events each in DEV. I found that the code fix resulted in changes of:

• 2016 AuAu200: MEAN=+0.03%, RMS=2.33%
• 2017 pp510: MEAN=+0.02%, RMS =1.88%
• 2018 isobar: MEAN=+0.02%, RMS=0.34%

This may be at a level that is below what may have impacted physics over these several years, but I have not (yet) looked more closely than this.

-Gene