Calibration

How to change the calibration constants used by recon?

(by Dave Smith, for the CAL case. )  There are 5 types of CAL calib.xml files, called

• asym   = light asymmnetry

• ci_intnonlin = integral non linearity

• peds = pedestals

• mpd = MeV per DAC

• thold.  = thresholds

These files are in $LATCalibRoot/CAL/CU06.

If you have new .xml files then the first thing to do is to copy them to that directory.

Don't have write privileges there? Then contact me or Johan Bregeon or Anders. In a hurry and none of them are available? Then try Johan Cohen-Tanugi, Joanne Bogaert, Richard Dubois.

Your next step is to enter the new files names into the RDB metadata database. If you're not in a flaming hurry, it's best to have one of us "experts" do it. 

But if we're unavailable, then log on to noric (or whatever machine your rdb MySQL system is) and type rdbGUI-new.

There is documentation, see

http://www.slac.stanford.edu/exp/glast/ground/software/notes/rdbGui/rdbGui-use.shtml

Older but still of some merit is the following.

http://www.slac.stanford.edu/exp/glast/ground/software/calibration/docs/mysqlDirect.shtml;

Once you've mastered rdbGUI and you've added your file names to the metadata database, triple check your entries. It is very important that vstart be consistent with the data you want (re-)processed. If your calibrations are to supersede older calibrations, that is, render the old ones obsolete, then YOU MUST CHANGE THE PROC_LEVEL FROM PROD TO SUPSED for the old file names.

If you have spaces, typos, invisible characters in your file names, it will CRASH THE PIPELINE so before you update the rdb database, send e-mail to francesco.longo@ts.infn.it  (and copies to focke@slac.stanford.edu   borgland@slac.stanford.edu).  They may ask you to wait for a less critical time(it's the same pipeline for TVAC, you know). Remember, you can use PROC_LEVEL DEV or TEST to run your own reconstruction if you don't want to wait for the pipeline.

Okay, it won't actually crash the whole pipeline, just those jobs that look for non-existing calibration files. Coordinating with the pipeline caretakers before you make a change will help them be alert to why many jobs are suddenly failing...

How to find out which calibration constants were used ?

Example : CAL calib constants

Here's one way (by Dave Smith).  From the eLog, click on "list root files" to find the name of the directory on noric where the recon files are. In that directory, you can do a grep. For example,

dsmith@noric06 $ cd /nfs/farm/g/glast/u37/BeamTest06/rootData/700000698/v4r0909p2/recon

dsmith@noric06 $ grep asym *.log
recon-v1r030603p4_700000698_00000-07469.log:XmlBaseCnv           INFO successfully parsed document $(LATCalibRoot)/CAL/CU06/mc_asym.jun8th2006.CU_pass1_Pisa.xml aka /afs/slac.stanford.edu/g/glast/ground/releases/calibrations//CAL/CU06/mc_asym.jun8th2006.CU_pass1_Pisa.xml
recon-v1r030603p4_700000698_07470-14939.log:XmlBaseCnv           INFO successfully parsed document $(LATCalibRoot)/CAL/CU06/mc_asym.jun8th2006.CU_pass1_Pisa.xml aka /afs/slac.stanford.edu/g/glast/ground/releases/calibrations//CAL/CU06/mc_asym.jun8th2006.CU_pass1_Pisa.xml
recon-v1r030603p4_700000698_14940-22409.log:XmlBaseCnv           INFO successfully parsed document $(LATCalibRoot)/CAL/CU06/mc_asym.jun8th2006.CU_pass1_Pisa.xml aka /afs/slac.stanford.edu/g/glast/ground/releases/calibrations//CAL/CU06/mc_asym.jun8th2006.CU_pass1_Pisa.xml
dsmith@noric06 $

You can do the same for the other 4 types of CAL calib.xml files that are used in recon, e.g.  ci_intnonlin, peds, mpd, thold.

CAL calibrations - XTalk And Charge Injection

Trending calibGenCal outputs

Here is the trending of calibGenCal outputs for the 3 CU CAL modules. Three time phases are included: NRL (pre-CU) and Pisa (2 phases). The 3 files are FM109, FM119and FM101. Asymmetry amplitudes are VERY stable while slight variations are observed for pedestal position (up to ~10 ADC units, ~5 ADC units in average) and MeV/DAC (up to ~4%, ~1.5% in average), due to the change of power supply in Pisa.

Trending CPTs

Here is the trending of the 3 CU CAL module performances from CPTs taken at Pisa (2 suites) and at CERN (PS and SPS). The 3 files are FM109-Pisa-PS-SPS, T02-FM119-Pisa-PS-SPSand T03-FM101-Pisa-PS-SPS for all time phases, and FM109-PS-SPS, T02-FM119-PS-SPSand T03-FM101-PS-SPS for the CERN phases only. Performances are found to be VERY stable at CERN, with slight differences wrt Pisa phases (for instance LE+/LE- diode ratio variation up to ~5%, ~2% in average), again due to the change of power supply.

Here are the same plots for PS, SPS and GSI phases: FM109-PS-SPS-GSI, T02-FM119-PS-SPS-GSIand T03-FM101-PS-SPS-GSI. No change was found.

Gain intercalibration procedure at SPS

The procedure for CAL gain intercalibration at PS and SPS uses the CalTuple of all 4-range readout runs taken at different scanning positions. It is based on the signal (in MeV) stored in the CalXtalFaceSignalAllRange[tower][layer][column][side][range] array. At SPS we checked the constants obtained at PS (towers 2 and 3), especially for HEX8 for which the lever arm in energy deposit was not so large at PS. We also calibrated tower 1 for which LEX1/HEX8 was not well calibrated at PS.

To intercalibrate gains of each given log end, we summed almost (see below) all runs available (to maximize the statistics) and fitted the profile histogram of R_i (signal for gain #i) vs R_i+1 (signal for gain #i+1) to get the slope. This profile is limited to the events where a) R_i does not saturate, b) R_i+1 < saturation value of R_i and c) the ratio R_i/R_i+1 is close to 1 (within a band parallel to and centered on the y=x line).

In addition, for the logs at the center of a module, we first ignored the runs corresponding to scan positions near their end to avoid direct illumination of the diodes due to beam and shower spread (in that case the scatter plots are a mess...). Despite these criteria, some weird features were observed, e.g. for the log end T2-L6-X5-S0 (i.e. tower 2, layer 6, column 5, side 0): in this file the 4 plots at the top are the R_i spectra (summed over all runs) in each energy range (R_0=LEX8, R_1=LEX1, R_2=HEX8, R_3=HEX1) while the 6 plots at the bottom are R_i vs R_i+1 (scatter plots on the left, superimposed on the linear fits - in red - of the profile histograms) and R_i/R_i+1 ratios (distributions on the right). Two populations are clearly visible in the R_1/R_2 ratio plot (with a difference of ~7%). The "bad" population was found to arise from one specific scanning position. Since other similar cases were found, new runs were taken at the same scanning positions, but the effect remains and is still not understood. However, we removed it using the following run selection:

• we decided to use only the runs taken in the X (resp. Y) scan to calibrate the Y (resp. X) logs;

• we looked at the dependency of the slope (from the linear fit of the profile histogram) of each log end ratio as a function of run number: in all cases the slope did not change from run to run, except for a very few runs which were then rejected (e.g. run 700001796 for T2-L6-X5-S0 or run 700001795 for T2-L4-X6-S1).

This procedure yielded a list of selected runs for each log end ratio and better results, see e.g. T2-L6-X5-S0. It was applied to all log ends and the results were stored in the following files: tower 1, X logs, tower 1, Y logs, tower 2, X logs, tower 2, Y logs,  tower 3, X logs, tower 3, Y logs. In these files the 96 first pages (one per log end) show the same kind of plots as those described above, and the 3 last pages show the graphs and distributions of the slope, chisquare and crossing value of the linear fit of the 96x3 profile histograms (the crossing value is in MeV and the range of the plots is +-1% of the R_i+1 spectrum maximum). These results show that tower 2 is correctly calibrated. In tower 3, Y logs are correctly calibrated as well, while 2 outliers (T3-L2-X7-S1-R_1/R_2 slope, T3-L6-X4-S0-R_2/R_3 slope) are observed as underflows in the slope distributions of X logs, also visible in the crossing value graph as points with large errors; the individual plots show that the second outlier is due to poor statistics, while the first one should be looked at in much detail (actually we assumed that the calibration is fine here, like for all other logs in tower 3...). Finally in tower 1, X log calibration constants are reliably obtained (1st and 3rd slopes very close to 1, and 2nd slope R_1/R_2 ~1.087 with a RMS of ~0.03), except the R_2/R_3 slopes (not used in data analysis anyway...) in layer 0 due to poor statistics at high energy since showers start deeper in the CAL in the absence of TKR in front of the 1st CAL module; as for the Y logs in tower 1, calibration constants are also reliably obtained, except for T1-L7-X11-S0 which exhibits a strange behaviour (R_1/R_2 and R_2/R_3 slopes were forced to 1 in the absence of any explanation...).

In conclusion, only R_1/R_2 (LEX1/HEX8) slopes for tower 1 were propagated in the DB by modifying the HEX8 MeV/DAC (see below).

Update of CAL calibration constants in DB (Aug 7th) pdf resumé

• A new CAL pedestals (700000953) has been recorded. Zach produced a set of xml files (see $LATCalibRoot/CAL/CU06):

cidac2adc.digitization-latte-v1r030603p2_700000446_digi_DIGI.xml
muonAsym.digitization-latte-v1r030603p2_700000276_digi_DIGI.FLIGHT_GAIN.xml
muonMPD.digitization-latte-v1r030603p2_700000276_digi_DIGI.FLIGHT_GAIN.xml
muonPeds.digitization-latte-v1r030603p4_700000953_digi_DIGI.FLIGHT_GAIN.xml
tholdci.CU06.FLIGHT_GAIN.08022006.xml 

• After intercalibration of LEX1 and HEX8 (from runs 700000700 to 700000750) the asymmetry and MevPerDac files have been updated:

muonAsym.digitization-latte-v1r030603p2_700000276_digi_DIGI.FLIGHT_GAIN_correct_v2.xml
muonMPD.digitization-latte-v1r030603p2_700000276_digi_DIGI.FLIGHT_GAIN_correct_v2.xml

ACD calibrations

CU ACD have basically two calibration parameters for each channel (PMT), 6 in total - MIP peak position and pedestal (both - in ADC bins). Calibration parameters (pedestals, MIP peak positions and tiles light yield) for PS obtained in the 5 GeV pions runs on July 29, and on 150 GeV proton beam on SPS, are given in the attachment\.

Light Yield (Number of PhotoElectrons)

The mean number of photoelectrons per mip is used during Monte Carlo simulations to obtain Poisson fluctuations for the signal collected from a given ACD tile. For Beamtest simulations this acdDigi_CU.xml file has the values that are relevant to the CU. The following instruction should be used in the joboptions file:

AcdDigiAlg.xmlFile = "acdDigi_CU.xml"