
La simulation HPC utilise le calcul haute performance pour exécuter des modèles scientifiques et techniques. Elle peut répartir un calcul exigeant entre plusieurs processeurs ou lancer de nombreux cas indépendants en parallèle. Elle devient utile lorsqu'une station de travail ne dispose pas d'assez de mémoire, ne termine pas le calcul à temps ou ne peut pas traiter toutes les variantes nécessaires à une étude.
Pour les ingénieurs et les chercheurs qui choisissent une infrastructure, la première question porte sur ce qui doit changer d'échelle. Une simulation fortement couplée et un ensemble de calculs indépendants peuvent nécessiter des systèmes très différents. Ce guide explique comment choisir les CPU, les GPU, la mémoire, le réseau et le stockage, puis tester le traitement complet avant d'augmenter les ressources.
Une simulation représente un système physique ou mathématique à l'aide d'un modèle et d'une méthode numérique. Un solveur effectue les calculs. Le HPC fournit des ressources qui peuvent permettre de traiter des problèmes plus grands, de réduire la durée d'exécution ou de terminer davantage de cas, à condition que le logiciel sache les utiliser.
Aucun nombre fixe de cœurs ou de cellules ne définit le passage au HPC. Les besoins dépendent des équations, du solveur, de la précision, de la taille des données et des critères d'arrêt. Certains calculs exigeants tiennent sur un seul nœud puissant ; d'autres nécessitent un cluster coordonné. Notre introduction au calcul haute performance présente le fonctionnement général du HPC.
La recherche scientifique associe le calcul à d'autres éléments de preuve. Les travaux de simulation du Lawrence Livermore National Laboratory illustrent le rôle de la modélisation à grande échelle dans l'étude de systèmes complexes. Une puissance de calcul supérieure ne prouve pas la justesse d'un modèle : les hypothèses, la convergence numérique, la qualité des données et la comparaison avec les observations restent essentielles.
Les systèmes de calcul haute performance sont utiles lorsque la méthode numérique crée plus de travail que la machine disponible ne peut en traiter. Un maillage plus fin peut représenter des phénomènes qu'un modèle grossier ne résout pas. Des pas de temps, des effets physiques ou des paramètres de conception supplémentaires peuvent encore augmenter le calcul. Une simulation plus détaillée nécessite néanmoins des éléments montrant que cette précision améliore la réponse.
En ingénierie, la simulation peut aider à comparer des conceptions avant de fabriquer chaque prototype. Une équipe aéronautique pourrait étudier l'écoulement autour d'un composant ; une équipe du secteur de l'énergie pourrait examiner une conception thermique. Ce sont des exemples de questions à modéliser, pas la preuve que la simulation remplace les essais physiques ou la validation réglementaire.
Les simulations créent aussi du travail en dehors du solveur. Des résultats volumineux peuvent nécessiter du filtrage, de la visualisation et de l'analyse avant de devenir utiles. Incluez ces outils et ces étapes dans le développement : gagner une heure de calcul a moins de valeur si l'analyse des résultats demande encore une journée.
Le traitement parallèle répartit le travail entre plusieurs processeurs. Un solveur peut répartir un maillage, une grille ou un ensemble de particules entre plusieurs processus. Chaque processus effectue sa part du travail et échange les informations nécessaires à la suite du calcul. Les threads en mémoire partagée utilisent un espace mémoire commun ; les programmes en mémoire distribuée utilisent souvent MPI pour communiquer entre processus. Les applications hybrides combinent plusieurs approches, parfois avec une accélération GPU.
Des échanges fréquents caractérisent un couplage fort. Par exemple, des portions voisines d'un modèle d'écoulement peuvent échanger des valeurs aux frontières à chaque itération. À mesure que les portions deviennent plus petites, le calcul entre deux échanges diminue. Ajouter des processeurs peut alors produire des gains décroissants, voire ralentir l'exécution.
Le strong scaling consiste à ajouter des ressources pour réduire la durée d'un problème de taille fixe. Le weak scaling augmente la taille totale du problème avec les ressources, en conservant une quantité de travail à peu près constante par processeur. Le cours du LLNL sur le calcul parallèle explique ces deux tests. Un bon résultat en weak scaling ne prouve pas qu'un petit modèle donné sera plus rapide sur davantage de nœuds.
Les études paramétriques, les analyses de sensibilité, l'exploration de variantes de conception et de nombreux calculs de Monte-Carlo comportent des cas séparés. Chaque cas peut utiliser plusieurs cœurs ou un GPU, tout en échangeant peu d'informations avec les autres pendant son exécution.
Prenons un exemple fictif de 100 variantes indépendantes. Si chaque variante tient sur une instance, répartir les variantes entre les instances disponibles peut augmenter le nombre de cas terminés, sans distribuer un même calcul entre plusieurs machines. Les téléchargements de données communes, les licences et la collecte des résultats peuvent néanmoins devenir des limites.
Choisissez la mesure qui correspond au projet. Un cas soumis à une échéance précise nécessite un délai de résolution plus court. Une campagne doit produire suffisamment de cas validés dans le temps et le budget disponibles. Affecter tous les processeurs à un seul cas peut réduire le nombre total de simulations terminées.
La mécanique des fluides numérique, ou CFD, modélise les écoulements et des phénomènes associés, comme les transferts thermiques ou l'aérodynamique. Le maillage, les modèles physiques, le solveur et la méthode d'intégration temporelle influencent la mémoire nécessaire et les performances parallèles.
La méthode des éléments finis, ou FEA, sert notamment aux analyses structurelles et thermiques. Un calcul transitoire explicite et une résolution implicite peuvent présenter des contraintes différentes de communication, de mémoire et de licences, même s'ils décrivent le même composant.
La dynamique moléculaire suit l'évolution de particules en interaction. La prise en charge des GPU dépend du logiciel et des opérations utilisées. Le guide de performance de GROMACS décrit, par exemple, la répartition du travail entre CPU et GPU, le coût des communications et les mesures disponibles dans le journal de simulation.
Les modèles météorologiques, les solveurs électromagnétiques, les calculs sismiques et les modèles de réservoir constituent d'autres usages du HPC. Leur domaine ne suffit pas à déterminer le matériel. Un prototype limité, un cas de production et un ensemble de cas peuvent avoir des besoins différents au sein d'une même discipline.
Commencez par les modes d'exécution pris en charge par l'application. Le CPU peut être le choix adapté si le solveur ne propose pas d'implémentation GPU appropriée, si une part importante du travail reste séquentielle, si le modèle dépasse la mémoire GPU disponible ou si les logiciels et les licences favorisent le CPU.
Comparez les performances par cœur, la bande passante mémoire et la RAM disponible en plus du nombre de cœurs. Un solveur qui attend la mémoire ou exécute une phase séquentielle peut peu bénéficier de cœurs supplémentaires. Établissez une mesure de référence avant de modifier le nombre de processus ou de threads.
Un GPU peut accélérer les noyaux de calcul pris en charge lorsqu'ils disposent d'assez de travail parallèle. Il n'accélère pas automatiquement toute la simulation. Vérifiez la version précise du solveur, les modèles physiques activés, la précision numérique requise, l'architecture GPU et la mémoire disponible.
Ansys documente plusieurs méthodes de calcul parallèle et explique comment les parties séquentielles limitent l'accélération totale. Un benchmark fournisseur renseigne sur sa configuration déclarée ; il ne prédit pas les performances d'un autre modèle.
Les GPU grand public et ceux destinés aux centres de données diffèrent aussi sur des caractéristiques utiles à la simulation. Vérifiez la précision numérique nécessaire et la liste de matériel compatible publiée par l'éditeur. Un chiffre de performance en IA ne suffit pas à choisir un GPU pour un solveur scientifique.
Plusieurs GPU ne sont utiles que si l'application sait répartir efficacement le travail. Les échanges de données, la synchronisation et les tâches exécutées sur CPU peuvent limiter le gain. Installer plusieurs GPU ne rend pas automatiquement leur mémoire accessible comme un espace unique.
Commencez par un cas représentatif sur un GPU lorsque le problème y tient. Testez ensuite une autre configuration prise en charge et comparez la durée, la mémoire, la validité des résultats et le coût. Si le modèle nécessite plusieurs GPU pour tenir en mémoire, utilisez la plus petite configuration possible comme référence et consignez ce choix.
Plusieurs nœuds peuvent apporter davantage de mémoire et de puissance de calcul. Pour un solveur fortement couplé, ils introduisent aussi le réseau dans le chemin du calcul. La latence, la bande passante, les bibliothèques de communication, le placement et la topologie peuvent déterminer l'intérêt de ces ressources supplémentaires.
Les recommandations AWS sur les charges fortement couplées relient les choix de calcul, de réseau, de stockage et de déploiement. Le simple fait de démarrer un solveur sur plusieurs instances cloud ne constitue pas la preuve d'un cluster HPC efficace.
Avant un test multi-nœud, confirmez la compatibilité des logiciels sur chaque machine, la configuration MPI prise en charge, les accès entre nœuds, l'allocation des ressources et les accès aux fichiers. Mesurez les phases qui communiquent beaucoup. La réussite d'un lot de tâches indépendantes ne valide pas les performances MPI d'un calcul fortement couplé.
La gestion des pannes devient importante lorsque la tâche grandit. Déterminez si la panne d'un processus ou d'un nœud arrête tout le calcul, comment le solveur enregistre ses points de contrôle et si une reprise retrouve un état exploitable. Testez cette reprise avant d'en dépendre pour une exécution coûteuse.
Estimez le pic de mémoire à partir d'un cas représentatif, en incluant les espaces de travail du solveur et les tableaux temporaires. La taille du maillage ne fournit pas une règle universelle fiable. La précision, les variables d'état, la méthode numérique et le partitionnement influencent la RAM et la mémoire GPU. Prévoyez une marge adaptée et surveillez les phases exigeantes.
Planifiez séparément les entrées, les fichiers de travail, les points de contrôle, le post-traitement et les résultats à conserver. Le NVMe local peut servir d'espace temporaire. Un stockage partagé peut être nécessaire lorsque plusieurs processus ou étapes doivent accéder aux mêmes fichiers. Un système de fichiers parallèle devient utile lorsque ses capacités répondent à un besoin d'entrées-sorties mesuré ; il n'est pas obligatoire pour toute simulation HPC.
Notre guide des systèmes de fichiers HPC et du stockage parallèle détaille ces choix. Le stockage objet peut accueillir les données sources et les résultats conservés, avec transfert vers l'environnement d'exécution si nécessaire. Il ne fournit pas la même interface qu'un système de fichiers POSIX monté.
La fréquence des points de contrôle représente un compromis entre le coût des écritures et le travail perdu après une panne. Mesurez leur durée, vérifiez la capacité disponible et assurez-vous que les copies de récupération résistent à la panne envisagée. Un point de contrôle conservé uniquement sur un stockage supprimé avec l'instance ne permet pas de récupérer après la perte de cette instance.
Une exécution commence généralement par une géométrie, un système physique ou un autre modèle mathématique. L'équipe prépare le maillage ou les données, règle le solveur, transfère les entrées, lance le calcul, conserve les états intermédiaires utiles et analyse les résultats. Une modification du modèle ou de la conception entraîne ensuite une nouvelle exécution.
Conservez avec chaque résultat la version du solveur, les dépendances, l'identité des données, les paramètres numériques et la configuration matérielle. Des environnements reproductibles facilitent les comparaisons et le diagnostic. Ils ne remplacent pas les sauvegardes des entrées et des résultats.
Slurm alloue les ressources et ordonnance les tâches dans de nombreux environnements HPC. Ses tableaux de tâches permettent de gérer des lots de travaux similaires. Un ordonnanceur coordonne l'exécution ; il ne rend pas parallèle un solveur séquentiel.
Dans le cloud, un traitement peut utiliser un service batch, un gestionnaire de tâches ou des scripts. Vérifiez ce que la plateforme automatise réellement. Le cycle de vie des instances, le lancement du solveur, les licences, les nouvelles tentatives, la validation des sorties et le nettoyage sont des responsabilités distinctes. Les reprises doivent distinguer le travail terminé des sorties partielles, afin qu'un transfert interrompu ne soit pas considéré comme un résultat valide.
Les logiciels commerciaux peuvent facturer séparément certaines fonctions, les ressources parallèles ou les tâches simultanées. Vérifiez les conditions du produit et du déploiement précis : utilisation dans le cloud, nombre de cœurs ou de GPU autorisés, simultanéité et accès éventuel à un serveur de licences.
Le guide des licences Ansys décrit les options HPC et les variantes paramétriques simultanées selon les produits. N'appliquez pas les conditions d'un produit à tous les solveurs. Confirmez les conditions actuelles auprès de l'éditeur avant de louer des ressources que la licence ne permettrait pas d'utiliser.
Incluez ces coûts dans la comparaison. Une configuration plus rapide peut réduire le temps de calcul tout en nécessitant une licence plus coûteuse. Un grand lot peut atteindre sa limite de licences simultanées avant d'épuiser les machines disponibles.
Le cloud peut convenir aux projets intermittents, aux pics temporaires, aux essais de nouvelles configurations ou à une étude qui dépasse la mémoire d'une station de travail. La disponibilité, les quotas, la préparation, les transferts et la compatibilité logicielle restent des contraintes. La capacité cloud ne doit pas être considérée comme illimitée.
Un système sur site existant peut convenir à une utilisation régulière, à des interconnexions spécialisées, à des besoins logiciels stables ou à de grands jeux de données déjà présents. Intégrez le matériel, l'exploitation, la maintenance et l'attente dans la comparaison, au lieu d'opposer simplement un tarif de location à un prix d'achat.
Avant de transférer des données de recherche confidentielles, vérifiez les accès, les responsabilités de sécurité logicielle et les emplacements autorisés pour les données. La compatibilité technique ne règle pas ces exigences.
Une approche hybride nécessite un plan clair pour les données et les logiciels. Déterminez les cas qui peuvent être déplacés, les transferts nécessaires et les moyens de conserver des licences et des configurations cohérentes. Commencez par une charge représentative dont les critères de réussite sont explicites.
Utilisez un cas représentatif de la taille et du comportement physique attendus. Conservez des versions, des objectifs de convergence, une précision et des sorties comparables. Une exécution plus rapide avec d'autres critères d'arrêt ne permet pas de comparer équitablement les infrastructures.
Délai de résolution : mesurez le temps du solveur et le temps total jusqu'au résultat exploitable, transferts et post-traitement compris. Relevez séparément l'attente et la préparation.
Débit de simulations : comptez les cas terminés et valides dans la période qui compte pour le projet.
Passage à l'échelle : comparez la durée lorsque les ressources changent, en précisant si la taille du problème reste fixe ou augmente.
Utilisation des ressources : mesurez les pics de mémoire, l'activité CPU/GPU, les attentes de communication et les délais d'entrées-sorties.
Coût total : incluez le calcul, le stockage, les transferts, les licences, les échecs et le travail d'exploitation.
Dans un exemple hypothétique, un cas fixe qui prend 10 heures sur un nœud et 6 heures sur deux présente une accélération d'environ 1,67 et une efficacité parallèle d'environ 83 %. Il consomme 12 heures-nœuds au lieu de 10. À tarif horaire identique par nœud, le calcul coûte 20 % de plus tout en se terminant 4 heures plus tôt. L'intérêt de ce compromis dépend de l'échéance et du traitement complet.
Répétez les essais pour observer la variabilité. Vérifiez les résultats selon les critères de validation de l'application et consignez la configuration utilisée. Des sorties identiques bit à bit ne constituent pas toujours le seul critère valable lorsque l'ordre d'exécution ou les bibliothèques numériques changent ; utilisez une méthode de comparaison adaptée au problème scientifique.
Compute with Hivenet propose des instances CPU et GPU pour les logiciels compatibles avec l'environnement choisi. Les simulations sur un nœud, les solveurs GPU pris en charge, les études paramétriques indépendantes et le pré- ou post-traitement sont des usages possibles à évaluer. Cela ne signifie pas que tous les solveurs sont compatibles ou inclus.
La FAQ Compute, disponible en anglais, décrit les environnements conteneur et machine virtuelle, l'accès SSH et le stockage NVMe local. Choisissez l'environnement et la configuration actuelle selon l'application, puis testez un cas réel. Conservez les données sources et les résultats sur un stockage dont le cycle de vie et les possibilités de récupération répondent au projet.
Pour un calcul fortement couplé sur plusieurs nœuds, confirmez avec Hivenet le réseau proposé, MPI, l'interface de stockage, l'ordonnancement et le support avant de vous engager. La location d'instances ne prouve pas, à elle seule, la disponibilité d'un cluster Slurm géré, d'un système de fichiers parallèle ou d'un niveau précis de performance réseau.
Commencez par un cas compatible, validez ses résultats et mesurez la durée et le coût. Augmentez ensuite les ressources ou le nombre de tâches simultanées lorsque les mesures justifient cette étape.
Non. Une station de travail peut suffire aux modèles limités et aux premières étapes de développement. Le HPC devient utile lorsque la mémoire, la durée ou le nombre de cas requis dépasse les ressources locales.
Non. Elle peut utiliser des CPU, des GPU ou les deux. L'accélération GPU dépend de l'implémentation du solveur et des parties du calcul qu'elle prend en charge.
Non. Les parties séquentielles, les communications, la mémoire et les entrées-sorties peuvent limiter ou inverser le gain. Testez un même cas sur quelques configurations possibles et choisissez à partir des mesures.
Non. Le HPC désigne des méthodes et des infrastructures de calcul ; l'IA désigne une famille de méthodes et d'applications. L'apprentissage automatique peut intervenir dans une simulation, par exemple avec un modèle de substitution ou l'analyse des résultats, mais il impose ses propres exigences d'entraînement et de validation.
Choisissez une charge de travail d’IA, de calcul ou de stockage à tester sur Hivenet, ou échangez avec notre équipe sur sa mise en production.