EmDQM HLT validation FastSim fix

[thomreis]

Hard coded genParticles process name resulted in empty histograms in FastSim after the consumes migration in 7_0_0_pre10.

This affects all Egamma HLT FastSim Relval starting from 7_0_0_pre10.

[cmsbuild]

A new Pull Request was created by @thomreis (Thomas Reis) for CMSSW_7_2_X.

EmDQM HLT validation FastSim fix

It involves the following packages:

HLTriggerOffline/Egamma

@nclopezo, @danduggan, @rovere, @cmsbuild, @deguio, @ojeda can you please review it and eventually sign? Thanks.
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.
@nclopezo you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[deguio]

@thomreis please submit for 73 also.
thanks,
F.

[thomreis]

@deguio you mean a new pull request for 73?
Looks like I have to resolve some conflicts then.

[deguio]

just want to make sure that this change doesn't get lost in 72 and it is ported to the dev branch as well.
another PR with the same change to line:
https://github.com/cms-sw/cmssw/blob/CMSSW_7_3_X/HLTriggerOffline/Egamma/src/EmDQM.cc#L48

is needed. you shouldn't find conflicts.
thanks,
F.

[thomreis]

OK I have made a new PR #5868 for 73 with the same changes.
Is this change also going to be in future patch releases of 72? Otherwise we cannot do the FastSim validation for Egamma HLT paths.

[deguio]

+1
yes, as soon as it is merged, this change will be part of the next 72 releases

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes or unless it breaks tests. @nclopezo can you please take care of it?

[cmsbuild]

-1
Tested at: 37aea8a
When I ran the RelVals I found an error in the following worklfows:
4.53 step2

runTheMatrix-results/4.53_RunPhoton2012B+RunPhoton2012B+HLTD+RECODreHLT+HARVESTDreHLT/step2_RunPhoton2012B+RunPhoton2012B+HLTD+RECODreHLT+HARVESTDreHLT.log
----- Begin Fatal Exception 17-Oct-2014 11:34:53 CEST-----------------------
An exception of category 'InvalidInput' occurred while
   [0] Processing run: 194533 lumi: 329 event: 461582793
   [1] Running path 'HLT_PFJet40_v1'
   [2] Calling event method for module PFJetCorrectionProducer/'hltAK4PFJetsCorrected'
   [3] Using EventSetup component JetCorrectionESChain/'hltESPAK4PFCorrection' to make data JetCorrector/'hltESPAK4PFCorrection' in record JetCorrectionsRecord
   [4] Using EventSetup component LXXXCorrectionESProducer/'hltESPAK4PFAbsoluteCorrectionESProducer' to make data JetCorrector/'hltESPAK4PFAbsoluteCorrectionESProducer' in record JetCorrectionsRecord
Exception Message:
 cannot find key 2 in the JEC payload, this usually means you have to change the global tag
----- End Fatal Exception -------------------------------------------------

you can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5859/112/summary.html

[davidlange6]

@cmsbuild - could you rerun the tests

[cmsbuild]

+1
Tested at: 37aea8a
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5859/246/summary.html

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes (tests are also fine). @nclopezo can you please take care of it?

[cmsbuild]

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

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes (tests are also fine). @nclopezo can you please take care of it?

[davidlange6]

perhaps going back to the pre getbytoken design of having this InputTag as part of the PSet would be a more robust long term solution?

[thomreis]

I consiered an InputTag but then decided to go back to the similar version as before the getbytoken, which was also hardcoded, so that the configuration stays the same.
But I agree that using an inputTag is nicer.