A High-Performance Computing (HPC) environment like the Sol and Phoenix supercomputer is vastly different from a desktop environment, like your personal workstation. Building software to run for HPCadds considerations in a few areas: architecture, interconnects, binary compatibility, and permissions, to name a few. These considerations make it more time-consuming and complicated to successfully build software.

...

In some cases, such as extremely domain-specific software, largely-untested code, and development versions of software, it may be imprudent to create public /wiki/spaces/RC/pages/45875213. Research Computing admins can still assist by building this software in the user’s HOME directory, or in the group share directory /data/grp_XXXX where XXXX is the user’s group (visible with the command groups). Note, there is no functional difference between an installation in a user’s HOME versus one built on shared storage (e.g., /data/grp_, /packages/) as an environment module simply adds environment variables to your terminal session. This allows convenient access to the binaries and proper environment configuration. All groups have this share and all users in the group share this space; it can be used freely up to the limit of 100GB, which is a hard cap (additional storage must be purchased).

...

Requesting software to be built

Requests for software installations can be made in a support ticket.

...

Sol currently uses Rocky Linux 8.x; software explicitly requiring Debian, Ubuntu, etc., may compile and a best-effort attempt will be attempted. Beyond that, seek a container solution.

Compiling software from source

Luckily, many of the compilation considerations mentioned above can be handled automatically, with provided build scripts and makefiles from the software author. At the minimum, an understanding of Linux filesystem permissions is required to build software, as most software defaults to installing files in locations not permissible by regular, non-admin users.

Filesystem Permissions & Shared Storage

An abbreviated--but valid--installation of python might go like this:

...

This error is not an indication of a failed build, but simple a failure to copy the binaries to root-owned paths on a node. Many users may recognize this as a sudo-solvable problem, but in HPC environments, that is not the case.

sudo access

Sudo access is reserved explicitly for Research Computing admins. If a software installation attempts to install to a local directory and fails, the answer is not to request more permission to be able to install to a local directory but instead to redirect the installation to a shared storage space, like your HOME directory.

Changing build directories

The above installation could therefore be adjusted in a very simple way to install to your HOME directory:

...
$ ./configure --prefix=/home/[asurite]/.local/python-3.9.7 
$ make
$ make install

Container solutions

/wiki/spaces/RC/pages/54099969 is available on the RC supercomputers. Many times, software is distributed in an easy-to-download package (.sif file) which can be uploaded to your HOME directory and used immediately.

In some cases where a pre-configured Singularity is not available, but one can be built with a recipe, the container must be built on your local workstation (rather than the supercomputer), due to sudo/ root requirements.

Please check this dedicated page for more information Apptainer usage .

Additional Help

If you require further assistance on this topic, please don't hesitate to contact the Research Computing Team. To create a support ticket, kindly send an email to rtshelp@asu.edu. For quick inquiries, you're welcome to reach out via our #rc-support Slack Channel or attend our office hours for live assistance

We also offer a series of workshops. More information here: Educational Opportunities and Workshops