search

XENON1T / pax

The XENON1T raw data processor [deprecated]
BSD 3-Clause "New" or "Revised" License
16 stars 15 forks source link

Update tight-coincidence definition #737

Closed JosephJHowlett closed 4 years ago

JosephJHowlett commented 4 years ago

This changed the definition of peaks' tight-coincidence. Previously, tight-coincidence was the number of hits whose maximum amplitude occurs within tight_coincidence_window of the peak's maximum amplitude. In this PR, it is changed to the number of hits whose mean occurs within tight_coincidence_window of the peak's mean. For peaks of a given size, this should reduce the variance of the tight_coincidence statistic. The plot shows the improvement in S1 acceptance for a few window sizes (window_left = window_right = window). We also expect reduced pileup of random hits for a given window, since the window isn't smeared out as much.

The PR also saves the tight-coincidence number for a few symmetric window sizes (30ns, 40ns, 50ns), while using the left and right windows from the config for classification.

modify_tight_coincidence_200329

JosephJHowlett commented 4 years ago

To decide the impact of this, maybe @zhut19 can check the lone-S1 rate by processing a bit of data on this branch.

zhut19 commented 4 years ago

We see the lone-s1 doubled given this pr shown in the following table, we believe the extra lone-s1s are very likely to be pileup as real s1 rate is not expected to double like this.

Lone S1 w/o this pr w/ this pr
Both Arraies 9.6 Hz 15.7 Hz
Only Bottom 2.8 Hz 4.6 Hz
feigaodm commented 4 years ago

thanks for the effort! Since it's not helping, let's close it.