Environment on Genepool
When you log into the Genepool system you will land in your $HOME directory on NERSC's "global homes" file system. The global homes file system is mounted across all NERSC computation systems with the exception of PDSF. The $HOME directory has quota of 40GB and 1,000,000 inodes. To customize your environment, by setting environment variables or aliases, you will need to modify one of the "dot" files that NERSC has created for you. You may NOT modify the .bashrc or .cshrc files. These are set to read-only on NERSC systems and specify system specific customizations. Instead you should modify a file called .bashrc.ext or .cshrc.ext.
Setting up your work environment with Modules
The JGI and NERSC have been collaborating to provide a large number of bioinformatics and many other software packages on genepool. These software are made available to you by the modules system. Please read the general documentation on using modules at NERSC. There are a number of default modules. These should usually not be unloaded unless there is a very specific need to do so (e.g. swap gcc/4.6.3 for gcc/4.8.0 if needed).
Genepool Default Modules:
- gcc/4.6.3: all dynamically linked software in the NERSC supported software environment is built using this verison of gcc; thus many software packages are dependent on this module
- mpfr, gmp and mpc are loaded to support gcc; these may be removed in the future
- jgitools: adds the legacy /jgi/tools into your environment
- uge: sets up the proper environment for accessing the genepool GridEngine batch scheduler
- OFED: on Infiniband-enabled nodes, the OFED module will be loaded to support software which can make use of the high-speed interconnects
- usg-default-modules: A meta-module which loads some of the default modules (at present: gcc, OFED)
- nsg: NERSC system-level utilities (e.g. myquota)
- modules: the modules environment
Working with Modules for production-level batch scripts
When writing a batch script which you may share with another genepool user, it can be difficult to ensure the environment the other user will be compatible with your batch script - usually because of differences in the dotfile configurations and interactive-usage preferences. For this reason, it is recommended that if you choose to load additional modules (or unload them) in your dotfiles, that you carefully consider how this will affect your jobs as well. One good practice for getting reproducible results from a batch script is to purge all modules from the environment, and manually construct the exact environment you need:
module load gcc/4.6.3
module load blast+/2.2.7
blastn <flags> ...