With the first couple getAllRuns_xxx.pl files completed, and the findBXoff.C run over them, it was time to begin analysis to ensure that everything was working just fine. I wrote OpenReadPrint.C which reads in the summary.pass8a.dat file, prints out a lot of information, flags numbers that seem too high or too low (ex: beam crossing 7 offsets of anything but 0 and 119 get flagged), and then produces 7 graphs (Edit: which are no attached in the 3rd Entry).

After coming back from a week long vacation, I began to notice that the jobs that were being submitted were no longer producing any files. At first I thought that I was writing them to /dev/null since I had recently changed to xml file to throw away my .out and .log files to there. Turns out while I was gone they had changed which version of the gcc compiler they were using. Eventually after a lot of "rm"-ing, "cons"-ing, and pouring over the code, it was realized that there was a line in the testTemplate.xml file that was limiting the number of events that was being put into the histograms. Worse yet, it would still run over all of the events, but it would break all of the events/files into seperate processes, where each wrote a .hist.root file with the same name, effectively overwriting itself for every process. This lead to historgrams with an extremely low and irregular number of events.

Deleting this line (somewhat counterintuitively) lets the program make much larger cuts inbetween its processes. This combined with setting the maximum size to 10k, ensured consistent results. It also massively cut down on the amount of runtime, and I was able to make up for the "lost" files, and then submit everything else in the testSummaryClean.txt file all in one afternoon! This lead to much rejoycing, and a lot of kicking ourselves.

I checked to see if all the files were accounted for the with runNumberComparer.pl, which was discussed last time, and discovered that I had all of the files I should have. (Edit: this is not true, see Entry 3)

I then made a list of all of the run numbers, and tried to feed it into findBXoffDynamic.C, a modified version of findBXoff.C which did the same thing, but could take in a list which it iterated over. Running this resulted in unexpected errors, some caused by it trying to analyze histrograms that had zero events in it, and some from the list being too long and the program running out of memory. This was fixed by removing all of the zero event histograms from the list, and then splitting the list in half and running it two seperate times. This wrote all of the data to the summary file, but it was out of order, and it was hard to see the patterns. So I did this process over again, in numerical order, to ensure that the data was easily understandable.