GROMACS

From CC Doc
Jump to navigation Jump to search
This page is a translated version of the page GROMACS and the translation is 100% complete.
Other languages:
English • ‎français

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 lors d'une simulation.

Points forts

  • Très bonne performance en comparaison 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 librairie de calcul Thread MPI pour les postes de travail à nœud simple.
  • 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 les CPU et les GPU en se basant sur l’équilibre raisonnable de leur performance.

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/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 GCC & MKL
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 GCC & MKL
GROMACS modules pour utiliser les CPU modules pour utiliser les GPU (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 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 modules pour utiliser les CPU modules pour utiliser les GPU (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

Notes :

  • Les versions depuis 2020.4 ont été compilées pour l'environnement logiciel standard StdEnv/2020.
  • La version 2018.7 et suivantes ont été compilées avec des compilateurs GCC et la bibliothèque MKL, puisqu'elles sont plus rapides.
  • 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/2021.2
or 
$ module load  StdEnv/2018.3  gcc/7.3.0 openmpi/3.1.2 gromacs/2020.2

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.0  openmpi/4.0.3  gromacs/2021.2 
or
$ module load  StdEnv/2018.3  gcc/7.3.0 cuda/10.0.130 openmpi/3.1.2  gromacs/2020.2

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 simple précision avec OpenMP, mais sans MPI
  • gmx_mpi - GROMACS en 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:30           # time limit (D-HH:MM)
#SBATCH --mem-per-cpu=1000M   # memory per CPU (in MB)
module purge  
module load StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2020.4
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

gmx mdrun -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=8      # request 8 MPI tasks per node
#SBATCH --cpus-per-task=4        # 4 OpenMP threads per MPI task => total: 8 x 4 = 32 CPUs/node
#SBATCH --mem=0                  # request all available memory on the node
#SBATCH --time=0-01:00           # time limit (D-HH:MM)
module purge  
module load StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2020.4
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

srun gmx_mpi mdrun -deffnm md
File : gromacs_whole_node_cedar.sh

#!/bin/bash
#SBATCH --nodes=1                        # number of nodes
#SBATCH --ntasks-per-node=12             # request 12 MPI tasks per node
#SBATCH --cpus-per-task=4                # 4 OpenMP threads per MPI task => total: 12 x 4 = 48 CPUs/node
#SBATCH --constraint="[skylake|cascade]" # restrict to AVX512 capable nodes.
#SBATCH --mem=0                          # request all available memory on the node
#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/2020  gcc/9.3.0 openmpi/4.0.3 gromacs/2020.4
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"
 
srun gmx_mpi mdrun -deffnm md
File : gromacs_whole_node_beluga.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=0                  # request all available memory on the node
#SBATCH --time=0-01:00           # time limit (D-HH:MM)
module purge  
module load StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2020.4
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"
 
srun 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=0                  # request all available memory on the node
#SBATCH --time=0-01:00           # time limit (D-HH:MM)
module purge --force
module load CCEnv
module load StdEnv/2020 gcc/9.3.0 openmpi/4.0.3 gromacs/2020.4
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"
 
srun gmx_mpi mdrun -deffnm md

Tâches GPU

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


File : gpu_gromacs_job.sh

#!/bin/bash
#SBATCH --gres=gpu:p100:1        # request 1 GPU as "generic resource"
#SBATCH --cpus-per-task 4        # number of OpenMP threads per MPI process
#SBATCH --mem-per-cpu 1000       # memory limit per CPU core (megabytes)
#SBATCH --time 0:30:00           # time limit (D-HH:MM:ss)
module purge  
module load  StdEnv/2020 gcc/9.3.0 cuda/11.0 openmpi/4.0.3 gromacs/2020.4
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

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


Tâches GPU-MPI

Le script suivant exécute mdrun sur un nœud, deux GPU avec six tâches MPI par nœud et quatre fils OpenMP par tâche MPI.

File : gromacs_job_GPU_MPI_Graham.sh

#!/bin/bash
#SBATCH --nodes=1                # number of nodes
#SBATCH --gres=gpu:p100:2             # request 2 GPUs per node (Graham)
#SBATCH --ntasks-per-node=4      # request 4 MPI tasks per node
#SBATCH --cpus-per-task=8        # 8 OpenMP threads per MPI process
#SBATCH --mem=0                  # Request all available memory in the node
#SBATCH --time=1:00:00           # time limit (D-HH:MM:ss)
module purge  
module load StdEnv/2020 gcc/9.3.0 cuda/11.0 openmpi/4.0.3 gromacs/2020.4
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

mpiexec gmx_mpi mdrun -deffnm md
File : gromacs_job_GPU_MPI_Cedar.sh

#!/bin/bash
#SBATCH --nodes=1                # number of nodes
#SBATCH --gres=gpu:p100:4             # request 4 GPUs per node (Cedar)
#SBATCH --ntasks-per-node=4      # request 4 MPI tasks per node
#SBATCH --cpus-per-task=6        # 6 OpenMP threads per MPI process
#SBATCH --mem=0                  # Request all available memory in the node
#SBATCH --time=1:00:00           # time limit (D-HH:MM:ss)
module purge  
module load StdEnv/2020 gcc/9.3.0 cuda/11.0 openmpi/4.0.3 gromacs/2020.4
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

mpiexec gmx_mpi mdrun -deffnm md
File : gromacs_job_GPU_MPI_Beluga.sh

#!/bin/bash
#SBATCH --nodes=1                # number of nodes
#SBATCH --gres=gpu:v100:4             # request 4 GPUs per node (Beluga)
#SBATCH --ntasks-per-node=4      # request 8 MPI tasks per node
#SBATCH --cpus-per-task=5        # 5 OpenMP threads per MPI process
#SBATCH --mem=0                  # Request all available memory in the node
#SBATCH --time=1:00:00           # time limit (D-HH:MM:ss)
module purge  
module load StdEnv/2020 gcc/9.3.0 cuda/11.0 openmpi/4.0.3 gromacs/2020.4
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

srun gmx_mpi mdrun -deffnm md
Travailler avec des GPU
  • Les nœuds GPU sont configurés différemment sur Cedar et Graham.
  • Cedar possède 4 GPU et 24 cœurs CPU par nœud.
  • Graham possède 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.

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/2020.4
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.cptstate.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. [1][2].


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/2020.4
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.[3]

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[4]).

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 clacul. Elle se mesure comme suit :

S = pN / ( N * p1 )

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[4] (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[5] 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 avec les processus MPI atteint la limite de scalabilité (c'est-à-dire que la scalabilité parallèle commence à diminuer), la performance peut encore être améliorée avec des fils OpenMP pour distribuer le travail d'un rang MPI sur plusieurs cœurs CPU. Pour ce faire, utilisez dans le script le paramètre Slurm --cpus-per-task et 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%nbsp;:


File : gromacs_job_cedar_avx512.sh

#!/bin/bash
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=48
#SBATCH --constraint="[skylake


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

Pièges à éviter

Modules reliés

GROMACS-PLUMED

PLUMED[6] 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.

GROMACS PLUMED modules pour utiliser les CPU modules pour utiliser les GPU (CUDA)
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
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
v2019.6 v2.5.4 gcc/7.3.0 openmpi/3.1.2 gromacs-plumed/2019.6 gcc/7.3.0 cuda/10.0.130 openmpi/3.1.2 gromacs-plumed/2019.6
v2019.5 v2.5.3 gcc/7.3.0 openmpi/3.1.2 gromacs-plumed/2019.5 gcc/7.3.0 cuda/10.0.130 openmpi/3.1.2 gromacs-plumed/2019.5
v2018.1 v2.4.2 gcc/6.4.0 openmpi/2.1.1 gromacs-plumed/2018.1 gcc/6.4.0 cuda/9.0.176 openmpi/2.1.1 gromacs-plumed/2018.1
v2016.3 v2.3.2 intel/2016.4 openmpi/2.1.1 gromacs-plumed/2016.3 intel/2016.4 cuda/8.0.44 openmpi/2.1.1 gromacs-plumed/2016.3

G_MMPBSA

G_MMPBSA[7] 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.

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[8] ont démontré que les méthodes de calcul des énergies libres liantes présentent certains problèmes de précision.

Liens utiles

Simulation biomoléculaire

Références