-
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
Inefficiency in electron paths in Phase2 HLT in 13_3_X #42850
Comments
A new Issue was created by @swagata87 Swagata Mukherjee. @Dr15Jones, @rappoccio, @smuzaffar, @makortel, @sextonkennedy, @antoniovilela can you please review it and eventually sign/assign? Thanks. cms-bot commands are listed here |
assign hlt
|
New categories assigned: hlt @mmusich,@missirol,@Martin-Grunewald you have been requested to review this Pull request/Issue and eventually sign? Thanks |
@swagata87 |
Hello Marco, Setup CMMSW area
L1 related stuff
HLT related stuff (Soham's branch on L1 EG fix is merged in a more recent 13_1_X)
rereun L1
It creates a config which I ran, via crab, on this dataset:
The output files are here (in prod/phys03):
rereun HLT (on above output)
It creates a config which I ran, via crab, on the dataset created in previous step:
The output of rerunning HLT is stored in:
The efficiency of HLT in 13_1_X is measured on the above files. For 13_3_X, I've done the following. In this case L1 is not re-run, this is expected to have minimal effect as I understood from Soham. Setup CMMSW area (that IB is chosen as it has Soham's 13_3 branch of L1 EG fix merged)
HLT related stuff
rereun HLT (on a RelVal sample)
It creates a config which I ran, via crab, on this dataset:
The RelVal is D98 geometry, while I used The output of rerunning HLT is stored in:
The efficiency of HLT in 13_3_X is measured on the above files. |
type egamma |
assign upgrade |
New categories assigned: upgrade @AdrianoDee,@srimanob you have been requested to review this Pull request/Issue and eventually sign? Thanks |
Hi @swagata87 |
I did not explicitly checked offline reco electrons. But that is normally checked as part of release validation, so any issue would have been / will be spotted. Tagging @cms-sw/egamma-pog-l2 in case they are aware of anything in Reco electron validation for phase2. If nothing is spotted there, then it could be a HLT-specific issue. Pixel matching algo at HLT is different than in offline. |
One of the possible sources of discrepancy proposed by @swagata87 in pixel matching step is a difference in which the online BeamSpot is supplied to the event (due to e.g. #41597 ). diff --git a/RecoVertex/BeamSpotProducer/plugins/BeamSpotOnlineProducer.cc b/RecoVertex/BeamSpotProducer/plugins/BeamSpotOnlineProducer.cc
index 83aa832cfa5..52550f60448 100644
--- a/RecoVertex/BeamSpotProducer/plugins/BeamSpotOnlineProducer.cc
+++ b/RecoVertex/BeamSpotProducer/plugins/BeamSpotOnlineProducer.cc
@@ -226,6 +226,9 @@ void BeamSpotOnlineProducer::produce(Event& iEvent, const EventSetup& iSetup) {
*result = aSpot;
+
+ edm::LogPrint("BeamSpotOnlineProducer")<< "Reco beamspot: " << aSpot << std::endl;
+
iEvent.put(std::move(result));
} in both 13.1.X and 13.3.X I see:
thus I would exclude this as a possible sources of inefficiency. |
Do we still need this issue? |
I have not seen any confirmation of resolution, so I would expect yes. |
Does this issue persist in |
I'm opening this issue as asked here: #42819 (comment)
We are seeing some inefficiency in Phase2 HLT electron paths, primarily coming from pixel matching step, and this seem to affect all electron paths in 13_3_X, both in barrel and endcaps. We have checked that efficiency is fine in 13_1_X.
The inefficiency in 13_3_X was spotted in the context of adding a new electron path to the Phase2 HLT menu (PR: #42819, talk: https://indico.cern.ch/event/1324703/#3-adding-single-electron-non-i). Later we found that the problem is not limited to the new path and affects all electron paths.
One set of example plots are here (left is 13_1_X and right is 13_3_X)
![](https://private-user-images.githubusercontent.com/5052706/270114162-32ae0413-9dd7-415a-955d-3366b3888448.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQxOTIwNTAsIm5iZiI6MTcyNDE5MTc1MCwicGF0aCI6Ii81MDUyNzA2LzI3MDExNDE2Mi0zMmFlMDQxMy05ZGQ3LTQxNWEtOTU1ZC0zMzY2YjM4ODg0NDgucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgyMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MjBUMjIwOTEwWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MjkzY2Q2MjBmYmNmNTkxYmVjMGM2MjNlMWI1YmE4MGY2ZTU3OTVlYThhNWEwYmEyZDIxYjY2MjQ4YzBiNGYyOCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.04ZG2HolGg2lvOQgKVvTPvYyTNTe1Z8kHfYsBOgW4z0)
![](https://private-user-images.githubusercontent.com/5052706/270114366-81fb8641-c7e7-4bda-b783-58a9cbdecb89.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQxOTIwNTAsIm5iZiI6MTcyNDE5MTc1MCwicGF0aCI6Ii81MDUyNzA2LzI3MDExNDM2Ni04MWZiODY0MS1jN2U3LTRiZGEtYjc4My01OGE5Y2JkZWNiODkucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgyMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MjBUMjIwOTEwWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9M2ExNTdjM2RjMmJmMWViM2E4OWNhM2UzMjdiMzNmYjA2ZWMxY2UzZDE3ZGYxNzZiNDY2MTc4ZTZjNDFjNzlmYyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.LHhvaInyd11cjuuxMPi2EULnAYs1IvuVYosiJBISwWo)
Nothing has changed in the pixel matching algorithm or parameters recently, so this is a bit unexpected.
The text was updated successfully, but these errors were encountered: