Currently there are three active conditions federations that are used for analysis (and skim production):
| FDB | Use with release | Status | Update frequency | Snapshot to use |
|---|---|---|---|---|
| cond22boot | 22.x.x | open (mirror of MASTER) | daily - weekly | CDB snapshot |
| cond18boot | 18.x.x | frozen | only if requested | CDB snapshot |
| cond16boot | 16.x.x | frozen | only if requested | CDB snapshot |
| cond14boot | 14.x.x | frozen | only if requested | Special snapshot (Important!!!) |
Data are processed in the reconstruction farms (PR) and new conditions are produced. The corresponding analysis conditions federation has to be updated with these conditions so that by the time the new data are available to users the new conditions are present in the conditions FDB.
Certain conditions (e.g.: PID-tables) might not be present or needed during production but are loaded to the MASTER conditions federations. Therefore an update of an analysis conditions federation is required even if no new data are produced. These updates are announced and only done if requested.
The frequency of the updated depends on the conditions federation. For cond14boot and cond16boot no new events are produced and therefore an update is only need if new conditions needed for these federations were loaded to the MASTER.
Cond18boot has to be updated frequently as events are processed in PR continuously, either new data from the detector or old data are reprocessed with a new release. At SLAC cond18boot is updated daily as new processed data are made available on a daily base.
For remote sites cond18boot should be updated less frequently. The time lag between collections processed in PR, declared as good and exported to a remote site is larger then a week and therefore a weekly update is sufficient.
Cond22boot was created end of December 2006. It is a mirror of the MASTER meaning its local-name is master-core. It is used for 22-series BaBar software releases. Run6 data are processed in the 22-series. For run6 configurations (CfgDB) are not accessible in Objectivity but only in root snapshots. Therefore, it is required to have the root CfgDB installed.
So far there is only one cond22boot federation.
Users must use the cond22boot alias not the explicit bootfile
| Bootfile | FDB ID | usage |
|---|---|---|
| /afs/slac/g/babar-ro/objy/databases/boot/physics/V9/ana/0201/BaBar.BOOT | 201 | analysis |
| /afs/slac/g/babar-ro/objy/databases/boot/physics/V9/ana/0202/BaBar.BOOT | 202 | analysis (mirror) |
| Bootfile | FDB ID | usage |
|---|---|---|
| /afs/slac/g/babar-ro/objy/databases/boot/physics/V8/ana/0204/BaBar.BOOT | 204 | analysis |
Cond18boot was created end of March 2005 and has been frozen at the end of Dezember, 2006. It is a mirror of the MASTER meaning its local-name is master-core. It is used for 18-series BaBar software releases. Run5 data and Run1-4 are processed (or reprocessed) in the 18-series.
There are three cond18boot federation. The user must always use the cond18boot alias to access a federation, never the explicit bootfile name. Because of the heavy load on cond18boot by users and skimming a new FDB for skimming has been created (May 2006).
Users must use the cond18boot alias not the explicit bootfile
| Bootfile | FDB ID | usage |
|---|---|---|
| /afs/slac/g/babar-ro/objy/databases/boot/physics/V7/ana/0190/BaBar.BOOT | 190 | skimming |
| /afs/slac/g/babar-ro/objy/databases/boot/physics/V7/ana/conditions/BaBar.BOOT | 193 | default |
| /afs/slac/g/babar-ro/objy/databases/boot/physics/V7/ana/0194/BaBar.BOOT | 194 | mirror |
Cond16boot was established in September 2004. It is used for processing and analyzing data with Babar releases of the 16 series.
cond16boot was a mirror of the MASTER but has been frozen March 25th, 2005. Its local-name is now analysis16-core. Regular sweeps from MASTER to cond16boot will be performed as it will be used for early Run5 data (up to summer 2005). Because it has been frozen, new loaded constants to the MASTER have to be made visible for cond16boot. Read the instructions How to freeze cond16boot.
Constants are written into the MASTER and therefore cond16boot using Objectivity on Linux with gcc 3.x.x. Because of this older releases (14.x.x and older) will not be able to read from cond16boot.
Users must use the cond16boot alias not the explicit bootfile
| Bootfile | FDB ID | usage |
|---|---|---|
| /afs/slac/g/babar-ro/objy/databases/boot/physics/V6/ana/conditions/BaBar.BOOT | 191 | default |
| /afs/slac/g/babar-ro/objy/databases/boot/physics/V6/ana/0192/BaBar.BOOT | 192 | mirror |
Cond14boot is used for 14-series releases. Original it was a mirror of the MASTER but then it has been frozen (Sep 2004) and it uses the local-name, analysis14-core. Read the instructions How to freeze cond14boot.
A final sweep from MASTER to cond14boot was done 2005-03-31 using a snapshot from 2005-03-24. No more sweeps to cond14boot must be done. The reason is that the MASTER will receive conditions from the PC farms which were written with a linux release compiled with gcc3. Older Babar releases are not able to read this data. The CDB-only snapshot
/nfs/objyserv03/objyserv03/objy/snapshot2/master/analysis/lastCond14bootand the full snapshot
/nfs/objyserv01/objy/databases3/snapshots/forSP6/20050904are the only ones that should be loaded to cond14boot. All other snapshots will contain databases that can't be read by 14-series releases.
A reference (or mirror) cond14boot was established. It could be used to load new constants into cond14boot. A user would load new constants into the reference cond14boot. Afterward a snapshot (only analysis14-core dbs) is taken an swept to MASTER and cond14boot.
Users must use the cond14boot alias not the explicit bootfile
Below are the bootfiles for cond14boot:
| Bootfile | FDB ID | usage |
|---|---|---|
| /afs/slac/g/babar-ro/objy/databases/boot/physics/V5/ana/conditions/BaBar.BOOT | 198 | default |
| /afs/slac/g/babar-ro/objy/databases/boot/physics/V5/ana/0199/BaBar.BOOT | 199 | reference |