Update on Run11 dsm algorithm coding
To improve the output matching between the DSM output bits in the data and the simulation, I tried a number of things related to interpreting the part of the dsm algorithm where its mentioned that the least significant 5 bits of the cluster sums be extracted and the result be set to 31 if either of the two most significant bits are set. The instructions weren't very clear and the direct interpretation looked a bit unwise as well, especially looking at the two most significant bits after extracting the least significant 5 bits.
After some playing around, the thing that works best is: just summing the pairs and getting the cluster sums and truncating it to 5 bits (just check if the sum > 31, in which case set it to 31). The same method is used later for quadrant sums, where 6 bits are used instead of 5 bits. With this, the test results are as follows:
Bit 0 Fms-HT-th0 0
Bit 1 Fms-HT-th1 0
Bit 2 FmsSml-Cluster-th0 18
Bit 3 FmsSml-Cluster-th1 22
Bit 4 FmsSml-Cluster-th2 17
Bit 5 FmsLrg-Cluster-th0 21
Bit 6 FmsLrg-Cluster-th1 15
Bit 7 FmsLrg-Cluster-th2 14
Bit 8 Fms-JP-th0 36
Bit 9 Fms-JP-th1 55
Bit 10 Fms-JP-th2 56
Bit 11 Fms-dijet 5
The above table shows numbers much better than my previous test, which can be found in my previous post. Also, in this test 849/1000 events had all the bits exactly matching.
It is now useful to figure out if the current discrepency is because of some bug in my code or is because of some fms geometry/qt information being not updated for Run 11 in the already existing code. This is what I plan to work on now.
- adhikari's blog
- Login or register to post comments