I attach a script used to estimate TOF efficiency (load_root_file.py). I see two classes of inefficiency:

1. There is a coincidence of two slabs in adjacent planes, but no space point made. This occurs for about 10 % of events in TOF0 and TOF2. I attach a plot of the difference between slab hit GetRawTime() for these events. Referring to 8681_raw_slab_hit_delta_t.pdf
   • I divide slab hits into plane 0 and plane 1; I iterate over all slab hits in each plane and find the smallest raw time difference available.
   • The full lines are all raw times. The dashed lines are raw times for those events that did not successfully make a calibration. There is no significant difference in the population and the raw times are all < 5 ns, indicating they are likely to be "real" particles.
2. The calibration succeeds, but the calibrated dt is > 0.5 ns, O(1 %) of events. Referring to 8681_slab_hit_calibrated_delta_t.pdf
   • I divide slab hits into plane 0 and plane 1; I iterate over all slab hits in each plane and find the smallest calibrated time difference available. I exclude slab hit coincidences with delta t < 1e-12 as these seem to correspond to events where the calibration procedure failed. I plot this with a dashed line.
   • I find the first space point in each TOF and plot the delta t. I plot this with a full line.
   • Note that the TOF2 calibrated delta t peak is not central. That's interesting
   • Note that the cut at 0.5 ns excludes about 2 % of events. The inefficiency is more than I would like (should be more like 0.1 %)

The flip side of the analysis; I extrapolate tracks from TKU to TOF2 and look to see where the trajectory lands. I see about 14 % inefficiency in TOF2. Well, that ties in pretty well with the numbers I list above. I can buy that some of these events are scraped, but my feeling is that a lot of it is reconstruction inefficiency.

See misses_tof2_x-y.pdf

I also note that the resolution comparing slabs is about 85 picoseconds (0.12/2**0.5). Is it possible to do better? It used to be 50 ps...

Most of the problem for the 'two slab hits but no space point' case was due to the fact that the analysis script was looking for TOF0 and TOF2 spacepoints even if there was no TOF1 spacepoint. The reconstruction doesn't attempt to make space points in TOF0 and TOF2 in that case, since with no trigger pixel you can't reconstruct the time. [MapCppTOFSpacePoints.cc line 227] changing the analysis script to not look for TOF0 and TOF2 spacepoints in that case, I get:

TOF0 failed calibration 0.03 % out of range 1.58 % Okay 98.39 %
TOF1 failed calibration 3.38 % out of range 0.62 % Okay 95.99 %
TOF2 failed calibration 4.16 % out of range 2.07 % Okay 93.77 %

I had a look at run 8448 available here

http://reco.mice.rl.ac.uk/MAUS-v2.8.4/geofix/08448_offline_geofix.tar

which was the one Jan was worried about (funny path is because Durga fixed some stuff in TOF2 recon). I added a requirement for TOF1 space point, as in load_root_file_2.py

I get quite poor performance from TOF2...

TOF0 failed calibration 0.04 % out of range 1.83 % Okay 98.14 %
TOF1 failed calibration 0.0 % out of range 0.0 % Okay 107.43 %
TOF2 failed calibration 15.12 % out of range 2.34 % Okay 82.55 %

I looked at following runs:

08447 (3-140)
TOF0 failed calibration 0.04 % out of range 1.31 % Okay 98.66 %
TOF1 failed calibration 0.0 % out of range 0.0 % Okay 100.0 %
TOF2 failed calibration 4.25 % out of range 1.48 % Okay 94.27 %

08448 (3-170, listed above)
TOF0 failed calibration 0.04 % out of range 1.79 % Okay 98.16 %
TOF1 failed calibration 0.0 % out of range 0.0 % Okay 100.0 %
TOF2 failed calibration 15.34 % out of range 1.91 % Okay 82.75 %

08450 (3-200)
TOF0 failed calibration 0.06 % out of range 2.18 % Okay 97.77 %
TOF1 failed calibration 0.0 % out of range 0.0 % Okay 100.0 %
TOF2 failed calibration 6.48 % out of range 1.46 % Okay 92.06 %

08451 (3-240)
TOF0 failed calibration 0.01 % out of range 2.79 % Okay 97.2 %
TOF1 failed calibration 0.0 % out of range 0.0 % Okay 100.0 %
TOF2 failed calibration 1.01 % out of range 1.63 % Okay 97.36 %

• The wide variation is interesting and merits further investigation.
• I found a small bug in the script so it was reporting > 100 % for TOF1 "Okay" events.
• I got impatient and only ran over the first 2100 DAQ events
• I attach plots, if they are interesting or useful tof_validation_plots.tar.gz

Right, I gave some updates at collaboration meetings but never marked it closed.

The original cause of the inefficiency was that the calibration didn't cover the edges of the TOFs, but the fix (using other datasets that had enough hits at the edges for a calibration) revealed strange effects in the slab dt. Finally, when another calibration run was done with enough statistics at the edges, the dt effects disappeared.

I note that there is a run dependence on the TOF dt; these are two nearly adjacent runs, run 10248 and run 10250. Note that the beamline is different so (a) the rate is probably different and (b) the beam is likely wider