Compton Online Analysis

This page is written for people with little background on how the compton online analysis scripts work, but want to know more. The analyzer itself is maintained by Juan Carlos Cornejo, but the online scripts are maintained by AJ Zec. This page will focus on the latter.

The Directories

There are three main directories pertaining to the online analysis, which can be found on the compton machine in /home/compton/online/:

1. CompMon/: This directory contains the CompMon analyzer code, as well as the scripts that produce the runwise online plots. Also contains code to display a panguin-style window of those plots.
2. aggregator/: Contains the code used to make a series of plots for each snail.
3. grand/: Contains the code for making runwise and snailwise plots as well as the compton grand rootfile.

The Main Script: online.sh

The online script is run whenever a new production run is completed. The script is run as such: ./online.sh -r <run number>. The run number argument is the only mandatory argument for the script.

Arguments

online.sh has a number of optional arguments that can be used.

1. --panguin: Including this argument brings up a panguin-style window of the compton run plots.
2. --rootfile: During the online plotting process a rootfile containing run plots gets generated and then deleted. Invoking this flag means the file does not get deleted after execution.
3. --nowebupload: By default the run plots get turned into PDFs and moved into the compton web directory /group/prex/analysis/www/<prex2/crex>/compton/. Invoking this flag skips that process.
4. --replay: By default the online script skips re-running this analyzer if a rootfile has already been generated for the specified run. Invoking this flag forces the analyzer to be re-run.
5. --nogrand: By default the online script generates a rootfile which is later used in the generation of the grand rootfile for either PREX-II or CREX. Invoking this flag skips that process.

How does it work?

This is a list of scripts that online calls in order and a short summary of what each script does. Assume that the script online.sh is called with a run number argument referred to as runNum:

1. Check if a directory for our web uploaded plots exists. If not, create one
   • The online plots are stored in the directory /group/prex/analysis/www/<prex2/crex>/compton/ depending on which experiment they are for. This directory is stored in the environment variable $COMPMON_WEB which can be changed from prex to crex mode. In each of those directories is a folder called runs/ which contains a folder for each individual run in the experiment which itself contains the plots for that run.
   • The script looks for a folder named like $COMPMON_WEB/runs/Run<runNum>/ and if it can't find it, it creates it.
2. ./compmon.sh -r runNum: If no analyzed rootfile exists for the run OR the --replay flag is invoked, then the script will call the compmon analyzer to replay the run.
3. root -l -b -q $COMPMON_LASERCYCLES/laserCycles.C(runNum): This is the laser cycle identification script found in CompMon/laserCycles/. This script parses the run rootfile sequentially, identifies laser periods (defined as any continuous group of MPSs sharing the same laser state) and groups them into laser cycles (defined as any three consecutive laser periods following a laser off-laser on-laser off pattern.)
4. root -q -b -l ./dataQualityCheck.C(runNum): This script makes the online plots for the run and stores them in a rootfile located in CompMon/output/. The rootfile is named compton_online_run_<runNum>.root. It is normally deleted at the end of execution.
5. python $COMPMON_PANGUIN/macros/writeCFG.py runNum: This is only called if the --panguin flag is invoked. This script writes a config file with the correct run information that panguin uses. AUTHOR'S NOTE: I tried doing it the regular way but I never got it to work, and frankly it's not worth the time investing into more because it's an aesthetic issue that almost never comes up.
6. $COMPMON_PANGUIN/build/panguin -f $COMPMON_PANGUIN/macros/prex_auto_runs.cfg -r $runNum: This is only called if the --panguin flag is invoked. This is what actually displays the panguin window using the auto-generated config file above.
7. root -q -b -l ./writeToPDF.C(runNum): This script is a wrapper for the code in utils.h which takes the plots in the rootfile generated by dataQualityCheck.C and turns them into a set of multi-page PDFs, and then places them in the correct $COMPMON_WEB directory.
8. root -l -b -q ./plotAllCycles.C(runNum): This script generates eight plots for every laser cycle in the run and groups them all into a single page PDF and adds it to the correct web directory.
9. python ./write_html.py $DATE $TIME index.html: This script creates an HTML file in the $COMPMON_WEB directory that can be accessed from a browser.
   • Steps 7-9 are skipped if
10. root -l -q $COMPMON_GRAND/buildRunRootfile.C(runNum): Creates a rootfile in the grand/ directory which will later be used when building the grand rootfile.

Laser Cycle Identification: laserCycles.C

The first non-analyzer script that gets called, this identifies the laser cycles in the run and stores their MPS number limits in a csv file. The script heavily uses the header laserUtils.h to define easy data structures in which to store laser periods and laser cycles, as well as evaluate them.

The Algorithm Described Verbally

1. Determine the laserState of the first pattern in the quartetwise tree.
2. Begin iterating through the tree until you find an entry with a different laserState than all the previous entries.
3. Once you find such an entry, then store the entry number at which the change happened, and start a new laser period in the new laserState. Also count the number of beam on entries. Save for later.
4. Continue until you have iterated through the entire run. Store the list of laser period limits in a vector.
5. Loop through the laser period list. Throw out any periods which:
   • Are less than 3 seconds long
   • Have laserState==4
6. Also throw out the first laser period only if it is not a laser-off period.
7. Loop through the trimmed laser period list. If two subsequent laser periods now have the same laserState, combine them by taking the start MPS of the first period and the end MPS of the last period and putting them together into the same period.
8. Create a new vector of the trimmed and combined laser periods.
9. Loop through the shortened laser period list. Look for any three consecutive laser periods in an OFF-ON-OFF pattern. Define it as the "candidate" cycle
10. Ignore the candidate cycle if:
    • The laser pattern is wrong or misidentified
    • There are 3 seconds or less of beam on laser on data
    • There are 3 seconds or less of beam off laser on data in either of the laser off periods.
    • If the separation between the laser on period limits and either laser off period's limits is greater than 10 seconds
    • The event range of the cycle is wholly or partially in a region that has been cut by mapfiles
11. If the cycle passes all cuts, add it to the laser cycle list. Continue until all laser periods have been examined.
12. Write the cycle MPS limits in a csv file
    • File format is one line for each laser cycle where each line contains data: first off period start MPS, first off period end MPS, on period start MPS, on period end MPS, last off period start MPS, last off period end MPS