Re: [BLAST_ANAWARE] timing issues

From: Tancredi Botto (tancredi@mitlns.mit.edu)
Date: Tue Jul 29 2003 - 11:27:34 EDT


Dear peter. I agree with your conclusions

but we need to check ttl-ttr as well.. That is to prove if the whole
thing works. If you look at pos_cal.C There are ways to fix positions
and leave the times constant.

Two questions:
A) are the offsets in 3) different from what was used so far?

B) are these offsets good also after run 1323 ? and before?

I know runs>1323 are d2 runs but even better so: for ee'p events you
should finally get the whole position distribution in a tof, i.e. the
paddle size, since e and p need not to be coplanar. This does not happen
for ep since the proton on the "edge" of the wch is stopped.

Ee'p data is cut by the d2_eep filter which is good for pol/unpol and uses
a cut as simple as pm_eep_cut and of course uses tracking info. From the
d2eep filter you get all the timing peaks. That defines your timing cuts
for eep. You get only the "right" timing peaks, making your life easier,
since events are selected in the wch. See how it is done in d2tof_flrn.C
via the definitions of rawmax3, rawmin3 in filter.h You can easily expand
and include filter.h in the macro of your liking. Note that those cut are
on the raw variables. Then, for each timing peak (or the sum of all of
timing peaks with the same tof involved), you could get the position even
without reuqiring the wch!!

Of course if you use d2eep data your job is faster. However events may not
distribute over the whole tof extension since tracking info was used. The
effect may not be large and anyways should be symmetric.

Either way (cut on raw timing or cut on wch) you should get symmetric
spectra and you are only trying to equalize their median values. I hope
you'll be able to have something before we start data taking. The
defualt cal file is defined in ~pro//Blast_Params/blastrc. Make sure
you change that (letting people know) once you have a calibration.

enjoy
-- tancredi
________________________________________________________________________________
Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Mon, 28 Jul 2003, Peter Karpius wrote:

> Tancredi-
>
> I have been putting some time into trying to figure out why the timing
> offsets have seemingly shifted. OK well I have given up trying to figure
> that out and am now only trying to rectify the problem. I have been
> crunching all the H2 data through run 801 using three different calib
> files. (Again these ntuples are being sent to "anothercrunchdir" so
> as not to corrupt the real analysis directory - as you know there is also
> a seperate directory set up for separate Blast_Params) The three calib
> files are based on:
>
> 1) zero offsets
> 2) offsets from run 1326 flasher (i.e. post-CFD delays = 2ns)
> 3) offsets from the actual H2 data
>
> Anyway, it seems that the best position results come from using the real
> data (please see that the attached plot) I do not necessarily think that
> this means that we can not use the flasher for determining offsets I just
> I am not sure about how the run conditions for flasher vs real data varied
> in this dataset. I still need to verify ttl-ttr:ttr-ttl but there is a
> small problem here (in test macro or elsewhere) on which I am
> stil working. Yes this is WAY overdue for a solution! Dealing with these
> offsets is getting, as we say, a little long in the tooth!
>
>
> Working on BATS tomorrow with Ben
> but I will be around to speak
> about this,
>
> Pete
>
>
>
>
> ----------------------------------------------
> Pete Karpius
> Graduate Research Assistant
> Nuclear Physics Group
> University of New Hampshire
> phone: (603)862-1220
> FAX: (603)862-2998
> email: karpiusp@einstein.unh.edu
> http://pubpages.unh.edu/~pkarpius/homepage.htm
> ----------------------------------------------
>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST