Conversation
72ae121 to
8f4f2fa
Compare
| std::vector<Hit> hits; | ||
| for (unsigned int iHit = 0, nHits = proto.recHitsSize(); iHit < nHits; ++iHit) { | ||
| TrackingRecHitRef refHit = proto.recHit(iHit); | ||
| if (refHit->isValid()) | ||
| hits.push_back((Hit)&(*refHit)); | ||
| } | ||
| sort(hits.begin(), hits.end(), HitLessByRadius()); |
There was a problem hiding this comment.
sorting and invalid hit filtering should probably be configurable and done regardless of removeOTRechits_
There was a problem hiding this comment.
These lines are a direct copy from:
so this part just replicates the behavior from the code below.
Would you like me to test what happens if I don't apply this sorting+filtering?
The only case that this sorting+filtering is not applied is when useProtoTrackKinematics and not removeOTRechits_. But I wouldn't like to change this general behavior, as it will have effects to the Run 3 reconstruction potentially.
There was a problem hiding this comment.
I implied that after my updates removeOTRechits_ can be set to false, then we'd likely want to have the same filtering and sorting still present here
There was a problem hiding this comment.
This is now implemented in 98bb453. Could you take a look and confirm this is how you wanted it?
| if (hits.size() > 2) { | ||
| SeedFromProtoTrack seedFromProtoTrack(config_, proto, SeedingHitSet(hits), es); | ||
| if (seedFromProtoTrack.isValid()) | ||
| (*result).push_back(seedFromProtoTrack.trajectorySeed()); | ||
| } |
There was a problem hiding this comment.
as a part of debugging the efficiency loss: please check if this part ever fails to produce seeds (IIUC the number of pixel hits is still expected to be at least 3, the question is if the SeedFromProtoTrack construction sometimes makes invalid seeds
There was a problem hiding this comment.
I can check this. However, since the part when we switch to this reconstruction is not enabled in this PR now, is it OK if we go ahead we made the PR to cms-sw first and check this in parallel?
8f4f2fa to
73365bd
Compare
|
run-ci: [all, hlt] |
|
The PR was built and ran successfully in standalone mode running on CPU. Here are some of the comparison plots.
The full set of validation and comparison plots can be found here. Here is a timing comparison: |
|
There was a problem while building and running with CMSSW. The logs can be found here. |
|
The PR was built and ran successfully with HLT setup running on CPU (procModifiers = ). Here are some plots. HLT General Plots
The full set of validation and comparison plots can be found here. |
|
run-ci: cmssw |
|
There was a problem while building and running with CMSSW. The logs can be found here. |
|
run-ci: cmssw |
|
The PR was built and ran successfully with CMSSW running on CPU. Here are some plots. OOTB All Tracks
The full set of validation and comparison plots can be found here. |
9b8e9aa to
9b32edd
Compare
|
@slava77 Let me know whether I can push this to CMSSW. |
There was a problem hiding this comment.
(not for this PR, but something to consider for a cleanup of the configs spaghetti , or is it copy-pasta)
I'd import from a reference definition HLTrigger/Configuration/python/HLT_75e33/modules/hltInitialStepTrajectorySeedsLST_cfi.py and clone with just a few changes
There was a problem hiding this comment.
I think this is "against the HLT config conventions", from the point of view that modules need to be explicitly defined or be modified clones of other modules in the same file. I can ask Marco M. at some point whether it would be acceptable though.
|
|
||
| TrajectorySeedCollection seeds; | ||
| seeds.clear(); |
There was a problem hiding this comment.
did this give some speedup?
The seeds are needed only between L249 and L262
Same for the hitsForSeed.
It's a bit harder to read/follow than if it's just in the scope where it's used.
There was a problem hiding this comment.
it may be more clear if seeds.clear(); is called just before it's used/populated
There was a problem hiding this comment.
The speed up from this was negligible. The current implementation changed the lines as close as possible to the previous lines but I can move this line close to 249 to make the logic clearer.
- Add flags for tracking/seeding production - Conditional creation of products - Per-iteration heap allocations moved out of the loop - Remove unnecessary OT hit loop + sort for pLS candidates
9b32edd to
0c81f3f
Compare
|
run-ci: [all, hlt] |
|
The PR was built and ran successfully in standalone mode running on CPU. Here are some of the comparison plots.
The full set of validation and comparison plots can be found here. Here is a timing comparison: |
|
The PR was built and ran successfully with CMSSW running on CPU. Here are some plots. OOTB All Tracks
The full set of validation and comparison plots can be found here. |
|
The PR was built and ran successfully with HLT setup running on CPU (procModifiers = ). Here are some plots. HLT General Plots
The full set of validation and comparison plots can be found here. |
|
@slava77 Is it OK to submit this to CMSSW? |
slava77
left a comment
There was a problem hiding this comment.
Thanks for the update.
It looks to me ready to go upstream/cms-sw
















This PR is fully technical, resulting in the same physics performance (validation plots here) and the following timing reduction (baseline timing vs. PR timing):