Restore old performance for Velo tracking using Phi-Sorted hits.
In this MR i tried to solve the issues #12 (closed) Basically I propose in the code 3 different configuration:
One which should gives as performance the ones which are currently in the nightlies, One for the best throughput (Still to be checked if it gives back same performance or not) , One for the BestPhysics scenario.
For the best physics scenario here is what i get as tracking efficiencies:
PrChecker2Fast INFO Results
PrChecker2Fast.... INFO **** Velo 200293 tracks including 1952 ghosts [ 0.97 %], Event average 0.88 % ****
PrChecker2Fast.... INFO 01_velo : 102095 from 104208 [ 97.97 %] 3536 clones [ 3.35 %], purity: 99.82 %, hitEff: 93.43 %, hitEffFirst3: 92.46 %, hitEffLast: 93.68 %
PrChecker2Fast.... INFO 02_long : 59416 from 59754 [ 99.43 %] 757 clones [ 1.26 %], purity: 99.87 %, hitEff: 96.81 %, hitEffFirst3: 95.99 %, hitEffLast: 97.17 %
PrChecker2Fast.... INFO 03_long>5GeV : 38321 from 38447 [ 99.67 %] 307 clones [ 0.79 %], purity: 99.89 %, hitEff: 97.48 %, hitEffFirst3: 96.84 %, hitEffLast: 97.79 %
PrChecker2Fast.... INFO 04_long_strange : 2919 from 2978 [ 98.02 %] 41 clones [ 1.39 %], purity: 99.50 %, hitEff: 96.54 %, hitEffFirst3: 95.75 %, hitEffLast: 96.70 %
PrChecker2Fast.... INFO 05_long_strange>5GeV : 1420 from 1443 [ 98.41 %] 14 clones [ 0.98 %], purity: 99.38 %, hitEff: 97.19 %, hitEffFirst3: 96.61 %, hitEffLast: 97.35 %
PrChecker2Fast.... INFO 06_long_fromB : 3795 from 3814 [ 99.50 %] 25 clones [ 0.65 %], purity: 99.89 %, hitEff: 97.13 %, hitEffFirst3: 96.11 %, hitEffLast: 97.56 %
PrChecker2Fast.... INFO 07_long_fromB>5GeV : 3140 from 3148 [ 99.75 %] 14 clones [ 0.44 %], purity: 99.90 %, hitEff: 97.45 %, hitEffFirst3: 96.53 %, hitEffLast: 97.80 %
PrChecker2Fast.... INFO 08_long_electrons : 4392 from 4576 [ 95.98 %] 47 clones [ 1.06 %], purity: 98.08 %, hitEff: 90.67 %, hitEffFirst3: 83.91 %, hitEffLast: 93.68 %
PrChecker2Fast.... INFO 09_long_fromB_electrons : 211 from 215 [ 98.14 %] 4 clones [ 1.86 %], purity: 98.78 %, hitEff: 92.44 %, hitEffFirst3: 88.84 %, hitEffLast: 94.76 %
PrChecker2Fast.... INFO 10_long_fromB_electrons_P>5GeV : 149 from 150 [ 99.33 %] 2 clones [ 1.32 %], purity: 98.90 %, hitEff: 93.02 %, hitEffFirst3: 89.40 %, hitEffLast: 94.89 %
PrChecker2Fast.... INFO 11_long_fromB_P>3GeV_Pt>0.5GeV : 2905 from 2912 [ 99.76 %] 14 clones [ 0.48 %], purity: 99.92 %, hitEff: 97.31 %, hitEffFirst3: 96.24 %, hitEffLast: 97.71 %
PrChecker2Fast.... INFO GeV : 2900 from 2907 [ 99.76 %] 14 clones [ 0.48 %], purity: 99.92 %, hitEff: 97.31 %, hitEffFirst3: 96.25 %, hitEffLast: 97.71 %
PrChecker2Fast.... INFOAccording to #12 (closed)
The target for our tracking efficiencies were something like what i put here after (sorted by X hits). I think we get quite a big improvement for the fake rate, but still 1% hit effiencies off) The hit efficiencies are not at the maximum level because the old algorithm when started to not find a hit in the same side module, was starting looking left/right in all the sequent modules. In the phi-sorted implementation this doesn't happen or at least not making the jump continuosly but only under some conditions.
PrChecker2 INFO Results
PrChecker2.Velo INFO **** Velo 290093 tracks including 7928 ghosts [ 2.73 %], Event average 2.07 % ****
PrChecker2.Velo INFO 01_velo : 146394 from 148676 [ 98.47 %] 5345 clones [ 3.52 %], purity: 99.74 %, hitEff: 94.03 %
PrChecker2.Velo INFO 02_long : 85044 from 85367 [ 99.62 %] 1142 clones [ 1.33 %], purity: 99.81 %, hitEff: 97.60 %
PrChecker2.Velo INFO 03_long>5GeV : 54882 from 55035 [ 99.72 %] 482 clones [ 0.87 %], purity: 99.83 %, hitEff: 98.28 %
PrChecker2.Velo INFO 04_long_strange : 4157 from 4206 [ 98.83 %] 61 clones [ 1.45 %], purity: 99.29 %, hitEff: 97.31 %
PrChecker2.Velo INFO 05_long_strange>5GeV : 2025 from 2057 [ 98.44 %] 16 clones [ 0.78 %], purity: 99.07 %, hitEff: 98.36 %
PrChecker2.Velo INFO 06_long_fromB : 4666 from 4682 [ 99.66 %] 30 clones [ 0.64 %], purity: 99.84 %, hitEff: 98.18 %
PrChecker2.Velo INFO 07_long_fromB>5GeV : 3853 from 3861 [ 99.79 %] 16 clones [ 0.41 %], purity: 99.87 %, hitEff: 98.52 %Probably there are some other tuning which can be done. Reading carefully the checker, one can see that 1/2 of the tracks found (and for which) the tracking efficiencies are quoted are outside the eta [2,5] and we find roughly a factor 2 more tracks .
Therefore , I believe that even tough the BestPhysics scenario is slower ( to be measured ) than what we use to have as displaced track reconstruction, we can reach the same thorughput avoiding to reconstruct backward tracks. I try to make some measurement on this.
@graven , thanks a lot for the comments you made to the issue and the code. I tried to port what you suggested inside ( except the Phi conversion from degree to radiants ). I left some comments in the code which are open discussions.
FYI: @adudziak , @gligorov , @cattanem , @sponce , @graven , @chasse , @sstahl , @fpolci. I will show tomorrow at the T&A meeting some of the things i implemented in the code and if I manage some throughput results for the various configurations.
For the time being i left as "default" a version for which you should not see any discrepancy with the nightly. We can therefore, decide what is the default to adopt.
I would let this in WIP for a bit, in the meanwhile people comment the lines and make suggestions of improvements, in particular for the BestPhysics scenario.
FYI : @dovombru , @dcampora , you may can take benefit of the improvement in tracking efficiencies also for the GPU version.
In attachment some slides about the various cases and performances (throughput/efficiencies) It seems like the Slides_VeloTrackingUpdate.pdf throughput measurement in the fast configruation are unchanged.