New track algorithm names for HI muon RegIt

[echapon]

This PR involves the following small adjustments concerning regional iterative tracking (RegIt) for heavy ion muons:

• Define new track algorithms in reco::TrackBase for the steps involved in HI muon RegIt. Among other things, this allows to fully follow the history of each track.
• The "high purity" selectors for HI muon RegIt steps now set the highPurity flag to the tracks they find. Since this was not the case before (only "loose" or "tight" qualities were set), tracks found both by standard HI tracking and by HI muon RegIt "lost" their highPurity flag, thus effectively slightly biasing down the tracking efficiency close to muons.
• The "tight" and "high purity" selectors for HI muon RegIt steps now inherit from the HI default selectors, not the pp ones, so that the selection of these qualities is more consistent. The "loose" selectors still inherit from pp, so as to be more permissive.

This PR is not expected to significantly change the reconstruction, except a tiny (sub-percent) increase of charged PF multiplicity in some events with high muon multiplicity.

[cmsbuild]

A new Pull Request was created by @echapon (Emilien Chapon) for CMSSW_7_6_X.

New track algorithm names for HI muon RegIt

It involves the following packages:

DataFormats/TrackReco
RecoHI/HiMuonAlgos

@cmsbuild, @cvuosalo, @slava77 can you please review it and eventually sign? Thanks.
@makortel, @MiheeJo, @jazzitup, @VinInn, @richard-cms, @yenjie, @kurtejung, @gpetruc, @istaslis, @mandrenguyen, @dgulhan, @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.

[istaslis]

It needs also similar MVA selection for tight and highPurity as used in original HI tracking. In that case tracks will have uniform quality based on the reconstruction (primary, detached, pixelpair) rather then origin (initial or muon-regional).

[echapon]

ha, right. Let me make this change.

[cmsbuild]

Pull request #10653 was updated. @cmsbuild, @cvuosalo, @slava77 can you please check and sign again.

[slava77]

@VinInn @rovere Please confirm that the changes in the tracking DF are OK for you.

[slava77]

@cmsbuild please test

@echapon Please clarify if this will need to be backported to 75X

[VinInn]

I do not know what "algoSize = 46" will cause to algomask... (schema evolution needed???)
for sure HI people will need to use to_ullong() to access their bits...

[cmsbuild]

The tests are being triggered in jenkins.

[VinInn]

what happened to version 16?
self answer: ROOT5 version (sic)

[istaslis]

Selectors have to be cloned from RecoHI.HiTracking.hiMultiTrackSelector_cfi.hiMultiTrackSelector object. PR will be updated.

[echapon]

@slava77 yes I need to create a 75X PR too.

Also, unfortunately @istaslis told me my last commit was not enough for the MVA selection to work :( sorry about that... May I commit the missing stuff? I'll double check with him this time...

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.

[cmsbuild]

Pull request #10653 was updated. @cmsbuild, @cvuosalo, @slava77 can you please check and sign again.

[cmsbuild]

+1
Tested at: a5518d4
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-10653/7616/summary.html

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-10653/7616/summary.html

[cvuosalo]

Extended tests on 140.53 are in progress, but Jenkins shows no problem with additional dimuons. The other small changes still show up in the Jenkins DQM results:

[echapon]

Yes, I would say these small changes look fine.

[slava77]

Is that dimuonHistograms InvMass plot now identical?

On 8/25/15 4:10 PM, Carl Vuosalo wrote:

Extended tests on 140.53 are in progress, but Jenkins shows no problem
with additional dimuons. The other small changes still show up in the
Jenkins DQM results:

jetpu
https://cloud.githubusercontent.com/assets/5736159/9479566/88c0ca80-4b43-11e5-8d0c-e13cda728ff5.png

ratiojetpt
https://cloud.githubusercontent.com/assets/5736159/9479564/88bd1f2a-4b43-11e5-838e-d7ce8d8cc9ee.png
numtracks
https://cloud.githubusercontent.com/assets/5736159/9479565/88bfe0f2-4b43-11e5-947f-cff53d8ef978.png

—
Reply to this email directly or view it on GitHub
#10653 (comment).

[echapon]

Yes, this histogram now looks good (I checked directly inside https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-10653/7616/runTheMatrix-results/140.53_RunHI2011+RunHI2011+RECOHID11+HARVESTDHI/DQM_V0001_R000182124__Global__CMSSW_X_Y_Z__RECO.root)

[cvuosalo]

@echapon:
Extra dimuons are still appearing. With 70 events of workflow 140.53 vs. baseline CMSSW_7_6_0_pre3, DQM shows these differences:

For comparison, here are the LM dimuons that only slightly increase by about 1.6%:

[echapon]

Thank you for reporting this issue with the high mass di-tracker muons histogram. I had only looked at the default 20 events, which is why I had missed this.
I had a closer a look, and it turns out that the remaining additional high mass tracker muon pairs come from only two events, each with one high pt muon with the following characteristics:

• not a PF muon
• inner track with 10 tracker hits
• 7 "layers with measurements"
• "loose" track quality
• found by the Regit pixel less step
• 0 pixel hit
• large dxy (|dxy|>2)

Because of the first and last two characteristics, I think that these problematic dimuon pairs will disappear at the analysis level (even assuming we will look at tracker muons, we require at least 1 pixel hit, and requiring a loose dxy cut like |dxy|<1 would kill these muons too). I would therefore say that we can live with these few high pt but poor quality fake muons.

[cvuosalo]

+1

For #10653 a5518d4

Small adjustments for Heavy Ion regional iterative tracking.

The code changes are satisfactory, and Jenkins tests against baseline CMSSW_7_6_X_2015-08-24-1100 show a number of small differences, none significant. An extended test of workflow 140.53 with 70 events against baseline CMSSW_7_6_0_pre3 shows similar differences, plus additional dimuons, but, as discussed above, these differences are acceptable.
This PR does not appreciably increase the event size, and processing time increases by about 1.7%:

Baseline
Max VSIZ 3235.7 on evt 59 ; max RSS 2639.23 on evt 59
Time av 21.664 s/evt   max 102.632 s on evt 59
M1 Time av 21.6781 s/evt   max 102.632 s on evt 59

PR
Max VSIZ 3170.32 on evt 63 ; max RSS 2682.97 on evt 59
Time av 22.039 s/evt   max 103.606 s on evt 59
M1 Time av 22.0683 s/evt   max 103.606 s on evt 59

Another time measure:

Job total:  21.5366 s/ev ==> 21.9076 s/ev
Job total:  21.7374 s/ev ==> 22.1186 s/ev (first event excluded)

Largest apparent source of time increase:

  delta/mean delta/orJob     original                   new       module name
  ---------- ------------     --------                  ----       ------------
  +0.405369      +0.54%       229.74 ms/ev ->       346.55 ms/ev siStripMatchedRecHits

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_6_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

[davidlange6]

+1