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
remove nonsense error along trajectory #17056
remove nonsense error along trajectory #17056
Conversation
A new Pull Request was created by @VinInn (Vincenzo Innocente) for CMSSW_9_0_X. It involves the following packages: RecoEgamma/EgammaPhotonAlgos @cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here #13028 |
@cmsbuild , please test |
The tests are being triggered in jenkins. |
@VinInn |
phase0 ttbar PU35 25ns in aout 420 events |
thanks, seems clear enough for this sample. |
after clarifying in the email thread, it looks like the error along momentum is indeed zero by construction (modulo numerical precision) |
|
Comparison job queued. |
+1 Eliminating pointless calculation of a trajectory error that is always essentially zero. There should be no change in monitored quantities. The code change is satisfactory, and Jenkins tests against baseline CMSSW_9_0_X_2016-12-16-1100 show no significant differences, as expected. Additional tests of workflows 1318.0_SingleGammaPt10 and 25202.0_TTbar_13 with 200 events each against baseline CMSSW_9_0_X_2016-12-16-1100 also show no significant differences. |
This pull request is fully signed and it will be integrated in one of the next CMSSW_9_0_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @smuzaffar |
+1 |
Pretty obvious
in case you really wonder:
it seems to me that the author is trying to compute the trajectory error along the track direction.
At best of my understanding the trajectory is evaluated at fixed "path length" (or on the surface) and given such a constrain the error along the track direction shall be zero
If I add
I get [1] that seems to confirm my argument...
This PR goes in the direction of getting rid of Trajectory clients outside Pattern-Recognition and track fitting
v.
[1]