OpenFOAM sur GPU : intégrations et validation

OpenFOAM n’accélère pas automatiquement toute une simulation sur GPU. Un solveur linéaire externe peut accélérer une partie du calcul, selon l’intégration, le matériel et le cas étudié. Cette page présente les points à vérifier avant un essai ; elle ne fournit pas de procédure d’installation universelle ni de garantie de performance.

En bref

Voies d’intégration à valider pour votre version

• PETSc4FOAM relie OpenFOAM à PETSc. Le README du dépôt OpenFOAM external-solver décrit le module petsc4Foam pour OpenFOAM.com, pas une prise en charge universelle de toutes les distributions. La présence de l’interface ne prouve pas que votre combinaison de matrices, de solveurs et de préconditionneurs fonctionne sur GPU. Consultez la matrice de prise en charge GPU de PETSc et testez la combinaison retenue.
• NVIDIA AmgX fournit une bibliothèque de solveurs linéaires accélérés. Son utilisation avec OpenFOAM nécessite une interface adaptée, par exemple un projet communautaire comme amgx4foam. Ne confondez pas la prise en charge de la bibliothèque avec celle de cette intégration.
• OpenFOAM Ginkgo Layer (OGL) relie OpenFOAM aux solveurs et préconditionneurs de Ginkgo. Sa documentation décrit plusieurs exécuteurs, mais aussi des limites : conditions cycliques de base uniquement, sans AMI ni matrices couplées par blocs. Vérifiez ces contraintes avant de choisir cette voie.

Développements spécifiques ou expérimentaux

• Portages et développements spécifiques : un résultat obtenu avec un solveur modifié ou un prototype ne démontre pas une accélération générale des applications OpenFOAM. Identifiez le code, la version et les opérations effectivement exécutées sur GPU.

Points à vérifier

• Les gains dépendent notamment de la part du temps d’exécution consacrée à l’algèbre linéaire.
• Les conversions de matrices et les transferts entre mémoire hôte et GPU ont un coût. Mesurez-les avec le temps total du cas, pas seulement avec le temps du solveur.
• Choisissez la précision selon les résultats numériques attendus, puis mesurez les performances du matériel dans cette précision. Consultez notre liste de contrôle FP64 pour préparer cette comparaison.

Préparer un environnement de test OpenFOAM

Choisissez une configuration adaptée à votre cas et vérifiez la compatibilité des versions avant de lancer vos essais. Conservez une référence CPU et sauvegardez les résultats hors de l’instance.

Try Compute now

Préparer un essai GPU : deux voies à examiner

Voie A : l’interface OpenFOAM avec PETSc

1. Environnement : relevez la distribution et la version d’OpenFOAM, le compilateur, MPI, le pilote, le toolkit GPU et le commit ou la version de PETSc. Une image contenant CUDA ne garantit pas leur compatibilité.
2. Intégration : utilisez les instructions du module de solveur externe correspondant à votre distribution. Validez d’abord le résultat CPU, puis testez une configuration GPU documentée pour les versions retenues.
3. Configuration du cas : partez des dictionnaires fournis avec cette version du module. Conservez les noms de fichiers et les mots-clés techniques d’origine, notamment system/fvSolution, sans les traduire.

Compilation : suivre les instructions de la version choisie

La documentation GPU de PETSc distingue la compilation et le choix des types de matrices et de vecteurs à l’exécution. Vérifiez ces deux étapes. Aucun jeu d’options générique ne suffit à démontrer que le solveur OpenFOAM utilise le GPU.

Dictionnaires OpenFOAM : utiliser un exemple compatible

Reprenez un cas de test du module choisi et comparez-le à votre référence CPU. Vérifiez le chargement de la bibliothèque, le solveur sélectionné et les critères d’arrêt dans les journaux. N’inventez pas de noms de bibliothèques ou de mots-clés pour remplacer un exemple incompatible.

Les opérations prises en charge dépendent du backend PETSc et du préconditionneur. Profilez aussi les transferts de données : un solveur accéléré peut rester limité par les copies entre CPU et GPU.

Voie B : AmgX avec une interface OpenFOAM compatible

1. Choisissez et examinez l’interface qui relie votre version d’OpenFOAM à NVIDIA AmgX. Consignez son dépôt et son commit, ainsi que les versions d’AmgX et de CUDA.
2. Utilisez les exemples livrés avec cette interface pour relier les réglages OpenFOAM à la configuration AmgX. Testez un cas de référence avant d’adapter votre simulation.

Vérifier le chargement et les données transmises

Contrôlez la conversion de la matrice, la précision et les résidus renvoyés à OpenFOAM. Une bibliothèque chargée sans erreur ne prouve pas que les résultats, les critères d’arrêt et le fonctionnement avec MPI sont corrects.

Configuration AmgX : conserver les identifiants d’origine

Partez d’un fichier de configuration livré avec la version retenue. Ne traduisez ni les clés JSON ni les identifiants de solveur. Vérifiez d’abord la syntaxe, puis faites lire le fichier par la bibliothèque ; un JSON valide peut encore contenir des options incompatibles.

Sur un petit cas de référence, comparez les champs calculés, les résidus, les itérations et la convergence avec le résultat CPU. Répétez ces contrôles après chaque changement de solveur ou de préconditionneur avant de mesurer les performances.

Quand les GPU aident (et quand ils ne le font pas)

De bons candidats

• Écoulements incompressibles pour lesquels le profilage montre que la résolution de l’équation de pression occupe une part importante du temps total.
• Cas assez grands pour que le temps gagné sur les résolutions compense l’initialisation et les transferts. Il n’existe pas de seuil universel de 60 à 70 % du temps de calcul.
• Cas dont les matrices, vecteurs, préconditionneurs et espaces de travail tiennent en VRAM avec une marge suffisante. La taille du maillage seule ne suffit pas à estimer ce besoin.

Des candidats médiocres

• Petits maillages, entrées/sorties lourdes ou modèles dans lesquels l'assemblage est prépondérant.
• Cas dont les conditions aux limites, les matrices ou les algorithmes ne sont pas pris en charge par l’intégration choisie.

Notes sur les performances et la précision

• Conversions matricielles : mesurez leur coût et leur fréquence. Ne réduisez pas les mises à jour nécessaires à la justesse du calcul pour améliorer artificiellement un résultat de performance.
• Préconditionneur : comparez les options compatibles avec votre matrice et votre backend. Retenez une combinaison qui converge correctement, puis comparez le temps total ; aucun choix n’est optimal pour tous les cas.
• Précision : comparez les grandeurs physiques, les champs et les historiques de résidus à la référence CPU. Une exécution plus rapide n’est pas acceptable si elle résout un problème numérique différent.
• Plusieurs GPU : vérifiez la prise en charge par l’interface, MPI et le backend, puis mesurez la communication et le temps total. Ne multipliez pas un gain sur un GPU par le nombre de GPU.

Protocole minimal de comparaison

Consignez le solveur, la physique, le maillage, les conditions aux limites et les critères de convergence. Mesurez l’initialisation, l’assemblage, les résolutions, les transferts observables, les entrées/sorties et le temps total. Après un échauffement, répétez les essais et indiquez leur dispersion, ainsi que le pic de VRAM et les écarts à la référence CPU.

Coût par cas convergé

À tarif constant, le coût de calcul d’une exécution correspond au tarif horaire multiplié par sa durée facturée en heures. Pour comparer deux déploiements, comptabilisez aussi les essais de compilation, les réglages et les exécutions échouées, ainsi que les autres frais applicables.

Conservez les versions exactes, les commits, les fichiers de configuration et les journaux avec les résultats. Ils permettent de distinguer un gain mesuré d’un changement de méthode.

Résolution des problèmes

GPU visible, mais peu utilisé
Vérifiez le backend réellement sélectionné, puis identifiez les phases dominantes. L’assemblage sur CPU, les transferts ou un préconditionneur non exécuté sur GPU peuvent limiter le gain.

Mémoire GPU insuffisante
Mesurez la mémoire utilisée par les matrices, les vecteurs, le préconditionneur et les espaces de travail. Réduisez le cas pour le diagnostic seulement ; choisissez ensuite une capacité ou une méthode adaptée au cas à comparer.

Solveur inconnu ou bibliothèque manquante
Vérifiez les chemins et la compatibilité entre la distribution OpenFOAM, le compilateur, MPI et les dépendances utilisés à la compilation et à l’exécution. Reprenez les instructions de la version du module, sans traduire ses identifiants.

Convergence différente de la référence CPU
Vérifiez les algorithmes, les tolérances et les critères d’arrêt. Examinez les champs et les grandeurs physiques, pas seulement le dernier résidu affiché. Ne retenez pas un gain de temps avant d’avoir expliqué les écarts.

Informations à conserver avec les résultats

Matériel : CPU, nombre de processus, GPU, VRAM, mémoire hôte et interconnexion.
Logiciels : distribution OpenFOAM, versions ou commits du module et des dépendances, compilateur, MPI, pilote et toolkit.
Cas : données d’entrée, maillage, physique, conditions aux limites et critères de convergence.
Configuration : fichiers réellement utilisés, sans identifiants traduits ni options supposées universelles.
Résultats : temps total et par phase, répétitions, résidus, champs comparés, mémoire maximale et coût. Cette liste est un relevé de méthode, pas un fichier de configuration exécutable.

Lecture associée

Modélisation scientifique sur les GPU cloud : choisir les cas à tester

Vérifier la configuration Compute

Vérifiez la configuration disponible et sa compatibilité avec votre pile OpenFOAM avant de réserver une instance. Les modèles personnalisés permettent de réutiliser une configuration de conteneur, sans garantir la compatibilité de ses logiciels. Sauvegardez vos fichiers hors de l’instance. Selon la documentation de démarrage et d’arrêt, le redémarrage dépend des ressources disponibles et une instance arrêtée au-delà du délai de conservation indiqué dans cette documentation est automatiquement supprimée, avec ses données.

‍