Project

General

Profile

Bug #1912

TOF inefficiency

Added by Rogers, Chris over 6 years ago. Updated over 5 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
TOF
Target version:
-
Start date:
21 February 2017
Due date:
% Done:

50%

Estimated time:
Workflow:
New Issue

Description

Looks like the TOFs are ~10% inefficient.


Files

8681_raw_slab_hit_delta_t.pdf (16.4 KB) 8681_raw_slab_hit_delta_t.pdf Rogers, Chris, 21 February 2017 12:43
8681_slab_hit_calibrated_delta_t.pdf (16.1 KB) 8681_slab_hit_calibrated_delta_t.pdf Rogers, Chris, 21 February 2017 12:43
load_root_file.py (9.65 KB) load_root_file.py Rogers, Chris, 21 February 2017 12:43
misses_tof2_x-y.pdf (14.8 KB) misses_tof2_x-y.pdf Rogers, Chris, 21 February 2017 12:50
tof_resolution.pdf (25.6 KB) tof_resolution.pdf Rogers, Chris, 03 March 2017 18:22
8681_raw_slab_hit_delta_t_new.pdf (16.4 KB) 8681_raw_slab_hit_delta_t_new.pdf Wilbur, Scott, 08 March 2017 13:00
load_root_file_2.py (10.7 KB) load_root_file_2.py Rogers, Chris, 11 April 2017 13:59
tof_validation_plots.tar.gz (285 KB) tof_validation_plots.tar.gz Rogers, Chris, 11 April 2017 16:12
tof_space_point_efficiency.png (5.97 KB) tof_space_point_efficiency.png Rogers, Chris, 29 November 2017 15:20
tof1_slab_dt.png (15.5 KB) tof1_slab_dt.png Rogers, Chris, 29 November 2017 15:20
tof0_slab_dt.png (15.5 KB) tof0_slab_dt.png Rogers, Chris, 29 November 2017 15:20
tof2_slab_dt.png (14.8 KB) tof2_slab_dt.png Rogers, Chris, 29 November 2017 15:21
tof1_slab_dt.png (15.8 KB) tof1_slab_dt.png Run 10248 Difference between slab hit times Rogers, Chris, 29 November 2017 16:13
tof1_slab_dt.png (16.3 KB) tof1_slab_dt.png Run 10250 Difference between slab hit times Rogers, Chris, 29 November 2017 16:14
tof_space_point_efficiency.png (5.99 KB) tof_space_point_efficiency.png Run 10248 Efficiency at finding spacepoint from slabs Rogers, Chris, 29 November 2017 16:16
tof_space_point_efficiency.png (5.94 KB) tof_space_point_efficiency.png Run 10250 Efficiency at finding spacepoint from slabs Rogers, Chris, 29 November 2017 16:16

Related issues

Related to MAUS - Bug #1917: Large discrepancy between triggers (as per CDB) and spacepointsOpenRogers, Chris03 March 2017

Actions
#1

Updated by Rogers, Chris over 6 years ago

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 %)
#2

Updated by Rogers, Chris over 6 years ago

Nb: More precise numbers for the two different classes of inefficiency:

TOF0 failed calibration 9.33 % out of range 1.43 % Okay 89.23 %
TOF1 failed calibration 3.38 % out of range 0.62 % Okay 97.21 %
TOF2 failed calibration 10.38 % out of range 1.93 % Okay 87.69 %

#3

Updated by Rogers, Chris over 6 years ago

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

#4

Updated by Rajaram, Durga over 6 years ago

In http://micewww.pp.rl.ac.uk/attachments/8348/8681_raw_slab_hit_delta_t.pdf what do the 6, 7, 10 etc on the plot legends mean?

#5

Updated by Rogers, Chris over 6 years ago

They are artefacts of my plotting routine. ROOT uses the name string to uniquely identify objects and also for default name in histogram legends. Sigh. So I add a unique integer identifier to stop ROOT doing daft things. I usually clean it up, I didn't bother this time.

#6

Updated by Rogers, Chris about 6 years ago

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...

#7

Updated by Rajaram, Durga about 6 years ago

Chris -- I don't think sigma/sqrt(2) has ever been 50ps

It's true that the intrinsic resolutions have become a little worse over time [ eg TOF0 58ps vs 53-55 in 2011 ] but as far as I know
the intrinsic counter resolution has always been at these levels

See e.g. https://arxiv.org/pdf/1001.4426.pdf, or MICE-Note 251.

Am I missing something?

#8

Updated by Rogers, Chris about 6 years ago

I had a chat with Durga, and reminded myself - the plot shows the resolution of the two slabs added in quadrature, so the width is sigma(t)*sqrt(2) where sigma(t) is the resolution of each slab. The combined resolution is then sigma(t)/sqrt(2), i.e. half the width of the plots, 60 - 65 ps.

#9

Updated by Wilbur, Scott about 6 years ago

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 %

#10

Updated by Rogers, Chris about 6 years ago

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 %
#11

Updated by Rogers, Chris about 6 years ago

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 %
Note
  • 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
#12

Updated by Dobbs, Adam almost 6 years ago

All, is this now fixed?

#14

Updated by Wilbur, Scott over 5 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

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.

#15

Updated by Rogers, Chris over 5 years ago

Scott, I still see poor efficiency in the recent data. Why is that?

#17

Updated by Franchini, Paolo over 5 years ago

  • Status changed from Closed to In Progress
  • % Done changed from 100 to 50
#18

Updated by Rogers, Chris over 5 years ago

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

#19

Updated by Rogers, Chris over 5 years ago

#20

Updated by Rogers, Chris over 5 years ago

Also available in: Atom PDF