-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-34612/24185
|
A new Pull Request was created by @namapane (Nicola Amapane) for master. It involves the following packages:
@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. 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") |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For HLT, a change can be inserted in https://github.com/cms-sw/cmssw/blob/master/HLTrigger/Configuration/python/customizeHLTforCMSSW.py
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
ESHandle<DTRecoConditions> hVdrift; | ||
setup.get<DTRecoConditionsVdriftRcd>().get(hVdrift); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
@cmsbuild please test |
please abort |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5be359/17188/summary.html 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. Comparison SummarySummary:
|
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5be359/17624/summary.html 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. Comparison SummarySummary:
|
+1 |
+1 |
+1 |
+1
|
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) |
+1 |
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.