Softwares

This section presents the various kinds of software products (binaries, libraries, scripts and tools) available on the center. It is organized as follows. After generally explaining the different kinds of software on the center, we will focus on specific cases (restricted and purchased products). Finally, we will talk about the software life cycle, from the installation request to the product removal.

Generalities on software

Lots of tools and products are available on the supercomputer. A distinction is made between the OS and CCC software.

OS software

They are software products provided by the operating system. They are installed by packages (rpm) and are locally stored on each node.

All common Linux software products enter in this category, such as:

  • shells (bash, tcsh),
  • common scripting tools (cat, sed, awk, …)
  • editors (vi, emacs, gedit, …),
  • minimal installations of common scripting language (perl, python).

Updates occur during maintenance or during production only if they do not impact the operating system of the node.

CCC software

CCC software products are the third-party dedicated tools or dedicated compilations. They are shared by all center nodes and are installed by TGCC-CCRT dedicated service(s) during production. We prefer the term CCC software products over center software which is ambiguous.

Contrary to the OS software products, CCC software products are not within the standard operating system paths for binaries or libraries (eg. /usr/bin or /usr/lib64).

Each product is installed in a dedicated directory and requires an update of environment variables like and before use. These environment updates are handled by the module tool detailed in the Environment management section.

Updates occur during production as they do not interrupt nor interfere with the operating system installation.

Software and module

A CCC software product requires an environment update before use. The module command is the tool for it, so a module exists for each CCC software product.

An OS software product is usually not referred to by a module, except when:

  • it is usually the case in other computing centers (ex: tcl)
  • there is a CCC software version of it (ex: valgrind): it helps to avoid conflicts between the OS and CCC installation.

Products referenced by module have been organized into categories:

  • applications: simulation products
  • environment: defines the user/group environment
  • tools: development tools
  • graphics: visualization or image manipulation tools
  • parallel: parallel execution software such as MPI
  • libraries: third-party libraries
  • compilers: the various compilers

A domain-oriented view is provided by module search <keyword>. To list the valid keywords use:

module help|show products/keywords

Software toolchains

Warning

Please refer to internal technical documentation to get information about available toolchains.

This approach provides a variety of compilation / runtime environments to users with consistency across products. To consult the list of available builds for a given product, type module help <product>.

The selection between toolchains is made with two modules flavor/buildcompiler/<compiler>/<version> and flavor/buildmpi/<mpi>/<version>. It allows you to change the toolchain used for any loaded product regardless of the Intel compiler and MPI implementation used at runtime, which is determined by your current intel and mpi modules loaded.

More information on the flavor mechanism can be found on the dedicated section.

The module flavor/buildcompiler/<compiler>/<version> lets you choose the version of the Intel compiler whereas the module flavor/buildmpi/<mpi>/<version> lets you choose the MPI implementation and version.

Product Life cycle

Here are the phases of a software product life cycle, explained chronologically from its installation request to its deprecation and removal.

Installation request

New products and/or product update(s) can be requested by mail to the TGCC-CCRT hotline.

Requests are usually accepted if:

  • the product is the last stable version,
  • the product is useful to many users,
  • the product has no license issue.

There are also special cases, namely:

Installation phase

If the installation request is approved, we will proceed to the installation itself:

  • for an OS software product, it should be done at the next maintenance (or before if this is deemed safe).
  • and for an CCC software product, it should take several days.

Note

Those are estimated installation times. If technical difficulties occur the installation may take longer (example: licensed products)

Newly installed CCC software maybe listed with:

module help|show products/newinstall

Production phase

During the production, the software product should be operational. If you detect an issue, a bug or a missing feature, please report it to the TGCC-CCRT hotline.

End-of-life and removal

An OS software product is considered obsolete when either the distribution considers it as such or when an update has been planned for the next maintenance.

For CCC software products, we try to respect the following rules. For each CCC software product, the center favors versions with the least bugs, the most features and the best performances. Hence the last stable version of a product is very welcome (new features, better performances and bug corrections). So when a new version of a product is installed, previous versions may become obsolete. To be more specific, we will only keep:

  • the latest version,
  • its last known stable(s) version(s) (for reference purpose),
  • and the version(s) before retro-compatibility issues (mainly API break).

Python

Available versions and toolchains

To display all Python versions, use the command module av -t python3:

python3/x.y.z
python3/x.y.z(stable)
python3/x.y.z(unstable)

The (stable) version only changes for security issues. The (unstable) version changes everytime a user asks for a new package or an update. We higly recommand the (stable) one for virtualenv users.

There are at least three types of Python distributions:

  • System:
    • Only packages that could be compiled with the operating system GCC
  • GCC+OpenMPI:
    • Compiled with a recent GCC and Open MPI
  • GCC+OpenMPI+CUDA
    • Compiled with a recent GCC, Open MPI and CUDA
    • For AI applications (PyTorch, Tensorflow…)

Display available configurations with the command module help python3/<version>.

-------------------------------------------------------------------
 Module Specific Help for /ccc/etc/modulefiles/tools/python3/<version>:

   Software description:
     Name          : Python lang
     Description   : Python programming language
     Version       : <versions>

   Software configuration(s):

     Copy/paste one of the following line ("module purge" could be required).

     Setup(s) for users based on GCC compiler:

       0 : module load gcc/<versions> mpi/openmpi/<versions> flavor/python3/cuda-<version> python3/<version>
       1 : module load gcc/<versions> mpi/openmpi/<versions> python3/<version>

     Setup(s) without specific requirement:

       2*: module load python3/<version>

 -------------------------------------------------------------------

For instance, to load the GCC+Openmpi+CUDA distribution:

$ module load gcc/<version> mpi/openmpi/<version> flavor/python3/cuda-<version> python3/<version>

To list all available Python packages in your current environment, run pip3 list.

Adding new module

Adding new modules in the distribution

In order to request the installation of one or several python modules, please refer to the Installation request part.

Adding new modules locally, through a virtual environment

Load the desired Python environment:

$ module purge ; module load [...] python3/<version>

Create a virtual environment based on this environment:

$ python3 -m venv <my_virtual_env> --system-site-packages

--system-site-packages option indicates that the original Python site-packages will be available to the new environment. Without this option, the new virtual environment will be empty and the environment should be rebuilt from scratch.

Activate it:

source <my_virtual_env>/bin/activate

Import the source code of the Python modules you need to install, for instance: maze-3.0.0.tar.gz (see Data transfers).

Extract the folder from the archive:

tar xfz <module.tar.gz>

Go in the folder containing the installation files:

cd <module>

Install the python module:

python3 setup.py install

You may need to install one or several dependencies to complete the installation. Proceed in the same way for each of those. It is recommended to identify beforehand the aforementioned dependencies either on a local computer and/or by reading the requirements.txt file that should be at the root of the Python package.

Machine learning and artificial intelligence

Pytorch

In order to use Pytorch, you may use the following environment:

$ module purge
$ module load gcc/<version> mpi/openmpi/<version> flavor/python3/cuda-<version> python3/<version>
$ python3
Python 3.x.y (main, XXX XX 20XX, XX:XX:XX) [GCC X.Y.Z] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>>

Tensorflow

In order to use Tensorflow, you may use the following environment:

$ module purge
$ module load gcc/<version> mpi/openmpi/<version> flavor/python3/cuda-<version> python3/<version>
$ python3
Python 3.x.y (main, XXX XX 20XX, XX:XX:XX) [GCC X.Y.Z] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow
>>>

Jupyter-lab

Jupyter-lab is available on irene. You may use the following commands to start Jupyter-lab:

$ module purge
$ module load python3/<version>
# or module load gcc/<version> mpi/openmpi/<version> python3/<version>
# or module load gcc/<version> mpi/openmpi/<version> flavor/python3/cuda-<version> python3/<version>
$ jupyter-lab

Warning

Jupyter-lab is not available with the Intel toolchain.

It is recommended to use NiceDCV for better stability.

Alphafold

We provide access to the DeepMind’s Alphafold software via a container. Included are the OCI image, the complete database and a set of scripts for easier usage.

Available versions

The version available is 2.3.1, and the database includes the latest versions of all files as of December 2022.

Using AlphaFold on TGCC

AlphaFold requires access to the |default_GPU_partition| partition. It may works on other GPU partition. Upon loading the module, you will receive a path to our AlphaFold Readme file.

$ module load alphafold

First import the image using pcocc-rs.

$ pcocc-rs image import docker-archive:${ALPHAFOLD_IMAGE_ROOT}/alphafold-2022.10.24.tar user:alphafold-231

Next, please copy the scripts we have provided to utilize AlphaFold via pcocc-rs.

$ cp -r ${ALPHAFOLDRUN_ROOT}/run_squashfs-flat ${CCCSCRATCHDIR}/<my_test_case>

You have the option to select between monomer or multimer cases. This can be configured in the submission script, with monomer being the default setting. The output directory should exist before sumbitting the script.

$ cat ${ALPHAFOLDRUN_ROOT}/run_squashfs-flat/submit_script_alphafold-231_squashfs-flat.sh
#!/bin/bash
#MSUB -e AF_%J.e
#MSUB -o AF_%J.o

#MSUB -n 1 # nombres de tâches MPI
#MSUB -c |cores_per_GPU_on_default_partition| # number of cores to be booked. You need |cores_per_GPU_on_default_partition| cores to get one GPU.
##MSUB -x #node exclusivity, to be add for big cases. (if you encounter a memory issue)

#MSUB -T 20000
#MSUB -q |default_GPU_partition|    # hybrid may be used as well
#MSUB -A <group>
#MSUB -m work,scratch

module purge
module load alphafold
export CCC_ALPHAFOLD_DATABASE
export CCC_ALPHAFOLD_IMAGE="alphafold-231"

# Use the database stored on hdd to test the impact
#export ALPHAFOLD_USE_DB_HDD=true

# the output directory should exist before launching the job. Adapt to your need.
export ALPHAFOLD_OUTPUT="$(pwd)/output-squash-flat"

# to edit to match your need
export ALPHAFOLD_INPUT=${ALPHAFOLDRUN_ROOT}/exemple_CCRT/input.fasta

# Replace ${ALPHAFOLDRUN_ROOT}/run_pcocc-rs_squashfs-flat_|default_GPU_partition|.sh by the path to your submission script if you want to use a tailored version
ccc_mprun ${ALPHAFOLDRUN_ROOT}/run_squashfs-flat/run_pcocc-rs_squashfs-flat_|default_GPU_partition|_monomer.sh --max_template_date 2020-05-14 --fasta_paths $ALPHAFOLD_INPUT > AF-231-squash-flat.log

Finally, simply submit the script as usual.

$ ccc_msub submit_script_alphafold-231_squashfs-flat.sh

The database includes the following files.

/ccc/products/alphafold-db-2022.10.24/system/default/db/
├── alphafold-db-compressed_hdd.sqsh
├── alphafold-db-compressed.sqsh
├── alphafold-db-flat_hdd.sqsh
├── alphafold-db-flat_t1.sqsh
├── bfd
│   ├── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_a3m.ffdata
│   ├── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_a3m.ffindex
│   ├── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_cs219.ffdata
│   ├── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_cs219.ffindex
│   ├── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_hhm.ffdata
│   └── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_hhm.ffindex
├── mgnify
│   └── mgy_clusters.fa
├── params
│   ├── LICENSE
│   ├── params_model_1_multimer_v3.npz
│   ├── params_model_1.npz
│   ├── params_model_1_ptm.npz
│   ├── params_model_2_multimer_v3.npz
│   ├── params_model_2.npz
│   ├── params_model_2_ptm.npz
│   ├── params_model_3_multimer_v3.npz
│   ├── params_model_3.npz
│   ├── params_model_3_ptm.npz
│   ├── params_model_4_multimer_v3.npz
│   ├── params_model_4.npz
│   ├── params_model_4_ptm.npz
│   ├── params_model_5_multimer_v3.npz
│   ├── params_model_5.npz
│   └── params_model_5_ptm.npz
├── pdb70
│   ├── md5sum
│   ├── pdb70_a3m.ffdata
│   ├── pdb70_a3m.ffindex
│   ├── pdb70_clu.tsv
│   ├── pdb70_cs219.ffdata
│   ├── pdb70_cs219.ffindex
│   ├── pdb70_hhm.ffdata
│   ├── pdb70_hhm.ffindex
│   └── pdb_filter.dat
├── pdb_mmcif
│   ├── mmcif_files
│   └── obsolete.dat
├── pdb_seqres
│   └── pdb_seqres.txt
├── uniclust30
│   ├── UniRef30_2022_02_a3m.ffdata
│   ├── UniRef30_2022_02_a3m.ffindex
│   ├── UniRef30_2022_02_cs219.ffdata
│   ├── UniRef30_2022_02_cs219.ffindex
│   ├── UniRef30_2022_02_hhm.ffdata
│   ├── UniRef30_2022_02_hhm.ffindex
│   └── UniRef30_2022_02.md5sums
├── uniprot
│   ├── uniprot_sprot.fasta
│   └── uniprot_trembl.fasta
└── uniref90
    └── uniref90.fasta

Note

For advanced use of AlphaFold, you may modify run_pcocc-rs_squashfs-flat_|default_GPU_partition|_monomer.sh and run_pcocc-rs_squashfs-flat_|default_GPU_partition|_multimer.sh as needed.

Note

AlphaFold is accessible to members of the alphafold UNIX group. To join, please contact support at please refer to internal documentation to get hotline email or please refer to internal documentation to get hotline phone.

Products list

This section catalogs all the software accessible on irene. For further details about these offerings, please engage with our support team. A number of applications within this list have the capability to execute computations on GPUs, as denoted by the “GPU Support” column. To clarify, this designation is exclusive to end-user applications. However, this does not preclude the possibility of other categories of products, such as tools and libraries, from being capable of running on GPUs. Should you require a GPU-aware version of any application not currently indicated as such, we encourage you to reach out to the support team for support.

The list is available in the dedicated section.

Specific software

The center has specific rules for restricted products and purchased products.

Restricted software products

A restricted product is referenced by module, but its access is restricted to a specific Unix group. Although the reasons may vary, this usually comes from a license requirement.

For example, a licensed product may restrict its usage to academic purposes, or the purchased license is an academic one.

Warning

Please refer to internal technical documentation to get information about this subject.

Installation request and restricted products

Warning

Please refer to internal technical documentation to get information about this subject.

Products with purchased license

Some products (such as Intel compilers) require a license server. We refer to them as licensed products.

Module and licensed products

Here are several adaptations of module for licensed products:

  • A licensed product module depends on a license module to find its license server.
  • Although the license module is not shown at load time, a module list can display it.
  • license module are named licsrv/<server> and are listed by:
module avail licsrv

Installation request and purchased products

While requesting the installation of a purchased product, you may:

  • have a license not requiring a dedicated server,
  • have the license and want to restrict its usage to a group of people (because you only have a few tokens),
  • have a global license (limited in time),
  • have no license and ask for the center to purchase it.

The two first cases are handled by defining it as a restricted product.

The last case must be clearly justified. If so, you must at least:

  • estimate the number of user,
  • specify its application domain,
  • tell us if you need the academic or the commercial license,
  • and tell us if you need a global license and/or how many tokens are necessary.

Please note that, even if such installation follows the usual validation process, you may have additional delays, namely:

  • if you need a non-FlexNet dedicated license server,
  • if you need to generate some license server identification (done by us and filtered for security reasons) before getting the license.