GAUDI User Guide

Chapter 3
Release notes and software installation

3.1 Release History

Version
Date
Package List

v6

10/11/2000

Gaudi[v8], GaudiSvc[v4], GaudiAlg[v1r1], LHCbEvent[v8], SicbCnv[v9], DbCnv[v3], HbookCnv[v7], DestDesc[v5], GaudiExamples[v9], Auditors[v1], GaudiTools[v1], RootHistCnv[1], XmlEditor[v1], GaudiLab[v2]

v5

24/07/2000

Gaudi[v7], GaudiSvc[v3], GaudiAlg[v1], LHCbEvent[v7r1], SicbCnv[v8], DbCnv[v2], HbookCnv[v6r1], DestDesc[v4], GaudiExamples[v8]

v4

14/04/2000

Gaudi[v6], GaudiSvc[v2], LHCbEvent[v7], SicbCnv[v7], DbCnv[v1], HbookCnv[v6], DestDesc[v3], GaudiExamples[v7]

v3

19/11/1999

Gaudi[v5], LHCbEvent[v6], SicbCnv[v6], RootCnv[v3], HbookCnv[v5], DestDesc[v2], GaudiLab[v1], GaudiExamples[v6]

v2

18/6/1999

Gaudi[v4], LHCbEvent[v5], SicbCnv[v5], RootCnv[v2], HbookCnv[v4], DestDesc[v1], GaudiExamples[v5]

v1

5/2/1999

Gaudi[v1], LHCbEvent[v1], SicbCnv[v1], HbookCnv[v1], GaudiExamples[v1]

3.2 Current Functionality

We use an incremental and iterative approach for producing the Gaudi software. We started in the first release with very basic functionality and we plan to expand its capabilities release by release. The basic functionality offered in the first release allowed you to read the already generated SICB Monte Carlo data sets (ZEBRA files). The data in these files is used to build C++ objects which can be used as input for the new software.

Release v3 incorporated most of the essential features which are needed for developing data processing applications (reconstruction, analysis, etc.). This functionality was enhanced in Releases v4 and v5 and has been further enhanced in the current 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 11.
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 12. 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 6 to 10.
Event data model
The event model has been extended to Velo, L0, L1 and updated for Calo. The current status is presented in Chapter 7.
Event data persistent storage
The current version supports event data files (or tapes) as input produced by SICB in ZEBRA format (RZ). 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. The DBCnv package is included to help the user to make objects persistent. Refer to Chapter 13 for more details.
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 9 and 10 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.
Detector description and geometry
The framework provides facilities for describing the logical structure of the detector 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 should allow to develop 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 detailed description can be found in Chapter 8. A transport service is provided to estimate the amount of material between 2 arbitrary points in the detector setup.
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 new 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 11.5) provides the properties of all the elementary particles. Access to the CLHEP and NAG C libraries (Chapter 15) provides numerical utilities for writing physics algorithms.
Visualization services
The framework provides facilities (at a prototype level) for visualization 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.
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 14 for more details.
Dynamic loading of libraries
The framework will 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. This release provides support for dynamic libraries for the NT and Linux platforms.

3.3 Changes in the new release

There are changes in current release with respect to the version 5 of the framework in interfaces and base classes, therefore the end-user applications will need to be re-compiled and re-linked. In general, there is no need to do any change in the user-code (algorithms, tools and converters). The only known incompatible changes are in the JobOptions to specify the input and output files.

3.3.1 Incompatible changes

JobOptions for n-tuple input and output files
The way of specifying the input and output n-tuple file has changed. The "Input" property can be associated to files in different formats.::

// The old way

// NTupleSvc.Input = {"MC#ntuple1.hbook",

// "USER#tuple2.hbook"};

// NTupleSvc.Type = 6 // = HBOOK

 

// The new way

NTupleSvc.Input = {

"FILE1 DATAFILE='tuple.mdb' OPT='NEW' TYP='MS Access'",

"FILE2 DATAFILE='tuple.hbook' OPT='NEW' TYP='HBOOK'"};

JobOptions for EventSelector
,The EventSelector input and output file specifications have changed in the same way as for n-tuples. Notice that the " EvtSel " property is now a property of EventSelector .
Possible tags are: FILE and JOBID for SICB data, DATAFILE for file name, TYP for technology identifier, OPT for new, update,..., SVC for conversion service name and AUTH for extra authentication information if needed by the technology.

// The old way

// ApplicationMgr.EvtSel = "FILE /afs/.../data.rawh";

// ApplicationMgr.EvtSel = "JOBID 16434";

 

// The new way

EventSelector.EvtMax = 5;

EventSelector.Input = {

"FILE='/afs/.../sicb_bpipi_v233_100ev.dst1'",

"JOBID='16434'",

"DATAFILE='D:\data\selected_events.root' TYP='ROOT'"

};

Detector Element
no longer has a default constructor. One must be provided explicitly.
IOpaqueAddress
Implementations of IOpaqueAddress no longer return the full path of an object with the function objectName() , only the name. To get the full path, use directory()->fullpath() instead.

3.3.2 Deprecated features

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:

The code, documentation and installation instructions are available from the LHCb web site at: http://cern.ch/lhcb-comp/Components/html/GaudiMain.html

3.5 Using the framework on NT with Developer Studio

The Framework sources are available via AFS or can be downloaded from the web. The libraries for NT are available in the LHCb AFS tree, in the Win32Debug subdirectory of each package.

Instructions for installing the LHCb software environment on NT and for customising MS Visual Studio can be found at: http://cern.ch/lhcb-comp/Support/html/DevStudio/default.htm

3.6 Using the framework in Unix

The framework libraries have been built for various Unix platforms and are available via AFS. These libraries have been built using the Configuration Management Tool (CMT). Therefore, using the CMT tool is the recommended way to modify existing packages or re-build the examples included in the release. Complete and up to date information about using CMT is available at the URL: http://cern.ch/lhcb-comp/Support/html/cmt.htm . Here we give only simple instructions on how to get started with the Gaudi software under CMT on Unix.

Getting a copy of a package:
Suppose you want to build the latest released version of the GaudiExamples package:

[1] cd mycmt

[2] getpack GaudiExamples

following versions are available - v6 v5r1 v5 v4 v3

Enter version number [<CR>=v6]->

Building and running an example:
Now that you have the code, suppose you want to modify the Histograms example, then build it and run it:

[3] cd GaudiExamples/v6/Histograms

[4] emacs HistoAlgorithm.cpp

----- Make your modification, then

[5] cd ../mgr

[6] emacs requirements

----- Uncomment Histograms and comment all the others

[7] gmake

[8] cd ../Histograms

[9] emacs jobOptions.txt

----- Make any modification if needed

[10] ../$CMTCONFIG/Histograms.exe

Modifying a library and rerunning the example:
Suppose now you want to modify one of the Gaudi libraries, build it, then relink the Histograms example and run it:

[11] cd $HOME/mycmt

[12] getpack HbookCnv v5

[13] cd HbookCnv/v5/HbookCnv

[14] emacs ....Make your modification...

[15] cd ../mgr

[16] gmake

[17] cd $HOME/mycmt/GaudiExamples/v6/mgr

[18] cmt show uses

----- Make sure that you are using the modified version (v5) of

----- HbookCnv. If not, edit the requirements file to use this version

[19] gmake

[20] cd ../Histograms

[21] ../$CMTCONFIG/Histograms.exe

3.7 Working with development releases

This User Guide corresponds to release 6 of the Gaudi software. Subsequent to this release, new features may be added to the CVS repository which will not become generally available (and documented) until the next release. Should you wish to use some of these new features before then, you can pick them up from the development release area.

3.7.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 reflects the date of the build, e.g. h000626 was built on 26th June 2000. The most recent successful build is pointed to by a logical link whose version number is the current release version number. In this way, if the area LHCBDEV is before LHCBSOFT in the CMTPATH , the head revision in DEV will be used for the packages that can be found there.

3.7.2 Using the development version of packages

The directory structure described above was designed 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.

On Unix it is sufficient to modify the CMTPATH environment variable to include the development area:

setenv CMTPATH $HOME/mycmt:$LHCBDEV

Packages will then be searched first in your private CMT area, then on LHCBDEV and finally on LHCBSOFT . Note that this will always give you the latest working version of all packages. If you only need a specific development version of one package while keeping the production version of all other packages, it would be better to leave CMTPATH pointing only to your private area, and making a logical link to the appropriate development package. For example:

cd $HOME/mycmt/Gaudiln -fs $LHCBDEV/Gaudi/h000626 v7

This would allow you to use the development version of Gaudi built on 26th June 2000, while using the released version of everything else.

On NT, only the first option is available, due to the absence of logical links. You can make a search list for your CMTPATH by simply adding a second path to the HKEY_CURRENT_USER/SOFTWARE/CMT/path registry key.

If you only want the development version of a specific package, the only option is currently to copy the appropriate package development subdirectory into your private CMT area.


1. Abstract Interfaces for Data Analysis ( http://wwwinfo.cern.ch/asd/lhc++/AIDA/index.html )