User name R. Michaels
Log entry time 09:58:10 on March 6,2006
Entry number 165478
Followups:
keyword=helicity check du jourSome asked (again) about helicity but didn't say what run #, so I
just checked the latest run 2695. Looks fine, see fig 1 & 2.
In fig 1 is the helicity vs event num at start of run. The first
approx 1000 events are used to load the helicity prediction.
Fig 2 shows the helicity after that (first 200K events). It shows
that 1.5% of data has helicity==0, which is expected because the
helicity transition occurs in 500 usec every 30 msec.
Now there are two problems, however:
1. Sometimes "helicity problems" may be reported by GenHelicity (they
are rare and I didn't see it in this run). According to R. Holmes
this happens because of a missing/bad bit in the clock used to
measure time, which makes QRT "appear" to jump in time. The code
goes into a recovery mode and assigns helicity==0. The solution to
this is to add a 2nd (& 3rd?) scaler to get a 2nd opinion. The bit
goes bad probably because ... high-rad environment (Moller has seen
this too). Also, the GenHelicity code could probably be made a
little smarter to recognize the bad bit.
2. Someone unplugged T9 !! T9 is important to see all helicity
transitions, even during beam trips, etc. If this was an accident,
fine, but please put it back. Basically I don't want to be asked
about helicity problems unless T9 is plugged in.
FIGURE 1
FIGURE 2
