CMS Pixel History Client


The pixel history client, as part of the CMS data quality monitoring (DQM) system, is to monitor the variations of pixel detector performance with respect to time in order to help diagnosing chronic problems such as aging of detector and slow changing in voltage, temperature or the environment.


The pixel history client is an EDAnalyzer in CMSSW. It consists of two processes - one retrieves pixel detector performance values from concurrent DQM MonitorElements (MEs) per run and records them into a database (DB); the other reads the performance values back and plots them vs. run number.

  • Writing to DB
    At the end of run (or luminosity section in the future) the pixel history client
    • retrieves MEs from the following (all the pixel) DQM sources
      • DQM/SiPixelMonitorRawDataError
      • DQM/SiPixelMonitorDigi
      • DQM/SiPixelMonitorCluster
      • DQM/SiPixelMonitorRecHit
      • DQM/SiPixelMonitorTrack
    • extracts pixel detector performance values out of the MEs,
    • fills the performance values in a defined summary table,
    • feeds the pixel performance summary table to the Oracle DB.

  • Reading from DB and Making History Plots
    At a separate time, one (expert, shift crew or any CMS user)
    • reads back from DB all or a specific range of run's pixel performance summary tables,
    • hooks up related digits, such as mean and rms of a certain performance variable, to plot the variations of pixel detector performance vs. run number.
    • web interface is being developed for advanced user-friendly history plot making.

  • Variables
    The pixel history client monitors the following pixel performance variables:
    • FED errors:
      • type 25: invalid ROC #25;
      • type 26: a gap word added to a 32-bit data word to make a 64-bit word;
      • type 27: dummy words added to generate minimum number of words;
      • type 28: nearly full FIFO 1, FIFO 2 or trigger FIFO;
      • type 29: timeout, i.e. data not sent from channel to FED in time;
      • type 30: TBM trailer showing errors such as invalid ROC, FSM error, data stream overflow;
      • type 31: event number mismatch between FED and TBM;
      • type 32: S-link header missing or incorrectly formatted;
      • type 33: S-link trailer missing or incorrectly formatted;
      • type 34: S-link trailer containing incorrect number of words;
      • type 35: invalid channel;
      • type 36: invalid ROC;
      • type 37: row or dcol value higher than allowable by module;
      • type 38: row or dcol value read out of order;
      • type 39: CRC error;
    • digis:
      • number of digis: number of digis in a module;
      • adc: charge of a digi in adc counts;
      • number of noise pixels: to be added;
      • number of bad/dead pixels: to be added;
    • clusters:
      • number of clusters: number of clusters in a module;
      • charge: charge of a cluster;
      • size: number of pixels contained in a cluster;
      • size X: number of pixels contained in the width of a cluster in the X direction;
      • size Y: number of pixels contained in the width of a cluster in the Y direction;
    • RecHits:
    • track residuals:
      • residual X: unbiased residual in X from a pixel hit to a track formed by more than 3 hits refitted without the hit;
      • residual Y: unbiased residual in Y from a pixel hit to a track formed by more than 3 hits refitted without the hit;
      • number of pixels used in track fitting: to be added.

  • Granularity
    The pixel history client can record pixel performance values
    • per FED and per module: 40 FEDs and 1440 modules;
    • per FED, per barrel layer and per endcap disk: the 1440 modules are in 12 barrel layers and 8 endcap disks.


The pixel history client can be run in your CMSSW_2_1_N pixel offline DQM release (N=10 as on 05.11.2008) on physics data.
scramv1 project CMSSW CMSSW_2_1_10
cd CMSSW_2_1_10/src
eval `scramv1 ru -(c)sh`
cvs co -r V00-03-08 DQM/SiPixelHistoricInfoClient
cd DQM/SiPixelHistoricInfoClient/test
The last step above will check out the correct version of SiPixelPerformanceSummary for the pixel history client to write to and read from DB with; it will scramv1 b in your project src area and go back to the previous DQM/SiPixelHistoricInfoClient/test directory. After successfully compiling CondFormats/SiPixelObjects and DQM/SiPixelHistoricInfoClient, you can proceed to run the pixel history client on your data.

Shifters only need to run the DB-writing process.

Before you run, identify the type of your input files:

  • DQM for harvest or pixel onffline DQM output root files, with MEs in the pixel DQM structure;
  • RAW for files in the CMSSW RAW data structure;
  • RECO for files in the CMSSW RECO data structure;
  • MC for files in the CMSSW RelVal MC structure.

The pixel history client uses different modules and different configurations to run on different types of input:

  • for DQM type of input, it uses the SiPixelHistoricInfoDQMClient module with scripts:
  • for CMSSW-structured types of files, it uses the SiPixelHistoricInfoEDAClient module with scripts:
the scripts filename runSiPixelHistoricInfoXXXClient_YYY_(template) where XXX = {DQM, EDA} and YYY = {harvest, RAW, RECO, MC} is informative; templates and non-templates only differ in 2 strings to be sedded, PoolSource fileNames and FrontierConditions globaltag. RAW and RECO scripts differ in SiStripRawToDigi, SiPixelRawToDigi and SiPixelMonitorTrack modules.

For each type of input, you have two ways to prepare and cmsRun the scripts:

  1. Open the right, edit PoolSource's fileNames (and FrontierConditions_GlobalTag's globaltag for RAW or RECO) and cmsRun it;
  2. List your input files in full path without quotes or comma in a text file, like DQM/SiPixelHistoricInfoClient/test/filelist.txt (and know your global tag name for RAW or RECO); then execute
./ [filelist] [filetype] ([globaltag for frontier condition])
  • DQM output or harvest root files must be on accessible afs area;
  • The amount of virtual memory that DQMStore can use to open DQM root files is limited by machine. If you encounter the problem of virtual memory exhaustion,
    • raise the virtual memory limit by limit vmemoryuse [amount in kbytes];
    • reduce the number of DQM files that you run in a single cmsRun process;
    • with vmemeryuse 3072000 kbytes, you can run 4-5 pixel offline DQM output files in a process.

RAW and RECO processes use MagneticField_cff and include DQM/SiPixelMonitorTrack by default. If you surely have SiStrip and SiPixel recHits in your data and therefore include the DQM/SiPixelMonitorTrack source in your process but know the magnetic field is not 3.8 Tesla, make the correction. For a 0-Tesla magnetic field, add after process.load("Configuration.StandardSequences.MagneticField_cff" process.load("Configuration.GlobalRuns.ForceZeroTeslaField_cff".

If you are interested in seeing pixel history plots including the runs of which the performance summaries are just written into DB by you, you can carry on to read SiPixelPerformanceSummary tables from DB and produce pixel history plots. For all types of input, it uses the SiPixelHistoricInfoReader module with scripts:

where the template and non-template only differ in the SiPixelPerformanceSummary tag string to be sedded.

For reading the pixel performance summary tables from DB, you have two ways to prepare and cmsRun the scripts:

  1. Open, edit and cmsRun with the following parameters to purpose:
  2. Execute ./ [filetype]
Either way, you will get a root file containing all the pixel history histograms you select to plot. If you don't like pixel history plots made by SiPixelHistoricInfoReader (the default value -99.9 is not plotted for visual ease), this root file can serve as an input to your own drawing macro like DQM/SiPixelHistoricInfoClient/test/SiPixelHistoricInfoPlotter.C.


Pixel performance summary tables should be written to oracle://cms_orcoff_prep/CMS_COND_PIXEL_COMM_21X in tag

Note records cannot be written to DB backward in time, i.e. SiPixelPerformanceSummary for Run 59999 or earlier cannot be written to the same DB in the same tag where SiPixelPerformanceSummary for Run 60000 or later has existed.

Pixel History Plots

Pixel history plots should be updated whenever new physics data become available. Before the common CMS history client web scheme matures, the pixel history plots are temporarily stored in the Rutgers physics department's web:

  • Lastest default appearance of a pixel history plot:


If you ever need the author's help or further information on the pixel history client, the ways of contact include

Latest Slides:


ShanhueiChuang a Suni October 2008

Edit | Attach | Watch | Print version | History: r32 < r31 < r30 < r29 < r28 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r32 - 2009-03-15 - ShanhueiChuang
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

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