LUMINOSITY FSM Guide

Introduction

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.

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.

STATE & STATUS

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:
OK
WARNING
ERROR

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 OR R OF: WARNING
  • 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

Luminosity

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 screen shows the following plots, labeled as:

  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
  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.

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

  1. Main:
    1. Table that is refreshed with the latest values displayed in the plots mentioned above.
    2. 24 hours peak quantities:
    3. Peak instantaneous luminosity
    4. Fill number with the maximum Integrated Luminosity (Delivered Total)
    5. 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. Average Number of Interactions per BX (BCID unaware; calibrated)
    2. Instantaneous Luminosity
  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 displays in a tabular format, all variables listed above. This tab also 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 also displays values plotted in the main panel in a tabular format.

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 two screen shots are of the LUCID display (main & Diagnostic RATIOS tabs selected respectively):

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

  1. Main
    1. Raw Instantaneous Luminosity
    2. Average Number of Interactions per BX (BCID blind; calibrated)
    3. Instantaneous Luminosity
  2. Diagnostic RATIOS
    1. LBav_rawInstLum_all to LBav_instLum_all
    2. Instantaneous Luminosity as computed from the detector’s algorithm to the Instantaneous Luminosity reported by the LHC.
    3. LBav_instLum_all to LBav_instLum_phys This node also has a side panel which shows all of the above in a tabular format and also keeps track of the detector’s preferred algorithm.

Detector Algorithms

-- ArjunTrivedi - 08-Feb-2010

Topic attachments
I Attachment History Action Size Date Who Comment
JPEGjpg ATLASLuminositySnapshot.jpg r1 manage 138.6 K 2010-02-13 - 17:58 UnknownUser  
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 LHCLuminositySnapshot.jpg r1 manage 104.0 K 2010-02-13 - 12:16 UnknownUser  
JPEGjpg LUCID_Diagnostics_Snapshot.jpg r1 manage 127.5 K 2010-02-13 - 12:17 UnknownUser  
JPEGjpg LUCID_MainSnapshot.jpg r1 manage 126.5 K 2010-02-13 - 12:17 UnknownUser  
JPEGjpg LuminosityFSM.jpg r1 manage 25.8 K 2010-02-13 - 12:18 UnknownUser  
JPEGjpg LuminosityNodeSnapshot.jpg r1 manage 129.1 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
Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 2010-02-13 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

  • Edit
  • Attach
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