GT updates for 900pre5 with Summer16 JECs, GEM reco geometry and ESEE Intercalib

[arunhep]

Description is updated below.

[cmsbuild]

A new Pull Request was created by @arunhep (Arun Kumar) for CMSSW_9_0_X.

It involves the following packages:

Configuration/AlCa

@ghellwig, @arunhep, @cerminar, @cmsbuild, @franzoni, @mmusich, @davidlange6 can you please review it and eventually sign? Thanks.
@makortel, @Martin-Grunewald, @ghellwig, @tocheng this is something you requested to watch as well.
@davidlange6, @smuzaffar you are the release manager for this.

cms-bot commands are listed here #13028

[arunhep]

please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/18001/console Started: 2017/02/28 11:21

[cmsbuild]

+1
Tested at: 744d514
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-17649/18001/summary.html

[cmsbuild]

Comparison job queued.

[franzoni]

@davidlange6
we would like this considered at the ORP today
we're waiting for the tests to finish to sign it

[cmsbuild]

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

[franzoni]

• GEM RECO geometry --> not expected to yield any change, simply added a record to support future eras which will demand the present of GEM reco geometry

• ESEE Intercalibration --> only affects 2016D, not probed by the short matrix; @cmkuo tested locally [here](https://github.com/cms-sw/cmssw/pull/17219#issuecomment-280834478)

• impact of JEC's update in data 2016B expected and understood, see link and plot
  

• impact of JEC's update in MC not understood.

  • The update is visible in the TTBar with 50ns pileup (plots)
    

  • The update is NOT visible in the TTBar with 25ns pileup (plots)

We'll update this PR when understood.
@schoef @slava77

[franzoni]

We got a larger (x10) statistics for TTBar 2016 with pile up. We confirm the outcome when looking at the profile of the average JEC's applied as a function of eta and pt (red=new GT's, blue=GT's as in the 90x currently - same conventions as the plots of last week):

• in the 50ns we observe differences

• in the 25ns there's no change

• in the 2017 (noPU) there's no change, either

@slava77 @schoef can you give us hints

[slava77]

On 3/6/17 2:29 AM, Giovanni Franzoni wrote: @slava77 <https://github.com/slava77> @schoef <https://github.com/schoef> can you give us hints

I don't have any specific comments based on the posted plots.

[franzoni]

Thanks @slava77
We've gotten feedback form Henning (JetMet) and will update this chat in the next hours with a summary.

[cmsbuild]

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

[franzoni]

• the update being deployed here to JEC's here only involves, for MC, their uncertainties
• as such, no differences are expected on the profiles vs eta/pt of the consumed JEC corrections, which is now the case for the 25ns and 50ns alike (for 2017 it's already been reported earlier) - verified in the relmon plots
• the difference previously noted on the 50ns plots stemmed from the fact that the 2016 startup global tag holds JEC's derived for 50ns; the tags we're deploying here are intended for 25 ns instead, hence we reverted the change to leave in 2016 startup. Now now no changes on the profiles vs eta/pt of the consumed JEC's are visible
• changes in MET, which probers also the JEC errors, proves that there is an effect of deploying the new tags, see:
  
  

Many Thanks to @Kirshen and @schoef

[franzoni]

+1

[cmsbuild]

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

[franzoni]

related to this 80x PR
which needs this PR to be merged/tested to trigger a backport
( Es conditions and code fix among the features needed for the legacy rereco )

[arunhep]

Summary of changes in Global Tags

RunII simulation

• RunII Asymptotic scenario : 90X_mcRun2_asymptotic_v5 as 90X_mcRun2_asymptotic_v4 with the following changes:

  • Summer16 JECs

• RunII Ideal scenario : 90X_mcRun2_design_v5 as 90X_mcRun2_design_v4 with the following changes:

  • Summer16 JECs

• RunII Startup scenario : Not changed. Kept the same GT as previous 90X_mcRun2_startup_v4 with JECs corresponding to 50ns.

RunI data

• RunI HLT processing : 90X_dataRun2_HLT_frozen_v3 as 90X_dataRun2_HLT_frozen_v2 with the following changes:

  • GEM RECO geometry
  • HCAL SiPM Parameter tag update

• RunI Offline processing : 90X_dataRun2_v5 as 90X_dataRun2_v4 with the following changes:

  • Summer16 JECs
  • ESEE Intercalibration mentioned here dead ES regions with correct energy each plane #17219
  • GEM RECO geometry

RunII data

• RunII HLTHI processing : 90X_dataRun2_HLTHI_frozen_v3 as 90X_dataRun2_HLTHI_frozen_v2 with the following changes:

  • GEM RECO geometry
  • HCAL SiPM Parameter tag update

• RunII HLT relval processing : 90X_dataRun2_HLT_relval_v3 as 90X_dataRun2_HLT_relval_v2 with the following changes:

  • GEM RECO geometry
  • HCAL SiPM Parameter tag update

• RunII Offline processing : 90X_dataRun2_v5 as 90X_dataRun2_v4 with the following changes:

  • Summer16 JECs
  • ESEE Intercalibration mentioned here dead ES regions with correct energy each plane #17219
  • GEM RECO geometry

• RunII Offline relval processing : 90X_dataRun2_relval_v5 as 90X_dataRun2_relval_v4 with the following changes:

  • Summer16 JECs
  • ESEE Intercalibration mentioned here dead ES regions with correct energy each plane #17219
  • GEM RECO geometry

• RunII Prompt processing : 90X_dataRun2_PromptLike_v5 as 90X_dataRun2_PromptLike_v4 with the following changes:

  • Summer16 JECs
  • GEM RECO geometry
  • HCAL SiPM Parameter tag update

• RunI HLT processing : 90X_dataRun2_HLT_frozen_v3 as 90X_dataRun2_HLT_frozen_v2 with the following changes:

  • GEM RECO geometry
  • HCAL SiPM Parameter tag update

Upgrade

• PhaseII realistic scenario : 90X_upgrade2023_realistic_v6 as 90X_upgrade2023_realistic_v4 with the following changes:

  • Summer16 JECs

• PhaseI 2017 design scenario : 90X_upgrade2017_design_IdealBS_v16 as 90X_upgrade2017_design_IdealBS_v15 with the following changes:

  • Summer16 JECs

• PhaseI 2017 realistic scenario : 90X_upgrade2017_realistic_v16 as 90X_upgrade2017_realistic_v15 with the following changes:

  • Summer16 JECs

• PhaseI 2018 design scenario : 90X_upgrade2018_design_IdealBS_v13 as 90X_upgrade2018_design_IdealBS_v12 with the following changes:

  • Summer16 JECs

• PhaseI 2018 realistic scenario : 90X_upgrade2018_realistic_v13 as 90X_upgrade2018_realistic_v12 with the following changes:

  • Summer16 JECs

[franzoni]

hello @davidlange6
would it be possible to have this PR merged ?
What should be provide for that to happen ?
( the chages are the same already merged in 91x #17702 )

There are other AlCa changes we want to deploy now. Test would be cleaner and more meaningful if we could have an IB including these changes.

thanks!

[argiro]

Ecal also would be interested in knowing if we can move forward ..

[franzoni]

hello @davidlange6
would it be possible to have this PR merged ?
What should be provide for that to happen ?
( the chages are the same already merged in 91x #17702 )

[franzoni]

hello @davidlange6
would it be possible to have this PR merged ?
What should be provide for that to happen ?
( the changes are the same already merged in 91x #17702 )

[davidlange6]

actually I missed in 91x - why gem reco geometry in run1? Did we not manage to fix the code to understand if there are gems or not?
@ianna

[ianna]

@davidlange6 - it's in 2017 onwards. What makes you think it is in run 1?

[davidlange6]

I read the comments from @arunhep.EG: • RunI Offline processing : 90X_dataRun2_v5 as 90X_dataRun2_v4 with the following changes: • Summer16 JECs • ESEE Intercalibration mentioned here #17219 • GEM RECO geometry

…

On Mar 13, 2017, at 5:09 PM, Ianna Osborne ***@***.***> wrote: @davidlange6 - it's in 2017 onwards. What makes you think it is in run 1? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ianna]

@davidlange6 - It looks like it's the same GT queue for both run 1 and run 2. The tags in data queues have IOVs. @arunhep and @franzoni, please confirm.

[davidlange6]

that indeed makes sense - so what is the IOV for the GEM reco geometry addition? Is it just the comment that is incorrect?

…

On Mar 13, 2017, at 5:45 PM, Ianna Osborne ***@***.***> wrote: @davidlange6 - It looks like it's the same GT queue for both run 1 and run 2. The tags in data queues have IOVs. @arunhep and @franzoni, please confirm. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[arunhep]

@davidlange6 @ianna yes as you mentioned data GTs contain tags with multiple IOVs, but the GEM geometry tag has one only one IOV (1) covering actually whole history. Will this affect the Run-I workflows? Because if version of code relevant for Run-I is not consuming this record then it should not affect anything. @franzoni can you please confirm?

[davidlange6]

lets fix the IOV to match reality in any case...

…

On Mar 13, 2017, at 5:53 PM, Arun Kumar ***@***.***> wrote: @davidlange6 @ianna yes as you mentioned data GTs contain tags with multiple IOVs, but the GEM geometry tag has one only one IOV (1) covering actually whole history. Will this affect the Run-I workflows? Because if version of code relevant for Run-I is not consuming this record then it should not affect anything. @franzoni can you please confirm? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ianna]

@arunhep - standard run 1 code does not consume this record. GEM producer which needs it is enabled from 2017 era onwards.

[franzoni]

hello @ianna @david
the record not being consumed in the run1 standard sequences
won't pose issues to the content / physics performance

We concur, however, that an introducing 2 IOV's is the cleaner solution
Thanks for pointing this out!

@ianna can you provide the tag ~now / today ?
@davidlange6 we'll have to add a commit to both #17886 and #17905 also for other updates - we'll make sure we'll also replace the tag in the data GT to add the IOV. We'll use the same run number we've used for the HCAL phaseI 287446

Cheers and thanks,
@arunhep and Giovanni

[franzoni]

lets fix the IOV to match reality in any case...

addressed here, given that #17886 will supersede this PR