Do not use CSC Bad Chambers list during muon reconstruction

[jhgoh]

CSC Bad chamber list was used in the muon reconstruction by default but this information but using this information is not recommended by the CSC DPG.
Excluding bad chamber may cause unexpected inefficiency if the information is not up to date.

The feature to exclude 'bad' CSCs are turned off by changing the default parameter in cff file.

[cmsbuild]

A new Pull Request was created by @jhgoh (Junghwan John Goh) for CMSSW_7_6_X.

Do not use CSC Bad Chambers list during muon reconstruction

It involves the following packages:

TrackingTools/TrackAssociator

@cmsbuild, @cvuosalo, @slava77 can you please review it and eventually sign? Thanks.
@battibass, @makortel, @abbiendi, @GiacomoSguazzoni, @rovere, @VinInn, @bellan, @istaslis, @gpetruc, @cerati, @trocino, @dgulhan 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]

a change made globally in this file will introduce problems in run1 simulation.
Run-2 specific changes should be added in postLS1 customizations

[slava77]

... maybe we actually add this to Configuration/StandardSequences/python/Reconstruction_Data_cff.py ?
I think it's more appropriate than even doing it just for run2

[jhgoh]

@slava77 includeBadChamber parameter is changed in the PostLS1 customization.

[cmsbuild]

Pull request #11248 was updated. @cmsbuild, @civanch, @mdhildreth can you please check and sign again.

[slava77]

@cmsbuild please test
(the one sent from email client didn't make it )

[cmsbuild]

The tests are being triggered in jenkins.

[cmsbuild]

+1
Tested at: 1f718c5
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-11248/8079/summary.html

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

[cmsbuild]

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

[civanch]

+1
however, the name of the parameter is misleading - these chambers are not "bad", I would change this name

[cmsbuild]

Pull request #11248 was updated. @cmsbuild, @civanch, @mdhildreth can you please check and sign again.

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.

[cmsbuild]

+1
Tested at: ac1f54d
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-11248/8384/summary.html

[cmsbuild]

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

[slava77]

• Looking at jenkins outputs: there are no changes as expected
  • run1 setup is not affected by construction
  • run2 MC has no bad chambers, so nothing to skip before the change
• tested locally in CMSSW_7_6_0_pre5 on 200 events in 251721, 256729, 254790: there is a change in an expected place the number of crossed chambers by the muon increases (1 muon that turned out to be in DoubleEG251721). There is no effect on other monitored quantities
  

[slava77]

"+1" (even though it's not a proper cms-bot signature)

[davidlange6]

+1

[civanch]

+1