-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Tune Pixel Cluster Shape Filter to mitigate BPIX1 inefficiency #20269
Conversation
The code-checks are being triggered in jenkins. |
A new Pull Request was created by @VinInn (Vincenzo Innocente) for master. It involves the following packages: HLTrigger/Configuration @perrotta, @cmsbuild, @silviodonato, @slava77, @Martin-Grunewald, @fwyzard can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
MTV ttbar pu35 1000 events: please note: as shown in next posts MonteCarlo does not reproduce data. |
+code-checks |
Comparison Data MC:
open
here DATA is SingleMuon run 300631 LS 205. |
Conclusion by TRK-POG: |
The code-checks are being triggered in jenkins. |
Pull request #20269 was updated. @perrotta, @cmsbuild, @silviodonato, @slava77, @Martin-Grunewald, @fwyzard can you please check and sign again. |
@cmsbuild , please test |
The tests are being triggered in jenkins. |
Comparison is ready Comparison Summary:
|
On 8/25/17 2:43 AM, Vincenzo Innocente wrote:
Conclusion: we have just relaxed the filter for BPIX1 and things seems
reasonable, still we cannot exclude that most of the recovered tracks
are of low-quality (fakes)
As a quick check for this I usually check the KShort mass plot.
(although it's perhaps more appropriate for more outer iterations)
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20269 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbvTPXeGCmRJsMAXXZInITyo-yG_cks5sbpdMgaJpZM4PCR1c>.
|
yes K0, I was thinking to post them here MC for current Pr and finally here data and MC normalized (mc reference and current PR as red and purple) |
+1 |
more info timing: reference
this PR
|
vs
is this real or just a single event variation? |
non single event as Max event is larger and the total difference in timing is larger than MaxEvent... |
If the per-event-per-module times are available, it should be possible [and I keep forgetting that my emails do not make it to the github threads anymore .. and github support did not respond since yesterday] |
this is for the full file 4LS ~4K events reference
this PR
|
and This is for the first 20 events reference
this PR
|
To be clear "the goal of this PR is NOT to mitigate the timing tails of jetcore". It is a side effect that can give clues where to further act on jet core. |
I was looking around at the comparisons in data (as provided in #20269 (comment)) [an input to the DQM developments] |
Timing and disk occupancy, evaluated with the same reference MC wf 10224 (high PU TTbar) are quite reasonable.
Job total: 6.83452 s/ev ==> 6.85637 s/ev
2341434 -> 2343583 2149 0.1 ALL BRANCHES |
+1
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
This PR introduced
threetwo changes:3) For Quadruplets apply filter to hits 2,3,4 instead of 1,2,3For performances please look to next posts