Adjust seeding region rebuilding parameters for phase1 initialStep

[makortel]

This PR reduces the high-eta duplicates as the seeding region is rebuilt more aggressively. Inspired by the phase2 configuration.

Here are MTV plots for phase1 default tracking in 9_0_0_pre4+#17537+#17511
https://mkortela.web.cern.ch/mkortela/tracking/validation/CMSSW_9_0_0_pre4_phase1SeedRegionRebuild/

Tested in 9_0_0_pre4, expecting changes indicated above in phase1 workflows. No changes are expected in phase0/2.

@rovere @VinInn @felicepantaleo @ebrondol

[makortel]

@cmsbuild, please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/17835/console Started: 2017/02/17 10:30

[cmsbuild]

A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_9_0_X.

It involves the following packages:

RecoTracker/IterativeTracking

@cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please review it and eventually sign? Thanks.
@ghellwig, @felicepantaleo, @GiacomoSguazzoni, @rovere, @VinInn, @mschrode, @gpetruc, @dgulhan this is something you requested to watch as well.
@davidlange6, @smuzaffar you are the release manager for this.

cms-bot commands are listed here #13028

[cmsbuild]

+1
Tested at: e6685f6
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-17544/17835/summary.html

[cmsbuild]

Comparison job queued.

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-17544/17835/summary.html

[makortel]

Regarding the visible efficiency drop in highPurity
https://mkortela.web.cern.ch/mkortela/tracking/validation/CMSSW_9_0_0_pre4_phase1SeedRegionRebuild/phase1_ttbar_pu35_highPurity/effandfakePtEtaPhi.pdf
the efficiency of generalTracks stays the same
https://mkortela.web.cern.ch/mkortela/tracking/validation/CMSSW_9_0_0_pre4_phase1SeedRegionRebuild/phase1_ttbar_pu35_ootb/effandfakePtEtaPhi.pdf
so the decrease is an effect of the HP track selection. Therefore we plan to re-train the MVA (at least for initialStep, for 91X).

Wrt. 900pre4 (i.e. the combined effect of #17537+#17511+this PR) the HP efficiency mostly improves
https://mkortela.web.cern.ch/mkortela/tracking/validation/CMSSW_9_0_0_pre4_phase1SeedRegionRebuild2/phase1_ttbar_pu35_highPurity/effandfakePtEtaPhi.pdf

[slava77]

In ttbar PU35 (wf 10224) with CMSSW_9_0_X_2017-02-16-1100 as a baseline

generalTracks count is down by ~0.15%
the shorter (nhits~<12) tracks are longer

pf charged hadron yield is up by ~0.15% with most noticeable increase in |eta|>2.5

So, incrementally, this is an improvement, although it apparently goes worse on top of the updated MVAs mentioned earlier https://mkortela.web.cern.ch/mkortela/tracking/validation/CMSSW_9_0_0_pre4_phase1SeedRegionRebuild/phase1_ttbar_pu35_highPurity/effandfakePtEtaPhi.pdf (although there may be it's a matter of choosing a different baseline)

Combined with the already MVA PR, there is still fairly significant increment in yields at high eta on top of the baseline

and indeed, there is a moderate decrease in high-eta yields incrementally on top of the MVA PR ( #17537)

The last plot has efficiency loss much smaller than in positive eta (and somewhat comparable to the negative eta) of
https://mkortela.web.cern.ch/mkortela/tracking/validation/CMSSW_9_0_0_pre4_phase1SeedRegionRebuild/phase1_ttbar_pu35_highPurity/effandfakePtEtaPhi.pdf

@makortel I didn't include #17511 in this incremental comparison .. is there additional destructive interference in positive eta with the MVA selection from it (#17511) and this PR?

I suppose, the arguments for having this PR included now is that it should be considered in a combination of the features that went in for tracking since pre4.
By itself it's rather questionable, driven by the HP efficiency loss (since HP defines what goes to PF).

[makortel]

@slava77 #17511 should be rather independent of MVA selection, as the duplicate merging is done after all iterations. This PR, on the other hand, "interferes" with the updated MVA such that the MVA needs to be retrained.

[slava77]

On 2/21/17 7:57 AM, Matti Kortelainen wrote: @slava77 <https://github.com/slava77> #17511 <#17511> should be rather independent of MVA selection, as the duplicate merging is done after all iterations. This PR, on the other hand, "interferes" with the updated MVA such that the MVA needs to be retrained.

OK. Do you happen to know what's happening on the positive eta side?

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17544 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEdcbjdi6KlQFSOVv-jDYH0g2hn-TParks5rewlZgaJpZM4MEDFk>.

[slava77]

+1

for #17544 e6685f6

• changes in initialStepTrajectoryBuilder in order to reduce high eta duplicates, as described; comes with some destructive interference incrementally on top of Retrained track selection MVA for phase1 #17537, but still is an improvement in combination with Retrained track selection MVA for phase1 #17537 (already merged).
• jenkins tests pass and comparisons with baseline show differences only in phase-1 workflows with small changes starting from tracks and propagating downstream
• local tests with extended statistics confirm observations in the supplied MTV tracking plots; the changes in tracks passing high-purity show up as slight changes in the pf charged hadrons most noticeable in |eta|>2.5 on top of the Retrained track selection MVA for phase1 #17537; further downstream performance appears to be essentially not affected. Signing off in view of getting rid of a significant fraction of short tracks and a combined performance improvement with the already merged Retrained track selection MVA for phase1 #17537 .
  • timing performance in 10224 appears to be somewhat unchanged, there maybe around 1% improvement, but since there is no clear localization across heavy modules, this is not significant.

[cmsbuild]

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. @davidlange6, @smuzaffar

[davidlange6]

+1