...
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.
...
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
we've been looking at the calibration runs 700001789-700001863 using the cal
tuples, to check the 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 (for the moment
let's forget about 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 sum summed almost (see below) all
runs available and fit (to maximize the statistics) and fitted the profile histogram of sR_i (signal for gain #i) vs
sR_i+1 (signal for gain #i+1) to get the slope. This profile is limited to the
events where 1/ s a) R_i does not saturate 2/ s, b) R_i+1 < saturation value of sR_i and 3/
c) the ratio sR_i/sR_i+1 is close to 1 within 30%. (within a band parallel to and centered on the y=x line).
In addition, for the logs at the
center of a module, we don't keep 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.
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
, 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) for in each energy range (R0R_0=LEX8, ...
R3R_1=LEX1, R_2=HEX8, R_3=HEX1) . The while the 6 plots at the bottom are R0 vs R1 R_i vs R_i+1 (scatter plot plots 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.
, 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).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é
...