BlueM Ready for Production

Both partitions of BlueM are ready for production work. If you are receiving this email you have an account on BlueM.

Both partitions of BlueM are ready for production work. If you are receiving this email you have an account on BlueM.

There are still some issues that are being worked out. If you have questions or problems contact hpcinfo@mines.edu

Ready to get your science in to high gear?

Please see the notes:

http://hpc.mines.edu/bluem/setup.html
Describes setting up access and your first login.
http://hpc.mines.edu/bluem/quick.html
This is a quick start guide that describes job submission and gives simple build and run scripts
http://hpc.mines.edu/bluem/transfer.html
Describes the file system layout and the best methods to get files to the machine.
http://inside.mines.edu/~tkaiser/cgi-bin/enote/cgi-bin/enote112.pl
HPC blog and archive of notes set to users.

As you recall, the AuN partition of BlueM is very similar to RA. Scripts that have been used on RA will work with only minor modifications on AuN.

If your group builds their own applications you should build your applications in your bins directory. However, you should run your applications in the scratch directory. (The bins file system is optimized for small files and the scratch directory for larger files.) The examples scripts in the quick startguide discuss how to create directories on the fly in your scratch directory.

When researchers requested time on BlueM the were asked to list the applications that they were planning on using. We are building many of these applications but have not yet completed the list.

BlueM Module System

BlueM has a module system. The module system allows setting up the environment for running applications using one or two simple commands. Module commands can be run from the command line or they can be placed in your .bashrc file. The primary module command is

module load Name_of_module_to_load

This would load a module, which sets your environment to run some application. This typically would involve changing your PATH environmental variable and possibly your LD_LIBRARY_PATH variable. There are also modules for setting up one of several different programming environments. Most users will not need to change their programming environment.

As we build applications we are also creating module files to facilitate execution of the applications.

***** IMPORTANT ***** Available Modules

There are two ways to see available modules. The first is to visit the links given here:

You can also run the command:

module avail

on Aun and Mc2. Running the command on the node will give you the most up to date list. The web page might be out of sink.

The full list contains modules for user applications, utilities, and different programing environments. You can limit the list to just modules created for running applications.

To see a list of modules built for various user programs run the command:

module avail Apps

"Apps" restricts the listing to only user programs. For example on AuN we currently (Mon Sep 30 15:51:48 MDT 2013) get:

[aun001 job-scripts]$ module avail Apps

-------------------------------- /opt/modulefiles --------------------------------
Apps/AmberMD/amber12-ambertools12 Apps/abinit/7.4.1
Apps/AmberMD/amber12-ambertools13 Apps/gromacs/4.5.5-BM
Apps/RGWBS/MIO.build              Apps/siesta/3.0
Apps/RGWBS/RA.build               Apps/siesta/3.1
Apps/abinit/5.4                   Apps/siesta/3.2
Apps/abinit/6.10.2                Apps/vasp/5.2.12
Apps/abinit/6.10.2-BM             Apps/vasp/5.2.12-BM

This lists the application name and the version number. "-BM" indicates this version of the program was built by IBM for benchmarking.

On Mc2 we have a module to facilitate running lammps. The command:

module load Apps/LAMMPS/22jun07-BM 

loads its module and adds to PATH

PATH=/gpfs/sb/mc2/opt/LAMMPS/22jun07-BM:$PATH

and sets

 LAMMPSROOT=/gpfs/sb/mc2/opt/LAMMPS/22jun07-BM

Modules we are building for user applications set a variable that point to install directory for the program of interest. LAMMPSROOT in this case.

The "ROOT" directory for most of the modules contain run scripts and data sets that can be used as a template for your scripts.

For example, back to lammps we have:

[mc2 job-scripts]$ ls -l $LAMMPSROOT
total 65688
drwxrwsr-x 4 root    bluemdev      512 Sep 23 15:34 job-scripts
-rwxr-xr-x 1 ibmtest bluemdev 67249077 Jul 12 04:05 lmp
drwxr-sr-x 2 root    bluemdev     8192 Sep 23 11:13 potentials

with

[mc2 job-scripts]$ ls -R $LAMMPSROOT/job-scripts
128n16p  32n16p  README

/gpfs/sb/mc2/opt/LAMMPS/22jun07-BM/job-scripts/128n16p:
cuu3  input.128nodes  lammps.cmd

/gpfs/sb/mc2/opt/LAMMPS/22jun07-BM/job-scripts/32n16p:
cuu3  input.32nodes  lammps.cmd

A module can be preloaded or loaded as part of your run script. That is, you can put a load module command in your .bashrc file or enter it on the command line before you submit a script. You can also put the load module command in your script. The advantage of preloading is that this gives you access to the environment in which your program will run before submitting the script, in particular the "ROOT" environment variable and the path to the executable. Loading the module as part of your script will ensure that the environment is set up properly for the application, independent of your login session.