I've got a few things to add to this:
>
> Summary of post-run analysis of run 10084 burst compared to monitor.
>
> 1) Monitor did not include SM5 because burst was reported before the SM5 GC
> buffer had read out. 2 of the hits in this burst are rejected because they
> were SM6 single box hits coincident with SM5 hits. This is an inherent
> limitation of the monitor.
This isn't exactly right: the monitor *did* include SM 5 in the burst
search when SM 5's buffer read out later, it just didn't find the
burst when it did the search including SM 5 because at that time it
*did* cut the 2 hits that Rich mentions.
Let me clarify:
What happens is that that the combined burst search gets done promptly
after any GC buffer reads out, on whichever supermodules have read out
so far (keeping track of current rates for the relevant SM combination
in order to set multiplicity thresholds)-- the search is highly
redundant and goes over the same time period several times as the
different SM's read out. This means that some inter-SM muon hits can
get left in the data sample for some of the combined burst searches,
if the GC buffer containing one or more of the hits hasn't read out
yet when the combined burst search is done on the buffer containing
another of the hits. This is what happened with yesterday's burst: it
didn't cut the inter-SM 5/6 hits before SM 5 had read out,and found a
burst then, but it *did* cut the hits after the SM 5 readout, so that the
burst was *not* found in the later combined burst search pass over
the same time period, this time including SM 5.
> If this burst had been a more compelling
> candidate, Kate's analysis would have rejected these hits in a post-run.
Actually not post-run: as I just described in fact the monitor *did*
reject these hits when the SM 5 buffer containing the partners of the
inter-SM 5/6 muons included in the burst read out. That's why the
burst only showed up in 3 SM's.
Of course, I could avoid the extra inter-SM muon contamination for
few-SM burst searches by always waiting for all SM's to read out
before performing a burst search. However I feel that it's
preferable to do searches as promptly as possible in order to
get alarms out as soon as possible after the burst happens.
> I pick up 4 additional single box events from SM5 during the burst
> interval, all below 5 MeV.
>
These were not reported by the monitor because no burst was found for
that time period after the SM 5 readout.
> 2) One additional single box hit is rejected due to coincidence with a Bari
> trigger.
Unfortunately the monitor can't pick up ST info without reducing GC
buffer collection efficiency, so this *is* an intrinsic limitation
of the monitor (unless RCD collection efficiency can improve dramatically).
< ADCZ/ TDCZ stuff deleted >
I'll leave discussion of these issues to a later note. I may change
the monitor ADCZ/TCDZ reconstruction and cuts, but only after
I've studied the effects some more.
> 6) One single box event is rejected by the monitor because it is within 400
> usec of another hit. The monitor has only 1 msec time reconstruction
> accuracy, whereas a post-run analysis can reconstruct with 50 usec
> resolution.
>
The monitor's time-coincidence cut window is 4 ms-- typically the ERP
clock calibration using muons at the beginning of the run is good to
1-2 ms by the end of the run. I have studied whether or not this
coincidence cut decreases signal/background and it does not
appreciably-- details in the new memo.
> 7) Net result: Monitor gives 7 hits, 2 are multi-box, 1 coincident with
> Bari trigger, 1 near tank end, and 2 with ADCZ/TDCZ mismatch, leaving 1 hit
> plus one additional hit rejected by monitor but kept post-run.
>
Overall, the comparison of the monitor analysis and Rich's looks
fairly good -- most the differences are understood as expected behavior,
with the possible exception of some energy/position reconstruction
questions which we're working on.
Kate.