fixed delta peak timestamp problem

[FaroutYLq]

What is the problem / what does the code in this PR do
The (lone hits) delta peaks added to merged_s2s waveforms have wrong time stamp. For example, in the example merged_s2s waveforms below, the red shadow marks peaklets while the blue shadow marks where we expect the lone hits, given the time stamps directly from lone_hits datatype. You can see the lone hits show up in the wrong time.

This PR did a minimal fix to this issue.

Can you briefly describe how it works?

index = (p['time'] - lh_i['time'])//p['dt']

is the problem. Apparently, lone hits' time should show up only after merged_s2s start. This implementation means that index is always negative, leading to a reversed ordering thus mirrored relative timestamp.

Can you give a minimal working example (or illustrate with a figure)?
I think this fix is simple enough to skip this part...

[coveralls]

Coverage remained the same at 91.736% when pulling b292d5a on FaroutYLq:fix_add_lone_hits into e8b03fc on AxFoundation:master.

[JoranAngevaare]

Great catch, must have been introduced in #506!

Thanks a lot Lanqing!

One day we may try again to not merge lone hits in te first place, especially if they are after pulses.

[WenzDaniel]

Thanks for catching Lanqing.

Rearding

One day we may try again to not merge lone hits in te first place, especially if they are after pulses.

One has to be a bit careful to not introduce in that case a z- and area dependent bias. This was one of the issues in the 1T Ar37 analysis as far as I remember.

[WenzDaniel]

Can you update the test such that we do not run into this issue ever again

strax/tests/test_peak_merging.py

Line 56 in d6b3575

def test_add_lone_hits(hits, peak_length):

?

[JoranAngevaare]

@WenzDaniel if we had realized this - the test would have worked. Now it always added zeros.