GROMACS avec accélération GPU

Exploitez le plein potentiel de Gromacs avec notre guide de démarrage pour application GPU.

GROMACS

GROMACS est une application de dynamique moléculaire conçue pour la simulation d’équations newtoniennes du mouvement avec des systèmes composés de quelques centaines à plusieurs millions de particules. Ces systèmes incluent des molécules biochimiques comme les protéines, les lipides et les acides nucléiques possédant de complexes interactions liées.

GROMACS offre des performances jusqu’à 3 fois plus rapides avec les GPU NVIDIA qu’avec les systèmes uniquement basés sur le traitement CPU*, ce qui permet de réduire la durée des simulations de dynamique moléculaire de plusieurs jours à quelques heures seulement.

GROMACS offre des performances jusqu’à 3 fois plus rapides grâce aux GPU NVIDIA

Installation

Vous pouvez télécharger la dernière version de GROMACS (actuellement : v5.1.2) sur le site Internet de GROMACS. Dans l’exemple ci-après, remplacez "VERSION" par "5.1.2" ou le numéro de la version de GROMACS que vous souhaitez utiliser. Depuis l’écriture de ce guide, il est possible de se procurer la version 5.1.4 ; qui offre des performances plus rapides que la version 5.1.2.

Instructions de téléchargement et d’installation

Pour configurer (avec CMake) et assembler la version accélérée par GPU, les composants logiciels suivants sont requis :

  • CMake
  • NVIDIA CUDA®*
  • GCC*
  • MPI (Composant optionnel. À utiliser uniquement avec la version multi-nœuds.)

*Nous vous recommandons d’utiliser une version récente de CUDA (actuellement : v7.5) et la version la plus récente de gcc actuellement supportée par CUDA.

$ wget ftp://ftp.gromacs.org/pub/gromacs/gromacs-VERSION.tar.gz
$ tar -xzvf gromacs-VERSION.tar.gz
$ mkdir gromacs-VERSION-build
$ cd gromacs-VERSION-build
$ CC=gcc CXX=g++ cmake <GROMACS_SRC_DIR> -DGMX_OPENMP=ON -DGMX_GPU=ON -
DGPU_DEPLOYMENT_KIT_ROOT_DIR=<GDK_PATH> -DGMX_BUILD_OWN_FFTW=ON -
DGMX_PREFER_STATIC_LIBS=ON -DCMAKE_BUILD_TYPE=Release -
DCMAKE_INSTALL_PREFIX=<GROMACS_INSTALL_DIR>

OPTIONS CMAKE (CROSS PLATFORM MAKE)

Veuillez remplacer par le chemin d’accès au répertoire source de GROMACS (par exemple : ../gromacs-5.1.2). désigne l’emplacement d’installation de votre kit de déploiement GPU.

Les fréquences GPU utilisées dans GROMACS 5.1 peuvent être automatiquement ajustées pour bénéficier de performances optimales via NVML. Pour activer le support optionnel de NVML, le kit de déploiement GPU  (GDK) est requis.

Après le téléchargement et l’installation, remplacez par le chemin d’accès du répertoire GDK. (Vous pouvez supprimer l’option -DGPU_DEPLOYMENT_KIT_ROOT_DIR= si vous avez installé GDK dans le répertoire par défaut.) Vous devez également remplacer par le répertoire d’installation correspondant (exemple : /opt/gromacs).

D’autres configurations peuvent également être réalisées en utilisant des options CMake, par exemple pour activer le support d'OpenMP avec la commande -DGMX_OPENMP=ON. L’option de configuration -DGMX_BUILD_OWN_FFTW=ON vous permet quant à elle de télécharger et de configurer FFTW pendant le déploiement de GROMACS. Vous pouvez ainsi choisir les drapeaux d’optimisation appropriés pour FFTW. Vous pouvez également utiliser une installation spécifique de FFTW. Pour plus d’informations, reportez-vous à la section FFTW des instructions d’installation de GROMACS. Pour obtenir des informations détaillées sur chaque option, veuillez vous référer au manuel de GROMACS.

GROMACS avec MPI

Pour configurer et installer GROMACS avec le support de MPI, vous devez modifier la commande précédente en utilisant les outils de compilation MPI et en y ajoutant "-DGMX_MPI=ON".

$ CC=mpicc CXX=mpicxx cmake <GROMACS_SRC_DIR> -DGMX_OPENMP=ON -DGMX_GPU=ON
-DGPU_DEPLOYMENT_KIT_ROOT_DIR=<GDK_PATH> -DGMX_MPI=ON -DGMX_BUILD_OWN_FFTW=ON -DGMX_PREFER_STATIC_LIBS=ON -
DCMAKE_BUILD_TYPE=Release -DGMX_BUILD_UNITTESTS=ON -DCMAKE_INSTALL_PREFIX=<GROMACS_INSTALL_DIR>

CONFIGURATION ET INSTALLATION

Pour configurer et installer GROMACS, veuillez utiliser la ligne de commande suivante :

$ make
$ sudo make install

Pour vérifier la conformité de GROMACS après l’installation, ajoutez l’option -"DREGRESSIONTEST_DOWNLOAD=ON" à la commande de configuration, puis exécutez "make check" avant "make install". Vous pouvez également utiliser "make -jN", où N spécifie le nombre de cœurs de votre plateforme (ceci afin d’accélérer la progression du déploiement).

Pour de plus amples informations sur les options d’installation, veuillez vous référer au guide d’installation de GROMACS.

Exécution

GROMACS fournit des scripts pour configurer l’environnement avec différentes interfaces système. Pour configurer les variables d’environnement, vous pouvez utiliser la commande suivante.

    $ source <GROMACS_INSTALL_DIR>/bin/GMXRC

Si vous avez configuré des fichiers binaires MPI et non-MPI comme décrit ci-dessus, vous trouverez "gmx" et "gmx_mpi" dans votre dossier bin d’installation. Les exemples décrits dans ce guide utilisent des jeux de données hydrauliques (dont le nom de fichier comporte le terme "water"), disponibles sur le serveur de fichiers de GROMACS. L’exécution de GROMACS avec ces jeux de données requiert une phase de préparation préalable décrite ci-dessous. Des détails et options complémentaires sur la préparation des fichiers d’entrée pour GROMACS sont disponibles ici.

Pour exécuter GROMACS, deux étapes préalables sont requises :

Étape 1. Préparez vos données d’entrée avec grompp (préprocesseur de GROMACS). 

a. Pour les versions à un seul nœud : $ gmx grompp -f

Étape 2. Exécutez mdrun.

a. Pour les versions à un seul nœud : $ gmx mdrun 
b. Pour les versions MPI : (np = #GPUs): $ mpirun –np gmx_mpi mdrun

Pour les configurations à faible nombre de nœuds, ces paramètres délivrent généralement de bonnes performances. Certains réglages complémentaires peuvent néanmoins améliorer les performances de simulation de GROMACS. Plus le nombre de nœuds est élevé, plus ces réglages sont importants. Pour plus d’informations, veuillez consulter le manuel de GROMACS , la liste de diffusion des utilisateurs gmx et les dossiers précédemment publiés.

Les options de réglage des performances GPU sont décrites dans ce document. Les jeux de données d’entrée pour les benchmarks sont disponibles au téléchargement à l’adresse suivante.

OPTIONS D’EXÉCUTION DES BENCHMARKS

Si vous souhaitez exécuter des benchmarks pour mesurer les performances de vos simulations sous GROMACS, veuillez utiliser les options de ligne de commande suivantes :

1. –resethway : Au début de chaque simulation, GROMACS analyse la décomposition de domaines et équilibre la charge entre les ressources CPU et GPU disponibles. Ce processus ralentit les premières centaines d’itérations. Étant donné que les simulations réelles s’exécutent généralement pendant une durée significativement longue, cela n’a pas d’impact sur les performances finales. Pour minimiser la durée d’exécution nécessaire à l’obtention de résultats de benchmark stables, vous pouvez spécifier l’option –resethway. -resethway réinitialise les compteurs de performance quand la moitié des itérations ont été accomplies, ce qui permet de mesurer les performances de manière réaliste en réduisant le nombre d’étapes requises. Si la réinitialisation intervient alors que l’équilibreur de charge PME est toujours actif en début de cycle, le message d’erreur suivant est susceptible de s’afficher : "PME tuning was still active when attempting to reset mdrun counters at step xxxxxxx" (la commande de réglage PME était toujours active lors de la tentative de réinitialisation des compteurs mdrun à l’étape xxxxxxx). Afin d’éviter ce problème, vous pouvez spécifier un plus grand nombre d’étapes en augmentant la valeur -maxh ou en ajoutant le paramètre -nsteps afin d’incrémenter le nombre d’intervalles de la simulation.

2. -maxh : Détermine la durée d’exécution maximale de la simulation. Veuillez noter que le programme mdrun fait appel à suffisamment d’étapes pour s’exécuter pendant le nombre d’heures spécifié. Pour obtenir des résultats de performance stables, cette valeur doit être suffisamment élevée. Nous recommandons une valeur telle que 5 minutes (= 0.08333). Vous pouvez soit utiliser la présente option, soit recourir à l’option "nsteps" décrite ci-dessous afin de limiter la durée d’exécution de la simulation.

3. –noconfout : Désactive la création du fichier de sortie confout.gro, pouvant s’avérer particulièrement chronophage, notamment avec les systèmes de fichiers parallèles. Nous recommandons de désactiver ce fichier de sortie pour les procédures de benchmarking.

4. –v : Génère des informations additionnelles pour la ligne de commande et le fichier journal "md.log". Les informations correspondantes peuvent s’avérer très utiles pour régler les performances de GROMACS.

5. –nb : Spécifie à GROMACS quel processeur utiliser (options disponibles : "gpu" ou "cpu") pour effectuer des calculs spécifiques.

6. –nsteps : Nombre d’étapes à exécuter. Permet d’écraser la valeur par défaut du fichier .mdp. Cette option peut également être utilisée pour contrôler la durée totale d’une simulation, plutôt que d’utiliser l’option "maxh".

Le niveau de performance enregistré lors du benchmark est affiché à la fin du fichier journal de sortie (md.log) ainsi que sur la console avec la valeur "ns/day" (plus la valeur est élevée, mieux c’est). 

Reportez-vous à la  documentation de GROMACS  pour obtenir plus d’informations sur les paramètres de ligne de commande.

OPTIMISATION DES PERFORMANCES

Pour mieux comprendre le niveau de performance de GROMACS, il convient d’avoir une compréhension basique des tâches exécutées par GROMACS. Vous en trouverez ci-après une brève synthèse. Dans une perspective de haut niveau, GROMACS exécute quatre tâches distinctes.

1. PP : Calcul des forces non-liées à courte portée ou des interactions particules-particules (PP) pour les communications entre éléments voisins.

2. PME : Calcul d’approximation des forces non-liées à longue portée pour les communications intensives entre configurations multi-nœuds.

3. B : Calcul des forces liées.

4. A : Toutes les autres opérations (application de contraintes liées, positionnement d’atomes, calcul de listes pour cellules voisines, etc.).

La version GPU de GROMACS permet d’accélérer les tâches PP les plus chronophages grâce au calcul par le GPU, les tâches PME, B et A restant quant à elles exclusivement exécutées sur CPU. Les tâches PP sont indépendantes des tâches B et PME et peuvent donc être exécutées en parallèle. Les tâches A dépendant pour leur part des résultats des trois autres, elles sont traitées en dernier. Comme l’illustre le schéma suivant, la version GPU de GROMACS permet donc de traiter simultanément les tâches B et PME sur CPU et les tâches PP sur GPU.

GROMACS assigne aux GPU les tâches de calcul PP les plus intenses

La mise à l’échelle de la distance de troncature électrostatique (ou "electrostatics cutoff", c’est-à-dire la distance au-dessus de laquelle une force est gérée sur une périodicité à longue portée) permet à GROMACS de transférer les opérations de calcul du CPU (tâches PME) au GPU (tâches PP). Cette mise à l’échelle est activée par défaut. Vous pouvez la désactiver avec la ligne de commande "–tunepme". Dans un souci de précision, le transfert des ressources de calcul fonctionne uniquement du CPU vers le GPU. Ce transfert peut offrir des gains de productivité significatifs. Comme l’illustre le schéma suivant, si le GPU termine ses tâches PP avant que le CPU ne termine ses tâches PME, les tâches PME restantes seront alors transférées au GPU afin d’accélérer la simulation.

GROMACS transfère la charge de travail sur GPU afin d’accélérer les simulations

Les tâches PP possèdent une complexité de type O(m*n) et les tâches PME sont de type O(n log(n)), où "n" représente le nombre de particules et "m" la taille de la liste de cellules voisines. Les valeurs typiques pour "m" sont comprises entre 200 et 400, soit une valeur plus faible que pour "n".

Les paramètres suivants peuvent être utilisés pour optimiser les performances de GROMACS.

CONFIGURATION DE LANCEMENT

GROMACS utilise MPI et OpenMP afin de pouvoir utiliser l’ensemble des ressources GPU et CPU disponibles sur un cluster. Selon le jeu de données d’entrée et la capacité du réseau, il est essentiel d’utiliser des configurations de lancement spécifiques, pouvant aller d’un seul process MPI par cœur logique avec un thread OpenMP chacun à un process MPI par nœud utilisant l’ensemble des cœurs disponibles sur le nœud. Pour choisir la meilleure configuration de lancement, veuillez suivre les instructions suivantes :

  • Si vous utilisez uniquement un ou deux sockets CPU, la parallélisation OpenMP est généralement plus efficace que le traitement MPI.
  • Si vous utilisez plusieurs sockets ou nœuds CPU, le traitement MPI couplé à la parallélisation hybride OpenMP (avec de 2 à 4 threads OpenMP par rang MPI) est généralement plus efficace que le traitement MPI exclusif.
  • Avec un grand nombre de nœuds, il peut s’avérer bénéfique d’utiliser encore plus de threads OpenMP par rang MPI afin de réduire la quantité de communications requises. La durée totale des communications est spécifiée dans le fichier de sortie "md.log" (dans la section "Script 1 Time").
Computing: Num Ranks Num Threads Call Count Wall time (s) Giga-Cycles total sum %
[…]
Comm. coord. 2 10 252681 63.467 3808.202 3.6
[…]
Comm. energies. 2 10 25917 1.108 66.457 0.1
Total 1782.537 106957.655 100.0
Breakdown of PME mesh computation
[…]
PME 3D-FFT Comm. 2 10 518322 126.829 7610.103 7.1
[…]

Section "Script 1 Time" relative aux communications dans le fichier de sortie "md.log".

En ce qui concerne la version MPI, vous pouvez contrôler son nombre de rangs dédiés grâce au lanceur utilisé pour l’implémentation MPI ("-np parameter"). Le nombre de threads OpenMP peut quant à lui être contrôlé avec l’option de ligne de commande "–ntomp" ou avec la variable d’environnement "OMP_NUM_THREADS". La version pour un seul nœud de mdrun utilise quant à elle thread-MPI (une implémentation interne de MPI basée sur threads) et OpenMP. Sur cette version, il est également possible de contrôler le nombre de threads OpenMP avec l’option de ligne de commande "–ntomp" et le nombre de rangs MPI avec l’option "–ntmpi". En ce qui concerne la version accélérée par GPU de GROMACS, il est nécessaire de disposer d’au moins un rang MPI par GPU afin d’utiliser l’ensemble des ressources GPU disponibles.

DÉFINITION DES THREADS ET PROCESS

Il convient de définir correctement l’allocation des threads OpenMP et des process MPI pour les cœurs du système. Vous pouvez le faire soit via le lanceur MPI ou le système de batchs, soit via GROMACS. Par défaut, GROMACS essaie de définir automatiquement l’allocation des threads mais, dans certains cas, le lanceur MPI peut s’en être déjà chargé. Cette fonction est désactivée quand l'implémentation OpenMP ou le nombre de cœurs logiques disponibles ne correspond pas au nombre total de threads utilisés sur nœud, auquel cas vous pouvez définir manuellement l’allocation des threads avec l’option "–pin" si jamais cela n’a pas déjà été fait par le lanceur MPI ou le système de batchs.

SMT/HYPERTHREADING

L’utilisation de tous les cœurs logiques d’un système (SMT ou Hyperthreading) offre généralement un gain substantiel de performances.

GPU BOOST

Les kernels GPU de GROMACS n’exploitent pas le plein potentiel de puissance et d’efficacité énergétique des configurations GPU. Il est par conséquent tout à fait possible - voire recommandé - d’augmenter en toute sécurité les fréquences GPU jusqu’à leur valeur maximale supportée par GROMACS. Depuis la version 5.1 de GROMACS, vous pouvez le faire automatiquement via l’exécutable gmx à partir du moment où les permissions de fréquence sont définies sur "UNRESTRICTED" (ILLIMITÉ). Si c’est le cas, un message de ce type devrait s’afficher : "Changing GPU clock rates by setting application clocks for Tesla K80 to (2505,875)" (Changement des fréquences GPU avec activation des valeurs 2505.875 pour Tesla K80).

Si jamais les permissions d’horloge de l’application sont définies sur "RESTRICTED" (LIMITÉ), un message de ce type devrait s’afficher :

"Not possible to change GPU clocks to optimal value because of insufficient permissions to set application clocks for Tesla K80" (Impossible d’activer les fréquences GPU à leur valeur optimale en raison de permissions insuffisantes pour l’overclocking du processeur Tesla K80). "Current values are (2505,562)" (Valeurs actuelles : 2505.562). "Max values are (2505,875)" (Valeurs maximales : 2505.875). "Use sudo nvidia-smi -acp UNRESTRICTED or contact your admin to change application clock permissions" (Utilisez la commande sudo nvidia-smi -acp UNRESTRICTED ou contactez votre administrateur pour changer les permissions de fréquence de l’application).

Comme l’indique le message d’avertissement ci-dessus, vous pouvez utiliser

$ sudo nvidia-smi -acp UNRESTRICTED

pour changer les permissions de fréquence sur UNRESTRICTED.

Si votre version de GROMACS n’inclut pas de kit de déploiement GPU, un avertissement de ce type devrait s’afficher :

"GROMACS was configured without NVML support hence it can not exploit
application clocks of the detected Tesla K80 GPU to improve performance.
Recompile with the NVML library (compatible with the driver used) or set application clocks manually." (GROMACS a été configuré sans support NVML et, par conséquent, vous ne pouvez pas modifier les fréquences du GPU Tesla K80 détecté afin d’améliorer les performances de l’application. Veuillez recompiler la bibliothèque NVML en vous assurant qu’elle est compatible avec le pilote utilisé, ou définissez manuellement les fréquences maximales de l’application.)

Vous pouvez définir manuellement la fréquence GPU boostée avec la ligne de commande ci-après. Veuillez cependant noter que chaque modèle de GPU peut posséder une fréquence maximale spécifique, la commande suivante est donc fournie à titre d’exemple.

$ nvidia-smi -ac 2505,875       # fréquences maximales pour GPU K80

Pour de plus amples informations sur la technologie GPU Boost, veuillez vous référer à l'article "Increase Performance with GPU Boost and K80 Autoboost" (en anglais).

MISE À JOUR DES LISTES DE CELLULES VOISINES

Dès lors que vous utilisez la méthode de Verlet, qui est requise pour l’accélération GPU, vous pouvez définir librement l’intervalle de mise à jour des listes de cellules voisines. Si la recherche des listes de cellules voisines s’avère trop longue, l’intervalle de mise à jour peut être étendue. La durée de recherche des listes de cellules voisines est spécifiée dans le fichier "md.log" (dans la section "Script 2 Time"). Les éventuelles extensions du rayon de troncature sont faites automatiquement. Étant donné que les listes de cellules voisines sont calculées via CPU et qu’un plus grand nombre de calculs de force augmente la durée des cycles avec nstlist, il convient de transférer une partie de la charge de calcul du CPU au GPU. Ce transfert permet également d’harmoniser les communications entre les rangs MPI ainsi que la charge de calcul globale.

Computing: Num
Nodes
Num
Threads
Call
Count
Wall time
(s)
Giga-Cycles total sum %
[…]
Neighbor search 2 10 6480 32.464 1947.963 1.8
[…]
Total 1782.537 106957.655 100.0

ÉQUILIBRAGE DE LA CHARGE PME/PP

[…]
Force evaluation time GPU/CPU: 4.972 ms/5.821 ms = 0.854
For optimal performance this ratio should be close to 1!
[…]

Section "Script 3 Time" relative à l’équilibrage de la charge PME/PP dans le fichier de sortie "md.log".

Comme l’indique la ligne de commande ci-dessus, vous pouvez équilibrer la charge entre les nœuds PME et PP. Cette commande est activée par défaut. Vous pouvez la désactiver avec le paramètre "–notunepme parameter". Pour les process uniques accélérés par GPU, l’équilibrage de la charge PP (GPU) et PME (CPU) est spécifié dans le fichier de sortie "md.log" (dans la section "Script 3 Time").

RANGS PME SÉPARÉS

Répartition des calculs PME

Breakdown of PME mesh computation
PME redist. X/F 2 10 518322 167.004 10020.730 9.4
PME spread/gather 2 10 518322 429.501 25771.381 24.1
PME 3D-FFT 2 10 518322 123.600 7416.369 6.9
PME 3D-FFT Comm. 2 10 518322 126.829 7610.103 7.1
PME solve Elec 2 10 259161 13.470 808.259 0.8

Section "Script 4 Time" relative aux tâches PME dans le fichier de sortie "md.log".

La gestion des interactions non-liées à longue portée avec PME, qui s’appuie sur des algorithmes FFT 3D, requiert d’importantes ressources en matière de communications. Étant donné que les tâches PP et PME sont indépendantes, GROMACS prend en charge des nœuds PME séparés afin de réduire la pression appliquée au réseau avec les programmes et les flux de données multiples. Par défaut, le nombre de rangs PME est déterminé automatiquement uniquement quand les GPU ne sont pas utilisés. Vous pouvez changer cette option avec le paramètre "–npme". Si le temps de communication de la tâche PME spécifié dans le fichier de sortie "md.log" est élevé, vous devriez envisager de configurer des nœuds PME séparés, dans l’idéal 3-4 ou plus.

Il existe deux options distinctes pour assigner des rangs MPI à des nœuds PP et PME avec les instances de GROMACS accélérées par GPU.

  • Les nœuds PME sont entrelacés avec les nœuds PP exécutant la tâche de Force, ce qui applique une pression additionnelle au réseau mais présente l’avantage de ne laisser aucune ressource inutilisée. L’option de ligne de commande correspondante est "–ddorder interleave" (activée par défaut avec les instances accélérées par GPU).
  • Les nœuds PME sont regroupés, ce qui applique moins de pression au réseau mais laisse certaines ressources GPU inutilisées. L’option de ligne de commande correspondante est –ddorder pp_pme" (activée par défaut avec le traitement CPU).

PARTAGE D’UN GPU ENTRE DES PROCESS MULTIPLES
ET LE SERVICE MPS (MULTI PROCESS SERVICE)

Dans de nombreuses situations, le partage d’un GPU entre plusieurs rangs MPI peut améliorer les performances.

Pour l’utilisation d’un seul nœud avec des versions non-MPI de GROMACS, vous pouvez configurer le partage GPU via thread-MPI avec la commande "-ntmpi" et les paramètres adéquats en configurant -ntmpi (ou en autorisant GROMACS à le faire pour vous) afin d’exécuter 2 rangs MPI ou plus par GPU.

Pour l’utilisation de nœuds multiples avec des versions MPI de GROMACS, vous pouvez configurer le partage GPU (avec des GPU dotés des capacités de calcul 3.5 ou plus) via le service MPS (Multi Process Service). Pour ce faire, vous devez configurer les GPU requis en mode exclusif et initialiser un gestionnaire MPS Control Daemon sur chaque nœud (nvidia-cuda-mps-control) :

#!/bin/bash
sudo nvidia-smi -c 3
nvidia-cuda-mps-control -decho " -started nvidia-cuda-mps-control on `hostname`"

Exemple de script pour démarrer MPS sur un seul nœud

#!/bin/bash
echo quit | nvidia-cuda-mps-control
sudo nvidia-smi -c 0
echo " stopping MPS on `hostname`"

Exemple de script pour arrêter MPS sur un seul nœud

Pour plus d'informations sur MPS, cliquez  ici.

OPTIONS D’INSTALLATION AVANCÉES

Des paramètres avancés de décomposition de domaines sont par ailleurs disponibles. Sur les systèmes non homogènes, le réglage de ces paramètres peut améliorer les performances. Pour plus d’informations, veuillez consulter le manuel de GROMACS ou la liste de diffusion des utilisateurs de GROMACS.

Avertissement

*GROMACS offre de nombreuses options pour optimiser les performances avec différents jeux de données d’entrée, systèmes ou architectures. Cet ensemble d’instructions a été conçu pour couvrir des aspects essentiels à l’accélération GPU de GROMACS.

EXEMPLES DÉTAILLÉS

Cette section regroupe plusieurs exemples détaillés relatifs à l’exécution de GROMACS. Les jeux de données d’entrée utilisés pour ces exemples sont disponibles  ici.

Pour commencer, veuillez télécharger et extraire l’archive.

$ wget ftp://ftp.gromacs.org/pub/benchmarks/water_GMX50_bare.tar.gz
$ tar -zxvf water_GMX50_bare.tar.gz

Ces données incluent des données hydrauliques de référence de différentes tailles avec des noms de dossier comme "0384", "0768" et "1536". Le nom du dossier correspond au nombre d’atomes en milliers (exemple : le dossier "0768" comporte un cas d’utilisation avec 256 000 molécules d’eau et 768 000 atomes). La première étape consiste à préparer les données avec l’outil grompp.

Pour l’exécution du cas d’utilisation 1536, vous devez par exemple utiliser les commandes ci-après. Utilisez "pme.mdp" si vous souhaitez utiliser la méthode de calcul de la sommation d’Ewald (PME). L’exécution de la commande suivante va générer un fichier "topol.tpr" qui sera utilisé comme jeu d’entrée pour GROMACS mdrun.

$ cd water-cut1.0_GMX50_bare/1536
$ gmx grompp -f pme.mdp

Vous trouverez ci-dessous différentes variations pour l’exécution de GROMACS avec ou sans traitement GPU sur un ou deux nœuds. Ces exemples représentent un sous-ensemble des cas d’utilisation ayant été utilisés pour collecter les résultats fournis à titre de référence dans cette section.

Le nombre de rangs MPI utilisés pour les exemples avec traitement GPU dépendent du nombre de GPU de votre système et du nombre de rangs MPI par GPU. Dans de nombreux cas, le recours à plus d’un rang MPI par GPU peut améliorer les performances. Pour ce faire, vous pouvez utiliser thread-MPI avec les configurations à un seul nœud ou vous servir du service MPS pour les configurations à nœuds multiples. Vous trouverez des informations complémentaires sur CUDA MPS dans ce guide.

Nous recommandons généralement d’utiliser 2 ou 6 threads pour chaque rang lors du recours au traitement GPU. La commande "-ntomp" ou la variable "OMP_NUM_THREADS" peuvent être utilisées pour spécifier le nombre de threads OMP par rang. Certaines expérimentations peuvent être requises pour ajuster le nombre de rangs MPI par rapport au nombre de threads par rang pour obtenir des résultats optimaux avec une configuration système et des données d’entrée spécifiques.

Dans les exemples 1, 2 et 4 ci-dessous, deux accélérateurs Tesla K80 à double GPU sont utilisés, ce qui représente un total de quatre GPU par nœud.

Les cinq exemples suivants ont été exécutés sur des nœuds avec deux sockets de CPU Haswell.

  • 32 cœurs au total
  • Hyperthreading désactivé

Exemple 1 .Les paramètres de lancement ("ntmpi" et "ntomp") n’étant pas spécifiés, GROMACS va définir automatiquement le nombre de rangs MPI à utiliser par GPU et le nombre de threads OMP par rang.

Procédez à l’exécution sur un seul nœud à 4 GPU via thread-MPI et autorisez GROMACS à déterminer lui-même les paramètres de lancement.

$ GROMACS_BIN_DIR/gmx mdrun -resethway -noconfout -nsteps 4000 -v -pin on -nb gpu

Si vous avez le temps de procéder à des expérimentations, vous pouvez tester différentes combinaisons de rangs MPI par GPU et de threads OMP par rang afin de déterminer comment obtenir des résultats optimaux. Les options disponibles dépendent du nombre total de cœurs CPU et du nombre de GPU par nœud. Par exemple, si vous disposez de 4 GPU et de 32 cœurs CPU par nœud, vous pouvez tester les combinaisons ci-après.

-ntmpi 4 -ntomp 8 # 1 rank per GPU with 8 threads per rank
-ntmpi 8 -ntomp 4 # 2 MPI ranks per GPU with 4 threads per rank
-ntmpi 16 -ntomp 2 # 4 MPI ranks er GPU with 2 threads per rank

Dans les exemples 2 à 5 ci-dessous, les cas d’utilisation sélectionnés délivrent les meilleurs résultats sur le système de benchmark.

Exemple 2 .Exécution sur un seul nœud avec 4 GPU, 4 threads OMP par rang, 8 rangs et 2 rangs MPI par GPU via thread-MPI.

$ GROMACS_BIN_DIR/gmx mdrun -ntmpi 8 -ntomp 4 -resethway -noconfout -nsteps 4000 -v -pin on -nb gpu

Exemple 3.Exécution sur un seul nœud avec des cœurs CPU exclusivement, 1 thread OMP par rang et 32 rangs via thread-MPI

$ $GROMACS_BIN_DIR/gmx mdrun -ntmpi 32 -ntomp 1 -resethway -noconfout -nsteps 4000 -v -pin on -nb cpu

Exemple 4.Exécution sur deux nœuds avec 4 GPU par nœud, 2 threads OMP par rang, 16 rangs par nœud et 4 rangs MPI par GPU via le service CUDA MPS afin d’autoriser des rangs MPI multiples par GPU.

$ OMP_NUM_THREADS=2 mpirun -np 32 $GROMACS_BIN_DIR/gmx_mpi mdrun -resethway -noconfout -nb gpu -nsteps 8000 -v -pin on

Exemple 5.Exécution sur deux nœuds avec des cœurs CPU exclusivement, 1 thread OMP par rang et 32 rangs par nœud.

$ OMP_NUM_THREADS=1 mpirun -np 64 $GROMACS_BIN_DIR/gmx_mpi mdrun -resethway -noconfout -nb cpu -nsteps 8000 -v -pin on

Benchmarks

Cette section présente les performances de benchmark multi-GPU du logiciel GROMACS sur un seul nœud. Notre benchmark synthétise par ailleurs les performances avec un, deux et quatre nœuds en utilisant deux cartes graphiques NVIDIA Tesla P100 par nœud. Chaque carte P100 est équipée d’un processeur graphique à architecture Pascal. Les benchmarks ont été utilisés avec des variations des lignes de commande présentées dans la section précédente pour des données hydrauliques de taille 0768, 1536 et 3072.

Performances hydrauliques 768K sur un serveur à un seul nœud
Performances hydrauliques 1,5M sur un serveur à un seul nœud
Performances hydrauliques 3M sur un serveur à un seul nœud
Performances hydrauliques 3M sur configuration évolutive

Configuration système recommandée

Configuration matérielle

PC

Parameter
Specs

CPU Architecture

x86

System Memory

16-32GB

CPUs

8 Cores, 8 GHz
10 Cores, 2.2 GHz
16 Cores, 2GHz

GPU Model

NVIDIA TITAN X

GPUs

1-2 TITAN X

Servers

Parameter
Specs

CPU Architecture

x86

System Memory

32GB

CPUs/Nodes

2 (16+ cores, 2+ GHz)

GPU Model

NVIDIA® Tesla® P100

GPU/Node

1-2 Tesla GPU cards

Interconnect

InfiniBand

Configuration logicielle

Software stack

Parameter
Version

OS

Linux

GPU Driver

352.79 or newer

CUDA Toolkit

7.5 or newer

Compiler

GCC 5.0

Déployez votre solution GPU personnalisée.