Using a file from the Run 19 FXT dataset production_4p59GeV_fixedTarget_2019, which I previously calibrated for event-by-event T0s, I examined the performance of three correction options by looking at vertex-finding results with the east TPC off and west TPC off:

• No correction
  • Yuri has been using this choice in SL24y productions with the new TPC alignment to date
• Irakli's correction
  • Based on matching east-only and west-only TPC vertices, using only the EPD MAX TAC
  • Known to be flawed for some events
  • As implemented so far, intends to include an overall <T0> shift representing a missing T0 correction for all events
  • See Irakli's blog on FXT T0 Work for more details
• Gene's correction
  • Based on prompt hit positions, using the earliest hit time from EPDE, VPDE, or BBCE depending on having any hits
  • Expected to work for 99.9% of events
  • As implemented so far, intends to include no overall <T0> shift, so that it only addresses event-by-event variations
  • See my blog on Event-by-event T0 for more details

Irakli's correction is flawed in FXT data for two previously identified reasons:

1. The EPD has a MAX TAC that is considered valid, but has a value of 0 in ~10% of events.
2. For events with a non-zero valid MAX TAC, it is in the east EPD for ~88% of events, and west EPD for ~12% of events, resulting in a time shift that is not accounted in the calibration.

That study also found that even when the above issues were avoided, there was some degraded correlation in the EPD MAX TAC with respect to BBC times as compared to the EPD east's earliest hit time that I have employed. But that seems to be a much smaller effect, was not understood, and may not be worth spending time on.

For this study, I ran with the new TPC alignment (SL24y with "CorrZ"), and processed two sets of jobs on ~40k events: with and without the shift in the vertex finder for the target being ~2 cm below the z axis (PR #720), which I will refer to as shifted VF and unshifted VF.

Here now are the distributions of the difference in vertex z position from the east-only TPC tracking vs. west-only for the three correction choices for unshifted VF (left) and shifted VF (right), with the RMS of the distributions shown on the plots and in the table below them. For each histogram, events were restricted to those where both the east-only and west-only jobs found a vertex within ±3.0 cm of z = +200.0 cm, which was typically only ~58% of the events, varying by ~0.1% for the three correction choices, and also ~0.1% higher for shifted VF than unshifted. I do want to re-state that this metric is what was optimized in Irakli's calibration method^†, while it is an independent metric from the prompt TPC hits used in my method.

Separate event selections

	unshifted VF	shifted VF
None	0.675 cm	0.574 cm
Irakli	0.663 cm	0.562 cm
Gene	0.651 cm	0.551 cm

There is a big improvement when using the shifted VF (which brought several impacts), and there is also some improvement when using the event-by-event T0 corrections. My corrections perform better than Irakli's primarily because of the known flaws in Irakli's, as can be demonstrated... When restricting the evaluation of the three corrections to use the exact same set of events that were "good" in all 6 productions, and excluding events where Irakli appears^‡ to have used a "zero" MAX TAC, the RMS results for Gene & Irakli's T0 corrections are nearly identical to each other, and both are better than no correction:

Identical event selections

	unshifted VF	shifted VF
None	0.666 cm	0.568 cm
Irakli	0.648 cm	0.547 cm
Gene	0.649 cm	0.548 cm

For SL24y, the disabling of Irakli's event-by-event T0 corrections was coded into StBFChain.cxx as an exclusion of non-"TFG" entries in the Calibrations_tpc/tpcBXT0CorrEPD table, so re-enabling his correction requires either modifying that code, or re-entering DB records with the "TFG" flavor.

Enabling my corrections requires only including the "EbyET0" chain option for the current SL24y once entries are placed in the database, but would require some means of disabling Irakli's correction in other existing libraries as there is no switch to turn his correction on or off. Disabling Irakli's corrections for those libraries could perhaps be most simply done by deactivating his database entries.

-Gene

---

† In order to use Irakli's correction in SL24y, which already compensates for T0s that apply to all events, I had to ad-hoc compensate Iraklis T0 by a fixed offset to remove that all-event correction: triggerOffset -= 0.572 time buckets.

‡ There were actually two sharp bands that showed up in Irakli's correction times distribution (after the above adjustment), at -0.223823 and +0.021746 time buckets. The former was at the low edge of the distribution and was likely the zero for MAX TAC. I did not investigate what the other, less prominent band was. Both bands were excluded in the context of using an identical set of events for all correction choices.