Optional use of Max-Sample algorithm for gain-switch cases

[emanueledimarco]

Related to 80X PR #17259, it includes the optional usage of the max-sample in EB or EE,
to remove the effect of the slew-rate limitation of the electronics in the ECAL amplifier,
in case of gain switch of it.

Further studies are needed to choose between this and option 4. of PR #17205.

This solution is already validated on 2016 data ( slewRateFix ).
In MC the slew-rate limitation is not simulated. Anyway we checked that the response is
close to the multifit one (presentation), and it is the Run1 algorithm for very high energy pulses.

For HLT this will make a negligible difference wrt to what we had in 2016, in terms of rates and CPU time.

@amassiro @lgray @bendavid @shervin86

[cmsbuild]

A new Pull Request was created by @emanueledimarco (Emanuele Di Marco) for CMSSW_9_0_X.

It involves the following packages:

RecoLocalCalo/EcalRecAlgos
RecoLocalCalo/EcalRecProducers

@cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please review it and eventually sign? Thanks.
@argiro 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

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/17441/console Started: 2017/01/25 17:56

[cmsbuild]

+1
Tested at: 455267f
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-17279/17441/summary.html

[cmsbuild]

Comparison job queued.

[cmsbuild]

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

[slava77]

with process.ecalMultiFitUncalibRecHit.algoPSet.gainSwitchEBMaxSample = True
I see some differences in regular matrix tests.
They are pretty small on the 200 events I used to show any particular change in plots

in 136.761 (JetHT 2016E workflow) a printout is more informative

en->Scan("EventAuxiliary.run():EventAuxiliary.event():EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.energy():eo.EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.energy():recoPFMETs_pfMet__reRECO.obj[0].pt():eo.recoPFMETs_pfMet__reRECO.obj[0].pt():recoPFMETs_pfMet__reRECO.obj[0].phi():eo.recoPFMETs_pfMet__reRECO.obj[0].phi()", "EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.energy()!=eo.EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.energy()")


 entry  * iter *   run *   event    * EB E new  * EB E old * pfMET new * pfMet old * pfMet.phi new  * pfMet.phi old 
*        3 *     3072 *    277069 *  54338128 * 184.65814 * 184.58984 * 34.117988 * 34.137405 * -1.942713 * -1.941813 *
*       37 *     1280 *    277069 *  54292181 * 216.43512 * 215.77362 * 73.425926 * 73.012771 * 0.8045494 * 0.8018864 *
*       40 *     1786 *    277069 *  54824155 * 166.95282 * 166.71604 * 41.767627 * 41.691749 * -2.516746 * -2.514802 *
*      109 *     2556 *    277069 *  54269138 * 215.31564 *         0 * 53.109245 * 53.109245 * -2.025533 * -2.025533 *
*      110 *     1317 *    277069 *  54282787 * 286.67196 *         0 * 19.252847 * 19.252847 * -0.008372 * -0.008372 *
*      129 *     2894 *    277069 *  54318475 * 186.26774 * 186.30551 * 42.300788 * 42.285659 * 2.8567485 * 2.8569345 *
*      156 *     3172 *    277069 *  54293225 * 275.60022 * 271.74719 * 50.027904 * 50.027904 * 2.3811783 * 2.3811783 *

Curiously, the hits with large energy change from 0 to ~200 didn't pass the downstream selections.
It was mentioned earlier that the effect is up to 20%. Was it based on some "collective" observable, or was it referring to individual hit energies with some additional quality requirements?

looking in more details at the hits

en->Scan("EventAuxiliary.run():EventAuxiliary.event():EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.id_.rawId():eo.EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.id_.rawId():EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.flagBits_:eo.EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.flagBits_:EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.energy():eo.EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.energy()", "EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.energy()!=eo.EcalRecHitsSorted_ecalRecHit_EcalRecHitsEB_reRECO.obj.obj.energy()")


*    Row   * Instance * entry  * iter *   run *   event    * rawId new * rawId old * flags new * flags old * EB E new  * EB E old *
***********************************************************************************************************************
*        3 *     3072 *    277069 *  54338128 * 838963517 * 838963517 *     65537 *     65537 * 184.65814 * 184.58984 *
*       37 *     1280 *    277069 *  54292181 * 838888710 * 838888710 *     65537 *     65537 * 216.43512 * 215.77362 *
*       40 *     1786 *    277069 *  54824155 * 838901608 * 838901608 *     65537 *     65537 * 166.95282 * 166.71604 *
*      109 *     2556 *    277069 *  54269138 * 838968643 * 838968643 *     81924 *     65537 * 215.31564 *         0 *
*      110 *     1317 *    277069 *  54282787 * 838876810 * 838876810 *     81924 *     65537 * 286.67196 *         0 *
*      129 *     2894 *    277069 *  54318475 * 838970003 * 838970003 *     65537 *     65537 * 186.26774 * 186.30551 *
*      156 *     3172 *    277069 *  54293225 * 838966940 * 838966940 *     65540 *     65540 * 275.60022 * 271.74719 *
***********************************************************************************************************************

65537 = kGood , kHasSwitchToGain6
81924 = kOutOfTime, kWeird, kHasSwitchToGain6
65540 = kOutOfTime, kHasSwitchToGain6

So, the flags for the hits with energy changing from 0 to ~200 change from kGood to kOutOfTime+kWeird, which explains their absence downstream.
Was everything actually set correctly for these?

I tested in CMSSW_9_0_X_2017-01-27-1100

[emanueledimarco]

@slava77 The average correction up to 20% was on average as a function of the multifit amplitude, in presence of a gain switch (see p. 16 of this presentation).

The flags can change, because the kOutOfTime is set in the uncalib rechit producer under certain conditions, in particular for high amplitudes (see here). So it is correct that if the amplitude was 0 before, the flag kOutOfTime and kWeird could not be set.

[slava77]

@emanueledimarco
should I take your explanation that the changes I posted in the printouts are expected?

[emanueledimarco]

@slava77
yes

[slava77]

+1

for #17279 455267f

• changes are as described; the defaults are unchanged
• jenkins tests pass and comparisons with baseline show no differences
• local tests with the switch enabled show roughly expected changes mentioned above

[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

[davidlange6]

+1