-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Try to fix GeometryProducer and G4e examples #38864
Conversation
} | ||
LogDebug("Geant4e") << "G4e -- Got simTracks of size " << simTracks->size(); | ||
std::cout << "Geant4e " << "G4e -- Got simTracks of size " << simTracks->size() << std::endl; |
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 one produces:
%MSG-w Geant4e: Geant4ePropagatorAnalyzer:propAna 26-Jul-2022 13:23:00 CEST Run: 1 Event: 1
No tracks found
%MSG
Geant4e G4e -- Got simTracks of size ----- Begin Fatal Exception 26-Jul-2022 13:23:00 CEST-----------------------
An exception of category 'ProductNotFound' occurred while
[0] Processing Event run: 1 lumi: 1 event: 1 stream: 0
[1] Running path 'g4AnalPath'
[2] Calling method for module Geant4ePropagatorAnalyzer/'propAna'
Exception Message:
Principal::getByLabel: Found zero products matching all criteria
Looking for type: std::vector<SimTrack>
Looking for module label: g4SimHits
Looking for productInstanceName:
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-38864/31276
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-38864/31277
|
A new Pull Request was created by @VinInn (Vincenzo Innocente) for master. It involves the following packages:
@cmsbuild, @civanch, @mdhildreth can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild, please test |
let's the test fail |
if (!simVertices.isValid()) { | ||
LogWarning("Geant4e") << "No tracks found" << std::endl; | ||
return; | ||
LogWarning("Geant4e") << "No verticess found" << std::endl; |
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.
typo.
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.
thanks for spotting.
Once we find how to get the products will fix this 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.
Probably unrelated, but about
the test does not find products (getByLabel broken?)
Shouldn't be tokens used instead? https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideEDMGetDataFromEvent#get_ByToken
AFAIK getByLabel
is deprecated, but I would have expected a different error message.
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.
AFAIK
getByLabel
is deprecated, but I would have expected a different error message.
Correct, and I would have expected too to see a different exception (complaining about missing consumes()
calls).
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.
deprecated should not mean not working... (or message should indeed say something different)
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.
Does one really has to consume each single product used?
and create tokens etc just for a single very stupid analyzer?
One cannot just say I consume everything in the input file?
I understand products to be produced, but for those in the input file is a bit abusive to ask all those boilerplate....
is there a script that generate the boilerplate?
I will not write it by hand!
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.
Does one really has to consume each single product used?
Yes.
and create tokens etc just for a single very stupid analyzer?
Yes.
One cannot just say I consume everything in the input file?
No.
I understand products to be produced, but for those in the input file is a bit abusive to ask all those boilerplate....
The consumes information is used also for input file to read in only those branches that are actually needed by the module.
is there a script that generate the boilerplate?
I'm not aware of any.
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've added
@@ -147,6 +147,9 @@ Geant4ePropagatorAnalyzer::Geant4ePropagatorAnalyzer(const edm::ParameterSet &iC
thePropagator(nullptr),
G4VtxSrc_(iConfig.getParameter<edm::InputTag>("G4VtxSrc")),
G4TrkSrc_(iConfig.getParameter<edm::InputTag>("G4TrkSrc")) {
+
+ consumes(G4TrkSrc_);
+
in the constructor.
getByLabel still produces the very same error as above
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 point of the migration is to use getByToken
instead of getByLabel
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.
Just to note that the exception message has been improved for this particular corner case in #38875.
About
@@ -147,6 +147,9 @@ Geant4ePropagatorAnalyzer::Geant4ePropagatorAnalyzer(const edm::ParameterSet &iC thePropagator(nullptr), G4VtxSrc_(iConfig.getParameter<edm::InputTag>("G4VtxSrc")), G4TrkSrc_(iConfig.getParameter<edm::InputTag>("G4TrkSrc")) { + + consumes(G4TrkSrc_); +
in this case the consumes()
call would need an explicit type (because it can't infer it from anywhere) along
@@ -147,6 +147,9 @@ Geant4ePropagatorAnalyzer::Geant4ePropagatorAnalyzer(const edm::ParameterSet &iC thePropagator(nullptr), G4VtxSrc_(iConfig.getParameter<edm::InputTag>("G4VtxSrc")), G4TrkSrc_(iConfig.getParameter<edm::InputTag>("G4TrkSrc")) { + + consumes<std::vector<SimTrack>>(G4TrkSrc_); +
In that case the getByLabel()
should still work (even if getByToken()
is strongly favored). The consumes()
call itself has been required since 2016.
On 26 Jul, 2022, at 4:34 PM, Matti Kortelainen ***@***.***> wrote:
The consumes information is used also for input file to read in only those branches that are actually needed by the module.
would not be enough something in the PoolSource such ```keep *_g4SimHits_*_SIM``` ?
Anyhow that's a disgression. Apparenlty no one else is botherer by having more boilerplate than actual code in their Analyzer
(or nobody is actually doing analysis in cmssw anyhow)
v.
|
-1 Failed Tests: UnitTests Unit TestsI found errors in the following unit tests: ---> test testG4Refitter had ERRORS Comparison SummarySummary:
|
what about this (including the modifier)? |
@cmsbuild, please test |
Looks ok to me (including the modifier). |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-38864/31296
|
Pull request #38864 was updated. @civanch, @mdhildreth can you please check and sign again. |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-1c3342/26489/summary.html Comparison SummarySummary:
|
+1 configuration of SIM magnetic field is more complicate in g4SImHits than is needed for propagation but the use of clone in any case is more correct than it was before. |
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, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
@VinInn the PR is still [RFC], and even if fully signed it will be considered for being merged after than that sign get removed from the PR title. By the way the PR description says
which kind of confirms that there is still some work in progress for the "old" propagator |
old refers to test not propagator. btw the reason the simple test does not propagate beyond 2m is trivial |
FWIW, +1 |
+1 |
status
works for run1 geometry (at least does not crash)
does not work for run2 (at least 2022)
see #38739
the test does not find products (getByLabel broken?)
updated status:
should work for all Eras and geometry models.
the propagator "old" test needs a "refresh": it was based on the early use of Geane for Muon reconstruction that has been obsoleted years ago. It cannot even work at the moment as current propagator is limited to 2m