Top and bottom timing parameters at event and peak level

[terliuk]

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

This PR adds plugins computing timing parameters (center time, rise time, 50% and 50% ranges) at peak level as well as event level, depending on needs of an individual analyst.

Can you briefly describe how it works?

Technical remark, in order to compute parameter, it forms "fake peaks" based on data_top for top array or (data - data_top) for bottom array. And then reuses the quantile calculation from strax to avoid unnecessary code duplication.

To get parameters at peak level, one needs to run:

st.get_array(run_id, 'peak_top_bottom_params')

which will return fields

• center_time_top, center_time_bot
• rise_time_top , rise_time_bot
• range_50p_area_top, range_50p_area_bot
• range_90p_area_top, range_90p_area_bot
  with definitions the same as in peak_basics.

To get it at event level one needs:

st.get_array(run_ids, "event_top_bottom_params")

which will provide the similar fields, but for main/alt s1/s2 forming the event, e.g. s1_rise_time_top, alt_s2_center_time etc.

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

Few plots from few Kr83m runs:

time difference between top and bottom center times as function of Z:

or rise time of bottom array

Please include the following if applicable:

• Update the docstring(s)

[coveralls]

Coverage increased (+0.04%) to 93.971% when pulling cdd153d on top_bottom_parameters into 1a4a294 on master.

[FaroutYLq]

Something general idea: do we want to put the parameters in peaklets level instead of above peaks, so these info can be used in peak classification?
nvm I was saying something stupid.

[FaroutYLq]

Looks good to me! Check here for plots.

[JoranAngevaare]

Thanks Andrii for the PR and Lanqing for the nice review!