Skip to content
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

Use parabolic magnetic field in track final fit and modify min N(hits) condition in track duplicate merge #39578

Merged
merged 4 commits into from Oct 4, 2022

Conversation

mmasciov
Copy link
Contributor

@mmasciov mmasciov commented Oct 3, 2022

PR description:

This PR:
(1) introduces the usage of parabolic magnetic field with corresponding propagator in track final fit, for main tracking iterations;
(2) modifies the condition on min N(hits) in KFFittingSmoother used in track duplicate merge.

(1) allows to reduce track fitting time by ~10%, with no visible change in tracking physics performance.
(2) allows to reduce duplicate rate at low pT and high pseudorapidity.

PR validation:

Please, refer to presentation at Tracking POG on September 12:
https://indico.cern.ch/event/1197539/#2-tracking-final-fit-opportuni
For (1): slides 5-8.
For (2): slides 26-27.

FYI: @mmusich @slava77

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 3, 2022

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-39578/32365

  • This PR adds an extra 20KB to repository

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 3, 2022

A new Pull Request was created by @mmasciov (Mario Masciovecchio) for master.

It involves the following packages:

  • RecoTracker/TrackProducer (reconstruction)
  • TrackingTools/TrackFitters (reconstruction)

@cmsbuild, @mandrenguyen, @clacaputo can you please review it and eventually sign? Thanks.
@VourMa, @felicepantaleo, @abbiendi, @CeliaFernandez, @mmusich, @cericeci, @andrea21z, @JanFSchulte, @jhgoh, @missirol, @HuguesBrun, @trocino, @GiacomoSguazzoni, @rovere, @VinInn, @bellan, @ebrondol, @mtosi, @dgulhan, @Fedespring, @lecriste, @gpetruc this is something you requested to watch as well.
@perrotta, @dpiparo, @rappoccio you are the release manager for this.

cms-bot commands are listed here

@mandrenguyen
Copy link
Contributor

please test

@mmusich
Copy link
Contributor

mmusich commented Oct 3, 2022

would it be worth to enable the profiling for the tests?

@slava77
Copy link
Contributor

slava77 commented Oct 3, 2022

would it be worth to enable the profiling for the tests?

I agree

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 3, 2022

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e7e9f8/27934/summary.html
COMMIT: d975c87
CMSSW: CMSSW_12_6_X_2022-10-02-2300/el8_amd64_gcc10
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/39578/27934/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

@slava77 comparisons for the following workflows were not done due to missing matrix map:

  • /data/cmsbld/jenkins/workspace/compare-root-files-short-matrix/data/PR-e7e9f8/41834.0_TTbar_14TeV+2026D94+TTbar_14TeV_TuneCP5_GenSimHLBeamSpot14+DigiTrigger+RecoGlobal+HARVESTGlobal

Summary:

  • No significant changes to the logs found
  • Reco comparison results: 13834 differences found in the comparisons
  • DQMHistoTests: Total files compared: 49
  • DQMHistoTests: Total histograms compared: 3432650
  • DQMHistoTests: Total failures: 49794
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 3382834
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 48 files compared)
  • Checked 204 log files, 49 edm output root files, 49 DQM output files
  • TriggerResults: no differences found

@slava77
Copy link
Contributor

slava77 commented Oct 3, 2022

enable profiling

@slava77
Copy link
Contributor

slava77 commented Oct 3, 2022

@cmsbuild please test

@slava77
Copy link
Contributor

slava77 commented Oct 3, 2022

Looking at comparisons, I wasn't really expecting changes in refittedStandAloneMuons .
It's not obvious which way it gets pulled in

Somewhat related, I see in RecoMuon/Configuration/python/DisplacedMuonSeededStep_cff.py:muonSeededTracksOutInDisplaced = RecoTracker.TrackProducer.TrackProducer_cfi.TrackProducer.clone(
I wouldn't be sure that the parabolic field will work there.

@mmasciov
I was expecting that the changes are localized to (iterative) tracking.
Some more careful update is likely needed.

@mandrenguyen
Copy link
Contributor

@mmasciov @slava77 Conversion step tracks are affected, which is not explicit in the code changes. Just checking, is that intentional / acceptable?

@clacaputo
Copy link
Contributor

clacaputo commented Oct 4, 2022

From igprof CPU usage comparison

  • 11834.21
    >> Total Cumulative(old->new): 331.84 -> 324.85
  • 136.889
    >> Total Cumulative(old->new): 959.74 -> 955.98
  • 39634.21
    >> Total Cumulative(old->new): 1164.03 -> 1177.86

12_6_0_pre2 for 11834.21
Screenshot 2022-10-04 at 17 24 00

This PR for 11834.21
Screenshot 2022-10-04 at 17 23 49

@slava77
Copy link
Contributor

slava77 commented Oct 4, 2022

@mmasciov @slava77 Conversion step tracks are affected, which is not explicit in the code changes. Just checking, is that intentional / acceptable?

conversionStepTracks are essentially a copy of convStepTracks (after extra quality sels), they come from convTrackCandidates built from photonConvTrajSeedFromSingleLeg , which uses generalTracks in the inputs

@slava77
Copy link
Contributor

slava77 commented Oct 4, 2022

  • 39634.21
    >> Total Cumulative(old->new): 1164.03 -> 1177.86

this is the only case going in the unexpected direction.
Looking at all_OldVSNew_TTbar14TeV2026D88PUwPRMXwf39634p999 (10 events, lower PU, just 50), there is nothing significant.

The TrackProducer time reduces as expected in this PR in this pase-2 wf.

@rappoccio
Copy link
Contributor

@mandrenguyen let us know ASAP if you're okay with this going into pre3, as discussed in ORP today.

@mandrenguyen
Copy link
Contributor

urgent
@rappoccio I'm just taking some more minutes to sort thru the comparisons, but I think I should be able to sign off soon

@cmsbuild cmsbuild added the urgent label Oct 4, 2022
@slava77
Copy link
Contributor

slava77 commented Oct 4, 2022

  • 39634.21
    >> Total Cumulative(old->new): 1164.03 -> 1177.86

this is the only case going in the unexpected direction. Looking at all_OldVSNew_TTbar14TeV2026D88PUwPRMXwf39634p999 (10 events, lower PU, just 50), there is nothing significant.

The TrackProducer time reduces as expected in this PR in this pase-2 wf.

[2    -> 2   ] [5.5    -> 5.6   ]  [96.08     -> 99.22    ]                  PrimaryVertexProducer::produce                    
[9    -> 7   ] [2.1    -> 2.2   ]  [36.88     -> 38.43    ]                  PFDisplacedVertexProducer::produce                
[11   -> 11  ] [1.7    -> 1.7   ]  [28.87     -> 30.26    ]                  TemplatedVertexArbitrator<edm::View<reco::Candidate...
[12   -> 10  ] [1.5    -> 1.8   ]  [27.05     -> 32.17    ]                 TrackstersProducer::produce     
[13   -> 12  ] [1.4    -> 1.5   ]  [24.57     -> 26.79    ]                  PFClusterProducer::produce                                          

PV is stochastic, perhaps a few tracks changing triggered a slowly converging case.
If there are per-event details ( timeMemoryInfo), it would be possible to check if it's a single event. I don't see timememoryinfo.log for step3/4 in https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e7e9f8/27963/profiling/39634.21/ (why?)

The TICL-related part seems to be similar in size of increase as the vertex; not obvious if PV feeds the TICL change though.

@mandrenguyen
Copy link
Contributor

+reconstruction
Expected improvement to CPU timing of TrackProducer is observed in profiling.
Changes to track distribution and downstream objects like PF candidates are at noise level.
The slight increase of timing in the Phase 2 workflow is a bit concerning, but could by just related to fluctuations in the vertexing. This increase is anyway rather small compared to recent changes to the Phase 2 reco.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 4, 2022

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, @rappoccio (and backports should be raised in the release meeting by the corresponding L2)

@rappoccio
Copy link
Contributor

+1

@rappoccio rappoccio merged commit 5bacac1 into cms-sw:master Oct 4, 2022
Comment on lines +5 to +7
useSimpleMF = cms.bool(True),
SimpleMagneticField = cms.string("ParabolicMf"),
Propagator = cms.string('PropagatorWithMaterialParabolicMf'),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use safer syntax (for a possible update)

@@ -65,7 +65,7 @@ namespace {
desc.add<int>("MaxNumberOfOutliers", 3);
desc.add<int>("MinDof", 2);
desc.add<bool>("NoOutliersBeginEnd", false);
desc.add<int>("MinNumberOfHits", 5);
desc.add<int>("MinNumberOfHits", 3);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it looks like this is cloned all over the place, like GsfElectronFittingSmoother or KFFittingSmootheForSTA, which all could trigger an increase in fakes (unless the number of hits 5->3 is shadowed by a tighter cut somewhere else).

It would be better to change this only in the iter tracking context.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, a bugfix is quite likely needed now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, a bugfix is quite likely needed now.

Yes!
Please @slava77 @mmasciov provide that fix
Please @rappoccio wait for that fix before proceeding with building the pre-release!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@slava77, @perrotta, @rappoccio: PR #39611 now only applies this change to RKFittingSmoother, without affecting GsfElectronFittingSmoother or KFFittingSmootheForSTA.

@mmusich
Copy link
Contributor

mmusich commented Oct 4, 2022

I have the impression the merge of this PR was unduly rushed.
Can the proponents clarify the hurry?

@slava77
Copy link
Contributor

slava77 commented Oct 4, 2022

I have the impression the merge of this PR was unduly rushed. Can the proponents clarify the hurry?

pre3 release.

How would a not rushed path look like?
(considering that I brought this up in the ORP, the signoff by POG may be outside of reco/ORP understanding)

@mmusich
Copy link
Contributor

mmusich commented Oct 4, 2022

pre3 release

please clarify why it was needed for pre3.

How would a not rushed path look like?

e.g. understanding in detail the large deal of differences seen in tests. 1 day for a PR review looks very rushed by normal reconstruction integration trajectories.

@slava77
Copy link
Contributor

slava77 commented Oct 4, 2022

pre3 release

please clarify why it was needed for pre3.

relvals. fewer features per pre-release is better.

@mmusich
Copy link
Contributor

mmusich commented Oct 4, 2022

relvals. fewer features per pre-release is better.

Good to know. Let's apply the same principle everywhere.

@mmusich
Copy link
Contributor

mmusich commented Oct 4, 2022

type tracking, performance-improvements

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants