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
Customization for merging General and Pixel Track Collections in PbPb Reconstruction #14819
Customization for merging General and Pixel Track Collections in PbPb Reconstruction #14819
Conversation
A new Pull Request was created by @abaty for CMSSW_7_5_X. It involves the following packages: RecoHI/Configuration @cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are list here #13028 |
The tests are being triggered in jenkins. |
Dear @slava77 , we would like to have a release to re-reco last year's PbPb data including pixel tracks. |
On 6/8/16 7:51 AM, Quan Wang wrote:
when?
Do you expect any more changes needed for this release?
|
@abaty Is there any reason not to add this to the frontier release (81X)? Or is this the first and last time we will ever run pixel tracking? What is the expected impact on downstream products such as muons and particle flow? |
In the future I believe we might promote the merged track collection the default track reconstruction for HI, but this needs more discussion in a wider audience I think. We should prepare a PR for the new release in any case. The current customization in this PR implementation should not affect anything downstream, as the building of the HIGeneralTracks collection has not changed at all. The downstream products will still use this collection as input, and then the collection will be dropped at the end of the processing, in favor of keeping the merged collection. In the future if it is decided we want to move towards using the merged collection for everything, we will need to make sure all the downstream stuff picks up the new collection. |
@abaty Making this the default behavior is a separate issue from having this in 81X. I'm somewhat wary of dropping hiGeneralTracks, since other collections will contain references to this collection. Given the very limited scope of this reprocessing (two primary datasets, I've been told), is it really worth dropping the standard track collection, which is being used by many downstream modules? Perhaps @BetterWang can comment for the flow group. |
If you are strongly against dropping this collection for now then I think we can keep it; we were trying to limit the amount of disk space used. As you said since this is a limited reprocessing then the extra space hopefully won't be a huge issue for now. |
Hi @abaty @mandrenguyen @CesarBernardes , |
@BetterWang That's not what was proposed to me by the HI conveners. I would suggest a clear plan that includes an estimate of the resources required be presented at the PAG meeting. I find it hard to believe that the other sub-group leaders will/have signed off on a reprocessing of the entire dataset without storing the standard track collection, which will almost certainly crash our standard ntuples (hiForest). |
Pull request #14819 was updated. @cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please check and sign again. |
@cmsbuild please test |
The tests are being triggered in jenkins. |
Testing in progress... |
@abaty: It appears the instructions for running the test config are wrong. The customise argument is given as:
but this causes an error because there is no file called
Are the instructions incorrect, or does the file in this PR have the wrong name? |
@cvuosalo The documentation was out dated. |
+1 Adding customization for merging General and Pixel Track Collections in PbPb reco. There should be no change in standard workflows since this PR adds a new config that is not used by default. The code changes are satisfactory, and Jenkins tests against baseline CMSSW_7_5_X_2016-06-12-0000 show no significant differences, as expected, though there are a few spurious differences in the validation plots. The following test exercised the new config with 10 events against baseline CMSSW_7_5_8_patch4:
The collections added by this PR increase Reco event content by about 7%:
CPU time increases by about 11%.
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_5_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_7_6_X is complete. This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @Degano, @smuzaffar |
+1 |
This PR adds a customization that merges tracks from the HIGeneralTracks and HIConformalPixelTracks collections into a single merged collection, which will be needed in a future reReco. This customization drastically improves the tracking efficiency and fake rate at pt's less than 2 GeV, and will significantly enhance physics capabilities in HI events at low pt.
The customization can be checked running a config generated with the command below over RAW data from the 2015 PbPb run. Note that with this customization the previously used HIGeneralTracks collection is dropped and replaced with a MergedCollection in the final event content.
cmsDriver.py step2 --process RECO --repacked --conditions 75X_dataRun2_PromptHI_v3 --scenario HeavyIons -s RAW2DIGI,L1Reco,RECO --datatier AOD --customise Configuration/DataProcessing/RecoTLR.customiseRun2CommonHI,RecoHI/Configuration/RecoMergedTrackCollection.customiseAddMergedTrackCollection --data --eventcontent AOD --no_exec
More information regarding the changes in performance can be found in the presentation shown in the HI PAG meeting here:
https://indico.cern.ch/event/507212/contributions/2189474/attachments/1284769/1910223/Pixel_Status_HIN_WEST.pdf
@CesarBernardes