ClusteringSpatial with use_trigger_timestamp assigns first trigger of the event
@williamm and I discussed about an issue this morning which occurs in her analysis because of the long events of 2ms she's building with the CLICpix2. We went through the difference of ClusteringSpatial
and Clustering4D
for the Mimosa26.
The summary is the following:
In the EventLoaderEUDAQ2
the pixel times for the Mimosa26 hits are set to the respective trigger timestamp (i.e. the one that triggered the readout of this block of data). This is the best estimate and should be done like this.
Now, when using Clustering4D
, all goes well because all pixel from one readout block have the same timestamp (i.e. the trigger timestamp) and so this is basically the same as spatial clustering + a constraint that the data stems from the same trigger. In the end, the cluster timestamp is set to the average pixel timestamp, which is equal the trigger timestamp. Fine.
When using ClusteringSpatial
instead and enabling use_trigger_timestamp
, the first trigger in the event is used to assign the cluster timestamp. This is problematic when the event (like in Morag's case) has a length of 2ms and many triggers are contained in this event. It would mean that for the tracking, a time cut spanning the entire event (2ms
) needs to be chosen. Instead, when using Clustering4D
a much smaller cut of 230us
can be used.
In turn, if we use ClusteringSpatial
with use_trigger_timestamp=false
, the last pixel added to the cluster defines the cluster timestamp. So this would probably in most cases be the trigger timestamp of the correct trigger as well...but if we by chance cluster pixels from different readout blocks together, it's also completely off...so this shouldn't be used. And this will happen more likely for long events and/or higher occupancies.
What should we do about this? There are the following ideas:
- Use
Clustering4D
and tell everyone to do the same. Problem solved. - Improve
ClusteringSpatial
. However, this is not so simple because in the clustering module, we do not know anymore which trigger was associated to which hit. The only solution would be to extend the pixel object and add a trigger number to it as well - do we really want this? In addition, this would not solve the problem that pixels from two separate M26 readout blocks (triggered by 2 different triggers) are merged into a cluster -- which trigger timestamp to use then? Or extendClusteringSpatial
to be based on trigger number + space? But all this is already done indirectly inClustering4D
.
What do you think? I'm opting for option 1.