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
Sort pixel tracks in the SoA converter #38065
Conversation
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-38065/30150
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
@silviodonato, Silvio can you please apply code checks so that the integration tests could be started? |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-38065/30154
|
A new Pull Request was created by @silviodonato (Silvio Donato) for master. It involves the following packages:
@jpata, @cmsbuild, @clacaputo, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
enable gpu |
test parameters:
|
please test |
type tracking |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-f3216b/24962/summary.html The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:
You can see more details here: GPU Comparison SummarySummary:
Comparison SummarySummary:
|
as you can see from the logs, this PR adds a flood of:
|
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-f3216b/25107/summary.html GPU Comparison SummarySummary:
Comparison SummarySummary:
|
I'm trying to understand the differences in the HLT outputs from the PR tests (e.g. wfs
Feedback from tracking experts is likely needed (and appreciated). |
I agree this is expected.
the mkFit customization uses the same seeds as the default HLT workflow customizeHLTIter0ToMkFit.py#L44, so the patatrack pixel tracks, but mkFit also performs an internal sorting and cleaning of the seeds, so probably part of what is implemented here is overridden anyway donwstream (@mmasciov)
As far as I understand the standard wf |
Thanks for the info, @mmusich . |
@missirol @mmusich Wf 11634.911 is DD4hep using geometry from XML files. 11634.0 is DD4hep with DB geometry. 11634.914 is DDD with DB geometry. The other 11634 wfs are DD4hep with DB geometry. |
Folks, how do you want to take this forward, and with what timescale? As far as I understand, minor differences in outputs can be expected given a different sorting, but the exact pattern of differences with respect to different geometry implementations is not understood. From the reco side, this is not a blocker. |
+hlt
|
+reconstruction
|
@cms-sw/heterogeneous-l2 Do you have any further comment? Or can you sign this PR? |
+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. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
This PR helps to reduce the CPU-GPU differences. Testing on 10k of events of 900 GeV collisions, the hltAK4PFJets with difference in pt greater than 0.35 GeV passed from 5 to 2.
Moreover, having the pixel tracks sorted by pT helps the CPU-GPU comparison.
PR validation:
I checked on 10k of events that this PR does not change the CPU reconstruction, while it changes 3 jets reconstructed using GPU, reducing the differences from CPU.
CPU3 and GPU3 are after the PR and CPU4 and GPU4 before the PR
Backport:
I will open soon the backport PRs to use this PR in the HLT at P5:
#38067 #38066
cc @cms-sw/hlt-l2 @fwyzard @VinInn