Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Det. Search
Who's who?
Intern. region
Vertex Tracker
Drift chamber
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

EMC Edge Correction CDB Loading for Production

This page describes the procedure to load the Emc edge correction constants, that are applied to EmcCand objects during reconstruction, to the MASTER Conditions Database. It is essential that you first check whether you can load the constants successfully into your own private conditions database.

The procedure below works for the case when the constants are stored in 4 array-type objects ("CdbTables") with the names
  • /emc/EmcEdgeCorrTheta
  • /emc/EmcEdgeCorrPhi
  • /emc/EmcEdgeCorrThetaSigma
  • /emc/EmcEdgeCorrPhiSigma
The first two represent the mean values of the theta and phi corrections, while the last two are the edge correction widths for theta and phi. The energy correction is the multiplication of the mean values of the theta and phi corrections. This correction is ignored if it is more than 10%. More information about the edge correction parameterisation can be found here.

If there are changes to how the EmcEdge correction is implemented, or to the structure of the correction tables, then the procedure outlined below will probably work with some tweaking. Everything in bold red below denotes something you must type on the command line.


  • Before proceeding with the loading procedure, make sure you have permission to upload the constants to the MASTER conditions database by first filling in the request form, and also notifying people on the relevant hypernews:

    It is a good idea to first familiarise yourself with the loading procedure mentioned below before filling in the above form, since the actual loading may have to be done within a strict time-schedule.

Building loading executable

  • First create a test-release at SLAC on a Solaris machine (Linux cannot be used for the loading - read about the reason here). Choose a production release that has EmcEdgeCorr objects that understand what to do with the given constants (i.e. have the correct "schema"). For example, choosing 19.4.1b:
  • newrel -s $BUILD -t 19.4.1b emc1941b

    where $BUILD is an environment variable that specifies the location of your afs/nfs space that stores the compilation libraries and binaries. You can change the name of the test-release directory ("emc1941b" above) to anything you like. Immediately run


    in the "emc1941b" directory above. Then add the following packages to your test release:

    addpkg EmcEnv; addpkg EmcEnvP; addpkg EmcCalibToo; addpkg CdbAdmin;
    addpkg workdir; gmake workdir.setup

    If the constants you want to upload require changes to the structure of the EmcEdgeCorr class (i.e. a new "schema"), then you need to addpkg the appropriate tags of EmcEnv/EmcEnvP/EmcCalibToo. It is essential that any such changes are first mentioned, discussed and approved by the relevant hypernews groups/experts before loading anything new to the Conditions Database:

  • You now need to compile the code in EmcEnv, EmcEnvP and EmcCalibToo. In order to do this, you must first have a private database. There are a number of steps involved:

    • Put a .bbobjy file in the "emc1941b" test-release and run the command


      The .bbobjy file must at least a valid FD number:


      If you don't know what numbers you can use, please run the command GetFDID and it will tell you. Make sure that OO_FD_BOOT environment variable points to the location of your private database at this stage, and not the MASTER conditions database! For example "echo $OO_FD_BOOT" reveals:

      /nfs/objyserv07/objy/databases/user2/< username >/< FD_NUMBER >/BaBar.BOOT
    • Create the private database by doing:

      gmake database.import

      gmake database.load

      There is no need to create a full snapshot - just the bare minimum is required for compilation.

  • Compile the code and link the database loading code for the edge correction constants in the usual manner:

    bsub -q bldrecoq -o gmake.log gmake lib EmcEnvP.extrabin
  • The EmcEnvP.extrabin target in the above gmake command tells the job to build the EmcEnvP/EmcTableBdbLoad executable that will load the constants into the database. After successful compilation/linking, go to the next step.

Loading Procedure

    First, you must have permission from the relevent people (see above) to load the new constants into the MASTER conditions database. You also need to read the instructions given here and here.

  • Make sure you are in the workdir directory of your "emc1941b" test-release. Make a soft-link to the CdbAdmin package:

    cd workdir; ln -s ../CdbAdmin .

  • There is a perl script available which simplifies the commands you need to use in order to load in the constants. It is called loadEmcTables, and should go into your workdir directory. This is the latest version of the script, and slightly differs from the one in the EmcEnvP package in CVS. To make the script work, you need to specify various things:

    • Valid file names of the 4 tables of constants mentioned in the introduction of this page. They need to be specified in the "@dataFile" array near the top of the loadEmcTables perl script. The latest text files for the constants are specified below:

    • A valid time interval for the constants, specified by the $beginTime and $endTime variables near the top of the loadEmcTables perl script, for which the constants are valid.

      Currently in release 18 processing, this range is "01Jan1970 12:00:00" to "+Infinity", since the constants are valid for all MC and data. Note that the validity starting time for MC is "01Jan1970 12:00:00". If you want to have different constants for MC and data, then you need to use the correct input text files, as well as the correct validity dates.

  • After the above steps, you should now specify the location of the MASTER conditions database file:

    • Set the location of the MASTER conditions database:

      setenv OO_FD_BOOT < location >

      where you must specify the directory of the MASTER conditions database for < location >.

    • Make sure you can write to the MASTER conditions database. Run the two commands:

      BdbAuthCmd lsusers C | grep "(SYS)" | grep `whoami`

      BdbAuthCmd lsmembers C "cdb" | grep `whoami`

      If your SLAC username does not appear in either list, then email BdbSOS to get permission, specifying the name of the MASTER boot file.

    • Set the verbose output flag

      setenv BDBDEBUG1 cout

      This prints out detailed messages during the loading procedure which you need to cut-and-paste into a text file.

  • Now run the loadEmcTables perl script:

    perl loadEmcTables

    • It will first print out some messages about what you are about to load, which input text files you are using, and for what time interval you have specified. Please check that the dates, condition names and filenames are correct. If they are correct, then type y (for "yes") at the first question prompt "--> proceed? (y/n)". If not, just type n (for "no") and the script will gracefully exit.
    • The script will then ask you whether you want to create the objects into the database. They should already be in the MASTER conditions database - choose n ("no") here, otherwise the loading will go horribly wrong. Only choose y ("yes") if the objects are not in the MASTER database (unlikely). If you think you may do a mistake here, edit the script to always put "no" here, or comment this section out.

    • The script will then ask you whether you want to load in the new constants ("Load tables in CDB? (y/n)"). Choose y ("yes") if you are happy about the validity dates, condition names and input text files.
    • Cut-and-paste the complete loading output into a text file, and then do

      unsetenv BDBDEBUG1

      to stop the database printing out detailed messages in the next few steps you need to do.

  • After successfully loading in the new constants, you need to set the revisions for each of them. Another perl script called puts in all the required steps outlined here. This script should go into your workdir directory. The only things you would need to change are

    • Uncomment the relevant conditions name, specified by the $condName variable.
    • Choose a meaningful revision name and description:

      $unix = "CdbManager create_revision \"$myCond\" \"Insert Revision Name Here\" \"Put Description Here\" 0";

      The name and description of the revision must not conflict with others already in the database. To check, run the command CdbBrowser config command on the given conditions object, e.g.

      CdbBrowser config "/emc/EmcEdgeCorrPhi".
  • Run the perl script for all 4 conditions objects, and savethe screen output into text files:


Checking Constants and Final Steps

  • To check whether the new constants are visible in the database, you can run the command within workdir
  • EmcTableBdbLoad find_object /emc/EmcEdgeCorrPhi < valid-time >

    where < valid time > is a valid (database) time for the given condition object "/emc/EmcEdgeCorrPhi". You can repeat this command for the other objects/validity times. The screen will print out the entries in the CdbTables, which should of course correspond exactly to the entries given in the original input text files.

    You can also inspect the validity intervals for your constants:

    CdbBrowser objects "/emc/EmcEdgeCorrPhi"

  • Email both the database loading and revision steps output to the relevant hypernews:

    The constants should then be swept into the relevant data/MC databases on Monday by the experts (around 11am SLAC time).

John Back