Removed hard-coded dxdy and uses per-sector dxdy.
-
Removed dxDy hardcoding from all tracking algorithms in HLT1. -
Test efficiencies in real data. -
Test the UT hits extrapolation and tolerance window cuts. -
Combine UTGeometry
andUTBoard
into one.
To be merged with: LHCb!4640 (merged), Detector!590 (merged) and Moore!3677 (merged)
Changes to Allen
-
dxDy
added as a member variable field toUTHits
event model andUTGeometry
. - Downstream and matching with UT uses a common
UTHitCache
. -
UTHitCache
now contains per-hitdxDy
information. This change neither increase shared memory nor register-per-thread usage in matching with UT algorithm (same can be assumed for downstream). -
UTHitCache
encodes and decodes UT hitsdxDy
and sectordy
information with 8 bits which keeps the shared memory usage the same despite adding more information. The encoder-decoder also uses constant memory, hence no increase in register usage. - UT hits test updated to check
dxDy
information. - Forward tracking also uses per-hit
dxDy
now instead of hardcoded per-layer values.
Testing on Real Data
- The HLT1 thresholds for charm yields are
no_ut_tuned_mu4_1000KHz_v1
, for both matching and forward sequence. - The
Ks-> pi pi
yields uses a custom set of cuts.
Matching with UT Charm Yields
After removing per-sector dxDy, we get 20-25% more charm yields passing through TOS triggers of Hlt1OneTrackMVA | Hlt1TwoTrackMVA
. Tested on run 297074.
Forward with UT Charm Yields
The differences here are more drastic since velo-UT part of forward tracking relies heavily on having well-aligned UT detector.
Matching with UT Ks->pi pi
After removing per-sector dxDy, we get 10% more Ks->pi pi in HLT1 (with some selections).
Edited by Da Yu Tou