LHCb Data Quality Procedures for 2008


The proposed procedure for assessing data quality is:
  1. The LHCb shifters will look at the monitoring histograms and trigger alarms in case of problems. Problems will be filled into the problems database.
  2. A daily meeting will discuss the problems that decide if green light can be given for processing. There can be three possible outcomes:
    • All is OK. Start processing.
    • Something is bad but can be fixed offline. A bug patch and new Brunel version is needed, or a calibration job should be started (and new database tagged). We have a few days of grace period at 2 kHz full running. This is explained here.
    • Something is bad and will take a lot of time to be investigated. Start processing anyway.
  3. The reconstruction happens and the DQ shifter looks at the output histograms. The regular meeting decides on a DQ flag to be set in the bookkeeping for every file (but likely to be discussed at run level). This flag is set by a DQ expert.
  4. Reconstructed files flagged as OK get stripped.
  5. Offline jobs analyse the stripped data to look at higher level monitoring.
  6. Stripped data considered OK gets tagged as good for physics.

Steps 4-6 will be expercised, but probably not be very useful in 2008. Everyone is likely to look at the whole data, not only stripped data.

Daily Meeting

The DQ meetings will happen every afternoon (time to be defined) in the offline control room (bld 2). Evo connection will be available, including possibility to connect from the pit for people who cannot come to Meyrin. The meetings should be kept short.

The meeting will the place where the knowledge transfer will happen

  • between what happened at the pit affecting the data and the data quality,
  • between the DQ and calibration experts and the offline for further processing.
It is the place where one will decide about which runs to process (or not) with which versions of Brunel (reco) and DaVinci (stripping) and which version of the database. Consequently it is the place where one will decide about new tags in the database and new versions of Brunel.

The meeting is run by the DQ shifter and will be attended by

  • the relevant subdetector DQ shifters (picket?)
  • the calibration (alignment...) pickets
  • the production shifter,
  • the run shifter,
  • anyone interested.

DQ Shifts

In 2008 everything will be a bit experimental and undefined. Therefore we need people with a good knowledge of the LHCb software and the people behind it. We thus propose to have one shifter who would have the responsibility that the necessary actions to ensure a smooth processing are taken.

The shifter would have to make sure that the data coming out of the pit can be processed. The shifter would have to

  1. Attend the run meeting in the morning
  2. Understand the problems which could affect DQ and identify who would have to solve them if possible.
  3. Make sure new versions of Brunel and the database are made, tagged.
  4. Test the new release using calibration data.
Once the data is sent for further processing the shifter would
  1. Retrieve and look at control histograms
  2. Identify and report problems
All this would be reported at the daily DQ meeting.

-- PatrickKoppenburg - 22 Aug 2008

This topic: LHCb > DataQuality > DQProcedures
Topic revision: r3 - 2008-08-29 - unknown
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 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