-- PeterMichaelFitzhugh - 2022-03-22

Introduction

The Detector Control System (DCS) Calculator is a defect calculator, used at the ATLAS detector at CERN. For every subsystem in ATLAS, a change in the value of a variable (eg. High voltage, Temperature) can cause a change in the quality of data retrieved at ATLAS. To help quantify this, the DCS Calculator is designed to retrieve the DCS information from COOL for every subsystem of the ATLAS detector for a given run and to assess what fraction of sub-detectors were in sub-optimal conditions and for what luminosity block periods they were. The function of the data quality process is to decide which data produced at ATLAS is suitable for physics analysis. For this purpos, the DCS Calculator can be used as a method of automatically assessing the quality of any run data given to it.

The DCS Calculator works by reading the DCS conditions for each run from the COOL database from each subdetector (e.g High Voltage, Low Voltage, Initialization of electronics). It then performs simple checks calculating the fraction of the Interval of Validities (IOVs) in the run that meets the specified requirements (e.g “HV at nominal setting”). Based on this fraction primary defects are then set. The general rule applied is that a run will be considerd bad if a greater than 10% amount of the subdetectors are not using optimal settings.

The DCS Calculator allows the user to specify which sub-detectors they want to analyze and for which runs/ luminosity blocks.

This Twiki Page is aimed at helping users understand the role the DCS Calculator plays in physics analysis at ATLAS, how to install and get the DCS Calculator working, how it works, including how it retrieves data and decides whether a run is bad or good, and how to modify sections to add functionality.

How the DCS Calculator Works

The flowchart below shows how the DCS Calculator works step-by-step. Start at the top left and follow the arrows, with each new row representing a different function that is named to the left of the row.

Installation Instructions

Previous Installation Instructions can be found on the previous Twiki page at the following link: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/DcsCalculator2. These should still be applicable now.

The repository for the DCS Calculator and its code can be accessed at https://gitlab.cern.ch/atlas/athena/tree/master/DataQuality/DCSCalculator2

DCSC File Structure

The DCS Calculator (DCSC) consists of 6 main .py files: *dcsc.py

• main.py
• variable.py
• subdetector.py
• libcore.py
• The relevant subdetector .py files (mdt.py, rpc.py etc)

dcsc.py: Called by the user in the terminal and is used to initialize all the sub-detector classes and to call the main function in main.py

main.py: Checks that all the extra arguments the user called (Can be seen in the other twiki page mentioned above) and that the range specified is compatible as well by checking that the relevant COOL folder for that range has IOVs that can be retrieved. Then the DCSC calls each of the subsystems sequentially to retrieve data from the corresponding COOL folder.

variable.py: Initializes the class 'DCSC_variable' which is responsible for: Reading Data from COOL, Determining the 'Good' state of a variable when called from the COOL database, and quantizing the state from time-based intervals to luminosity blocks.

subdetector.py: Initializes the class: 'DCSC_Subdetector' which is responsible for: merging IOVs with the same subsystem chamber, calculating the Dead Fraction, and assigning an output chamber ID to each IOV.

libcore.py: Used to map the channel IDs retrieved from the COOL folder to their channel name given by the sub-detector .py files.

Each subdetector.py file contains the relevant chamber ID mappings and the conditions by which a variable of a subsystem is considered 'Good' or 'Bad'.

The DCSC also calls functions from DQUtils in Data Quality in Athena for various other functions such as reading the data from COOL.

DCSC Operation Procedure

The DCSC Starts of by calling dcsc.py, which calls main.py and checks that the user inputs are good (See above). The DCSC then goes through the following steps for each sub-detector separately and sequentially.

Reading From COOL

The DCSC reads the relevant data for the variables of the chosen sub-detectors from the COOL library, which can be accessed via an online data viewer at https://coolr.web.cern.ch/ext/web/coolrui/index.html. The data that is collected is the IOV data for the given run or luminosity block range (depending on the one specified by the user.). This is done separately for each variable of the sub-detector, meaning that there will be separate IOV lists for each variable. Even though the DCSC specifies the range to be given in term of runs or luminosity blocks, the DCSC reads the data from the COOL folders using real time values. Each IOV will consist of the chamber ID, the time interval of the IOV, and the specific variable values for the chosen variable (Example seen below):

These are some of the variables that are stored in the COOL folder for the MDT chamber HV variable, later on the voltage variables will be used to determine whether each IOV can be considered good or not.

Determining Whether each IOV is Good or Bad

Each Sub-detector has its own list of variables that it calls from the COOL database, the measurement of these variables is used to decide whether a specific IOV is considered 'Good' or 'Bad', these conditions can be found in the respective functions of the variable in the .py file for each respective sub-detector:

MDT Sub-detector

HV: High Voltage, Considered 'Good' if the HV value is above 3050V LV: Low Voltage, Considered 'Good' if the LV is On JTAG: Considered 'Good' if the JTAG is initialized

TGC Sub-detector

HV: How Voltage, Considered 'Good' if the HV is On

RPC Sub-detector

HV: How Voltage, Considered 'Good' if the HV is On

For every IOV in a run for every Sub-detector, the DCSC appends a tag to the IOV defining whether if the IOV is considered 'Good' or 'Bad' based on the conditions defined in the .py file, these IOVs are then grouped according to this state. For example, If there was 10 IOVs in a row for a specific chamber that were considered 'Good' and the next IOV was considered 'Bad' for one variable the first 10 IOVs would be merged together for this specific variable.

Mapping Channel IDs to Channel Names

From the COOL folder the Chamber IDs are given and stored as a number for each IOV, The next stage of the DCSC is to convert these numbers into the corresponding chamber name. For most subsystems the mapping can be found in the respective .py file and usually defines whether a given chamber ID belongs to the A or C side, the end cap or the barrel, in which case, the chamber IDs are already in a correct order and requires a simple mapping. For a Sub-detector such as the MDT, the mappings are more complicated due to the fact that each MDT chamber is given its own unique ID. For these cases, a mdt_codes.dat file is provided with the DCSC to find the correct chamber name for a given corresponding ID. After this process each IOV should consist of a Goodness rating, chamber name, and an interval duration.

Grouping IOVs by Channel Number

The next step of the DCSC is to take all these IOVs and further merge them so that one channel ID corresponds to one IOV. Whilst merging the IOVs if any of the IOVs have there status set to 'Bad' the merged IOV will have a 'Bad' status as well. Only by having every merged IOV being considered 'Good' will give a 'Good' status for the combined IOV. At the end of this procedure the IOVs are combined across variables as well so one chamber has one IOV consisting of every variable. Once again, whilst merging, if one of the IOVs is considered 'Bad' the resultant merged IOV is considered 'Bad'.

Appending Output Channel to IOVs

The output channels are represented by the numbers 302,303,304,305 which correspond to the 4 sections of the detector, BA, BC, EA, EC and says where the chambers are located in the ATLAS detector. These numbers are appending on to each individual IOV depending on what the dictionary provided by the DCSC says where each chamber name is located in the detector. At this point in the DCSC, The IOV gives information on the chamber name, output channel, The IOVs 'Goodness', and the range of the IOV given in luminosity blocks.

Calculating the Dead Fraction

The final step of the DCSC is to now calculate the final Dead Fraction, the final output of the program. To do this, the remaining IOVs are combined together further via their output channel and into IOVSets, usually with several IOVSets for each section of the detector for a normal run

Once this is done, for each new IOVSet, the number of 'Good' and 'Bad' IOVs are counted for each one and the fraction of the 'Good' IOVs are calculated. The bad fraction is therefore 1 - this fraction. If the bad fraction is above the specified tolerance (Usually 10% of IOVs) the IOVSet is flagged as bad and will be printed during the final printout along with the specific bad fraction value

Final Printout

At the end of the DCSC program for a run, the final printout of the DCSC will look like this:

Each Line of the output represents a group of IOVs for a specified luminosity block range, as seen by the two numbers after the run number. The next line 'MS_MDT_BA_STANDBY_HV' specifies which sub-detector it is we are looking at and in which section of the ATLAS detector we are looking at, in this case it's the barrel A-side. The Bad Fraction number displays the fraction of the IOVs in each grouping that are considered 'Bad' by the DCSC, since all these values are greater than 0.1, the DCSC displays the 'True' output for each line to show that the DCSC has flagged these IOVs as not suitable for physics analysis.

Topic attachments
I Attachment History Action Size Date Who Comment
svg DCS.drawio.svg r1 manage 196.7 K 2022-11-03 - 10:04 PeterMichaelFitzhugh
jpg DCS_output.jpg r1 manage 306.8 K 2022-04-13 - 13:57 PeterMichaelFitzhugh
png Screenshot_2022-11-03_at_10.14.30.png r1 manage 362.3 K 2022-11-03 - 10:16 PeterMichaelFitzhugh
png flowchart.png r1 manage 1204.6 K 2022-03-22 - 14:36 PeterMichaelFitzhugh
Topic revision: r8 - 2022-11-03 - PeterMichaelFitzhugh

 Home Sandbox Web P View Edit Account
 Cern Search TWiki Search Google Search Sandbox All webs
Copyright &© 2008-2022 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