Fix bug in hitlets time ordering

[dachengx]

Before you submit this PR: make sure to put all operations-related information in a wiki-note, a PR should be about code and is publicly accessible

What does the code in this PR do / what does it improve?

In

straxen/straxen/plugins/peaklets/peaklets.py

Lines 232 to 234 in b1a0884

	hitlet_time_shift = (hitlets['left'] - hitlets['left_integration']) * hitlets['dt']
	hitlets['time'] = hitlets['time'] - hitlet_time_shift
	hitlets['length'] = (hitlets['right_integration'] - hitlets['left_integration'])

hitlet_time_shift is calculated but in

straxen/straxen/plugins/peaklets/peaklets.py

Line 235 in b1a0884

hitlets = strax.sort_by_time(hitlets)

hitlets is sorted, so

straxen/straxen/plugins/peaklets/peaklets.py

Lines 283 to 287 in b1a0884

	hit_max_times = np.sort(
	hitlets['time']
	+ hitlets['dt'] * hit_max_sample(records, hitlets)
	+ hitlet_time_shift # add time shift again to get correct maximum
	)

will mix hitlets with different order in time into hit_max_times.

Additionally,

straxen/straxen/plugins/peaklets/peaklets.py

Lines 291 to 297 in b1a0884

	tight_coincidence_channel = get_tight_coin(
	hit_max_times,
	hitlets['channel'],
	peaklet_max_times,
	self.tight_coincidence_window_left,
	self.tight_coincidence_window_right,
	self.channel_range)

hit_max_times and hitlets['channel'] might not have the same time order.

Can you briefly describe how it works?

The new codes will not set the variable used in get_tight_coin in hitlets['time'] order.

Can you give a minimal working example (or illustrate with a figure)?

Please include the following if applicable:

• Update the docstring(s)
• Update the documentation
• Tests to check the (new) code is working as desired.
• Does it solve one of the open issues on github?

Notes on testing

• Until the automated tests pass, please mark the PR as a draft.
• On the XENONnT fork we test with database access, on private forks there is no database access for security considerations.

All italic comments can be removed from this template.

[FaroutYLq]

Thanks a lot for catching this. The fix looks good to me. I would suggest doing small S1 wfsim and check distribution of S1 tight coincidence to understand the artifact in the most vulnerable scenario.

[FaroutYLq]

Looks good to me now. Thanks!

[coveralls]

Coverage: 93.443% (+0.02%) from 93.418% when pulling 59ad229 on fix_tc_order into b1a0884 on master.