Hi Tancredi-
I agree with the new strategy and will see what I can do about the
new results from show_protons ... after the collaboration meeting. Now I
have to get some sleep - be there at midnight!
Pete
On Wed, 9 Jul 2003, Tancredi Botto wrote:
>
> 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
> > ----------------------------------------------
> >
> >
>
----------------------------------------------
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