There was a bug in the code designed to throw away unreasonable fits, but it was throwing away all fits to deconvoluted time spectra when TRFF=2. (For info on TRFF=0,1,2, see our discussion on the time deconvolution in the old hitfinder.) Therefore, the evaluations below in settings 1, 2, and 3, were essentially TRFF=0 (no convolution).
When the bug was fixed (compare settings 3 and 8), we find more hits (naturally) but the number of tracks goes down by like 30% !!
TRFF=0 (no deconvolution) gives the least hits (18420) but the most tracks (238.6). See setting 7.
TRFF=1 (Gulshan's Gaussian fits) gives 22870 hits and 174.8 tracks on average. See setting 6.
TRFF=2/DECON=1 (Mike's asymmetric Gaussian with fixed width) gives 23260 hits and 183.7 tracks. See setting 8.
TRFF=2/DECON=2 (Mike's asymmetric Gaussian with varying width) gives 23080 hits and 181.4 tracks. See setting 10. This setting does the best (judged by eye) in deconvoluting overlapping peaks in time, but it takes 5-8 times longer in cpu, with no real improvement in efficiency!!!!
It is fair to say that with distortion and t0 corrections turned off, and tracking done in single-pass mode, the new (2d) algorithm does much better than the old hitfinder. Compare setting 4, which is the new hitfinder run in its simplest mode.
The number of tracks found is significantly higher (300) than the best seen with the old hitfinder (239 in setting 7).
The hits/track of the found tracks is about 15% longer (33.7 compared to roughly 29) with the new hitfinder.
The hit removal efficiency is also much higher (about 50% compared to about 20-30%).
The cpu time (for both hitfinding and tracking) is comparable to the fastest seen for the old hitfinder (compare 269 sec/event in setting 4 to 240 sec/event in setting 6). And it is considerably faster than the "best" old hitfinder setting (438 sec/event for setting 7).
So far we have made a comparison with the distortion correction on and off with no time deconvolution, no t0 correction applied, and in the pre-official code. This should be done again with the official code.
The result was (see settings 1 and 2): The number of tracks found went down from 236.7 to 225.5 on average. Not much else changed.
The same test was tried again with the CVS "official" code and macros. See settings 11 and 12. It was disappointing to find that there is not much improvement, if any at all. The average multiplicity and residuals get a bit worse, if anything.
We don't know any effects of this because the damned thing was hard-wired disabled in the code. :(
First look at this indicates no big change going from pre-official code to the one now (23mar97) in CVS library. Compare settings 11 and 6, both done with trff=decon=1, no t0 correction, and no distortion correction.
Looking at the new hitfinder algorithm (compare setting 4 with setting 13), also we see very little change going from pre-official to official.
coming soon...
The reason I am looking at this is that both the old and new hitfinder seemed to have worked better when we were at Brookhaven than they do now. It is the *same* code, so I suspect something in the tracker has changed. The only switch difference between now at at Brookhaven has been the TRK_SW.VCALC setting. But, as you can see by comparing results of this setting with those of the previous one (setting 4), this switch does not make a difference.
I wonder therefore if the VCALC algorithm has been disconnected altogether since we left Brookhaven?
The gist is that the bug essentially threw away all convolution peaks when TRFF=2, making it perform as if it were TRFF=0 (compare evaluations 3 and 7). Now, with the bug fixed, most of the pulses pass the "quality" test, and TRFF=2 performs similarly to TRFF=1 (compare this setting to setting 6).
