1. Gianluigi, 10 Sep 2012 Paris, September 10 th 2012 Status of the Pattern Recognition Code Gianluigi Boca GSI & Pavia University 1

2. Outlook The semplification of the code of Central Tracker (Stt+Mvd+SciTil) Pattern Recognition : performances; Directions for further improvements; Gianluigi, 10 Sep 2012 Speeding up the code : status and performances after the improvements; To Do list. 2

3. 3 The semplification of the code of Central Tracker (Stt+Mvd+SciTil) Pattern Recognition : performances;

4. 4 Before : two separate tasks : 1) STT alone Pattern Recognition,; 2) STT – MVD  SciTil combined Pattern Recognition; Now : only one task with STT + MVD + SciTil Pattern Recognition Let’s see the performances of this PR in terms of : 1) track reconstruction efficiency 2) % of ghost tracks 3) % of true hits in reconstructed tracks 4) % of fake hits in reconstructed tracks 5) resolution on momentum of track 6) Cpu time consumption.

5. 5 Track Reconstruction Efficiency % of reconstructed tracks. In these plots ‘reconstructed track’ means AT LEAST 80% of the TRUE Stt+Mvd hits. No BkgBkg added MC generation : Box Generator; multiplicities from 1 up to 8; momenta from 0.3 to 10 GeV/c. Low efficiency at 0.3 GeV/c ! Why ? Low efficiency at 0.3 GeV/c ! Why ?

6. 6 Example of event causing the trouble Total P : 0.3 GeV/c ; 8  tracks, no Bkg added Green = MC truth tracks Red = tracks found Mvd Pixel Mvd Strip Stt Skew, (mid position!) Stt Parallel SciTil Those events happen approximately  % of the times !

7. 77 Ghost tracks per event Only non-fake reconstructed tracks in these plots. Bkg added MC generation : Box Generator; multiplicities from 1 up to 8; momenta from 0.3 to 10 GeV/c. No Bkg

8. Bkg added Axial 8 Bkg added Skew % Stt true hits in recon.ted (non-fake) tracks No Bkg

9. Axial 99 Bkg added Skew % Stt spurious hits in recon.ted (non-fake) tracks No Bkg Bkg added

10. 10 Generally speaking, the efficiencies are slightly better than last year’s code and the contaminations are a bit higher. I haven’t investigated deeply why it is so and I will do that but I suspect that is due to some trimmering of the proximity parameters used in the code.

11. 11 No Kalman filter, only Pattern Recognition momenta. No BkgBkg added MC generation : Box Generator; multiplicities from 1 up to 8; momenta from 0.3 to 10 GeV/c. P tot resolution Only non-fake reconstructed tracks in these plots.

12. 12 No Kalman filter, only Pattern Recognition momenta. No Bkg MC generation : Box Generator; multiplicities from 1 up to 8; momenta from 0.3 to 10 GeV/c. P z resolution Only non-fake reconstructed tracks in these plots. Bkg added

13. 13 The momentum resolutions are the same as those obtained with last year’s code.

14. 14 Cpu time consumption MC generation : Box Generator; multiplicities from 1 up to 8; momenta from 0.3 to 10 GeV/c. No Bkg Bkg added Cpu times measured on an Intel Xeon 2.13 GHz 64 bit Lenny machine

15. 15 Speedup of the code of Central Tracker (Stt+Mvd+SciTil) Pattern Recognition : performances;

16. 16 Further improvements of the code: thanks to the unification of the Stt-Mvd-SciTil code, one cycle of fits over the candidate tracks has become redundant and it has been eliminated. Also for this new verson of the code performance test has been performed : 1) track reconstruction efficiency 2) % of ghost tracks 3) % of true hits in reconstructed tracks 4) % of fake hits in reconstructed tracks 5) resolution on momentum of track 6) Cpu time consumption. The efficiencies/resolution obtained with this new algorithm turned out to be just the same (obviously !) and I don’t show them. Only the Cpu times are different.

17. 17 Cpu time consumption, new algorithm MC generation : Box Generator; multiplicities from 1 up to 8; momenta from 0.3 to 10 GeV/c. No Bkg Bkg added Cpu times on an Intel Xeon 2.13 GHz 64 bit Lenny machine

18. Cpu time consumption comparison old/new algorithm Type of eventOld CodeNew Code sec/evt/track P = 0.3 GeV/c ; 1 trk0.800.71 P = 1 GeV/c ; 1 trk0.140.10 P = 2 GeV/c ; 1 trk0.140.11 P = 5 GeV/c ; 1 trk0.120.08 P = 10 GeV/c ; 1 trk0.130.10 P = 0.3 GeV/c ; 4 trk1.040.98 P = 1 GeV/c ; 4 trk0.230.19 P = 2 GeV/c ; 4 trk0.320.29 P = 5 GeV/c ; 4 trk0.330.30 P = 0.3 GeV/c ; 8 trk1.871.81 P = 1 GeV/c ; 8 trk0.680.64 P = 2 GeV/c ; 8 trk0.750.73 No Bkg

19. Cpu time consumption comparison old/new algorithm Type of eventOld CodeNew Code sec/evt/track P = 0.3 GeV/c ; 1 trk12.1111.87 P = 1 GeV/c ; 1 trk11.5511.30 P = 2 GeV/c ; 1 trk11.5711.39 P = 5 GeV/c ; 1 trk11.4311.11 P = 10 GeV/c ; 1 trk11.3511.14 P = 0.3 GeV/c ; 4 trk4.254.21 P = 1 GeV/c ; 4 trk3.483.36 P = 2 GeV/c ; 4 trk3.493.38 P = 5 GeV/c ; 4 trk3.673.59 P = 0.3 GeV/c ; 8 trk4.124.10 P = 1 GeV/c ; 8 trk2.882.79 P = 2 GeV/c ; 8 trk2.812.75 With Bkg

20. In general there is an improvement of ~  % still not satisfactory!

21. 21 Directions for further improvements

22. Strategies for making the code faster Presently the bottleneck is the amount of time spent for fitting a track. Therefore the strategies to follow are : 1)try a different fitting algorithm. Now the minimizer is much faster than Minuit and it gives the nice option of solving the right/left ambiguity for each straw hit or even rejecting the hit from the fit (a form of annealing filter). However a faster analitic algorithm (even if rougher) could work as well, or a Hough transform method (ONLY FOR FITTING THE FINAL TRACK PARAMETERS!); 2)the use of the SciTil as initial seed of the track has not so far fully exploited; 3)the number of iterations over the hits can further be diminuished; 4)the code CAN BE PARALLELIZED. Some modifications are are required at the beginning of the algorithm, but rather minor.

23. To Do list

24. 24 Improvement of the cleanup code with the use of a precise geometry; The V 0 Pattern Recognition; Speed up the code further implementing the strategies outlined above; The issue of how the Annealing filter works in the Kalman.

25. 25 Finally, I would ike to start EVO meetings on a regular basis devoted to the pattern recognition issues (offline and online). Everybody is warmly invited !!

26. Summary The semplification of the code of Central Tracker (Stt+Mvd+SciTil) Pattern Recognition with the unification of the Stt alone and Stt+Mvd tasks has been done and the performances has been shown; efficiencies (slightly better), spurious hits (slightly worse) and momentum resolution are essentially the same as last year’s code; the momentum resolutions are the same; directions for further improvements has been discussed; someome redundant fit loops in the code has been eliminated; the code now is some  % faster; To Do list has been shown. Thank you for your attention!