CHAPITRE 4 SIMULATION NUMERIQUE DES ECOULEMENTS GAZ
5.3 La structure du code couplé
STRUCTURES DES ALGORITHMES, PARALLELISATION
Nous présentons ici les bases qui ont été utilisées pour la construction du code dont les résultats ont été montrés dans les chapitres précédents. Dans une première partie, nous exposerons les algorithmes séquentiels utilisés pour le calcul de la phase granulaire. Ces algorithmes sont présentés dans le sous chapitre 5.1. Dans un souci de réduction et dæoptimisation des temps de calculs, la partie granulaire du code diphasique a été parallélisée. L’analyse de performances est un point très important lorsque l’on construit un code parallèle. Elle permet de connaître très précisément les algorithmes à améliorer, mais également d’utiliser des paramètres de calculs optimaux. En effet, bien que la taille des clusters soit toujours grandissante, le nombre d’utilisateurs l’est aussi. Cela contribue à une gestion des heures de calculs de plus en plus difficile. Il est donc nécessaire pour un problème donné de n’utiliser que les ressources nécessaires aux calculs et de les estimer au plus juste avant de se lancer dans la production de résultats. Plusieurs tests de performances ont été effectués pour obtenir la configuration optimale. Les méthodes utilisées sont détaillées dans le sous chapitre 5.2. Pour finir, læalgorithme complet du couplage entre la partie granulaire et la partie fluide sera présenté dans le sous chapitre 5.3
5.1. La phase granulaire : algorithmes séquentiels
Lorsque la résolution de la phase granulaire est basée sur des modèles DEM, le rôle du programme consiste à calculer les forces à appliquer à chaque particule. Pour cela, il est nécessaire de détecter les collisions entre les différentes particules. Une fois que les forces ont été calculées, le programme peut calculer la nouvelle position des particules.
Après l’initialisation, le programme de résolution de la phase granulaire est divisé en 4 grandes étapes effectuées à chaque pas de temps. La figure 5.1 donne l’ordre chronologique d’exécution des ces différentes tâches. Parmi ces étapes, la détection des contacts est particulièrement importante car cæest sur elle que repose læensemble du programme.
5
C h ap it reFig. 5.1. Algorithme général du déroulement du programme de DEM
5.1.1 La fonction de repérage
Le repérage des particules est la base de l’algorithme utilisé pour la recherche des contacts. Les explications concernant le choix de la méthode utilisée sont données dans le paragraphe suivant. L’algorithme de repérage consiste déterminer pour chaque maille les particules qui y sont présente. Une particule étant considérée comme appartenant à une cellule si son centre y est situé (Figure 5.2).
Fig. 5.2. Grille utilisée pour repérer les particules appartenant à une maille,
les particules grisées sont considérées comme appartenant à la cellule 13
5.1.2 La recherche des contacts
La recherche des contacts est une partie importante du programme de calcul de la phase granulaire. C’est en effet l’un des sous programme les plus chronophages. Lorsque la mécanique des milieux granulaires est traitée par des méthodes d’éléments distincts de type sphères molles, seuls les plus proches voisins, et uniquement les contacts directs collaborent à la mise en mouvement des grains. Il est donc nécessaire de bien soigner cette partie du programme. En partant du principe que les grains traités sont tous parfaitement sphériques, parmi l’ensemble des méthodes de recherche des voisins, la plus simple consiste à calculer, particule par particule, la distance entre chaque élément du lit de particules. Dès que la distance qui sépare le centre de deux particules est inférieure à la somme de leur rayon respectif, les particules sont en contact. Cet algorithme de complexité O
( )
n2 est extrêmement lent. Pour l’améliorer, il est possible de ne chercher pour la particule i que les contacts avec des particules ayant un rang j supérieur. Bien que deux fois plus rapide, cet algorithme conserve une complexité en O( )
n2 . Il n’est pas raisonnable d’utiliser un tel algorithme en présence d’un grand nombre de particules. Des algorithmes plus poussés tels que les Kd-Tree, la triangularisation de Delaunay ou encore la division spatiale régulière sont plus intéressants. Certains auteurs ont testés ces différentes méthodes [1], leurs conclusions quant à leur efficacité, dépendent de l’utilisation qui en est faite. Pour résumer, dans le cadre de particules de tailles homogènes, la complexité algorithmique de ces algorithmes dépend essentiellement de l’utilisation que l’on veut en faire. Les Kd-tree et triangulations de Delaunay ont des complexités algorithmiques d’ordre O (n logm(n)), où la base m du logarithme change si lecalcul est en 2D ou en 3D. C'est-à-dire que pour trouver les voisins directs, la base logarithmique sera m=4 pour un Quadtree, et m=8 pour un Octree. La méthode que nous avons utilisée est une décomposition spatiale cartésienne régulière du domaine ; cette méthode est également appelée méthode de chaînage [2]. Pour ce type d’algorithme, il a été montré que la taille des mailles doit être égale à la taille de la plus grosse particule présente dans le domaine. Pour être performant, il est également recommandé d’utiliser une distribution de taille des particules la plus faible possible. Le mécanisme de recherche est le suivant : Considérant une particule i au milieu d’un nuage d’autres particules, si toutes les particules du domaine ont la même taille, tous ses voisins potentiels seront positionnés dans une zone carrée de taille 3 mailles × 3 mailles (en rouge dans la figure 5.3). La fonction de repérage ayant déjà listé les particules appartenant à chaque maille, il ne reste plus qu’à calculer la distance entre la particule i et celles situées dans les 9 cases (27 en 3D) formant la zone des voisins potentiels.
Fig. 5.3. Exemple de recherche des voisins de la particule 3, les particules 1, 2, 4 et 5 seront testées, mais seules
les particules 2, 4 et 5 seront retenues comme étant en contact avec la particule 3. Le carré rouge délimite la zone de recherche des contacts des particules situées dans la maille 13.
Une seconde optimisation de la zone de recherche a été envisagée. Le principe consiste à utiliser la propriété de dualité de l’ensemble des solutions trouvées. En effet, si pour chaque particule nous faisons la liste de l’ensemble des voisins, alors, chaque solution trouvée sera double. Si A est voisin de B, B est également voisin de A. Ayant trouvé une solution, il n’est donc pas nécessaire de chercher la seconde. Pour cela, nous avons utilisé un algorithme de recherche "vers l’avant", c'est-à-dire que nous ne recherchons les voisins que dans la moitié "avant" de la zone de recherche définie précédemment, réduisant à 4 (13 en 3D) le nombre de cases contenant des voisins possibles (figure 5.4) [2].
Fig. 5.4. Apres optimisation de l’algorithme, seul les particules 4 et 5 seront retenues comme étant en contact
avec la particule 3. La particule 3 fera partie de la liste des contacts de la particule 2. Læaire rouge délimite la zone de recherche des contacts des particules situées dans la maille 13.
Cette optimisation permet de diviser par deux le nombre de voisins à rechercher, et donc également le temps passé à les chercher. En 2D, la complexité algorithmique d’une telle méthode est linéaire en O(n×4×m ) où m est le nombre moyen de particules par maille. Si la taille des mailles se rapproche de la taille des particules alors la complexité est en O (n ×4), ce qui est, de loin, la complexité algorithmique la plus faible de tous les algorithmes de recherche de l’ensemble des voisins directs. Il faut cependant ajouter que l’utilisation d’une seule particule beaucoup plus grosse que la moyenne réduira à néant les efforts fournis pour réduire la complexité algorithmique, et les méthodes de type Kd-tree ou triangulation de Delaunay peuvent devenir infiniment plus efficace que la méthode de chaînage. La dégradation de læefficacité ce cet méthode est liée au fait que la taille des mailles doit être égale à la taille de la plus grosse particule du domaine, ce qui multipliera automatiquement le nombre de petite particule présente dans chaque maille. Cette augmentation se traduira par une multiplication du nombre de tests à effectuer pour chaque particule voisine. La figure 5.5 présente une comparaison du temps d’exécution des trois algorithmes principaux : La recherche en O
( )
n2 , l’Octree et la méthode de chaînage (NBS) pour des particules de tailles identiques dans læensemble du domaine.Fig. 5.5. Comparaison des méthode de recherche de voisin (Boyalakuntla [1])
Nombre de particules T em p s (s )
5.2. La phase granulaire, parallélisation
5.2.1. Parallélisations, concepts de base
Aujourd’hui, et depuis quelques dizaines d’années déjà, la mise à disposition de supercalculateurs par les centres nationaux de calculs français et européens ont permis d’augmenter considérablement le nombre de configuration traitées par simulation numérique.
La méthode consiste à reformuler les algorithmes pour répartir les données à traiter sur un nombre de processeurs donné. Par la suite, nous ferons la distinction entre le processeur (matériel) et les processus (listes dæinstructions exécutées par les processeurs). Entre chaque instruction, ou tout du moins de façon assez régulière, il est nécessaire d’instaurer une sorte de dialogue entre les différents processus afin de synchroniser les tâches et les données à traiter. Si les tâches sont bien réparties, ce type de parallélisation permet de réduire drastiquement le temps d’exécution du programme pour un problème donné. Cependant, à nombre égal de configurations traitées, il y a de forte probabilité pour qu’une méthode scalaire soit plus rapide qu’un programme parallélisé. Ceci est dû au fait qu’en plus du temps d’exécution "normal" liés aux instructions de calculs, il faut ajouter le temps d’exécution des opérations de dialogue entre les différents processus associés à la tâche principale. La parallélisation "logicielle" est donc à réserver pour des codes dont les temps d’exécution atteignent plusieurs jours.
Dans le cadre de cette thèse, c’est sur la parallélisation de la partie granulaire via des bibliothèques dæéchange de messages de type MPI (Message Passing Interface) que repose les performances de l’ensemble du code. La figure 5.6 montre le schéma de principe de la parallélisation par échange de messages.
Fig. 5.6. Schéma de principe d’une parallélisation par échange de message. Les données à traiter sont distribuées
sur plusieurs cœurs, un dialogue est instauré entre les processus pour obtenir le résultat.
Résultats Données à
5.2.2. La répartition des tâches
Pour traiter un volume important de données avec un programme parallélisé de type MPI, la répartition des tâches est læoutil principal devant aider à réduire les temps de calcul. Cette répartition doit être faite avec soin car il est important de répartit équitablement la charge de chaque processeur. Une charge inégale provoquera indubitablement des temps dæexécution différents dæun processeur à læautre. Les processeurs les moins chargés, devront attendre le processeur le plus chargé dès quæune instruction de dialogue ou de synchronisation sera rencontrée, ralentissant par la même occasion læexécution du programme. Parmi les techniques de parallélisation par échange de messages, il en existe deux qui sont régulièrement utilisées. Il s’agit de la répartition spatiale par décomposition en sous-domaines réguliers (figure 5.7 a) ou, d’une répartition en nombre égal d’objets (figure 5.7 b). Ces deux méthodes sont utilisées dans le but dæéquilibrer la charge de chaque processeur. La décomposition en sous-domaines réguliers est généralement adoptée dans des milieux continus et homogènes alors que la décomposition par objets est utilisée pour des milieux discontinus ou hétérogènes. Il existe également des décompositions "en crayon" utilisées pour privilégier les dialogues dans une direction donnée [3].
Fig. 5.7. Répartition d’un calcul en sous domaines de tailles égales (a) ou par égalisation du nombre d’objet à
traiter (b). Dans chaque cas, la charge des processeurs doit être équilibrée.
La simulation d’un milieu granulaire et donc discontinu nous conduit à l’utilisation de la seconde méthode, cependant, comme nous l’avons vu dans le chapitre 2, le modèle DEM utilisé ne tient compte que des interactions proches, il est donc concevable d’essayer de stocker dans chaque processus un nombre à peu près égal de particules mais respectant également une certaine proximité. C’est donc une décomposition hybride, sous- domaine/nombre d’objets, qui a été envisagée.
Pour effectuer une répartition qui respecte les deux critères, nous avons décidé d’utiliser une
P1 P2 P3 P4 P1 P2 P3 (b) (a)
décomposition cartésienne non homogène du domaine de calcul. Bien qu’il existe certainement des décompositions plus efficaces [4], nous avons choisi celle-ci pour la simplicité de recherche des sous-domaines voisins. Une fois que l’utilisateur a choisi le nombre de divisions qu’il désire dans chaque direction, il suffit de trouver la position des interfaces de chaque sous-domaine.
Pour une répartition en n sous-domaines dans une direction donnée, l’opération consiste à trouver les n−1 quantiles calculés à partir de la position des particules dans la direction donnée. L’algorithme utilisé pour calculer les quantiles est basé sur un algorithme de tri rapide (Qsort) récursif avec un pivot aléatoire [5]. La figure 5.8 (a) montre la répartition d’un nuage de particules en 4 sous-domaines dans la direction x comprenant autant de particules, séparé par les trois quartiles calculés à partir des coordonnées en x des particules.
Ce type de répartition mixte aboutit à des sous-domaines continus, de tailles différentes, mais contenant tous autant de particules. Une fois qu’une répartition homogène en nombre de particules a été effectuée, il est nécessaire de gérer les interfaces entre les sous-domaines de façon à limiter les dialogues entre les différents processus. Pour faciliter les algorithmes, les interfaces entre les sous-domaines sont ramenées à læinterface entre les deux mailles les plus proche (figure 5.8 (b)).
Fig. 5.8. Répartition de 12 particules dans 4 sous-domaines. Les trais rouge représentent les quartiles délimitant
les sous domaines. En (a) répartition idéale, chaque sous-domaine contenant 3 particules. En (b) après avoir ramené les interfaces des sous domaines sur les interfaces entre les mailles les plus proches.
Les librairies MPI fournissent deux modes de communications très différents. Le premier est dit collectif, c'est-à-dire qu’il implique l’ensemble des processus appartenant à un même communicateur alors que le second, de type point à point, ne permet que la communication de processus deux à deux. Chaque mode ayant ses avantages et ses inconvénients. L’utilisation de communications collectives est relativement aisée puisqu’elle ne nécessite pas de gérer la
synchronisation des processus, ceux-ci étant tous concernés à chaque appel. Le principal défaut étant un envoi des données en impliquant l’ensemble des processus, chacun d’entre eux devant faire le tri concernant la pertinence ou non des données reçues. Deux inconvénients majeurs découlent de ce type de communication. Tout d’abord il peut engendrer un grand nombre de transferts de données inutiles, mais il bloque également l’ensemble des processus à chaque demande de dialogue. Pour éviter cela, le mode point à point est utilisé. Ce mode nécessite que chaque processus soit en mesure de savoir à quel moment un autre processus veut lui communiquer des données ainsi que le type et le nombre de données à recevoir. D’une gestion beaucoup plus difficile ce mode de communication permet également de minimiser les temps de communications ainsi que les volumes de données transférées. Par ailleurs, la communication point à point entre deux processus n’oblige pas les autres à arrêter leur tâche en cours. On perçoit donc tout læintérêt que læon a à adopter une telle approche. Toute la difficulté réside dans la gestion des appels aux routines de communication. Chaque appel doit être effectué au bon moment pour être sûr que le processus avec lequel il faut instaurer le dialogue soit près à communiquer. Une mauvaise gestion des communications par le programmeur peut à terme engendrer des temps d’attente de messages très longs, voir des blocages du programme et du coup dégrader les performances espérées.
Bien que ce mode de dialogue soit un peut plus délicat à utiliser, c’est ce que nous avons mis en œuvre puisque son utilisation à bon escient doit permettre d’optimiser les temps d’exécution du programme. Cependant, pour faciliter la gestion de la synchronisation des différents processus, nous nous sommes limités à des appels dits bloquants des routines de communications. Dans leurs versions non bloquantes, les routines de communications permettent de recouvrir par des calculs les temps dæattente liés à la synchronisation. Cet avantage, souvent synonyme dæexécution plus rapide du programme, ajoute un niveau de difficulté à la programmation. En effet, contrairement aux communication dites bloquantes, il est nécessaire de vérifier si les données que læon veut traiter ont bien été reçues. Dans les communications bloquantes, rien ne peut être exécuté tant que la communication næest pas achevée, ce qui garantie le disponibilité des données au moment de leur traitement. Pour sæassurer de la disponibilité des processus au moment dæune communication, il est possible de placer des barrières de synchronisation. La barrière de synchronisation ne peut être franchie que si læensemble des processus a atteint læinstruction barrière, obligeant alors les processus les plus rapides à attendre les plus lents. Une fois que la répartition et le mode de communication ont été choisis, nous avons regardé ce que cela impliquait en termes de modification des algorithmes.
La majorité des algorithmes qui ont été mis en place jusqu’ici sont basés sur une boucle parcourant soit les particules, soit les mailles du domaine. La seule modification qui doit leur être apporté consiste donc à n’effectuer les boucles que sur les particules et les mailles appartenant au sous-domaine. Pour cela, des tableaux locaux, propres à chaque sous-domaines
sont déclarés. Cela permet dæune part de travailler avec des tableaux de taille plus petite et continus en mémoire. Dæautre part en limitant læespace nécessaire à chaque processus, les temps dæaccès à la mémoire seront optimisés.
5.2.3 Læalgorithme de recherche des contacts
La parallélisation par répartition en sous domaines entraîne des modifications importantes de l’algorithme de recherche des contacts. En effet, si à l’intérieur des sous- domaines il ne semble pas y avoir de différence majeur entre la version parallélisée et celle qui ne l’est pas, il n’en est pas de même à proximité des interfaces entre les différents sous- domaines.
Comme nous l’avons vu précédemment l’algorithme de recherche des voisins dæune particule i n’implique qu’une recherche "vers l’avant", et toujours d’une maille maximum en aval de la maille contenant la particule i. Par soucis d’efficacité, nous avons souhaité conserver cette méthode de recherche. Lorsque la recherche de contact doit se faire entre une particule i appartenant à un sous-domainde d1 et une particule j du sous-domaine d2, il est nécessaire que le processus qui gère le sous-domaine d1 soit également en mesure de connaître les particules situées dans les mailles appartenant au sous-domaine d2.
Pour résoudre ce problème, deux solutions s’offrent à nous : La première consiste à instaurer un dialogue avec le processus voisin dès que ce cas est rencontré, ce qui à de grandes chances d’arriver souvent puisque nous utilisons des lits de particules compacts. De plus, la synchronisation des dialogues semble relativement difficile, le processus appelé ne pouvant présager du moment de l’appel. La seconde solution consiste à prévenir ce genre de situation en envoyant en avance aux processus voisins toutes les particules appartenant aux mailles proche des interfaces entre les sous-domaines. Cette opération s’effectue avant l’appel à la routine de recherche des voisins. Bien que plus coûteuse en terme de tailles de messages puisque des particules n’ayant pas besoin d’être transférées le seront nécessairement, cette solution est beaucoup plus facile à mettre en œuvre d’un point de vue synchronisation des dialogues. Cette synchronisation étant naturelle puisque c’est toujours avant la recherche des contacts que le dialogue est instauré. La mise en place de cette solution consiste à créer une "bande interface" de la taille d’une maille placée en aval de chaque sous-domaine pour y placer les particules reçues de ces mêmes processus (Figure 5.9). Une "bande interface"