OK,
hold on everybody.
1) the "zero" file comes from march 13, I suspect it comes from cvs but
maybe I am wrong. It certainly was not there from the first cvs_v3 co.
This is different then having shifting offsets.
2) A bad tdc offset files move tdc offsets only, by a constant and/or
predictable offset. That is far away from saying that it destroys
analysis
3) If you have followed last week discussions with me, vz, pk we are
in the processes of having to change this calibration file ANYWAYS,
since we believe it is not accurate enough. The restored file today
is probably not good in the first place.
-- ________________________________________________________________________________ Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124 research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^On Mon, 14 Jul 2003, Chris Crawford wrote:
> > > zhangchi wrote: > > >Hi, all, > > > >Just found that the blast.sc_cal file in blast Blast_Param is over written > >by a dummy at a certain point. Do not know who did this and the time stamp > >does not reflect this incident. all tof tdc offsets in that file are 0. > > > >replaced it with blast.sc_cal.save in the same directory. Noticed that it > >is difference from the one in CVS. Some one should decide which one is > > > hi, > i calibrated the positions, and checked the new sc_cal file into cvs, > but didn't start using it for crunches, since i didn't want to change > things up for only half the runs. you can check that only the > positional calibration has changed (ie. t1+t2, which affects the mean > time, hasn't changed). > now we have to redo things i suggest using the new one (latest in > cvs). however, if these delays in the trigger have really been varying, > sounds like we need more than one cal file! (database?) > --chris > > >good and synchronize them. the bad file is copied into blast.sc_cal.BAD > >with time stamp preserved. > > > >all data crunched after July 8th are bad. sympton is ttl-ttr for > >left+/right- events peaks are 700 channels instead of 200. > > > >Vitaliy, Aaron and anyone who is doing analysis on these runs, which > >include all the 2-cycle deuterium runs, you may want to stop and wait for > >them to recrunch if your analysis depend on any cuts that is sensitive to > >timing. > > > >It sure fucked me up badly. > > > >Chi > > > > > >
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST