You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 50 Next »

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

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.

 

Gain intercalibration procedure

The procedure for CAL gain intercalibration at PS and SPS is based on the
we've been looking at the calibration runs 700001789-700001863 using the cal
tuples, to check the constants obtained at PS (towers 2 and 3), especially for
HEX8 for which the lever arm in energy deposit was not so large (for the moment
let's forget about tower 1 for which LEX1/HEX8 was not calibrated at PS).

To intercalibrate gains of each given log end, we sum almost (see below) all
runs available and fit the profile histogram of s_i (signal for gain #i) vs
s_i+1 (signal for gain #i+1) to get the slope. This profile is limited to the
events where 1/ s_i does not saturate 2/ s_i+1 < saturation value of s_i and 3/
the ratio s_i/s_i+1 is close to 1 within 30%. In addition, for the logs at the
center of a module, we don't keep 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.

Let's indeed take the example of tower 2 and the 4+4=8 logs at the center in X
and Y direction (columns 4 to 7): for those we only keep the scan positions 5 to
8 (the scan position range from 1 to 12). Please have a look at pages 4 to 10
of the file in attachment:

- page 4 shows the plots for layer 6, col 5 and side 1 (L6-X5-S1). The 4 plots
at the top are the spectra (summed over all runs) for each range (R0=LEX8, ...
R3=HEX1). The 6 plots at the bottom are R0 vs R1 (scatter plot on the left) and
R0/R1 (distribution on the right), R1 vs R2 and R1/R2, R2 vs R3 and R2/R3. Here
all plots are fine.

- page 5: same plots for the other end of the log (L6-X5-S0): here 2 populations
are clearly visible in the R1 vs R2 plots

- page 6: L6-X5-S0 w/ Y scan runs only; still the same problem
- page 7: L6-X5-S0 w/o the Y scan position number 7 (run 700001796); now it's ok
- page 8: L6-X5-S0 for run 700001796 only: here is the 2nd population

We have found some other cases like this one. Note that the effect is of the
order of a few %, as you can see in page 10 which gives the fitted slope value
for each channel (left column, points in red): the plot on the left in the
middle show that LEX1/HEX8 slope is close to 1 (a bit less), somtimes as low as
~0.95 or even 0.93 for a few logs.

I am investigating these small discrepancies by looking at the dependency of
each slope as a function of run number, however I dont see anything else that
such a systematic study to delimit them (this effect which is not geometric and
only seen on a few log ends like L6-X5-S0). Would you have any other idea ?

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)

Tile Recon

Number of PE

Plot

Comment

0

14.9

pe_tile0.gif

 

100

29.15

pe_tile100.gif

2 Channels combined as suggested by Alex

110

16.78

pe_tile110.gif

 

120

34.73

pe_tile120.gif

 

130

25.32

pe_tile130.gif

 

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"

  • No labels