-
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
Missing --hltprocess in reHLT workflows #39714
Comments
A new Issue was created by @silviodonato Silvio Donato. @Dr15Jones, @perrotta, @dpiparo, @rappoccio, @makortel, @smuzaffar can you please review it and eventually sign/assign? Thanks. cms-bot commands are listed here |
assign pdmv |
New categories assigned: pdmv @bbilin,@sunilUIET,@kskovpen you have been requested to review this Pull request/Issue and eventually sign? Thanks |
We have submitted the reHLT wfs to complete the ROOT626 and gcc11 campaigns (https://cms-talk.web.cern.ch/t/new-validation-campaign-12-5-0-pre5-2022-root626-added/15016/32) from the HLT side: https://cms-pdmv.cern.ch/stats/?prepid=CMSSW_12_5_0_pre5_ROOT626__fullsim_PU_2022_14TeV-TTbar_14TeV-00002 The outputs of these workflows should be compared to: /RelValTTbar_14TeV/CMSSW_12_5_0_pre5-PU_125X_mcRun3_2022_realistic_v3-v1/DQMIO Please let us know about the outcome of this validation (when ready). |
Adding @kjpena :) |
@silviodonato could you please confirm if the configuration is fine here: https://cms-pdmv.cern.ch/relval/api/relvals/get_cmsdriver/CMSSW_12_5_0_pre5_ROOT626__fullsim_PU_2022_14TeV-TTbar_14TeV-00002 ? |
Just for my understanding, is [1] needed in any of the steps in [2] ? If so, why? [1] |
@missirol thanks, it should have no effect, because no digitalization is triggered. In any case, thanks for noticing that, it is pointless to have it being specified here in the first place. In order to avoid any further confusion, we've resubmitted these wfs: https://cms-pdmv.cern.ch/stats/?prepid=CMSSW_12_5_0_pre5_ROOT626__fullsim_PU_2022_14TeV-TTbar_14TeV-00003 |
Thanks for clarifying, @kskovpen . |
Hi @kskovpen , it seems good to me. |
In the past the RECO+...+VALIDATION step (step3 in [2] above) re-ran the MixingModule in a playback mode in order to re-create CrossingFrame objects that were used by some of the validation modules. Has this changed or somehow not needed for the reHLT workflows? |
I really don't know about these validation modules that need to re-ran the MixingModule |
Hi @kskovpen , regarding #39714 (comment), we should try to fix the wfs that should use |
@silviodonato , the fix is in place, but I'm not sure if TSG needs backports of this or not. |
Thanks Marino, from the TSG point of view the backport is not necessary as the "alca relvals" are already running with re-HLT. |
This was mostly driven by the need to be able to compare fairly target and reference in the tracking @ HLT technical validations (ROOT6, gcc11, etc.) in the master cycle, so the main use case is addressed with #39834. On the other hand this looks like a "bug" worth fixing at least down to 12.4.x (for private usage?) |
Dear @cms-sw/pdmv-l2,
I've just realized that the reHLT workflows (eg.
140.003 RunJetHT2022B+HLTRUN3+RECONANORUN3+HARVESTRUN3
), the RECO...DQM step does not include the--hltprocess reHLT
option, to run the HLT DQM from the reHLT instead of the original HLT.(@cms-sw/dqm-l2 do you confirm this?).
This seems a problem similar to what we had with the ALCA relvals some weeks ago (link )
It seems that we should add a
RECONANORUN3_reHLT
version inConfiguration/PyReleaseValidation/python/relval_steps.py
and use them in the matrix.This problem was spotted in the contest of https://its.cern.ch/jira/browse/CMSHLT-2503 (@kjpena )
cc @cms-sw/hlt-l2
The text was updated successfully, but these errors were encountered: