Introduce changes in order to switch from LumiScalers to MetaData #27677
Conversation
…lineLuminosityRecord when the last are avilable
|
The code-checks are being triggered in jenkins. |
|
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-27677/11263
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
| } | ||
| else{ | ||
| edm::Handle<LumiScalersCollection> lumiScalers; | ||
| iEvent.getByToken(lumiScalersSrc_, lumiScalers); |
There was a problem hiding this comment.
If the needed product is known at configuration time (as #27676 hints), it would be better to directly configure the modules to consume only the needed product.
There was a problem hiding this comment.
In this case yes.
Given that this pattern is copy-pasted in this PR 4 times, a possible option would be to create an additional producer that extracts the lumi value from LumiScalersCollection/OnlineLuminosityRecord after which there would be one point for the customization, and all the clients could then just read the float from the event.
There was a problem hiding this comment.
yes, that's a good suggestion. We didn't want to make era-based customizations because the list of modules needing to be treated is long (this is just the tip of the iceberg), but if there is a single event product that can be consumed for everybody that's more economical indeed.
There was a problem hiding this comment.
@arossi83, @makortel
@mtosi (if I understood correctly) is suggesting to make use of this class: https://github.com/cms-sw/cmssw/blob/master/DQM/TrackingMonitor/src/GetLumi.cc and change the code only there (subsequently use this interface everywhere else in the client code).
This would avoid writing an additional EDProducer, would this be acceptable?
There was a problem hiding this comment.
The class is certainly an improvement wrt. copy-paste. The input product customization (if that route is chosen) would still have to be repeated for each client, right?
|
@fabiocos I'm closing this PR, a completely new approach is needed. |
PR description:
With the changes proposed here the TkDQM module which make use of SCAL information about luminosity will, by default, first check the availability of MetaData and only if this are not available use SCAL info. This changes will work only together with PR #27676 which introduce a customization of the RawToDigi sequence via era modifier.
PR validation:
To test it a manual merge of PR #27676 is needed otherwise the code will use luminosity info from metadata also for run where metadata are not available (OnlineLuminosityRecord filled with all 0).
Manually tested on a run from 2017(no softFED1022) and one from 2018(with softFED1022).
2017
cmsDriver.py step1 -s RAW2DIGI,L1Reco,RECO,DQM -n 100 --eventcontent DQM --datatier DQMIO --conditions 110X_dataRun2_v1 --filein /store/data/Run2018D/ZeroBias/RAW/v1/000/323/997/00000/DDE05469-39F3-0647-BC31-AA8247C0B6C1.root --data --no_exec --python_filename=runFirst2017.py --era Run2_2017
cmsRun runFirst2017.py
2018
cmsDriver.py step1 -s RAW2DIGI,L1Reco,RECO,DQM -n 100 --eventcontent DQM --datatier DQMIO --conditions 110X_dataRun2_v1 --filein /store/data/Run2018D/ZeroBias/RAW/v1/000/323/997/00000/DDE05469-39F3-0647-BC31-AA8247C0B6C1.root --data --no_exec --python_filename=runFirst2018.py --era Run2_2018
cmsRun runFirst2018.py
if this PR is a backport please specify the original PR:
is not a backport