Project

General

Profile

Bug #1997

TOF distribution in reconstructed data with MAUS-v3.3.3 for John's runs

Added by Franchini, Paolo over 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Franchini, Paolo
Category:
-
Target version:
-
Start date:
04 March 2020
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

Description

Broader peak in the muon TOF01 peak for the muon beams runs with respect to the previous reconstruciton done with v3.1.2

Files

MCSNote_new.pdf (4.28 MB) MCSNote_new.pdf Franchini, Paolo, 04 March 2020 17:27
reco_07666_dt=0.5.png (14.3 KB) reco_07666_dt=0.5.png Franchini, Paolo, 04 March 2020 17:30
#1

Updated by Franchini, Paolo over 3 years ago

  • Assignee set to Franchini, Paolo
#2

Updated by Franchini, Paolo over 3 years ago

As in a previous email thread, from myself

what I can think has been changed in terms of TOF reconstruction happened when we were struggling with the TOF SP efficiency:
basically as in https://micewww.pp.rl.ac.uk/projects/computing-software/wiki/Computing-Software-Handover-Document#TOF

(there is much more from Viktor https://micewww.pp.rl.ac.uk/projects/maus/wiki/Some_TOF_Space_Point_Performance_Plots)

was suggested to move the TOF_makeSpacePointCut (and TOF_findTriggerPixelCut) in ConfigurationDefaults.py
from 0.5 ns to 3ns (and this is in MAUS since 3.2.0), to accept as SP with a larger slab dt.

This might have been correct for the pion beam but not for the TOF calibration for the muon runs.

A quick reconstruction of run 7666 moving back the dt cut to 0.5ns shows a better agreement

#3

Updated by Franchini, Paolo about 3 years ago

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

Also available in: Atom PDF