Anaconda

On Koa, modules for Anaconda exist.  These modules are provided so that users do not need to install their own copy of anaconda or miniconda.  While this may provide convenience  to many users, for those that require full control over their conda version, please look at the MiniConda guide.

While the modules for Anaconda can simplify using conda install software, it does have at least two things that you should be aware of:

1. The conda version is updated using newer modules, so some packages may be out of date compared to the latest available version
2. Not all of the latest commands work with the Anaconda modules.  The most visible case of this is how one activates and deactivates a conda environment.

To build an conda environment on Koa, one would first start an interactive session and then load the specific Anaconda module they wish to use.  Take note of the module you use, since you will need to load the anaconda module each time you wish to use anaconda and you may want to use the same or newer version.

[user@login001 ~]$ srun -p sandbox --mem=6G -c 2 -t 60 --pty /bin/bash
[user@node-0005 ~]$ module load  lang/Anaconda3
[user@node-0005 ~]$ mamba create -n ipyrad -c conda-forge -c bioconda ipyrad

Once anaconda is loaded, you will now be able to create an anaconda environment, using the conda  create command.  In the example below, we will be naming our conda environment "test" and temporarily adding the conda channel of "conda-forge", while trying to install "

[user@node-0005 ~]$ mamba create -n test -c conda-forge -c conda  python=3.8 matplotlib scipy ipython

Once the environment is installed, it can be activated using "source activate test", or the generic form of "source activate [name of conda environment ]".

[user@node-0005 ~]$ source activate test
(test) [user@node-0005 ~]$ conda deactivate
[user@node-0005 ~]$ 

MiniConda

While a base anaconda module exists for users to access and build their own conda environments, this is not the only way.  Below you will find instructions created by Eric Firing covering an alternate method in which you can use miniconda on Koa instead of the Anaconda module.

Source material for the below instructions can be found at: https://currents.soest.hawaii.edu/ocn_data_analysis/packages.html

Clusters are set up and managed centrally, so setting up and using the conda package manager and conda-installed packages is a little bit different than it would be on a user’s own Linux box or Mac. There are three types of difference:

1. The user has no ability to install system-level packages. Instead, the administrators install packages together with modules that the user can load to put those packages on the user’s path, thereby making them accessible.

2. The user cannot write to the user’s own .bashrc file, even though the standard Linux permissions for the file show the file as user-writable. Writing is blocked at a different level.

3. Some libraries must be compiled specifically for HPC use, so packages from conda-forge using the Message Passing Interface (MPI) might not work correctly. See this note on MPI in conda-forge. I don’t know how this applies to the Koa.

The Koa admins have created a module giving access to a base Anaconda environment at the system level, meaning the user cannot change anything in that environment. It is possibly, however, to use that as a base environment for the creation of new working environments in the user’s directory tree (specifically, hidden in the ~/.conda/ subdirectory). This still has some disadvantages compared to using a normal Miniconda installation; primarily, that conda itself (which must live in the base environment) cannot be updated, and that the newer method of activating and deactivating environments with conda is unavailable.

A naive attempt to install Miniconda fails because .bashrc is not writable. But there is a reasonably clean and simple workaround: use zsh instead of bash when working with conda or in conda environments.

We will now illustrate how to set up a Miniconda installation in a user’s home directory. We are assuming the directory is freshly prepared for a new user; if not, at least check ~/.bash_profile to see that nothing python-related has been put on the PATH either directly or via module loading. If .conda/ and/or .condarc are present, it would be advisable to rename or delete them.

Starting in either a login node or a compute node, make zsh available by appending this line to the .bash_profile file:

module load tools/zsh

At this point there is no .zshrc file, so make one that starts with the following line:

. /usr/share/lmod/lmod/init/zsh # Needed to run modules in zsh

Now log out completely, log back in, and start an interactive session on a compute node. Download the Miniconda installer:

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh

Run it like this, but at the end, answer “N” to the question about shell initialization:

bash Miniconda3-latest-Linux-x86_64.sh

Now tell it to initialize for zsh:

miniconda3/condabin/conda init zsh

Switch into zsh by executing:

zsh

and you should be in your fresh base environment. Now would be a good time to tell conda to prefer conda-forge. Execute:

conda config --add channels conda-forge conda config --set channel_priority strict

Make your first working environment with some basics, and switch to it:

conda create -n py38 python=3.8 matplotlib scipy ipython 
conda activate py38

Of course, any time you can use conda to add more packages, use pip to install packages that are not available from conda-forge, make and populate new environments, etc. Just be careful to activate whichever environment you want to work with.

Now, completely log out, and log back in to a login node. You can start an interactive compute session directly with zsh, or start first with bash and than execute zsh in the resulting terminal to switch. An example of the first case would be:

srun -I30 -p sandbox -N 1 -c 1 --mem=6G -t 0-01:00:00 --pty zsh

Your terminal should now be in a compute node, running zsh, with the base environment activated. Don’t forget to activate your desired working environment.

If you don’t want zsh to come up with the base activated you can use one more conda configuration option:

conda config --set auto_activate_base false

Like the other conda config commands, this is actually writing to the ~/.condarc file.

Note that you can activate any environment from scratch; conda will be on your path in zsh even when you have not activated an environment, so you can directly:

conda activate py38

for example, from your zsh shell, regardless of whether any other environment is active.

External Links

Using Intel optimized packages in Anaconda

Intel Anaconda Channel