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
Quadruplet seeding by propagating triplet to 4th layer #13753
Conversation
334a641
to
244c235
Compare
A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_8_1_X. It involves the following packages: Calibration/IsolatedParticles @perrotta, @cmsbuild, @diguida, @cvuosalo, @fwyzard, @cerminar, @Martin-Grunewald, @franzoni, @slava77, @mmusich, @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. |
-1 ^ /cvmfs/cms-ib.cern.ch/week0/slc6_amd64_gcc530/cms/cmssw-patch/CMSSW_8_1_X_2016-03-16-2300/src/FWCore/Framework/interface/one/EDAnalyzerBase.h:98:20: note: overridden virtual function is here virtual void beginJob() {} ^ >> Compiling edm plugin /build/cmsbuild/jenkins-workarea/workspace/ib-any-integration/CMSSW_8_1_X_2016-03-16-2300/src/RecoPixelVertexing/PixelTriplets/plugins/SealModule.cc /build/cmsbuild/jenkins-workarea/workspace/ib-any-integration/CMSSW_8_1_X_2016-03-16-2300/src/RecoPixelVertexing/PixelTriplets/plugins/PixelQuadrupletGenerator.cc:66:46: error: variable length array of non-POD element type 'ThirdHitRZPrediction' ThirdHitRZPrediction preds[size]; ^ /build/cmsbuild/jenkins-workarea/workspace/ib-any-integration/CMSSW_8_1_X_2016-03-16-2300/src/RecoPixelVertexing/PixelTriplets/plugins/PixelQuadrupletGenerator.cc:112:21: error: constexpr variable 'nSigmaRZ' must be initialized by a constant expression constexpr float nSigmaRZ = std::sqrt(12.f); ^ ~~~~~~~~~~~~~~~ you can see the results of the tests here: |
Some modernizations were missing, should be fixed now. |
@cmsbuild please test |
The tests are being triggered in jenkins. |
An extended test of workflow 10224.0_TTbar_13 (which is a 2017 workflow) with the algorithm enabled (as explained in the description) and with 70 events against baseline CMSSW_8_1_X_2016-03-10-2300 with the algorithm disabled shows no significant increase in time or memory usage. Note these tests included both the DQM and Validation steps.
The time for various tracking steps increased or decreased, but the overall time showed a slight decrease (times exclude first event):
Another measurement gives a similar picture:
|
The same extended test described above produces extensive differences in tracking quantities, as might be expected. However, most all of the changes preserve the shapes of distributions even while possibly changing the number of histogram entries. But at least two DQM plots show significant shape changes: |
The same extended test described above shows a 2% decrease in the size of RECO event content. The largest changes are:
|
@cvuosalo what are the totals of time changes in the reco steps/tracking steps? 10% is a large difference (maybe that fits the "slight decrease" in your summary). Is the DQM comparison appropriately normalized? There is a ~40% discrepancy. |
@slava77:
The module time difference is:
Note that the DQM/Validation step was included in these workflows. Concerning the DQM comparison, many of the plots have similar numbers of entries and similar shapes. I presented two plots where neither the number of entries nor the shapes match. |
On 3/22/16 4:00 PM, Carl Vuosalo wrote:
this includes mixing module and validation in the job and, because of
This is a sum for modules with differences (>5% for heavier or >10% for
|
@slava77:
|
On 3/22/16 4:15 PM, Carl Vuosalo wrote:
Thank you. So, it is indeed about 10% decrease.
|
+1 Adding quadruplet seeding using the new fourth layer of the 2017 pixel tracker. There should be no changes in standard workflows. The code changes are satisfactory, and Jenkins tests against baseline CMSSW_8_1_X_2016-03-21-1100 show no significant differences, as expected. An extended test of workflow 10224.0_TTbar_13 (which is a 2017 workflow) with 70 events against baseline CMSSW_8_1_X_2016-03-10-2300 also show no significant differences with the new algorithm disabled. Test results with the new algorithm are discussed above, and they are satisfactory. |
@slava77 Indeed this version suffers from efficiency loss at low pT. One symptom is migration of tracks from quadrupled steps to triplet steps (best visible in lowPt*Step plots e.g. in @cvuosalo's comment #13753 (comment)). I'm experimenting ways to recover the low-pT efficiency. |
+1 |
@Martin-Grunewald @perrotta we need your signature here |
+1 |
This pull request is fully signed and it will be integrated in one of the next CMSSW_8_1_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @Degano, @smuzaffar |
+1 |
This PR adds code for the first prototype of quadruplet seeding by "propagating triplet to 4th layer and searching for compatible hits", discussed in TRK POG meetings March 14 https://indico.cern.ch/event/508493/contribution/3/attachments/1242946/1828945/slides.pdf and Feb 23 2015 https://indico.cern.ch/event/361404/contribution/3/attachments/719405/987513/slides.pdf. The algorithm is disabled by default, but a customize
--customise RecoTracker/Configuration/customiseForQuadrupletsByPropagation.customiseForQuadrupletsByPropagation
switching all triplet-merging cases to propagation in PixelTrackProducer and in seeding.Although being still work in progress and disabled by default, integrating the code eases its maintenance and testing by other people.
Tested in 8_0_1_pre1, no changes expected in standard workflows.
I have here two sets of MTV plots (with 1000 TTbar+PU events in CMSSW_8_1_X_2016-03-15-1100)
@rovere @VinInn