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
ssh <my-user-name>@lcgui.gridpp.rl.ac.ukYou 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:-
gangaIf 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:-
^DThe 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\.ukThe "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:-
config['LCG']['GLITE_ENABLE']should show:-
True
j.backend.middleware = 'GLITE'
^D
q
q or ^D
jobs(0).peek() Lists output directory
jobs(0).peek("stdout","less") Runs command on specific file
for j in jobs:
if j.status == "completed":
print "\nContents of stdout for job " + str(j.id)
j.peek("stdout","head -20")
ganga --generate-configThen you can adjust it as you please. Caution: should you want to change the place where Ganga stores its data i.e. job repositories and workspaces.
Ganga 4
[DefaultJobRepository]
local_root =/stage/minos-data1/gangadir/repository/nwest
[FileWorkspace]
topdir = /stage/minos-data1/gangadir/workspace/nwest
Ganga 5
[Configuration]
gangadir = /stage/minos-data1/gangadir
then be warned, moving existing repository and workspace data from the
default will break it as the input and output job directory
information is hardwired into it. So it would be safer to wipe the
old than attempt to move it.
ganga --guiBut 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 --guiFor further details see the GANGA GUI User Manual
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/gangaNot 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.inihave been developed. The appropriate file is pointed to by
GANGA_CONFIG_PATHwhich is initialised inside the wrapper executable
$MOG_TOOLS/bin/gangaUntil users start uncommenting their ~/.gangarc, this will take priority.
$MOG_TOOLS/bin/gangato 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 productionIf not defined, the value 'pro' is assumed. If the required version cannot be found the wrapper tries to find the latest version.
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.
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'