Introduction

Overview

Teaching: 30 min
Exercises: 10 min

Questions

• What is luminosity?

• What is the difference between instantaneous and integrated luminosity?

• Why is knowing the luminosity important?

• How is luminosity measured?

Objectives

• Know what luminosity is and why it is important

• Know how luminosity is measured

References

You can find several papers with much more technical detail and several articles with additional (less formal) information in the References.

Instantanous Luminosity

In the context of the LHC, instantaneous luminosity \(\mathcal{L}_{inst}\), corresponds to the number of interactions produced when bunches of protons are crossed. Roughly speaking, it refers to the “real-time rate of interactions”. During 2022, groups of more than 100 billion protons were crossed as often as 40 million times per second yielding an overall average of 46 interactions per crossing (pileup) within the CMS detector.

More precisely, instantaneous luminosity quantifies the ability of particle accelerator to produce a certain number of interactions. It represents a proportionality factor between rate of interactions \(\left( \frac{dN}{dt} \right)\) and the cross-section (\(\sigma\)):

[\frac{d\mathrm{N}}{dt} = \mathcal{L}_{inst} \cdot \sigma]

Thus, instantaneous luminosity is usually expressed in the cgs units of \(\mathrm{cm^{-2} s^{-1}}\). Units of “barns” are also used frequently, where \(1 \mathrm{b} = \mathrm{10^{-24} cm^{2}}\), thanks to two Purdue University physicists working on the Manhattan Project in 1942. As an example, let’s very approximately calculate the total Higgs Boson production rate at CMS:

1.1 Total Higgs boson production rate at CMS

• During November 2022, the LHC routinely delivered instantanous luminosities close to \(\approx 2 \times 10^{34} \mathrm{cm^{-2} s^{-1}}\) \(\left( 0.02 \mathrm{pb^{-1} s^{-1}} \right)\) at CMS
• The total production cross section of Standard Model Higgs boson at \(\sqrt{s} = 13.6 \mathrm{TeV}\) is nearly \(\approx 60 \mathrm{pb}\) (see table 11.2 in the 2024 PDG)

What is the rate of Higgs production at CMS?

\[\frac{d\mathrm{N_{Higgs}}}{dt} = \mathcal{L}_{inst}^{\mathrm{peak}} \cdot \sigma_{\mathrm{Higgs}}^{\mathrm{total}}\]

Integrated Luminosity

Instantaneous luminosity is aggregated over a certain period of time to obtain integrated luminosity:

[\mathcal{L}{int} = \int \mathcal{L}{inst} dt]

It is commonly used to quantify the “amount of data” delivered by the accelerator or recorded by the experiment. Units of inverse femtobars \(\mathrm{fb^{-1}}\) are frequently used in CMS.

To illustrate, we can very roughly estimate the total number of Higgs bosons produced during 24 hours at CMS:

1.2 Total Higgs bosons produced at CMS during 24 hours

• During 2022-Nov-01, CMS recorded \(\approx 1000 \mathrm{pb^{-1}}\) during a 24-hour period
• The total production cross section of Standard Model Higgs boson at \(\sqrt{s} = 13.6 \mathrm{TeV}\) is nearly \(\approx 60 \mathrm{pb}\) (see table 11.2 in the 2024 PDG)

How many Higgs bosons were produced at CMS during these 24 hours?

\[\mathrm{N_{Higgs}} = \mathcal{L}_{int}^{\mathrm{24hr}} \cdot \sigma_{\mathrm{Higgs}}^{\mathrm{total}}\]

Importance of Luminosity

Along with the center of mass energy, instantanous luminosity is the most significant performance parameter for any particle accelerator. Real-time monitoring of instantaneous luminosity is critical for the accelerator to carry out beam tuning and collision optimization. It is also essential for the CMS trigger system in order to pre-scale (throttle) the trigger rates.

Measuring integrated luminosity precisely is crucial since it contributes to the systematic uncertainty for nearly all physics searches and measurements. The uncertainty in the integrated luminosity is often the dominant systematic uncertainty in EWK cross-section measurements. We can emphasize the impact of the integrated luminosity uncertainty by considering a relatively rare process:

1.3 Total Higgs bosons decaying to muon pairs at CMS

• During 2022, CMS recorded around \(\approx 38 \mathrm{fb^{-1}}\) of good-quality data with 1.4% uncertainty (see Luminosity recommendations for Run 3 analyses)
• The total production cross section of Standard Model Higgs boson at \(\sqrt{s} = 13.6 \mathrm{TeV}\) is nearly \(\approx 60 \mathrm{pb}\) (see Table 11.2 in the 2024 PDG)
• The branching ratio for \(H \rightarrow \mu \mu\) is nearly \(\approx 2 \times 10^{-4}\) (see Table 11.3 in the 2024 PDG)

What is the minimum and maximum expected event yield given the uncertainty in integrated luminosity?

\[\mathrm{N}_{H \rightarrow \mu \mu}^{2022} = \left( \mathcal{L}_{int}^{2022} \pm \delta \right) \cdot \sigma_{\mathrm{Higgs}}^{\mathrm{total}} \cdot \mathcal{B}_{H \rightarrow \mu \mu}\]

Luminosity Measurement

CMS has two dedicated systems for measuring luminosity, both located \(z \approx \pm 1.8 \mathrm{m}\) from the interaction point and radius \(\approx 6 \mathrm{cm}\):

Fast Beam Condition Monitor (BCM1F)

C-shaped PCBs arranged into two rings at each side of CMS with 6 double-pad silicon sensors per c-shape

Precise timing measurements (\(6.25 \mathrm{ns}\) per bin), via two independent read out systems (VME & \(\mu\)TCA), facilitate separation of collision products from machine-induced background

Pixel Luminosity Telescope (PLT)

16 “telescopes” (8 per side of CMS) with three hybrid silicon pixel sensors per telescope

Fast cluster-counting signal readout (\(40 \mathrm{MHz}\)), in parallel to full pixel data readout

In addition, several sub-detectors are used for luminosity measurement, among them:

PCC (Pixel Cluster Counting)

Counts the mean number of pixel clusters in the most “stable” modules of the silicon pixel detector

Hadronic Forward (HF)

Steel absorber with quartz fibers to detect Cherenkov light histogrammed as function of bunch crossing and read out via two independent systems (HFET & HFOC)

Which detector is more photogenic?

https://indico.cern.ch/event/1239959/surveys/4059

Luminosity Calibration

The precise determination of integrated luminosity is particularly challenging at hadron colliders, in part due to the theoretical predictions being generally less precise compared to \(e^{+} e^{−}\) colliders (e.g. uncertainties in the parton distribution functions and precision of parton-level cross-section calculations). A sub-detector can easily measure “relative” luminosity on an arbitrary scale based on the measured event rate. The complexity lies in the determination of “absolute” luminosity, which involes re-scaling the measured event rate by a proportionality factor, \(\sigma_{vis}\), derived from the properties of the colliding beams. This scaling factor may be thought of as a way to account for the sub-detector’s particular acceptance and response.

At the LHC, the primary technique to determine the absolute luminosity scale is the van der Meer (vdM) scan method, based on dedicated beam-separation scans. The size and shape of the interaction region is measured by recording the relative interaction rates as a function of the transverse beam separation. After adopting several assumptions (e.g. transverse and longitudinal beam densities are Gaussian, density functions are factorizable into \(x\)- and \(y\)-dependent components, etc.), the visible cross-section can be expressed as

[\sigma_{vis} = \mu_{vis}^{\mathrm{max}} \frac{2 \pi \Sigma_{x} \Sigma_{y}}{n_{1} n_{2}}]

where \(\mu_{vis}^{\mathrm{max}}\) is the peak visible interaction rate per bunch, \(n_{1}\) and \(n_{2}\) are the numbers of particles in each of the two bunches, and \(\Sigma_{x}\) and \(\Sigma_{y}\) correspond to the effective beam overlap widths in each scan plane. Thus, luminosity can be determined from the number of particles per bunch and the geometrical overlap of the two beams (luminous region).

Calibration (\(\sigma_{vis}\)) corrections

Several systematic effects can affect the measurement of \(\sigma_{vis}\). These represent a major contribution to the final uncertainty in the measurement of integrated luminosity.

Orbit drift & beam position corrections

Time-dependent changes of the transverse beam positions (orbit drift) that affect the beam separation are monitored with the DOROS beam positions monitors (BPM)

After considering nominal beam positions, linear orbit drift corrections, and predicted beam-beam deflection, residual deviations are applied as corrections to the beam positions

Length scale calibration

During the beam separation scans, the beam positions are steered with LHC corrector magnets; thus, the nominal beam position is derived from the magnet currents

These nominal beam positions are corrected using the beamspot position extracted from reconstructed vertices during dedicated length-scale (“Hobbit”) scans

Beam-beam effects

The electromagnetic interaction between proton bunches changes their transverse position (beam-beam deflection) and their density distribution (dynamic-β effect)

The effect of beam-beam deflection is calculated analitically from the Bassetti–Erskine formula and the dynamic-β effect is parametrized using numerical simulations

Factorization bias

The estimation of the luminous area from an \(x-y\) scan pair assumes that the transverse proton bunch densities can be expressed as uncorrelated functions in \(x\) and \(y\)

This assumption is tested by using multiple 2D fit functions to model the beam overlap shape while comparing their consistency for several luminometers

Bunch current measurement and corrections

Bunch current is measured with the fast bunch current transformers (FBCT) and the total beam current with the direct current current transformers (DCCT)

“Spurious” charges (ghosts👻 in empty bunch slots and out-of-time satellites🛰 orbiting a filled bunch) are measured by longitudinal density monitors (LDMs)

Dominant uncertainties in the absolute luminosity scale (\(\sigma_{vis}\))

• factorization bias
• beam-beam effects
• beam position corrections

Integration (detector-specific) corrections

The vdM scan program is carried out with a small number of well-separated proton bunches with low bunch intensities. In order to extrapolate the resulting \(\sigma_{vis}\) to high-pileup data-taking conditions, several corrections need to be estimated and applied.

Out-of-time pileup corrections

Corrections for contributions due to spill-over of electronic signals (type-I) and exponentially decaying afterglow due to activation of detector material (type-II)

Stability and linearity

Gradual efficiency loss for each luminometer (mainly due to radiation damage) is monitored and corrected for based on the analysis of emittance scans (fast luminosity separation scans run often under physics production conditions) and by comparing the consistency between multiple luminometers

The consistency of detector response as a function of pileup is compared between several luminometers to estimate the non-linearity of each luminometer

Key Points

• Luminosity is a measure of how many collisions are delivered to and recorded by the detector.

• Instantaneous luminosity is usually expressed as the number of collisions per square centimeter per second.

• Integrated luminosity is the integral of instantaneous luminosity over time and is a measurement of data size. It is usually expressed in units of inverse cross section.

• Knowing the luminosity is important to determining and measuring accelerator and detector performance and operation. It is also an essential component for measuring cross sections and for setting limits on beyond-SM processes.

• Measurement of luminosity is done with muiltple systems in the CMS detector.

Using brilcalc

Overview

Teaching: 20 min
Exercises: 10 min

Questions

• What tools are available to query the delivered and recorded luminosity?

Objectives

• Learn how to use brilcalc to query luminosity information.

Important

This exercise is meant to be run from lxplus.cern.ch.

Please follow the setup instructions before getting started.

brilcalc

brilcalc is the official tool for querying CMS luminosity information. It currently has three subcommands: lumi, beam, and trg. The official brilcalc documentation can be found here: https://cmslumi.web.cern.ch/.

brilcalc lumi

This lesson will focus on the brilcalc lumi subcommand, which can query the delivered and recorded CMS luminosity. Let’s try a few examples:

Glossary

If you are unfamiliar with “fills”, “runs”, “lumisections”, etc., you can find their definitions in the Glossary

Run brilcalc for fill 9666

brilcalc lumi -f 9666

Output

#Data tag : 24v1 , Norm tag: onlineresult
+-------------+-------------------+-----+------+---------------------+---------------------+
| run:fill    | time              | nls | ncms | delivered(/ub)      | recorded(/ub)       |
+-------------+-------------------+-----+------+---------------------+---------------------+
| 381143:9666 | 05/24/24 11:04:03 | 12  | 0    | 14.181185411        | 0                   |
| 381147:9666 | 05/24/24 11:08:23 | 231 | 223  | 91256126.248753428  | 77027107.891959071  |
| 381148:9666 | 05/24/24 12:38:03 | 292 | 283  | 144805628.612147063 | 127957935.748760328 |
| 381149:9666 | 05/24/24 14:31:14 | 140 | 133  | 69235351.710984617  | 61366554.087962441  |
| 381150:9666 | 05/24/24 15:25:36 | 51  | 41   | 24489229.453756947  | 18476291.350573931  |
| 381151:9666 | 05/24/24 15:45:17 | 860 | 852  | 324855104.257013619 | 307000908.806938708 |
| 381152:9666 | 05/24/24 21:19:14 | 194 | 194  | 55802570.516791143  | 54069059.298041537  |
+-------------+-------------------+-----+------+---------------------+---------------------+
#Summary:
+-------+------+------+------+---------------------+---------------------+
| nfill | nrun | nls  | ncms | totdelivered(/ub)   | totrecorded(/ub)    |
+-------+------+------+------+---------------------+---------------------+
| 1     | 7    | 1780 | 1726 | 710444024.980632067 | 645897857.184236050 |
+-------+------+------+------+---------------------+---------------------+ 

Run brilcalc for run 370000

brilcalc lumi -r 370000

Output

#Data tag : 24v1 , Norm tag: onlineresult
+-------------+-------------------+-----+------+--------------------+--------------------+
| run:fill    | time              | nls | ncms | delivered(/ub)     | recorded(/ub)      |
+-------------+-------------------+-----+------+--------------------+--------------------+
| 370000:9023 | 07/03/23 02:01:15 | 224 | 224  | 65453850.326108657 | 63313828.920737430 |
+-------------+-------------------+-----+------+--------------------+--------------------+
#Summary:
+-------+------+-----+------+--------------------+--------------------+
| nfill | nrun | nls | ncms | totdelivered(/ub)  | totrecorded(/ub)   |
+-------+------+-----+------+--------------------+--------------------+
| 1     | 1    | 224 | 224  | 65453850.326108657 | 63313828.920737430 |
+-------+------+-----+------+--------------------+--------------------+  

brilcalc options

brilcalc provides a generous number of command line options. You can get a summary by running brilcalc lumi --help. But the official documentation is much more comprehensive.

Example brilcalc common command options

Selections

period to query

• -f <fill>
• -r <run>
• --begin <fill>
• --begin <run>
• --begin <MM/DD/YY HH:MM:SS> (UTC)
• --end <fill>
• --end <run>
• --end <MM/DD/YY HH:MM:SS> (UTC)

Filters

conditions to query

• -b <beam status> [“STABLE BEAMS”, “FLAT TOP”, “ADJUST”, “SQUEEZE”]
• --amodetag <machine mode> [“PROTPHYS”, “IONPHYS”, “PAPHYS”]
• --beamenergy <beam energy> (in GeV)

Output/Display

output file, table/csv/html output format, utc/local time, etc.

• -o <output file> (csv format)
• --output-style <output format> [“tab”, “csv”, “html”] (ignored if -o is provided)
• -n <scalefactor> (scale output by 1/scalefactor)
• --cerntime (display times in CERN local time)
• --tssec (display times as UNIX timestamps)

Database connection

connect to a database, such as a web cache

• -c <connection> [“offline”, “online”, “onlinew”, “dev”]

Example brilcalc lumi options

--byls

Show luminosity and average pileup by lumi section

-u <unit>

Show luminosity in the specified unit and scale the output value accordingly

[“/kb”, “/b”, “/mb”, “/ub”, “/nb”, “/pb”, “/fb”, “/ab”]

[“1e21/cm2”, “1e24/cm2”, “1e27/cm2”, “1e30/cm2”, “1e33/cm2”, “1e36/cm2”, “1e39/cm2”, “1e42/cm2”]

--type <luminometer>

Show results from the selected luminometer

[“hfoc”, “hfet”, “bcm1f”, “bcm1fsi”, “bcm1futca”, “pltzero”, “pltslink”, “dt”, “pxl”, “ramses”, “radmon”]

brilcalc --output-style

The stdout (display output) of brilcalc can be specified with the --output-style flag. Note that this in a “common” or “global” option, meaning that it is also available for the brilcalc beam and brilcalc trg subcommands. Let’s reproduce the above output in csv format:

brilcalc lumi -r 370000 --output-style csv

Output

#Data tag : 24v1 , Norm tag: None
#run:fill,time,nls,ncms,delivered(/ub),recorded(/ub)
370000:9023,07/03/23 02:01:15,224,224,65453850.326108657,63313828.920737430
#Summary:
#nfill,nrun,nls,ncms,totdelivered(/ub),totrecorded(/ub)
#1,1,224,224,65453850.326108657,63313828.920737430  

2.1 Query luminosity info for fill corresponding to run 370000

Using brilcalc, determine the fill that run 370000 corresponds to. What is the total recorded luminosity for this fill in inverse picobarns?

Key Points

• brilcalc is a command-line tool provided by the CMS BRIL group for querying luminosity information.

Normtags and Data Certification

Overview

Teaching: 10 min
Exercises: 20 min

Questions

• What is a normtag?

• What is data certification?

Objectives

• Learn what is a normtag and how to use it

• Learn about data certification and how it relates to physics analyses

Important

This exercise is meant to be run from lxplus.cern.ch.

Please follow the setup instructions before getting started.

Normtags

A normtag is a file that defines the official luminosity calibrations and detectors to use for a given period. The normtag files are maintained by the Lumi POG and periodically updated as the calibrations are improved. It is important to always use the latest normtag in order to get the best results.

Important

Never run brilcalc without a --normtag argument unless you know exactly what you are doing.
Running brilcalc without --normtag will give you the online luminosity, which can change significantly by improvements in calibration. It is neither accurate, nor precise, nor stable.

The physics normtag is /cvmfs/cms-bril.cern.ch/cms-lumi-pog/Normtags/normtag_PHYSICS.json. Always use this normtag for pp runs. This is the only normtag which can be used for physics analyses. It covers all periods for which there is a final approved number for physics (which includes all pp running and some special runs).

The preliminary normtag is /cvmfs/cms-bril.cern.ch/cms-lumi-pog/Normtags/normtag_BRIL.json. It contains the best-available preliminary calibrations and can be used for cases when an approved number is not available yet (i.e. for 2023-2024).

3.1 Query fill 8333 using the physics normtag

Using the physics normtag, what is the recorded luminosity in picobarns for fill 8333?

3.2 Query fill 9666 using the BRIL normtag

Using the BRIL normtag, what is the recorded luminosity in picobarns for fill 9666?

Data Certification

Data collected by CMS is certified on a luminosity-section basis to determine the subset of data of good quality to be included in physics analyses. Data certification is carried out by taking into account both the operational health of the sub-detectors and scrutiny of the reconstructed physics objects by DPG and POG experts. The outcome of the certification process is regularly updated as more data gets collected, and for each new version of the data processing, by the DQM-DataCertification. One of the main deliverables of this process are JSON files listing runs and lumisection which are good for physics analysis.

Key Points

• Make sure to use a normtag when querying brilcalc for your analysis

• Data collected by CMS needs to be evaluated and a subset is certified as good quality data to be used for physics analysis