More flexible SOI handling

[igv4321]

Added more flexible handling of SOI (sample of interest) so that the case of SOI=5 will be correctly handled. This is expected due to the impending change of SiPM dark current modelling in MC, where placement of SOI at a later time slice allows for skipping two initial time slices at which the dark current is not well modelled (as there is not enough history).

This change is not supposed to modify any test results.

The usual "runTheMatrix" sequence was run to validate.

[cmsbuild]

The code-checks are being triggered in jenkins.

[cmsbuild]

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28948/13762

• This PR adds an extra 20KB to repository

Code check has found code style and quality issues which could be resolved by applying following patch(s)

• code-format:
  https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28948/13762/code-format.patch
  e.g. curl https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28948/13762/code-format.patch | patch -p1
  You can also run scram build code-format to apply code format directly

[cmsbuild]

The code-checks are being triggered in jenkins.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28948/13763

• This PR adds an extra 20KB to repository

[cmsbuild]

A new Pull Request was created by @igv4321 (Igor Volobouev) for master.

It involves the following packages:

RecoLocalCalo/HcalRecProducers

@perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks.
@apsallid, @mariadalfonso this is something you requested to watch as well.
@davidlange6, @silviodonato, @fabiocos you are the release manager for this.

cms-bot commands are listed here

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/4647/console Started: 2020/02/13 14:52

[cmsbuild]

+1
Tested at: 12f899b
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-89feba/4647/summary.html
CMSSW: CMSSW_11_1_X_2020-02-13-1100
SCRAM_ARCH: slc7_amd64_gcc820

[cmsbuild]

Comparison job queued.

[cmsbuild]

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

Comparison Summary:

• No significant changes to the logs found
• Reco comparison results: 998 differences found in the comparisons
• DQMHistoTests: Total files compared: 34
• DQMHistoTests: Total histograms compared: 2694005
• DQMHistoTests: Total failures: 15
• DQMHistoTests: Total nulls: 1
• DQMHistoTests: Total successes: 2693643
• DQMHistoTests: Total skipped: 346
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.008 KiB( 33 files compared)
• DQMHistoSizes: changed ( 4.53 ): 0.008 KiB JetMET/SUSYDQM
• Checked 147 log files, 16 edm output root files, 34 DQM output files

[abdoulline]

NB: during Run1 we have had several HCAL modules with "precession" (instability) of the clock synchronization wrt LHC clock. So that their SOI was moving back and force in TS range=(3,5).
We did discuss this in the past in several PRs...
And once this PR adds a special case with SOI=5 for our coming (soon) modification of MC Data frame size (with SOI=5) for >=Run3, it's "sensitive" to this old Run1 problem.
I suppose it's not a showstopper.

[slava77]

+1

for #28948 12f899b

• code changes are in line with the PR description. The sample/range selection looks more appropriate now even for the drifting channels from Run 1.
• jenkins tests pass and comparisons with the baseline show differences only in Run 1 data tests, which are affected by the drifting channels mentioned in More flexible SOI handling #28948 (comment)

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @silviodonato, @fabiocos (and backports should be raised in the release meeting by the corresponding L2)

[silviodonato]

And once this PR adds a special case with SOI=5 for our coming (soon) modification of MC Data frame size (with SOI=5) for >=Run3, it's "sensitive" to this old Run1 problem.

Could you give more details on this? Merging this PR, will we get a better or worse data(run1)/MC agreement?

[abdoulline]

@silviodonato
Flexibility in general sounds better :)
Now, in particular (for this Run1 issue) - when in the data SOI happens to arrive to TS=5, with this PR it can be handled, which wasn't the case before.
So, with this PR it becomes better, albeit it doesn't fully cure the Run1 issue, as the timing alignment was seamless/gradual (rather constant "precession" than quantized jumping between TS' 3,4,5)

[silviodonato]

+1
thanks