• Created by Unknown User (sanchez), last modified on Jun 20, 2008

Python script for LAC, FLE, FHE

I wrote a python script to easily run the code (genHists* and fit* and monitoring code) for LAC, FLE, FHE. It also plot threshold distribution if asked.
The script is located here : /a/sulky36/g.glast.u33/sanchez/CALcalib.py

Documentation

usage : python CALcalib.py -P-D-M Mode
where -P : plot results
-D : Print this doc and stop
-M : PLot Monitoring run : FLE FHE only, This option bypass Mode option
where Mode is : - LAC

  • FLE
  • FHE
  • ALL
    where Tag is the ouput basename

A script only to plot threshold distribution (/a/sulky36/g.glast.u33/sanchez/PlotRun.py)

Documentation

usage : python PlotRun.py -D-M Mode Tag
where -D : Print this doc and stop
-M : PLot Monitoring run : FLE FHE only, This option bypass Mode option
where Mode is : - LAC

  • FLE
  • FHE
  • ALL
    where Tag is the ouput basename

First look at genTrigMonitorHists and fitTrigMonitorHists

Zach wrote a code to monitor FLE and FHE threshold with nomSciOps runs. We used run 077018082.

PED : digitization-licos-v3r9p3_077014293_digi_DIGI.FLIGHT_GAIN.calPed.txt
MuSlope : digitization-licos-v3r9p3_077014313_digi_DIGI.FLIGHT_GAIN.muSlope.txt

The following figure shows threshold values. We have two populations : low energy should be FLE threshold value and hight energy FHE threshold. For FLE the mean value is around 150 Mev. There is not enough statistic for FHE threshold.

The code works find at SLAC. I have some issues to run it on my laptop sue to version conflict)

A look at the new version of the code with nomSciOps runs.

We used run 077018082.
PED : digitization-licos-v3r9p3_077014293_digi_DIGI.FLIGHT_GAIN.calPed.txt
MuSlope : digitization-licos-v3r9p3_077014313_digi_DIGI.FLIGHT_GAIN.muSlope.txt

Zach made some changes in the code to be less sensitive to the trigger noise. The main change is a better definition of 'firstNonZeroBin' variable. Here is part of his mail.

Basically I have replaced David's 'firstNonZeroBin' variable w/ a 'firstBin>15%max' which should serve the same purpose - it should avoid sensitivity to any noise triggers in the LAC circuit.

Also I have a gemDeltaEventTime < 500 microseconds cut in genLACHists.exe which should also reduce noise hits.

Also I restricted the threshold fit parameter, making it a little more stable.


LAC value distribution for run 077018222. The new code greatly improve the fit. Only few LAC value are obviously not found.

LEX8 signal histograms for 2 channel badly fitted


LEX8 signal histogram for crystal T3L5C8 which was badly fitted with previous version.

Impact on LAC runs, TVAC run 077016907.

There is no major impact. Fitted LAC values remain almost the same.

Using sasha's code

I have use sasha's code with run 077018222. I put his code in cmt and was able to compile it.

I used fill_LAC_hists.C to make histogram and plot_lac_all_channels.cxx to make the following plot.

Next step

Use : fit_lac_thresh.cxx and compare result with the new version of the GR analyze chain.

Conclusions

We are ready to monitor LAC, FLE, FHE threshold.

training with run backgnd-GR-v15r0-2

h.3 GR code
We train with a simulated run.
PED : digitization-licos-v3r9p3_077014293_digi_DIGI.FLIGHT_GAIN.calPed.txt
MuSlope : digitization-licos-v3r9p3_077014313_digi_DIGI.FLIGHT_GAIN.muSlope.txt

We fit LAC threshold for the NEG face.


LAC distribution for NEG face obtained with Zach code

change in the code

We change firstBin > 15%max by firstBin > 20%max. Without this, the code rise an exception.

h.3 python script to monitor

FLE/FHE distribution obtained with the monitoring code


CalMaxEne>>hflenofhe","CalMaxEne>0 && (GemConditionsWord==4 || GemConditionsWord==5 || GemConditionsWord==6 || GemConditionsWord==7)


CalMaxEne>>hnoflefhe","CalMaxEne>0 && (GemConditionsWord==8 ||GemConditionsWord==9 || GemConditionsWord==10 || GemConditionsWord==11)


CalMaxEne>>hflefhe","CalMaxEne>0 && (GemConditionsWord==12 || GemConditionsWord==13 || GemConditionsWord==14 || GemConditionsWord==15)


CalMaxEne>>hnoflenofhe","CalMaxEne>0 && (GemConditionsWord==1 || GemConditionsWord==2 || GemConditionsWord==3 )

Finding LAC value with nomSciOps runs

Warning

This part is no more relevant since Zach changed the 'firstNonZeroBin' variable

Berrie and I (David Sanchez) had a look at how the code works with nomSciOps runs.
We found that some events have direct diode deposit on the opposite face. This case is not yet taking into account in the code that generated LAC histogram leading to bad LAC value.

This plot is the LAC value distribution for run 077018222. X axis is p0-Ped . We used the following configurations files:

PED : digitization-licos-v3r9p3_077014293_digi_DIGI.FLIGHT_GAIN.calPed.txt
MuSlope : digitization-licos-v3r9p3_077014313_digi_DIGI.FLIGHT_GAIN.muSlope.txt

All files can be found at /afs/slac.stanford.edu/g/glast/ground/releases/calibrations/CAL/LAT-flight_gain/


This is the LEX8 signal histogram for tower 9, layer 4, crystal 0 Face 1. X axis is ADC value . This crystal is one with weird LAC value. This is due to non-empty low energy bin. In fact the fitting procedure use the first non-empty bin as a reference. In such case, this first bin is not relevant. To tackle this issue we have modify the code that generate LAC histograms to cut the events with direct diode deposit.

the following plot are LAC value distribution and LEX8 signal histograms for the same run and crystal

It remains no bad value. It is probably useful to modify all scripts generating LAC, FLE, FHE histograms to take this case into account.

  • No labels

2 Comments

  1. Unknown User (fewtrell)

    genFLEHists.exe & genFHEHists.exe calibGenCAL applications already have the asymmetry cut (see LPAFheAlg.cxx & LPAFleAlg.cxx).

    In fact the cut is only one way, ie

    if (current_face_signal/opposite_face_signal > 3) then continue

    I think the opposite condition (< 1/3) indicates a direct deposit on opposite face, which would not affect the current face's trigger. 

  2. Unknown User (fewtrell)

    Looking good, a few comments, orgainized by section:

    First look at genTrigMonitorHists and fitTrigMonitorHists

    During my analysis, fitTrigMonitorHists had trouble fitting the spectra sometimes, and would miss the threshold entirely.  Maybe someone else can improve on it.  Otherwise great.

    Finding LAC value with nomSciOps runs

    It appears that you are still not running Sasha's code which
    was intended specifically for nomSciOps data.  As you can see from some of the plots, the thresholds are poorly defined because the instrument OR's both faces together. 
    It appears that the main problem in T6L6C0F1 and T3L5CF1 is the firstBin > 15% max is being confused by noise hits @ 20% max.  simply raising this threshold to maybe 30% would likely improve the fits.