Contact: Tom Stuttard (UCL) -

Overview contains the code to read, re-organise, cut and analyse g-2 tracker test beam data.

The main contents are:

  • Definition of many parameters relating to the test beam setup
  • Processing of data ROOT trees (straw TDCs, scints) into C++ STL container structures with intuitive layers (e.g. spills, accumulations, channels etc)
  • Generic cutting functions
  • Cuts tailored to the test beam data
  • Event reconstruction for the straws
    • Coincident hit pairs in overlapping straws in a single plane form doublet events
    • Coincident overlapping doublet events in different planes from station events
  • Analysis functions:
    • General sanity plots
    • Straw hit time profiles
    • Straw readout cycle
    • Straw drift times (in doublets)
    • 2D hit position reconstruction in straws (station events)
    • Scint performance

The code does not:

  • Combine scint data with straws to get trigger (still have issues with scint data)
  • Look at MWPC of beam monitor data
    • Stand-alone python scripts used for MWPC in software/src/analysis
    • Beam monitor not yet analysed

Individual read, cut and analysis tasks are functionalised and called from the main function. Comment out any individual analysis functions if you don't want to run them to save time.

The data containers of stacked STL containers looks a bit scary at first, but is (hopefully) reasonably intuitive. They are a stacked in a 'belong to' system, so data for an accumulation is with the container for the spill it occurred in. As an example, The time of the first hit in spill 2, accumulation 5, TDC 0 is given by:


In practise the containers are generally just being iterated over most of the time, and there are plenty examples to follow of this in the code. Also note that if anaData is passed by const reference to a function, the [] operator cannot be used on the maps, and instead map::find must be used (rembering that this returns the pair rather than the second element of the pair).

This code should eventually be ported to the offline system, and also become part of an analysis git repo. The structure of the code should fit well with the format of art modules, with the code functions being already suited to being split into a number of producers, filters and analyzers.

It would also be useful to be able to write the processed data to a new tree/ntuple at some stage, but this will require a considerable amount of work as the data structure will need to be re-flattened.


Currently the main data runs being used for this analysis are Run 497 (Jan) and Run 1300 (April).

User guide

Running the analysis

The test beam analysis code is in the file tracker DAQ repo, see here for more info on this, including how to get it, compile it etc. An important step is that you will need to setup the environment correctly for your system in, and this file must be sourced at each new login.

The analysis code is in the file software/src/ Many of the generic processes are used from software/src/analysis/

To compile it, use the following command in software/src:

make analysis

The executable will be in software/bin/TestBeamAnalysis.exe.

There are some command line arguments required to run the analysis executable, see the following examples (or just run the file without any and check the console output):

  ../bin/TestBeamAnalysis.exe DATA_TYPE=JAN IP_FILE=Run-001-straws-0-scint-0-mwpc-0-protons-0.root OP_PATH=. BEAM=Y SCINT=Y MAX_SPILLS=10
  ../bin/TestBeamAnalysis.exe DATA_TYPE=SIM IP_FILE=strawDriftTimesSim.root OP_PATH=. BEAM=Y SCINT=N MAX_SPILLS=10000

A list of the arguments is given below:

  • DATA_TYPE - JAN,APR,SIM - configure the analysis to the Jan/April test beams, or to sim data
  • IP_FILE - ROOT file containing TDC data trees (either a Run-XXX.root from Midas output, or a TestBeamSim output file)
  • OP_PATH - path to write output file to
  • BEAM - Y/N - indicates if there is expected to be beam in this data or not (e.g. a background run) (changes some cuts)
  • SCINT - Y/N - indicates if scint data is available to be processed in the input ROOT file
  • MAX_SPILLS - max number of spills to process (can be used to save time)

The output ROOT file contains histograms and graphs and is named Run-XXX-TestBeamAnalysis.root, where XXX is the run number of the input ROOT file (it is SIM when simulations are used.

Note that for large data files, the code can be slow.

Currently params are defined as global variables, are are assigned values either at declaration or at the start of the main function. It would be good to read these from configuration files at some point, especially as some values are also defined in other places (such as TestBeamSim) and hence mismatches are possible. However, it is probably better to wait until the porting of the code to the online framework to do this.