Adding the option to save/or not QA-flagged events

[ckierans]

I cherry-picked this from PR #148 since it's much simpler to have this as it's own PR.

I checked this with gse_20250709T113820.hdf for detector HP52358-3 and get 9.3 degrees when we allow QA-flagged events through, and 8.2 degrees when we don't. There's also a loss of ~50% of the events when remove QA-flagged hits. It seems like the majority of these hits that are filtered out with the QA flag are events when the best strip pairing leaves at least one grouping of strips unpaired.

@julianmgerber should compare with his ARM numbers to see if this selection recovers the better ARMs he was seeing before we let these lesser quality events through.

[julianmgerber]

I tried this out with data from 434-1 (gse_20260227T150331.hdf5). When I include QA-flagged events I get an ARM of 9.9 +/- 0.1 deg. When excluding QA-flagged events, I get 9.58 +/- 0.11 deg. However this doesn't improve the ARM all the way to the value I was getting during the original unit level calibration, 9.19 +/- 0.13 deg (which was done on March 6th).

I also tried it on 434-2 data (gse_20260128T103501.hdf5). Again, the ARM I find when excluding QA-flagged events (9.77 +/- 0.16 deg) still doesn't get down to the older unit level calibration number (9.11 +/- 0.15 deg). I also tested a couple different slow thresholds to see if that could be playing a role. When I use a flat 20 keV cut, the ARM (excluding QA-flagged events) is 10.72 +/- 0.1 deg. When I use the actual per-strip calibration file (20260126_LBL_HP52434-2_slow_thresholds_avg.csv), I get a similar value of 10.32 +/- 0.13 deg. I'm not totally sure what to make of this since I would've expected the slow threshold to improve the ARM a bit.

[ckierans]

Okay, thanks for checking. Let me see if I can track all of the QA and BD events that may have changed to understand why we're not recovering the same ARM with the QA filter.

[ckierans]

Hmm, I'm seeing behavior that makes sense to me when looking at 358-3, including with the threshold file. @julianmgerber What Nuclearizer git commit were you using when you got the older unit level calibration numbers for the two detectors listed above?

I checked out the develop/em branch from March '26 (commit 8114b7c):
I get 7.7 +/- 0.3 degrees FWHM for the ARM fit of gse_20250709T113820.hdf when using the threshold file (vs the worse results listed above).

Then, checking out the this PR and keeping the QA events, I get 7.8 +/- 0.3 deg, aka consistent results with the analysis with the older commit. Excluding QA events get 7.1 +/- 0.3 degrees. Again, these both are using the threshold file, I'm ignoring NN strip hits, and I'm using your strip pairing algorithm.

For me, using a flat 20 keV threshold gives worse results than the file threshold (7.7 deg vs 7.1 deg). I think this is because cutting with 20 keV is quite a bit larger than the thresholds in the file, so we're missing information and therefore getting worse reconstruction for some events (the spectrum shows a large low-energy tail with the 20 keV threshold). When you say you're expecting the slow thresholds to improve the ARM, do you mean you expected a better improvement with the file, or you expected a better improvement with the 20 keV cut?

[julianmgerber]

@ckierans I'll try running it for 358-3 as well and see if I get the same numbers just to make sure I'm not doing anything wrong. For the original 434-1 unit level calibration, I believe I was on commit 3dd7d93. For 434-2, I originally ran it on a branch that had the updated strip pairing but was otherwise a bit behind develop/em. Essentially, I believe it was commit 2cd0898 with 8eb29cd cherry-picked.

For me, using a flat 20 keV threshold gives worse results than the file threshold (7.7 deg vs 7.1 deg). I think this is because cutting with 20 keV is quite a bit larger than the thresholds in the file, so we're missing information and therefore getting worse reconstruction for some events (the spectrum shows a large low-energy tail with the 20 keV threshold). When you say you're expecting the slow thresholds to improve the ARM, do you mean you expected a better improvement with the file, or you expected a better improvement with the 20 keV cut?

I think I expected the ARM to improve with the threshold cut file compared to no threshold cut. But the ARM I'm getting with the threshold cut file (10.32 deg) is worse than with no threshold cut at all (9.77 deg)