Subsections

2 Applications

In GANGA you can specify any GAUDI application directly as the appliaction for your job. Specific versions of the handler are available for all the different GAUDI applliactions like GAUSS and DAVINCI. Since they all work in the same way we will only describe DAVINCI here.

The example below illustrates the creation of a job where the version of DAVINCI is changed and the options file specified.


 In [1]: dv = DaVinci()


In [2]: dv


Out[2]: DaVinci (

 extraopts = None ,

 configured = 0 ,

 package = 'Phys' ,

 masterpackage = None ,

 platform = 'slc4_ia32_gcc34' ,

 version = 'v19r13' ,

 lhcb_release_area = '/afs/cern.ch/lhcb/software/releases' ,

 user_release_area = '/afs/cern.ch/user/u/uegede/cmtuser' ,

 optsfile = []

 )


In [3]: dv.version='v20r0'


In [4]: dv.optsfile=['~/myopts.py']


In [5]: j = Job(application=dv)

This can of course all be done in a single line.


 j = Job(application=DaVinci(version='v20r0', optsfile=['~/myopts.py']))

Note how the optfile field is a list. If more than one element is supplied they are all used one after the other to define the configuration.

2.1 The parameters of the GAUDI (GAUSS, DAVINCI, etc.) handlers

The GAUDI applications each have a set of parameters that are explained here for reference. The examples in section 6 are good for understanding how they can be used.

version

This is the version of DAVINCI (or whatever other GAUDI application) that will be used.

optsfile

You can either provide a single options file or a list of files.. If more than one element is supplied they are all used one after the other to define the configuration. Give the absolute path and do not change the value of the subdir field. Both old .opts and new .py options can be used and mixed. Include statements in the files will be expanded at submission time and a full copy made.

extraopts

In this field you can add extra options that will be appended to the end of your options file before running. This is very convienient for changing a single parameter before running a job. Only the new Python format is accepted in this field.

j.application.extraopts="""
ApplicationMgr().EvtMax = 1000
HistogramPersistencySvc().OutputFile = "DVHistos_1.root"
"""

Notice the use of triple quotes in PYTHON to specify a multiline option.

user_release_area

The CMT user path to be used. By default the value of the first element in the User_release_area environment variable. After assigning this you can do


 j.application.getpack('Phys/DaVinci v20r0')

to check out into the new location. If you work on several simultaneous projects it is advisable that you keep them in separate CMT areas.

masterpackage

The package where your top level requirements file is read from. Can be written either as a path Tutorial/Analysis/v6r0 or in a CMT style notation Analysis v6r0 Tutorial.

lhcb_release_area

The location of the LHCb releases. As an example this can be changed to point to the DEV area.

platform

The architecture (like 32bit versus 64 bit) that will be used to run your job. If you change this you have to make sure your own DLLs are complied for the correct architecture as well. The best way to make sure this is the case is to do

j.application.make()

which will build the code for the specified platform.

2.2 Job submission and running

When a GANGA job with a GAUDI application is submitted several things will happen.

CMT is used to identify the packages in your local CMT area that the job depends on. The requirements file in your masterpackage will be the one that determines this.
All the include statements in the option files are recursively expanded and the fully expanded options file is cached with the job.
A copy of all shared libraries used in your private CMT project area(s) is made. This also includes the rootmap and confDb PYTHON files.

The purpose of the above oprations is to make your job independent of your CMT area. This means that after you have submitted a job (and before it has finished) you can edit your options files, rebuild the code etc. without putting your running job at risk. This is something that is not possible if running from the command line. If you are curious about the cached files that are created (or suspect a bug in the implementation) you can find them in the directory j.inputdir where j is your job. Simply unpack the two tar files and see what is there.

2.3 Helper functions

The GAUDI application handlers provide functions to make it easier to check out and build code when you are working with multiple different versions and release areas. Look at the example below where the CMT area is in my public/cmtTutorial directory and the package Tutorial/Analysis v7r4 is checked out and built.


 In [11]:dv = DaVinci(version='v20r0', 

                     user_release_area='~/tmp/public/cmtTutorial',

                     masterpackage='Tutorial/Analysis/v7r4')

 


In [12]:dv.getpack('Tutorial/Analysis v7r4')

:


getpack v4r0


cvs -d :kserver:isscvs.cern.ch:/local/reps/lhcb co -d gaudi-req-190403 

    Tutorial/Analysis/cmt/requirements


U gaudi-req-190403/requirements

----------------------------------------


cvs -d :kserver:isscvs.cern.ch:/local/reps/lhcb co -P -d v7r4  

    -r v7r4  Tutorial/Analysis

:



< edit your code >




In [13]:dv.make()

:

#-------------------------------

# Now trying [make] in /afs/cern.ch/user/u/uegede/tmp/public/cmtTutorial/

                       Tutorial/Analysis/v7r4/cmt (191/192)

#--------------------------------

:

:

#-------------------------------

# Now trying [make] in /afs/cern.ch/user/u/uegede/tmp/public/cmtTutorial/

                       Tutorial/Analysis/v7r4/cmt (191/192)

#--------------------------------

:

---> Analysis : library ok

---> Analysis ok

---> (constituents.make) Analysis done

 all ok.

The full signature of the helper functions are:

getpack(options): Execute a getpack command getpack options with CMT configured to use the specified CMT user area. To see the arguments you can include in the getpack command give it the argument -h as in dv.getpack('-h').
make(argument): Build the code in the release area the application object points to. The actual command executed is cmt broadcast make argument after the proper configuration has taken place. An example is j.application.make() to do a broadcast make or j.application.make('clean') to clean up. The code will be build using the architecture specified in the platform field for the application.
cmt(command): Execute a general cmt command in the cmt user area pointed to by the application. Will execute the command cmt command after the proper configuration. Do not include the word cmt yourself. An example is j.application.cmt('show uses').

The CMT commands are related to the CMT area that the application points to. If you perform a getpack, a make or whatever using these commands it will affect all jobs where the application points to this area.

Note: If a job has already been submitted shared libraries and options are cached and they will not be affected by whatever CMT commands you might use. This is the case even if the job is still pending in a batch queue.

2.4 GAUDIPYTHON

For the more experience users of GAUDI, there is also the possibility to use GAUDIPYTHON. In this mode of working you are in control of loading shared libraries, importing modules and executing the event loop yourself. The GAUDIPYTHON application handler allows you to work like this. The parameters the GAUDIPYTHON handler takes are:

project: The project used for configuring the environment. By default it is using Davinci.
version: The version of the project used for configuring the environment. By default using the latest available.
script: The script that is executed. You can either give a single script or a list of scripts. If a list the first will be executed and it is your own responsibility to include the others in the first script.

If you have shared libraries to include, it is your own responsibility to enter them into the input sandbox.

You can also define the data the job should run over as inputdata in the same way as for GAUDI jobs specified below. This inputdata will be defined in the PYTHON session before control is handed to your script (so do not overwrite it with your own EventSelector statement in the script).

2.5 ROOT jobs

There is a ROOT application handler in GANGA that makes it possible to create jobs for running within ROOT. As a user you will specify the CINT or PYROOT script to run and then the rest is taken care of. The ROOT application works with all backends but the versions that can run on the DIRAC backend is limited to the ROOT versions already installed. If you try to use a version not pre-installed, you will get an error message. See the comprehensive documentation in the reference manual for further details.

See About this document... for information on suggesting changes.