DØ "How To" Guide to
How To Use the DØ Software Releases
| Page updated January 22, 2003 |
This document describes how to use the DØ software releases.
The first step in using DØ software is to choose the release in which you will work. DØ has two types of releases - development and production. Each release represents a complete set of DØ software, organized into various CVS packages (CVS is the DØ code management system). Each CVS package has a set of developers ("czars") who may modify that package, as well as a "sub-system coordinator", who is responsible for managing a group of related packages. A list of the releases currently available on disk on the DØ Fermilab computing systems is available. A list of CVS packages and their developers / coordinators is also available.
Production releases are labelled pxx.yy.zz and are typically built quarterly (every three months). They are intended to be used for official processing (e.g. online, Level 3 triggering, Monte Carlo generation, data reconstruction, etc.), and are stable and tested. Developers who are working on self-contained projects, or users looking for certified programs should use a production release. However, before using a particular executable in a production release, you should determine the status of that executable. For example, the status of the offline reconstruction program (RECO) is documented on the Algorithms group web page. Occasionally, there are known problems with a particular executable within a production release, and users should consult the appropriate group's web site before assuming a program is fully operational.
Development releases are labelled txx.yy.zz (also called "t" or "test" releases) and are built every week (yy is the week and xx is the year of the build). If you are developing new software, or need to use the absolutely lastest version of some package, you will use a test release. However, note that these releases change every week, and are by their nature unstable. If you need to use a development release, you are usually best off with the one from the preceeding week. The current week's build will dissappear and reappear on a nightly basis, as developers attempt to fix any problems introduced with new versions of software. On Fermilab computing systems, releases are deleted after a few weeks (governed by available disk space).
A new test release is built each week. The first build of the week occurs Monday evening. Requests for new versions of software to be included must be made by 3PM (Chicago time). Incremental builds are then made daily, including any bug fixes to fix problems. At the end of the week, the release is frozen, and made available for export to remote sites.
When a release is ready for general use, it is frozen. A "tar ball" is created, which can be used to install the release on a remote system. In addition, the parameters used to control the various algorithms are written into the RCP database for use when running programs. The RCP system is used to input "Run Control Parameters" (for example, parameters used to control various reconstruction algorithms), and a database is used to keep track of these parameters. While a release is being prepared, it is possible that a RCP parameter might change. Once the release is ready for distribution, the final version of these parameters are "frozen" (i.e. copied into the database). Users should be very careful not to generate any data files that are intended for long-term use using a release that has not been frozen, since the official parameters controlling algorithms may have changed. In fact, the RCP system will not allow users to analyze any files generated with a build "in progress". If you get an error from the RCP system referring to a "RCPID" that is "xxx 2" (the "2" indicates the RCP was created during the build of a release), then you are using a file created before the release was frozen.
To use a particular release, you must first set up that release. Assuming that you are using a Fermilab computing system:
This will set up many standard products (KCC compiler, ROOT, python, etc.). If you are going to be checking out software from the code management system, you will also need
For a given release, users can choose to use either optimized or non-optimized code. Typically, optimized code runs twice as fast, but non-optimized code is easier to debug. By default, the above selects the non-optimized build. To switch to using the optimized build,
To switch back:
Note that the optimized build in the current week's test build is not made until the end of the week.
On Fermilab computing systems, releases are installed on disk in
In this area, you will find links to each CVS package comprising the release. In addition, you will find the following generally useful directories
Many of these directories will contain two sub-directories, corresponding to the optimized (maxopt) and non-optimized (debug) builds.
Details about the status of a particular release are available in the results directory, and may be of general interest. In the appropriate maxopt / debug sub-directory, you will find several build*.* files: .begin, .bin, .codegen, .d0omgen, .end, .include, .init, .lib, .log. These files are created at various stages of building the release, and you can determine whether a particular build has started (a .begin exists) and ended (a .end exists). You can also determine how many builds have occured for this release, by looking at the build*-nn.begin files (nn is incremented for each build). Finally, the log files from compiling and testing each package within the release are available in the corresponding compile and test sub-directories in results. Users having problems with a particular package or program may wish to consult these logs, to determine if an error occured during the build of the release.
Even more details are available in the tmp directory. Until a release is frozen, the actual results from testing each package is available, and can be consulted to see is you are experiencing an error that has already occured (and presumably is being investigated by the developers). However, the tmp directory is cleaned up when the release is frozen, and so this is only useful for the weekly development build.
This page maintained by Harry Melanson