Last modified: Fri Jan 23 12:43:28 GMT 2009
Nick West
Return to home page

GridTools: Ganga

Contents

Introduction

Ganga is an OO job submission system written collaboratively by Atlas and LHCb and used by them and groups in other disciplines. It's based on the idea of a Job object that is configured, submitted, interrogated about job status and then used to retrieve the output. Job objects can be collected into arrays and processed in parallel.

The Ganga documentation includes a very good tutorial You can run Ganga without any prior knowledge about the way jobs run on the LCG GRID, but Ganga uses the same basic model, even when running jobs on the local machine, so if terms like InputSandbox and OutputSandbox are alien to you, you might like to read (but not attempt) Submitting Jobs to the Grid

Running Ganga

Start by logging into our User Interface:-
  ssh <my-user-name>@lcgui.gridpp.rl.ac.uk
You can learn quite a bit from running Ganga even if you don't have a GRID proxy but take this a reminder that you will need one as part of Joining the MINOS VO. If you have a GRID proxy, activate it.

If you get stuck getting started with Ganga, take a look at Hints and Tips.

Start Ganga by typing:-

  ganga
If the command is not found you will need to setup the GridTools environment.

Once Ganga is running read the tutorial

In case you are wondering already about your exit strategy, to leave Ganga type:-

  ^D
The tutorial starts by explaining what happens the first time you run Ganga and how the on-line help works (section 2). Carry on and work through sections 3 to 6.

In section 7, skip 7.3 Job Templates, we don't have any, at least not yet.

In section 11 they start running jobs on the LHC GRID, so this is the end of the line if you don't have a GRID proxy! If you do you should be able to work through this section too. If Ganga has been set up properly it should know that we are in the MINOS VO, which can be confirmed by examining the VirtualOrganisation option of the LCG section of the configuration object config by typing:-

config['LCG']['VirtualOrganisation']
In a similar way check that the job will only run on RAL T1 (lcgce02):-
config['LCG']['AllowedCEs']
which should show:-
lcgce02\.gridpp\.rl\.ac\.uk
The "dot"s have to be escaped to stop them being treated like wild card matches.

By default Ganga still submits using the old edg-job-* API, but it's better to use the new gLite-wms-job_* API and to do that you will need to:-

  1. Make sure that gLite/WMS is properly configured at your UI.

  2. Make sure that the interface is enabled
      config['LCG']['GLITE_ENABLE']
    
    should show:-
      True
    

  3. Once you have created a job, set the middleware to GLITE:-
      j.backend.middleware = 'GLITE'
    

Hints and Tips

The GUI

According to the Ganga documentation to start a GUI interface to Ganga, type:-
  ganga --gui
But currently (November 2007) this fails at RAL and we have a hack to the setup_minos_lcg_grid.sh [see the routine set_environment ()] to get the right modules to load and then it is necessary to:-
  $GANGA_BIN --no-rexec --gui
For further details see the GANGA GUI User Manual

Installing and Version Selection

Installing

Install Ganga as follows:-
  mkdir <top directory for ganga>
  cd    <top directory for ganga>

  wget -N http://cern.ch/ganga/download/ganga-install

   python ganga-install                   \
      --all-deps --force                  \
      --extern=GangaGUI,GangaPlotter      \
      --prefix=`pwd`                      \
      LAST 
The --all-deps --force forces the installer to ignore any locally available support libraries such as ipython and download the versions it requires. The option makes the install bigger but insulates it from conflicts with the local versions of the libraries.

LAST just gets the latest stable version which was 4.4.3 when this was first written. It should install flawlessly and created the binary:-

  .../ganga/install/<ganga version e.g. 4.4.3>/bin/ganga
Not surprisingly not all the (commented out) default values in the resource file ~/.gangarc are not suitable for GRID operation so :-
  For Ganga 4: GridTools/Ganga/GangaMinos-4.ini
  For Ganga 5: GridTools/Ganga/GangaMinos.ini
have been developed. The appropriate file is pointed to by
 GANGA_CONFIG_PATH
which is initialised inside the wrapper executable
  $MOG_TOOLS/bin/ganga
Until users start uncommenting their ~/.gangarc, this will take priority.

Version Selection

If the environmental variable GANGA_ROOT is defined and set equal the top level directory then the GridTools environment setup scripts can use it to configure the wrapper executable
  $MOG_TOOLS/bin/ganga
to run Ganga. Where multiple versions of Ganga are installed, this wrapper also allows the user to select a specific version using the environment variable GANGA_VER which takes the following values:-
  version    - a specific version e.g. 4.4.11  
  'new'      - whatever version is currently considered to be new
  'pro'      - whatever version is currently considered to be production
If not defined, the value 'pro' is assumed. If the required version cannot be found the wrapper tries to find the latest version.

Migrating to Ganga 5

Ganga 5 was released in June 2008. The most significant change relative to Ganga 4 is that the job repository is incompatible. The default location is different:-
  Ganga 4: gangadir/repository/<user>/2.0

  Ganga 5: gangadir/repository/<user>/LocalAMGA/
             (in case you are wondering, AMGA is ARDA Metadata Grid
             Application and is part of the gLite middleware and is used
             by Ganga and other GRID applications for meta-data.)
so both Ganga 4 and Ganga 5 can operate together; they just cannot share jobs. In order to switch to Ganga 5 you have review your Ganga configuration, if you have one. The Ganga tutorial has some migration notes which includes details of the configuration changes.

Development and Debugging

Ganga provides a good service to submit individual jobs, but something needs to be layered on top in order to run many jobs as automatically as possible. To do this a fault tolerant Ganga-based Batch Submission GBS system has been developed.

To help with debugging the logging level of the component parts can be raised from the normal 'WARNING' or 'INFO' to 'DEBUG' e.g.:-

config['Logging']['Ganga.GPIDev']          = 'DEBUG'
config['Logging']['Ganga.Utility.logging'] = 'DEBUG'

Return to home page