Introduction

The CDF collaboration consists of several hundred physicists from about 40 institutions. The goals of these physicists, as well as the computer resources available to them, span a considerable range. In spite of this diversity, it is extremely desirable to insure that all CDF analysis is done within a common framework. This approach allows code to migrate from one application to another (algorithms developed by users can easily be incorporated in the production analysis package, or can easily be borrowed by other users). It also allows physicists to shift from one project to another with a minimum of overhead. In addition, the existence of a common analysis framework encourages the development of high quality, reliable analysis tools since such tools can be used by the whole collaboration rather than by a limited subset.

In order to satisfy the needs of the CDF community, we therefore have developed a general control structure for driving CDF analysis programs. This structure can be used for Online Calibration and Monitoring, as well as for Standard Reconstruction and Dst Analysis. The ANALYSIS_CONTROL and BUILD_JOB packages together provide a mechanism for painlessly combining several independent subprograms, called modules, into a single executable image. In addition, the system supports a high level of run-time flexibility, thus allowing the user to easily modify the default running conditions without having to edit analysis modules he did not write and without having to relink his program. Among the features available to the user within his executable program are:

1. The ability to specify that only a subset of the linked modules should be run and the ability to override the default order in which these modules are run.

2. The ability to manipulate the histograms associated with a given analysis module. Each group of histograms can be independently booked, deleted, cleared, displayed and output to disk.

3. The ability to enter a "parameter override" menu for any modules that supply such menus. This facility allows a mechanism for changing cuts without relinking.

4. The ability to stop event analysis in the middle of an analysis path on the basis of information provided by an event selection or filter module. The package allows multiple analysis paths to be executed for each event and each path can have an independent set of filters. If an event passes the filter criteria for more than one path, the analysis modules common to the two paths will be executed only once. (An override mechanism is provided for the applications programmer who wishes to insure that his module will be run multiple times.)

5. The ability to specify multiple output streams. For each output stream, the user can specify what banks and record types will be retained. The user can also specify that only those events that pass a set of filter requirements or selected paths will be output.

6. The ability to specify the source of the input data. Options are currently available for reading events from disk or tape, for reading events from the online event buffer and for accessing the online data acquisition system over DECNET or TCPIP. The package allows the user to include other "input modules" in his link. For example, a Monte Carlo generator could be included as an input module.

7. The package provides a mechanism for handling modules that can be run with more than one set of default parameters (for example, different physics analyses might use the same electron finding code, but might change the values of the cuts used in that code). For such modules, the user can specify which parameter set he wishes to use and can require that the module be run several times for each event using different parameter sets.