[Halld-pid] Start Counter Meeting Minutes, September 21, 2017

[Mark Ito]

PID'lers,

Please find the minutes below and at 
https://halldweb.jlab.org/wiki/index.php/GlueX_Start_Counter_Meeting_September_21,_2017#Minutes 
.

  - Mark

_____________


    GlueX Start Counter Meeting September 21, 2017, Minutes

Present:

  * *FIU *: Werner Boeglin, Mahmoud Kamel
  * *FSU *: Sean Dobbs
  * *JLab *: Thomas Britton, Mark Ito (chair), Simon Taylor, Beni Zihlmann

There is a recording of this meeting 
<https://bluejeans.com/s/FU0KH/%E2%80%8E> on the BlueJeans site 
<https://jlab.bluejeans.com/>. Use your JLab credentials to authenticate.


      Review of minutes from the last meeting

We went over the minutes from August 24 
<https://halldweb.jlab.org/wiki/index.php/GlueX_Start_Counter_Meeting,_August_24,_2017#Minutes>. 


  * Thomas suspects that here may be a clocking problem with the start
    counter in *HDvis * that needs to be looked at. Mahmoud expressed
    interest in playing with HDvis with an event source. Thomas will
    send him email with instructions.
  * Werner recently sent some final plots to Eric Pooser for the *NIM
    paper.* The FIU folks want to get together one more time before
    general release, but Werner thinks they are pretty close now.


      Calibration and Efficiency

Mahmoud brought us up-to-date on his efficiency analysis. Please see his 
slides 
<https://halldweb.jlab.org/talks/2017/Analysis_Meeting_9_20_2017.pdf> 
for the plots and details.

He has changed the procedure to use the RF signal as a time reference 
for the start counter hits in his efficiency calculation, cutting the 
resulting time difference to decide whether a counter is hit or not. He 
is correcting for the target z position of the event vertex, the 
time-of-flight from the target to the start counters, light propagation 
in the counters and z-position of the hit in the counters. The time 
difference has the expected prominent peak at zero, but with not 
insignificant (few percent) nearest-neighbor RF bucket peaks and smaller 
next-to-nearest-neighbor peaks as well. Interpretation of these peaks as 
accidental background gives a artificially low efficiency after 
subtraction. There were several suggestions about things to try.

  * Beni advised avoiding RF times that were chosen based on the start
    counter.
  * Beni provided guidance on which RF factory product should be used.
  * Mark suggested selecting events where the event vertex is well
    defined, either those with multiple tracks or those with tracks that
    go transverse to the beamline. That may give events with better RF
    bucket choices.
  * Mark mentioned calculating efficiency treating the neighboring peaks
    as signal and getting the accidental correction from RF peaks far
    away from zero where the time distribution looks flat (just to see
    what you get).


      Separating tracking contribution to resolution in mcsmear

Sean led us through his wiki page 
<https://halldweb.jlab.org/wiki/index.php/SC_mcsmear_resolutions> where 
he studies, in simulated data, the dependence of the measured start 
counter timing resolution on the amount of start counter time smearing 
input to mcsmear. Roughly speaking, he measures something about 10% 
broader than the smearing we put in. This is likely due to the 
contribution to the resolution from tracking that is intrinsic to the 
measurement.

Sean uses an empirical linear function to capture this effect, on a 
counter-by-counter basis. We all agreed that this should be implemented 
into mcsmear at some point. Sean also pointed out that there may be an 
even bigger effect to include, that of the dependence of time resolution 
on the z-position of the hit in the start counter.

Retrieved from 
"https://halldweb.jlab.org/wiki/index.php?title=GlueX_Start_Counter_Meeting_September_21,_2017&oldid=83748"

  * This page was last modified on 21 September 2017, at 21:43.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-pid/attachments/20170921/894c5d1c/attachment.html>