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

Update DT DQM, calibration scripts, and local reco code to allow using "new" DB format #34612

Merged
merged 8 commits into from Aug 12, 2021

Conversation

namapane
Copy link
Contributor

PR description:

New DT payload formats were introduced with #5977, but so far have been adopted only for uncertainties (#9883).
A first bucnch of updates to DT vdrift calibration code/scripts to enable to optionally read/write constants in the new format was published with #31808.
This PR updates all remaining code. The default behaviour is unchanged (ie use the legacy format); it is one step towards enabling a complete migration.

PR validation:

all modifications checked to provide identical results with the default (old) format as well as when reading identical constants in the new format.

@cmsbuild cmsbuild added this to the CMSSW_12_0_X milestone Jul 24, 2021
@namapane namapane changed the title Update DT DQM, calibration scripts, and local reco code yo allow using "new" DB format Update DT DQM, calibration scripts, and local reco code to allow using "new" DB format Jul 24, 2021
@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-34612/24185

  • This PR adds an extra 216KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @namapane (Nicola Amapane) for master.

It involves the following packages:

  • CalibMuon/DTCalibration (alca)
  • CondTools/DT (db)
  • DQM/DTMonitorClient (dqm)
  • DQM/DTMonitorModule (dqm)
  • RecoLocalMuon/DTRecHit (reconstruction)

@perrotta, @malbouis, @andrius-k, @yuanchao, @kmaeshima, @tlampen, @ErnestaP, @ahmad3213, @rvenditti, @cmsbuild, @jpata, @jfernan2, @slava77, @ggovi, @pohsun, @francescobrivio, @tvami can you please review it and eventually sign? Thanks.
@bellan, @mmusich, @jhgoh, @tocheng, @battibass this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy, @perrotta you are the release manager for this.

cms-bot commands are listed here

@@ -34,19 +36,37 @@ DTLinearDriftFromDBAlgo::DTLinearDriftFromDBAlgo(const ParameterSet& config)
// Option to force going back to digi time at Step 2
stepTwoFromDigi(config.getParameter<bool>("stepTwoFromDigi")),
useUncertDB(config.getParameter<bool>("useUncertDB")),
readLegacyTTrigDB(config.existsAs<bool>("readLegacyTTrigDB") ? config.getParameter<bool>("readLegacyTTrigDB")
Copy link
Contributor

Choose a reason for hiding this comment

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

::exists method is rather an exception left for cases for rather old and complex pre-7X software.
Define a ::fillDescriptions method https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideConfigurationValidationAndHelp
If a fillDescriptions implementation is too complicated due to the tools/plugins coding pattern, please modify the existing configs appropriately and set the value to true/false there.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I discussed this with @battibass before PR-ing and our opinion is that ,oving to fillDescriptions consistently would be too complicated since his module is re-used in several places upstream, cf:
https://github.com/cms-sw/cmssw/search?l=Python&q=DTLinearDriftFromDBAlgo

OTHO, all existing configs have already been modified in this same PR. The reason we added existsAs is not because of cfgs, but because this module is used in HLT and we want to allow for a smooth transition while the new cards are added to confDB.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Uhm the clean solution is obviously to update confDB which (in my understanding) is trivial once the card is present in the relevant cfi.py. At that point the temporary existsAs can be removed. I think that editing customizeHLTforCMSSW.py would be an equally temporary solution, and it seem less clean potentially and more error-prone..
What about open an issue to re-check and clean-up existAs in DT code instead, so that we don't forget to remove the temporary existAs()? (I think there are a few to be removed elsewhere as well)

Copy link
Contributor

Choose a reason for hiding this comment

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

customizeHLTforCMSSW.py has been the preferred solution since a while

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see but as I mentioned this module is reused in a number of places, cf:
https://github.com/cms-sw/cmssw/search?l=Python&q=DTLinearDriftFromDBAlgo
which means we would have to add quite a number of temporary changes in customizeHLTforCMSSW.py instead than a single line in the code...
OTOH we have other existsAs to cleanup in the subsystem, so my proposal of coupling this with an issue would also go in the direction of a full cleanup and sync.
If that is not fine with you, my preference is to postpone modification of this class to a future PR, after the new cards have been added to confDB manually (and proceed with the rest of the PR now).

Copy link
Contributor

Choose a reason for hiding this comment

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

If that is not fine with you, my preference is to postpone modification of this class to a future PR, after the new cards have been added to confDB manually (and proceed with the rest of the PR now).

My preference in the current context (no dillDescriptions) is to have a customizeHLTforCMSSW.py and no existsAs

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I understand but I really have a hard time figuring out how this would be done.
The new cards should be added to these psets:

  • hltDt1DRecHits.recAlgoConfig
  • hltDt4DSegments.Reco4DAlgoConfig.recAlgoConfig
  • hltDt4DSegments.Reco4DAlgoConfig.Reco2DAlgoConfig.recAlgoConfig
  • hltDt4DSegmentsMeanTimer.Reco4DAlgoConfig.recAlgoConfig
  • hltDt4DSegmentsMeanTimer.Reco4DAlgoConfig.Reco2DAlgoConfig.recAlgoConfig

How should that be coded in customizeHLTforCMSSW.py?
is there a way to add only the new cards, or should the entire pset be replaced?

Copy link
Contributor

Choose a reason for hiding this comment

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

there are relevant examples in customizeHLTforCMSSW.py already for replacement/parameter insertions by the module type.

IIUC, DTRecHitProducer is the first kind

for producer in producers_by_type(process, "DTRecHitProducer"):
  producer.recAlgoConfig.readLegacyTTrigDB = cms.bool(False)

the other cases are apparently DTRecSegment4DProducer

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should be done now. As far as I can tell, HLT runs correctly with the latest commit.

Comment on lines +59 to +60
ESHandle<DTRecoConditions> hVdrift;
setup.get<DTRecoConditionsVdriftRcd>().get(hVdrift);
Copy link
Contributor

Choose a reason for hiding this comment

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

this additional es.get goes against the current campaign to define esConsumes.
Please consider adding esConsumes in this PR already.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK will have a look on this on Monday (other get's will have to be migrated in the same class as well)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Uhm, this class is an helper that is called by the actual EDProducer, but is not an EDProducer itself.
So I cannot directly call esConsumes from here. ("error: 'esConsumes' was not declared in this scope")
@slava77, do you know how should I handle this use case? I checked the doc but found nothing apparently related.

Copy link
Contributor

Choose a reason for hiding this comment

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

the consumesCollector will need to be passed to the algorithm constructor.
a (somewhat random) example is available in isolation

theExtractor = IsoDepositExtractorFactory::get()->create(extractorName, extractorPSet, consumesCollector());

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Mmhh this would mean updating every implementation under RecoLocalMuon/DTRecHit/plugins, don't you think it would make sense as a separate migration rather than being coupled to this specific PR?

Copy link
Contributor

Choose a reason for hiding this comment

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

it's OK to do in a follow up PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

One thing I could do is to add this in the algo interface with cc=0 as a default and leave it dummy in other implementations not affected by this PR. Do you like the idea?

Copy link
Contributor

Choose a reason for hiding this comment

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

without compiling this locally, I'm not sure that this would help much.

We did something along the lines in the MuonServiceProxy; there the solution was to add an interface (constructor and related calls) with ConsumesCollector. But then in this case it will probably just complicate the implementation with something artificially temporary.

@slava77
Copy link
Contributor

slava77 commented Jul 24, 2021

@cmsbuild please test

@qliphy
Copy link
Contributor

qliphy commented Jul 26, 2021

please abort

@qliphy
Copy link
Contributor

qliphy commented Jul 26, 2021

please test

@cmsbuild
Copy link
Contributor

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5be359/17188/summary.html
COMMIT: dce7665
CMSSW: CMSSW_12_0_X_2021-07-25-0000/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/34612/17188/install.sh to create a dev area with all the needed externals and cmssw changes.

CMS StaticAnalyzer warnings: There are 8 EventSetupRecord::get warnings. See https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5be359/17188/llvm-analysis/esrget-sa.txt for details.
CMS StaticAnalyzer warnings: There are 1 inherits from legacy modules warnings. See https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5be359/17188/llvm-analysis/legacy-mod-sa.txt for details.

Comparison Summary

Summary:

  • No significant changes to the logs found
  • Reco comparison results: 6 differences found in the comparisons
  • DQMHistoTests: Total files compared: 39
  • DQMHistoTests: Total histograms compared: 2998564
  • DQMHistoTests: Total failures: 12
  • DQMHistoTests: Total nulls: 1
  • DQMHistoTests: Total successes: 2998529
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.004 KiB( 38 files compared)
  • DQMHistoSizes: changed ( 312.0 ): 0.004 KiB MessageLogger/Warnings
  • Checked 165 log files, 37 edm output root files, 39 DQM output files
  • TriggerResults: no differences found

@cmsbuild
Copy link
Contributor

cmsbuild commented Aug 7, 2021

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5be359/17624/summary.html
COMMIT: 8fa7b72
CMSSW: CMSSW_12_1_X_2021-08-06-1100/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/34612/17624/install.sh to create a dev area with all the needed externals and cmssw changes.

CMS StaticAnalyzer warnings: There are 8 EventSetupRecord::get warnings. See https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5be359/17624/llvm-analysis/esrget-sa.txt for details.
CMS StaticAnalyzer warnings: There are 1 inherits from legacy modules warnings. See https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5be359/17624/llvm-analysis/legacy-mod-sa.txt for details.

Comparison Summary

Summary:

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

@slava77
Copy link
Contributor

slava77 commented Aug 9, 2021

+reconstruction

for #34612 8fa7b72

  • code changes since the last reco signoff for e98692d were technical, to rebase after the context lines changed in HLTrigger/Configuration/python/customizeHLTforCMSSW.py
  • jenkins tests pass

@jfernan2
Copy link
Contributor

+1

@Martin-Grunewald
Copy link
Contributor

+1

@ggovi
Copy link
Contributor

ggovi commented Aug 10, 2021

+1

@yuanchao
Copy link
Contributor

+1

  • enable new DT payload formats and validation
  • due to refactoring needed, esConsume mirgration to be done later
  • matrix tests and unit tests passed

@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. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

@qliphy
Copy link
Contributor

qliphy commented Aug 12, 2021

+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