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
Fast match #2581
Fast match #2581
Conversation
Hi Vincenzo, |
Since the performance changes on the physics side, I think that we need this vetted by the tracking POG. I'd expect that PU40@25ns at 13 TeV, our baseline for post-LS1 should be included in the tests for |
202.0_TTbar+TTbarINPUT+DIGIPU1+RECOPU1+HARVEST Prefilter off there is no regression even with your validate.C Tracking POG is fully informed and we decided for this route. NO regression, at all with the committed code. I have PU40 TTbar . I have to run them again starting from step2... |
A new Pull Request was created by @VinInn (Vincenzo Innocente) for CMSSW_7_1_X. Fast match It involves the following packages: RecoLocalTracker/SiStripRecHitConverter @nclopezo, @cmsbuild, @anton-a, @thspeer, @slava77, @Degano can you please review it and eventually sign? Thanks. |
On 21 Feb, 2014, at 3:36 PM, slava77 notifications@github.com wrote:
v. |
OK, if it's just adding the ability to cut, but not cut, this PR itself can get in quicker ;) @ktf Giulio, the bot was pretty sluggish here, it took it almost an hour to notice this PR |
Sorry, what is holding progress toward approval here? |
@VinInn, this new parameter would seem to break hlt configurations, no? (not all of them I guess) |
is untracked. I know HLT likes to have all parameters specified, but will not break the config. @mtosi can comment and eventually act Is untracked exactly not to break configs. |
its untracked, but the code is requiring it to be in the pset, no? On Feb 25, 2014, at 12:12 PM, Vincenzo Innocente notifications@github.com
|
really?
has always been "if missing is false" unmodified HLT config |
Ha. Missed the default argument. Sorry On Feb 25, 2014, at 12:32 PM, "Vincenzo Innocente" <notifications@github.commailto:notifications@github.com> wrote: really? preFilter_(conf.getUntrackedParameter("PreFilter",false)) has always been "if missing is false" unmodified HLT config — |
But since a change in the parameter changes the physics result, albeit slightly, the parameter is required to be tracked. |
as I commented above this to ease testing.
I was asked to allow more people to test this feature to investigate the difference w.r.t. the full combinatorics and the use of a config param seemed to be the easiest solution. |
For the tracked vs untracked: please change to tracked and use fillDescriptions or existsAs to provide a default value. |
existsAs should solve the problem without affected anybody, no?.. (long ago we've given up the idea of forcing tracked parameters to be in all configs) On Feb 25, 2014, at 4:26 PM, Vincenzo Innocente notifications@github.com
|
On 25 Feb, 2014, at 4:33 PM, davidlange6 notifications@github.com wrote:
I will try with existsAs: I have examples… |
wrong default, sorry! |
done. sorry for the time waisted on this point: I was still under the impression that we were forcing tracked parameters to be in all configs. |
Tracked doesn't have to be in the config, this is important for the provenance tracking. |
Yes, we are fine with this changes! On Feb 27, 2014, at 4:42 PM, slava77 notifications@github.com wrote:
|
@slava77 |
RecoLocalTracker -- Fast match
fixes py2-h5py dependencies
these modification enable the possibility to study a "faster" version of the hit matcher
that preselects the hits to match based on the track parameters
The selection is controlled by a parameter of the Matcher "PreFilter"
default is false.
to set to true just
the speed up obtained depends on occupancy and track density in each det-unit.
At high pileup it is expected to be significant.
for a typical JetHT sample from 2012C one saves about 25% of the time in the matcher itself
corresponding to about a 6% speed up of the total CkfTrackCandidateMakerBase.
the cost is a small inefficiency caused by a loss of about 10% of the hits on the track, as it can be seen in
the standard MTV plots for TTBar
http://innocent.home.cern.ch/innocent/FastMatchMTV/
this loss in not present al all in single particle events and seems to be constant with the increase of the pileup
The use of this optimization shall be therefore reviewed in light of the final configuration for Run 2
including cluster-charge cuts and new setup for the iterative-tracking
I have of course verified that the modifications with default configuration do not produce any regression