For some reason the rate of alarms seems to have gone up over the last
few days. This happened at about the same time as the addition of the
wfd to the acq, and it may or may not be a coincidence. It's not
really clear how the wfd data could affect the alarm rate; Alec
suggests that the background rate determination is less accurate
because the runs are shorter now, which is probably true, although if
that's the reason I'm not sure why we didn't get a lot of bursts near
the beginning of a run before. It may be just a fluke.
Anyway, I have raised the burst threshold a bit (I lowered the Poisson
prob threshold to 10^-6). If we still get a high rate of alarms
I'll check into things some more and try to figure out why.
We do have another quite serious problem which may well have something
to do with the addition of wfd to the acq: the scratch disk keeps
filling up. The monitor outputs stuff to the scratch disk. In the
last several months the scratch disk hardly ever filled up; however in
the last couple of weeks it's been filling up quite frequently,
probably due to the extra data, and this has been causing crashes of
the monitor. This is a stupid reason for the monitor to crash, and is
unacceptable, so I'm going to ask Marini for some reserved disk space
for the monitor, which I'll take responsibility for keeping clean and
backed up.
Another secondary effect of the wfds: since runs are shorter,
a greater (although still small) percentage of the GC data is
contained in the end of run buffers. The (fairly minor) job
of adding the eor buffers to the monitor now gets higher weighting on my
monitor to-do priority queue.
BTW, I have checked that the RCD buffer collection efficiency is still
OK (~98%, about the same as before) even with the higher data volume.
So, in summary, here is the top of my to-do priority queue:
1. Clean up and back up monitor scratch area
2. Write to Marini to try to get reserved monitor output disk space.
3. Update CALMOD databases on VXMACB (it's a db or two away from being
the most up to date). As Rich points out, there is some giuge that
gets cleaned up by using the "best" db's. I am also going to separate
LUT db's from the standard one on VXMACB, but that's another story.
4. Add end of run GC buffer decoding.
#1 and #2 I will do today; the rest I'll try to get to soon.
One more tiny detail: in the monitor burst output, I changed the "*"
in the "Cut" column to mean "didn't pass cuts", not "passed cuts" for
each hit, since more than one person has thought that this was the
more natural interpretation.
Kate.