Add combined premixing stage1+stage2 workflows for 2016-18 #22956
Conversation
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-22956/4342 |
|
@cmsbuild, please test workflow 250202.1,250202.171,250202.181,250206.181 |
|
The tests are being triggered in jenkins. |
|
A new Pull Request was created by @makortel (Matti Kortelainen) for master. It involves the following packages: Configuration/PyReleaseValidation @GurpreetSinghChahal, @cmsbuild, @prebello, @kpedro88, @fabozzi can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
Comparison job queued. |
|
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
|
+1 |
I agree, and wrote a bit more generic issue #22998. |
|
Hi @makortel , please I would like few clarifications.
Thank you |
No, the workflows are added for 2016, 2017, and 2018. The current separate workflows test the premixing procedure as in production (pileup library (stage1) and overlaying pileup with signal (stage2) separately). While this is a necessary test, it is not optimal for testing changes affecting stage1 (either accidentally or on purpose), as those would be seen only after next pre-release with the new pileup library. Combined workflow exercising both stage1 and stage2 tests the whole chain in one go, and is in my opinion the best way to resolve #22586. (obviously there is no need to run these workflows beyond PR tests and IBs, so RelVal procedure can continue as they are) For phase2 there is no stage2 implementation yet (it's coming but I need bunch of pre-requisite PRs to be merged first). A combined stage1+stage2 workflow for phase2 will be included as well (actually being the only way to test the whole chain until the first pileup library, and even then stage1 may be a bit "unstable" for some time).
No. At the time of submitting this PR I thought the fixes needed for CSC, DT, and RPC digi validation would have required breaking stage2-only workflows or disabling these modules in these workflows (see discussion #22957), but that turned out to be a misunderstanding from my part (see the actual fix in #22977). In case the stage2-only workflows would have been affected a combined stage1+stage2 workflow for ZMM would have been useful to produce histograms for these validation modules from events with muons. Since that didn't happen there is little motivation for the ZMM workflow (since ttbar has also muons, even if less). I can drop it if people prefer that (one workflow less to be run in IBs). |
|
+1 |
cmsbuild
added
fully-signed
pdmv-approved
and removed
pdmv-pending
pending-signatures
labels
|
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, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
| # though) also for "-i all" because in that case the --filein for DAS | ||
| # input is after this one in the list of command line arguments to | ||
| # cmsDriver, and gets then used in practice. | ||
| digiPremixLocalPileup = { |
There was a problem hiding this comment.
is this going to work in a relval setup?
There was a problem hiding this comment.
I assume you mean that this works for the single workflow but not necessarily when injecting the production of the overall sample. I think this is a question for PdmV, how is this managed there?
There was a problem hiding this comment.
@davidlange6
I do not think these kinds of premix workflows can run as a relval, because in a taskchain all the output datasets from the workflow steps are being produced at the same time (and not one after the other). So the mixing step will search for an input PU dataset that is still in production. In addition to this, I am not sure if it is possible to specify in WMAgent an input PU taken from a previous step of the workflow.
But I think these workflows are only needed for testing a PR or to run in IB, right?
There was a problem hiding this comment.
But I think these workflows are only needed for testing a PR or to run in IB, right?
That (PR+IB) is indeed my intention. I'd think the current separate stages approach works indeed better for RelVal (and production).
There was a problem hiding this comment.
Ok, let's take this anyway in mind
|
+1 |
This PR suggests an implementation for combined premixing stage1+stage2 workflows for 2016, 2017, and 2018, following discussions after my O&C week presentation on phase2 premixing
https://indico.cern.ch/event/711343/#54-phase-2-premixing-status
The combined workflow allows testing changes affecting stage1 such that the changes propagate to the DQM histograms of stage2.
The workflows are added for ttbar as a representative sample, and also for ZMM for 2018 to possibly help with the muon premixing debugging.
A speciality of these workflows is that first two steps (signal GEN-SIM and premix stage1) do not take any input, and the third step (premix stage2) takes the the input of the first two steps via
--fileinand--pileup_input(respectively). I did not find a clear way to achieve that (without spending lots of time understanding the details of the workflow generation), so I added a special treatment for premixing stage1 toWorkFlowRunner.Tested in CMSSW_10_2_X_2018-04-12-2300, no changes expected in existing workflows.
@kpedro88 @mdhildreth