-
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
Track-gen matching passing through TrackingParticle #33774
Conversation
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33774/22739
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-33774/22772
|
A new Pull Request was created by @elusian for master. It involves the following packages: SimTracker/TrackAssociation @cmsbuild, @civanch, @mdhildreth can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-dfca37/15210/summary.html Comparison SummarySummary:
|
// class declaration | ||
// | ||
|
||
class PackedCandidateGenAssociationProducer : public edm::stream::EDProducer<> { |
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.
Looks like this could be edm::global
module.
// class declaration | ||
// | ||
|
||
class SimLinkPruner : public edm::stream::EDProducer<> { |
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.
Looks like this too could be edm::global
module.
using namespace edm; | ||
|
||
if (firstEvent_) { | ||
PdgEntryReplacer rep(iSetup); |
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 needs to be migrated to EventSetup consumes. (I understand it would have implications outside of the code added in this PR, so this may be a note more for @cms-sw/simulation-l2)
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.
Hi,
I think a lot of the event data access boilerplate can be simplified to improve readability as you don't check the validity of the handles, as suggested at: https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideEDMGetDataFromEvent#get.
Also I would suggest a better naming for SimLinkPruner
-> DigiSimLinkPruner
edm::Handle<edm::Association<reco::GenParticleCollection>> htrackToGenAssoc; | ||
iEvent.getByToken(trackToGenToken_, htrackToGenAssoc); | ||
const auto& trackToGenAssoc = *htrackToGenAssoc; |
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.
edm::Handle<edm::Association<reco::GenParticleCollection>> htrackToGenAssoc; | |
iEvent.getByToken(trackToGenToken_, htrackToGenAssoc); | |
const auto& trackToGenAssoc = *htrackToGenAssoc; | |
const auto& trackToGenAssoc = iEvent.get(trackToGenToken_); |
edm::Handle<edm::Association<pat::PackedCandidateCollection>> htrackToPackedCandidatesAssoc; | ||
iEvent.getByToken(trackToPcToken_, htrackToPackedCandidatesAssoc); | ||
const auto& trackToPackedCandidatesAssoc = *htrackToPackedCandidatesAssoc; |
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.
edm::Handle<edm::Association<pat::PackedCandidateCollection>> htrackToPackedCandidatesAssoc; | |
iEvent.getByToken(trackToPcToken_, htrackToPackedCandidatesAssoc); | |
const auto& trackToPackedCandidatesAssoc = *htrackToPackedCandidatesAssoc; | |
const auto& trackToPackedCandidatesAssoc = iEvent.get(trackToPcToken_); |
edm::Handle<edm::Association<reco::GenParticleCollection>> hgenToPrunedAssoc; | ||
iEvent.getByToken(genToPrunedToken_, hgenToPrunedAssoc); | ||
const auto& genToPrunedAssoc = *hgenToPrunedAssoc; |
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.
edm::Handle<edm::Association<reco::GenParticleCollection>> hgenToPrunedAssoc; | |
iEvent.getByToken(genToPrunedToken_, hgenToPrunedAssoc); | |
const auto& genToPrunedAssoc = *hgenToPrunedAssoc; | |
const auto& genToPrunedAssoc = iEvent.get(genToPrunedToken_); |
edm::Handle<edm::Association<reco::GenParticleCollection>> hgenToPrunedAssocWSO; | ||
iEvent.getByToken(genToPrunedWSOToken_, hgenToPrunedAssocWSO); | ||
const auto& genToPrunedAssocWSO = *hgenToPrunedAssocWSO; |
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.
edm::Handle<edm::Association<reco::GenParticleCollection>> hgenToPrunedAssocWSO; | |
iEvent.getByToken(genToPrunedWSOToken_, hgenToPrunedAssocWSO); | |
const auto& genToPrunedAssocWSO = *hgenToPrunedAssocWSO; | |
const auto& genToPrunedAssocWSO = iEvent.get(genToPrunedWSOToken_); |
edm::Handle<edm::View<reco::Track>> htracks; | ||
iEvent.getByToken(tracksToken_, htracks); | ||
const auto& tracks = *htracks; |
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.
edm::Handle<edm::View<reco::Track>> htracks; | |
iEvent.getByToken(tracksToken_, htracks); | |
const auto& tracks = *htracks; | |
const auto& tracks = iEvent.get(tracksToken_); |
firstEvent_ = false; | ||
} | ||
|
||
edm::Handle<TrackingParticleCollection> tps; |
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.
as above, but changing the loop at line 315
iEvent.getByToken(tpToken_, tps); | ||
|
||
edm::Handle<reco::GenParticleCollection> gps; | ||
iEvent.getByToken(gpToken_, gps); |
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.
as above, but changing the calls below.
// ------------ method fills 'descriptions' with the allowed parameters for the module ------------ | ||
void SimLinkPruner::fillDescriptions(edm::ConfigurationDescriptions& descriptions) { | ||
edm::ParameterSetDescription desc; | ||
desc.add<edm::InputTag>("trackingParticles", edm::InputTag("mix", "MergedTrackTruth")); |
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.
how does premixing deal with this?
Or is this meant for Signal TPs only by construction?
|
||
void TrackingParticleSelectorByGen::fillDescriptions(edm::ConfigurationDescriptions &descriptions) { | ||
edm::ParameterSetDescription desc; | ||
desc.add<edm::InputTag>("trackingParticles", edm::InputTag("mix", "MergedTrackTruth")); |
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.
how is premixing going to be dealt with?
Or is this meant for Signal TPs only by construction?
// class declaration | ||
// | ||
|
||
class SimLinkPruner : public edm::stream::EDProducer<> { |
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 think something like DigiSimLinkPruner
would be more appropriate.
@elusian , what is the value of extra memory, which bring this PR? |
…d on their association to a gen particle
+operations |
@cms-sw/pdmv-l2 @cms-sw/upgrade-l2 Do you have further comments? |
Sorry, I somehow miss this. Could you please clarify few things? (It is maybe somewhere in the long discussion of this PR)
Thanks and sorry for my late. |
as described in #33774 (comment) (even though it was done in 10_6_X), the code works with premixing. Note though that the code is making associations only to the signal tracking particles. So, the presence of pileup doesn't really matter that much. |
+Upgrade Thanks @slava77 for confirmation. That is what I understand from the code too that it will work with signal only for premixing. For Phase-2 size, I think the review can be done later, considering the need of PR for UL now. |
+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. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
Hello @elusian , just to inform you that because of this PR, we are not able to produce RECO-only RelVal for 12_0_0_pre3 campaign (both Run3 and Phase2). The production failed to find the module and complained product not found. Please see what we have tried here. https://dmytro.web.cern.ch/dmytro/cmsprodmon/workflows.php?campaign=CMSSW_12_0_0_pre3__fullsim_PU_2021_14TeV_RECOonly-1624276545 Fatal Exception (Exit code: 8006) |
@chayanit The change of RAW content is in |
That is correct, the missing product in the RAWSIM was not available on CMSSW_12_0_0_pre2, so it is not possible to run only on the old RAW without configuration changes |
PR description:
This PR adds a way to match generalTracks (in AOD) and packedPFCandidates and lostTracks (in miniAOD) to a subset of genParticles, using association by hit on TrackingParticles.
The association is performed on step3 and just replicated in the miniAOD.
Since the track association by hit needs both TrackingParticles and SimLink for pixel and strips and the SimLink collections are not available in RAWSIM, two plugins are created to be run in step2 to add two pruned collections and avoid adding the all the SimLink, which have a non negligible size.
The changes contained are:
No plugin is needed for association between tracks and GenParticles through TrackingParticle as it is already present in CMSSW (MCTrackMatcher).
PR validation:
On a B+->Psi2SK sample (one of the possible targets for this PR) we registered this increases in size, timing and memory
if this PR is a backport please specify the original PR and why you need to backport that PR:
Not a backport, but if possible we would like to backport this to 10_6 for MC production for BParking reprocessing