Hi peter, vitaly, and all retime/beta loving people
I've finished my analysis of various cal files (not, I derive my own cal
files with macros/tdc_offsets.C, results in results/tancredi/tdc_offsets)
obtained for different flasher runs.
I "think" it is unlikely that the retime offsets were wrong this year.
However, compared to last year we had no meantimer in the way of the
trigger time. Further I'd consider the tdc offsets from last year to be
wrong for a number of reasons (for once, our startegy is now different,
as summarized below).
Then I'd really like to see the results from show_protons for an updated
blastcal file obtained from a flasher run with and without retime
offsets and a show_protons for no blast cal file. We want to see an
improvements step by step. Peter, can you take care of that ???
Here is how I based my conclusion about the retime:
a) For runs 1325/1332 and 1326/1334 the offsets are the same within 0.5 ns
see elogbook.
b) for run 1235, compared with 1325 and 1332, about 3 and 9 channels are
outside 1 ns. Run 1235 is "representative" of how the delays were
downloaded this year, until the trigger gui bug was found.
c) if the retime delays were wrong they were likely in within these
limits. Note that all triggers downloaded this year had the right
retime delays (until I started playing with them).
d) In this result there is also the effect of ramping the HV's and of the
field (which was not on in run 1235)
e) The flasher peak has a sigma of 0.2 ns... so these shifts are really
large systematics. We plan on keeping it on during data taking as well
More comments:
1) Although reproducibility seems ok (mostly <0.5 ns) the "scale" of
the delays units can be way off. In other words some channels respond
in a non-linear fashion. You'll be surprised you can miss 4 ns out of
16 ns... but then turns out to be ok when you download 32 ns...
2) These conditions are how we determined our retime, so we have to
believe the actual delays are ok, although the behaviour of the nominal
value was never as smooth as we wanted it (and we never really
explained that, see retime delays for channel R4t vs R4b)
3) The trigger gui bug at download remains.
4) we don't really have spare delay units and you can't really get them
either
Here's my strategy:
_ our most realistic tdc offsets (and also truer to their definition)
are obtained for flasher runs where the retime delays have been taken
out. More over in this way you get t=0 for any detector.
_ We wish with this strategy to make all proton timing peaks arrive
at the same tdc channel (after correction)
- realistically, do not expect the peaks to line up much better than +-40
channels across L/R and for different combinations
- The position can be further adjusted, mantaining the sum (time) a
constant with chris' macro.
- If we are still unhappy then I think we'll have to sharpen our "tune"
with kinematics and apply a second channel by channel correction. It does
not really matter "what the correction is" since you know the mass of the
proton has to be m = p/v and tof is only used for pid. I can see having
to this for a few analysis.
- true, for the neutron we are more dependent on the timing offsets and
2ns is not very appealing since that can be 10% of the flight time, but
again you can use momentum conservation to tune out p_neutron(timing) as
well as some smart analysis with the gamma peak
- Another option, with enough shielding (such as what we used on the start
counter for CC tests) we could retime the detector for bent tracks instead
of straight tracks
-tancredi
________________________________________________________________________________
Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Tue, 8 Jul 2003, Peter Karpius wrote:
> V-
> OK I have calculated the offsets based on run 1326 (no delays) and
> created an ep ntuple from runs 705-735 (missing a few). I plotted ttl-ttr
> against ttr-ttl and things don't look good. Still trying to figure out
> why.
>
>
> Pete
>
> PS the macro I used to do this was proton_sum.C in
> /home/blast/blast/pro2003/analysis/macros
>
> ----------------------------------------------
> 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