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 Mana 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:
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.
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.
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 Mana.
The Mana 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:
. /opt/ohpc/admin/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.