The PoC software is packaged so that it installs in
/opt/vl-e/ instead of /usr. Besides
that, each package gets its own installation directory based on
name and version number. For instance, FSL 3.3 is
installed in
/opt/vl-e/fsl_3.3/
This is done to avoid clashes between PoC software and standard OS software, and clashes between different versions of the same package in the PoC (for example, we have both VTK 4 and VTK 5).
The way it's packaged, most of the software doesn't work straight away. You need to set up a bunch of environment variables, the least of which are PATH and LD_LIBRARY_PATH, in order for the software to figure out where it lives. This is not a pleasant experience and to help ease the pain, we've incorporated the use of modules. This is a handy tool to configure your work environment with just the packages you need.
After you log in to the User Interface, you can see the available modules with module avail.
$ module avail
---------------------- /opt/vl-e/modules/Modules/versions ----------------------
3.2.3
----------------- /opt/vl-e/modules/Modules/3.2.3/modulefiles ------------------
dot module-cvs module-info modules null use.own
-------------------------- /etc/opt/vl-e/modulefiles ---------------------------
fsl/3.3 lam/7.1.2 rmpi/0.5
fsl/3.3.11 mesa3d/6.4 sesame-client/1.2
gat/1.8 mesa3d/6.4.2 sesame-client/1.2.6
gat/1.8.2 mpitb/2.1 srb/3.4
graphviz/2.12 mpitb/2.1.73 srb/3.4.2
gt/2 mricro/1.39 taverna/1.4
gt/4.0 mricro/1.39.3 vle/1
gt/4.0.5 nimrod/3.2 vle/2
ibis/1.4 nimrodo/2.8 vlet/0.7
itk/2.8 octave/2.1 vlet/0.7.3e
itk/2.8.1 octave/2.1.73 vtk/4.4
java/1.4 ogsadai-wsrf/2.2 vtk/4.4.2
java/1.5 paraview/2.4 vtk/5.0
javagat/1.7 paraview/2.4.4 vtk/5.0.2
javagat/1.7.1 pl/5.6 weka/3.4
kepler/1.0 pl/5.6.27 weka/3.4.9
kepler/1.0.0beta2 r/2.4
lam/7.1 r/2.4.0
You can load a module by typing, e.g. module load r. This will load the highest available version of R. You can inspect the currently loaded modules by typing module list. A specific version of a module can be loaded by specifying the full name of the module. Use module switch to switch to a different version of the same package.
$ echo $LD_LIBRARY_PATH
/opt/globus/lib:
$ module load r
$ echo $LD_LIBRARY_PATH
/opt/vl-e/r_2.4/lib:/opt/globus/lib:
$ module list
Currently Loaded Modulefiles:
1) r/2.4.0
$ module switch r/2.4
$ module list
Currently Loaded Modulefiles:
1) r/2.4
$ module load fsl/3.3
$ module list
Currently Loaded Modulefiles:
1) r/2.4 2) fsl/3.3
$ module rm r
$ module list
Currently Loaded Modulefiles:
1) fsl/3.3
$ which fsl
/opt/vl-e/fsl_3.3/bin/fsl
$ module rm fsl
$ fsl
-bash: fsl: command not found
There are several subcommands of module, which can be seen by running module help. The manual page should explain the details.
The modules installed on a PoC UI are the same as on a worker node, so you can begin your job script with a bunch of module load commands for your job's environment. There is one catch: you must begin the script with
#!/bin/bash -l
This is because 'modules'
is a shell construct (otherwise it wouldn't be able to
manipulate the environment), and hence must be loaded in the
shell prior to use. The place to do this is
/etc/profile, but that is sourced only for login
shells. The -l expressly requests a login shell.
When you submit grid jobs to use some of the PoC software, you want to make sure you only land on nodes that have the PoC installed. The way to enforce this is by specifying it as a requirement in your JDL file, using this string:
Requirements = Member("nl.vl-e.poc-release-2", other.GlueHostApplicationSoftwareRunTimeEnvironment);
This page $Revision: 1.1 $, $Date: 2007/09/28 08:45:02 $.