The problem

I have previously discussed instances of "stuck" 1-second RICH scaler readings in Run 8 data [1,Run 8 1-second scaler failures,Handling stuck 1-second RICH scalers]. These corrupt values of the RICH scalers (usually an integral factor of x2 or x3 too high) cause severely incorrect application of TPC distortion corrections. Therefore, these events will be problematic for any analyses which use TPC information (note that this includes TPC-found primary vertices as well as anything involving tracking).

I believe we have Handling stuck 1-second RICH scalers for this problem for the Run 8 pp st_physics production (no other Run 8 pp data has yet been produced with TPC tracking). However, this implementation came too late for the Run 8 dAu production.

As far as I know, the corruption of the scalers has no correlation with anything physics related (most likely due to hardware glitches for the RICH scalers) and only occur for a second or two here and there every few hours or so. They also seem to occur for different scalers independently (i.e. the ZDC east scaler might get stuck at a different random times from the ZDC west scaler). So simply cutting out these events from analyses seems to be the best choice. The task at hand is to design this "cut" which can be applied event by event (rather than removing all files or runs with corrupt events). 

The tools

The TPC distortion corrections for Run 8 dAu rely on the ZDC coincidence, ZDC east, and BBC beam background scaler rates (see the dAu200 (2008) for details). So all of three of these must be checked for validity. All of the RICH scalers are available in the MuDst, so they can be used for cuts in analyses at that level of data processing. One could make an ntuple of these scalers from a large, random sample (all?) of the dAu MuDsts produced so far. The scalers are in MuEvent->runInfo() [MuEvent.mRunInfo.mZdcCoincidenceRate].

In addition, we have another complete set of RICH scalers stored in the offline database. These scalers are integrated over 30 seconds (as opposed to the 1-second scalers stored in the DAQ files and which were used for the dAu production). I have an ntuple of these scalers which includes associated run numbers available at:

/star/institutions/bnl/genevb/Scalers/ScalersRunTimesRun8/ntup.root

The 30-second scalers are not corrupted by factors of x2 or x3 (it remains to be proven whether they are corrupt by factors of x(31/30) or x(32/30), but that's a separate issue). Though they are easier to work with, they are not in the MuDst files. They may be useful in trying to understand what normal ranges are for the scalers and ratios of scalers. (important note: the BBC beam background scaler which needs to be monitored for the dAu data is labeled as the blue [bbcBlueBackgroundRate] in the 1-second scalers in the MuDsts, while it is reversely labeled as yellow [bbcyb] in the 30-second scalers due to a bug You do not have access to view this node).

To jump-start ideas for cuts, I found that the following cut would work well for a large portion of the Run 8 pp data:

19 < (zdcw+zdce)/zdcx < 28

Here, zdcw and zdce are the west and east ZDC singles rates, and zdcx is the ZDC coincidence rate. Using the 30-second scalers from the database, here is that quantity for the pp data:

Fig. 1: (zdcw+zdce)/zdcx versus run-9000000 for the Run 8pp data

From this plot you can see that a different cut would be needed for pp runs < 9047000 as what were outliers during later running were standard operating conditions during earlier running. We need cuts that identify any of the three used 1-second scalers as being anomalously high by a factor of x2 (or more).

It is likely that such a cut definition for Run 8 dAu would also need to be different for different running periods (again, see the dAu200 (2008) for how I had to use different calibrations for different run ranges). Perhaps coming up with cuts defined day-to-day would be sufficient.  Actually, the ZDC east scaler is used only for runs > 9016000 and would not need to be monitored for earlier runs.

-Gene