The purpose of this document is to record the development of the HELicity Physics program (HelP) in its attempt to check the integrity of the beam helicity label with the associated physics events and normalization information. Additionally the program was used to recover from a hardware failure to record the helicity bit in individual physics events.
Originally the HelP program was concieved to check the inegrity of the helicity information being recorded in the data stream. In 1998 (EG1a), the helicity was psuedo-randomly selected every second such that a helicity compliment state followed the original helicity state. While each triggered physics events was labeled with a helicity state in the "HEAD" bank, the beam charge was integrated over the helicity state. The information was stored locally on the readout controller (ROC) and then recorded in the data stream in 10 second intervals when a scaler readout was triggered. This meant that in order to determine the FC counts for a given helicity state one need to look forward in the data file by at least 10-20 seconds. The HelP program was created to "realign" this information with the respective physics events. This meant post processing the "cooked" data files. It was also decided that this prost processing of the "cooked" data files would create output files that compacted the information and only kept information needed for physics analysis with minimal reconstruction abilitities (DST; Data Summary Tapes ).
In 2000 (EG1b), a 30 Hz helicity flip rate was used, the FC electronics were altered to be more sensitivity to beam charge, and the readout of the FC scaler was stored in the data stream immediately after a helicity flip (sometimes the information was injected after 2 helicity flips depending on the DAQ throughput). This substantially simplified the HelP algorithm needs thus the algorithm was rewritten. Unfortunately, the helicity label stored in each physics event failed to latch for some of the run period. Fortunately, the FC scaler had its own helicity label latch which did not fail. As a result, the HelP program was altered to recover the physics events which failed to be accurately labeled with the helicity state.
In the interest of time it was decided to depend on the appearance of the HLS scaler bank immediately after a helicity state change. If the HLS bank failed to be written to the file immediately after a helicity state change, it will appear at the next helicity state change along with the HLS bank for that particular helicity state. I will not try to line up an HLS event beyond the preceding helicity state change so I will label helicity states as bad if the HLS information is not present immediately after a helicity state change. Current status This appears to be recovering most of the data. I next need to verify the helicity labels in the DST file and then try some more runs to search for algorithm failures.
Angela Bisselli determined the full extent of a problem we have known about for some time. The DSTs are written such that physics events are grouped according to the beam helicity. This grouping is done like a "double nested for loop". The DST file has a "bank" or record which is labeled "HELEVENT". This "bank" contains information which identifies the helicity of the physics events which are to come in the next record/bank called the "PHYS" bank. The "HELEVENT" also contains the event number of the first and last physics events which were reconstructed during the helicity state. In version 1.0 of the DST writer we were finding that some events were being written more than once.
For example in dst file dst27078_00.B00
EvMin EvMax helicity
HELEVENT° : 94895 94928 : hel=4
HELEVENT° : 94936 94969 : hel=1
HELEVENT° : 94936 94969 : hel=1
HELEVENT° : 95013 95047 : hel=1
HELEVENT° : 95054 95095 : hel=4
The physics events with event numbers 94936 -> 94969 appear to have been written twice and the physics events between 94970->95012 appear to have been skipped. (Note: only reconstructed tracks are written out so the skip from event 94928 to 94936 is probably because an electron was not reconstructed for those 7 triggered events)
But if you look at the physics events within the above helicity blocks you find that the events within the "PHYS" bank do not lie within the range of numbers recorded in the second duplicate "HELEVENT" bank. Those physics events are probably for the next helicity state.
HELEVENT PHYS
EvMin EvMax EvMin EvMax
94936 94969 1 1 94936 94969
94936 94969 1 1 94978 95007
Conclusion: "PHYS" events 94978->95007 have the wrong "HELEVENT" label.
Safest Work around: In your physics analysis require that the physics event numbers recorded in the "HELEVENT" bank increase.
The cause of the mislabeling may be due to a bug my HelP table lookup routine which I use for writing the DST file.
Indexing problem was found for TRL1 DC information. only Y & Z positions were written to TRL1_X and TRL1_Y respectively. The DST writer in the claseg1 account was changed on September 19, 2003 and the CVS repository was updated on October 14, 2003.