Optimisation d'un code de calcul écrit en tâche sur calculateur à mémoire distribuée
| Auteur / Autrice : | Alice Lasserre |
| Direction : | Raymond Namyst, Abdou Guermouche |
| Type : | Projet de thèse |
| Discipline(s) : | Informatique |
| Date : | Inscription en doctorat le 18/10/2022 |
| Etablissement(s) : | Bordeaux |
| Ecole(s) doctorale(s) : | École doctorale de mathématiques et informatique |
| Partenaire(s) de recherche : | Laboratoire : LaBRI - Laboratoire Bordelais de Recherche en Informatique |
| Equipe de recherche : Supports et Algorithmes pour les applications numériques hautes performances (SATANAS) |
Mots clés
Mots clés libres
Résumé
Les évolutions des machines de calculs dédiés à la simulation les ont rendu plus complexe à programmer. Sur un nud de calcul, chaque processeur est désormais composé de plusieurs curs de calculs et il est possible d'avoir des accélérateurs. Les différents nuds de calculs ne partagent pas la mémoire et doivent communiquer via l'intermédiaire du réseau. Il n'est pas aisé d'obtenir des performances avec de telles machines : le programmeur devant prendre en compte les différentes unités de calcul et leur hétérogénéité. De plus, lors d'un changement de machine il est possible que les optimisations faites soient rendues caduques. La programmation à base de tâches exécutées par un moteur d'exécution cherche à pallier ce problème. Le problème est décrit sous forme de tâches et le moteur se charge de les répartir entre les différentes unités de calculs en respectant les différentes dépendances entre les tâches. Plusieurs stratégies d'ordonnancement sont ensuite possibles. Le code FLUSEPA (propriété d'ArianeGroup) est un code de CFD dont l'une des caractéristiques majeur est la capacité à traiter les problèmes instationnaires impliquant des corps en mouvement relatif. La gestion des corps en mouvement relatif se fait via l'intersection de plusieurs maillages, comparable à une méthode chimère. En règle générale, les calculs aérodynamiques représentent la majeure partie du calcul, cependant actuellement les changements de topologie entraînent un recalcul de nombreuses structures de données qui ralentissent fortement le calcul. Aujourd'hui, le solveur aérodynamique est parallélisé en tâches, qui sont ordonnancés par StarPU. Ce travail a nécessité une refonte des structures de données et une refactorisation du code. Les parties géométriques du code n'ont pas encore été parallélisées suivant ce paradigme. Cependant, une version du code écrite en MPI/OpenMP a montré qu'il était possible de calculer la topologie suivante pendant les calculs aérodynamiques sans perte de qualité notable en nécessitant toutefois une synchronisation lourde pour la réactualisation de la topologie. Le travail proposé consiste dans un premier temps à analyser et post-traiter les performances du code FLUSEPA pour ensuite améliorer les performances du solveur en tirant partie de la description du problème via un graphe de tâches. Pour le moment, le solveur aérodynamique de FLUSEPA est décrit sous forme de tâches. Une première décomposition de domaine permet de partager le travail pour différents nuds de calculs. Au sein de ces nuds une autre décomposition de domaine a lieu afin de pouvoir générer les tâches. Ces tâches peuvent ensuite être ordonnées de plusieurs manières. L'algorithme explicite d'avancement en temps dépend de la physique et certaines cellules nécessitent plus de calculs que d'autres. Ces cellules peuvent changer au cours des itérations et ainsi la charge de calcul évolue. De plus, un raffinement du maillage peut avoir lieu et modifier fortement la charge de calcul localement. Il est aujourd'hui possible de sortir une trace d'exécution d'une itération ainsi que les niveaux temporels de chaque cellules. Ces données peuvent être utilisées pour simuler une autre exécution en changeant à la fois les décompositions de domaines et l'ordonnancement. Il est donc possible de simuler d'autres exécutions à partir d'une exécution réelle en modifiant le graphe de tâches, via la décomposition de domaine. L'utilisation de ces simulations permet d'évaluer rapidement différentes stratégies. Il est ensuite possible d'injecter une décomposition de domaine dans la véritable simulation, afin de l'évaluer en conditions réelles. Une autre question importante concerne le rééquilibrage en cours de calcul de manière optimale : quand rééquilibrer et comment faire en sorte que l'application du rééquilibrage soit le moins coûteuse possible. Lors d'un calcul avec le solveur explicite, les échanges de données sont très locaux entre les cellules donc il est envisageable de pouvoir continuer le calcul pendant que certaines mailles sont échangées entre les différents domaines.