-
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
Migrate customiseForRunI to era (81X) #13988
Migrate customiseForRunI to era (81X) #13988
Conversation
A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_8_1_X. It involves the following packages: Configuration/StandardSequences @cvuosalo, @cmsbuild, @franzoni, @deguio, @slava77, @vanbesien, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are list here #13028 |
@cmsbuild please test |
The tests are being triggered in jenkins. |
Ping (the 80X version has been merged already). |
_globalreco_tracking_Phase1PU70 = globalreco_tracking.copy() | ||
_globalreco_tracking_Phase1PU70.replace(trackingGlobalReco, recopixelvertexing+trackingGlobalReco) | ||
eras.trackingPhase1PU70.toReplaceWith(globalreco_tracking, _globalreco_tracking_Phase1PU70) | ||
_globalreco_tracking_LowPU_Phase1PU70 = globalreco_tracking.copy() |
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 see that you merged the names.
I'd rather have a copy-pasted _globalreco_tracking_LowPU
and _globalreco_tracking_Phase1PU70
I guess, this assumes that trackingPhase1PU70 will forever remain the SLHC almost-run1-like scenario used in TP, right?
[I was hoping it will go away at some point.]
Imagine we need to define a more proper Phase1 for PU70 in a couple of years. These merged-name LowPU_Phase1PU70 will have to be split up.
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.
@slava77 No, I still intend to clean up the trackingPhase1PU70 after the trackingPhase1 is frozen for next year. Here (and in few other places) I just wanted to avoid copy-paste. I can split them or just rename them to _LowPU
if you want (to me it's the same if I do it now or when cleaning up trackingPhase1PU70).
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.
It's OK to stay if you are planning to update or refactor this later
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.
@slava77 OK. Would it be fine to leave the update to the point where trackingPhase1PU70 is cleaned up, or would you like to see it addressed sooner?
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.
@makortel
it's OK to leave until trackingPhase1PU70 is cleaned up
+1
|
@deguio |
Pull request #13988 was updated. @cvuosalo, @cmsbuild, @franzoni, @deguio, @slava77, @vanbesien, @davidlange6 can you please check and sign again. |
@cmsbuild please test |
The tests are being triggered in jenkins. |
Comparison is ready There are some workflows for which there are errors in the baseline: |
@deguio |
+1 |
On 4/27/16 10:11 AM, Matti Kortelainen wrote:
I think these can be removed in 81X.
|
This PR is a partial forward-port of #13945, that is, migrating
RecoTracker/Configuration/customiseForRunI.customiseForRunI
toRun2_2016_trackingLowPU
era (I'll leave the DataProcessing part for @slava77 to do). I should also note that the "erafication" is not fully equivalent to the customize:Compared to #13945, the new configuration code is a bit tidied up, and the tracking validation is also included (was much easier to do here than in 80X thanks to the earlier phase1 era work).
Tested in 8_1_0_pre2 (rebased on top of CMSSW_8_1_X_2016-04-19-2300), no changes expected in standard workflows.
@rovere @VinInn