Waveform Time of Maximum Calculation

[Cormed-Mack]

Hi, I'm Cara Dignam I work at IRAP on NectarCam.

The calculation of the peak time in /src/ctapipe/image/extractor.py extract_around_peak() produces peak times that are off by around 0.8-1.0ns. I tested the code with some simulated waveforms from the NectarCam camera, we get a consistent difference of 0.8-1.0ns in the peak time calculation when compared to other methods. I tested four different methods of determining the peak time and a cubicspline interpolation of the waveform with 0.1ns samples and then finding the peak time of the interpolated waveform seems to work the best. I've included my results from a presentation I gave to the nectarcam collaboraiton. Is it possible that the calculation can be changed based on this?

NectarCam SciSoft Meeting-ToM Analysis.pdf

[maxnoe]

Hi @Cormed-Mack

The peak_time is not necessarily defined to be the maximum, there are many different possible definitions and the maximum is not always the best reference.

The definition in extract_around_peak uses a definition originally coming from I think MAGIC, which is the average of the sample time weighted with the sample's amplitude. Others use e.g. the half-height of the maximum on the rising edge, or the inflection point, or ...

ctapipe/src/ctapipe/image/extractor.py

Lines 128 to 136 in 2a4b881

	i_sum = float64(0.0)
	time_num = float64(0.0)
	time_den = float64(0.0)
	for isample in prange(start, end):
	i_sum += waveforms[isample]
	if waveforms[isample] > 0:
	time_num += waveforms[isample] * isample
	time_den += waveforms[isample]

Depending on the pulse shape in question, this will usually not be the same as the maximum.

[Cormed-Mack]

hi @maxnoe
We have a quantity in NectarCam we refer to as the "Time of Maximum" (ToM) I'm not sure of it's use in other systems, but for our timing analysis of the camera system we are required to know when the waveform reaches it's maximum for checking our trigger systems and timing uncertainty and whatnot, so presumably, this "peak time" here is not representative of this "Time of Maximum"?
Also thank you for your fast reply!!

[maxnoe]

No, this is by design not an estimate of the maximum of the waveform.

I'm also not aware of any telescope-level requirements that explicitly refer to the maximum of the waveform.

[maxnoe]

we are required to know when the waveform reaches it's maximum for checking our trigger systems and timing uncertainty and whatnot,

Wouldn't for the trigger system not be the time when the signal reaches a trigger threshold be more relevant than the time of the maximum?

[maxnoe]

You could probably tune the extractor settings though (window shift and window width) so that the peak_time average better corresponds to the maximum.

[maxnoe]

We also have an issue about providing additional metrics about the the waveforms:

• Extracting pulse width #1243
• FWHM #2124 (specifically about full-width-half-maximum)

and a corresponding PR that has been stale for some time: #2151

We would still be happy about including such information optionally in the output

[Cormed-Mack]

Yes, I might be wrong about the trigger actually, I've only worked with the timing uncertainty and ToM, I'll have a conversation with the collaboration and get back to you! Thank you for your answers!

[Cormed-Mack]

I might ask, as I've not heard this before, why not calculate the time of maximum of the waveform? Why is the peak_time using this weighted average? Is it just because it's quicker to calculate?

[maxnoe]

Usually, it's better determined than the maximum. As you found, simply using the argmax does not give you sub-sample precision, while the average give this without expensive interpolation or other such operations to determine a maximum with sub-sample precision.

I think that's the main motivation.