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.
...
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 UH-HPC 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.
...