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

Migrate most of MixingModule and PreMixingModule to EventSetup consumes #31697

Merged
merged 3 commits into from Apr 30, 2021

Conversation

makortel
Copy link
Contributor

@makortel makortel commented Oct 7, 2020

PR description:

This PR is part of #31061. In addition of plain migration to EventSetup consumes I did some refactoring related to getting the EventSetup products (like moving the get() calls from beginRun/beginLumi to Event, and passing around const references to ES products instead of edm::ESHandle). It has two caveats (which make the "most of") that need to be discussed/agreed:

I noticed the MixingModule (and BMixingModule base class, so affects all mixing modules) have the capability of updating the mixing parameters from the EventSetup, see e.g.

void MixingModule::reload(const edm::EventSetup& setup) {
//change the basic parameters.
edm::ESHandle<MixingModuleConfig> config;
setup.get<MixingRcd>().get(config);
minBunch_ = config->minBunch();
maxBunch_ = config->maxBunch();
bunchSpace_ = config->bunchSpace();
//propagate to change the workers
for (unsigned int ii = 0; ii < workersObjects_.size(); ++ii) {
workersObjects_[ii]->reload(setup);
}
}

void PileUp::reload(const edm::EventSetup& setup) {
//get the required parameters from DB.
edm::ESHandle<MixingModuleConfig> configM;
setup.get<MixingRcd>().get(configM);
const MixingInputConfig& config = configM->config(inputType_);

For the EventSetup consumes that alone is fine, but the pixel digitizer uses the bunchspacing to decide which of the two ES products it gets
void SiPixelDigitizerAlgorithm::init_DynIneffDB(const edm::EventSetup& es, const unsigned int& bunchspace) {
if (AddPixelInefficiency && !pixelEfficiencies_.FromConfig) {
if (bunchspace == 50)
es.get<SiPixelDynamicInefficiencyRcd>().get("50ns", SiPixelDynamicInefficiency_);
else
es.get<SiPixelDynamicInefficiencyRcd>().get(SiPixelDynamicInefficiency_);
pixelEfficiencies_.init_from_db(geom_, SiPixelDynamicInefficiency_);
}
}

In principle it could be possible for the product-to-be-got to change in the IOV boundaries of MixingRcd (if this mode of operation would be enabled), on the other hand updates after the first event are, in fact, already made impossible by
if (firstFinalizeEvent_) {
const unsigned int bunchspace = PileupInfo_->getMix_bunchSpacing();
_pixeldigialgo->init_DynIneffDB(iSetup, bunchspace);
firstFinalizeEvent_ = false;
}

Nevertheless, it could be that the mixing parameters would be read from an EventSetup object instead of configuration. If this mode of operation needs to be supported, we need to figure out some way to get only (right) one of the SiPixelDynamicInefficiency products instead of both as in this PR. Possibilities include an ESProducer mayConsume-type feature, or abstracting the choice between the products into a new ESProducer. Anyway, the big question is if MixingModule infrastructure has to continue to support changing mixing parameters based on MixingModuleConfig EventSetup product?

Answer below: this mode should continue to be supported. To be done in a subsequent PR.

I did not migrate DataMixingModule (because it is not being used). Likely it becomes even more broken with this PR. I hope this is acceptable.

Answer below: Breaking DataMixingModule even more is acceptable.

PR validation:

Limited matrix runs.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2020

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2020

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31697/18856

Code check has found code style and quality issues which could be resolved by applying following patch(s)

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2020

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2020

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31697/18858

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2020

A new Pull Request was created by @makortel (Matti Kortelainen) for master.

It involves the following packages:

CalibTracker/SiPixelESProducers
RecoLocalTracker/SiStripZeroSuppression
SimCalorimetry/CastorSim
SimCalorimetry/EcalSimProducers
SimCalorimetry/EcalTestBeam
SimCalorimetry/HGCalSimProducers
SimCalorimetry/HcalSimProducers
SimCalorimetry/HcalTestBeam
SimFastTiming/FastTimingCommon
SimGeneral/CaloAnalysis
SimGeneral/MixingModule
SimGeneral/TrackingAnalysis
SimTracker/SiPhase2Digitizer
SimTracker/SiPixelDigitizer
SimTracker/SiStripDigitizer

@perrotta, @civanch, @yuanchao, @slava77, @christopheralanwest, @mdhildreth, @cmsbuild, @tocheng, @tlampen, @jpata, @pohsun, @kpedro88 can you please review it and eventually sign? Thanks.
@echabert, @felicepantaleo, @yduhm, @robervalwalsh, @argiro, @pfs, @thomreis, @lgray, @threus, @mmusich, @cericeci, @sethzenz, @abdoulline, @JanFSchulte, @jhgoh, @dgulhan, @apsallid, @prolay, @HuguesBrun, @slomeo, @ferencek, @pieterdavid, @vandreev11, @abbiendi, @GiacomoSguazzoni, @rovere, @VinInn, @cseez, @tocheng, @deguio, @hatakeyamak, @alesaggio, @ebrondol, @mtosi, @fabiocos, @rchatter, @trocino, @gbenelli, @Fedespring, @calderona, @dkotlins, @gpetruc, @mariadalfonso, @folguera, @tvami this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

@makortel
Copy link
Contributor Author

makortel commented Oct 7, 2020

@cmsbuild, please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2020

The tests are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2020

+1
Tested at: 316e388
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2430a0/9778/summary.html
CMSSW: CMSSW_11_2_X_2020-10-07-1100
SCRAM_ARCH: slc7_amd64_gcc820

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2020

Comparison job queued.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2020

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2430a0/9778/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 35
  • DQMHistoTests: Total histograms compared: 2542225
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2542202
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 34 files compared)
  • Checked 149 log files, 22 edm output root files, 35 DQM output files

@cmsbuild
Copy link
Contributor

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2430a0/14351/summary.html
COMMIT: 7f1c3b1
CMSSW: CMSSW_12_0_X_2021-04-19-2300/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/31697/14351/install.sh to create a dev area with all the needed externals and cmssw changes.

CMS Clang-Tidy warnings: There are Clang-Tidy warnings. See https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2430a0/14351/llvm-analysis/cmsclangtidy.txt for details.

Comparison Summary

Summary:

  • No significant changes to the logs found
  • Reco comparison results: 4 differences found in the comparisons
  • DQMHistoTests: Total files compared: 38
  • DQMHistoTests: Total histograms compared: 2877046
  • DQMHistoTests: Total failures: 7
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2877017
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 37 files compared)
  • Checked 160 log files, 37 edm output root files, 38 DQM output files
  • TriggerResults: no differences found

@perrotta
Copy link
Contributor

+1

  • Mostly AlCa and Sim: for Reco there are only two classes in RecoLocalTrackers touched, with rather simple updates
  • Jenkins tests pass, with no differences in output

@yuanchao
Copy link
Contributor

+1

  • migrated most of EventSetupRecord::get(ESHandle&) to EventSetup::getHandle(ESGetToken&); two in TODO explained
  • WF matrix tests and unit tests all passed

@srimanob
Copy link
Contributor

+Upgrade

@civanch
Copy link
Contributor

civanch commented Apr 24, 2021

+1

@silviodonato
Copy link
Contributor

kind reminder @cms-sw/db-l2

@makortel
Copy link
Contributor Author

@ggovi Could you please review and sign? Thanks.

@ggovi
Copy link
Contributor

ggovi commented Apr 30, 2021

+1

@cmsbuild
Copy link
Contributor

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

@silviodonato
Copy link
Contributor

+1

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.

None yet