Parallélisation dans VASP
J'ai un système qui a 1 point k, 54 atomes NBANDS=152, et NGZ=80. J'exécute une simulation AIMD sur VASP version 5.4.4
Le supercalculateur a 32 cœurs / nœud. C'est un cluster LINUX lié par Infiniband, machine multicœur moderne. Je me demandais quelle serait la meilleure façon de sélectionner les paramètres et de demander des ressources pour obtenir un calcul efficace et rapide. Voici quelques scénarios que j'ai envisagés. Je suis curieux de savoir quelle serait la «meilleure» méthode (en termes d'efficacité et de rapidité).
- Basé sur ce que j'ai lu ici
- Je devrais demander quelque chose comme 19 bandes (152/8). Peut-être définir NBANDS = 160 pour demander même 20 cœurs.
- Est-ce que je définirais alors NCORE = 20 dans mon fichier INCAR et demanderais 20 cœurs sur 1 nœud?
- Ou serait-il préférable de définir NCORE = 10. Et ensuite demander quelque chose comme 2 nœuds et 10 cœurs par nœud? ou est-ce que cela créerait trop de frais généraux de communication et ralentirait la simulation?
- Si je décide d'utiliser # de cœurs = # d'atomes = 54
- Est-ce que je définirais NCORE = 32, puis demanderais 54 cœurs sur 2 nœuds (32 sur 1 nœud + 22 sur le second)? Ou 9 cœurs / nœud et 6 nœuds?
- Puis-je simplement demander le nœud entier? 1 nœud, 32 cœurs
- alors réglez NCORE = 32 et je demande juste le nœud entier. Cependant, le manuel VASP suggère de ne pas le faire car cela ferait NPAR = 1
- cela me déroute un peu car je suppose que 32 cœurs sur un nœud seraient plus efficaces que d'avoir des cœurs sur plusieurs nœuds communiquant entre eux
Réponses
En tant que personne qui a fait beaucoup de benchmarking pour VASP, je vous suggère d'essayer l'approche expérimentale. Je crois que VASP ajoutera des bandes supplémentaires pour vous si nécessaire pour la parallélisation, donc je ne m'inquiéterais pas personnellement à ce sujet. La disposition physique du nœud (32 cœurs sur 1 processeur vs 16 cœurs sur 2 processeurs vs dispositions de processeur AMD spéciales sur un seul processeur) peut différer considérablement d'un cluster à l'autre, vous ne pouvez pas savoir ce qui est optimal sans essayer.
Puisque vous exécutez des simulations MD, il semble que je pense que cela vaut la peine de comparer chaque système avant de lancer une longue simulation. Des changements mineurs ne vous obligent pas à repenser, mais si vous passez de 50 à 150 à 300 atomes, l'idéal peut changer. Exécutez une série de calculs rapides avec toute la gamme de NCORE qui semble raisonnable. Utilisez le meilleur résultat. J'ai tendance à vérifier chaque facteur du plus grand nœud.
Pour 32 cœurs, je vérifierais NCORE = (1, 2, 4, 8, 16, 32). Je le chronométrerais par rapport à une dizaine de pas géométriques. Cela peut sembler une perte de temps, mais cela peut finir par gagner beaucoup de temps à l'avenir.
Je suggérerais presque toujours de demander des nœuds entiers à moins que vous n'ayez une bonne raison de ne pas le faire. Vous pouvez éventuellement voir une option KPAR en regardant autour de vous, j'ai entendu des opinions mitigées. Personnellement, je n'ai jamais obtenu de meilleur résultat avec la parallélisation kpoint que sans elle. Cela peut faire une différence de mémoire cependant.
J'ai pensé afficher les résultats de l'analyse comparative selon la suggestion de Tristan. Peut-être que ce sera utile pour quelqu'un dans le futur. Je n'ai fait que 10 étapes dans le MD (taille de pas de 1 fs, 10 fs au total).
Les différences de pourcentage sont toutes relatives à l'exécution NCORE = 1 avec 32 cœurs et 1 nœud. Il y a une accélération de 33% en allant aux 2 nœuds avec 64 cœurs (NCORE = 32).
Évidemment, cela peut différer en fonction de votre cluster. Il s'agit de la grappe Graham sur Sharcnet au Canada, donc j'espère qu'elle sera utile aux autres Canadiens :)
