Addition of pixel Tracking in HI pp_on_AA_2018 era #24257
Conversation
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-24257/5964 |
|
A new Pull Request was created by @abaty for master. It involves the following packages: Configuration/Eras @perrotta, @cmsbuild, @franzoni, @slava77, @fabiocos, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
Why do we then need a new era? |
|
My understanding is that depending on the final data-taking strategy, there could be a request to only run the pixel tracking on a subset of all the PDs gathered for the HI run in 2018. In order to facilitate running two different sequences on specific PDs, I was told it would be beneficial to keep the pixel tracking as a separate era. Let me know if this is not the case. @slava77 |
|
On 8/9/18 7:03 AM, abaty wrote:
My understanding is that depending on the final data-taking strategy,
there could be a request to only run the pixel tracking on a subset of
all the PDs gathered for the HI run in 2018. In order to facilitate
running two different sequences on specific PDs, I was told it would be
beneficial to keep the pixel tracking as a separate era. Let me know if
this is not the case. @slava77
ok,
from your most recent response it sounds like the statement in the PR
description
"Storing the extra track collection has been estimated to increase the
event content size of AOD by 11%, which is a number the HI PAG is
willing to accept."
is a bit of wishful thinking.
BTW, how does this increment look like for minbias or for something very
central?
|
|
@slava77 Based on the decision at the last HIN PAG meeting, we are indeed willing to add 11% to AOD. Regarding the two eras, this was requested for the minbias datasets, so I suggested to make a separate era. This being said, I don't think it was yet excluded that we just store pixel tracks for all PDs. Let us get clarification at tomorrow's PAG meeting and we can update this PR if necessary. |
|
if we really need this additional scenario for the production/prompt later this year, please also make a relval matrix workflow so that the code can be regularly tested (including this PR). |
|
We recently checked the size increase in b=0 events, and it looks like the number is still 11%. |
| extraHitRPhitolerance = cms.double(0.032), | ||
| maxChi2 = cms.PSet( | ||
| enabled = cms.bool(True), | ||
| pt1 = cms.double(0.7), |
There was a problem hiding this comment.
please drop type specifications for all parameters which already exist.
This is a safer way to protect from parameter name mistakes and will also help in possible parameter migrations.
| ) | ||
|
|
||
| #Pixel tracks | ||
| hiConformalPixelTracksPhase1 = cms.EDProducer("PixelTrackProducer", |
There was a problem hiding this comment.
I think that "Phase1" can be dropped from the producer name.
|
@mandrenguyen |
|
Based on the HI PAG meeting on Friday, the decision was made to move the pixel tracking into the main pp_on_AA_2018 era. To try to mitigate some of the event size increase, we will also slightly bump up the low-pt threshholds of the generalTracks (as these tracks are mostly fake anyways). I'm finishing up some tests on the new setup and should push is soon. |
|
The code-checks are being triggered in jenkins. |
|
I've moved the changes in this PR back into the main pp_on_AA_2018 era, as discussed in my previous comment. The pt threshholds for the low pt steps have been raised from 0.3 to 0.49 GeV as well. This reduces the number of tracks under 0.5 GeV stored, reducing the extra event content added to AOD in this PR from 11% down to around 7%. RECO now also runs slightly faster because of the timing saved in the low-pt step. I've also made changes addressing comments from Slava's code review. |
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-24257/6028 |
|
@cmsbuild please test workflow 158.0 |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
|
Here are some observations to go with the PR Using 230 minbias events after the filter "3000":
particle flow follows with a drop at very low pt and some increase up to 1.5 GeV, from the later iterations; overall 12% fewer charged candidates the pixel tracks show up as expected. There are about 5K tracks per event (only about 20% less than in the generalTracks collection) CPU use decreased by about 2%:
The event size is up by about 7.5% in AODSIM output
Memory peak in a production-like job with 8 threads increased by 1 GB (from 15 GB to 16 GB). This is apparently the cost of adding the pixel tracks, but is perhaps also partly coming from the increase in iterative tracking seeds and candidates for higher iterations. Overall, the results appear to be somewhat as expected. |
|
similar plots for wf 158.0 (200 events):
there is essentially no visible increase in the number of tracks with pt around 1 GeV. Here the fraction of fakes is apparently much smaller. The change in the fake rate can be seen from the MTV plots:
|
|
+1
|
|
+1 |
|
merge |
This PR creates a new era which is a copy of Run2_2018_pp_on_AA, and adds a pixel tracking sequence to the reconstruction. This pixel tracking sequence has been requested to meet physics goals requiring low-pt tracks with a higher purity than what is achievable with full tracks. The additional pixel tracking modules have been found to have a negligible impact on the total timing. Storing the extra track collection has been estimated to increase the event content size of AOD by 11%, which is a number the HI PAG is willing to accept. Details of the pixel tracking performance in MB HI events can be found at [1].
The PR can be tested with the normal pp_on_AA_2018 cmsDriver command with the era changed to the 'Run2_2018_pp_on_AA_wPixelTrk'.
[1] https://indico.cern.ch/event/749011/contributions/3098671/attachments/1698408/2736177/pixelUpdate_20180727.pdf
@mandrenguyen