Comparison of MC and data Abelardo Moralejo Padova

Outline We have compared the data from a few Off Crab data runs from January 27 th with MC protons. 18 data runs: and Total time (not live-time) 231 seconds, zenith angle about 10 deg. Average raw rate ~ 130 Hz Used MC from 0 to 30 degrees (for better statistics) Approximate normalizations of MC and data to obtain rates which can be compared; drawbacks: only protons considered in MC, proton flux uncertainty, no dead time correction in data…

Reconstruction of data Calibration: used F-factor method (as it was in cvs around mid March). Pedestal run 12543, calibration runs Signal extraction with MExtractSignal3: Integration window 6 slices, the same for all pixels, determined event by event from the position of highest non- saturated HG peak. 41 pixels with no valid calibration interpolated using MBlindPixelsCalc2.

Treatment of MC Used preliminary version of camera simulation v 0.7 Several new features implemented: realistic pulse shape from pulpo setup, gaussian blurring of spot PSF (RMS in x and y ~ 3cm), new calculation of pedestal RMS. Tried to set both the gain (ADC counts/photoelectron) and pedestal fluctuations of pixels close to those observed in the data. RMS of pedestal was tuned to be the same in ADC counts (~7.3 and 4.9 for inner and outer pixels resp.) Gains were set to 5 and 1.25 ADC cts / phe, but in the data they have turned out to be more like 8, 1.7 

Treatment of MC (II)  The most relevant consequence is that noise in MC, in photons, is larger than in data. For 6-slice integration, approximate RMS in photons is: MC : 18 (inner) 48 (outer) Data: Patch: we will correct for this by applying higher tail-cuts in data with respect to MC: MC : 4 , 2  Data : 6 , 3  Another (less important) consequence is that saturation will occur at a different light level. BOTTOM LINE: all this has to be redone in any case

Used MC gammas with no added noise as calibration events First loop: relative “calibration” (values simply read from MC headers): inner/outer pixels and hi/lo gain. Calculate Size and correlate with (known # of photons) Second loop: apply obtained conversion factor  MCerPhotEvt MC calibration (mccalibrate.C)

Treatment of MC (III) For all the rest, MC events were reconstructed in the same way as real data (used MExtractSignal3), and the same 41 pixels were treated as faulty and therefore interpolated. Note that the results presented here supersede those in the Padua web page, where for instance different signal extraction methods had been used for data and MC. This is the case even if the agreement between data and MC seems to be worse now in some aspects.

Odd events excluded from data

Spectrum of # of “core pixels” Core pixels: those surviving first cleaning level

Size spectrum Beware: absolute Size scale not more accurate than ~20% (differences in mirror, QE… etc). Y-axis normalization: uncertainty of the same order (same plot in log Y)

“Corrected” Size spectrum Applied a factor 0.77 to MC light values, to account for incomplete mirror dish in data (~10%?) and higher  QE  in MC (0.21 vs estimated 0.18)

Adding cuts in # core pixels

??? BIG mismatch: DIST

LENGTH > 60 core pixels

WIDTH

Energy threshold, MC gammas GeV ?

Effective area, MC gammas Rate estimate for Crab: ~ 6.6 events /min (before cuts). Seems low compared to excesses observed in data (see i.e. Munich analysis) ? Likely explanation: harder cleaning in our analysis. This implies threshold is also overestimated (don’t take these two slides too seriously) Size (corrected *0.77) > 3000 photons > 6 core pixels

To be done in the boot camp Conclusion Up to now the MC does not seem to reproduce well the data. A certain agreement in LENGTH and WIDTH distributions for large events might be just a coincidence, given the large mismatch of DIST. Also large discrepancy in Size for small events. One problem has been identified: different noise level (in terms of photons), but seems unlikely it can account for the discrepancies. Get these 18 data runs checked and analyzed by experts to exclude the possibility of having made some mistake in the calibration… etc. Use latest Mars from cvs. Investigate the reason for the differences, using recently produced camera files with a (hopefully) more realistic noise and QE. New image parameters may be helpful.