Better Fitting of Ultra Latency Scans

[bdorney]

Description

Changes to anaUltraLatency.py

The fitting performed in anaUltraLatency.py leaves something to be desired. In this PR the functionality is changed such that the latency distributions are not fit by default. Instead three new options are added to anaUltraLatency.py:

• -f, --fit flag to perform fit,
• --latSigRange comma separated pair of integers specifying the range of the signal in an N vs. Latency distribution, and
• --latSigMaskRange comma separated pair of integers specifying the portion of an N vs. Latency distribution to not consider as noise

If an example signal range is given as --latSigRange=41,42 and --latSigMaskRange is not specified the default behavior is then treated as latSigRange_Min-1 and latSigRange_Max+1, so [40,43] in this case.

These parameters will then be used to fit the latency distributions for the purpose of determining:

• True signal count in the lat range specified, and
• Signal over noise ratios.

Example workflow is now:

1. Analyze an ultraLatency.py output file,
2. Look where the muon peak is in the output distributions,
3. Re-analyze the ultraLatency.py output file using the --fit, --latSigRange, and --latSigMaskRange options to perform the fitting.

Example syntax for steps 1 & 3:

anaUltraLatency.py -iLatencyScanData.root
anaUltraLatency.py -iLatencyScanData.root --fit --latSigRange=43,46 --latSigMaskRange=40,48 --debug

Note using the --debug with the --fit flag will cause a table of VFAT\tSignal\tSignalOverNoise to be printed to the terminal.

Changes to ana_scans.py

Subsequent parameters have been added to ana_scans.py to extend the new functionality of anaUltraLatency.py. In this case they are:

• --latFit
• --latSigRange, and
• --latSigMaskRange.

Again one should first analyze a latency scan, look at the output to determine the fit ranges, and then re-analyze the scan. Example calling syntax:

ana_scans.py --anaType=latency --scandate=2017.08.31.15.46
ana_scans.py --anaType=latency --scandate=2017.08.31.15.46 --latFit --latSigRange=43,45 --latSigMaskRange=40,48

Changes to plot_eff.py

The possibility to use the true signal count obtained from the latency fitting in calculation of efficiency with plot_eff.py has also been added.

The previous functionality still exists using syntax:

plot_eff.py --infilename=listOfScanDates_eff_vt1bump0.txt --vfatList=4,12 --latSig=44 --print                      

But to now use the true signal counts to measure the efficiency first analyze the latency ultra scans of interest, then use the --bkgSub argument in place of the --latSig argument:

[dorney@cosmicstandtif]~/scratch0/CMS_GEM/CMS_GEM_DAQ/gem-plotting-tools% plot_eff.py --infilename=listOfScanDates_eff_vt1bump0.txt --vfatList=4,12 --bkgSub --print 

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [X] Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context

Fitting in anaUltraLatency.py could not accurately determine signal to noise ratios.

How Has This Been Tested?

I performed the analysis.

Screenshots (if appropriate):

From using ana_scans.py to re-analyze data. Note in Summary.png the green line is a fit to the defined signal region (argument of --latSigRange) and the red line is a fit to the noise region with the defined signal region masked (argument of --latSigMaskRange).

From plot_eff.py using the --bkgSub flag.

Checklist:

• [X] My code follows the code style of this project.
• [X] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [X] I have added tests to cover my changes.
• [X] All new and existing tests passed.

[bdorney]

As you can see:

https://twiki.cern.ch/twiki/bin/view/CMS/GEMDOCDoc#How_to_Produce_Scan_Plots_Taken

Under the heading "Analyze a latency scan" the instructions for this have already been updated and provided to the DOC.

[cbravo135]

I was referring to plot_eff.py which seems to require anaUltraLatency to already be ran, though I am not exactly sure what the work flow is because I haven't looked at it carefully enough.

[bdorney]

I was referring to plot_eff.py which seems to require anaUltraLatency to already be ran, though I am not exactly sure what the work flow is because I haven't looked at it carefully enough.

That's not true, plot_eff.py was added in commit: 64015fbc137706303e4b2a0ec2544bb87508f68b (19 days ago). It can run on a raw file produced by vfatqc-python-scripts/ultraLatency.py. The latTree must be analyzed by anaUltraLatency.py only if the --bkgSub option is supplied. The help menu of this option specifically states the file must have been analyzed by anaUltraLatency.py as shown here.

Moreover if the user does use the --bkgSub option and has not run anaUltraLatency.py then plot_eff.py will tell the user that they did analyze the output from ultraLatency.py correctly, as shown here.

Finally, I doubt that plot_eff.py will be used anywhere but an expert level test stand with a very specific trigger configuration.