Software at TACC

Last update: September 30, 2024

This document is in progress.

System-Installed

TACC maintains a large list of currently installed software on all HPC resources: Lonestar6, Frontera, Stampede3 and Vista.

If the software search results are inconclusive you have two choices:

1. Request TACC staff make a global, system-wide, installation of your software package
2. Install the software package in your own directory. You can always make the executable available to project members.

Resource-Specific Build Instructions

See each resource user guide's Building Software and Performance sections for architecture-specific build instructions:

• Frontera
• Lonestar6
• Stampede3
• Vista

Building Third-Party Software

You are welcome to download third-party research software and install it in your own account. In most cases you'll want to download the source code and build the software so it's compatible with the resource's software environment.

Instead, the key is to specify an installation directory for which you have write permissions. Details vary; you should consult the package's documentation and be prepared to experiment. Using the three-step autotools build process, the standard approach is to use the $PREFIX environment variable to specify a non-default, user-owned installation directory at the time you execute configure or make:

$ export INSTALLDIR=$WORK/apps/t3pi
$ ./configure --prefix=$INSTALLDIR
$ make
$ make install

CMake based installations have a similar workflow where you specify the install location. Unlike with configure, you create a separate build location and tell cmake where to find the source:

$ mkdir build && cd build
$ cmake -D CMAKE_INSTALL_PREFIX=$WORK/apps/yourpackage /home/you/src/yourpackage
$ make
$ make install

Many packages at TACC set the $CMAKE_PREFIX_PATH or $PKG_CONFIG_PATH environment variables in their respective modulefiles, so that dependent modules are found automatically. See CMake's Getting Started with CMake documentation.

Other languages, frameworks, and build systems generally have equivalent mechanisms for installing software in user space. In most cases a web search like "Python Linux install local" will get you the information you need.

In Python, a local install will resemble one of the following examples:

$ pip install netCDF4     --user                    # install netCDF4 package to $HOME/.local
$ python setup.py install --user                    # install to $HOME/.local
$ pip install netCDF4     --prefix=$INSTALLDIR      # custom location; add to PYTHONPATH

Similarly in R:

$ module load Rstats                                # load TACC's default R
$ R                                                 # launch R
> install.packages('devtools')                      # R will prompt for install location

You may, of course, need to customize the build process in other ways. It's likely, for example, that you'll need to edit a makefile or other build artifacts to specify resource-specific include and library paths or other compiler settings. A good way to proceed is to write a shell script that implements the entire process: definitions of environment variables, module commands, and calls to the build utilities. Include echo statements with appropriate diagnostics. Run the script until you encounter an error. Research and fix the current problem. Document your experience in the script itself; including dead-ends, alternatives, and lessons learned. Re-run the script to get to the next error, then repeat until done. When you're finished, you'll have a repeatable process that you can archive until it's time to update the software or move to a new machine.

If you wish to share a software package with collaborators, you may need to modify file permissions. See Sharing Files with Collaborators for more information and detailed instructions.