3.3.1.1 Design Principles

Major design principles that influenced the development of Athena were:

• Abstract interfaces. These allow for the provision of different implementation providing similar functionality but optimized for particular environments (e.g. high-level trigger and offline, different persistency technologies). They also allow for easy manipulation of groups of components sharing a common interface.
• Extensive use of dynamic libraries and loading implement the Gaudi component architecture.
• A clear separation between data and algorithms. For example, the interface that allows access to the data of a track (e.g. its 4-momentum) is separated in different classes (and usually different packages) from the algorithmic code responsible for finding and building tracks given a list of track segments. At first sight, this separation appears to violate one of the main principles of object-oriented software, encapsulation, but the opposite is actually true. By separating the complex algorithmic code that is responsible for the construction of the track objects from the much simpler and more stable client view of a track, the dependencies between the producer of a track object and its consumers are drastically reduced. This approach facilitates, for example, the transparent change at run time of the track-finding strategy without having to recompile or to reconfigure downstream particle identification algorithms that are clients of track objects.
• The recognition that there are many types of data having different lifetimes within the software. Event data is directly associated with an ATLAS event, but detector information such as the geometry, alignment and electronics calibrations is in general stable across many physics events and therefore has a different lifetime. Similarly, statistical data accumulated in histograms is long-lived compared to the data of an individual event.
• A clear separation between persistent and transient data. In general the algorithmic code operating on the data should be independent of the technology used to store it, which might vary over the lifetime of the experiment, or depend upon the local environment (e.g. within the trigger data acquisition and offline environments).
• Recognition of multiple types of developer. Thus the code written by the end-user physicist should be exposed to relatively few, simply interfaces, and be isolated from that written by the tracking specialist or persistency expert.
• Attempt to re-use components and interface standards where feasible.

3.3.1.2 Major Component Abstractions

The major components that have been identified within the architecture are shown in Figure 3-1. This shows component instances and their relationships in terms of navigability and usage.

Figure 3-1 Athena Component Model

Major components are:

• Application Manager . The application manager is the overall driving intelligence that manages and coordinates the activity of all other components within the application. There is one instance of the application manager and it is common to all applications.
• Algorithms and Sequencers . Algorithms share a common interface and provide the basic per-event processing capability of the framework. Each Algorithm performs a well-defined but configurable operation on some input data, in many cases producing some output data.

A Sequencer is a sequence of Algorithms, each of which might itself be another Sequencer, allowing for a tree structure of processing elements. A filter Algorithm can indicate that the event being processed fails to meet its filter criteria and inhibit the processing of downstream Algorithms.

• Tools . A Tool is similar to an Algorithm in that it operates on input data and can generate output data, but differs in that it can be executed multiple times per event. In contrast to Algorithms, Tools do not normally share a common interface so are more specialized in their manipulation. Each instance of a Tool is owned, either by an Algorithm, a Service, or by default by the AlgToolSvc.
• Transient Data Stores . The data objects accessed by Algorithms are organized in various transient data stores depending on their characteristics and lifetimes. The event data itself is managed by one store instance, detector conditions data, such as the geometry and alignment, by another store, etc.
• Services . A Service provides services needed by the Algorithms. In general these are high-level, designed to support the needs of the physicist. Examples are the message-reporting system, different persistency services, random-number generators, etc.
• Selectors . These components perform selection. For example, the Event Selector provides functionality to the Application Manager for selecting the input events that the application will process. Other types of selectors permit the selection of objects within the transient data stores.
• Converters . These are responsible for converting data from one representation to another. One example is the transformation of an object from its transient form to its persistent form and vice versa.
• Properties . All components of the architecture can have adjustable properties that modify the operation of the component. Typically these are basic types (integer, float, etc.), but can also be specified as having upper and lower bounds.
• Utilities . These are C++ classes that provide general support for other components.

3.3.1.3 Concrete Athena Services

One of the strengths of a common architecture is the accumulation of services useful to developers of algorithmic code. To start with, the Athena developer has available an array of core "system" services for job configuration, message logging, error handling, job tracing, performance monitoring and resource management.

• Job Option Service. The JobOptionSvc is a catalogue of user-modifiable properties of Algorithms, Tools and Services. As an example, the value of a cone radius cut "ConeR" in the JetConeFinderTool named "ConeJets.ConeFinder" can be set either from a job-option file or from the Athena interactive prompt (see Section 3.3.1.4 , "Scripting") by:

ConeJets.ConeFinder.ConeR = 0.7

Default values are set in the Algorithm, Tool or Service itself.

1. Logging and Error-handling . The MessageSvc controls the output of messages sent by the developers using a MsgStream. The developer specifies the source of the message (its name) and the message verbosity level. The MessageSvc can be configured (using the JobOptionSvc) to filter out messages coming from certain sources or having a high verbosity level. Future implementations of MessageSvc are expected to log messages to a production or online database and to send critical error messages also to the (production or DAQ) operator console.

When an Algorithm throws an Exception during the execute phase, it is caught and passed on to the Exception Service, which allows the users to manipulate the outcome. The service can be configured via job options to change the meaning of an exception from a failure to a success or recoverable error, to the status code of an associated GaudiException, or to re-throw the exception to a lower level, on a per-Algorithm or global basis.

2. Performance and Resource Monitoring . The AuditorSvc and the ChronoStatSvc manage and report the results of a number of Auditor objects, providing statistics on the CPU and memory usage (including potential memory leaks) of Algorithms and Services. A TimeKeeper service monitors the remaining CPU time available to a job running in batch and terminates the job when it estimates that there is not enough time left to process a new event.

In addition to these generic tools, Athena provides many domain-specific tools, to record data-processing history, manage event and detector data, manage random-number generation, histogramming and n-tuples, and provide access to PDG [3-5] particle properties.

• HistorySvc . The ability to recreate the initial conditions of a particular event-processing job is of utmost importance. The History Service records the state of all Services, Algorithms, AlgTools, and run-time parameters and environment variables at the beginning of the job, using the appropriate type of History Object. Furthermore, whenever an object is registered with StoreGate1, it creates an associated History Object that records the object type, classID and store that the object is saved into, as well as using the AlgContext Service to determine which Algorithm was being executed when the object was created. All these objects are linked in a hierarchical manner, allowing the user to navigate from the DataHistory Object all the way back to the JobHistory Object.
• Histogramming and N-tuples . The Histogramming and n-tuple services allow one to book, fill, manipulate and analyse histograms and n-tuples from within the Gaudi framework. Pre-existing histograms and n-tuples can also be imported from persistent storage. These services use abstract interfaces, so that the concrete implementation of each service can be changed if necessary, as has already been done with the transition from HTL [3-6] to ROOT [3-7] for the implementation of the histograms.
• Access Time-Varying Data . The Interval of Validity Service (IOVSvc) manages the automatic updating of conditions data. Users can request a smart pointer to the appropriate conditions data, knowing that it will always be kept up to date without their intervention. Furthermore, callback functions can be registered with the service, so that when a conditions object enters a new range of validity, the callback function is triggered, allowing users to recalculate cached information. Callback functions are registered in a hierarchical manner, and are triggered according to their dependency tree. Users can choose when to check the ranges of validity - at every event, at the start of every run, or just once at the beginning of the job - to customize the level of database access, an important consideration for trigger-level activities. Also, users can force the service to preload the values of all ranges and related conditions objects at the beginning of the job, to eliminate all further database access during the course of the job.
• Random Numbers . The ATLAS Random Number service uses the RanecuEngine of CLHEP [3-8], and supports multiple streams, each stream being able to provide an independent sequence of random numbers. The initial seeds of each stream can be set via job options.

3.3.1.4 Scripting

There are two primary motivations for scripting within the Athena framework. The first is for configuration, taking advantage of the component architecture to build applications that are tailored for particular capabilities from a pool of available components. Thus the configuration should be able to specify the set of Algorithms and Services that are to be used, modify their behaviour by specifying overrides to the default Property settings, and specify any needed input or output files.

The second motivation is to provide support for interactivity, allowing the user to modify a static configuration and allow for rapid feedback from changes to, for example, tracking road widths, p _T thresholds and rapidly reprocessing a set of events so as to optimize the configuration for a later job over a larger event sample.

Athena uses a common scripting language, Python [3-9], for both the configuration and interactivity roles. So-called "Python bindings" are provided to its core abstractions, in particular the application manager, services, algorithms, histogramming, data store, etc. Scripting provides support not only for configuration and interactive use, but also for steering/control and interoperability with alternative front-ends to Athena. (The latter are not described further here.)

Python is a popular, open-source, dynamic language with an interactive interpreter. Like C++, Python is a multi-paradigm language and provides such concepts as modules, classes, exceptions and very high-level dynamic data types, etc. There are interfaces to most system calls, a large set of standard libraries, and bindings to many existing third-party applications and libraries. Initial scripting support for Athena was provided by an implementation of a Python scripting service conforming to the IRunable Service component abstraction. However, initial experience indicated that greater flexibility could be had by complementing this with a Python script that starts and runs the Athena Application Manager directly, using Python bindings to the core Athena abstractions.

Athena jobs are configured by specifying the set of Algorithms, Services, and other components to be used, as well as their Properties. This is done through the scripting interface, which transports the settings to the appropriate Athena components, or provides place-holders until the components are available. Since Python is a complete programming environment, end-users and package providers can write higher level interfaces on top of the Athena configuration facilities. This is often done to provide (semi-)automatic configuration based on a couple of basic, or initial settings.

The main Athena Python control script is simply a user interface on top of a set of scripts and modules that provide a programming interface at a more abstract level of steering than do the Athena component interfaces. It parses user command-line options, loops over configuration files, and sets some common defaults. The scripts/modules, all written in Python, with the code that performs the actual work, such as reading the configuration files, responding to settings, etc., are used in conjunction with other main Athena programs as well (in particular athena.C, and athenaMT).

The scripting facilities support interactive use of Athena; once the Python prompt has been reached, typically upon completion of the initial application configuration, actual instances of the components can be accessed, thus allowing their properties to be examined and modified. New components, possibly written in Python, can be loaded and configured, objects in the transient data store can be examined and their data can be plotted, and the event processing loop can be run completely in Python. New functionality can be built on top of the interactive layer, using third-party packages or parts of the Python standard libraries (e.g. the Python SimpleXMLRPCServer). An interactive physics analysis environment based on Python is under development.