Draft 2.4
  06 July 2001

Technical Annex 1 to ATLAS Software Agreement No. 2001/01: Control Framework


This document describes, for the purpose of ATLAS Software Agreement No. 01/2001, the 'Control Framework' of the ATLAS software, and the task to be carried out under the terms of that agreement. The document includes a Definition of Terms, the Purpose and Scope, and the Schedule as presently defined.

Definition of Terms

Purpose and Scope

The Control Framework software provides the operating environment for all other software modules, and supplies mechanisms for the control of these modules, for data input/output to them, and for communication and co-ordination between modules. Such modules will usually be written by different people and groups, which makes careful definition and implementation of inter-module communication particularly important.

The Control Framework insulates the user from the underlying details of the operating system, data formats, and communication protocols.

The task is to develop this Control Framework for ATLAS, oversee its deployment, and provide documentation and user-support in a manner to be mutually agreed with those responsible for the ATLAS Quality Control and Documentation procedures.

The framework should be designed taking into account modern ideas on OO software engineering. The software should be written in C++, though the implications of a possible migration to another OO language in the long term should be considered. The software should allow modules written in any ATLAS supported language to gain access, perhaps with restrictions to features of the framework. The design should be such that the framework is independent of the underlying persistency mechanism(s).

As explained above, the Control Framework covers 'control' and a sub-set of the 'services'. However, the interfacing of the Control Framework software with all services is a task to be shared between the Control Framework task and the service provider, and requires close collaboration and co-operation with those providers.

A very significant service that must be provided via the Control Framework is the 'Data Dictionary'. The technical details for the Data Dictionary are set out in Technical Annex 2 of this Software Agreement.

There are significant requirements on the flexibility and robustness of the Control Framework, as indicated by the following non-exhaustive list:

The task is to be carried out within the context of the ATLAS Computing Management, under the overall co-ordination and technical leadership of the Computing Co-ordinator and Chief Architect.

The development should follow a cyclic and iterative model; intermediate versions should be released to the Collaboration, implementing increasing functionality. The major releases foreseen as of May 2001, and the functionality expected, are given below. It should be noted that the functionality includes aspects that are not part of Control Framework as defined here. The further development of the release strategy is part of the Control Framework task.

Schedule as of May 2001

Many of the deliverables are split into 'prototype' and 'deployed'. The first means that there is a proof-of-principle demonstration that is available to a limited set of testers; the second means that the deliverable is available to all developers/users within the context of an ATLAS developers' release. Deployment is not meant to imply that development ceases at that point. It is expected that many deliverables will have extended, iterative development cycles extending well past their nominal deployment.

Each deliverable is classified as 'Essential' (E) or 'Desirable' (D). This can indicate either some flexibility in a timeline, or a lower priority for desirable deliverables.

June 2001 Framework Milestone


  1. Data Dictionary prototype
    As discussed earlier, the Data Dictionary is covered by this Software Agreement, and detailed in Technical Annex 2. For completeness, the main deliverables are itemized here.
  2. Pile-up support prototype
    Demonstrate a framework to support merging of background events with primary events. Merging should be at least at the simulated Hit level.


  1. Detector Description prototype
    A strategy for access to time-varying information should be in place by this time, and a prototype implementation should be available to support further development studies.
  2. Particle Properties Service deployed
    The initial implementation of a particle property services was discovered to be inadequate for use by ATLAS. This milestone refers to a second-generation version, developed in conjunction with the CLHEP developers and LHCb experiment. The milestone is for that to be available for general use within the framework.
  3. Physics Analysis output/binding to JAS deployed
    JAS (the Java Analysis Studio) is one of the physics analysis tools that are being used by physicists for end-user analysis. The goal are are output of analysis objects in a persistent format capable of being input into JAS, and of a tighter binding allowing direct sharing of data between the Athena framework and JAS without the necessity for converting it to a persistent representation.
  4. Visualization prototype
    This milestone is for the prototype of a visualization service that will allow interaction between the user and a graphical representation of the detector an event information. This would replace the current Algorithm-based visualization which allows restricted interactivity.
  5. Service Management restructuring deployed. The goals of this are:
  6. Statistics and Monitoring Tools prototype
    This provides a mechanism for monitoring various aspects of the performance of framework-based applications (e.g. cpu useage and memory utilization) and facilities whereby application may gather and store statistical information such as histograms and n-tuples.
  7. Bookkeeping prototype
    This provides a mechanism for recording the conditions under which data were generated, including the job configuration details (which software versions and parameter values was used) as well as information summarizing the quality of the output.
  8. Java/C++ support prototype
    As well as the capability to wrap FORTRAN code fragments, it is desirable to demonstrate a tight coupling between Algorithms and Services written in Java. This prototype should demonstrate access to framework services from an algorithm written in Java.

September 2001 Framework milestones


  1. Detector Description deployed
    The prototype demonstrated in the May 2001 milestone should be deployed in an ATLAS release, and documentation should be available to allow subsystem developers to design and implement their specific versions.
  2. Data Dictionary deployed


  1. Visualization deployed
    The prototype delivered in June 2001 should be available within the context of an ATLAS release, and have supporting documentation.
  2. Statistics and Monitoring Tools deployed
    The prototype delivered in June 2001 should be available within the context of an ATLAS release, and have supporting documentation.
  3. Bookkeeping deployed
    The prototype delivered in June 2001 should be available within the context of an ATLAS release, and have supporting documentation.
  4. Full multi-language support (services and algorithms in Java)
    The co-existence of both algorithms and services written in either of Java or C++ should be demonstrated.

December 2001 Framework milestones

This is the first 'production' version. The primary target for this milestone is Data Challenge One.


  1. Bookkeeping deployed
    The prototype delivered in June 2001 must be available within the context of an ATLAS release, and have supporting documentation.


  1. Grid enabled prototype
    This version will incorporate Grid services and capabilities.

Further Framework milestones

Details of Control Framework milestones and deliverables for the years 2002 onwards have not yet been scheduled in detail. This schedule will obviously be based on the requirements of the overall Computing Milestones, in particular the Data Challenges, and the results from the ongoing Grid R&D projects and their impact on the Computing Model. However, it is expected that the major features to be delivered will include:

  1. support for a strategy for calibration and alignment handling based upon the ongoing detector description work, and with capabilities well beyond what will be available at the end of 2001. For example: the generation of new calibration and alignment information; the QA to be applied before such new information is accepted; how information from multiple processing nodes is going to be accumulated;
  2. extension of the initial pile-up prototype to encompass all detector subsystems, accommodating their different integration requirements;
  3. distributed histogramming capability to address the needs of the event filter and prompt reconstruction farms;
  4. parallel analysis support for large event samples;
  5. improved multi-language support, particularly for Java.