A couple of things:
1. First, a note on Rich's burst of several days ago: the monitor code
sees all the hits Rich lists, except the three from the hot box in the
south face (the endcaps are ignored by the monitor due to their very
low rate of GC buffer readout). Energy and position reconstructions come out
slightly different from Rich's due to the different calibration
databases used. However, the monitor rejects almost all of the hits
in this burst because they are below the monitor's software energy
threshold of 10 MeV (chosen for good signal/background in the burst
search).
2. I've completed a minor upgrade of the ERP GC monitor. I
cleaned up some things in the decoding/reconstruction, fixed a few
UT time bugs, and the LARGE_BURST output files will now look slightly
different -- they now include more information about the "error type"
of each hit.
For those interested in the details of the changes:
* I now pack more information into the "TYPE" word for each event.
Previously, there were only type 0 (good hit), type 1 (decoding error)
and type 2 (reconstruction error) hits. Now, each hit gets
bits set as follows:
Bit 0: set if box number decoding out of range (error or fake box)
Bit 1: set if ADC<ped or ADC>overflow for either ADC value
Bit 2: set if ADCA<ped or ADCA>overflow for either ADCA value
Bit 3: set if TDCH<underflow or TDCH>overflow for either TDCH value
Bit 4: set if TDCL<underflow or TDCL>overflow for either TDCH value
Bit 5: set if ERP time problem
Bit 6: set if Calmod calibration constant problems
Bit 7: set for reconstruction problems: ADCZ<-560 cm or ADCZ>560 cm
Bit 8: set if ADCZ/TDCZ mismatch
The TYPE word of each hit in a burst gets written out in the LARGE_BURST
file (as a decimal integer as yet -- I may change this).
* I modified some of the cuts (these changes are long overdue, in fact!)
(a) I no longer require both TDCH and TDCL info to be
non-over or -underflow (since we changed the MBT
discriminator threshold to be less than the TDCH
discriminator threshold in some cases, some boxes
have large numbers of TDCH underflows for pulses
which make the MBT thresholds but not the TDCH thresholds--
yet the TDCL information is good for such).
(b) There is now an ADC versus TDC position consistency
requirement of |ADCZ-TDCZ|<150 cm (I'm still working
on what the optimum consistency requirement is,
so the value here may change.)
Rates per SM actually remain approximately the same as before -- (b)
decreases rates of accepted hits, whereas (a) tends to increase them. Both
changes have the positive effect of making the box-to-box rates more
uniform.
* I fixed a couple of things with the UT time determination:
there was a bug causing it to get the date wrong for the first day of
a month, which is now fixed. Also, standard UT time (GMT) is now
printed in the LARGE_BURST files instead of local UT time (I just removed
a 1 hour local time offset which had somehow got into the code).
* Information about the UT vs ERPtime fit for each SM now gets written
to a file, FIT_runnum_INFO.OUT, for each run. BTW, (for those who
remember this) I think I figured out what the problem was with those
bursts we got a month or so ago for which the UT time fit apparently
failed (and for which I couldn't reproduce the same behavior when
running on a disk file!). Here's the scenario: when the detached
analysis process dies (which doesn't happen very often, but it does
happen), it gets relaunched automatically by SENTINEL. This can
happen in the middle of a run. When the detached process restarts
in the middle of the run, there is a reasonable probability of a GC
buffer reading out before enough muons have been collected for a UT
time fit for that SM (at the beginning of a run, this is quite
unlikely to happen). So, if a burst is found before the UT vs ERP
time fit has been done in all SM's, the UT time recorded for the burst
will not be correct. I tracked the UT time fit failures of last month
to detached process crashes due to file access problems (now fixed).
Anyway, this should be rare occurrence. Fixing this is nevertheless on
my to-do list: I will put in a way of delaying the processing of GC
buffers until a sufficient number of muons for a satisfactory UT time
fit have been collected.
* I also updated the calib constants on VXMACB to run 10578 (not quite
the latest ones).
There is one other thing that I should mention:
This new version of the monitor executable (running on a disk file) is
slower than the old one by a factor of about two (takes about 4 hours
to process an 8-hour run instead of <2). The reason is not clear:
I've removed various chunks of the new code to try to figure out what
could be causing the slowdown, but there's no obvious thing. I've had
this problem before -- it's probably some weird thing to do with the
way the executable gets built. Anyway, as it is now the code should
still be fast enough to keep up with the data (the mailbox has space
for several GC buffers, so the analysis program only has to run as
fast as the data comes in on average), but I'll keep an eye on buffer
collection efficiencies over the next few days -- if there's a
decrease, I'll work on restructuring things until speed improves.
Kate.