GAUDI User Guide

13.1  Overview

In order to facilitate the transition towards C++ based code we have implemented a number of features into the Gaudi framework whose purpose is to allow access to facilities existing within SicB but not yet existing within the framework itself.

In this chapter we cover: staging data from DSTs, the magnetic field map, accessing the SicB geometry description and the use of the SUINIT, SUANAL and SULAST routines from within the Gaudi framework.

When using the geometry and magnetic field descriptions described here, you should not forget that they are a temporary solution and that they will disappear at some point in the future. It is advisable to use them to populate some predefined class which can then be used in your algorithms. In this way when the detector description data base is ready the required changes in your code will be confined to the parts which access the geometry.

13.2  Reading DST tapes

Important Note: Accessing DST tapes and the following instructions may only work in the CERN installation.

There are two ways to specify an input event data file in Gaudi. The first is to simply specify a file on disk by setting the appropriate option of the application manager in the job options file:

 
ApplicationMgr.EvtSel = "FILE S:\lhcb\software\class_b\sicbmc.dat";

The second possibility is to specify a data set by giving the job identification number, as was done in Sicb. The framework will look into the database in order to find the corresponding tape and then stage it in. To use this feature you should specify the following options within the job options file:

 
ApplicationMgr.EvtSel = "JOBID 11758";
EventSelector.TapesDataBase = "F:\mcdbase\mcmain.db";

The first line specifies the job-id, while the second tells the event selector where to find the job-id database. It is necessary to explicitly specify the database location since the framework may be run from a machine without an AFS client. If you have AFS you will find the database at:

 
$LHCBHOME/mcdbase/mcmain.db

If you are using a PC you may copy it in your local disk and set the TapesDataBase option to point to it. However it is advisable to have AFS installed on your PC and read the database from the standard AFS location as this is the only way to ensure that the database you are using is up to date. This procedure will change when the new bookeeping data-base becomes available.

To access the tape server from your PC you will need to install or update your local shift configuration. This is necessary only once for each machine and may be done directly from one of the CERN/NICE menus:

Start -> Physics -> Shift -> Install or update SHIFT configuration .

Unfortunately due to technical problems in the way Gaudi interacts with the SICB code which actually reads the DST we are currently able to read only one file or job-id per job. Hopefully this will be enough for code development and the problem will be solved in the near future.

13.3  Access to the Magnetic Field

The magnetic field map will be accessible in the future via the transient detector store. For the time being, as this is not implemented and as access to the magnetic field has been requested, we have provided a magnetic field service. Again this is effectively just a wrapper which uses SicB routines to read the information from a . cdf file.

The location of the field.cdf file is provided by the standard.stream file which is read in by a SICB routine called from Gaudi. This file is in the data base area: $LHCBROOT/$LHCBVER/dbase/standard.stream in AFS and %LHCBROOT%\%LHCBVER%\dbase\standard.stream from the PC server at CERN. For every version the file used in the production is read in. The location of the standard.stream file will be taken from an environment variable as per normal SicB operation.

To use the Magnetic field service one should modify the jobOptions.txt file to include the following:

 
ApplicationMgr.ExtSvc = { "MagneticFieldSvc"};

Any algorithm which requires the use of the service makes a request via the serviceLocator() method of the Algorithm base class:

 
IMagneticFieldSvc* pIMF= 0;
serviceLocator()->getService("MagneticFieldSvc", 
                             IID_IMagneticFieldSvc, 
                             		reinterpret_cast<IInterface*&>( pIMF) );

The service provide a method:

 
StatusCode fieldVector(HepPoint3D& Pos, HepVector3D& field)

which gives a magnetic field vector at a given point in space, for example:

 
HepPoint3D P(0., 0., 0.); 
HepVector3D B; 
pIMF->fieldVector( P, B );

The magnetic field service uses a new version of the SicB routine GUFLD. In this new version the best possible description of the magnet geometry and the field are assumed in order to eliminate dependencies with other parts of SicB. Technically in SicB this corresponds to:

 
IMAGLEV = IUVERS('GEOM','MAGN') = 4
IFLDLEV = IUVERS('GEOM','MFLD') = 4

These two parameters have been fixed to 4 in the production since a few months before the Technical Proposal: version 111 of SicB. Thus this seems to be a reasonable restriction until the field map is provided in the detector description database.

For an example of the use of this service see the sub-algorithm readMagField in the example FieldGeom distributed with the release.

13.4  Accessing the SicB detector geometry from Gaudi

As discussed previously, the detector geometry will be included along with the field map in the detector description database. However, for the time being the detector geometry used in the production of the data can be obtained by calling a function in the SicbFortran name space (this function is just a wrapper for the FORTRAN function of similar name):

 
void SicbFortran::utdget(const std::string& a1, const std::string& a2,  
                         int& nParam, int* data);

nParam should be set to the number of data words required and on return from the function will contain the number of data words actually copied into the array: data. The first string contains the name of the sub detector whose geometry is being requested and the second string is a list of options:

An algorithm requiring this access should include the header file:

 
#include "SicbCnv/TopLevel/SicbFortran.h"

and call it so:

 
float rpar[300]; 

SicbFortran::utdget("WDRF","D",mpar, (int *) rpar);
log << MSG::INFO << " wdpar(" << j << ") = " << vf[j] << endreq;

Note that the data returned by the function is written into an integer array. However we can also read floating point numbers as in the code fragment above by casting a float array.

One should notice that the geometry returned by this function is that which was used in the production of the data and not that which is in the current version of the .cdf files. Only if the option 'N' is specified are the .cdf files read in from the standard location. In order to be able to use the array of parameters returned one has to know in advance the organization of these data in the cdf file since the data are stored in an array and not in a common block with named variables.

The sub-algorithm readTRackerGeom in the example FieldGeom extracts and writes out some digitization and geometry parameters of the outer tracker.

13.5  Using fortran code in Gaudi

Existing FORTRAN code can be used within a Gaudi application by using the FortranAlgorithm class.This is a standard Gaudi algorithm which calls the FORTRAN routines: SUINIT in the initialize() method, SUANAL in the execute() method for each event, and SULAST in finalize(). Implementing these three routines allows you to write code in FORTRAN and have it called from within Gaudi, in particular to import routines already written in SicB.

Note, however that there are some points that should be kept in mind when importing SicB code into Gaudi. The following list is far from being complete but we hope that it will help anyone using the FortranAlgorithm. It may be updated in the future with the user's experiences and our own findings.

• Gaudi is linked with only two sub-packages of SICB: FINCLUDE and FUTIO. This means that taking some code from SICB and running it successfully in Gaudi will not always be straight forward. Every case will have to be studied separately. In some cases you may find that the effort required to make the code compatible with Gaudi is comparable to writing it directly in C++. For some pieces of code the integration into Gaudi may be very simple. The difficulties will come mainly from dependencies of the code you want to include on other parts of SICB. For instance there may be common blocks which your code needs but which are never initialized.
• As most of SICB is not executed, you will have either to include and execute the required initialization or to try to eliminate those dependencies.
• Gaudi uses SICB to access the data in the DST's, to extract the information from the banks and to convert the data into the appropriate classes. This needs some initialization but not every SICB initialization step is followed. The standard.stream file and setup.cdf are read in from the standard locations. The program will have access to the data in the cdf files which were used to produce the DST.
• Sicb.dat is not read in. If you need to change the running conditions of your program do it using the jobOptions.txt file or write your own cards file and read it in SUINIT.
• In FINCLUDE you will find all the NAME_BANK.INC and NAME_FUNC.INC include files. This means that you have access to the bank data with the usual utilities provided by SICB. For example, to access the momentum of the reconstructed track one can use (as in SicB):

P = AXTK$P(NOBJ)

• FUTIO includes most of the UT* and UB routines which can therefore be used by fortran code within Gaudi.
• Initialize the histogram files yourself in SUINIT. Gaudi initializes the histogram service but this can be accessed only from C++ code.
• Remember Gaudi reads DST files. Do not expect to have data which are not in them (for instance the inner and outer tracker digitizations). If your algorithm needs data which are not in the DST there are two solutions. The easiest, but only valid for developing and debugging your code, is to write a new DST including the data you need. The second solution is to integrate the SicB code which produces these data as a fortran algorithm in Gaudi.This also applies to new C++ algorithms which need data not present in the DSTs.