Skip to content

Try to fix ft zone order

Monir Hadji requested to merge fix-ftzone-ordering into master

related to @jvantilb suggestion on this comment from !882 (merged)

to be consistant with input data from raw bank to avoid weird adaptation on some parts supposedly generic

get rid of the specific ft code on MultiIndexedHitContainer and adaptation of algorithms using ft hits

old order assumed by PrStoreFTHit ; PrForwardTracking

 y ^
   |    0  2  4  6     8 10 12 14    16 18 20 22
   |    |  |  |  |     |  |  |  |     |  |  |  |
   |    |  |  |  |     |  |  |  |     |  |  |  |
   |------------------------------------------------> z
   |    |  |  |  |     |  |  |  |     |  |  |  |
   |    |  |  |  |     |  |  |  |     |  |  |  |
   |    1  3  5  7     9 11 13 15    17 19 21 23

current order assumed by PrStoreFTHit ; PrForwardTracking

 y ^
   |    1  3  5  7     9 11 13 15    17 19 21 23
   |    |  |  |  |     |  |  |  |     |  |  |  |
   |    |  |  |  |     |  |  |  |     |  |  |  |
   |------------------------------------------------> z
   |    |  |  |  |     |  |  |  |     |  |  |  |
   |    |  |  |  |     |  |  |  |     |  |  |  |
   |    0  2  4  6     8 10 12 14    16 18 20 22

the input order (based on current name) from raw bank is [ 0 ; 1 ; 2 ; 3 ; ...

TODO

  • adapt HLT1 (prforwardtracking) to this numerotation of ft hits
  • adapt HLT2 to this numerotation of ft hits

cc @rquaglia

Edited by Marco Cattaneo

Merge request reports