People combining different event types for their analysis need to be aware
of a "feature" that's a consequence of how we program the cross-MLU (XMLU),
how the trigger supervisor (TS) prescale works, and how we make the event
type assignment.
The XMLU looks at the various bits showing which detectors fired for each
sector, and outputs a bit pattern indicating event type. For example, if a
left and right TOF each fire, and a Cerenkov for one sector, then output
bits 1 (coincidence) and 7 (electron singles) are set. If one of the TOFs
is TOF12-15 (with a neutron if it's the right sector), then bit 6 (TOF12-15
singles) is set. We set all bits that apply to the particular event, so
that the scalers will show an inclusive event rate. This design choice was
made long ago; we let the TS sort out what the most exclusive event type is
(trigger type 1 in the above example). See Chris Crawford's thesis for a
nice table of XMLU patterns and event types.
The 8 output bits from the XMLU are presented to the TS. The TS applies a
user-programmable prescale circuit to each input bit. We currently have
the following prescale factors:
Event type Prescale
----------------- -------------
1 1
2 1
3 10
4 100
5 1
6 100
7 3
8 1
The TS looks at whatever bits pass the prescale, takes the least
significant bit, and uses that to define the event type (our "trig"
histogram); e.g., if the 3rd bit is the least significant bit set, the
event is trigger type 3.
Now comes the problem. If an event comes out of the XMLU with bits 3 and
7 set, it's possible for the event to FAIL the bit 3 prescale, PASS the bit
7 prescale, and end up being recorded as trigger type 7 (a careful
examination of the TOF hits in event 7 would sometimes show you events that
belonged in event 3, though). If you are interested in trigger type 3, you
can get an accurate cross section by looking only at trigger type 3, and
multiplying by 10. That's fine. If you're interested in trigger type 1,
we never prescale that, and you don't have to worry.
If you look at ALL events without cutting on trigger type, you would find
some of interest in trigger type 7, and you would have to multiply the # of
THOSE events by the trig 7 prescale, and then add them to the trig 3 events
-- but do NOT multiply the trig 3 events by the trig 3 prescale, because
you already caught the failed 3's in trig 7.
If you are interested in singles, you need to add together all event types
to get the inclusive cross section. But with the "features" outlined
above, I don't think it's correct to take the number of each event type and
multiply it by its prescale factor, and then add everything up. Instead, I
think you follow the prescription of the previous paragraph -- take the
highest event number (7), multiply by its prescale, then add in any other
events that would have "failed back" to event 7, but do NOT multiply by
that prescale. If you did, you'd be double-counting events.
There are some cases where 3 XMLU bits are set, and the prescription may
be more complicated. I haven't worked that out yet.
This "feature" may explain why Nik has been seeing strange changes in his
asymmetries when he tries to add run periods with different prescale
factors (for example, we took some deuterium data with event 7 prescaled by
3, some with 9).
I'll post more information as I work it out.
Karen
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:32 EST