Add fix integration window for the noise runs

[GiovanniVolta]

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?

The decreasing occupancy shown in Peak finding a plugin for LED calibration processing is because the integration window of the noise run is moving too much inside the waveforms.

See here below the case for PMT 0:

Can you briefly describe how it works?

Given that the pulser can/is causing some noise in the waveforms in coincidence with the LED (therefore it is fully caught by the LED on-runs integration window), it is better to place the integration window of the LED off-runs (aka noise runs) in proximity to where we would expect the LED.

The pulse is delayed by ~990 ns WRT the DAQ (see here). Therefore the expected_led_position is placed at 98 ADC sample.

Although the delay between the pulser and the DAQ, we suggest putting the fixed integration window at 98 ADC. This led to some instability in the occupancy for certain calibration campaigns. Empirically, a fixed integration window defined starting from the 88 ADC sample gives more stable results. The finding are summarized in the note.

Note that the check I performed was done with the fixed position at 86 ADC sample, but we have determined that the position of the integration window for the noise has an impact of 1% on occupancy and gain estimation.

To discriminate between the noise and the led runs, we used the comments from the run_doc. The noise runs have always (thanks to the automatic script for the LED calibration) the 'SPE_calibration_step0', 'Gain_calibration_step3'.

I check this using the LED-on run '054597' (Gain_calibration_step2) and the LED-off run '065876' (Gain_calibration_step3) with some ad-hoc print:

As you can see the noise run has the integration window defined starting from the fixed positon.

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

The gains' stability and dependence on the position of the fixed integration window for the nose runs are discussed here.

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]

Hi quick comment. Can you link a notes next to the default expected_led_position and minimum_hits_requirement in annotation?

[GiovanniVolta]

This is the draft PR for fixing the issues causing the downward trend in occupancy. I need to make the plots and update the notes.

@tflehmke, please have a look and check it independently.

[coveralls]

coverage: 90.208% (-0.004%) from 90.212%
when pulling ccb77ec on fix_integration_window_for_noise
into 3213160 on master.

[GiovanniVolta]

I have further checked the impact the fixed integration window for the noise on the occupancy and gain.
I have summarized here
In a few words:

• the position of the window as a <2% impact on the estimation of the occupancy and gain
• the more stable condition (stability of occupancy and gain for different lengths of the integration window) is achieved by defining expected_led_position to 88 ADC

It is unclear why we have this behavior, and I would like @tflehmke , @sanaouahada, and @MaxiA04 to keep looking into it. Given the impact is within the 2.5% value that we use to model the time trend of the gain, I would suggest moving on.

[dachengx]

We should replace the minimum_hits_requirement by the tagging, like https://github.com/XENONnT/cutax/blob/87f4d25a2bd36cbb96fefab26c00bc3779b47396/cutax/utils.py#L190. The tag can tell us which run is a noise run.

[dachengx]

I hope the new push will work, and it looks good. Here are some small not fatal points that would be good to fix along with future push. They are not urgent.

[dachengx]

This line is a very good implementation! @GiovanniVolta