Continuing with the fills, the next in line is fill 16447. This had no error message, meaning begEndComp.tcl found a difference in the v124 files from the beginning to ending run in the fill. To try and sort out this fill, I looked at the cdev record corresponding to the ending time of the fill 2012-02-19 20:45:26 GMT. The return from this shows that the measured fill pattern was zero, but the fill number was consistent. The spin pattern for this time is B+-+--+-+ Y++--++--, but for the middle of the fill it should be a P4 pattern B-+-++-+- Y--++--++. So if we back up to the end of the last run in the fill 13050051 and check the cdev output (2012-02-19 20:35:26) the same result comes out. So, if we agree to scrap this run and check the next-to-last run in the fill 13050050 (2012-02-19 20:20:20) then we get the results we expect, a good measured fill pattern and a P4 spin pattern. Thus we can use this fill, but we need to throw away run 13050051.

The next fill is 16452. The first run in the fill is 13052026 and is a setup_2012_ht run, but I start with it because it's status is Questionable. The measured fill pattern and polarization pattern for this run are very odd (using 2012-02-21 15:48:46 GMT), they're not full, but not all zeros either. So, if we move on to the next run in the fill 13052035 (2012-02-21 18:40:20 GMT) we find that everything looks good, with a polarization pattern of B-+-++-+- Y --++--++ (P4). So then we check the ending time of the fill (2012-02-22 02:26:09 GMT) and also find the same P4 pattern and a good measured fill pattern. Thus, we conclude that the questionable run was throwing the script for a loop. So we throw away run 13052026 and keep the fill with a P4 pattern.

The next fill I looked at was 16462. This is an odd fill. There are only a handful of runs in this fill and it's split down the middle as to what the spin pattern is. Using a script called spinCrawler.tcl provided by Brian Page, I was able to pinpoint that the pattern changes from B-+-++-+- Y--++--++ (P4) to B+-+--+-+ Y++--++-- (P1) during the middle of the fill around 2012-02-24 15:20:00 GMT. The script takes a start and stop time and increments by 60 seconds for each loop, looking at the cdev records to find the spin pattern. The time where the pattern changed isn't obvious. It was in the middle of a run and the RICH scalar plots for this time don't look funky. So, I would scrap this fill, and the 9 runs that go with it, as it's not clear what spin pattern is correct for the fill.

The next fill to sort out is 16484. Taking a look at the cdev output for the end of the fill time (2012-02-29 06:51:42 GMT) we find that the measured fill pattern is zero (beam was ramping down) but the fill number is the same and we get a polarization pattern of B++--++-- Y+-+--+-+, but if we look at the records for the end of the last run (2012-02-29 06:41:41 GMT) we get the correct polarization pattern (P1) as we have at the beginning of the fill. So this fill is OK we just need to change the ending time of the fill to something closer to that of the last run in the fill to make it have a consistent fill and spin pattern.

The next fill is 16487. This fill is another odd one, most of the runs taken in this fill were marked as junk, and not used. Following the standard procedure I checked the end of the fill time, and the end of the final run in the fill (2012-03-01 01:00:04 GMT && 2012-03-01 00:50:04 GMT respectively). Both of these returned zeros for the measured fill patterns, and incorrect spin patterns. If I then check the run before the final run that wasn't marked bad I look at run 13060020, I find the same results for the fill and spin patterns. So I then look at the beginning run ( 13060005) and the run two back from the end (13060012) I find that these two are consistent with each others fill and spin patterns and with spinTime.txt (P5 pattern). So we can use this fill, but must remove the last two runs (13060135 and 13060020).

To try to salvage fill 16509, we again check the end of the fill cdev output (2012-03-05 15:13:42 GMT) to find that the polarization pattern is all messed up, as well as the fill patterns. If we, though check the ending run in the fill (2012-03-05 15:03:42 GMT) we find that the pattern matches up with the expected P5 pattern, as well as the first run in the fill (2012-03-05 07:21:22 GMT). So we adjust the ending time for the fill closer to the end of the final run, put it in the good list.

This is again the case for fill 16541. The end of the fill time (2012-03-12 01:09:58 GMT) shows that the spin pattern is B--++--++ Y-+-++-+-, whereas if we back up to the end of the final run (2012-03-12 00:59:58 GMT) we get B--++--++ Y+-+--+-+. Now if we check the first run (2012-03-11 17:14:05 GMT) we return the same spin pattern as the last run, thus indicating that we need to use the fill but change the stopping time of the fill.

These last three runs are the ones with the *fb errors.

First up is fill 16507. This one was an easy fix. The error told me to examine the beginning of the fill so I checked the first run in the fill 13064046 (2012-03-04 18:20:38 GMT), and it returned all zeros for measured fill pattern, but the spin pattern was good. If I check the ending fill time as well as the second run in the fill, I get a good fill pattern and the expected P5 spin pattern. This one was added to ghe good list and run 13064046 was removed from the fill

Next up was fill 16523. The first run in the fill, 13068006 was marked as junk by the shift leader, so I threw it away immediately. If I check the resulting beginning run (2012-03-08 06:58:10 GMT) and the ending fill time (2012-03-08 14:21:56 GMT) I find that they both give a good P5 pattern, and are useable. So this fill is good if we remove the run mentioned previously.

Finally we have to sort out fill 16538. The first three runs are three successful setup_2012_ht runs. But the problem is that they're at injections so the measured fill pattern is zero and flagging the script. The spin patterns are consistent throughout until the end of the fill, but the fill pattern is zero. We can throw these runs away and we will have another nice clean fill. Thus we loose runs 13070038, 13070039, and 13070040. 

I will write another post soon summarizng the overall results of the QA and what runs were lost in the process.