A
recent (Sept. 2000) fix for this problem which introduced these new map items
was committed to the sc package by Jim Ball. At the same time, calibration constants
were entered for run 11759(g1a).
All of this occurred after the cooking of the E1c data leaving the corrections up
to the individual analyses. While writing a filter program to extract events for a
specific channel, I wanted to include a timing correction for these coupled paddles.
Here I present some work I'm doing to produce these calibration constants for (some
of) the E1c data set.
|
These two plots illustrate the problem very well. These plots are made from sector 4
SCID 41 of run 16271. The top plot shows the time shift
needed in nanoseconds(Tpi) to push a pion candidate( mass between 50MeV and 450MeV) onto
the know pion mass. The two peaks arise from different timing between the two paddles.
The red and blue shaded areas indicate cuts on the upper plot used to create the red and blue histograms on the lower plot. The lower plot is the track position at the SC plane relative to the "bar center"(as returned by get_bar_center()). The red histogram shows clearly that the upstream paddle corresponds to the peak centered at zero in the upper plot. The blue histogram shows that the downstream paddle corresponds to the peak centered at 1ns in the upper plot. |
 |
|
The cut applied in the sc package to separate the paddles is on the
track position at the plane being greater or less than "bar center". This plot illustrates
more precisely how this cut would correspond to the two peaks in the Tpi plot. The histogram
outlined in blue was made by cutting on (sc_z-bar_center)< 0.
The histogram outlined in red was made by cutting on (sc_z-bar_center)> 0.
The calibration procedure I am using is done by fitting gaussians to the two Tpi peaks obtained by cutting on (sc_z-bar_center) being in the range -30cm to -5cm for the upstream and 5cm to 30cm for the downstream. It is neccessary to do this calibration for every run in which an SC calibration was done. This is because the SC calibration procedure used on the E1c data chose one peak to time in for each coupled pair. The same peak was not chosen consistently for the entire data set leading to the occasional swap between the upstream or downstream paddle being properly timed in. In most cases though, the upstream paddle would be chosen preferentially since they correspond to smaller theta and thus, slightly higher statistics. |
 |
17815
17746
17678* < - Combined events from runs 17678,17682,17707,17723,17746
17591* < - Combined events from runs 17591,17611,17628,17644
17558
17516
17403
17332
17235
17137
17104
16957
16874
16693
16581
16342
16294
16201* < - Combined events from runs 16218,16227,16230,16271
16159* < - Combined events from runs 16186,16191
16156
To apply these timing corrections to the already cooked data, I've written a small filter
program. The important file is correct_for_scid.c.
This can be included in any filter/analysis program by placing a call to
FixSCIDtiming(int runno)early in the event loop. Initialization will take place on the first call or whenever the runnumber changes. It will need to be linked with a recent sc library and compiled with an updated include package. This will modify the values in the sc_time and beta fields of the TBID banks and the time field of the SCPB bank. The effect of this calibration can be seen on the right. A set of cooked files from runs 17591,17611, and 17628 were run through the filter program with and without the flag to correct the coupled_paddled delays via FixSCIDtiming(int runno). The plots are both from sector 4 SCID=40. The top plot shows without the correction and the bottom plot shows with the correction. You can even see that the peak near zero on the upper plot was not perfectly aligned with zero. In the corrected plot, however, both peaks were shifted to be centered at zero. One can also see the 2ns beam structure much more clearly after applying the correction. |
 |