Empirical calibration correction, re-locate?

[moralejo]

ctapipe_io_lst/ctapipe_io_lst/calibration.py

Lines 122 to 130 in 67b609d

	calib_scale_high_gain = FloatTelescopeParameter(
	default_value=1.18,
	help='High gain waveform is multiplied by this number'
	).tag(config=True)
	calib_scale_low_gain = FloatTelescopeParameter(
	default_value=1.09,
	help='Low gain waveform is multiplied by this number'
	).tag(config=True)

see also https://indico.cta-observatory.org/event/3052/contributions/25956/attachments/18098/24447/CalibrationScalingFactors_5_10_2020.pdf

These correction factors have two components:

1. one that accounts for the extra "noise" in pulse charge reconstruction, coming from the un-corrected uneven DRS4 sampling, which therefore slightly affects the F-factor method result.
2. one that corrects for the fact that in the F-factor calibration procedure we integrate 12 samples, whereas for the cosmics we integrate 8.

Since here we are calibrating the waveforms, and we should do it such that the full integration results in the true number of p.e., the correction (2) does not really belong here. That correction depends on the integration window used for calibration and for cosmics, so it should rather be applied at a later stage.

I am NOT proposing to change this immediately, but certainly we should do it before we use this event source regularly with ctapipe's stage1 tool. In that case we can use ctapipe's pulse integration correction to take care of (2).

[maxnoe]

@moralejo These values are not used to change the waveforms, they are only filled into the event.calib.dl1 container to be used by the CameraCalibrator as correction when calculating the image.

[moralejo]

Ah, ok, but as said above part of such factors are integration-details specific, so that part does not belong here.

[moralejo]

Not that it is a problem right now, but it is prone to making mistakes.

[FrancaCassol]

Hi @moralejo,

I agree, the first factor (which by the way depends also from the FF integration window) and the 12 ns correction from the calibration side should actually be already included in the calibration constants, the 8 ns correction of the cosmics should be applied later at integration level. Let take it in mind for next

[maxnoe]

@moralejo The problem right now is that the EventSource is the only place where we can let custom LST configuration enter into the ctapipe tools, until a better setup for monitoring information is available, this needs to be filled by the source

[moralejo]

@maxnoe I am not sure I understood. I would put part (1) of the correction in the calculation of conversion factors, as suggested by Franca. Then for (2) we could adopt, also for real data, ctapipe's pulse integration correction. We only need to provide the pulse shape needed by ctapipe for the correction - perhaps this is what you mean that cannot yet be done?

[maxnoe]

@moralejo No, I just didn't understand your proposal fully.

That will work! The pulse template is part of the Subarray description.

[rlopezcoto]

We only need to provide the pulse shape needed by ctapipe for the correction

If I do not recall wrong, this was the part that was problematic for real data, right @FrancaCassol?

[maxnoe]

Only be cause we couldn't deactivate the correction. This is solved since quite some time and we now provide the correct pulse shape and deactivate the correction.

If I understood correctly, we would now change the corrections to be on and calculate the calibration file accordingly.

[moralejo]

Only be cause we couldn't deactivate the correction. This is solved since quite some time and we now provide the correct pulse shape and deactivate the correction.

If I understood correctly, we would now change the corrections to be on and calculate the calibration file accordingly.

Yes, that is the correct solution I think. But I would do that once we move to using stage1.