Here I detail the problem with the spin patterns seen in Run 12 ...

While I was testing the code to do the Spin QA for Run 12, I encountered an odd feature with how the spin patterns were loaded into the collider. For some fills, the spin patterns are not repeated modulo 8 over the RF buckets in the ring. The list of fills I have looked at can be seen here. The list covers the 2012 Longitudinal running period. The fills which have this spin pattern problem have "c's" in the spin pattern. One thing to note is that most of the problem fills are those in which the blue and yellow beams have 107 bunches filled as opposed to the normal 109. I'm not sure if this is just a coincidence or a clue.

To give a clearer picture of what the problem is, I have included two example polarization fill patterns from the cdev records. These blocks show the polarization state for each bunch in the ring. Figure 1 shows the blue beam pattern for a fill which did not show the spin pattern problem (16701). Figure 2 shows the blue beam pattern for a fill which did show the spin pattern problem (16594). Both fills had a P3 spin pattern.

The Spin QA code reads in these blocks from cdev and performs several checks on them. One check is to make sure the spin pattern is repeated regularly throughout the bunches. There are 360 bunches in each ring (count i 0-359) and every third one (i%3 = 0) is filled. The spin pattern should repeat every 8 bunches, so every (i%3 = 0) bucket which has the same value of ((i/3)%8) should have the same spin bit if the pattern is repeated correctly. For the blue beam P3 pattern, the spin bit for each ((i/3)%8) position should be:

((i/3)%8) = 0: Spin Bit = 1

((i/3)%8) = 1: Spin Bit = -1

((i/3)%8) = 2: Spin Bit = 1

((i/3)%8) = 3: Spin Bit = -1

((i/3)%8) = 4: Spin Bit = -1

((i/3)%8) = 5: Spin Bit = 1

((i/3)%8) = 6: Spin Bit = -1

((i/3)%8) = 7: Spin Bit = 1

Figure 1: This figure shows a good P3 Blue Beam Pattern:

If you count out each filled bunch shown in figure 1, you will see that the spin pattern repeates itself in the manner described above. Now look at the pattern shown in figure 2, 1/3 of the way down there is a row in which two buckets which should nominally be filled (i%3 = 0) are not, this is a planned feature. But we see that in the bad fill below, after these two unfilled buckets, the spin pattern shifts. The first filled bucket after the row with the unfilled buckets is i=120, ((120/3)%8) = 0, so according to the chart above the spin bit for bucket 120 should be +1 but we see that it is actually -1. If you look closely at the pattern after the two unfilled buckets you will see that the pattern has shifted by two. Instead of counting through the spin pattern even if a bucket is not filled as was done in the fill shown in figure 1, the fill in figure 2 ties the spin pattern to filled buckets.

Figure 2: This figure shows a bad P3 pattern.

I have been doing the spin bit QA since 2008 and this is the first time I have noticed this problem of the spin pattern not being repeated consistently across all buckets. A closer look at the lists below shows that this issue was present for three fills (10881, 10884, and 10951) from the 2009 200GeV period. Below I link the lists of fills for the previous periods I have done the QA:

2008 Run

2009 500 GeV Run

2009 200 GeV Run

2011 Transverse Run

2011 Longitudinal Run

2012 Transverse Run

I do not believe the issue I describe above will have any affect on determining spin asymmetries in any analysis that uses the spin database. Each bunch crossing will still have a well defined spin combination (++,+-,-+, or --). What I do not have a good feeling for is how this will affect attempts to understand the systematics on the relative luminosity.