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.
float, bool, int, string
), or extended with bounds checking, hierarchical lists, and immediate callback from string "commands".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.
// NTupleSvc.Input = {"MC#ntuple1.hbook", // NTupleSvc.Type = 6 // = HBOOK |
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
.
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.
// ApplicationMgr.EvtSel = "FILE /afs/.../data.rawh"; // ApplicationMgr.EvtSel = "JOBID 16434"; "FILE='/afs/.../sicb_bpipi_v233_100ev.dst1'", |
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.
msgSvc()
) instead of the long equivalent ones (e.g.
messageService()
)
service()
instead of using the
serviceLocator()
together with the
queryInterface()
to get a reference to a service interface.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
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
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.
[3] cd GaudiExamples/v6/Histograms ----- Make your modification, then ----- Uncomment Histograms and comment all the others |
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.
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.
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 )