OpenFoam

De Wiki de Calcul Québec
Aller à : Navigation, rechercher
Autres langues :anglais 100% • ‎français 100%

Note : Cette documentation a été testée sur Colosse. Certaines instructions pourraient être différentes sur d'autres serveurs.

Sommaire

Description

OpenFOAM (Open Field Operation and Manipulation) est un code multi-physiques principalement axé sur la résolution des équations de la mécanique des fluides. C'est une application MPI qui est bien adaptée à une utilisation sur une grappe de calcul parallèle.

Il s'agit d'un code ouvert (open source).

Particularités

OpenFoam a quelques particularités qu'il faut bien comprendre pour en faire une utilisation optimale sur une grappe de calcul et ne pas nuire à la stabilité du système.

Création d'un grand nombre de fichiers

OpenFoam génère un grand nombre de fichiers de sortie. La création d'un point de sauvegarde (checkpoint) engendre la création d'un répertoire par rang MPI et contenant un fichier par paramètre. Pour une exécution sur plusieurs dizaines de cœurs, on crée donc plusieurs centaines de fichiers par checkpoint ce qui a le potentiel de résulter dans des milliers, voire des dizaines de milliers de fichiers après quelques heures d'exécution seulement. Ces fichiers, quoique de petites tailles, peuvent saturer le système de fichier et ainsi vous faire excéder rapidement votre quota sur les systèmes.

Génération d'une charge importante sur un système de fichier parallèle

Il faut comprendre que chaque opération sur un fichier génère une ou plusieurs opérations d'entrées-sorties sur le système de fichiers. Des exemples d'opérations d'entrées-sorties pourraient être : ouverture ou fermeture d'un fichier (open, close), écriture ou lecture de données d'un fichier (read, write), demande des propriétés d'un fichier (stat). Un système de fichier donné peut seulement répondre à une quantité donnée d'opérations d'entrées-sorties sur une période de temps. On mesure cette valeur en opérations d'entrées-sorties par seconde (iops). Une application qui génère un nombre très élevé d'iops cause une charge importante sur le système de fichier et aura ainsi un impact négatif sur ses propres performances, mais aussi sur les performances du système de fichiers pour les autres usagers.

OpenFoam a le potentiel, de par son design, de générer une quantité élevée d'iops. Nous avons observé des charges, en fonction du problème et des paramètres utilisés, de 50 iops à près de 50000 iops par nœud de calcul utilisé (huit cœurs). L'impact sur les autres utilisateurs du système peut être considérable.

Bonnes pratiques

Quelques conseils pour tirer les meilleures performances possible d'OpenFoam et minimiser les impacts négatifs sur le système.

  • Réduire la fréquence des événements de sauvegarde (checkpointing)
  • Réduire la quantité de fichiers de sauvegardes conservés pendant l'exécution de la tâche : Il est possible de réduire de façon importante la quantité de sauvegardes en utilisant le paramètre purgeWrite dans system/controlDict. Ce paramètre permet de contrôler le nombre de sauvegardes qui seront conservées en cours de calcul. Lorsque le nombre de purgeWrite est à 0, toutes les sauvegardes sont conservées. Par contre, lorsqu'une valeur supérieure à 0 est utilisée, cette valeur indique le nombre de sauvegardes à conserver. Les sauvegardes plus anciennes sont alors effacées lorsque les plus récentes sont écrites. Cela permet d'utiliser une fréquence élevée de sauvegardes tout en limitant la quantité de fichiers créés.
  • Effectuer rapidement le post-traitement sur les résultats de calculs : Il est de bonne pratique de faire rapidement le post-traitement de résultats de calculs d'OpenFoam pour faire l'agrégation des fichiers de résultats. Cette opération permettra de rapidement réduire le nombre de fichiers conservés sur le système et donc de vous permettre de continuer de lancer d'autres calculs sans excéder vos limites de nombre de fichiers.
  • Éviter les 'pas de temps' (timestep) de calcul très courts : La durée, en temps de calcul, d'un pas de temps de votre simulation a un impact majeur sur les performances de votre tâche. En effet, la fin de chaque pas de temps impliquant une synchronisation des données et l'écriture d'information dans le fichier de log, la réduction de celui-ci réduit la proportion du 'temps de calcul' Vs 'événement de synchronisation' et réduit donc plus ou moins proportionnellement les performances par cœur de l'application. Il est donc bénéfique, lorsque possible, de viser des 'pas de temps' plus long. Cela peut se faire, par exemple, en augmentant le nombre de cellules par cœur.
  • Utiliser OpenFoam sans permettre les modifications en cours d'exécution : Par défaut, OpenFoam permet à l'utilisateur de modifier les paramètres du problème en cours d'exécution. Cette fonctionnalité force l'application à surveiller les fichiers d'entrées tout au long de l'exécution et donc à en demander les propriétés (stats) entre chaque pas de temps. Lorsque combiné à un pas de temps très court, cela peut engendrer plusieurs dizaines de milliers d'iops sans aucun gain. Quoique très utile lorsque l'on développe/détermine les paramètres exacts de nos simulations, il est préférable de désactiver cette fonctionnalité pour augmenter les performances d'OpenFoam. Des tests effectués localement ont permis de vérifier que la désactivation de cette fonction engendrait une réduction d'un facteur 10 du nombre d'iops générés par une exécution d'OpenFoam et incidemment une réduction de plus de 20 % du temps de calcul pour un problème donné. L'option « runTimeModifiable » dans le fichier de dictionnaire d'une tâche OpenFoam (system/controlDict) permet de contrôler cette fonctionnalité.

Merci à l'équipe du professeur Guy Dumas du département de Génie Mécanique de l'Université Laval dans l'élaboration de ces recommandations et plus spécialement à Simon Lapointe.

Module OpenFOAM 2.1.0

Certaines variables d'environnement ne sont pas définies par ce module par souci de cohérence. Ces variables pointent habituellement vers les répertoires utilisateur et site. Voici une liste de ces variables d'environnement ainsi que la valeur standard qu'elles devraient prendre. L'utilisation de ces variables n'est pas nécessaire si vous n'avez pas de contenu additionnel.

Variable Valeur
WM_PROJECT_USER_DIR $HOME/$WM_PROJECT/$USER-$WM_PROJECT_VERSION
FOAM_SITE_APPBIN $WM_PROJECT_INST_DIR/site/platforms/$WM_OPTIONS/bin
FOAM_SITE_LIBBIN $WM_PROJECT_INST_DIR/site/platforms/$WM_OPTIONS/lib
FOAM_USER_APPBIN $WM_PROJECT_USER_DIR/platforms/$WM_OPTIONS/bin
FOAM_USER_LIBBIN $WM_PROJECT_USER_DIR/platforms/$WM_OPTIONS/bin
FOAM_RUN $WM_PROJECT_USER_DIR/run

Pour ajouter ces variables à votre environnement, utilisez la commande export. Par exemple, pour ajouter WM_PROJECT_USER_DIR,

[nom@serveur $]  export WM_PROJECT_USER_DIR=$HOME/$WM_PROJECT/$USER-$WM_PROJECT_VERSION 


Notez que ce qui est à droite du = peut prendre n'importe quelle valeur.

Si vous ajoutez FOAM_SITE_APPBIN, FOAM_SITE_LIBBIN, FOAM_USER_APPBIN et FOAM_USER_LIBBIN, n'oubliez pas non plus de les ajouter à votre PATH et LD_LIBRARY_PATH.

Un alias n'est pas non plus défini, run. Pour le définir :

[nom@serveur $]  alias run "cd $FOAM_RUN"


Il est toujours possible (mais pas nécessaire) de « sourcer » la configuration par défaut en utilisant la variable d'environnement OPENFOAM_ETC comme ceci :

[nom@serveur $]  source $OPENFOAM_ETC/bashrc


Outils personnels
Espaces de noms

Variantes
Actions
Navigation
Ressources de Calcul Québec
Outils
Partager