ACD Software scalar documentation
Monday, July 19, 2004 2:29 PM
The software accumulates three distinct sets of numbers and uses both the GEM and ACD contributions as input to from the output record)
The first 9 32-bit numbers are arranged a 3 x 3 array giving the status of the GEM and ACD contributions. The next 7 are spares for future expansion. Either contribution (GEM/ACD) may be
Currently the GEM contribution can generate no internal errors. About the only thing that I could think of was that the length of the GEM contribution did not match the expectation (the length of the GEM contribution is constant). The ACD contribution, however, can generate internal consistency errors, so things may show up in this category. As soon as I have a good idea of what to check for, I may change the GEM contribution to check for consistency also.
The 3x3 numbers are laid out as
So, for example, entry 0 is both ACD and GEM Present and OK. The GEM is the faster moving index. See EMP/ASC.h for details; its the ASC_SUMMARY enumeration. Naturally, there really is no category called Missing&InError.
Here is a formatted view of these numbers from a test set of data. You can tell it is a test set since all events have both GEM and ACD contributions in the Present & Ok state; i.e. everything is perfect.
| GEM |
| Total Events | PRESENT | |
| +-----------------+ MISSING|
| 186 | OK | ERROR | |
| | P | OK | 186| 0| 0|
| A | R +------+--------+--------+--------+
| E | S | ERR | 0| 0| 0|
| M +---+------+--------+--------+--------+
| | MISSING | 0| 0| 0|
What to do about events with missing contributions
There was a design decision I had to make; what to do with events having a missing contribution. The decision was to update the remaining statistics as best I could. This causes no confusion for the CNO statistics, since either the ACD contribution is present (in which case they are accumulated) or the ACD contribution is absent (in which case, surprise, surprise, they aren't accumulated). However the tile statistics block does mix the two contributions in a way which is obvious once you read what is being accumulated, so a missing ACD or GEM contribution could distort the statistics. For the application currently targeted, testing of the ACD, this seemed like a reasonable compromise. (If I carry these counters into the FSW proper, I'll probably separate the tile statistics into 3 classes; ACD only, GEM only; ACD&GEM both present.)
The CNO statistics block is a block of 4 numbers for each of the 6 A/B board pairs. The four numbers for each board pair represent the number of events where
For reasons of efficiency, category 0 (CNO signal was absent on both boards) is not accumulated, but can be easily gleaned from the data by subtracting the sum of the other 3 categories from the total number of events accumulated.
Here is a formatted example (note that I didn't even bother with the CNO signal absent of both boards category).
1LA: 36 2LA: 0 2RA: 36 3LA: 114 4LA: 0 4RA: 0
1RB: 0 2LB: 0 2RB: 0 3RB: 0 4LB: 0 4RB: 0
Both: 0 Both: 0 Both: 0 Both: 0 Both: 0 Both: 0
Ah, the main course. On a per tile basis, an array of 32 counters is accumulated. The index of this array (running from 0->31) is actually a bit mask of the status of the 5 differ rent bits associated with each tile. The index is formed as follows
So, a counter at array index of 31 (0x1f) have all 5 bits set. Note also that, again for efficiency reasons, index 0, no bits set, is not accumulated, but can be had be subtracting the sum of all the other entries from the total number of events.
Why did I choose this method?
Depending on the setting of the discriminators one would certainly expect various strong correlations. For example, all things being equal (efficiency collection, light transport, photo-tube gains, amplifier gains, discriminator setting etc), one would expect a high correlation between the A and B readouts of the same tile. One can check if there is consistency by beating the 5 signals against each other.
The tiles arrays are arranged in 4 arrays of 32. These 4 arrays or 32 tiles and the order within the 32 tiles match the order of the tiles in the GEM data (bit 0 = array index 0). This ordering of the tiles was another design decision, but a somewhat easier one than the previous decision on what to do when an ACD or GEM contribution was missing. The order could have been by electronics, essentially following the board order, or it could have been (as was chosen) by the more geometrical order as presented by the GEM data. I choose the latter for two reasons
Basically, I didn't want to destroy any information. Naturally I can't preserve all the information present in the raw data, but I thought this scheme allowed for preserving some of the more interesting correlations.
SUGGESTIONS ON USAGE
The software I provided only does 2 things interesting to you, accumulates the statistics and clears the statistics. The starting/stopping and when to clear is purely a LATTE control functionality. I would suggest that one use the CLEAR function sparingly. I would suggest whenever one wished to issue a clear, instead one read the statistics at that point and make it a base-line set. Display of subsequent readings would then subtract this base-line set to get the delta.
This scheme has two advantages.