GROMACS

From Alliance Doc
Jump to navigation Jump to search
This site replaces the former Compute Canada documentation site, and is now being managed by the Digital Research Alliance of Canada.

Ce site remplace l'ancien site de documentation de Calcul Canada et est maintenant géré par l'Alliance de recherche numérique du Canada.

This page is a translated version of the page GROMACS and the translation is 96% complete.
Outdated translations are marked like this.
Other languages:

Généralités

GROMACS est un logiciel de simulation en dynamique moléculaire pouvant traiter des systèmes composés de quelques centaines à quelques millions de particules. D'abord conçu pour les molécules biochimiques avec de nombreuses interactions liantes et complexes telles que les protéines, lipides et acides nucléiques, GROMACS est aussi utilisé par plusieurs groupes de recherche sur des systèmes non biologiques (par ex. les polymères) en raison de la vitesse à laquelle le logiciel calcule les interactions non liantes souvent dominantes dans le temps de calcul d'une simulation.

Points forts

  • Très bonne performance comparativement à d'autres applications.
  • Depuis GROMACS 4.6, excellente accélération CUDA des GPU possédant la capacité de calcul Nvidia, soit >= 2.0 (par exemple Fermi ou plus).
  • Grand choix d'outils d'analyse des trajectoires.
  • Exécution en parallèle avec le protocole MPI standard ou la bibliothèque de calcul Thread MPI pour les postes de travail à nœuds simples.
  • Logiciel gratuit sous la version 2.1 de LGPL (GNU Lesser General Public License).

Points faibles

  • Afin d'augmenter la vitesse de simulation, les analyses et/ou la collecte de données interactives sont réduites. Il peut donc s'avérer difficile d'obtenir de l'information non standard sur le système faisant l'objet de la simulation.
  • Les méthodes de simulation et les paramètres par défaut varient grandement d'une version à l'autre. Il peut s'avérer difficile de reproduire les mêmes résultats avec des versions différentes.
  • Les outils d’analyse et les utilitaires ajoutés au programme ne sont pas toujours de la meilleure qualité : ils peuvent contenir des bogues et les méthodes sont souvent mal documentées. Nous recommandons l'emploi de méthodes indépendantes pour vérifier les résultats.

Utilisation de GPU

La première partie du fichier de journalisation décrit la configuration et indique si la version utilisée permet l'utilisation de GPU. GROMACS utilise automatiquement tout GPU repéré.

GROMACS utilise à la fois les CPU et les GPU; la performance est tributaire d’un équilibre raisonnable entre les deux.

La nouvelle liste de voisins (neighbor structure) exigeait l'ajout au fichier MDP de la nouvelle variable du rayon de coupure (cutoff-scheme). Le comportement des versions d'avant 4.6 correspond à cutoff-scheme = group, alors que pour utiliser l'accélération GPU il faut plutôt cutoff-scheme = verlet qui est par défaut dans la version 5.

Guide de démarrage

Cette section aborde les détails de configuration.

Modules d'environnement

Les versions suivantes sont disponibles :

GROMACS modules pour utiliser les CPU modules pour utiliser les GPU (CUDA) Notes
gromacs/2023.3 StdEnv/2023 gcc/12.3 openmpi/4.1.5 gromacs/2023.3 gcc/12.3 openmpi/4.1.5 cuda/12.2 gromacs/2023.3 GCC, FlexiBLAS & FFTW
GROMACS modules pour utiliser les CPU modules pour utiliser les GPU (CUDA) Notes
gromacs/2023.2 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2023.2 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs/2023.2 GCC, FlexiBLAS & FFTW
gromacs/2023 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2023 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs/2023 GCC, FlexiBLAS & FFTW
gromacs/2022.3 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2022.3 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs/2022.3 GCC, FlexiBLAS & FFTW
gromacs/2022.2 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2022.2 GCC, FlexiBLAS & FFTW
gromacs/2021.6 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2021.6 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs/2021.6 GCC, FlexiBLAS & FFTW
gromacs/2021.4 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2021.4 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs/2021.4 warning GCC, FlexiBLAS & FFTW
gromacs/2021.2 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs/2021.2 warning GCC, FlexiBLAS & FFTW
gromacs/2021.2 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2021.2 StdEnv/2020 gcc/9.3.0 cuda/11.0 openmpi/4.0.3 gromacs/2021.2 warning GCC & MKL
gromacs/2020.6 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2020.6 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs/2020.6 warning GCC, FlexiBLAS & FFTW
gromacs/2020.4 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs/2020.4 warning GCC, FlexiBLAS & FFTW
gromacs/2020.4 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2020.4 StdEnv/2020 gcc/9.3.0 cuda/11.0 openmpi/4.0.3 gromacs/2020.4 warning GCC & MKL
GROMACS version modules for running on CPUs modules for running on GPUs (CUDA) Notes
gromacs/2020.2 StdEnv/2018.3 gcc/7.3.0 openmpi/3.1.2 gromacs/2020.2 StdEnv/2018.3 gcc/7.3.0 cuda/10.0.130 openmpi/3.1.2 gromacs/2020.2 warning GCC & MKL
gromacs/2019.6 StdEnv/2018.3 gcc/7.3.0 openmpi/3.1.2 gromacs/2019.6 StdEnv/2018.3 gcc/7.3.0 cuda/10.0.130 openmpi/3.1.2 gromacs/2019.6 GCC & MKL
gromacs/2019.3 StdEnv/2018.3 gcc/7.3.0 openmpi/3.1.2 gromacs/2019.3 StdEnv/2018.3 gcc/7.3.0 cuda/10.0.130 openmpi/3.1.2 gromacs/2019.3 GCC & MKL  ‡
gromacs/2018.7 StdEnv/2018.3 gcc/7.3.0 openmpi/3.1.2 gromacs/2018.7 StdEnv/2018.3 gcc/7.3.0 cuda/10.0.130 openmpi/3.1.2 gromacs/2018.7 GCC & MKL
GROMACS version modules for running on CPUs modules for running on GPUs (CUDA) Notes
gromacs/2018.3 StdEnv/2016.4 gcc/6.4.0 openmpi/2.1.1 gromacs/2018.3 StdEnv/2016.4 gcc/6.4.0 cuda/9.0.176 openmpi/2.1.1 gromacs/2018.3 GCC & FFTW
gromacs/2018.2 StdEnv/2016.4 gcc/6.4.0 openmpi/2.1.1 gromacs/2018.2 StdEnv/2016.4 gcc/6.4.0 cuda/9.0.176 openmpi/2.1.1 gromacs/2018.2 GCC & FFTW
gromacs/2018.1 StdEnv/2016.4 gcc/6.4.0 openmpi/2.1.1 gromacs/2018.1 StdEnv/2016.4 gcc/6.4.0 cuda/9.0.176 openmpi/2.1.1 gromacs/2018.1 GCC & FFTW
gromacs/2018 StdEnv/2016.4 gromacs/2018 StdEnv/2016.4 cuda/9.0.176 gromacs/2018 Intel & MKL
gromacs/2016.5 StdEnv/2016.4 gcc/6.4.0 openmpi/2.1.1 gromacs/2016.5 StdEnv/2016.4 gcc/6.4.0 cuda/9.0.176 openmpi/2.1.1 gromacs/2016.5 GCC & FFTW
gromacs/2016.3 StdEnv/2016.4 gromacs/2016.3 StdEnv/2016.4 cuda/8.0.44 gromacs/2016.3 Intel & MKL
gromacs/5.1.5 StdEnv/2016.4 gromacs/5.1.5 StdEnv/2016.4 cuda/8.0.44 gromacs/5.1.5 Intel & MKL
gromacs/5.1.4 StdEnv/2016.4 gromacs/5.1.4 StdEnv/2016.4 cuda/8.0.44 gromacs/5.1.4 Intel & MKL
gromacs/5.0.7 StdEnv/2016.4 gromacs/5.0.7 StdEnv/2016.4 cuda/8.0.44 gromacs/5.0.7 Intel & MKL
gromacs/4.6.7 StdEnv/2016.4 gromacs/4.6.7 StdEnv/2016.4 cuda/8.0.44 gromacs/4.6.7 Intel & MKL
gromacs/4.6.7 StdEnv/2016.4 gcc/5.4.0 openmpi/2.1.1 gromacs/4.6.7 StdEnv/2016.4 gcc/5.4.0 cuda/8.0 openmpi/2.1.1 gromacs/4.6.7 GCC & MKL & ThreadMPI

Remarques :

  • * warning Les versions 2020.0 jusqu'à 2021.5 inclusivement contiennent un bogue quand elles sont utilisées avec des GPU de génération Volta ou plus récentes (V100, T4 et A100) avec l'option -update gpu de mdrun qui aurait pu perturber le calcul viriel et ainsi fausser le raccord de pression. Dans les notes de mise à jour de la version 2021.6 on peut lire :[1]

    [traduction libre] La mise à jour n'est pas activée par défaut sur le GPU et donc l'erreur ne peut se produire que dans les simulations où l'option -update gpu a été explicitement sélectionnée; même dans ce cas, l'erreur peut être rare car nous ne l'avons pas observée en pratique dans les tests que nous avons effectués.

    Vous trouverez plus d'information dans GitLab, au sujet #4393 du projet GROMACS.[2]
  • Les versions depuis 2020.4 ont été compilées pour l'environnement logiciel standard StdEnv/2020.
  • Les versions 2018.7 et suivantes ont été compilées avec les compilateurs GCC et la bibliothèque MKL puisqu’ils améliorent légèrement la performance.
  • Les versions antérieures ont été compilées avec soit des compilateurs GCC et FFTW, soit avec des compilateurs Intel MKL avec des bibliothèques Open MPI 2.1.1 à partir de l'environnement par défaut, comme indiqué dans le tableau ci-dessus.
  • Les versions CPU (non GPU) sont disponibles en simple et double précisions à l'exception de 2019.3 (‡), où la double précision n'est pas disponible pour AVX512.

Pour charger ces modules, utilisez la commande module load avec les noms indiqués dans le tableau ci-dessus, par exemple 

$ module load  StdEnv/2020  gcc/9.3.0  openmpi/4.0.3  gromacs/2023.2
or 
$ module load  StdEnv/2023  gcc/12.3   openmpi/4.1.5  gromacs/2023.3

Ces versions utilisent aussi les GPU, mais uniquement en simple précision. Pour charger la version utilisant les GPU, chargez d'abord le module cuda. Pour les noms, voyez le tableau ci-dessus. 

$ module load  StdEnv/2020  gcc/9.3.0  cuda/11.4  openmpi/4.0.3  gromacs/2023.2 
or
$ module load  StdEnv/2023  gcc/12.3  openmpi/4.1.5  cuda/12.2  gromacs/2023.3

Consultez Utiliser des modules pour plus d’information sur les modules d’environnement.

Suffixes

Versions 5.x, 2016.x et suivantes

Les versions 5 et suivantes comprennent quatre binaires possédant toutes les fonctionnalités de GROMACS. Les outils des versions précédentes ont été implémentés en sous-commandes des binaires gmx. Consultez GROMACS 5.0 Tool Changes et la documentation GROMACS.

  • gmx - GROMACS en mixte (simple) précision avec OpenMP, mais sans MPI
  • gmx_mpi - GROMACS en mixte (simple) précision avec OpenMP et MPI
  • gmx_d - GROMACS en double précision avec OpenMP, mais sans MPI
  • gmx_mpi_d - GROMACS en double précision avec OpenMP et MPI

Version 4.6.7

  • Les binaires double précision ont le suffixe _d.
  • Les binaires parallèles simple précision et double précision mdrun sont :
  • mdrun_mpi
  • mdrun_mpi_d


Scripts de soumission des tâches

Consultez Exécuter des tâches sur comment utiliser l'ordonnanceur Slurm.

Tâches séquentielles

Voici un script simple pour la tâche séquentielle mdrun.


File : serial_gromacs_job.sh

#!/bin/bash
#SBATCH --time=0-0:30         # time limit (D-HH:MM)
#SBATCH --mem-per-cpu=1000M   # memory per CPU (in MB)
module purge  
module load  StdEnv/2023  gcc/12.3  openmpi/4.1.5  gromacs/2024.1
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"
gmx mdrun -nt 1 -deffnm em


La simulation du système moléculaire sera exécutée dans le fichier em.tpr.

Nœuds entiers

Les systèmes simulés par GROMACS sont habituellement si grands que vous voudrez utiliser plusieurs nœuds entiers.

Le produit de --ntasks-per-node= par --cpus-per-task correspond généralement au nombre de cœurs CPU dans les nœuds de calcul de la grappe. Voir la section Performance ci-dessous.

File : gromacs_whole_node_graham.sh

#!/bin/bash
#SBATCH --nodes=1                # number of nodes
#SBATCH --ntasks-per-node=16     # request 16 MPI tasks per node
#SBATCH --cpus-per-task=2        # 2 OpenMP threads per MPI task => total: 16 x 2 = 32 CPUs/node
#SBATCH --mem-per-cpu=2000M      # memory per CPU (in MB)
#SBATCH --time=0-01:00           # time limit (D-HH:MM)
module purge  
module load  StdEnv/2023  gcc/12.3  openmpi/4.1.5  gromacs/2024.1
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

srun --cpus-per-task=$OMP_NUM_THREADS gmx_mpi mdrun -deffnm md
File : gromacs_whole_node_cedar.sh

#!/bin/bash
#SBATCH --nodes=1                        # number of nodes
#SBATCH --ntasks-per-node=24             # request 24 MPI tasks per node
#SBATCH --cpus-per-task=2                # 2 OpenMP threads per MPI task => total: 24 x 2 = 48 CPUs/node
#SBATCH --constraint="[skylake|cascade]" # restrict to AVX512 capable nodes.
#SBATCH --mem-per-cpu=2000M              # memory per CPU (in MB)
#SBATCH --time=0-01:00                   # time limit (D-HH:MM)
module purge
module load arch/avx512   # switch architecture for up to 30% speedup
module load  StdEnv/2023  gcc/12.3  openmpi/4.1.5  gromacs/2024.1
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"
 
srun --cpus-per-task=$OMP_NUM_THREADS gmx_mpi mdrun -deffnm md
File : gromacs_whole_node_beluga.sh

#!/bin/bash
#SBATCH --nodes=1                # number of nodes
#SBATCH --ntasks-per-node=20     # request 20 MPI tasks per node
#SBATCH --cpus-per-task=2        # 2 OpenMP threads per MPI task => total: 20 x 2 = 40 CPUs/node
#SBATCH --mem-per-cpu=2000M      # memory per CPU (in MB)
#SBATCH --time=0-01:00           # time limit (D-HH:MM)
module purge  
module load  StdEnv/2023  gcc/12.3  openmpi/4.1.5  gromacs/2024.1
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"
 
srun --cpus-per-task=$OMP_NUM_THREADS gmx_mpi mdrun -deffnm md
File : gromacs_whole_node_beluga.sh

#!/bin/bash
#SBATCH --nodes=1                # number of nodes
#SBATCH --ntasks-per-node=32     # request 32 MPI tasks per node
#SBATCH --cpus-per-task=2        # 2 OpenMP threads per MPI task => total: 20 x 2 = 40 CPUs/node
#SBATCH --mem-per-cpu=2000M      # memory per CPU (in MB)
#SBATCH --time=0-01:00           # time limit (D-HH:MM)
module purge  
module load  StdEnv/2023  gcc/12.3  openmpi/4.1.5  gromacs/2024.1
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"
 
srun --cpus-per-task=$OMP_NUM_THREADS gmx_mpi mdrun -deffnm md
File : gromacs_whole_node_niagara.sh

#!/bin/bash
#SBATCH --nodes=1                # number of nodes
#SBATCH --ntasks-per-node=10     # request 10 MPI tasks per node
#SBATCH --cpus-per-task=4        # 4 OpenMP threads per MPI task => total: 10 x 4 = 40 CPUs/node
#SBATCH --mem-per-cpu=2000M      # memory per CPU (in MB)
#SBATCH --time=0-01:00           # time limit (D-HH:MM)
module purge --force
module load CCEnv
module load  StdEnv/2023  gcc/12.3  openmpi/4.1.5  gromacs/2024.1
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"
 
srun --cpus-per-task=$OMP_NUM_THREADS gmx_mpi mdrun -deffnm md

Tâches GPU

Le script suivant exécute mdrun sur quatre fils OpenMP et un GPU.

{{File 

 |name=gpu_gromacs_job.sh
 |lang="sh"
 |contents=
  1. !/bin/bash
  2. SBATCH --gres=gpu:p100:1 # request 1 GPU as "generic resource"
  3. SBATCH --cpus-per-task=4 # number of OpenMP threads per MPI process
  4. SBATCH --mem-per-cpu=1000 # memory limit per CPU core (megabytes)
  5. SBATCH --time=0:30:00 # time limit (D-HH:MM:ss)

module purge module load StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs/2023.2 export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

Please read Using GPUs with Slurm for general information on using GPUs on our systems.

This is a job script for mdrun using 4 OpenMP threads and one GPU:

File : gpu_gromacs_job.sh

#!/bin/bash
#SBATCH --gpus-per-node=1        # request 1 GPU per node
#SBATCH --cpus-per-task=4        # number of OpenMP threads per MPI process
#SBATCH --mem-per-cpu=2000M      # memory limit per CPU core (megabytes)
#SBATCH --time=0:30:00           # time limit (D-HH:MM:ss)
module purge  
module load StdEnv/2023  gcc/12.3  openmpi/4.1.5  cuda/12.2  gromacs/2024.1
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

gmx mdrun -ntomp ${SLURM_CPUS_PER_TASK:-1} -deffnm md


Travailler avec des GPU

Il faut noter que le fait d'utiliser plus qu'un GPU cause habituellement une pauvre efficacité. Avant d'utiliser plusieurs GPU pour vos simulations, effectuez des tests comparatifs avec un seul et avec plusieurs pour évaluer la performance

  • warning Les versions 2020.0 jusqu'à 2021.5 inclusivement contiennent un bogue quand elles sont utilisées avec des GPU de génération Volta ou plus récentes (V100, T4 et A100) avec l'option -update gpu de mdrun qui aurait pu perturber le calcul viriel et ainsi fausser le raccord de pression. Dans les notes de mise à jour de la version 2021.6 on peut lire :[3]

    [traduction libre] La mise à jour n'est pas activée par défaut sur le GPU et donc l'erreur ne peut se produire que dans les simulations où l'option -update gpu a été explicitement sélectionnée; même dans ce cas, l'erreur peut être rare car nous ne l'avons pas observée en pratique dans les tests que nous avons effectués.

    Vous trouverez plus d'information dans GitLab, au sujet #4393 du projet GROMACS.[4]
  • Les nœuds GPU sont configurés différemment sur nos grappes.
  • Cedar offre 4 GPU et 24 cœurs CPU par nœud
  • Graham offre 2 GPU et 32 cœurs CPU par nœud.
Les paramètres sont différents si vous voulez utiliser tous les GPU et cœurs CPU d'un nœud.
  • Cedar : --gres=gpu:p100:4 --ntasks-per-node=4 --cpus-per-task=6
  • Graham : --gres=gpu:p100:2 --ntasks-per-node=4 --cpus-per-task=8
Bien entendu, le système simulé doit être assez grand pour utiliser toutes les ressources.
  • GROMACS impose certaines contraintes dans le choix du nombre de GPU, de tâches (rang MPI) et de fils OpenMP.

Pour la version 2018.2, les contraintes sont :

  • --tasks-per-node doit être un multiple du nombre de GPU (--gres=gpu:)
  • GROMACS fonctionne avec un seul fil OpenMP seulement si l'option -ntomp est utilisée.
    Le nombre optimal de --cpus-per-task se situe entre 2 et 6, selon les développeurs.
  • Évitez d'utiliser une fraction de CPU et de mémoire plus grande que la fraction de GPU que vous demandez dans un nœud.
  • Même si selon les développeurs de l'ordonnanceur Slurm il est préférable de démarrer les tâches MPI avec srun plutôt qu'avec mpiexec/mpirun, certaines tâches n'arrivent pas à démarrer quand deux tâches utilisent srun sur le même nœud de calcul.
    Dans ces cas, nous recommandons donc d'utiliser mpiexec, surtout lorsque seuls des nœuds partiels sont utilisés.

You can explore some benchmark results on our MDBench portal.

Utilisation

[cette section est en préparation]

Préparation du système

L'exécution d'une simulation requiert un fichier d'entrée binaire tpr (portable binary run input file) qui contient la structure de simulation de départ, la topologie moléculaire et l'ensemble des paramètres de simulation.

La commande gmx grompp crée les fichiers tpr; pour les versions antérieures à 5.0, la commande est grompp. Vous avez besoin des fichiers suivants :

  • Le fichier de coordonnées avec la structure de départ; les formats de fichiers valides sont .gro, .pdb oo .cpt (point de contrôle GROMACS).
  • Le fichier de topologie du système au format top; celui-ci détermine le champ de force et la façon dont les paramètres du champ de force s'appliquent au système simulé. Les topologies des parties individuelles du système simulé (soit les molécules) sont placées dans des fichiers itp distincts et sont incluses dans le fichier top avec la commande #include.
  • Le fichier mdp des paramètres d'exécution. Consultez le guide GROMACS pour la description détaillée des options.

Les fichiers trp sont portables et peuvent donc être groupés (grompp-ed) sur une grappe, copiés sur une autre grappe et utilisés comme fichier d'entrée pour mdrun. Utilisez toujours la même version GROMACS pour grompp et mdrun. Même si mdrun peut utiliser des fichiers tpr créés avec une version antérieure de grompp, la simulation peut donner des résultats inattendus.

Exécuter une simulation

Les simulations MD prennent souvent plus de temps à compléter que la durée maximale permise en temps réel pour une tâche; elles doivent donc être redémarrées. Pour minimiser le temps d'attente avant le lancement d'une tâche, vous pouvez maximiser le nombre de nœuds auxquels vous avez accès en choisissant une durée d'exécution plus courte. Un bon compromis entre le temps d'attente et la durée d'exécution est souvent de demander une durée en temps réel de 24 ou 72 heures.

Vous devriez utiliser le paramètre -maxh de mdrun pour indiquer au programme la durée en temps réel pour que l'étape en cours se termine bien lorsque la durée atteint 99%. De cette façon, mdrun crée à cette étape un fichier de point de contrôle (checkpoint file) et lui permet de bien fermer tous les fichiers de sortie (trajectoires, énergie, journalisation, etc.).

Par exemple, utilisez #SBATCH --time=24:00 avec gmx mdrun -maxh 24 ... ou #SBATCH --time=3-00:00 avec gmx mdrun -maxh 72 ....


File : gromacs_job.sh

#!/bin/bash
#SBATCH --nodes=1                # number of Nodes
#SBATCH --tasks-per-node=32      # number of MPI processes per node
#SBATCH --mem-per-cpu=4000       # memory limit per CPU (megabytes)
#SBATCH --time=24:00:00          # time limit (D-HH:MM:ss)
module purge
module load StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2023.2
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

srun  gmx_mpi  mdrun  -deffnm md  -maxh 24



Redémarrer une simulation

Vous pouvez redémarrer une simulation avec la même commande mdrun que pour la simulation originale en ajoutant le paramètre -cpi state.cpt où state.cpt est le nom du dernier fichier de point de contrôle. Depuis la version 4.5, mdrun tente par défaut d'utiliser les fichiers existants (trajectoires, énergie, journalisation, etc.). GROMACS vérifie la cohérence entre les fichiers de sortie et rejette au besoin les étapes plus récentes que le fichier de point de contrôle.

Le paramètre -maxh fait en sorte que les fichiers de contrôle et de sortie sont cohérents au moment où la simulation atteint la durée limite d'exécution.

Pour plus d'information, consultez la documentation GROMACS. [5] [6].


File : gromacs_job_restart.sh

#!/bin/bash
#SBATCH --nodes=1                # number of Nodes
#SBATCH --tasks-per-node=32      # number of MPI processes per node
#SBATCH --mem-per-cpu=4000       # memory limit per CPU (megabytes)
#SBATCH --time=24:00:00          # time limit (D-HH:MM:ss)
module purge
module load StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2023.2
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

srun  gmx_mpi  mdrun  -deffnm md  -maxh 24.0  -cpi md.cpt


Performance

Il n'est pas facile d'obtenir la meilleure performance mdrun et les développeurs de GROMACS y consacrent beaucoup d'information en rapport avec les options, paramètres et stratégies.[7]

Il n'y a pas de solution universelle, mais le meilleur choix de paramètres dépend fortement de la taille du système (nombre de particules, taille et forme de la boite de simulation) et des paramètres de la simulation (rayons de coupure, utilisation de la sommation d'Ewald[8]).

L'information et les statistiques de performance sont imprimées à la fin du fichier md.log, permettant de mieux identifier les goulots d'étranglement. On peut souvent y trouver aussi des notes sur comment améliorer la performance.

La performance de la simulation se mesure typiquement par le nombre de nanosecondes de trajectoire pouvant être simulée en un jour (ns/jour).

La scalabilité parallèle indique l'efficacité de l'utilisation des ressources de calcul. Elle se mesure comme suit&nbsp:

S = pN / ( N * p1 )

où pN représente la performance avec N cœurs CPU.

Idéalement, la performance s'accroît de façon linéaire avec le nombre de cœurs CPU. (scalabilité linéaire; S = 1).


Processus MPI / Tâches Slurm / Décomposition des domaines

La façon la plus simple d'augmenter le nombre de processus MPI (MPI-ranks dans la documentation GROMACS) est d'utiliser les options Slurm --ntasks ou --ntasks-per-node Slurm dans le script.

GROMACS utilise la méthode de décomposition des domaines[8] (DD) pour distribuer sur plusieurs cœurs CPU la solution des interactions non liantes entre particules (PP). Ceci s'effectue en découpant en domaines la boite de simulation selon les axes X, Y et/ou Z et en assignant chacun des domaines à un processus MPI.

Ceci fonctionne bien jusqu'à ce que le temps exigé pour la communication devienne grand par rapport à la taille du domaine en termes de nombre de particules et de volume du domaine. La scalabilité parallèle tombe loin sous 1 et dans les cas extrêmes, la performance diminue avec l'augmentation du nombre de domaines.

GROMACS peut répartir la charge de façon dynamique (dynamic load balancing) pour déplacer dans une certaine mesure les frontières des domaines afin d'empêcher que certains prennent beaucoup plus de temps à résoudre que d'autres. Le paramètre mdrun est présent par défaut.

Dans chaque direction, un domaine ne peut pas être plus petit que le plus long rayon de coupure.


Sommation d'Ewald (PME) et interactions à distance

La sommation d'Ewald (PME ou particle mesh Ewald method) est souvent employée pour le calcul des interactions non liantes à distance, soit les interactions qui dépassent le rayon de coupure. Puisque cette méthode nécessite une communication globale, la performance peut se dégrader rapidement lorsque plusieurs processus MPI sont impliqués à la fois dans le calcul des interactions rapprochées protéine-protéine (PP) et des interactions à distance (PME). Pour éviter cette baisse de performance, des processus MPI traiteront uniquement des interactions PME.

Avec un total de plus de 12 processus MPI, mdrun utilise par défaut une méthode heuristique pour attribuer ces processus au calcul des interactions PME. Le nombre de rangs PME peut être sélectionné manuellement avec le paramètre mdrun -npme.

Dans le cas d'un débalancement de charge important entre les rangs PP et PME (c'est-à-dire que les rangs PP travaillent plus que les rangs PME au cours d'une étape), le travail peut être redirigé des rangs PP aux rangs PME en augmentant le rayon de coupure. Ceci n'aura aucun effet sur le résultat puisque la somme des forces (ou énergies) des interactions rapprochées et de celles à distance demeure la même pour une étape particulière. À partir de la version 4.6, mdrun tente de faire ceci automatiquement, sauf si le paramètre -notunepme est utilisé.

À partir de la version 2018, les interactions PME peuvent être redirigées vers un GPU (voir ci-dessous), mais la version 2018.1 présente toutefois plusieurs contraintes[9] dont le fait qu'un seul rang GPU peut être dédié aux PME.


Fils OpenMP / Nombre de CPU par tâche

Une fois que la décomposition des domaines atteint la limite de scalabilité (décroissance de la scalabilité parallèle), la performance peut encore être améliorée avec des fils OpenMP par la distribution du travail d'un processus MPI (rang) sur plus d'un cœur CPU. et srun. Pour ce faire, utilisez le paramètre --cpus-per-task dans le script (à la fois pour #SBATCH> etsrun). Aussi, définissez la variable OMP_NUM_THREADS' avec export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}" (recommandé) ou le paramètre mdrun -ntomp ${SLURM_CPUS_PER_TASK:-1}.

Selon les programmeurs de GROMACS le nombre optimal de fils OpenMP par processus MPI (CPU par tâche) se situe habituellement entre 2 et 6. Cependant, il vaut la peine d'augmenter le nombre de CPU par tâche dans le cas de tâches exécutées sur un nombre élevé de nœuds.

Surtout dans les cas où la méthode PME n'est pas employée, il n'est pas nécessaire de se soucier de PP-PME Load Imbalance; nous pouvons sélectionner 2 ou 4 ntasks-per-node et définir cpus-per-task par une valeur où ntasks-per-node * cpus-per-task correspond au nombre de cœurs CPU dans un nœud de calcul.

Architecture des CPU

GROMACS utilise des fonctions optimisées (kernel functions) pour calculer la portion réelle des interactions non liées à courte portée. Ces fonctions sont disponibles pour une variété de jeux d’instructions SIMD tels qu’AVX, AVX2 ou AVX512. Ces fonctions sont choisies lors de la compilation de GROMACS, et devraient correspondre aux capacités des CPU qui exécuteront les simulations. Cela est fait pour vous par l’équipe de Calcul Canada : quand vous ajoutez à votre environnement un module pour GROMACS, une version pour AVX/AVX2/AVX512 est choisie en fonction de l’architecture de la grappe de calculs. GROMACS indique quel jeu d’instructions SIMD il supporte dans le fichier du journal (log) et vous avertira si la fonction choisie est sous-optimale.

Toutefois, certaines grappes de calcul contiennent une variété de CPU ayant différents niveaux de support SIMD. Dans ce cas, le plus petit commun dénominateur est choisi. Par exemple, si la machine a des CPU Skylake (AVX/AVX2/AVX512) et Broadwell (AVX/AVX2), comme c’est le cas présentement (mai 2020) pour Cedar, une version de GROMACS pour AVX2 sera choisie. Cela implique que vous pouvez obtenir une fonction sous-optimale, dépendamment des nœuds de calculs alloués à votre tâche.

Vous pouvez demander explicitement des nœuds de calcul supportant AVX512 avec l’option SLURM --constraint=cascade|skylake sur les grappes qui offrent ces types de nœuds. Ceci fera en sorte que votre tâche sera assignée soit à des nœuds dans une architecture Cascade Lake, soit à des nœuds dans une architecture Skylake, mais non distribuée sur les deux architectures.

Si vous travaillez en ligne de commande, n'oubliez pas les guillemets ("--constraint=cascade|skylake") pour protéger les caractères spéciaux [ et ]. Vous pouvez ensuite demander explicitement les logiciels pour AVX512 avec module load arch/avx512, avant d’ajouter les autres modules.

Voici un exemple de script pour une tâche simple :


File : gromacs_job_cedar_avx512.sh

#!/bin/bash
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=48
#SBATCH --constraint="[skylake|cascade]"
#SBATCH --time=24:00:00
module load arch/avx512
module load StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2023.2
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"
srun gmx_mpi mdrun


Nos bancs d’essai suggèrent que passer d’AVX2 à AVX512 sur les nœuds Skylake ou Cascade résulte en un gain de performance de 20 à 30%. Toutefois, considérez également que vous restreindre aux nœuds supportant AVX512 mènera à plus de temps d’attente dans la file.

GPU

[contenu en préparation].

Analyser les résultats

Outils

GROMACS offre beaucoup d'outils pouvant être utilisés pour des tâches communes de post-traitement et d'analyse. Le manuel de GROMACS contient une liste des commandes disponibles selon le sujet et aussi selon le nom; chaque commande est accompagnée d'une courte description et un lien conduit à l'information de référence.

Typiquement, ces commandes lisent la trajectoire (au format XTC, TNG ou TRR), un fichier de coordonnées (GRO, PDB, TPR, etc.) et produit un graphique au format XVG qui peut être utilisé par l'outil de traçage Grace (module grace/5.99.0; commande xmgrace; voyez Grace User Guide). Comme les fichiers XVG sont des fichiers texte, ils peuvent être analysés par des scripts ou importés dans des feuilles de calcul.

VMD

VMD est un programme de visualisation moléculaire pour afficher, animer et analyser de grands systèmes biomoléculaires à l'aide de graphiques 3D et de scripts intégrés. Il peut être utilisé pour inspecter visuellement les trajectoires GROMACS et offre également un grand nombre de plugiciels intégrés et externes pour l'analyse. Il peut également être utilisé en mode ligne de commande.

Utiliser Python

MDAnalysis et MDTraj sont deux paquets Python que nous offrons en wheels Python précompilés. Ils peuvent lire et écrire des fichiers de trajectoires et de coordonnées GROMACS (TRR et XTC) et d'autres paquets de dynamique moléculaire, en plus d'offrir plusieurs fonctions d'analyse fréquemment employées. MDAnalysis peut aussi lire l'information topologique contenue dans les fichiers GROMACS TPR, mais pas toujours ceux produits par les récentes versions de GROMACS.

Les deux paquets disposent d'un langage de sélection d'atomes polyvalent et exposent les coordonnées des trajectoires, ce qui facilite l'écriture d'outils d'analyse personnalisés qui peuvent être adaptés à un problème particulier et bien s'intégrer aux paquets de science des données de Python tels que NumPy, SciPy et Pandas, et aux bibliothèques de traçage comme Matplotlib/Pyplot et Seaborn.

Pièges à éviter

Modules reliés

GROMACS-PLUMED

PLUMED[10] est une bibliothèque open source pour le calcul de l'énergie libre dans les systèmes moléculaires; elle fonctionne avec divers programmes de dynamique moléculaire.

Les modules gromacs-plumed sont des versions de GROMACS auxquelles des correctifs ont été apportés en fonction des modifications de PLUMED; ils peuvent exécuter des simulations métadynamiques.

v2022.6 v2.8.3 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs-plumed/2022.6 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs-plumed/2022.6 GCC, FlexiBLAS & FFTW
GROMACS PLUMED modules pour utiliser les CPU modules pour utiliser les GPU (CUDA) Notes
v2022.3 v2.8.1 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs-plumed/2022.3 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs-plumed/2022.3 GCC, FlexiBLAS & FFTW
v2021.6 v2.7.4 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs-plumed/2021.6 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs-plumed/2021.6 GCC, FlexiBLAS & FFTW
v2021.4 v2.7.3 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs-plumed/2021.4 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs-plumed/2021.4 GCC, FlexiBLAS & FFTW
v2021.2 v2.7.1 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs-plumed/2021.2 StdEnv/2020 gcc/9.3.0 cuda/11.0 openmpi/4.0.3 gromacs-plumed/2021.2 GCC & MKL
v2019.6 v2.6.2 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs-plumed/2019.6 StdEnv/2020 gcc/9.3.0 cuda/11.0 openmpi/4.0.3 gromacs-plumed/2019.6 GCC & MKL
v2019.6 v2.5.4 StdEnv/2018.3 gcc/7.3.0 openmpi/3.1.2 gromacs-plumed/2019.6 StdEnv/2018.3 gcc/7.3.0 cuda/10.0.130 openmpi/3.1.2 gromacs-plumed/2019.6 GCC & MKL
v2019.5 v2.5.3 StdEnv/2018.3 gcc/7.3.0 openmpi/3.1.2 gromacs-plumed/2019.5 StdEnv/2018.3 gcc/7.3.0 cuda/10.0.130 openmpi/3.1.2 gromacs-plumed/2019.5 GCC & MKL
v2018.1 v2.4.2 StdEnv/2016.4 gcc/6.4.0 openmpi/2.1.1 gromacs-plumed/2018.1 StdEnv/2016.4 gcc/6.4.0 cuda/9.0.176 openmpi/2.1.1 gromacs-plumed/2018.1 GCC & FFTW
v2016.3 v2.3.2 StdEnv/2016.4 intel/2016.4 openmpi/2.1.1 gromacs-plumed/2016.3 StdEnv/2016.4 intel/2016.4 cuda/8.0.44 openmpi/2.1.1 gromacs-plumed/2016.3 Intel & MKL

GROMACS-Colvars

Colvars[11] est un module logiciel qui permet d'ajouter aux programmes de simulation moléculaire les variables collectives avancées pour l'application de potentiels de polarisation; le calcul les potentiels de force moyenne (PMF) pour tous les ensembles de variables; et l'utilisation de méthodes avancées d'échantillonnage comme la force de polarisation adaptative (ABF pour Adaptive Biasing Force), la métadynamique, la dynamique moléculaire dirigée et l'échantillonnage parapluie.

Pour plus d'information, consultez le manuel de référence de GROMACS[12] et cet article[13].

Les modules gromacs-colvars sont des versions de GROMACS auxquelles on a ajouté les modifications de Colvars pour permettre l'utilisation de variables collectives avancées dans les simulations.

GROMACS Colvars modules pour utiliser les CPU modules pour utiliser les GPU (CUDA) Notes
v2020.6 2021-12-20 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs-colvars/2020.6 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs-colvars/2020.6 GCC, FlexiBLAS & FFTW

GROMACS+CP2K

CP2K[14] est un progiciel de chimie quantique et de physique du solide. Depuis 2022, GROMACS peut être compilé pour prendre en charge les simulations hybrides quantiques-classiques (QM/MM)[15] avec CP2K[16].

Les modules gromacs-cp2k sont des versions de GROMACS qui ont été compilées avec le support de QM/MM avec CP2K.

Ils sont différents d'autres modules en ce qu'ils peuvent être utilisés uniquement pour les calculs avec CPU et non avec GPU (CUDA). De plus, ils contiennent uniquement des exécutables compatibles avec MPI :

  • gmx_mpi - GROMACS en mixte précision avec OpenMP et MPI.
  • gmx_mpi_d - GROMACS en double précision avec OpenMP et MPI.
GROMACS CP2K modules for running on CPUs Notes
v2022.2 9.1 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs-cp2k/2022.2 GCC, FlexiBLAS & FFTW

Les ressources suivantes sont pour les simulations QM/MM avec cette combinaison de GROMACS et CP2K.

  • Documentation GROMACS, Hybrid Quantum-Classical simulations (QM/MM) with CP2K interface.
  • BioExcel, CP2K QM/MM Best Practices Guide.
  • BioExcel, atelier QM/MM with GROMACS + CP2K
    Comprend un tutoriel sur comment préparer et faire exécuter des simulations QM/MM et des liens vers des vidéos théoriques sur YouTube. Le tutoriel est conçu pour les ressources de CIP de BioExcel (European Centre of Excellence for Computational Biomolecular Research), mais peut être suivi sur nos systèmes avec quelques légères modifications.
    En particulier, il faut remplacer gmx_cp2k par gmx_mpi (mixte précision) ou gmx_mpi_d (double précision) et modifier les scripts de tâches qui sont aussi pris en charge par Slurm.

GROMACS-RAMD

GROMACS-RAMD est un dérivé de GROMACS qui implémente la méthode RAMD (Random Acceleration Molecular Dynamics).[17] Cette méthode peut être employée pour identifier les voies de sortie des ligands à partir des poches de liaison enterrées des récepteurs et étudier le mécanisme de dissociation des ligands par l'exécution de simulations de dynamique moléculaire avec une force supplémentaire orientée au hasard appliquée à une molécule du système.

Vous trouverez l'information sur les options RAMD[18] dans la page GROMACS-RAMD GitHub.

GROMACS RAMD modules pour utilisation avec CPU modules pour utilisation avec GPU (CUDA) Remarques
v2020.5 2.0 StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs-ramd/2020.5-RAMD-2.0 StdEnv/2020 gcc/9.3.0 cuda/11.4 openmpi/4.0.3 gromacs-ramd/2020.5-RAMD-2.0 GCC, FlexiBLAS & FFTW

G_MMPBSA

G_MMPBSA[19] est un outil de calcul des composantes de l'énergie de liaison qui utilise la méthode MM-PBSA, à l'exception de la composante entropique et la contribution énergétique de chaque résidu, par l'utilisation de principes de décomposition de l'énergie.

Le développement de G_MMPBSA semble s'être arrêté en avril 2016; il n'est donc compatible qu'avec GROMACS 5.1.x. Pour les versions plus récentes de GROMACS, vous pourriez utiliser gmx_MMPBSA[20] (voir ci-dessous).

La version installée peut être chargée avec module load StdEnv/2016.4 gcc/5.4.0 g_mmpbsa/2016-04-19. Il s'agit de la plus récente version constituée de la version 1.6 et de modifications la rendant compatible avec GROMACS 5.1.x; elle a été compilée avec gromacs/5.1.5 et apbs/1.3.

Notez que G_MMPBSA utilise des solvants implicites et que certaines études[21] ont démontré que les méthodes de calcul des énergies libres liantes présentent certains problèmes de précision.

gmx_MMPBSA

gmx_MMPBSA[20] est un outil basé sur le MMPBSA.py d'AMBER pour le calcul de l'état final de l'énergie libre à l'aide de fichiers GROMACS.

Outre G_MMPBSA[19] qui est moins récent et seulement compatible avec les versions plus anciennes de GROMACS, gmx_MMPBSA peut être utilisé avec les versions courantes de GROMACS et AmberTools.

Il faut savoir que gmx_MMPBSA utilise des solvants implicites et que certaines études [21] ont démontré que les méthodes de calcul des énergies libres liantes présentent certains problèmes de précision.

Installer gmx_MMPBSA dans un environnement virtuel

La procédure qui suit a été testée avec une combinaison de gmx_MMPBSA 1.5.0.3, gromacs/2021.4 et ambertools/21. Elle devrait fonctionner avec d'autres versions récentes de GROMACS, mais présentement seule la version AmberTools 21 est supportée.

1. Chargez les modules nécessaires. 

$ module purge
$ module load gcc/9.3.0 python/3.8  gromacs/2021.4
$ module load ambertools/21
$ virtualenv venv_gmxMMPBSA
$ source venv_gmxMMPBSA/bin/activate

2. Installez les paquets Python nécessaires. 

$ pip install --no-index "numpy~=1.22.0" gmx_MMPBSA
$ python -m pip install git+https://github.com/ParmEd/ParmEd.git@16fb236

Il faut savoir que les versions de ParMed jusqu'à 3.4.3 contenaient un bogue qui est éliminé dans le commit 16fb236, mais qu'une nouvelle version n'est toujours pas disponible.

3. Une fois que l'environnement virtuel est prêt, chargez le module Qt/PyQt. 

$ module load qt/5.15.2

4. Testez l'application principale. 

$ gmx_MMPBSA -h
$ gmx_MMPBSA_test -ng -n 4

Heureusement, le test s'effectue rapidement et vous pouvez l'exécuter sur le nœud de connexion.

Par la suite, quand vous utiliserez gmx_MMPBSA dans une tâche, vous devrez charger les modules et activez l'environnement virtuel comme suit : 

module purge
module load gcc/9.3.0 python/3.8 ambertools/21 gromacs/2021.4 qt/5.15.2
source venv_gmxMMPBSA/bin/activate

Liens utiles

Simulation biomoléculaire

Références

  1. ↑ "Fix missing synchronization in CUDA update kernels" in GROMACS 2021.6 Release Notes [1]
  2. ↑ Issue #4393 in GROMACS Project on GitLab.com [2]
  3. ↑ "Fix missing synchronization in CUDA update kernels" in GROMACS 2021.6 Release Notes [3]
  4. ↑ Issue #4393 in GROMACS Project on GitLab.com [4]
  5. ↑ GROMACS User-Guide: Managing long simulations.
  6. ↑ GROMACS Manual page: gmx mdrun
  7. ↑ GROMACS User-Guide: Getting good performance from mdrun
  8. ↑ 8.0 8.1 GROMACS User-Guide: Performance background information
  9. ↑ GROMACS User-Guide: GPU accelerated calculation of PME
  10. ↑ Site Web PLUMED
  11. ↑ Site Web Colvars
  12. ↑ Colvars Reference manual for GROMACS
  13. ↑ Fiorin et al. 2013, Using collective variables to drive molecular dynamics simulations.
  14. ↑ CP2K Home
  15. ↑ QM/MM with CP2K in the GROMACS Reference manual
  16. ↑ Building GROMACS with CP2K QM/MM support
  17. ↑ Information sur la méthode RAMD
  18. ↑ Options RAMD
  19. ↑ 19.0 19.1 Site Web G_MMPBSA
  20. ↑ 20.0 20.1 gmx_MMPBSA Homepage
  21. ↑ 21.0 21.1 Comparison of Implicit and Explicit Solvent Models for the Calculation of Solvation Free Energy in Organic Solvents

Message Passing Interface

GNU Compiler Collection, an open source compiler collection

Intel Math Kernel Library, a software library of optimized math routines

Retrieved from "https://docs.alliancecan.ca/mediawiki/index.php?title=GROMACS/fr&oldid=152022"