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

Introduce changes in order to switch from LumiScalers to MetaData #27677

Closed
wants to merge 1 commit into from

Conversation

arossi83
Copy link
Contributor

@arossi83 arossi83 commented Aug 2, 2019

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).

  1. 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

  2. 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

…lineLuminosityRecord when the last are avilable
@cmsbuild
Copy link
Contributor

cmsbuild commented Aug 2, 2019

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Aug 2, 2019

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-27677/11263

  • This PR adds an extra 60KB to repository

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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean via eras?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@mmusich mmusich Aug 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

hold

@arossi83 @mmusich given the situation #27676 I put on hold this PR (up to you to say whether you would like to review it later or make a new one)

@cmsbuild cmsbuild modified the milestones: CMSSW_11_1_X, CMSSW_11_0_X Dec 10, 2019
@cmsbuild cmsbuild mentioned this pull request Dec 13, 2019
@fabiocos
Copy link
Contributor

fabiocos commented Dec 16, 2019

@arossi83 what is the plan here? This PR was dependent on #27676 which was withdrawn pending a new proposal with a different approach

@arossi83
Copy link
Contributor Author

@fabiocos I'm closing this PR, a completely new approach is needed.

@arossi83 arossi83 closed this Dec 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants