cms-sw
Missing --hltprocess in reHLT workflows
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 in Configuration/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
140.003 RunJetHT2022B+HLTRUN3+RECONANORUN3+HARVESTRUN3 [1]: input from: /JetHT/Run2022B-v1/RAW with run []
[2]: cmsDriver.py step2 --process reHLT -s L1REPACK:Full,HLT:@relval2022 --conditions auto:run3_hlt_relval --data --eventcontent FEVTDEBUGHLT --datatier FEVTDEBUGHLT --era Run3 -n 100
[3]: cmsDriver.py step3 --conditions auto:run3_data_relval -s RAW2DIGI,L1Reco,RECO,PAT,NANO:PhysicsTools/NanoAOD/V10/nano_cff,DQM:@miniAODDQM+@nanoAODDQM --datatier RECO,MINIAOD,DQMIO --eventcontent RECO,MINIAOD,DQM --data --process reRECO --scenario pp --era Run3 --customise Configuration/DataProcessing/RecoTLR.customisePostEra_Run3 -n 100
[4]: cmsDriver.py step4 -s HARVESTING:@miniAODDQM+@nanoAODDQM --conditions auto:run3_data --data --filetype DQM --scenario pp -n 100
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
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 https://cms-pdmv.cern.ch/stats/?prepid=CMSSW_12_5_0_pre5__fullsim_PU_2022_14TeV_gcc11-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).
@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 ?
@kskovpen
Just for my understanding, is [1] needed in any of the steps in [2] ? If so, why?
[1] --pileup Run3_Flat55To75_PoissonOOTPU --pileup_input das:/RelValMinBias_14TeV/CMSSW_12_5_0_pre5_ROOT626-125X_mcRun3_2022_realistic_v3-v1/GEN-SIM
[2] https://cms-pdmv.cern.ch/relval/api/relvals/get_cmsdriver/CMSSW_12_5_0_pre5_ROOT626__fullsim_PU_2022_14TeV-TTbar_14TeV-00002
@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 https://cms-pdmv.cern.ch/stats/?prepid=CMSSW_12_5_0_pre5__fullsim_PU_2022_14TeV_gcc11-TTbar_14TeV-00003
Hi @kskovpen , it seems good to me. The purpose of this issue was more about fixing the 140.1XX and 140.0XX workflows, which runs "Run.....2022....+HLTRUN3+RECONANORUN3" to include the option "--hltprocess reHLT" in "RECONANORUN3". But yes, it would be good to have similar reHLT workflows also for MC to be used in RelVals
Just for my understanding, is [1] needed in any of the steps in [2] ? If so, why?
[1]
--pileup Run3_Flat55To75_PoissonOOTPU --pileup_input das:/RelValMinBias_14TeV/CMSSW_12_5_0_pre5_ROOT626-125X_mcRun3_2022_realistic_v3-v1/GEN-SIM[2] https://cms-pdmv.cern.ch/relval/api/relvals/get_cmsdriver/CMSSW_12_5_0_pre5_ROOT626__fullsim_PU_2022_14TeV-TTbar_14TeV-00002
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 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 https://github.com/cms-sw/cmssw/issues/39714#issuecomment-1277609417, we should try to fix the wfs that should use --hltProcess reHLT but currently aren't. I made an attempt in #39834, but I'm not familiar with that part of CMSSW, so feel free to open a better PR.
@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. I don't know if @cms-sw/pdmv-l2 needs the backport (cc @kjpena)
I don't know if @cms-sw/pdmv-l2 needs the backport
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 https://github.com/cms-sw/cmssw/pull/39834. On the other hand this looks like a "bug" worth fixing at least down to 12.4.x (for private usage?)
I'll just open the backports and let people decide.
Edit: the backports are #39899 (12_5_X) and #39900 (12_4_X).