Reduced pTmin of pixel pairs from 4 to 1 GeV in HI reco

[mandrenguyen]

Improves efficiency by 5-10% between 1-4 GeV for the HI reco (pp reco unaffected).
Pixel pairs step timing will be longer, as well as modest increase in PF timing.
Total size of track collection will grow, but fake rate for highPurity tracks (which are what enters analysis) is essentially unchanged.

[cmsbuild]

A new Pull Request was created by @mandrenguyen for CMSSW_7_5_X.

Reduced pTmin of pixel pairs from 4 to 1 GeV in HI reco

It involves the following packages:

RecoHI/HiTracking

@cmsbuild, @cvuosalo, @slava77 can you please review it and eventually sign? Thanks.
@echapon, @jazzitup, @dgulhan, @appeltel, @yenjie, @kurtejung, @richard-cms, @yetkinyilmaz this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@Degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.

[slava77]

I'll run our (reco) 100 evt test locally

[cmsbuild]

+1
Tested at: 169cc0a
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-9591/5458/summary.html

The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:
9f68ee0
eb6ebd4
You can see more details here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-9591/5458/git-log-recent-commits
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-9591/5458/git-merge-result

[slava77]

Here are some notes based on comparisons done in CMSSW_7_5_X_2015-06-12-1100 /my test area sign564/

• the CPU and disk output size on disk increase as expected. In 140.53 (run 182124 UPC PD) 100 events:
  • about 20% more CPU spent (from 46 s/evt to 57 s/evt on average; this apparently increases slightly in events with higher track occupancy)
  • 12% larger RECO output
  • 6% larger AOD output (note that the size of the particle flow candidates collection increases only by 1.3% compared to 30% of the increase in hiGeneralTracks. This should probably be tuned on the HI pf reco side.

file size changes for branch size diff of 100 byte or 5%
-------------------------------------------------------------
 or, B       new, B      delta, B   delta, %   deltaJ, %    branch 
-------------------------------------------------------------
    37866 ->       38048        182      0.5   0.01     CaloTowersSorted_PFTowers__reRECO.
     6960 ->        7062        102      1.5   0.01     recoPFJets_akVs3PFJets__reRECO.
   185855 ->      247814      61959     28.6   4.80     recoTracks_hiGeneralTracks__reRECO.
   110037 ->      111464       1427      1.3   0.11     recoPFCandidates_particleFlowTmp__reRECO.
    93904 ->       94806        902      1.0   0.07     recoVoronoiBackgroundedmValueMap_voronoiBackgroundPF__reRECO.
    14620 ->       26482      11862     57.7   0.92     recoMuons_muons__reRECO.
     6665 ->        8790       2125     27.5   0.16     floatedmValueMap_hiGeneralTracks_MVAVals_reRECO.
     8355 ->        8460        104      1.2   0.01     recoPFJets_akVs5PFJets__reRECO.
      621 ->        4380       3758     150.3   0.29     floatedmValueMap_hiPixelPairStepSelector_MVAVals_reRECO.
-------------------------------------------------------------
  1291829 ->     1374363      82534             6.4     ALL BRANCHES

compare to pf candidates (only charged hadrons increase in size)

RECO output shows that the particleFlowBlock increases only by 1.7%. So, this most likely means that the additional tracks are not imported (probably due to the highPurity flag).

Compare this to minbias events (140.0, after the fix in #9487 ):

Does this mean the rate of fakes is higher in data, or is it some kind of trigger bias in the /HIMinBiasUPC/HIRun2011-v1/RAW run=182124

[slava77]

+1

for #9591 169cc0a

• code change is fairly simple and is done as expected
• the number of hiGeneralTracks increases, which is followed by a somewhat smaller increase in downstream objects (PF candidates or muons)
  • behavior in data and MC don't quite match
• CPU increase in data is ~20%, driven by an increase in the number of tracks. Some of the largest increase in times are:

        hiPixelPairTrackCandidates       629.447 ms/ev -> 5630.7 ms/ev
        hiPixelPairGlobalPrimTracks      80.6743 ms/ev -> 753.284 ms/ev
        hiGeneralTracks          614.423 ms/ev -> 1278.28 ms/ev
        muons    1904.09 ms/ev -> 3458.37 ms/ev
        particleFlowTmp          1462.12 ms/ev -> 1582.08 ms/ev

[cmsbuild]

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). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

[davidlange6]

+1