Second tuning of Pixel cluster shape cut for Phase 2

[ebrondol]

After the PR #16943 where the parameters of SiPixel local reco have been changed to match the specs of the phase2 read-out chip, a second tuning of the pixel cluster shape cut for Phase 2 has been done.
Few changes in performance - but nothing drastic - are expected.

informing @delaere @atricomi @boudoul

[cmsbuild]

A new Pull Request was created by @ebrondol for CMSSW_9_0_X.

It involves the following packages:

RecoPixelVertexing/PixelLowPtUtilities

@cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please review it and eventually sign? Thanks.
@makortel, @felicepantaleo, @GiacomoSguazzoni, @rovere, @VinInn, @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

[ebrondol]

@slava77 since this PR is going to change some performance, while the PR I submit yesterday (#17106) is just updating the documentation, I would prefer to keep them separate. Let me know if you have any problem with that..

[slava77]

@cmsbuild please test

@ebrondol
no problem with having two separate PRs, they are covering different features

Have you run some tests with PU200 to see that timing stays under control?

Do you have any visual representation of the changes in the cluster shape at the lower level (e.g. cut value vs cluster size or something natural wrt definition of the cut)?

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/17176/console Started: 2017/01/04 15:26

[ebrondol]

Hi @slava77 , for the first question, I did not run at high PU but I think it should be pretty stable the timing performance respect to before.
I do not have any visual representation at the cluster level. Maybe @emiglior can comment on that?

[cmsbuild]

+1
Tested at: 5c1751c
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-17110/17176/summary.html

[cmsbuild]

Comparison job queued.

[cmsbuild]

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

[slava77]

@ebrondol
please clarify from which workflow are your plots in the PR description

[slava77]

I observe virtually no differences after running in CMSSW_9_0_0_pre2

• 500 events 10 mu E 0 to 200 without PU (20011.0,22811.0,23611.0 or D7, D4Timing and D9)
• 100 events ttbar with PU200 D4Timing (wf 23034)

The efficiency plot from 22811 "/DQMData/Run 1/Tracking/Run summary/Track/generalPt09_trackingParticleRecoAsssociation/effic" with this PR shows a plot similar to what was posted in the PR description in red

Is something missing in this PR (is the .par file change all that's needed) ?

[ebrondol]

Hi @slava77 , yes, the file .par is the only change needed in principle. I have used 1k events coming from RelValSingleMuPt10Extended with 0PU (wf 21218).

[slava77]

On 1/9/17 2:42 AM, ebrondol wrote: Hi @slava77 <https://github.com/slava77> , yes, the file .par is the only change needed in principle. I have used 1k events coming from RelValSingleMuPt10Extended with 0PU (wf 21218).

In this case, I should see the changes in the tenmu samples, but I don't. I will check on the same sample, just to be sure. Which release did you use? It might be worth to double-check that the correct file was pushed to the PR.

…

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

[ebrondol]

Hi @slava77 , I am also double checking in CMSSW_9_0_X_2017-01-08-2300 with the WF #21218.0. I will post the results before the end of the day.

[ebrondol]

With the same statistic, I see what you also reported: http://ebrondol.web.cern.ch/ebrondol/Phase2Tracking/PR17110/SingleMuPt10Extended/plots_ootb/effandfake1.pdf
no difference between with or without the PR. This is very strange..

[slava77]

@ebrondol
did you happen to gain some better understanding of the issue in this PR of the lack of changes in more recent tests compared to the tests done before the PR submission?

Since you were able to reproduce the lack of changes, maybe it is still possible to go back to the setup that had desired changes and compare/debug.

[ebrondol]

@slava77 After some test, I think that the lost of efficiency is due to another problem and cannot be solved with this re-tuning. Said so, probably would be good to put this PR in release to keep consistency between the geometry/digitization and the tuning (with no changes on the performance).

[slava77]

On 1/13/17 1:24 AM, ebrondol wrote: @slava77 <https://github.com/slava77> After some test, I think that the lost of efficiency is due to another problem and cannot be solved with this re-tuning. Said so, probably would be good to put this PR in release to keep consistency between the geometry/digitization and the tuning (with no changes on the performance).

OK. Please update the PR description to match the expected little impact on performance (it now has the plots suggesting significant improvements in efficiency)

…

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

[slava77]

+1

for #17110 5c1751c

• pixelShape_Phase2Tk.par update for consistency with the new tracker response parameters
• jenkins tests pass and comparisons show only small changes
• local tests on larger samples confirm that changes are small as noted earlier in the thread

[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