Use Pedestal Width for ZS During HBHE TP Formation #49724

JHiltbrand · 2026-01-06T11:09:14Z

PR description:

This PR adds functionality to perform zero suppression during trigger primitive formation for the HCAL barrel and endcap. The ZS threshold is configured as some amount of pedestal widths (per-channel), where the widths are simply taken from the conditions database. The amount of widths to use is anticipated to be stored in the third byte of the auxi1 parameter of the HcalTPParameters condition. The value extracted from this condition parameter is assumed to be fixed-point with a scale factor of 16 to allow for a final fractional value to be used as the number of widths. E.g. a third byte value of 21 results in a number of widths of 1.3125.

Historically, the third byte (and all) of auxi1 of HcalTPParameters has been unused and set to 0 (only recently as of PR #49012 has the first and second bytes been used). Thus, with the default value of 0 for the third byte, the aforementioned functionality is not activated and no changes are expected in TPs or LUT XMLs. Once the third byte of the HcalTPParameter auxi1 parameter is filled, the new functionality is activated. Python configuration overrides are also made available, but they are also off by default.

PR validation:

Ran the local LUT XML production workflow and manipulated the third byte of auxi1 of HcalTPParameters to yield changes in the LUT consistent with the effect of zero suppression.

A talk was given to L1T DPG over-viewing this development with example impact on TPs for a number of pedestal widths of 3

If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:

Not a backport itself, but should be backported to 16_0_X

ATTN: @akhukhun

cmsbuild · 2026-01-06T11:09:38Z

cms-bot internal usage

cmsbuild · 2026-01-06T11:11:47Z

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-49724/47306

There are other open Pull requests which might conflict with changes you have proposed:
- File SimCalorimetry/HcalTrigPrimProducers/python/hcaltpdigi_cff.py modified in PR(s): Update HF FG thresholds for 2025 PbPb #49677

cmsbuild · 2026-01-06T11:12:14Z

A new Pull Request was created by @JHiltbrand for master.

It involves the following packages:

CalibCalorimetry/HcalTPGAlgos (alca, l1)
CalibCalorimetry/HcalTPGEventSetup (alca, l1)
SimCalorimetry/HcalTrigPrimProducers (l1)

@Alejandro1400, @BenjaminRS, @JanChyczynski, @arunhep, @atpathak, @cmsbuild, @perrotta, @quinnanm can you please review it and eventually sign? Thanks.
@abdoulline, @bsunanda, @missirol, @mmusich, @rovere, @rsreds, @sameasy, @tocheng, @yuanchao this is something you requested to watch as well.
@ftenchini, @mandrenguyen, @sextonkennedy you are the release manager for this.

cms-bot commands are listed here

quinnanm · 2026-01-07T18:01:12Z

please test

cmsbuild · 2026-01-07T19:48:58Z

-1

Failed Tests: UnitTests
Size: This PR adds an extra 16KB to repository
Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-b2ea65/50469/summary.html
COMMIT: aef8b46
CMSSW: CMSSW_16_1_X_2026-01-07-1100/el8_amd64_gcc13
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/49724/50469/install.sh to create a dev area with all the needed externals and cmssw changes.

Failed Unit Tests

I found 1 errors in the following unit tests:

---> test test-das-selected-lumis had ERRORS

Comparison Summary

Summary:

You potentially removed 1 lines from the logs
ROOTFileChecks: Some differences in event products or their sizes found
Reco comparison results: 4 differences found in the comparisons
Reco comparison had 4 failed jobs
DQMHistoTests: Total files compared: 53
DQMHistoTests: Total histograms compared: 4280553
DQMHistoTests: Total failures: 127
DQMHistoTests: Total nulls: 0
DQMHistoTests: Total successes: 4280406
DQMHistoTests: Total skipped: 20
DQMHistoTests: Total Missing objects: 0
DQMHistoSizes: Histogram memory added: 0.0 KiB( 52 files compared)
Checked 227 log files, 198 edm output root files, 53 DQM output files
TriggerResults: no differences found

quinnanm · 2026-01-07T23:25:23Z

please test

cmsbuild · 2026-01-08T01:22:27Z

+1

Size: This PR adds an extra 16KB to repository
Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-b2ea65/50471/summary.html
COMMIT: aef8b46
CMSSW: CMSSW_16_1_X_2026-01-07-1100/el8_amd64_gcc13
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/49724/50471/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

You potentially removed 2 lines from the logs
ROOTFileChecks: Some differences in event products or their sizes found
Reco comparison results: 8 differences found in the comparisons
Reco comparison had 4 failed jobs
DQMHistoTests: Total files compared: 53
DQMHistoTests: Total histograms compared: 4280553
DQMHistoTests: Total failures: 127
DQMHistoTests: Total nulls: 0
DQMHistoTests: Total successes: 4280406
DQMHistoTests: Total skipped: 20
DQMHistoTests: Total Missing objects: 0
DQMHistoSizes: Histogram memory added: 0.0 KiB( 52 files compared)
Checked 227 log files, 198 edm output root files, 53 DQM output files
TriggerResults: no differences found

perrotta · 2026-01-09T14:08:33Z

CalibCalorimetry/HcalTPGAlgos/src/HcaluLUTTPGCoder.cc

+  // The number of pedestal widths for ZS is packed into the third byte
+  // of the 32 bit auxi1 variable from HcalTPParameters
+  // Assume a fixed-point SF of 1 / 16 to convert to final number of widths
+  double nPedWidthsForZSfromDB = ((aux1 & 0xFF0000u) >> 16) / 16.0;


There are several assumptions here:
The value extracted from this condition parameter is assumed to be fixed-point with a scale factor of 16 to allow for a final fractional value to be used as the number of width
When do you think that this will be finalized, and a candidate condition can be tested with this PR?

By the way: shouldn't it be

Suggested change

double nPedWidthsForZSfromDB = ((aux1 & 0xFF0000u) >> 16) / 16.0;

double nPedWidthsForZSfromDB = ((aux1 >> 16) & 0xFF0000u) / 16.0;

instead?

By the way: shouldn't it be

instead?

I think with your suggestion, one would need to AND with 0xFFu, since the shift by 16 bits first moved what was in the third byte to become the lowest byte. But perhaps I am missing something ?

There are several assumptions here: The value extracted from this condition parameter is assumed to be fixed-point with a scale factor of 16 to allow for a final fractional value to be used as the number of width When do you think that this will be finalized, and a candidate condition can be tested with this PR?

Indeed, some assumptions here..., which is the theme with our recent campaign of packing things into the bytes of unused auxiliary words (e.g. #49012). The onus is on HCAL to keep track of how and where each byte is prepared/used correctly.

I believe we have determined recently (@akhukhun can correct me) that a realistic value for the number of pedestal widths to use would 1.31 (i.e. a third byte equal to 0x15), so a candidate condition could be produced to test with this PR. I am unfamiliar with testing PRs with specific candidate conditions, what is the best way to proceed ?

Yes, you are right: I meant

Suggested change

double nPedWidthsForZSfromDB = ((aux1 & 0xFF0000u) >> 16) / 16.0;

double nPedWidthsForZSfromDB = ((aux1 >> 16) & 0xFFu) / 16.0;

In my mind the logic would be: first skip the first two bytes, and then select the following one. But at the end, I agree with you that it may end up with assigning the content of the same byte, indeed...

I believe we have determined recently (@akhukhun can correct me) that a realistic value for the number of pedestal widths to use would 1.31 (i.e. a third byte equal to 0x15), so a candidate condition could be produced to test with this PR. I am unfamiliar with testing PRs with specific candidate conditions, what is the best way to proceed ?

This is a test that you can do yourself, outside of the automatic PR tests, and report about it in the PR thread

I believe we have determined recently (@akhukhun can correct me) that a realistic value for the number of pedestal widths to use would 1.31 (i.e. a third byte equal to 0x15), so a candidate condition could be produced to test with this PR. I am unfamiliar with testing PRs with specific candidate conditions, what is the best way to proceed ?

This is a test that you can do yourself, outside of the automatic PR tests, and report about it in the PR thread

Hi @perrotta,

How sophisticated of a test is desired ? I am imagining having a test tag of the HcalTPParameter condition in conddb, and setting up a basic cmsRun job that runs the affected code to show that an expected value for number of pedestal widths comes out. Or are you looking for physics impact (if so, see my slides I linked in the PR main text) ? Or something else entirely ?

How sophisticated of a test is desired ? I am imagining having a test tag of the HcalTPParameter condition in conddb, and setting up a basic cmsRun job that runs the affected code to show that an expected value for number of pedestal widths comes out. Or are you looking for physics impact (if so, see my slides I linked in the PR main text) ? Or something else entirely ?

I think that for the PR it may be sufficient to " test tag of the HcalTPParameter condition in conddb, and setting up a basic cmsRun job that runs the affected code to show that an expected value for number of pedestal widths comes out"

As you write, you were already showing the physics impact of this development, and I assume that L1T will take care of it for their signature.

perrotta · 2026-01-09T14:12:47Z

CalibCalorimetry/HcalTPGAlgos/interface/HcaluLUTTPGCoder.h

  std::unique_ptr<HcalPulseContainmentManager> pulseCorr_;
  bool overrideDBweightsAndFilterHB_ = false;
  bool overrideDBweightsAndFilterHE_ = false;
+  double nPedWidthsForZS_ = 0.0;


ped and pedwidth are both float: why to make nPedWidthsForZS_, nPedWidthsForZSfromDB and nPedWidthsForZSfinal as double?

Understandable, I can make them float.

Changed to float.

JHiltbrand · 2026-01-15T07:29:46Z

Hi @perrotta,

I have performed a basic test to verify the behavior of this code and extracting information from the HcalTPParameters condition. I set up a simple cmsRun config (test_tpzs_pr.py), which runs on a RAW file, unpacks HCAL TPs and re-emulates HCAL TPs (thereby using the code modified in this PR). Locally, in HcaluLUTTPGCoder.cc, I added a printout statement to show the value of auxi1 from the TPParameters condition, and all three used bytes: HF FG1 (directly from byte 1), HF FG2 (directly from byte 2), and now number of pedestal widths for TP ZS (computed from byte 3). I ran on a 2025G ZeroBias RAW file and specifically run 397868. I show the printout for three scenarios and describe below:

1. auxi1: 0       | fg_hf_lo: 17 | fg_hf_hi: 255 | nPedWidthsForZSfromDB: 0      | nPedWidthsForZSfinal: 0
2. auxi1: 1376256 | fg_hf_lo: 17 | fg_hf_hi: 255 | nPedWidthsForZSfromDB: 1.3125 | nPedWidthsForZSfinal: 1.3125
3. auxi1: 1376256 | fg_hf_lo: 17 | fg_hf_hi: 255 | nPedWidthsForZSfromDB: 1.3125 | nPedWidthsForZSfinal: 3.7

Using the conditions for run 397868 via the production GT 150X_dataRun3_HLT_v1. At the time of that run, auxi1 was still its default value of 0. Thus, for the HF FG thresholds, they fell back to their default values defined per-era in python cfg. Likewise, byte 3 is also 0, which translates to a number of pedestal widths of 0 (the functionality introduced here is deactivated as intended).
Now I override the HcalTPParametersRcd from the above GT with the test tag HcalTPParameters_2026_v1.0_data_test1. In this test tag auxi1 has been set to 0x150000 i.e. the third byte set to 0x15 or 21. Via the changes in this PR, the extracted 21 for the third byte translates to a number of pedestal widths of 21/16 => 1.3125. Likewise, the HF FG thresholds are unaffected by the change in the third byte.
With the GT override still in place, I then use the python cfg override introduced in this PR to on-demand choose a number of pedestal widths of 3.7. So while auxi1 and nPedWidthsForZSfromDB still come out non-zero in the code, the final number of pedestal widths used for constructing the LUT later on is the chosen-via-python-cfg 3.7.

Hopefully this test is meaningful to see how the code works with an actual test tag for HcalTPParameters.

cmsbuild · 2026-01-15T07:30:23Z

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-49724/47499

cmsbuild · 2026-01-15T07:30:54Z

Pull request #49724 was updated. @Alejandro1400, @BenjaminRS, @JanChyczynski, @arunhep, @atpathak, @cmsbuild, @perrotta, @quinnanm can you please check and sign again.

perrotta · 2026-01-15T09:13:21Z

please test

cmsbuild · 2026-01-15T11:17:37Z

+1

Size: This PR adds an extra 28KB to repository
Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-b2ea65/50650/summary.html
COMMIT: ffc83f3
CMSSW: CMSSW_16_1_X_2026-01-14-2300/el8_amd64_gcc13
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/49724/50650/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

You potentially added 3 lines to the logs
Reco comparison results: 12 differences found in the comparisons
DQMHistoTests: Total files compared: 52
DQMHistoTests: Total histograms compared: 4025536
DQMHistoTests: Total failures: 12
DQMHistoTests: Total nulls: 0
DQMHistoTests: Total successes: 4025504
DQMHistoTests: Total skipped: 20
DQMHistoTests: Total Missing objects: 0
DQMHistoSizes: Histogram memory added: 0.0 KiB( 51 files compared)
Checked 222 log files, 193 edm output root files, 52 DQM output files
TriggerResults: no differences found

perrotta · 2026-01-15T12:44:35Z

+alca

Until the amount of widths to be used is not inserted in the DB this PR does not change the current behaviour.
The effectiveness of the inclusion of the new feature in the DB was privately verified by the author, see Use Pedestal Width for ZS During HBHE TP Formation #49724 (comment)

cmsbuild added this to the CMSSW_16_1_X milestone Jan 6, 2026

cmsbuild added l1-pending alca-pending pending-signatures tests-pending orp-pending code-checks-pending labels Jan 6, 2026

cmsbuild added code-checks-approved and removed code-checks-pending labels Jan 6, 2026

cmsbuild added tests-started and removed tests-pending labels Jan 7, 2026

cmsbuild added tests-rejected and removed tests-started labels Jan 7, 2026

cmsbuild added tests-started and removed tests-rejected labels Jan 7, 2026

cmsbuild added tests-approved and removed tests-started labels Jan 8, 2026

JHiltbrand mentioned this pull request Jan 8, 2026

[Backport to 16_0_X (#49724)] Use Pedestal Width for ZS During HBHE TP Formation #49743

Open

perrotta reviewed Jan 9, 2026

View reviewed changes

cmsbuild mentioned this pull request Jan 13, 2026

NanoDQM plots per PFCand type #49803

Open

cmsbuild added tests-pending and removed tests-approved code-checks-approved labels Jan 15, 2026

cmsbuild added the code-checks-pending label Jan 15, 2026

use ped width for ZS in input LUT

ffc83f3

JHiltbrand force-pushed the hcalTPlutZS_161X branch from 01c0d5a to ffc83f3 Compare January 15, 2026 07:30

cmsbuild added code-checks-approved and removed code-checks-pending labels Jan 15, 2026

cmsbuild added tests-started and removed tests-pending labels Jan 15, 2026

cmsbuild added tests-approved and removed tests-started labels Jan 15, 2026

cmsbuild added alca-approved and removed alca-pending labels Jan 15, 2026

	double nPedWidthsForZSfromDB = ((aux1 & 0xFF0000u) >> 16) / 16.0;
	double nPedWidthsForZSfromDB = ((aux1 >> 16) & 0xFF0000u) / 16.0;

Use Pedestal Width for ZS During HBHE TP Formation #49724

Are you sure you want to change the base?

Use Pedestal Width for ZS During HBHE TP Formation #49724

Conversation

JHiltbrand commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR description:

PR validation:

If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:

Uh oh!

cmsbuild commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cmsbuild commented Jan 6, 2026

Uh oh!

cmsbuild commented Jan 6, 2026

Uh oh!

quinnanm commented Jan 7, 2026

Uh oh!

cmsbuild commented Jan 7, 2026

Failed Unit Tests

Comparison Summary

Uh oh!

quinnanm commented Jan 7, 2026

Uh oh!

cmsbuild commented Jan 8, 2026

Comparison Summary

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JHiltbrand commented Jan 15, 2026

Uh oh!

cmsbuild commented Jan 15, 2026

Uh oh!

cmsbuild commented Jan 15, 2026

Uh oh!

perrotta commented Jan 15, 2026

Uh oh!

cmsbuild commented Jan 15, 2026

Comparison Summary

Uh oh!

perrotta commented Jan 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

JHiltbrand commented Jan 6, 2026 •

edited

Loading

cmsbuild commented Jan 6, 2026 •

edited

Loading