Luminosity information is obtained from 6 ATLAS luminosity detectors (BCM, MBTS, LUCID, FCAL, ZDC & HLT) and the LHC. One of the ATLAS detectors is called the ‘preferred’ detector. Additionally, each ATLAS detector implements one or more algorithms, out of which one is the ‘preferred’ algorithm. Keeping this in mind, the following graphical architecture for the Luminosity node follows naturally.

Luminosity Monitoring Variables

A list of ‘luminosity monitoring variables’ were defined to be displayed in the ATLAS CR. Apart from the obvious variables like instantaneous and integrated luminosities, the list also includes a host of other variables that can be used for diagnostic purposes. These include quantities like the Dead Time from the Central Trigger Processor (CTP), beam parameters from the LHC, and ratios to compare the performance of various detectors & algorithms. In order to monitor the variables displayed, it will be useful to understand the basic steps of how the online luminosity is computed. The following diagram shows the 3 basic steps involved (for FCAL, the 2nd step is not applicable):

Raw data from each detector & algorithm is processed to obtain the average number of interactions per bunch crossing. The number so obtained is corrected for each detector’s non linearity. Non linearity corrections are obtained by studying the detector response for various interaction rates in Monte Carlo. For example, at low interaction rates, the #hits in a detector increases linearly. However, at higher rates, the #hits has a non linear dependence with the interaction rate.

From the average number of interactions per bunch crossing, the final luminosity is obtained by applying an external calibration constant. This constant is obtained during absolute luminosity measurements. When the LHC starts up at the end of this year, this constant will be obtained by comparing the interaction rate as measured by the detectors to the absolute luminosity obtained by the Van der Meer Scan. Before we have such a constant, the pp inelastic cross section will be used.

Additionally there are a few other concepts relating to the nomenclature of the variables that should be kept in mind:

  • An ATLAS run is made up of several Luminosity Blocks (LBs). A LB is a time interval (of the order of a minute) and is the period over which the integrated luminosity is calculated. By d ividing a run into several LBs, ATLAS can record luminosity more efficiently by removing any LBs that were affected by failures of the DAQ system, machine etc.
  • A lot of the variables are averaged over LB; thus the prefix ‘LB averaged’ (sometime shortened to ‘LBav’) often appear in the variable names.
  • In a LB, detectors can record data from ‘phys BCIDs’ or be ‘BCID blind’. In the former case, detectors record raw data only from BCIDs (Bunch Crossing Identity) in physics bunch group. In the latter, data is recorded from the start to the end of a LB without paying attention to BCIDs. Variables holding data recorded from ‘phys BCIDs’ often have a ‘_phys’ suffix, while ‘BCID blind’ variables have a ’_all’ suffix.
  • The ATLAS CR displays receive the luminosity monitoring variables from the 'OLC' (Online Luminosity Calculator). OLC is the program that receives and processes raw data from the detectors before sending them to the ATLAS CR displays. While most of the detectors provide (amongst other quantities) raw 'LB averaged' data to the OLC, for consistency check (and for detectors that do not provide 'LB averaged' raw data), the OLC calculates its own LB averages. Such quantities appear with a prefix 'OLC'.

Following is a table that describes some of the variables that either appear explicitly in the displays or are used for computing a diagnostic ratio.


NOTE: Some variable names also have their shortened versions displayed in italics. These names are often used in displays to save space. (A.U. = Arbitrary Units)

Luminosity Finite State Machine (FSM) node

This section is meant to give a working overview of the Luminosity FSM.

The ATLAS Detector Control System (DCS) is a tree of FSM nodes, the highest node being ‘ATLAS’. The FSM nodes below represent detector hardware ordered hierarchically in a manner that makes for efficient control and monitoring. ‘States’ from lowest lying hardware units propagate upwards and ‘Commands’ downwards. Each FSM node can be programmed to have an allowed set of ‘States’ & ‘Commands’. Without going into any additional detail, here is the structure of the Luminosity FSM:

The Luminosity FSM is relatively simple in its implementation of the FSM nodes. Unlike other sub systems that monitor and send commands to actual hardware units, the lowest lying nodes of the Luminosity tree are ‘virtual’ Device Units. They are abstract entities representing luminosity information from the LHC and per ATLAS detector. The two Control Units are Passive i.e. they don’t send any Commands, but only monitor the States of the virtual devices.


The following snapshot shows the STATE & STATUS conditions are that appear in the FSM:

The nodes have the following STATEs defined:

Apart from STATE, each unit also has a STATUS. While the STATE defines the “operational mode of the system”, the STATUS gives additional details about “how well the system is working” (ATLAS DCS, FSM Integration Guideline, A. Barriuso Poy and S. Schlenker). The latter can be used in cases, for example when LUCID is reporting luminosity from its preferred algorithm, but one of the other algorithms stops reporting data.

For the virtual Device Units corresponding to ATLAS luminosity detectors & the LHC, the possible STATUS is:

They are defined as,

If Detector is preferred:

  • All Algorithms ON: OK
  • Any Algorithms OFF: WARNING
  • All Algorithms OFF: ERROR
If Detector is not preferred:
  • All Algorithms on: OK
  • Any or All Algorithms OFF: WARNING

For virtual Device Units corresponding to LHC:

  • L & R ON: OK
  • L & R OFF: ERROR

L & R correspond to the left and right BRAN respectively.

Propagation of STATE & STATUS in the Luminosity FSM

As one would expect, the top level node in the tree should be make the shifter aware of any anomaly in the FSM nodes below. Thus, STATE and STATUS propagate upwards in a manner that reflects any of the error conditions defined above. However, in the Luminosity FSM, there is an exception for the propagation of STATE in the ‘ATLAS Luminosity’ sub node. From the lowest level Device Units comprising the ATLAS luminosity detectors, the flow of state upwards depends only on the states of BCM and LUCID:

  • If LUCID or BCM is READY, then overall ATLAS Luminosity node STATE = READY
  • If LUCID and BCM NOT_READY, then overall ATLAS Luminosity node STATE = NOT_READY

For now, the states of the other detectors are ignored while determining the overall state of the ‘ATLAS Luminosity’ node since only BCM & LUCID are capable of monitoring luminosity on a bunch by bunch basis. The following snapshot illustrates how the STATE of the ‘ATLAS Luminosity’ is READY, even though LUCID & FCAL are NOT_READY. This is because BCM is READY.

Details of the Displays

NOTE: All values in the displays were randomly populated by me for testing purposes


This is the top level display in the tree structure:

In this screen, the idea it to display the monitoring variables from the LHC and ATLAS preferred algorithm & detector. The display is divided into two tabs, 'Main and 'ATLAStoLHC'. The 'ATLAStoLHC' tab displays the values of Instantaneous Luminosity that ATLAS sends to the LHC. However, for monitoring purposes, the LB averaged Instantaneous Luminosity is shown in the Main tab (amongst other variables).

  1. Main
    1. LB Averaged Instantaneous Luminosity (BCID blind) (LHC & ATLAS preferred detector and algorithm)
    2. Integrated Luminosity
      1. LHC integrated Luminosity (Total Delivered Luminosity)
      2. ATLAS integrated Luminosity (Total Delivered)
      3. ATLAS integrated Luminosity (Total Usable)
      4. ATLAS integrated Luminosity (Total Recorded)
    3. Beam Currents
      1. Currents from both beams along with the totalLiveTimeFraction are plotted here.
    1. Instantaneous Luminosity (LHC & ATLAS preferred detector and algorithm)
      1. LHC instantaneous Luminosity
      2. ATLAS instantaneous Luminosity (preferred detector and algorithm)
      3. ATLAS specific Luminosity

The top level Luminosity node also has a side panel with three sub tabs, labeled:

  1. Main:
    1. 24 hours peak quantities:
      1. Peak instantaneous luminosity
      2. Fill number with the maximum Integrated Luminosity (Delivered Total)
      3. Integrated luminosity (Delivered Total) from the above fill.
  2. Diagnostics (not selected in the Screen Shot):
    1. The ratio of the ATLAS LBav_instLum_all to the ATLAS LBav_instLum_phys.
    2. nbrPhysBunchPairs
  3. meanBunchCurrents (not selected in the Screen Shot):
    1. The bunch currents averaged over a LB (LBav_meanBunchCurrentB1/B2)
    2. ATLAS specific luminosity (ATL_specLum)
  4. invBeamLifeTime (not selected in the Screen Shot):
    1. Inverse beam life time for both the colliding beams (B1/B2_invLifeTime).
    2. totalLivetimeFraction

ATLAS Luminosity

‘ATLAS Luminosity’ (along with ‘LHC Luminosity’) forms the second level in the hierarchy of the Luminosity tree. The main purpose of the ATLAS Luminosity node is to give an overview of the luminosity as reported by the all the ATLAS luminosity detectors (Detailed luminosity information for each detector can be seen in the dedicated tree nodes per detector, which form the 3rd level in the hierarchy). Below is a screen capture of the ATLAS Luminosity Node.

The node is divided into two tabs which displays the following information per detector:

  1. Main
    1. LB Averaged Number of Interactions per BX (Depending on the detector, the legend of the plot states if it is calculated from phys BCIDS or is BCID blind
    2. Instantaneous Luminosity
    3. LB Averaged Instantaneous Luminosity (Depending on the detector, the legend of the plot states if it is calculated from phys BCIDS or is BCID blind
  2. Diagnostic RATIOS (not selected in the Screen Shot)
    1. Ratio of the each detector’s Integrated Luminosity (delivered Total) to the ATLAS preferred detector’s Integrated Luminosity (delivered Total)
    2. Ratio of the each detector’s LBav_instLum_all to the ATLAS preferred detector’s LBav_instLum_all

This node also has a side panel which keeps track of the preferred ATLAS Detector and its preferred Algorithm.

LHC Luminosity

This node displays the instantaneous and integrated luminosity as reported by the LHC. This node’s side panel displays the names of the LHC detectors used to measure luminosity.

LUCID Luminosity

(I am going to use LUCID as an example to describe the 3rd level hierarchy formed by nodes dedicated to each luminosity detector. The other detector nodes are similar with only minor variations)

The purpose of this tab is to monitor in detail the luminosity as computed from every algorithm implemented by LUCID and diagnostic variables to track the same. The following 4 screen shots are of 4 different tabs of the LUCID display:

The display has 4 tabs which displays the following per algorithm:

  1. Main
    1. Raw Instantaneous Luminosity
    2. Instantaneous Luminosity
    3. LB averaged Instantaneous Luminosity (phys BCID)
  2. LBav; BCID blind
    1. LB averaged Raw Instantaneous Luminosity (BCID blind)
    2. LB averaged Number of Interaction per BX (BCID blind; calibrated)
    3. LB averaged Instantaneous Luminosity (BCID blind)
  3. LBav; phys BCID - This tab shows the same quantities listed above, except the averages are computer using only phys BCIDS
  4. Diagnostic RATIOS
    1. LB averaged instLum (BCID blind)/LB averaged rawInstLum (BCID blind)
    2. LB averaged instLum (BCID blind)/LB averaged instLum (phys BCIDs)
    3. LB averaged instLum (OLC BCID blind)/LB averaged instLum (BCID blind)

This node also has a side panel which keeps track of the detector’s preferred algorithms and their statuses.

Detector Algorithms

-- ArjunTrivedi - 08-Feb-2010

Topic attachments
I Attachment History Action Size DateSorted ascending Who Comment
JPEGjpg DetectorAlgorithms.jpg r1 manage 62.2 K 2010-02-13 - 12:15 UnknownUser  
JPEGjpg GraphicalStructure_LuminosityNode.jpg r1 manage 22.0 K 2010-02-13 - 12:15 UnknownUser  
JPEGjpg LuminosityFSM.jpg r1 manage 25.8 K 2010-02-13 - 12:18 UnknownUser  
JPEGjpg STATESTATUS.jpg r1 manage 19.9 K 2010-02-13 - 12:19 UnknownUser  
JPEGjpg STATESTATUSsnapshot.jpg r1 manage 21.7 K 2010-02-13 - 12:19 UnknownUser  
JPEGjpg STATEtable.jpg r1 manage 19.0 K 2010-02-13 - 12:20 UnknownUser  
JPEGjpg dataFlow.jpg r1 manage 32.9 K 2010-02-13 - 11:08 UnknownUser Online Luminosity Data Flow to ACR
JPEGjpg VariablesTable.jpg r1 manage 191.5 K 2010-02-22 - 15:50 UnknownUser  
JPEGjpg ATLASLuminosity_Diagnostics_shot.jpg r1 manage 190.4 K 2010-03-03 - 12:42 UnknownUser  
JPEGjpg ATLASLuminosity_Main_shot.jpg r1 manage 238.0 K 2010-03-03 - 12:41 UnknownUser  
JPEGjpg LHCLuminosity_shot.jpg r1 manage 176.8 K 2010-03-03 - 12:43 UnknownUser  
JPEGjpg LUCID_Diagnostics_shot.jpg r1 manage 207.3 K 2010-03-03 - 12:43 UnknownUser  
JPEGjpg LUCID_LBav_all_shot.jpg r1 manage 228.5 K 2010-03-03 - 12:42 UnknownUser  
JPEGjpg LUCID_LBav_phys_shot.jpg r1 manage 230.0 K 2010-03-03 - 12:42 UnknownUser  
JPEGjpg LUCID_main_shot.jpg r1 manage 225.9 K 2010-03-03 - 12:42 UnknownUser  
JPEGjpg Luminosity_shot.jpg r1 manage 225.0 K 2010-03-03 - 12:41 UnknownUser  
Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r6 - 2010-03-03 - KurtBrendlinger
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback