Skip to content
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

Closed
silviodonato opened this issue Oct 12, 2022 · 17 comments · Fixed by #39834
Closed

Missing --hltprocess in reHLT workflows #39714

silviodonato opened this issue Oct 12, 2022 · 17 comments · Fixed by #39834

Comments

@silviodonato
Copy link
Contributor

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 
@cmsbuild
Copy link
Contributor

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

@makortel
Copy link
Contributor

assign pdmv

@cmsbuild
Copy link
Contributor

New categories assigned: pdmv

@bbilin,@sunilUIET,@kskovpen you have been requested to review this Pull request/Issue and eventually sign? Thanks

@kskovpen
Copy link
Contributor

@kskovpen
Copy link
Contributor

Adding @kjpena :)

@kskovpen
Copy link
Contributor

@missirol
Copy link
Contributor

@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

@kskovpen
Copy link
Contributor

@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

@missirol
Copy link
Contributor

Thanks for clarifying, @kskovpen .

@silviodonato
Copy link
Contributor Author

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

@makortel
Copy link
Contributor

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?

@silviodonato
Copy link
Contributor Author

I really don't know about these validation modules that need to re-ran the MixingModule

@missirol
Copy link
Contributor

Hi @kskovpen ,

regarding #39714 (comment), 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.

@missirol
Copy link
Contributor

@silviodonato , the fix is in place, but I'm not sure if TSG needs backports of this or not.

@silviodonato
Copy link
Contributor Author

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)

@mmusich
Copy link
Contributor

mmusich commented Oct 28, 2022

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 #39834. On the other hand this looks like a "bug" worth fixing at least down to 12.4.x (for private usage?)

@missirol
Copy link
Contributor

missirol commented Oct 28, 2022

I'll just open the backports and let people decide.

Edit: the backports are #39899 (12_5_X) and #39900 (12_4_X).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants