SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Comp. Search
Who's who?
Meetings
FAQ Homepage
Archive
Environment
Administration
New User Info.
Web Info/Tools
Monitoring
Training
Tools & Utils
Programming
C++ Standard
SRT, AFS, CVS
QA and QC
Remedy
Histogramming
Operations
PromptReco
Simulation Production
Online SW
Dataflow
Detector Control
Evt Processing
Run Control
Calibration
Databases
Offline
Workbook
Coding Standards
Simulation
Reconstruction
Prompt Reco.
BaBar Grid
Data Distribution
Beta & BetaTools
Kanga & Root
Analysis Tools
RooFit Toolkit
Data Management
Data Quality
Event display
Event Browser
Code releases
Databases
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

Production QA for SP1

This page describes the role of QA in the production process, for SP1. For specific information on each of the production steps see the relevant documentation for the individual QA Production packages : QaSimTools, QaSimAppTools, QaRecoTools.


  • Results for SP1 (Bear & SimApp)
  • The structure of the QA production tools
  • Step-by-step instructions for running QA in production
  • table for selecting references - QA now provides some flexibility for selecting references if no exact datatype match exists
  • Subsystem contacts for SP1





    For each of the QA Production packages, there are two scripts for running the relevant executable :

    In production, the relevant QA script is sourced at the end of a job by a script which performs local end-of-run tasks.

    See directory $BFROOT/prod/mgr/ :

    PRODUCTION STAGE end-of-run production script Qa production script QA executable
    BBSIM local-wrapup qasim_prod QaSimToolsApp
    SimApp local-mixr-wrapup qasimapp_prod QaSimAppToolsApp
    Reco local-reco-wrapup qarun_prod QaRecoToolsApp

    At the start of production with a new release, no up-to-date reference files are available, so the first 10K events are compared with references from an older release. If the results are acceptable, then these 10K events are used to create a new set of references for subsequent comparison tests during the production.

    A set of references is needed for each different run type which the QA Production Tools use in their comparison tests. Examples of run types used for QA in previous releases are shown below :

    QaSimTools (release 6.10.6) QaSimAppTools (release 6.10.10) QaRecoTools (release 6.10.10)
    B0 -> pi+ pi-, B0~ -> X

    B0 -> X, B0~ -> pi+ pi-

    B0 -> D*(2010)- pi+, B0~ -> X

    B0 -> X, B0~ -> D*(2010)+ pi-

    B0 -> D*(2010)- l+ nu, B0~ -> X

    B0 -> X, B0~ -> D*(2010)+ l- nub

    e+e- -> x x~ (x=u,d,s,c,b,tau)

    single mu- 500MeV-4GeV

    B0 -> X, B0~ -> K*0~ gamma

    B0 -> D*(2010)+ D*(2010)-, B0~ -> X

    B0 -> D*(2010)+ D*(2010)-, B0~ -> X (weighted mix)

    B0 -> X, B0~ -> J/psi(e+e-/mu+mu-) X

    bhabhas

    radiative bhabhas

    mu-pairs

    B0 -> D*(2010)- pi+, B0~ -> X

    B0 -> D*(2010)- l+ nu, B0~ -> X

    e+e- -> x x~ (x=u,d,s,c,b,tau)

    B0 -> X, B0~ -> pi+ pi-

    B0 -> X, B0~ -> D*(2010)+ l- nub

    B0 -> pi+ pi-, B0~ -> X

    B0 -> D*(2010)- l+ nu, B0~ -> X

    B0 -> D*(2010)- pi+, B0~ -> X

    B0 -> X, B0~ -> D*(2010)+ l- nub

    e+e- -> x x~ (x=u,d,s,c,b,tau)


    Step-by-step instructions for running QA in production

    1) Create the executable in the QA space: $BFROOT/QA/QaXXXTools/XXX_prod_exec. For example for
        QaRecoTools it is $BFROOT/QA/QaRecoTools/reco_prod_exec :
     
     

    unix@slac> cd $BFROOT/QA/QaRecoTools/reco_prod_exec
    unix@slac> newrel -t x.y.z release_xyz
    unix@slac> cd release_xyz
    unix@slac> addpkg QaRecoTools (or any specific tag)
    unix@slac> gmake QaRecoTools.all

    2) The executable which taken by the production script should be under:                           $BFROOT/QA/QaXXXTools/XXX_prod_exec/current/prod/$BFARCH

        Two remarks:

    3) There are two options of analysis which can be used: Hbook or Dhp. This can be set in QaXXXTool.cc with the variable analysisCase. If it is equal to 1 it means that you use hbook.
    If it is equal to 2 it means that you're using Dhp.
     

    4) A call to the QA script (qarun_prod, qasim_prod, qasimapp_prod) is done in the production scripts $BFROOT/prod/mgr/local_wrapup_xxxx. The QA scripts should be under $BFROOT/prod/mgr
     

    5) In order to make reference data, you need to follow the instruction written at the following link.

    6) In the case where you want to use Dhp. The warning of the histogram are written in the log file or/and a CMLOG GUI interface. You have the ability to retrieve these warnings on the GUI by following
    these instruction:

            In the first window, you start the CMLOG server. I use the example of a server on shire00.
     

    shire00@slac> source $BFROOT/QA/QaXXXTools/mgr/QaCmlog.setup
    shire00@slac> source $BFROOT/QA/QaXXXTools/mgr/QaCmlog.server

            In the second window (any sun machine), you start your CMLOG GUI:
     

    sun@slac> source $BFROOT/QA/QaXXXTools/mgr/QaCmlog.setup
    sun@slac> source $BFROOT/QA/QaXXXTools/mgr/QaCmlog.gui

    If you want to use another machine than shire00 as a CMLOG server. You need to change the    CMLOG_HOST variable to the name you want. This should be done in the three scripts: QaCmlog.setup. QaCmlog.server, QaCmlog.gui

    7)The threshold probability for warning is set to 0.001 for all the histograms in the file:

    $BFROOT/QA/QaXXXTools/current/QaXXXTools/QaXXXHists.data
       

    DEFAULT_THRESHOLD_PROBA         0.001
    SUB_SYSTEMS 7

    The variable is named: DEFAULT_THRESHOLD_PROBA and can be changed any time.
     
     

    If needed, you can change this value for a specific histogram in the following file:

    $BFROOT/QA/QaXXXTools/current/QaXXXTools/refdata/QaXXX_Limits++_RELEASE.data

    I take the example of QaSimTools, where this file looks like:
     
     

    NUMBER_HISTOGRAMS 2
    ------------------------------------------------------------------
      Histogram_title                          Threshold_Probability
    ------------------------------------------------------------------
    I.P. Vertex position: y                         0.0
    gtime  (DCH) (nsec) coarse                      0.0 

    In this example, I set the threshold for 2 histograms to 0 which means essentialy no warning.

    8) During,the production. everything is done automatically. If there are warnings you get e-mails. The runcharts are updated automatically. You just need to update the run numbers and releases available.
    This should be done in :

    $BFROOT/doc/Computing/www/QA/QaXXXTools/RunChart/General/retrieve.html


    modified 23 June, 1999, Chris Hawkes