This note continues my categorization of problems associated with the
WFD system. While the last note explored problems associated with the
STOP-master this note examines problems I have seen with the WFDs
themselves.
As before it is important to understand these problems because they
can change the effective acceptance of rare-particle searches and in
some cases, they might be able to produce background events.
One of the main differences from my last note is that I do not know of
a way to systematically tag these events. Typically they cause my
reconstruction algorithms to fail. Sometimes because of an
accidental radioactivity, the WFDs still reconstruct, but the timing
values are wrong. We must assume that sometimes they reconstruct and
the timing values look reasonable.
At this point I would say it not clear exactly how to handle these
problems.
I. Introduction
------------------------------------------------------------------------
To categorize these problems I have done the following: After
choosing events with a LIP trigger and a single ST track(using both
the lateral and strip views) I pass the events through filters to
remove events with the STOP master problems I described in my last
note. At this point I should have a sample of events with good
reconstructible WFDs in every channel. I then project the
three-dimensional track through the boxes in the event and for every
box which has the track going through it I try to reconstruct the
WFDs.
Although I could have chosen to look at every box, I chose boxes with a
track through them because the muon makes it easier both to determine how
big the pulse in the WFDs should have been, and the relative amplitudes
between the two sides. This is useful when trying to decipher
mysterious events.
After the reconstruction the WFD objects can have the following states:
{OK, empty, missingWfds, overflow, noMatchingDiscBits}
These states mean the following:
OK: Both sides of tank had a WFD pulse with the proper disc bits in
the time window you would expect for the trigger.
empty: There were no samples in the WFDs in the proper time window
missingWfds: One or both sides of the tank's WFD channels were
missing from the data
overflow: During the readout the one or both of the channels hit
the byte readout limit. This is usually due to extremely
large pulses.
noMatchingDiscBits: Although there is data in the time window none
of it is on the right input.
If after reconstruction the status is either empty, missingWfds, or
noMatchingDiscBits then the event is tagged for further investigation.
It should be noted there are some channels during different periods of
time which are "broken" and do not reconstruct properly ever. These
boxes are placed in a "bad-list" and are not used to tag bad events.
The number of events which are tagged bad by the analysis is about .6% of
the good events with LIP triggers and tracks.
After tagging the bad events I go back to the original data and
regenerate DSTs for these events with things like time windowing and
the fix for the first 4 buckets of the data turned off so I can
examine everything about the WFDs for these events. The procedure is
fairly tedious and what I will present here are the results of looking
carefully at seven events.
II. The Data
------------------------------------------------------------------------
I have made a ZEBRA files with the data for the events in:
ftp://ftp.cithep.caltech.edu/pub/wfd/10850.zeb
A text dump of the WFD information is in:
ftp://ftp.cithep.caltech.edu/pub/wfd/10850.out
To check in detail everything in the note for yourself you can just
look at the text file. If you want to reconstruct the data yourself
or look at other stuff about the event like stop times or event
displays you will need the raw data. I can also make the FARFALLA
file available if people want it. You can ignore the other stuff in
the directory. It is from related work that Chris O. and have been
doing.
III. Summary of problems
------------------------------------------------------------------------
There seems to quite a menagerie of problems. Because of this I can't
just summarize them in a list. Instead here is a description of each
event. Just reading them will describe the problems I found. If you
follow along with the text file you can see all the stuff I describe.
Event 43:
************************************************************************
Tank 3T03 chan 0x321:
The readout for this tank stopped too early. I have no explanation for
why. Because of it we are missing all of the muon data.
Tank 3C03 chan 0x309:
There looks like there is a problem with the time on this channel.
However, that is only because I turned of my "first-sample" fix which
corrects for what happens if the first sample is not separated by four
time words from the second(Which can happen if the system is
digitizing during a stop).
Event 1308:
************************************************************************
Tank 3W8/10/12/14 chan 0x319:
This channel has the muon showing up too early. It appears that this
box missed a roll-over word. Some boxes (especially verticals) seem to
sometimes miss a roll-over word. Perhaps the rate is not high enough
in these boxes. The effect of this is that the muon seems to show up
328 uSec too early(328uSec = 65536*5ns).
Tank 3B12/14 chan 0x307:
This chan overflowed(hit the byte readout limit). However all of the
ADC data is 0 and all of the dBits are FFFF!
Tank 3B09/13 chan 0x304 0x305:
These overflowed but because of a very large pulse. The WFDs are OK
Event 4269:
************************************************************************
All of these channels seem to have the muon offset by 2.5 usec. I
actually reported this quite some time ago. Everything on SM4 is
offset by this amount. This one happened to be so close to the edge
of the timing window that part of the muon got cut off. At some point
I seem to have commented my fix for this out of the code. So this is
really a STOP-master problem. However the STOP master thinks it only
counted for 1 ms. So it looks like the clock chip itself was/is
slightly off.
Event 4767:
************************************************************************
Tank 3E04 chan 0x317:
missed roll-over word
Event 4986:
************************************************************************
Tank 2W08 chan 0x218:
In this event the time-word "glitched" and went up instead of going
down. Because of this the readout routine got confused(thinking a
roll-over happened) and stopped the readout thinking it had read
enough data:
Here is the section of the data:
Time Timewd dBits AD0 AD1 AD2 AD3
999345 51396 1111 27 26 28 27 0.2 1.0 -0.6 0.2
999365 51392 1111 28 31 34 38 -0.6 -3.0 -5.4 -8.7
1326745 51452 1100 37 33 29 26 -7.8 -4.6 -1.4 1.0
Event 5577:
************************************************************************
Tank 6B12 chan 0x607
The data is missing in the relevant section of the buffer for this
event. However it is clear something went wrong during the stop as
the ADC and dBit values in the first sample are nonsensical:
Time Timewd dBits AD0 AD1 AD2 AD3
0 8478 1D1A 242 81 0 0 -8697.8 -54.7 0.0 0.0
59905 62033 0000 26 26 26 26 0.2 0.2 0.2 0.2
Event 7414:
************************************************************************
Tank 6E04/06 chan 0x617:
Missed roll-over
Tank 6C08 chan 0x60B:
The second ADC value is stuck at the value 9