Introduction:

I list here instructions on doing the TPC anode voltage QA via the example of Run 10 datasets for 7 GeV and 11 GeV AuAu collisions. In this data, nominal voltage was considered to be 1390 V on outer sector channels, and 1135 V on inner sector channels, with the exception of 3 specific channels set to lower voltages (channel 7-6 @ 1150 V, 18-4 @ 1100 V, and 24-5 @ 1345 V). Please be aware that instructions and scripts must be modified for the dataset of interest. Scripts are attached as a tar file.

________________________________

Concepts:

These scripts scan through each run looking for voltage deviations (greater than ±4 V) from nominal values. For each run, all channels are examined in a loop. For each channel, two checks are made:

1. Voltage picked up at the beginning of a run.
   • If the voltage is bad, but the next voltage recording in time for this channel is good, output instructions on how to transfer the next voltage to a timestamp corresponding to 30 seconds before the start of this run.
   • If the voltage is bad, also output instructions on how to deactivate the voltage so that the previous recording may be picked up instead. Also print a note on what that previous voltage is (it may also be undesirable).
   • The user must often decide which method (or both, or neither) between transfer and deactivation to use. The decision may be based on proximity in time of the alternative recordings, or may be constrained by other factors. For example, the voltage on the channel may really have been turned off or changed, in which case it is correct. At this time I have not come up with a good way to automate the decisions.
2. Average of voltage entries made during a run.
   • If the average voltage is bad, output instructions on how to deactivate the voltage so that the previous recording may be used instead. These bad averages are usually for one of two reasons:
     1. A voltage supply trip
        • There is no reason to deactivate this recording.
     2. A false zero (often obviated by another recording shortly afterwards restoring the voltage)
        • The zero should be deactivated
   • The user must decide whether to deactivate or not.

The procRun script handles all of these tasks for individual runs. It is called from the procAvg script, which takes care of looping over runs. It also disperses the queries among multiple databases and collates output from individual procRun jobs in run number order. Lastly, procAvg calls procCodes, which utilizes unique codes written in the output of procRun which allows duplication of issues seen in multiple sequential runs to be truncated.

Another pair of script are provided called procAvgDeactive and procRunDeactive. Their purpose is to output commands which deactivate extraneous (unnecessary) entries between runs. This should be done only after the voltages used for runs have been finalized. The principle here is that these extra values in the DB may be picked up if simulations are run with a semi-random timestamp. Instead of getting some voltage values representative of the general operations of the TPC near that point in time, it's possible to pick up a large group of zero voltage readings from a moment between runs (for example, if a simulation uses sdt20100501, then the exact time "2010-05-01 00:00:00 GMT" is actually between runs, and the TPC voltages could theoretically be off [zero] at that moment). These zeros disable the TPC as an active detector for tracking (it becomes a dead detector where voltages are below a minimum amount).

Deactivation commands output a deactivation timestamp of FFFF. This needs changed to the current time when the commands are sent to the database. The current time is easily obtained on the linux farm via:  date --utc '+%s'

________________________________

Instructions:

1. Get list of runs:

   get_file_list.pl -keys runnumber -limit 0 -cond 'runnumber>11100000,tpx=1,trgsetupname=CosmicLocalClock' > runs
   get_file_list.pl -keys runnumber -limit 0 -cond 'runnumber>11100000,tpx=1,trgsetupname=cosmicNoBeam' >> runs
   get_file_list.pl -keys runnumber -limit 0 -cond 'runnumber>11100000,tpx=1,trgsetupname=AuAu7_production' >> runs
   get_file_list.pl -keys runnumber -limit 0 -cond 'runnumber>11100000,tpx=1,trgsetupname=AuAu11_production' >> runs

2. Make sure the list only has sane and good status runs:
   The file catalog queries in step 1 should already set a requirement on sanity, so one should just be able to copy:

    cp runs runs_sane

   However, if you have obtained a run list in some other way, sanity should be checked (note that this can be slow):

   ./procSanity

   [ Output: runs_sane ]
   This is then used as input for the status check:

     ./procStatus

   [ Output: runs_good ]
    
3. Obtain list of run times:

   ./findtimes

   [ Output: begins, ends ]
    
4. Make sure nominal voltages for the whole run period are as they should be. These can be set in the procAvg script, which then passes them to the procRun script. Exceptions for individual channels can be set in the procRun script.
    
5. Run the checks (this will take a long time and should only be done over the full list of runs when everything is ready). The results file shows all results for all runs, while the resultsZ file has redundancies removed.

   ./procAvg >& log.check &

   [ Output: results, resultsZ ]
    
6. Sort through the resultsZ file to pick the appropriate commands to run for the database (other commands can be turned into simple mysql comments). Be sure to properly convert deactivation times and then run the DB commands.
7. Run the checks on extraneous voltages:

   ./procAvgDeactive >& log.extra &

   [ Output: resultsD ]
    
8. Replace the deactivation time in the resultsD file and the run the DB commands.