| |
|
|
|
Chapter 3
Release notes and software installation
3.1 Release History
The Gaudi architecture and framework, which was initially developed by the LHCb collaboration, became a joint development project between several experiments, starting from release v6. At this time the package structure was modified, to split the experiment specific packages from the common packages. The following table reflects the version history since the re-packaging. For the history of earlier releases, please refer to previous versions of the (LHCb) Gaudi Users Guide.
3.2 Current Functionality
We use an incremental and iterative approach for producing the Gaudi software. We plan to expand its capabilities release by release. The functionality list that follows is organized by categories.
Interfaces
A set of interfaces that facilitates the interaction between the different components of the framework. Mainly these are interfaces to services.
Basic framework services
This set of services offer the minimal functionality needed for constructing applications. They are described in detail in Chapter 12.
The message service is used to send and format messages generated in the code, with an associated severity that is used for filtering and dispatching them.
The job options service allows the configuration of the application by end users assigning values to properties defined within the code; properties can be basic types (float, bool, int, string), or extended with bounds checking, hierarchical lists, and immediate callback from string "commands".
The Random Numbers service makes available several random number distributions via a standard interface, and ensures that applications use a unique random number engine in a reproducible fashion.
The Chrono service offers the functionality for measuring elapsed time and job execution statistics.
Auditors and AuditorSvc provide monitoring of various characteristics of the execution of Algorithms. Auditors are called before and after invocation of any Algorithm method.
The Incident service provides a synchronization between objects within the Application by using named incidents that are communicated to listener clients.
The Tools service, which provides management of Tools, is discussed in Chapter 13. Tools are lightweight objects which can be requested and used many times by other components to perform well defined tasks. A base class for associator tools has been added in this release.
Data services provide the access to the transient data objects (event, detector and statistical data). The data services are described in chapters 7 to 11. The basic building blocks for the implementation of the experiment specific data models are also described in Chapter 7.
Event data model
The event model has been extended to Velo, L0, L1 and updated for Calo. The current status is presented in Chapter 8.
Event data persistent storage
The current version provides a set of generic classes for implementing event data persistency (GaudiDb package) and a set of classes supporting persistent I/O to ROOT files (GaudiRootDb package). Details can be found in Chapter 14.
Input from event data files (or tapes) produced by SICB in ZEBRA format (RZ) is also supported. The ZEBRA banks are converted to C++ objects by specialized fragments of code (SICB converters). This conversion is available in the framework for a number of SICB banks. Adding more converters is possible and will be done on request. The event data produced by the application can be stored in ROOT files and retrieved later. This also requires to write specialized converters.
Histograms & N-tuples
The framework provides facilities for creating histograms (1 and 2 dimensional) and n-tuples (row and column wise) from user algorithms. The histogram interface is the AIDA1 common interface. Saving histograms and n-tuples is currently implemented using the HBOOK and ROOT format. The interface to histograms and n-tuples from the user code should not be affected if the persistency representation is changed later. Details of the histogram and n-tuple facilities can be found in Chapter 10 and 11 respectively.
Event tag collections
The framework provides facilities for creating and using collections of event tags for fast direct access to physics events. The event tag collections are based on an n-tuples implementation. The user can specify an event tag collection as input data to his/her application and perform sophisticated selections using the facilities existing in the data storage technology. This is explained in Chapter 11.
Detector description and geometry
The framework provides facilities for accessing detector description and geometry data. The logical structure of the detector is described in terms of a hierarchy of detector elements and also the basic geometry description in terms of volumes, solids and materials. Facilities for customizing the generic description to many specific detector needs are also provided. This allows the development of detector specific code which can provide geometry answers to questions from the physics algorithms (simulation, reconstruction and analysis). The persistent representation of the detector description is based on text files in XML format. An XML editor that understands the detector description semantics has been developed. A transport service is provided to estimate the amount of material between two arbitrary points in the detector setup. This is described in detail in Chapter 9.
Analysis services
A number of facilities and services are included in the current release to facilitate writing physics analysis code. The GaudiAlg package is a collection of general purpose algorithms, including a sequencer which uses the filtering capability of algorithms to manage the execution of algorithm sequences in a filtering application, as discussed in section 5.5. The Particle Properties service (section 12.5) provides the properties of all the elementary particles. Access to the CLHEP and NAG C libraries (Chapter 17) provides numerical utilities for writing physics algorithms.
Visualization services
The framework provides facilities for the visualisation of event and detector data. These services are currently based on the packages that constitute the Open Scientist suite (OpenGL, OpenInventor(soFree), Lab,...). An event and geometry display application has been built using these facilities. This is briefly described in Chapter 15.
SICB services
A number of services are included in the current release to facilitate the access to SICB data (detector description, magnetic field, etc.) and to facilitate re-using existing Fortran code with the framework. These services can be extended to accommodate new concrete requests when integrating big parts of the current legacy code (SICB). In the latest release there full support for event pile-up. It is possible to read events from two input data streams and merge them before any processing is done. Refer to Chapter 18 for more details.
Scripting services
The framework provides a service for interfacing Python with a Gaudi application. The user can interact with a Gaudi application from the Python prompt. The current functionality is rather limited, allowing the user to set and get properties from Algorithms and Services, and to schedule the execution of the application's algorithms with coarse control for the time being. This facility will be extended in forthcoming releases.
Dynamic loading of libraries
The framework can be used to implement different data processing applications for different environments. It is important that the services and their concrete implementations are extendable and configurable dynamically at run time and not statically. The latter would imply linking with all the available libraries producing huge executables. And in certain applications and environments some of the libraries will surely never be used. The framework provides support for dynamic libraries for the Windows and Linux platforms.
3.3 Changes in the new release
· The current release includes some re-packaging and changes in location of some include files, see section 3.3.1.
· The control of the "physics event" loop has been separated from the ApplicationMgr and has become a new component, the event loop manager. A number of subsequent specializations have been provided: MininalEventLoopMgr, EventLoopMgr, and GaudiEventLoopMgr. These changes have been made to allow the possibility to have other types of event loop processing. These changes are backward compatible.
· The first version of a scripting service based on Python has been released.
· A number of small internal framework improvements:
· Elimination of the up to now required static libraries.
· Added version number (major and minor) to the Interface ID to check for interface compatibility at run-time.
· Re-shuffling of the System class and conversion to a namespace.
· Handling empty vectors in JobOptions.
3.3.1 Incompatible changes
In this section we will list changes that users need to make to their code in order to upgrade to the current version of Gaudi from the previous version.
1. Histogram persistency. In previous versions, the HBOOK histogram persistency service was created by default. From this version there is no default histogram persistency: the ROOT or HBOOK persistency services have to be explicitly declared. See Section 10.4 for details
2. EvtMax. In previous versions it was possible to declare the number of events to be processed through either of the properties ApplicationMgr.EvtMax or EventSelector.EvtMax. In this release, only ApplicationMgr.EvtMax is supported, the default being all the events in the input file
3. The property EventSelector.JobInput has been removed. Use EventSelector.Input instead (note the change in format of the value string).
4. Detector Description. The detector description interfaces (ISolid.h, IDetectorElement.h, IGeometryInfo.h etc.) have been moved out of the GaudiKernel package and into the DetDesc package. The detector description related options of the Application Manager (ApplicationMgr.DetDbLocation etc.) are now properties of the Detector Data Service (e.g. DetectorDataSvc.DetDbLocation etc.).
5. Gaudi has been restructured into a set of experiment independent packages, and a set of LHCb packages. Since many of the packages have changed name, the paths on which to find include files has also changed.
3.3.2 Deprecated features
We list here features of the framework which have become obsolete, because they have been superseded by more recent features. Users are discouraged from using the deprecated features, which may be removed in a future release.
Accessors names in Algorithm
Use the service accessors with short names (e.g. msgSvc() ) instead of the long equivalent ones (e.g. messageService() )
Access to extra services from Algorithms.
Use the templated method service() instead of using the serviceLocator() together with the queryInterface() to get a reference to a service interface.
3.4 Availability
The application framework is supported on the following platforms:
· Windows NT4 and Windows 2000, using the Developer Studio 6.0 SP2 C++ environment
· RedHat Linux 6.1 (certified CERN Linux distribution with SUE and AFS) with egcs-2.91.66.
The code, documentation and installation instructions are available from the LHCb web site at: http://cern.ch/lhcb-comp/Components/html/GaudiMain.html .
Framework sources and binaries are also available in the CERN AFS cell, at /afs/cern.ch/sw/Gaudi for the common Gaudi packages, and at /afs/cern.ch/lhcb/software/NEW for the LHCb specific packages.
3.5 Using the framework
3.5.1 CVS repository
The framework sources are stored in CVS and can be accessed using the getpack command. The first time you access a Gaudi package, the CVS server will ask for a password, reply CERNuser. Note that you only have write access to the LHCb specific part of the repository. For the common Gaudi packages you cansend all the CVS commands that don't require write access. If you use a command like commit, you will get an error message.
3.5.2 CMT
The framework libraries have been built using the Configuration Management Tool (CMT) [7]. Therefore, using the CMT tool is the recommended way to modify existing packages or re-build the examples included in the release. If CMT is not available in your system, please follow the installation instructions in [7]. The following simple examples are for Unix, but similar commands exist also for Windows. They assume that the CMTPATH environment variable is set to $HOME/mycmt:$GAUDIHOME.
Getting a copy of a package:
Suppose you want to build the latest released version of the GaudiExamples package:
1: cd mycmt
2: cmt checkout GaudiExamples -r v7
Building and running an example:
Now that you have the code, suppose you want to modify the AlgSequencer example, then build it and run it:
Modifying a library and rerunning the example:
Suppose now you want to modify one of the Gaudi libraries, build it, then rerun the AlgSequencer example with it:
3.5.3 Using the framework on Windows with Developer Studio or Nmake
The libraries for Windows are available for download from the web, and in AFS in the Win32Debug subdirectory of each package.
Instructions for installing the Gaudi environment on Windows and for customising MS Visual Studio are available at: http://cern.ch/lhcb-comp/Support/html/DevStudio/default.htm
The requirements files and CMT commands expect the following enviornment variables:
· HOME Needs to be set to the user's home directory. Typically this is in a network server and will have the form "\\server\username" or can also be a local directory like "C:\home". This environment variable is used to locate the .cmtrc file that contains the default CMTPATH.
· PATH Should be set up correctly to locate the Developer Studio executables (this is typically the case after installation).
· TEMP Location for temporary files. This is set correctly after the operating system installation.
· SITEROOT This is the root where software is installed. Typically it will point to some share in some server (\\server\siteroot) or to the locally mounted AFS drive (F:\cern.ch).
· CMTPATH The first location where CMT is looking for packages. This is typically the local directory C:/mycmt
· CMTSITE This is your site name. At CERN site and for the Windows platform we use CERN_WIN32.
3.5.4 Using the framework in Unix
The libraries for Linux are available for download from the web, and in AFS in the i386_linux22 and Linuxdbx subdirectories of each package (for the optimised and debug versions respectively).
Instructions for installing the Gaudi environment on Linux are available at: http://cern.ch/lhcb-comp/Support/html/start_gaudi.htm
3.6 Working with development releases
This User Guide corresponds to release v7 of the Gaudi software.
For Gaudi packages, the convention is that odd numbered versions, such as v7, correspond to frozen, public releases of the software. Even numbered versions are development releases, which are periodically rebuilt from the head revision of the CVS repository. These versions are not guaranteed to work and may change without notice; they should be used with care, mainly if you wish to use new features of the software which have not yet been incorporated in a public release.
For LHCb specific packages, we have adopted a different strategy. Development versions of these packages are periodically made available in the development release area.
3.6.1 The development release area
Development releases of packages are made periodically into the AFS directory tree below /afs/cern.ch/lhcb/software/DEV (pointed to by the LHCBDEV environment variable on Unix), by checking out and building the CVS head revision of modified packages. The directory structure of LHCBDEV is analogous to LHCBSOFT - there is a subdirectory per package, below which there are subdirectories for each development release version of that package. These subdirectories have a name which is constructed from the version number of the package and the date of the build, e.g. v4r1d010316 corresponds to version v4r1 and was built on 16th March 2001. The version number is greater than or equal to that of the most recent public release, depending on what has been changed in the package since the release.
3.6.2 Using the development version of packages
The purpose of the development area is to make it easy to work with the development version of packages, without needing to make a private copy of the head revision of a package.
To use packages from the development area, it is sufficient to add the $LHCBDEV area to your CMTPATH, ahead of the release area. This is done either by editing the file .cmtrc in your home directory (both Unix and Windows), by typing (Unix only):
setenv CMTPATH $HOME/mycmt:$LHCBDEV
Note that this latter method is valid only for the current login session, whereas the former method is valid until the next time you modify the file.
1 Abstract Interfaces for Data Analysis (http://wwwinfo.cern.ch/asd/lhc++/AIDA/index.html)
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|