Analysis Cuts

Various cuts are available in each of the analysis processes. Common cuts to all analyses which ccan be used involve the fundamental objects themselves such as analysis events and DUTs.

Proximity

When a DUT is defined the last two numbers in the return function for FE-I4 and FE-I3 DUTs denote the allowed proximity of tracks; x (cols) and y (rows), respectively and both in microns. This is used for the definition of efficiency, which is the ratio between the number of reconstructed tracks that hit the detector in the proximity of a fired pixel to the total number of reconstructed tracks that hit the detector. The proximity region is defined as a x-y distances in the makeduts.h file in the core/include directory of tbmon.

e.g. DUT* m20 = makeFEI4("MICRON01", dutnumber, 2, 250.0, 50.0);

Chi Squared The quality of fitting is defined using a member function of the config class, Chi2Builder. To check the chi2 distribution of the events see the maxcellres_DUT_chi2 histogram.

e.g. config.addBuilder(new Chi2Builder(15.0));

Level 1 (out-of-time) To mitigate the effects of out-of-time hits a level-1 cut is made using the DUT object method lv1Range. To check the chi2 distribution of the events see the maxcellres_DUT_lv1 histogram.

e.g. m20->lv1Range(5, 9);

Analysis Processes

Standard Plots

maxcellres_DUT_lv1 -- used for optimising level1 cuts (see above)

maxcellres_DUT_chi2 -- used for fitting tracks to clusters ( see above)

efficiency_DUT_effDis -- spectrum of pixel efficiency

efficiency_DUT_effMap -- 2D map of pixel efficiency

clustercheker_DUT_unmatchClusterSize -- size of unmatched clusters

clustercheker_DUT_matchClusterSize -- size of matched clusters

clustercheker_DUT_matchClusterSizeX/Y -- size of X/Y matched clusters

residuals_DUT_cluSizeX/Y -- size of residuals in X/Y, used to compare \sigma of fitted Gaussian (measured resolution) to compare to \frac{pitch}{\sqrt[2]{12}} (ideal resolution).

EUTelescope And IBL Testbeam pages

Notes on customising analysis of IBL testbeam data using tbmon.

Assuming you are in PATH_TO_ANALYSIS directory...

To add new code to analyses you'll need to create/edit files in PATH_TO_ANALYSIS/analysis/ part of the file structure. A header (i.e. .h file) must be in the analysis/include directory with all declarations (classes, member functions, variables etc.). The corresponding source (i.e. .cc file) file must be in the analysis/src directory with all the analysis functionality.

If you are creating a new anlysis you'll need to tell the rest of the software about it. Once you have created someAnalysis.h and someAnalysis.cc files the code must be introduced in the driver.cc file in the PATH_TO_ANALYSIS directory. The analysis must be added to the set of included files at the begining of the file (e.g. #include "someanalysis.h") and added to the list of possible analyses in the allAnalyses function (e.g. config.addAnalysis(new SomeAnalysis, "someanalysis", dut);).

The last thing to do is mention the new analysis in the Makefile so that it is compiled along with the rest of the software. You must add a .o mention (e.g. someanalysis.o to the ANALYSIS section of the Makefile.

After any changes the code must be recompiled:

> make

Then, supposing you have gone through all the steps required before running analysis algorithms* (here) you can run your custom analysis like any other task:

> ./tbmon -s/r/l RUN_NUMBER(s)/RUN_LIST -a ANALYSIS_TASK -c CONFIGURATION_SET

* Changes made only to analysis will not require rerunning of hotpixelfinder, checkalign, getetacorr, checkalign steps.

-- KennyWraight - 2013-06-11