This merge was reverted by !832 (merged) and has thus not been applied to master. It will be applied to TDR branch instead, and will make it to master when TDR is merged to master.
Forward velo tracks can be identified by having all Zhits > -100 mm ,
Backward velo tracks can be identified by having all Zhits < 100 mm.
In the algorithm one can check from dx , dy that
dr/dz > 0 (<0) if looking to pairs of hits in z > -100 ( z< 100 mm ) and make an early killing of combinatorics in the pair creation.
The original velo pixel tracking was searching pairs scanning from LastModule ( most downstream ) to FirstModule (the most downstream).
When dealing with forward tracks this is kept, for backward tracks search, the best is to reverse the order of looping.
Indeed, the most time consuming part is the central region z in [-100, 100] mm which is shared between the forward/backward track search, but if in a sequential approach you flag hits starting downstream ( upstream) , you likely save computing time because you will find (at the end of the execution) hits flagged between [-100, 100] mm
According to the flagging of the hits, one can perform first a forward track search and later a backward track search.
In the current implementation you can come back to original simple.
From a first check , this brings a 25% speed-up in the actual calculations with a tiny drop of efficiencies.
From a comparison of performance on 1000 minBias event with seeding and velo tracking [ independent algorithms ]
Default
lb-run --nightly-cvmfs --nightly --lhcb-future Brunel/future PrChecker2Fast INFO ResultsPrChecker2 INFO ResultsPrChecker2.Velo INFO **** Velo 212406 tracks including 3741 ghosts [ 1.76 %], Event average 1.26 % ****PrChecker2.Velo INFO 01_velo : 105761 from 107069 [ 98.78 %] 3226 clones [ 2.96 %], purity: 99.81 %, hitEff: 95.00 %PrChecker2.Velo INFO 02_long : 61612 from 61845 [ 99.62 %] 775 clones [ 1.24 %], purity: 99.85 %, hitEff: 97.80 %PrChecker2.Velo INFO 03_long>5GeV : 39500 from 39626 [ 99.68 %] 342 clones [ 0.86 %], purity: 99.86 %, hitEff: 98.36 %PrChecker2.Velo INFO 04_long_strange : 3107 from 3139 [ 98.98 %] 32 clones [ 1.02 %], purity: 99.34 %, hitEff: 97.74 %PrChecker2.Velo INFO 05_long_strange>5GeV : 1503 from 1525 [ 98.56 %] 11 clones [ 0.73 %], purity: 99.15 %, hitEff: 98.25 %PrChecker2.Velo INFO 06_long_fromB : 64 from 66 [ 96.97 %] 0 clones [ 0.00 %], purity: 99.78 %, hitEff: 98.72 %PrChecker2.Velo INFO 07_long_fromB>5GeV : 46 from 46 [100.00 %] 0 clones [ 0.00 %], purity: 99.69 %, hitEff: 98.74 %
Forward_tracks + Backward_tracks splitted (with these changes)
On top of current master branch PrChecker2Fast INFO ResultsPrChecker2 INFO ResultsPrChecker2.Velo INFO **** Velo 211305 tracks including 2746 ghosts [ 1.30 %], Event average 0.96 % ****PrChecker2.Velo INFO 01_velo : 105545 from 107069 [ 98.58 %] 3156 clones [ 2.90 %], purity: 99.83 %, hitEff: 95.01 %PrChecker2.Velo INFO 02_long : 61536 from 61845 [ 99.50 %] 763 clones [ 1.22 %], purity: 99.86 %, hitEff: 97.79 %PrChecker2.Velo INFO 03_long>5GeV : 39477 from 39626 [ 99.62 %] 340 clones [ 0.85 %], purity: 99.87 %, hitEff: 98.35 %PrChecker2.Velo INFO 04_long_strange : 3089 from 3139 [ 98.41 %] 29 clones [ 0.93 %], purity: 99.35 %, hitEff: 97.80 %PrChecker2.Velo INFO 05_long_strange>5GeV : 1498 from 1525 [ 98.23 %] 11 clones [ 0.73 %], purity: 99.15 %, hitEff: 98.28 %PrChecker2.Velo INFO 06_long_fromB : 64 from 66 [ 96.97 %] 0 clones [ 0.00 %], purity: 99.78 %, hitEff: 98.72 %PrChecker2.Velo INFO 07_long_fromB>5GeV : 46 from 46 [100.00 %] 0 clones [ 0.00 %], purity: 99.69 %, hitEff: 98.74 %
People which may be interested in this and comment on the change:
@adudziak , @decianm , @graven , @chasse , @raaij , @fpolci, @sponce , @cofitzpa , @gligorov let me know if there are some corner case i am missing ( for instance tracks at large z with a dr/dz < 0 ? ) and if what I did here looks reasonable and if I have to test the timing improvement w.r.t to the current master branch.
Merge branch 'rquaglia_splitVeloPix_Forward_BackwardTracks' into 'rquaglia_splitVeloPix_Forward_Backward'
move enum to int values
See merge request !817
