Fix ADC range for HGC scintillators

[deguio]

The ADC range was fixed to [0, 68.5] MIPs which isn't enough for large energy deposits. the range is now extended to 275 MIPs. the current implementation of the readout electronics for the HGC scintillators is a simplistic one so this choice is arbitrary.

this PR also includes:

• updated conversion of the kev2mip factor --> transparent for the reco as rechits are autocalibrated
• subtraction of the pedestal mean at digi level --> this is following some discussion we had recently and it is relevant for aged scenario only

the PR was validated locally and passes:
scram build code-checks
scram b runtests
runTheMatrix.py -l limited -i all --ibeos (still running)

@rovere @jingyucms @pfs @cseez

[cmsbuild]

The code-checks are being triggered in jenkins.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-27377/10651

• This PR adds an extra 20KB to repository

[cmsbuild]

A new Pull Request was created by @deguio (Federico De Guio) for master.

It involves the following packages:

SimCalorimetry/HGCalSimProducers

@cmsbuild, @civanch, @kpedro88, @mdhildreth can you please review it and eventually sign? Thanks.
@vandreev11, @sethzenz, @makortel, @kpedro88, @lgray, @cseez, @pfs this is something you requested to watch as well.
@davidlange6, @slava77, @fabiocos you are the release manager for this.

cms-bot commands are listed here

[kpedro88]

please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/1208/console Started: 2019/06/27 16:07

[cmsbuild]

+1
Tested at: 1d49340
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-92dcb6/1208/summary.html

[cmsbuild]

Comparison job queued.

[cmsbuild]

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

Comparison Summary:

• No significant changes to the logs found
• Reco comparison results: 8538 differences found in the comparisons
• DQMHistoTests: Total files compared: 33
• DQMHistoTests: Total histograms compared: 3254598
• DQMHistoTests: Total failures: 3848
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3250416
• DQMHistoTests: Total skipped: 334
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 32 files compared)
• Checked 137 log files, 14 edm output root files, 33 DQM output files

[kpedro88]

Comparison differences are isolated to 2023 workflows and appear to be statistical, likely due to changes in random number sequences in the DIGI step.

The exception is the HEB RecHits, where there appears to be a systematic shift:

Is this expected?

[civanch]

+1

[deguio]

Is this expected?

hi @kpedro88
I'm not sure yet. The difference you've highlighted seems to be the effect of updating the keV2MIP param, but I was expecting to see only minor changes at rechit level as the rechit energy should be automatically re-calibrated for scintillators according to this. @rovere is this a correct assumption?

I've already updated the same parameter in a previous PR, but the value wasn't accurate.

To cross check this PR I've generated few events using a muon particle gun and when summing the PCaloHit energy deposited in each DetID the single MIP peak sits around 675 keV:

when plotting the DIGI distribution in ADC the peak is now around 15 ADC which is what is expected (see red histo) compared to the peak obtained with the conversion at 500 keV (black):

[kpedro88]

@deguio @rovere what is the status of this PR? (is the shift in the HEB RecHit energy spectrum expected?)

[deguio]

ciao @kpedro88,
I've looked into more details and I've convinced myself that the shift is indeed expected.
I was wrongly assuming that for scintillators the recHit energy is automatically re-calibrated, but that doesn't seem to be the case because in the end the parameter kev2mip is never re-used at (uncalib)rechit level.

For scintillators the other factors that come into play are the weights which should depend only on the material.

So in the end updating this value seems the right thing to do to restore the proper conversion from keV (from G4) to MIPs

[kpedro88]

@deguio to make sure I understand, the conclusion is that your update keV2MIP fixes some behavior that was wrong before? (I want to make sure we know how to keep this value in sync with other changes...)

[deguio]

hi @kpedro88
yes. I've recently (PR #26811) updated the same keV2MIP value from 1/616 to 1/500 but I've made a mistake and the measurement wasn't correct. The new value I'm proposing is a more accurate measurement of the conversion from simHits energy to MIPs based on geometry v10.

[kpedro88]

+upgrade

[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, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2)

[fabiocos]

+1