Aggregator outputs, Slug Plots, and Grand Plots

This is a work in progress! - Buddhini

Information given in this page are extracted from Cameron's "PREX II/CREX HOWTO Guide: How to replicate respins" document

The Aggregrator

The “Aggregator” is one of many tools for pulling calculated values of interest from the runs processed in a respin. It and its affiliated plotting scripts were generated during the PREX and CREX run periods as events unfolded, which is partly why there are so many dead ends and mediocre functional programming things going on. There are also the treemerge scripts that extract the JAPAN produced calculated values as well as others made by various students, so using the Aggregator is not a hard requirement by any means. The Aggregator however is special in part because it can be easily modified to utilize different cuts and to produce any output that could go into a “Draw” command at the ROOT command line within its text input files. It is also interesting as it is a fully realized implementation of the ROOT DataFrame workflow, which has demonstrated significantly faster (python-Pandas-esque) fast “lazy” actions when generating simple histograms (i.e. 1 dimensional Draw commands).

How to use the Aggregator

The Aggregator relies on global shell variables to tell it where inputs and outputs should go, as well as a slew of command line arguments, and finally a long input configuration file that lists the analyses that should be performed. These 3 features are handled fairly automatically using scripts, with the ultimate burden of deciding these inputs being decided in 2 places: the input configuration file and the global variable sourced file.

Using the input configuration file

The input configuration file lists the analyses to be performed, and there are several options that can be used. Over time a lot of things have become hardcoded or get passed in as global shell variables, but here is a list of kinds of analyses that can be included in the input configs and example lines to implement them:

• “meanrms” - this is the base…..

reg_asym_us_avg,reg.reg_asym_us_avg,meanrms cor_asym_us_avg,mulc_lrb_alldet_burst.cor_asym_us_avg.hw_sum,meanrms

• “slopes” - this ….

Using the sourced input scripts

To simplify setting up the global shell variables, there is a folder containing scripts that can be sourced to set those up for various analyses, found here in the prex-prompt repository. These scripts contain several important variables, which can be set to system dependent values or left empty for apar@adaq default choices (which may or may not work outside of apar@adaq). Those variables are as follows:

   • List
   • Of
   • Config
   • Sourced
   • Variables
   

Merging Aggregator outputs into one giant ROOT file for the whole experiment

Because we want to be able to analyze multiple runs or miniruns at the same time, the Aggregator is set up to print a unique ROOT file for each run or minirun that is being analyzed, and merging is left for later.

Due to the complication of changing device lists (some BPMs come and others go across the run, etc.) during PREX II, Cameron set up a more complicated implementation of the basic “Hadd” algorithm, called the “smartHadd” or “Merger” script in JAPAN (found here, with accompanying documentation and automation scripts). This smartHadd script also allows for substantial compression of the outputs, but is rather slow and prone to crashing when too much memory is used.

For simplicity, this set of scripts relies on the same global shell variables that the Aggregator does, which means the same input source scripts should be passed as were used in the creation of the aggregator files being merged.

Because this merging script is not perfectly designed, it is prone to running very slowly and to running out of memory and crashing. As such, if bypassing mixed device lists is not urgently important, it is easiest to segment the full run list into several chunks and do this smartHadd analysis in chunks. The resulting chunks can then be hadd’ed normally, or this smartHadd script can be run again on the freshly merged (and ROOT compressed) outputs to make a single final giant ROOT file.

This set of merging scripts also works for other kinds of analyses, though it may be overkill and using Hadd is still preferred most of the time.