Tile SCR/DQ Shifter Manual


Data processing in ATLAS currently consists of two main steps. After a run has ended, the express trigger stream is reconstructed to provide a first glance at the Data Quality of the run. In the following 36 hours (calib loop), its essential to use this data to quickly identify and fix/mask problems. Providing the most up to date analysis of DQ for Tile is the main purpose of the SCR shift.

Role of the SCR shifter

* provide rapid analysis of Tile's DQ status
* assist DQ Leader/Validator with in-depth analysis of problems
* confirm appearance/disappearance of problems

Getting started

Browse the ATLAS e-log and compile a list of DQ problems noted by the Tile ACR shifter in the past 24 hours. The DQ Leader may also provide you with a list of problems to be checked as well. Sometimes problems come and go so it's also necessary to check up on problems that may have disappeared. There is also a list on the TileCalorimeterWhiteBoard . You can check a channel's status in the database using the handy MCWS tool.

Finding Run Numbers

For a collision run to be considered long enough to interesting (ie. requires DQ assessment), the integrated luminosity should be greater than 5 ub-1 . The Atlas Run Query can be used to quickly produce a list of runs with Tile and integrated luminosity >5 ub-1 for the past 36 hours. You should also have your own list compiled from Tile e-log entries. Starting at least one day before starting your shift, you should sign up for atlas-dataQuality-automatic-notifications e-mails. This list sends a daily e-mail with a list of runs to be checked.

Tile DQ Tools

Tier 0 Monitoring

The main tool for DQ assessment of collision runs is the Tier 0 display. This webpage will display a list of runs and trigger streams. For the most recent runs, you will see something like
  <run #>  ES1:  <AMI tags>           [express_express] [physics_CosmicCalo] [physics_ZeroBias] 

Crosschecking problems with Calibration runs

To fully investigate some problems, it may be necessary to look at results from calibration runs. The best tool for this is the TCWS webpage ( or this development version). Clicking on the "plots" icon for a given run will load a page with a drop down menu for each of the modules included in the run. Instructions on how to interpret the various plots are detailed in the Offline Shift Manual.
* Pedestal runs are useful for checking for noise since they don't have any signal. A hot spot in occupancy may be coherent noise that will probably be visible in pedestal runs.
* CIS runs scan most of the range of the electronics and are useful for identifying stuck bits and problems in the electronics.
* MonoCIS runs inject a constant charge so that the electronics stability can be tested.
* Laser runs are usually taken at a single amplitude in either the HG or LG. These runs are useful for identifying timing problems in digitizers.

Monitoring Histograms

ROOT Histogram files

Realtime DQ Tools

You can browse the DQMD output from the current run here. This is limited in scope since it only displays a limited set of histograms and only for tests that don't return a green status.


* DQ Coordinators - Rob Calkins (rcalkins@cernNOSPAMPLEASE.ch) and Giorgi Arabidze (giorgi.arabidze@cernNOSPAMPLEASE.ch)
* Run Coordinator - Vincent Giangiobbe (vincent.giangiobbe@cernNOSPAMPLEASE.ch)

-- Main.rcalkins - 2010-05-18 -- Main.rcalkins - 2010-05-26 draft version

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2010-05-26 - RobertCalkins
    • 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