-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Remove 50ns-labeled dynamic inefficiency payload usage from SiPixelDigitizer #34502
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-34502/23982
|
A new Pull Request was created by @carolinecollard for master. It involves the following packages:
@cmsbuild, @civanch, @mdhildreth can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild , please test |
@carolinecollard can the title be a little bit more explicative? |
This PR also resolves #33616. Does this mean that the empty-labeled dynamic inefficiency payload in the GT corresponding the |
Yes, they are different and yes we should indeed do that. |
assign trk-dpg |
hold the change in the GT requested at #34502 (comment) should come first in order not to change the simulation behavior. |
Pull request has been put on hold by @mmusich |
I came across with this comment in matrix workflow definitions cmssw/Configuration/PyReleaseValidation/python/relval_pileup.py Lines 11 to 17 in 01d487d
|
I looked into workflow 200, and indeed the |
I checked 25.0 and gave me 450ns |
So presumably there is potential danger towards supporting 7 TeV MC with 450 ns bunchspacing and 8 TeV with 50 ns. Maybe this approach originates from those times, trying to support both with one GT? |
Just to add that we didnt simulate the inefficiencies in the 7 TeV MC with 450 ns bunchspacing. That tag |
@mmusich Hi Marco, I did the rebase with the help of Tamas and following the web page with instructions you pointed to me --> Now I am in CMSSW_12_0_X_2021-07-20-2300. During the rebase step, I still got conflicts for 3 keys : phase1_2021_realistic, phase1_2023_realistic, phase1_2024_realistic. Tamas was using the V4 while the original code uses the V3 for autoCond.py. Tamas recommended that I uses the V4. This what I did to resolve the conflicts. So I hope this will not introduce new conflicts here... |
test parameters:
|
@cmsbuild , please test |
@@ -2,29 +2,27 @@ | |||
|
|||
### NEW KEYS ### | |||
# GlobalTag for MC production with perfectly aligned and calibrated detector for Run1 | |||
'run1_design' : '113X_mcRun1_design_v3', | |||
'run1_design' : '120X_mcRun1_design_v1', |
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.
These changes in autoCOnd GTs must be blessed by @cms-sw/alca-l2
I suspect that going back to older versions is outside the scope of this PR, and should be reverted
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.
AlCa is giving the blessing :) 120X_mcRun1_design_v1
is a newer version than 113X_mcRun1_design_v3
, please note the CMSSW version numbering in the beginning of the string. As explained in the PR description, the differences between the GTs can be found in the attached google sheet. Specifically this one is row 5, https://cms-conddb.cern.ch/cmsDbBrowser/diff/Prod/gts/113X_mcRun1_design_v3/120X_mcRun1_design_v1
as you can see the difference is only between the desired tags.
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-215eb5/17067/summary.html Comparison SummaryThe workflows 140.53 have different files in step1_dasquery.log than the ones found in the baseline. You may want to check and retrigger the tests if necessary. You can check it in the "files" directory in the results of the comparisons @slava77 comparisons for the following workflows were not done due to missing matrix map:
Summary:
|
+alca
|
unassign trk-dpg |
+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. @silviodonato, @dpiparo, @qliphy, @perrotta (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
First part of the PR :
Removal of the code lines related to the 50ns labeled dynamic inefficiency for Pixels, in view of removing the payload
SiPixelDynamicInefficiencyRcd | 50ns | SiPixelDynamicInefficiency_13TeV_50ns_v2_mc
from the Global Tag, as discussed during the Pixel Offline Meeting of July 14 (https://indico.cern.ch/event/1000813/#11-removal-of-50ns-labeled-dyn).
I have made some checks in the SiPixelDigitizerAlgorithm::PixelEfficiencies::init_from_db function,
and verified that the code before and after my modifications delivers exactly the same SiPixelDynamicInefficiency information.
Second part of the PR (Global Tag changes):
In case when the simulations require 50 ns bunch spacing the previously labeled (50 ns specific) payload is used. Code changes and validation can be found in the PR34502 [2]. The differences of the new and old GTs can be found in [3].
This PR contains the removal of the unused key run1_mc_pa as well.
[1] https://hypernews.cern.ch/HyperNews/CMS/get/calibrations/4431.html
[2] #34502
[3] https://docs.google.com/spreadsheets/d/1FlABJmzWOrxKaNSUD_N980GQeO9ecYj4C8xXcl4IMNE/edit?usp=sharing
PR validation:
runTheMatrix.py -l limited,140.0,200.0,202.0,203.0,204.0,205.0,4001.0,4006.0,4007.0,4008.0,11634.0,12434.0,12834.0,1325.516,50200.0,7.22,145.0,281.0,10424.0,7.21,11224.0,250200.182,11024.2,7.4,12034.0,7.23,159.0,12834.0,7.24 --ibeos -j8
Private validation under
https://indico.cern.ch/event/1000813/contributions/4447059/attachments/2281939/3880637/20210714_PixelMeeting_DynEffCheck.pdf
plus wf25.0 and wf9.0 were tested
https://tvami.web.cern.ch/tvami/projects/PixelOffline/DynEffValidation/wf25/?match=ffic
https://tvami.web.cern.ch/tvami/projects/PixelOffline/DynEffValidation/wf9/?match=ffic
and show no significant changes.