add L2L3Residual as know correction level to JetCorrector[Calculator]…

[kirschen]

…; this way, L2L3Residual txt-files can also carry L2L3Residual als correction level in their parametrization

backport of #13949

[cmsbuild]

A new Pull Request was created by @kirschen for CMSSW_8_0_X.

It involves the following packages:

CondFormats/JetMETObjects
JetMETCorrections/Algorithms

@ggovi, @cmsbuild, @davidlange6 can you please review it and eventually sign? Thanks.
@TaiSakuma, @ahinzmann, @mmarionncern, @rappoccio, @jdolen, @nhanvtran, @apfeiffer1, @schoef, @mariadalfonso 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

[mmusich]

please test

[cmsbuild]

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

[cmsbuild]

+1
Tested at: af30d53
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-13951/12201/summary.html

[cmsbuild]

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

[mmusich]

+1

[ggovi]

+1

[gpetruc]

Hello, would you mind explaining a bit more what this PR does? (in particular, does it affect production in any way?)

[kirschen]

Hi Giovanni,

short answer: no, it is [almost] just cosmetics ;)
The FactorizedJetCorrectorCalculator-code was never updated to accept L2L3Residual as a valid string for a correction level, when parsing the correction-parameters.

This leads to the unpractical situation that ever since the addition of L2L3Residual corrections in 2010, the txt-files carry "L2Relative" as dummy in the header line (see e.g. https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/CondFormats/JetMETObjects/data/Jec10V1_L2L3Residual_AK5PF.txt for one of the first "L2L3Residual" files). This is in contrast to all other previously existing correction levels where txt-file name and "correction level" match and is just inconsistent.

The definition of the "correction level" has almost zero impact, the only place I am aware of is a check that enforces that L4EMF (not used anyway) is only applied to CaloJets (https://github.com/kirschen/cmssw/blob/CMSSW_8_0_X_makeL2L3ResidualKnownToJetCorrector/JetMETCorrections/Algorithms/src/LXXXCorrector.cc#L74).

The only practical change is that new L2L3Residuals can (but don't have to) carry "L2L3Residual" as correction level in their definition. Old behaviour is preserved.

Cheers,
Henning

P.S.: The reason why to get rid of this inconsistency ~now is that a payload with "L2L3Residual" in the definition was put into the CondDB for HLT-usage and lead to runtime errors.

[kirschen]

It would be good if you could merge the PR in.
#13949 (81X-version) was merged in a couple of days ago.

[kirschen]

@gpetruc @ggovi @mmusich @davidlange6
Could you merge this in, please?

[davidlange6]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_8_0_X IBs (tests are also fine). This pull request will be automatically merged.