-
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
Format for clustering CSC rechits with jet algorithms #35543
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-35543/25769
|
A new Pull Request was created by @kakwok for master. It involves the following packages:
@jpata, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
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 is just a quick set of comments on the style
#include "Geometry/CSCGeometry/interface/CSCGeometry.h" | ||
#include "DataFormats/MuonDetId/interface/CSCDetId.h" | ||
|
||
class CSCJetCandidateProducer : 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.
header files are not needed for plugins; please merge this .h file contents into the CSCJetCandidateProducer.cc
all new modules should have a fillDescriptions
method defined to provide a default configuration
https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideConfigurationValidationAndHelp
<use name="DataFormats/TrackingRecHit"/> | ||
<use name="DataFormats/Common"/> |
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.
please revert to the old indentation
<class name="reco::CSCJetCandidate" ClassVersion="4"> | ||
<version ClassVersion="3" checksum="1185432696"/> | ||
<version ClassVersion="4" checksum="882507185"/> |
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.
<class name="reco::CSCJetCandidate" ClassVersion="4"> | |
<version ClassVersion="3" checksum="1185432696"/> | |
<version ClassVersion="4" checksum="882507185"/> | |
<class name="reco::CSCJetCandidate" ClassVersion="3"> | |
<version ClassVersion="3" checksum="882507185"/> |
remove intermediate/unused class versions
edm::ESHandle<CSCGeometry> cscG; | ||
edm::Handle<CSCRecHit2DCollection> cscRechits; | ||
|
||
setup.get<MuonGeometryRecord>().get(cscG); |
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.
esConsumes should be used
https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideHowToGetDataFromES#In_ED_module
#include "DataFormats/Math/interface/Point3D.h" | ||
#include "DataFormats/Common/interface/SortedCollection.h" | ||
|
||
#include <DataFormats/CSCRecHit/interface/CSCRecHit2D.h> |
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.
not used.
#include <DataFormats/CSCRecHit/interface/CSCRecHit2D.h> |
|
||
namespace reco { | ||
|
||
class CSCJetCandidate : public LeafCandidate { |
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 have (so far just minor) preference for such class to be in DataFormats/MuonReco.
Also, the purpose seems to be rather generic and we should probably consider making a more generic type that can handle transparently other muon detectors (DT/RPC/GEM).
: LeafCandidate(0, LorentzVector(math::PtEtaPhiMLorentzVector(1.0, eta, phi, 0)), Point(0, 0, 0)) { | ||
x_ = x; |
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.
: LeafCandidate(0, LorentzVector(math::PtEtaPhiMLorentzVector(1.0, eta, phi, 0)), Point(0, 0, 0)) { | |
x_ = x; | |
: LeafCandidate(0, LorentzVector(math::PtEtaPhiMLorentzVector(1.0, eta, phi, 0)), Point(0, 0, 0)), x_(x) { |
initializer list (before {
is preferred to the use of the constructor body)
[the comment applies to the rest of the members]
@cmsbuild please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8a69e7/19421/summary.html CMS StaticAnalyzer warnings: There are 1 EventSetupRecord::get warnings. See https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8a69e7/19421/llvm-analysis/esrget-sa.txt for details. Comparison SummarySummary:
|
is all this really needed? |
@laurenhay In the reco meeting discussion on Oct 1 the discussion was suggestive that the persisted products in the standard data tiers (e.g. miniAOD) was not yet planned/intended. |
Pulling in @rappoccio to clarify since he's been in contact with Martin on this. From what I understand it's a no, FastJet can only run on compatible jet objects. |
Generally speaking, no, we can't do this at the moment. We really have to rewrite the data formats for this from scratch if we want to avoid the back-and-forth copy. We are in contact with the fastjet authors to put in the hooks so that we can avoid the copy and just run on flat vectors. (In fact I put a proposal in to get a postdoc to work on this for HL-LHC but it wasn't deemed important enough so wasn't funded). This would be an HL-LHC target, we definitely shouldn't hold up this PR. |
Do not understand. you have just to copy RecHit position in FastJet jets. clusterize. copy back into Clusters. |
Hi Slava,
What is all this about? Why is somebody adding code to CSC Local Reco? I
have heard nothing about it.
Thanks,
Tim
Slava Krutelyov wrote on 10/6/21 17:27:
…
is all this really needed? would not be better to directly call
FastJet and avoid to create new data objects and copy back and
forth info?
@laurenhay <https://github.com/laurenhay>
please check this PR and perhaps clarify if there is a (configurable)
interface to call FastJet directly without redirecting the
|edm::Event| data via a jet producer?
In the reco meeting discussion on Oct 1 the discussion was suggestive
that the persisted products in the standard data tiers (e.g. miniAOD)
was not yet planned/intended.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35543 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGYLHQ2PGFMHFWCGLCVZY3UFRTGPANCNFSM5FMA5VOQ>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Yes, all well and good, but it shouldn't be inside CSC local reco
packages! Surely its just a consumer of CSC rechits?
Tim
rappoccio wrote on 10/7/21 19:27:
…
Hi @VinInn <https://github.com/VinInn> we've been doing this at the
HLT level since 2009, it's no different from every other jet
collection at HLT.
@ptcox <https://github.com/ptcox> this is for an EXO-based trigger
from @kakwok <https://github.com/kakwok> for long-lived jets.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35543 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGYLHWVEITF3FGQFGETTBTUFXKBPANCNFSM5FMA5VOQ>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Hi Tim, I thought that this analysis was closely known in the CSC DPG. I guess I've overestimated. |
Hi Slava,
No I've never heard of it. It's nothing to do with CSC DPG. And I'd
really really like it NOT to be entangled into CSC rechit building. I do
not want to have to worry about somebody else's tangential code inside
CSCRecHitD.
Tim
Slava Krutelyov wrote on 10/7/21 19:32:
…
Hi Tim,
I thought that this analysis was closely known in the CSC DPG. I guess
I've overestimated.
As I commented in the preliminary review, |I have (so far just minor)
preference for such class to be in DataFormats/MuonReco.|
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35543 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGYLHR6YVMCUDBYN7XQRE3UFXKUDANCNFSM5FMA5VOQ>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Hi @ptcox , yes, it's a consumer of CSC rechits. We can move the code to Hi @rappoccio, if I understand correctly, @VinInn 's proposal is to write a new producer directly calling |
Isn't @VinInn perhaps trying to hint to the costs implied by the approach? |
@dpiparo they're the same as other jet HLT paths. I also don't see the advantage. We still have to copy rechits to a new DataFormat just like we do now, but @VinInn's suggestion has the disadvantage of having parallel code that implements exactly the same thing as FastjetProducer, but with fewer features implemented and less validation ;). A better approach is to fix this "en masse" during / after Run 3 so the data handling in and out of fastjet is done in a better way. We're already in contact with the authors (along with IRIS-HEP people), and the way forward is relatively clear, we just need someone who can do the implementation. |
On 8 Oct, 2021, at 2:19 PM, rappoccio ***@***.***> wrote:
We still have to copy rechits to a new DataFormat just like we do now
Why?
One needs just to populate locally the FastJet input vector
v.
|
So that @kakwok and collaborators can access information about the CSC rechits from the jets they're making. It needs to be persistified one way or another. |
On 8 Oct, 2021, at 2:26 PM, rappoccio ***@***.***> wrote:
So that @kakwok and collaborators can access information about the CSC rechits from the jets they're making. It needs to be persistified one way or another.
https://github.com/cms-sw/cmssw/pull/35543/files#diff-e9b281fcb4d161c1ad2090f7ea36ea1f78ce9dc27143496de45e16d6a7fb348aR62-R74
what one builds is not Jet as-we-know-it. It's a local cluster (as in all other detectors).
One builds a specific CSCCluster with a RefVector to the hits in question.
v.
|
IMO, "a specific CSC cluster with a RefVector" is a new dataformat that should be encapsulated concisely. Anyway, you all have the last word. I think it's not going to be faster in the end, it will duplicate code, and will needlessly add to the long-term maintenance and validation costs. My 0.02 CHF. I'll shut up now :) |
@kakwok |
-1 superseded by #35836 |
PR description:
This PR adds a new class
CSCJetCandidate
that builds fromCSCRecHit2D
and conform toReco::Candidate
format.The new collection can be used for running jet algorithms on CSC rechits.
This is an essential ingredient for an HLT path for LLP in Run 3.
Presentation at Reco meeting, Oct 1
PR validation: