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
expand tracker-driven coverage for electron seeds; jetCore mitigation #35892
expand tracker-driven coverage for electron seeds; jetCore mitigation #35892
Conversation
@cms-sw/egamma-pog-l2 @cms-sw/tracking-pog-l2 |
enable profiling |
} | ||
if (hitShared == (hitSeed - 1)) { | ||
NewSeed.setCtfTrack(TSeed[it].ctfTrack()); | ||
newSeed.setCtfTrack(tSeed.ctfTrack()); | ||
} else if (hitShared > 0 && !newSeed.isTrackerDriven()) { |
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.
to reduce the number of times the loop over the full track hits is used, I'm requiring here a partial match with at least one hit from the seed.
This will not help for deepCore when it gets enabled
IIUC, the deepCore seeds have no hits and this part will block the option to match to the track hits. But perhaps for this case the solution would be to actually fill the hits for deepCore
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.
here, can we add in ||
something like if (newSeed.nHits() == 0)
so that deepCore will also pass this condition and enter the following loop. So, if the seed has no hit then this partial match of at least 1 hit is not required. Will that be okay?
@smuzaffar |
This is now apparently targeted for 12.2.x. I just want to check if that's fine for POG/PAG sample production view, the schedule changed so many times, I lost track of what is the plan. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-35892/26294
|
A new Pull Request was created by @slava77 (Slava Krutelyov) 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 will be one open pre-release in 12_2. |
@cmsbuild please test |
Ciao @mmusich The name of the releases changed, in fact, but the actual schedule from the point of view of the developers did not actually moved significantly from what was decided some time ago, see https://twiki.cern.ch/twiki/bin/viewauth/CMS/ReleaseSchedule The last open pre-release available for POG developments meant to Run3 is on 2021/11/09: it is now called CMSSW_12_2_0_pre2 instead of CMSSW_12_1_0_preSomething |
here are plots from my validation, |
-1 Failed Tests: RelVals-INPUT RelVals-INPUT
Comparison SummarySummary:
|
I added updates for deepCore. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-35892/26328
|
@cmsbuild please test |
In the PR tests for the previous commit #35892 (comment) (which I expect to be repeated in the latest version) there were some changes in the PF CH vs ele assignments, e.g. in 136.793 DoubleEG2017C (100 events) there is one more electron vs 92 in the baseline (well, there is one more gedGsfElectron there as well; so it's not a pure reassignment inside PF). @cms-sw/pf-l2 @laurenhay @marksan87 |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-4c1245/20152/summary.html Comparison SummarySummary:
|
a link to the TRK POG presentation(s) is added in the PR description |
+reconstruction
|
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
|
…JetCore expand tracker-driven coverage for electron seeds; jetCore mitigation (bp of #35892)
Changes in this PR were motivated to mitigate the situation with tracks reconstructed multiple times, one of them jet core after introduction of mkFit to the non-jetCore iterations. Such tracks are more predominantly assigned to jetCore algorithm.
EGM/electron reco has some dependence on this:
originalAlgo
to take into account also the other iteration that may have reconstructed the same trackThis was presented in TRK POG on Nov 1: https://indico.cern.ch/event/1092090/#3-interplay-in-high-pt-electro
Illustrations of the issue:
in pre4 Z'->ee https://tinyurl.com/yfd22fxr the track algorithm is more dominantly the jetCore (starts at 100 GeV)
the reconstructed electron provenance https://tinyurl.com/yg4rfp7c is showing a drop in the tracker-driven electrons { provenance: +1 ecal; -1 tracker; 0 either; +2 ecal-only; -2 tracker-only}
After this PR, on the same sample, only 100 events
default tracking with mkFit (red is new, black is pre4)
even in the CKF tracking (reco with
Run3_noMkFit
) there is a noticeable increase in the tracker-driven categorization and decrease in the ecal-only