Introduce High Granularity Tracker Alignment Prompt Calibration Loop for HLT alignment conditions

[phnattla]

PR description:

The goal of this PR is to integrate a new High Granularity Tracker Alignment Prompt Calibration Loop using both MinumumBias and Z → µµ data ("HG Combined alignment), aiming to provide alignment conditions for the High Level Triggers (HLT).
This would help keeping the alignment conditions for the HLT up to date to help combat effects of radiations damage, which accumulate over the year (see e.g. here).
This development is co-authored by @mmusich

PR validation:

This PR has been validated using the recipe [*]. Results of this validation can be inspected on this website.

[*]

cmsrel CMSSW_14_2_0_pre3
cd CMSSW_14_2_0_pre3/src/
cmsenv
git cms-init
git cms-merge-topic cms-trackeralign:HLT_TkAl_HGComb
scramv1 b -j 20
cmsenv
voms-proxy-init --voms cms --valid 192:00
cd Alignment/CommonAlignmentProducer/test
source test-PromptCalibProdSiPixelAliHLTHGC.sh 

CC: @henriettepetersen @TomasKello

[cmsbuild]

cms-bot internal usage

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-46888/42923

[cmsbuild]

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

It involves the following packages:

• Alignment/CommonAlignmentProducer (alca)
• Configuration/AlCa (alca)
• Configuration/EventContent (operations)
• Configuration/StandardSequences (operations)

@antoniovilela, @atpathak, @cmsbuild, @consuegs, @davidlange6, @fabiocos, @mandrenguyen, @perrotta, @rappoccio can you please review it and eventually sign? Thanks.
@GiacomoSguazzoni, @Martin-Grunewald, @VinInn, @VourMa, @adewit, @dgulhan, @fabiocos, @felicepantaleo, @makortel, @missirol, @mmusich, @mtosi, @pakhotin, @rovere, @rsreds, @sameasy, @slomeo, @tlampen, @tocheng, @yuanchao this is something you requested to watch as well.
@antoniovilela, @mandrenguyen, @rappoccio, @sextonkennedy you are the release manager for this.

cms-bot commands are listed here

[mmusich]

@cmsbuild, please test

[cmsbuild]

+1

Size: This PR adds an extra 48KB to repository
Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-bb0714/43296/summary.html
COMMIT: 00c34cb
CMSSW: CMSSW_15_0_X_2024-12-05-2300/el8_amd64_gcc12
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/46888/43296/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• You potentially added 1 lines to the logs
• Reco comparison results: 36 differences found in the comparisons
• DQMHistoTests: Total files compared: 46
• DQMHistoTests: Total histograms compared: 3494042
• DQMHistoTests: Total failures: 1606
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3492416
• DQMHistoTests: Total skipped: 20
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 45 files compared)
• Checked 202 log files, 172 edm output root files, 46 DQM output files
• TriggerResults: found differences in 1 / 44 workflows

[perrotta]

Don't you think to clone them from triggerResultsFilterFromDB, as modified for other AlCa filters in #46742? I understand that you probably don't plan to prescale further these paths, but I wonder if the same configurations could be used for all them. Unless there is a real advantage in cloning from hltHighLevel

[perrotta]

Same comment applies to the other similar instances in this PR

[mmusich]

In this specific instance you have commented upon it's not possible to use triggerResultsFilterFromDB because the filtering is not based on a path key retrieved from the event setup but rather on the name of the path pathALCARECOTkAlHLTTracksZMuMu which is executed in the step before (the alcareco sample creation: this ensures that the producer is run only in presence of the right input set of tracks).
Elsewhere it might be possible to use it, but there is no advantage in doing so. The input HLT paths are actually already limited in rate (see CMSHLT-3404), thus prescaling is not desireable - we'll actually be statistically limited.

[perrotta]

@phnattla @mmusich wouldn't it be worth adding a RelVal to test this during the release validation?

[mmusich]

wouldn't it be worth adding a RelVal to test this during the release validation?

@perrotta thanks for the comment. Indeed @phnattla and I have discussed this topic before and we definitely want to do that. We have been targeting that development for a follow-up PR to come at a later time for the following reasons:

• I won't be able to look at it in the next few days :)
• the data used to develop the workflow is "opportunistic". It's a block of /HLTMonitor/Run2024I-Express-v2/FEVTHLTALL provisionally blocked on T2 disk by an alca rucio rule. Moreover the input files are quite large (for this reason they are generally quickly deleted from Tier0 without a TAPE copy and thus lost forever) and we should think carefully what we want to keep for automatic testing.
• we wanted to suggest a Tier0 replay with the current state of the software in order to secure the output of the step1 of the procedure (alca skimming)- which is more manageable in terms of size, and use that to put together the relval workflows.
• there is a script that can be used to test privately introduced in this PR (link).

In case you insist with introducing a strawman workflow in this PR, I take note and will try to provide one (albeit not immediately) -- unless @phnattla wants to follow-up on that.

[perrotta]

+alca

• A relval designed to keep monitored this PCL workflow will come later, as explained in Introduce High Granularity Tracker Alignment Prompt Calibration Loop for HLT alignment conditions #46888 (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. @antoniovilela, @sextonkennedy, @rappoccio, @mandrenguyen (and backports should be raised in the release meeting by the corresponding L2)

[mandrenguyen]

+1