modify L2MuonSeedGeneratorFromL1T to deal with possible L1 zero charge

[sarafiorendi]

The code has been modified to associate offlineSeeds and L1 by comparing them without trajectory propagation to compatible detector layers if the charge of the L1 object is invalid or == 0.
Propagation for objects with zero charge would otherwise cause inefficiencies in the L2 muon seed generation.
Also, the possibility to define the matching cone in different eta bins is introduced.

[cmsbuild]

A new Pull Request was created by @sarafiorendi for CMSSW_8_1_X.

It involves the following packages:

RecoMuon/L2MuonSeedGenerator

@cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please review it and eventually sign? Thanks.
@battibass, @abbiendi, @jhgoh, @bellan, @trocino, @bachtis, @rociovilar this is something you requested to watch as well.
@slava77, @Degano, @smuzaffar you are the release manager for this.

cms-bot commands are list here #13028

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/12476/console

[cmsbuild]

+1
Tested at: d8d6ffb
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-14135/12476/summary.html

[Martin-Grunewald]

@davidlange6
OK, put in if possible

[cmsbuild]

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

[cvuosalo]

@sarafiorendi: Could you please provide instructions for testing this change so that I can verify that invalid L1 objects are properly handled?
Thanks.

[sarafiorendi]

@cvuosalo: you can produce some relvals[1] w/ and w/o this PR.
You need to have merged this other PR before to read Stage2 L1 objects in the validation plots.

[1]
cmsDriver.py step2 --conditions auto:run2_mc -s DIGI:pdigi_valid,L1,DIGI2RAW,HLT:@relval2016 --datatier GEN-SIM-DIGI-RAW-HLTDEBUG -n 10 --era Run2_2016 --eventcontent FEVTDEBUGHLT n=10 --filein root://xrootd.unl.edu//store/relval/CMSSW_8_1_0_pre2/RelValZMM_13/GEN-SIM/80X_mcRun2_asymptotic_v10_gs810pre2-v1/00000/1628A30E-D0FD-E511-AD71-0CC47A4D762E.root --fileout file:step2.root > step2_ZMM_13+ZMM_13+DIGIUP15+RECOUP15+HARVESTUP15.log

cmsDriver.py step3 --runUnscheduled --conditions auto:run2_mc -s RAW2DIGI,L1Reco,RECO,EI,PAT,VALIDATION:@standardValidation+@miniAODValidation,DQM:@standardDQM+@miniAODDQM --datatier GEN-SIM-RECO,MINIAODSIM,DQMIO -n 10 --era Run2_2016 --eventcontent RECOSIM,MINIAODSIM,DQM n=10 --filein file:step2.root --fileout file:step3.root > step3_ZMM_13+ZMM_13+DIGIUP15+RECOUP15+HARVESTUP15.log

cmsDriver.py step4 --filetype DQM --conditions auto:run2_mc --mc -s HARVESTING:@standardValidation+@standardDQM+@miniAODValidation+@miniAODDQM --era Run2_2016 n=10 -n 100 --filein file:step3_inDQM.root --fileout file:step4.root > step4_ZMM_13+ZMM_13+DIGIUP15+RECOUP15+HARVESTUP15.log

[perrotta]

@cvuosalo : what about the results of your tests? If there are no issues, could you please sign?
Thank you, A.

[cvuosalo]

@sarafiorendi, @perrotta: There are issues. Jenkins tests between this PR and #14136, the 80X version, have inconsistent results. For workflow 1330 (ZMM) there are 2526 DQM plots with non-spurious differences in this PR versus 4033 DQM plots with differences in #14136. Also, DQM plots for wf 25202 (ttbar) show no significant differences for this PR while showing 730 DQM plots with non-spurious differences in #14136. These differences are all related to HLT, but I don't know how to account for such dramatic inconsistencies between these two PRs which naively should be the same.

Have there been some big changes in HLT DQM between 80X and 81X that would account for thousands of difference plots disappearing from 80X to 81X?

[cvuosalo]

A test as described above using RelValZMM_13 shows the improved HLT efficiencies as intended by this PR and no other problems. An example of the efficiency improvement:

[cvuosalo]

+1

For #14135 d8d6ffb

Corrected handling of invalid or zero L1 objects in L2MuonSeedGeneratorFromL1T.

#14136 is the 80X version of this PR.

The code changes are satisfactory. Jenkins tests against baseline CMSSW_8_1_X_2016-04-19-1100 show no significant differences, except for workflow 1330.0_ZMM_13, where the DQM plots show numerous small HLT-related changes expected for this PR. An additional test of RelValZMM_13 as described above with #14146 included against baseline CMSSW_8_1_0_pre3 shows the HLT efficiency improvement shown above and no other problems.

The additional DQM differences observed for #14136 are explained by the fact that in 80X L1 muon objects have the L1 charge problem in the overlap and endcap regions, while in 81X this problem only occurs in the overlap region.

[cmsbuild]

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