-
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
HCAL 2017 Phase1 Workflows #15889
HCAL 2017 Phase1 Workflows #15889
Changes from 1 commit
a4e6c05
bf5f1f2
4eb39a0
0afa935
bfe444b
ff46989
61abaf5
e3418e2
909daed
1046942
256242e
8393d1a
68b20fd
7fadf6c
b1543bb
a14deaa
833fe0e
21e6fec
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -57,7 +57,7 @@ | |
upgradeProperties[2017] = { | ||
'2017' : { | ||
'Geom' : 'Extended2017dev', | ||
'GT' : 'auto:phase1_2017_realistic', | ||
'GT' : 'auto:phase1_2017_hcaldev', | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I presume this will switch pixel geometry (well, everything) to be read from XML. In which pre-release is this PR planned to be integrated? (pre12, pre13; or will the geometry be included in a GT before the pre-release?) I'm wondering a possible interference with #15883 and #15805 (or actually with their validation). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, this sounds like it could cause great chaos if it gets into pre12. And for pre13/the release, I have the feeling that nothing called 'dev' should be in the then-production workflows. It seems to me that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note that #15674 changed There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The 2017dev geometry itself does not need validation, but it can only be used (for DIGI-RECO) with an appropriate global tag having HCAL conditions for all the new channels. As we just got one, it could not have been used in the workflow until now. @ianna doesn't have the latest version of it in the database yet, so I assigned the xml version for now. This shouldn't "interfere" with the new pixel geometry PRs, as those are creating a separate workflow for validation. @davidlange6 requested that I not make yet another separate workflow for HCAL 2017. At some point, all of these geometry changes need to be reconciled into one final 2017 geometry, but I think that should be done after or otherwise outside of this PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had the impression that the goal of pre13 was to "merge" the "2017_NewFPix" workflow introduced in #15805 back to the "2017" workflow. Personally I don't have a problem in keeping it around if needed for other reasons, just all cleanup needs to be done in there (although maybe not much can be done before the "2017" and "2017_NewFPix" get really merged?). For my education, are the additions in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is not strictly correct, the new WFs exist to evaluate the new FPIX individually. There are aso BPIX changes that need validation in the normal 2017 geometry. However, these are not as drastic as the FPIX changes and might be fine to coexist with the HCAL changes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It is not just the BPix changes we need to validate with pre12, but also all non-geometry changes between pre11 and pre12 (e.g. turning off VPF30 mitigation), and that is best done with exactly the same geometry as in pre11. Now, trying to be practical (probably along what @slava77 already wrote), as these two parameters are passed to cmsDriver they can be changed at the time of RelVal submission (to be coordinated with PdmV; by the way, if this PR goes in pre12, do you want RelVals with the So my only concern is the effect of the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nominally, undoing a change implemented with an era, should be another era, If I understand correctly, changes made by HCAL eras in this PR will not work on the old 2016 HCAL geometry. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @slava77 - yes, HCal and CaloTower reco geometries produced from a 2017dev scenario differ from the ones produced from a 2017 scenario. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @makortel the changes from the new HCAL geometry, tag, and customizations definitely are not statistically insignificant. You cannot use the new HCAL tag with pre11 GEN-SIM. I first suggested making a separate testing workflow and Era for the HCAL changes, but @davidlange6 did not want me to do this. At this point, he should comment if he would accept this PR with such a (temporary) new workflow and Era before I make those changes. |
||
'Era' : 'Run2_2017', | ||
'ScenToRun' : ['GenSimFull','DigiFull','RecoFull','HARVESTFull'], | ||
}, | ||
|
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.
@kpedro88 - no need to change it from DB:Extended if taken with #15924
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.
I'll change it back when #15924 is merged