-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Seed Extension #12517
Seed Extension #12517
Conversation
@cmsbuild, please test |
The tests are being triggered in jenkins. |
A new Pull Request was created by @VinInn (Vincenzo Innocente) for CMSSW_8_0_X. It involves the following packages: RecoEgamma/EgammaPhotonProducers @cmsbuild, @cvuosalo, @davidlange6, @slava77 can you please review it and eventually sign? Thanks. Following commands in first line of a comment are recognized
|
@VinInn I see quite a few changes in jenkins comparisons. |
Sorry, @slava77 , could you point me to the most relevant differences? in any case, expected changes: NONE |
It's clearly not "NONE", not literally. |
Ok, I understand the change and I should correct the NONE. Trk-POG considers this new behavior correct. I agree that my previous statement was wrong. |
There is a one-track difference in generalTracks as well Please get the regular tracking (pre)validation plots. |
here is mtv for ttbar 15PU 25ns 1000 events... |
@cmsbuild please test |
The tests are being triggered in jenkins. |
explicit SeedExtensionTrajectoryFilter() {} | ||
|
||
explicit SeedExtensionTrajectoryFilter(edm::ParameterSet const & pset, edm::ConsumesCollector&) : | ||
theStrict(pset.existsAs<bool>("strictSeedExtension") ? pset.getParameter<bool>("strictSeedExtension"):false), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what prevents making fillDescriptions for these?
Use of pset.existsAs in new code is an exception that needs to be justified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is a PSet...
@makortel looked into this kind of issue last year, he may comment further (there is also an issue with PSet_Ref)
In any case with @mtosi we will review the use in HLT and eventually remove all those "exitsAs" that I dislike as well.
At the moment we need them if we with to progress fast (as HLT asked)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So let me repeat the story (again, and maybe some day we get there). The inherent "problem" is that the tracking code is organized as EDProducers that make extensive use of helper plugins (that use plugins that use plugins; by very quick look I can indeed find three layers of these...), and I'm not aware of any "easy" solution for fillDescription for plugins. E.g. the TrajectoryFilter
s here are such plugins.
One option suggested by @Dr15Jones
https://hypernews.cern.ch/HyperNews/CMS/get/edmFramework/3446/1.html
would be to create a second class structures only for the fillDescriptions (my impression of the thread above is that the validation system does not currently understand refToPSet_
). Back when we decided to replace the ESProducers with helper plugins and refToPSet_
we had many other alternatives on the table
https://indico.cern.ch/event/308199/contribution/8/2/attachments/588340/809738/slides.pdf
https://hypernews.cern.ch/HyperNews/CMS/get/edmFramework/3244/4/1.html
I'm repeating these because one of the options back then was to store the helper algorithms to event (EDProducers could naturally use fillDescriptions), but downsides being either
- no finer-grained caching than event (e.g. seed), or
- rewriting algorithms to separate the transient state and pass that around
- (or we could try to see if all fine-grained caching is still needed, I don't anymore remember which pieces of code do it)
Clearly whatever we will for the fillDescriptions in tracking will require significant development investment (possibly having impact on HLT configuration), and then somebody need(s) to decide what to do and when to do it.
As for HLT and existsAs
, why not employing customizeHLTforCMSSW.py
?
+1
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_8_0_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @Degano, @smuzaffar |
+1 |
Implement a Seed Extension as a TrajectoryFilter that requires no missing (or even no Invalid) hits as long as the track have less then a given number of hits beyond the seed.
The main purpose is (yet another way) to implement "Quadruplet seeding" for PhaseI.
It can also be used to reduce fakes (and speedup processing) in many other situations,
notably HLT.
Its indiscriminate use at RunII (i.e. changing the default) speeds-up tracking of almost a factor 2 at high pileup with minor loss in efficiency.