In the whole guidance, it is assumed that you're interested in looking at runs which have been processed in Event Reconstruction (ER). This is the second step of the processing -- after the Prompt Calibration (PC) -- which is made with more statistics than the first step. Therefore, it is the suitable processing to test the runs QA.

• The package RqmRootTreeTools is release-independent so any recent release should be fine. Yf you're using a too old release, you may have trouble in processing the root QA files. To run properly, the ROOT version of your release must not be older than the one which was used by OPR to produce the files. So, if you have such problems, compare the releases and update yours if needed.

• Checkout the package in your test release. You can get the head version with addpkg -h RqmRootTreeTools but it is not guaranteed to be working fine. It is safer to find the last official tag (VXX-YY-ZZ), either in the Data Quality Hypernews or directly in the CVS repository. The current manager of this package is Frank Winklmeier -- his term ended September 1rst but nobody was found so far to replace him.
• Compile it:
  gmake lib
  gmake bin
• Go to your workdir. Copy in this directory the file ER_Default.tcl from the RqmRootTreeTools package. Before running the QA code, you should customize this file which is used to setup your job's parameters.
  By default, the program will pick up the tcl in your workdir and will ignore the file present in the RqmRootTreeTools directory. You should avoid touching that file to make sure you won't commit your personnal setup in the CVS archive.
  Make sure to modify the following parameters before running any job.
  • Replace <MAIL:NO> (default option) by <MAIL:YES> to ensure that an e-mail summarizing the run-by-run automated checks is sent at the end of each job. Otherwise, you'll have to scan the logfiles to find the runs which did not pass your full set of automated checks which is not very convenient.
  • Later in the file, set all systems but the DIRC to 'NON ACTIVE': <ACTIVE:XXX:NO>, XXX being the subsystem ID. Make sure that the DIRC 'ACTIVE' flag is setup: <ACTIVE:DRC:YES> -- otherwise DIRC QA won't be checked! Keeping only the DIRC active will allow you to save CPU time as by default all subsystems are 'ACTIVE'. Turning off all subystems but the DIRC is harmless as the DIRC tests are independent from the other subsystems.
  • Close to the end of the file, you will see the list of experts which will get the automatic e-mails produced by the QA job. If you're not in the list, add your e-mail: <MAILTO:DRC:your e-mail>. To avoid spamming other experts, make sure you commented out all other e-mail addresses!
• Finally, copy the perl macro checkRuns.pl in your workdir. This macro is home-made and aims at launching QA jobs more easily.

• RqmMakeAll processes a list of runs which can be provided on two different formats which are mutually exclusive (don't mix them in the same input file!).
  1. <run number> <processing>
     example: 55402 P18.1.0cV00fb
  2. Absolute paths pointing to the OPR ROOT files
     example: /nfs/babar/DQG/hbook/ER3/18.0.4c/35698-P18.0.4cV00fb.merged.root.gz
  For weekly QA checks, the RQM (currently Mark Tiller) prepares lists of runs in both format and makes them available on the Stripcharts webpage. The RQM sends an e-mail to the Data Quality Hypernews when a new list is available: one has usually 2-3 days to check the runs before the DQG meeting held on Thursday morning @ 10.30.
  The RQM also runs RqmMakeAll on the run lists he's producing ⇒ you'll get automated messages as well. But I find more convenient to rerun the jobs on my own: first, the RQM may not use the latest version of RqmRootTreeTools; second, he/she doesn't use the DIRC specific functionnalities (Run-dependent stripchart ranges, DIRC-customized stripchart plots production etc.) detailled below which make the QA checks easier and... faster!
• The list of runs should be in your workdir. To use the checkRuns.pl perl script (DIRC home-made), the name of the file must obey the following convention: runList-<tag>.txt where <tag> is the label you chose to identify this set of runs (for instance Run5-2005-11-10 for a list of Run 5 runs to be checked before the DQG meeting of November 10^th 2005).
• You also need to edit ER_Default.tcl again. Whereas the changes to this file described above had to be done once in your life of QA checker, the setup below needs to be adapted each time you're going to run a new job.
  • Set the run boundaries <RUNSTART_STRIP>, <RUNSTOP_STRIP>, <RUNSTART_QA> and <RUNSTOP_QA> . These variables define the range of runs included in the QA check such as the extend of the x-axis in all stripchart postscript plots. Be sure to start/stop at least 1 run before/after the first/last run number included in the run file: otherwise, the extreme runs will not be checked (code feature!). I never completely understood the difference between the two START/STOP parameters: the simpler is to set them to equal values.
  • ER_Default.tcl also allows one to setup parameters which are defined and used in a subsystem monitoring code (for the DIRC these are the files DircTreeMaker.cc/.hh and DircStripChartsCollection.cc/.hh). The DIRC code has three such parameters: <CONFIG:DRC:DRC_run>, <CONFIG:DRC:DRC_minNumErrors> and <CONFIG:DRC:DRC_countErrors>.
    The first one, <CONFIG:DRC:DRC_run>, is used to define the Run (note the capital 'R') during which the runs contained in the input list have been taken. The values of this parameter are currently 0 (default), 1, 2, 3, 4 and 5. As the data taking conditions have significantly evolved since the beginning of BaBar, the boundaries of the 'nominal range' associated with each stripchart have been made Run-dependent to ensure that the QA check parameters follow the evolution of data.
    The second parameter (<CONFIG:DRC:DRC_minNumErrors>) sets the minimum number of failed QA checks needed in a given run to trigger an automatic report for this run. RqmMakeAll adds this report in a text buffer which is sent to the subsystem expert(s) by e-mail when the QA check ends. For new runs which have never been checked before by the DQG group, it is safer to set this parameter to 1. If several tens (hundreds!) of reprocessed runs (i.e. which have been already checked in the past) have to be checked, increasing this parameter to 2 is a convenient way to prevent the log file sent by e-mail from being too big.
    Finally, uncommenting the last parameter (<CONFIG:DRC:DRC_countErrors>) by removing the '#' which starts the line makes the DIRC part of RqmMakeAll more verbose to ease the debugging of the code if needed.
• Then, you can launch the perl script:
  perl checkRuns.pl <tag> <Run Number> <Format>
  • <tag> is the file ID which you used to label the list of runs on which RqmMakeAll will run.
  • <Run Number> must be equal to the corresponding parameter defined in ER_Default.tcl (<CONFIG:DRC:DRC_run>, see above for details). It is an input of the home-made ROOT macro plotDircStripcharts.cc included in the RqmRootTreeTools package. Called by the perl script after RqmMakeAll, it produces a nice postscript file gathering all the DIRC stripcharts: the time evolution (vs. run number) and the histogram of each monitored quantity are displayed, with red lines showing the current limits of the nominal range.
  • <Format> is equal to 1 or 2 depending on the file format chosen. Its default value is 1 and so setting it is not compulsory if you're using the format <run number> <processing>. In this case, perl checkRuns.pl <tag> <Run Number> should work fine!
• You can also run RqmMakeAll directly without using the perl script. Examples of command are in the README file of the RqmRootTreeTools package. They can also be guessed by looking at the DIRC perl macro code. The output postscript files will also have generic names -- they are renamed in the macro code.

• A logfile called <tag>.rqmlog.
• Two ROOT files ER-new_<tag>.root and ER_<tag>.root which are analyzed in a second step by the ROOT macro plotDircStripcharts.cc.
• A postscript file showing the stripchart evolution 'a la RqmRootTreeTools': ER_<tag>.ps.


• A similar file produced by plotDircStripcharts.cc: DIRC_stripcharts_<tag>.ps. For each stripchart, two plots are displayed: on the left, the histogram of the variable; on the right, its evolution as a function the run number. Red lines show the boundaries of the allowed region for this stripchart.
• Various other files not interesting for QA.

1. to run RqmMakeAll of the list of runs as described above;
2. to check the QA plots of the runs which don't pass the DIRC automatic monitoring;
   [Bad runs are normally clearly visible: they fail most of the automated checks and the corresponding stripcharts often have crazy values (null occupancy etc.)]
3. to look at the DIRC QA stripcharts to have an overview of the run quality and to identify unexpected long-term evolution of some stripcharts -- like for instance a net decrease of the mean number of photons per track.