MNT: Update HIT L1b livetime calculation

[greglucas]

Change Summary

Overview

The livetime calculation should follow a 3-segment polynomial which was updated in the algorithm document.

closes #2356

[greglucas]

@gmitch3088 there are failures in the validation data now. Do you have new validation data you are expecting with this update, or should it match the previous validation data for count rates? With this update the count rate is ~100x higher than it was before.

E               AssertionError: 
E               Not equal to tolerance rtol=1e-07, atol=0.001
E               Mismatch in coinrates at frame 0
E               Mismatched elements: 18 / 26 (69.2%)
E               Max absolute difference among violations: 27937.05454687
E               Max relative difference among violations: 53.96104344
E                ACTUAL: array([1.626847e+01, 0.000000e+00, 1.179464e+02, 4.250137e+02,
E                      1.303511e+03, 5.083896e+00, 1.931881e+01, 3.064573e+03,
E                      6.507387e+02, 1.016779e+00, 1.016779e+00, 2.033559e+00,...
E                DESIRED: array([3.00000e-01, 0.00000e+00, 2.17400e+00, 7.83400e+00, 2.40270e+01,
E                      9.40000e-02, 3.56000e-01, 5.64890e+01, 1.19950e+01, 1.90000e-02,
E                      1.90000e-02, 3.70000e-02, 0.00000e+00, 0.00000e+00, 0.00000e+00,...

[vmartinez-cu]

Nice implementation of the different calculations using boolean masks. Putting this in a function would make it easier to write a unit test for it

[gmitch3088]

This looks to me to be in the right place, but @vmartinez-cu can confirm.

[vmartinez-cu]

There are some tests that still use the old calculation. It would be good to update them. Example

[vmartinez-cu]

@gmitch3088 there are failures in the validation data now. Do you have new validation data you are expecting with this update, or should it match the previous validation data for count rates? With this update the count rate is ~100x higher than it was before.

E               AssertionError: 
E               Not equal to tolerance rtol=1e-07, atol=0.001
E               Mismatch in coinrates at frame 0
E               Mismatched elements: 18 / 26 (69.2%)
E               Max absolute difference among violations: 27937.05454687
E               Max relative difference among violations: 53.96104344
E                ACTUAL: array([1.626847e+01, 0.000000e+00, 1.179464e+02, 4.250137e+02,
E                      1.303511e+03, 5.083896e+00, 1.931881e+01, 3.064573e+03,
E                      6.507387e+02, 1.016779e+00, 1.016779e+00, 2.033559e+00,...
E                DESIRED: array([3.00000e-01, 0.00000e+00, 2.17400e+00, 7.83400e+00, 2.40270e+01,
E                      9.40000e-02, 3.56000e-01, 5.64890e+01, 1.19950e+01, 1.90000e-02,
E                      1.90000e-02, 3.70000e-02, 0.00000e+00, 0.00000e+00, 0.00000e+00,...

@gmitch3088, for context this validation data is the instrument validation data, not the fake data you produced. This test was written before you began validating against the fake data. It's still a helpful check for changes to the processing code

[gmitch3088]

@gmitch3088 there are failures in the validation data now. Do you have new validation data you are expecting with this update, or should it match the previous validation data for count rates? With this update the count rate is ~100x higher than it was before.

E               AssertionError: 
E               Not equal to tolerance rtol=1e-07, atol=0.001
E               Mismatch in coinrates at frame 0
E               Mismatched elements: 18 / 26 (69.2%)
E               Max absolute difference among violations: 27937.05454687
E               Max relative difference among violations: 53.96104344
E                ACTUAL: array([1.626847e+01, 0.000000e+00, 1.179464e+02, 4.250137e+02,
E                      1.303511e+03, 5.083896e+00, 1.931881e+01, 3.064573e+03,
E                      6.507387e+02, 1.016779e+00, 1.016779e+00, 2.033559e+00,...
E                DESIRED: array([3.00000e-01, 0.00000e+00, 2.17400e+00, 7.83400e+00, 2.40270e+01,
E                      9.40000e-02, 3.56000e-01, 5.64890e+01, 1.19950e+01, 1.90000e-02,
E                      1.90000e-02, 3.70000e-02, 0.00000e+00, 0.00000e+00, 0.00000e+00,...

@gmitch3088, for context this validation data is the instrument validation data, not the fake data you produced. This test was written before you began validating against the fake data. It's still a helpful check for changes to the processing code

Sorry, I missed this. This is expected as the fake validation data assumed that the max was 270 (c.f. the old algorithm). So in the first minute in which the livetime counter was 250, the livetime fraction previously would have been ~0.926 whereas with the new algorithm, it is ~0.149 (similarly, for the second point that has a livetime counter of 188, the previous livetime fraction would be ~0.696 whereas with the new algorithm it is ~0.146). Let me know if you have any questions!