The Data Path
A summary based on postings by Teela and David H.
http://babar-hn.slac.stanford.edu:5090/HyperNews/get/DQG/1075.html
http://babar-hn.slac.stanford.edu:5090/HyperNews/get/DQG/1075/1.html

--IR2--

data:
 - raw data written to xtc files
 - calib-xtc produced from xtc files
 - both xtc and calib-xtc put into bstore (hpss)
 - xtc files pulled from bstore and transfered to Padova
   (cronjob on bbr-xfer02)

metadata:
 - run info written to Oracle bbrora.shift_run tables (elogbook)
 - xtc and calib-xtc info written to mySql (bfo-rdb100) opr tables
   (constants block (CB) database)
 - bbrora.shift_run and CB databases synched to Padova
   (cronjob on bbr-xfer02) this triggers new file transfer

quality control:
 - shifter marks run: ok, flawed, unusable, detector studies, (unmarked)
   in elogbook (bbrora.shift_run)

conditions:
 - ir2boot updated with detector conditions
 - some subsystems may load conditions by hand to ir2boot
 - ir2boot automatic snapshot taken every hour
 - ambientboot updated from:
   - ir2 once a day, starts 06:15 ends ~07:30
   - master once a week


--PC--

data:
 - pulls calib-xtc from bstore to local disk
 - must process runs sequentially, does not scale with lumi
 - PC1 for live data, PC2/3 for reprocessing
 - new runs submitted to PC1s queue with following criteria:
   - run has been done for 2 hours (to give time to QA)
   - Colliding Beams (OprMode=yes)
   - QA = ok or flawed
   - calib-xtc has >= 700 events

metadata:
 - run processing info written to Oracle bbrora.shift_oprrun
 - synched to Padova mySql using Kobi (every four hours)

quality control:
 - built in check that finalize node does not crash and
   so Rolling Calibrations are written
 - QA root and ps files available once run is 'done'
 - checked by DQG once a week

conditions:
 - PC1 loads latest ir2boot snapshot when needed
 - writes Rolling Calibrations
 - some pseudo-Rolling Calibrations written directly here by subsystems
 - automatic snapshot taken once a day (configurable) and
   loaded to Master
 - snapshot copied to disk in Padova (cronjob on bbr-xfer02)


--Master CDB--

 - conditions from PCs loaded once a day (push)
 - as part of PC1 snapshot loads also ir2boot info once a day
 - snapshot taken once a day (around 17:00) and loaded to cond18boot
 - many non-RC loaded directly to Master


--ER--

- Run Processing

data:
 - pulls xtc from buffer disk or tape (in Padova)
 - collections written locally on nodes, copied to datamovers

metadata:
 - run processing info written to mySql bbrora.shift_oprrun
 - synched to slac Oracle by Kobi every four hours

quality control:
 - QA root and ps files available once run is 'processed'
 - rsynched to slac QA area
 - 'done' runs checked by DQG once a week

conditions:
 - loads latest snapshot from relevant PC farm when needed
 - each ER farm is assigned one CDB
 - there are 2-3 mirror CDBs of each PC1/2/3 available

- Post Processing

data:
 - merges N collections per run on datamover into one collection
 - three streams (collections) written out:
   - AllEvents
   - TriggerStream
   - BackgroundEvents
 - tars all three collections together and copies tarball to
   export system

metadata:
 - updates entry in mySql bbrora.shift_run table
   'processed' to 'done' or 'merging failed' and topublish flag
 - adds collection and file info to bbrora tables
   linked to shift_oprrun
 - synched to slac Oracle by Kobi every four hours

- Publishing

 - bbk tool runs in cronjob and inserts/updates bbkr18
   Oracle tables at slac
 - loads ir2 information (read from Padvoa mySql bbrora.shift_run)
 - loads ER run processing info (read from Padvoa mySql bbrora.shift_oprrun)
 - loads collection (bbrora.shift_oprcoll_cm2) and
   file (bbrora.shift_oprdatafile) information

- Export System
 - pushes tar file from one processing of a run to slac (bbr-xfer03)
 - separate Padova mySql tables to do bookkeeping

- Import System
 - import scripts at slac running on bbr-xfer03
 - untars file and writes collections to kan cluster and hpss
 - updates is_local flag in bbk tables


--Data Quality Group--

 - once a week RQM makes a list of all new 'done' processings for
   the week for each run cycle (Run1-5)
 - RQM makes stripcharts from QA root files for PC and ER
 - QA ps files also available to look at individual runs

 - DQG meeting once a week (Thursday)
 - sub-system experts report (by HN and in person) on data quality

 - RQM updates DQG tables in Oracle:
  - Each PR processing in bbrora.shift_oprrun is linked to one record 
    per subsystem in bbrora.shift_qastatus + optional comment
  - Each subsystem marks a processing as good, flawed or bad.
     - Good is self explanatory
     - Flawed means this processing should not be used by a later one 
       might be OK
     - Bad means the data is never going to be usable
  - The RQM makes a global decision as to the state of the run
  - "RQM" system tag sets the global status of the processing
  - "CAL" system status is set to either Physics if the final 
    calibrations are ready or "Det. Study" if the data is only
    suitable for detector studies.

  - Every night (3am SLAC time?) a cron job checks all new DQG entries
    and updates the dse_status of the PR collections in the bookkeeping
    db.
    if unchecked, then dse_status = 0
    if( RQM=GOOD AND CAL=Physics ) then dse_status = 1
    otherwise dse_status = 2

  Note detector study runs are considered bad, so all runs are now 
  considered as "physics" to produce datasets early.

--Skimming--

 - finds and skims new processings (AllEvents collection) from
   bbk tables with is_local = 1
 - reads from cond18boot
 - each new AllEvents collection is broken into pieces, skimmed,
   and merged - sub-merge
 - skimmed collections merged over many runs (to get around M? events)
   only skimmed collections where the parent AllEvents collection
   is marked dse_status = 1 (DQG passed) is used in merge
 - dse_status of parent collection is given to skim collections

 - ? where is bcounting lumi info obtained and loaded to bbk
   tables or are there separate tables?

--Data Sets--

 - new collections (PR and Skims) which are marked:
   is_local=1 and dse_status=1 are added to open datasets
 - any collection whose status changes can be removed
   using extended syntax when needed
 - one dataset for each stream/skim broken up by run cycle (Run1-5)
 - tag of datasets are static, used to give to analysis users