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
Second part of the migration to era for phase2 tracking #15417
Second part of the migration to era for phase2 tracking #15417
Conversation
moving inactivePixelDetectorLabels to era Trying to move siPixelCluster.src but gives changes.. Moving ClusterShapeHitFilterESProducer.PixelShapeFile to era Moving MeasurementTrackerEvent and preDuplicateMergingDisplaced to era moving phase2ITPixelClusters to eras and first attempt for the EventContent moving to era recoFromSimDigis_cff.py and globalreco_tracking
…anges (as has been done for phase1)
moving regional cosmics fixing MissCalibrate
A new Pull Request was created by @ebrondol for CMSSW_8_1_X. It involves the following packages: Configuration/StandardSequences @civanch, @Dr15Jones, @cvuosalo, @ianna, @mdhildreth, @cmsbuild, @franzoni, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are list here #13028 |
@cmsbuild please test |
The tests are being triggered in jenkins. |
@kpedro88 do you think this will have conflict with #15393? |
@ebrondol there are no modified files in common between this and #15393, so there shouldn't be any conflict there. As for #15075, there are a lot of edits in the phase2Tk*.py files. Sometimes the diff is too complicated for git to figure out there isn't an actual conflict, in which case a rebase would still be required. |
The tests are being triggered in jenkins. |
Jenkins tests and extended tests of workflows 10424.0_TTbar_13+TTbar_13TeV_TuneCUETP8M1_2023D1 and 10824.0_TTbar_13+TTbar_13TeV_TuneCUETP8M1_2023D2 with 30 events each against baseline CMSSW_8_1_X_2016-08-11-2300 show no significant differences in monitored quantities. The PR does cause a very slight change in the number of messages logged. |
@cvuosalo thanks for the report, can you please copy one of the error message? |
The extended tests described above show a change in the modules running. The following modules have been added: CastorTowerReco One module was removed: PixelLayerTriplets |
@ebrondol: I can't find any difference in the error messages. It could be that the additional modules change the timing and slightly change the diagnostic logs. |
@ebrondol: You say in the PR description, "No difference is expected with the baseline." However, this PR adds and removes running modules. How can you change which modules are running and yet produce no differences? |
@cvuosalo Ah, ok, so I think I misunderstood your comment "The PR does cause a very slight change in the number of error messages logged.". Is it referred to other Log messages and not LogError? About the second question, on the tracking point of view, the modules that have been changed are, for example: PixelLayerTriplets -> PixelLayerTripletsPreSplitting. If they are set in the correct way, those modifications should not produce any changes in the reco. @makortel can confirm. |
@ebrondol: The only evidence for changes in logging are in the validation plots. I don't think they are significant. |
+1 Completing era migration for Phase 2 tracking. There should be no change in monitored quantities. The code changes are satisfactory, and Jenkins tests against baseline CMSSW_8_1_X_2016-08-12-1100 show no significant differences, as expected. Extended tests as described above also show no significant differences. Changes in running modules as discussed above are desired and correct. |
+1 |
This PR is a continuation of the PR #15183 .
The entire
customise_Reco
method as been migrated to era for both tilted and flat geometry.Mostly of the migration has been done following the Phase1 migration.
No difference is expected with the baseline, here the comparison for flat and tilted using the MTV. No difference is also expected for phase0/1 iterative tracking.
Thanks to @makortel for the precious help (again and again!).
Informing @VinInn @rovere @delaere @boudoul @kpedro88