New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix SeedExtensionTrajectoryFilter when it is disabled #14472
Conversation
A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_8_1_X. It involves the following packages: TrackingTools/TrajectoryFiltering @cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are list here #13028 |
@cmsbuild please test |
The tests are being triggered in jenkins. |
+1
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_8_1_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @Degano, @smuzaffar |
@davidlange6 |
+1 |
It turns out that in some corner cases the
SeedExtensionTrajectoryFilter
, with its default configuration parameters, stops trajectory propagation, in contrast to the intent of the default values (that would be "no effect"). These cases are essentially such that the trajectory has at most as many measurements as the seed, and no lost hits (i.e. the condition oflooseTBC
), and occur e.g. inmuonSeededStepInOut
(where seeds have many hits) when rebuilding the trajectory in the seed region (can lead to lost hits).Here are MultiTrackValidator plots from 1000 TTbar+PU events (red is with this PR) https://mkortela.web.cern.ch/mkortela/tracking/validation/CMSSW_8_1_X_seedExtension/
The effect becomes more noticeable if we start to reject trajectories stopped by
SeedExtension
(as in #14356).Tested in CMSSW_8_1_X_2016-05-09-2300, expecting tiny changes in tracking.
@rovere @VinInn: I decided to use the value of
seedExtension
parameter directly to dictate whether the filter should be enabled or not (<= 0
for disabled,> 0
for enabled) instead of introducing a new flag, since these interpretations of the parameter values are compatible with the current intended uses.